[Bug c++/97885] New: overload resolution fails with the existence of both a constrained and a non-constrained template

[nickgray0 at brown dot edu via Gcc-bugs]

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

Bug ID: 97885
   Summary: overload resolution fails with the existence of both a
constrained and a non-constrained template
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nickgray0 at brown dot edu
  Target Milestone: ---

see: https://godbolt.org/z/aqe9nq

the constrained overload should be invoked, however the compiler reports that
the overload resolution is ambiguous. This bug does not exist in GCC 10.1, it
first appears in GCC 10.2 and affects all versions of GCC onwards including GCC
trunk.

[Bug target/97875] suboptimal loop vectorization

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org

--- Comment #3 from Richard Biener  ---
That would then point to DR_TARGET_ALIGNMENT being wrong here.  Now, not sure
whether we can guarantee to pick the "correct" instruction at RTL expansion but
surely the vectorizer can elide the runtime alignment check and emit
appropriately aligned (to vector element) vector loads / stores here.

You mention vldrw.32 but I assume the same applies to vstrw.32

[Bug c++/97878] [8/9/10/11 Regression] ICE in cxx_eval_outermost_constant_expr, at cp/constexpr.c:6825

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
Summary|[9/10/11 Regression] ICE in |[8/9/10/11 Regression] ICE
   |cxx_eval_outermost_constant |in
   |_expr, at   |cxx_eval_outermost_constant
   |cp/constexpr.c:6825 |_expr, at
   ||cp/constexpr.c:6825

[Bug tree-optimization/97736] [9/10/11 Regression] switch codegen

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

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

--- Comment #13 from Martin Liška  ---
(In reply to ncm from comment #12)
> As it is, your probability of failure in 9 and 10 is exactly 1.0.

I don't get this?

We speak a possibility that we break a stable release branch by a backport that
can somehow interact with other parts of the compiler. The purpose of stable
branches is to keep them as stable as possible.

This bug is a minor performance issue, not any wrong code or a compiler crash.

[Bug c/97879] [11 Regression] ICE in from_mode_char, at attribs.h:298

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |11.0
 CC||msebor at gcc dot gnu.org

[Bug c/97880] [8/9/10/11 Regression] ICE in emit_library_call_value_1, at calls.c:5298

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||openacc
   Target Milestone|--- |8.5
Summary|[9/10/11 Regression] ICE in |[8/9/10/11 Regression] ICE
   |emit_library_call_value_1,  |in
   |at calls.c:5298 |emit_library_call_value_1,
   ||at calls.c:5298

[Bug sanitizer/97868] warn about using fences with TSAN

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

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2020-11-18
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED

--- Comment #1 from Martin Liška  ---
I can take care of it. First, we can discuss that with upstream.

[Bug c++/97881] [11 Regression] ICE in warn_about_ambiguous_parse, at cp/parser.c:20800

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug target/97847] [11 Regression] ICE in insert_insn_on_edge, at cfgrtl.c:1976

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #2 from Martin Liška  ---
I've just reproduced that on gcc110 machine with the following revision
g:4b81528241ca682025d92558ff6aeec91dafdca8

$ ./xgcc -v
Using built-in specs.
COLLECT_GCC=./xgcc
Target: powerpc64-unknown-linux-gnu
Configured with: ../configure --disable-bootstrap --enable-languages=c,c++,lto
--prefix=/home/marxin/bin/gcc
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20201118 (experimental) (GCC) 

$ ./xgcc -B.
/home/marxin/Programming/gcc/gcc/testsuite/gcc.c-torture/compile/pr32919.c
-mno-speculate-indirect-jumps -c --verbose
Reading specs from ./specs
COLLECT_GCC=./xgcc
Target: powerpc64-unknown-linux-gnu
Configured with: ../configure --disable-bootstrap --enable-languages=c,c++,lto
--prefix=/home/marxin/bin/gcc
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20201118 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-B' '.' '-mno-speculate-indirect-jumps' '-c' '-v'
 ./cc1 -quiet -v -iprefix
/home/marxin/Programming/gcc/objdir/gcc/../lib/gcc/powerpc64-unknown-linux-gnu/11.0.0/
-isystem ./include -isystem ./include-fixed
/home/marxin/Programming/gcc/gcc/testsuite/gcc.c-torture/compile/pr32919.c
-quiet -dumpbase pr32919.c -dumpbase-ext .c -mno-speculate-indirect-jumps
-version -o /tmp/cc35CrAT.s
GNU C17 (GCC) version 11.0.0 20201118 (experimental)
(powerpc64-unknown-linux-gnu)
compiled by GNU C version 4.8.5 20150623 (Red Hat 4.8.5-39), GMP
version 6.0.0, MPFR version 3.1.1, MPC version 1.0.1, isl version none
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
ignoring nonexistent directory
"/home/marxin/Programming/gcc/objdir/gcc/../lib/gcc/powerpc64-unknown-linux-gnu/11.0.0/include"
ignoring nonexistent directory
"/home/marxin/Programming/gcc/objdir/gcc/../lib/gcc/powerpc64-unknown-linux-gnu/11.0.0/include-fixed"
ignoring nonexistent directory
"/home/marxin/Programming/gcc/objdir/gcc/../lib/gcc/powerpc64-unknown-linux-gnu/11.0.0/../../../../powerpc64-unknown-linux-gnu/include"
ignoring nonexistent directory
"/home/marxin/Programming/gcc/objdir/gcc/../lib/gcc/../../lib/gcc/powerpc64-unknown-linux-gnu/11.0.0/include"
ignoring nonexistent directory
"/home/marxin/Programming/gcc/objdir/gcc/../lib/gcc/../../include"
ignoring nonexistent directory
"/home/marxin/Programming/gcc/objdir/gcc/../lib/gcc/../../lib/gcc/powerpc64-unknown-linux-gnu/11.0.0/include-fixed"
ignoring nonexistent directory
"/home/marxin/Programming/gcc/objdir/gcc/../lib/gcc/../../lib/gcc/powerpc64-unknown-linux-gnu/11.0.0/../../../../powerpc64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 ./include
 ./include-fixed
 /usr/local/include
 /usr/include
End of search list.
cc1: warning: ‘-mno-speculate-indirect-jumps’ is deprecated and not recommended
in any circumstances
GNU C17 (GCC) version 11.0.0 20201118 (experimental)
(powerpc64-unknown-linux-gnu)
compiled by GNU C version 4.8.5 20150623 (Red Hat 4.8.5-39), GMP
version 6.0.0, MPFR version 3.1.1, MPC version 1.0.1, isl version none
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 7d94193eb0258434742b800b3306907a
/home/marxin/Programming/gcc/gcc/testsuite/gcc.c-torture/compile/pr32919.c: In
function ‘_IO_vfprintf_internal’:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.c-torture/compile/pr32919.c:13:6:
warning: implicit declaration of function ‘read_int’
[-Wimplicit-function-declaration]
   13 |  read_int (&f);
  |  ^~~~
/home/marxin/Programming/gcc/gcc/testsuite/gcc.c-torture/compile/pr32919.c:15:5:
warning: implicit declaration of function ‘_itoa_word’
[-Wimplicit-function-declaration]
   15 | _itoa_word (spec);
  | ^~
/home/marxin/Programming/gcc/gcc/testsuite/gcc.c-torture/compile/pr32919.c:23:7:
warning: implicit declaration of function ‘__strnlen’
[-Wimplicit-function-declaration]
   23 |   __strnlen ();
  |   ^
during RTL pass: ira
/home/marxin/Programming/gcc/gcc/testsuite/gcc.c-torture/compile/pr32919.c:28:1:
internal compiler error: in ira, at ira.c:5432
   28 | }
  | ^
0x10839583 ira
../../gcc/ira.c:5432
0x10839583 execute
../../gcc/ira.c:5945
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/97884] INT_MIN falsely expanded to 64 bit

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
You need to write -2147483647 - 1 to make it 'int', -2147483648 are two tokens
and the second is too large for int.

[Bug ipa/92535] [10/11 regression] ICF is relatively expensive and became less effective

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

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

--- Comment #13 from Jan Hubicka  ---
Actually, I did not wait long enough for ICF to finish dumping. Here is the
correct output. Still nice improvement for OBJ_TYPE_REF

   8399   false returned: 'parameter type is not compatible' in
compatible_parm_types_p at ../../gcc/ipa-icf.c:512
  10187   false returned: 'inline attributes are different' in
compare_referenced_symbol_properties at ../../gcc/ipa-icf.c:350
  16217   false returned: 'parameter types are not compatible' in equals_wpa at
../../gcc/ipa-icf.c:639
  26071   false returned: 'references to virtual tables cannot be merged' in
compare_referenced_symbol_properties at ../../gcc/ipa-icf.c:373
  28812   false returned: 'decl_or_type flags are different' in equals_wpa at
../../gcc/ipa-icf.c:572
  32287   false returned: 'different tree types' in compatible_types_p at
../../gcc/ipa-icf-gimple.c:206
  60520   false returned: 'call function types are not compatible' in
compare_gimple_call at ../../gcc/ipa-icf-gimple.c:635
 103684   false returned: 'types are not compatible' in compatible_types_p at
../../gcc/ipa-icf-gimple.c:212
 119994   false returned: 'result types are different' in equals_wpa at
../../gcc/ipa-icf.c:621
 134888   false returned: '' in compare_gimple_call at
../../gcc/ipa-icf-gimple.c:607
 264624   false returned: 'compare_ao_refs failed (semantic difference)' in
compare_operand at ../../gcc/ipa-icf-gimple.c:336
 456907   false returned: 'THIS pointer ODR type mismatch' in equals_wpa at
../../gcc/ipa-icf.c:677
 460246   false returned: 'types are not same for ODR' in
compatible_polymorphic_types_p at ../../gcc/ipa-icf-gimple.c:197
 881974   false returned: 'operand_equal_p failed' in compare_operand at
../../gcc/ipa-icf-gimple.c:356
1011296   false returned: 'GIMPLE assignment operands are different' in
compare_gimple_assign at ../../gcc/ipa-icf-gimple.c:699
1239444   false returned: '' in equals_private at ../../gcc/ipa-icf.c:886

[Bug c++/97885] [10/11 Regression] overload resolution fails with the existence of both a constrained and a non-constrained templates

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||rejects-valid
   Target Milestone|--- |10.3
  Known to work||10.1.0
Summary|overload resolution fails   |[10/11 Regression] overload
   |with the existence of both  |resolution fails with the
   |a constrained and a |existence of both a
   |non-constrained templates   |constrained and a
   ||non-constrained templates
  Known to fail||10.2.0, 11.0

[Bug c/97880] [8/9/10/11 Regression] ICE in emit_library_call_value_1, at calls.c:5298

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2020-11-18
 CC||cesar at codesourcery dot com,
   ||marxin at gcc dot gnu.org,
   ||nathan at gcc dot gnu.org

--- Comment #1 from Martin Liška  ---
Confirmed, started with r7-6598-g02889d23ee3b0285.

[Bug c/97879] [11 Regression] ICE in from_mode_char, at attribs.h:298 since r11-3303-g6450f07388f9fe57

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

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2020-11-18
 Status|UNCONFIRMED |NEW
  Known to work||10.2.0
 Ever confirmed|0   |1
  Known to fail||11.0
 CC||marxin at gcc dot gnu.org
Summary|[11 Regression] ICE in  |[11 Regression] ICE in
   |from_mode_char, at  |from_mode_char, at
   |attribs.h:298   |attribs.h:298 since
   ||r11-3303-g6450f07388f9fe57

--- Comment #2 from Martin Liška  ---
Started with r11-3303-g6450f07388f9fe57.

[Bug target/97865] libtool needs to be updated for Darwin20.

[juergen.reuter at desy dot de via Gcc-bugs]

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

--- Comment #14 from Jürgen Reuter  ---
If there is a git branch or so, I could also test it on my system with our code
whether this works as expected.

[Bug middle-end/97862] [11 Regression] ICE in expand_omp_for_init_vars, at omp-expand.c:2524

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

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

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

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

commit r11-5121-gba009860aec4619f2424f5bdee812f14572dc3cc
Author: Jakub Jelinek 
Date:   Wed Nov 18 09:40:45 2020 +0100

openmp: Fix ICE on non-rectangular loop with known 0 iterations

The loops in the testcase are non-rectangular and have 0 iterations
(the outer loop iterates, but the inner one never).  In this case we
just have the overall number of iterations computed (0), and don't have
factor and other values computed.  We never need to map logical iterations
to the individual iterations in that case, and we were crashing during
expansion of that code.

2020-11-18  Jakub Jelinek  

PR middle-end/97862
* omp-expand.c (expand_omp_for_init_vars): Don't use the sqrt path
if number of iterations is constant 0.

* c-c++-common/gomp/pr97862.c: New test.

[Bug tree-optimization/97832] AoSoA complex caxpy-like loops: AVX2+FMA -Ofast 7 times slower than -O3

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

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

--- Comment #6 from Richard Biener  ---
So for example we'd like to vectorize with SLP when reassociation is permitted
(thus with -Ofast for example):

double a[1024], b[1024], c[1024];

void foo()
{
  for (int i = 0; i < 256; ++i)
{
  a[2*i] = 1. - a[2*i] + b[2*i];
  a[2*i+1] = a[2*i+1] + b[2*i+1] + 1.;
}
}

it again works when written as follows and with -fno-tree-reassoc

double a[1024], b[1024], c[1024];

void foo()
{
  for (int i = 0; i < 256; ++i)
{
  a[2*i] = 1. - a[2*i] + b[2*i];
  a[2*i+1] = 1 + a[2*i+1] + b[2*i+1];
}
}

[Bug tree-optimization/97886] New: [11 Regression] ICE in vect_slp_analyze_node_operations, at tree-vect-slp.c:3528 since r11-4428-g4a369d199bf2f34e037030b18d0da923e8a24997

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

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

Bug ID: 97886
   Summary: [11 Regression] ICE in
vect_slp_analyze_node_operations, at
tree-vect-slp.c:3528 since
r11-4428-g4a369d199bf2f34e037030b18d0da923e8a24997
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
  Target Milestone: ---

Since the revision, the following ICEs:

$ ./xgcc -B.
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/torture/pr95295-3.c
-fgraphite --param=unroll-jam-min-percent=0
--param=max-completely-peeled-insns=0 -Ofast -c
during GIMPLE pass: vect
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/torture/pr95295-3.c: In
function ‘test’:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/torture/pr95295-3.c:7:6:
internal compiler error: in vect_slp_analyze_node_operations, at
tree-vect-slp.c:3528
7 | void test()
  |  ^~~~
0x17e52fd vect_slp_analyze_node_operations
/home/marxin/Programming/gcc2/gcc/tree-vect-slp.c:3528
0x17e51b1 vect_slp_analyze_node_operations
/home/marxin/Programming/gcc2/gcc/tree-vect-slp.c:3490
0x17e59cf vect_slp_analyze_operations(vec_info*)
/home/marxin/Programming/gcc2/gcc/tree-vect-slp.c:3682
0x17aaa6f vect_analyze_loop_2
/home/marxin/Programming/gcc2/gcc/tree-vect-loop.c:2338
0x17ac378 vect_analyze_loop(loop*, vec_info_shared*)
/home/marxin/Programming/gcc2/gcc/tree-vect-loop.c:2799
0x17fae5c try_vectorize_loop_1
/home/marxin/Programming/gcc2/gcc/tree-vectorizer.c:995
0x17fb60e try_vectorize_loop
/home/marxin/Programming/gcc2/gcc/tree-vectorizer.c:1146
0x17fb808 vectorize_loops()
/home/marxin/Programming/gcc2/gcc/tree-vectorizer.c:1229
0x1622ef7 execute
/home/marxin/Programming/gcc2/gcc/tree-ssa-loop.c:414
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/97886] [11 Regression] ICE in vect_slp_analyze_node_operations, at tree-vect-slp.c:3528 since r11-4428-g4a369d199bf2f34e037030b18d0da923e8a24997

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

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

Martin Liška  changed:

   What|Removed |Added

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

[Bug tree-optimization/97832] AoSoA complex caxpy-like loops: AVX2+FMA -Ofast 7 times slower than -O3

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

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

--- Comment #7 from Richard Biener  ---
Or

double a[1024], b[1024], c[1024];

void foo()
{
  for (int i = 0; i < 256; ++i)
{
  a[2*i] = 1. - a[2*i] + b[2*i];
  a[2*i+1] = 1 + a[2*i+1] - b[2*i+1];
}
}

which early folding breaks unless we add -fno-associative-math.  We then
end up with

  a[_1] = (((b[_1]) - (a[_1])) + 1.0e+0);
  a[_6] = (((a[_6]) - (b[_6])) + 1.0e+0);

where SLP operator swaping cannot handle to bring the grouped loads into
the same lanes.

So the idea is to look at single-use chains of plus/minus operations and
handle those as wide associated SLP nodes with flags denoting which lanes
need negation.  We'd have three children and each child has a per-lane
spec whether to add or subtract.

[Bug c++/97885] [10/11 Regression] overload resolution fails with the existence of both a constrained and a non-constrained templates

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
The bug reporting guidelines require the code to be provided here, not just via
URL to some other site. See https://gcc.gnu.org/bugs/

GCC is right to say this is ambiguous. The overloads do not have equivalent
template parameters and function parameters, so we should not compare the
constraints to see which is "more constrained". In this case one takes its
argument by value and one takes its argument by reference.

Change the first one to f(weak_same auto&&) and it will be more constrained.

The change between gcc-10.1 and gcc-10.2 was done by
g:c3d4dbc68be1484294143a3d0e0d86034e9aa883 and the commit log for that change
refers to https://wg21.link/p2113

[Bug c++/97885] [10/11 Regression] overload resolution fails with the existence of both a constrained and a non-constrained templates

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

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

--- Comment #2 from Jonathan Wakely  ---
The code from the godbolt link is:

#include 

template
concept weak_same = std::same_as, U>;

enum struct A {
x
};

auto f(weak_same auto) {}
auto f(auto&&) {}

auto main()->int {
f(A::x);
}

The function templates can be rewritten as:


template requires weak_same
auto f(T) { }
template
auto f(T&&) { }

Which shows the difference in function parameters more clearly.

The fixed version would use:

template requires weak_same
auto f(T&&) { }
template
auto f(T&&) { }

Or using the abbreviated syntax:

auto f(weak_same auto&&) {}
auto f(auto&&) {}

[Bug tree-optimization/97886] [11 Regression] ICE in vect_slp_analyze_node_operations, at tree-vect-slp.c:3528 since r11-4428-g4a369d199bf2f34e037030b18d0da923e8a24997

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
Mine.  This is odd IL - we're having a PHI node copying an extern and we're
getting confused about it

pr95295-3.c:7:6: note: node 0x399c5a0 (max_nunits=16, refcnt=1)
pr95295-3.c:7:6: note:  stmt 0 arr_2_I_lsm.9_41 = PHI <_4(31)>
pr95295-3.c:7:6: note:  children 0x399c450
pr95295-3.c:7:6: note: node (external) 0x399c450 (max_nunits=1, refcnt=1)
pr95295-3.c:7:6: note:  { _4 }

of course I never thought we'll run into this ;)

[Bug target/97887] New: Failure to optimize neg plus div to avoid using x87 floating point stack

[gabravier at gmail dot com via Gcc-bugs]

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

Bug ID: 97887
   Summary: Failure to optimize neg plus div to avoid using x87
floating point stack
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gabravier at gmail dot com
  Target Milestone: ---

float f(float a)
{
return -a / a;
}

On x86 -O3, LLVM outputs this:

.LCPI0_0:
  .long 0x8000 # float -0
  .long 0x8000 # float -0
  .long 0x8000 # float -0
  .long 0x8000 # float -0
f(float):
  movaps xmm1, xmmword ptr [rip + .LCPI0_0] # xmm1 =
[-0.0E+0,-0.0E+0,-0.0E+0,-0.0E+0]
  xorps xmm1, xmm0
  divss xmm1, xmm0
  movaps xmm0, xmm1
  ret

GCC outputs this:

f(float):
  movss DWORD PTR [rsp-4], xmm0
  fld DWORD PTR [rsp-4]
  movaps xmm1, xmm0
  fchs
  fstp DWORD PTR [rsp-4]
  movss xmm0, DWORD PTR [rsp-4]
  divss xmm0, xmm1
  ret

I'm *pretty sure* that loading the value into the x87 stack (especially mixed
with SSE instructions) is much slower than using SSE instructions for this.

[Bug tree-optimization/97888] New: wrong code at -Os and above on x86_64-pc-linux-gnu

[zhendong.su at inf dot ethz.ch via Gcc-bugs]

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

Bug ID: 97888
   Summary: wrong code at -Os and above on x86_64-pc-linux-gnu
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhendong.su at inf dot ethz.ch
  Target Milestone: ---

[525] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--prefix=/local/suz-local/software/local/gcc-trunk --enable-languages=c,c++
--disable-werror --enable-multilib --with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20201118 (experimental) [master revision
b03be74bad0:b7ec4b4b7a1:4b81528241ca682025d92558ff6aeec91dafdca8] (GCC) 
[526] % 
[526] % gcctk -O1 small.c; ./a.out
[527] % 
[527] % gcctk -Os small.c
[528] % ./a.out
Illegal instruction
[529] % 
[529] % cat small.c
int a = 1, b, c = 4, d, e;

int main() {
  int f = 2273363750;
  for (; b < 10; b++) {
int g = f % (~0 && a) && g, h = 0, i = 0;
if (c)
  h = f;
if (h > -2021603546)
  e = d / i;
f = h;
  }
  return 0;
}

[Bug tree-optimization/97888] [11 Regression] wrong code at -Os and above on x86_64-pc-linux-gnu

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|--- |11.0
Summary|wrong code at -Os and above |[11 Regression] wrong code
   |on x86_64-pc-linux-gnu  |at -Os and above on
   ||x86_64-pc-linux-gnu
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Priority|P3  |P1
 CC||aldyh at gcc dot gnu.org,
   ||amacleod at redhat dot com,
   ||jakub at gcc dot gnu.org
   Last reconfirmed||2020-11-18

--- Comment #1 from Jakub Jelinek  ---
Started with r11-5111-g1e27e7a582a9b86bcf86f5c103cd947672746e97

[Bug tree-optimization/97888] [11 Regression] wrong code at -Os and above on x86_64-pc-linux-gnu

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

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

--- Comment #2 from Jakub Jelinek  ---
The comments in that commit look incorrect btw,
// if a & b >=0 , then a >= 0.
should have been
// if a % b >=0 , then a >= 0.
(ditto the other one).

[Bug target/97866] [11 Regression] bootstrap error in libasan building a s390x-linux-gnu cross compiler

[doko at debian dot org via Gcc-bugs]

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

Matthias Klose  changed:

   What|Removed |Added

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

--- Comment #4 from Matthias Klose  ---
yes, that's fixed on the trunk

[Bug d/97889] New: d: OutOfMemoryError thrown when appending to an array with a side effect

[ibuclaw at gdcproject dot org via Gcc-bugs]

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

Bug ID: 97889
   Summary: d: OutOfMemoryError thrown when appending to an array
with a side effect
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: ibuclaw at gdcproject dot org
  Target Milestone: ---

Similar to pr97843.

The following program results in OutOfMemoryError being raised.

auto mul11ret3(T)(ref T s)
{
s ~= 11;
return [3];
}

void main()
{
static auto test3(int[] val) { (val ~= 7) ~= mul11ret3(val); return val; }
assert(test3([2]) == [2,7,11,3]);
}

[Bug c++/97890] New: Abstract virtual classes suddenly allowed as parameter types ?

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 97890
   Summary: Abstract virtual classes suddenly allowed as parameter
types ?
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

For this wrong C++ code:

struct S// abstract
{
int b;

virtual void f() = 0;
};

extern void g( struct S);

Suddenly seems to have started working sometime between 20201114
and 20201116.

/home/dcb/gcc/results.20201114/bin/gcc
nov18b.cc:9:24: error: cannot declare parameter to be of abstract type ‘S’
9 | extern void g( struct S);
  |^
nov18b.cc:2:8: note:   because the following virtual functions are pure within
‘S’:
2 | struct S// abstract
  |^
nov18b.cc:6:22: note: ‘virtual void S::f()’
6 | virtual void f() = 0;
  |  ^
/home/dcb/gcc/results.20201116.valgrind/bin/gcc

Compiler dated 20201104 has git hash 8270a7238ba1b535
and compiler dated 20201116 has git hash 2f473f4b065d3cc0.

Accident or design ?

[Bug tree-optimization/97888] [11 Regression] wrong code at -Os and above on x86_64-pc-linux-gnu

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

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

--- Comment #3 from Jakub Jelinek  ---
And I think the commit doesn't implement what Bruno wrote.
In particular, it was
b >= 0 && a % b > 0 implies a >= 0
b >= 0 && a % b < 0 implies a <= 0
while the patch implemented
b >= 0 && a % b >= 0 implies a >= 0
b >= 0 && a % b < 0 implies a <= 0

Consider -4 % 4, b >= 0 and a % b == 0, which is >= 0, but a is < 0.

So, another miscompiled testcase is:
__attribute__((noipa)) void
foo (int i)
{
  if ((i % 7) >= 0)
{
  if (i >= 0)
__builtin_abort ();
}
}

int
main ()
{
  foo (-7);
  foo (-21);
  return 0;
}

[Bug tree-optimization/97886] [11 Regression] ICE in vect_slp_analyze_node_operations, at tree-vect-slp.c:3528 since r11-4428-g4a369d199bf2f34e037030b18d0da923e8a24997

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

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

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

https://gcc.gnu.org/g:30270bf042049bf6aee6184e0b7688d9ca7b479d

commit r11-5126-g30270bf042049bf6aee6184e0b7688d9ca7b479d
Author: Richard Biener 
Date:   Wed Nov 18 10:32:29 2020 +0100

tree-optimization/97886 - deal with strange LC PHI nodes

This makes vectorization properly assign vector types to PHI
nodes that copy from externals on loop exit edges.

2020-11-18  Richard Biener  

PR tree-optimization/97886
* tree-vect-loop.c (vectorizable_lc_phi): Properly assign
vector types to invariants for SLP.

[Bug tree-optimization/97886] [11 Regression] ICE in vect_slp_analyze_node_operations, at tree-vect-slp.c:3528 since r11-4428-g4a369d199bf2f34e037030b18d0da923e8a24997

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug d/97842] ice compiling dxml

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

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Iain Buclaw
:

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

commit r10-9042-g7e6dbe4e571a375330beb4266813006dc474b716
Author: Iain Buclaw 
Date:   Tue Nov 17 10:48:41 2020 +0100

d: Fix a couple of ICEs found in the dmd front-end (PR97842)

- Segmentation fault on incomplete static if.
- Segmentation fault resolving typeof() expression when gagging is on.

gcc/d/ChangeLog:

PR d/97842
* dmd/cond.c (StaticIfCondition::include): Return error if
condition
expression is unset.
* dmd/mtype.c (TypeTypeof::resolve): Return error if scope is
unset.

gcc/testsuite/ChangeLog:

PR d/97842
* gdc.test/fail_compilation/fail18970.d: New test.
* gdc.test/fail_compilation/imports/test21164a.d: New test.
* gdc.test/fail_compilation/imports/test21164b.d: New test.
* gdc.test/fail_compilation/imports/test21164c.d: New test.
* gdc.test/fail_compilation/imports/test21164d.d: New test.
* gdc.test/fail_compilation/test21164.d: New test.

(cherry picked from commit 27d8c3516b67c0f5a8fe8970d0558ee3b97e8281)

[Bug d/97843] Bad code gen when concatenating to array

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

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

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

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

commit r10-9043-gbbb887834d78cf6a444bf9cecc29d14b4dfb9cf8
Author: Iain Buclaw 
Date:   Tue Nov 17 13:11:33 2020 +0100

d: Fix LHS of array concatentation evaluated before the RHS.

In an array append expression:

array ~= fun(array);

The array in the left hand side of the expression was extended before
evaluating the result of the right hand side, which resulted in the
newly uninitialized array index being used before set.

This fixes that so that the result of the right hand side is always
saved in a reusable temporary before assigning to the destination.

gcc/d/ChangeLog:

PR d/97843
* d-codegen.cc (build_assign): Evaluate TARGET_EXPR before use in
the right hand side of an assignment.
* expr.cc (ExprVisitor::visit (CatAssignExp *)): Force a
TARGET_EXPR
on the element to append if it is a CALL_EXPR.

gcc/testsuite/ChangeLog:

PR d/97843
* gdc.dg/pr97843.d: New test.

(cherry picked from commit 798bdfa0ebcf2bd012ffce75a594f783a8cb2dd0)

[Bug target/97887] [10/11 Regression] Failure to optimize neg plus div to avoid using x87 floating point stack

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||vmakarov at gcc dot gnu.org
 Target|x86_64 i?86 |x86_64-*-* i?86-*-*
   Keywords||needs-bisection, ra
   Target Milestone|--- |10.3
   Priority|P3  |P2
Summary|Failure to optimize neg |[10/11 Regression] Failure
   |plus div to avoid using x87 |to optimize neg plus div to
   |floating point stack|avoid using x87 floating
   ||point stack
  Known to fail||10.2.0, 11.0
  Known to work||7.5.0, 9.3.1

--- Comment #1 from Richard Biener  ---
Whoo:

** Local #1: **

   Spilling non-eliminable hard regs: 7
New elimination table:
Can eliminate 16 to 7 (offset=8, prev_offset=0)
Can eliminate 16 to 6 (offset=8, prev_offset=0)
Can eliminate 19 to 7 (offset=0, prev_offset=0)
Can eliminate 19 to 6 (offset=0, prev_offset=0)
0 Non-prefered reload: reject+=600
0 Non input pseudo reload: reject++
1 Matching alt: reject+=2
1 Non-prefered reload: reject+=600
  alt=0,overall=1227,losers=4,rld_nregs=2
Staticly defined alt reject+=600
0 Non-prefered reload: reject+=600
0 Non input pseudo reload: reject++
1 Matching alt: reject+=2
1 Non-prefered reload: reject+=600
alt=1,overall=1815,losers=2 -- refuse
 Choosing alt 0 in insn 7:  (0) =f  (1) 0 {*negsf2_i387_1}
  Creating newreg=89 from oldreg=86, assigning class FLOAT_REGS to r89
7: {r89:SF=-r89:SF;clobber flags:CC;}
  REG_UNUSED flags:CC
Inserting insn reload before:
   18: r89:SF=r88:SF
Inserting insn reload after:
   19: r86:SF=r89:SF

WTF.

[Bug target/97887] [10/11 Regression] Failure to optimize neg plus div to avoid using x87 floating point stack

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-11-18
 Ever confirmed|0   |1

[Bug tree-optimization/97888] [11 Regression] wrong code at -Os and above on x86_64-pc-linux-gnu

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
Created attachment 49585
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49585&action=edit
gcc11-pr97888.patch

Untested fix.

[Bug d/97843] Bad code gen when concatenating to array

[ibuclaw at gdcproject dot org via Gcc-bugs]

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

Iain Buclaw  changed:

   What|Removed |Added

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

--- Comment #8 from Iain Buclaw  ---
Fix committed to mainline and backported to gcc-10.

[Bug ada/97859] [11 Regression] bootstrap error building a gnat cross compiler targeting ppc64le on x86_64-linux-gnu

[doko at debian dot org via Gcc-bugs]

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

--- Comment #4 from Matthias Klose  ---
hmm, that file doesn't exist for the cross build.

$ find -name 's-val*.o'
./build/gcc/ada/libgnat/s-valint.o
./build/gcc/ada/libgnat/s-valuti.o
./build/gcc/ada/libgnat/s-valuns.o
./build/gcc/ada/rts/s-valdec.o
./build/gcc/ada/rts/s-valueu.o
./build/gcc/ada/rts/s-valboo.o
./build/gcc/ada/rts/s-valuei.o
./build/gcc/ada/rts/s-vallli.o
./build/gcc/ada/rts/s-valint.o
./build/gcc/ada/rts/s-valuti.o
./build/gcc/ada/rts/s-valwch.o
./build/gcc/ada/rts/s-valuns.o
./build/gcc/ada/rts/s-valrea.o
./build/gcc/ada/rts/s-valcha.o
./build/gcc/ada/rts/s-valllu.o
./build/gcc/ada/rts/s-valenu.o
./build/gcc/ada/rts/s-vallld.o

but it's build in a native build.

$ build/gcc/xgcc -v
Using built-in specs.
COLLECT_GCC=build/gcc/xgcc
OFFLOAD_TARGET_NAMES=nvptx-none
Target: powerpc64le-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 11-20201117-1'
--with-bugurl=file:///usr/share/doc/gcc-11/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-11 --enable-shared
--enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/
--enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object --enable-plugin
--enable-default-pie --with-system-zlib --enable-libphobos-checking=release
--without-target-system-zlib --enable-secureplt --with-cpu=power8
--enable-targets=powerpcle-linux --disable-multilib --enable-multiarch
--disable-werror --with-long-double-128
--enable-offload-targets=nvptx-none=/packages/cross/11/gcc-cross/gcc/debian/tmp-nvptx/usr
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=powerpc64le-linux-gnu --program-prefix=powerpc64le-linux-gnu-
--includedir=/usr/powerpc64le-linux-gnu/include
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.0.0 20201117 (experimental) [master revision
c2cf58f0e3a:4924d184b2a:a5f9c27bfc4417224e332392bb81a2d733b2b5bf] (Debian
11-20201117-1)

[Bug d/97842] ice compiling dxml

[ibuclaw at gdcproject dot org via Gcc-bugs]

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

Iain Buclaw  changed:

   What|Removed |Added

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

--- Comment #7 from Iain Buclaw  ---
Fix for both segfaults committed to mainline and backported to gcc-10.

[Bug d/97843] Bad code gen when concatenating to array

[ibuclaw at gdcproject dot org via Gcc-bugs]

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

--- Comment #9 from Iain Buclaw  ---
Another related issue has been created in pr97889.

[Bug c++/97890] Abstract virtual classes suddenly allowed as parameter types ?

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #1 from David Binderman  ---
For C++ testsuite file g++.dg/other/abstract8.C, the number
of errors seems to have gone down from 21 to 16.

Here is a diff of the errors:

$ diff /tmp/00 /tmp/11
1d0
< ./g++.dg/other/abstract8.C:13:9: error: invalid abstract type ‘A’ for ‘ar’
4,7d2
< ./g++.dg/other/abstract8.C:16:15: error: cannot allocate an object of
abstract type ‘A’
< ./g++.dg/other/abstract8.C:19:10: error: cannot declare variable ‘a’ to be of
abstract type ‘A’
< ./g++.dg/other/abstract8.C:21:1: error: invalid abstract return type ‘A’
< ./g++.dg/other/abstract8.C:22:9: error: cannot declare parameter to be of
abstract type ‘A’
9c4
< ./g++.dg/other/abstract8.C:26:1: error: invalid abstract return type ‘A’
---
> ./g++.dg/other/abstract8.C:25:4: error: creating array of ‘A’, which is an 
> abstract class type
$

[Bug target/97887] [10/11 Regression] Failure to optimize neg plus div to avoid using x87 floating point stack

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||uros at gcc dot gnu.org

--- Comment #2 from Richard Biener  ---
combine first makes recog pick negsf2_i387_1:

Trying 6 -> 7:
6: r87:V4SF=[`*.LC0']
  REG_EQUAL const_vector
7: {r86:SF=-r84:SF;use r87:V4SF;clobber flags:CC;}
  REG_DEAD r87:V4SF
  REG_UNUSED flags:CC
Successfully matched this instruction:
(parallel [
(set (reg:SF 86) 
(neg:SF (reg/v:SF 84 [ a ])))
(use (mem/u/c:V4SF (symbol_ref/u:DI ("*.LC0") [flags 0x2]) [0  S16
A128]))
(clobber (reg:CC 17 flags))
])
allowing combination of insns 6 and 7
original costs 8 + 4 = 12
replacement cost 4

...

(insn 7 6 8 2 (parallel [
(set (reg:SF 86)
(neg:SF (reg:SF 88))) 
(clobber (reg:CC 17 flags))
]) "t.i":3:12 595 {*negsf2_i387_1}
 (expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))
(insn 8 7 13 2 (set (reg:SF 85)
(div:SF (reg:SF 86)
(reg:SF 88))) "t.i":3:15 965 {*fop_sf_1}
 (expr_list:REG_DEAD (reg:SF 88)
(expr_list:REG_DEAD (reg:SF 86)
(nil

of course we have fop_sf_1 for the division already before but that's
probably just a misnamed pattern.

[Bug ada/97859] [11 Regression] bootstrap error building a gnat cross compiler targeting ppc64le on x86_64-linux-gnu

[doko at debian dot org via Gcc-bugs]

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

--- Comment #5 from Matthias Klose  ---
target_cpu is powerpc64le

Makefile.rtl:

ifeq ($(strip $(filter-out powerpc64,$(target_cpu))),)
  ifneq ($(strip $(MULTISUBDIR)),/ppc)
LIBGNAT_TARGET_PAIRS += $(GNATRTL_128BIT_PAIRS)
EXTRA_GNATRTL_NONTASKING_OBJS += $(GNATRTL_128BIT_OBJS)
  else
SO_OPTS += -m32
  endif
else
  ifeq ($(strip $(MULTISUBDIR)),/ppc64)
SO_OPTS += -m64
LIBGNAT_TARGET_PAIRS += $(GNATRTL_128BIT_PAIRS)
EXTRA_GNATRTL_NONTASKING_OBJS += $(GNATRTL_128BIT_OBJS)
  endif
endif
  endif

looks like this logic makes the assumption that any power architecture is
always mutilib'd, which is only true for powerpc-linux-gnu and
powerpc64-linux-gnu, but not powerpc64le-linux-gnu.

I didn't check where else this assumption is made.

[Bug ada/97859] [11 Regression] bootstrap error building a gnat cross compiler targeting ppc64le on x86_64-linux-gnu

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

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

--- Comment #6 from Eric Botcazou  ---
> target_cpu is powerpc64le
> 
> Makefile.rtl:
> 
> ifeq ($(strip $(filter-out powerpc64,$(target_cpu))),)
>   ifneq ($(strip $(MULTISUBDIR)),/ppc)
> LIBGNAT_TARGET_PAIRS += $(GNATRTL_128BIT_PAIRS)
> EXTRA_GNATRTL_NONTASKING_OBJS += $(GNATRTL_128BIT_OBJS)
>   else
> SO_OPTS += -m32
>   endif
> else
>   ifeq ($(strip $(MULTISUBDIR)),/ppc64)
> SO_OPTS += -m64
> LIBGNAT_TARGET_PAIRS += $(GNATRTL_128BIT_PAIRS)
> EXTRA_GNATRTL_NONTASKING_OBJS += $(GNATRTL_128BIT_OBJS)
>   endif
> endif
>   endif

It's the MacOS section though.

Can you replace "powerpc64" with "powerpc64%" in the Linux section?

  ifeq ($(strip $(filter-out powerpc64,$(target_cpu))),)
ifneq ($(strip $(MULTISUBDIR)),/32)
  LIBGNAT_TARGET_PAIRS += $(GNATRTL_128BIT_PAIRS)
  EXTRA_GNATRTL_NONTASKING_OBJS += $(GNATRTL_128BIT_OBJS)
endif
  else
ifeq ($(strip $(MULTISUBDIR)),/64)
  LIBGNAT_TARGET_PAIRS += $(GNATRTL_128BIT_PAIRS)
  EXTRA_GNATRTL_NONTASKING_OBJS += $(GNATRTL_128BIT_OBJS)
endif
  endif

[Bug c++/97890] Abstract virtual classes suddenly allowed as parameter types ?

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #2 from David Binderman  ---
I am having my first go at a git bisect. I am trying git hash 9243f0fba68339fa.

[Bug d/97889] d: OutOfMemoryError thrown when appending to an array with a side effect

[ibuclaw at gdcproject dot org via Gcc-bugs]

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

--- Comment #1 from Iain Buclaw  ---
Things go wrong because there is a SAVE_EXPR on the result of the library
function call of (val ~= 7).

It ends up being compiled down to:

  save = _d_arrayappendcTX (typeid(val), &val, 1),
*(save.ptr + save.length - 1) = 7;

Then an address of this taken for the outer array append operation, so you end
up with:

  &(*(save = _d_arrayappendcTX (typeid(val), &val, 1),
  save.ptr + save.length - 1) = 7);

As _d_arrayappendcTX is known to return the new value of `val`, which is also
passed by reference, this can be instead lowered to ignore the return value,
and create a SAVE_EXPR on `&val' instead.

  save = &val,
_d_arrayappendcTX (typeid(val), save, 1),
(*save).ptr + (*save).length - 1 = 7,
*save;

[Bug ada/97859] [11 Regression] bootstrap error building a gnat cross compiler targeting ppc64le on x86_64-linux-gnu

[doko at debian dot org via Gcc-bugs]

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

--- Comment #7 from Matthias Klose  ---
patch posted at
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559485.html

the build succeeds

[Bug c++/97890] Abstract virtual classes suddenly allowed as parameter types ?

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #3 from David Binderman  ---

Git hash 9243f0fba68339fa is silent on the code. Trying git hash
253c415a1acba507

[Bug target/97891] New: [x86] Consider using registers on large initializations

[andysem at mail dot ru via Gcc-bugs]

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

Bug ID: 97891
   Summary: [x86] Consider using registers on large
initializations
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andysem at mail dot ru
  Target Milestone: ---

Consider the following example code:

struct A
{
long a;
short b;
int c;
char d;
long x;
bool y;
int z;
char* p;

A() :
a(0), b(0), c(0), d(0), x(0), y(false), z(0), p(0)
{}
};

void test(A* p, unsigned int count)
{
for (unsigned int i = 0; i < count; ++i)
{
p[i] = A();
}
}

When compiled with "-O3 -march=nehalem" the generated code is:

test(A*, unsigned int):
testl   %esi, %esi
je  .L1
leal-1(%rsi), %eax
leaq(%rax,%rax,2), %rax
salq$4, %rax
leaq48(%rdi,%rax), %rax
.L3:
xorl%edx, %edx
movq$0, (%rdi)
addq$48, %rdi
movw%dx, -40(%rdi)
movl$0, -36(%rdi)
movb$0, -32(%rdi)
movq$0, -24(%rdi)
movb$0, -16(%rdi)
movl$0, -12(%rdi)
movq$0, -8(%rdi)
cmpq%rax, %rdi
jne .L3
.L1:
ret

https://gcc.godbolt.org/z/TrfWYr

Here, the main loop body between .L3 and .L1 is 60 bytes large, with a
significant amount of space wasted on the $0 constants encoded in mov
instructions. It would be more efficient to use a single zero register in all
member initializations, especially given that %edx is already used like that.

A loop rewritten like this:

for (unsigned int i = 0; i < count; ++i)
{
__asm__
(
"movq%q1, (%0)\n\t"
"movw%w1, 8(%0)\n\t"
"movl%1, 12(%0)\n\t"
"movb%b1, 16(%0)\n\t"
"movq%q1, 24(%0)\n\t"
"movb%b1, 32(%0)\n\t"
"movl%1, 36(%0)\n\t"
"movq%q1, 40(%0)\n\t"
: : "r" (p + i), "q" (0)
);
}

compiles to:

test(A*, unsigned int):
testl   %esi, %esi
je  .L1
leal-1(%rsi), %eax
leaq(%rax,%rax,2), %rax
salq$4, %rax
leaq48(%rdi,%rax), %rdx
xorl%eax, %eax
.L3:
movq%rax, (%rdi)
movw%ax, 8(%rdi)
movl%eax, 12(%rdi)
movb%al, 16(%rdi)
movq%rax, 24(%rdi)
movb%al, 32(%rdi)
movl%eax, 36(%rdi)
movq%rax, 40(%rdi)

addq$48, %rdi
cmpq%rdx, %rdi
jne .L3
.L1:
ret

Here, the loop between .L3 and .L1 only takes 34 bytes, which is nearly half
the original size.

Constant (for example, zero) initialization is a frequently used pattern to
initialize structures, so the sequences like the above are quite wide spread.
Converting cases like this to the use of registers could save some code size
and reduce cache pressure.

[Bug target/97891] [x86] Consider using registers on large initializations

[andysem at mail dot ru via Gcc-bugs]

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

--- Comment #1 from andysem at mail dot ru ---
As a side note, the "xorl %edx, %edx" in the original code should have been
moved outside the loop, as it was in the code with __asm__ block.

[Bug target/97887] [10/11 Regression] Failure to optimize neg plus div to avoid using x87 floating point stack

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Uroš Bizjak  ---
(In reply to Richard Biener from comment #2)
> combine first makes recog pick negsf2_i387_1:

This should have the following insn constraint:

  "TARGET_80387 && !(SSE_FLOAT_MODE_P (mode) && TARGET_SSE_MATH)"

to hide it from combine in cases where relevant SSE mode is available.

[Bug c++/97890] Abstract virtual classes suddenly allowed as parameter types ?

[dcb314 at hotmail dot com via Gcc-bugs]

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

David Binderman  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #4 from David Binderman  ---
A quick review of the git log suggests Jason Merrill 's commit hashed as
baf38d2e363971ed8baa5f82b2eaf21cd8e74aae is a hot candidate.

Given that clang-11 won't compile the code (even with -std=c++20) 
and gcc didn't used to, is it perhaps a good idea to 

a) go back to old behaviour by default for gcc.
b) put gcc's new behaviour into -std=c++20 only.

Perhaps Jason is well placed to advise further.

[Bug ada/97859] [11 Regression] bootstrap error building a gnat cross compiler targeting ppc64le on x86_64-linux-gnu

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

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

--- Comment #8 from CVS Commits  ---
The master branch has been updated by Matthias Klose :

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

commit r11-5129-gba97b532604815333848ee30e069dde6e36ce4c9
Author: Matthias Klose 
Date:   Wed Nov 18 13:24:33 2020 +0100

Fix PR ada/97859, building ada cross compiler targeting
powerpc64le-linux-gnu

2020-11-18  Matthias Klose  

PR ada/97859
* Makefile.rtl (powerpc% linux%): Also match powerpc64le cpu.

[Bug target/97827] bootstrap error building the amdgcn-amdhsa offload compiler with LLVM 11

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

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

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

First review regards this as LLVM bug.

[Bug ada/97859] [11 Regression] bootstrap error building a gnat cross compiler targeting ppc64le on x86_64-linux-gnu

[doko at debian dot org via Gcc-bugs]

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

Matthias Klose  changed:

   What|Removed |Added

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

[Bug c++/97890] Abstract virtual classes suddenly allowed as parameter types ?

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

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

--- Comment #5 from Jonathan Wakely  ---
The commit log refers to
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0929r2.html which was
accepted as a defect report (i.e. a fix for previous standards) in Rapperswil
2018.

[Bug target/97827] bootstrap error building the amdgcn-amdhsa offload compiler with LLVM 11

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek  ---
Might not be a LLVM bug if llvm-as doesn't pretend to be assembler compatible
with other assemblers.  But in that case we should treat it as a target with
specific assembler requirements (e.g. like Darwin).

[Bug libstdc++/97869] defines __cpp_lib_span even when doesn't provide an implementation

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

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

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

https://gcc.gnu.org/g:992643655c872f8332f9e8e453631a8fad52943a

commit r10-9044-g992643655c872f8332f9e8e453631a8fad52943a
Author: Jonathan Wakely 
Date:   Tue Nov 17 15:26:29 2020 +

libstdc++: Fix unconditional definition of __cpp_lib_span in  [PR
97869}

The  header is empty unless Concepts are supported, but 
defines the __cpp_lib_span feature test macro unconditionally. It should
be guarded by the same conditions as in .

libstdc++-v3/ChangeLog:

PR libstdc++/97869
* include/precompiled/stdc++.h: Include .
* include/std/version (__cpp_lib_span): Check __cpp_lib_concepts
before defining.

(cherry picked from commit ecf65330c11544ebf35e198087b4a42be089c620)

[Bug libstdc++/97869] defines __cpp_lib_span even when doesn't provide an implementation

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #4 from Jonathan Wakely  ---
Fixed for 10.3

[Bug other/97892] New: ICE in tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in c_expr_sizeof_expr, at c/c-typeck.c:2946

[doko at debian dot org via Gcc-bugs]

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

Bug ID: 97892
   Summary: ICE in tree check: expected class ‘type’, have
‘exceptional’ (error_mark) in c_expr_sizeof_expr, at
c/c-typeck.c:2946
   Product: gcc
   Version: 10.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at debian dot org
  Target Milestone: ---

seen with the gcc-10 branch and the trunk, gcc configured with 
--enable-checking=yes,extra,rtl

gcc-9 configured here with --enable-checking=release, so I don't know if that's
a regression.

$ cat qq.i 
int m(int a) { return sizeof((char[a])); };

$ gcc-9 -c qq.i 
qq.i: In function ‘m’:
qq.i:1:39: error: expected expression before ‘)’ token
1 | int m(int a) { return sizeof((char[a])); };
  |   ^

$ gcc-10 -c qq.i 
qq.i: In function ‘m’:
qq.i:1:39: error: expected expression before ‘)’ token
1 | int m(int a) { return sizeof((char[a])); };
  |   ^
qq.i:1:39: internal compiler error: tree check: expected class ‘type’, have
‘exceptional’ (error_mark) in c_expr_sizeof_expr, at c/c-typeck.c:2946
0x7602ef tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
../../src/gcc/tree.c:9780
0x5c2697 tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
../../src/gcc/tree.h:3417
0x5c2697 c_expr_sizeof_expr(unsigned int, c_expr)
../../src/gcc/c/c-typeck.c:2946
0xa274b7 c_parser_sizeof_expression
../../src/gcc/c/c-parser.c:8348
0xa274b7 c_parser_unary_expression
../../src/gcc/c/c-parser.c:8245
0xa280fd c_parser_cast_expression
../../src/gcc/c/c-parser.c:8115
0xa28389 c_parser_binary_expression
../../src/gcc/c/c-parser.c:7918
0xa29365 c_parser_conditional_expression
../../src/gcc/c/c-parser.c:7652
0xa29980 c_parser_expr_no_commas
../../src/gcc/c/c-parser.c:7569
0xa29be1 c_parser_expression
../../src/gcc/c/c-parser.c:10644
0xa2a387 c_parser_expression_conv
../../src/gcc/c/c-parser.c:10677
0xa20861 c_parser_statement_after_labels
../../src/gcc/c/c-parser.c:6212
0xa21d11 c_parser_compound_statement_nostart
../../src/gcc/c/c-parser.c:5805
0xa407c4 c_parser_compound_statement
../../src/gcc/c/c-parser.c:5617
0xa42281 c_parser_declaration_or_fndef
../../src/gcc/c/c-parser.c:2505
0xa4a3f3 c_parser_external_declaration
../../src/gcc/c/c-parser.c:1745
0xa4aef1 c_parser_translation_unit
../../src/gcc/c/c-parser.c:1618
0xa4aef1 c_parse_file()
../../src/gcc/c/c-parser.c:21752
0xaa21fb c_common_parse_file()
../../src/gcc/c-family/c-opts.c:1190
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.

[Bug tree-optimization/97832] AoSoA complex caxpy-like loops: AVX2+FMA -Ofast 7 times slower than -O3

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

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

--- Comment #8 from Richard Biener  ---
Created attachment 49586
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49586&action=edit
prototype

This is a prototype patch which can serve as proof-of-concept.  It needs
cleanup plus better handling of hybrid SLP discovery.

It depends on
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559347.html to fix the
testcase in this PR (which is included in the patch).

[Bug other/97892] ICE in tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in c_expr_sizeof_expr, at c/c-typeck.c:2946

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-11-18
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
It's at least as old as GCC 4.8.0.

[Bug tree-optimization/97888] [11 Regression] wrong code at -Os and above on x86_64-pc-linux-gnu

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #5 from Andrew Macleod  ---
Doh, yeah. Patch looks good.

[Bug tree-optimization/97832] AoSoA complex caxpy-like loops: AVX2+FMA -Ofast 7 times slower than -O3

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

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

--- Comment #9 from Richard Biener  ---
There's then also a permute optimization left on the plate:

t.c:16:3: note:   node 0x3a19590 (max_nunits=4, refcnt=2)
t.c:16:3: note: stmt 0 _153 = f11_im_76 * x1_im_142;
t.c:16:3: note: stmt 1 _213 = f11_re_72 * x1_re_202;
t.c:16:3: note: stmt 2 _275 = f11_re_72 * x1_re_264;
t.c:16:3: note: stmt 3 _337 = f11_re_72 * x1_re_326;
t.c:16:3: note: stmt 4 _155 = f11_im_76 * x1_re_140;
t.c:16:3: note: stmt 5 _217 = f11_im_76 * x1_re_202;
t.c:16:3: note: stmt 6 _279 = f11_im_76 * x1_re_264;
t.c:16:3: note: stmt 7 _341 = f11_im_76 * x1_re_326;
t.c:16:3: note: children 0x3a19600 0x3a19670
t.c:16:3: note:   node (external) 0x3a19600 (max_nunits=1, refcnt=1)
t.c:16:3: note: { f11_im_76, f11_re_72, f11_re_72, f11_re_72,
f11_im_76, f11_im_76, f11_im_76, f11_im_76 }
t.c:16:3: note:   node 0x3a19670 (max_nunits=4, refcnt=1)
t.c:16:3: note: stmt 0 x1_im_142 = *_141;
t.c:16:3: note: stmt 1 x1_re_202 = *_201;
t.c:16:3: note: stmt 2 x1_re_264 = *_263;
t.c:16:3: note: stmt 3 x1_re_326 = *_325;
t.c:16:3: note: stmt 4 x1_re_140 = *_139;
t.c:16:3: note: stmt 5 x1_re_202 = *_201;
t.c:16:3: note: stmt 6 x1_re_264 = *_263;
t.c:16:3: note: stmt 7 x1_re_326 = *_325;
t.c:16:3: note: load permutation { 4 1 2 3 0 1 2 3 }

which we currently do not handle (there's a FIXME as to permute externals,
currently we only handle splats as transparent for permutes).

[Bug target/97873] Failure to optimize abs optimally (at least one completely useless instruction on x86)

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
So then either we should expand the SWI48x mode abs for !TARGET_EXPAND_ABS into
a pre-reload define_insn_and_split with abs that we'd split almost like smax,
except for using the result of neg for the condition codes (and we'd need to
see how it plays with STV), or add a define_insn_and_split that would match
what the combiner is trying:
(set (reg:SI 84)
(smax:SI (neg:SI (reg/v:SI 83 [ x ]))
(reg/v:SI 83 [ x ])))
(clobber (reg:CC 17 flags))
and again split that cmov consumer of neg as flag setter (and again see what
STV does with that).

[Bug middle-end/97862] [11 Regression] ICE in expand_omp_for_init_vars, at omp-expand.c:2524

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek  ---
Fixed.

[Bug target/97887] [10/11 Regression] Failure to optimize neg plus div to avoid using x87 floating point stack

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

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

--- Comment #4 from Richard Biener  ---
(In reply to Uroš Bizjak from comment #3)
> (In reply to Richard Biener from comment #2)
> > combine first makes recog pick negsf2_i387_1:
> 
> This should have the following insn constraint:
> 
>   "TARGET_80387 && !(SSE_FLOAT_MODE_P (mode) && TARGET_SSE_MATH)"
> 
> to hide it from combine in cases where relevant SSE mode is available.

Hmm, it is

;; Changing of sign for FP values is doable using integer unit too.
(define_insn "*2_i387_1"
  [(set (match_operand:X87MODEF 0 "register_operand" "=f,!r")
(absneg:X87MODEF
  (match_operand:X87MODEF 1 "register_operand" "0,0")))
   (clobber (reg:CC FLAGS_REG))]
  "TARGET_80387"
  "#")

that is not guarded in this way?

[Bug target/97887] [10/11 Regression] Failure to optimize neg plus div to avoid using x87 floating point stack

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Uroš Bizjak  ---
> > This should have the following insn constraint:
> > 
> >   "TARGET_80387 && !(SSE_FLOAT_MODE_P (mode) && TARGET_SSE_MATH)"
> > 
> > to hide it from combine in cases where relevant SSE mode is available.
> 
> Hmm, it is
> 
> ;; Changing of sign for FP values is doable using integer unit too.
> (define_insn "*2_i387_1"
>   [(set (match_operand:X87MODEF 0 "register_operand" "=f,!r")
> (absneg:X87MODEF
>   (match_operand:X87MODEF 1 "register_operand" "0,0")))
>(clobber (reg:CC FLAGS_REG))]
>   "TARGET_80387"
>   "#")
> 
> that is not guarded in this way?

Yes, this is the one.

[Bug target/97887] [10/11 Regression] Failure to optimize neg plus div to avoid using x87 floating point stack

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

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

--- Comment #6 from Richard Biener  ---
So likely caused by g:f359611b363490b48a7ce0fd021f7e47d8816eb0

[Bug c/97860] [11 Regression] ICE in handle_argspec_attribute, at c-family/c-attribs.c:3244 since r11-3303-g6450f07388f9fe57

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
The problem is that in the C FE TYPE_MAX_VALUE (TYPE_DOMAIN (type)) isn't set
for the [0] types (yet they are complete), while the middle-end expects for
them to have TYPE_MAX_VALUE of -1 or so, so array_type_nelts returns
error_mark_node.
We could do:
  /* array_type_nelts assumes the middle-end TYPE_DOMAINs, while
 GNU [0] array in the FE don't have TYPE_MAX_VALUE of the
 domain set, yet they are complete types with no elements.  */
  if (nelts == error_mark_node
  && TYPE_DOMAIN (type)
  && !TYPE_MAX_VALUE (TYPE_DOMAIN (type))
  && COMPLETE_P (type)
  && integer_zerop (TYPE_SIZE (type)))
continue;
but then it doesn't make sense to queue up error_mark_nodes in the attributes
when we ICE on them later, so perhaps better:
2020-11-18  Jakub Jelinek  

PR c/97860
* c-decl.c (get_parm_array_spec): Don't chain error_mark_node as
VLA bounds.

* gcc.dg/pr97860.c: New test.

--- gcc/c/c-decl.c.jj   2020-11-11 01:46:03.245697697 +0100
+++ gcc/c/c-decl.c  2020-11-18 15:11:14.613565216 +0100
@@ -5775,7 +5775,7 @@ get_parm_array_spec (const struct c_parm
   type = TREE_TYPE (type))
{
  tree nelts = array_type_nelts (type);
- if (TREE_CODE (nelts) != INTEGER_CST)
+ if (TREE_CODE (nelts) != INTEGER_CST && nelts != error_mark_node)
{
  /* Each variable VLA bound is represented by the dollar
 sign.  */
--- gcc/testsuite/gcc.dg/pr97860.c.jj   2020-11-18 15:15:08.858931877 +0100
+++ gcc/testsuite/gcc.dg/pr97860.c  2020-11-18 15:14:50.751135430 +0100
@@ -0,0 +1,11 @@
+/* PR c/97860 */
+/* { dg-do compile } */
+/* { dg-options "" } */
+
+void
+foo (int n)
+{
+  typedef int T[0];
+  typedef T V[n];
+  void bar (V);
+}

[Bug ipa/97673] [11 Regression] ICE in remap_gimple_stmt, at tree-inline.c:1922 since r11-4267-g0e590b68fa374365

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
It is not, it still ICEs with r11-5128 and
-O3 -fno-early-inlining --param large-stack-frame=4000 on x86_64-linux.

[Bug tree-optimization/97579] [11 Regression] ICE in gimple_expand_vec_cond_expr, at gimple-isel.cc:201 since r11-4123-g128f43cf679e5156

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek  ---
So fixed?  Any reason why the testcase hasn't been added to the testsuite?  I
can test it on skylake-avx512 and add it there.

[Bug tree-optimization/97579] [11 Regression] ICE in gimple_expand_vec_cond_expr, at gimple-isel.cc:201 since r11-4123-g128f43cf679e5156

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

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

--- Comment #7 from Jakub Jelinek  ---
Actually still ICEs.

[Bug target/96377] [10/11 Regression] GCC 10.2/11 doesn't build Linux kernel anymore

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #14 from Jakub Jelinek  ---
Fixed.

[Bug c/97892] [10/11 Regression] ICE in tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in c_expr_sizeof_expr, at c/c-typeck.c:2946

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

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

Richard Biener  changed:

   What|Removed |Added

Summary|ICE in tree check: expected |[10/11 Regression] ICE in
   |class ‘type’, have  |tree check: expected class
   |‘exceptional’ (error_mark)  |‘type’, have ‘exceptional’
   |in c_expr_sizeof_expr, at   |(error_mark) in
   |c/c-typeck.c:2946   |c_expr_sizeof_expr, at
   ||c/c-typeck.c:2946
   Priority|P3  |P4
  Component|other   |c
   Keywords||error-recovery
   Target Milestone|--- |10.3

[Bug target/97891] [x86] Consider using registers on large initializations

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

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2020-11-18
 Status|UNCONFIRMED |NEW
 Target|x86-64  |x86_64-*-* i?86-*-*
 Ever confirmed|0   |1
   Keywords||missed-optimization

--- Comment #2 from Richard Biener  ---
Confirmed.  I think we have (plenty?) duplicates.

[Bug tree-optimization/85315] missed range optimisation opportunity for derefences where index must be 0 or otherwise constrained

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #12 from Andrew Macleod  ---
Maybe I'm a little dense.

if we are presuming that  
  &x + (a + b) 
implies a + b == 0, then we also should assume that

  &x + a  implies a == 0

and if we can make those assumptions, then
&x + 1 is garbage because we can assume 1 == 0.

And if a and b are both unsigned, then I guess we can also assume a == b ==
MAX_UINT / 2 ?


Now, if we decided to actually do this...  I see IL:

 :
  x.0_1 = x;
  y = x.0_1;
  a.1_2 = a;
  b.2_3 = b;
  _4 = a.1_2 + b.2_3;
  _5 = (long unsigned int) _4;
  _6 = _5 * 4;
  _7 = &y + _6;

The clear implications is that _6 == 0 in this expression?

If we implemented that in the operator_pointer_plus::op1_range routine, and
then were to back substitute, we'd get
(_6)[0,0] = _5 * 4   -> _5 = [0,0]
(_5)[0,0] = (long unsigned int) _4;  -> _4 == [0,0]
(_4)[0,0] = a.1_2 + b.2_3   which gives us nothing additional...  Other than a
potential relationship to track I suppose  a.1_2 == -B.2_3 for signed, but it
would record that _4 is [0,0] when we calculate an outgoing range.

but regardless, its seems that another straightforward place to do this would
be in statement folding?  Isn't the basic assumption:

_7 = &y + _6;
implies _6 is always 0, which would enable us to fold this to
_7 = &y
then _6 is unused and the other statements would ultimately just go away.

So why not make folding simply throw away the "+ _6" part because it is now
being forced to be 0?  We can't really assume that it is [0,0], but then not
use that information to optimize?

[Bug c++/95192] [11 Regression] ICE: tree check: expected tree_list, have error_mark in handle_assume_aligned_attribute, at c-family/c-attribs.c:2996

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
In cp/parser.c, we have code that avoids building attributes with
error_mark_node values (instead just use error_mark_node as the attributes).

So, I wonder if we shouldn't do that in tsubst_attributes too, like:
--- gcc/cp/pt.c.jj  2020-11-18 09:40:09.618663053 +0100
+++ gcc/cp/pt.c 2020-11-18 15:47:26.584181671 +0100
@@ -11502,6 +11502,8 @@ tsubst_attribute (tree t, tree *decl_p,
   tree chain
= tsubst_expr (TREE_CHAIN (val), args, complain, in_decl,
   /*integral_constant_expression_p=*/false);
+  if (chain == error_mark_node)
+   return error_mark_node;
   if (chain != TREE_CHAIN (val))
val = tree_cons (NULL_TREE, TREE_VALUE (val), chain);
 }
@@ -11524,8 +11526,12 @@ tsubst_attribute (tree t, tree *decl_p,
   return list;
 }
   else
-val = tsubst_expr (val, args, complain, in_decl,
-  /*integral_constant_expression_p=*/false);
+{
+  val = tsubst_expr (val, args, complain, in_decl,
+/*integral_constant_expression_p=*/false);
+  if (val == error_mark_node)
+   return val;
+}

   if (val != TREE_VALUE (t))
 return build_tree_list (TREE_PURPOSE (t), val);

Except that we accept the testcase then rather than reject - the unification is
done with complain == 0...

[Bug target/97887] [10/11 Regression] Failure to optimize neg plus div to avoid using x87 floating point stack

[ubizjak at gmail dot com via Gcc-bugs]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |ubizjak at gmail dot com

--- Comment #7 from Uroš Bizjak  ---
I'll fix this.

[Bug tree-optimization/85315] missed range optimisation opportunity for derefences where index must be 0 or otherwise constrained

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #13 from Jakub Jelinek  ---
(In reply to Andrew Macleod from comment #12)
> Maybe I'm a little dense.
> 
> if we are presuming that  
>   &x + (a + b) 
> implies a + b == 0, then we also should assume that

&x + (a + b) for scalar x doesn't imply a + b == 0, it implies a + b <= 1.
Only when it is dereferenced, i.e. (&x)[a + b] is accessed a + b has to be 0.

[Bug target/97870] [11 Regression] ICE: verify_flow_info failed (error: too many outgoing branch edges from bb 2)

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Vladimir Makarov :

https://gcc.gnu.org/g:2f2709e691148160e4f88090eaf48d3e4915b0e4

commit r11-5131-g2f2709e691148160e4f88090eaf48d3e4915b0e4
Author: Vladimir N. Makarov 
Date:   Wed Nov 18 10:07:56 2020 -0500

[PR97870] LRA: don't remove asm goto, just nullify it.

gcc/

2020-11-18  Vladimir Makarov  

PR target/97870
* lra-constraints.c (curr_insn_transform): Do not delete asm goto
with wrong constraints.  Nullify it saving CFG.

[Bug tree-optimization/22326] promotions (from float to double) are not removed when they should be able to

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

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

Segher Boessenkool  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org

--- Comment #8 from Segher Boessenkool  ---
The fmadd;frsp sequence is correct for this source code.  It does double
rounding of the result (first to DP float, then to SP float), so using
just fmadds is only correct for -ffast-math or similar.

[Bug c/97882] [8/9/10/11 Regression] Segmentation Fault on improper redeclaration of function

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Started with r7-760-gaa4b467b680f230ab11922d1e29695e1eaba12af

[Bug c/97860] [11 Regression] ICE in handle_argspec_attribute, at c-family/c-attribs.c:3244 since r11-3303-g6450f07388f9fe57

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

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

--- Comment #3 from Martin Sebor  ---
I was going to commit the following but I'll leave it to you.

diff --git a/gcc/c/c-decl.c b/gcc/c/c-decl.c
index d348e39c27a..95cf9e4cb00 100644
--- a/gcc/c/c-decl.c
+++ b/gcc/c/c-decl.c
@@ -5775,6 +5775,10 @@ get_parm_array_spec (const struct c_parm *parm, tree
attrs)
   type = TREE_TYPE (type))
{
  tree nelts = array_type_nelts (type);
+ if (error_operand_p (nelts))
+   /* Avoid erroneous expressions.  */
+   return attrs;
+
  if (TREE_CODE (nelts) != INTEGER_CST)
{
  /* Each variable VLA bound is represented by the dollar

[Bug c/97860] [11 Regression] ICE in handle_argspec_attribute, at c-family/c-attribs.c:3244 since r11-3303-g6450f07388f9fe57

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

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

--- Comment #4 from Jakub Jelinek  ---
(In reply to Martin Sebor from comment #3)
> I was going to commit the following but I'll leave it to you.
> 
> diff --git a/gcc/c/c-decl.c b/gcc/c/c-decl.c
> index d348e39c27a..95cf9e4cb00 100644
> --- a/gcc/c/c-decl.c
> +++ b/gcc/c/c-decl.c
> @@ -5775,6 +5775,10 @@ get_parm_array_spec (const struct c_parm *parm, tree
> attrs)
>type = TREE_TYPE (type))
> {
>   tree nelts = array_type_nelts (type);
> + if (error_operand_p (nelts))
> +   /* Avoid erroneous expressions.  */
> +   return attrs;
> +
>   if (TREE_CODE (nelts) != INTEGER_CST)
> {
>   /* Each variable VLA bound is represented by the dollar

For errors why not, but typedef int T[0]; really is not an error actually.

[Bug target/97532] [11 Regression] Error: insn does not satisfy its constraints, internal compiler error: in extract_constrain_insn, at recog.c:2196

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #16 from Jakub Jelinek  ---
.

[Bug tree-optimization/85315] missed range optimisation opportunity for derefences where index must be 0 or otherwise constrained

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

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

--- Comment #14 from Martin Sebor  ---
Andrew, we discussed the same idea for built-in functions at Couldron.  For
instance, in:

  void f (const char *s, int n)
  {
char a[8];
memcpy (a, s, n); // n must be in [0, 8]
if (n < 0 || n > 8)   // fold to false
  abort ();
  }

[Bug c/97884] INT_MIN falsely expanded to 64 bit

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

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #3 from Martin Sebor  ---
Compiling with -Wall should issue a warning pointing out the problem:

$ cat pr97884.c && gcc -O2 -S -Wall pr97884.c
void f (void)
{
  __builtin_printf ("%i\n", -2147483648);
  __builtin_printf ("%i\n", (int)-2147483648);
}


pr97884.c: In function 'f':
pr97884.c:3:23: warning: format '%i' expects argument of type 'int', but
argument 2 has type 'long long int' [-Wformat=]
3 |   __builtin_printf ("%i\n", -2147483648);
  |  ~^ ~~~
  |   | |
  |   int   long long int
  |  %lli

[Bug target/97528] [9/10/11 Regression] ICE in decompose_automod_address, at rtlanal.c:6298 (arm-linux-gnueabihf)

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
We have:
(insn 7 6 9 2 (set (reg:SI 114 [ _3 ])
(ashift:SI (reg:SI 122 [ d ])
(const_int 1 [0x1]))) "pr97528-2.c":14:9 147 {*arm_shiftsi3}
 (expr_list:REG_DEAD (reg:SI 122 [ d ])
(nil)))
...
(insn 12 25 24 2 (set (mem/c:V4HI (post_modify:SI (reg/v/f:SI 118 [ dst ])
(plus:SI (reg/v/f:SI 118 [ dst ])
(reg:SI 114 [ _3 ]))) [0 MEM[(short int[4] *)&c]+0 S8 A16])
(unspec:V4HI [
(reg:V4HI 117 [ _14 ])
] UNSPEC_VST1)) "pr97528-2.c":13:5 2508 {neon_vst1v4hi}
 (expr_list:REG_INC (reg/v/f:SI 118 [ dst ])
(nil)))
and combine attempts to propagate the shift into the insn:
(insn 12 25 24 2 (set (mem/c:V4HI (post_modify:SI (reg/v/f:SI 118 [ dst ])
(plus:SI (mult:SI (reg:SI 122 [ d ])
(const_int 2 [0x2]))
(reg/v/f:SI 118 [ dst ]))) [0 MEM[(short int[4] *)&c]+0 S8
A16])
(unspec:V4HI [
(reg:V4HI 117 [ _14 ])
] UNSPEC_VST1)) "pr97528-2.c":13:5 2508 {neon_vst1v4hi}
 (expr_list:REG_INC (reg/v/f:SI 118 [ dst ])
(nil)))
That is not valid RTL, as documented:
   Currently, the compiler can only handle second operands of the
   form (plus (reg) (reg)) and (plus (reg) (const_int)), where
   the first operand of the PLUS has to be the same register as
   the first operand of the *_MODIFY.

[Bug target/97528] [9/10/11 Regression] ICE in decompose_automod_address, at rtlanal.c:6298 (arm-linux-gnueabihf)

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug analyzer/97893] New: Analyzer should only use CWE 690 when null ptr is from a function return

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

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

Bug ID: 97893
   Summary: Analyzer should only use CWE 690 when null ptr is from
a function return
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

>From an email from a user:

> -Wanalyzer-possible-null-dereference reports CWE-690. If we
> know that the NULL is the result of a function returning NULL, then 690 is
> correct.  Otherwise, 476 is the parent of 690 which means it's a more
> generalized classification for all NULL ptr dereferences. So, it's probably 
> what we want for less specific kinds of dereferences.

Internally, 690 is used unconditionally by possible_null_deref::emit,
possible_null_arg::emit, null_deref::emit, and null_arg::emit.

[Bug c/97884] INT_MIN falsely expanded to 64 bit

[s.bauroth--- via Gcc-bugs]

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

--- Comment #4 from s.baur...@tu-berlin.de ---
I am aware of the warning, I disagree with it's content. INT_MIN is an int, not
a long long int. I understand why it is processed as a long long int
internally, but that should not be visible from the outside world, at least
imho.

[Bug c/97884] INT_MIN falsely expanded to 64 bit

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
But INT_MIN in C is (-2147483647 - 1) for 32-bit ints, not -2147483648, as has
been explained, there is a significant difference for those two, because
2147483648 constant is not representable in int and therefore the constant gets
a different type and the negation preserves that type.
If something defines INT_MIN to -2147483648, the bug is in whatever defines it
that way.

[Bug c/97894] New: gcc/attr-fnspec.h: 8 * function could be const ?

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 97894
   Summary: gcc/attr-fnspec.h: 8 * function could be const ?
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

It would be a minor tidyup to mark some member functions in file 
gcc/attr-fnspec.h as const.

Here is some output from from a recent run of the static analyser cppcheck:

trunk.git/gcc/attr-fnspec.h:109:3: style:inconclusive: Technically the member
function 'attr_fnspec::known_p' can be const. [functionConst]
trunk.git/gcc/attr-fnspec.h:227:3: style:inconclusive: Technically the member
function 'attr_fnspec::returns_arg' can be const. [functionConst]
trunk.git/gcc/attr-fnspec.h:241:3: style:inconclusive: Technically the member
function 'attr_fnspec::returns_noalias_p' can be const. [functionConst]
trunk.git/gcc/attr-fnspec.h:248:3: style:inconclusive: Technically the member
function 'attr_fnspec::global_memory_read_p' can be const. [functionConst]
trunk.git/gcc/attr-fnspec.h:256:3: style:inconclusive: Technically the member
function 'attr_fnspec::global_memory_written_p' can be const. [functionConst]
trunk.git/gcc/attr-fnspec.h:262:3: style:inconclusive: Technically the member
function 'attr_fnspec::errno_maybe_written_p' can be const. [functionConst]
trunk.git/gcc/attr-fnspec.h:272:3: style:inconclusive: Technically the member
function 'attr_fnspec::get_str' can be const. [functionConst]
trunk.git/gcc/attr-fnspec.h:77:16: style:inconclusive: Technically the member
function 'attr_fnspec::arg_idx' can be const. [functionConst]

[Bug c++/97895] New: [11 Regression] ICE in do_auto_deduction, at cp/pt.c:29255

[gscfq--- via Gcc-bugs]

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

Bug ID: 97895
   Summary: [11 Regression] ICE in do_auto_deduction, at
cp/pt.c:29255
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Changed recently between 20201018 and 20201108 :


$ cat z1.cc
namespace std {
  template struct initializer_list {
const T *ptr;
decltype(sizeof 0) n;
  };
  auto a = {};
}


$ g++-11-20201115 -c z1.cc
z1.cc:6:13: internal compiler error: Segmentation fault
6 |   auto a = {};
  | ^
0xc727ef crash_signal
../../gcc/toplev.c:330
0x7642c1 vec::end()
../../gcc/vec.h:585
0x7642c1 do_auto_deduction(tree_node*, tree_node*, tree_node*, int,
auto_deduction_context, tree_node*, int)
../../gcc/cp/pt.c:29255
0x6c4cf2 cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
../../gcc/cp/decl.c:7570
0x74d7f7 cp_parser_init_declarator
../../gcc/cp/parser.c:21362
0x72f42a cp_parser_simple_declaration
../../gcc/cp/parser.c:13943
0x75307a cp_parser_declaration
../../gcc/cp/parser.c:13640
0x753d34 cp_parser_declaration_seq_opt
../../gcc/cp/parser.c:13485
0x753d34 cp_parser_namespace_body
../../gcc/cp/parser.c:19955
0x753d34 cp_parser_namespace_definition
../../gcc/cp/parser.c:19933
0x752eaf cp_parser_declaration
../../gcc/cp/parser.c:13620
0x75390a cp_parser_translation_unit
../../gcc/cp/parser.c:4806
0x75390a c_parse_file()
../../gcc/cp/parser.c:44595
0x81d252 c_common_parse_file()
../../gcc/c-family/c-opts.c:1196

[Bug c/97860] [11 Regression] ICE in handle_argspec_attribute, at c-family/c-attribs.c:3244 since r11-3303-g6450f07388f9fe57

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

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

--- Comment #5 from Martin Sebor  ---
Actually, I missed that your patch just skips over the error node.  That will
leave the attribute spec out of sync with the argument (it contains a '$' for
each VLA bound).  Rather than continuing to the next bound I think we should
bail.  The alternative is to change the rest of the code (the attribute handler
and the whole attribute access machinery) to skip these erroneous bounds.

[Bug fortran/97896] New: [11 Regression] ICE in gfc_trans_assignment_1, at fortran/trans-expr.c:11156

[gscfq--- via Gcc-bugs]

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

Bug ID: 97896
   Summary: [11 Regression] ICE in gfc_trans_assignment_1, at
fortran/trans-expr.c:11156
   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: ---

Follow-up of pr91651, changed between 20201004 and 20201018 :


$ cat z1.f90
program p
   logical :: a(2)
   integer :: b(2)
   b = index('xyxy', 'yx', a, 4)
   print *, b
end


$ gfortran-11-20201004 -c z1.f90
$
$ gfortran-11-20201115 -c z1.f90
z1.f90:4:32:

4 |b = index('xyxy', 'yx', a, 4)
  |1
internal compiler error: in gfc_trans_assignment_1, at
fortran/trans-expr.c:11156
0x764094 gfc_trans_assignment_1
../../gcc/fortran/trans-expr.c:11155
0x725aa7 trans_code
../../gcc/fortran/trans.c:1888
0x74bbe4 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6878
0x6d2e86 translate_all_program_units
../../gcc/fortran/parse.c:6347
0x6d2e86 gfc_parse_file()
../../gcc/fortran/parse.c:6616
0x71ee2f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:212

[Bug c/97897] New: ICE tree check: expected ssa_name, have integer_cst in compute_optimized_partition_bases, at tree-ssa-coalesce.c:1638

[gscfq--- via Gcc-bugs]

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

Bug ID: 97897
   Summary: ICE tree check: expected ssa_name, have integer_cst in
compute_optimized_partition_bases, at
tree-ssa-coalesce.c:1638
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Affects versions down to at least r5 :
(compiles with "(_Complex a)" instead)


$ cat z1.c
void h ();
void f () __attribute__ ((returns_twice));
void g (_Complex int a)
{
  f ();
  if (a != 0)
  {
a = 0;
h ();
  }
}


$ gcc-11-20201115 -c z1.c
during RTL pass: expand
z1.c: In function 'g':
z1.c:3:6: internal compiler error: tree check: expected ssa_name, have
integer_cst in compute_optimized_partition_bases, at tree-ssa-coalesce.c:1638
3 | void g (_Complex int a)
  |  ^
0x626df8 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/tree.c:9779
0xe4bb1f tree_check(tree_node*, char const*, int, char const*, tree_code)
../../gcc/tree.h:3314
0xe4bb1f compute_optimized_partition_bases
../../gcc/tree-ssa-coalesce.c:1638
0xe4bb1f coalesce_ssa_name(_var_map*)
../../gcc/tree-ssa-coalesce.c:1718
0xdde89b remove_ssa_form
../../gcc/tree-outof-ssa.c:1065
0xdde89b rewrite_out_of_ssa(ssaexpand*)
../../gcc/tree-outof-ssa.c:1323
0x80fa70 execute
../../gcc/cfgexpand.c:6407