[Bug debug/97344] aarch64 tls debuginfo missing location info

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||qiyao at gcc dot gnu.org

--- Comment #8 from Andrew Pinski  ---
*** Bug 83010 has been marked as a duplicate of this bug. ***

[Bug debug/83010] [AARCH64] DW_AT_location is not emitted for thread local variable

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
Even though this bug is older, PR 97344 has more information on what needs to
be done to support this. Basically binutils as support needs to be added too.

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

[Bug middle-end/47590] pragma optimize doesn't recompute derived options (was: var tracking produces wrong debug in code where optimization is turned off using pragma)

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||wrong-debug
  Component|debug   |middle-end

--- Comment #10 from Andrew Pinski  ---
I wonder if this has been fixed since there has been so many fixes for #prama
optimize even in GCC 4.8.0.

[Bug driver/70419] descriptions of -fpic/-fPIC and -fpic/-fPIE aren't clear and contain syntax error

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

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Balint Reczey from comment #1)
> Also please fix the error message emitted when trying to link a non-PIE
> non-PIC static library to a position independent executable:

The error message comes from binutils project so it is hard for the GCC project
to fix it. Please report a bug to them (https://sourceware.org/bugzilla/ ).

[Bug driver/64499] -gsplit-dwarf splits objcopy argument at spaces in file path

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

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

--- Comment #1 from Andrew Pinski  ---
The problem is in ASM_FINAL_SPEC in gcc.c:
#ifndef ASM_FINAL_SPEC
#define ASM_FINAL_SPEC \
  "%{gsplit-dwarf: \n\
   objcopy --extract-dwo \
 %{c:%{o*:%*}%{!o*:%w%b%O}}%{!c:%U%O} \
 %b.dwo \n\
   objcopy --strip-dwo \
 %{c:%{o*:%*}%{!o*:%w%b%O}}%{!c:%U%O} \
}"
#endif


But this was changed r11-627, so it might have been fixed. I will test this in
a bit.

[Bug driver/90443] when collect2/lto-wrapper/gcc-nm/gcc-ld fails to find a program, it does not say which program is being found

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Mine.

[Bug driver/90902] collect2 does not propagate gcc -wrapper far enough to wrap ld

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Let me try to fix this.

[Bug driver/45749] Response file unwrapped between collect2.exe and ld.exe

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #13 from Andrew Pinski  ---
Let me try to fix this.

[Bug driver/91244] gcc-ar prepends --plugin option thus triggers binutils getopt_long bug 13256

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
Mine.

[Bug driver/77576] gcc-ar doesn't work if all options are read from file

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2022-01-01
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=91244
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #4 from Andrew Pinski  ---
Let me see if I can fix this. Adding != '@' does not seem correct. I suspect we
should expand the @file and then put it in a temp file and do the correct
thing.

[Bug target/99783] relocation truncated to fit: R_OR1K_GOT16 on OpenRISC, building libgeos

[shorne at gmail dot com via Gcc-bugs]

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

--- Comment #9 from shorne at gmail dot com ---
I was able to debug this.

Basically, the code to avoid overflow by masking the relocation value with
0x fails if the relocation value has the 16-bit sign bit set. I.e. 0x90e4
has 0x8000 set when we see the overflow message.

It seems the number of GOT relocations in libgeos as gone beyond this limit and
triggered this bug.

This is an oversite and needs a further patch to OpenRISC binutils.  I will
think about how to patch it and post a patch in a few days


DEBUG:

x   1184  status = bfd_check_overflow (howto->complain_on_overflow,
x   1185   howto->bitsize,
x   1186   howto->rightshift,
x   1187   bfd_arch_bits_per_address
(input_bfd),
x   1188   value);
x   1189  value >>= howto->rightshift;
x   1190
x   1191  /* If we're overwriting the entire destination,
x   1192 then no need to read the current contents.  */
x  >1193  if (size == 0 || howto->dst_mask == N_ONES (size))
x   1194x = 0;
x   1195  else
x   1196{
x   1197  BFD_ASSERT (size == 4);
x   1198  x = bfd_get_32 (input_bfd, contents + offset);
x   1199}
x   1200
x   1201  switch (howto->type)
x   1202{
x   1203case R_OR1K_SLO16:
x   1204case R_OR1K_GOTOFF_SLO16:
x   1205case R_OR1K_TLS_LE_SLO16:

native process 3648008 In: or1k_final_link_relocate L1193 PC:
0x43afb3
(gdb) n
or1k_final_link_relocate (howto=howto@entry=0x50fff0
, input_bfd=input_bfd@entry=0x57ac90,
input_section=input_section@entry=0x593fb8,
contents=contents@entry=0xb3e17b0 "\234!\377\374\030`", offset=68,
value=37092) at elf32-or1k.c:1189
(gdb) p status
$3 = bfd_reloc_overflow
(gdb) p/x value
$4 = 0x90e4

On Fri, Dec 31, 2021 at 11:26:06AM +, giulio.benetti at benettiengineering
dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99783

[Bug c++/103884] ICE when calling static and non-static member function templates with the same parameter types and requires clause

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||assemble-failure,
   ||ice-checking

--- Comment #1 from Andrew Pinski  ---
Note with -fno-checking GCC is able to compile the source but assembling is a
different question.

[Bug sanitizer/103878] ThreadSanitizer: false report about data race

[fchelnokov at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Fedor Chelnokov  ---
Bugreport for Clang/LLVM: https://github.com/llvm/llvm-project/issues/52942

[Bug c++/103884] New: ICE when calling static and non-static member function templates with the same parameter types and requires clause

[fchelnokov at gmail dot com via Gcc-bugs]

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

Bug ID: 103884
   Summary: ICE when calling static and non-static member function
templates with the same parameter types and requires
clause
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fchelnokov at gmail dot com
  Target Milestone: ---

Building this program:
```
struct A {
static int f(auto) { return 1; }
int f(auto) requires true { return 2; }
};

int main() {
[[maybe_unused]] int (A::*y)(int) = &A::f;
[[maybe_unused]] int (*x)(int) = &A::f;
}
```
results in ICE in GCC. Other compilers also show some errors, but not ICE.
Demo: https://gcc.godbolt.org/z/9aYofP31x

It is not clear yet whether `A` definition is correct, but all compilers accept
it. Related discussion: https://stackoverflow.com/q/70542265/7325599

[Bug c++/86143] ICE capturing constexpr chrono duration

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=88761
   Keywords||needs-bisection

--- Comment #1 from Andrew Pinski  ---
Looks to be fixed for GCC 8.3.0+ and GCC 9+. I suspect it might be fixed by PR
88761 but I could be wrong

[Bug sanitizer/103878] ThreadSanitizer: false report about data race

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

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

--- Comment #2 from Andrew Pinski  ---
Since it was reported that clang/LLVM have the same issue, is there a bug
report about that?

[Bug c++/98364] [modules] unnneded global constructors are emitted for a module

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |NEW
Summary|[modules] global|[modules] unnneded global
   |constructor emission|constructors are emitted
   ||for a module
   Severity|normal  |enhancement

--- Comment #8 from Andrew Pinski  ---
Confirmed:
;; Function (static initializers for hello.cc) (_ZGIW5helloEv)
;; enabled by -tree-original


{
  static bool __in_chrg;

static bool __in_chrg;
  if (__in_chrg)
{
  return;
}
  <;
}


In main-hello.cc.005t.original.

The code comes from start_objects in cp/decl2.c:


  if (module_init > 0)
{
  // 'static bool __in_chrg = false;
  // if (__inchrg) return;
  // __inchrg = true
  tree var = build_lang_decl (VAR_DECL, in_charge_identifier,
  boolean_type_node);
  DECL_CONTEXT (var) = fndecl;
  DECL_ARTIFICIAL (var) = true;
  TREE_STATIC (var) = true;
  pushdecl (var);
  cp_finish_decl (var, NULL_TREE, false, NULL_TREE, 0);

  tree if_stmt = begin_if_stmt ();
  finish_if_stmt_cond (var, if_stmt);
  finish_return_stmt (NULL_TREE);
  finish_then_clause (if_stmt);
  finish_if_stmt (if_stmt);

  tree assign = build2 (MODIFY_EXPR, boolean_type_node,
var, boolean_true_node);
  TREE_SIDE_EFFECTS (assign) = true;
  finish_expr_stmt (assign);
}
  if (module_init)
module_add_import_initializers ();

Maybe if there are no initializers, maybe we should not create the global init.

[Bug go/103847] gccgo SIGSEGV in libgo standard library on sparc64

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

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

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

https://gcc.gnu.org/g:7918d8270a43e42b0cba902ec17ce87b6a3c74a9

commit r12-6163-g7918d8270a43e42b0cba902ec17ce87b6a3c74a9
Author: Jakub Jelinek 
Date:   Sat Jan 1 06:30:39 2022 +0100

testsuite: Adjust gcc.misc-tests/godump-1.c testcase

On Wed, Dec 29, 2021 at 03:54:03PM -0800, Ian Lance Taylor via Gcc-patches
wrote:
> PR go/103847
> * godump.c (go_force_record_alignment): Name the alignment
> field "_".

> --- a/gcc/godump.c
> +++ b/gcc/godump.c
> @@ -651,7 +651,7 @@ go_force_record_alignment (struct obstack *ob, const
char *type_string,
>  unsigned int index, const char *error_string)
>  {
>index = go_append_artificial_name (ob, index);
> -  obstack_grow (ob, "_align ", 7);
> +  obstack_grow (ob, "_ ", 2);
>if (type_string == NULL)
>  obstack_grow (ob, error_string, strlen (error_string));
>else

This change caused
+FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^type _ts_nested struct { u
struct { s int16; Godump_0_pad [2]byte; Godump_1_align
[0]u?int32; }; }\$
+FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^type _ts_nested2 struct { u
struct { Godump_0_pad [4]byte; Godump_1_pad [2]byte; s int16; c
int8; Godump_2_pad
+[1]byte; Godump_3_pad [2]byte; Godump_4_align
[0]u?int32; }; }\$
+FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^type _tsbf_gaps struct {
bf1 uint8; c uint8; bf2 uint8; Godump_0_pad [2]byte; s uint16;
Godump_1_align [0]int32; }\$
+FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^type _tsbf_pad16_1 struct {
Godump_0_pad [1]byte; c uint8; Godump_1_align [0]int16; }\$
+FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^type _tsbf_pad16_2 struct {
Godump_0_pad [2]byte; c uint8; Godump_1_pad [.]byte;
Godump_2_align [0]int16; }\$
+FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^type _tsbf_pad32_1 struct {
Godump_0_pad [1]byte; c uint8; Godump_1_pad [.]byte;
Godump_2_align [0]int32; }\$
+FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^type _tsbf_pad32_2 struct {
Godump_0_pad [4]byte; c uint8; Godump_1_pad [.]byte;
Godump_2_align [0]int32; }\$
+FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^type _tsbf_pad64_1 struct {
Godump_0_pad [1]byte; c uint8; Godump_1_pad [.]byte;
Godump_2_align [0]int64; }\$
+FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^type _tsbf_pad64_2 struct {
Godump_0_pad [8]byte; c uint8; Godump_1_pad [.]byte;
Godump_2_align [0]int64; }\$
+FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^type _tsn_anon struct { a
uint8; s uint16; b uint8; Godump_0_pad [.]byte; Godump_1_align
[0]int16; }\$
+FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^type _tsu_anon struct { c
uint8; Godump_0_pad [7]byte; Godump_1_align [0]u?int64; }\$
+FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^type _tu1 struct { c uint8;
Godump_0_pad [.]byte; Godump_1_align [0]u?int64; }\$
+FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^type _tu3_size struct { ca
[4+1]uint8; Godump_0_pad [.]byte; Godump_1_align
[0]u?int64; }\$
+FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^type _tu_nested struct { u
struct { s int16; Godump_0_pad [2]byte; Godump_1_align
[0]u?int32; }; }\$
+FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^type _tu_nested2 struct { u
struct { Godump_0_pad [4]byte; Godump_1_pad [2]byte; s int16; c
int8; Godump_2_pad
+[1]byte; Godump_3_pad [2]byte; Godump_4_align
[0]u?int32; }; }\$
+FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^type _tu_size struct { ca
[4+1]uint8; Godump_0_pad [.]byte; Godump_1_align
[0]u?int64; }\$
+FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^var _s_nested struct { u
struct { s int16; Godump_0_pad [2]byte; Godump_1_align
[0]u?int32; }; }\$
+FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^var _s_nested2 struct { u
struct { Godump_0_pad [4]byte; Godump_1_pad [2]byte; s int16; c
int8; Godump_2_pad
+[1]byte; Godump_3_pad [2]byte; Godump_4_align
[0]u?int32; }; }\$
+FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^var _sbf_gaps struct { bf1
uint8; c uint8; bf2 uint8; Godump_0_pad [2]byte; s uint16;
Godump_1_align [0]int32; }\$
+FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^var _sbf_pad16_1 struct {
Godump_0_pad [1]byte; c uint8; Godump_1_align [0]int16; }\$
+FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^var _sbf_pad16_2 struct {
Godump_0_pad [2]byte; c uint8; Godump_1_pad [.]byte;
Godump_2_align [0

[Bug objc/103639] [11/12 Regression] switch case with break in fast enumeration loop generates wrong code

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

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

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

https://gcc.gnu.org/g:222dbebefbbc07f78e51d82ba605988ef57e5fc9

commit r12-6162-g222dbebefbbc07f78e51d82ba605988ef57e5fc9
Author: Jakub Jelinek 
Date:   Sat Jan 1 06:29:36 2022 +0100

objc: Fix handling of break stmt inside of switch inside of ObjC foreach
[PR103639]

The r11-3302-g3696a50beeb73f changes broke the following ObjC testcase.
in_statement is either 0 (not in a looping statement), various IN_* flags
for various kinds of looping statements (or OpenMP structured blocks) or
those flags ored with IN_SWITCH_STMT when a switch appears inside of those
contexts.  This is because break binds to switch in that last case, but
continue binds to the looping construct in that case.
The c_finish_bc_stmt function performs diagnostics on incorrect
break/continue uses and then checks if in_statement & IN_OBJC_FOREACH
and in that case jumps to the label provided by the caller, otherwise
emits a BREAK_STMT or CONTINUE_STMT.  This is incorrect if we have
ObjC foreach with switch nested in it and break inside of that,
in_statement in that case is IN_OBJC_FOREACH | IN_SWITCH_STMT and
is_break is true.  We want to handle it like other breaks inside of
switch, i.e. emit a BREAK_STMT.

The following patch fixes that.

2022-01-01  Jakub Jelinek  

PR objc/103639
* c-typeck.c (c_finish_bc_stmt): For break inside of switch inside
of
ObjC foreach, emit normal BREAK_STMT rather than goto to label.

2022-01-01  Iain Sandoe  

PR objc/103639
* objc.dg/pr103639.m: New test.

[Bug c++/103524] [meta-bug] modules issue

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

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

Bug 99051 Summary: [modules] ICE/SIGSEGV in get_location_from_adhoc_loc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99051

   What|Removed |Added

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

[Bug c++/99915] [modules] ICE in write_location

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||boris at kolpackov dot net

--- Comment #4 from Andrew Pinski  ---
*** Bug 99051 has been marked as a duplicate of this bug. ***

[Bug c++/99051] [modules] ICE/SIGSEGV in get_location_from_adhoc_loc

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Dup of bug 99915.

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

[Bug c++/103524] [meta-bug] modules issue

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

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

Bug 101184 Summary: [modules] ICE and unexpected behavior when using precisely 
5 stl-memory includes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101184

   What|Removed |Added

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

[Bug c++/99915] [modules] ICE in write_location

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||1lumin at protonmail dot com

--- Comment #3 from Andrew Pinski  ---
*** Bug 101184 has been marked as a duplicate of this bug. ***

[Bug c++/101184] [modules] ICE and unexpected behavior when using precisely 5 stl-memory includes.

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Dup of bug 99915

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

[Bug c++/100052] [11/12 regression] ICE in compiling g++.dg/modules/xtreme-header-3_b.C after r11-8118

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com

--- Comment #8 from Andrew Pinski  ---
*** Bug 12 has been marked as a duplicate of this bug. ***

[Bug c++/100002] internal compiler error: in hashtab_chk_error, at hash-table.c:137

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

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

--- Comment #3 from Andrew Pinski  ---
Sorry PR 100052.

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

[Bug c++/99861] [modules] ICE in hashtab_chk_error

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

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

Bug 12 Summary: internal compiler error: in hashtab_chk_error, at 
hash-table.c:137
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12

   What|Removed |Added

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

[Bug c++/103769] [11/12 Regression] checking ICE in hashtab_chk_error with alias template and pack expansion after r11-7931

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com

--- Comment #4 from Andrew Pinski  ---
*** Bug 12 has been marked as a duplicate of this bug. ***

[Bug c++/100002] internal compiler error: in hashtab_chk_error, at hash-table.c:137

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Dup of bug 103769.

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

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

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Alexander Lelyakin from comment #3)
> There is a suspect that 99737,99479,99722,99948 are all somehow connected
> with hashtab checking. At least some of examples change diagnostic with:
>   --param=hash-table-verification-limit=1000

The hash table verification bug looks to be PR 103769.

The majority of the other ones looks to be similar to PR 99479 where there is
some write/read after free happening and I reduced that testcase down to a
simple testcase (30 lines header file and a 4 line source file).

[Bug c++/99915] [modules] ICE in write_location

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Confirmed, I have seen this while reducing PR 99479

[Bug c++/99479] [modules] ICE Aborted signal terminated program cc1plus

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

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

--- Comment #19 from Andrew Pinski  ---
Created attachment 52106
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52106&action=edit
reduced testcase

Not even though it says PR 100129, this is the reduced testcase.
just execute t.sh which does:
gcc header.hh -std=c++20 -fmodules-ts
gcc t.cc -std=c++20 -fmodules-ts -wrapper valgrind,--error-exitcode=1

And you will see the valgrind failures.

[Bug debug/103874] [11/12 Regression] ICE in internal_error on riscv64 and -gsplit-dwarf

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

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

--- Comment #6 from Andrew Pinski  ---
I doubt many people use gsplit-dwarf really.

[Bug target/103874] [11/12 Regression] ICE in internal_error on riscv64

[aurelien at aurel32 dot net via Gcc-bugs]

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

Aurelien Jarno  changed:

   What|Removed |Added

 CC||jakub at redhat dot com

--- Comment #5 from Aurelien Jarno  ---
A bisect pointed me to that commit:

commit 4b33c5aaab9e863da162942ab8bcd54070b705af
Author: Jakub Jelinek 
Date:   Wed Mar 31 21:25:58 2021 +0200

dwarf2out: Fix up ranges for -gdwarf-5 -gsplit-dwarf [PR99490]

For -gdwarf-4 -gsplit-dwarf we used to emit .debug_ranges section
(so in the binaries/shared libraries) with DW_AT_ranges from skeleton
units as well as .debug_info.dwo pointing to it through DW_FORM_sec_offset
(and DW_AT_GNU_ranges_base pointing into section, not sure for what
reason exactly).
When DWARF5 support was being added, we've started using .debug_rnglists
section, added DW_AT_rnglists_base to the DW_TAG_skeleton_unit, kept
DW_AT_ranges with DW_FORM_sec_offset in the skeleton and switched
over to DW_FORM_rnglistx for DW_AT_ranges in .debug_info.dwo.
But the DWARF5 spec actually means for the ranges section (at least
everything for those DW_AT_ranges in .debug_info.dwo) to sit
in .debug_rnglists.dwo section next to the .debug_info.dwo, rather than
having consumers look it up in the binary/shared library instead.
Based on some discussions in the DWARF discuss mailing list:
   
http://lists.dwarfstd.org/pipermail/dwarf-discuss-dwarfstd.org/2021-March/thread.html#4765
this patch mostly follows what LLVM emits for that right now:
1) small .debug_rnglists section (when needed) just to cover the
   skeleton DW_AT_ranges (if present); the content of the section
   uses the Split DWARFy DW_RLE_* codes with addrx encodings where
   possible
2) DW_AT_ranges in the skeleton uses DW_FORM_sec_offset (difference
   from LLVM which uses DW_FORM_rnglistx, which makes it larger
   and ambiguous)
3) DW_AT_rnglists_base attribute is gone from the skeleton (again,
   unlike LLVM where it is just confusing what exactly it means because
   it is inherited; it would make sense if we emitted DW_FORM_rnglistx
   in non-split DWARF, but unless ranges are shared, I'm afraid we'd
   make DWARF larger with fewer relocations by that)
4) usually big .debug_rnglists.dwo section again with using DW_RLE_*x*
   where possible
5) DW_AT_ranges with DW_FORM_rnglistx from .debug_info.dwo referring to
   that .debug_rnglists.dwo ranges

2021-03-31  Jakub Jelinek  

PR debug/99490
* dwarf2out.c (debug_ranges_dwo_section): New variable.
(DW_RANGES_IDX_SKELETON): Define.
(struct dw_ranges): Add begin_entry and end_entry members.
(DEBUG_DWO_RNGLISTS_SECTION): Define.
(add_ranges_num): Adjust r initializer for addition of *_entry
members.
(add_ranges_by_labels): For -gsplit-dwarf and force_direct,
set idx to DW_RANGES_IDX_SKELETON.
(use_distinct_base_address_for_range): New function.
(index_rnglists): Don't set r->idx if it is equal to
DW_RANGES_IDX_SKELETON.  Initialize r->begin_entry and
r->end_entry for -gsplit-dwarf if those will be needed by
output_rnglists.
(output_rnglists): Add DWO argument.  If true, switch to
debug_ranges_dwo_section rather than debug_ranges_section.
Adjust l1/l2 label indexes.  Only output the offset table when
dwo is true and don't include in there the skeleton range
entry if present.  For -gsplit-dwarf, skip ranges that belong
to the other rnglists section.  Change return type from void
to bool and return true if there are any range entries for
the other section.  For dwarf_split_debug_info use
DW_RLE_startx_endx, DW_RLE_startx_length and DW_RLE_base_addressx
entries instead of DW_RLE_start_end, DW_RLE_start_length and
DW_RLE_base_address.  Use use_distinct_base_address_for_range.
(init_sections_and_labels): Initialize debug_ranges_dwo_section
if -gsplit-dwarf and DWARF >= 5.  Adjust ranges_section_label
and range_base_label indexes.
(dwarf2out_finish): Call index_rnglists earlier before finalizing
.debug_addr.  Never emit DW_AT_rnglists_base attribute.  For
-gsplit-dwarf and DWARF >= 5 call output_rnglists up to twice
with different dwo arguments.
(dwarf2out_c_finalize): Clear debug_ranges_dwo_section.

 gcc/dwarf2out.c | 255 ++--
 1 file changed, 211 insertions(+), 44 deletions(-)

[Bug c/93239] Enhancement: allow unevaluated statement expressions at filescope

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

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

Eric Gallager  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=65345
   Severity|normal  |enhancement
 CC||egallager at gcc dot gnu.org

[Bug libstdc++/103879] error: accessing value of variant::_Copy_ctor_base through a 'const variant' glvalue in a constant expression

[lhlaurini at hotmail dot com via Gcc-bugs]

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

Luiz Henrique Laurini  changed:

   What|Removed |Added

 CC||lhlaurini at hotmail dot com

--- Comment #3 from Luiz Henrique Laurini  ---
(In reply to Andrew Pinski from comment #2)
> MSVC also rejects it:
> example.cpp
> (14): error C2131: expression did not evaluate to a constant
> (10): note: failure was caused by call of undefined function or one
> not declared 'constexpr'
> (10): note: see usage of 'S::~S'

It does compile with MSVC v19.latest: https://godbolt.org/z/McKjfdP5Y.

[Bug target/103882] Register corruption in ASM only functions when optization is -O2/-Os/-O3

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
It does.

[Bug c/101537] -Wconversion false positive in ternary and |=

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
Created attachment 52105
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52105&action=edit
gcc12-pr101537.patch

Untested fix.  The PR101537 is fixed by this in both C and C++, PR103881 only
in C; for C++ we end up with a COMPOUND_EXPR with TARGET_EXPR and then
BIT_IOR_EXPR of something and the TARGET_EXPR_DECL.  We'd need to remember when
looking through COMPOUND_EXPRs if they don't have TARGET_EXPRs on the lhs and
if so, remember for conversion_warning the mapping from their TARGET_EXPR_DECLs
to those TARGET_EXPRs, so that we could then look those up.
But it seems unsafe_conversion_p has some BIT_*_EXPR handling code, so that
would need to be copied over into conversion_warning too.
Or perhaps alternatively we could change unsafe_conversion_p to handle whatever
is missing in there (SAVE_EXPRs, TARGET_EXPRs etc.).

[Bug fortran/95644] [F2018] IEEE_FMA is missing from the IEEE_ARITHMETIC module

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

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

   Target Milestone|--- |12.0

[Bug fortran/89639] FAIL: gfortran.dg/ieee/ieee_9.f90 -O0 (test for excess errors)

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

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

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

--- Comment #13 from Francois-Xavier Coudert  ---
Fixed at cb48166e52c0f159eb80a0666c4847825e294ec0

[Bug libstdc++/103879] error: accessing value of variant::_Copy_ctor_base through a 'const variant' glvalue in a constant expression

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

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

--- Comment #2 from Andrew Pinski  ---
MSVC also rejects it:
example.cpp
(14): error C2131: expression did not evaluate to a constant
(10): note: failure was caused by call of undefined function or one not
declared 'constexpr'
(10): note: see usage of 'S::~S'

[Bug libstdc++/103879] error: accessing value of variant::_Copy_ctor_base through a 'const variant' glvalue in a constant expression

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

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

--- Comment #1 from Andrew Pinski  ---
clang rejects it also (with their libc++):

:10:5: error: variable of non-literal type 'S' cannot be defined in a
constexpr function
  S s{"str"};
^
:6:29: note: 'S' is not literal because it has data member 'v' of
non-literal type 'std::variant' (aka 'variant, allocator>>')
  std::variant v;
^

[Bug target/103882] Register corruption in ASM only functions when optization is -O2/-Os/-O3

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

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

--- Comment #4 from Andrew Pinski  ---
noipa might help also. Though I can't remember if the IPA RA checks that (it
should).

[Bug target/103882] Register corruption in ASM only functions when optization is -O2/-Os/-O3

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
Oh that is because there is some IPA Register allocation going on. Anyways this
is still not a bug. You need to mark a0 as a clobber in the inline-asm to let
GCC know that a0 is touched.

[Bug target/103882] Register corruption in ASM only functions when optization is -O2/-Os/-O3

[krystalgamer at protonmail dot com via Gcc-bugs]

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

Jose Silva  changed:

   What|Removed |Added

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

--- Comment #2 from Jose Silva  ---
Marking as noinline does not help.

See the generated code:

```
0040014c :
  40014c:   27bdffe0addiu   sp,sp,-32
  400150:   afbf001csw  ra,28(sp)
  400154:   0c100050jal 400140 
  400158:   nop
  40015c:   8082lb  v0,0(a0)
  400160:   8fbf001clw  ra,28(sp)
  400164:   27bd0020addiu   sp,sp,32
  400168:   38420061xoriv0,v0,0x61
  40016c:   03e8jr  ra
  400170:   2c420001sltiu   v0,v0,1

```

The marking as a clobbered does work, but it doesn't fix the underlying issue.
On my original code I had a `syscall`, which passes the code execution to the
kernel that I have no control over or know the full implementation.


The specific syscall was overwriting the $a0 register which I simplified in my
example.

GCC when -O2 is enabled is making too strong assumptions about the code. To
better illustrate the issue, let me give another example. If I call a function
via a function pointer regardless of the optimization level, GCC will save all
caller-saved registers in use. But when it encounters an ASM statement it
treats it like it doesn't exist. In my opinion, the same assumptions made when
calling from a function pointer should apply when calling a function with
inline-asm*.

* Manually indicating the clobbered registers could override this behaviour

[Bug fortran/89639] FAIL: gfortran.dg/ieee/ieee_9.f90 -O0 (test for excess errors)

[dave.anglin at bell dot net via Gcc-bugs]

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

--- Comment #12 from dave.anglin at bell dot net ---
On 2021-12-29 12:26 p.m., fxcoudert at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89639
>
> --- Comment #10 from Francois-Xavier Coudert  
> ---
> Created attachment 52086
>--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52086&action=edit
> adjust testcase
>
> David, could you kindly test the attached patch, to see if it fixes things?
Tests pass with patch on hppa-unknown-linux-gnu.

[Bug c++/103876] Parameter pack not expanded in lambda within static_assert in a fold-expression of a lambda

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-12-31
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
Confirmed.

[Bug libstdc++/103866] AM_PROG_LIBTOOL not compatible with GCC_NO_EXECUTABLES

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

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

--- Comment #10 from Jonathan Wakely  ---
Created attachment 52104
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52104&action=edit
libstdc++: Fix freestanding build using --without-headers

[Bug libstdc++/103877] libstdc++ docs give a bad recommendation for printing C++ defines

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||documentation
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-12-31
 Ever confirmed|0   |1
  Component|web |libstdc++

--- Comment #1 from Jonathan Wakely  ---
Confirmed.

"g++ -E -dM -x c++ /dev/null" is simpler.

[Bug libstdc++/103866] AM_PROG_LIBTOOL not compatible with GCC_NO_EXECUTABLES

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

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

--- Comment #9 from Jonathan Wakely  ---
GCC_HEADER_STDINT is unusable for freestanding, because it uses autoconf's
AC_CHECK_SIZEOF with the default includes, which does #include 
unconditionally.

But we only use GCC_HEADER_STDINT to create include/gstdint.h which is only
needed by src/c++11/compatibility-atomic-c++0x.cc, which could just use
 instead.

For now we can just make the use of GCC_HEADER_STDINT depend on $is_hosted, but
I think we should just remove it eventually.

[Bug c/103880] GCC

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Invalid.

[Bug target/103882] Register corruption in ASM only functions when optization is -O2/-Os/-O3

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||inline-asm
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Andrew Pinski  ---
You either need to mark fail as noinline or you need to use extended inline-asm
to mark a0 as clobbered in the inline-asm. Or you need to have the inline-asm
save/restore a0.

[Bug c++/103878] ThreadSanitizer: false report about data race

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

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

--- Comment #1 from Jonathan Wakely  ---
Isn't this simply the documented limitation of tsan?
https://gcc.gnu.org/onlinedocs/libstdc++/manual/debug.html#debug.races

[Bug fortran/82207] ieee_class identifies signaling NaNs as quiet NaNs

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

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

  Attachment #52101|0   |1
is obsolete||

--- Comment #15 from Francois-Xavier Coudert  ---
Created attachment 52103
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52103&action=edit
Patch, v2

Updated patch, passing -fsignaling-nans to the build machinery for IEEE-related
runtime files. This fixes the __builtin_nans() issue, and is good practice in
any case.

[Bug middle-end/103883] New: Signaling NaN is not handled correctly on typedef'd floating-point type

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

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

Bug ID: 103883
   Summary: Signaling NaN is not handled correctly on typedef'd
floating-point type
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fxcoudert at gcc dot gnu.org
  Target Milestone: ---

Take this code:


#include 
#include 

typedef double GFC_REAL_8;

GFC_REAL_8 foo (void) { return __builtin_nans(""); }
double bar (void) { return __builtin_nans(""); }

int main (void) {
  double x;

  x = __builtin_nans ("");
  printf("==> %lX\n", *(uint64_t *) &x);
  x = foo ();
  printf("==> %lX\n", *(uint64_t *) &x);
  x = bar ();
  printf("==> %lX\n", *(uint64_t *) &x);
}


Compiling this with GCC:

==> 7FF4
==> 7FF8
==> 7FF4

That is, the first and third calls returns a signalling nan, but the second one
returns a quiet nan. -fsignaling-nans fixes the issue, but I do not believe it
should be necessary here. There is no floating-point operation being performed.

See also: Joseph discussion of this issue at
https://gcc.gnu.org/pipermail/gcc/2021-December/237977.html

[Bug c/103881] Wconversion false positive when using |= and &= with two rvalues in binary op

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

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

--- Comment #2 from Jakub Jelinek  ---
See C99 6.3.1.1/2 and 6.3.1.8, yes, in all cases of |=, &=, |, & the uint8_t
operands are promoted to int.
And the reason why we don't warn for the simple binary operations is that those
common cases have special cases for the warnings, while if you have more
complex expressions you get warnings.  This is a FE warning, value range
propagation etc. doesn't happen at that point...

[Bug c/103881] Wconversion false positive when using |= and &= with two rvalues in binary op

[thomas at habets dot se via Gcc-bugs]

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

--- Comment #1 from thomas at habets dot se ---
I just reproduced this from git HEAD, as seen on github (commit
e3cbb8c66c930ba738674b0fcf29848dc3ecfef2), with latest commit today,
2021-12-31.

[Bug rtl-optimization/98782] [11/12 Regression] Bad interaction between IPA frequences and IRA resulting in spills due to changes in BB frequencies

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

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #32 from rsandifo at gcc dot gnu.org  
---
Created attachment 52102
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52102&action=edit
Alternative patch

This patch is a squash of several ira tweaks that together recover the
pre-GCC11 exchange2 performance on aarch64.  It isn't ready for trunk
yet (hence lack of comments and changelog).  It would be great to hear
whether/how it works on other targets though.

The patch bootstraps on aarch64-linux-gnu and x86_64-linux-gnu,
but there are some new scan-assembler failures that need looking at.

Quoting from the covering message:

The main changes are:

(1) Add ira_loop_border_costs to simplify spill cost calculations
(NFC intended)

(2) Avoid freeing updated costs until the loop node has been fully
allocated.  This in turn allows:

(3) Make improve_allocation work exclusively on updated costs,
rather than using a mixture of updated and original costs.
One reason this matters is that the register costs only make
sense relative to the memory costs, so in some cases,
a common register is subtracted from the updated memory cost
instead of being added to each individual updated register cost.

(4) If a child allocno has a hard register conflict, allow the parent
allocno to handle the conflict by spilling to memory throughout
the child allocno's loop.  This carries the child allocno's full
memory cost plus the cost of spilling to memory on entry to the
loop and restoring it on exit, but this can still be cheaper
than spilling the entire parent allocno.  In particular, it helps
for allocnos that are live across a loop but not referenced
within it, since the child allocno's memory cost is 0 in
that case.

(5) Extend (4) to cases in which the child allocno is live across
a call.  The parent then has a free choice between spilling
call-clobbered registers around each call (as normal) or
spilling them on entry to the loop, keeping the allocno in memory
throughout the loop, and restoring them on exit from the loop.

(6) Detect <80><9C>soft conflicts<80><9D> in which:

- one allocno (A1) is a cap whose (transitive) <80><9C>real<80><9D>
allocno
  is A1'

- A1' occurs in loop L1'

- the other allocno (A2) is a non-cap allocno

- the equivalent of A2 is live across L1' (hence the conflict)
  but has no references in L1'

In this case we can spill A2 around L1' (or perhaps some parent
loop) and reuse the same register for A1'.  A1 and A2 can then
use the same hard register, provided that we make sure not to
propagate A1's allocation to A1'.

[Bug c/101537] -Wconversion false positive in ternary and |=

[thomas at habets dot se via Gcc-bugs]

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

thomas at habets dot se changed:

   What|Removed |Added

 CC||thomas at habets dot se

--- Comment #3 from thomas at habets dot se ---
This may be related, as the bug I just filed seemed to be another case of the
warning not being suppressed.

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

[Bug target/103882] New: Register corruption in ASM only functions when optization is -O2/-Os/-O3

[krystalgamer at protonmail dot com via Gcc-bugs]

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

Bug ID: 103882
   Summary: Register corruption in ASM only functions when
optization is -O2/-Os/-O3
   Product: gcc
   Version: 10.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: krystalgamer at protonmail dot com
  Target Milestone: ---
  Host: x86_64-linux-gnu
Target: mips-linux-gnu
 Build: x86_64-linux-gnu

When a function is only composed of an `asm` statement if the optimizations are
at least -O2 it will make it assume none of the registers will be tainted.


Example code:

```
int is_first_char_a(const char *f){
return f[0] == 'a';
}

void fail(){
asm __volatile__ (
"li $a0, 0x60606060\n"
);
}

int example(char *c){
fail();
return is_first_char_a(c);
}

void __start(){}
```


Compiled with `-nostdlib -O1`, generates the following code:

```
00400180 :
  400180:   27bdffe0addiu   sp,sp,-32
  400184:   afbf001csw  ra,28(sp)
  400188:   afb00018sw  s0,24(sp)
  40018c:   00808025moves0,a0
  400190:   0c10005djal 400174 
  400194:   nop
  400198:   8202lb  v0,0(s0)
  40019c:   38420061xoriv0,v0,0x61
  4001a0:   2c420001sltiu   v0,v0,1
  4001a4:   8fbf001clw  ra,28(sp)
  4001a8:   8fb00018lw  s0,24(sp)
  4001ac:   03e8jr  ra
  4001b0:   27bd0020addiu   sp,sp,32
```


Compiled with `-nostdlib -O2`, generates the following code:

```
00400180 :
  400180:   3c046060lui a0,0x6060
  400184:   34846060ori a0,a0,0x6060
  400188:   8082lb  v0,0(a0)
  40018c:   38420061xoriv0,v0,0x61
  400190:   03e8jr  ra
  400194:   2c420001sltiu   v0,v0,1
```


As can be seen before -O1 levels of optimization the compiler saves $a0 in $s0
and then restores it. -O2 level and beyond causes the compiler to assume that
a0 is preserved.



>From what I can tell this might be because the optimizer doesn't take into
consideration ASM statements(which is good), but it makes wrong assumptions. A
possible solution would be to save the caller-saved registers whenever a
function with an ASM statement is called.

[Bug fortran/82207] ieee_class identifies signaling NaNs as quiet NaNs

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

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

--- Comment #14 from Francois-Xavier Coudert  ---
Created attachment 52101
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52101&action=edit
First attempt at a patch

This is a first version of a patch for support of signalling NaNs. What it
does:

- In the code implementing IEEE_CLASS, use the target issignaling macro (from
TS 18661-1:2014) to check whether a NaN is signalling.
- Sadly, very few targets implement this (I think only glibc targets,
currently). This means we will have to provide fallback implementations. A
first attempt at fallback implementations is included in the patch, but has not
been tested thoroughly. It will require testing on many platforms to be
validated.
- I moved the library implementation of IEEE_VALUE from Fortran to C code,
which gives us access to GCC's built-in functions for NaN generation (both
quiet and signalling).

What remains to be done:
- Write testcases that exercise the different aspects of these functions
- Figure out a weird behaviour for __builtin_nanq() in C code:
https://gcc.gnu.org/pipermail/gcc/2021-December/237976.html
- More testcases :)
- Testing the behaviour on different targets

Help would be appreciated in finding good testcases.

[Bug c/103881] New: Wconversion false positive when using |= and &= with two rvalues in binary op

[thomas at habets dot se via Gcc-bugs]

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

Bug ID: 103881
   Summary: Wconversion false positive when using |= and &= with
two rvalues in binary op
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thomas at habets dot se
  Target Milestone: ---

Got:

Warnings of conversion from int when doing "x |= f() | f()", with all types set
to uint8_t.

No warning when using "=" instead of "|=".

Per https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40752, this makes me wonder if
"|=" creates as implicit cast to int (but why?).
But if that's the case then why does "x |= f()" and "x |= a & a" not warn?
And if "|=" implicitly casts to int, that should mean there's no way at all to
not trigger this warning for |= into an uint8_t?

Or does binary "&" implicitly cast to int (again, why?), then why does "x |= a
& a" and "x = f() & f()" not warn?

Reproduce program:
#include
uint8_t f();
void foo()
{
  uint8_t t = 0;
  t |= f();   // one rvalue: no warning
  t |= f() & f(); // two rvalues: warn
  t &= f() & f(); // same with &=
  t = f() & f();  // no warning with assign

  uint8_t a = f(); // no warning
  t |= a & a;  // no warning with variables.
  t |= f() & a;// warning with one rvalue
  t |= a & f();// no matter position.
}

Output
$ gcc -v -save-temps -Wconversion -c bug2.c
Using built-in specs.
COLLECT_GCC=gcc
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 11.2.0-10'
--with-bugurl=file:///usr/share/doc/gcc-11/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-11
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib
--enable-libphobos-checking=release --with-target-system-zlib=auto
--enable-objc-gc=auto --enable-multiarch --disable-werror --enable-cet
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-11-R0liEm/gcc-11-11.2.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-11-R0liEm/gcc-11-11.2.0/debian/tmp-gcn/usr
--without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
--with-build-config=bootstrap-lto-lean --enable-link-serialization=8
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.2.0 (Debian 11.2.0-10) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wconversion' '-c' '-mtune=generic'
'-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/11/cc1 -E -quiet -v -imultiarch x86_64-linux-gnu
bug2.c -mtune=generic -march=x86-64 -Wconversion -fpch-preprocess
-fasynchronous-unwind-tables -o bug2.i
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-gnu/11/include-fixed"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-linux-gnu/11/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-linux-gnu/11/include
 /usr/local/include
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wconversion' '-c' '-mtune=generic'
'-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/11/cc1 -fpreprocessed bug2.i -quiet -dumpbase
bug2.c -dumpbase-ext .c -mtune=generic -march=x86-64 -Wconversion -version
-fasynchronous-unwind-tables -o bug2.s
GNU C17 (Debian 11.2.0-10) version 11.2.0 (x86_64-linux-gnu)
compiled by GNU C version 11.2.0, GMP version 6.2.1, MPFR version
4.1.0, MPC version 1.2.1, isl version isl-0.24-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C17 (Debian 11.2.0-10) version 11.2.0 (x86_64-linux-gnu)
compiled by GNU C version 11.2.0, GMP version 6.2.1, MPFR version
4.1.0, MPC version 1.2.1, isl version isl-0.24-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 010de8893e7b0de1cd6903c6a1890e7a
bug2.c: In function ‘foo’:
bug2.c:7:8: warning: conversion from ‘int’ to ‘uint8_t’ {aka ‘unsigned char’}
may change value [-Wconversion]
7 |   t |= f() & f(); // two rvalues: warn
  |^
bug2.c:8:8: warning: conversion from ‘int’ to ‘uint8_t’ {aka ‘unsigned char’}
may change value [-Wconversion]
8 |   t &= f() & f(); // same with &=
  |^
bug2.c

[Bug c/103880] GCC

[krystalgamer at protonmail dot com via Gcc-bugs]

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

--- Comment #1 from Jose Silva  ---
pressed enter, and accidentally submitted :|

[Bug c/103880] New: GCC

[krystalgamer at protonmail dot com via Gcc-bugs]

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

Bug ID: 103880
   Summary: GCC
   Product: gcc
   Version: 10.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: krystalgamer at protonmail dot com
  Target Milestone: ---
  Host: x86_64-linux-gnu
Target: mips-linux-gnu
 Build: x86_64-linux-gnu

[Bug target/103874] [11/12 Regression] ICE in internal_error on riscv64

[aurelien at aurel32 dot net via Gcc-bugs]

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

--- Comment #4 from Aurelien Jarno  ---
This is a better backtrace after building a riscv64 cross compiler from the
releases/gcc-11 branch:

/tmp/onnxifi_loader.c.i:6:1: internal compiler error: Segmentation fault
6 | }
  | ^
0xadad0f crash_signal
/home/aurel32/git/gcc/gcc/toplev.c:327
0x76ef21 output_rnglists
/home/aurel32/git/gcc/gcc/dwarf2out.c:12174
0x7b7782 dwarf2out_finish
/home/aurel32/git/gcc/gcc/dwarf2out.c:32058
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/103329] [11/12 Regression] Code divergence in debug info with -fdump-tree-original since r11-291-g0f50f6daa140186a

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

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

--- Comment #4 from Jakub Jelinek  ---
But, if we avoid that
  /* Mark enumeration types as used.  */
  if (TREE_CODE (decl) == CONST_DECL)
used_types_insert (DECL_CONTEXT (decl));
during error.c instantiations, will it be actually marked if something later
needs that particular instantiation (I mean, don't we in that case just reuse
what we've instantiated during the error.c instantiations rather than trying to
instantiate it again)?

[Bug libstdc++/103879] New: error: accessing value of variant::_Copy_ctor_base through a 'const variant' glvalue in a constant expression

[hewillk at gmail dot com via Gcc-bugs]

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

Bug ID: 103879
   Summary: error: accessing value of variant::_Copy_ctor_base
through a 'const variant' glvalue in a
constant expression
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hewillk at gmail dot com
  Target Milestone: ---

From
https://stackoverflow.com/questions/70541636/stdvariant-of-stdstring-inside-any-class-in-constexpr-context-fails-to-compi

#include 
#include 

struct S {
  std::variant v;
};

constexpr int func() {
  S s{"str"};
  return 0;
}

constexpr int x = func();

I think this should be well-formed.

[Bug c++/103878] New: ThreadSanitizer: false report about data race

[fchelnokov at gmail dot com via Gcc-bugs]

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

Bug ID: 103878
   Summary: ThreadSanitizer: false report about data race
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fchelnokov at gmail dot com
  Target Milestone: ---

The program as follows is valid:
```
#include 
#include 
#include 

int state = 0;
std::atomic_int a = 0;

void foo(int from, int to) 
{
for (int i = 0; i < 10; i++)
{
while (a.load(std::memory_order_relaxed) != from) {}
std::atomic_thread_fence(std::memory_order_acquire);
state++;
a.store(to, std::memory_order_release);
}
}

int main()
{
auto x = std::async(std::launch::async, foo, 0, 1);
auto y = std::async(std::launch::async, foo, 1, 0);
}
```
The access to `state` variable is not a data race, because each thread before
the modification executes `atomic_thread_fence` to see the results of the other
thread, and after the modification executes atomic store with
`memory_order_release`. But the sanitizer erroneously reports data race. Demo:
https://gcc.godbolt.org/z/9cY3aM3cz

Related discussion: https://stackoverflow.com/q/70542993/7325599

[Bug tree-optimization/103873] [12 Regression] wrong code at -O3 on x86_64-linux-gnu

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 CC||jakub at gcc dot gnu.org,
   ||matz at gcc dot gnu.org
Summary|wrong code at -O3 on|[12 Regression] wrong code
   |x86_64-linux-gnu|at -O3 on x86_64-linux-gnu
 Status|UNCONFIRMED |NEW
Version|unknown |12.0
   Priority|P3  |P1
   Target Milestone|--- |12.0
   Last reconfirmed||2021-12-31

--- Comment #1 from Jakub Jelinek  ---
Started to ICE with r12-4526-gd8edfadfc7a9795b65177a50ce44fd348858e844
(before it compiled and executed fine) and starting with
r12-5264-gd1ca8aeaf34a717dffd8f4a1f0333d25c7d1c904 it doesn't ICE anymore but
is instead miscompiled.
Perhaps related to PR103300 ?

[Bug target/103874] [11/12 Regression] ICE in internal_error on riscv64

[aurelien at aurel32 dot net via Gcc-bugs]

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

--- Comment #3 from Aurelien Jarno  ---
I have been able to reduce the reproducer code to almost nothing, so I guess
the issue is mostly related to the options and not to the source code.

[Bug target/103874] [11/12 Regression] ICE in internal_error on riscv64

[aurelien at aurel32 dot net via Gcc-bugs]

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

Aurelien Jarno  changed:

   What|Removed |Added

  Attachment #52099|0   |1
is obsolete||

--- Comment #2 from Aurelien Jarno  ---
Created attachment 52100
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52100&action=edit
Minimal reproducer

[Bug c++/36566] Cannot bind packed field

[steve+gcc at tecwec dot eu via Gcc-bugs]

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

Eric Estievenart  changed:

   What|Removed |Added

 CC||steve+gcc at tecwec dot eu

--- Comment #14 from Eric Estievenart  ---
What about:
struct S
{
int i;
}  __attribute__((__packed__)) __attribute((aligned(8)));

void f( S* s )
{
int& i = s->i; // Error here
}

S::i is obviously properly aligned, the compiler should know it and accept the
referencing.

As for the argument 'the field might be unaligned and this would violate... and
crash...', I don´t really agree. The compiler knows the arch, the alignment,
and it can decide:
- to emit an error if unaligned(or unknown) if alignment required by arch
- to emit a warning on other arch

Note by the way that this seems accepted by clang...

[Bug web/103877] New: libstdc++ docs give a bad recommendation for printing C++ defines

[blubban at gmail dot com via Gcc-bugs]

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

Bug ID: 103877
   Summary: libstdc++ docs give a bad recommendation for printing
C++ defines
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: web
  Assignee: unassigned at gcc dot gnu.org
  Reporter: blubban at gmail dot com
  Target Milestone: ---

https://gcc.gnu.org/onlinedocs/libstdc++/faq.html#faq.predefined

> You can also run g++ -E -dM - < /dev/null" to display a
> list of predefined macros for any particular installation.

Issue 1: The unmatched quote.

Issue 2: g++ -E defaults to C mode, where _GNU_SOURCE is, in fact, not defined.
The correct command is  g++ -E -dM -xc++ - < /dev/null

[Bug ipa/103875] Dead writes are not optimized out

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
  Component|middle-end  |ipa
   Severity|normal  |enhancement
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-12-31
 CC||marxin at gcc dot gnu.org

--- Comment #1 from Andrew Pinski  ---
The inliner removes the clobber in this case it seems:
We have:

void foo::pop (struct foo * const this)
{
  long unsigned int _1;
  long unsigned int _2;
  long unsigned int _3;
  value_type * _4;

   :
  _1 = this_6(D)->size;
  _2 = _1 + 18446744073709551615;
  this_6(D)->size = _2;
  _3 = this_6(D)->size;
  _4 = &this_6(D)->data[_3];
  *_4 ={v} {CLOBBER};
  return;

}
void use_foo (struct foo & f)
{
  int _1;
  int _2;
  value_type & _6;

   :
  _6 = foo::back (f_4(D));
  _1 = *_6;
  _2 = _1 * 42;
  *_6 = _2;
  foo::pop (f_4(D));
  return;

}

And then foo::pop (and back) gets inlined we get:

void use_foo (struct foo & f)
{
  value_type & D.2143;
  int _1;
  int _2;
  long unsigned int _5;
  value_type & _6;
  long unsigned int _9;
  long unsigned int _10;
  long unsigned int _11;
  value_type & _12;
  value_type & _13;

   :
  _10 = f_4(D)->size;
  _11 = _10 + 18446744073709551615;
  _12 = &f_4(D)->data[_11];
  _13 = _12;
  _6 = _13;
  _1 = *_6;
  _2 = _1 * 42;
  *_6 = _2;
  _5 = f_4(D)->size;
  _9 = _5 + 18446744073709551615;
  f_4(D)->size = _9;
  return;

}

[Bug c++/103876] New: Parameter pack not expanded in lambda within static_assert in a fold-expression of a lambda

[johelegp at gmail dot com via Gcc-bugs]

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

Bug ID: 103876
   Summary: Parameter pack not expanded in lambda within
static_assert in a fold-expression of a lambda
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: johelegp at gmail dot com
CC: johelegp at gmail dot com
  Target Milestone: ---

See https://godbolt.org/z/5W1fYn7E4.

```C++
void f() {
  [](auto... op) {
(..., void([] {
  static_assert([] {
return requires(T v) { op(v); };
  }.template operator()());
}));
  }([](...) {});
}
```

```
In instantiation of 'f():: [with auto:1 =
{f()::}]':
:8:4:   required from here
:5:16: error: parameter packs not expanded with '...':
5 | return requires(T v) { op(v); };
  |^~~~
:5:16: note: 'op'
:6:33: error: could not convert 'f()::().f()::()' from 'void' to 'bool'
4 |   static_assert([] {
  | ~
5 | return requires(T v) { op(v); };
  | 
6 |   }.template operator()());
  |   ~~^~
  | |
  | void"
```

[Bug pending/103875] New: Dead writes are not optimized out

[lh_mouse at 126 dot com via Gcc-bugs]

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

Bug ID: 103875
   Summary: Dead writes are not optimized out
   Product: gcc
   Version: 11.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: pending
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lh_mouse at 126 dot com
  Target Milestone: ---

I was reading
,
which I think is a great article. But the issue that was mentioned in that
article seems to be specific to `std::vector`.

Specifically, for this hand-written 'static vector', neither GCC or Clang is
able to optimize out any dead writes (godbolt [1]):

```
struct foo
  {
using value_type = int;

unsigned long size;
value_type data[10];

value_type&
back()
  {
return this->data[this->size-1];
  }

void
pop()
  {
this->size --;
this->data[this->size].~value_type();   // the last element is
destroyed here
  }
  };

void
use_foo(foo& f)
  {
f.back() *= 42;   // this write should be dead
f.pop();
  }
```

```
use_foo(foo&):
mov rdx, QWORD PTR [rdi]
lea rax, [rdx-1]
imuledx, DWORD PTR [rdi+4+rdx*4], 42
mov DWORD PTR [rdi+8+rax*4], edx   # dead write is here
mov QWORD PTR [rdi], rax
ret
```


Making `value_type` non-trivial as suggested does not help (godbolt [2]):

```
struct foo
  {
struct value_type
  {
int val = 0;
int& operator*=(int x) { return this->val *= x;  }
~value_type() { }  // non-trivial
  };

unsigned long size;
value_type data[10];

value_type&
back()
  {
return this->data[this->size-1];
  }

void
pop()
  {
this->size --;
this->data[this->size].~value_type();
  }
  };

void
use_foo(foo& f)
  {
f.back() *= 42;
f.pop();
  }
```

```
use_foo(foo&):
mov rdx, QWORD PTR [rdi]
lea rax, [rdx-1]
imuledx, DWORD PTR [rdi+4+rdx*4], 42
mov DWORD PTR [rdi+8+rax*4], edx# dead write is still here
mov QWORD PTR [rdi], rax
ret
```


[1] https://gcc.godbolt.org/z/f9xx3c6Y7
[2] https://gcc.godbolt.org/z/Ysss5GMjj

[Bug c/103874] [11/12 Regression] ICE in internal_error on riscv64

[aurelien at aurel32 dot net via Gcc-bugs]

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

--- Comment #1 from Aurelien Jarno  ---
Sorry I submitted the bug by mistake without filling a comment.

pytorch failed to build in Debian on riscv64 following the switch to GCC 11 by
default:
https://buildd.debian.org/status/fetch.php?pkg=pytorch&arch=riscv64&ver=1.8.1-2%2Bb3&stamp=1640951671&raw=0

I have extracted a reproducer (attached), here are the output with GCC 10, 11
and 12:

aurel32@beaglev:~/pytorch$ gcc-10 -v
Using built-in specs.
COLLECT_GCC=gcc-10
COLLECT_LTO_WRAPPER=/usr/lib/gcc/riscv64-linux-gnu/10/lto-wrapper
Target: riscv64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 10.3.0-13'
--with-bugurl=file:///usr/share/doc/gcc-10/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-10
--program-prefix=riscv64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
--enable-gnu-unique-object --disable-libitm --disable-libsanitizer
--disable-libquadmath --disable-libquadmath-support --enable-plugin
--enable-default-pie --with-system-zlib --enable-libphobos-checking=release
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch
--disable-werror --disable-multilib --with-arch=rv64imafdc --with-abi=lp64d
--enable-checking=release --build=riscv64-linux-gnu --host=riscv64-linux-gnu
--target=riscv64-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.3.1 2027 (Debian 10.3.0-13)
aurel32@beaglev:~/pytorch$ /usr/bin/gcc-10 -gsplit-dwarf -O2 -g -fPIC -std=c90
-c ./onnxifi_loader.c.i
aurel32@beaglev:~/pytorch$


aurel32@beaglev:~/pytorch$ gcc-11 -v
Using built-in specs.
COLLECT_GCC=gcc-11
COLLECT_LTO_WRAPPER=/usr/lib/gcc/riscv64-linux-gnu/11/lto-wrapper
Target: riscv64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 11.2.0-13'
--with-bugurl=file:///usr/share/doc/gcc-11/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-11
--program-prefix=riscv64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
--enable-gnu-unique-object --disable-libitm --disable-libquadmath
--disable-libquadmath-support --enable-plugin --enable-default-pie
--with-system-zlib --enable-libphobos-checking=release
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch
--disable-werror --disable-multilib --with-arch=rv64imafdc --with-abi=lp64d
--enable-checking=release --build=riscv64-linux-gnu --host=riscv64-linux-gnu
--target=riscv64-linux-gnu --with-build-config=bootstrap-lto-lean
--enable-link-serialization=2
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.2.0 (Debian 11.2.0-13)   
(sid-riscv64)aurel32@beaglev:~/pytorch$ /usr/bin/gcc-11 -gsplit-dwarf -O2 -g
-fPIC -std=c90 -c ./onnxifi_loader.c.i
/home/aurel32/pytorch/pytorch-1.8.1/debian/foxi/foxi/onnxifi_loader.c:212:1:
internal compiler error: Segmentation fault
  212 | }
  | ^
0xa26915 internal_error(char const*, ...)
???:0
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
aurel32@beaglev:~/pytorch$


aurel32@beaglev:~/pytorch$ gcc-12 -v
Using built-in specs.
COLLECT_GCC=gcc-12
COLLECT_LTO_WRAPPER=/usr/lib/gcc/riscv64-linux-gnu/12/lto-wrapper
Target: riscv64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 12-20211217-1'
--with-bugurl=file:///usr/share/doc/gcc-12/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-12
--program-prefix=riscv64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
--enable-gnu-unique-object --disable-libitm --disable-libquadmath
--disable-libquadmath-support --enable-plugin --enable-default-pie
--with-system-zlib --enable-libphobos-checking=release
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch
--disable-werror --disable-multilib --with-arch=rv64imafdc --with-abi=lp64d
--enable-checking=release --build=riscv64-linux-gnu --host=riscv64-linux-gnu
--target=riscv64-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.0 20211217 (experimental) [master r12-6027-g774269aa4b9]
(Debian 12-2021121

[Bug c/103874] New: [11/12 Regression] ICE in internal_error on riscv64

[aurelien at aurel32 dot net via Gcc-bugs]

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

Bug ID: 103874
   Summary: [11/12 Regression] ICE in internal_error on riscv64
   Product: gcc
   Version: 11.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aurelien at aurel32 dot net
  Target Milestone: ---

Created attachment 52099
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52099&action=edit
Reproducer

[Bug c++/103871] [11/12 Regression] co_await causes build error

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

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

--- Comment #4 from Iain Sandoe  ---
this is most likely a dup of 98056 - I have some WIP to deal with that (but it
needs some more tidying before posting).

[Bug target/99783] relocation truncated to fit: R_OR1K_GOT16 on OpenRISC, building libgeos

[giulio.benetti at benettiengineering dot com via Gcc-bugs]

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

--- Comment #8 from Giulio Benetti  ---
Thanks a lot Stafford

[Bug tree-optimization/103873] New: wrong code at -O3 on x86_64-linux-gnu

[zhendong.su at inf dot ethz.ch via Gcc-bugs]

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

Bug ID: 103873
   Summary: wrong code at -O3 on x86_64-linux-gnu
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhendong.su at inf dot ethz.ch
  Target Milestone: ---

It appears to be a recent regression.

[568] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--prefix=/local/suz-local/software/local/gcc-trunk --enable-languages=c,c++
--disable-werror --disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20211231 (experimental) (GCC) 
[569] % 
[569] % gcctk -O2 small.c; ./a.out
[570] % 
[570] % gcctk -O3 small.c
[571] % ./a.out
Aborted
[572] % 
[572] % cat small.c
int a, b, c, d[3], e, f;
int main() {
  if (b)
goto L;
  for (; f < 1; f++)
for (; a < 1; a++) {
  for (c = 0; c < 3; c++)
for (e = 0; e < 3; e++)
  d[e] |= c;
  for (; b; b++)
  L:;
}
  if (d[1] != 3)
__builtin_abort();
  return 0;
}

[Bug c++/103871] [11/12 Regression] co_await causes build error

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|--- |11.3
   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
 CC||iains at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2021-12-31

--- Comment #3 from Jakub Jelinek  ---
On the trunk started with r12-618-g14ed21f8749ae359690d9c4a69ca38cc45d0d1b0
which has been backported in r11-9055-gb874ece3ff95d3afa575d40b6e14e95cae8baf87

[Bug target/85927] ud2 instruction generated starting with gcc 8

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #6 from Jakub Jelinek  ---
The ud2 is there since naked has been implemented for x86 in PR25967.
It is true it is a kind of debugging aid, so perhaps more suitable for
sanitization or if we add some option to decide preferred behavior on e.g.
__builtin_unreachable or for detected UB in the code (whether to use
__builtin_unreachable with its current behavior, just assume it doesn't happen
and don't emit anything in there, or whether to act as __builtin_trap etc.).
But without it e.g. the reporter wouldn't know so easily the function is
invalid and won't work correctly.

[Bug target/85927] ud2 instruction generated starting with gcc 8

[pskocik at gmail dot com via Gcc-bugs]

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

Petr Skocik  changed:

   What|Removed |Added

 CC||pskocik at gmail dot com

--- Comment #5 from Petr Skocik  ---
I think it'd be more welcome if gcc just put nothing there like clang does.

[Bug c++/103871] [11/12 Regression] co_await causes build error

[egor.pugin at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Egor Pugin  ---
Repro

#include 
#include 
#include 

struct s {
s(std::vector &&);
};
struct async_task {
struct promise_type {
auto initial_suspend() const { return std::suspend_never{}; }
auto final_suspend() noexcept { return std::suspend_never{}; }
auto get_return_object() { return async_task{}; }
void return_void() {}
void unhandled_exception() {}
};
bool await_ready() const { return false; }
void await_suspend(std::coroutine_handle<> h) {}
auto await_resume() {}
};
auto g(auto f) {
return async_task{};
}
async_task f() {
// comment out co_await to make error disappear
co_await g(std::make_unique(std::vector{0L})); // error
//g(std::make_unique(std::vector{0L})); // ok
co_return;
}
int main() {
f();
}