[Bug target/99530] [i386] 'P' inline assembly operand modifier should obey -fno-plt

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

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-03-11
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |hjl.tools at gmail dot 
com
 CC||hjl.tools at gmail dot com

--- Comment #2 from H.J. Lu  ---
It is OK to use indirect branch via GOT in 64-bit. But it isn't OK for 32-bit
since PIC register may not be available at call site.

[Bug target/99530] [i386] 'P' inline assembly operand modifier should obey -fno-plt

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

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

--- Comment #3 from H.J. Lu  ---
Created attachment 50366
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50366&action=edit
A patch

I am testing this.

[Bug target/99530] [i386] 'P' inline assembly operand modifier should obey -fno-plt

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

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

H.J. Lu  changed:

   What|Removed |Added

  Attachment #50366|0   |1
is obsolete||

--- Comment #7 from H.J. Lu  ---
Created attachment 50369
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50369&action=edit
The v2 patch

[Bug target/99530] [i386] 'P' inline assembly operand modifier should obey -fno-plt

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

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

--- Comment #9 from H.J. Lu  ---
(In reply to Thiago Macieira from comment #8)
> (In reply to H.J. Lu from comment #7)
> > Created attachment 50369 [details]
> > The v2 patch
> 
> Code generation with "call %P0" is now identical to what GCC generates on
> its own.
> 
> Even the alignment is now right, somehow, though it also added a newline?
> 
> $ ~/dev/gcc/bin/gcc -fPIC -fno-plt -S -o - -O2 -xc - <<<'extern void
> f(void); void g() { asm("cmp %P0,$0" : : "X" (f)); }' | grep -A1 GOTPC  
> 
> cmp *f@GOTPCREL(%rip)
> ,$0
> 
> That's probably not right.

Don't use %P with cmp.

[Bug target/99530] [i386] 'P' inline assembly operand modifier should obey -fno-plt

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

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

H.J. Lu  changed:

   What|Removed |Added

URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2021-March/5
   ||66651.html

--- Comment #11 from H.J. Lu  ---
A patch is posted at

https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566651.html

[Bug target/99530] [i386] 'P' inline assembly operand modifier should obey -fno-plt

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

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

--- Comment #12 from H.J. Lu  ---
(In reply to Thiago Macieira from comment #10)
> (In reply to H.J. Lu from comment #9)
> > Don't use %P with cmp.
> 
> I know, but that's besides the point. I was merely trying to find something
> that would have a reason to type more after the %P and show that a newline
> could be wrong.

Since my patch uses output_asm_insn to finish the instruction, %P must be
the last operand.

[Bug target/99530] [i386] 'P' inline assembly operand modifier should obey -fno-plt

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

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

H.J. Lu  changed:

   What|Removed |Added

  Attachment #50369|0   |1
is obsolete||

--- Comment #14 from H.J. Lu  ---
Created attachment 50381
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50381&action=edit
The v3 patch

[Bug lto/99618] `.gnu.debuglto_.debug_macro' referenced in section `.gnu.debuglto_.debug_macro' of X defined in discarded section

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

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

H.J. Lu  changed:

   What|Removed |Added

 Resolution|MOVED   |---
   Last reconfirmed||2021-03-17
 Status|RESOLVED|REOPENED
 Ever confirmed|0   |1

--- Comment #3 from H.J. Lu  ---
This is what GCC generates:

hjl@gnu-cfl-2 pr27590]$ cat bad.s
.section.gnu.debuglto_.debug_macro,"e",@progbits
.Ldebug_macro0:
.long   .Ldebug_macro2
.section.gnu.debuglto_.debug_macro,"eG",@progbits,wm4,comdat
.Ldebug_macro2:
.value  0x4
[hjl@gnu-cfl-2 pr27590]$ gcc -c bad.s
[hjl@gnu-cfl-2 pr27590]$ ld -r bad.o bad.o
`.gnu.debuglto_.debug_macro' referenced in section `.gnu.debuglto_.debug_macro'
of bad.o: defined in discarded section `.gnu.debuglto_.debug_macro[wm4]' of
bad.o
[hjl@gnu-cfl-2 pr27590]$

[Bug lto/99618] `.gnu.debuglto_.debug_macro' referenced in section `.gnu.debuglto_.debug_macro' of X defined in discarded section

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

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

--- Comment #7 from H.J. Lu  ---
(In reply to Jakub Jelinek from comment #6)
> For normal non-LTO debug macro we emit:
> .section.debug_macro,"",@progbits
> .Ldebug_macro0:
> .value  0x5 # DWARF macro version number
> .byte   0x2 # Flags: 32-bit, lineptr present
> .long   .Ldebug_line0
> .byte   0x7 # Import
> .long   .Ldebug_macro2
> ...
> .section   
> .debug_macro,"G",@progbits,wm4.0.d634b2ca9ddb72f687ab125549c033d0,comdat
> .Ldebug_macro2:
> .value  0x5 # DWARF macro version number
> .byte   0   # Flags: 32-bit
> .byte   0x5 # Define macro strp
> .uleb128 0  # At line number 0
> ...
> I don't see how that is any different from the above.  The intent is (and it
> has been working fine for years) that linker merges the comdat sections with
> the same hash into one, and the import relocations resolve to the start of
> that section.

Same result:

[hjl@gnu-cfl-2 pr27590]$ cat bad2.s 
.section.gnu.debuglto_.debug_macro,"",@progbits
.Ldebug_macro0:
.long   .Ldebug_macro2
.section.gnu.debuglto_.debug_macro,"G",@progbits,wm4,comdat
.Ldebug_macro2:
.value  0x4
[hjl@gnu-cfl-2 pr27590]$ gcc -c bad2.s
[hjl@gnu-cfl-2 pr27590]$ ld -r bad2.o bad2.o
`.gnu.debuglto_.debug_macro' referenced in section `.gnu.debuglto_.debug_macro'
of bad2.o: defined in discarded section `.gnu.debuglto_.debug_macro[wm4]' of
bad2.o
[hjl@gnu-cfl-2 pr27590]$

[Bug debug/99618] `.gnu.debuglto_.debug_macro' referenced in section `.gnu.debuglto_.debug_macro' of X defined in discarded section

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

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

--- Comment #8 from H.J. Lu  ---
(In reply to Richard Biener from comment #5)
> Maybe it's an assembler bug that it fails to set 'E' on the GROUP section?
> 

SHF_EXLCUDE doesn't apply to "ld -r".

[Bug debug/99618] `.gnu.debuglto_.debug_macro' referenced in section `.gnu.debuglto_.debug_macro' of X defined in discarded section

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

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

H.J. Lu  changed:

   What|Removed |Added

 Status|REOPENED|NEW

--- Comment #9 from H.J. Lu  ---
(In reply to Jakub Jelinek from comment #6)
> I don't see how that is any different from the above.  The intent is (and it
> has been working fine for years) that linker merges the comdat sections with
> the same hash into one, and the import relocations resolve to the start of
> that section.

This works if the symbol reference to the comdat section is global.

[Bug debug/99618] `.gnu.debuglto_.debug_macro' referenced in section `.gnu.debuglto_.debug_macro' of X defined in discarded section

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

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

--- Comment #16 from H.J. Lu  ---
(In reply to Richard Biener from comment #15)
> So as expected all of the linkers are happy with
> 
> .section.gnu.debuglto_.debug_macro,"e",@progbits
> .Ldebug_macro0:
> .long   debug_macro2
> .section.gnu.debuglto_.debug_macro,"eG",@progbits,wm4,comdat
> .globl debug_macro2
> debug_macro2:
> .value  0x4

You can put the first .gnu.debuglto_.debug_macro in a comdat group section.

[Bug tree-optimization/99504] Missing memmove detection

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

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

--- Comment #3 from H.J. Lu  ---
(In reply to CVS Commits from comment #2)
> The master branch has been updated by H.J. Lu :
> 
> https://gcc.gnu.org/g:adf14bdbc10d4114865a08cf20020a2616039057
> 
> commit r11-7701-gadf14bdbc10d4114865a08cf20020a2616039057
> Author: H.J. Lu 
> Date:   Thu Mar 11 06:48:24 2021 -0800
> 
> x86: Update 'P' operand modifier for -fno-plt
> 
> Update 'P' operand modifier for -fno-plt to support inline assembly
> statements.  In 64-bit, we can always load function address with
> @GOTPCREL.  In 32-bit, we load function address with @GOT only for
> non-PIC since PIC register may not be available at call site.
> 
> gcc/
> 
> PR target/99504
> * config/i386/i386.c (ix86_force_load_from_GOT_p): Support
> inline assembly statements.
> (ix86_print_operand): Update 'P' handling for -fno-plt.
> 
> gcc/testsuite/
> 
> PR target/99504
> * gcc.target/i386/pr99530-1.c: New test.
> * gcc.target/i386/pr99530-2.c: Likewise.
> * gcc.target/i386/pr99530-3.c: Likewise.
> * gcc.target/i386/pr99530-4.c: Likewise.
> * gcc.target/i386/pr99530-5.c: Likewise.
> * gcc.target/i386/pr99530-6.c: Likewise.

Wrong PR number in commit log.

[Bug target/99530] [i386] 'P' inline assembly operand modifier should obey -fno-plt

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

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

H.J. Lu  changed:

   What|Removed |Added

 Resolution|--- |FIXED
   Target Milestone|--- |11.0
 Status|NEW |RESOLVED

--- Comment #15 from H.J. Lu  ---
It is fixed by

The master branch has been updated by H.J. Lu :

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

commit r11-7701-gadf14bdbc10d4114865a08cf20020a2616039057
Author: H.J. Lu 
Date:   Thu Mar 11 06:48:24 2021 -0800

x86: Update 'P' operand modifier for -fno-plt

Update 'P' operand modifier for -fno-plt to support inline assembly
statements.  In 64-bit, we can always load function address with
@GOTPCREL.  In 32-bit, we load function address with @GOT only for
non-PIC since PIC register may not be available at call site.

gcc/

PR target/99504
* config/i386/i386.c (ix86_force_load_from_GOT_p): Support
inline assembly statements.
(ix86_print_operand): Update 'P' handling for -fno-plt.

gcc/testsuite/

PR target/99504
* gcc.target/i386/pr99530-1.c: New test.
* gcc.target/i386/pr99530-2.c: Likewise.
* gcc.target/i386/pr99530-3.c: Likewise.
* gcc.target/i386/pr99530-4.c: Likewise.
* gcc.target/i386/pr99530-5.c: Likewise.
* gcc.target/i386/pr99530-6.c: Likewise.

[Bug debug/99618] `.gnu.debuglto_.debug_macro' referenced in section `.gnu.debuglto_.debug_macro' of X defined in discarded section

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

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

H.J. Lu  changed:

   What|Removed |Added

   See Also||https://sourceware.org/bugz
   ||illa/show_bug.cgi?id=27590
 Resolution|--- |MOVED
 Status|NEW |RESOLVED

--- Comment #20 from H.J. Lu  ---
Moved to

https://sourceware.org/bugzilla/show_bug.cgi?id=27590

[Bug debug/99606] [10/11 Regression] ld.bfd: DWARF error: could not find abbrev number 64 since r10-7521-g54af95767e887d63

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

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

H.J. Lu  changed:

   What|Removed |Added

 Resolution|--- |MOVED
 Status|NEW |RESOLVED

--- Comment #3 from H.J. Lu  ---
Linker bug.

[Bug target/99652] New: inline doesn't with -mno-sse

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

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

Bug ID: 99652
   Summary: inline doesn't with -mno-sse
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: ubizjak at gmail dot com
  Target Milestone: ---

[hjl@gnu-cfl-2 tmp]$ cat x.c
inline double
foo (void)
{
  return 1.0;
}
[hjl@gnu-cfl-2 tmp]$ gcc -S x.c
[hjl@gnu-cfl-2 tmp]$ cat x.s
.file   "x.c"
.text
.ident  "GCC: (GNU) 10.2.1 20210130 (Red Hat 10.2.1-11)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-cfl-2 tmp]$ gcc -S x.c -mno-sse
x.c: In function ‘foo’:
x.c:3:1: error: SSE register return with SSE disabled
3 | {
  | ^
[hjl@gnu-cfl-2 tmp]$

[Bug target/99652] inline doesn't with -mno-sse

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

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

H.J. Lu  changed:

   What|Removed |Added

   Last reconfirmed||2021-03-18
 Status|RESOLVED|NEW
 Resolution|INVALID |---
 Ever confirmed|0   |1

--- Comment #2 from H.J. Lu  ---
(In reply to Andrew Pinski from comment #1)
> I don't see why this is a bug. GCC decides the return register early on and
> that is a good thing.

On arm64, I got

[hjl@gnu-cfl-2 gcc]$ cat /tmp/x.c
inline double
foo (void)
{
  return 1.0;
}
[hjl@gnu-cfl-2 gcc]$ ./xgcc -B./ -mgeneral-regs-only /tmp/x.c -S
[hjl@gnu-cfl-2 gcc]$

[Bug target/99652] inline doesn't with -mno-sse

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

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

H.J. Lu  changed:

   What|Removed |Added

   See Also||https://sourceware.org/bugz
   ||illa/show_bug.cgi?id=27600

--- Comment #4 from H.J. Lu  ---
We run into this with Intel UINTR on :

https://sourceware.org/bugzilla/show_bug.cgi?id=27600

We'd like to allow  with -mgeneral-regs-only.

[Bug target/99652] inline doesn't with -mno-sse

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

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

H.J. Lu  changed:

   What|Removed |Added

   Target Milestone|--- |11.0
 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from H.J. Lu  ---
Fixed for GCC 11.

[Bug target/99679] [11 Regression] ICE in construct_container at gcc/config/i386/i386.c:2571 since g:5e2eabe1eed1e53d39923517122d3c7de2013ad4

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

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #2 from H.J. Lu  ---
Fixed.

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

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

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

Bug ID: 99704
   Summary: volatile is needed on asm statements in 
   Product: gcc
   Version: 9.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: crazylht at gmail dot com, ubizjak at gmail dot com
  Target Milestone: ---
Target: i386,x86-64

Since CPUID instruction may return different values on hybrid core.
volatile is needed on asm statements in .

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

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

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

H.J. Lu  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |hjl.tools at gmail dot 
com
   Last reconfirmed||2021-03-22
 Status|UNCONFIRMED |NEW

--- Comment #1 from H.J. Lu  ---
Created attachment 50446
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50446&action=edit
A patch

[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

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

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

--- Comment #17 from H.J. Lu  ---
Created attachment 50451
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50451&action=edit
A patch

Try this.

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

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

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

H.J. Lu  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
   Target Milestone|--- |11.0
 Resolution|--- |FIXED

--- Comment #8 from H.J. Lu  ---
Fixed for GCC 11 and on GCC 8/9/10 branches.

[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 #20 from H.J. Lu  ---
(In reply to Worx from comment #19)
> It's seems that the patch fix the issue. 
> 
> Unfortunately, I have another error, but it's maybe i do not proper
> configure "-march=c3"
> 
> 
> 
> make[3]: Leaving directory '/opt/gcc/host-i686-pc-linux-gnu/libdecnumber'
> make[3]: Entering directory '/opt/gcc/host-i686-pc-linux-gnu/gcc'
> build/gengtype  \
> -S ../.././gcc -I gtyp-input.list -w tmp-gtype.state
> /bin/sh ../.././gcc/../move-if-change tmp-gtype.state gtype.state
> build/gengtype  \
> -r gtype.state
> make[3]: *** [Makefile:2786: s-gtype] Illegal instruction

Which instruction is Illegal instruction?

[Bug testsuite/99731] New: g++.dg/modules/alias-1_a.H: error: failed to read compiled module: No such file or directory

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

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

Bug ID: 99731
   Summary: g++.dg/modules/alias-1_a.H: error: failed to read
compiled module: No such file or directory
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: nathan at acm dot org
  Target Milestone: ---

On x86-64 machine with 112 processors,

$ make -j 56 check RUNTESTFLAGS="--target_board='unix{-m32,}'"

leads to

In module imported at
/export/gnu/import/git/gitlab/x86-gcc/gcc/testsuite/g++.dg/modules/alias-1_b.C:5:1:
/export/ssd/git/gitlab/x86-gcc/gcc/testsuite/g++.dg/modules/alias-1_a.H: error:
failed to read compiled module: No such file or directory
/export/ssd/git/gitlab/x86-gcc/gcc/testsuite/g++.dg/modules/alias-1_a.H: note:
compiled module file is
'gcm.cache/./export/ssd/git/gitlab/x86-gcc/gcc/testsuite/g++.dg/modules/alias-1_a.H.gcm'
/export/ssd/git/gitlab/x86-gcc/gcc/testsuite/g++.dg/modules/alias-1_a.H: note:
imports must be built before being imported
/export/ssd/git/gitlab/x86-gcc/gcc/testsuite/g++.dg/modules/alias-1_a.H: fatal
error: returning to the gate for a mechanical issue
compilation terminated.
compiler exited with status 1
FAIL: g++.dg/modules/alias-1_b.C -std=c++17 (test for excess errors)
Excess errors:
/export/ssd/git/gitlab/x86-gcc/gcc/testsuite/g++.dg/modules/alias-1_a.H: error:
failed to read compiled module: No such file or directory
/export/ssd/git/gitlab/x86-gcc/gcc/testsuite/g++.dg/modules/alias-1_a.H: fatal
error: returning to the gate for a mechanical issue
compilation terminated.

FAIL: g++.dg/modules/dir-only-2_b.C -std=c++17 (test for excess errors)
FAIL: g++.dg/modules/dir-only-2_b.C -std=c++2a (test for excess errors)
FAIL: g++.dg/modules/dir-only-2_b.C -std=c++2b (test for excess errors)
FAIL: g++.dg/modules/cpp-6_c.C -std=c++17 (test for excess errors)
FAIL: g++.dg/modules/cpp-6_c.C -std=c++2a (test for excess errors)
FAIL: g++.dg/modules/cpp-6_c.C -std=c++2b (test for excess errors)
FAIL: g++.dg/modules/alias-1_b.C -std=c++17 (test for excess errors)
FAIL: g++.dg/modules/alias-1_b.C -std=c++17  scan-lang-dump-times module "CMI
is " 1
FAIL: g++.dg/modules/alias-1_d.C -std=c++17 (test for excess errors)
FAIL: g++.dg/modules/alias-1_d.C module-cmi kevin (gcm.cache/kevin.gcm)
FAIL: g++.dg/modules/alias-1_e.C -std=c++17 (test for excess errors)
FAIL: g++.dg/modules/alias-1_f.C -std=c++17 (test for excess errors)
FAIL: g++.dg/modules/alias-1_b.C -std=c++2a (test for excess errors)
FAIL: g++.dg/modules/alias-1_b.C -std=c++2a  scan-lang-dump-times module "CMI
is " 1
FAIL: g++.dg/modules/alias-1_d.C -std=c++2a (test for excess errors)
FAIL: g++.dg/modules/alias-1_d.C module-cmi kevin (gcm.cache/kevin.gcm)
FAIL: g++.dg/modules/alias-1_e.C -std=c++2a (test for excess errors)
FAIL: g++.dg/modules/alias-1_f.C -std=c++2a (test for excess errors)
FAIL: g++.dg/modules/alias-1_b.C -std=c++2b (test for excess errors)
FAIL: g++.dg/modules/alias-1_b.C -std=c++2b  scan-lang-dump-times module "CMI
is " 1
FAIL: g++.dg/modules/alias-1_d.C -std=c++2b (test for excess errors)
FAIL: g++.dg/modules/alias-1_d.C module-cmi kevin (gcm.cache/kevin.gcm)
FAIL: g++.dg/modules/alias-1_e.C -std=c++2b (test for excess errors)
FAIL: g++.dg/modules/alias-1_f.C -std=c++2b (test for excess errors)

[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 #22 from H.J. Lu  ---
(In reply to Worx from comment #21)
> Sorry about the dumb question, but how to know ?

Run it under gdb and disassemble.  It should show which instruction caused
the problem.

[Bug testsuite/99731] g++.dg/modules/alias-1_a.H: error: failed to read compiled module: No such file or directory

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

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #2 from H.J. Lu  ---
(In reply to Nathan Sidwell from comment #1)
> How repeatable is this?

Close to 100%.

[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 #23 from H.J. Lu  ---
Created attachment 50464
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50464&action=edit
A program

Please run this and upload its output.  If it fails to run, please
show me the output of

$ grep "^flags" /proc/cpuinfo | head -1

[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 #25 from H.J. Lu  ---
(In reply to Worx from comment #24)
> worx@c3eden ~ $ gdb ./sample.bin
> GNU gdb (Gentoo 10.1 vanilla) 10.1
> Copyright (C) 2020 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later 
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
> Type "show copying" and "show warranty" for details.
> This GDB was configured as "i586-pc-linux-gnu".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> .
> Find the GDB manual and other documentation resources online at:
> .
> 
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from ./sample.bin...
> (No debugging symbols found in ./sample.bin)
> (gdb) run
> Starting program: /home/worx/sample.bin
> 
> Program received signal SIGILL, Illegal instruction.
> 0x0804f547 in ?? ()
> (gdb)

Please try different N (between 2 and 20) with "disass/r (0x0804f547 - N), +32"
under gdb until you can figure out what Illegal instruction is.

[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 #28 from H.J. Lu  ---
(In reply to Worx from comment #27)
> (gdb) disass/r (0x0804f547 - 2), +32
> Dump of assembler code from 0x804f545 to 0x804f565:
>0x0804f545:  00 00   add%al,(%eax)
> => 0x0804f547:  0f 44 44 24 14  cmove  0x14(%esp),%eax

This is CMOV which is in i686.  Please configure GCC with
i586-pc-linux-gnu, instead of i686-pc-linux-gnu.

[Bug target/99744] New: __attribute__ ((target("general-regs-only"))) doesn't work with GPR intrinsics

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

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

Bug ID: 99744
   Summary: __attribute__ ((target("general-regs-only"))) doesn't
work with GPR intrinsics
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: crazylht at gmail dot com, ubizjak at gmail dot com
  Target Milestone: ---
Target: x86-64,i386

[hjl@gnu-cfl-2 uintr-2]$ cat x.c
#include 

extern unsigned long long int curr_deadline;
extern void bar (void);

__attribute__ ((target("general-regs-only")))
void
foo (void)
{
  if (__rdtsc () < curr_deadline)
return; 
  bar ();
}
[hjl@gnu-cfl-2 uintr-2]$ /usr/gcc-11.0.0-x32/bin/gcc -S x.c
In file included from
/usr/gcc-11.0.0-x32/lib/gcc/x86_64-pc-linux-gnu/11.0.0/include/x86gprintrin.h:27,
 from
/usr/gcc-11.0.0-x32/lib/gcc/x86_64-pc-linux-gnu/11.0.0/include/x86intrin.h:27,
 from x.c:1:
x.c: In function ‘foo’:
/usr/gcc-11.0.0-x32/lib/gcc/x86_64-pc-linux-gnu/11.0.0/include/ia32intrin.h:112:1:
error: inlining failed in call to ‘always_inline’ ‘__rdtsc’: target specific
option mismatch
  112 | __rdtsc (void)
  | ^~~
x.c:10:7: note: called from here
   10 |   if (__rdtsc () < curr_deadline)
  |   ^~
[hjl@gnu-cfl-2 uintr-2]$ ls
foo.c  Makefile  x.c
[hjl@gnu-cfl-2 uintr-2]$ 

ix86_can_inline_p failed since caller disabled SSE and MMX, but __rdtsc had
SSE and MMX enanbled.  However GPR intrinsics don't need SSE nor MMX.

[Bug target/99744] __attribute__ ((target("general-regs-only"))) doesn't work with GPR intrinsics

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

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2021-03-24
   Keywords||patch
URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2021-March/5
   ||67255.html

--- Comment #4 from H.J. Lu  ---
A patch has been posted at

https://gcc.gnu.org/pipermail/gcc-patches/2021-March/567255.html

[Bug middle-end/98209] [8/9/10/11 Regression] printf failed with O1 or above

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

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

H.J. Lu  changed:

   What|Removed |Added

   Target Milestone|8.5 |11.0

--- Comment #13 from H.J. Lu  ---
Fixed for GCC 11 so far.

[Bug target/99744] __attribute__ ((target("general-regs-only"))) doesn't work with GPR intrinsics

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

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

H.J. Lu  changed:

   What|Removed |Added

 Resolution|--- |FIXED
   Target Milestone|--- |11.0
 Status|NEW |RESOLVED

--- Comment #6 from H.J. Lu  ---
Fixed for GCC 11.

[Bug middle-end/98209] [8/9/10 Regression] printf failed with O1 or above

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

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

--- Comment #14 from H.J. Lu  ---
The fix was reverted by

commit de00a7bda94910835012bc7150be53b460a5c8b6
Author: H.J. Lu 
Date:   Thu Mar 25 06:57:37 2021 -0700

Revert "x86: Skip ISA check for always_inline in system headers"

This reverts commit 72982851d70dfbc547d83ed2bb45356b9ebe3ff0.

[Bug target/99744] __attribute__ ((target("general-regs-only"))) doesn't work with GPR intrinsics

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

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

H.J. Lu  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #7 from H.J. Lu  ---
The fix was reverted by

commit de00a7bda94910835012bc7150be53b460a5c8b6
Author: H.J. Lu 
Date:   Thu Mar 25 06:57:37 2021 -0700

Revert "x86: Skip ISA check for always_inline in system headers"

This reverts commit 72982851d70dfbc547d83ed2bb45356b9ebe3ff0.

[Bug middle-end/99857] New: [11 Regression] FAIL: libgomp.c/declare-variant-1.c (test for excess errors) by r11-7926

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

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

Bug ID: 99857
   Summary: [11 Regression] FAIL: libgomp.c/declare-variant-1.c
(test for excess errors) by r11-7926
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: jh at suse dot cz
  Target Milestone: ---

r11-7926 caused:

lto1: fatal error: bytecode stream: trying to read 0 bytes after the end of the
input buffer^M
compilation terminated.^M
lto-wrapper: fatal error:
/export/users/hjl/build/gnu/tools-build/gcc-32bit-gitlab-native/build-i686-linux/./gcc/xgcc
returned 1 exit status^M
compilation terminated.^M
/usr/local32/bin/ld: error: lto-wrapper failed^M
collect2: error: ld returned 1 exit status^M
See ":er exited with status 1.
FAIL: libgomp.c/declare-variant-1.c (test for excess errors)fter the end of the
Excess errors:

[Bug middle-end/99857] [11 Regression] FAIL: libgomp.c/declare-variant-1.c (test for excess errors) by r11-7926

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

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

H.J. Lu  changed:

   What|Removed |Added

 Status|RESOLVED|NEW
 Ever confirmed|0   |1
   Last reconfirmed||2021-04-01
 Resolution|FIXED   |---

--- Comment #2 from H.J. Lu  ---
> Fixed with g:23ce9945d5efa77c96161443f68e03664705ada3.

No, it doesn't fix this regression.

[Bug target/99870] New: uiret generated for -mcmodel=kernel

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

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

Bug ID: 99870
   Summary: uiret generated for -mcmodel=kernel
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---
Target: x86-64

[hjl@gnu-cfl-2 tmp]$ /usr/gcc-11.0.1-x32/bin/gcc -march=sapphirerapids
-mcmodel=kernel -mno-sse -mno-mmx  -O2 -S -mno-80387 x.c 
[hjl@gnu-cfl-2 tmp]$ cat x.s
.file   "x.c"
.text
.p2align 4
.globl  foo
.type   foo, @function
foo:
.LFB0:
.cfi_startproc
uiret
.cfi_endproc
.LFE0:
.size   foo, .-foo
.ident  "GCC: (GNU) 11.0.1 20210330 (experimental)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-cfl-2 tmp]$ cat x.c
__attribute__((interrupt))
void
foo (void *frame)
{
}
[hjl@gnu-cfl-2 tmp]$ /usr/gcc-11.0.1-x32/bin/gcc -march=sapphirerapids
-mcmodel=kernel -mno-sse -mno-mmx  -O2 -S -mno-80387 x.c 
[hjl@gnu-cfl-2 tmp]$ cat x.s
.file   "x.c"
.text
.p2align 4
.globl  foo
.type   foo, @function
foo:
.LFB0:
.cfi_startproc
uiret  <<  This should be iret.
.cfi_endproc
.LFE0:
.size   foo, .-foo
.ident  "GCC: (GNU) 11.0.1 20210330 (experimental)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-cfl-2 tmp]$

[Bug target/99881] Regression compare -O2 -ftree-vectorize with -O2 on SKX/CLX

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

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

H.J. Lu  changed:

   What|Removed |Added

   Last reconfirmed||2021-04-02
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from H.J. Lu  ---
(In reply to Hongtao.liu from comment #0)
> testcase is extracted from 557.xz_r
> 
> void
> foo (int* __restrict a, int n, int c)
> {
> a[0] = n;
> a[1] = c;
> }
> 
> gcc -O2 -ftree-vectorize -fvect-cost-model=very-cheap
> 
> foo(int*, int, int):
> movdxmm0, esi
> movdxmm1, edx
> punpckldq   xmm0, xmm1
> movqQWORD PTR [rdi], xmm0
> ret
> 
> without vectorization
> 
> foo(int*, int, int):
> mov DWORD PTR [rdi], esi
> mov DWORD PTR [rdi+4], edx
> ret
> 
> cost model:
> scalar: 2 times scalar_store costs 24,
> vector: 1 times unaligned_store costs 12, vec_contruct 8

How is vec_contruct cost computed today?

[Bug target/99881] Regression compare -O2 -ftree-vectorize with -O2 on SKX/CLX

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

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

--- Comment #2 from H.J. Lu  ---
Created attachment 50501
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50501&action=edit
A patch to add vec_contruct cost

ix86_builtin_vectorization_cost has

  case vec_construct:
{
  /* N element inserts into SSE vectors.  */
  int cost = TYPE_VECTOR_SUBPARTS (vectype) * ix86_cost->sse_op;
  /* One vinserti128 for combining two SSE vectors for AVX256.  */
  if (GET_MODE_BITSIZE (mode) == 256)
cost += ix86_vec_cost (mode, ix86_cost->addss);
  /* One vinserti64x4 and two vinserti128 for combining SSE
 and AVX256 vectors to AVX512.  */
  else if (GET_MODE_BITSIZE (mode) == 512)
cost += 3 * ix86_vec_cost (mode, ix86_cost->addss);
  return cost; 
}

Add vec_contruct cost for vec_construct operation.

[Bug target/99941] New: m_ALDERLAKE is missing from m_CORE_AVX2

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

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

Bug ID: 99941
   Summary: m_ALDERLAKE is missing from m_CORE_AVX2
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: crazylht at gmail dot com, lili.cui at intel dot com
  Target Milestone: ---
Target: x86-64

i386-options.c has

#define m_ALDERLAKE (HOST_WIDE_INT_1U<

[Bug bootstrap/99996] New: [10 Regression] r10-9673 failed to build

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

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

Bug ID: 6
   Summary: [10 Regression] r10-9673 failed to build
   Product: gcc
   Version: 10.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: fdumont at gcc dot gnu.org
  Target Milestone: ---

On Linux/x86-64, r10-9673 failed to build:

https://gcc.gnu.org/pipermail/gcc-regression/2021-April/074554.html

/export/project/git/gcc-bisect-bootstrap/releases/gcc-10/r10-9675/bld/./gcc/xgcc
-shared-libgcc
-B/export/project/git/gcc-bisect-bootstrap/releases/gcc-10/r10-9675/bld/./gcc
-nostdinc++
-L/export/project/git/gcc-bisect-bootstrap/releases/gcc-10/r10-9675/bld/x86_64-pc-linux-gnu/libstdc++-v3/src
-L/export/project/git/gcc-bisect-bootstrap/releases/gcc-10/r10-9675/bld/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-L/export/project/git/gcc-bisect-bootstrap/releases/gcc-10/r10-9675/bld/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/export/project/git/gcc-bisect-bootstrap/releases/gcc-10/r10-9675/usr/x86_64-pc-linux-gnu/bin/
-B/export/project/git/gcc-bisect-bootstrap/releases/gcc-10/r10-9675/usr/x86_64-pc-linux-gnu/lib/
-isystem
/export/project/git/gcc-bisect-bootstrap/releases/gcc-10/r10-9675/usr/x86_64-pc-linux-gnu/include
-isystem
/export/project/git/gcc-bisect-bootstrap/releases/gcc-10/r10-9675/usr/x86_64-pc-linux-gnu/sys-include
  -fno-checking -x c++-header -nostdinc++ -g -O2 -D_GNU_SOURCE 
-I/export/project/git/gcc-bisect-bootstrap/releases/gcc-10/r10-9675/bld/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu
-I/export/project/git/gcc-bisect-bootstrap/releases/gcc-10/r10-9675/bld/x86_64-pc-linux-gnu/libstdc++-v3/include
-I/export/project/git/gcc-bisect-bootstrap/releases/gcc-10/gcc/libstdc++-v3/libsupc++
 -O2 -g
/export/project/git/gcc-bisect-bootstrap/releases/gcc-10/gcc/libstdc++-v3/include/precompiled/stdc++.h
-o x86_64-pc-linux-gnu/bits/stdc++.h.gch/O2g.gch
In file included from
/export/project/git/gcc-bisect-bootstrap/releases/gcc-10/r10-9675/bld/x86_64-pc-linux-gnu/libstdc++-v3/include/unordered_map:46,
 from
/export/project/git/gcc-bisect-bootstrap/releases/gcc-10/gcc/libstdc++-v3/include/precompiled/stdc++.h:117:
/export/project/git/gcc-bisect-bootstrap/releases/gcc-10/r10-9675/bld/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/hashtable.h:1317:56:
internal compiler error: in merge_exception_specifiers, at cp/typeck2.c:2564
 1317 |   std::is_nothrow_copy_constructible<_Equal>::value)
  |^
In file included from
/export/project/git/gcc-bisect-bootstrap/releases/gcc-10/r10-9675/bld/x86_64-pc-linux-gnu/libstdc++-v3/include/unordered_map:46,
 from
/export/project/git/gcc-bisect-bootstrap/releases/gcc-10/gcc/libstdc++-v3/include/precompiled/stdc++.h:117:
/export/project/git/gcc-bisect-bootstrap/releases/gcc-10/r10-9675/bld/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/hashtable.h:1317:56:
internal compiler error: in merge_exception_specifiers, at cp/typeck2.c:2564
 1317 |   std::is_nothrow_copy_constructible<_Equal>::value)
  |^
0xcf184b merge_exception_specifiers(tree_node*, tree_node*)
../../../gcc/gcc/cp/typeck2.c:2564
0xcc15d5 merge_types(tree_node*, tree_node*)
../../../gcc/gcc/cp/typeck.c:873
0xa33be2 duplicate_decls(tree_node*, tree_node*, bool)
../../../gcc/gcc/cp/decl.c:2259
0xa5772b grokfndecl
../../../gcc/gcc/cp/decl.c:9893
0xa63acf grokdeclarator(cp_declarator const*, cp_decl_specifier_seq*,
decl_context, int, tree_node**)
../../../gcc/gcc/cp/decl.c:13622
0xa71a5e start_function(cp_decl_specifier_seq*, cp_declarator const*,
tree_node*)
../../../gcc/gcc/cp/decl.c:16541
0xb80df2 cp_parser_function_definition_from_specifiers_and_declarator
../../../gcc/gcc/cp/parser.c:28909
0xb70523 cp_parser_init_declarator
../../../gcc/gcc/cp/parser.c:20694
0xb82675 cp_parser_single_declaration
../../../gcc/gcc/cp/parser.c:29528
0xb812fa cp_parser_template_declaration_after_parameters
../../../gcc/gcc/cp/parser.c:29100
0xb8226e cp_parser_explicit_template_declaration
../../../gcc/gcc/cp/parser.c:29366
0xb822c8 cp_parser_template_declaration_after_export
../../../gcc/gcc/cp/parser.c:29385
0xb67265 cp_parser_template_declaration
../../../gcc/gcc/cp/parser.c:15877
0xb62d67 cp_parser_declaration
../../../gcc/gcc/cp/parser.c:13398
0xb6305c cp_parser_toplevel_declaration
../../../gcc/gcc/cp/parser.c:13477
0xb62ae8 cp_parser_declaration_seq_opt
../../../gcc/gcc/cp/parser.c:13325
0xb6e5c4 cp_parser_namespace_body
../../../gcc/gcc/cp/parser.c:19740
0xb6e56d cp_parser_namespace_definition
../../../gcc/gcc/cp/parser.c:19718
0xb62e7b cp_pa

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

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

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

Bug ID: 12
   Summary: internal compiler error: in hashtab_chk_error, at
hash-table.c:137
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: nathan at acm dot org
  Target Milestone: ---

On Linux/x86-64, r11-8071 gave:

[hjl@gnu-clx-1 g++]$ cat /tmp/doit0
/export/build/gnu/tools-build/gcc/build-x86_64-linux/gcc/testsuite/g++/../../xg++
-B/export/build/gnu/tools-build/gcc/build-x86_64-linux/gcc/testsuite/g++/../../
/export/gnu/import/git/gitlab/x86-gcc/gcc/testsuite/g++.dg/modules/xtreme-tr1_a.H
-m32 -fdiagnostics-plain-output -nostdinc++
-I/export/build/gnu/tools-build/gcc/build-x86_64-linux/x86_64-pc-linux-gnu/32/libstdc++-v3/include/x86_64-pc-linux-gnu
-I/export/build/gnu/tools-build/gcc/build-x86_64-linux/x86_64-pc-linux-gnu/32/libstdc++-v3/include
-I/export/gnu/import/git/gitlab/x86-gcc/libstdc++-v3/libsupc++
-I/export/gnu/import/git/gitlab/x86-gcc/libstdc++-v3/include/backward
-I/export/gnu/import/git/gitlab/x86-gcc/libstdc++-v3/testsuite/util
-fmessage-length=0 -std=c++17 -pedantic-errors -Wno-long-long -fmodule-header
-S -o xtreme-tr1_a.s
[hjl@gnu-clx-1 g++]$ sh /tmp/doit0
[hjl@gnu-clx-1 g++]$ cat /tmp/doit
/export/build/gnu/tools-build/gcc/build-x86_64-linux/gcc/testsuite/g++/../../xg++
-B/export/build/gnu/tools-build/gcc/build-x86_64-linux/gcc/testsuite/g++/../../
/export/gnu/import/git/gitlab/x86-gcc/gcc/testsuite/g++.dg/modules/xtreme-tr1_b.C
-m32 -fdiagnostics-plain-output -nostdinc++
-I/export/build/gnu/tools-build/gcc/build-x86_64-linux/x86_64-pc-linux-gnu/32/libstdc++-v3/include/x86_64-pc-linux-gnu
-I/export/build/gnu/tools-build/gcc/build-x86_64-linux/x86_64-pc-linux-gnu/32/libstdc++-v3/include
-I/export/gnu/import/git/gitlab/x86-gcc/libstdc++-v3/libsupc++
-I/export/gnu/import/git/gitlab/x86-gcc/libstdc++-v3/include/backward
-I/export/gnu/import/git/gitlab/x86-gcc/libstdc++-v3/testsuite/util
-fmessage-length=0 -std=c++17 -pedantic-errors -Wno-long-long -fmodules-ts
-fno-module-lazy -S -o xtreme-tr1_b.s -march=skylake-avx512 -mrtm
[hjl@gnu-clx-1 g++]$ sh /tmp/doit
hash table checking failed: equal operator returns true for a pair of values
with a different hash value
/export/gnu/import/git/gitlab/x86-gcc/gcc/testsuite/g++.dg/modules/xtreme-tr1_b.C:4:25:
internal compiler error: in hashtab_chk_error, at hash-table.c:137
0x8f2583 hashtab_chk_error()
/export/gnu/import/git/sources/gcc/gcc/hash-table.c:137
0xb01265 hash_table::verify(spec_entry*
const&, unsigned int)
/export/gnu/import/git/sources/gcc/gcc/hash-table.h:1033
0xb017ee hash_table::find_slot_with_hash(spec_entry* const&, unsigned int,
insert_option)
/export/gnu/import/git/sources/gcc/gcc/hash-table.h:968
0xabe57b match_mergeable_specialization(bool, spec_entry*)
/export/gnu/import/git/sources/gcc/gcc/cp/pt.c:29961
0xa37998 trees_in::key_mergeable(int, merge_kind, tree_node*, tree_node*,
tree_node*, tree_node*, bool)
/export/gnu/import/git/sources/gcc/gcc/cp/module.cc:10670
0xa3b594 trees_in::decl_value()
/export/gnu/import/git/sources/gcc/gcc/cp/module.cc:7903
0xa343f7 trees_in::tree_node(bool)
/export/gnu/import/git/sources/gcc/gcc/cp/module.cc:9153
0xa3aa1b module_state::read_cluster(unsigned int)
/export/gnu/import/git/sources/gcc/gcc/cp/module.cc:14811
0xa3af1d module_state::load_section(unsigned int, binding_slot*)
/export/gnu/import/git/sources/gcc/gcc/cp/module.cc:18082
0xa3d6b5 module_state::read_language(bool)
/export/gnu/import/git/sources/gcc/gcc/cp/module.cc:18011
0xa3d87e direct_import
/export/gnu/import/git/sources/gcc/gcc/cp/module.cc:18877
0xaa4f97 cp_parser_translation_unit
/export/gnu/import/git/sources/gcc/gcc/cp/parser.c:4907
0xaa4f97 c_parse_file()
/export/gnu/import/git/sources/gcc/gcc/cp/parser.c:45268
0xbc9a9d c_common_parse_file()
/export/gnu/import/git/sources/gcc/gcc/c-family/c-opts.c:1218
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
[hjl@gnu-clx-1 g++]$ 

Remove -mrtm makes ICE go away:

[hjl@gnu-clx-1 g++]$
/export/build/gnu/tools-build/gcc/build-x86_64-linux/gcc/testsuite/g++/../../xg++
-B/export/build/gnu/tools-build/gcc/build-x86_64-linux/gcc/testsuite/g++/../../
/export/gnu/import/git/gitlab/x86-gcc/gcc/testsuite/g++.dg/modules/xtreme-tr1_b.C
-m32 -fdiagnostics-plain-output -nostdinc++
-I/export/build/gnu/tools-build/gcc/build-x86_64-linux/x86_64-pc-linux-gnu/32/libstdc++-v3/include/x86_64-pc-linux-gnu
-I/export/build/gnu/tools-build/gcc/build-x86_64-linux/x86_64-pc-linux-gnu/32/libstdc++-v3/include
-I/export/gnu/import/git/gitlab/x86-gcc/libs

[Bug driver/47785] GCC with -flto does not pass -Wa/-Xassembler options to the assembler

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

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

--- Comment #19 from H.J. Lu  ---
I'd like to backport it to GCC 9.

[Bug c/100005] undefined reference to `_rdrand64_step'

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

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

--- Comment #9 from H.J. Lu  ---
I don't think we need to support taking address of intrinsic.
By definition, there is no intrinsic address to take.

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

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

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

--- Comment #1 from H.J. Lu  ---
This may be related to PR 12

[Bug tree-optimization/100076] eembc/automotive/basefp01 has 30.3% regression compare -O2 -ftree-vectorize with -O2 on CLX/Znver3

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

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

--- Comment #1 from H.J. Lu  ---
Is -O3 slower than -O3 -fno-tree-vectorize? If not, why?

[Bug target/100088] ymm store split into two xmm stores

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

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

H.J. Lu  changed:

   What|Removed |Added

   Target Milestone|--- |11.0
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from H.J. Lu  ---
Fixed in GCC 11 by

commit b80fefd626460fb8924248622ba59dd56246703e
Author: liuhongt 
Date:   Thu Jan 28 14:07:00 2021 +0800

Enable X86_TUNE_AVX256_UNALIGNED_{LOAD??STORE}_OPTIMAL in generic tune.

gcc/ChangeLog:

PR target/98172
* config/i386/x86-tune.def
(X86_TUNE_AVX256_UNALIGNED_LOAD_OPTIMAL):
Remove m_GENERIC from ~list.
(X86_TUNE_AVX256_UNALIGNED_STORE_OPTIMAL): Ditto.

[Bug sanitizer/100114] libasan built against latest glibc doesn't work

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

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

--- Comment #3 from H.J. Lu  ---
(In reply to Richard Biener from comment #2)
> Confirmed by code inspection, but it's for sure sth not new (but would be
> nice to fix before GCC 11.1).
> 
> I suggtest to simply move the initialization inside SetAlternateSignalStack.
> Sth like
> 
> diff --git a/libsanitizer/sanitizer_common/sanitizer_posix_libcdep.cpp
> b/libsanitizer/sanitizer_common/sanitizer_posix_libcdep.cpp
> index d29438cf9db..803712e268e 100644
> --- a/libsanitizer/sanitizer_common/sanitizer_posix_libcdep.cpp
> +++ b/libsanitizer/sanitizer_common/sanitizer_posix_libcdep.cpp
> @@ -165,7 +165,7 @@ bool SupportsColoredOutput(fd_t fd) {
>  
>  #if !SANITIZER_GO
>  // TODO(glider): different tools may require different altstack size.
> -static const uptr kAltStackSize = SIGSTKSZ * 4;  // SIGSTKSZ is not enough.
> +static const uptr kAltStackSize;
>  
>  void SetAlternateSignalStack() {
>stack_t altstack, oldstack;
> @@ -176,6 +176,7 @@ void SetAlternateSignalStack() {
>// TODO(glider): the mapped stack should have the MAP_STACK flag in the
>// future. It is not required by man 2 sigaltstack now (they're using
>// malloc()).
> +  kAltStackSize = SIGSTKSZ * 4;  // SIGSTKSZ is not enough.
>void* base = MmapOrDie(kAltStackSize, __func__);
>altstack.ss_sp = (char*) base;
>altstack.ss_flags = 0;

We can initialize it with a constructor or .init_array.

[Bug c++/100131] New: [meta-bug] internal compiler error: in hashtab_chk_error, at hash-table.c:137

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

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

Bug ID: 100131
   Summary: [meta-bug] internal compiler error: in
hashtab_chk_error, at hash-table.c:137
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
Blocks: 12, 91190, 93907, 97093, 99445
  Target Milestone: ---

hash table checking failed: equal operator returns true for a pair of values
with a different hash value
/export/gnu/import/git/gitlab/x86-gcc/gcc/testsuite/g++.dg/modules/xtreme-tr1_b.C:4:25:
internal compiler error: in hashtab_chk_error, at hash-table.c:137
0x8f2583 hashtab_chk_error()
/export/gnu/import/git/sources/gcc/gcc/hash-table.c:137
0xb01265 hash_table::verify(spec_entry*
const&, unsigned int)
/export/gnu/import/git/sources/gcc/gcc/hash-table.h:1033
0xb017ee hash_table::find_slot_with_hash(spec_entry* const&, unsigned int,
insert_option)
/export/gnu/import/git/sources/gcc/gcc/hash-table.h:968
0xabe57b match_mergeable_specialization(bool, spec_entry*)
/export/gnu/import/git/sources/gcc/gcc/cp/pt.c:29961
0xa37998 trees_in::key_mergeable(int, merge_kind, tree_node*, tree_node*,
tree_node*, tree_node*, bool)
/export/gnu/import/git/sources/gcc/gcc/cp/module.cc:10670
0xa3b594 trees_in::decl_value()
/export/gnu/import/git/sources/gcc/gcc/cp/module.cc:7903
0xa343f7 trees_in::tree_node(bool)
/export/gnu/import/git/sources/gcc/gcc/cp/module.cc:9153
0xa3aa1b module_state::read_cluster(unsigned int)
/export/gnu/import/git/sources/gcc/gcc/cp/module.cc:14811
0xa3af1d module_state::load_section(unsigned int, binding_slot*)
/export/gnu/import/git/sources/gcc/gcc/cp/module.cc:18082
0xa3d6b5 module_state::read_language(bool)
/export/gnu/import/git/sources/gcc/gcc/cp/module.cc:18011
0xa3d87e direct_import
/export/gnu/import/git/sources/gcc/gcc/cp/module.cc:18877
0xaa4f97 cp_parser_translation_unit
/export/gnu/import/git/sources/gcc/gcc/cp/parser.c:4907
0xaa4f97 c_parse_file()
/export/gnu/import/git/sources/gcc/gcc/cp/parser.c:45268
0xbc9a9d c_common_parse_file()
/export/gnu/import/git/sources/gcc/gcc/c-family/c-opts.c:1218
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91190
[Bug 91190] [10 Regression] ICE on valid code: in hashtab_chk_error, at
hash-table.c:137
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93907
[Bug 93907] [10 Regression] internal compiler error: in hashtab_chk_error, at
hash-table.c:137
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97093
[Bug 97093] ICE on C++20 code when chaining requirements (in hashtab_chk_error,
at hash-table.c:137)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99445
[Bug 99445] [11 Regression] ICE in hashtab_chk_error, at hash-table.c:137 since
r11-7011-g6e0a231a4aa2407b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12
[Bug 12] internal compiler error: in hashtab_chk_error, at hash-table.c:137

[Bug c++/98964] FAIL: g++.dg/cpp0x/constexpr-52830.C -std=c++14 (test for excess errors)

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

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

H.J. Lu  changed:

   What|Removed |Added

   Host|hppa-unknown-linux-gnu  |
  Component|testsuite   |c++
 Ever confirmed|0   |1
 Target|hppa-unknown-linux-gnu  |
  Build|hppa-unknown-linux-gnu  |
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-04-20

--- Comment #1 from H.J. Lu  ---
On Linux/x86-64, r11-8260 gave

./releases/gcc-11/r11-8260/bld/gcc/xgcc -B./releases/gcc-11/r11-8260/bld/gcc/
-S constexpr-52830.C 
constexpr-52830.C:27:1: error: no declaration matches ??void foo::func(T&&,
typename eif::value>::type*)??
   27 | foo::
  | ^~~
constexpr-52830.C:21:8: note: candidate is: ??template void
foo::func(T&&, typename eif::value>::type*)??
   21 |   void func(T && a,
  |^~~~
constexpr-52830.C:19:8: note: ??struct foo?? defined here
   19 | struct foo {
  |^~~
gnu-skx-1:pts/4[56]> ./releases/gcc-11/r11-8254/bld/gcc/xgcc
-B./releases/gcc-11/r11-8254/bld/gcc/ -S constexpr-52830.C
constexpr-52830.C:29:60: internal compiler error: canonical types differ for
identical types ??eif::value>?? and
??eif::value>??
   29 |  typename eif::value>::type * )
  |^
0xe0117d comptypes(tree_node*, tree_node*, int)
../../../gcc/gcc/cp/typeck.c:1558
0xe01353 same_type_ignoring_top_level_qualifiers_p(tree_node*, tree_node*)
../../../gcc/gcc/cp/typeck.c:1594
0xe005e0 structural_comptypes
../../../gcc/gcc/cp/typeck.c:1443
0xe010c4 comptypes(tree_node*, tree_node*, int)
../../../gcc/gcc/cp/typeck.c:1547
0xe0027e structural_comptypes
../../../gcc/gcc/cp/typeck.c:1401
0xe010c4 comptypes(tree_node*, tree_node*, int)
../../../gcc/gcc/cp/typeck.c:1547
0xe015d8 compparms(tree_node const*, tree_node const*)
../../../gcc/gcc/cp/typeck.c:1699
0xb72130 check_classfn(tree_node*, tree_node*, tree_node*)
../../../gcc/gcc/cp/decl2.c:686
0xb47ae5 grokfndecl
../../../gcc/gcc/cp/decl.c:10109
0xb5445c grokdeclarator(cp_declarator const*, cp_decl_specifier_seq*,
decl_context, int, tree_node**)
../../../gcc/gcc/cp/decl.c:13924
0xb6274b start_function(cp_decl_specifier_seq*, cp_declarator const*,
tree_node*)
../../../gcc/gcc/cp/decl.c:16859
0xcbe4d3 cp_parser_function_definition_from_specifiers_and_declarator
../../../gcc/gcc/cp/parser.c:29940
0xcad696 cp_parser_init_declarator
../../../gcc/gcc/cp/parser.c:21653
0xcbfdf6 cp_parser_single_declaration
../../../gcc/gcc/cp/parser.c:30564
0xcbea7b cp_parser_template_declaration_after_parameters
../../../gcc/gcc/cp/parser.c:30136
0xcbf9ef cp_parser_explicit_template_declaration
../../../gcc/gcc/cp/parser.c:30402
0xcbfa49 cp_parser_template_declaration_after_export
../../../gcc/gcc/cp/parser.c:30421
0xca3912 cp_parser_template_declaration
../../../gcc/gcc/cp/parser.c:16609
0xc9f1e0 cp_parser_declaration
../../../gcc/gcc/cp/parser.c:14085
0xc9f5f3 cp_parser_toplevel_declaration
../../../gcc/gcc/cp/parser.c:14183
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/97148] Add

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

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #3 from H.J. Lu  ---
Fixed by

commit 59a95143ddeb4939fe2336e8f86cbc908bfa8e1a
Author: H.J. Lu 
Date:   Mon Sep 21 12:17:01 2020 -0700

x86: Add 

[Bug target/97250] Implement -march=x86-64-v2, -march=x86-64-v3, -march=x86-64-v4 for x86-64

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

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

H.J. Lu  changed:

   What|Removed |Added

 Resolution|FIXED   |---
 Status|RESOLVED|REOPENED

--- Comment #4 from H.J. Lu  ---
x86-64-v2 includes CMPXCHG16B, aka CX16. But -mcx16 doesn't define __CX16__.

[Bug target/97250] Implement -march=x86-64-v2, -march=x86-64-v3, -march=x86-64-v4 for x86-64

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

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

--- Comment #6 from H.J. Lu  ---
(In reply to Florian Weimer from comment #5)
> (In reply to H.J. Lu from comment #4)
> > x86-64-v2 includes CMPXCHG16B, aka CX16. But -mcx16 doesn't define __CX16__.
> 
> It's called __GCC_HAVE_SYNC_COMPARE_AND_SWAP_16, I think. Is this good
> enough?

Yes. But a test is missing.

[Bug target/97250] Implement -march=x86-64-v2, -march=x86-64-v3, -march=x86-64-v4 for x86-64

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

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

--- Comment #8 from H.J. Lu  ---
(In reply to Florian Weimer from comment #7)
> (In reply to H.J. Lu from comment #6)
> > (In reply to Florian Weimer from comment #5)
> > > (In reply to H.J. Lu from comment #4)
> > > > x86-64-v2 includes CMPXCHG16B, aka CX16. But -mcx16 doesn't define 
> > > > __CX16__.
> > > 
> > > It's called __GCC_HAVE_SYNC_COMPARE_AND_SWAP_16, I think. Is this good
> > > enough?
> > 
> > Yes. But a test is missing.
> 
> Fair enough.  Are you going to send a patch?

Sure.

[Bug target/97250] Implement -march=x86-64-v2, -march=x86-64-v3, -march=x86-64-v4 for x86-64

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

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

H.J. Lu  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|REOPENED|RESOLVED

--- Comment #10 from H.J. Lu  ---
Fixed.

[Bug target/97140] [10/11 Regression] ICE in error: unable to generate reloads for since r10-400-gecfdb16c54ad06ac

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

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

--- Comment #3 from H.J. Lu  ---
The real updated patch:

https://gcc.gnu.org/pipermail/gcc-patches/2020-September/554385.html

[Bug target/95483] [i386] Missing SIMD functions

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

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

H.J. Lu  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |11.0

--- Comment #4 from H.J. Lu  ---
Fixed for GCC 11.

[Bug bootstrap/97451] New: [11 Regression] r11-3959 failed --with-build-config=bootstrap-cet

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

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

Bug ID: 97451
   Summary: [11 Regression] r11-3959 failed
--with-build-config=bootstrap-cet
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---

On Linux/x86-64 with binutils 20201014 master branch, r11-3959 failed to
bootstrap when configured with

--enable-cet --with-demangler-in-ld  --prefix=/usr/gcc-11.0.0-cet-x32
--with-local-prefix=/usr/local --enable-gnu-indirect-function
--enable-clocale=gnu --with-system-zlib --with-target-system-zlib
--with-fpmath=sse --with-multilib-list=m32,m64,mx32 --enable-linker-build-id
--enable-gnu-unique-object --with-build-config=bootstrap-cet
--with-multilib-list=m64,mx32,m32
--enable-languages=c,c++,fortran,lto,objc,obj-c++,go

Bootstrap comparison failure!
libiberty/lbasename.o differs
x86_64-pc-linux-gnu/32/libstdc++-v3/libsupc++/eh_globals.o differs
x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/eh_globals.o differs
x86_64-pc-linux-gnu/x32/libstdc++-v3/libsupc++/eh_globals.o differs
make[4]: *** [Makefile:23878: compare] Error 1

[hjl@gnu-skx-1 build-x86_64-linux]$ cmp --ignore-initial=16
stage2-libiberty/lbasename.o stage3-libiberty/lbasename.o
stage2-libiberty/lbasename.o stage3-libiberty/lbasename.o differ: byte 965,
line 2
[hjl@gnu-skx-1 build-x86_64-linux]$ readelf -w stage2-libiberty/lbasename.o
...
The Directory Table (offset 0x1c):
  1 /tmp
  2 /export/gnu/import/git/sources/gcc/libiberty
  3 /export/gnu/import/git/sources/gcc/libiberty/../include

 The File Name Table (offset 0x87):
  Entry Dir TimeSizeName
  1 2   0   0   lbasename.c
  2 3   0   0   safe-ctype.h
  3 1   0   0   cccS9GKD.s
This seems to come from assembly file.

[Bug bootstrap/97451] [11 Regression] r11-3959 failed --with-build-config=bootstrap-cet

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

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

--- Comment #1 from H.J. Lu  ---
The problem is triggered by missing config/bootstrap-debug.mk.  But
cccS9GKD.s is is odd.

[Bug bootstrap/97451] [11 Regression] r11-3959 failed --with-build-config=bootstrap-cet

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

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

H.J. Lu  changed:

   What|Removed |Added

   See Also||https://sourceware.org/bugz
   ||illa/show_bug.cgi?id=26740
 CC||jakub at redhat dot com

--- Comment #2 from H.J. Lu  ---
This is triggered by r11-3693:

commit 6923255e35a3d54f2083ad0f67edebb3f1b86506
Author: Jakub Jelinek 
Date:   Wed Oct 7 10:55:35 2020 +0200

debug: Pass --gdwarf-N to assembler if fixed gas is detected during
configure

[Bug bootstrap/97451] [11 Regression] r11-3959 failed --with-build-config=bootstrap-cet

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

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-10-16
   Assignee|unassigned at gcc dot gnu.org  |hjl.tools at gmail dot 
com
 Ever confirmed|0   |1

--- Comment #4 from H.J. Lu  ---
Created attachment 49389
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49389&action=edit
A patch

I am testing this patch.

[Bug bootstrap/97451] [11 Regression] r11-3959 failed --with-build-config=bootstrap-cet

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

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

H.J. Lu  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #5 from H.J. Lu  ---
(In reply to H.J. Lu from comment #4)
> Created attachment 49389 [details]
> A patch
> 
> I am testing this patch.

It works:

https://gcc.gnu.org/pipermail/gcc-patches/2020-October/556394.html

[Bug other/97473] Spilled function parameters not aligned properly on multiple non-x86 targets

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

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

--- Comment #1 from H.J. Lu  ---
(In reply to Nate Eldredge from comment #0)
>
> On x86_64-linux-gnu, gcc generates instructions to align the stack and place
> the spilled copy of x at an aligned address, and the testcase passes there. 
> (Perhaps this was implemented to support AVX?)  With -m32 it copies x from
> its original unaligned position on the stack into an aligned stack slot.
> 

When we enabled AVX in GCC, we updated middle-end to properly align
the shack with backend hooks.  A backend can properly align the stack
if it implements similar hooks for stack re-alignment.

[Bug rtl-optimization/97482] Optimized (-O3) XMM register load incorrectly uses movdqu

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

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
   Target Milestone|--- |10.3
 Resolution|--- |DUPLICATE

--- Comment #1 from H.J. Lu  ---
Dup.

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

[Bug target/96827] [10/11 Regression] __m128i from _mm_set_epi32 is backwards with -O3

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

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

H.J. Lu  changed:

   What|Removed |Added

 CC||vkkerrata at gmail dot com

--- Comment #16 from H.J. Lu  ---
*** Bug 97482 has been marked as a duplicate of this bug. ***

[Bug c/97480] ice in vect_get_and_check_slp_defs, at tree-vect-slp.c:538

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

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

--- Comment #1 from H.J. Lu  ---
It is caused by r11-3998:

commit 540d5f4f0215e1cdd2d4a2c89c65e46033298be0
Author: Richard Biener 
Date:   Wed Oct 14 15:37:51 2020 +0200

Refactor vect_get_and_check_slp_defs some more

This refactors vect_get_and_check_slp_defs so that the ops and def_stmts
arrays are filled for all stmts and operands even when we signal failure.
This allows later changes for BB vectorization SLP discovery heuristics.

2020-10-16  Richard Biener  

* tree-vect-slp.c (vect_get_and_check_slp_defs): First analyze
all operands and fill in the def_stmts and ops entries.
(vect_def_types_match): New helper.

[Bug lto/97508] New: lto1: internal compiler error: decompressed stream: Destination buffer is too small

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

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

Bug ID: 97508
   Summary: lto1: internal compiler error: decompressed stream:
Destination buffer is too small
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

[hjl@gnu-skx-1 tmp]$ cat pr15323a.c
int main (void)
{
  return 0;
}
[hjl@gnu-skx-1 tmp]$ cat doit
CFLAGS="-flto -fno-profile-use -O2"
cc $CFLAGS -c pr15323a.c -o pr15323a.o
cc $CFLAGS -r -nostdlib pr15323a.o -o pr15323a-r.o
cc $CFLAGS  -o pr15323a.exe pr15323a-r.o
[hjl@gnu-skx-1 tmp]$ sh doit
during IPA pass: cp
lto1: internal compiler error: decompressed stream: Destination buffer is too
small
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
lto-wrapper: fatal error: cc returned 1 exit status
compilation terminated.
/usr/local/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
[hjl@gnu-skx-1 tmp]$

[Bug ada/97541] New: Ada failed to bootstrap: Error: file table slot 1 is already occupied by a different file

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

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

Bug ID: 97541
   Summary: Ada failed to bootstrap: Error: file table slot 1 is
already occupied by a different file
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---
Target: i386,x86-64

With --gdwarf-4 assembler on Linux/x86-64, I got

$ /export/users/hjl/build/gnu/tools-build/gcc/build-x86_64-linux/./gcc/xgcc
-B/export/users/hjl/build/gnu/tools-build/gcc/build-x86_64-linux/./gcc/
-B/usr/gcc-11.0.0-x86-64/x86_64-pc-linux-gnu/bin/
-B/usr/gcc-11.0.0-x86-64/x86_64-pc-linux-gnu/lib/ -isystem
/usr/gcc-11.0.0-x86-64/x86_64-pc-linux-gnu/include -isystem
/usr/gcc-11.0.0-x86-64/x86_64-pc-linux-gnu/sys-include   -fchecking=1 -c -g -O2
-m32  -W -Wall -gnatpg -nostdinc -m32  a-stzunb.adb -c
/tmp/cc6QPugj.s: Assembler messages:
/tmp/cc6QPugj.s:42: Error: file table slot 1 is already occupied by a different
file (/tmp/cc6QPugj.s vs a-stzunb.adb)

Ada generates:

.file   "a-stzunb.adb"
.text
.Ltext0:
.align 2
.p2align 4
.globl  ada__strings__wide_wide_unbounded___size__2
.type   ada__strings__wide_wide_unbounded___size__2, @function
ada__strings__wide_wide_unbounded___size__2:
.LFB5:
.cfi_startproc
movl$64, %eax
xorl%edx, %edx
ret
.cfi_endproc
.LFE5:
.size   ada__strings__wide_wide_unbounded___size__2,
.-ada__strings__wid
e_wide_unbounded___size__2
.align 2
.p2align 4
.globl 
ada__strings__wide_wide_unbounded__unbounded_wide_wide_stringDA_
_2
.type  
ada__strings__wide_wide_unbounded__unbounded_wide_wide_stringDA_
_2, @function
ada__strings__wide_wide_unbounded__unbounded_wide_wide_stringDA__2:
.LFB12:
.cfi_startproc
movl4(%esp), %eax
movl4(%eax), %eax
#APP
# 82 "s-atocou.adb" 1   File 1
lock incl   4(%eax)
# 0 "" 2
#NO_APP
ret
.cfi_endproc
.LFE12:
.size  
ada__strings__wide_wide_unbounded__unbounded_wide_wide_stringDA_
_2, .-ada__strings__wide_wide_unbounded__unbounded_wide_wide_stringDA__2
.align 2
.p2align 4
.globl  ada__strings__wide_wide_unbounded__adjust__2
.type   ada__strings__wide_wide_unbounded__adjust__2, @function
ada__strings__wide_wide_unbounded__adjust__2:
.LVL0:
.LFB47:
.file 1 "a-stzunb.adb"  File 1 again
.loc 1 478 4 view -0
.cfi_startproc
.LBB706:
.LBB707:
.LBB708:
.file 2 "s-atocou.adb"

[Bug ada/97541] Ada failed to bootstrap: Error: file table slot 1 is already occupied by a different file

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

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

H.J. Lu  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2020-10-23
 Status|UNCONFIRMED |NEW
 CC||jakub at redhat dot com

--- Comment #1 from H.J. Lu  ---
This is triggered by r11-3693:

commit 6923255e35a3d54f2083ad0f67edebb3f1b86506
Author: Jakub Jelinek 
Date:   Wed Oct 7 10:55:35 2020 +0200

debug: Pass --gdwarf-N to assembler if fixed gas is detected during
configure

[Bug ada/97541] Ada failed to bootstrap: Error: file table slot 1 is already occupied by a different file

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

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

--- Comment #3 from H.J. Lu  ---
(In reply to Jakub Jelinek from comment #2)
> So isn't that yet another thing that needs to be changed/fixed in gas?
> Plus on the gcc side add a test for that once it is fixed in binutils?

I think this is a GCC bug.  We can't assign the same file number to different
files:

# 82 "s-atocou.adb" 1
...
.file 1 "a-stzunb.adb"

This seems to be Ada specific.  I can't find a testcase in C nor C++.

[Bug ada/97541] Ada failed to bootstrap: Error: file table slot 1 is already occupied by a different file

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

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

H.J. Lu  changed:

   What|Removed |Added

   Host||https://sourceware.org/bugz
   ||illa/show_bug.cgi?id=26778

--- Comment #7 from H.J. Lu  ---
I opened:

https://sourceware.org/bugzilla/show_bug.cgi?id=26778

[Bug bootstrap/97451] [11 Regression] r11-3959 failed --with-build-config=bootstrap-cet

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

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #7 from H.J. Lu  ---
Fixed.

[Bug target/95458] Inline strncmp is *much* slower than glibc

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

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #4 from H.J. Lu  ---
Fixed for GCC 11.

[Bug target/95151] [9/10/11 Regression] Add cmpmemM pattern for -minline-all-stringops

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

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #4 from H.J. Lu  ---
Fixed for GCC 11 by

commit 3edc21af5272194794fbf24b2c5f0981c632e866
Author: H.J. Lu 
Date:   Thu May 14 13:06:23 2020 -0700

x86: Add cmpmemsi for -minline-all-stringops

[Bug lto/97586] New: "make check" failures in binutils with -flto=jobserver

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

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

Bug ID: 97586
   Summary: "make check" failures in binutils with -flto=jobserver
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

On Linux/x86-64, with GCC 11

commit 4f8cfb42883cc247f11096a3703e379d1f24ab3f
Author: Jan Hubicka 
Date:   Mon Oct 26 20:19:33 2020 +0100

Extend builtin fnspecs

"make check" on binutils users/hjl/lto branch:

https://gitlab.com/x86-binutils/binutils-gdb/-/commits/users/hjl/lto

gave

FAIL: nm --line-numbers on DWARF-4 debug info (grep for externd global
file/line)
FAIL: build-id-debuglink (grepping for source file name in disassembly output)
FAIL: objdump -S
FAIL: objdump --source-comment
FAIL: DWARF2 debugging information 2
FAIL: DWARF2 debugging information 2 with SHF_COMPRESSED
FAIL: 64bit DWARF2 debugging information 2
FAIL: 64bit DWARF2 debugging information 2 with SHF_COMPRESSED
FAIL: DWARF parse during linker error
FAIL: Build warn libbar.so
FAIL: Dump pr21978.so
FAIL: Run warn with versioned libfoo.so
FAIL: undefined symbol with compressed debug sections
FAIL: PR ld/12760
FAIL: plugin claimfile lost symbol
FAIL: plugin claimfile replace symbol
FAIL: plugin claimfile resolve symbol
FAIL: plugin claimfile lost symbol with source
FAIL: plugin claimfile replace symbol with source
FAIL: plugin claimfile resolve symbol with source
FAIL: plugin 2 with source lib
FAIL: load plugin 2 with source
FAIL: plugin 3 with source lib
FAIL: load plugin 3 with source
FAIL: undefined line
FAIL: undefined line
FAIL: undefined symbol with compressed debug sections

when compiled with -O2 -g -flto=jobserver.

[Bug tree-optimization/97567] [11 Regression] wrong code at -Os and above on x86_64-pc-linux-gnu

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

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

--- Comment #4 from H.J. Lu  ---
(In reply to CVS Commits from comment #3)
> The master branch has been updated by Andrew Macleod :
> 
> https://gcc.gnu.org/g:48722d158cbf692c24025e345ec570f66aa5
> 
> commit r11-4393-g48722d158cbf692c24025e345ec570f66aa5
> Author: Andrew MacLeod 
> Date:   Mon Oct 26 14:55:00 2020 -0400
> 
> Combine logical OR ranges properly.
> 
> When combining logical OR operands with a FALSE result, union the false
> ranges for operand1 and operand2... not intersection.
> 
> gcc/
> PR tree-optimization/97567
> * gimple-range-gori.cc (gori_compute::logical_combine): Union the
> ranges of operand1 and operand2, not intersect.
> gcc/testsuite/
> * gcc.dg/pr97567.c: New.

This commit compiled gcc.dg/pr97567.c into an finite loop on Linux/x86.

[Bug ipa/97586] [11 Regression] "make check" failures in binutils with -flto since r11-3641-gc34db4b6f8a5d803

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

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #17 from H.J. Lu  ---
Fixed for GCC 11.

[Bug c++/95519] [coroutines] non-functions for promise_type::return_void not supported

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

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

H.J. Lu  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 CC||hjl.tools at gmail dot com,
   ||skpgkp2 at gmail dot com
 Resolution|FIXED   |---

--- Comment #9 from H.J. Lu  ---
On AVX or AVX512 machines, I got

FAIL: g++.dg/coroutines/torture/pr95519-05-gro.C   -O0  execution test
FAIL: g++.dg/coroutines/torture/pr95519-05-gro.C   -O1  execution test
FAIL: g++.dg/coroutines/torture/pr95519-05-gro.C   -O2  execution test
FAIL: g++.dg/coroutines/torture/pr95519-05-gro.C   -O3 -g  execution test
FAIL: g++.dg/coroutines/torture/pr95519-05-gro.C   -Os  execution test
FAIL: g++.dg/coroutines/torture/pr95519-05-gro.C   -O2 -flto
-fno-use-linker-plugin -flto-partition=none  execution test
FAIL: g++.dg/coroutines/torture/pr95519-05-gro.C   -O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects  execution test

with r11-1673:

commit e74c76073092f4715007584edb1fe6b7a17274db
Author: Iain Sandoe 
Date:   Fri Jun 26 10:48:35 2020 +0100

coroutines: Handle non-method promise expressions [PR95519]

(gdb) r
Starting program: /tmp/x 

Program received signal SIGABRT, Aborted.
0x77ad3b85 in raise () from /lib64/libc.so.6
(gdb) f 2
#2  0x004013ee in main () at pr95519-05-gro.C:56
56abort ();
(gdb) list
51 }
52f.resume();
53if (!f.done())
54  {
55PRINT ("expected foo to be finished");
56abort ();
57 }
58  
59if (called_gro_op != 1)
60  {
(gdb)

[Bug c++/95519] [coroutines] non-functions for promise_type::return_void not supported

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

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

H.J. Lu  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|REOPENED|RESOLVED

--- Comment #11 from H.J. Lu  ---
(In reply to Iain Sandoe from comment #10)
> (In reply to H.J. Lu from comment #9)
> > On AVX or AVX512 machines, I got
> 
> (I test on AVX and AVX512 machines without seeing this)
> 
> What version of glibc do you have?
> this might be a dup of PR96504
> 

Yes, it is the same.

[Bug c++/96504] [coroutines] test failures with glibc-2.32

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

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

H.J. Lu  changed:

   What|Removed |Added

   Last reconfirmed||2020-10-31
 Ever confirmed|0   |1
   See Also||https://sourceware.org/bugz
   ||illa/show_bug.cgi?id=26826
 Status|UNCONFIRMED |NEW
 CC||hjl.tools at gmail dot com

--- Comment #2 from H.J. Lu  ---
This is triggered by glibc commit:

https://sourceware.org/git/?p=glibc.git;a=commit;h=a1a486d70ebcc47a686ff5846875eacad0940e41

[Bug c++/96504] [coroutines] test failures with glibc-2.32

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

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

--- Comment #3 from H.J. Lu  ---
With glibc 2.31, I got

==2688647== Memcheck, a memory error detector
==2688647== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==2688647== Using Valgrind-3.16.1 and LibVEX; rerun with -h for copyright info
==2688647== Command: ./dynamic
==2688647== 
==2688647== Invalid read of size 8
==2688647==at 0x401405: std::__n4861::coroutine_handle::done() const
(coroutine:121)
==2688647==by 0x4013D1: main (pr95519-05-gro.C:53)
==2688647==  Address 0x4d7ec80 is 0 bytes inside a block of size 48 free'd
==2688647==at 0x483BEDD: operator delete(void*) (vg_replace_malloc.c:584)
==2688647==by 0x401350:
_ZL3fooRNSt7__n486116coroutine_handleIvEE.actor(foo(std::__n4861::coroutine_handle&)::_ZL3fooRNSt7__n486116coroutine_handleIvEE.frame*)
(pr95519-05-gro.C:41)
==2688647==by 0x40142A: std::__n4861::coroutine_handle::resume()
const (coroutine:126)
==2688647==by 0x4013C5: main (pr95519-05-gro.C:52)
==2688647==  Block was alloc'd at
==2688647==at 0x483AE7D: operator new(unsigned long)
(vg_replace_malloc.c:342)
==2688647==by 0x40115D: foo(std::__n4861::coroutine_handle&)
(pr95519-05-gro.C:41)
==2688647==by 0x4013A4: main (pr95519-05-gro.C:46)
==2688647==

[Bug c++/96504] [coroutines] Use after free in std::__n4861::coroutine_handle::done()

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

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

--- Comment #4 from H.J. Lu  ---
__builtin_coro_resume and __builtin_coro_destroy delete the memory.
Everything goes downhill after it.

[Bug c++/96504] [coroutines] Use after free in std::__n4861::coroutine_handle::done()

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

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

H.J. Lu  changed:

   What|Removed |Added

   Target Milestone|--- |10.3

[Bug bootstrap/97662] New: [11 Regression] r11-4587 breaks non-bootstrap build

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

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

Bug ID: 97662
   Summary: [11 Regression] r11-4587 breaks non-bootstrap build
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: jh at suse dot cz
  Target Milestone: ---

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

$ ../../gcc/configure
--prefix=/export/project/git/gcc-bisect-bootstrap/master/r11-4587/usr
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld
--with-fpmath=sse --enable-languages=c,c++ --enable-cet --disable-bootstrap
--with-fpmath=sse --disable-libcc1 --disable-libcilkrts --disable-libsanitizer
...
git/gcc-bisect-bootstrap/master/r11-4587/usr/x86_64-pc-linux-gnu/bin/
-B/export/project/git/gcc-bisect-bootstrap/master/r11-4587/usr/x86_64-pc-linux-gnu/lib/
-isystem
/export/project/git/gcc-bisect-bootstrap/master/r11-4587/usr/x86_64-pc-linux-gnu/include
-isystem
/export/project/git/gcc-bisect-bootstrap/master/r11-4587/usr/x86_64-pc-linux-gnu/sys-include
   -O2 -g -O2  -O2 -g -DIN_GCC-W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wno-error=format-diag -Wstrict-prototypes -Wmissing-prototypes
-Wno-error=format-diag -Wold-style-definition  -isystem ./include  -fpic
-mlong-double-80 -DUSE_ELF_SYMVER -fcf-protection -mshstk -g -DIN_LIBGCC2
-fbuilding-libgcc -fno-stack-protector  -fpic -mlong-double-80 -DUSE_ELF_SYMVER
-fcf-protection -mshstk -I. -I. -I../.././gcc -I../../../../gcc/libgcc
-I../../../../gcc/libgcc/. -I../../../../gcc/libgcc/../gcc
-I../../../../gcc/libgcc/../include -I../../../../gcc/libgcc/config/libbid
-DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS  -DUSE_TLS -Wno-missing-prototypes
-Wno-type-limits -o floatunditf_s.o -MT floatunditf_s.o -MD -MP -MF
floatunditf_s.dep -DSHARED  -c ../../../../gcc/libgcc/soft-fp/floatunditf.c
/export/project/git/gcc-bisect-bootstrap/master/r11-4587/bld/./gcc/xgcc
-B/export/project/git/gcc-bisect-bootstrap/master/r11-4587/bld/./gcc/
-B/export/project/git/gcc-bisect-bootstrap/master/r11-4587/usr/x86_64-pc-linux-gnu/bin/
-B/export/project/git/gcc-bisect-bootstrap/master/r11-4587/usr/x86_64-pc-linux-gnu/lib/
-isystem
/export/project/git/gcc-bisect-bootstrap/master/r11-4587/usr/x86_64-pc-linux-gnu/include
-isystem
/export/project/git/gcc-bisect-bootstrap/master/r11-4587/usr/x86_64-pc-linux-gnu/sys-include
   -O2 -g -O2  -O2 -g -DIN_GCC-W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wno-error=format-diag -Wstrict-prototypes -Wmissing-prototypes
-Wno-error=format-diag -Wold-style-definition  -isystem ./include  -fpic
-mlong-double-80 -DUSE_ELF_SYMVER -fcf-protection -mshstk -g -DIN_LIBGCC2
-fbuilding-libgcc -fno-stack-protector  -fpic -mlong-double-80 -DUSE_ELF_SYMVER
-fcf-protection -mshstk -I. -I. -I../.././gcc -I../../../../gcc/libgcc
-I../../../../gcc/libgcc/. -I../../../../gcc/libgcc/../gcc
-I../../../../gcc/libgcc/../include -I../../../../gcc/libgcc/config/libbid
-DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS  -DUSE_TLS -Wno-missing-prototypes
-Wno-type-limits -o fixtfti_s.o -MT fixtfti_s.o -MD -MP -MF fixtfti_s.dep
-DSHARED  -c ../../../../gcc/libgcc/soft-fp/fixtfti.c
/export/project/git/gcc-bisect-bootstrap/master/r11-4587/bld/./gcc/xgcc
-B/export/project/git/gcc-bisect-bootstrap/master/r11-4587/bld/./gcc/
-B/export/project/git/gcc-bisect-bootstrap/master/r11-4587/usr/x86_64-pc-linux-gnu/bin/
-B/export/project/git/gcc-bisect-bootstrap/master/r11-4587/usr/x86_64-pc-linux-gnu/lib/
-isystem
/export/project/git/gcc-bisect-bootstrap/master/r11-4587/usr/x86_64-pc-linux-gnu/include
-isystem
/export/project/git/gcc-bisect-bootstrap/master/r11-4587/usr/x86_64-pc-linux-gnu/sys-include
   -O2 -g -O2  -O2 -g -DIN_GCC-W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wno-error=format-diag -Wstrict-prototypes -Wmissing-prototypes
-Wno-error=format-diag -Wold-style-definition  -isystem ./include  -fpic
-mlong-double-80 -DUSE_ELF_SYMVER -fcf-protection -mshstk -g -DIN_LIBGCC2
-fbuilding-libgcc -fno-stack-protector  -fpic -mlong-double-80 -DUSE_ELF_SYMVER
-fcf-protection -mshstk -I. -I. -I../.././gcc -I../../../../gcc/libgcc
-I../../../../gcc/libgcc/. -I../../../../gcc/libgcc/../gcc
-I../../../../gcc/libgcc/../include -I../../../../gcc/libgcc/config/libbid
-DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS  -DUSE_TLS -Wno-missing-prototypes
-Wno-type-limits -o fixunstfti_s.o -MT fixunstfti_s.o -MD -MP -MF
fixunstfti_s.dep -DSHARED  -c ../../../../gcc/libgcc/soft-fp/fixunstfti.c
/export/project/git/gcc-bisect-bootstrap/master/r11-4587/bld/./gcc/xgcc
-B/export/project/git/gcc-bisect-bootstrap/master/r11-4587/bld/./gcc/
-B/export/project/git/gcc-bisect-bootstrap/master/r11-4587/usr/x86_64-pc-linux-gnu/bin/
-B/export/project/git/gcc-bisect-bootstrap/master/r11-4587/usr/x86_64-pc-linux-gnu/lib/
-isystem
/export/project/git/gcc-bisect-bootstrap/master/r11-4587/usr/x86_64-p

[Bug bootstrap/97662] [11 Regression] r11-4587 breaks non-bootstrap build

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

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #1 from H.J. Lu  ---
Dup.

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

[Bug ipa/97660] [11 Regression] ICE: Segmentation fault in function_summary::get(cgraph_node*) since r11-4587

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

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

H.J. Lu  changed:

   What|Removed |Added

   Last reconfirmed||2020-11-01
 Ever confirmed|0   |1
 CC||jh at suse dot cz
   Host|x86_64-freebsd12.2  |
   Target Milestone|--- |11.0
  Build|x86_64-freebsd12.2  |
 Target|x86_64-freebsd12.2  |
 Status|UNCONFIRMED |NEW

--- Comment #3 from H.J. Lu  ---
j...@suse.cz

[Bug ipa/97660] [11 Regression] ICE: Segmentation fault in function_summary::get(cgraph_node*) since r11-4587

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

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

H.J. Lu  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com

--- Comment #2 from H.J. Lu  ---
*** Bug 97662 has been marked as a duplicate of this bug. ***

[Bug fortran/97674] New: [11 Regression] gfortran.dg/pdt_14.f03 is compiled into an infinite loop

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

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

Bug ID: 97674
   Summary: [11 Regression] gfortran.dg/pdt_14.f03 is compiled
into an infinite loop
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---

On Linux/x86-64, r11-4588 compiles gfortran.dg/pdt_14.f03 into an infinite
loop.
r11-4584 is OK.

[Bug testsuite/97688] check_vect doesn't detect AVX2 on zen

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

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

--- Comment #10 from H.J. Lu  ---
FWIW, x86 source in gcc testsuite should be converted to
__builtin_cpu_supports().

[Bug testsuite/97688] check_vect doesn't detect AVX2 on zen

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

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

--- Comment #12 from H.J. Lu  ---
Created attachment 49495
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49495&action=edit
Something like this.

[Bug target/97715] [11 Regression] ICE in insn_default_length, at config/i386/i386.md:15325 since r11-4578-gd10f3e900b0377b4

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

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

H.J. Lu  changed:

   What|Removed |Added

 CC|hjl at gcc dot gnu.org |hjl.tools at gmail dot 
com

--- Comment #2 from H.J. Lu  ---
(In reply to qinzhao from comment #1)
> for -fzero-call-used-regs=all, when zeroing st/mm registers under x87 exit
> mode, However, command line option force no 80387 mode, the following insn
> generated to zero st registers is not recognized:
> 
> (insn 27 67 28 2 (set (reg:XF 8 st)
> (const_double:XF 0.0 [0x0.0p+0])) "zero-scratch-regs-10.c":8:1 -1
>  (nil))

You should avoid zeroing fixed registers.

[Bug testsuite/97803] New: c-c++-common/asan/pointer-compare-1.c assumes variable placement

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

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

Bug ID: 97803
   Summary: c-c++-common/asan/pointer-compare-1.c assumes variable
placement
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---

c-c++-common/asan/pointer-compare-1.c has

char global1[100] = {}, global2[100] = {}; 
char __attribute__((used)) smallest_global[5] = {}; 
char small_global[7] = {}; 
char __attribute__((used)) little_global[10] = {}; 
char __attribute__((used)) medium_global[4000] = {}; 
char large_global[5000] = {}; 
char __attribute__((used)) largest_global[6000] = {}; 

They are used to has layout:

00404380 B largest_global
00405b20 B large_global
00406ee0 B medium_global
00407ea0 B little_global
00407ee0 B small_global
00407f20 B smallest_global
00407f60 B global2
00408000 B global1
004080e0 B __odr_asan.largest_global
004080e1 B __odr_asan.large_global
004080e2 B __odr_asan.medium_global
004080e3 B __odr_asan.little_global
004080e4 B __odr_asan.small_global
004080e5 B __odr_asan.smallest_global
004080e6 B __odr_asan.global2
004080e7 B __odr_asan.global1

With SHF_GNU_RETAIN change:

https://gitlab.com/x86-gcc/gcc/-/tree/users/hjl/elf/shf_retain

the new layout become:

00404380 B large_global
00405740 B small_global
00405780 B global2
00405820 B global1
00405900 B __odr_asan.largest_global
00405901 B __odr_asan.large_global
00405902 B __odr_asan.medium_global
00405903 B __odr_asan.little_global
00405904 B __odr_asan.small_global
00405905 B __odr_asan.smallest_global
00405906 B __odr_asan.global2
00405907 B __odr_asan.global1
00405920 B largest_global
004070c0 B medium_global
00408080 B little_global
004080c0 B smallest_global

and test fails.

[Bug testsuite/97803] c-c++-common/asan/pointer-compare-1.c assumes variable placement

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

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

--- Comment #3 from H.J. Lu  ---
(In reply to Richard Biener from comment #1)
> Does it work if you add -fno-toplevel-reorder?  SHF_GNU_RETAIN should
> preserve the order of vars even if 'used' then.

Linker will reorder section layout when SHF_GNU_RETAIN is used.

[Bug testsuite/97803] c-c++-common/asan/pointer-compare-1.c assumes variable placement

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

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

--- Comment #4 from H.J. Lu  ---
Created attachment 49552
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49552&action=edit
A patch

This works with SHF_GNU_RETAIN.

[Bug lto/46769] LTO failed to build gold

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

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

H.J. Lu  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |10.2

--- Comment #8 from H.J. Lu  ---
GCC 10.2 can build gold with LTO.