[Bug target/99704] volatile is needed on asm statements in

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Hongtao.liu  ---
(In reply to Hongtao.liu from comment #2)
> How should we handle -march=native on hybrid core?

Nevermind, assume you're meaning the bellow parts are different on hybrid core
02H
EAX Cache and TLB Information 
EBX Cache and TLB Information.
ECX Cache and TLB Information.
EDX Cache and TLB Information.

[Bug debug/66728] [5 Regression] CONST_WIDE_INT causes corrupted DWARF debug info

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

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

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

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

commit r11-7757-gfc9c4e5fc50c7fcbd27d6cb3dd372f7da8216954
Author: Jakub Jelinek 
Date:   Mon Mar 22 08:52:04 2021 +0100

debug: Fix __int128 handling in dwarf2out [PR99562]

The PR66728 changes broke __int128 handling.
It emits wide_int numbers in their minimum unsigned precision
rather than in their full precision.
The problem is then that e.g. the DW_OP_implicit_value path:
  int_mode = as_a  (mode);
  loc_result = new_loc_descr (DW_OP_implicit_value,
  GET_MODE_SIZE (int_mode), 0);
  loc_result->dw_loc_oprnd2.val_class = dw_val_class_wide_int;
  loc_result->dw_loc_oprnd2.v.val_wide = ggc_alloc ();
  *loc_result->dw_loc_oprnd2.v.val_wide = rtx_mode_t (rtl,
int_mode);
emits invalid DWARF.  In particular this patch fixes there multiple
occurences of:
.byte   0x9e# DW_OP_implicit_value
.uleb128 0x10
.quad   0x
+   .quad   0
.quad   .LVL46  # Location list begin address (*.LLST40)
.quad   .LFE14  # Location list end address (*.LLST40)
where we said the value has 16 byte size but then only emitted 8 byte
value.
My understanding is that most of the places that use val_wide expect
the precision they chose (the one of the mode they want etc.), the only
exception is the add_const_value_attribute case where it deals with
VOIDmode CONST_WIDE_INTs, for that I agree when we don't have a mode
we need to fallback to minimum precision (not sure if maximum of
min_precision UNSIGNED and SIGNED wouldn't be better, then consumers
would know if it is signed or unsigned by looking at the MSB),
but that code already computes the precision, just decided to
create the wide_int with much larger precision (e.g. 512 bit
on x86_64).

2021-03-22  Jakub Jelinek  

PR debug/99562
PR debug/66728
* dwarf2out.c (get_full_len): Use get_precision rather than
min_precision.
(add_const_value_attribute): Make sure add_AT_wide argument has
precision prec rather than some very wide one.

[Bug debug/99562] Invalid debug info: objdump: Warning: Location list starting at offset 0x9c3 is not terminated.

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

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

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

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

commit r11-7757-gfc9c4e5fc50c7fcbd27d6cb3dd372f7da8216954
Author: Jakub Jelinek 
Date:   Mon Mar 22 08:52:04 2021 +0100

debug: Fix __int128 handling in dwarf2out [PR99562]

The PR66728 changes broke __int128 handling.
It emits wide_int numbers in their minimum unsigned precision
rather than in their full precision.
The problem is then that e.g. the DW_OP_implicit_value path:
  int_mode = as_a  (mode);
  loc_result = new_loc_descr (DW_OP_implicit_value,
  GET_MODE_SIZE (int_mode), 0);
  loc_result->dw_loc_oprnd2.val_class = dw_val_class_wide_int;
  loc_result->dw_loc_oprnd2.v.val_wide = ggc_alloc ();
  *loc_result->dw_loc_oprnd2.v.val_wide = rtx_mode_t (rtl,
int_mode);
emits invalid DWARF.  In particular this patch fixes there multiple
occurences of:
.byte   0x9e# DW_OP_implicit_value
.uleb128 0x10
.quad   0x
+   .quad   0
.quad   .LVL46  # Location list begin address (*.LLST40)
.quad   .LFE14  # Location list end address (*.LLST40)
where we said the value has 16 byte size but then only emitted 8 byte
value.
My understanding is that most of the places that use val_wide expect
the precision they chose (the one of the mode they want etc.), the only
exception is the add_const_value_attribute case where it deals with
VOIDmode CONST_WIDE_INTs, for that I agree when we don't have a mode
we need to fallback to minimum precision (not sure if maximum of
min_precision UNSIGNED and SIGNED wouldn't be better, then consumers
would know if it is signed or unsigned by looking at the MSB),
but that code already computes the precision, just decided to
create the wide_int with much larger precision (e.g. 512 bit
on x86_64).

2021-03-22  Jakub Jelinek  

PR debug/99562
PR debug/66728
* dwarf2out.c (get_full_len): Use get_precision rather than
min_precision.
(add_const_value_attribute): Make sure add_AT_wide argument has
precision prec rather than some very wide one.

[Bug target/71009] g++: ICE on modified gdb/valarith.c with -Ofast

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #15 from Martin Liška  ---
I'm closing this, please open a separate issue.

[Bug middle-end/99689] Initialized local variable becomes uninitialized after use

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1
   Last reconfirmed||2021-03-22
 CC||marxin at gcc dot gnu.org

--- Comment #3 from Martin Liška  ---
I also cannot reproduce it with any GCC compiler version newer than 8.1.0.

[Bug middle-end/99694] [9/10/11 Regression] gcc: fatal error: Killed signal terminated program cc1 under -O2 to -Os since r9-7156-g33579b59aaf02eb7

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

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

Martin Liška  changed:

   What|Removed |Added

Summary|gcc: fatal error: Killed|[9/10/11 Regression] gcc:
   |signal terminated program   |fatal error: Killed signal
   |cc1 under -O2 to -Os|terminated program cc1
   ||under -O2 to -Os since
   ||r9-7156-g33579b59aaf02eb7
 CC||law at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-03-22

--- Comment #1 from Martin Liška  ---
Confirmed, started with r9-7156-g33579b59aaf02eb7.

[Bug middle-end/99689] Initialized local variable becomes uninitialized after use

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
Have you tried with -fpie and whatever other non-default options Ubuntu enables
by default?

[Bug target/99703] gcc-10.2.0 with Via C3 Eden: configure: error: Intel CET must be enabled on Intel CET enabled host

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

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2021-03-22
 Status|UNCONFIRMED |WAITING
 CC||marxin at gcc dot gnu.org

--- Comment #2 from Martin Liška  ---
It seems the binutils was fixed. Does it help in your scenario?

[Bug target/99702] [11 Regression] ICE: RTL check: expected code 'const_int', have 'subreg' in riscv_expand_block_move, at config/riscv/riscv.c:3262 with memcpy() since r11-7757-gfc9c4e5fc50c7fcbd27d6

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

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

Martin Liška  changed:

   What|Removed |Added

Summary|[11 Regression] ICE: RTL|[11 Regression] ICE: RTL
   |check: expected code|check: expected code
   |'const_int', have 'subreg'  |'const_int', have 'subreg'
   |in riscv_expand_block_move, |in riscv_expand_block_move,
   |at  |at
   |config/riscv/riscv.c:3262   |config/riscv/riscv.c:3262
   |with memcpy()   |with memcpy() since
   ||r11-7757-gfc9c4e5fc50c7fcbd
   ||27d6cb3dd372f7da8216954
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2021-03-22
   Target Milestone|--- |11.0
 CC||marxin at gcc dot gnu.org,
   ||sinan.lin at aalto dot fi
  Known to work||10.2.0

--- Comment #2 from Martin Liška  ---
Started with r11-7757-gfc9c4e5fc50c7fcbd27d6cb3dd372f7da8216954.

[Bug middle-end/99694] [9/10/11 Regression] gcc: fatal error: Killed signal terminated program cc1 under -O2 to -Os since r9-7156-g33579b59aaf02eb7

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |9.4

--- Comment #2 from Jakub Jelinek  ---
Seems the hang is during VN in the PRE pass, after a short while we keep
cycling between process_bb on
 [local count: 719407025]:
# k_14 = PHI 
# f_28 = PHI 
# g_30 = PHI 
# e_10 = PHI 
*g_30 = 0;
e.1_2 = e_10;
_3 = e.1_2 + 1;
e_13 = _3;
e.3_4 = e_13;
if (e.3_4 != 0)
  goto ; [0.00%]
else
  goto ; [100.00%]
and on
 [local count: 0]:
goto ; [100.00%]
forever.

[Bug target/99702] [11 Regression] ICE: RTL check: expected code 'const_int', have 'subreg' in riscv_expand_block_move, at config/riscv/riscv.c:3262 with memcpy() since r11-7757-gfc9c4e5fc50c7fcbd27d6

[zsojka at seznam dot cz via Gcc-bugs]

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

--- Comment #3 from Zdenek Sojka  ---
(In reply to Martin Liška from comment #2)
> Started with r11-7757-gfc9c4e5fc50c7fcbd27d6cb3dd372f7da8216954.

Thank you for the analysis! However I don't think that's possible, since I was
observing the failure on r11-7753 ; I even reported this before r11-7757 was
available.

[Bug target/99702] [11 Regression] ICE: RTL check: expected code 'const_int', have 'subreg' in riscv_expand_block_move, at config/riscv/riscv.c:3262 with memcpy() since r11-7757-gfc9c4e5fc50c7fcbd27d6

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

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

Kito Cheng  changed:

   What|Removed |Added

 CC||kito at gcc dot gnu.org
 Status|NEW |ASSIGNED

--- Comment #4 from Kito Cheng  ---
Hi Zdenek:
Confirmed, and has fix patch, it's trivial fix, so I'll commit the fix after
test.

I believe its cause by this patch:

https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=d9f0ade001533c9544bf2153b6baa8844ec0bee4


Hi Martin:

Thanks for the info :)

[Bug target/99702] [11 Regression] ICE: RTL check: expected code 'const_int', have 'subreg' in riscv_expand_block_move, at config/riscv/riscv.c:3262 with memcpy() since g:d9f0ade001533c9544bf2153b6baa

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

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

Martin Liška  changed:

   What|Removed |Added

Summary|[11 Regression] ICE: RTL|[11 Regression] ICE: RTL
   |check: expected code|check: expected code
   |'const_int', have 'subreg'  |'const_int', have 'subreg'
   |in riscv_expand_block_move, |in riscv_expand_block_move,
   |at  |at
   |config/riscv/riscv.c:3262   |config/riscv/riscv.c:3262
   |with memcpy() since |with memcpy() since
   |r11-7757-gfc9c4e5fc50c7fcbd |g:d9f0ade001533c9544bf2153b
   |27d6cb3dd372f7da8216954 |6baa8844ec0bee4

--- Comment #5 from Martin Liška  ---
Yes, sorry, I made a copy&paste error, it's really
g:d9f0ade001533c9544bf2153b6baa8844ec0bee4.

[Bug c++/99705] New: [10/11 Regression] ICE in expand_expr_real_1 since r10-3661

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

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

Bug ID: 99705
   Summary: [10/11 Regression] ICE in expand_expr_real_1 since
r10-3661
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

template
struct C
{
C() { f(); }
~C() {}
static void f() {}
};

struct X
{
X();
int n = 10;
C* p = new C[n];
};

X::X()
{}

ICEs with -std=c++14 starting with my
r10-3661-g8e007055dd1374ca4c44406a4ead172be0dfa3a8

[Bug c++/99705] [10/11 Regression] ICE in expand_expr_real_1 since r10-3661

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

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

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
   Priority|P3  |P2
   Last reconfirmed||2021-03-22
   Target Milestone|--- |10.3

[Bug fortran/99688] AddressSanitizer: stack-buffer-overflow on address at gfc_match_name(char*) gcc/fortran/match.c:685

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

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

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

https://gcc.gnu.org/g:0e792ee11aa6ebb6f61e9ed33eb06e260f0ec703

commit r11-7758-g0e792ee11aa6ebb6f61e9ed33eb06e260f0ec703
Author: Tobias Burnus 
Date:   Mon Mar 22 09:49:48 2021 +0100

Fortran: Fix 'name' bound size [PR99688]

gcc/fortran/ChangeLog:

PR fortran/99688
* match.c (select_type_set_tmp, gfc_match_select_type,
gfc_match_select_rank): Fix 'name' buffersize to avoid out of
bounds.
* resolve.c (resolve_select_type): Likewise.

[Bug sanitizer/99673] [11 Regression] bogus -Wstringop-overread warning with address sanitizer due to member address substitution

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |11.0

[Bug c++/99675] [10/11 Regression] ICE during template deduction since r10-5020-g1a291106384cabc7

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

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

Richard Biener  changed:

   What|Removed |Added

Summary|[11 Regression] ICE during  |[10/11 Regression] ICE
   |template deduction since|during template deduction
   |r10-5020-g1a291106384cabc7  |since
   ||r10-5020-g1a291106384cabc7
   Target Milestone|--- |10.3
   Priority|P3  |P2
  Known to work|10.2.0  |
  Known to fail||10.2.0

[Bug c++/99677] [[gnu::const]] attribute does not prevent dead global variable gets emitted.

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

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

--- Comment #5 from Richard Biener  ---
I think Andrew is correct.  Note we can't elide "unused" not statically
initialized variables (since the initialization is seen as use).

[Bug c/99693] -O2 not move 'if' checks on const data outside the loops

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
Yes, if you want to stick to -O2 use -funswitch-loops.

[Bug middle-end/99694] [9/10/11 Regression] gcc: fatal error: Killed signal terminated program cc1 under -O2 to -Os since r9-7156-g33579b59aaf02eb7

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

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

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  ---
Mine.

[Bug c++/99677] [[gnu::const]] attribute does not prevent dead global variable gets emitted.

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #6 from cqwrteur  ---
(In reply to Richard Biener from comment #5)
> I think Andrew is correct.  Note we can't elide "unused" not statically
> initialized variables (since the initialization is seen as use).

but here the result is always the same from importing functions from ntdll.dll
or kernel32.dll

[Bug c++/99677] [[gnu::const]] attribute does not prevent dead global variable gets emitted.

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #7 from Jakub Jelinek  ---
As the functions aren't constexpr, they aren't even considered during C++ FE
constexpr processing.  gnu::const means something completely different.
I bet we optimize away static const variables only written (even with
non-constant initializers) and never address taken or otherwise used, this PR
seems to ask to handle inline const (with the C++ FE specific behavior for
them) in such cases too.
I'm not sure it is valid if the vars are odr-used somewhere and the odr-uses
are later optimized away, I think emitting the inline vars in that case is part
of the ABI.  And the not odr-used cases which are only used by their
initialization is yet another question.

[Bug c++/95985] [11 Regression] ICE: tree check: expected tree_list, have error_mark in common_handle_aligned_attribute, at c-family/c-attribs.c:1980

[asolokha at gmx dot com via Gcc-bugs]

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

--- Comment #3 from Arseny Solokha  ---
I cannot reproduce it w/ yesterday's gcc-11.0.1-alpha20210321 snapshot
(g:fc24ea2374259d401a46ce3526688b7e79d4cc13).

[Bug tree-optimization/98655] 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

--- Comment #3 from Arseny Solokha  ---
I cannot reproduce it w/ yesterday's gcc-11.0.1-alpha20210321 snapshot
(g:fc24ea2374259d401a46ce3526688b7e79d4cc13).

[Bug ipa/99696] lto looks past aliases to initializers

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

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

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
  Known to fail||10.2.1, 11.0, 7.5.0
 Status|UNCONFIRMED |NEW
Version|unknown |10.2.1
   Last reconfirmed||2021-03-22
  Component|middle-end  |ipa
 CC||hubicka at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org

--- Comment #2 from Richard Biener  ---
Confirmed.  Honza, can you please have a look? 

The cgraph dump shows:

x/5 (x) @0x7637b180
  Type: variable definition analyzed
  Visibility: prevailing_def_ironly
  References:
  Referring: y/6 (alias) init/7 (write)
  Read from file: ./a.ltrans0.o
  Availability: available
  Varpool flags:
y/6 (y) @0x7637b080
  Type: variable definition analyzed alias
  Visibility: prevailing_def_ironly
  References: x/5 (alias)
  Referring: main/0 (read)
  Read from file: ./a.ltrans0.o
  Availability: available
  Varpool flags: read-only const-value-known

so indeed somehow the read-only flag is "miscomputed".

OTOH I remember that we chose to "ignore" mismatches in constness for aliases
and thus simply declare this use unsupported (there have been related
bugreports IIRC around const / non-const mixing in aliases).
Note we do not have ODR warnings for y vs. x though.

[Bug target/99706] New: [11 Regression] ICE: maximum number of generated reload insns per insn achieved (90)

[asolokha at gmx dot com via Gcc-bugs]

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

Bug ID: 99706
   Summary: [11 Regression] ICE: maximum number of generated
reload insns per insn achieved (90)
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---
Target: aarch64-linux-gnu

gcc-11.0.1-alpha20210321 snapshot (g:fc24ea2374259d401a46ce3526688b7e79d4cc13)
ICEs when compiling the following testcase w/ -O2 -ftree-loop-vectorize
-fno-tree-pta --param scev-max-expr-size=5:

int kk;

void
ii (int BUFSIZE)
{
  char buf[BUFSIZE], *ptr = buf;
  int i;

  for (i = 0; i < BUFSIZE; i++)
*ptr++ = kk = 0;
}

% aarch64-linux-gnu-gcc-11.0.1 -O2 -ftree-loop-vectorize -fno-tree-pta --param
scev-max-expr-size=5 -c oeplxogh.c
during RTL pass: reload
oeplxogh.c: In function 'ii':
oeplxogh.c:11:1: internal compiler error: maximum number of generated reload
insns per insn achieved (90)
   11 | }
  | ^
0xd42ab0 lra_constraints(bool)
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210321/work/gcc-11-20210321/gcc/lra-constraints.c:5091
0xd2b3e5 lra(_IO_FILE*)
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210321/work/gcc-11-20210321/gcc/lra.c:2336
0xce15c4 do_reload
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210321/work/gcc-11-20210321/gcc/ira.c:5834
0xce15c4 execute
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210321/work/gcc-11-20210321/gcc/ira.c:6020

I believe it is different from PR97141.

[Bug target/99703] gcc-10.2.0 with Via C3 Eden: configure: error: Intel CET must be enabled on Intel CET enabled host

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

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

--- Comment #3 from Richard Biener  ---
Try --disable-cet as a workaround

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

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Liška  ---
Thus fixed.

[Bug target/99706] [11 Regression] ICE: maximum number of generated reload insns per insn achieved (90)

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Thos are some interesting options.  How did you decide to use them?

Note the options used here are unrelated to the ICE though.

[Bug c/99693] -O2 not move 'if' checks on const data outside the loops

[rafal at bursig dot org via Gcc-bugs]

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

--- Comment #4 from rafal at bursig dot org ---
but using  -O2 -funswitch-loops will bring me those problems why this flag is
not in default -O2. Which is not a solution.

Maybe -O2 may have weaken version of this optimization and will work only if
one of if brock is empty. And -O3 will have full version. 

Example:

form:
for(...)
{
 if (local_value)
 {
   logic;
 }
}
To:
if (local_value)
for(...)
{
   logic;
}

I know that such code could be fixed by developer but gcc don't generate any
diagnostic message about such constructions and for a large project it's
difficult to find all of such places

[Bug c++/89565] [C++2a] ICE on template instantiating user defined non-type template from template value member

[falemagn at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Fabio Alemagna  ---
Just encountered this bug myself, with trunk gcc (11.0.1 20210321
(experimental)).

See godbolt: https://godbolt.org/z/TxW137Whh

[Bug target/55656] objc/obj-c++ failures present under darwin11

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

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

--- Comment #7 from Iain Sandoe  ---
fixed on master
e.g.
https://gcc.gnu.org/pipermail/gcc-testresults/2021-March/669584.html

[Bug target/99706] [11 Regression] ICE: maximum number of generated reload insns per insn achieved (90)

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2021-03-22
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #2 from Andrew Pinski  ---
It is this RTL which is causing the issue:
(insn 31 27 29 4 (set (reg:V2DI 125 [ ivtmp.27 ])
(subreg:V2DI (reg/f:DI 31 sp) 0)) 1163 {*aarch64_simd_movv2di}
 (expr_list:REG_DEAD (reg:TI 32 v0)
(nil)))

Which was created while expanding (well sp is not there right away, it is done
later on):
  _42 = (sizetype) buf.1_10;
  _43 = _42 + 1;
  _44 = {_42, _43};

[Bug target/99706] [11 Regression] ICE: maximum number of generated reload insns per insn achieved (90)

[asolokha at gmx dot com via Gcc-bugs]

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

--- Comment #3 from Arseny Solokha  ---
(In reply to Andrew Pinski from comment #1)
> Thos are some interesting options.  How did you decide to use them?

TL;DR: they were randomly chosen.

I run (somewhat) automated gcc fuzz testing for several years by now. I briefly
explained it in the first paragraph of PR92115 comment 4 (and likely
elsewhere), but can discuss it in more details if so desired.

[Bug c/99693] -O2 not move 'if' checks on const data outside the loops

[rafal at bursig dot org via Gcc-bugs]

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

--- Comment #5 from rafal at bursig dot org ---
Additional when I use c++ variant of this code and throw exception in else then
in  -O2 level the 'if' is removed outside loop:

typedef struct Update {
int m_update;
//...
} Update;

extern void antagonizer( Update * );

void antagonize(Update *data, unsigned int n)
{
int _update = data->m_update;
while(--n)
{

if (_update)
{
antagonizer( data );
} else throw  std::runtime_error("error");

}
}

The asm looks like:


.LC0:
.string "error"
antagonize(Update*, unsigned int):
mov eax, DWORD PTR [rdi]
sub esi, 1
je  .L12
pushr12
pushrbp
mov rbp, rdi
pushrbx
mov ebx, esi
testeax, eax
je  .L3
.L4:
mov rdi, rbp
callantagonizer(Update*)
sub ebx, 1
jne .L4
pop rbx
pop rbp
pop r12
ret
.L12:
ret
antagonize(Update*, unsigned int) [clone .cold]:
.L3:
mov edi, 16
call__cxa_allocate_exception
mov esi, OFFSET FLAT:.LC0
mov rdi, rax
mov rbp, rax
callstd::runtime_error::runtime_error(char const*) [complete object
constructor]
mov edx, OFFSET FLAT:_ZNSt13runtime_errorD1Ev
mov esi, OFFSET FLAT:_ZTISt13runtime_error
mov rdi, rbp
call__cxa_throw
mov r12, rax
mov rdi, rbp
call__cxa_free_exception
mov rdi, r12
call_Unwind_Resume


when I comment the "else throw ..." then the if check return int loop

[Bug target/99702] [11 Regression] ICE: RTL check: expected code 'const_int', have 'subreg' in riscv_expand_block_move, at config/riscv/riscv.c:3262 with memcpy() since g:d9f0ade001533c9544bf2153b6baa

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

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Kito Cheng :

https://gcc.gnu.org/g:540dace2ed3949571f2ce6cb007354e69bda0cb2

commit r11-7759-g540dace2ed3949571f2ce6cb007354e69bda0cb2
Author: Kito Cheng 
Date:   Mon Mar 22 16:32:45 2021 +0800

PR target/99702: Check RTL type before get value

gcc/ChangeLog:

PR target/99702
* config/riscv/riscv.c (riscv_expand_block_move): Get RTL value
after type checking.

gcc/testsuite/ChangeLog:

PR target/99702
* gcc.target/riscv/pr99702.c: New.

[Bug target/99702] [11 Regression] ICE: RTL check: expected code 'const_int', have 'subreg' in riscv_expand_block_move, at config/riscv/riscv.c:3262 with memcpy() since g:d9f0ade001533c9544bf2153b6baa

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

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

Kito Cheng  changed:

   What|Removed |Added

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

--- Comment #7 from Kito Cheng  ---
Hi Martin, Zdenek:

Thanks you guys!

[Bug c/99707] New: missing -Woverflow in floating-point to integer conversion for known but non-constant value

[vincent-gcc at vinc17 dot net via Gcc-bugs]

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

Bug ID: 99707
   Summary: missing -Woverflow in floating-point to integer
conversion for known but non-constant value
   Product: gcc
   Version: 10.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vincent-gcc at vinc17 dot net
  Target Milestone: ---

Consider the following code (from PR93806 Comment 29):

#include 

int main (void)
{
  volatile double d = -1.0;
  double x = d;
  unsigned int i = x;

  printf ("%u\n", i);
  if (x == -1.0)
printf ("%u\n", i);
  return 0;
}

First note that if instead of "unsigned int i = x;", one has "unsigned int i =
-1.0;", then one gets a warning with GCC 10.2.1:

conv-warn.c: In function ‘main’:
conv-warn.c:7:20: warning: overflow in conversion from ‘double’ to ‘unsigned
in’ changes value from ‘-1.0e+0’ to ‘0’ [-Woverflow]
7 |   unsigned int i = -1.0;
  |^

But the original code does not give any warning, even though with -O1, GCC uses
the fact that x == -1.0 to optimize and give a strange result (because the
variable i appears to have two different values):

4294967295
0

Thus GCC should know about the undefined behavior and warn.

[Bug target/99708] New: __SIZEOF_FLOAT128__ not defined on powerpc64le-linux

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

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

Bug ID: 99708
   Summary: __SIZEOF_FLOAT128__ not defined on powerpc64le-linux
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

For consistency with other targets, I think the rs6000 backend should predefine
__SIZEOF_FLOAT128__ 16
__SIZEOF_IBM128__ 16
__SIZEOF_IEEE128__ 16
macros (each of them whenever __float128, __ibm128 or __ieee128 can be used
given the current ABI and ISA options etc.).
E.g. i386 backend has in i386-c.c

  cpp_define_formatted (parse_in, "__SIZEOF_FLOAT80__=%d",
GET_MODE_SIZE (XFmode));

  cpp_define (parse_in, "__SIZEOF_FLOAT128__=16");

Seems rs6000 predefines __FLOAT128__ macro instead when __float128 can be used
and  __FLOAT128_TYPE__ when __ibm128 and __ieee128 can be used.

[Bug c/99707] missing -Woverflow warning in floating-point to integer conversion for known but non-constant value

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

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

--- Comment #1 from Andrew Pinski  ---
Gcc does not know that x will be negative. 

Note: x == -1.0 is well defined. As x is converted to double from unsigned int.

-Wconversion might warn about this but I have not tried.

[Bug c/99707] missing -Woverflow warning in floating-point to integer conversion for known but non-constant value

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

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

--- Comment #2 from Andrew Pinski  ---
Also this might be caught at runtime with -fsanitizer=undefined but I have not
tried yet. Since this is undefined behavior in this case unlike the original
PR93806.

[Bug target/99702] [11 Regression] ICE: RTL check: expected code 'const_int', have 'subreg' in riscv_expand_block_move, at config/riscv/riscv.c:3262 with memcpy() since g:d9f0ade001533c9544bf2153b6baa

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

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

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

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

commit r10-9506-ge1aa525179b72fb7ea7822c794ec844893ed47e4
Author: Kito Cheng 
Date:   Mon Mar 22 16:32:45 2021 +0800

PR target/99702: Check RTL type before get value

gcc/ChangeLog:

PR target/99702
* config/riscv/riscv.c (riscv_expand_block_move): Get RTL value
after type checking.

gcc/testsuite/ChangeLog:

PR target/99702
* gcc.target/riscv/pr99702.c: New.

(cherry picked from commit 540dace2ed3949571f2ce6cb007354e69bda0cb2)

[Bug target/99702] [11 Regression] ICE: RTL check: expected code 'const_int', have 'subreg' in riscv_expand_block_move, at config/riscv/riscv.c:3262 with memcpy() since g:d9f0ade001533c9544bf2153b6baa

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

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

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

https://gcc.gnu.org/g:3100cdf24a88aecc428e77fc8a4268947836d66c

commit r9-9301-g3100cdf24a88aecc428e77fc8a4268947836d66c
Author: Kito Cheng 
Date:   Mon Mar 22 16:32:45 2021 +0800

PR target/99702: Check RTL type before get value

gcc/ChangeLog:

PR target/99702
* config/riscv/riscv.c (riscv_expand_block_move): Get RTL value
after type checking.

gcc/testsuite/ChangeLog:

PR target/99702
* gcc.target/riscv/pr99702.c: New.

(cherry picked from commit 540dace2ed3949571f2ce6cb007354e69bda0cb2)

[Bug target/99706] [11 Regression] ICE: maximum number of generated reload insns per insn achieved (90)

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

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

--- Comment #4 from Richard Biener  ---
Likely an "RTL expansion testcase" using the GIMPLE FE with IL as seen around
RTL expansion could more reliably produce the bad IL.

[Bug target/55657] objc/obj-c++ failures present under darwin12

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

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

--- Comment #10 from Iain Sandoe  ---
(In reply to Iain Sandoe from comment #8)

> > FAIL: obj-c++.dg/property/at-property-13.mm -fgnu-runtime execution test

This is a dyld bug, the objc_setProperty() call should be provided from
libobjc-gnu.dylib (that's what the symbol two-level lookup says in the
executable).

However, dyld is resolving it to objc_setProperty_no_gc from libobjc.A.dylib.

So I don't plan to try to address this any further (the test case works for
NeXT runtime and for both NeXT and GNU runtimes on other OS versions).

The remaining issues are fixed on master e.g.
https://gcc.gnu.org/pipermail/gcc-testresults/2021-March/669585.html

[Bug middle-end/28831] [8/9/10/11 Regression] Aggregate copy not elided when using a return value as a pass-by-value parameter

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

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

--- Comment #36 from Richard Biener  ---
Note that if we'd want to "preallocate" (or re-use) variables for argument
slots we have to properly arrange them according to the ABI.  Consider
a function taking more than just a single argument [passed on stack] which
we might still able to handle optimally [with greater difficulty].

Jasons C++ example expands from

  D.2368 = {};
  D.2368.i[0] = 1;
  f (D.2368);

if you modify that to

struct A { int i[100]; };
void f(int i, struct A, int j);
int main()
{
  f(0, (struct A){1}, 2);
}

then on i?86 both extra arguments are passed on the stack as well but
RTL expansion sees again

  D.2370 = {};
  D.2370.i[0] = 1;
  f (0, D.2370, 2);

but clearly we cannot just allocate D.2370 in a random place if it is
passed on the stack (on i?86 it's passed by reference).  For example

struct A { int i[2]; };
void f(struct A);
int main()
{
  f((struct A){1});
}

expanded as

  MEM  [(struct A *)&D.1960 + 4B] = {};
  D.1960.i[0] = 1;
  f (D.1960);

is passed on the stack though.  So if we want to expose anything on GIMPLE
then we have to make the argument space on the stack distinct from random
stack variables.

[Bug c/99707] missing -Woverflow warning in floating-point to integer conversion for known but non-constant value

[vincent-gcc at vinc17 dot net via Gcc-bugs]

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

--- Comment #3 from Vincent Lefèvre  ---
(In reply to Andrew Pinski from comment #1)
> Gcc does not know that x will be negative.

Actually, the code should have been (without the volatile):

#include 

int main (void)
{
  double x = -1.0;
  unsigned int i = x;

  printf ("%u\n", i);
  if (x == -1.0)
printf ("%u\n", i);
  return 0;
}

I don't get the warning either, and due to the "double x = -1.0;", GCC knows
that x is negative.

> -Wconversion might warn about this but I have not tried.

The test is done with -Wconversion.

(In reply to Andrew Pinski from comment #2)
> Also this might be caught at runtime with -fsanitizer=undefined but I have
> not tried yet. Since this is undefined behavior in this case unlike the
> original PR93806.

After checking... This is not undefined behavior, but the value is unspecified.
F.4: "[...] if the floating value is infinite or NaN or if the integral part of
the floating value exceeds the range of the integer type, then the “invalid”
floating-point exception is raised and the resulting value is unspecified."

[Bug c++/99705] [10/11 Regression] ICE in expand_expr_real_1 since r10-3661

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

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

--- Comment #1 from Jakub Jelinek  ---
The *.original dump diff before/after is
@@ -32,11 +32,11 @@
 }
   :;
   {
-struct C * D.2390;
+struct C * D.2390 = D.2378 + ((SAVE_EXPR <(sizetype) ((struct X *)
this)->n> - (sizetype) D.2380) + 18446744073709551615);

 (if (D.2378 != 0B)
   {
-(void) (D.2390 = D.2378 + ((SAVE_EXPR <(sizetype) ((struct X *)
this)->n> - (sizetype) D.2380) + 18446744073709551615));, while (1)
+struct C * D.2390 = D.2378 + ((SAVE_EXPR <(sizetype) ((struct
X *) this)->n> - (sizetype) D.2380) + 18446744073709551615);, while (1)
   {
 if (D.2390 == D.2378) break;, (void) (D.2390 = D.2390 +
18446744073709551615);;, C::~C (D.2390);;
   };
and I think the problem is that this in the latter comes from the wrong ctor -
_ZN1XC4Ev rather than expected _ZN1XC2Ev.

[Bug tree-optimization/90591] Avoid unnecessary data transfer out of OMP construct

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

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

Thomas Schwinge  changed:

   What|Removed |Added

   Assignee|sandra at gcc dot gnu.org  |tschwinge at gcc dot 
gnu.org

--- Comment #6 from Thomas Schwinge  ---
(In reply to Richard Biener from comment #3)
> I think while relying on a robust IPA analysis and optimization framework
> sounds appealing the problem is _much_ easier solved before OMP/OACC
> lowering and I would strongly suggest to tackle the problem from that side
> if you want a
> workable solution in a timely manner.

ACK.  WIP:
.

> I realize that has a plethora of its own issues, first of all it seems
> the respective lowering is done _very_ early - aka the optimization would
> need to be part of omplower? (I see .omp_data_i constructed there)
> 
> So what you need is liveness and def/use analysis on high GIMPLE which I
> think is straight-forward enough.  You have no SSA form at your hands
> (actually SSA names can appear and there'll be use->def links but
> no immediate uses).

[Bug c++/99687] AddressSanitizer: alloc-dealloc-mismatch (malloc vs operator delete) on 0x604000000d50

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

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

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

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

commit r11-7761-gc4519fe3db366d781f342b7f04c4a09e4cc9fbd9
Author: Martin Liska 
Date:   Sat Mar 20 20:57:13 2021 +0100

C++ modules: fix alloc-dealloc-mismatch ASAN issue

gcc/cp/ChangeLog:

PR c++/99687
* module.cc (fini_modules): Call vec_free instead of delete.

[Bug c++/99687] AddressSanitizer: alloc-dealloc-mismatch (malloc vs operator delete) on 0x604000000d50

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

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

Martin Liška  changed:

   What|Removed |Added

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

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

[Bug other/86656] [meta-bug] Issues found with -fsanitize=address

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

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

Bug 99687 Summary: AddressSanitizer: alloc-dealloc-mismatch (malloc vs operator 
delete) on 0x60400d50
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99687

   What|Removed |Added

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

[Bug c++/99215] coroutines: debugging with gdb

[nilsgladitz at gmail dot com via Gcc-bugs]

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

--- Comment #7 from Nils Gladitz  ---
(In reply to Nils Gladitz from comment #5)
> Apparently when the coroutine happens to be a member function (even a static
> one) printing *frame_ptr results in "{}".

I reported the "{}" issue at the gdb issue tracker:
https://sourceware.org/bugzilla/show_bug.cgi?id=27556

Managed to create a local workaround from comments made there.
It was mentioned that gcc itself may be generating improper debug information
(I think specifically nesting the frame type within a function) but as I
mentioned  over there I myself don't know for sure if this is uncommon or
actually invalid.

[Bug c++/99215] coroutines: debugging with gdb

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

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

--- Comment #8 from Iain Sandoe  ---
(In reply to Nils Gladitz from comment #7)
> (In reply to Nils Gladitz from comment #5)
> > Apparently when the coroutine happens to be a member function (even a static
> > one) printing *frame_ptr results in "{}".
> 
> I reported the "{}" issue at the gdb issue tracker:
> https://sourceware.org/bugzilla/show_bug.cgi?id=27556
> 
> Managed to create a local workaround from comments made there.
> It was mentioned that gcc itself may be generating improper debug
> information (I think specifically nesting the frame type within a function)
> but as I mentioned  over there I myself don't know for sure if this is
> uncommon or actually invalid.

I am not 100% sure about the nesting of the type info
on one hand, the type _is_ local to the function (it's compiler-generated, end
users shouldn't need to look inside it - we are only doing so as a work-around
for missing info)

on the other, I suppose it's also unique to the function and therefore could be
pushed to file scope.

In the end I expect things to work better if we make use of the existing
machinery for decls being represented by some specified expression - then you
would not need to be poking inside the private (compiler-generated) type for
the frame.

In support of improved debug, I'm collecting some local patches - ready for
next stage 1.  One thing done already is to change the resume index even if the
suspend is not taken - so that an interrupted coro would have some indication
of which part of the code was active.

[Bug c++/99215] coroutines: debugging with gdb

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

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

--- Comment #9 from Iain Sandoe  ---
(In reply to Iain Sandoe from comment #8)
> (In reply to Nils Gladitz from comment #7)
> > (In reply to Nils Gladitz from comment #5)
> > > Apparently when the coroutine happens to be a member function (even a 
> > > static
> > > one) printing *frame_ptr results in "{}".

> on the other, I suppose it's also unique to the function and therefore could
> be pushed to file scope.

um, maybe that should be the class scope, for member functions.

[Bug fortran/99709] New: VALUE attribute for an object with nonconstant length parameter

[xiao.liu--- via Gcc-bugs]

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

Bug ID: 99709
   Summary: VALUE attribute for an object with nonconstant length
parameter
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: xiao@compiler-dev.com
  Target Milestone: ---

The extensions to VALUE attribute(f2008) permitted for an object with a
nonconstant length parameter, but the result of the following test case 
is same with none VALUE attribute.

program value_f2008
  implicit none
  type :: matrix(k)
integer, len :: k
integer :: elements(k, k)
!integer :: elements(2, 2)
  end type matrix

  type, extends(matrix) :: child
  end type child

  type(child(2)) :: obj
  obj%elements = reshape([1, 2, 3, 4], shape(obj%elements))

  call test_value_attr(2, obj)
  print *, obj%elements

contains

  subroutine test_value_attr(n,  nonconstant_length_object)
integer :: n
type(child(n)), value :: nonconstant_length_object
nonconstant_length_object%elements = 0
  end subroutine test_value_attr
end program value_f2008

The result is 
   0   0   0   0

[Bug target/99703] gcc-10.2.0 with Via C3 Eden: configure: error: Intel CET must be enabled on Intel CET enabled host

[worx at pouf dot org via Gcc-bugs]

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

--- Comment #4 from Worx  ---
(In reply to Martin Liška from comment #2)
> It seems the binutils was fixed. Does it help in your scenario?

Yes ...

[Bug target/99703] gcc-10.2.0 with Via C3 Eden: configure: error: Intel CET must be enabled on Intel CET enabled host

[worx at pouf dot org via Gcc-bugs]

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

--- Comment #5 from Worx  ---
(In reply to Martin Liška from comment #2)
> It seems the binutils was fixed. Does it help in your scenario?

Yes ...

[Bug target/99703] gcc-10.2.0 with Via C3 Eden: configure: error: Intel CET must be enabled on Intel CET enabled host

[worx at pouf dot org via Gcc-bugs]

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

--- Comment #6 from Worx  ---
(In reply to Richard Biener from comment #3)
> Try --disable-cet as a workaround

How apply this option ?

[Bug target/99703] gcc-10.2.0 with Via C3 Eden: configure: error: Intel CET must be enabled on Intel CET enabled host

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

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

--- Comment #7 from Richard Biener  ---
(In reply to Worx from comment #6)
> (In reply to Richard Biener from comment #3)
> > Try --disable-cet as a workaround
> 
> How apply this option ?

At configure time.

[Bug target/99703] gcc-10.2.0 with Via C3 Eden: configure: error: Intel CET must be enabled on Intel CET enabled host

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

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

--- Comment #8 from Martin Liška  ---
(In reply to Richard Biener from comment #7)
> (In reply to Worx from comment #6)
> > (In reply to Richard Biener from comment #3)
> > > Try --disable-cet as a workaround
> > 
> > How apply this option ?
> 
> At configure time.

https://gcc.gnu.org/install/configure.html

[Bug target/99703] gcc-10.2.0 with Via C3 Eden: configure: error: Intel CET must be enabled on Intel CET enabled host

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #9 from Jakub Jelinek  ---
Do we enable CET by default when targetting such CPUs, or is it just Gentoo
scripts passing --enable-cet ?
Looking at config/cet.m4, for --enable-cet=auto which should be the default,
it should not be enabled when __SSE2__ is not defined and I think c3 only has
MMX/3dNOW! support, not SSE2, c3-2 MMX/SSE.

[Bug c++/99710] New: coroutines: co_yield and co_await should only be allowed in suspension context

[nilsgladitz at gmail dot com via Gcc-bugs]

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

Bug ID: 99710
   Summary: coroutines: co_yield and co_await should only be
allowed in suspension context
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nilsgladitz at gmail dot com
  Target Milestone: ---

I quite enjoyed seemingly being able to co_await in exception catch handlers
but as I am being told by another compiler this is apparently not legal.

Not sure I really understand why the standard disallows this but perhaps gcc
should issue a corresponding error diagnostic as well.

Equivalent (fixed) issue report I found for clang:
https://bugs.llvm.org/show_bug.cgi?id=40978

[Bug target/99703] gcc-10.2.0 with Via C3 Eden: configure: error: Intel CET must be enabled on Intel CET enabled host

[worx at pouf dot org via Gcc-bugs]

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

--- Comment #10 from Worx  ---
When I deep dive, in the logs

No issue at the root level : 

c3eden /opt/gcc-10.2.0 # ./configure --disable-cet
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking target system type... i686-pc-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
checking whether ln works... yes
[..]
checking whether to enable maintainer-specific portions of Makefiles... no
configure: creating ./config.status
config.status: creating Makefile
c3eden /opt/gcc-10.2.0 #


But : 


c3eden /opt/gcc-10.2.0 # lto-plugin/configure --disable-cet
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking target system type... i686-pc-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking for style of include used by make... GNU
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking dependency style of gcc... gcc3
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking minix/config.h usability... no
checking minix/config.h presence... no
checking for minix/config.h... no
checking whether it is safe to define __EXTENSIONS__... yes
checking for gcc... (cached) gcc
checking whether we are using the GNU C compiler... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking for gcc option to accept ISO C89... (cached) none needed
checking whether gcc understands -c and -o together... (cached) yes
checking dependency style of gcc... (cached) gcc3
checking for special C compiler options needed for large files... no
checking for _FILE_OFFSET_BITS value needed for large files... 64
checking whether gcc supports -Wall... yes
checking for -static-libgcc... yes
checking for CET support... configure: error: Intel CET must be enabled on
Intel CET enabled host
c3eden /opt/gcc-10.2.0 #

[Bug c++/99701] std::nullptr_t can be compared with relational ops

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Polacek  ---
Mine (for GCC 12).

[Bug c++/99705] [10/11 Regression] ICE in expand_expr_real_1 since r10-3661

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

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

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

One possible fix.  The reason I've made the build_vec_delete_1 changes was that
P0784R7 was implemented some months before P1331R2 and therefore the artificial
tbase var without initializer was rejected during constexpr evaluation, but now
it is not anymore.

[Bug middle-end/99694] [9/10/11 Regression] gcc: fatal error: Killed signal terminated program cc1 under -O2 to -Os since r9-7156-g33579b59aaf02eb7

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

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

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

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

commit r11-7762-gb931e4792b8696f3da69f70988720c4d1ec6142a
Author: Richard Biener 
Date:   Mon Mar 22 11:09:46 2021 +0100

tree-optimization/99694 - fix value-numbering PHIs

This avoids endless cycling when a PHI node with unchanged backedge
value (the PHI result appearing there) is subject to CSE since doing
that effectively alters the hash entry.  The way to avoid this is
to ignore such edges when processing the PHI node.

2021-03-22  Richard Biener  

PR tree-optimization/99694
* tree-ssa-sccvn.c (visit_phi): Ignore edges with the
PHI result.

* gcc.dg/torture/pr99694.c: New testcase.

[Bug middle-end/99694] [9/10 Regression] gcc: fatal error: Killed signal terminated program cc1 under -O2 to -Os since r9-7156-g33579b59aaf02eb7

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

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

Richard Biener  changed:

   What|Removed |Added

Summary|[9/10/11 Regression] gcc:   |[9/10 Regression] gcc:
   |fatal error: Killed signal  |fatal error: Killed signal
   |terminated program cc1  |terminated program cc1
   |under -O2 to -Os since  |under -O2 to -Os since
   |r9-7156-g33579b59aaf02eb7   |r9-7156-g33579b59aaf02eb7
  Known to fail||10.2.0
  Known to work||11.0
   Priority|P3  |P2

--- Comment #5 from Richard Biener  ---
Fixed on trunk sofar.

[Bug target/99649] GDB has issue to show backtrace if the breakpoint is in a function with more then 8 parameters - only for target aarch64-elf ILP32

[filip.bascarevic at siemens dot com via Gcc-bugs]

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

--- Comment #4 from Filip Bascarevic  ---
Thank you so much for your replies. I also contacted the GDB community and will
see what will they reply

[Bug fortran/99711] New: Crash when reading an allocated character array in namelist

[phil1691 at gmail dot com via Gcc-bugs]

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

Bug ID: 99711
   Summary: Crash when reading an allocated character array in
namelist
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: phil1691 at gmail dot com
  Target Milestone: ---

The following code crashes with a segmentation fault (gcc 10.2.0):
> cat alloc_nml.f90 
program allocnml
  implicit none

  character(len=:), dimension(:), allocatable :: cbulist_ru
  integer :: iluseg

  namelist /nam_bu_ru/ cbulist_ru

  allocate( character(len=10) :: cbulist_ru(5) )

  open(newunit=iluseg, file='list.nml', status='old', &
   action='read', form='formatted', access='sequential')

  read(unit=iluseg, nml=nam_bu_ru)

  print *, cbulist_ru

  close(unit=iluseg)
end program allocnml

With the following namelist file:
> cat list.nml
&NAM_BU_RU
 CBULIST_RU(1) = 'PRES'
 CBULIST_RU(2) = 'NEST'
 CBULIST_RU(3) = 'HTURB'
 CBULIST_RU(4) = 'VTURB'
/

Compilation:
> gfortran -g alloc_nml.f90

Execution:
> ./a.out 

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0  0x146bdba3349f in ???
#1  0x146bdbb57d7a in ???
#2  0x146bdc79df4b in nml_read_obj
at ../../../gcc-10.2.0-srcdir/libgfortran/io/list_read.c:3142
#3  0x146bdc79ee8a in nml_get_obj_data
at ../../../gcc-10.2.0-srcdir/libgfortran/io/list_read.c:3512
#4  0x146bdc7a78b7 in finalize_transfer
at ../../../gcc-10.2.0-srcdir/libgfortran/io/transfer.c:4128
#5  0x400d48 in allocnml
at
/home/waup/F90/bug_gcc/character_allocatable_namelist/alloc_nml.f90:14
#6  0x400e20 in main
at
/home/waup/F90/bug_gcc/character_allocatable_namelist/alloc_nml.f90:19
Erreur de segmentation (core dumped)

[Bug target/97252] [10/11 Regression] arm: ICE compiling pure-code/pr94538-2.c with MVE since r10-7293-g3eff57aa

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

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Alex Coplan :

https://gcc.gnu.org/g:150a829accd76ddd73c20628774cb0781f6e8bfe

commit r11-7764-g150a829accd76ddd73c20628774cb0781f6e8bfe
Author: Alex Coplan 
Date:   Mon Mar 22 14:43:15 2021 +

arm: Fix MVE ICEs with vector moves and -mpure-code [PR97252]

This fixes around 500 ICEs in the testsuite which can be seen when
testing with -march=armv8.1-m.main+mve -mfloat-abi=hard -mpure-code
(leaving the testsuite free of ICEs in this configuration). All of the
ICEs are in arm_print_operand (which is expecting a mem and gets another
rtx, e.g. a const_vector) when running the output code for
*mve_mov in alternative 4.

The issue is that MVE vector moves were relying on the arm_reorg pass to
move constant vectors that we can't easily synthesize to the literal
pool. This doesn't work for -mpure-code where the literal pool is
disabled. LLVM puts these in .rodata: I've chosen to do the same here.

With this change, for -mpure-code, we no longer want to allow a constant
on the RHS of a vector load in RA. To achieve this, I added a new
constraint which matches constants only if the literal pool is
available.

gcc/ChangeLog:

PR target/97252
* config/arm/arm-protos.h (neon_make_constant): Add generate
argument to guard emitting insns, default to true.
* config/arm/arm.c (arm_legitimate_constant_p_1): Reject
CONST_VECTORs which neon_make_constant can't handle.
(neon_vdup_constant): Add generate argument, avoid emitting
insns if it's not set.
(neon_make_constant): Plumb new generate argument through.
* config/arm/constraints.md (Ui): New. Use it...
* config/arm/mve.md (*mve_mov): ... here.
* config/arm/vec-common.md (movv8hf): Use neon_make_constant to
synthesize constants.

[Bug target/97252] [10 Regression] arm: ICE compiling pure-code/pr94538-2.c with MVE since r10-7293-g3eff57aa

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

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

Alex Coplan  changed:

   What|Removed |Added

Summary|[10/11 Regression] arm: ICE |[10 Regression] arm: ICE
   |compiling   |compiling
   |pure-code/pr94538-2.c with  |pure-code/pr94538-2.c with
   |MVE since   |MVE since
   |r10-7293-g3eff57aa  |r10-7293-g3eff57aa
  Known to fail|11.0|10.2.1

--- Comment #6 from Alex Coplan  ---
Fixed on trunk. Needs backporting to GCC 10.

[Bug rtl-optimization/99712] New: Cannot elide aggregate parameter setup

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

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

Bug ID: 99712
   Summary: Cannot elide aggregate parameter setup
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

On arm32 for

struct X { int a; int b; int c; int d; int e; };

volatile int i;

void bar (struct X);
void foo (struct X x)
{
  i = x.a;
//  i = x.e;
}

we are not able to elide the argument setup generated by RTL expansion:

foo:
@ args = 20, pretend = 16, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
sub sp, sp, #16
sub ip, sp, #4
add sp, sp, #16
stmib   ip, {r0, r1, r2, r3}
movwr3, #:lower16:.LANCHOR0
movtr3, #:upper16:.LANCHOR0
str r0, [r3]
bx  lr

note the stmib and all the stack slot setup while we were able to CSE
the "load" to r0.  It looks like the frame setup is not subject to DSE,
it's generated as

(insn 2 4 3 2 (parallel [
(set (mem/c:SI (reg/f:SI 107 virtual-incoming-args) [2 x+0 S4 A32])
(reg:SI 0 r0))
(set (mem/c:SI (plus:SI (reg/f:SI 107 virtual-incoming-args)
(const_int 4 [0x4])) [2 x+4 S4 A32])
(reg:SI 1 r1))
(set (mem/c:SI (plus:SI (reg/f:SI 107 virtual-incoming-args)
(const_int 8 [0x8])) [2 x+8 S4 A32])
(reg:SI 2 r2))
(set (mem/c:SI (plus:SI (reg/f:SI 107 virtual-incoming-args)
(const_int 12 [0xc])) [2 x+12 S4 A32])
(reg:SI 3 r3))
]) "t.c":7:1 -1
 (nil))
(note 3 2 6 2 NOTE_INSN_FUNCTION_BEG)

[Bug c++/99425] [modules] ICE tree check: expected tree_vec, have tree_list in lookup_template_class_1, at cp/pt.c:9803

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Nathan Sidwell :

https://gcc.gnu.org/g:87e3c2ef682e2ba7692ee56142a4eb5b6441c4d3

commit r11-7765-g87e3c2ef682e2ba7692ee56142a4eb5b6441c4d3
Author: Nathan Sidwell 
Date:   Thu Mar 18 05:12:59 2021 -0700

c++: duplicate alias templates with decltype [PR 99425]

This failure was ultimately from incorrect handling of alias
templates, but required a specific set of occurrences to happen in the
specialization hash table.  This cleans up the specialization
streaming to add alias instantiations at the same point as other
instantiations.  I also removed some unneeded global variables dealing
with mapping of duplicate decl contexts.

PR c++/99425
gcc/cp/
* cp-tree.h (map_context_from, map_context_to): Delete.
(add_mergeable_specialization): Add is_alias parm.
* pt.c (add_mergeable_specialization): Add is_alias parm, add them.
* module.cc (map_context_from, map_context_to): Delete.
(trees_in::decl_value): Add specializations later, adjust call.
Drop useless alias lookup. Set duplicate fn parm context.
(check_mergeable_decl): Drop context mapping.
(trees_in::is_matching_decl): Likewise.
(trees_in::read_function_def): Drop parameter context adjustment
here.
gcc/testsuite/
* g++.dg/modules/pr99425-1.h: New.
* g++.dg/modules/pr99425-1_a.H: New.
* g++.dg/modules/pr99425-1_b.H: New.
* g++.dg/modules/pr99425-1_c.C: New.
* g++.dg/modules/pr99425-2_a.X: New.
* g++.dg/modules/pr99425-2_b.X: New.
* g++.dg/template/pr99425.C: New.

[Bug c++/99425] [modules] ICE tree check: expected tree_vec, have tree_list in lookup_template_class_1, at cp/pt.c:9803

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

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #4 from Nathan Sidwell  ---
* 87e3c2ef682 2021-03-18 | c++: duplicate alias templates with decltype [PR
99425]

[Bug c++/99227] [meta] [modules] Bugs relating to header-units of STL header files

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

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

Bug 99425 Summary: [modules] ICE tree check: expected tree_vec, have tree_list 
in lookup_template_class_1, at cp/pt.c:9803
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99425

   What|Removed |Added

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

[Bug libstdc++/99713] New: Add _GLIBCXX_CHECK_PREDICATES that violates runtime guarantees and ensures predicates are valid

[fiesh at zefix dot tv via Gcc-bugs]

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

Bug ID: 99713
   Summary: Add _GLIBCXX_CHECK_PREDICATES that violates runtime
guarantees and ensures predicates are valid
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fiesh at zefix dot tv
  Target Milestone: ---

This is an extension of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60519

A very nasty kind of bugs stems from invalid predicates to standard library
functions like sort or unique.  They will introduce UB but might not even
trigger since the predicate is not applied to all possible tuples, leading to
bugs that will only manifest in certain situations.

Alas there's no way to establish the correctness of a predicate at compile
time, it's trivial to code the halting problem in it.  Furthermore the
predicate only needs to satisfy its requirements for the ranges that it is
applied to.

Therefore I'd like to suggest a flag that enables checking the predicates
satisfy what's expected of them for the entire range supplied in all function
that make such expectations -- preferably checking what the standard mandates
even if it's more than what the function requires in its implementation.  (For
example I'm pretty sure that std::unique doesn't actually care if its predicate
is transitive, but this assumption might turn out to not be safe for the future
when some sort of parallelization kicks in.  I wouldn't be surprised if a lot
of people used std::unique to eliminate close-enough duplicates from ranges of
doubles, which is UB.)

As a reference for what I'm talking about, here's what we use internally to
catch some bugs.  std::sort could then just call `assert(isCompare(begin, end,
pred))`.

namespace wstd {
//! Check if a predicate is reflexive for a given range
/*!
 * The worst case time complexity of this check is N many applications
of pred, where N is the distance from begin to end.
 */
template 
constexpr bool isReflexive(It const begin, It const end, Pred const &
pred)
{
for (auto iter = begin; iter != end; ++iter) {
if (!pred(*iter, *iter)) {
return false;
}
}
return true;
}

//! Check if a predicate is irreflexive for a given range
/*!
 * The worst case time complexity of this check is N many applications
of pred, where N is the distance from begin to end.
 */
template 
constexpr bool isIrreflexive(It const begin, It const end, Pred const &
pred)
{
for (auto iter = begin; iter != end; ++iter) {
if (pred(*iter, *iter)) {
return false;
}
}
return true;
}

//! Check if a predicate is symmetric for a given range
/*!
 * The time complexity of this check if O(N^2) many applications of
pred, where N is distance from begin to end.
 */
template 
constexpr bool isSymmetric(It const begin, It const end, Pred const &
pred)
{
for (auto iter0 = begin; iter0 != end; ++iter0) {
for (auto iter1 = begin; iter1 != end; ++iter1) {
if (pred(*iter0, *iter1) && !pred(*iter1,
*iter0)) {
return false;
}
}
}
return true;
}

//! Check if a predicate is asymmetric for a given range
/*!
 * The time complexity of this check if O(N^2) many applications of
pred, where N is distance from begin to end.
 */
template 
constexpr bool isAsymmetric(It const begin, It const end, Pred const &
pred)
{
for (auto iter0 = begin; iter0 != end; ++iter0) {
for (auto iter1 = begin; iter1 != end; ++iter1) {
if (pred(*iter0, *iter1) && pred(*iter1,
*iter0)) {
return false;
}
}
}
return true;
}

//! Check if a given predicate is transitive on a given range
/*!
 * Note that this has time complexity of O(N^3) applications of pred,
where N is the distance from begin to end.
 */
template 
constexpr bool isTransitive(It const begin, It const end, Pred const &
pred)
{
for (auto iter0 = begin; iter0 != end; ++iter0) {
for (auto iter1 = begin; iter1 != end; ++iter1) {
  

[Bug middle-end/99714] New: warn about alloca/dealloc mismatches based on calls with same object in different functions

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

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

Bug ID: 99714
   Summary: warn about alloca/dealloc mismatches based on calls
with same object in different functions
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Deallocating an object in one function through a pointer that's assigned the
result of a mismatched allocation in another function is almost certainly a
bug.  Diagnosing such mismatched calls would help detect at compile time
problems like pr99687 that are currently only detected by dynamic analysis
tools.

#if __cplusplus

struct A {
  int *p;
  A (int);
  ~A ();
};

A::A (int n): p (new int[n]{ }) { }

A::~A ()
{
  delete p;// missing -Wmismatched-new-delete
}
#else

struct A { int *p; };

void dealloc (void*);
__attribute__ ((malloc (dealloc))) void* alloc (int);

void init (struct A *p, int n) { p = alloc (n * sizeof *p); }
void fini (struct A *p)
{
  __builtin_free (p);  // missing -Wmismatched-dealloc
}

#endif

[Bug middle-end/99715] New: bogus/missing Wmismatched-dealloc warnings

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

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

Bug ID: 99715
   Summary: bogus/missing Wmismatched-dealloc warnings
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

This is a meta-bug to track false positives and negatives in the
-Wmismatched-dealloc warning, new in GCC 11.

[Bug middle-end/99714] warn about alloca/dealloc mismatches based on calls with same object in different functions

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

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||documentation
 Blocks||99715
   Severity|normal  |enhancement


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99715
[Bug 99715] [meta-bug] bogus/missing Wmismatched-dealloc warnings

[Bug middle-end/99715] [meta-bug] bogus/missing Wmismatched-dealloc warnings

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

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

Martin Sebor  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

[Bug analyzer/99716] New: -Wanalyzer-double-fclose when fclose is called inside a loop

[rjones at redhat dot com via Gcc-bugs]

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

Bug ID: 99716
   Summary: -Wanalyzer-double-fclose when fclose is called inside
a loop
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: rjones at redhat dot com
  Target Milestone: ---

This seems pretty bogus to me:

#include 
#include 

int
main ()
{
  int i;

  for (i = 0; i < 2; ++i) {
FILE *fp = fopen ("/tmp/test", "w");
fprintf (fp, "hello");
fclose (fp);
  }
  exit (EXIT_SUCCESS);
}

$ gcc -O2 -fanalyzer /tmp/fclose-loop.c -o /tmp/fclose-loop
/tmp/fclose-loop.c: In function ‘main’:
/tmp/fclose-loop.c:12:5: warning: double ‘fclose’ of FILE ‘fp’
[-Wanalyzer-double-fclose]
   12 | fclose (fp);
  | ^~~
  ‘main’: events 1-7
|
|9 |   for (i = 0; i < 2; ++i) {
|  |   ~~^~~
|  | |
|  | (1) following ‘true’ branch (when ‘i != 2’)...
|  | (5) following ‘true’ branch (when ‘i != 2’)...
|   10 | FILE *fp = fopen ("/tmp/test", "w");
|  |
|  ||
|  |(2) ...to here
|  |(3) opened here
|  |(6) ...to here
|   11 | fprintf (fp, "hello");
|   12 | fclose (fp);
|  | ~~~  
|  | |
|  | (4) first ‘fclose’ here
|  | (7) second ‘fclose’ here; first ‘fclose’ was at (4)

This is with:
gcc-11.0.0-0.19.fc35.x86_64

I do not have any later version of GCC to test, but also I don't see any
other bug about this.

[Bug c++/99717] New: ICE in finish_expr_stmt, at cp/semantics.c:681

[jmullee at yahoo dot com via Gcc-bugs]

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

Bug ID: 99717
   Summary: ICE in finish_expr_stmt, at cp/semantics.c:681
   Product: gcc
   Version: 9.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jmullee at yahoo dot com
  Target Milestone: ---

Created attachment 50448
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50448&action=edit
g++ -v, specs, src files, etc

I wasn't able to make it happen again, but the circumstances were:

- using g++ precompiled headers

- incrementally editing an include file, replacing ints with enums (which get
used in a #def macro)

- using CGAL, a header-only library with many templates etc

error:
---
$ make -f tryMakefile && ./try_hilbersort
g++  -I/opt/CGAL/cgal-5.2.1/include -c -o try_hilbersort.o
try_hilbersort.cpp
In file included from /opt/CGAL/cgal-5.2.1/include/CGAL/basic.h:31,
 from
/opt/CGAL/cgal-5.2.1/include/CGAL/HalfedgeDS_vector.h:23,
 from try_hilbersort.h:2:
/opt/CGAL/cgal-5.2.1/include/CGAL/Polyhedron_incremental_builder_3.h: In
instantiation of
‘CGAL::Polyhedron_incremental_builder_3::Polyhedron_incremental_builder_3(CGAL::Polyhedron_incremental_builder_3::HDS&,
bool) [with HalfedgeDS_ = CGAL::HalfedgeDS_default;
CGAL::Polyhedron_incremental_builder_3::HDS =
CGAL::HalfedgeDS_default]’:
/opt/CGAL/cgal-5.2.1/include/CGAL/IO/Polyhedron_builder_from_STL.h:42:49:  
required from ‘void CGAL::Polyhedron_builder_from_STL::operator()(HDS&)
[with HDS = CGAL::HalfedgeDS_default]’
try_hilbersort.cpp:44:14:   required from here
   
/opt/CGAL/cgal-5.2.1/include/CGAL/Polyhedron_incremental_builder_3.h:193:29:
internal compiler error: in finish_expr_stmt, at cp/semantics.c:681
  193 | CGAL_assertion_code(check_protocoll = protocoll::created;)
// Polyhedron_incremental_builder_3::CTOR
  | ^~~
/opt/CGAL/cgal-5.2.1/include/CGAL/assertions.h:103:37: note: in definition
of macro ‘CGAL_assertion_code’
  103 | #  define CGAL_assertion_code(CODE) CODE
  | ^~~~
Please submit a full bug report,

---

[Bug c++/99480] [modules] ICE in import_entity_index, at cp/module.cc:3952

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

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

Nathan Sidwell  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2021-03-22
 Status|UNCONFIRMED |ASSIGNED

--- Comment #1 from Nathan Sidwell  ---
// bug_a.ii
template
struct atomic;

template
struct atomic<_Tp*>;

// bug_b.ii
import  "bug_a.ii";

template
struct atomic<_Tp*>
{
};
./cc1plus -std=c++20 -quiet -fmodule-header bug_a.ii && ./cc1plus -std=c++20
-quiet -fmodule-header bug_b.ii
bug_b.ii:5:1: internal compiler error: in import_entity_index, at
cp/module.cc:3943
5 | {
  | ^
0xc8affe import_entity_index
../../../src/gcc/cp/module.cc:3943
0xcc4350 module_may_redeclare(tree_node*)
../../../src/gcc/cp/module.cc:18440
0xe23fda begin_class_definition(tree_node*)
../../../src/gcc/cp/semantics.c:3334

[Bug c++/99705] [10/11 Regression] ICE in expand_expr_real_1 since r10-3661

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

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

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

Another untested fix instead of the above.

[Bug sanitizer/99673] [11 Regression] bogus -Wstringop-overread warning with address sanitizer due to member address substitution

[arnd at linaro dot org via Gcc-bugs]

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

--- Comment #4 from Arnd Bergmann  ---
I posted a set of kernel patches to address all the warnings I found at

https://lore.kernel.org/lkml/20210322160253.4032422-1-a...@kernel.org/T/#t

[Bug analyzer/99716] -Wanalyzer-double-fclose when fclose is called inside a loop

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

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

--- Comment #1 from David Malcolm  ---
Thanks.  Looks very similar to bug 93695 - the analyzer "gets confused" in how
it tracks allocations in a loop (albeit with a different kind of resource, and
thus worth tracking as a separate bug).

[Bug target/99718] New: [11 regression] ICE in new test case gcc.target/powerpc/pr98914.c for 32 bits

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

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

Bug ID: 99718
   Summary: [11 regression] ICE in new test case
gcc.target/powerpc/pr98914.c  for 32 bits
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:d0a5e8e1a84bdd6ce915c3be65da8af2552cd49e, r11-7755
make  -k check-gcc RUNTESTFLAGS="--target_board=unix'{-m32}'
powerpc.exp=gcc.target/powerpc/pr98914.c"
FAIL: gcc.target/powerpc/pr98914.c (internal compiler error)
FAIL: gcc.target/powerpc/pr98914.c (test for excess errors)
# of unexpected failures2

This fails for 32 bits only on powerpc64 BE.

spawn /home/seurer/gcc/git/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-test/gcc/ exceptions_enabled3605.cc
-fdiagnostics-plain-output -S -m32 -o exceptions_enabled3605.s
FAIL: gcc.target/powerpc/pr98914.c (test for excess errors)
Excess errors:
during RTL pass: expand
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.target/powerpc/pr98914.c:9:10:
internal compiler error: in rs6000_expand_vector_set, at
config/rs6000/rs6000.c:7221
0x1101a543 rs6000_expand_vector_set(rtx_def*, rtx_def*, rtx_def*)
/home/seurer/gcc/git/gcc-test/gcc/config/rs6000/rs6000.c:7221
0x11631653 gen_vec_setv16qi(rtx_def*, rtx_def*, rtx_def*)
/home/seurer/gcc/git/gcc-test/gcc/config/rs6000/vector.md:1233
0x1097519b rtx_insn* insn_gen_fn::operator()(rtx_def*, rtx_def*, rtx_def*) const
/home/seurer/gcc/git/gcc-test/gcc/recog.h:407
0x1097519b maybe_gen_insn(insn_code, unsigned int, expand_operand*)
/home/seurer/gcc/git/gcc-test/gcc/optabs.c:7787
0x1097538f maybe_expand_insn(insn_code, unsigned int, expand_operand*)
/home/seurer/gcc/git/gcc-test/gcc/optabs.c:7820
0x1077c017 expand_vec_set_optab_fn
/home/seurer/gcc/git/gcc-test/gcc/internal-fn.c:2871
0x1077c017 expand_VEC_SET
/home/seurer/gcc/git/gcc-test/gcc/internal-fn.def:148
0x1078a82f expand_internal_call(internal_fn, gcall*)
/home/seurer/gcc/git/gcc-test/gcc/internal-fn.c:4079
0x1078a82f expand_internal_call(gcall*)
/home/seurer/gcc/git/gcc-test/gcc/internal-fn.c:4087
0x1044e617 expand_call_stmt
/home/seurer/gcc/git/gcc-test/gcc/cfgexpand.c:2749
0x1044e617 expand_gimple_stmt_1
/home/seurer/gcc/git/gcc-test/gcc/cfgexpand.c:3844
0x1044fd5f expand_gimple_stmt
/home/seurer/gcc/git/gcc-test/gcc/cfgexpand.c:4008
0x104577b3 expand_gimple_basic_block
/home/seurer/gcc/git/gcc-test/gcc/cfgexpand.c:6045
0x1045a28b execute
/home/seurer/gcc/git/gcc-test/gcc/cfgexpand.c:6729

commit d0a5e8e1a84bdd6ce915c3be65da8af2552cd49e
Author: Xionghu Luo 
Date:   Sun Mar 21 21:14:02 2021 -0500

rs6000: Convert the vector set variable idx to DImode [PR98914]

[Bug target/97926] ICE in patch_jump_insn, at cfgrtl.c:1298

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

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Segher Boessenkool :

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

commit r11-7767-gba16797fe69a0fae47355aa2c102ffac1c48c3bd
Author: Segher Boessenkool 
Date:   Fri Mar 19 15:02:00 2021 +

ubsan: Don't test for NaNs if those do not exist (PR97926)

2021-03-22  Segher Boessenkool  

PR target/97926
* ubsan.c (ubsan_instrument_float_cast): Don't test for unordered
if
there are no NaNs.

[Bug testsuite/97926] ICE in patch_jump_insn, at cfgrtl.c:1298

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

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

Segher Boessenkool  changed:

   What|Removed |Added

  Component|target  |testsuite
 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from Segher Boessenkool  ---
Fixed.

[Bug target/99708] __SIZEOF_FLOAT128__ not defined on powerpc64le-linux

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

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

--- Comment #1 from Segher Boessenkool  ---
Yes, the __SIZEOF_* macros do not say whether some type can be used.  This is
true for all targets!

What would it be useful for to define these macros?  They all are equivalent to

#define SIXTEEN 16

:-)

[Bug c/99707] missing -Woverflow warning in floating-point to integer conversion for known but non-constant value

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

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

--- Comment #4 from Andrew Pinski  ---
The front end does not normally do constant prop if the variable is not a
const/constexpr so the warning would be done in the middle end and might have
false warnings so it might not be useful.

[Bug c++/69549] Named Address Spaces does not compile in C++

[thiago at kde dot org via Gcc-bugs]

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

--- Comment #4 from Thiago Macieira  ---
And in GCC 11.

gcc version 11.0.1 20210308 (experimental) (GCC)

[Bug target/99581] [11 Regression] internal compiler error: during RTL pass: final - void QTWTF::TCMalloc_PageHeap::scavengerThread() since r11-7526

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

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

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

https://gcc.gnu.org/g:02f2dc441b1954736cc61e3f97687cd23d5586c5

commit r11-7768-g02f2dc441b1954736cc61e3f97687cd23d5586c5
Author: Vladimir N. Makarov 
Date:   Mon Mar 22 13:34:50 2021 -0400

[PR99581] Define relaxed memory and use it for aarch64

aarch64 needs to skip memory address validation for LD1R insns.  Skipping
the address validation may result in LRA crash for some targets when usual
memory constraint is used.  This patch introduces
define_relaxed_memory_constraint,
skipping address validation for it, and defining relaxed memory for
aarch64 LD1r insn memory operand.

gcc/ChangeLog:

PR target/99581
* config/aarch64/constraints.md (UtQ): Use
define_relaxed_memory_constraint for it.
* doc/md.texi (define_relaxed_memory_constraint): Describe it.
* genoutput.c (main): Process DEFINE_RELAXED_MEMORY_CONSTRAINT.
* genpreds.c (constraint_data): Add bitfield is_relaxed_memory.
(have_relaxed_memory_constraints): New static var.
(relaxed_memory_start, relaxed_memory_end): Ditto.
(add_constraint): Add arg is_relaxed_memory.  Check name for
relaxed memory.  Set up is_relaxed_memory in constraint_data and
have_relaxed_memory_constraints.  Adjust calls.
(choose_enum_order): Process relaxed memory.
(write_tm_preds_h): Ditto.
(main): Process DEFINE_RELAXED_MEMORY_CONSTRAINT.
* gensupport.c (process_rtx): Process
DEFINE_RELAXED_MEMORY_CONSTRAINT.
* ira-costs.c (record_reg_classes): Process CT_RELAXED_MEMORY.
* ira-lives.c (single_reg_class): Use
insn_extra_relaxed_memory_constraint.
* ira.c (ira_setup_alts): CT_RELAXED_MEMORY.
* lra-constraints.c (valid_address_p): Use
insn_extra_relaxed_memory_constraint instead of other memory
constraints.
(process_alt_operands): Process CT_RELAXED_MEMORY.
(curr_insn_transform): Use insn_extra_relaxed_memory_constraint.
* recog.c (asm_operand_ok, preprocess_constraints): Process
CT_RELAXED_MEMORY.
* reload.c (find_reloads): Ditto.
* rtl.def (DEFINE_RELAXED_MEMORY_CONSTRAINT): New.
* stmt.c (parse_input_constraint): Use
insn_extra_relaxed_memory_constraint.

gcc/testsuite/ChangeLog:

PR target/99581
* gcc.target/powerpc/pr99581.c: New.

[Bug target/99708] __SIZEOF_FLOAT128__ not defined on powerpc64le-linux

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

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

--- Comment #2 from Jakub Jelinek  ---
The __SIZEOF_*__ macros are widely used to detect both if a type can be used
and what sizeof (the_type) is when it needs to be checked in preprocessor
conditionals, including hundreds of times in GCC testsuite.
It is something supported by multiple compilers (GCC, clang, ICC at least).
Having to remember magic macros which are different on each arch and in each
compiler is much more complicated.
The topic this came up on is libstdc++ headers which in ext/numeric_traits.h
wants to provide ppc64le compatibility and right now assumes that if
__LONG_DOUBLE_IEEE128__ is defined then __ibm128 type can be used and
__LONG_DOUBLE_IBM128__ is defined then __ieee128 type can be used.
Apparently that is not the case at least for clang which didn't have __ieee128
support until very recently and __float128 support needs a non-default option
passed to the compiler.
Which was why I suggested to guard those by
# elif defined __LONG_DOUBLE_IBM128__ && __SIZEOF_FLOAT128__ == 16
or something similar, but it doesn't work for GCC.

[Bug c++/69549] Named Address Spaces does not compile in C++

[thiago at kde dot org via Gcc-bugs]

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

--- Comment #5 from Thiago Macieira  ---
BTW, Clang solved this by making __seg_fs, __seg_gs macros that resolve to
__attribute__:

$ clang -dM -E -xc /dev/null | grep __seg_.s
#define __seg_fs __attribute__((address_space(257)))
#define __seg_gs __attribute__((address_space(256)))

That way, they don't need to be deduced as qualifiers in C, like const,
volatile and _Atomic.

So this compiles with Clang in C++:

void *tid() { auto tib = (void * __seg_fs*)(0); return *tid; }

_Z3tibv:# @_Z3tibv
movq%fs:0, %rax
retq

[Bug target/99663] [11 Regression] ICE in extract_constrain_insn, at recog.c:2670 on s390x-linux-gnu

[doko at debian dot org via Gcc-bugs]

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

Matthias Klose  changed:

   What|Removed |Added

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

--- Comment #11 from Matthias Klose  ---
fixed

[Bug target/99703] gcc-10.2.0 with Via C3 Eden: configure: error: Intel CET must be enabled on Intel CET enabled host

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

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

--- Comment #11 from H.J. Lu  ---
(In reply to Worx from comment #10)
> When I deep dive, in the logs
> 
> No issue at the root level : 
> 
> c3eden /opt/gcc-10.2.0 # ./configure --disable-cet
> checking build system type... i686-pc-linux-gnu
> checking host system type... i686-pc-linux-gnu
> checking target system type... i686-pc-linux-gnu
> checking for a BSD-compatible install... /usr/bin/install -c
> checking whether ln works... yes
> [..]
> checking whether to enable maintainer-specific portions of Makefiles... no
> configure: creating ./config.status
> config.status: creating Makefile
> c3eden /opt/gcc-10.2.0 #
> 
> 
> But : 
> 
> 
> c3eden /opt/gcc-10.2.0 # lto-plugin/configure --disable-cet
> checking build system type... i686-pc-linux-gnu
> checking host system type... i686-pc-linux-gnu
> checking target system type... i686-pc-linux-gnu
> checking for a BSD-compatible install... /usr/bin/install -c
> checking whether build environment is sane... yes
> checking for a thread-safe mkdir -p... /bin/mkdir -p
> checking for gawk... gawk
> checking whether make sets $(MAKE)... yes
> checking whether make supports nested variables... yes
> checking whether to enable maintainer-specific portions of Makefiles... no
> checking for style of include used by make... GNU
> checking for gcc... gcc
> checking whether the C compiler works... yes
> checking for C compiler default output file name... a.out
> checking for suffix of executables...
> checking whether we are cross compiling... no
> checking for suffix of object files... o
> checking whether we are using the GNU C compiler... yes
> checking whether gcc accepts -g... yes
> checking for gcc option to accept ISO C89... none needed
> checking whether gcc understands -c and -o together... yes
> checking dependency style of gcc... gcc3
> checking how to run the C preprocessor... gcc -E
> checking for grep that handles long lines and -e... /bin/grep
> checking for egrep... /bin/grep -E
> checking for ANSI C header files... yes
> checking for sys/types.h... yes
> checking for sys/stat.h... yes
> checking for stdlib.h... yes
> checking for string.h... yes
> checking for memory.h... yes
> checking for strings.h... yes
> checking for inttypes.h... yes
> checking for stdint.h... yes
> checking for unistd.h... yes
> checking minix/config.h usability... no
> checking minix/config.h presence... no
> checking for minix/config.h... no
> checking whether it is safe to define __EXTENSIONS__... yes
> checking for gcc... (cached) gcc
> checking whether we are using the GNU C compiler... (cached) yes
> checking whether gcc accepts -g... (cached) yes
> checking for gcc option to accept ISO C89... (cached) none needed
> checking whether gcc understands -c and -o together... (cached) yes
> checking dependency style of gcc... (cached) gcc3
> checking for special C compiler options needed for large files... no
> checking for _FILE_OFFSET_BITS value needed for large files... 64
> checking whether gcc supports -Wall... yes
> checking for -static-libgcc... yes
> checking for CET support... configure: error: Intel CET must be enabled on
> Intel CET enabled host
> c3eden /opt/gcc-10.2.0 #

In which directory did it fail?

[Bug target/99703] gcc-10.2.0 with Via C3 Eden: configure: error: Intel CET must be enabled on Intel CET enabled host

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

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

--- Comment #12 from Sergei Trofimovich  ---
Downstream bug report is https://gcc.gnu.org/PR99703 (has all config.log files
and build log files). Caveat: Gentoo's gcc-10.2.0 has a
https://gitweb.gentoo.org/proj/gcc-patches.git/tree/10.2.0/gentoo/44_all_cet-i486.patch
applied (not yet in gcc master, I might have done it incorrectly).

To decrease unknowns, Worx, can you clone gcc's git tree and try to build gcc
out of it? On Gentoo system it should be a:

$ git clone git://gcc.gnu.org/git/gcc.git
$ mkdir gcc-build
$ cd gcc-build
$ patch -p1 /path/to/44_all_cet-i486.patch
$ ../gcc/configure
$ make

We'll need a build log and all `config.log` files (there will be a bunch in
different build dirs, one of them will contain CET mis-detection).