[Bug c/97172] [11 Regression] ICE: tree code ‘ssa_name’ is not supported in LTO streams since r11-3303-g6450f07388f9fe57

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

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

--- Comment #17 from Richard Biener  ---
Well - you're the first to add nontrivial (non-constant) trees to attributes. 
In GIMPLE all effects are supposed to be reflected in the IL and thus things
like
variable TYPE_SIZE or TYPE_MIN/MAX_VALUE are actually gimplified with code
generated during that inserted at the respective DECL_EXPR (which is where
gimplification is triggered from for the types).

Honestly I am not sure what you think you can do with arbitrary expressions
in an attribute down the GIMPLE pipeline given there's no connection to
actual variable values.  That said, the idea of sticking this additional
information in attributes in form of some random plain tree expressions
doesn't work.  You'd have to sanitize them at least if, say, expressions
based purely on other formal function arguments is what you are after.

That would for example be done by unsharing the expressions without locations
which you could try.  But for example the PR97133 case,

attributes 
value 
chain 
side-effects
arg:0 
side-effects
arg:0 
side-effects arg:1 >
arg:1 
side-effects arg:0 >>
arg:1 

certainly is missing constant evaluation (I can bet whatever is supposed
to consume the access attributes gives up on the above anyway).
C_MAYBE_CONST_EXPR is a frontend specific tree code and thus it shouldn't
even survive GENERICization.

So I would stronly suggest to revisit the way you try to record "every
information for accesses" for GCC 12 and for GCC 11 restrict the information
to CONSTANT_CLASS_P trees.

[Bug c++/98077] New: C++ 17: Using alias template bug in gcc

[juergen.reiss at gmx dot de via Gcc-bugs]

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

Bug ID: 98077
   Summary: C++ 17: Using alias template bug in gcc
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: juergen.reiss at gmx dot de
  Target Milestone: ---

The error was reported here:
https://stackoverflow.com/questions/65079471/c-17-using-alias-template-bug-in-gcc
A demo is here: https://godbolt.org/z/avGv3n

[Bug libfortran/98076] Increase speed of integer I/O

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

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

Thomas Koenig  changed:

   What|Removed |Added

Version|unknown |11.0
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |tkoenig at gcc dot 
gnu.org
   Severity|normal  |enhancement
   Target Milestone|--- |11.0
   Last reconfirmed||2020-12-01
 Status|UNCONFIRMED |ASSIGNED
   Keywords||missed-optimization

[Bug libfortran/98076] New: Increase speed of integer I/O

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

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

Bug ID: 98076
   Summary: Increase speed of integer I/O
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tkoenig at gcc dot gnu.org
  Target Milestone: ---

Currently, we use GFC_INTEGER_LARGEST for a lot of integer I/O.

One place where things could be improved is gfc_itoa:

const char *
gfc_itoa (GFC_INTEGER_LARGEST n, char *buffer, size_t len)
{
...
  GFC_UINTEGER_LARGEST t;
...
  t = n;
  if (n < 0)
{
  negative = 1;
  t = -n; /*must use unsigned to protect from overflow*/
}
...

  while (t != 0)
{
  *--p = '0' + (t % 10);
  t /= 10;
}

Currently, the quotient / remainder calculation is expanded into
a libcall.  This could be done by the improved remainder calculation
from PR97459 with the calculation of the quotient by multiplicative
inverse, and by switching to a smaller datatype once the value fits in
there.  Both can and should be combined, of course.

[Bug c++/94932] [10/11 Regression] ICE in ovl_skip_hidden, at cp/tree.c:2292 since r10-8016-gbce54ed494fd0e61

[asolokha at gmx dot com via Gcc-bugs]

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

--- Comment #3 from Arseny Solokha  ---
I cannot reproduce it anymore w/ gcc-11.0.0-alpha20201129 snapshot
(g:bb67ad5cff58a707aaae645d4f45a913d8511c86). gcc 10 and 11 now accept this
code.

[Bug ipa/97575] [11 Regression] ICE in try_make_edge_direct_simple_call, at ipa-prop.c:3671 or in propagate_controlled_uses, at ipa-prop.c:4073

[asolokha at gmx dot com via Gcc-bugs]

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

--- Comment #3 from Arseny Solokha  ---
I cannot reproduce it anymore w/ gcc-11.0.0-alpha20201129 snapshot
(g:bb67ad5cff58a707aaae645d4f45a913d8511c86).

[Bug target/96177] ICE: in extract_insn, at recog.c:2294 (error: unrecognizable insn)

[asolokha at gmx dot com via Gcc-bugs]

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

--- Comment #1 from Arseny Solokha  ---
I cannot reproduce it anymore w/ gcc-11.0.0-alpha20201129 snapshot
(g:bb67ad5cff58a707aaae645d4f45a913d8511c86).

[Bug ipa/98075] New: [10/11 Regression] ICE: verify_cgraph_node failed (error: malloc attribute should be used for a function that returns a pointer)

[asolokha at gmx dot com via Gcc-bugs]

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

Bug ID: 98075
   Summary: [10/11 Regression] ICE: verify_cgraph_node failed
(error: malloc attribute should be used for a function
that returns a pointer)
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

g++-11.0.0-alpha20201129 snapshot (g:bb67ad5cff58a707aaae645d4f45a913d8511c86)
ICEs when compiling the following testcase w/ -O2 -fno-inline:

template 
class xg {
public:
  BS *
  fw ()
  {
return static_cast (operator new (sizeof (BS)));
  }
};

class zp : xg {
public:
  __attribute__ ((always_inline)) zp ()
  {
hy = xg::fw ();
  }

private:
  int *hy;
};

void
e5 ()
{
  zp ix;
}

% g++-11.0.0 -O2 -fno-inline -c yhmypmjz.cpp
yhmypmjz.cpp:26:1: error: malloc attribute should be used for a function that
returns a pointer
   26 | }
  | ^
_ZN2xgIiE2fwEv.isra.0/7 (fw.isra) @0x7fb655a53660
  Type: function definition analyzed
  Visibility:
  References:
  Referring:
  Clone of _ZN2xgIiE2fwEv/4
  Availability: local
  Function flags: count:1073741824 (estimated locally) local
  Called by: _Z2e5v/3 (1073741824 (estimated locally),1.00 per call) (can throw
external)
  Calls: _Znwm/6 (1073741824 (estimated locally),1.00 per call) (can throw
external)
yhmypmjz.cpp:26:1: internal compiler error: verify_cgraph_node failed
0xbef9a8 cgraph_node::verify_node()
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201129/work/gcc-11-20201129/gcc/cgraph.c:3807
0xbde7c4 symtab_node::verify()
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201129/work/gcc-11-20201129/gcc/symtab.c:1356
0xbdf9b7 symtab_node::verify_symtab_nodes()
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201129/work/gcc-11-20201129/gcc/symtab.c:1384
0xbf49e0 symtab_node::checking_verify_symtab_nodes()
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201129/work/gcc-11-20201129/gcc/cgraph.h:675
0xbf49e0 symbol_table::compile()
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201129/work/gcc-11-20201129/gcc/cgraphunit.c:2321
0xbf7d47 symbol_table::compile()
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201129/work/gcc-11-20201129/gcc/cgraphunit.c:2274
0xbf7d47 symbol_table::finalize_compilation_unit()
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201129/work/gcc-11-20201129/gcc/cgraphunit.c:2542

[Bug tree-optimization/98074] New: [9/10 Regression] C Wrong code at O2~Os

[haoxintu at gmail dot com via Gcc-bugs]

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

Bug ID: 98074
   Summary: [9/10 Regression] C Wrong code at O2~Os
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: haoxintu at gmail dot com
  Target Milestone: ---

$cat small.c
#include 
#include 
struct {
  int64_t a;
} b;
struct c {
  signed d : 9;
  signed a : 21;
  signed e : 1;
};
int f, g;
uint16_t h() {
  struct c aa = {0, -4};
  int64_t *ab = 
  for (; g; g = 1)
;
  *ab = 5 && aa.e;
  return f;
}
int main() {
  h();
  printf("%d\n", (int)b.a);
}

$gcc-10 small.c ; ./a.out
0

$gcc-10 -O2 small.c ; ./a.out
1

$gcc-10 -O3 small.c ; ./a.out
1

This is only reproduced in GCC 10.x versions, and the GCC-trunk or GCC-9
downwards version seems fine to it.

BTW, may I ask how to check whether a wrong-code bug is already reported or
not? It's not like a crash that can be easily known as the duplicated one. I
will be appreciated if you can give me some tips. Thanks.

Best,
Haoxin

[Bug target/97417] RISC-V Unnecessary andi instruction when loading volatile bool

[admin at levyhsu dot com via Gcc-bugs]

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

--- Comment #46 from Levy  ---
Looking at gcc/passed.def and gcc/config/riscv-passes.def:

pass_shorten_memrefs is inserted after NEXT_PASS (pass_rtl_store_motion);

  NEXT_PASS (pass_rtl_store_motion);
(pass_shorten_memrefs)
  NEXT_PASS (pass_cse_after_global_opts);
  NEXT_PASS (pass_rtl_ifcvt);
  NEXT_PASS (pass_reginfo_init);
  /* Perform loop optimizations.  It might be better to do them a bit
  sooner, but we want the profile feedback to work more
  efficiently.  */
  NEXT_PASS (pass_loop2);
  PUSH_INSERT_PASSES_WITHIN (pass_loop2)
NEXT_PASS (pass_rtl_loop_init);
NEXT_PASS (pass_rtl_move_loop_invariants);
NEXT_PASS (pass_rtl_unroll_loops);
NEXT_PASS (pass_rtl_doloop);
NEXT_PASS (pass_rtl_loop_done);
  POP_INSERT_PASSES ()
  NEXT_PASS (pass_lower_subreg2);
  NEXT_PASS (pass_web);
  NEXT_PASS (pass_rtl_cprop);
  NEXT_PASS (pass_cse2);
  NEXT_PASS (pass_rtl_dse1);
  NEXT_PASS (pass_rtl_fwprop_addr);
  NEXT_PASS (pass_inc_dec);
  NEXT_PASS (pass_initialize_regs);
  NEXT_PASS (pass_ud_rtl_dce);
  NEXT_PASS (pass_combine);
  NEXT_PASS (pass_if_after_combine);
  NEXT_PASS (pass_jump_after_combine);
  NEXT_PASS (pass_partition_blocks);
  NEXT_PASS (pass_outof_cfg_layout_mode);
  NEXT_PASS (pass_split_all_insns);
  NEXT_PASS (pass_lower_subreg3);
  NEXT_PASS (pass_df_initialize_no_opt);
  NEXT_PASS (pass_stack_ptr_mod);
  NEXT_PASS (pass_mode_switching);
  NEXT_PASS (pass_match_asm_constraints);
  NEXT_PASS (pass_sms);
  NEXT_PASS (pass_live_range_shrinkage);
  NEXT_PASS (pass_sched);
  NEXT_PASS (pass_early_remat);
  NEXT_PASS (pass_ira);
  NEXT_PASS (pass_reload);
  NEXT_PASS (pass_postreload);
  PUSH_INSERT_PASSES_WITHIN (pass_postreload)
NEXT_PASS (pass_postreload_cse);
NEXT_PASS (pass_gcse2);
NEXT_PASS (pass_split_after_reload);
..

After some debugging processes. it seems either:
1.The address cost info was calculated between (pass_combine) and
(pass_shorten_memrefs) for patched version, then merged in the combined pass. 
patched one is failed to be recognized as unpathed one due to Sign/Zero extend
then Subreg.
This can be verified by adding -fdisable-rtl-combine option when compile, also
the address_cost was not called for the whole time.

2.4 insn was determined(or say fixed?) before (pass_rtl_fwprop_addr), as for
patched version, I saw forward_propagate_and_simplify() was called for 4 extra
times, then pass all the way to
propagate_rtx()->propagate_rtx_1()->should_replace_address()->address_cost() in
fwprop.c

I've also tested the (pass_postreload) as mentioned by Jim and
new_address_profitable_p(). But they seem not to be the right one.

Need some time to examine and trace the pass between (pass_shorten_memrefs) and
(pass_rtl_fwprop_addr).

[Bug c++/97975] [8/9/10/11 Regression] ICE unexpected expression '(int)A< >::b' of kind implicit_conv_expr

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

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

Marek Polacek  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug c++/97975] [8/9/10/11 Regression] ICE unexpected expression '(int)A< >::b' of kind implicit_conv_expr

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
   Target Milestone|--- |8.5
 Status|NEW |ASSIGNED
Summary|ICE unexpected expression   |[8/9/10/11 Regression] ICE
   |'(int)A<|unexpected expression
   ||'(int)A<
   |>::b' of kind   |
   |implicit_conv_expr  |>::b' of kind
   ||implicit_conv_expr

--- Comment #2 from Marek Polacek  ---
Started with r249382, actually.  I think I have a patch.

[Bug analyzer/98073] New: error: in can_merge_p, at analyzer/region-model.cc

[rnsanchez at gmail dot com via Gcc-bugs]

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

Bug ID: 98073
   Summary: error: in can_merge_p, at analyzer/region-model.cc
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: rnsanchez at gmail dot com
  Target Milestone: ---

Created attachment 49655
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49655=edit
Manually reduced after preprocessing http_htx.c

While compiling HAProxy from git (@v2.4-dev1-42-g4d6c59499).

Compiling the reduced file:

$ cc -Iinclude -fanalyzer -Wno-address-of-packed-member   -DUSE_EPOLL 
-DUSE_NETFILTER -DUSE_PCRE-DUSE_POLL  -DUSE_THREAD  -DUSE_BACKTRACE  
-DUSE_TPROXY -DUSE_LINUX_TPROXY -DUSE_LINUX_SPLICE -DUSE_LIBCRYPT -DUSE_CRYPT_H
-DUSE_GETADDRINFO -DUSE_OPENSSL -DUSE_LUA -DUSE_FUTEX -DUSE_ACCEPT4  -DUSE_ZLIB
 -DUSE_CPU_AFFINITY -DUSE_TFO -DUSE_NS -DUSE_DL -DUSE_RT  -DUSE_PRCTL
-DUSE_THREAD_DUMP -DUSE_PCRE -I/usr/include 
-DCONFIG_HAPROXY_VERSION=\"2.4-dev1-4d6c59-42\"
-DCONFIG_HAPROXY_DATE=\"2020/11/30\" -c -o src/http_htx.o
src/http_htx-reduced.i -v -save-temps
Reading specs from /usr/lib64/gcc/x86_64-slackware-linux/10.2.0/specs
COLLECT_GCC=cc
Target: x86_64-slackware-linux
Configured with: ../configure --prefix=/usr --libdir=/usr/lib64
--mandir=/usr/man --infodir=/usr/info --enable-shared --enable-bootstrap
--enable-languages=ada,brig,c,c++,d,fortran,go,lto,objc,obj-c++
--enable-threads=posix --enable-checking=release --enable-objc-gc
--with-system-zlib --enable-libstdcxx-dual-abi --with-default-libstdcxx-abi=new
--disable-libstdcxx-pch --disable-libunwind-exceptions --enable-__cxa_atexit
--disable-libssp --enable-gnu-unique-object --enable-plugin --enable-lto
--disable-install-libiberty --disable-werror --with-gnu-ld --with-isl --verbose
--with-arch-directory=amd64 --disable-gtktest --enable-clocale=gnu
--disable-multilib --target=x86_64-slackware-linux
--build=x86_64-slackware-linux --host=x86_64-slackware-linux
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.2.0 (GCC) 
COLLECT_GCC_OPTIONS='-I' 'include' '-fanalyzer' '-Wno-address-of-packed-member'
'-D' 'USE_EPOLL' '-D' 'USE_NETFILTER' '-D' 'USE_PCRE' '-D' 'USE_POLL' '-D'
'USE_THREAD' '-D' 'USE_BACKTRACE' '-D' 'USE_TPROXY' '-D' 'USE_LINUX_TPROXY'
'-D' 'USE_LINUX_SPLICE' '-D' 'USE_LIBCRYPT' '-D' 'USE_CRYPT_H' '-D'
'USE_GETADDRINFO' '-D' 'USE_OPENSSL' '-D' 'USE_LUA' '-D' 'USE_FUTEX' '-D'
'USE_ACCEPT4' '-D' 'USE_ZLIB' '-D' 'USE_CPU_AFFINITY' '-D' 'USE_TFO' '-D'
'USE_NS' '-D' 'USE_DL' '-D' 'USE_RT' '-D' 'USE_PRCTL' '-D' 'USE_THREAD_DUMP'
'-D' 'USE_PCRE' '-I' '/usr/include' '-D'
'CONFIG_HAPROXY_VERSION="2.4-dev1-4d6c59-42"' '-D'
'CONFIG_HAPROXY_DATE="2020/11/30"' '-c' '-o' 'src/http_htx.o' '-v'
'-save-temps' '-mtune=generic' '-march=x86-64'
 /usr/libexec/gcc/x86_64-slackware-linux/10.2.0/cc1 -fpreprocessed
src/http_htx-reduced.i -quiet -dumpbase http_htx-reduced.i -mtune=generic
-march=x86-64 -auxbase-strip src/http_htx.o -Wno-address-of-packed-member
-version -fanalyzer -o http_htx-reduced.s
GNU C17 (GCC) version 10.2.0 (x86_64-slackware-linux)
compiled by GNU C version 10.2.0, GMP version 6.2.0, MPFR version
4.1.0, MPC version 1.2.1, isl version isl-0.23-GMP

warning: GMP header version 6.2.0 differs from library version 6.2.1.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C17 (GCC) version 10.2.0 (x86_64-slackware-linux)
compiled by GNU C version 10.2.0, GMP version 6.2.0, MPFR version
4.1.0, MPC version 1.2.1, isl version isl-0.23-GMP

warning: GMP header version 6.2.0 differs from library version 6.2.1.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 7ecb224e89d32d55be91bf0fce5dc194
during IPA pass: analyzer
src/http_htx-reduced.i: In function 'http_update_host':
src/http_htx-reduced.i:123:14: internal compiler error: in can_merge_p, at
analyzer/region-model.cc:2053
  123 |authority = uri;
  |~~^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug c++/98072] New: [11 Regression] ICE in cp_parser_omp_var_list_no_open, at cp/parser.c:34843

[asolokha at gmx dot com via Gcc-bugs]

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

Bug ID: 98072
   Summary: [11 Regression] ICE in cp_parser_omp_var_list_no_open,
at cp/parser.c:34843
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code, openmp
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

g++-11.0.0-alpha20201129 snapshot (g:bb67ad5cff58a707aaae645d4f45a913d8511c86)
ICEs when compiling the following testcase, reduced from
test/OpenMP/depobj_ast_print.cpp from the clang 11.0.0 test suite, w/ -fopenmp:

void
dh (int *vp, int pm, int ca)
{
#pragma omp depobj (pm) depend (iterator (ca = 0 : *vp), in: vp[ca])
;
}

% g++-11.0.0 -fopenmp -c wmttbiko.cpp
wmttbiko.cpp: In function 'void dh(int*, int, int)':
wmttbiko.cpp:4:65: internal compiler error: in cp_parser_omp_var_list_no_open,
at cp/parser.c:34843
4 | #pragma omp depobj (pm) depend (iterator (ca = 0 : *vp), in: vp[ca])
  | ^~
0x9e4b1b cp_parser_omp_var_list_no_open
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201129/work/gcc-11-20201129/gcc/cp/parser.c:34843
0x9ec406 cp_parser_omp_clause_depend
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201129/work/gcc-11-20201129/gcc/cp/parser.c:37177
0x9d9540 cp_parser_omp_depobj
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201129/work/gcc-11-20201129/gcc/cp/parser.c:38787
0x9d9540 cp_parser_pragma
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201129/work/gcc-11-20201129/gcc/cp/parser.c:44282
0x9dfd68 cp_parser_statement
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201129/work/gcc-11-20201129/gcc/cp/parser.c:11561
0x9e0aed cp_parser_statement_seq_opt
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201129/work/gcc-11-20201129/gcc/cp/parser.c:11953
0x9e0bc8 cp_parser_compound_statement
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201129/work/gcc-11-20201129/gcc/cp/parser.c:11903
0x9fac64 cp_parser_function_body
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201129/work/gcc-11-20201129/gcc/cp/parser.c:23570
0x9fac64 cp_parser_ctor_initializer_opt_and_function_body
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201129/work/gcc-11-20201129/gcc/cp/parser.c:23621
0x9ff719 cp_parser_function_definition_after_declarator
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201129/work/gcc-11-20201129/gcc/cp/parser.c:29511
0xa00ab9 cp_parser_function_definition_from_specifiers_and_declarator
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201129/work/gcc-11-20201129/gcc/cp/parser.c:29427
0xa00ab9 cp_parser_init_declarator
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201129/work/gcc-11-20201129/gcc/cp/parser.c:21143
0x9ddaf7 cp_parser_simple_declaration
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201129/work/gcc-11-20201129/gcc/cp/parser.c:13963
0xa0aaa4 cp_parser_declaration
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201129/work/gcc-11-20201129/gcc/cp/parser.c:13660
0xa0b450 cp_parser_translation_unit
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201129/work/gcc-11-20201129/gcc/cp/parser.c:4806
0xa0b450 c_parse_file()
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201129/work/gcc-11-20201129/gcc/cp/parser.c:44630
0xb3082d c_common_parse_file()
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201129/work/gcc-11-20201129/gcc/c-family/c-opts.c:1198

The failing assert has been introduced in
g:c0c7270cc4efd896fe99f8ad5409dbef089a407f.

[Bug tree-optimization/98066] [11 Regression] ICE: Segmentation fault (in gsi_next)

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

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

--- Comment #8 from luoxhu at gcc dot gnu.org ---
Thanks for the quick fix!

[Bug c/97172] [11 Regression] ICE: tree code ‘ssa_name’ is not supported in LTO streams since r11-3303-g6450f07388f9fe57

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

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

--- Comment #16 from Martin Sebor  ---
The ICE in pr97133 mentions BIND_EXPR.  It's still there, even after unsharing:

$ gcc -O2 -S -flto -shared -fPIC /src/gcc/master/gcc/testsuite/gcc.dg/pr88701.c
during IPA pass: modref
/src/gcc/master/gcc/testsuite/gcc.dg/pr88701.c:18:1: internal compiler error:
tree code ‘bind_expr’ is not supported in LTO streams

The unsharing also doesn't remove the ICE in pr97298.  The SSA_NAME is replaced
by a STATEMENT_LIST:

$ gcc -O2 -S -flto -shared -fPIC
/src/gcc/master/gcc/testsuite/gcc.dg/atomic/pr65345-4.c
during IPA pass: modref
/src/gcc/master/gcc/testsuite/gcc.dg/atomic/pr65345-4.c:58:1: internal compiler
error: tree code ‘statement_list’ is not supported in LTO streams

[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases

[abebeos at lazaridis dot com via Gcc-bugs]

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

--- Comment #27 from abebeos at lazaridis dot com ---
The "contrib/compare_tests" created a wrong delta.

"contrib/dg-cmp-results.sh seems to produce a more concise delta, and it shows
that...

==> ...we are down to essentially 6 issues:

PASS->FAIL: c-c++-common/zero-scratch-regs-10.c  -Wc++-compat  (test for excess
errors)
[...] (similar failure category)
NA->FAIL: gcc.dg/pr83480.c (internal compiler error)
PASS->FAIL: gcc.dg/pr83480.c (test for excess errors)
FAIL->PASS: gcc.dg/tree-ssa/pr92085-2.c (test for excess errors)
PASS->FAIL: gcc.target/avr/pr88253.c scan-assembler lds r\\d+,121
NA->FAIL: gcc.target/avr/torture/builtins-2-flash.c   -O1  (internal compiler
error)
[...] (similar failure category)

If i did not something very wrong with my testing, this means that those
failures should be nearly non-relevant (>100K tests pass).

I'll file tomorrow the remaining 5 issues with error-info here:

https://github.com/abebeos/avr-gnu/issues

[Bug c/98070] errno is not re-evaluated after clearing errno and calling realloc(ptr, SIZE_MAX)

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=88576

--- Comment #1 from Andrew Pinski  ---
Related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88576 .

[Bug libstdc++/98003] FAIL: 27_io/basic_syncbuf/sync_ops/1.cc (test for excess errors)

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
Thought it might be that, thanks.

[Bug libstdc++/98003] FAIL: 27_io/basic_syncbuf/sync_ops/1.cc (test for excess errors)

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

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

--- Comment #1 from John David Anglin  ---
spawn /test/gnu/gcc/objdir/./gcc/xg++ -shared-libgcc
-B/test/gnu/gcc/objdir/./gc
c -nostdinc++ -L/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/src
-L/tes
t/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/src/.libs
-L/test/gnu/gcc/objd
ir/hppa64-hp-hpux11.11/libstdc++-v3/libsupc++/.libs
-B/opt/gnu64/gcc/gcc-11/hppa
64-hp-hpux11.11/bin/ -B/opt/gnu64/gcc/gcc-11/hppa64-hp-hpux11.11/lib/ -isystem
/
opt/gnu64/gcc/gcc-11/hppa64-hp-hpux11.11/include -isystem
/opt/gnu64/gcc/gcc-11/
hppa64-hp-hpux11.11/sys-include -fchecking=1
-B/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libstdc++-v3/src/.libs
-fmessage-length=0 -fno-show-column -ffunction-sections -fdata-sections -g -O2
-DLOCALEDIR="." -nostdinc++
-I/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/hppa64-hp-hpux11.11
-I/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include
-I/test/gnu/gcc/gcc/libstdc++-v3/libsupc++
-I/test/gnu/gcc/gcc/libstdc++-v3/include/backward
-I/test/gnu/gcc/gcc/libstdc++-v3/testsuite/util
/test/gnu/gcc/gcc/libstdc++-v3/testsuite/27_io/basic_syncbuf/sync_ops/1.cc
-std=gnu++2a -pthread -fdiagnostics-plain-output ./libtestc++.a
-L/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/src/filesystem/.libs
-lm -o ./1.exe
ld: Unsatisfied symbol "__atomic_fetch_add_4" in file /var/tmp//ccnLRNCV.o
1 errors.
collect2: error: ld returned 1 exit status

It seems we need to link against libatomic.

[Bug middle-end/98055] __builtin_alloca should not have warn_unused_result attribute

[psmith at gnu dot org via Gcc-bugs]

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

--- Comment #5 from Paul Smith  ---
IMO that response is missing the point.  This bug should be reopened and
resolved by removing this attribute from the __builtin_alloca function in GCC. 
That's all that's needed: there's no need for more complexity.

First, there's no need to add this attribute to alloca(): it's has virtually no
useful effect.  The chance that it actually catches a noticeable bug is almost
nil; any incorrect result that was more severe than reserving more stack than
was strictly necessary (actually failing to assign to a variable where it was
needed) would be obvious.

Second, alloca() is not just GCC's __builtin_alloca().  There are other
implementations, that behave differently than __builtin_alloca() and in those
implementations calling alloca() without using the return value is a valid and
useful thing to do.  I agree that it should not be up to GCC to try to suggest
portability options and am not suggesting it should do that.  However by adding
this attribute GCC is actively and affirmatively working _AGAINST_ portability.

The GCC docs say:

> warn_unused_result
> The warn_unused_result attribute causes a warning to be emitted if a caller
> of the function with this attribute does not use its return value. This is
> useful for functions where not checking the result is either a security
> problem or always a bug, such as realloc.

Using alloca() without checking the result is not a security problem, and it is
not always a bug as I've explained.  If it were the case that a commonly-used
malloc() replacement required calling malloc(0) (and not using the return
value) periodically for proper functioning, then absolutely GCC should clearly
not emit a warning for that usage even though GCC's malloc() doesn't work that
way, because otherwise it's hard to write code that doesn't depend on a
particular compiler.

Put more simply, I have this code in my program:

alloca (0);

I need that line there so things work properly on compilers that don't provide
alloca().

How do you suggest I compile with GCC without either (a) forgoing this warning
everywhere or (b) adding a lot of pragma boilerplate to allow me to disable the
warning for this line or (c) creating a hack such as:

{ void *__p = alloca (0); (void) __p; }

Is there some preprocessor magic that lets me know that I'm using GCC's
__builtin_alloc so I can avoid calling alloca(0) in that situation?  I can't
think of one myself.

[Bug fortran/96983] [11 regression] ICE compiling gfortran.dg/pr96711.f90 starting with r11-3042

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

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

--- Comment #29 from seurer at gcc dot gnu.org ---
Still showing up on powerpc64.

[Bug fortran/98023] ICE: free_expr0(): Bad expr type

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

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

--- Comment #3 from anlauf at gcc dot gnu.org ---
The patch in comment#1 does not work for me on x86_64-pc-linux-gnu.

In decl.c:

6242cleanup:
6243  if (saved_kind_expr)
6244gfc_free_expr (saved_kind_expr);
6245  if (type_param_spec_list)
6246gfc_free_actual_arglist (type_param_spec_list);

(gdb) p type_param_spec_list->expr->expr_type
$177 = 42350080

So type_param_spec_list really gets screwed up.

[Bug analyzer/97090] gcc.dg/analyzer/malloc-vs-local-1b.c fails on arm and powerpc64*-linux-gnu

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

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

--- Comment #9 from seurer at gcc dot gnu.org ---
I saw

FAIL: gcc.dg/analyzer/malloc-vs-local-1b.c  (test for bogus messages, line 170)

on a make check for 66dde7bc64b75d4a338266333c9c490b12d49825, r11-5583 just
moments ago on a powerpc64 BE box.

I reran just that test and it failed 3 times in a row.

Looking back at the logs on this machine it's failed on and off since r11-4323
(run on 23 October).

[Bug c/97172] [11 Regression] ICE: tree code ‘ssa_name’ is not supported in LTO streams since r11-3303-g6450f07388f9fe57

[hubicka at ucw dot cz via Gcc-bugs]

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

--- Comment #15 from Jan Hubicka  ---
> I'm not sure I understand correctly what you mean by "avoiding the attribute
> for VLA types would likely also be good (are those handled in any reasonable
> way?)"  As I explain in the thread at the link above, the attribute is 
> strictly
> only strictly necessary for the most significant bound of a VLA parameter.  
> The
> other bounds are encoded in the type and so don't also need to be duplicated 
> in
> the attribute (it's just more convenient/faster that way).  But even with that
> change,  and with the unsharing (or with the SAVE_EXPR around it), I'd expect
> the most significant bound to still be a problem for the streamer since it 
> will
> still contain the unsupported nodes.  Not SSA_NAMEs but some of the others.

What kind of other nodes you see?  Basically everything that makes sense
out of the function body can be streamed.  You can not refer also to
local scopes of the function, ipa-prop has unshare_expr_without_location

[Bug go/98041] [11 Regression] libgo doesn't build on mipsel-linux-gnu

[ian at airs dot com via Gcc-bugs]

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

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #2 from Ian Lance Taylor  ---
Fixed on trunk.

[Bug go/98041] [11 Regression] libgo doesn't build on mipsel-linux-gnu

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

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Ian Lance Taylor :

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

commit r11-5591-geafb46ce90c23efd22c61d941face060bb9f11f3
Author: Ian Lance Taylor 
Date:   Sat Nov 28 11:29:25 2020 -0800

internal/cpu: don't define CacheLinePadSize for mips64x

For libgo the definition comes from the generated file cpugen.go.

Fixes PR go/98041

Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/273866

[Bug c++/86769] g++ destroys condition variable in for statement too early

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #4 from Marek Polacek  ---
Unfinished/untested patch:

commit f873acfa7ed1956a58d02cc383b8d709c446f656 (HEAD -> PR86769)
Author: Marek Polacek 
Date:   Fri Nov 20 16:40:50 2020 -0500

c++: Condition in for statement destroyed too early [PR86769]

diff --git a/gcc/c-family/c-gimplify.c b/gcc/c-family/c-gimplify.c
index a7c0ec3be0d..f0a19456715 100644
--- a/gcc/c-family/c-gimplify.c
+++ b/gcc/c-family/c-gimplify.c
@@ -205,6 +205,30 @@ expr_loc_or_loc (const_tree expr, location_t or_loc)
   return loc;
 }

+/* TODO */
+
+static bool
+maybe_inject_incr_to_body (tree body, tree incr)
+{
+  if (TREE_CODE (body) == BIND_EXPR)
+body = BIND_EXPR_BODY (body);
+  if (TREE_CODE (body) == STATEMENT_LIST)
+{
+  tree_stmt_iterator i = tsi_last (body);
+  tree t = tsi_stmt (i);
+  if (TREE_CODE (t) == TRY_FINALLY_EXPR)
+   {
+ if (TREE_CODE (TREE_OPERAND (t, 0)) == STATEMENT_LIST)
+   {
+ i = tsi_last (TREE_OPERAND (t, 0));
+ tsi_link_after (, incr, TSI_CONTINUE_LINKING);
+ return true;
+   }
+   }
+}
+  return false;
+}
+
 /* Build a generic representation of one of the C loop forms.  COND is the
loop condition or NULL_TREE.  BODY is the (possibly compound) statement
controlled by the loop.  INCR is the increment expression of a for-loop,
@@ -291,6 +315,9 @@ genericize_c_loop (tree *stmt_p, location_t start_locus,
tree cond, tree body,
   append_to_statement_list (top, _list);
 }

+  if (maybe_inject_incr_to_body (body, incr))
+incr = NULL_TREE;
+
   append_to_statement_list (body, _list);
   finish_bc_block (_list, bc_continue, clab);
   if (incr)

[Bug c++/97187] [11 Regression] ICE: tree check: expected tree_list, have error_mark in tsubst_copy_and_build, at cp/pt.c:19782

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

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug c++/97993] [11 Regression] ICE tree check: expected tree_list, have error_mark in tsubst_copy_and_build, at cp/pt.c:19834 since r11-423-gcda6396a1b6e6bba

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

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug libstdc++/98034] std::atomic_signed_lock_free and std::atomic_unsigned_lock_free not defined

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

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

Thomas Rodgers  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-11-30

[Bug c++/98071] no_unique_address and reusing tail padding

[barry.revzin at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Barry Revzin  ---
On further discussion, since the ABI disallows reusing the tail padding of
PODs, sizeof(B) cannot be 8. This is more likely a clang bug.

[Bug c++/80780] Front-end support needed for experimental::source_location

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

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

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

Full untested patch.

[Bug c++/97993] [11 Regression] ICE tree check: expected tree_list, have error_mark in tsubst_copy_and_build, at cp/pt.c:19834 since r11-423-gcda6396a1b6e6bba

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

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

Marek Polacek  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=97187
 CC||mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
Probably a dup of bug 97187.

[Bug c++/98071] New: no_unique_address and reusing tail padding

[barry.revzin at gmail dot com via Gcc-bugs]

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

Bug ID: 98071
   Summary: no_unique_address and reusing tail padding
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: barry.revzin at gmail dot com
  Target Milestone: ---

Simple example:

struct A {
int x;
char y;
};

template 
struct B {
[[no_unique_address]] T t;
bool u;
};

static_assert(sizeof(B) == sizeof(A));

The data member "t" is potentially-overlapping, and its three bytes of padding
could be used to fit the "u" member. But gcc doesn't do this at the moment, and
so sizeof(B) is 12. On clang, sizeof(B) is 8, as desired.

[Bug c++/97966] [10/11 Regression] maybe_instantiate_noexcept

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

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

--- Comment #3 from Marek Polacek  ---
Reduced (but invalid?):

// PR c++/97966

template 
struct S {
  __attribute__((used)) S() noexcept(noexcept(this->foo()));
  void foo();
};

void
g ()
{
  S<1> s;
}

[Bug c++/97966] [10/11 Regression] maybe_instantiate_noexcept

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

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

Marek Polacek  changed:

   What|Removed |Added

   Last reconfirmed||2020-11-30
 Ever confirmed|0   |1
   Target Milestone|--- |10.3
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
Summary|maybe_instantiate_noexcept  |[10/11 Regression]
   ||maybe_instantiate_noexcept
 Status|UNCONFIRMED |ASSIGNED
 CC||mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
Started with r272586 so mine.

[Bug c++/84655] internal compiler error: unexpected expression 'a' of kind template_parm_index

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

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

Marek Polacek  changed:

   What|Removed |Added

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

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

[Bug c++/80780] Front-end support needed for experimental::source_location

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

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

--- Comment #10 from Jonathan Wakely  ---
The values of __builtin_LINE and __builtin_FUNCTION do the right thing for
NSDMIs, but I don't know what they do to make that work. 

(In reply to Jakub Jelinek from comment #9)
> If there is a user defined ctor, I guess the nsdmis in that ctor should get
> one of the locations of the ctor (but which one),

Any location is valid. The closing paren of the ctor parameter list would be
OK, since that's guaranteed to be present for all ctors, even =default ones.

> what about if there is no
> user defined ctor and the compiler synthetizes it?  What location should
> that have?

Warnings and debuginfo for such ctors tend to point to the "class S" or "struct
S" class-head. Another option would be the line with the NSDMI itself.

[Bug c++/97962] ICE in build_over_call, at cp/call.c:8976

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=95675

--- Comment #3 from Marek Polacek  ---
A dup of 95675 most likely, which has a much better test.

[Bug c++/80780] Front-end support needed for experimental::source_location

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

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

--- Comment #9 from Jakub Jelinek  ---
Created attachment 49653
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49653=edit
gcc11-pr80780-wip.patch

For the default argument, my current ugly hack is attached.
But guess it needs to be done similarly when parsing_nsdmi () and then at some
point (and I have no idea where exactly) call the same function, somewhere
after break_out_target_exprs is called on the nsdmi.
If there is a user defined ctor, I guess the nsdmis in that ctor should get one
of the locations of the ctor (but which one), what about if there is no user
defined ctor and the compiler synthetizes it?  What location should that have?
And, I'm not sure I understood where it would get something from aggregate
initialization.

So something like:
struct S
{
  source_location a = source_location::current_location ();
  source_location b = source_location::current_location ();
  S () {}
};

struct T
{
  int t;
  source_location u = source_location::current_location ();
};

?

[Bug c++/80780] Front-end support needed for experimental::source_location

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

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

--- Comment #8 from Jonathan Wakely  ---
The default argument case is:

source_location f(source_location a = source_location::current()) {
  return a;
}

int main()
{
  auto loc = f(); // f's first argument corresponds to this line of code
  VERIFY( loc.line() == 8 ); // where line 8 is the line above
  VERIFY( loc.column() == 16 ); // assuming you use the closing paren of f()
  VERIFY( !__builtin_strcmp(loc.file_name(),__FILE__) );
  VERIFY( !__builtin_strcmp(loc.function_name(), __FUNCTION__) );
}

[Bug c/97172] [11 Regression] ICE: tree code ‘ssa_name’ is not supported in LTO streams since r11-3303-g6450f07388f9fe57

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

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

--- Comment #14 from Martin Sebor  ---
I submitted a simple patch to do the unsharing as the first step toward fixing
this bug here:
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559770.html

I'm not sure I understand correctly what you mean by "avoiding the attribute
for VLA types would likely also be good (are those handled in any reasonable
way?)"  As I explain in the thread at the link above, the attribute is strictly
only strictly necessary for the most significant bound of a VLA parameter.  The
other bounds are encoded in the type and so don't also need to be duplicated in
the attribute (it's just more convenient/faster that way).  But even with that
change,  and with the unsharing (or with the SAVE_EXPR around it), I'd expect
the most significant bound to still be a problem for the streamer since it will
still contain the unsupported nodes.  Not SSA_NAMEs but some of the others.

[Bug c++/97995] [8/9/10/11 Regression] ICE tree check: expected tree that contains 'typed' structure, have 'deferred_noexcept' in unify, at cp/pt.c:23473 since r7-4383-g51dc660315ef83dc

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #3 from Marek Polacek  ---
This also ICEs, but in a different spot:

struct S;
template  void foo () noexcept (T::v);
template 
void bar (void (A...) noexcept (1));
static_assert (bar (foo));

[Bug rtl-optimization/98037] ICE in dse.c:find_shift_sequence for large non-integer modes

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

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

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

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

commit r11-5580-gf835e9f6562dda9c8a1384be2c9d4e45c112ed8e
Author: Richard Sandiford 
Date:   Mon Nov 30 17:15:47 2020 +

dse: Cope with bigger-than-integer modes [PR98037]

dse.c:find_shift_sequence tries to represent a store and load
back as a shift right followed by a truncation.  It therefore
needs to find an integer mode in which to do the shift right.
The loop it uses has the form:

  FOR_EACH_MODE_FROM (new_mode_iter,
  smallest_int_mode_for_size (GET_MODE_BITSIZE
(read_mode)))

which implicitly assumes that read_mode has an equivalent integer mode.
As shown in the testcase, not all modes have such an integer mode.

This patch just makes the code start from the smallest integer mode and
skip modes that are too small.  The loop already breaks at the first
mode wider than word_mode.

gcc/
PR rtl-optimization/98037
* dse.c (find_shift_sequence): Iterate over all integers and
skip modes that are too small.

gcc/testsuite/
PR rtl-optimization/98037
* gcc.target/aarch64/sve/acle/general/pr98037.c: New test.

[Bug c++/80780] Front-end support needed for experimental::source_location

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

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

--- Comment #7 from Jonathan Wakely  ---
Oh great, thanks :-)

I might push my implementation of std::source_location, with some tests
commented out for now.

[Bug middle-end/19987] [meta-bug] fold missing optimizations in general

[law at redhat dot com via Gcc-bugs]

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

Bug 96679 Summary: Failure to optimize or+and+or pattern to and+or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96679

   What|Removed |Added

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

[Bug tree-optimization/96679] Failure to optimize or+and+or pattern to and+or

[law at redhat dot com via Gcc-bugs]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com
 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #2 from Jeffrey A. Law  ---
Should be fixed with Eugene's patch on the trunk.

[Bug tree-optimization/96679] Failure to optimize or+and+or pattern to and+or

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

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Jeff Law :

https://gcc.gnu.org/g:28a7fdd81e857057f18f87a3c9dd180ad99b77f6

commit r11-5579-g28a7fdd81e857057f18f87a3c9dd180ad99b77f6
Author: Eugene Rozenfeld 
Date:   Mon Nov 30 09:48:58 2020 -0700

Optimize or+and+or pattern to and+or

gcc/
PR tree-optimization/96679
* match.pd (((b | c) & a) | b -> (a & c) | b): New pattern.

[Bug c/98070] New: errno is not re-evaluated after clearing errno and calling realloc(ptr, SIZE_MAX)

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

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

Bug ID: 98070
   Summary: errno is not re-evaluated after clearing errno and
calling realloc(ptr, SIZE_MAX)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: stli at linux dot ibm.com
  Target Milestone: ---

Created attachment 49652
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49652=edit
Testcase reproducing the issue with gcc-head

Hi,

After setting errno=0 and calling realloc with a too large size, which sets
errno to ENOMEM, a subsequent "if (errno == ENOMEM)" is not evaluated as true.
Instead gcc assumes that errno has not changed and is directly executing the
else-path without testing errno again.

This happens in the glibc-testcase:
/malloc/tst-malloc-too-large.c test
(see
https://sourceware.org/git/?p=glibc.git;a=blob;f=malloc/tst-malloc-too-large.c;h=b5ad7eb7e7bf764fe57ceff5a810e3c211ca05e0;hb=refs/heads/master)
on at least x86_64 and s390x with gcc-head.

The attached small reproducer fails with gcc-head, but not with gcc 10, 9
(before):
/* Output with gcc 11:
   $ ./tst-errno-realloc (build with >= -O1)
   47: errno == 0 (Cannot allocate memory). We are in the else-part of 'if
(errno == ENOMEM)'. Does errno correspond to %m or the line below or to '(gdb)
p errno'?!
   dump_errno(48, compare to line above!): errno == 12 (Cannot allocate memory)
vs main_errno=0

   On s390x:
   $ gcc -v
   Using built-in specs.
   COLLECT_GCC=./install-s390x-head/bin/gcc
  
COLLECT_LTO_WRAPPER=/home/stli/gccDir/install-s390x-head/libexec/gcc/s390x-ibm-linux-gnu/11.0.0/lto-wrapper
   Target: s390x-ibm-linux-gnu
   Configured with: /home/stli/gccDir/gcc-head/configure
--prefix=/home/stli/gccDir/install-s390x-head/ --enable-shared
--with-system-zlib --enable-threads=posix --enable-__cxa_atexit
--enable-checking --enable-gnu-indirect-function --enable-languages=c,c++
--with-arch=zEC12 --with-tune=z13 --disable-bootstrap --with-long-double-128
--enable-decimal-float
   Thread model: posix
   Supported LTO compression algorithms: zlib
   gcc version 11.0.0 20201127 (experimental) (GCC)
   $ git log --oneline
   5e9f814d754 (HEAD -> master, origin/master, origin/HEAD) rs6000: Change
rs6000_expand_vector_set param

   Also on x86_64:
   $ gcc -v
   Using built-in specs.
   COLLECT_GCC=/home/stli/gccDir/install-x86_64-head/bin/gcc
  
COLLECT_LTO_WRAPPER=/home/stli/gccDir/install-x86_64-head/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper
   Target: x86_64-pc-linux-gnu
   Configured with: /home/stli/gccDir/gcc-head/configure
--prefix=/home/stli/gccDir/install-x86_64-head/ --enable-shared
--with-system-zlib --enable-threads=posix --enable-__cxa_atexit
--enable-checking --enable-gnu-indirect-function --enable-languages=c,c++
--with-tune=generic --with-arch_32=x86-64 --disable-bootstrap
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id --with-linker-hash-style=gnu --enable-plugin
--enable-initfini-array --disable-libgcj --disable-multilib
   Thread model: posix
   Supported LTO compression algorithms: zlib zstd
   gcc version 11.0.0 20201130 (experimental) (GCC)
   $ git log --oneline
   a5ad5d5c478 (HEAD -> master, origin/master, origin/HEAD) RISC-V: Always
define MULTILIB_DEFAULTS
*/

[Bug tree-optimization/98069] [8/9/10/11 Regression] Miscompilation with -O3 since r8-2380-g2d7744d4ef93bfff

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

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

Martin Liška  changed:

   What|Removed |Added

  Known to work||7.4.0
  Known to fail||10.2.0, 11.0, 8.4.0, 9.3.0
   Target Milestone|--- |8.5

[Bug tree-optimization/98069] [8/9/10/11 Regression] Miscompilation with -O3 since r8-2380-g2d7744d4ef93bfff

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

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

Martin Liška  changed:

   What|Removed |Added

Summary|Miscompilation with -O3 |[8/9/10/11 Regression]
   ||Miscompilation with -O3
   ||since
   ||r8-2380-g2d7744d4ef93bfff
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
 CC||marxin at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
   Last reconfirmed||2020-11-30

--- Comment #1 from Martin Liška  ---
Started with r8-2380-g2d7744d4ef93bfff.

[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases

[abebeos at lazaridis dot com via Gcc-bugs]

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

--- Comment #26 from abebeos at lazaridis dot com ---
(In reply to Richard Biener from comment #24)
> Amending / adjusting
> https://gcc.gnu.org/wiki/Building_Cross_Toolchains_with_gcc
> (the only place that somewhat "documents" how to setup AVR testing) is
> appreciated.

You'll find some instructions in https://github.com/abebeos/avr-gnu (should be
within the next days).

[Bug c++/80780] Front-end support needed for experimental::source_location

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

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

--- Comment #6 from Jakub Jelinek  ---
I'm aware of
https://github.com/cplusplus/draft/pull/3749/commits/ade9b1552eed5b1b0b3fc2808e6575ee6b526301
and am working on that today incidentally.

[Bug c++/80780] Front-end support needed for experimental::source_location

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #5 from Jonathan Wakely  ---
r278949 added _builtin_source_location but it doesn't do the right thing for
thing for constructors:

#include 

namespace std {
  struct source_location {
struct __impl {
  const char *_M_file_name;
  const char *_M_function_name;
  unsigned int _M_line, _M_column;
};
const __impl *__ptr;
constexpr source_location () : __ptr (nullptr) {}
static consteval source_location
current (const void *__p = __builtin_source_location ()) {
  source_location __ret;
  __ret.__ptr = static_cast  (__p);
  return __ret;
}
constexpr const char *file_name () const {
  return __ptr ? __ptr->_M_file_name : "";
}
constexpr const char *function_name () const {
  return __ptr ? __ptr->_M_function_name : "";
}
constexpr unsigned line () const {
  return __ptr ? __ptr->_M_line : 0;
}
constexpr unsigned column () const {
  return __ptr ? __ptr->_M_column : 0;
}
  };
}

using namespace std;

struct S {
  const char* func;
  source_location loc = source_location::current();

  S(source_location loc = source_location::current())
  : func(__FUNCTION__), loc(loc) // values of loc will be from call-site
  {}

  S(int)
  : func(__FUNCTION__) // values of loc should be hereabouts
  {}
};

int main()
{
  S s0;
  assert( s0.loc.line() == 48 );
  assert( !__builtin_strcmp(s0.loc.file_name(), __FILE__) );
  assert( !__builtin_strcmp(s0.loc.function_name(), __FUNCTION__) );

  S s1(1);
  assert( s1.loc.line() == 42 );
  assert( !__builtin_strcmp(s1.loc.file_name(), __FILE__) );
  assert( !__builtin_strcmp(s1.loc.function_name(), s1.func) );
}

[Bug target/98060] Failure to optimize cmp+setnb+add to cmp+sbb

[ubizjak at gmail dot com via Gcc-bugs]

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

Uroš Bizjak  changed:

   What|Removed |Added

   Severity|normal  |enhancement
   Last reconfirmed||2020-11-30
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from Uroš Bizjak  ---
There are several other cases where sbb/adc can be used:

--cut here--
int r1 (unsigned v0, unsigned v1, int v2)
{
return (v0 >= v1) + v2;
}

int r2 (unsigned v0, unsigned v1, int v2)
{
return (v1 > v0) + v2;
}

int r3 (unsigned v0, unsigned v1, int v2)
{
return (v0 <= v1) + v2;
}

int r4 (unsigned v0, unsigned v1, int v2)
{
return (v1 < v0) + v2;
}
--cut here--

r1 and r3 can be implemented with sbb $-1, reg, r2 and r4 with adc $0, reg.

gcc currently converts only r4.

[Bug d/98067] [11 Regression] d: ICE in in force_decl_die, at dwarf2out.c:26197 with -gdwarf-2 -gstrict-dwarf

[ibuclaw at gdcproject dot org via Gcc-bugs]

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

--- Comment #8 from Iain Buclaw  ---
As a last resort I could just not emit D manifest constants as CONST_DECLs. 
They are a nice-to-have from the debugger, but functionally equivalent to C
macros.

[Bug c/97172] [11 Regression] ICE: tree code ‘ssa_name’ is not supported in LTO streams since r11-3303-g6450f07388f9fe57

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

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

Martin Sebor  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com

--- Comment #13 from Martin Sebor  ---
*** Bug 98068 has been marked as a duplicate of this bug. ***

[Bug lto/98068] [11 Regression] FAIL: gcc.dg/atomic/pr65345-4.c -O2 -flto -fno-use-linker-plugin -flto-partition=none (internal compiler error) by r11-3303

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

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Sebor  ---
Yes, pr97172 is tracking the underlying problem.

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

[Bug target/89057] [8/9/10/11 Regression] AArch64 ld3 st4 less optimized

[abhiraj.garakapati at gmail dot com via Gcc-bugs]

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

Abhiraj Garakapati  changed:

   What|Removed |Added

 CC||abhiraj.garakapati at gmail 
dot co
   ||m

--- Comment #7 from Abhiraj Garakapati  ---
This issue is observed during the RTL phase (test1.cpp.234r.expand i.e, during
Gimple to RTL conversion.) with -O1 flag enabled. (This issue is seen in -O1,
-O2, -O3 not in -O0.)

All these below 3 Gimple instructions are converted to 2 move instructions each
during Gimple to RTL conversion. This scenario is not seen in GCC-7.3.0 only
seen from GCC-8.1.0 due to the patch:
https://gcc.gnu.org/git/?p=gcc.git;a=patch;h=a977dc0c5e069bf198f78ed4767deac369904301
  _68 = __builtin_aarch64_combinev8qi (_67, { 0, 0, 0, 0, 0, 0, 0, 0 });
  _69 = __builtin_aarch64_combinev8qi (_66, { 0, 0, 0, 0, 0, 0, 0, 0 });
  _70 = __builtin_aarch64_combinev8qi (_65, { 0, 0, 0, 0, 0, 0, 0, 0 });

This issue can be fixed by adding "-fno-move-loop-invariants" (as a
workaround).

This issue can be fixed on GCC-8.1.0 by reverting "aarch64-simd.md" file
changes in the patch:
https://gcc.gnu.org/git/?p=gcc.git;a=patch;h=a977dc0c5e069bf198f78ed4767deac369904301

Also, cross-checked the newly built toolchain with reverting "aarch64-simd.md"
file changes with the above-mentioned test case and got the expected output
same as GCC-7.3.0.

With gcc 8.1 with reverting "aarch64-simd.md" file changes the inner loop is:
.L5:
ld3 {v4.8b-v6.8b}, [x1]
add x1, x1, #0x18
mov v0.8b, v6.8b
mov v1.8b, v5.8b
mov v2.8b, v4.8b
mov v3.16b, v7.16b
st4 {v0.8b-v3.8b}, [x0]
add x0, x0, 32
cmp x3, x0
bhi .L5

Also, cross-checked it with the below test case (which is mentioned in patch:
https://gcc.gnu.org/git/?p=gcc.git;a=patch;h=a977dc0c5e069bf198f78ed4767deac369904301
this patch improves code generation for literal vector construction by
expanding and exposing the pattern to RTL optimization earlier. The current
implementation delays splitting the pattern until after reload which results in
poor code generation for the following code)

Test case to show patch
improvement(https://gcc.gnu.org/git/?p=gcc.git;a=patch;h=a977dc0c5e069bf198f78ed4767deac369904301
):

#include "arm_neon.h"
int16x8_t
foo ()
{
  return vcombine_s16 (vdup_n_s16 (0), vdup_n_s16 (8));
}

GCC_8.1.0 -O1 with reverting "aarch64-simd.md" file changes:

foo():
adrpx0, 0 <_Z3foov>
ldr q0, [x0]
ret

So, reverting the "aarch64-simd.md" file changes does not result in poor code
generation.
Also, cross-checked it with the latest GCC version GCC-10.2.0.

[Bug tree-optimization/98069] New: Miscompilation with -O3

[vsevolod.livinskij at frtk dot ru via Gcc-bugs]

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

Bug ID: 98069
   Summary: Miscompilation with -O3
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vsevolod.livinskij at frtk dot ru
  Target Milestone: ---

Reproducer:
//func.cpp
extern long long var_3;
extern short var_8;
extern int var_17;
extern short arr_165[];
long c(long e, long f) { return f ? e : f; }
void test() {
for (int b = 0; b < 19; b = var_17)
for (int d = int(~c(-2147483647 - 1, var_3)) - 2147483647; d < 22; d++)
arr_165[d] = var_8;
}

//driver.cpp 
#include 

long long int var_3 = -166416893043554447LL;
short var_8 = (short)27092;
unsigned int var_17 = 75036300U;
short arr_165[23];

void test();

int main() {
for (size_t i_3 = 0; i_3 < 23; ++i_3)
arr_165[i_3] = (short)-8885;
test();
printf("%d\n", arr_165[0]);
}

>$ g++ -O3 func.cpp driver.cpp && ./a.out
Segmentation fault (core dumped)
>$ g++ -O2 func.cpp driver.cpp && ./a.out
27092

gcc version 11.0.0 20201126 (beb9afcaf1466996a301c778596c5df209e7913c)

[Bug c/97172] [11 Regression] ICE: tree code ‘ssa_name’ is not supported in LTO streams since r11-3303-g6450f07388f9fe57

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

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

--- Comment #12 from Richard Biener  ---
unsharing the tree is correct AFAICS, avoiding the attribute for VLA types
would likely also be good (are those handled in any reasonable way?).  Note
nothing will update those SSA names so they should not creep in there in the
first place (and do so from gimplifying).

[Bug fortran/98011] [OpenACC] 'gcc/fortran/scanner.c:load_line' should consider 'flag_openacc' in addition to 'flag_openmp' (and vice versa?)?

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

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

Tobias Burnus  changed:

   What|Removed |Added

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

--- Comment #4 from Tobias Burnus  ---
Actually, the code in gcc/fortran/scanner.c load_line is fine. It does load too
much for OpenMP – but that only wastes memory.

The actual check for '!$omp' vs. '!$ ' is done in skip_free_comments and
skip_fixed_comments (which has to do some additional checking). And that check
works well.

However, as mentioned in comment 2, 'gfortran -fopenacc' did process OpenMP's
'!$ ' conditional-compilation sentinels (and OpenACC does not have its own
sentinels).

That issue has now been FIXED for mainline.

[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases

[abebeos at lazaridis dot com via Gcc-bugs]

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

--- Comment #25 from abebeos at lazaridis dot com ---
(In reply to John Paul Adrian Glaubitz from comment #22)
[...]
> > https://www.gnu.org/prep/maintain/html_node/Copyright-Papers.html

FSF has a fascinating way to make trivial things complicated. Largest-Scale
companies do such kind of legal stuff with one-click.

In any way, thank you for pointing to the official legal doc (I was looking for
in #comment17)

[Bug fortran/98010] [OpenACC] 'gcc/fortran/options.c:gfc_post_options' should consider 'flag_openacc' in addition to 'flag_openmp'?

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

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

Tobias Burnus  changed:

   What|Removed |Added

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

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

Now FIXED on mainline.

One could argue whether it should or shouldn't be backported as depending on
the use this may lead to wrong code. (Local array in static memory instead of
stack but used concurrently with different values.)

[Bug fortran/98013] [OpenACC] 'gcc/fortran/trans-decl.c:gfc_generate_function_code' should consider 'flag_openacc' in addition to 'flag_openmp'?

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

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

Tobias Burnus  changed:

   What|Removed |Added

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

--- Comment #2 from Tobias Burnus  ---
As mentioned in the patch submission, it is a bit unclear what to check for in
that corner case.

Now simplified to simply use effectively the same condition in both conditions.
(Actual use: 'if (recurcheckvar)'.)
→ https://gcc.gnu.org/pipermail/gcc-patches/2020-November/560454.html

FIXED on mainline.

Thanks for looking at the code.

[Bug fortran/98011] [OpenACC] 'gcc/fortran/scanner.c:load_line' should consider 'flag_openacc' in addition to 'flag_openmp' (and vice versa?)?

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Tobias Burnus :

https://gcc.gnu.org/g:1d6f6ac693a8601bef9fe4ba72eb6fbf7b60b5cd

commit r11-5572-g1d6f6ac693a8601bef9fe4ba72eb6fbf7b60b5cd
Author: Tobias Burnus 
Date:   Mon Nov 30 15:30:51 2020 +0100

Fortran: With OpenACC, ignore OpenMP's cond comp sentinels

gcc/fortran/ChangeLog:

PR fortran/98011
* scanner.c (skip_free_comments, skip_fixed_comments): If only
-fopenacc but not -fopenmp is used, ignore OpenMP's conditional
compilation sentinels. Fix indentation, use 'else if' for
readability.

gcc/testsuite/ChangeLog:

PR fortran/98011
* gfortran.dg/goacc/sentinel-free-form.f95:
* gfortran.dg/goacc-gomp/fixed-1.f: New test.
* gfortran.dg/goacc-gomp/free-1.f90: New test.
* gfortran.dg/goacc/fixed-5.f: New test.

[Bug jit/97867] [11 Regression] thunk_info::release breaks function calls in libgccjit

[hubicka at ucw dot cz via Gcc-bugs]

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

--- Comment #8 from Jan Hubicka  ---
> 
> FWIW, did you configure with --enable-host-shared ?  Forgetting to enable that
> is the usual source of weird errors when building libgccjit.

I think it does not let you to build it otherwise, but I believe I did.
I just need to find time to update my setup. It is really out of date.

BTW if you build with LTO, I think there should be no performance
penalty for building libbackend with -fpic since we take it away while
producing the final binary.  This may be relevant for those who build
distros (I suppose you do not want to ship main compilers with PIC build
for performance reasons).

Honza

[Bug fortran/98010] [OpenACC] 'gcc/fortran/options.c:gfc_post_options' should consider 'flag_openacc' in addition to 'flag_openmp'?

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Tobias Burnus :

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

commit r11-5571-gf4e7ea81d1369d4d6cb6d8e440aefb3407142e05
Author: Tobias Burnus 
Date:   Mon Nov 30 15:27:44 2020 +0100

Fortran: -fno-automatic and -fopenacc / recusion check cleanup

Options: -fopenmp and -fopenacc imply concurrent calls to a
procedure; now also -fopenacc implies -frecursive, disabling
that larger local const-size array variables use static memory.

Run-time recursion check: Always reset the check variable at the
end of the procedure; this avoids a bogus error with -fopenmp
when called twice nonconcurrently/nonrecursively. (Issue requires
using -fno-automatic or -fmax-stack-var-size= to trigger.)

gcc/fortran/ChangeLog:

PR fortran/98010
PR fortran/98013
* options.c (gfc_post_options): Also imply recursive with
-fopenacc.
* trans-decl.c (gfc_generate_function_code): Simplify condition.

[Bug fortran/98013] [OpenACC] 'gcc/fortran/trans-decl.c:gfc_generate_function_code' should consider 'flag_openacc' in addition to 'flag_openmp'?

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

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Tobias Burnus :

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

commit r11-5571-gf4e7ea81d1369d4d6cb6d8e440aefb3407142e05
Author: Tobias Burnus 
Date:   Mon Nov 30 15:27:44 2020 +0100

Fortran: -fno-automatic and -fopenacc / recusion check cleanup

Options: -fopenmp and -fopenacc imply concurrent calls to a
procedure; now also -fopenacc implies -frecursive, disabling
that larger local const-size array variables use static memory.

Run-time recursion check: Always reset the check variable at the
end of the procedure; this avoids a bogus error with -fopenmp
when called twice nonconcurrently/nonrecursively. (Issue requires
using -fno-automatic or -fmax-stack-var-size= to trigger.)

gcc/fortran/ChangeLog:

PR fortran/98010
PR fortran/98013
* options.c (gfc_post_options): Also imply recursive with
-fopenacc.
* trans-decl.c (gfc_generate_function_code): Simplify condition.

[Bug c++/98043] [8/9/10/11 Regression] ICE ‘verify_gimple’ failed since r5-3726-g083e891e69429f93b958f6c18e2d52f515bae572

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #3 from Marek Polacek  ---
Mine then.

[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases

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

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

--- Comment #24 from Richard Biener  ---
Amending / adjusting
https://gcc.gnu.org/wiki/Building_Cross_Toolchains_with_gcc
(the only place that somewhat "documents" how to setup AVR testing) is
appreciated.

[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases

[abebeos at lazaridis dot com via Gcc-bugs]

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

--- Comment #23 from abebeos at lazaridis dot com ---
(In reply to Senthil Kumar Selvaraj from comment #21)
> (https://github.com/saaadhu/gcc-avr-cc0/tree/avr-cc0-squashed)

I can still do a test-run, to see if it produces less fails than pip's one.
Though it seems pip's work "last 2%" should be manageable. But in any case,
having a 2nd solution-path (based on your work) is nice, as I really want to
avoid to start from scratch (after those weeks of mostly integration work).

> I don't have the spare time now to start full fledged work on this, but I
> can help with any issues you run into.

Very nice, I can isolate the errors like:

=> "sorry, unimplemented: '-fzero-call-used-regs' not supported on this target"

so you folks can take a look with minimum effort. I'll file issues within the
github repo when I cannot solve something myself.

[Bug d/98067] [11 Regression] d: ICE in in force_decl_die, at dwarf2out.c:26197 with -gdwarf-2 -gstrict-dwarf

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

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

--- Comment #7 from Jakub Jelinek  ---
(In reply to Richard Biener from comment #5)
> > Would it be correct to fallback on a lang_hooks.name comparison if
> > dwarf_version < 2?
> 
> I wonder if we can instead "delay" applying "strict dwarf" to the actual
> output of DW_AT_language.  I mean, with DWARF2 there should be no debug
> for D at all since you can't specify the source language ...

I think that would be quite problematic, because we earlier decide on the
abbreviation for it, consider it for sizes etc. and all that is from the exact
value, which could be different.
Using lang_hooks.name is problematic too, that would be GNU GIMPLE for lto...
Though maybe we don't need it during late dwarf at all.

[Bug lto/98068] [11 Regression] FAIL: gcc.dg/atomic/pr65345-4.c -O2 -flto -fno-use-linker-plugin -flto-partition=none (internal compiler error) by r11-3303

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

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

--- Comment #2 from Martin Liška  ---
I guess it's PR97172.

[Bug jit/97867] [11 Regression] thunk_info::release breaks function calls in libgccjit

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

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

David Malcolm  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org

--- Comment #7 from David Malcolm  ---
(In reply to Jan Hubicka from comment #6)
> Fixed sorry for taking so long

Thanks for fixing this.


(In reply to Jan Hubicka from comment #4)
> Sorry, I lost track of this, because i still hit the strange linker error
> with building libjit

FWIW, did you configure with --enable-host-shared ?  Forgetting to enable that
is the usual source of weird errors when building libgccjit.

[Bug libstdc++/98005] FAIL: std/ranges/adaptors/sizeof.cc (test for excess errors)

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

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

Patrick Palka  changed:

   What|Removed |Added

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

[Bug lto/98068] [11 Regression] FAIL: gcc.dg/atomic/pr65345-4.c -O2 -flto -fno-use-linker-plugin -flto-partition=none (internal compiler error) by r11-3303

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |11.0

--- Comment #1 from Richard Biener  ---
Thought we already have a bug about this.

[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #22 from John Paul Adrian Glaubitz  ---
(In reply to abebeos from comment #20)
> Testsuite comparison on local dev system looks quite good:
> 
> https://github.com/abebeos/avr-gnu/issues/1

Just as a heads-up: Please keep in mind that submitting patches requires a
proper attribution and copyright assignment, see:

> https://www.gnu.org/prep/maintain/html_node/Copyright-Papers.html

[Bug d/98067] [11 Regression] d: ICE in in force_decl_die, at dwarf2out.c:26197 with -gdwarf-2 -gstrict-dwarf

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

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

--- Comment #6 from Iain Sandoe  ---
although this was discovered on Darwin, I guess any platform supporting D could
be invoked with -gdwarf-2 and that ought not to ICE.

I suppose we could adjust configury to decline building D without DWARF >= 3
support.

( I plan to add some support for detecting this for Darwin, system versions
with LLDB and dsymutil from LLVM are capable of supporting DWARF-4 - and maybe
some earlier cases do support DWARF-3 .. )

[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases

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

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

Senthil Kumar Selvaraj  changed:

   What|Removed |Added

 CC||saaadhu at gcc dot gnu.org

--- Comment #21 from Senthil Kumar Selvaraj  ---
FWIW, I was working on this as well some time in August, and had a semi working
implementation going. Pip's implementation generated better code on the few
benchmark workloads I compared, so I shelved my work
(https://github.com/saaadhu/gcc-avr-cc0/tree/avr-cc0-squashed)

I don't have the spare time now to start full fledged work on this, but I can
help with any issues you run into.

[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases

[abebeos at lazaridis dot com via Gcc-bugs]

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

--- Comment #20 from abebeos at lazaridis dot com ---
Testsuite comparison on local dev system looks quite good:

https://github.com/abebeos/avr-gnu/issues/1

[Bug lto/98068] [11 Regression] FAIL: gcc.dg/atomic/pr65345-4.c -O2 -flto -fno-use-linker-plugin -flto-partition=none (internal compiler error) by r11-3303

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

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

Martin Liška  changed:

   What|Removed |Added

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

[Bug lto/98068] New: [11 Regression] FAIL: gcc.dg/atomic/pr65345-4.c -O2 -flto -fno-use-linker-plugin -flto-partition=none (internal compiler error) by r11-3303

[hjl.tools at gmail dot com via Gcc-bugs]

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

Bug ID: 98068
   Summary: [11 Regression] FAIL: gcc.dg/atomic/pr65345-4.c   -O2
-flto -fno-use-linker-plugin -flto-partition=none
(internal compiler error) by r11-3303
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: marxin at gcc dot gnu.org, msebor at gcc dot gnu.org
  Target Milestone: ---

On Linux/x86-64, r11-3303 caused:

FAIL: gcc.dg/atomic/pr65345-4.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  (internal compiler error)
FAIL: gcc.dg/atomic/pr65345-4.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  (test for excess errors)
FAIL: gcc.dg/atomic/pr65345-4.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  (internal compiler error)
FAIL: gcc.dg/atomic/pr65345-4.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  (test for excess errors)

[Bug tree-optimization/98064] ICE in check_loop_closed_ssa_def, at tree-ssa-loop-manip.c:726 with -O3 since r11-4921-g86cca5cc14602814

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/98064] ICE in check_loop_closed_ssa_def, at tree-ssa-loop-manip.c:726 with -O3 since r11-4921-g86cca5cc14602814

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

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

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

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

commit r11-5542-gebbe3f29518854c36574adbd4fa82fd56fa64056
Author: Richard Biener 
Date:   Mon Nov 30 13:39:59 2020 +0100

tree-optimization/98064 - fix BB SLP live lane extract wrt LC SSA

This avoids breaking LC SSA when SLP codegen pulled an out-of-loop
def into a loop when merging with in-loop defs for an external def.

2020-11-30  Richard Biener  

PR tree-optimization/98064
* tree-vect-loop.c (vectorizable_live_operation): Avoid
breaking LC SSA for BB vectorization.

* g++.dg/vect/pr98064.cc: New testcase.

[Bug c++/98043] [8/9/10/11 Regression] ICE ‘verify_gimple’ failed since r5-3726-g083e891e69429f93b958f6c18e2d52f515bae572

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org
Summary|[10/11 Regression] ICE  |[8/9/10/11 Regression] ICE
   |‘verify_gimple’ failed  |‘verify_gimple’ failed
   |since   |since
   |r10-5122-g6fcb7ebb377f27c7  |r5-3726-g083e891e69429f93b9
   ||58f6c18e2d52f515bae572

--- Comment #2 from Jakub Jelinek  ---
The ICE is much older is you remove the for the ICE unnecessary C++20
initializer of the bitfield.

enum class B { A };
struct C { B c : 8; };

bool
foo (C x)
{
  switch (x.c)
{
case B::A:
  return false;
default:
  return true;
}
}

[Bug pch/56549] #pragma once ineffective with BOM in include file

[jruffin at gmail dot com via Gcc-bugs]

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

--- Comment #7 from Julien Ruffin  ---
Here is the patch for the current master. I have tested it on large C++ code
bases. So far, it builds successfully and significantly faster.

diff --git a/libcpp/files.c b/libcpp/files.c
index 301b2379a23..cbc2b0f4540 100644
--- a/libcpp/files.c
+++ b/libcpp/files.c
@@ -1978,25 +1978,28 @@ _cpp_save_file_entries (cpp_reader *pfile, FILE *fp)
   result->entries[count].once_only = f->once_only;
   /* |= is avoided in the next line because of an HP C compiler bug */
   result->have_once_only = result->have_once_only | f->once_only;
+
   if (f->buffer_valid)
-   md5_buffer ((const char *)f->buffer,
-   f->st.st_size, result->entries[count].sum);
+{
+  md5_buffer ((const char *)f->buffer,
+  f->st.st_size, result->entries[count].sum);
+}
   else
-   {
- FILE *ff;
- int oldfd = f->fd;
-
- if (!open_file (f))
-   {
- open_file_failed (pfile, f, 0, 0);
- free (result);
- return false;
-   }
- ff = fdopen (f->fd, "rb");
- md5_stream (ff, result->entries[count].sum);
- fclose (ff);
- f->fd = oldfd;
-   }
+{
+  if (!read_file (pfile, f, 0))
+{
+  return false;
+}
+
+  md5_buffer ((const char *)f->buffer,
+  f->st.st_size, result->entries[count].sum);
+
+  const void* to_free = f->buffer_start;
+  f->buffer_start = NULL;
+  f->buffer = NULL;
+  f->buffer_valid = false;
+  free ((void*) to_free);
+}
   result->entries[count].size = f->st.st_size;
 }

[Bug tree-optimization/98048] [11 Regression] ICE in build_vector_from_val, at tree.c:1985 by r11-5429

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug target/98063] Emit R_X86_64_GOTOFF64 instead of R_X86_64_GOTPCRELX for -mcmodel=large -fno-plt

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug tree-optimization/98048] [11 Regression] ICE in build_vector_from_val, at tree.c:1985 by r11-5429

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

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

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

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

commit r11-5539-g4bcded23eb87c55a1a3fcd23d5629a0c35aee4ba
Author: Richard Biener 
Date:   Mon Nov 30 10:41:36 2020 +0100

tree-optimization/98048 - fix vector lowering of ABSU_EXPR

This makes sure to use the correct type for the LHS of the scalar
replacement statement.

20220-11-30  Richard Biener  

PR tree-optimization/98048
* tree-vect-generic.c (expand_vector_operations_1): Use the
correct type for the scalar LHS replacement.

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

[Bug ipa/98057] [11 Regression] ICE verify_cgraph_node failed since r11-4900-g4656461585bfd0b9

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

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

--- Comment #4 from Martin Liška  ---
I've got a patch candidate.

[Bug tree-optimization/98064] ICE in check_loop_closed_ssa_def, at tree-ssa-loop-manip.c:726 with -O3 since r11-4921-g86cca5cc14602814

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

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

--- Comment #3 from Richard Biener  ---
The issue is

t.C:11:24: note: extracting lane for live stmt _201 = (signed short) pretmp_25;

where the vectorized def of this out-of-loop definition is in-loop and thus
replacing its uses would require a LC-SSA def.

[Bug tree-optimization/98066] [11 Regression] ICE: Segmentation fault (in gsi_next)

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

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

Martin Liška  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/98066] [11 Regression] ICE: Segmentation fault (in gsi_next)

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

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

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

https://gcc.gnu.org/g:5877c544c18259e6f8a07ec99e22bbfe8c6d64a6

commit r11-5538-g5877c544c18259e6f8a07ec99e22bbfe8c6d64a6
Author: Martin Liska 
Date:   Mon Nov 30 11:10:28 2020 +0100

gimple ISEL: fix BB stmt iteration

gcc/ChangeLog:

PR tree-optimization/98066
* gimple-isel.cc (gimple_expand_vec_exprs): Return when
gimple_expand_vec_exprs replaces last stmt.

[Bug d/98067] [11 Regression] d: ICE in in force_decl_die, at dwarf2out.c:26197 with -gdwarf-2 -gstrict-dwarf

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

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

--- Comment #5 from Richard Biener  ---
(In reply to Iain Buclaw from comment #4)
> What fails is gen_decl_die()
> 
> ---
>  case CONST_DECL:
> ─> if (!is_fortran () && !is_ada () && !is_dlang ())
>  {
>/* The individual enumerators of an enum type get output when we
> output
>   the Dwarf representation of the relevant enum type itself.  */
>break;
>  }
> 
>/* Emit its type.  */
>gen_type_die (TREE_TYPE (decl), context_die);
> 
>/* And its containing namespace.  */
>context_die = declare_in_namespace (decl, context_die);
>  
>gen_const_die (decl, context_die);
>break;
> ---
> 
> Here, the condition `!is_dlang ()` returns true because DW_LANG_D does not
> exist in DWARFv2.
> 
> Would it be correct to fallback on a lang_hooks.name comparison if
> dwarf_version < 2?

I wonder if we can instead "delay" applying "strict dwarf" to the actual
output of DW_AT_language.  I mean, with DWARF2 there should be no debug
for D at all since you can't specify the source language ...

[Bug d/98067] [11 Regression] d: ICE in in force_decl_die, at dwarf2out.c:26197 with -gdwarf-2 -gstrict-dwarf

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |11.0

[Bug d/98067] [11 Regression] d: ICE in in force_decl_die, at dwarf2out.c:26197 with -gdwarf-2 -gstrict-dwarf

[ibuclaw at gdcproject dot org via Gcc-bugs]

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

--- Comment #4 from Iain Buclaw  ---
What fails is gen_decl_die()

---
 case CONST_DECL:
─> if (!is_fortran () && !is_ada () && !is_dlang ())
 {
   /* The individual enumerators of an enum type get output when we output
  the Dwarf representation of the relevant enum type itself.  */
   break;
 }

   /* Emit its type.  */
   gen_type_die (TREE_TYPE (decl), context_die);

   /* And its containing namespace.  */
   context_die = declare_in_namespace (decl, context_die);

   gen_const_die (decl, context_die);
   break;
---

Here, the condition `!is_dlang ()` returns true because DW_LANG_D does not
exist in DWARFv2.

Would it be correct to fallback on a lang_hooks.name comparison if
dwarf_version < 2?

[Bug c++/98054] [11 Regression] ICE: in pp_cxx_trait_expression, at cp/cxx-pretty-print.c:2671 since r11-4386-g9e2256dcd481ffe3

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

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

--- Comment #4 from Ville Voutilainen  ---
Patch at https://gcc.gnu.org/pipermail/gcc-patches/2020-November/560591.html

[Bug target/91816] [8/9 Regression] Arm generates out of range conditional branches in Thumb2

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

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

Stam Markianos-Wright  changed:

   What|Removed |Added

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

--- Comment #9 from Stam Markianos-Wright  ---
Patch is now on all active branches, so moving to RESOLVED. Thanks to all for
their reviews!