[Bug tree-optimization/98655] New: ICE: verify_gimple failed (error: integral result type precision does not match field size of 'bit_field_ref')

[asolokha at gmx dot com via Gcc-bugs]

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

Bug ID: 98655
   Summary: ICE: verify_gimple failed (error: integral result type
precision does not match field size of
'bit_field_ref')
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---
Target: powerpc-*-linux-gnu

gcc-11.0.0-alpha20210110 snapshot (g:872373360dab259d51caa002ff1722ff84746d8b)
configured for rs6000 target ICEs when compiling the following testcase,
reduced from testsuite/gcc.target/i386/pr97521.c, w/ -O1 -fno-tree-forwprop:

typedef unsigned char __attribute__ ((__vector_size__ (8))) V;
typedef unsigned long long __attribute__ ((__vector_size__ (16))) W;

V
foo (W f)
{
  W g = ((W) { 0, 1 } < 1) <= (0 < f);

  return (V) (g[0]);
}

% powerpc-e300c3-linux-gnu-gcc-11.0.0 -O1 -fno-tree-forwprop -w -c mvzpqney.c
mvzpqney.c: In function 'foo':
mvzpqney.c:5:1: error: integral result type precision does not match field size
of 'bit_field_ref'
5 | foo (W f)
  | ^~~
_10 = BIT_FIELD_REF <_9, 1, 0>;
mvzpqney.c:5:1: error: integral result type precision does not match field size
of 'bit_field_ref'
_12 = BIT_FIELD_REF <_11, 1, 0>;
mvzpqney.c:5:1: error: integral result type precision does not match field size
of 'bit_field_ref'
_16 = BIT_FIELD_REF <_15, 1, 1>;
mvzpqney.c:5:1: error: integral result type precision does not match field size
of 'bit_field_ref'
_18 = BIT_FIELD_REF <_17, 1, 1>;
during GIMPLE pass: veclower2
mvzpqney.c:5:1: internal compiler error: verify_gimple failed
0xe59f67 verify_gimple_in_cfg(function*, bool)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20210110/work/gcc-11-20210110/gcc/tree-cfg.c:5467
0xd27b0e execute_function_todo
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20210110/work/gcc-11-20210110/gcc/passes.c:2042
0xd2821c do_per_function
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20210110/work/gcc-11-20210110/gcc/passes.c:1687
0xd2821c execute_todo
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20210110/work/gcc-11-20210110/gcc/passes.c:2096

[Bug target/95905] Failure to optimize _mm_unpacklo_epi8 with 0 as right operand to _mm_cvtepu8_epi16

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

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

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

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

commit r11-6628-gb668a06e37f72fd96bacd6769990ec97dac4ac6d
Author: Jakub Jelinek 
Date:   Wed Jan 13 08:02:54 2021 +0100

i386: Optimize _mm_unpacklo_epi8 of 0 vector as second argument or similar
VEC_PERM_EXPRs into pmovzx [PR95905]

The following patch adds patterns (so far 128-bit only) for permutations
like { 0 16 1 17 2 18 3 19 4 20 5 21 6 22 7 23 } where the second
operand is CONST0_RTX CONST_VECTOR to be emitted as pmovzx.

2021-01-13  Jakub Jelinek  

PR target/95905
* config/i386/predicates.md (pmovzx_parallel): New predicate.
* config/i386/sse.md (*sse4_1_zero_extendv8qiv8hi2_3): New
define_insn_and_split pattern.
(*sse4_1_zero_extendv4hiv4si2_3): Likewise.
(*sse4_1_zero_extendv2siv2di2_3): Likewise.

* gcc.target/i386/pr95905-1.c: New test.
* gcc.target/i386/pr95905-2.c: New test.

[Bug target/98647] Failure to optimize out convertion from float to vector type

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org,
   ||matz at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
If the psABI doesn't say those upper parts of the register have to be cleared
(explicitly), then it means their content is undefined in the register passing.
I believe even LLVM doesn't assume it has to be zeros, otherwise it wouldn't
compile:
typedef float V __attribute__((vector_size (16), may_alias));
float foo (V x) { return x[0]; }
into just retq - if the psABI mandated clearing of the upper bits, then we'd
need to clear in that case.

Anyway, as only the low float is extracted from it in the end, it might be best
to just change the mask into 0x7fff, 0, 0, 0 and then ignore any code that
would only ensure those upper floats are initialized properly.

Testcase with generic vectors so that intrinsics don't interfere with this:
typedef float V __attribute__((vector_size (16), may_alias));
typedef int W __attribute__((vector_size (16), may_alias));

float
foo (float x)
{
  V a = (V) { x, 0.0, 0.0, 0.0 };
  W b = *(W *)
  b &= (W) { 0x7fff, 0x7fff, 0x7fff, 0x7fff };
  V c = *(V *)
  return c[0];
}

V
bar (float x)
{
  V a = (V) { x, 0.0, 0.0, 0.0 };
  W b = *(W *)
  b &= (W) { 0x7fff, 0x7fff, 0x7fff, 0x7fff };
  V c = *(V *)
  return c;
}

[Bug target/93390] AARCH64: FP move costs needs improvements for ThunderX2

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |WONTFIX
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Andrew Pinski  ---
ThunderX 2 is no longer being produced so closing as won't fix.

[Bug middle-end/98649] Trivial jump table not eliminated

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c++ |middle-end
   Severity|normal  |enhancement

--- Comment #1 from Andrew Pinski  ---
This might be because there is type based vtable not lowered until expand time.

[Bug other/98652] unused code found in function analyze_functions:1194

[ashimida at linux dot alibaba.com via Gcc-bugs]

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

--- Comment #3 from ashimida  ---
*** Bug 98654 has been marked as a duplicate of this bug. ***

[Bug other/98654] unused code found in function analyze_functions:1194

[ashimida at linux dot alibaba.com via Gcc-bugs]

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

ashimida  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from ashimida  ---
same problem

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

[Bug other/98652] unused code found in function analyze_functions:1194

[ashimida at linux dot alibaba.com via Gcc-bugs]

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

--- Comment #2 from ashimida  ---
*** Bug 98653 has been marked as a duplicate of this bug. ***

[Bug other/98653] unused code found in function analyze_functions:1194

[ashimida at linux dot alibaba.com via Gcc-bugs]

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

ashimida  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from ashimida  ---
same problem

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

[Bug other/98652] unused code found in function analyze_functions:1194

[ashimida at linux dot alibaba.com via Gcc-bugs]

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

--- Comment #1 from ashimida  ---
*** Bug 98651 has been marked as a duplicate of this bug. ***

[Bug other/98651] unused code found in function analyze_functions:1194

[ashimida at linux dot alibaba.com via Gcc-bugs]

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

ashimida  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from ashimida  ---
same problem

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

[Bug other/98654] New: unused code found in function analyze_functions:1194

[ashimida at linux dot alibaba.com via Gcc-bugs]

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

Bug ID: 98654
   Summary: unused code found in function analyze_functions:1194
   Product: gcc
   Version: new-ra
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ashimida at linux dot alibaba.com
  Target Milestone: ---

In function "analyze_functions"[1]:1194, the value of "changed" should always
be "true" and the fprintf will output nothing. codes in line [1194,1195] should
be deleted.



1173   while (changed)
1174 {
1175   changed = false;
1176   process_function_and_variable_attributes (first_analyzed,
1177 first_analyzed_var);
1178 
1179   /* First identify the trivially needed symbols.  */
1180   for (node = symtab->first_symbol ();
1181node != first_analyzed
1182&& node != first_analyzed_var; node = node->next)
1183 {
1184   /* Convert COMDAT group designators to IDENTIFIER_NODEs.  */
1185   node->get_comdat_group_id ();
1186   if (node->needed_p ())
1187 {
1188   enqueue_node (node);
1189   if (!changed && symtab->dump_file)
1190 fprintf (symtab->dump_file, "Trivially needed symbols:");
1191   changed = true;
1192   if (symtab->dump_file)
1193 fprintf (symtab->dump_file, " %s", node->dump_asm_name
());
1194   if (!changed && symtab->dump_file)
1195 fprintf (symtab->dump_file, "\n");
1196 }
1197   if (node == first_analyzed
1198   || node == first_analyzed_var)
1199 break;
1200 }

[1]:https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/cgraphunit.c;h=cf64e56ab951a0a757e507f59c236523b003a6be;hb=HEAD

[Bug other/98653] New: unused code found in function analyze_functions:1194

[ashimida at linux dot alibaba.com via Gcc-bugs]

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

Bug ID: 98653
   Summary: unused code found in function analyze_functions:1194
   Product: gcc
   Version: new-ra
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ashimida at linux dot alibaba.com
  Target Milestone: ---

In function "analyze_functions"[1]:1194, the value of "changed" should always
be "true" and the fprintf will output nothing. codes in line [1194,1195] should
be deleted.



1173   while (changed)
1174 {
1175   changed = false;
1176   process_function_and_variable_attributes (first_analyzed,
1177 first_analyzed_var);
1178 
1179   /* First identify the trivially needed symbols.  */
1180   for (node = symtab->first_symbol ();
1181node != first_analyzed
1182&& node != first_analyzed_var; node = node->next)
1183 {
1184   /* Convert COMDAT group designators to IDENTIFIER_NODEs.  */
1185   node->get_comdat_group_id ();
1186   if (node->needed_p ())
1187 {
1188   enqueue_node (node);
1189   if (!changed && symtab->dump_file)
1190 fprintf (symtab->dump_file, "Trivially needed symbols:");
1191   changed = true;
1192   if (symtab->dump_file)
1193 fprintf (symtab->dump_file, " %s", node->dump_asm_name
());
1194   if (!changed && symtab->dump_file)
1195 fprintf (symtab->dump_file, "\n");
1196 }
1197   if (node == first_analyzed
1198   || node == first_analyzed_var)
1199 break;
1200 }

[1]:https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/cgraphunit.c;h=cf64e56ab951a0a757e507f59c236523b003a6be;hb=HEAD

[Bug other/98652] New: unused code found in function analyze_functions:1194

[ashimida at linux dot alibaba.com via Gcc-bugs]

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

Bug ID: 98652
   Summary: unused code found in function analyze_functions:1194
   Product: gcc
   Version: new-ra
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ashimida at linux dot alibaba.com
  Target Milestone: ---

In function "analyze_functions"[1]:1194, the value of "changed" should always
be "true" and the fprintf will output nothing. codes in line [1194,1195] should
be deleted.



1173   while (changed)
1174 {
1175   changed = false;
1176   process_function_and_variable_attributes (first_analyzed,
1177 first_analyzed_var);
1178 
1179   /* First identify the trivially needed symbols.  */
1180   for (node = symtab->first_symbol ();
1181node != first_analyzed
1182&& node != first_analyzed_var; node = node->next)
1183 {
1184   /* Convert COMDAT group designators to IDENTIFIER_NODEs.  */
1185   node->get_comdat_group_id ();
1186   if (node->needed_p ())
1187 {
1188   enqueue_node (node);
1189   if (!changed && symtab->dump_file)
1190 fprintf (symtab->dump_file, "Trivially needed symbols:");
1191   changed = true;
1192   if (symtab->dump_file)
1193 fprintf (symtab->dump_file, " %s", node->dump_asm_name
());
1194   if (!changed && symtab->dump_file)
1195 fprintf (symtab->dump_file, "\n");
1196 }
1197   if (node == first_analyzed
1198   || node == first_analyzed_var)
1199 break;
1200 }

[1]:https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/cgraphunit.c;h=cf64e56ab951a0a757e507f59c236523b003a6be;hb=HEAD

[Bug other/98651] New: unused code found in function analyze_functions:1194

[ashimida at linux dot alibaba.com via Gcc-bugs]

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

Bug ID: 98651
   Summary: unused code found in function analyze_functions:1194
   Product: gcc
   Version: new-ra
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ashimida at linux dot alibaba.com
  Target Milestone: ---

In function "analyze_functions"[1]:1194, the value of "changed" should always
be "true" and the fprintf will output nothing.
  codes in line [1194,1195] should be deleted.



1173   while (changed)
1174 {
1175   changed = false;
1176   process_function_and_variable_attributes (first_analyzed,
1177 first_analyzed_var);
1178 
1179   /* First identify the trivially needed symbols.  */
1180   for (node = symtab->first_symbol ();
1181node != first_analyzed
1182&& node != first_analyzed_var; node = node->next)
1183 {
1184   /* Convert COMDAT group designators to IDENTIFIER_NODEs.  */
1185   node->get_comdat_group_id ();
1186   if (node->needed_p ())
1187 {
1188   enqueue_node (node);
1189   if (!changed && symtab->dump_file)
1190 fprintf (symtab->dump_file, "Trivially needed symbols:");
1191   changed = true;
1192   if (symtab->dump_file)
1193 fprintf (symtab->dump_file, " %s", node->dump_asm_name
());
1194   if (!changed && symtab->dump_file)
1195 fprintf (symtab->dump_file, "\n");
1196 }
1197   if (node == first_analyzed
1198   || node == first_analyzed_var)
1199 break;
1200 }

[1]:https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/cgraphunit.c;h=cf64e56ab951a0a757e507f59c236523b003a6be;hb=HEAD

[Bug demangler/98650] New: Issue within gdb with debugging symbols of telegram-desktop under Debian 10 GNU/Linux amd64

[galex-713--- via Gcc-bugs]

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

Bug ID: 98650
   Summary: Issue within gdb with debugging symbols of
telegram-desktop under Debian 10 GNU/Linux amd64
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: demangler
  Assignee: unassigned at gcc dot gnu.org
  Reporter: galex-...@galex-713.eu
  Target Milestone: ---

Hello,

I was told on a gdb bug (here:
https://sourceware.org/bugzilla/show_bug.cgi?id=27176), that I should report
here an issue with debugging symbols of telegram-desktop (1.5.11-1) produced by
gcc 8.2.0-15 under Debian GNU/Linux 10 amd64, that cause gdb 8.2.1 to say
“demangler-warning: unable to demangle” while loading debugging symbols.

Here’s the build log:
https://buildd.debian.org/status/fetch.php?pkg=telegram-desktop=amd64=1.5.11-1=1549231362=0

And here’s what gdb says me, as soon as I installed the debugging symbols:
GNU gdb (Debian 8.2.1-2+b3) 8.2.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from
telegram-desktop.../build/gdb-EbRs5Y/gdb-8.2.1/gdb/cp-support.c:1581:
demangler-warning: unable to demangle
'_ZNSt11_Tuple_implILm0EJN3rpl8producerIN4base5flagsIN11MTPDchannel4FlagEEENS0_8no_errorEZNS0_7details10map_helperIZN4Data18FlagsValueWithMaskINSA_5FlagsIS6_Lj2147486693EE6ChangeES7_ZNS8_11then_helperISE_S7_ZNKS0_12event_streamISE_E6eventsEvEUlRKT_E_EclISE_S7_ZNS0_6singleISE_EEDaOSI_EUlSK_E_SE_S7_EEDaONS1_ISI_T0_T1_EEEUlSK_E_EEDaSU_NSI_4TypeEEUlRKSE_E0_EclISE_S7_ZNS8_13filter_helperIZNSB_ISE_S7_SV_EEDaSU_SW_EUlSY_E_EclISE_S7_SV_vEEDaSU_EUlSK_E_S6_EEDaSU_EUlSK_E_EENS1_IbS7_ZNS9_IZNSA_15SingleFlagValueINSC_INS3_IN19MTPDchatAdminRights4FlagEEELj4294967295EE6ChangeES7_ZNSF_IS1E_S7_ZNKSG_IS1E_E6eventsEvEUlSK_E_EclIS1E_S7_ZNSO_IS1E_EEDaSP_EUlSK_E_S1E_S7_EEDaSU_EUlSK_E_EEDaSU_NSI_4EnumEEUlS1C_E_EclIS1C_S7_ZNS9_IZNSB_IS1E_S7_S1K_EEDaSU_SW_EUlRKS1E_E0_EclIS1E_S7_ZNS12_IZNSB_IS1E_S7_S1K_EEDaSU_SW_EUlS1Q_E_EclIS1E_S7_S1K_vEEDaSU_EUlSK_E_S1C_EEDaSU_EUlSK_E_bEEDaSU_EUlSK_E_EENS1_IbS7_ZNS9_IZNS19_INSC_INS3_IN20MTPDchatBannedRights4FlagEEELj4294967295EE6ChangeES7_ZNSF_IS25_S7_ZNKSG_IS25_E6eventsEvEUlSK_E_EclIS25_S7_ZNSO_IS25_EEDaSP_EUlSK_E_S25_S7_EEDaSU_EUlSK_E_EEDaSU_S1L_EUlS23_E_EclIS23_S7_ZNS9_IZNSB_IS25_S7_S2B_EEDaSU_SW_EUlRKS25_E0_EclIS25_S7_ZNS12_IZNSB_IS25_S7_S2B_EEDaSU_SW_EUlS2G_E_EclIS25_S7_S2B_vEEDaSU_EUlSK_E_S23_EEDaSU_EUlSK_E_bEEDaSU_EUlSK_E_EES2Q_EED1Ev'
(demangler failed with signal 11)
Unable to dump core, use `ulimit -c unlimited' before executing GDB next time.
/build/gdb-EbRs5Y/gdb-8.2.1/gdb/cp-support.c:1595: demangler-warning: unable to
demangle
'_ZNSt11_Tuple_implILm0EJN3rpl8producerIN4base5flagsIN11MTPDchannel4FlagEEENS0_8no_errorEZNS0_7details10map_helperIZN4Data18FlagsValueWithMaskINSA_5FlagsIS6_Lj2147486693EE6ChangeES7_ZNS8_11then_helperISE_S7_ZNKS0_12event_streamISE_E6eventsEvEUlRKT_E_EclISE_S7_ZNS0_6singleISE_EEDaOSI_EUlSK_E_SE_S7_EEDaONS1_ISI_T0_T1_EEEUlSK_E_EEDaSU_NSI_4TypeEEUlRKSE_E0_EclISE_S7_ZNS8_13filter_helperIZNSB_ISE_S7_SV_EEDaSU_SW_EUlSY_E_EclISE_S7_SV_vEEDaSU_EUlSK_E_S6_EEDaSU_EUlSK_E_EENS1_IbS7_ZNS9_IZNSA_15SingleFlagValueINSC_INS3_IN19MTPDchatAdminRights4FlagEEELj4294967295EE6ChangeES7_ZNSF_IS1E_S7_ZNKSG_IS1E_E6eventsEvEUlSK_E_EclIS1E_S7_ZNSO_IS1E_EEDaSP_EUlSK_E_S1E_S7_EEDaSU_EUlSK_E_EEDaSU_NSI_4EnumEEUlS1C_E_EclIS1C_S7_ZNS9_IZNSB_IS1E_S7_S1K_EEDaSU_SW_EUlRKS1E_E0_EclIS1E_S7_ZNS12_IZNSB_IS1E_S7_S1K_EEDaSU_SW_EUlS1Q_E_EclIS1E_S7_S1K_vEEDaSU_EUlSK_E_S1C_EEDaSU_EUlSK_E_bEEDaSU_EUlSK_E_EENS1_IbS7_ZNS9_IZNS19_INSC_INS3_IN20MTPDchatBannedRights4FlagEEELj4294967295EE6ChangeES7_ZNSF_IS25_S7_ZNKSG_IS25_E6eventsEvEUlSK_E_EclIS25_S7_ZNSO_IS25_EEDaSP_EUlSK_E_S25_S7_EEDaSU_EUlSK_E_EEDaSU_S1L_EUlS23_E_EclIS23_S7_ZNS9_IZNSB_IS25_S7_S2B_EEDaSU_SW_EUlRKS25_E0_EclIS25_S7_ZNS12_IZNSB_IS25_S7_S2B_EEDaSU_SW_EUlS2G_E_EclIS25_S7_S2B_vEEDaSU_EUlSK_E_S23_EEDaSU_EUlSK_E_bEEDaSU_EUlSK_E_EES2Q_EED1Ev'
(demangler failed with signal 11)
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n)

[Bug libstdc++/98471] libstdc++ fails to build with clang on windows because of filesystem bug

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #1 from cqwrteur  ---
Is this possible to fix? Is that anything wrong with the patch I provided?

[Bug tree-optimization/14721] jump optimization involving a sibling call within a jump table

[pdimov at gmail dot com via Gcc-bugs]

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

Peter Dimov  changed:

   What|Removed |Added

 CC||pdimov at gmail dot com

--- Comment #5 from Peter Dimov  ---
It's becoming more common with the use of std::variant and compatible libraries
(such as Boost.Variant2.) https://godbolt.org/z/414e6j shows a reduced example.

[Bug c++/98649] New: Trivial jump table not eliminated

[pdimov at gmail dot com via Gcc-bugs]

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

Bug ID: 98649
   Summary: Trivial jump table not eliminated
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pdimov at gmail dot com
  Target Milestone: ---

Trivial jump tables where all entries are the same are sometimes not
eliminated. E.g. the following example

```
struct Base { virtual void run( float f ) = 0; };
struct T0: Base { void run( float f ); };
struct T1: Base { void run( float f ); };
struct T2: Base { void run( float f ); };
struct T3: Base { void run( float f ); };
struct T4: Base { void run( float f ); };

template struct mp_int {};

struct variant
{
unsigned index_;

union
{
T0 t0_;
T1 t1_;
T2 t2_;
T3 t3_;
T4 t4_;
};

T0& get( mp_int<0> ) { return t0_; }
T1& get( mp_int<1> ) { return t1_; }
T2& get( mp_int<2> ) { return t2_; }
T3& get( mp_int<3> ) { return t3_; }
T4& get( mp_int<4> ) { return t4_; }
};

template decltype(auto) get( variant& v )
{
return v.get( mp_int() );
}

void f1( variant& v, float f )
{
switch( v.index_ )
{
case 0: get<0>(v).run( f ); break;
case 1: get<1>(v).run( f ); break;
case 2: get<2>(v).run( f ); break;
case 3: get<3>(v).run( f ); break;
case 4: get<4>(v).run( f ); break;
default: __builtin_unreachable();
}
}

```

(https://godbolt.org/z/MxzGh8)

results in

```
f1(variant&, float):
mov eax, DWORD PTR [rdi]
lea r8, [rdi+8]
jmp [QWORD PTR .L4[0+rax*8]]
.L4:
.quad   .L3
.quad   .L3
.quad   .L3
.quad   .L3
.quad   .L3
.L3:
mov rax, QWORD PTR [rdi+8]
mov rdi, r8
mov rax, QWORD PTR [rax]
jmp rax
```

This case may seem contrived, but it's not that rare in practice, because code
using std::variant or equivalent (such as Boost.Variant2, from which the
example has been reduced) is becoming more and more common nowadays.

[Bug c++/63707] Brace initialization of array sometimes fails if no copy constructor

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

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

Marek Polacek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

[Bug c++/63707] Brace initialization of array sometimes fails if no copy constructor

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

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

Marek Polacek  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
 CC||mpolacek at gcc dot gnu.org

--- Comment #15 from Marek Polacek  ---
Looking.

[Bug target/98647] Failure to optimize out convertion from float to vector type

[gabravier at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Gabriel Ravier  ---
I have just looked at the ABI and it just says that floats/doubles are passed
in SSE registers, but does not seem to explicitly specify whether the upper
bits are cleared or not (it explicitly specifies that only the first 8 bits of
a _Bool return are specified: I would tend to deduce from that that by default,
the upper bits or a value are specified to be cleared).

[Bug target/98648] Failure to optimize out no-op vector operation using andnot

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ABI

--- Comment #1 from Andrew Pinski  ---
I think this is an ABI issue.  What does the ABI say about the other bits of
the SSE register for float passing?
This might be a clang/LLVM issue if the ABI says the other bits are not defined
to be 0.

[Bug target/98647] Failure to optimize out convertion from float to vector type

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ABI

--- Comment #1 from Andrew Pinski  ---
I think this is an ABI issue.  What does the x86_64 ABI say about the other
bits of the SSE register when passing float to a function?
It might be the case that clang/llvm is not implementing the ABI correctly.

[Bug target/98648] New: Failure to optimize out no-op vector operation using andnot

[gabravier at gmail dot com via Gcc-bugs]

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

Bug ID: 98648
   Summary: Failure to optimize out no-op vector operation using
andnot
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gabravier at gmail dot com
  Target Milestone: ---

__m128 f(__m128 val) 
{
return _mm_andnot_ps(_mm_set_ps1(0.0f), val);
}

This can be optimized to `return val;`. This optimization is done by LLVM, but
not by GCC.

[Bug target/98647] New: Failure to optimize out convertion from float to vector type

[gabravier at gmail dot com via Gcc-bugs]

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

Bug ID: 98647
   Summary: Failure to optimize out convertion from float to
vector type
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gabravier at gmail dot com
  Target Milestone: ---

float f(float val)
{
return _mm_cvtss_f32(_mm_and_ps(_mm_set_ss(val),
_mm_castsi128_ps(_mm_set1_epi32(0x7fff;
}

This can be optimized to avoid the conversions in the emitted assembly code.
This optimization is done by LLVM, but not by GCC.

LLVM code generation :

.LCPI1_0:
  .long 0x7fff # float NaN
  .long 0x7fff # float NaN
  .long 0x7fff # float NaN
  .long 0x7fff # float NaN
f(float): # @f(float)
  andps xmm0, xmmword ptr [rip + .LCPI1_0]
  ret

GCC code generation :

f(float):
  pxor xmm1, xmm1
  movss xmm1, xmm0
  movaps xmm0, XMMWORD PTR .LC1[rip]
  andps xmm0, xmm1
  ret

.LC1:
  .long 2147483647
  .long 2147483647
  .long 2147483647
  .long 2147483647

[Bug c++/98646] [11 Regression] A static_cast confuses -Wnonnull, causing false positives

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

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

Martin Sebor  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=96003
 Blocks||95507
 Status|UNCONFIRMED |NEW
   Keywords||diagnostic
Summary|A static_cast confuses  |[11 Regression] A
   |-Wnonnull, causing false|static_cast confuses
   |positives   |-Wnonnull, causing false
   ||positives
   Last reconfirmed||2021-01-13

--- Comment #1 from Martin Sebor  ---
Confirmed.  It must be an instance we missed in the fix for pr96003 where the
C++ front end adds a COND_EXPR to static_cast.

The larger context in the translation unit is:

  if (tp && tp->handle())
transientXcbParent = static_cast(tp->handle())->winId();

The caller guards against tp->handle() being null but the front end doesn't
consider that and adds another guard which then triggers the warning that also
runs in the front end.  The pr96003 fix works around the same problem by
setting the TREE_NO_WARNING bit so the same hack is needed wherever else the
front end builds a static_cast.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95507
[Bug 95507] [meta-bug] bogus/missing -Wnonnull

[Bug testsuite/98643] [11 regression] r11-6615 causes failure in gcc.target/powerpc/fold-vec-extract- char.p7.c

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

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

Segher Boessenkool  changed:

   What|Removed |Added

   Last reconfirmed||2021-01-13
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #2 from Segher Boessenkool  ---
Yeah, the last addi in the new addi/add/addi sequences is superfluous.

Confirmed.

[Bug testsuite/98643] [11 regression] r11-6615 causes failure in gcc.target/powerpc/fold-vec-extract- char.p7.c

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

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

--- Comment #1 from seurer at gcc dot gnu.org ---
Here's a context diff


seurer@genoa:~/gcc/git/build/gcc-test$ diff -c
fold-vec-extract-char.p7.s.r11-6614 fold-vec-extract-char.p7.s.r11-6615
*** fold-vec-extract-char.p7.s.r11-6614 Tue Jan 12 14:12:26 2021
--- fold-vec-extract-char.p7.s.r11-6615 Tue Jan 12 14:00:56 2021
***
*** 9,19 
  testbc_var:
  .LFB0:
.cfi_startproc
!   addi 10,1,-48
li 9,32
stvx 2,10,9
-   rldicl 5,5,0,60
-   add 5,10,5
lbz 3,32(5)
blr
.long 0
--- 9,20 
  testbc_var:
  .LFB0:
.cfi_startproc
!   rldicl 5,5,0,60
li 9,32
+   addi 10,5,-48
+   add 5,10,1
+   addi 10,1,-48
stvx 2,10,9
lbz 3,32(5)
blr
.long 0
***
*** 28,38 
  testsc_var:
  .LFB1:
.cfi_startproc
!   addi 10,1,-48
li 9,32
stvx 2,10,9
-   rldicl 5,5,0,60
-   add 5,10,5
lbz 3,32(5)
extsb 3,3
blr
--- 29,40 
  testsc_var:
  .LFB1:
.cfi_startproc
!   rldicl 5,5,0,60
li 9,32
+   addi 10,5,-48
+   add 5,10,1
+   addi 10,1,-48
stvx 2,10,9
lbz 3,32(5)
extsb 3,3
blr
***
*** 48,58 
  testuc_var:
  .LFB2:
.cfi_startproc
!   addi 10,1,-48
li 9,32
stvx 2,10,9
-   rldicl 5,5,0,60
-   add 5,10,5
lbz 3,32(5)
blr
.long 0
--- 50,61 
  testuc_var:
  .LFB2:
.cfi_startproc
!   rldicl 5,5,0,60
li 9,32
+   addi 10,5,-48
+   add 5,10,1
+   addi 10,1,-48
stvx 2,10,9
lbz 3,32(5)
blr
.long 0

[Bug tree-optimization/96674] Failure to optimize combination of comparisons to dec+compare

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
/* x < y || x == XXX_MIN --> x <= y - 1 */
(simplify
 (bit_ior (eq @1 min_value) (lt @0 @1))
  (if (INTEGRAL_TYPE_P (TREE_TYPE (@1))
   && TYPE_OVERFLOW_WRAPS (TREE_TYPE (@1)))
  (le @0 (minus @1 { build_int_cst (TREE_TYPE (@1), 1); }
The comment doesn't match what the simplification implements (x == XXX_MIN
should be y == XXX_MIN).
Furthermore, bit_ior is commutative and for the optimization no specific order
is needed, so probably bit_ior:c is needed.  Also, the optimization doesn't
seem to be worth if either eq or lt has multiple uses, so both should have :s
suffixes.  When x < y || y == min can be simplified into x <= y - 1, can't
its negation, i.e. x >= y && y != min be simplified into x > y - 1 ?
And agree on the noipa attribute, most of the tests you're citing just predate
the noipa attribute.  We had noinline for many years, later added noclone and
have been using noinline, noclone and when we started adding further IPA
optimizations, noipa has been added.

[Bug c++/63707] Brace initialization of array sometimes fails if no copy constructor

[pdimov at gmail dot com via Gcc-bugs]

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

Peter Dimov  changed:

   What|Removed |Added

 CC||pdimov at gmail dot com

--- Comment #14 from Peter Dimov  ---
FWIW, I just hit this problem as well when trying to make changes to
Boost.Variant2. My reduced test case is https://godbolt.org/z/zG6ddP; I was
going to submit that as a bug but found this one.

I support the petition to have this fixed.

[Bug tree-optimization/96674] Failure to optimize combination of comparisons to dec+compare

[gabravier at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Gabriel Ravier  ---
I'd assume those are for older test cases: __attribute__((noipa)) makes more
sense (at least to me) considering it's made specifically to prevent
inter-procedural optimization (which __attribute__((noinline)) does not, afaik)
which is helpful for testing specific optimizations on specific functions and
seeing whether the optimizations make those functions non-functional without
potentially having problems with inter-procedural optimization doing stuff like
constant-propagation or anything that could interfere with the proper testing
of a specific optimization.

[Bug c++/98645] C++ modules support does not work on PowerPC with IEEE 128-bit long double

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

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

--- Comment #1 from Segher Boessenkool  ---
(In reply to Michael Meissner from comment #0)
> I am tuning up the final patches for providing support to enable the PowerPC
> server compilers to change the default long double from using the IBM
> 128-bit double double format to IEEE 128-bit.

You mean "change the default for powerpc64le-*" I hope?  Most other
configurations we cannot change, certainly not before we allow IEEE QP
float everywhere.

> When the default long double is IEEE 128-bit, the powerpc backend needs to
> create a new type (__ibm128) to allow access to the old IBM 128-bit format. 
> It looks like the gcc/cp/module.cc code does not have a method of dealing
> with target specific floating point types.

If that is true, this should be a P1.  Please figure out if it is true!

[Bug analyzer/98599] fatal error: Cgraph edge statement index out of range with -Os -flto -fanalyzer

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

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

--- Comment #6 from David Malcolm  ---
(In reply to Martin Liška from comment #5)
> @David: Can you really reproduce that on x86_64-linux-gnu (I can't for some
> reason)?
Yes (with current master e.g. cfaaa6a1ca744c1a93fa08a3e7ab2a821383cac1), using
  -Os -flto -fanalyzer
and adding
  -v --save-temps
to debug it

[Bug tree-optimization/96674] Failure to optimize combination of comparisons to dec+compare

[erozen at microsoft dot com via Gcc-bugs]

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

--- Comment #3 from Eugene Rozenfeld  ---
Both are used but it looks like __attribute__((noinline)) is used more
frequently.
Under gcc/testsuite there are 1537 instances of __attribute__((noipa)) and 3794
instances of __attribute__((noinline)).

[Bug c++/98646] New: A static_cast confuses -Wnonnull, causing false positives

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

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

Bug ID: 98646
   Summary: A static_cast confuses -Wnonnull, causing false
positives
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ville.voutilainen at gmail dot com
  Target Milestone: ---

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

Compile with

/usr/local/bin/c++ -DQT_ASCII_CAST_WARNINGS -DQT_BUILDING_QT
-DQT_BUILD_XCB_PLUGIN -DQT_BUILD_XCB_QPA_LIB_LIB -DQT_CORE_LIB
-DQT_DEPRECATED_WARNINGS -DQT_DEPRECATED_WARNINGS_SINCE=0x06
-DQT_DISABLE_DEPRECATED_BEFORE=0x05 -DQT_GUI_LIB -DQT_MOC_COMPAT
-DQT_NO_CAST_TO_ASCII -DQT_NO_EXCEPTIONS -DQT_NO_FOREACH -DQT_OPENGL_LIB
-DQT_USE_QSTRINGBUILDER -DXcbQpa_EXPORTS -D_LARGEFILE64_SOURCE
-D_LARGEFILE_SOURCE -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -Wall
-Wextra -fno-exceptions -fPIC -Werror -Wno-error=cpp
-Wno-error=deprecated-declarations -Wno-error=strict-overflow
-Wno-error=implicit-fallthrough -Wno-error=deprecated-copy
-Wno-error=redundant-move -Wno-error=init-list-lifetime
-Wno-error=format-overflow -Wsuggest-override -std=c++17 -c winid-nonnull.cpp

The result is
/home/vivoutil/kuutti/kuuttikutonen/qt5/qtbase/src/plugins/platforms/xcb/qxcbwindow.cpp:
In member function ‘void QXcbWindow::show()’:
/home/vivoutil/kuutti/kuuttikutonen/qt5/qtbase/src/plugins/platforms/xcb/qxcbwindow.cpp:685:91:
error: ‘this’ pointer null [-Werror=nonnull]
  685 | transientXcbParent = static_cast(tp->handle())->winId();
  |
  ^
In file included from
/home/vivoutil/kuutti/kuuttikutonen/qt5/qtbase/src/plugins/platforms/xcb/qxcbwindow.cpp:40:
/home/vivoutil/kuutti/kuuttikutonen/qt5/qtbase/src/plugins/platforms/xcb/qxcbwindow.h:87:9:
note: in a call to non-static member function ‘virtual WId QXcbWindow::winId()
const’
   87 | WId winId() const override;
  | ^

Removing the static_cast removes the warning.

[Bug c++/98645] C++ modules support does not work on PowerPC with IEEE 128-bit long double

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

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

Michael Meissner  changed:

   What|Removed |Added

 CC||bergner at gcc dot gnu.org,
   ||dje at gcc dot gnu.org,
   ||meissner at gcc dot gnu.org,
   ||nathan at gcc dot gnu.org,
   ||segher at gcc dot gnu.org,
   ||wschmidt at gcc dot gnu.org
   Priority|P3  |P2
  Build||powerpc64le-gnu-linux
   Severity|normal  |major
 Target||powerpc64le-gnu-linux
   Host||powerpc64le-gnu-linux

[Bug c++/98645] New: C++ modules support does not work on PowerPC with IEEE 128-bit long double

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

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

Bug ID: 98645
   Summary: C++ modules support does not work on PowerPC with IEEE
128-bit long double
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: meissner at gcc dot gnu.org
  Target Milestone: ---

I am tuning up the final patches for providing support to enable the PowerPC
server compilers to change the default long double from using the IBM 128-bit
double double format to IEEE 128-bit.

When the default long double is IEEE 128-bit, the powerpc backend needs to
create a new type (__ibm128) to allow access to the old IBM 128-bit format.  It
looks like the gcc/cp/module.cc code does not have a method of dealing with
target specific floating point types.

If you build a compiler with IEEE 128-bit long double default, the following
tests now fail:

$ make check-c++ RUNTESTFLAGS=modules.exp

Running /home/meissner/fsf-src/trunk/gcc/testsuite/g++.dg/modules/modules.exp
...
FAIL: g++.dg/modules/binding-1_a.H -std=c++17 (internal compiler error)
FAIL: g++.dg/modules/binding-1_a.H -std=c++17 (test for excess errors)
FAIL: g++.dg/modules/binding-1_a.H module-cmi 
(gcm.cache/home/meissner/fsf-src/trunk/gcc/testsuite/g++.dg/modules/binding-1_a.H.gcm)
FAIL: g++.dg/modules/binding-1_b.H -std=c++17 (internal compiler error)
FAIL: g++.dg/modules/binding-1_b.H -std=c++17 (test for excess errors)
FAIL: g++.dg/modules/binding-1_b.H module-cmi 
(gcm.cache/home/meissner/fsf-src/trunk/gcc/testsuite/g++.dg/modules/binding-1_b.H.gcm)
FAIL: g++.dg/modules/binding-1_c.C -std=c++17 (test for excess errors)
FAIL: g++.dg/modules/binding-1_c.C module-cmi hello (gcm.cache/hello.gcm)
FAIL: g++.dg/modules/binding-1_a.H -std=c++2a (internal compiler error)
FAIL: g++.dg/modules/binding-1_a.H -std=c++2a (test for excess errors)
FAIL: g++.dg/modules/binding-1_a.H module-cmi 
(gcm.cache/home/meissner/fsf-src/trunk/gcc/testsuite/g++.dg/modules/binding-1_a.H.gcm)
FAIL: g++.dg/modules/binding-1_b.H -std=c++2a (internal compiler error)
FAIL: g++.dg/modules/binding-1_b.H -std=c++2a (test for excess errors)
FAIL: g++.dg/modules/binding-1_b.H module-cmi 
(gcm.cache/home/meissner/fsf-src/trunk/gcc/testsuite/g++.dg/modules/binding-1_b.H.gcm)
FAIL: g++.dg/modules/binding-1_c.C -std=c++2a (test for excess errors)
FAIL: g++.dg/modules/binding-1_c.C module-cmi hello (gcm.cache/hello.gcm)
FAIL: g++.dg/modules/hello-1_a.C -std=c++17 (internal compiler error)
FAIL: g++.dg/modules/hello-1_a.C -std=c++17 (test for excess errors)
FAIL: g++.dg/modules/hello-1_a.C module-cmi hello (gcm.cache/hello.gcm)
FAIL: g++.dg/modules/hello-1_b.C -std=c++17 (test for excess errors)
FAIL: g++.dg/modules/hello-1_a.C -std=c++2a (internal compiler error)
FAIL: g++.dg/modules/hello-1_a.C -std=c++2a (test for excess errors)
FAIL: g++.dg/modules/hello-1_a.C module-cmi hello (gcm.cache/hello.gcm)
FAIL: g++.dg/modules/hello-1_b.C -std=c++2a (test for excess errors)
FAIL: g++.dg/modules/iostream-1_a.H -std=c++17 (internal compiler error)
FAIL: g++.dg/modules/iostream-1_a.H -std=c++17 (test for excess errors)
FAIL: g++.dg/modules/iostream-1_a.H module-cmi 
(gcm.cache/home/meissner/fsf-src/trunk/gcc/testsuite/g++.dg/modules/iostream-1_a.H.gcm)
FAIL: g++.dg/modules/iostream-1_b.C -std=c++17 (test for excess errors)
FAIL: g++.dg/modules/iostream-1_a.H -std=c++2a (internal compiler error)
FAIL: g++.dg/modules/iostream-1_a.H module-cmi 
(gcm.cache/home/meissner/fsf-src/trunk/gcc/testsuite/g++.dg/modules/iostream-1_a.H.gcm)
FAIL: g++.dg/modules/iostream-1_b.C -std=c++2a (test for excess errors)
FAIL: g++.dg/modules/string-1_a.H -std=c++17 (internal compiler error)
FAIL: g++.dg/modules/string-1_a.H -std=c++17 (test for excess errors)
FAIL: g++.dg/modules/string-1_a.H module-cmi 
(gcm.cache/home/meissner/fsf-src/trunk/gcc/testsuite/g++.dg/modules/string-1_a.H.gcm)
FAIL: g++.dg/modules/string-1_b.C -std=c++17 (test for excess errors)
FAIL: g++.dg/modules/string-1_a.H -std=c++2a (internal compiler error)
FAIL: g++.dg/modules/string-1_a.H -std=c++2a (test for excess errors)
FAIL: g++.dg/modules/string-1_a.H module-cmi 
(gcm.cache/home/meissner/fsf-src/trunk/gcc/testsuite/g++.dg/modules/string-1_a.H.gcm)
FAIL: g++.dg/modules/string-1_b.C -std=c++2a (test for excess errors)
FAIL: g++.dg/modules/xtreme-header-1_a.H -std=c++17 (internal compiler error)
FAIL: g++.dg/modules/xtreme-header-1_a.H -std=c++17 (test for excess errors)
FAIL: g++.dg/modules/xtreme-header-1_a.H module-cmi 
(gcm.cache/home/meissner/fsf-src/trunk/gcc/testsuite/g++.dg/modules/xtreme-header-1_a.H.gcm)
FAIL: g++.dg/modules/xtreme-header-1_b.C -std=c++17 (test for excess errors)
FAIL: g++.dg/modules/xtreme-header-1_c.C -std=c++17 (test for excess errors)
FAIL: g++.dg/modules/xtreme-header-1_a.H -std=c++2a (internal compiler error)
FAIL: 

[Bug fortran/93340] [8/9/10/11 Regression] ICE in check_constant_initializer, at fortran/trans-decl.c:5450

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

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

--- Comment #6 from anlauf at gcc dot gnu.org ---
Tentative patch: https://gcc.gnu.org/pipermail/fortran/2021-January/055589.html

[Bug c/98592] [11 Regression] ICE in gimple_canonical_types_compatible_p while formatting a MEM_REF

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

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Sebor  ---
I've changed it to TYPE_MAIN_VARIANT in r11-6621.  It didn't cause any
testsuite fallout so it wasn't being sufficiently tested anyway.  If it in the
future turns out that something more involved is necessary let's revisit it
then.

[Bug go/98610] syscall.TestUnshareUidGidMapping sporadically fails on powerpc64le

[ian at airs dot com via Gcc-bugs]

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

Ian Lance Taylor  changed:

   What|Removed |Added

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

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

[Bug go/98610] syscall.TestUnshareUidGidMapping sporadically fails on powerpc64le

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

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

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

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

commit r11-6622-gcfaaa6a1ca744c1a93fa08a3e7ab2a821383cac1
Author: Paul E. Murphy 
Date:   Fri Jan 8 15:43:54 2021 -0600

syscall: ensure openat uses variadic libc wrapper

On powerpc64le, this caused a failure in TestUnshareUidGidMapping
due to stack corruption which resulted in a bogus execve syscall.

Use the existing c wrapper to ensure we respect the ppc abi for
variadic functions.

Fixes PR go/98610

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

[Bug c++/98642] [10/11 Regression] wrong "use of deleted function" error

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

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

Jason Merrill  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org
   Last reconfirmed||2021-01-12
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org

[Bug c++/98644] New: [concepts] ICE in satisfaction_value, at cp/constraint.cc:2825

[arthur.j.odwyer at gmail dot com via Gcc-bugs]

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

Bug ID: 98644
   Summary: [concepts] ICE in satisfaction_value, at
cp/constraint.cc:2825
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arthur.j.odwyer at gmail dot com
  Target Milestone: ---

// https://godbolt.org/z/qh1zos
template concept Signed = bool(T(1));
static_assert(Signed);

Compile with "-std=c++20":

:2:28: internal compiler error: in satisfaction_value, at
cp/constraint.cc:2825
2 | static_assert(Signed);
  |^
0x1cc31d9 internal_error(char const*, ...)
???:0
0x6b25f7 fancy_abort(char const*, int, char const*)
???:0
0x7390d2 evaluate_concept_check(tree_node*, int)
???:0
0x7255f4 maybe_constant_value(tree_node*, tree_node*, bool)
???:0
0x97ffcd finish_static_assert(tree_node*, tree_node*, unsigned int, bool, bool)
???:0

Another very similar ICE, even though the stack trace is different:

// https://godbolt.org/z/rPn6vd
bool Signed = requires { requires bool((char *)1); };

:1:35: internal compiler error: in satisfaction_value, at
cp/constraint.cc:2825
1 | bool Signed = requires { requires bool((char *)1); };
  |  ~^~~
0x1cc31d9 internal_error(char const*, ...)
???:0
0x6b25f7 fancy_abort(char const*, int, char const*)
???:0
0x737597 tsubst_requires_expr(tree_node*, tree_node*, int, tree_node*)
???:0

[Bug tree-optimization/96691] Failure to optimize bitwise not+or+xor with constants to and+xor with bitwise not-ed constants

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
(~x | 123) ^ 321 can't be replaced by (x | 123) ^ ~321, that is not equivalent.
I think the equivalencies this is based on are that for any X, C, D
((~X | C) ^ D) == ((X | C) ^ (~D ^ C))
and
((~X & C) ^ D) == ((X & C) ^ (D ^ C))
so if C and D are integral constants (scalar or vector), we should simplify it
that way, and furthermore I'd say we should simplify
(X | Y) ^ (~Z ^ Y)
into
(~X | Y) ^ Z
as the latter has fewer operations.

[Bug testsuite/98643] New: [11 regression] r11-6615 causes failure in gcc.target/powerpc/fold-vec-extract- char.p7.c

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

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

Bug ID: 98643
   Summary: [11 regression] r11-6615 causes failure in
gcc.target/powerpc/fold-vec-extract- char.p7.c
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:cf2ac1c30af0fa783c8d72e527904dda5d8cc330, r11-6615

make  -k check-gcc
RUNTESTFLAGS="powerpc.exp=gcc.target/powerpc/fold-vec-extract-
char.p7.c"
FAIL: gcc.target/powerpc/fold-vec-extract-char.p7.c scan-assembler-times
\\maddi\\M 6
# of expected passes7
# of unexpected failures1

Some extra expected assembler output addi instructions.  The difference in the
assembler is this:

12,15d11
<   rldicl 5,5,0,60
<   li 9,32
<   addi 10,5,-48
<   add 5,10,1
16a13
>   li 9,32
17a15,16
>   rldicl 5,5,0,60
>   add 5,10,5
32,35d30
<   rldicl 5,5,0,60
<   li 9,32
<   addi 10,5,-48
<   add 5,10,1
36a32
>   li 9,32
37a34,35
>   rldicl 5,5,0,60
>   add 5,10,5
53,56d50
<   rldicl 5,5,0,60
<   li 9,32
<   addi 10,5,-48
<   add 5,10,1
57a52
>   li 9,32
58a54,55
>   rldicl 5,5,0,60
>   add 5,10,5

So it looks like 3 extra addi's are generated.

[Bug tree-optimization/98597] [11 Regression] ICE in print_mem_ref since r11-6508-gabb1b6058c09a7c0

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

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

--- Comment #6 from Jakub Jelinek  ---
This is not a proper fix, you avoid the ICEs perhaps, but keep printing
completely bogus output for many cases.

[Bug c/98592] [11 Regression] ICE in gimple_canonical_types_compatible_p while formatting a MEM_REF

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Martin Sebor :

https://gcc.gnu.org/g:5a9cfad2de92f2d65585774acb524b3fa17621b5

commit r11-6621-g5a9cfad2de92f2d65585774acb524b3fa17621b5
Author: Martin Sebor 
Date:   Tue Jan 12 12:58:27 2021 -0700

Avoid a couple more ICEs in print_mem_ref (PR c/98597).

Resolves:
PR c/98597 - ICE in -Wuninitialized printing a MEM_REF
PR c/98592 - ICE in gimple_canonical_types_compatible_p while formatting

gcc/c-family/ChangeLog:

PR c/98597
PR c/98592
* c-pretty-print.c (print_mem_ref): Avoid assuming MEM_REF operand
has pointer type.  Remove redundant code.  Avoid calling
gimple_canonical_types_compatible_p.

gcc/testsuite/ChangeLog:

PR c/98597
PR c/98592
* g++.dg/warn/Wuninitialized-13.C: New test.
 gcc.dg/uninit-39.c: New test.

#

[Bug tree-optimization/98597] [11 Regression] ICE in print_mem_ref since r11-6508-gabb1b6058c09a7c0

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

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

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

https://gcc.gnu.org/g:5a9cfad2de92f2d65585774acb524b3fa17621b5

commit r11-6621-g5a9cfad2de92f2d65585774acb524b3fa17621b5
Author: Martin Sebor 
Date:   Tue Jan 12 12:58:27 2021 -0700

Avoid a couple more ICEs in print_mem_ref (PR c/98597).

Resolves:
PR c/98597 - ICE in -Wuninitialized printing a MEM_REF
PR c/98592 - ICE in gimple_canonical_types_compatible_p while formatting

gcc/c-family/ChangeLog:

PR c/98597
PR c/98592
* c-pretty-print.c (print_mem_ref): Avoid assuming MEM_REF operand
has pointer type.  Remove redundant code.  Avoid calling
gimple_canonical_types_compatible_p.

gcc/testsuite/ChangeLog:

PR c/98597
PR c/98592
* g++.dg/warn/Wuninitialized-13.C: New test.
 gcc.dg/uninit-39.c: New test.

#

[Bug c++/98642] [10/11 Regression] wrong "use of deleted function" error

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

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

--- Comment #1 from Marek Polacek  ---
$ ./cc1plus -quiet 98642.C
98642.C: In instantiation of ‘C& bar() [with C = const foo]’:
98642.C:19:25:   required from here
98642.C:13:12: error: use of deleted function ‘base::base(base&&)’
   13 |   static C c{};
  |^
98642.C:4:3: note: declared here
4 |   base(base &&) = delete;
  |   ^~~~

[Bug c++/98642] [10/11 Regression] wrong "use of deleted function" error

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

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

Marek Polacek  changed:

   What|Removed |Added

Summary|wrong "use of deleted   |[10/11 Regression] wrong
   |function" error |"use of deleted function"
   ||error
   Priority|P3  |P1
   Target Milestone|--- |10.3
   Keywords||rejects-valid

[Bug c++/98642] New: wrong "use of deleted function" error

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

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

Bug ID: 98642
   Summary: wrong "use of deleted function" error
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

class base {
public:
  base(void) {};
  base(base &&) = delete;
};

class foo : public base {
};

template
inline C (void)
{
  static C c{};
  return c;
}

const foo (void)
{
  return bar();
}

is rejected since r11-2704 in C++17.  clang++/EDG accept this.

[Bug libstdc++/98605] [8/9/10 Regression] clang-tidy error parsing on libstdc++-v3

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

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

--- Comment #7 from Jonathan Wakely  ---
The original report said it was with 4.0.0

[Bug c/98627] GCC emits unaligned memory access instructions causing address error exceptions with the 68000 architecture

[noring at nocrew dot org via Gcc-bugs]

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

--- Comment #8 from Fredrik Noring  ---
Thanks, Mikael. Users evidently take whatever m68k-* GCC they have at hand and
so 68000-projects therefore must have a special configure test to verify that
-march=68000 isn't broken with the user's choice of GCC. I must say I do think
it's quite wrong to blame the user for this problem.

[Bug tree-optimization/98597] [11 Regression] ICE in print_mem_ref since r11-6508-gabb1b6058c09a7c0

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

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

--- Comment #4 from Jakub Jelinek  ---
Also, it seems the shortcut for MEM_REF [, 0] is only correct if the types
of var and MEM_REF are compatible, if I have say
struct S { int a, int b; } var;
then if MEM[, 0] has int type, then it shouldn't be printed as var, but as
*(int *) or so.
The patch has been committed without any patch review from what I can see, and
it really shows up that it hasn't been reviewed.
I think best would be to revert it, then fix all issues it has and then submit
for patch review.

[Bug libstdc++/98605] [8/9/10 Regression] clang-tidy error parsing on libstdc++-v3

[mizvekov at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Matheus Izvekov  ---
What clang-tidy version? From the date of the commit, it was probably no older
than 6, probably 4 or 5.
If that is too old and probably considered unsupported, I think that is fine.

But even if in the end it was a false positive, the warning seemed to me to be
of high quality, ie to some standard of coding practice, it would be advised to
document this somewhat subtle assumption. Not sure that applies to libstdc++
standards :)

But if you cannot reproduce the original warning anyway, then I guess it's
better to just remove it than make some change that can't even be tested.

[Bug tree-optimization/98640] [10/11 Regression] GCC produces incorrect code with -O1 and higher since r10-2711-g3ed01d5408045d80

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2021-01-12
Summary|GCC produces incorrect code |[10/11 Regression] GCC
   |with -O1 and higher |produces incorrect code
   ||with -O1 and higher since
   ||r10-2711-g3ed01d5408045d80
   Target Milestone|--- |10.3
 CC||marxin at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
  Known to fail||10.2.0, 11.0

--- Comment #1 from Martin Liška  ---
Thanks for the report, started with r10-2711-g3ed01d5408045d80.

[Bug tree-optimization/98597] [11 Regression] ICE in print_mem_ref since r11-6508-gabb1b6058c09a7c0

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||law at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
The bug is clear:
  const bool addr = TREE_CODE (arg) == ADDR_EXPR;
  if (addr)
{
  arg = TREE_OPERAND (arg, 0);
...
}
makes arg sometimes pointer and sometimes what the pointer points to (which can
be another pointer or something completely different).
So obviously
  tree arg_type = TREE_TYPE (TREE_TYPE (arg));
can't work reliably.
Either the arg = TREE_OPERAND (arg, 0); should be done only if byte_off == 0,
or everything else that uses TREE_TYPE (TREE_TYPE (arg)) needs to be changed to
do something different based on whether addr is true or false.
I'd note that having the same variable represent different levels of
indirection in the same code depending on some circumstances is a maintainance
nightmare.
E.g. instead of having a bool whether arg was originally ADDR_EXPR or not, it
might be better to keep arg as it is and have another tree that would represent
what arg points to if it is ADDR_EXPR, otherwise NULL_TREE.

[Bug bootstrap/98509] [11 Regression] BUGURL quotation problem in libcody

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

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #1 from Nathan Sidwell  ---
Fixed e2aa8a5f982 2021-01-11 | libcody: Simplify configure [PR 98414, 98509]

[Bug bootstrap/98414] [11 Regression] UBSAN bootstrap is broken: ubsan/ubsan_type_hash_itanium.cpp:162: undefined reference to `__dynamic_cast' since r11-6083-gb7dfc2074c78415d451eb34d1608016c80b1c41a

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

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #18 from Nathan Sidwell  ---
Fixed e2aa8a5f982 2021-01-11 | libcody: Simplify configure [PR 98414, 98509]

[Bug tree-optimization/96938] Failure to optimize bit-setting pattern when not using temporary

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
   Last reconfirmed||2021-01-12

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

Untested fix.

[Bug c/98592] [11 Regression] ICE in gimple_canonical_types_compatible_p while formatting a MEM_REF

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

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

Martin Sebor  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2021-01-12
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED
Summary|ICE in  |[11 Regression] ICE in
   |gimple_canonical_types_comp |gimple_canonical_types_comp
   |atible_p while formatting a |atible_p while formatting a
   |MEM_REF |MEM_REF

[Bug c++/98639] GCC accepts cast from Base to Derived in C++20 mode

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #6 from Marek Polacek  ---
Closing thus.  I'm not convinced that we need a new diagnostic for this.

[Bug c++/98639] GCC accepts cast from Base to Derived in C++20 mode

[arthur.j.odwyer at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Arthur O'Dwyer  ---
Meh, I guess this is just an unintended (but conforming) consequence of the
shifting C++17/20 rules. Jonathan links to
https://twitter.com/wakomeup/status/1274778577087627267 as another example:

// https://godbolt.org/z/WWr9b8 
Base b;
const Derived& rd = b; // ill-formed forever, I hope
const Derived& rd{b};  // ill-formed until '14, OK in '17 and later
const Derived& rd(b);  // ill-formed until '17, OK in '20 and later

It remains _surprising_ that you can make a `Derived` out of a `Base` in the
absence of a constructor... but that's just the new aggregate-paren-init rules
at work.
It remains _surprising_ that you can bind a `const Derived&` to a `Base&`
without a cast... but that's just the interaction of lifetime extension with
the new aggregate-init rules.

I do think it'd be nice for GCC to give some sort of diagnostic here. But I
guess it would have to be an opt-in diagnostic switch. And we already have that
switch today; it's called `-std=c++17`. ;)  So maybe there's really no way to
improve the situation here at all, and this can be closed as NOTABUG.

[Bug middle-end/95848] missing -Wuninitialized passing structs by value (VOPS)

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

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

Martin Sebor  changed:

   What|Removed |Added

 Ever confirmed|0   |1
  Known to fail||10.2.0, 11.0, 9.3.0
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-01-12

--- Comment #2 from Martin Sebor  ---
No improvement in GCC 11, even though passing structs by reference to const
pointer/reference arguments is diagnosed:

$ cat a.c && gcc -O2 -S -Wall -Wextra -fdump-tree-optimized=/dev/stdout a.c
struct S { int i; };

void f (const struct S*);
void g (struct S);

void ff (void)
{
  struct S s;
  f ();// -Wmaybe-uninitialized (good)
}

void gg (void)
{
  struct S s;
  g (s); // missing warning
}

a.c: In function ‘ff’:
a.c:9:3: warning: ‘s’ may be used uninitialized [-Wmaybe-uninitialized]
9 |   f ();// -Wmaybe-uninitialized (good)
  |   ^~
a.c:3:6: note: by argument 1 of type ‘const struct S *’ to ‘f’ declared here
3 | void f (const struct S*);
  |  ^
a.c:8:12: note: ‘s’ declared here
8 |   struct S s;
  |^

;; Function ff (ff, funcdef_no=0, decl_uid=1949, cgraph_uid=1, symbol_order=0)

void ff ()
{
  struct S s;

   [local count: 1073741824]:
  f ();
  s ={v} {CLOBBER};
  return;

}



;; Function gg (gg, funcdef_no=1, decl_uid=1953, cgraph_uid=2, symbol_order=1)

void gg ()
{
  struct S s;

   [local count: 1073741824]:
  g (s); [tail call]
  s ={v} {CLOBBER};
  return;

}

[Bug c++/98639] GCC accepts cast from Base to Derived in C++20 mode

[redbeard0531 at gmail dot com via Gcc-bugs]

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

Mathias Stearn  changed:

   What|Removed |Added

 CC||redbeard0531 at gmail dot com

--- Comment #4 from Mathias Stearn  ---
This really seems like it *is* supposed to be allowed based on simply following
the normal language rules for aggregates. It would probably require a special
case rule to prevent it from working. Is there something that leads you to
think that such a special case rule was forgotten, rather than the natural
outcome being expected?

[Bug c++/98641] Feature request: implement pointer alignment builtins

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

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

--- Comment #1 from ktkachov at gcc dot gnu.org ---
The component is marked as C++, but it would be good to have these in C as
well.

[Bug c++/98641] New: Feature request: implement pointer alignment builtins

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

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

Bug ID: 98641
   Summary: Feature request: implement pointer alignment builtins
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ktkachov at gcc dot gnu.org
  Target Milestone: ---

We received reports that users found the pointer alignment builtins provided by
LLVM useful in avoiding error-prone casting to and from intptr_t:
https://clang.llvm.org/docs/LanguageExtensions.html#alignment-builtins

It would be great if we could support them in GCC as well.

This would involve implementing:
Type __builtin_align_up(Type value, size_t alignment);
Type __builtin_align_down(Type value, size_t alignment);
bool __builtin_is_aligned(Type value, size_t alignment);

Using these builtins the compiler can also preserve pointer provenance
information  more easily.

[Bug tree-optimization/98640] New: GCC produces incorrect code with -O1 and higher

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

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

Bug ID: 98640
   Summary: GCC produces incorrect code with -O1 and higher
   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:
#include 

unsigned long long int var_0 = 18128133247277979402ULL;
long long int var_14 = 6557021550272328915LL;
unsigned long long int var_83 = 10966786425750692026ULL;

void test() {
  var_14 = var_0 + (bool)7;
  var_83 = 1 + (int)var_0; // 1 + 888395530
}

int main() {
test();
printf("%llu\n", var_83);
}

https://godbolt.org/z/axYx1f

>$ g++ -O0 driver.cpp && ./a.out 
888395531
>$ g++ -O1 driver.cpp && ./a.out 
18128133247277979403

gcc version 11.0.0 20210112 (cf2ac1c30af0fa783c8d72e527904dda5d8cc330)

[Bug c++/58993] incorrectly accept access of protected member method from derived class template

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #8 from Patrick Palka  ---
(In reply to Jonathan Wakely from comment #5)
> Warning-free testcase:
> 
> class base {
> private:
> void foo() { }
> };
> 
> template 
> struct bar : public base {
> void test() {
> (void) ::foo;  // should be rejected
> }
> };
> 
> template <>
> struct bar : public base {
> void test() {
> // ::foo;  // correctly rejected
> }
> };
> 
> int main() {
> bar().test();
> bar().test();
> }
> 
> Still accepted by trunk.
> 
> 
> Clang says:
> 
> 58993.cc:9:23: error: 'foo' is a private member of 'base'
> (void) ::foo;  // should be rejected
>   ^
> 58993.cc:3:10: note: declared private here
> void foo() { }
>  ^
> 1 error generated.
> 
> 
> and EDG says:
> 
> "58993.cc", line 9: error: function "base::foo" (declared at line 3) is
>   inaccessible
>   (void) ::foo;  // should be rejected
> ^
>   detected during instantiation of "void bar::test() [with T=int]"
> at line 21
> 
> 1 error detected in the compilation of "58993.cc".

With GCC 11 (after the PR41437 patch), we reject the first access only if
bar::test() is defined out-of-line:

class base {
private:
int foo() { }
};

template 
struct bar : public base {
void test();
};

template 
void bar::test() {
::foo;
}

int main() {
bar().test();
}

Investigating.

[Bug target/97875] suboptimal loop vectorization

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

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

Christophe Lyon  changed:

   What|Removed |Added

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

--- Comment #8 from Christophe Lyon  ---
Fixed on trunk

[Bug target/97875] suboptimal loop vectorization

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

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Christophe Lyon :

https://gcc.gnu.org/g:25bef68902f42f414f99626cefb2d3df81de7dc8

commit r11-6616-g25bef68902f42f414f99626cefb2d3df81de7dc8
Author: Christophe Lyon 
Date:   Tue Jan 12 16:47:27 2021 +

arm: Add movmisalign patterns for MVE (PR target/97875)

This patch adds new movmisalign_mve_load and store patterns for
MVE to help vectorization. They are very similar to their Neon
counterparts, but use different iterators and instructions.

Indeed MVE supports less vectors modes than Neon, so we use the
MVE_VLD_ST iterator where Neon uses VQX.

Since the supported modes are different from the ones valid for
arithmetic operators, we introduce two new sets of macros:

ARM_HAVE_NEON__LDST
  true if Neon has vector load/store instructions for 

ARM_HAVE__LDST
  true if any vector extension has vector load/store instructions for


We move the movmisalign expander from neon.md to vec-commond.md, and
replace the TARGET_NEON enabler with ARM_HAVE__LDST.

The patch also updates the mve-vneg.c test to scan for the better code
generation when loading and storing the vectors involved: it checks
that no 'orr' instruction is generated to cope with misalignment at
runtime.
This test was chosen among the other mve tests, but any other should
be OK. Using a plain vector copy loop (dest[i] = a[i]) is not a good
test because the compiler chooses to use memcpy.

For instance we now generate:
test_vneg_s32x4:
vldrw.32   q3, [r1]
vneg.s32  q3, q3
vstrw.32   q3, [r0]
bx  lr

instead of:
test_vneg_s32x4:
orr r3, r1, r0
lslsr3, r3, #28
bne .L15
vldrw.32q3, [r1]
vneg.s32  q3, q3
vstrw.32q3, [r0]
bx  lr
.L15:
push{r4, r5}
ldrdr2, r3, [r1, #8]
ldrdr5, r4, [r1]
rsbsr2, r2, #0
rsbsr5, r5, #0
rsbsr4, r4, #0
rsbsr3, r3, #0
strdr5, r4, [r0]
pop {r4, r5}
strdr2, r3, [r0, #8]
bx  lr

2021-01-12  Christophe Lyon  

PR target/97875
gcc/
* config/arm/arm.h (ARM_HAVE_NEON_V8QI_LDST): New macro.
(ARM_HAVE_NEON_V16QI_LDST, ARM_HAVE_NEON_V4HI_LDST): Likewise.
(ARM_HAVE_NEON_V8HI_LDST, ARM_HAVE_NEON_V2SI_LDST): Likewise.
(ARM_HAVE_NEON_V4SI_LDST, ARM_HAVE_NEON_V4HF_LDST): Likewise.
(ARM_HAVE_NEON_V8HF_LDST, ARM_HAVE_NEON_V4BF_LDST): Likewise.
(ARM_HAVE_NEON_V8BF_LDST, ARM_HAVE_NEON_V2SF_LDST): Likewise.
(ARM_HAVE_NEON_V4SF_LDST, ARM_HAVE_NEON_DI_LDST): Likewise.
(ARM_HAVE_NEON_V2DI_LDST): Likewise.
(ARM_HAVE_V8QI_LDST, ARM_HAVE_V16QI_LDST): Likewise.
(ARM_HAVE_V4HI_LDST, ARM_HAVE_V8HI_LDST): Likewise.
(ARM_HAVE_V2SI_LDST, ARM_HAVE_V4SI_LDST, ARM_HAVE_V4HF_LDST):
Likewise.
(ARM_HAVE_V8HF_LDST, ARM_HAVE_V4BF_LDST, ARM_HAVE_V8BF_LDST):
Likewise.
(ARM_HAVE_V2SF_LDST, ARM_HAVE_V4SF_LDST, ARM_HAVE_DI_LDST):
Likewise.
(ARM_HAVE_V2DI_LDST): Likewise.
* config/arm/mve.md (*movmisalign_mve_store): New pattern.
(*movmisalign_mve_load): New pattern.
* config/arm/neon.md (movmisalign): Move to ...
* config/arm/vec-common.md: ... here.

PR target/97875
gcc/testsuite/
* gcc.target/arm/simd/mve-vneg.c: Update test.

[Bug tree-optimization/96938] Failure to optimize bit-setting pattern when not using temporary

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

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

--- Comment #3 from Jakub Jelinek  ---
Plus the less reduced testcase:
void
baz (char *f, int o, char v)
{
  *f = (*f & ~(1 << o)) | (v << o);
}
On bar above, we match this during combine:
Trying 10, 11 -> 13:
   10: r96:SI=0xfffe
   11: {r98:SI=r96:SI<- 12:
   10: r95:SI=0xfffe
   11: {r97:QI#0=r95:SI<- 10:
8: r89:SI=0xfffe
9: {r91:QI#0=r89:SI<-= 8.

[Bug libstdc++/98384] [11 Regression] new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE

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

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

--- Comment #8 from Patrick Palka  ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #7)
> > --- Comment #6 from Patrick Palka  ---
> [...]
> > Thanks for testing!  Hmm, that execute failure is surprising.  I wonder just
> > how much we're diverging from the output of printf here.  If possible, could
> > you let me know the value of the locals 'to_chars_buffer', 'printf_buffer',
> > 'precision' and 'testcase' (ideally in hex form) at the point of the 
> > assertion
> > failure?
> 
> I'm seeing exactly the same failure mode on Solaris, both sparc and x86:
> 32-bit compilation PASSes, execution XFAILed, 64-bit compilation PASSes,
> too, but execution FAILs with the same assertion failure.
> 
> Here's what gdb prints for those variables (with the test compiled with
> -g3 -O0 where the assertion still fails):
> 
> (gdb) p to_chars_buffer
> $1 = "f.", 'f' , "ep+5380", '\000' 
> (gdb) p printf_buffer
> $2 = "0x1.", 'f' , "cp+5383", '\000' 
> (gdb) p precision
> No symbol "precision" in current context.
> (gdb) p testcase
> $3 = 5.56540347525605847154e+1620
> (gdb) p/x testcase
> $5 = 0x7fff

Thanks for this helpful info. 

>From what I can tell, the difference in output here is basically harmless.  The
two hexadecimal forms (in to_chars_buffer and printf_buffer) are equivalent,
though ours is one digit shorter.  Both hexadecimal forms are also valid
results of printf's %La specifier for this value.

Since the standard underspecifies the result of printf's %a specifier, and
since there's apparent implementation divergence, we shouldn't be verifying the
hex output of std::to_chars by comparing it with that of printf.  Instead we
should compare with the known correct value, or perhaps verify that applying
std::from_chars on the output yields the original value.

[Bug target/97969] [9/10/11 Regression][ARM/Thumb] Certain combo of codegen options leads to compilation infinite loop with growing memory use

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

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

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

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

commit r11-6615-gcf2ac1c30af0fa783c8d72e527904dda5d8cc330
Author: Vladimir N. Makarov 
Date:   Tue Jan 12 11:26:15 2021 -0500

[PR97969] LRA: Transform pattern `plus (plus (hard reg, const), pseudo)`
after elimination

LRA can loop infinitely on targets without `reg + imm` insns.  Register
elimination
on such targets can increase register pressure resulting in permanent
stack size increase and changing elimination offset.  To avoid such
situation, a simple
transformation can be done to avoid register pressure increase after
generating reload insns containing eliminated hard regs.

gcc/ChangeLog:

PR target/97969
* lra-eliminations.c (eliminate_regs_in_insn): Add transformation
of pattern 'plus (plus (hard reg, const), pseudo)'.

gcc/testsuite/ChangeLog:

PR target/97969
* gcc.target/arm/pr97969.c: New.

[Bug c/98627] GCC emits unaligned memory access instructions causing address error exceptions with the 68000 architecture

[mikpelinux at gmail dot com via Gcc-bugs]

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

--- Comment #7 from Mikael Pettersson  ---
The correct target to use in this case is m68k-elf.

[Bug libstdc++/98605] [8/9/10 Regression] clang-tidy error parsing on libstdc++-v3

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

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

--- Comment #5 from Jonathan Wakely  ---
I can't reproduce the original error reported in PR 82481 anyway. Maybe
clang-tidy got smarter (it doesn't show problems in system headers by default,
which helps).

Maybe we can just remove that code entirely.

[Bug tree-optimization/96938] Failure to optimize bit-setting pattern when not using temporary

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Reduced testcase:
void
foo (char *x, int y)
{
  *x &= ~(1 << y);
}

void
bar (char *x, int y)
{
  int t = *x & ~(1 << y);
  *x = t;
}
With type narrowing which only happens in the FEs right now, we are then unable
to match bt* instruction.

[Bug libstdc++/98605] [8/9/10 Regression] clang-tidy error parsing on libstdc++-v3

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |8.5
  Known to work||11.0, 7.2.0
  Known to fail||10.2.0, 7.3.0, 8.4.0, 9.3.0
Summary|clang-tidy error parsing|[8/9/10 Regression]
   | on libstdc++-v3 |clang-tidy error parsing
   || on libstdc++-v3

[Bug libstdc++/98605] clang-tidy error parsing on libstdc++-v3

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

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

--- Comment #4 from Jonathan Wakely  ---
Doh, I missed out the actual commit hash. It was:

commit d1e85aa999ab87009fa02a5261754fbaa69206f2

[Bug libstdc++/98605] clang-tidy error parsing on libstdc++-v3

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

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to Matheus Izvekov from comment #0)
> This was caused by the following commit:
> 
> ```
> commit 018813c8994b7dceab1b7d999e9c09654a22ef50

I can't identify that commit. The one in the GCC tree is:

Author: Jonathan Wakely 
AuthorDate: Fri Oct 13 13:39:24 2017

PR libstdc++/82481 Suppress clang-tidy warnings

PR libstdc++/82481
* include/std/mutex (call_once): Suppress clang-tidy warnings about
dangling references.

From-SVN: r253724

[Bug c++/98639] GCC accepts cast from Base to Derived in C++20 mode

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

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to Arthur O'Dwyer from comment #0)
> I actually suspect that this behavior is related to C++20's paren-init for
> aggregates;

Yes, and the change to allow aggregates to have base classes. Derived(b)
initializes the base class from b.

> it might even be conforming?

It is.

> But there's no way this behavior
> was *intentional.* A value of type Base shouldn't be castable to Derived.

Some people seem to think otherwise.

https://twitter.com/wakomeup/status/1274778577087627267

[Bug c++/98632] Warn about unspecified expression ordering for atomics with non-relaxed memory ordering.

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||diagnostic

--- Comment #1 from Jonathan Wakely  ---
Please provide a code example, showing the warnings you'd like for it.

[Bug target/97969] [9/10/11 Regression][ARM/Thumb] Certain combo of codegen options leads to compilation infinite loop with growing memory use

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

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

--- Comment #17 from Przemyslaw Wirkus  ---
(In reply to Vladimir Makarov from comment #16)
> (In reply to Przemyslaw Wirkus from comment #14)
> > Hi Vladimir,
> > 
> > I'm assigned to the issue and I'm working on it. I think I got the root
> > cause.
> > I'm in the process of creating a patch after I complete few tests.
> > 
> > kind regards
> > Przemyslaw
> 
> Sorry, it was not clear for me that somebody was working on the patch.  The
> bug is actually severe and should be classified as P1.
> 
> In any case, here is my patch fixing this.  The patch is in the attachment. 
> May be your patch will use a better approach.

No worries, we were looking at the problem from Arm's backend pov.
Regardless, please carry on with your patch for this PR as my solution was just
masking the core issue you've addressed.

Thank you for looking at this, cheers!

[Bug tree-optimization/85316] [meta-bug] VRP range propagation missed cases

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

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

Bug 98513 Summary: [10 Regression] Wrong code with -O3 since 
r10-2804-gbf05a3bbb58b3558
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98513

   What|Removed |Added

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

[Bug tree-optimization/98513] [10 Regression] Wrong code with -O3 since r10-2804-gbf05a3bbb58b3558

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||10.2.1
 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #15 from Richard Biener  ---
Fixed where it triggeed, but the issue is latent on older branches as well.

[Bug tree-optimization/98513] [10 Regression] Wrong code with -O3 since r10-2804-gbf05a3bbb58b3558

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

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

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

https://gcc.gnu.org/g:71878c08e967997b570b1acbd9ffef4234e94698

commit r10-9263-g71878c08e967997b570b1acbd9ffef4234e94698
Author: Richard Biener 
Date:   Wed Jan 6 09:26:55 2021 +0100

tree-optimization/98513 - fix bug in range intersection code

This fixes a premature optimization in the range intersection code
which assumes earlier branches have to be taken, not taking into
account that for symbolic ranges we cannot always compare endpoints.
The fix is to instantiate the compare deemed redundant (which then
fails as undecidable for the testcase).

2021-01-06  Richard Biener  

PR tree-optimization/98513
* value-range.cc (intersect_ranges): Compare the upper bounds
for the expected relation.

* gcc.dg/tree-ssa/pr98513.c: New testcase.

(cherry picked from commit a05cc70a6c1ae0e5b22e16f4d8d13995a38ea1f9)

[Bug target/96906] Failure to optimize __builtin_ia32_psubusw128 compared to 0 to __builtin_ia32_pminuw128 compared to operand

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #10 from Jakub Jelinek  ---
.

[Bug target/97969] [9/10/11 Regression][ARM/Thumb] Certain combo of codegen options leads to compilation infinite loop with growing memory use

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

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

--- Comment #16 from Vladimir Makarov  ---
(In reply to Przemyslaw Wirkus from comment #14)
> Hi Vladimir,
> 
> I'm assigned to the issue and I'm working on it. I think I got the root
> cause.
> I'm in the process of creating a patch after I complete few tests.
> 
> kind regards
> Przemyslaw

Sorry, it was not clear for me that somebody was working on the patch.  The bug
is actually severe and should be classified as P1.

In any case, here is my patch fixing this.  The patch is in the attachment. 
May be your patch will use a better approach.

[Bug target/97969] [9/10/11 Regression][ARM/Thumb] Certain combo of codegen options leads to compilation infinite loop with growing memory use

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

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

--- Comment #15 from Vladimir Makarov  ---
Created attachment 49955
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49955=edit
a patch fixing the PR

[Bug c++/98639] GCC accepts cast from Base to Derived in C++20 mode

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Whether it is valid or not will defer to language lawyers.
It started to be accepted with
r10-5137-g43aae289866f5ea55d187444520412554aa2e171
aka P0960R3 implementation.
And clang doesn't seem to implement P0960R3 yet, so not surprisingly it rejects
it.

[Bug c++/98639] GCC accepts cast from Base to Derived in C++20 mode

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
Started with r278939 indeed.  But note that
  return Derived{b};
is also accepted in C++17.

So I think it's not a gcc bug, but maybe we need to clarify with the CWG.

[Bug c++/98639] New: GCC accepts cast from Base to Derived in C++20 mode

[arthur.j.odwyer at gmail dot com via Gcc-bugs]

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

Bug ID: 98639
   Summary: GCC accepts cast from Base to Derived in C++20 mode
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arthur.j.odwyer at gmail dot com
  Target Milestone: ---

// https://godbolt.org/z/96EEPa
struct Base {};
struct Derived : Base {};
Derived t() { Base b; return Derived(b); }

// https://godbolt.org/z/G4covG
auto lam = [i=42]() { return i; };
struct Derived : decltype(lam) {
bool is_derived() const { return true; }
};
Derived t() { return Derived(lam); }

I actually suspect that this behavior is related to C++20's paren-init for
aggregates; it might even be conforming? But there's no way this behavior was
*intentional.* A value of type Base shouldn't be castable to Derived.

static_cast(b) is also accepted by GCC.

[Bug target/71233] [ARM, AArch64] missing AdvSIMD intrinsics

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

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

--- Comment #73 from Christophe Lyon  ---
As of 2021-01-12 (trunk r11-6612 g:e91910d3576eeac714c93ec25ea3b15012007903),
after applying the recipe from comment #6, the situation is:

* no missing aarch64 intrinsic

* List of A32/A64 intrinsics not present in arm/arm_neon:
vceqq_p64
vceqz_p64
vceqzq_p64
vcopy_lane_p64
vcopy_laneq_p64
vcopyq_lane_p64
vcopyq_laneq_p64
vcvtaq_s32_f32
vcvtaq_u32_f32
vcvta_s32_f32
vcvta_u32_f32
vcvtmq_s32_f32
vcvtmq_u32_f32
vcvtm_s32_f32
vcvtm_u32_f32
vcvtnq_s32_f32
vcvtnq_u32_f32
vcvtn_s32_f32
vcvtn_u32_f32
vcvtpq_s32_f32
vcvtpq_u32_f32
vcvtp_s32_f32
vcvtp_u32_f32
vld1_bf16_x2
vld1_bf16_x4
vld1_dup_bf16
vld1_p64_x2
vld1_p64_x3
vld1_p64_x4
vld1q_bf16_x2
vld1q_bf16_x4
vld1q_dup_bf16
vld1q_p64_x2
vld1q_p64_x3
vld1q_p64_x4
vrndi_f32
vrndiq_f32
vrndn_f64
vrndnq_f64
vrndns_f32
vst1_bf16_x2
vst1_bf16_x3
vst1_bf16_x4
vst1_p64_x2
vst1_p64_x3
vst1_p64_x4
vst1q_bf16_x2
vst1q_bf16_x3
vst1q_bf16_x4
vst1q_p64_x2
vst1q_p64_x4
vtstq_p64


* List of v7/a32/a64 intrinsics not present in arm/arm_neon.h:
vadd_p16
vadd_p64
vadd_p8
vaddq_p128
vaddq_p16
vaddq_p64
vaddq_p8
vclsq_u16
vclsq_u32
vclsq_u8
vcls_u16
vcls_u32
vcls_u8
vfma_n_f32
vfmaq_n_f32
vld1_bf16_x3
vld1_f16_x2
vld1_f16_x3
vld1_f16_x4
vld1_f32_x2
vld1_f32_x3
vld1_f32_x4
vld1_p16_x2
vld1_p16_x3
vld1_p16_x4
vld1_p8_x2
vld1_p8_x3
vld1_p8_x4
vld1q_bf16_x3
vld1q_f16_x2
vld1q_f16_x3
vld1q_f16_x4
vld1q_f32_x2
vld1q_f32_x3
vld1q_f32_x4
vld1q_p16_x2
vld1q_p16_x3
vld1q_p16_x4
vld1q_p8_x2
vld1q_p8_x3
vld1q_p8_x4
vld1q_s16_x2
vld1q_s16_x3
vld1q_s16_x4
vld1q_s32_x2
vld1q_s32_x3
vld1q_s32_x4
vld1q_s64_x2
vld1q_s64_x3
vld1q_s64_x4
vld1q_s8_x2
vld1q_s8_x3
vld1q_s8_x4
vld1q_u16_x2
vld1q_u16_x3
vld1q_u16_x4
vld1q_u32_x2
vld1q_u32_x3
vld1q_u32_x4
vld1q_u64_x2
vld1q_u64_x3
vld1q_u64_x4
vld1q_u8_x2
vld1q_u8_x3
vld1q_u8_x4
vld1_s16_x2
vld1_s16_x3
vld1_s16_x4
vld1_s32_x2
vld1_s32_x3
vld1_s32_x4
vld1_s64_x2
vld1_s64_x3
vld1_s64_x4
vld1_s8_x2
vld1_s8_x3
vld1_s8_x4
vld1_u16_x2
vld1_u16_x3
vld1_u16_x4
vld1_u32_x2
vld1_u32_x3
vld1_u32_x4
vld1_u64_x2
vld1_u64_x3
vld1_u64_x4
vld1_u8_x2
vld1_u8_x3
vld1_u8_x4
vld2q_dup_f16
vld2q_dup_f32
vld2q_dup_p16
vld2q_dup_p8
vld2q_dup_s16
vld2q_dup_s32
vld2q_dup_s8
vld2q_dup_u16
vld2q_dup_u32
vld2q_dup_u8
vld3q_dup_f16
vld3q_dup_f32
vld3q_dup_p16
vld3q_dup_p8
vld3q_dup_s16
vld3q_dup_s32
vld3q_dup_s8
vld3q_dup_u16
vld3q_dup_u32
vld3q_dup_u8
vld4q_dup_f16
vld4q_dup_f32
vld4q_dup_p16
vld4q_dup_p8
vld4q_dup_s16
vld4q_dup_s32
vld4q_dup_s8
vld4q_dup_u16
vld4q_dup_u32
vld4q_dup_u8
vmovn_high_s16
vmovn_high_s32
vmovn_high_s64
vmovn_high_u16
vmovn_high_u32
vmovn_high_u64
vreinterpretq_f64_u64
vst1_f16_x2
vst1_f16_x3
vst1_f16_x4
vst1_f32_x2
vst1_f32_x3
vst1_f32_x4
vst1_p16_x2
vst1_p16_x3
vst1_p16_x4
vst1_p8_x2
vst1_p8_x3
vst1_p8_x4
vst1q_f16_x2
vst1q_f16_x3
vst1q_f16_x4
vst1q_f32_x2
vst1q_f32_x3
vst1q_f32_x4
vst1q_p16_x2
vst1q_p16_x3
vst1q_p16_x4
vst1q_p64_x3
vst1q_p8_x2
vst1q_p8_x3
vst1q_p8_x4
vst1q_s16_x2
vst1q_s16_x3
vst1q_s16_x4
vst1q_s32_x2
vst1q_s32_x3
vst1q_s32_x4
vst1q_s64_x2
vst1q_s64_x3
vst1q_s64_x4
vst1q_s8_x2
vst1q_s8_x3
vst1q_s8_x4
vst1q_u16_x2
vst1q_u16_x3
vst1q_u16_x4
vst1q_u32_x2
vst1q_u32_x3
vst1q_u32_x4
vst1q_u64_x2
vst1q_u64_x3
vst1q_u64_x4
vst1q_u8_x2
vst1q_u8_x3
vst1q_u8_x4
vst1_s16_x2
vst1_s16_x3
vst1_s16_x4
vst1_s32_x2
vst1_s32_x3
vst1_s32_x4
vst1_s64_x2
vst1_s64_x3
vst1_s64_x4
vst1_s8_x2
vst1_s8_x3
vst1_s8_x4
vst1_u16_x2
vst1_u16_x3
vst1_u16_x4
vst1_u32_x2
vst1_u32_x3
vst1_u32_x4
vst1_u64_x2
vst1_u64_x3
vst1_u64_x4
vst1_u8_x2
vst1_u8_x3
vst1_u8_x4
vst3q_lane_p8
vst3q_lane_s8
vst3q_lane_u8

[Bug target/98636] [ARM] ICE on passing incompatible options for fp16 - global_options’ are modified in local context

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

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

--- Comment #9 from Martin Liška  ---
All right.
@Prathamesh: Can you run that in debugger and show what option foo is causing
the internal_error:

void
cl_optimization_compare (gcc_options *ptr1, gcc_options *ptr2)
{
...
  if (ptr1->x_foo != ptr2->x_help_foo)
internal_error ("% are modified in local context");

[Bug target/98636] [ARM] ICE on passing incompatible options for fp16 - global_options’ are modified in local context

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

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

--- Comment #8 from ktkachov at gcc dot gnu.org ---
(In reply to prathamesh3492 from comment #7)
> I think the error is correct.
> CCing Kyrill -- could you please confirm if the error is valid for
> above case ?
> Thanks!

Yes, -mfp16-format=alternative is incompatible with the intrinsics

[Bug tree-optimization/98282] [8/9/10 Regression] Segmentation fault when compiling with optimization >= 2

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

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

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

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

commit r10-9262-gedb7dbc25de455300ce066a2ebe728256ea46e3a
Author: Richard Biener 
Date:   Mon Jan 4 11:40:40 2021 +0100

tree-optimization/98282 - classify V_C_E as nary

This avoids running into memory reference code in compute_avail by
properly classifying unfolded reference trees on constants.

2021-01-04  Richard Biener  

PR tree-optimization/98282
* tree-ssa-sccvn.c (vn_get_stmt_kind): Classify tcc_reference on
invariants as VN_NARY.

* g++.dg/opt/pr98282.C: New testcase.

(cherry picked from commit 13b80a7d1b9b712651f5ece589634a6e57c26362)

[Bug c/98630] Seg-fault when using a goto after condition (if)

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

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

--- Comment #15 from Jakub Jelinek  ---
Yes, that -Wjump-misses-init or -Wc++-compat.

[Bug c/98630] Seg-fault when using a goto after condition (if)

[k.even-mendoza at imperial dot ac.uk via Gcc-bugs]

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

--- Comment #14 from Karine EM  ---
I did compile it that way: 
> gcc-10 -w -O2 r.c -pedantic -Wall -Wextra
but got no warnings at all. Should I add any flag?
Thanks!

[Bug c/98630] Seg-fault when using a goto after condition (if)

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

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

--- Comment #13 from Jakub Jelinek  ---
Then -Wjump-misses-init should warn even on the unreduced testcase...