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

[crazylht at gmail dot com via Gcc-bugs]

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

Hongtao.liu  changed:

   What|Removed |Added

 CC||crazylht at gmail dot com

--- Comment #6 from Hongtao.liu  ---


(In reply to Vladimir Makarov from comment #4)
> (In reply to Jakub Jelinek from comment #3)
> > The IRA dump says:
> >   a2(r189,l0) costs: AREG:2000,2000 DREG:2000,2000 CREG:26000,-1000
> > BREG:2000,2000 SIREG:2000,2000 DIREG:2000,2000 AD_REGS:2000,2000
> > CLOBBERED_REGS
> > :2000,2000 Q_REGS:2000,2000 TLS_GOTBASE_REGS:2000,2000
> > GENERAL_REGS:2000,2000 SSE_FIRST_REG:12000,12000 NO_REX_SSE_REGS:12000,12000
> > SSE_REGS:12000,
> > 12000 ALL_SSE_REGS:12000,12000 MMX_REGS:26000,26000 INT_SSE_REGS:26000,26000
> > ALL_REGS:424000,424000 MEM:12000,12000
> > so the INT_SSE_REGS cost of 26000 seems might higher than GENERAL_REGS cost.
> 
> It does not matter what class IRA gives the address reg. LRA should fix this
> anyway.  For usual memory the correct address reg class is checked by
> legitimate_address_p hook.
> 
> I guess in this case it is a special memory and its constraint does not
> check address reg class at all.  I believe the bug should be fixed on
> machine-dependent side of GCC (in constraints and predicates).

In 
(define_predicate "bcst_mem_operand"
  (and (match_code "vec_duplicate")
   (and (match_test "TARGET_AVX512F")
(ior (match_test "TARGET_AVX512VL")
 (match_test "GET_MODE_SIZE (GET_MODE (op)) == 64")))
   (match_test "VALID_BCST_MODE_P (GET_MODE_INNER (GET_MODE (op)))")
   (match_test "memory_operand (XEXP (op, 0), GET_MODE (XEXP (op, 0)))")))

Shouldn't memory_operand (XEXP (op, 0), GET_MODE (XEXP (op, 0))) imply
legitimate_address_p?

[Bug c++/97537] New: gcc -H Option Issue, incomplete dependency tree listing

[adrien.guichard at citel dot fr via Gcc-bugs]

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

Bug ID: 97537
   Summary: gcc -H Option Issue, incomplete dependency tree
listing
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: adrien.guichard at citel dot fr
  Target Milestone: ---

Created attachment 49426
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49426=edit
source code sample showing the issue.

Copied from Stack Overflow: "GCC -H option issue (header dependency tree
listing)"
https://stackoverflow.com/questions/58864013/gcc-h-option-issue-header-dependency-tree-listing

If the content of an included header file evaluates to empty string during
repeated inclusion (because of the content being enclosed in an #ifndef
statement), then the included header file name is not listed as a dependency of
any subsequent header files.

Example:
$ cat main.cpp
#include "header1.h"
int main(void) {
  return 0;
}

$ cat header1.h
#ifndef header1_h
#define header1_h
#include "header2.h"
#include "header3.h"
#endif

$ cat header2.h
#ifndef header2_h
#define header2_h
#include "header3.h"
#endif

$ cat header3.h
#ifndef header3_h
#define header3_h
void header3_function1(void);
#endif

$ gcc -H main.cpp 
. header1.h
.. header2.h
... header3.h

Problem:
We would expect header3.h to be a dependency of header1.h.

Expected output:
. header1.h
.. header2.h
... header3.h
.. header3.h


Using the attached file:
$ tar xvfz h-option-test-case.tar.gz
$ cd h-option-test-case/
$ gcc -H main.cpp

Thanks for your support,
Adrien

[Bug fortran/95107] ICE in hash_operand, at fold-const.c:3768

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

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

--- Comment #5 from Eric Gallager  ---
(In reply to Eric Gallager from comment #4)
> I ran into an ICE at that same line in that same file, but it was when
> compiling a C source file instead of a Fortran one... should I open a
> separate bug?

actually never mind; the issue I was running into was actually bug 97125

[Bug fortran/95107] ICE in hash_operand, at fold-const.c:3768

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

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #4 from Eric Gallager  ---
I ran into an ICE at that same line in that same file, but it was when
compiling a C source file instead of a Fortran one... should I open a separate
bug?

[Bug objc/90707] GNU Objective C (C++) does not support nullability syntax.

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

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #2 from Eric Gallager  ---
a simple testcase is just to include 

[Bug objc/90709] [meta-bug] GNU Objective C (C++) cannot consume current headers on Darwin platforms.

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

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #10 from Eric Gallager  ---
I just ran into this trying to compile my fork of emacs on Catalina; from
looking at config.log (5.3MB!) it looks like the lack of support for "nullable"
(bug 90707) is the biggest missing feature

[Bug rtl-optimization/97535] On AArch64 memcpy expansion cannot handle length > 32-bit signed int max

[icenowy at aosc dot io via Gcc-bugs]

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

--- Comment #1 from Icenowy Zheng  ---
The problem is found to be trying to expand a memcpy() call with fixed length
2181038080.

Handling of memcpy() expansion seem to be corrupted when len >= 2147483648. The
length is mod with 2147483648, and then forced to expand.

When a test program that contains a call to memcpy() with len 2147483648 is
tried, it is "expanded" to nothing.

The problematic thing seems to be aarch64_expand_cpymem() in master at
config/aarch64/aarch64.c (aarch64_expand_movmem() in GCC 9), in which the
variable n is declared with `int` (a 32-bit signed integer on both AArch64 LP64
and x86-64). Modify it to HOST_WIDE_INT seems to fix the problem.

[Bug c++/97536] New: [concepts] parser segfault for concept defined in function template

[hello at josephloser dot com via Gcc-bugs]

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

Bug ID: 97536
   Summary: [concepts] parser segfault for concept defined in
function template
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hello at josephloser dot com
  Target Milestone: ---

The code below causes a segfault when parsing a concept definition inside a
function template. Note that concepts cannot be defined inside a function
scope, so this should result in a useful diagnostic.

Output of compiling the program with -std=c++2a:
prog.cc: In function 'auto foo()':
prog.cc:3:5: warning: C++20 concept definition syntax is 'concept  =
'
3 | concept bar = true;
  | ^~~
prog.cc:3:13: internal compiler error: Segmentation fault
3 | concept bar = true;
  | ^~~
0xc2e30f crash_signal
../../source/gcc/toplev.c:330
0x68c49c grokvardecl
../../source/gcc/cp/decl.c:10103
0x68c49c grokdeclarator(cp_declarator const*, cp_decl_specifier_seq*,
decl_context, int, tree_node**)
../../source/gcc/cp/decl.c:13691
0x6913c8 start_decl(cp_declarator const*, cp_decl_specifier_seq*, int,
tree_node*, tree_node*, tree_node**)
../../source/gcc/cp/decl.c:5218
0x71cc3e cp_parser_init_declarator
../../source/gcc/cp/parser.c:20934
0x6fe49c cp_parser_simple_declaration
../../source/gcc/cp/parser.c:13876
0x7002ad cp_parser_declaration_statement
../../source/gcc/cp/parser.c:13316
0x700e97 cp_parser_statement
../../source/gcc/cp/parser.c:11562
0x701e6d cp_parser_statement_seq_opt
../../source/gcc/cp/parser.c:11928
0x701f20 cp_parser_compound_statement
../../source/gcc/cp/parser.c:11878
0x718d2a cp_parser_function_body
../../source/gcc/cp/parser.c:23236
0x718d2a cp_parser_ctor_initializer_opt_and_function_body
../../source/gcc/cp/parser.c:23287
0x71c730 cp_parser_function_definition_after_declarator
../../source/gcc/cp/parser.c:29182
0x71d64f cp_parser_function_definition_from_specifiers_and_declarator
../../source/gcc/cp/parser.c:29098
0x71d64f cp_parser_init_declarator
../../source/gcc/cp/parser.c:20838
0x722c14 cp_parser_single_declaration
../../source/gcc/cp/parser.c:29669
0x722d77 cp_parser_template_declaration_after_parameters
../../source/gcc/cp/parser.c:29242
0x72337a cp_parser_explicit_template_declaration
../../source/gcc/cp/parser.c:29507
0x726cd9 cp_parser_declaration
../../source/gcc/cp/parser.c:13524
0x72726d cp_parser_translation_unit
../../source/gcc/cp/parser.c:4793
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Wandbox link: https://wandbox.org/permlink/PKqzkXQLl3fv8ev4

For what its worth, the warning given for when a concept is defined inside a
function (not a function template) could probably be improved as well. If you
remove the template on `foo` such that it is just a function, the error is:

prog.cc: In function 'auto foo()':
prog.cc:2:5: warning: C++20 concept definition syntax is 'concept  =
'
2 | concept bar = true;
  | ^~~
prog.cc:2:5: error: a non-template variable cannot be 'concept'

The error message is fine, but the warning is a bit of a misnomer as `concept
bar = true;` does meet the grammar of `concept  = `.

[Bug rtl-optimization/97535] New: ICE when building xmrig on AArch64

[icenowy at aosc dot io via Gcc-bugs]

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

Bug ID: 97535
   Summary: ICE when building xmrig on AArch64
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: icenowy at aosc dot io
  Target Milestone: ---

Created attachment 49425
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49425=edit
Preprocessed source file

When building xmrig on AArch64 with GCC 9.3.1, this file will trap cc1plus into
infinitely running.

I extracted the preprocessed source and then proceed with GCC master (commit
0a74a0e1a2d ("libstdc++: Fix custom clock in test")), and now it fails with
ICE:

/var/cache/acbs/build/acbs.6sxjqdht/xmrig-6.3.5/src/crypto/rx/RxDataset.cpp: In
member function 'void xmrig::RxDataset::setRaw(const void*)':
/var/cache/acbs/build/acbs.6sxjqdht/xmrig-6.3.5/src/crypto/rx/RxDataset.cpp:178:1:
error: unrecognizable insn:
(insn 80 79 81 4 (parallel [
(set (reg:V4SI 162)
(mem:V4SI (plus:DI (reg:DI 97)
(const_int 1024 [0x400])) [0 MEM 
[(void *)raw_7(D)]+1024 S16 A8]))
(set (reg:V4SI 163)
(mem:V4SI (plus:DI (reg:DI 97)
(const_int 1040 [0x410])) [0 MEM 
[(void *)raw_7(D)]+1040 S16 A8]))
])
"/var/cache/acbs/build/acbs.6sxjqdht/xmrig-6.3.5/src/crypto/rx/RxDataset.cpp":177:11
-1
 (nil))
during RTL pass: vregs
/var/cache/acbs/build/acbs.6sxjqdht/xmrig-6.3.5/src/crypto/rx/RxDataset.cpp:178:1:
internal compiler error: in extract_insn, at recog.c:2295
0x82f9e8 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/icenowy/git-repos/gcc/gcc/rtl-error.c:108
0x82fa04 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/home/icenowy/git-repos/gcc/gcc/rtl-error.c:116
0x82def9 extract_insn(rtx_insn*)
/home/icenowy/git-repos/gcc/gcc/recog.c:2295
0xe433b7 instantiate_virtual_regs_in_insn
/home/icenowy/git-repos/gcc/gcc/function.c:1656
0xe433b7 instantiate_virtual_regs
/home/icenowy/git-repos/gcc/gcc/function.c:1977
0xe433b7 execute
/home/icenowy/git-repos/gcc/gcc/function.c:2026

[Bug c++/93297] internal compiler error: in set_constraints, at cp/constraint.cc:

[john at mcfarlane dot name via Gcc-bugs]

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

--- Comment #9 from John McFarlane  ---
And here is an ICE in 10.2: 

   struct a;
   template  class b;
   template  b()->b<>;
   template  using c = b;
   static_assert(c{}

CL: g++ -v -std=c++2a source.cpp
Online: https://godbolt.org/z/54aTr6

[Bug target/97534] New: [10/11 Regression] ICE in decompose, at rtl.h:2280 (arm-linux-gnueabihf)

[doko at debian dot org via Gcc-bugs]

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

Bug ID: 97534
   Summary: [10/11 Regression] ICE in decompose, at rtl.h:2280
(arm-linux-gnueabihf)
   Product: gcc
   Version: 10.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at debian dot org
  Target Milestone: ---

seen building mariadb with the gcc-10 branch and trunk, not seen without -g, or
with -O0:

$ cat btr0cu.ii
struct a {
  int b;
  void c(int d) { __atomic_fetch_sub(, d, int()); }
};
class e {
  a f;
  int g = 1 << 31;
  void h() { f.c(g); }
public:
  void i() {
e j;
j.h();
  }
} k;
void l() { k.i(); }

$ g++ -std=gnu++11 -c -g -O2 btr0cu.ii
during RTL pass: vartrack
btr0cu.ii: In function 'void l()':
btr0cu.ii:15:19: internal compiler error: in decompose, at rtl.h:2280
   15 | void l() { k.i(); }
  |   ^
0x8d359d wi::int_traits >::decompose(long
long*, unsigned int, std::pair const&)
../../src/gcc/rtl.h:2280
0x8d36ab wide_int_ref_storage::wide_int_ref_storage
>(std::pair const&)
../../src/gcc/wide-int.h:1024
0x8d36ab generic_wide_int
>::generic_wide_int >(std::pair const&)
../../src/gcc/wide-int.h:782
0x8d36ab poly_int<1u, generic_wide_int >
>::poly_int >(std::pair const&)
../../src/gcc/poly-int.h:670
0x8d36ab wi::to_poly_wide(rtx_def const*, machine_mode)
../../src/gcc/rtl.h:2365
0x8d36ab neg_poly_int_rtx
../../src/gcc/simplify-rtx.c:64
0x8daa91 simplify_binary_operation_1
../../src/gcc/simplify-rtx.c:2728
0x8dfa79 simplify_binary_operation(rtx_code, machine_mode, rtx_def*, rtx_def*)
../../src/gcc/simplify-rtx.c:2342
0x8dfaef simplify_gen_binary(rtx_code, machine_mode, rtx_def*, rtx_def*)
../../src/gcc/simplify-rtx.c:189
0xb7294d reverse_op
../../src/gcc/var-tracking.c:5942
0xb7294d add_stores
../../src/gcc/var-tracking.c:6225
0xb6cca9 add_with_sets
../../src/gcc/var-tracking.c:6648
0x51b913 cselib_record_sets
../../src/gcc/cselib.c:2904
0x51c6cf cselib_process_insn(rtx_insn*)
../../src/gcc/cselib.c:3066
0xb7c5d5 vt_initialize
../../src/gcc/var-tracking.c:10252
0xb82185 variable_tracking_main_1
../../src/gcc/var-tracking.c:10481
0xb822df variable_tracking_main()
../../src/gcc/var-tracking.c:10534
0xb822df execute
../../src/gcc/var-tracking.c:10571
Please submit a full bug report,
with preprocessed source if appropriate.


gcc-10 was configured with 

--with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=hard --with-mode=thumb 
--enable-checking=yes,extra,rtl
--enable-default-pie

gcc trunk was configured with --enable-checking=yes

[Bug fortran/95979] [10/11 Regression] ICE in get_kind, at fortran/simplify.c:129

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

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

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

https://gcc.gnu.org/g:90b83a25b3499ff50a9b7afc0e84e1355191c220

commit r10-8939-g90b83a25b3499ff50a9b7afc0e84e1355191c220
Author: Harald Anlauf 
Date:   Fri Oct 16 22:17:46 2020 +0200

PR fortran/95979 - ICE in get_kind, at fortran/simplify.c:129

Simplification of the elemental intrinsic INDEX with constant array-valued
arguments failed with an ICE or did not reduce to a constant array,
depending
also on the presence of the optional KIND argument.  Add a further attempt
of
simplification in the case of elemental intrinsics, and make sure the KIND
argument is not removed prematurely during simplification of INDEX.

gcc/fortran/ChangeLog:

PR fortran/95979
* expr.c (gfc_check_init_expr): Fix check of return code from
gfc_intrinsic_func_interface.
* intrinsic.c (gfc_intrinsic_func_interface): Add further attempt
of simplification of elemental intrinsics with array arguments.
* iresolve.c (gfc_resolve_index_func): Keep optional KIND argument
for simplification of elemental use of INDEX.

gcc/testsuite/ChangeLog:

PR fortran/95979
* gfortran.dg/index_4.f90: New test.

(cherry picked from commit 02629b116eed7c6911ef0eb2ef97e1883e9fb1de)

[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

--- Comment #5 from Jakub Jelinek  ---
The operand in this case is the whole
(vec_duplicate:V8DF (mem:DF (reg...) [6 *fact_18(D)+0 S8 A64]))
which matches the
(define_special_memory_constraint "Br"
  "@internal bcst memory operand."
  (match_operand 0 "bcst_mem_operand"))
constraint where bcst_mem_operand is:
(define_predicate "bcst_mem_operand"
  (and (match_code "vec_duplicate")
   (and (match_test "TARGET_AVX512F")
(ior (match_test "TARGET_AVX512VL")
 (match_test "GET_MODE_SIZE (GET_MODE (op)) == 64")))
   (match_test "VALID_BCST_MODE_P (GET_MODE_INNER (GET_MODE (op)))")
   (match_test "memory_operand (XEXP (op, 0), GET_MODE (XEXP (op, 0)))")))
I think the extract_mem_from_operand function has been introduced for this in
LRA, but perhaps it is not used in all the places where it is needed.

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

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

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

--- Comment #4 from Vladimir Makarov  ---
(In reply to Jakub Jelinek from comment #3)
> The IRA dump says:
>   a2(r189,l0) costs: AREG:2000,2000 DREG:2000,2000 CREG:26000,-1000
> BREG:2000,2000 SIREG:2000,2000 DIREG:2000,2000 AD_REGS:2000,2000
> CLOBBERED_REGS
> :2000,2000 Q_REGS:2000,2000 TLS_GOTBASE_REGS:2000,2000
> GENERAL_REGS:2000,2000 SSE_FIRST_REG:12000,12000 NO_REX_SSE_REGS:12000,12000
> SSE_REGS:12000,
> 12000 ALL_SSE_REGS:12000,12000 MMX_REGS:26000,26000 INT_SSE_REGS:26000,26000
> ALL_REGS:424000,424000 MEM:12000,12000
> so the INT_SSE_REGS cost of 26000 seems might higher than GENERAL_REGS cost.

It does not matter what class IRA gives the address reg. LRA should fix this
anyway.  For usual memory the correct address reg class is checked by
legitimate_address_p hook.

I guess in this case it is a special memory and its constraint does not check
address reg class at all.  I believe the bug should be fixed on
machine-dependent side of GCC (in constraints and predicates).

[Bug c++/97533] New: ICE encountering operator() within lambda expression within templated struct

[harry at mccleave dot ca via Gcc-bugs]

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

Bug ID: 97533
   Summary: ICE encountering operator() within lambda expression
within templated struct
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: harry at mccleave dot ca
  Target Milestone: ---

gcc version: 10.2
options: /std:c++17
Issue: internal compiler error
godbolt link: https://godbolt.org/z/W4GGnE
reduced code that replicates:
template
struct Blah
{
  void operator()(int& a,int& b) {
[this](auto&... args) {
  (operator()(args),...);
}(a, b);
  }
};

int main() {
  Blah proc;
  int a, b;
  proc(a, b);
}

[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

--- Comment #3 from Jakub Jelinek  ---
The IRA dump says:
  a2(r189,l0) costs: AREG:2000,2000 DREG:2000,2000 CREG:26000,-1000
BREG:2000,2000 SIREG:2000,2000 DIREG:2000,2000 AD_REGS:2000,2000 CLOBBERED_REGS
:2000,2000 Q_REGS:2000,2000 TLS_GOTBASE_REGS:2000,2000 GENERAL_REGS:2000,2000
SSE_FIRST_REG:12000,12000 NO_REX_SSE_REGS:12000,12000 SSE_REGS:12000,
12000 ALL_SSE_REGS:12000,12000 MMX_REGS:26000,26000 INT_SSE_REGS:26000,26000
ALL_REGS:424000,424000 MEM:12000,12000
so the INT_SSE_REGS cost of 26000 seems might higher than GENERAL_REGS cost.

[Bug ada/97504] [11 Regression] Ada bootstrap error after r11-4029

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

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

Eric Botcazou  changed:

   What|Removed |Added

   Last reconfirmed||2020-10-22
 Ever confirmed|0   |1
 CC||ebotcazou at gcc dot gnu.org
 Status|UNCONFIRMED |NEW

--- Comment #3 from Eric Botcazou  ---
This occurs on Aarch64 and SPARC as well.

[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

 CC||liuhongt at gcc dot gnu.org,
   ||vmakarov at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Started with r11-4203-g7026bb9504eb0f95e114f832cd6dd14302376861
We have:
(insn 87 4 5 2 (set (reg:DI 189)
(reg:DI 2 cx [ fact ])) "simd-2.f90":13:0 74 {*movdi_internal}
 (expr_list:REG_DEAD (reg:DI 2 cx [ fact ])
(nil)))
...
(insn 76 75 81 2 (set (reg:V8DF 153 [ vect_c_20.334 ])
(plus:V8DF (vec_duplicate:V8DF (mem:DF (reg:DI 189) [6 *fact_18(D)+0 S8
A64]))
(reg:V8DF 184 [ vect__17.333 ]))) "simd-2.f90":18:0 1569
{*addv8df3}
 (expr_list:REG_DEAD (reg:DI 189)
(expr_list:REG_DEAD (reg:V8DF 184 [ vect__17.333 ])
(nil
as the only insns that refer to pseudo 189, and for some reason IRA decides to
allocate that pseudo into xmm4 register which is not valid for memory
addresses.
So, something in the r11-4202 IRA changes doesn't work properly (and maybe
something in LRA too, because even if IRA decides to put it into such register,
which it e.g. could because 95% of uses would be in vector register contexts,
LRA should be able to fix it up, shouldn't it?

[Bug c++/97328] [10 Regression] ICE in verify_ctor_sanity, at cp/constexpr.c:3995 since r10-7313-gb599bf9d6d1e180d

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #9 from Patrick Palka  ---
Fixed for GCC 10.3+.

[Bug c++/97328] [10 Regression] ICE in verify_ctor_sanity, at cp/constexpr.c:3995 since r10-7313-gb599bf9d6d1e180d

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

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

--- Comment #8 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Patrick Palka
:

https://gcc.gnu.org/g:8094f781c35b64da68245d351b85546cca5b809b

commit r10-8938-g8094f781c35b64da68245d351b85546cca5b809b
Author: Patrick Palka 
Date:   Thu Oct 22 07:40:40 2020 -0400

c++: Handle RANGE_EXPR index in init_subob_ctx [PR97328]

In the testcase below, we're ICEing during constexpr evaluation of the
CONSTRUCTOR {.data={{}, [1 ... 7]={}}} of type 'vector'.  The interesting
thing about this CONSTRUCTOR is that it has a RANGE_EXPR index for an
element initializer which doesn't satisfy reduced_constant_expression_p
(because the field 't' is uninitialized).

This is a problem because init_subob_ctx currently punts on setting up a
sub-aggregate initialization context when given a RANGE_EXPR index, so
we later trip over the asserts in verify_ctor_sanity when recursing into
cxx_eval_bare_aggregate on this element initializer.

Fix this by making init_subob_ctx set up an appropriate initialization
context when supplied a RANGE_EXPR index.

gcc/cp/ChangeLog:

PR c++/97328
* constexpr.c (init_subob_ctx): Don't punt on RANGE_EXPR
indexes, instead build a sub-aggregate initialization context
with no subobject.

gcc/testsuite/ChangeLog:

PR c++/97328
* g++.dg/cpp2a/constexpr-init19.C: New test.
* g++.dg/cpp2a/constexpr-init20.C: New test.

(cherry picked from commit 3d423c6f6a69d87ad52ba3af75f3debd8a8b8810)

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

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

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

Richard Biener  changed:

   What|Removed |Added

Summary|Error: insn does not|[11 Regression] Error: insn
   |satisfy its constraints,|does not satisfy its
   |internal compiler error: in |constraints, internal
   |extract_constrain_insn, at  |compiler error: in
   |recog.c:2196|extract_constrain_insn, at
   ||recog.c:2196
   Last reconfirmed||2020-10-22
   Target Milestone|--- |11.0
 Status|UNCONFIRMED |NEW
 Target||x86_64-*-* i?86-*-*
 Ever confirmed|0   |1
  Component|libgomp |target

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

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

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

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

Bug ID: 97532
   Summary: Error: insn does not satisfy its constraints, internal
compiler error: in extract_constrain_insn, at
recog.c:2196
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

At commit c26d7df1031 "OpenMP: Fortran - support omp flush's memorder clauses"
I'm seeing a few new FAILs with nvptx offloading:
...
FAIL: libgomp.fortran/examples-4/simd-2.f90   -O1  (internal compiler error)
FAIL: libgomp.fortran/examples-4/simd-2.f90   -O1  (test for excess errors)
FAIL: libgomp.fortran/examples-4/simd-2.f90   -O2  (internal compiler error)
FAIL: libgomp.fortran/examples-4/simd-2.f90   -O2  (test for excess errors)
FAIL: libgomp.fortran/examples-4/simd-2.f90   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  (internal compiler
error)
FAIL: libgomp.fortran/examples-4/simd-2.f90   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  (test for excess
errors)
FAIL: libgomp.fortran/examples-4/simd-2.f90   -O3 -g  (internal compiler error)
FAIL: libgomp.fortran/examples-4/simd-2.f90   -O3 -g  (test for excess errors)
FAIL: libgomp.fortran/examples-4/simd-2.f90   -Os  (internal compiler error)
FAIL: libgomp.fortran/examples-4/simd-2.f90   -Os  (test for excess errors)
...

In more detail:
...
/home/vries/oacc/trunk/source-gcc/libgomp/testsuite/libgomp.fortran/examples-4/simd-2.f90:19:0:
Error: insn does not satisfy its constraints:^M
(insn 76 75 82 2 (set (reg:V8DF 20 xmm0 [orig:153 vect_c_20.334 ] [153])^M
(plus:V8DF (reg:V8DF 20 xmm0 [orig:184 vect__17.333 ] [184])^M
(vec_duplicate:V8DF (mem:DF (reg:DI 24 xmm4 [189]) [6 *fact_18(D)+0
S8 A64]
"/home/vries/oacc/trunk/source-gcc/libgomp/testsuite/libgomp.fortran/examples-4/simd-2.f90":18:0
1569 {*addv8df3}^M
 (nil))^M
during RTL pass: reload^M
/home/vries/oacc/trunk/source-gcc/libgomp/testsuite/libgomp.fortran/examples-4/simd-2.f90:19:0:
internal compiler error: in extract_constrain_insn, at recog.c:2196^M
0x6092d8 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)^M
/home/vries/oacc/trunk/source-gcc/gcc/rtl-error.c:108^M
0x609301 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)^M
/home/vries/oacc/trunk/source-gcc/gcc/rtl-error.c:118^M
0xcb52ad extract_constrain_insn(rtx_insn*)^M
/home/vries/oacc/trunk/source-gcc/gcc/recog.c:2196^M
0xb99457 check_rtl^M
/home/vries/oacc/trunk/source-gcc/gcc/lra.c:2173^M
...

[Bug c++/96499] Pass ill-formed visitor with different return type of result type of 3-way comparison into std::visit occurs internal compiler error

[hewillk at gmail dot com via Gcc-bugs]

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

康桓瑋  changed:

   What|Removed |Added

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

--- Comment #1 from 康桓瑋  ---
Fixed.

[Bug c++/96409] A lambda with a template parameter list inside the template function using C++20 nested requirements clauses occurs internal compiler error

[hewillk at gmail dot com via Gcc-bugs]

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

康桓瑋  changed:

   What|Removed |Added

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

--- Comment #5 from 康桓瑋  ---
Fixed.

[Bug c++/96410] A lambda with a template parameter list inside the template function using C++20 requires clauses is not usable in a constant expression

[hewillk at gmail dot com via Gcc-bugs]

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

康桓瑋  changed:

   What|Removed |Added

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

--- Comment #5 from 康桓瑋  ---
Fixed.

[Bug c++/97531] New: Improve type/non-type declaration diagnostic

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

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

Bug ID: 97531
   Summary: Improve type/non-type declaration diagnostic
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

For this:

struct A { };
struct B { B(A); };

void
fn ()
{
  B(A()); // extern struct B A (void);
  A a;
}

we issue:
q.C: In function ‘void fn()’:
q.C:8:4: error: expected ‘;’ before ‘a’
8 |   A a;
  |^~
  |;

Eh, what?

clang++:
q.C:8:3: error: must use 'struct' tag to refer to type 'A' in this scope
  A a;
  ^
  struct 
q.C:7:5: note: struct 'A' is hidden by a non-type declaration of 'A' here
  B(A()); // extern struct B A (void);
^

[Bug fortran/97530] New: Segmentation fault compiling coarray program with option -fcoarray=shared (not with -fcoarray={lib,single})

[toon at moene dot org via Gcc-bugs]

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

Bug ID: 97530
   Summary: Segmentation fault compiling coarray program with
option -fcoarray=shared (not with
-fcoarray={lib,single})
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: toon at moene dot org
  Target Milestone: ---

Created attachment 49424
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49424=edit
Source code of the of the full program reported on.

This is actually using the compiler from the devel/coarray_native branch (built
today), but I couldn't select that with the "version" option.

I get the following Segmentation fault when compiling the attached program, as
follows:

~/compilers/install/devel/coarray_native/bin/gfortran  -S -fcoarray=shared
random-weather.f90 
random-weather.f90:236:0:

  236 |   int_mult % ps = ms % ps * ifactor
  | 
internal compiler error: Segmentation fault
0xe61e3f crash_signal
/home/toon/compilers/coarray_native/gcc/toplev.c:327
0x92954d gfc_conv_ss_descriptor
/home/toon/compilers/coarray_native/gcc/fortran/trans-array.c:3044
0x92c380 gfc_conv_ss_startstride(gfc_loopinfo*)
/home/toon/compilers/coarray_native/gcc/fortran/trans-array.c:4433
0x961ba9 gfc_trans_assignment_1
/home/toon/compilers/coarray_native/gcc/fortran/trans-expr.c:10858
0x920a82 trans_code
/home/toon/compilers/coarray_native/gcc/fortran/trans.c:1899
0x94ff8e gfc_generate_function_code(gfc_namespace*)
/home/toon/compilers/coarray_native/gcc/fortran/trans-decl.c:7067
0x924f61 gfc_generate_module_code(gfc_namespace*)
/home/toon/compilers/coarray_native/gcc/fortran/trans.c:2299
0x8cc28d translate_all_program_units
/home/toon/compilers/coarray_native/gcc/fortran/parse.c:6334
0x8cc28d gfc_parse_file()
/home/toon/compilers/coarray_native/gcc/fortran/parse.c:6616
0x91da6f gfc_be_parse_file
/home/toon/compilers/coarray_native/gcc/fortran/f95-lang.c:212
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Doesn't happen with -fcoarray={lib,single}

[Bug c++/25814] Request for warning for parser ambiguity of function declarations and variable declarations with initializations

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #18 from Marek Polacek  ---
I now have a patch.

[Bug tree-optimization/97529] New: Condition not constant folded

[jmuizelaar at mozilla dot com via Gcc-bugs]

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

Bug ID: 97529
   Summary: Condition not constant folded
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jmuizelaar at mozilla dot com
  Target Milestone: ---

>From https://github.com/rust-lang/rust/issues/74938

GCC compiles:

#include 

const size_t N = 3;

int foo(size_t len) {
size_t newlen = (len / N) * N;
return newlen <= len;
}

to:

foo:
movabs  rdx, -6148914691236517205
mov rax, rdi
mul rdx
mov rax, rdx
and rdx, -2
shr rax
add rdx, rax
xor eax, eax
cmp rdi, rdx
setnb   al
ret
N:
.quad   3

clang:

foo:# @foo
mov eax, 1
ret
N:
.quad   3

[Bug testsuite/97522] [11 regression] test cases fail on powerpc64 BE after r11-4077

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

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

--- Comment #2 from David Edelsohn  ---
fixed

[Bug testsuite/97522] [11 regression] test cases fail on powerpc64 BE after r11-4077

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

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

David Edelsohn  changed:

   What|Removed |Added

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

--- Comment #1 from David Edelsohn  ---
fixed

[Bug lto/97524] Compiling with -flto=auto fails in make is not installed

[tstellar at redhat dot com via Gcc-bugs]

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

--- Comment #6 from Tom Stellard  ---
If I have make installed on my system, but am using something else (e.g. ninja)
to build my project, will I still get parallel execution?

[Bug bootstrap/97527] OpenBSD bootstrap fails with out of memory allocating 8 bytes after a total of 0 bytes

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

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

--- Comment #9 from Thomas Koenig  ---
Created attachment 49423
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49423=edit
config.log from libgomp using binutils compiled with gcc 8.4.0

Using the binutils compiled with gcc 8.4 now leads to an error in
libgomp configure, apparently because of some collision with LTO
symbols (???)

gmake[4]: Leaving directory
'/home/tkoenig/trunk-bin/x86_64-unknown-openbsd6.8/libgcc'
gmake[3]: Leaving directory
'/home/tkoenig/trunk-bin/x86_64-unknown-openbsd6.8/libgcc'
Checking multilib configuration for libgomp...
Configuring stage 1 in x86_64-unknown-openbsd6.8/libgomp
configure: loading cache ./config.cache
checking for --enable-version-specific-runtime-libs... no
checking for --enable-generated-files-in-srcdir... no
checking build system type... x86_64-unknown-openbsd6.8
checking host system type... x86_64-unknown-openbsd6.8
checking target system type... x86_64-unknown-openbsd6.8
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /usr/local/bin/gmkdir -p
checking for gawk... gawk
checking whether gmake sets $(MAKE)... yes
checking whether gmake supports nested variables... yes
checking for x86_64-unknown-openbsd6.8-gcc...
/home/tkoenig/trunk-bin/./gcc/xgcc -B/home/tkoenig/trunk-bin/./gcc/
-B/home/tkoenig/x86_64-unknown-openbsd6.8/bin/
-B/home/tkoenig/x86_64-unknown-openbsd6.8/lib/ -isystem
/home/tkoenig/x86_64-unknown-openbsd6.8/include -isystem
/home/tkoenig/x86_64-unknown-openbsd6.8/sys-include   -fno-checking
checking whether the C compiler works... no
configure: error: in
`/home/tkoenig/trunk-bin/x86_64-unknown-openbsd6.8/libgomp':
configure: error: C compiler cannot create executables
See `config.log' for more details
gmake[2]: *** [Makefile:24794: configure-stage1-target-libgomp] Error 77
gmake[2]: Leaving directory '/home/tkoenig/trunk-bin'
gmake[1]: *** [Makefile:27002: stage1-bubble] Error 2
gmake[1]: Leaving directory '/home/tkoenig/trunk-bin'
gmake: *** [Makefile:1004: all] Error 2

The suspicious part is

configure:3910: checking whether the C compiler works
configure:3932: /home/tkoenig/trunk-bin/./gcc/xgcc
-B/home/tkoenig/trunk-bin/./gcc/ -B/home/tkoenig/x86_64-unknown-openbsd6.8/bin/
-B/home/tkoenig/x86_64-unknown-openbsd6.8/lib/ -isystem
/home/tkoenig/x86_64-unknown-openbsd6.8/include -isystem
/home/tkoenig/x86_64-unknown-openbsd6.8/sys-include   -fno-checking -g -O2  
conftest.c  >&5
Wrong dl symbols!
/home/tkoenig/x86_64-unknown-openbsd6.8/bin/ld:
/home/tkoenig/trunk-bin/./gcc/liblto_plugin.so: error loading plugin: Wrong dl
symbols!

collect2: error: ld returned 1 exit status
configure:3936: $? = 1
configure:3974: result: no
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "GNU Offloading and Multi Processing Runtime Library"
| #define PACKAGE_TARNAME "libgomp"
| #define PACKAGE_VERSION "1.0"
| #define PACKAGE_STRING "GNU Offloading and Multi Processing Runtime Library
1.0"
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE_URL "http://www.gnu.org/software/libgomp/;
| #define PACKAGE "libgomp"
| #define VERSION "1.0"
| /* end confdefs.h.  */
| 
| int
| main ()
| {
| 
|   ;
|   return 0;
| }
configure:3979: error: in
`/home/tkoenig/trunk-bin/x86_64-unknown-openbsd6.8/libgomp':
configure:3981: error: C compiler cannot create executables
See `config.log' for more details

[Bug lto/97524] Compiling with -flto=auto fails in make is not installed

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

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

Martin Liška  changed:

   What|Removed |Added

   Target Milestone|--- |11.0

--- Comment #5 from Martin Liška  ---
Btw. the following also fails probably since the beginning:

$ echo "void main() { }" | MAKE=mymake gcc -x c -flto=16 -
lto-wrapper: fatal error: execvp: No such file or directory
compilation terminated.
/usr/lib64/gcc/x86_64-suse-linux/10/../../../../x86_64-suse-linux/bin/ld:
error: lto-wrapper failed
collect2: error: ld returned 1 exit status

I've got a patch for both cases.

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

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords|ice-on-invalid-code |ice-on-valid-code
   Target Milestone|--- |10.3

[Bug c++/97328] [10 Regression] ICE in verify_ctor_sanity, at cp/constexpr.c:3995 since r10-7313-gb599bf9d6d1e180d

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

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

Patrick Palka  changed:

   What|Removed |Added

Summary|[10/11 Regression] ICE in   |[10 Regression] ICE in
   |verify_ctor_sanity, at  |verify_ctor_sanity, at
   |cp/constexpr.c:3995 since   |cp/constexpr.c:3995 since
   |r10-7313-gb599bf9d6d1e180d  |r10-7313-gb599bf9d6d1e180d

--- Comment #7 from Patrick Palka  ---
Fixed for GCC 11 so far.

[Bug c++/96575] std::ranges::sort is not usable as a 'constexpr' function when saving its return value in lambda function

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #4 from Patrick Palka  ---
Thanks for the report.  The testcase was triggering a bug in the constexpr
evaluator, which should now been fixed.

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

[doko at debian dot org via Gcc-bugs]

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

Bug ID: 97528
   Summary: [10/11 Regression] ICE in decompose_automod_address,
at rtlanal.c:6298 (arm-linux-gnueabihf)
   Product: gcc
   Version: 10.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at debian dot org
  Target Milestone: ---

seen on the gcc-10 branch 2020-10-11 and trunk, building firefox.

$ cat intrapred_neon.i
typedef __simd64_int16_t a;
typedef __simd64_uint16_t b;
unsigned short c;
int d;
b e;
void f() {
  unsigned short *dst = 
  int g = d, bw = 4;
  b dc = e;
  for (int h = 0; h < bw; h++) {
unsigned short *i = dst;
b j = dc;
__builtin_neon_vst1v4hi((__builtin_neon_hi *)i, (a)j);
dst += g;
  }
}

$ gcc -o intrapred_neon.o -c -O1 -mfpu=neon intrapred_neon.i
during RTL pass: reload
/home/glandium/firefox-esr-78.4.0esr/third_party/aom/aom_dsp/arm/intrapred_neon.c:
In function 'aom_highbd_dc_predictor_4x4_neon':
/home/glandium/firefox-esr-78.4.0esr/third_party/aom/aom_dsp/arm/intrapred_neon.c:589:188:
internal compiler error: in decompose_automod_address, at rtlanal.c:6298
0x6cda45 decompose_automod_address
../../src/gcc/rtlanal.c:6298
0x6cda45 decompose_address(address_info*, rtx_def**, machine_mode, unsigned
char, rtx_code)
../../src/gcc/rtlanal.c:6463
0x6cdb19 decompose_mem_address(address_info*, rtx_def*)
../../src/gcc/rtlanal.c:6486
0x59a67b process_address_1
../../src/gcc/lra-constraints.c:3374
0x59c4cd process_address
../../src/gcc/lra-constraints.c:3648
0x59c4cd curr_insn_transform
../../src/gcc/lra-constraints.c:3963
0x5a088f lra_constraints(bool)
../../src/gcc/lra-constraints.c:5036
0x58e7a5 lra(_IO_FILE*)
../../src/gcc/lra.c:2443
0x54f331 do_reload
../../src/gcc/ira.c:5527
0x54f331 execute
../../src/gcc/ira.c:5713
Please submit a full bug report,
with preprocessed source if appropriate.

gcc-10 was configured with 

--with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=hard --with-mode=thumb 
--enable-checking=yes,extra,rtl
--enable-default-pie

gcc trunk was configure with --enable-checking=yes

[Bug c++/97511] [11 Regression] ICE in template_parm_to_arg, at cp/pt.c:4744 since r11-3296-ge5d72c840a226fdb

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #3 from Patrick Palka  ---
Should be fixed now, thanks for the report.

[Bug c++/97328] [10/11 Regression] ICE in verify_ctor_sanity, at cp/constexpr.c:3995 since r10-7313-gb599bf9d6d1e180d

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

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

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

commit r11-4231-g3d423c6f6a69d87ad52ba3af75f3debd8a8b8810
Author: Patrick Palka 
Date:   Thu Oct 22 07:40:40 2020 -0400

c++: Handle RANGE_EXPR index in init_subob_ctx [PR97328]

In the testcase below, we're ICEing during constexpr evaluation of the
CONSTRUCTOR {.data={{}, [1 ... 7]={}}} of type 'vector'.  The interesting
thing about this CONSTRUCTOR is that it has a RANGE_EXPR index for an
element initializer which doesn't satisfy reduced_constant_expression_p
(because the field 't' is uninitialized).

This is a problem because init_subob_ctx currently punts on setting up a
sub-aggregate initialization context when given a RANGE_EXPR index, so
we later trip over the asserts in verify_ctor_sanity when recursing into
cxx_eval_bare_aggregate on this element initializer.

Fix this by making init_subob_ctx set up an appropriate initialization
context when supplied a RANGE_EXPR index.

gcc/cp/ChangeLog:

PR c++/97328
* constexpr.c (init_subob_ctx): Don't punt on RANGE_EXPR
indexes, instead build a sub-aggregate initialization context
with no subobject.

gcc/testsuite/ChangeLog:

PR c++/97328
* g++.dg/cpp2a/constexpr-init19.C: New test.
* g++.dg/cpp2a/constexpr-init20.C: New test.

[Bug c++/97511] [11 Regression] ICE in template_parm_to_arg, at cp/pt.c:4744 since r11-3296-ge5d72c840a226fdb

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

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

commit r11-4229-gb083a14dfe1f53446722f45078e419238d24
Author: Patrick Palka 
Date:   Thu Oct 22 07:27:55 2020 -0400

c++: Check DECL_TEMPLATE_PARM_P in duplicate_decls [PR97511]

This makes duplicate_decls differentiate a TYPE_DECL for an alias
template from a TYPE_DECL for one of its template parameters.  The
recently added assert in template_parm_to_arg revealed this latent issue
because merging of the two TYPE_DECLs cleared the DECL_TEMPLATE_PARM_P
flag.

With this patch, we now also correctly diagnose the name shadowing in
the below testcase (as required by [temp.local]/6).

gcc/cp/ChangeLog:

PR c++/97511
* decl.c (duplicate_decls): Return NULL_TREE if
DECL_TEMPLATE_PARM_P differ.

gcc/testsuite/ChangeLog:

PR c++/97511
* g++.dg/template/shadow3.C: New test.

[Bug c++/96575] std::ranges::sort is not usable as a 'constexpr' function when saving its return value in lambda function

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

https://gcc.gnu.org/g:46fdced6a9f936ae4d5b42347d7d87f69875683a

commit r11-4230-g46fdced6a9f936ae4d5b42347d7d87f69875683a
Author: Patrick Palka 
Date:   Thu Oct 22 07:33:58 2020 -0400

c++: constexpr evaluation and bare EMPTY_CLASS_EXPR [PR96575]

In the testcase below, folding of the initializer for 'ret' inside the
instantiated f::lambda ends up yielding an initializer for which
potential_constant_expression returns false.  This causes finish_function
to mark the lambda as non-constexpr, which ultimately causes us to reject
'f(g)' as a call to a non-constexpr function.

The initializer for 'ret' inside f::lambda, prior to folding, is
the CALL_EXPR

  ::operator() (, ({}, <<< Unknown tree: empty_class_expr
>>>;))

where the second argument is a COMPOUND_EXPR whose second operand is an
EMPTY_CLASS_EXPR that was formed by build_class_a.  cp_fully_fold_init
is able to only partially fold this initializer: it gets rid of the
side-effectless COMPOUND_EXPR to obtain

  ::operator() (, <<< Unknown tree: empty_class_expr >>>)

as the final initializer for 'ret'.  This initializer no longer satifies
potential_constant_expression due to the bare EMPTY_CLASS_EXPR which is
not wrapped in a COMPOUND_EXPR.

(cp_fully_fold_init first tries maybe_constant_value on the original
CALL_EXPR, but constexpr evaluation punts upon seeing
__builtin_is_constant_evaluated, since manifestly_const_eval is false.)

To fix this, it seems we could either make cp_fold preserve the
COMPOUND_EXPR trees produced by build_call_a, or we could improve
the constexpr machinery to treat EMPTY_CLASS_EXPR trees as first-class
citizens.  Assuming it's safe to continue folding away these
COMPOUND_EXPRs, the second approach seems cleaner, so this patch
implements the second approach.

gcc/cp/ChangeLog:

PR c++/96575
* constexpr.c (cxx_eval_constant_expression)
: Lower it to a CONSTRUCTOR.
(potential_constant_expression_1) : Remove
now-redundant handling of COMPOUND_EXPR with EMPTY_CLASS_EXPR
second operand.
: Return true instead of false.

gcc/testsuite/ChangeLog:

PR c++/96575
* g++.dg/cpp1z/constexpr-96575.C: New test.

[Bug target/97521] [11 Regression] wrong code with -mno-sse2 since r11-3394

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #14 from Richard Biener  ---
Accidentially pushed it before knowing AVX512 HW results.  Let's hope fixed.

[Bug target/97521] [11 Regression] wrong code with -mno-sse2 since r11-3394

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

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

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

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

commit r11-4226-gb960a9c83a93b58a84a7a370002990810675ac5d
Author: Richard Biener 
Date:   Thu Oct 22 09:29:47 2020 +0200

middle-end/97521 - fix VECTOR_CST expansion

This fixes expansion of VECTOR_BOOLEAN_TYPE_P VECTOR_CSTs which
when using an integer mode are not always "mask-mode" but may
be using an integer mode when there's no supported vector mode.

The patch makes sure to only go the mask-mode expansion if
the elements do not line up to cover the full integer mode
(when they do and the mode was an actual mask-mode there's
no actual difference in both expansions).

2020-10-22  Richard Biener  

PR middle-end/97521
* expr.c (expand_expr_real_1): Be more careful when
expanding a VECTOR_BOOLEAN_TYPE_P VECTOR_CSTs.

* gcc.target/i386/pr97521.c: New testcase.

[Bug bootstrap/97502] [11 Regression] PGO bootstrap failure on s390x-linux with -march=z13 starting with r11-3426

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug rtl-optimization/97439] Wrong min value generated for DFP numbers

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

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-8 branch has been updated by Andreas Krebbel
:

https://gcc.gnu.org/g:2819cdd8ff8e15ed5efb4095143cf531cf3e50f9

commit r8-10593-g2819cdd8ff8e15ed5efb4095143cf531cf3e50f9
Author: Andreas Krebbel 
Date:   Thu Oct 22 12:24:22 2020 +0200

Fix PR97439

decimal_real_maxval misses to set the sign flag in the REAL_VALUE_TYPE.

gcc/ChangeLog:

PR rtl-optimization/97439
* dfp.c (decimal_real_maxval): Set the sign flag in the
generated number.

gcc/testsuite/ChangeLog:

* gcc.dg/dfp/pr97439.c: New test.

(cherry picked from commit e3f25eac67aee77af0b2038cd4d6cbd36d7f1030)

[Bug rtl-optimization/97439] Wrong min value generated for DFP numbers

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

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Andreas Krebbel
:

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

commit r9-9007-ga07af7753004e711d0db8d4e5620a4e8afc8f10c
Author: Andreas Krebbel 
Date:   Thu Oct 22 12:24:22 2020 +0200

Fix PR97439

decimal_real_maxval misses to set the sign flag in the REAL_VALUE_TYPE.

gcc/ChangeLog:

PR rtl-optimization/97439
* dfp.c (decimal_real_maxval): Set the sign flag in the
generated number.

gcc/testsuite/ChangeLog:

* gcc.dg/dfp/pr97439.c: New test.

(cherry picked from commit e3f25eac67aee77af0b2038cd4d6cbd36d7f1030)

[Bug rtl-optimization/97439] Wrong min value generated for DFP numbers

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

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

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

https://gcc.gnu.org/g:523e6e5bd47bcc03e9782039b52fb3f8b3276e64

commit r10-8937-g523e6e5bd47bcc03e9782039b52fb3f8b3276e64
Author: Andreas Krebbel 
Date:   Thu Oct 22 12:24:22 2020 +0200

Fix PR97439

decimal_real_maxval misses to set the sign flag in the REAL_VALUE_TYPE.

gcc/ChangeLog:

PR rtl-optimization/97439
* dfp.c (decimal_real_maxval): Set the sign flag in the
generated number.

gcc/testsuite/ChangeLog:

* gcc.dg/dfp/pr97439.c: New test.

(cherry picked from commit e3f25eac67aee77af0b2038cd4d6cbd36d7f1030)

[Bug rtl-optimization/97439] Wrong min value generated for DFP numbers

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Andreas Krebbel :

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

commit r11-4223-ge3f25eac67aee77af0b2038cd4d6cbd36d7f1030
Author: Andreas Krebbel 
Date:   Thu Oct 22 12:24:22 2020 +0200

Fix PR97439

decimal_real_maxval misses to set the sign flag in the REAL_VALUE_TYPE.

gcc/ChangeLog:

PR rtl-optimization/97439
* dfp.c (decimal_real_maxval): Set the sign flag in the
generated number.

gcc/testsuite/ChangeLog:

* gcc.dg/dfp/pr97439.c: New test.

[Bug bootstrap/97502] [11 Regression] PGO bootstrap failure on s390x-linux with -march=z13 starting with r11-3426

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

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

--- Comment #8 from CVS Commits  ---
The master branch has been updated by Andreas Krebbel :

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

commit r11-4224-gf3cf5174b19a89aeed5aa2ba82a373ded35a4a96
Author: Andreas Krebbel 
Date:   Thu Oct 22 12:24:22 2020 +0200

Fix PR97502

The S/390 backend does not define vec_cmp expanders so far. We relied
solely on expanding vcond.  With commit 502d63b6d various testcases
started to ICE now.

This patch just adds the missing expanders to prevent the ICE.
However, there are still a couple of performance-related testcase
regressions with the vcond lowering which have to be fixed
independently.

gcc/ChangeLog:

PR target/97502
* config/s390/vector.md ("vec_cmp")
("vec_cmpu"): New expanders.

gcc/testsuite/ChangeLog:

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

[Bug analyzer/97514] [11 Regression] ICE in add_function_entry, at analyzer/engine.cc:1958

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

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

David Malcolm  changed:

   What|Removed |Added

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

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

[Bug analyzer/97489] [11 Regression] ICE: Segmentation fault (in ana::supergraph::get_node_for_function_entry(function*) const) since r10-5950-g757bf1dff5e8cee3

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

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

David Malcolm  changed:

   What|Removed |Added

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

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

[Bug bootstrap/97527] OpenBSD bootstrap fails with out of memory allocating 8 bytes after a total of 0 bytes

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

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

--- Comment #8 from Thomas Koenig  ---
The *.s file generated with -save-temps is attached, but it
is truncated for a reason that I do not understand.

The binutils is indeed self-compiled from source (because the LLVM
linker cannot handle gcc compilation), using the system compiler, clang.
I'll recompile this with gcc 8.4 (which is installed in /usr/local/bin
as egcc) and see what happens then.

[Bug analyzer/97514] [11 Regression] ICE in add_function_entry, at analyzer/engine.cc:1958

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

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

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

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

commit r11-4222-gf7decfaebbcb8522fcb39b03a391a5c2cb64f460
Author: David Malcolm 
Date:   Thu Oct 22 06:16:28 2020 -0400

analyzer: fix ICE when handling callback exceeds enode limit [PR97514]

gcc/analyzer/ChangeLog:
PR analyzer/97514
* engine.cc (exploded_graph::add_function_entry): Handle failure
to create an enode, rather than asserting.

gcc/testsuite/ChangeLog:
PR analyzer/97514
* gcc.dg/analyzer/pr97514.c: New test.

[Bug analyzer/97489] [11 Regression] ICE: Segmentation fault (in ana::supergraph::get_node_for_function_entry(function*) const) since r10-5950-g757bf1dff5e8cee3

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

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

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

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

commit r11-4220-gb7f2cfbf0fc7bcd5c1e60fca354de8bf60f9acfa
Author: David Malcolm 
Date:   Thu Oct 22 06:12:31 2020 -0400

analyzer: fix ICE on dtor [PR97489]

gcc/analyzer/ChangeLog:
PR analyzer/97489
* engine.cc (exploded_graph::add_function_entry): Assert that we
have a function body.
(exploded_graph::on_escaped_function): Reject fndecls that don't
have a function body.

gcc/testsuite/ChangeLog:
PR analyzer/97489
* g++.dg/analyzer/pr97489.C: New test.

[Bug driver/81358] libatomic not automatically linked with C11 code

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

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #11 from Tobias Burnus  ---
RFC draft patch – also to solve an offload problem with atomic and nvptx
libgomp:
https://gcc.gnu.org/pipermail/gcc-patches/2020-October/556297.html
See reply for what still needs to be done (esp. related to building libraries +
testsuite).

[Bug target/97521] [11 Regression] wrong code with -mno-sse2 since r11-3394

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #12 from rguenther at suse dot de  ---
On Thu, 22 Oct 2020, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97521
> 
> --- Comment #11 from Jakub Jelinek  ---
> We don't necessarily need to make it user accessible.

Though I've missed a way to create VECTOR_BOOLEAN_TYPE_P vector
types for the GIMPLE FE (which measn the C FE has to have a way to
create them).

[Bug target/96759] [10/11 Regression] ICE in extract_insn, at recog.c:2294

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

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

Kito Cheng  changed:

   What|Removed |Added

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

--- Comment #7 from Kito Cheng  ---
Fixed on both trunk and gcc 10.

[Bug target/97521] [11 Regression] wrong code with -mno-sse2 since r11-3394

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

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

--- Comment #11 from Jakub Jelinek  ---
We don't necessarily need to make it user accessible.

[Bug target/97521] [11 Regression] wrong code with -mno-sse2 since r11-3394

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #10 from Hongtao.liu  ---
Speaking about how to represent the V*BImode constants, i think we need to
extend attribute vector_size to handle something like
---
typedef bool v8bi __attribute__ ((vector_size (1)));
---

currently there would be an error as 

:1:51: error: invalid vector type for attribute 'vector_size'

1 | typedef bool v8qi __attribute__ ((vector_size (1)));


also we need to support type convert between vector boolean types and integer
in front end, since many users may use integer as a mask.

[Bug target/97521] [11 Regression] wrong code with -mno-sse2 since r11-3394

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

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

--- Comment #9 from Jakub Jelinek  ---
Looking at simplify-rtx.c, I think as long as the constants are CONST_INTs,
simplify-rtx.c doesn't care if the non-constant is represented with scalar int
mode registers (etc.) or V*BImode.

[Bug target/97521] [11 Regression] wrong code with -mno-sse2 since r11-3394

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

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

--- Comment #8 from Jakub Jelinek  ---
Well, I think it is certainly desirable to keep using VEC_MERGE, not only
because it is less IL.
But pedantically already what i386 backend does doesn't match the documentation
which says that the last operand of VEC_MERGE is a CONST_INT.
We could just say that it is either a CONST_INT, or an RTL expression with a
scalar integral mode, or V*BImode mode.
And another question is how to represent the V*BImode constants, whether to
represent them as normal VOIDmode CONST_INTs, or something else
(const_vector:V*BI ...).

[Bug target/97521] [11 Regression] wrong code with -mno-sse2 since r11-3394

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #7 from rguenther at suse dot de  ---
On Thu, 22 Oct 2020, crazylht at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97521
> 
> Hongtao.liu  changed:
> 
>What|Removed |Added
> 
>  CC||crazylht at gmail dot com
> 
> --- Comment #6 from Hongtao.liu  ---
> (In reply to Richard Biener from comment #4)
> > (In reply to Jakub Jelinek from comment #3)
> > > And we do that because:
> > > case VECTOR_CST:
> > >   {
> > > tree tmp = NULL_TREE;
> > > if (VECTOR_MODE_P (mode))
> > >   return const_vector_from_tree (exp);
> > > scalar_int_mode int_mode;
> > > if (is_int_mode (mode, _mode))
> > >   {
> > > if (VECTOR_BOOLEAN_TYPE_P (TREE_TYPE (exp)))
> > >   return const_scalar_mask_from_tree (int_mode, exp);
> > 
> > but I have no easy access to a AVX512 runtime system (and no idea how to
> > make dejagnu use sde for a i386.exp testsuite run).  On a AVX2 system
> > i386.exp is clean with the above.
> > 
> > Thoughts?
> > 
> > [AVX512 should have used VnBImode like SVE does]
> > 
> 
> 
> Can vec_merge support operands with VnBImode as items? I didn't find it's used
> in any SVE patterns.

You can use (vec_select (vec_concat ...)) instead of (vec_merge ...).
It's a long standing issue that we have two ways of expressing the same
(each with it's own drawbacks).

[Bug target/96759] [10/11 Regression] ICE in extract_insn, at recog.c:2294

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

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

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

https://gcc.gnu.org/g:3444bed1a0bedf8c5e97ba9b0de6a547bb375ead

commit r10-8936-g3444bed1a0bedf8c5e97ba9b0de6a547bb375ead
Author: Kito Cheng 
Date:   Wed Sep 2 14:26:15 2020 +0800

PR target/96759 - Handle global variable assignment from misaligned
structure/PARALLEL return values.

In g:70cdb21e579191fe9f0f1d45e328908e59c0179e, DECL/global variable has
handled
misaligned stores, but it didn't handle PARALLEL values, and I refer the
other part of this function, I found the PARALLEL need handled by
emit_group_* functions, so I add a check, and using emit_group_store if
storing a PARALLEL value, also checked this change didn't break the
testcase(gcc.target/arm/unaligned-argument-3.c) added by the orginal
changes.

For riscv64 target, struct S {int a; double b;} will pack into a parallel
value to return and it has TImode when misaligned access is supported,
however TImode required 16-byte align, but it only 8-byte align, so it go
to
the misaligned stores handling, then it will try to generate move
instruction from a PARALLEL value.

Tested on following target without introduced new reguression:
  - riscv32/riscv64 elf
  - x86_64-linux
  - arm-eabi

v2 changes:
  - Use maybe_emit_group_store instead of emit_group_store.
  - Remove push_temp_slots/pop_temp_slots, emit_group_store only require
stack temp slot when dst is CONCAT or PARALLEL, however
maybe_emit_group_store will always use REG for dst if needed.

gcc/ChangeLog:

PR target/96759
* expr.c (expand_assignment): Handle misaligned stores with
PARALLEL
value.

gcc/testsuite/ChangeLog:

PR target/96759
* g++.target/riscv/pr96759.C: New.
* gcc.target/riscv/pr96759.c: New.

(cherry picked from commit 78fbe731a8822e819c4ca0e6d6f777c7a2f36bad)

[Bug target/97521] [11 Regression] wrong code with -mno-sse2 since r11-3394

[crazylht at gmail dot com via Gcc-bugs]

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

Hongtao.liu  changed:

   What|Removed |Added

 CC||crazylht at gmail dot com

--- Comment #6 from Hongtao.liu  ---
(In reply to Richard Biener from comment #4)
> (In reply to Jakub Jelinek from comment #3)
> > And we do that because:
> > case VECTOR_CST:
> >   {
> > tree tmp = NULL_TREE;
> > if (VECTOR_MODE_P (mode))
> >   return const_vector_from_tree (exp);
> > scalar_int_mode int_mode;
> > if (is_int_mode (mode, _mode))
> >   {
> > if (VECTOR_BOOLEAN_TYPE_P (TREE_TYPE (exp)))
> >   return const_scalar_mask_from_tree (int_mode, exp);
> 
> but I have no easy access to a AVX512 runtime system (and no idea how to
> make dejagnu use sde for a i386.exp testsuite run).  On a AVX2 system
> i386.exp is clean with the above.
> 
> Thoughts?
> 
> [AVX512 should have used VnBImode like SVE does]
> 


Can vec_merge support operands with VnBImode as items? I didn't find it's used
in any SVE patterns.

[Bug tree-optimization/97519] builtin_constant_p (x + cst) should be optimized to builtin_constant_p (x)

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
We would certainly need to punt on gimple_could_trap_p assignments, as can be
seen e.g. on
static inline int
foo (int x)
{
  return __builtin_constant_p ((x + 32) / 0);
}

int
bar (void)
{
  return foo (35);
}
with -O2 -fno-early-inlining.
Anyway, I'm actually not sure if it is safe to perform this change at all.
Consider:
int
foo (int x)
{
  if (x < __INT_MAX__ - 30)
return 23;
  int y = x + 30;
  if (__builtin_constant_p (y))
return y;
  return 42;
}
with -O2 -fdisable-tree-evrp
y is constant (__INT_MAX__), but x is certainly not constant.

[Bug target/96998] GCC ICEs in on building AArch64 Linux kernel after basepoints/gcc-11-2903-g6b3034eaba83

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

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

--- Comment #11 from Alex Coplan  ---
The patch series has been restructured to first fix the AArch64 bug, and then
restore code quality with a patch to combine.

The AArch64 patch
(https://gcc.gnu.org/pipermail/gcc-patches/2020-October/556237.html) has been
approved, we're waiting for a review of the 2/2 combine patch.

[Bug target/96998] GCC ICEs in on building AArch64 Linux kernel after basepoints/gcc-11-2903-g6b3034eaba83

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

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

Alex Coplan  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #10 from Alex Coplan  ---
*** Bug 97526 has been marked as a duplicate of this bug. ***

[Bug rtl-optimization/97526] [11 Regression] ICE in lra_set_insn_recog_data, at lra.c:1004 since r11-2903-g6b3034eaba83935d9f6dfb20d2efbdb34b5b00bf

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

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

Alex Coplan  changed:

   What|Removed |Added

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

--- Comment #2 from Alex Coplan  ---
Dup. The aarch64 patch
https://gcc.gnu.org/pipermail/gcc-patches/2020-October/556237.html fixes this
ICE. We're waiting to get a review for the 2/2 combine patch.

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

[Bug c/94722] implement __attribute__((no_stack_protector)) function attribute

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

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

Martin Liška  changed:

   What|Removed |Added

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

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

[Bug c/94722] implement __attribute__((no_stack_protector)) function attribute

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

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

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

https://gcc.gnu.org/g:346b302d09c1e6db56d9fe69048acb32fbb97845

commit r11-4218-g346b302d09c1e6db56d9fe69048acb32fbb97845
Author: Martin Liska 
Date:   Fri May 15 14:42:12 2020 +0200

Implement no_stack_protector attribute.

gcc/ChangeLog:

2020-05-18  Martin Liska  

PR c/94722
* cfgexpand.c (stack_protect_decl_phase):
Guard with lookup_attribute("no_stack_protector") at
various places.
(expand_used_vars): Likewise here.
* doc/extend.texi: Document no_stack_protector attribute.

gcc/ada/ChangeLog:

2020-05-18  Martin Liska  

PR c/94722
* gcc-interface/utils.c (handle_no_stack_protect_attribute):
New.
(handle_stack_protect_attribute): Add error message for a
no_stack_protector function.

gcc/c-family/ChangeLog:

2020-05-18  Martin Liska  

PR c/94722
* c-attribs.c (handle_no_stack_protect_function_attribute): New.
(handle_stack_protect_attribute): Add error message for a
no_stack_protector function.

gcc/testsuite/ChangeLog:

2020-05-18  Martin Liska  

PR c/94722
* g++.dg/no-stack-protector-attr-2.C: New test.
* g++.dg/no-stack-protector-attr-3.C: New test.
* g++.dg/no-stack-protector-attr.C: New test.

[Bug tree-optimization/97505] [11 Regression] ICE in extract_range_basic, at vr-values.c:1439 since r11-4130-g16e4f1ad44e3c00b8b73c9e4ade3d236ea7044a8

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

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

--- Comment #4 from Aldy Hernandez  ---
Looking at vr_values::extract_range_builtin(), I see that every single place
where we use ask for a range, we bail on non-integers (symbolics, etc).  That
is, with the exception of the UBSAN builtins.

The UBSAN builtins degrade into PLUS/MINUS/MULT and call
extract_range_from_binary_expr, which as I've shown, can special case some
symbolics which the ranger doesn't currently handle.

Since this is a UBSAN issue, we could still go with the original plan of
removing the duplicity in ranger vs vr-values, but we'd still have to leave in
the UBSAN builtin handling, perhaps as vr_values::extract_ubsan_builtin(). 
This isn't ideal, as we'd like to remove all the common code, but I'd be
willing to put up with UBSAN duplication for the time being.

A possible solution for this PR would be to disable the assert on the UBSAN
builtins:

diff --git a/gcc/vr-values.c b/gcc/vr-values.c
index 67c88006f13..3021f619319 100644
--- a/gcc/vr-values.c
+++ b/gcc/vr-values.c
@@ -1432,14 +1432,17 @@ vr_values::extract_range_basic (value_range_equiv *vr,
gimple *stmt)

   if (is_gimple_call (stmt) && extract_range_builtin (vr, stmt))
 {
+  combined_fn cfn = gimple_call_combined_fn (stmt);
+  if (cfn == CFN_UBSAN_CHECK_ADD
+ || cfn == CFN_UBSAN_CHECK_SUB
+ || cfn == CFN_UBSAN_CHECK_MUL)
+   return;
+
   value_range_equiv tmp;

And then, as a follow-up, remove all the builtin code from
extract_range_builtin, with the exception of the UBSAN stuff (renaming it to
extract_ubsan_builtin).

Now... the question is, whether this is worth it, since the plan for next
stage1 is to overhaul evrp and vrp, causing vr_values and friends to be
entirely removed.  If we leave the duplicate code in, we'll have to remember to
update the vr_values and ranger versions of this code in sync for the next
year.  I'm guessing this code doesn't change much??

If we do decide to remove it starting with the proposed patch above, we'd have
to do more extensive testing to make sure shit doesn't break.  Perhaps testing
on {-m32,-m64,-fsanitize=signed-integer-overflow} on x86, ppc64, and possibly
other slowpokes such as aarch64.

I'm torn.  It may be a lot of testing and possible breakage in return for
removing 90% of code that will hopefully be entirely removed during the next
cycle.

Thoughts?

[Bug target/96456] [10/11 Regression] ICE in expand_insn, at optabs.c:7511 on s390x-linux-gnu

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

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

Andreas Krebbel  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

--- Comment #5 from Andreas Krebbel  ---
closing

[Bug target/96456] [10/11 Regression] ICE in expand_insn, at optabs.c:7511 on s390x-linux-gnu

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

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

Andreas Krebbel  changed:

   What|Removed |Added

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

--- Comment #4 from Andreas Krebbel  ---
Fixed for trunk and GCC 10

[Bug lto/97524] Compiling with -flto=auto fails in make is not installed

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

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

--- Comment #4 from Martin Liška  ---
> It could, maybe with some diagnostic.  It could also use fork-based
> parallelism.

It seems to me extra work.
Expecting make for parallel execution seems to be a reasonable request.

[Bug target/97521] [11 Regression] wrong code with -mno-sse2 since r11-3394

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

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

--- Comment #5 from Jakub Jelinek  ---
I can test it on skylake-avx512.

[Bug bootstrap/97527] OpenBSD bootstrap fails with out of memory allocating 8 bytes after a total of 0 bytes

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1
   Last reconfirmed||2020-10-22

--- Comment #7 from Richard Biener  ---
So it's the assembler that runs OOM - can you instead attach the assembler
file (-save-temps should produce it) and try if manually invoking the
assembler reproduces the bug?

What's the version of 'as'?  It looks like self-compiled?

[Bug lto/97524] Compiling with -flto=auto fails in make is not installed

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

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

--- Comment #3 from Richard Biener  ---
(In reply to Jakub Jelinek from comment #2)
> Well, can't it fall back to serial compilation?

It could, maybe with some diagnostic.  It could also use fork-based
parallelism.

[Bug rtl-optimization/97526] [11 Regression] ICE in lra_set_insn_recog_data, at lra.c:1004 since r11-2903-g6b3034eaba83935d9f6dfb20d2efbdb34b5b00bf

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

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

Martin Liška  changed:

   What|Removed |Added

   Priority|P3  |P1
 CC||acoplan at gcc dot gnu.org
  Known to work||10.2.0
Summary|ICE in  |[11 Regression] ICE in
   |lra_set_insn_recog_data, at |lra_set_insn_recog_data, at
   |lra.c:1004  |lra.c:1004 since
   ||r11-2903-g6b3034eaba83935d9
   ||f6dfb20d2efbdb34b5b00bf
  Known to fail||11.0

--- Comment #1 from Martin Liška  ---
Started with r11-2903-g6b3034eaba83935d9f6dfb20d2efbdb34b5b00bf.

[Bug testsuite/97522] [11 regression] test cases fail on powerpc64 BE after r11-4077

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
   Target Milestone|--- |11.0

[Bug target/97521] [11 Regression] wrong code with -mno-sse2 since r11-3394

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Biener  ---
(In reply to Jakub Jelinek from comment #3)
> And we do that because:
> case VECTOR_CST:
>   {
> tree tmp = NULL_TREE;
> if (VECTOR_MODE_P (mode))
>   return const_vector_from_tree (exp);
> scalar_int_mode int_mode;
> if (is_int_mode (mode, _mode))
>   {
> if (VECTOR_BOOLEAN_TYPE_P (TREE_TYPE (exp)))
>   return const_scalar_mask_from_tree (int_mode, exp);

I think const_scalar_mask_from_tree is completely wrong in ignoring the
precision of the VECTOR_BOOLEAN component type.  At least it is
inconsistent with the processing of VECTOR_BOOLEAN_TYPE_P CTORs.

Now I can see that this was intended for AVX512 but I can't see how this
"inconsistency" can possibly work if you consider the use of _1:

  _19 = BIT_FIELD_REF <_1, 64, 0>;

if you disable TER then how should we ever able to "reinterpret" the
BIT_FIELD_REF to the "narrowed" view of the VECTOR_BOOLEAN_TYPE_P
mask?

A heuristic for an intermediate hack might be to skip
const_scalar_mask_from_tree when the component precision times the
number of elements equals the mode precision of the vector.

Thus the following fixes the testcase

diff --git a/gcc/expr.c b/gcc/expr.c
index 9d951e82522..d87bda777d0 100644
--- a/gcc/expr.c
+++ b/gcc/expr.c
@@ -10356,7 +10356,10 @@ expand_expr_real_1 (tree exp, rtx target, machine_mode
tmode,
scalar_int_mode int_mode;
if (is_int_mode (mode, _mode))
  {
-   if (VECTOR_BOOLEAN_TYPE_P (TREE_TYPE (exp)))
+   if (VECTOR_BOOLEAN_TYPE_P (TREE_TYPE (exp))
+   && maybe_ne (TYPE_PRECISION (TREE_TYPE (TREE_TYPE (exp)))
+* TYPE_VECTOR_SUBPARTS (TREE_TYPE (exp)),
+GET_MODE_PRECISION (int_mode)))
  return const_scalar_mask_from_tree (int_mode, exp);
else

but I have no easy access to a AVX512 runtime system (and no idea how to
make dejagnu use sde for a i386.exp testsuite run).  On a AVX2 system
i386.exp is clean with the above.

Thoughts?

[AVX512 should have used VnBImode like SVE does]

> where the VECTOR_CST type is now a vector boolean with DImode element type
> and TImode as the (poor man's) vector mode.
> 
> So, the question is how to differentiate between vector booleans that want
> to be a bitmask in an integral mode vs. poor man's vector booleans for which
> we'd want to fallthru into the VIEW_CONVERT_EXPR code below this.
> And what other spots need that.
> Perhaps check if the bitsize (or precision?) of the vector type's mode is
> equal to bitsize (or precision?) of the element mode times number of
> elements in the vector?

[Bug lto/97524] Compiling with -flto=auto fails in make is not installed

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Well, can't it fall back to serial compilation?

[Bug tree-optimization/97520] ICE in calc_stmt, at gimple-range.cc:399 with "-O1 -fno-tree-fre -ftree-vrp"

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/97519] builtin_constant_p (x + cst) should be optimized to builtin_constant_p (x)

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

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

--- Comment #2 from Richard Biener  ---
Implemented in match.pd it will cover both.  SSA backprop would be the most
natural classical pass candidate but that runs after IPA.  The other candidate
is of course forwprop where it would be "cheaper" (not so many new patterns
to match in match.pd), "chewing" ops during re-processing of processed stmts.

[Bug bootstrap/97527] OpenBSD bootstrap fails with out of memory allocating 8 bytes after a total of 0 bytes

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

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

--- Comment #6 from Thomas Koenig  ---
The machine is gcc220.fsffrance.org ; if anybody has an account there
and wants to peek into /home/tkoenig to look into more details, be my
guest.

[Bug bootstrap/97527] OpenBSD bootstrap fails with out of memory allocating 8 bytes after a total of 0 bytes

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

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

--- Comment #5 from Thomas Koenig  ---
Created attachment 49422
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49422=edit
Generated gimple-match.c

All the temporary files were generated by manually adding -save-temps
to the Makefile in the gcc subdirectory, then re-compiling.

The error is repeatable.

Here's the output of vmstat while the machine is not compiling:

gcc220$ vmstat
 procsmemory   pagedisk traps  cpu
 r   s   avm fre  flt  re  pi  po  fr  sr sd0  int   sys   cs us sy id
 1  60   35M   2616M 6785   0   0   0   0   0   2   87  5296  432  8  2 90

[Bug bootstrap/97527] OpenBSD bootstrap fails with out of memory allocating 8 bytes after a total of 0 bytes

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

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

Thomas Koenig  changed:

   What|Removed |Added

 Target||x86_64-unknown-openbsd6.8

--- Comment #4 from Thomas Koenig  ---
Boostrapping compiler is

gcc220$ egcc -v
Using built-in specs.
COLLECT_GCC=egcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-openbsd6.8/8.4.0/lto-wrapper
Target: x86_64-unknown-openbsd6.8
Configured with: /usr/obj/ports/gcc-8.4.0/gcc-8.4.0/configure
--with-stage1-ldflags=-L/usr/obj/ports/gcc-8.4.0/bootstrap/lib --verbose
--program-transform-name='s,^,e,' --disable-nls --with-system-zlib
--disable-libmudflap --disable-libgomp --disable-libssp --disable-tls
--with-gnu-ld --with-gnu-as --enable-threads=posix --enable-wchar_t
--with-gmp=/usr/local --enable-languages=c,c++,fortran,objc,ada
--disable-libstdcxx-pch --enable-default-ssp --enable-default-pie --without-isl
--enable-cpp --prefix=/usr/local --sysconfdir=/etc --mandir=/usr/local/man
--infodir=/usr/local/info --localstatedir=/var --disable-silent-rules
--disable-gtk-doc
Thread model: posix
gcc version 8.4.0 (GCC) 
gcc220$ eg++ -v
Using built-in specs.
COLLECT_GCC=eg++
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-openbsd6.8/8.4.0/lto-wrapper
Target: x86_64-unknown-openbsd6.8
Configured with: /usr/obj/ports/gcc-8.4.0/gcc-8.4.0/configure
--with-stage1-ldflags=-L/usr/obj/ports/gcc-8.4.0/bootstrap/lib --verbose
--program-transform-name='s,^,e,' --disable-nls --with-system-zlib
--disable-libmudflap --disable-libgomp --disable-libssp --disable-tls
--with-gnu-ld --with-gnu-as --enable-threads=posix --enable-wchar_t
--with-gmp=/usr/local --enable-languages=c,c++,fortran,objc,ada
--disable-libstdcxx-pch --enable-default-ssp --enable-default-pie --without-isl
--enable-cpp --prefix=/usr/local --sysconfdir=/etc --mandir=/usr/local/man
--infodir=/usr/local/info --localstatedir=/var --disable-silent-rules
--disable-gtk-doc
Thread model: posix
gcc version 8.4.0 (GCC) 

Assember is

gcc220$ as --version
GNU assembler (GNU Binutils) 2.35
Copyright (C) 2020 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of `x86_64-unknown-openbsd6.8'.

(self-compiled)

[Bug bootstrap/97527] OpenBSD bootstrap fails with error: C++ preprocessor "/lib/cpp" fails sanity check

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

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

--- Comment #3 from Thomas Koenig  ---
Created attachment 49421
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49421=edit
config.log from the main build directory

[Bug bootstrap/97527] OpenBSD bootstrap fails with error: C++ preprocessor "/lib/cpp" fails sanity check

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

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

--- Comment #2 from Thomas Koenig  ---
Created attachment 49420
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49420=edit
Resulting assember file (which is incomplete)

[Bug bootstrap/97527] OpenBSD bootstrap fails with error: C++ preprocessor "/lib/cpp" fails sanity check

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

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

--- Comment #1 from Thomas Koenig  ---
Created attachment 49419
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49419=edit
Preprocessed source of gimple-match.ii (compressed)

[Bug bootstrap/97527] New: OpenBSD bootstrap fails with error: C++ preprocessor "/lib/cpp" fails sanity check

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

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

Bug ID: 97527
   Summary: OpenBSD bootstrap fails with error: C++ preprocessor
"/lib/cpp" fails sanity check
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tkoenig at gcc dot gnu.org
  Target Milestone: ---

Created attachment 49418
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49418=edit
config.log from the gcc subdirectory

Bootstrap on OpenBSD fails with a strange error: 

/home/tkoenig/trunk-bin/./prev-gcc/xg++ -B/home/tkoenig/trunk-bin/./prev-gcc/
-B/home/tkoenig/x86_64-unknown-openbsd6.8/bin/ -nostdinc++
-B/home/tkoenig/trunk-bin/prev-x86_64-unknown-openbsd6.8/libstdc++-v3/src/.libs
-B/home/tkoenig/trunk-bin/prev-x86_64-unknown-openbsd6.8/libstdc++-v3/libsupc++/.libs

-I/home/tkoenig/trunk-bin/prev-x86_64-unknown-openbsd6.8/libstdc++-v3/include/x86_64-unknown-openbsd6.8
 -I/home/tkoenig/trunk-bin/prev-x86_64-unknown-openbsd6.8/libstdc++-v3/include 
-I/home/tkoenig/trunk/libstdc++-v3/libsupc++
-L/home/tkoenig/trunk-bin/prev-x86_64-unknown-openbsd6.8/libstdc++-v3/src/.libs
-L/home/tkoenig/trunk-bin/prev-x86_64-unknown-openbsd6.8/libstdc++-v3/libsupc++/.libs
 -fno-PIE -c   -g -O2 -fchecking=1 -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wno-error=format-diag -Wmissing-format-attribute
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -Werror -fno-common -Wno-unused -DHAVE_CONFIG_H -I. -I.
-I../../trunk/gcc -I../../trunk/gcc/. -I../../trunk/gcc/../include
-I../../trunk/gcc/../libcpp/include -I/home/tkoenig/trunk-bin/./gmp
-I/home/tkoenig/trunk/gmp -I/home/tkoenig/trunk-bin/./mpfr/src
-I/home/tkoenig/trunk/mpfr/src -I/home/tkoenig/trunk/mpc/src 
-I../../trunk/gcc/../libdecnumber -I../../trunk/gcc/../libdecnumber/dpd
-I../libdecnumber -I../../trunk/gcc/../libbacktrace
-I/home/tkoenig/trunk-bin/./isl/include -I/home/tkoenig/trunk/isl/include  -o
gimple-match.o -MT gimple-match.o -MMD -MP -MF ./.deps/gimple-match.TPo
gimple-match.c

/home/tkoenig/x86_64-unknown-openbsd6.8/bin/as: out of memory allocating 8
bytes after a total of 0 bytes

[Bug rtl-optimization/97526] ICE in lra_set_insn_recog_data, at lra.c:1004

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Target Milestone|--- |11.0
   Last reconfirmed||2020-10-22
 Ever confirmed|0   |1
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=97313

[Bug rtl-optimization/97313] [11 Regression] ICE in lra_set_insn_recog_data, at lra.c:1004 since r11-937-g5261cf8ce824bfc7

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #6 from Martin Liška  ---
Closing then.

[Bug rtl-optimization/97526] New: ICE in lra_set_insn_recog_data, at lra.c:1004

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

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

Bug ID: 97526
   Summary: ICE in lra_set_insn_recog_data, at lra.c:1004
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-linux
Target: aarch64-linux-gnu

The following fails:

$ aarch64-linux-gnu-gcc
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/torture/pr91178-2.c
--param=max-gcse-memory=0 -fno-sched-pressure -Ofast -fno-ivopts -c
during RTL pass: reload
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/torture/pr91178-2.c: In
function ‘c’:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/torture/pr91178-2.c:12:1:
internal compiler error: in lra_set_insn_recog_data, at lra.c:1004
   12 | }
  | ^
0x658c8d lra_set_insn_recog_data(rtx_insn*)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/lra.c:1004
0xa1b917 lra_get_insn_recog_data
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/lra-int.h:488
0xa1b917 lra_update_insn_regno_info(rtx_insn*)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/lra.c:1625
0xa1baad lra_update_insn_regno_info(rtx_insn*)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/lra.c:1623
0xa1baad lra_push_insn_1
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/lra.c:1780
0xa1c79e lra_push_insn(rtx_insn*)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/lra.c:1788
0xa1c79e push_insns
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/lra.c:1831
0xa1c79e push_insns
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/lra.c:1823
0xa1c79e lra_process_new_insns(rtx_insn*, rtx_insn*, rtx_insn*, char const*)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/lra.c:1879
0xa31c90 curr_insn_transform
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/lra-constraints.c:4611
0xa338f7 lra_constraints(bool)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/lra-constraints.c:5105
0xa1d54c lra(_IO_FILE*)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/lra.c:2415
0x9dae01 do_reload
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/ira.c:5529
0x9dae01 execute
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/ira.c:5715
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug lto/97524] Compiling with -flto=auto fails in make is not installed

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
Confirmed. When make is not installed, no fallback is possible as LTO uses make
to do the parallel execution.