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

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |11.0

[Bug c++/98043] (Regression) ICE in verify_gimpl due to bitpacked enum class (amd64)

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |11.0
   Keywords||ice-checking
 Target||x86_64-*-*

[Bug target/98045] [11 Regression] ICE in compute_fn_summary, at ipa-fnsummary.c:3138 on powerpc64le-linux-gnu

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords|ice-on-invalid-code |build, ice-on-valid-code
 CC||hubicka at gcc dot gnu.org
   Target Milestone|--- |11.0

[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|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

--- Comment #3 from Richard Biener  ---
I will have a look.

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

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |11.0
Summary|ICE: in |[11 Regression] ICE: in
   |pp_cxx_trait_expression, at |pp_cxx_trait_expression, at
   |cp/cxx-pretty-print.c:2671  |cp/cxx-pretty-print.c:2671

[Bug c++/98038] ICE on invalid trying to recursively invoke a lambda object with operator()

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Liška  ---
Likely started with r8-2724-g88b811bd29063036.

[Bug plugins/98059] [11 regression] Plugins don't compile with c++20

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |11.0
   Keywords||build

[Bug plugins/98062] [11 regression] Crash in type_as_string from plugin

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |11.0

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

[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

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

--- Comment #1 from Richard Biener  ---
I will have a look.

[Bug target/98065] [11 Regression] ICE in rs6000_expand_vector_set, at config/rs6000/rs6000.c:7024

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |11.0
   Keywords||ice-on-valid-code

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

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
I will have a look.

[Bug c++/98043] [10/11 Regression] ICE ‘verify_gimple’ failed since r10-5122-g6fcb7ebb377f27c7 since r10-5122-g6fcb7ebb377f27c7

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

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

Martin Liška  changed:

   What|Removed |Added

Summary|(Regression) ICE in |[10/11 Regression] ICE
   |verify_gimpl due to |‘verify_gimple’ failed
   |bitpacked enum class|since
   |(amd64) |r10-5122-g6fcb7ebb377f27c7
   ||since
   ||r10-5122-g6fcb7ebb377f27c7
  Known to work||9.3.0
 CC||jakub at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
  Known to fail||10.2.0, 11.0
   Last reconfirmed||2020-11-30
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Started with Jakub's revision.

[Bug target/98045] [11 Regression] ICE in compute_fn_summary, at ipa-fnsummary.c:3138 on powerpc64le-linux-gnu

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Liška  ---
I'll try to reproduce that.

[Bug middle-end/98049] False positive when compiling with -Os -Wmaybe-uninitialized

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
Confirmed. We know that -Wmaybe-uninitialized tend to have false positives.

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

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

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

--- Comment #17 from luoxhu at gcc dot gnu.org ---
(In reply to rsand...@gcc.gnu.org from comment #16)
> > 2)  mad2.c
> > 
> > float foo (double x, float y, float z)
> > {
> >return ( y * fabs (x) + z ); 
> > }
> > 
> > 
> > mad2.c.098t.cunrolli:
> > 
> > foo (double x, float y, float z)
> > {
> >   double _1;
> >   double _2;
> >   double _3;
> >   double _4;
> >   double _5;
> >   float _9;
> > 
> >[local count: 1073741824]:
> >   _1 = (double) y_6(D);
> >   _2 = ABS_EXPR ;
> >   _3 = _1 * _2;
> >   _4 = (double) z_8(D);
> >   _5 = _3 + _4;
> >   _9 = (float) _5;
> >   return _9;
> > 
> > }
> > 
> > mad2.c.099t.backprop:
> > 
> > [USE] _9 in return _9;
> > [USE] _5 in _9 = (float) _5;
> >   _5: convert from float to double not important
> > [DEF] Recording new information for _5 = _3 + _4;
> >   _5: convert from float to double not important
> > [USE] _4 in _5 = _3 + _4;
> >   _4: convert from float to double not important
> > [DEF] Recording new information for _4 = (double) z_8(D);
> >   _4: convert from float to double not important
> > [USE] _3 in _5 = _3 + _4;
> >   _3: convert from float to double not important
> > [DEF] Recording new information for _3 = _1 * _2;
> >   _3: convert from float to double not important
> > [USE] _2 in _3 = _1 * _2;
> >   _2: convert from float to double not important
> > [DEF] Recording new information for _2 = ABS_EXPR ;
> >   _2: convert from float to double not important
> > [USE] _1 in _3 = _1 * _2;
> >   _1: convert from float to double not important
> > [DEF] Recording new information for _1 = (double) y_6(D);
> >   _1: convert from float to double not important
> > 
> > Deleting _4 = (double) z_8(D);
> > Deleting _1 = (double) y_6(D);
> > 
> > 
> > EMERGENCY DUMP:
> > 
> > __attribute__((noinline))
> > foo (double x, float y, float z)
> > {
> >   double _2;
> >   double _3;
> >   double _5;
> >   float _9;
> > 
> >[local count: 1073741824]:
> >   _2 = ABS_EXPR ;
> >   _3 = _2 * y_6(D);
> >   _5 = _3 + z_8(D);
> >   _9 = (float) _5;
> >   return _9;
> > 
> > }
> Maybe I'm misunderstanding the point, but isn't this
> just an issue with the way that the results of the
> analysis are applied to the IL, rather than a problem
> in the analysis itself?

Yes, the optimize operations on Gimple is a bit uncertain.
Do you mean add convert from double to float at proper place
like below to avoid ICE caused by type mismatch ICE in verify_ssa?
Which one will be better, and whether it is correct for all kind
of math operations like pow/exp, etc under fast-math?  If so, no
cancelling is needed again as Richi mentioned?

1) convert before ABS_EXPR:

foo (double x, float y, float z)
{
  float _9;
  float _11;
  float _12;
  float _13;
  float _14;

   [local count: 1073741824]:
  _11 = (float) x_6(D);
  _12 = ABS_EXPR <_11>;
  _13 = y_7(D) * _12;
  _14 = z_8(D) + _13;
  _9 = _14;
  return _9;

}

foo:
.LFB0:
.cfi_startproc
frsp 0,1
fabs 0,0
fmadds 1,2,0,3
blr


2) OR convert after ABS_EXPR:

foo (double x, float y, float z)
{
  double _1;
  float _9;
  float _11;
  float _12;
  float _13;

   [local count: 1073741824]:
  _1 = ABS_EXPR ;
  _11 = (float) _1;
  _12 = y_7(D) * _11;
  _13 = z_8(D) + _12;
  _9 = _13;
  return _9;

}

foo:
.LFB0:
.cfi_startproc
fabs 0,1
frsp 0,0
fmadds 1,2,0,3
blr

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

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
Confirmed, thank you for the report.
I'm reducing that..

[Bug c++/98056] internal compiler error: tree check: expected record_type or union_type or qual_union_type, have array_type in build_special_member_call, at cp/call.c:9862

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Liška  ---
Confirmed, I'm reducing that..

[Bug ipa/98057] ICE when build clang

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
Can you please provide a pre-processed source file (-E option)?

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

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

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

Martin Liška  changed:

   What|Removed |Added

  Known to fail||11.0
Summary|[11 Regression] ICE: in |[11 Regression] ICE: in
   |pp_cxx_trait_expression, at |pp_cxx_trait_expression, at
   |cp/cxx-pretty-print.c:2671  |cp/cxx-pretty-print.c:2671
   ||since
   ||r11-4386-g9e2256dcd481ffe3
 CC||ville.voutilainen at gmail dot 
com

--- Comment #2 from Martin Liška  ---
Started with r11-4386-g9e2256dcd481ffe3, before the revision it was rejected.
Reduced test-case:

$ cat polymorphicsmallobjecttest.cc.ii
struct integral_constant {};
template  using __bool_constant = integral_constant;
template 
using __is_nothrow_assignable_impl =
__bool_constant<__is_nothrow_assignable(_Tp, _Up)>;
template 
struct __is_nt_move_assignable_impl : __is_nothrow_assignable_impl<_Tp, _Tp>
{};
template  struct aligned_storage {
  struct type {
char __data[_Len];
  };
};
template 
using aligned_storage_t = typename aligned_storage<_Len>::type;
template  class PolymorphicSmallObject {
  aligned_storage_t buffer_;
};
template  void test() { __is_nt_move_assignable_impl value; }
int main() { test>; return 0; }

$ g++ polymorphicsmallobjecttest.cc.ii -c
$ g++ polymorphicsmallobjecttest.cc.ii -c -pedantic
‘
polymorphicsmallobjecttest.cc.ii: In instantiation of ‘struct
aligned_storage<0>::type’:
polymorphicsmallobjecttest.cc.ii:16:33:   required from ‘class
PolymorphicSmallObject<0>’
polymorphicsmallobjecttest.cc.ii:5:21:   in pp_cxx_trait_expression, at
cp/cxx-pretty-print.c:2671
   10 | char __data[_Len];
  |  ^~
0x65210c pp_cxx_trait_expression(cxx_pretty_printer*, tree_node*)
/home/marxin/Programming/gcc/gcc/cp/cxx-pretty-print.c:2671
0x9949ea dump_template_parms
/home/marxin/Programming/gcc/gcc/cp/error.c:1945
0x996c3a subst_to_string
/home/marxin/Programming/gcc/gcc/cp/error.c:3369
0x996c3a cp_printer
/home/marxin/Programming/gcc/gcc/cp/error.c:4361
0x1b72e3c pp_format(pretty_printer*, text_info*)
/home/marxin/Programming/gcc/gcc/pretty-print.c:1475
0x1b74ec0 pp_format_verbatim(pretty_printer*, text_info*)
/home/marxin/Programming/gcc/gcc/pretty-print.c:1536
0x1b74ec0 pp_verbatim(pretty_printer*, char const*, ...)
/home/marxin/Programming/gcc/gcc/pretty-print.c:1790
0x98c3ac print_instantiation_partial_context_line
/home/marxin/Programming/gcc/gcc/cp/error.c:3596
0x98c3ac print_instantiation_partial_context
/home/marxin/Programming/gcc/gcc/cp/error.c:3705
0x98c3ac print_instantiation_full_context
/home/marxin/Programming/gcc/gcc/cp/error.c:3585
0x99791a maybe_print_instantiation_context
/home/marxin/Programming/gcc/gcc/cp/error.c:3722
0x99791a cp_diagnostic_starter
/home/marxin/Programming/gcc/gcc/cp/error.c:3413
0x1b56c7a diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
/home/marxin/Programming/gcc/gcc/diagnostic.c:1217
0x1b59338 diagnostic_impl
/home/marxin/Programming/gcc/gcc/diagnostic.c:1366
0x1b59338 pedwarn(unsigned int, int, char const*, ...)
/home/marxin/Programming/gcc/gcc/diagnostic.c:1599
0x94d269 compute_array_index_type_loc
/home/marxin/Programming/gcc/gcc/cp/decl.c:10512
0xa69a70 tsubst(tree_node*, tree_node*, int, tree_node*)
/home/marxin/Programming/gcc/gcc/cp/pt.c:15842
0xa54b1f tsubst_decl
/home/marxin/Programming/gcc/gcc/cp/pt.c:14475
0xa81ead instantiate_class_template_1
/home/marxin/Programming/gcc/gcc/cp/pt.c:11959
0xa830f2 instantiate_class_template(tree_node*)
/home/marxin/Programming/gcc/gcc/cp/pt.c:12196
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug ipa/98057] ICE when build clang

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

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

Martin Liška  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Status|WAITING |ASSIGNED

--- Comment #2 from Martin Liška  ---
Not needed, I was able to reproduce it. Reducing now..

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

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

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

Martin Liška  changed:

   What|Removed |Added

Summary|ICE in  |ICE in
   |check_loop_closed_ssa_def,  |check_loop_closed_ssa_def,
   |at  |at
   |tree-ssa-loop-manip.c:726   |tree-ssa-loop-manip.c:726
   |with -O3|with -O3 since
   ||r11-4921-g86cca5cc14602814
 CC||marxin at gcc dot gnu.org

--- Comment #2 from Martin Liška  ---
For the record, started with r11-4921-g86cca5cc14602814.

[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

Ville Voutilainen  changed:

   What|Removed |Added

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

--- Comment #3 from Ville Voutilainen  ---
Whoops, I need to add the handling of the new intrinsics into
pp_cxx_trait_expression. This should be quite straightforward, stay tuned...

[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

Martin Liška  changed:

   What|Removed |Added

  Known to work||10.2.0
  Known to fail||11.0
Summary|ICE when build clang|[11 Regression] ICE
   ||verify_cgraph_node failed
   ||since
   ||r11-4900-g4656461585bfd0b9
   Target Milestone|--- |11.0
   Priority|P3  |P1

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

$ cat mm.ii
class JITSymbolResolver {
  virtual void anchor();
};
class MemoryManager {
  virtual void anchor();
};
class MCJITMemoryManager : MemoryManager {
  void anchor();
};
class RTDyldMemoryManager : MCJITMemoryManager, JITSymbolResolver {
  void anchor();
};
void RTDyldMemoryManager::anchor() {}
void MCJITMemoryManager::anchor() {}

$ g++ mm.ii -O3 -ffunction-sections -c
mm.ii:14:36: error: implicit_section flag is set but section isn’t
   14 | void MCJITMemoryManager::anchor() {}
  |^
*.LTHUNK0/1 (void RTDyldMemoryManager::*.LTHUNK0()) @0x77742440
  Type: function definition analyzed alias cpp_implicit_alias
  Visibility: prevailing_def_ironly (implicit_section) artificial
  References: _ZN18MCJITMemoryManager6anchorEv/3 (alias) 
  Referring: 
  Availability: available
  Function flags:
  Called by: _ZThn8_N19RTDyldMemoryManager6anchorEv/2 (can throw external) 
  Calls: 
during IPA pass: icf
mm.ii:14:36: internal compiler error: verify_cgraph_node failed
0xc05900 cgraph_node::verify_node()
/home/marxin/Programming/gcc/gcc/cgraph.c:3807
0xbf5974 symtab_node::verify()
/home/marxin/Programming/gcc/gcc/symtab.c:1356
0xbf6b3e symtab_node::verify_symtab_nodes()
/home/marxin/Programming/gcc/gcc/symtab.c:1384
0xe6dd86 symtab_node::checking_verify_symtab_nodes()
/home/marxin/Programming/gcc/gcc/cgraph.h:675
0xe6dd86 symbol_table::remove_unreachable_nodes(_IO_FILE*)
/home/marxin/Programming/gcc/gcc/ipa.c:679
0xf72e99 execute_todo
/home/marxin/Programming/gcc/gcc/passes.c:2107
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

I'm gonna fix it.

[Bug d/98067] New: [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

Bug ID: 98067
   Summary: [11 Regression] d: ICE in in force_decl_die, at
dwarf2out.c:26197 with -gdwarf-2 -gstrict-dwarf
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: ibuclaw at gdcproject dot org
  Target Milestone: ---

Minimal test:

mman.d:
   enum MAP_ANON = 0x10;

test.d:
   import mman : MAP_ANON;

command:
   gdc -gdwarf-2 -gstrict-dwarf test.d

Have also tested with gdc-10 and gdc-9, and no ICE occurs.

[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

Iain Buclaw  changed:

   What|Removed |Added

 Blocks||98058
  Known to work||10.2.1

--- Comment #1 from Iain Buclaw  ---
Blocking pr98058, because darwin targets are strict dwarf2.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98058
[Bug 98058] libphobos: Support building on *-*-darwin*

[Bug rtl-optimization/97954] [11 Regression] ICE in maybe_record_trace_start, at dwarf2cfi.c:2360

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.  Normal jumps including conditional jumps are ignored by the
routine, because they have as SET_DEST (pc) and (pc) has VOIDmode.
Similarly, asm goto with multiple outputs is ok, as it will fail the single_set
check.

[Bug rtl-optimization/97459] __uint128_t remainder for division by 3

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

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

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

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

commit r11-5533-g4d87bd39bafae86747944b2f8c53fdbc43b8dac3
Author: Jakub Jelinek 
Date:   Mon Nov 30 10:55:43 2020 +0100

expansion: Improve double-word modulo by certain constant divisors
[PR97459]

As discussed in the PR, e.g. on x86_64 (both -m32 and -m64) there is no
double-word modulo and so we expand it to a __{,u}mod[dt]i3 call.
For certain constant divisors we can do better.  E.g. consider
32-bit word-size, 0x1ULL % 3 == 1, so we can use partly the
Hacker's
delight modulo by summing digits approach and optimize
unsigned long long foo (unsigned long long x) { return x % 3; }
as
unsigned long long foo (unsigned long long x) {
  unsigned int sum, carry;
  carry = __builtin_add_overflow ((unsigned int) x, (unsigned int) (x >>
32), &sum);
  sum += carry;
  return sum % 3;
}
Similarly, 0x1000ULL % 5 == 1 (note, 1 << 28), so
unsigned long long bar (unsigned long long x) { return x % 5; }
as
unsigned long long bar (unsigned long long x) {
  unsigned int sum = x & ((1 << 28) - 1);
  sum += (x >> 28) & ((1 << 28) - 1);
  sum += (x >> 56);
  return sum % 5;
}
etc.
And we can do also signed modulo,
long long baz (long long x) { return x % 5; }
as
long long baz (long long x) {
  unsigned int sum = x & ((1 << 28) - 1);
  sum += ((unsigned long long) x >> 28) & ((1 << 28) - 1);
  sum += ((unsigned long long) x >> 56);
  /* Sum adjustment for negative x.  */
  sum += (x >> 63) & 3;
  unsigned int rem = sum % 5;
  /* And finally adjust it to the right interval for negative values.  */
  return (int) (rem + ((x >> 63) & -4));
}

2020-11-30  Jakub Jelinek  

PR rtl-optimization/97459
* internal-fn.h (expand_addsub_overflow): Declare.
* internal-fn.c (expand_addsub_overflow): No longer static.
* optabs.c (expand_doubleword_mod): New function.
(expand_binop): Optimize double-word mod with constant divisor.

* gcc.dg/pr97459-1.c: New test.
* gcc.dg/pr97459-2.c: New test.

[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 #2 from Iain Buclaw  ---
Backtrace:
0xaf0ca2 force_decl_die
../../gcc/dwarf2out.c:26197
0xae7bd6 force_decl_die
../../gcc/dwarf2out.c:26142
0xae7bd6 dwarf2out_imported_module_or_decl_1
../../gcc/dwarf2out.c:26809
0xb086a0 dwarf2out_imported_module_or_decl
../../gcc/dwarf2out.c:26895
0x9aabbe DeclVisitor::visit(Import*)
../../gcc/d/decl.cc:199
0x9a75af DeclVisitor::build_dsymbol(Dsymbol*)
../../gcc/d/decl.cc:145
0x9a75af build_decl_tree(Dsymbol*)
../../gcc/d/decl.cc:1015
0x9b9cc0 build_module_tree(Module*)
../../gcc/d/modules.cc:737
0x9aaa9b DeclVisitor::visit(Module*)
../../gcc/d/decl.cc:162
0x9a75af DeclVisitor::build_dsymbol(Dsymbol*)
../../gcc/d/decl.cc:145
0x9a75af build_decl_tree(Dsymbol*)
../../gcc/d/decl.cc:1015
0x9a4512 d_parse_file
../../gcc/d/d-lang.cc:1236
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[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 #3 from Iain Buclaw  ---
It looks like the regressing change was r11-5003.

[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

   Assignee|rguenth at gcc dot gnu.org |marxin at gcc dot 
gnu.org
 CC||marxin at gcc dot gnu.org

--- Comment #2 from Martin Liška  ---
I've got a fix for the ICE.

[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

Iain Sandoe  changed:

   What|Removed |Added

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

[Bug c++/98056] ICE tree check: expected record_type or union_type or qual_union_type, have array_type in build_special_member_call, at cp/call.c:9862 since r11-2183-g0f66b8486cea8668

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

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

Martin Liška  changed:

   What|Removed |Added

   Target Milestone|--- |10.3
Summary|internal compiler error:|ICE tree check: expected
   |tree check: expected|record_type or union_type
   |record_type or union_type   |or qual_union_type, have
   |or qual_union_type, have|array_type in
   |array_type in   |build_special_member_call,
   |build_special_member_call,  |at cp/call.c:9862 since
   |at cp/call.c:9862   |r11-2183-g0f66b8486cea8668

--- Comment #3 from Martin Liška  ---
Before r11-2183-g0f66b8486cea8668 it was rejected.

Reduced test-case:

$ cat cloudstorage.cc.ii
namespace std {
template  struct coroutine_traits : _Result {};
template  struct coroutine_handle {
  operator coroutine_handle<>();
};
struct suspend_never {
  void await_ready();
  void await_suspend(coroutine_handle<>);
  void await_resume();
};
} // namespace std
namespace std_ns = std;
namespace coro::stdx {
template  using coroutine_handle = std_ns::coroutine_handle<>;
}
namespace std {
struct pair {
  template  pair(_U1, _U2);
};
template  class initializer_list {
  int *_M_array;
  unsigned long _M_len;
};
int typedef string;
} // namespace std
namespace coro::stdx {
class stop_token {};
} // namespace coro::stdx
namespace coro {
class Task {
public:
  void await_ready();
  void await_suspend(stdx::coroutine_handle<>);
  void await_resume();
  struct promise_type {
struct final_awaitable {
  void await_ready();
  template  void await_suspend(V);
  void await_resume();
};
std::suspend_never initial_suspend();
final_awaitable final_suspend();
void unhandled_exception();
  };
};
} // namespace coro
namespace std {
class optional {
public:
  template  optional(_Up);
};
} // namespace std
namespace coro::http {
struct Request {
  std::optional body;
};
template  concept HttpClient = requires { stdx::stop_token(); };
} // namespace coro::http
namespace coro::cloudstorage {
template  concept CloudProviderImpl = requires(T stop_token) {
  stop_token;
};
template  class CloudProvider : Impl {
public:
  Impl::Impl;
  template 
  void RefreshAccessToken(HttpClient http, int refresh_token,
  stdx::stop_token stop_token = stdx::stop_token()) {
Impl::RefreshAccessToken(http, refresh_token, stop_token);
  }
};
} // namespace coro::cloudstorage
namespace coro::util {
template 
Task FetchJson(auto, RequestType, stdx::stop_token);
}
namespace coro::http {
template >
int FormDataToString(List);
}
namespace coro::cloudstorage {
class GoogleDrive {
public:
  GoogleDrive(int);
  template 
  Task RefreshAccessToken(HttpClient http, int refresh_token,
  stdx::stop_token stop_token) {
co_await util::FetchJson(
http, http::Request{http::FormDataToString({{"", refresh_token}})},
stop_token);
  }
};
} // namespace coro::cloudstorage
using coro::cloudstorage::CloudProvider;
using coro::cloudstorage::GoogleDrive;
int GetGoogleDriveAuthData();
template 
void GetAccessToken(int *, HttpClient http) {
  CloudProvider(GetGoogleDriveAuthData())
  .RefreshAccessToken(http, std::string());
}
void CoMain() {
  int *event_loop;
  void http();
  GetAccessToken(event_loop, http);
}

$ g++ cloudstorage.cc.ii -c -fcoroutines -std=gnu++2a
cloudstorage.cc.ii:65:3: warning: access declarations are deprecated in favour
of using-declarations; suggestion: add the ‘using’ keyword [-Wdeprecated]
   65 |   Impl::Impl;
  |   ^~~~
cloudstorage.cc.ii: In instantiation of ‘coro::Task
coro::cloudstorage::GoogleDrive::RefreshAccessToken(HttpClient, int,
coro::stdx::stop_token) [with HttpClient = void (*)()]’:
cloudstorage.cc.ii:69:29:   required from ‘void
coro::cloudstorage::CloudProvider::RefreshAccessToken(HttpClient, int,
coro::stdx::stop_token) [with HttpClient = void (*)(); Impl =
coro::cloudstorage::GoogleDrive]’
cloudstorage.cc.ii:100:26:   required from ‘void GetAccessToken(int*,
HttpClient) [with HttpClient = void (*)()]’
cloudstorage.cc.ii:105:34:   required from here
cloudstorage.cc.ii:91:3: internal compiler error: tree check: expected
record_type or union_type or qual_union_type, have array_type in
build_special_member_call, at cp/call.c:9862
   91 |   }
  |   ^
0x80d3ef tree_check_failed(tree_node const*, char const*, int, char const*,
...)
/home/marxin/Programming/gcc/gcc/tree.c:9810
0x62a1ea tree_check3(tree_node*, char const*, int, char const*, tree_code,
tree_code, tree_code)
/home/marxin/Programming/gcc/gcc/tree.h:3371
0x62a1ea build_special_member_call(tree_node*, tree_node*, vec**, tree_node*, int, int)
/home/marxin/Programming/gcc/gcc/cp/call.c:9862
0x92c1a4 flatten_await_stmt
/home/marxin/Program

[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

--- Comment #3 from Martin Liška  ---
Created attachment 49650
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49650&action=edit
Patch candidate

With the patch I see that the target can't expand it to RTL:

$ ./xgcc -B. pr98066.c -mvsx -O1 -c -fdump-tree-optimized=/dev/stdout
...
   [local count: 1073741824]:
  t7.0_1 = t7;
  _2 = __builtin_altivec_vcmpequw_p (a0_4(D), i1_7(D), t7.0_1);
  if (_2 != 0)
...
during RTL pass: expand
pr98066.c: In function ‘qs’:
pr98066.c:7:12: internal compiler error: in rs6000_expand_vector_set, at
config/rs6000/rs6000.c:7024
7 | t7[a0] = a0;
  | ~~~^~~~
0x72e396 rs6000_expand_vector_set(rtx_def*, rtx_def*, rtx_def*)
/home/marxin/Programming/gcc2/gcc/config/rs6000/rs6000.c:7024
0x15a1660 ???
/home/marxin/Programming/gcc2/gcc/config/rs6000/vector.md:1251
0xc4e448 maybe_expand_insn(insn_code, unsigned int, expand_operand*)
/home/marxin/Programming/gcc2/gcc/optabs.c:7435
0xaf484a expand_vec_set_optab_fn
/home/marxin/Programming/gcc2/gcc/internal-fn.c:2879
0xaf484a expand_VEC_SET
/home/marxin/Programming/gcc2/gcc/internal-fn.def:148
0x8deb17 expand_call_stmt
/home/marxin/Programming/gcc2/gcc/cfgexpand.c:2740
0x8deb17 expand_gimple_stmt_1
/home/marxin/Programming/gcc2/gcc/cfgexpand.c:3835
0x8deb17 expand_gimple_stmt
/home/marxin/Programming/gcc2/gcc/cfgexpand.c:3999
0x8e41ca expand_gimple_basic_block
/home/marxin/Programming/gcc2/gcc/cfgexpand.c:6040
0x8e5bf6 execute
/home/marxin/Programming/gcc2/gcc/cfgexpand.c:6724
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

That's something for Xionghu Luo.

[Bug tree-optimization/98066] ICE in rs6000_expand_vector_set, at config/rs6000/rs6000.c:7024

[asolokha at gmx dot com via Gcc-bugs]

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

--- Comment #4 from Arseny Solokha  ---
Is it a duplicate of PR98065, then?

[Bug target/98045] [11 Regression] ICE in compute_fn_summary, at ipa-fnsummary.c:3138 on powerpc64le-linux-gnu

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #5 from Martin Liška  ---
Can't reproduce on gcc112 compile farm machine for
g:a5ad5d5c478ee7bebf057161bb8715ee7d286875 with:

$ ../configure  --enable-default-pie  --enable-secureplt
--with-cpu=power8 --enable-targets=powerpcle-linux --disable-multilib
--enable-multiarch  --disable-werror   --with-long-double-128
--enable-checking=yes,extra,rtl
$ nice make profiledbootstrap

[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

Summary|ICE in  |[11 Regression] ICE:
   |rs6000_expand_vector_set,   |Segmentation fault (in
   |at  |gsi_next)
   |config/rs6000/rs6000.c:7024 |

--- Comment #5 from Martin Liška  ---
(In reply to Arseny Solokha from comment #4)
> Is it a duplicate of PR98065, then?

Yes, so I will keep this for the gsi_next ICE.

[Bug d/87818] D runtime does not build on FreeBSD.

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

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Iain Buclaw :

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

commit r11-5535-ge855b30c28391b190eebb8e6afc8d2116a6d85de
Author: Iain Buclaw 
Date:   Sat Nov 28 16:55:53 2020 +0100

d: Add freebsd support for D compiler and runtime

gcc/ChangeLog:

PR d/87818
* config.gcc (*-*-freebsd*): Add freebsd-d.o and t-freebsd.
* config/freebsd-d.c: New file.
* config/t-freebsd: New file.

libphobos/ChangeLog:

PR d/87818
* configure.tgt: Add x86_64-*-freebsd* and i?86-*-freebsd* as
supported targets.

[Bug d/87818] D runtime does not build on FreeBSD.

[ibuclaw at gdcproject dot org via Gcc-bugs]

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

Iain Buclaw  changed:

   What|Removed |Added

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

--- Comment #6 from Iain Buclaw  ---
i386 and x86_86 freebsd support has been added.

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

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

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

--- Comment #7 from CVS Commits  ---
The releases/gcc-8 branch has been updated by Stam Markianos-Wright
:

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

commit r8-10655-g3a936a9ecddef58ad5b6ee11697c3f791b942708
Author: Stam Markianos-Wright 
Date:   Mon Nov 30 10:47:54 2020 +

Backport of the patch for PR target/91816

This is a patch for an issue where the compiler was generating a
conditional branch in Thumb2, which was too far for b{cond} to handle.

This backport also includes the subsequent fixes to the test in this
patch.

gcc/ChangeLog

PR target/91816
* config/arm/arm-protos.h: New function arm_gen_far_branch
prototype.
* config/arm/arm.c (arm_gen_far_branch): New function
arm_gen_far_branch.
* config/arm/arm.md: Update b for Thumb2 range checks.

gcc/testsuite/ChangeLog

PR target/91816
* gcc.target/arm/pr91816.c: New test.

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

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

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

--- Comment #8 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Stam Markianos-Wright
:

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

commit r9-9081-g6b7ab0e565d79a7e6ae5dbbf17a5eb4eafe56dc8
Author: Stam Markianos-Wright 
Date:   Mon Nov 30 11:05:30 2020 +

Backport of the patch for PR target/91816

This is a patch for an issue where the compiler was generating a
conditional branch in Thumb2, which was too far for b{cond} to handle.

This backport also includes the subsequent fixes to the test in this
patch.

gcc/ChangeLog

* config/arm/arm-protos.h: New function arm_gen_far_branch
prototype.
* config/arm/arm.c (arm_gen_far_branch): New function
arm_gen_far_branch.
* config/arm/arm.md: Update b for Thumb2 range checks.

gcc/testsuite/ChangeLog

* gcc.target/arm/pr91816.c: New test.

[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!

[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 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 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

[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 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 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/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 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/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 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&action=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

[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 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 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 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 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 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 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 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 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 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

[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 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 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 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 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 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 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 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 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 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 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 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/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 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/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 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/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 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 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 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 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 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 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 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 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 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 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 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 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 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&action=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/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 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 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 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 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++/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 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++/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++/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&action=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 ();
};

?