[Bug target/89229] Incorrect xmm16-xmm31/ymm16-ymm31 in vector move

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #35 from H.J. Lu  ---
Fixed for GCC 10.

[Bug target/89226] codegen for copying a 512-bit object fails to use avx instructions

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||crazylht at gmail dot com

--- Comment #8 from H.J. Lu  ---
This may be a candidate for fast short REP MOV optimization.

[Bug target/94343] [10 Regression] invalid AVX512VL vpternlogd instruction emitted for -march=knl

[hjl.tools at gmail dot com]

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

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

Jakub, this is what I have. Feel free to ignore it.

[Bug target/94343] [10 Regression] invalid AVX512VL vpternlogd instruction emitted for -march=knl

[hjl.tools at gmail dot com]

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

--- Comment #6 from H.J. Lu  ---
(In reply to Jakub Jelinek from comment #5)
> Created attachment 48127 [details]
> gcc10-pr94343.patch
> 
> That of course doesn't work if the input operand is memory.  This should.

LGTM.  Thanks.

[Bug driver/94381] New: -falign-function/-falign-labels/-falign-loops documentation is inaccurate

[hjl.tools at gmail dot com]

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

Bug ID: 94381
   Summary: -falign-function/-falign-labels/-falign-loops
documentation is inaccurate
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: crazylht at gmail dot com, skpgkp2 at gmail dot com
  Target Milestone: ---

'-falign-functions'
'-falign-functions=N'
'-falign-functions=N:M'
'-falign-functions=N:M:N2'
'-falign-functions=N:M:N2:M2'
 Align the start of functions to the next power-of-two greater than
 N, skipping up to M-1 bytes.

But

[hjl@gnu-cfl-2 align]$ cat y.i
void
foo (void)
{
}
[hjl@gnu-cfl-2 align]$ gcc -O2 -S -falign-functions=4 y.i
[hjl@gnu-cfl-2 align]$ cat y.s
.file   "y.i"
.text
.p2align 2 <<<<<<<< 4 is not the next power-of-two greater than 4.
.globl  foo
.type   foo, @function
foo:
.LFB0:
.cfi_startproc
ret
.cfi_endproc
.LFE0:
.size   foo, .-foo
.ident  "GCC: (GNU) 9.3.1 20200317 (Red Hat 9.3.1-1)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-cfl-2 align]$ 

It should be "the next power-of-two no less than N".

'-falign-labels'
'-falign-labels=N'
'-falign-labels=N:M'
'-falign-labels=N:M:N2'
'-falign-labels=N:M:N2:M2'
 Align all branch targets to a power-of-two boundary.

and

'-falign-loops'
'-falign-loops=N'
'-falign-loops=N:M'
'-falign-loops=N:M:N2'
'-falign-loops=N:M:N2:M2'
 Align loops to a power-of-two boundary.  

may leave an impression of alignment is N to the power-of-two.

[Bug driver/94381] -falign-function/-falign-labels/-falign-loops documentation is inaccurate

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

   Last reconfirmed||2020-03-28
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

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

'-falign-loops'
'-falign-loops=N'
'-falign-loops=N:M'
'-falign-loops=N:M:N2'
'-falign-loops=N:M:N2:M2'

and

'-falign-jumps'
'-falign-jumps=N'
'-falign-jumps=N:M'
'-falign-jumps=N:M:N2'
'-falign-jumps=N:M:N2:M2'

specify the maximum alignment.  The actual alignment is also controlled by

'-falign-labels'
'-falign-labels=N'
'-falign-labels=N:M'
'-falign-labels=N:M:N2'
'-falign-labels=N:M:N2:M2'

[Bug driver/94381] -falign-function/-falign-labels/-falign-loops documentation is inaccurate

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2020-March/5
   ||42861.html
   Target Milestone|--- |10.0
   Keywords||patch

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

https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542861.html

[Bug fortran/94386] New: [10 Regression] FAIL: gfortran.dg/pr93365.f90

[hjl.tools at gmail dot com]

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

Bug ID: 94386
   Summary: [10 Regression] FAIL: gfortran.dg/pr93365.f90
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: pault at gcc dot gnu.org
  Target Milestone: ---

commit 7d57570b0658b8c1b8a97dafa53dfd4ab4bd3f65
Author: Paul Thomas 
Date:   Sat Mar 28 19:11:35 2020 +

Patch for PR94246

caused:

FAIL: gfortran.dg/pr93365.f90   -O0  (internal compiler error)
FAIL: gfortran.dg/pr93365.f90   -O0  (test for excess errors)
FAIL: gfortran.dg/pr93365.f90   -O1  (internal compiler error)
FAIL: gfortran.dg/pr93365.f90   -O1  (test for excess errors)
FAIL: gfortran.dg/pr93365.f90   -O2  (internal compiler error)
FAIL: gfortran.dg/pr93365.f90   -O2  (test for excess errors)
FAIL: gfortran.dg/pr93365.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (internal compiler error)
FAIL: gfortran.dg/pr93365.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (test for excess errors)
FAIL: gfortran.dg/pr93365.f90   -O3 -g  (internal compiler error)
FAIL: gfortran.dg/pr93365.f90   -O3 -g  (test for excess errors)
FAIL: gfortran.dg/pr93365.f90   -Os  (internal compiler error)
FAIL: gfortran.dg/pr93365.f90   -Os  (test for excess errors)
FAIL: gfortran.dg/pr93600_1.f90   -O  (internal compiler error)
FAIL: gfortran.dg/pr93600_1.f90   -O   (test for errors, line 6)
FAIL: gfortran.dg/pr93600_1.f90   -O   (test for errors, line 7)
FAIL: gfortran.dg/pr93600_1.f90   -O  (test for excess errors)
FAIL: gfortran.dg/pr93600_2.f90   -O0  (internal compiler error)
FAIL: gfortran.dg/pr93600_2.f90   -O0  (test for excess errors)
FAIL: gfortran.dg/pr93600_2.f90   -O1  (internal compiler error)
FAIL: gfortran.dg/pr93600_2.f90   -O1  (test for excess errors)
FAIL: gfortran.dg/pr93600_2.f90   -O2  (internal compiler error)
FAIL: gfortran.dg/pr93600_2.f90   -O2  (test for excess errors)
FAIL: gfortran.dg/pr93600_2.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (internal compiler error)
FAIL: gfortran.dg/pr93600_2.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (test for excess errors)
FAIL: gfortran.dg/pr93600_2.f90   -O3 -g  (internal compiler error)
FAIL: gfortran.dg/pr93600_2.f90   -O3 -g  (test for excess errors)
FAIL: gfortran.dg/pr93600_2.f90   -Os  (internal compiler error)
FAIL: gfortran.dg/pr93600_2.f90   -Os  (test for excess errors)

[Bug driver/94381] -falign-function/-falign-labels/-falign-loops documentation is inaccurate

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

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

[Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Resolution|WONTFIX |WORKSFORME

--- Comment #4 from H.J. Lu  ---
(In reply to Yuxuan Shui from comment #0)
> Test case:
> 
> Source file (a.c):
> extern char _binary_a_c_size[];
> unsigned long foo() { return (unsigned long)_binary_a_c_size; }

Try

---
extern unsigned long _binary_a_c_size;
unsigned long foo() { return _binary_a_c_size; }
---

> Run:
> objcopy -B i386:x86-64 -I binary -O elf64-x86-64 a.c b.o
> gcc -fuse-ld=lld -fpie -pie a.c b.o
> 
> lld complains about:
> 
> ld.lld: error: relocation R_X86_64_PC32 cannot refer to absolute symbol:
> _binary_a_c_size

This is an lld bug.

[Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation

[hjl.tools at gmail dot com]

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

--- Comment #9 from H.J. Lu  ---
(In reply to Fangrui Song from comment #5)
> This bug exposes several problems:
> 
> * GNU ld does not reject a PC-relative relocation referencing a SHN_ABS
> symbol
> * GCC should not produce R_X86_64_PC32 referencing an external symbol in
> -fpie mode. 
> 
> % gcc -fuse-ld=lld -nostdlib -fpie -pie a.c
> % objdump -dr a.o
> ...
>  :
>0:   55  push   %rbp
>1:   48 89 e5mov%rsp,%rbp
>4:   48 8d 05 00 00 00 00lea0x0(%rip),%rax# b 
> 7: R_X86_64_PC32_binary_a_c_size-0x4
>b:   5d  pop%rbp
>c:   c3  retq
> 
> % gcc -fuse-ld=bfd -nostdlib -fpie -pie a.c b.o -o a
> /usr/bin/ld.bfd: warning: cannot find entry symbol _start; defaulting to
> 1000
> % objdump -dr a
> ...
> 1000 :
> 1000:   55  push   %rbp
> 1001:   48 89 e5mov%rsp,%rbp
> 1004:   48 8d 05 39 f0 ff fflea-0xfc7(%rip),%rax# 44
> <_binary_a_c_size>
> 100b:   5d  pop%rbp
> 100c:   c3  retq
> 
> It is incorrect to reference a non-preemptible symbol with a PC relative
> relocation in a -pie link. GNU ld allows it but the code can be incorrect at
> runtime.
> 
> lea-0xfc7(%rip),%rax  # loads 44 to %rax only if the load base is 0. Due
> to ASLR (-pie), this is simply not true.

Your are using the incorrect user code.  Please use

---
extern unsigned long _binary_a_c_size;
unsigned long foo() { return _binary_a_c_size; }
---

GCC and ld handle it correctly.

[Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation

[hjl.tools at gmail dot com]

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

--- Comment #12 from H.J. Lu  ---
(In reply to Yuxuan Shui from comment #11)
> (In reply to Andrew Pinski from comment #8)
> > Also it is wrong for a person to assume a normal C variable could be
> > SHN_ABS; that is the bug here.  It is a bug in the user code.
> > I showed up to fix it by using an top level inline-asm.
> 
> Why is this wrong? Is it written down somewhere that a C variable can never
> be SHN_ABS, perhaps in the standard, or in the X86-psABI?
> 
> If this is wrong, then what is the correct way to access a SHN_ABS symbol?
> Is it just no way to do it? If so, what's the purpose of objcopy generating
> such symbols?

Have you tried my way with ld?  Lld bug is a different issue.

[Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation

[hjl.tools at gmail dot com]

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

--- Comment #13 from H.J. Lu  ---
The current relocation doesn't support PC32 relocation against SHN_ABS
in PIE nor shared library.  I will change ld to issue an error.

[Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation

[hjl.tools at gmail dot com]

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

--- Comment #14 from H.J. Lu  ---
(In reply to H.J. Lu from comment #13)
> The current relocation doesn't support PC32 relocation against SHN_ABS
> in PIE nor shared library.  I will change ld to issue an error.

I opened:

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

[Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation

[hjl.tools at gmail dot com]

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

--- Comment #16 from H.J. Lu  ---
(In reply to Yuxuan Shui from comment #15)
> Your code is going to dereference the value stored in the ABS symbol as an
> address (e.g. if the symbol has value 10, your code will access (*(char
> *)10), barring the unwanted relocation), which is not the intention here.

This works in all cases:

unsigned long
size2 (void)
{
  return ((unsigned long) &_binary_a_c_end
  - (unsigned long) &_binary_a_c_start);
}

[Bug target/94417] New: -fcf-protection -mcmodel=large is broken

[hjl.tools at gmail dot com]

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

Bug ID: 94417
   Summary: -fcf-protection -mcmodel=large is broken
   Product: gcc
   Version: 10.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

From:

https://bugs.llvm.org/show_bug.cgi?id=45364

Testcase:

void ext();
__attribute((noinline)) static void a() { ext(); }
void b() { a(); }

Compile with "gcc -O2 -mcmodel=large -fcf-protection".  Note the indirect
call to "a", which does not have an endbr64.

[Bug target/94417] -fcf-protection -mcmodel=large/-mforce-indirect-call is broken

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

Summary|-fcf-protection |-fcf-protection
   |-mcmodel=large is broken|-mcmodel=large/-mforce-indi
   ||rect-call is broken

--- Comment #1 from H.J. Lu  ---
-mforce-indirect-call has the same issue.

[Bug target/94417] -fcf-protection -mcmodel=large/-mforce-indirect-call is broken

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2020-03-31

--- Comment #2 from H.J. Lu  ---
This seems to work:

diff --git a/gcc/config/i386/i386-features.c b/gcc/config/i386/i386-features.c
index 66b120d21a7..78fb373db6e 100644
--- a/gcc/config/i386/i386-features.c
+++ b/gcc/config/i386/i386-features.c
@@ -1963,7 +1963,12 @@ rest_of_insert_endbranch (void)
   && (!flag_manual_endbr
 || lookup_attribute ("cf_check",
DECL_ATTRIBUTES (cfun->decl)))
-  && !cgraph_node::get (cfun->decl)->only_called_directly_p ())
+  && (!cgraph_node::get (cfun->decl)->only_called_directly_p ()
+|| ix86_cmodel == CM_LARGE
+|| ix86_cmodel == CM_LARGE_PIC
+|| flag_force_indirect_call
+|| (TARGET_DLLIMPORT_DECL_ATTRIBUTES
+&& DECL_DLLIMPORT_P (cfun->decl
 {
   /* Queue ENDBR insertion to x86_function_profiler.  */
   if (crtl->profile && flag_fentry)

[Bug target/94417] -fcf-protection -mcmodel=large/-mforce-indirect-call is broken

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

   Target Milestone|--- |10.0
URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2020-March/5
   ||42984.html
   Keywords||patch

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

https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542984.html

[Bug middle-end/94449] New: [10 Regression] FAIL: gcc.c-torture/execute/pr92904.c gcc.dg/torture/pr48731.c

[hjl.tools at gmail dot com]

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

Bug ID: 94449
   Summary: [10 Regression] FAIL: gcc.c-torture/execute/pr92904.c
gcc.dg/torture/pr48731.c
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---
Target: i686

On Linux/i686, r10-7496 gave

FAIL: gcc.c-torture/execute/pr92904.c   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (internal compiler error)
FAIL: gcc.c-torture/execute/pr92904.c   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (test for excess errors)
FAIL: gcc.c-torture/execute/pr92904.c   -O3 -g  (internal compiler error)
FAIL: gcc.c-torture/execute/pr92904.c   -O3 -g  (test for excess errors)
FAIL: gcc.dg/torture/pr48731.c   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (internal compiler error)
FAIL: gcc.dg/torture/pr48731.c   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (test for excess errors)
FAIL: gcc.dg/torture/pr48731.c   -O3 -g  (internal compiler error)
FAIL: gcc.dg/torture/pr48731.c   -O3 -g  (test for excess errors)

r10-7486 is OK.

[Bug middle-end/94449] [10 Regression] FAIL: gcc.c-torture/execute/pr92904.c gcc.dg/torture/pr48731.c

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #1 from H.J. Lu  ---
It is on Linux/x86-64.

[Bug middle-end/94449] [10 Regression] FAIL: gcc.c-torture/execute/pr92904.c gcc.dg/torture/pr48731.c

[hjl.tools at gmail dot com]

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

--- Comment #2 from H.J. Lu  ---
/export/gnu/import/git/gcc-test-master-intel64/bld/gcc/xgcc
-B/export/gnu/import/git/gcc-test-master-intel64/bld/gcc/
/export/gnu/import/git/gcc-test-master-intel64/src-master/gcc/testsuite/gcc.dg/torture/pr48731.c
-mx32 -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -fdiagnostics-urls=never -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions -S -o pr48731.s
/export/gnu/import/git/gcc-test-master-intel64/src-master/gcc/testsuite/gcc.dg/torture/pr48731.c:
In function 'blah':
/export/gnu/import/git/gcc-test-master-intel64/src-master/gcc/testsuite/gcc.dg/torture/pr48731.c:5:5:
error: missing definition
for SSA_NAME: _104 in statement:
_69 = _104;
during GIMPLE pass: vect
/export/gnu/import/git/gcc-test-master-intel64/src-master/gcc/testsuite/gcc.dg/torture/pr48731.c:5:5:
internal compiler error: verify_ssa failed
0xfa5802 verify_ssa(bool, bool)
../../src-master/gcc/tree-ssa.c:1208
0xcbec85 execute_function_todo
../../src-master/gcc/passes.c:1992
0xcbf9cc do_per_function
../../src-master/gcc/passes.c:1640
0xcbf9cc execute_todo
../../src-master/gcc/passes.c:2039
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
compiler exited with status 1

[Bug middle-end/94449] [10 Regression] FAIL: gcc.c-torture/execute/pr92904.c gcc.dg/torture/pr48731.c

[hjl.tools at gmail dot com]

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

--- Comment #3 from H.J. Lu  ---
/export/gnu/import/git/gcc-test-master-intel64/bld/gcc/xgcc
-B/export/gnu/import/git/gcc-test-master-intel64/bld/gcc/
/export/gnu/import/git/gcc-test-master-intel64/src-master/gcc/testsuite/gcc.c-torture/execute/pr92904.c
-mx32 -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -fdiagnostics-urls=never -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions -w -lm -o ./pr92904.exe
/export/gnu/import/git/gcc-test-master-intel64/src-master/gcc/testsuite/gcc.c-torture/execute/pr92904.c:
In function 'f1':
/export/gnu/import/git/gcc-test-master-intel64/src-master/gcc/testsuite/gcc.c-torture/execute/pr92904.c:23:1:
error: missing definition
for SSA_NAME: _98 in statement:
_69 = _98;
during GIMPLE pass: vect
/export/gnu/import/git/gcc-test-master-intel64/src-master/gcc/testsuite/gcc.c-torture/execute/pr92904.c:23:1:
internal compiler error: verify_ssa failed
0xfa5802 verify_ssa(bool, bool)
../../src-master/gcc/tree-ssa.c:1208
0xcbec85 execute_function_todo
../../src-master/gcc/passes.c:1992
0xcbf9cc do_per_function
../../src-master/gcc/passes.c:1640
0xcbf9cc execute_todo
../../src-master/gcc/passes.c:2039
Please submit a full bug report, 
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report. 
See  for instructions.
compiler exited with status 1

[Bug middle-end/94449] [10 Regression] FAIL: gcc.c-torture/execute/pr92904.c gcc.dg/torture/pr48731.c

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||linkw at gcc dot gnu.org

--- Comment #4 from H.J. Lu  ---
It is caused by r10-7501:

commit bd0f22a8d5caea8905f38ff1fafce31c1b7d33ad
Author: Kewen Lin 
Date:   Tue Mar 31 22:48:46 2020 -0500

Fix PR94043 by making vect_live_op generate lc-phi

[Bug middle-end/94449] [10 Regression] FAIL: gcc.c-torture/execute/pr92904.c gcc.dg/torture/pr48731.c

[hjl.tools at gmail dot com]

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

--- Comment #5 from H.J. Lu  ---
(In reply to H.J. Lu from comment #4)
> It is caused by r10-7501:

It is r10-7491

> commit bd0f22a8d5caea8905f38ff1fafce31c1b7d33ad
> Author: Kewen Lin 
> Date:   Tue Mar 31 22:48:46 2020 -0500
> 
> Fix PR94043 by making vect_live_op generate lc-phi

[Bug middle-end/94449] [10 Regression] FAIL: gcc.c-torture/execute/pr92904.c gcc.dg/torture/pr48731.c

[hjl.tools at gmail dot com]

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

--- Comment #6 from H.J. Lu  ---
May need to boostrap GCC on Linux/x86-64 to see it.  It can be reproduced
even when x32 isn't enabled.

[Bug middle-end/94449] [10 Regression] FAIL: gcc.c-torture/execute/pr92904.c gcc.dg/torture/pr48731.c

[hjl.tools at gmail dot com]

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

--- Comment #9 from H.J. Lu  ---
(In reply to Kewen Lin from comment #8)
> May I ask for the configuration option? 
> 
> I used x86_64 machine in CFarm with cpuinfo
> 

I used

--prefix=/usr/10.0.1 --enable-clocale=gnu --with-system-zlib --enable-shared
--enable-cet --with-demangler-in-ld --with-fpmath=sse

[Bug target/94452] I386 ABI: How to determine the alignment arguments on the stack of struct or union for argument passing

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #6 from H.J. Lu  ---
(In reply to ChenLiu from comment #5)
> (In reply to Richard Biener from comment #4)
> > (In reply to ChenLiu from comment #2)
> > > (In reply to Richard Biener from comment #1)
> > > > I see gx aligned to 64 bytes (as I expected).  Can you be more specific 
> > > > as
> > > > to what target you tested?
> > > 
> > > I tested on i386 target. I think you may misunderstand what I mean. The gx
> > > will align to 4 byte when passing it on stack. I think this should belong 
> > > to
> > > calling conventions.
> > 
> > Ah, OK.  IIRC the psABI does not factor in over/under alignment but only
> > size and kind of (sub-)objects so eventually extra copy-in/out is required
> > to have the callee see arguments of the desired alignment.
> > 
> > HJ can probably clarify.
> > 
> > Note bugzilla isn't really for this kind of questions, there's a psABI
> > mailing list somewhere.
> 
> Thanks for your help.

Please raise this question at

https://groups.google.com/forum/#!forum/ia32-abi

[Bug bootstrap/90497] [10 Regression] Broken bootstrap on i686-linux

[hjl.tools at gmail dot com]

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

--- Comment #9 from H.J. Lu  ---
Why do we have

define_expand "sse2_umulv1siv1di3"
  [(set (match_operand:V1DI 0 "register_operand")
(mult:V1DI
  (zero_extend:V1DI
(vec_select:V1SI
  (match_operand:V2SI 1 "nonimmediate_operand")
  (parallel [(const_int 0)])))
  (zero_extend:V1DI
(vec_select:V1SI
  (match_operand:V2SI 2 "nonimmediate_operand")
  (parallel [(const_int 0)])]
  "TARGET_SSE2"
  "ix86_fixup_binary_operands_no_copy (MULT, V2SImode, operands);")

i386-builtin.def:BDESC (OPTION_MASK_ISA_SSE2 | OPTION_MASK_ISA_MMX, 0,
CODE_FOR_sse2_umulv1siv1di3, "__builtin_ia32_pmuludq", IX86_BUILTIN_PMULUDQ,
UNKNOWN, (int) V1DI_FTYPE_V2SI_V2SI)

sse2_umulv1siv1di3 isn't available with MMX.

[Bug target/94461] [10 Regression] ICE: in extract_insn, at recog.c:2294 with __builtin_ia32_pmuludq() and -mno-sse2

[hjl.tools at gmail dot com]

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

--- Comment #4 from H.J. Lu  ---
Why do we have

define_expand "sse2_umulv1siv1di3"
  [(set (match_operand:V1DI 0 "register_operand")
(mult:V1DI
  (zero_extend:V1DI
(vec_select:V1SI
  (match_operand:V2SI 1 "nonimmediate_operand")
  (parallel [(const_int 0)])))
  (zero_extend:V1DI
(vec_select:V1SI
  (match_operand:V2SI 2 "nonimmediate_operand")
  (parallel [(const_int 0)])]
  "TARGET_SSE2"
  "ix86_fixup_binary_operands_no_copy (MULT, V2SImode, operands);")

i386-builtin.def:BDESC (OPTION_MASK_ISA_SSE2 | OPTION_MASK_ISA_MMX, 0,
CODE_FOR_sse2_umulv1siv1di3, "__builtin_ia32_pmuludq", IX86_BUILTIN_PMULUDQ,
UNKNOWN, (int) V1DI_FTYPE_V2SI_V2SI)

sse2_umulv1siv1di3 isn't available with MMX.

[Bug target/94461] [10 Regression] ICE: in extract_insn, at recog.c:2294 with __builtin_ia32_pmuludq() and -mno-sse2

[hjl.tools at gmail dot com]

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

--- Comment #6 from H.J. Lu  ---
(In reply to Uroš Bizjak from comment #3)
> It looks to me that the fix for PR90497 is not entirely correct, because it
> allows to bypass builtins that have additional SSE* restrictions.
> 
> The following test also fails with -mmmx -msse -mno-sse2 (or -m32):
> 
> ttt.c: In function ‘foo’:
> ttt.c:8:1: error: unrecognizable insn:
> 8 | }
>   | ^
>

Where is the test?

[Bug target/94461] [10 Regression] ICE: in extract_insn, at recog.c:2294 with __builtin_ia32_pmuludq() and -mno-sse2

[hjl.tools at gmail dot com]

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

--- Comment #5 from H.J. Lu  ---
The following ones:

BDESC (OPTION_MASK_ISA_SSE2 | OPTION_MASK_ISA_MMX, 0, CODE_FOR_sse2_cvtpd2pi,
"__builtin_ia32_cvtpd2pi", IX86_BUILTIN_CVTPD2PI, UNKNOWN, (int)
V2SI_FTYPE_V2DF)
BDESC (OPTION_MASK_ISA_SSE2 | OPTION_MASK_ISA_MMX, 0, CODE_FOR_sse2_cvttpd2pi,
"__builtin_ia32_cvttpd2pi", IX86_BUILTIN_CVTTPD2PI, UNKNOWN, (int)
V2SI_FTYPE_V2DF)
BDESC (OPTION_MASK_ISA_SSE2 | OPTION_MASK_ISA_MMX, 0, CODE_FOR_sse2_cvtpi2pd,
"__builtin_ia32_cvtpi2pd", IX86_BUILTIN_CVTPI2PD, UNKNOWN, (int)
V2DF_FTYPE_V2SI)
BDESC (OPTION_MASK_ISA_SSE2 | OPTION_MASK_ISA_MMX, 0,
CODE_FOR_sse2_umulv1siv1di3, "__builtin_ia32_pmuludq", IX86_BUILTIN_PMULUDQ,
UNKNOWN, (int) V1DI_FTYPE_V2SI_V2SI)
BDESC (OPTION_MASK_ISA_SSSE3 | OPTION_MASK_ISA_MMX, 0, CODE_FOR_ssse3_absv8qi2,
"__builtin_ia32_pabsb", IX86_BUILTIN_PABSB, UNKNOWN, (int) V8QI_FTYPE_V8QI)
BDESC (OPTION_MASK_ISA_SSSE3 | OPTION_MASK_ISA_MMX, 0, CODE_FOR_ssse3_absv4hi2,
"__builtin_ia32_pabsw", IX86_BUILTIN_PABSW, UNKNOWN, (int) V4HI_FTYPE_V4HI)
BDESC (OPTION_MASK_ISA_SSSE3 | OPTION_MASK_ISA_MMX, 0, CODE_FOR_ssse3_absv2si2,
"__builtin_ia32_pabsd", IX86_BUILTIN_PABSD, UNKNOWN, (int) V2SI_FTYPE_V2SI)
BDESC (OPTION_MASK_ISA_SSSE3 | OPTION_MASK_ISA_MMX, 0,
CODE_FOR_ssse3_phaddwv4hi3, "__builtin_ia32_phaddw", IX86_BUILTIN_PHADDW,
UNKNOWN, (int) V4HI_FTYPE_V4HI_V4HI)
BDESC (OPTION_MASK_ISA_SSSE3 | OPTION_MASK_ISA_MMX, 0,
CODE_FOR_ssse3_phadddv2si3, "__builtin_ia32_phaddd", IX86_BUILTIN_PHADDD,
UNKNOWN, (int) V2SI_FTYPE_V2SI_V2SI)
BDESC (OPTION_MASK_ISA_SSSE3 | OPTION_MASK_ISA_MMX, 0,
CODE_FOR_ssse3_phaddswv4hi3, "__builtin_ia32_phaddsw", IX86_BUILTIN_PHADDSW,
UNKNOWN, (int) V4HI_FTYPE_V4HI_V4HI)
BDESC (OPTION_MASK_ISA_SSSE3 | OPTION_MASK_ISA_MMX, 0,
CODE_FOR_ssse3_phsubwv4hi3, "__builtin_ia32_phsubw", IX86_BUILTIN_PHSUBW,
UNKNOWN, (int) V4HI_FTYPE_V4HI_V4HI)
BDESC (OPTION_MASK_ISA_SSSE3 | OPTION_MASK_ISA_MMX, 0,
CODE_FOR_ssse3_phsubdv2si3, "__builtin_ia32_phsubd", IX86_BUILTIN_PHSUBD,
UNKNOWN, (int) V2SI_FTYPE_V2SI_V2SI)
BDESC (OPTION_MASK_ISA_SSSE3 | OPTION_MASK_ISA_MMX, 0,
CODE_FOR_ssse3_phsubswv4hi3, "__builtin_ia32_phsubsw", IX86_BUILTIN_PHSUBSW,
UNKNOWN, (int) V4HI_FTYPE_V4HI_V4HI)
BDESC (OPTION_MASK_ISA_SSSE3 | OPTION_MASK_ISA_MMX, 0,
CODE_FOR_ssse3_pmaddubsw, "__builtin_ia32_pmaddubsw", IX86_BUILTIN_PMADDUBSW,
UNKNOWN, (int) V4HI_FTYPE_V8QI_V8QI)
BDESC (OPTION_MASK_ISA_SSSE3 | OPTION_MASK_ISA_MMX, 0,
CODE_FOR_ssse3_pmulhrswv4hi3, "__builtin_ia32_pmulhrsw", IX86_BUILTIN_PMULHRSW,
UNKNOWN, (int) V4HI_FTYPE_V4HI_V4HI)
BDESC (OPTION_MASK_ISA_SSSE3 | OPTION_MASK_ISA_MMX, 0,
CODE_FOR_ssse3_pshufbv8qi3, "__builtin_ia32_pshufb", IX86_BUILTIN_PSHUFB,
UNKNOWN, (int) V8QI_FTYPE_V8QI_V8QI)
BDESC (OPTION_MASK_ISA_SSSE3 | OPTION_MASK_ISA_MMX, 0,
CODE_FOR_ssse3_psignv8qi3, "__builtin_ia32_psignb", IX86_BUILTIN_PSIGNB,
UNKNOWN, (int) V8QI_FTYPE_V8QI_V8QI)
BDESC (OPTION_MASK_ISA_SSSE3 | OPTION_MASK_ISA_MMX, 0,
CODE_FOR_ssse3_psignv4hi3, "__builtin_ia32_psignw", IX86_BUILTIN_PSIGNW,
UNKNOWN, (int) V4HI_FTYPE_V4HI_V4HI)
BDESC (OPTION_MASK_ISA_SSSE3 | OPTION_MASK_ISA_MMX, 0,
CODE_FOR_ssse3_psignv2si3, "__builtin_ia32_psignd", IX86_BUILTIN_PSIGND,
UNKNOWN, (int) V2SI_FTYPE_V2SI_V2SI)
BDESC (OPTION_MASK_ISA_SSSE3 | OPTION_MASK_ISA_MMX, 0,
CODE_FOR_ssse3_palignrdi, "__builtin_ia32_palignr", IX86_BUILTIN_PALIGNR,
UNKNOWN, (int) V1DI_FTYPE_V1DI_V1DI_INT_CONVERT)

have the same problem.

[Bug target/94461] [10 Regression] ICE: in extract_insn, at recog.c:2294 with __builtin_ia32_pmuludq() and -mno-sse2

[hjl.tools at gmail dot com]

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

--- Comment #9 from H.J. Lu  ---
(In reply to Jakub Jelinek from comment #8)
> So, I believe the r10-400-gecfdb16c54ad06ac23193e5de292fc71e5958526 change
> has been incorrect.
> We should revert those i386-builtin.def changes, and instead treat builtins
> with sole OPTION_MASK_ISA_MMX (and nothing else) as being enabled also if
> TARGET_MMX_WITH_SSE, not just with TARGET_MMX.

The problem is OPTION_MASK_ISA_MMX is used for 2 different purposes:

1. Enable MMX registers.
2. Enable MMX ISA.

pcmpeq is an MMX insn, but 128bit pcmpeq is in SSE2, not SSE.

[Bug target/94461] [10 Regression] ICE: in extract_insn, at recog.c:2294 with __builtin_ia32_pmuludq() and -mno-sse2

[hjl.tools at gmail dot com]

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

--- Comment #12 from H.J. Lu  ---
Created attachment 48186
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48186&action=edit
An incomplete patch

Jakub, this is an incomplete patch with 2 testcases.  Can you take it over?
I will fix PR 94467.  Thanks.

[Bug target/94467] [10 Regression] wrong code with -mavx and ssse3 builtins

[hjl.tools at gmail dot com]

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

--- Comment #6 from H.J. Lu  ---
The bug was introduced by r10-393:

commit 16ed2601ad0a4aa82f11e9df86ea92183f94f979
Author: H.J. Lu 
Date:   Wed May 15 15:26:19 2019 +

i386: Emulate MMX pshufb with SSE version

Emulate MMX version of pshufb with SSE version by masking out the bit 3
of the shuffle control byte.  Only SSE register source operand is allowed.

PR target/89021
* config/i386/sse.md (ssse3_pshufbv8qi3): Changed to
define_insn_and_split.  Also allow TARGET_MMX_WITH_SSE.  Add
SSE emulation.

+(define_insn_and_split "ssse3_pshufbv8qi3"
+  [(set (match_operand:V8QI 0 "register_operand" "=y,x,Yv")
+  (unspec:V8QI [(match_operand:V8QI 1 "register_operand" "0,0,Yv")
+   (match_operand:V8QI 2 "register_mmxmem_operand" "ym,x,Yv")]
+  UNSPEC_PSHUFB))
+   (clobber (match_scratch:V4SI 3 "=X,x,Yv"))]  <<< This is an earlyclobber
operand.
+  "(TARGET_MMX || TARGET_MMX_WITH_SSE) && TARGET_SSSE3"
+  "@
+   pshufb\t{%2, %0|%0, %2}
+   #
+   #"
+  "TARGET_MMX_WITH_SSE && reload_completed"
+  [(set (match_dup 3) (match_dup 5))
+   (set (match_dup 3)
+  (and:V4SI (match_dup 3) (match_dup 2)))
+   (set (match_dup 0)
+  (unspec:V16QI [(match_dup 1) (match_dup 4)] UNSPEC_PSHUFB))]

[Bug target/94467] [10 Regression] wrong code with -mavx and ssse3 builtins

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #8 from H.J. Lu  ---
Fixed for GCC 10.

[Bug ipa/94486] [10 regression] bootstrap build failure after r10-7552

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #1 from H.J. Lu  ---
Fixed by r10-7555

[Bug target/94417] -fcf-protection -mcmodel=large/-mforce-indirect-call is broken

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #5 from H.J. Lu  ---
Fixed for GCC 10.

[Bug target/94541] [8/9/10 Regression] -mx32 gcc produces wrong code passing structs by value

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |hjl.tools at gmail dot 
com
   Last reconfirmed||2020-04-09
 Status|UNCONFIRMED |ASSIGNED
  Known to work||4.9.3
Summary|-mx32 gcc produces wrong|[8/9/10 Regression] -mx32
   |code passing structs by |gcc produces wrong code
   |value   |passing structs by value
 Ever confirmed|0   |1

--- Comment #3 from H.J. Lu  ---
[hjl@gnu-cfl-2 tmp]$ cat bar.c
typedef unsigned int size_t;
struct Array
{
  size_t length;
  void *ptr;
};
extern int munmap (void *__addr, size_t __len);

int
deallocate(struct Array b)
{
  int result = 0;
  if (b.length)
result = munmap(b.ptr, b.length);
  return result;
}
[hjl@gnu-cfl-2 tmp]$  gcc -S -O bar.c -mx32 
[hjl@gnu-cfl-2 tmp]$ cat bar.s
.file   "bar.c"
.text
.globl  deallocate
.type   deallocate, @function
deallocate:
.LFB0:
.cfi_startproc
movl$0, %eax
testl   %edi, %edi
jne .L8
ret
.L8:
subl$8, %esp
.cfi_def_cfa_offset 16
movq%rdi, %rsi   <<<<<< It should be movl %edi, %esi
shrq$32, %rdi
callmunmap
addl$8, %esp
.cfi_def_cfa_offset 8
ret
.cfi_endproc
.LFE0:
.size   deallocate, .-deallocate
.ident  "GCC: (GNU) 9.3.1 20200408 (Red Hat 9.3.1-2)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-cfl-2 tmp]$ 

GCC 4.9.3 works.

[Bug target/94541] [8/9/10 Regression] -mx32 gcc produces wrong code passing structs by value

[hjl.tools at gmail dot com]

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

--- Comment #6 from H.J. Lu  ---
It was caused by r5-901:

commit acea91c9012e211283130eb486d83243bcbbb327
Author: Martin Jambor 
Date:   Mon May 26 17:36:00 2014 +0200

ira.c (split_live_ranges_for_shrink_wrap): Remove bailout on subreg uses.

2014-05-26  Martin Jambor  

* ira.c (split_live_ranges_for_shrink_wrap): Remove bailout on
subreg uses.

From-SVN: r210936

[Bug target/94541] [8/9/10 Regression] -mx32 gcc produces wrong code passing structs by value

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

   Assignee|hjl.tools at gmail dot com |unassigned at gcc dot 
gnu.org
 Status|ASSIGNED|NEW

[Bug middle-end/94541] [8/9/10 Regression] -mx32 gcc produces wrong code passing structs by value

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

  Component|target  |middle-end

--- Comment #7 from H.J. Lu  ---
After 284r.ira:

(insn 12 11 13 3 (parallel [
(set (reg:DI 88)
(lshiftrt:DI (reg/v:DI 85 [ b ])
(const_int 32 [0x20])))
(clobber (reg:CC 17 flags))
]) "y.i":14:14 639 {*lshrdi3_1}
 (expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))
(insn 13 12 14 3 (set (reg:SI 4 si)
(subreg:SI (reg/v:DI 85 [ b ]) 0)) "y.i":14:14 67 {*movsi_internal}
 (expr_list:REG_DEAD (reg/v:DI 85 [ b ])
(nil)))
(insn 14 13 15 3 (set (reg:DI 5 di)
(reg:DI 88)) "y.i":14:14 66 {*movdi_internal}
 (expr_list:REG_DEAD (reg:DI 88)
(nil)))

After 285r.reload:

(insn 32 11 12 3 (set (reg:DI 5 di [88])
(reg/v:DI 4 si [orig:85 b ] [85])) "y.i":14:14 66 {*movdi_internal}
 (nil))
(insn 12 32 15 3 (parallel [
(set (reg:DI 5 di [88])
(lshiftrt:DI (reg:DI 5 di [88])
(const_int 32 [0x20])))
(clobber (reg:CC 17 flags))
]) "y.i":14:14 639 {*lshrdi3_1}
 (nil))

[Bug middle-end/94541] [8/9/10 Regression] -mx32 gcc produces wrong code passing structs by value

[hjl.tools at gmail dot com]

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

--- Comment #9 from H.J. Lu  ---
I am testing this:

diff --git a/gcc/lra-spills.c b/gcc/lra-spills.c
index 0caa4acd3b5..bd4ee80245d 100644
--- a/gcc/lra-spills.c
+++ b/gcc/lra-spills.c
@@ -844,9 +844,14 @@ lra_final_code_change (void)

  struct lra_static_insn_data *static_id = id->insn_static_data;
  bool insn_change_p = false;
+ set = single_set (insn);

+ /* NB: Never change SUBREG in the source operand of a SET
+insn to REG.  */
  for (i = id->insn_static_data->n_operands - 1; i >= 0; i--)
if ((DEBUG_INSN_P (insn) || ! static_id->operand[i].is_operator)
+   && (set == NULL
+   || !rtx_equal_p (SET_SRC (set), *id->operand_loc[i]))
&& alter_subregs (id->operand_loc[i], ! DEBUG_INSN_P (insn)))
  {
lra_update_dup (id, i);
@@ -855,7 +860,7 @@ lra_final_code_change (void)
  if (insn_change_p)
lra_update_operator_dups (id);

- if ((set = single_set (insn)) != NULL
+ if (set != NULL
  && REG_P (SET_SRC (set)) && REG_P (SET_DEST (set))
  && REGNO (SET_SRC (set)) == REGNO (SET_DEST (set)))
{

[Bug middle-end/94541] [8/9/10 Regression] -mx32 gcc produces wrong code passing structs by value

[hjl.tools at gmail dot com]

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

--- Comment #10 from H.J. Lu  ---
(In reply to Andrew Pinski from comment #8)
> (In reply to H.J. Lu from comment #7)
> > After 284r.ira:
> 
> That is fine according to the rules as long as TARGET_TRULY_NOOP_TRUNCATION 
> is true.

We can't turn

(insn 13 12 14 3 (set (reg:SI 4 si)
(subreg:SI (reg/v:DI 85 [ b ]) 0)) "y.i":14:14 67 {*movsi_internal}
 (expr_list:REG_DEAD (reg/v:DI 85 [ b ])
(nil)))

into


(insn 13 12 14 3 (set (reg:SI 4 si)
(reg:SI 4 si [orig:85 b ] [85])) "y.i":14:14 67 {*movsi_internal}
 (expr_list:REG_DEAD (reg/v:DI 4 si [orig:85 b ] [85])
(nil)))

This is simple wrong.

[Bug middle-end/94541] [8/9/10 Regression] -mx32 gcc produces wrong code passing structs by value

[hjl.tools at gmail dot com]

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

--- Comment #12 from H.J. Lu  ---
(In reply to Andrew Pinski from comment #11)
> (In reply to H.J. Lu from comment #10)
> > (In reply to Andrew Pinski from comment #8)
> > > (In reply to H.J. Lu from comment #7)
> > > > After 284r.ira:
> > > 
> > > That is fine according to the rules as long as 
> > > TARGET_TRULY_NOOP_TRUNCATION 
> > > is true.
> > 
> > We can't turn
> > 
> > (insn 13 12 14 3 (set (reg:SI 4 si)
> > (subreg:SI (reg/v:DI 85 [ b ]) 0)) "y.i":14:14 67 {*movsi_internal}
> >  (expr_list:REG_DEAD (reg/v:DI 85 [ b ])
> > (nil)))
> > 
> > into
> > 
> > 
> > (insn 13 12 14 3 (set (reg:SI 4 si)
> > (reg:SI 4 si [orig:85 b ] [85])) "y.i":14:14 67 {*movsi_internal}
> >  (expr_list:REG_DEAD (reg/v:DI 4 si [orig:85 b ] [85])
> > (nil)))
> > 
> > This is simple wrong.
> 
> How is that wrong?  What register was 85 assigned to?  4?
> Then is fully correct as TARGET_TRULY_NOOP_TRUNCATION is true for those
> sizes.  
> 
> On MIPS,  TARGET_TRULY_NOOP_TRUNCATION is false for SI/DI truncation.
> You need TARGET_TRULY_NOOP_TRUNCATION to be false for those sizes and you
> get a truncate RTL instead of the subreg.  subreg means the upper bits of
> the register are undefined.

In this case, upper bits in 85 are undefined:

(insn 13 12 14 3 (set (reg:SI 4 si)
(subreg:SI (reg/v:DI 4 si [orig:85 b ] [85]) 0)) "y.i":14:14 67
{*movsi_internal}
 (expr_list:REG_DEAD (reg/v:DI 4 si [orig:85 b ] [85])
(nil)))

LRA has:

 for (i = id->insn_static_data->n_operands - 1; i >= 0; i--)
if ((DEBUG_INSN_P (insn) || ! static_id->operand[i].is_operator)
&& alter_subregs (id->operand_loc[i], ! DEBUG_INSN_P (insn)))
  {
lra_update_dup (id, i);
insn_change_p = true;
  }
  if (insn_change_p)
lra_update_operator_dups (id);

  if ((set = single_set (insn)) != NULL
  && REG_P (SET_SRC (set)) && REG_P (SET_DEST (set))
  && REGNO (SET_SRC (set)) == REGNO (SET_DEST (set)))
{
  /* Remove an useless move insn.  IRA can generate move
 insns involving pseudos.  It is better remove them
 earlier to speed up compiler a bit.  It is also
 better to do it here as they might not pass final RTL
 check in LRA, (e.g. insn moving a control register
 into itself).  */
  lra_invalidate_insn_data (insn);
  delete_insn (insn);
}

But

(insn 13 12 14 3 (set (reg:SI 4 si)
(subreg:SI (reg/v:DI 4 si [orig:85 b ] [85]) 0)) "y.i":14:14 67
{*movsi_internal}
 (expr_list:REG_DEAD (reg/v:DI 4 si [orig:85 b ] [85])
(nil)))

isn't useless and shouldn't be removed.

[Bug target/94541] [8/9/10 Regression] -mx32 gcc produces wrong code passing structs by value

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|NEW |RESOLVED

--- Comment #14 from H.J. Lu  ---
It is an x32 kernel bug.  These system calls:

   int mprotect(void *addr, size_t len, int prot);
   void *mmap(void *addr, size_t length, int prot, int flags,
  int fd, off_t offset);
   int munmap(void *addr, size_t length);

take both void *, off_t and size_t.  They need special conversions
since they can't use LP64 nor IA32 versions.

[Bug target/94541] [8/9/10 Regression] -mx32 gcc produces wrong code passing structs by value

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

   See Also||https://bugzilla.kernel.org
   ||/show_bug.cgi?id=207187
 Resolution|INVALID |MOVED

[Bug target/94541] [8/9/10 Regression] -mx32 gcc produces wrong code passing structs by value

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

   See Also|https://bugzilla.kernel.org |https://sourceware.org/bugz
   |/show_bug.cgi?id=207187 |illa/show_bug.cgi?id=25810

--- Comment #15 from H.J. Lu  ---
I will fix it in glibc:

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

[Bug target/94556] New: [10 Regression] FAIL: nptl/tst-thread-exit-clobber

[hjl.tools at gmail dot com]

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

Bug ID: 94556
   Summary: [10 Regression] FAIL: nptl/tst-thread-exit-clobber
   Product: gcc
   Version: 10.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

On Linux/x32, GCC 10.0.1 20200324 caused

FAIL: nptl/tst-thread-exit-clobber

[hjl@gnu-cfl-2 build-x86_64-linux]$ nptl/tst-thread-exit-clobber --direct
info: unsigned int, direct pthread_exit call
info: double, direct pthread_exit call
error: tst-thread-exit-clobber.cc:119: not true: value ==
magic_values_double.v2
info: unsigned int, indirect pthread_exit call
info: double, indirect pthread_exit call
error: 1 test failures
[hjl@gnu-cfl-2 build-x86_64-linux]$ 

in tests on glibc master branch.  GCC 9.3 is OK.

[Bug target/94556] [10 Regression] FAIL: nptl/tst-thread-exit-clobber

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 CC||ubizjak at gmail dot com
   Target Milestone|--- |10.0
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-04-10

--- Comment #1 from H.J. Lu  ---
It is caused by r10-2846:

commit bc4aa158c9490e76573bee3eec90f893b7d0b1ae
Author: Uros Bizjak 
Date:   Wed Aug 28 17:09:51 2019 +0200

* config/i386/i386-features.c
(general_scalar_chain::compute_convert_gain):
Correct cost for double-word shifts.
(general_scalar_to_vector_candidate_p): Reject count operands
greater or equal to mode bitsize.

From-SVN: r274994

[Bug target/94556] [10 Regression] FAIL: nptl/tst-thread-exit-clobber

[hjl.tools at gmail dot com]

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

--- Comment #2 from H.J. Lu  ---
(In reply to H.J. Lu from comment #1)
> It is caused by r10-2846:
> 
> commit bc4aa158c9490e76573bee3eec90f893b7d0b1ae
> Author: Uros Bizjak 
> Date:   Wed Aug 28 17:09:51 2019 +0200
> 
> * config/i386/i386-features.c
> (general_scalar_chain::compute_convert_gain):
> Correct cost for double-word shifts.
> (general_scalar_to_vector_candidate_p): Reject count operands
> greater or equal to mode bitsize.
> 
> From-SVN: r274994

This isn't the real cause.  The bug is somewhere else.

[Bug target/94556] [10 Regression] FAIL: nptl/tst-thread-exit-clobber

[hjl.tools at gmail dot com]

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

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

[hjl@gnu-cfl-2 tmp]$ /usr/gcc-9.3.1-x32/bin/g++ -mx32 -O2 foo.cc -lpthread
[hjl@gnu-cfl-2 tmp]$ ./a.out 
info: double, direct pthread_exit call
[hjl@gnu-cfl-2 tmp]$ /usr/gcc-10.0.1-x32/bin/g++ -mx32 -O2 foo.cc -lpthread
[hjl@gnu-cfl-2 tmp]$ ./a.out 
info: double, direct pthread_exit call
Aborted (core dumped)
[hjl@gnu-cfl-2 tmp]$ 

CFI may be incorrect.

[Bug target/94556] [10 Regression] FAIL: nptl/tst-thread-exit-clobber

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Depends on||83641

--- Comment #4 from H.J. Lu  ---
This is related to PR 83641.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83641
[Bug 83641] -fstack-clash-protection generates incorrect CFI on i386

[Bug target/94561] [10 Regression] ICE in ix86_get_ssemov

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2020-April/5
   ||43746.html
   Keywords||patch

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

https://gcc.gnu.org/pipermail/gcc-patches/2020-April/543746.html

[Bug target/94556] [10 Regression] FAIL: nptl/tst-thread-exit-clobber

[hjl.tools at gmail dot com]

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

--- Comment #5 from H.J. Lu  ---
The code looks like:

vmovq   %xmm2, %r15
vmovq   %xmm3, %rbp
.LEHB0:
callpthread_exit
.LEHE0:
.L15:
movl%eax, %ebx
.L14:
vmovq   %rbp, %xmm0
movl$4, %edi
vzeroupper
call_Z11check_magicid

101 vmovq   %xmm3, %rbp
(gdb) next
103 callpthread_exit
(gdb) p/x $rbp
$3 = 0x3f853f3c88fc5280
(gdb) next
106 movl%eax, %ebx
(gdb) p/x $rbp
$4 = 0x88fc5280  < Only lower 32-bits are restored.
(gdb)

[Bug target/94556] [10 Regression] FAIL: nptl/tst-thread-exit-clobber

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |hjl.tools at gmail dot 
com

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

I am testing this.

[Bug d/94609] New: FAIL: gdc.dg/runnable.d

[hjl.tools at gmail dot com]

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

Bug ID: 94609
   Summary: FAIL: gdc.dg/runnable.d
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---
Target: x86-64

On Linux/x32, I got

FAIL: gdc.dg/runnable.d   -O0  execution test
FAIL: gdc.dg/runnable.d   -O1  execution test
FAIL: gdc.dg/runnable.d   -O2  execution test
FAIL: gdc.dg/runnable.d   -O3  execution test
FAIL: gdc.dg/runnable.d   -Os  execution test
FAIL: gdc.dg/runnable.d   -O0 -g  execution test
FAIL: gdc.dg/runnable.d   -O1 -g  execution test
FAIL: gdc.dg/runnable.d   -O2 -g  execution test
FAIL: gdc.dg/runnable.d   -O3 -g  execution test
FAIL: gdc.dg/runnable.d   -Os -g  execution test

[hjl@gnu-cfl-2 gdc]$ ./runnable.exe
1.00
2.00
3.00
Construct: this=0xffcc2100
Check: this=0xffcc2100 a=0xffcc2100
Check: this=0xffcc2140 a=0xffcc2100
core.exception.AssertError@/export/gnu/import/git/gitlab/x86-gcc/gcc/testsuite/gdc.dg/runnable.d(547):
Assertion failure

/export/gnu/import/git/gitlab/x86-gcc/libphobos/libdruntime/core/exception.d:441
onAssertError [0x47401c]
/export/gnu/import/git/gitlab/x86-gcc/gcc/testsuite/gdc.dg/runnable.d:547 void
runnable.test52() [0x407aa2]
/export/gnu/import/git/gitlab/x86-gcc/gcc/testsuite/gdc.dg/runnable.d:1596
_Dmain [0x40622e]
[hjl@gnu-cfl-2 gdc]$ 

Starting program:
/export/build/gnu/tools-build/gcc-x32-d-gitlab-debug/build-x86_64-linux/gcc/testsuite/gdc/runnable.exe
 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[New Thread 0xf7b6b940 (LWP 987423)]
[New Thread 0xf736a940 (LWP 987424)]
[New Thread 0xf67ff940 (LWP 987425)]
[New Thread 0xf5ffe940 (LWP 987426)]
[New Thread 0xf55ff940 (LWP 987427)]
[New Thread 0xf4dfe940 (LWP 987428)]
[New Thread 0xf41ff940 (LWP 987429)]
1.00
2.00
3.00
Construct: this=0xca80
Check: this=0xca80 a=0xca80

Thread 1 "runnable.exe" hit Breakpoint 2, runnable.C52.check() (
this=0xca80)
at
/export/gnu/import/git/gitlab/x86-gcc/gcc/testsuite/gdc.dg/runnable.d:518
518 return this is a;
(gdb) disass
Dump of assembler code for function _D8runnable3C525checkMFZb:
   0x004077fc <+0>: push   %rbp
   0x004077fd <+1>: mov%esp,%ebp
   0x004077ff <+3>: sub$0x10,%esp
   0x00407802 <+6>: mov%rdi,%rdx
   0x00407805 <+9>: mov%edx,-0x4(%ebp)
   0x00407809 <+13>:cmpl   $0x0,-0x4(%ebp)
   0x0040780e <+18>:setne  %dl
   0x00407811 <+21>:movzbl %dl,%edx
   0x00407814 <+24>:test   %edx,%edx
   0x00407816 <+26>:je 0x407826 <_D8runnable3C525checkMFZb+42>
   0x00407818 <+28>:mov-0x4(%ebp),%eax
   0x0040781c <+32>:mov%rax,%rdi
   0x0040781f <+35>:callq  0x474910 <_D9invariant12_d_invariantFC6ObjectZv>
   0x00407824 <+40>:jmp0x40787e <_D8runnable3C525checkMFZb+130>
   0x00407826 <+42>:movabs $0x,%rdx
   0x00407830 <+52>:and%rcx,%rdx
   0x00407833 <+55>:or $0x45,%rdx
   0x00407837 <+59>:mov%rdx,%rcx
   0x0040783a <+62>:mov$0x4be030,%edx
   0x0040783f <+67>:mov%edx,%edx
   0x00407841 <+69>:shl$0x20,%rdx
   0x00407845 <+73>:mov%ecx,%ecx
   0x00407847 <+75>:or %rcx,%rdx
   0x0040784a <+78>:mov%rdx,%rcx
   0x0040784d <+81>:movabs $0x,%rdx
   0x00407857 <+91>:and%rdx,%rax
   0x0040785a <+94>:or $0x9,%rax
   0x0040785e <+98>:mov$0x4be075,%edx
   0x00407863 <+103>:   mov%edx,%edx
   0x00407865 <+105>:   shl$0x20,%rdx
   0x00407869 <+109>:   mov%eax,%eax
   0x0040786b <+111>:   or %rdx,%rax
   0x0040786e <+114>:   mov$0x203,%edx
   0x00407873 <+119>:   mov%rcx,%rsi
   0x00407876 <+122>:   mov%rax,%rdi
   0x00407879 <+125>:   callq  0x474450 <_d_assert_msg>
   0x0040787e <+130>:   mov-0x4(%ebp),%eax
   0x00407882 <+134>:   mov0x8(%eax),%eax
   0x00407886 <+138>:   mov%eax,%edx
   0x00407888 <+140>:   mov-0x4(%ebp),%eax
   0x0040788c <+144>:   mov$0x4be228,%ecx
   0x00407891 <+149>:   mov%ecx,%ecx
   0x00407893 <+151>:   mov%rax,%rsi
   0x00407896 <+154>:   mov%rcx,%rdi
   0x00407899 <+157>:   mov$0x0,%eax
   0x0040789e <+162>:   callq  0x4025e0 
=> 0x004078a3 <+167>:   mov-0x4(%ebp),%eax
   0x004078a7 <+171>:   mov0x8(%eax),%eax
   0x004078ab <+175>:   cmp%eax,-0x4(%ebp)
--Type  for more, q to quit, c to 

[Bug d/94609] FAIL: gdc.dg/runnable.d

[hjl.tools at gmail dot com]

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

--- Comment #2 from H.J. Lu  ---
LP64 has:

(gdb) disass _D8runnable6test52FZv
Dump of assembler code for function _D8runnable6test52FZv:
   0x0040943a <+0>: push   %rbp
   0x0040943b <+1>: mov%rsp,%rbp
   0x0040943e <+4>: push   %r13
   0x00409440 <+6>: push   %r12
   0x00409442 <+8>: push   %rbx
   0x00409443 <+9>: sub$0x28,%rsp
   0x00409447 <+13>:lea-0x40(%rbp),%rax
   0x0040944b <+17>:mov%rax,%rdi
   0x0040944e <+20>:callq  0x409326
<_D8runnable7test52aFZS8runnable7test52aFZ6Scoped>

The argument is passed in RDI.  But x32 has

Dump of assembler code for function _D8runnable6test52FZv:
   0x00407a33 <+0>: push   %rbp
   0x00407a34 <+1>: mov%esp,%ebp
   0x00407a36 <+3>: push   %rbx
   0x00407a37 <+4>: sub$0x18,%esp
   0x00407a3a <+7>: callq  0x4078f0
<_D8runnable7test52aFZS8runnable7test52aFZ6Scoped>

RDI/EDI isn't used to pass argument.  Is this done on purpose?  Where does
D frontend decide how to pass argument?

[Bug d/94609] FAIL: gdc.dg/runnable.d

[hjl.tools at gmail dot com]

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

--- Comment #6 from H.J. Lu  ---
(In reply to Iain Buclaw from comment #5)
> The struct is built as a POD type.  As the struct is nested, it should be
> considered non-POD, otherwise it gets left up to aggregate_value_p to decide
> how to pass it around.
> 
> i386 returns true from aggregate_value_p because flag_pcc_struct_return=1.
> 
> x86_64 returns true from aggregate_value_p because
> targetm.calls.return_in_memory returns true.
> 
> x32 returns false from aggregate_value_p because the halved size makes it
> small enough to pass around in registers.

Does x32 return it in a single 64-bit register?

[Bug d/94609] FAIL: gdc.dg/runnable.d

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2020-04-15

--- Comment #9 from H.J. Lu  ---
(In reply to Iain Buclaw from comment #7)
>
> However the front-end for some time now has implemented an isPOD method that
> recursively checks all fields too.  It would be better to use this instead.
> 
> --- a/gcc/d/types.cc
> +++ b/gcc/d/types.cc
> @@ -915,7 +915,7 @@ public:
>  /* For structs with a user defined postblit or a destructor,
> also set TREE_ADDRESSABLE on the type and all variants.
> This will make the struct be passed around by reference.  */
> -if (t->sym->postblit || t->sym->dtor)
> +if (!t->sym->isPOD ())
>{
> for (tree tv = t->ctype; tv != NULL_TREE; tv = TYPE_NEXT_VARIANT
> (tv))
>   TREE_ADDRESSABLE (tv) = 1;
> 
> 
> 
> The test itself now passes with the above, but going to rebuild the library
> and run it on the wider testsuite.

I tested with glibc 2.30 with fix for

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

I got

FAIL: libphobos.phobos_shared/std/algorithm/mutation.d execution test
FAIL: libphobos.phobos_shared/std/algorithm/mutation.d execution test
FAIL: libphobos.phobos_shared/std/algorithm/mutation.d execution test
FAIL: libphobos.phobos_shared/std/conv.d execution test
FAIL: libphobos.phobos_shared/std/conv.d execution test
FAIL: libphobos.phobos_shared/std/conv.d execution test
FAIL: libphobos.phobos_shared/std/datetime/systime.d execution test
FAIL: libphobos.phobos_shared/std/datetime/systime.d execution test
FAIL: libphobos.phobos_shared/std/datetime/systime.d execution test
FAIL: libphobos.phobos_shared/std/range/primitives.d (test for excess errors)
FAIL: libphobos.phobos/std/algorithm/mutation.d execution test
FAIL: libphobos.phobos/std/algorithm/mutation.d execution test
FAIL: libphobos.phobos/std/algorithm/mutation.d execution test
FAIL: libphobos.phobos/std/conv.d execution test
FAIL: libphobos.phobos/std/conv.d execution test
FAIL: libphobos.phobos/std/conv.d execution test
FAIL: libphobos.phobos/std/datetime/systime.d execution test
FAIL: libphobos.phobos/std/datetime/systime.d execution test
FAIL: libphobos.phobos/std/datetime/systime.d execution test
FAIL: libphobos.phobos/std/range/primitives.d (test for excess errors)

with

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

[Bug d/94609] FAIL: gdc.dg/runnable.d

[hjl.tools at gmail dot com]

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

--- Comment #10 from H.J. Lu  ---
core.exception.RangeError@/export/gnu/import/git/gitlab/x86-gcc/libphobos/testsuite/../src/std/algorithm/mutation.d(1518):
Range violation

/export/gnu/import/git/gitlab/x86-gcc/libphobos/libdruntime/core/exception.d:496
onRangeError [0x4cc45e]
/export/gnu/import/git/gitlab/x86-gcc/libphobos/testsuite/../src/std/algorithm/mutation.d:1518
void std.algorithm.mutation.__unittestL1506_44() [0x412314]
/export/users/hjl/build/gnu/tools-build/gcc-x32-d-gitlab/build-x86_64-linux/x86_64-pc-linux-gnu/libphobos/testsuite/libphobos6/:1
void std.algorithm.mutation.__modtest() [0x41f109]
/export/gnu/import/git/gitlab/x86-gcc/libphobos/libdruntime/core/runtime.d:561
__foreachbody2 [0x4daae7]
/export/gnu/import/git/gitlab/x86-gcc/libphobos/libdruntime/rt/minfo.d:777
__foreachbody2 [0x4d2998]
/export/gnu/import/git/gitlab/x86-gcc/libphobos/libdruntime/gcc/sections/elf_shared.d:109
int gcc.sections.elf_shared.DSO.opApply(scope int delegate(ref
gcc.sections.elf_shared.DSO)) [0x4c8161]
/export/gnu/import/git/gitlab/x86-gcc/libphobos/libdruntime/rt/minfo.d:770 int
rt.minfo.moduleinfos_apply(scope int delegate(immutable(object.ModuleInfo*)))
[0x4d3f8b]
/export/gnu/import/git/gitlab/x86-gcc/libphobos/libdruntime/object.d:1598 int
object.ModuleInfo.opApply(scope int delegate(object.ModuleInfo*)) [0x4d83ab]
/export/gnu/import/git/gitlab/x86-gcc/libphobos/libdruntime/core/runtime.d:551
runModuleUnitTests [0x4dadd1]
/export/gnu/import/git/gitlab/x86-gcc/libphobos/libdruntime/rt/dmain2.d:496
runAll [0x4c7b14]
/export/gnu/import/git/gitlab/x86-gcc/libphobos/libdruntime/rt/dmain2.d:472
tryExec [0x4c7cb1]
/export/gnu/import/git/gitlab/x86-gcc/libphobos/libdruntime/rt/dmain2.d:505
_d_run_main [0x4c7cb1]
/export/ssd/git/gitlab/x86-gcc/libphobos/libdruntime/__entrypoint.di:44 main
[0x41f21a]
??:? __libc_start_main [0x7fc7d0ab4162]
??:? _start [0x409e6d]
??:? ???[0x]
FAIL: libphobos.phobos/std/algorithm/mutation.d execution test

std.conv.ConvException@/export/gnu/import/git/gitlab/x86-gcc/libphobos/testsuite/../src/std/conv.d(2018):
Can't parse string: bool should be case-insensitive 'true' or 'false'

/export/gnu/import/git/gitlab/x86-gcc/libphobos/testsuite/../src/std/conv.d:2018
pure @safe bool std.conv.parse!(bool,
std.conv.__unittestL2029_55().InputString).parse(ref
std.conv.__unittestL2029_55().InputString) [0x80a0677]
/export/gnu/import/git/gitlab/x86-gcc/libphobos/testsuite/../src/std/conv.d:2044
@safe void std.conv.__unittestL2029_55() [0x8079203]
/export/users/hjl/build/gnu/tools-build/gcc-x32-d-gitlab/build-x86_64-linux/x86_64-pc-linux-gnu/libphobos/testsuite/libphobos4/:1
void std.conv.__modtest() [0x80911d2]
/export/gnu/import/git/gitlab/x86-gcc/libphobos/libdruntime/core/runtime.d:561
__foreachbody2 [0x820380b]
/export/gnu/import/git/gitlab/x86-gcc/libphobos/libdruntime/rt/minfo.d:777
__foreachbody2 [0x81fa3a0]
/export/gnu/import/git/gitlab/x86-gcc/libphobos/libdruntime/gcc/sections/elf_shared.d:109
int gcc.sections.elf_shared.DSO.opApply(scope int delegate(ref
gcc.sections.elf_shared.DSO)) [0x81edb07]
/export/gnu/import/git/gitlab/x86-gcc/libphobos/libdruntime/rt/minfo.d:770 int
rt.minfo.moduleinfos_apply(scope int delegate(immutable(object.ModuleInfo*)))
[0x81fbc0e]
/export/gnu/import/git/gitlab/x86-gcc/libphobos/libdruntime/object.d:1598 int
object.ModuleInfo.opApply(scope int delegate(object.ModuleInfo*)) [0x8200a3e]
/export/gnu/import/git/gitlab/x86-gcc/libphobos/libdruntime/core/runtime.d:551
runModuleUnitTests [0x8203bef]
/export/gnu/import/git/gitlab/x86-gcc/libphobos/libdruntime/rt/dmain2.d:496
runAll [0x81ed4d4]
/export/gnu/import/git/gitlab/x86-gcc/libphobos/libdruntime/rt/dmain2.d:472
tryExec [0x81ed6af]
/export/gnu/import/git/gitlab/x86-gcc/libphobos/libdruntime/rt/dmain2.d:505
_d_run_main [0x81ed6af]
/export/ssd/git/gitlab/x86-gcc/libphobos/libdruntime/__entrypoint.di:44 main
[0x80914c1]
??:? __libc_start_main [0xf7c0cfa8]
??:? _start [0x8052475]
??:? ???[0x]
FAIL: libphobos.phobos/std/conv.d execution test

core.exception.RangeError@/export/ssd/git/gitlab/x86-gcc/libphobos/src/std/algorithm/iteration.d(637):
Range violation

/export/gnu/import/git/gitlab/x86-gcc/libphobos/libdruntime/core/exception.d:496
onRangeError [0x8220bb9]
/export/gnu/import/git/gitlab/x86-gcc/libphobos/libdruntime/core/exception.d:672
_d_arraybounds [0x82211ff]
/export/ssd/git/gitlab/x86-gcc/libphobos/src/std/algorithm/iteration.d:637 pure
nothrow @nogc @safe
std.algorithm.iteration.MapResult!(std.datetime.systime.__unittestL9645_129().__funcliteral5(immutable(char)[]).__lambda2,
immutable(ubyte)[]).MapResult
std.algorithm.iteration.MapResult!(std.datetime.systime.__unittestL9645_129().__funcliteral5(immutable(char)[]).__lambda2,
immutable(ubyte)[]).MapResult.opSlice(uint, uint) [0x8187146]
/export/gnu/import/git/gitlab/x86-gcc/libphobos/testsuite/../src/std/datetime/systime.d:9568

[Bug target/94417] -fcf-protection -mcmodel=large/-mforce-indirect-call is broken

[hjl.tools at gmail dot com]

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

--- Comment #8 from H.J. Lu  ---
Fixed for GCC 10, GCC 9.4 and GCC 8.5.

[Bug target/94556] FAIL: nptl/tst-thread-exit-clobber

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #11 from H.J. Lu  ---
Fixed for GCC 10, GCC 9.4 and GCC 8.5.

[Bug target/94736] New: Missing ENDBR at label

[hjl.tools at gmail dot com]

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

Bug ID: 94736
   Summary: Missing ENDBR at label
   Product: gcc
   Version: 10.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
  Target Milestone: ---
Target: i386,x86-64

[hjl@gnu-cfl-2 gcc]$ cat /tmp/foo.c
#include 

typedef void *(*func_t) (void);

void *p;

void
__attribute__ ((noclone, noinline))
foo (int a)
{
  switch (a)
{
case 0:
a0:
  return;
case 1:
a1:
  p = &&a1;
case 2:
a2:
  p = &&a2;
case 3:
a3:
  p = &&a3;
case 4:
a4:
  p = &&a4;
case 5:
a5:
  p = &&a5;
case 6:
a6:
  p = &&a6;
case 7:
a7:
  p = &&a7;
case 8:
a8:
  p = &&a8;
case 9:
a9:
  p = &&a9;
case 10:
a10:
  p = &&a10;
default:
  p = &&a0;
}
  goto *p;
}

int
main ()
{
  foo (20);
  if (p == NULL)
abort ();
  ((func_t) p) ();
  return 0;
}
[hjl@gnu-cfl-2 gcc]$ ./xgcc -B./ -S -O2  -fcf-protection /tmp/foo.c
[hjl@gnu-cfl-2 gcc]$ cat foo.s
.file   "foo.c"
.text
.p2align 4
.globl  foo
.type   foo, @function
foo:
.LFB11:
.cfi_startproc
endbr64
testl   %edi, %edi
je  .L1
.L3:
endbr64
.L4:
.L5:
.L6:
.L7:
.L8:
.L9:
.L10:
.L11:
.L12:
movq$.L2, p(%rip)
.L2:
.L1: <<<<<<<< Missing ENDBR
ret
.cfi_endproc
.LFE11:
.size   foo, .-foo
.section.text.unlikely,"ax",@progbits
.LCOLDB0:
.section.text.startup,"ax",@progbits
.LHOTB0:
.p2align 4
.globl  main
.type   main, @function
main:
.LFB12:
.cfi_startproc
endbr64
subq$8, %rsp
.cfi_def_cfa_offset 16
movl$20, %edi
callfoo
movqp(%rip), %rax
testq   %rax, %rax
je  .L19
call*%rax
xorl%eax, %eax
addq$8, %rsp
.cfi_def_cfa_offset 8
ret
.cfi_endproc
.section.text.unlikely
.cfi_startproc
.type   main.cold, @function
main.cold:
.LFSB12:
.L19:
.cfi_def_cfa_offset 16
callabort
.cfi_endproc
.LFE12:
.section.text.startup
.size   main, .-main
.section.text.unlikely
.size   main.cold, .-main.cold
.LCOLDE0:
.section.text.startup
.LHOTE0:
.globl  p
.bss
.align 8
.type   p, @object
.size   p, 8
p:
.zero   8
.ident  "GCC: (GNU) 10.0.1 20200422 (experimental)"
.section.note.GNU-stack,"",@progbits
.section.note.gnu.property,"a"
.align 8
.long1f - 0f
.long4f - 1f
.long5
0:
.string  "GNU"
1:
.align 8
.long0xc002
.long3f - 2f
2:
.long0x3
3:
.align 8
4:
[hjl@gnu-cfl-2 gcc]$

[Bug bootstrap/94739] New: GCC won't build on CET enabled Linux OS

[hjl.tools at gmail dot com]

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

Bug ID: 94739
   Summary: GCC won't build on CET enabled Linux OS
   Product: gcc
   Version: 10.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: ---

[hjl@gnu-tgl-1 build-x86_64-linux]$ readelf -n /bin/ld 2>&1|more

Displaying notes found in: .note.gnu.property
  OwnerData sizeDescription
  GNU  0x0030   NT_GNU_PROPERTY_TYPE_0
  Properties: x86 feature: IBT, SHSTK
x86 ISA used: CMOV, SSE, SSE2
x86 feature used: x86, XMM

and I got

build-x86_64-linux/./gcc/liblto_plugin.so: indirect branch tracking isn't
enabled: Invalid argument
collect2: error: ld returned 1 exit status
make[7]: *** [Makefile:994: libgcc_s.so] Error 1

Since ld is CET enabled, dlopen failed on liblto_plugin.so since it isn't CET
enabled.  On CET enabled Linux OS, we need to always enable CET on
liblto_plugin.so.

[Bug libstdc++/94744] New: [9 Regression] FAIL: experimental/net/executor/1.cc (test for excess errors)

[hjl.tools at gmail dot com]

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

Bug ID: 94744
   Summary: [9 Regression] FAIL: experimental/net/executor/1.cc
(test for excess errors)
   Product: gcc
   Version: 9.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---

On Fedora 31, r9-8540 gave

Executing on host:
/export/gnu/import/git/gcc-test-release-1-ia32/bld/./gcc/xg++ -shared-libgcc
-B/export/gnu/import/git/gcc-test-release-1-ia32/bld/./gcc -nostdinc++
-L/export/gnu/import/git/gcc-test-release-1-ia32/bld/i686-linux/libstdc++-v3/src
-L/export/gnu/import/git/gcc-test-release-1-ia32/bld/i686-linux/libstdc++-v3/src/.libs
-L/export/gnu/import/git/gcc-test-release-1-ia32/bld/i686-linux/libstdc++-v3/libsupc++/.libs
-B/usr/9.3.1/i686-linux/bin/ -B/usr/9.3.1/i686-linux/lib/ -isystem
/usr/9.3.1/i686-linux/include -isystem /usr/9.3.1/i686-linux/sys-include
-fchecking=1
-B/export/gnu/import/git/gcc-test-release-1-ia32/bld/i686-linux/./libstdc++-v3/src/.libs
-fmessage-length=0 -fno-show-column -ffunction-sections -fdata-sections
-fcf-protection -mshstk -g -O2 -D_GNU_SOURCE -DLOCALEDIR="." -nostdinc++
-I/export/gnu/import/git/gcc-test-release-1-ia32/bld/i686-linux/libstdc++-v3/include/i686-linux
-I/export/gnu/import/git/gcc-test-release-1-ia32/bld/i686-linux/libstdc++-v3/include
-I/export/gnu/import/git/gcc-test-release-1-ia32/src-9/libstdc++-v3/libsupc++
-I/export/gnu/import/git/gcc-test-release-1-ia32/src-9/libstdc++-v3/include/backward
-I/export/gnu/import/git/gcc-test-release-1-ia32/src-9/libstdc++-v3/testsuite/util
/export/gnu/import/git/gcc-test-release-1-ia32/src-9/libstdc++-v3/testsuite/experimental/net/executor/1.cc
-include bits/stdc++.h -fno-diagnostics-show-caret
-fdiagnostics-color=never ./libtestc++.a -Wl,--gc-sections
-L/export/gnu/import/git/gcc-test-release-1-ia32/bld/i686-linux/libstdc++-v3/src/filesystem/.libs
 -lm  -o ./1.exe(timeout = 600)
spawn -ignore SIGHUP
/export/gnu/import/git/gcc-test-release-1-ia32/bld/./gcc/xg++ -shared-libgcc
-B/export/gnu/import/git/gcc-test-release-1-ia32/bld/./gcc -nostdinc++
-L/export/gnu/import/git/gcc-test-release-1-ia32/bld/i686-linux/libstdc++-v3/src
-L/export/gnu/import/git/gcc-test-release-1-ia32/bld/i686-linux/libstdc++-v3/src/.libs
-L/export/gnu/import/git/gcc-test-release-1-ia32/bld/i686-linux/libstdc++-v3/libsupc++/.libs
-B/usr/9.3.1/i686-linux/bin/ -B/usr/9.3.1/i686-linux/lib/ -isystem
/usr/9.3.1/i686-linux/include -isystem /usr/9.3.1/i686-linux/sys-include
-fchecking=1
-B/export/gnu/import/git/gcc-test-release-1-ia32/bld/i686-linux/./libstdc++-v3/src/.libs
-fmessage-length=0 -fno-show-column -ffunction-sections -fdata-sections
-fcf-protection -mshstk -g -O2 -D_GNU_SOURCE -DLOCALEDIR="." -nostdinc++
-I/export/gnu/import/git/gcc-test-release-1-ia32/bld/i686-linux/libstdc++-v3/include/i686-linux
-I/export/gnu/import/git/gcc-test-release-1-ia32/bld/i686-linux/libstdc++-v3/include
-I/export/gnu/import/git/gcc-test-release-1-ia32/src-9/libstdc++-v3/libsupc++
-I/export/gnu/import/git/gcc-test-release-1-ia32/src-9/libstdc++-v3/include/backward
-I/export/gnu/import/git/gcc-test-release-1-ia32/src-9/libstdc++-v3/testsuite/util
/export/gnu/import/git/gcc-test-release-1-ia32/src-9/libstdc++-v3/testsuite/experimental/net/executor/1.cc
-include bits/stdc++.h -fno-diagnostics-show-caret -fdiagnostics-color=never
./libtestc++.a -Wl,--gc-sections
-L/export/gnu/import/git/gcc-test-release-1-ia32/bld/i686-linux/libstdc++-v3/src/filesystem/.libs
-lm -o ./1.exe
In file included from
/export/gnu/import/git/gcc-test-release-1-ia32/src-9/libstdc++-v3/testsuite/experimental/net/executor/1.cc:20:
/export/gnu/import/git/gcc-test-release-1-ia32/bld/i686-linux/libstdc++-v3/include/experimental/executor:
In instantiation of '_Executor* std::experimental::net::v1::executor::target()
[with _Executor = test02()::E]':
/export/gnu/import/git/gcc-test-release-1-ia32/src-9/libstdc++-v3/testsuite/experimental/net/executor/1.cc:71:
  required from here
/export/gnu/import/git/gcc-test-release-1-ia32/bld/i686-linux/libstdc++-v3/include/experimental/executor:1112:
error: no matching function for call to 'test02()::E::E(const void*&)'
/export/gnu/import/git/gcc-test-release-1-ia32/src-9/libstdc++-v3/testsuite/experimental/net/executor/1.cc:45:
note: candidate: 'constexpr test02()::E::E(const test02()::E&)'
/export/gnu/import/git/gcc-test-release-1-ia32/src-9/libstdc++-v3/testsuite/experimental/net/executor/1.cc:45:
note:   no known conversion for argument 1 from 'const void*' to 'const
test02()::E&'
/export/gnu/import/git/gcc-test-release-1-ia32/src-9/libstdc++-v3/testsuite/experimental/net/executor/1.cc:45:
note: candidate: 'constexpr test02()::E::E(test02()::E&&)'
/export/g

[Bug bootstrap/94739] GCC won't build on CET enabled Linux OS

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

   Last reconfirmed||2020-04-24
   Keywords||patch
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2020-April/5
   ||44535.html

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

https://gcc.gnu.org/pipermail/gcc-patches/2020-April/544535.html

[Bug bootstrap/94739] GCC won't build on CET enabled Linux OS

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #3 from H.J. Lu  ---
Fixed for GCC 10.

[Bug jit/94778] New: All jit tests failed with multilib

[hjl.tools at gmail dot com]

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

Bug ID: 94778
   Summary: All jit tests failed with multilib
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: jit
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---

On Linux/x86-64, all jit tests failed with

$ make check RUNTESTFLAGS="--target_board='unix{-m32,}'"
...
spawn -ignore SIGHUP
/export/users/hjl/build/gnu/tools-build/gcc-x32-d-gitlab/build-x86_64-linux/gcc/xgcc
-B/export/users/hjl/build/gnu/tools-build/gcc-x32-d-gitlab/build-x86_64-linux/gcc/
/export/gnu/import/git/gitlab/x86-gcc/gcc/testsuite/jit.dg/test-error-get-type-bad-enum.c
-m32 -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -fdiagnostics-urls=never
-I/export/gnu/import/git/gitlab/x86-gcc/gcc/testsuite/../jit -lgccjit -g -Wall
-Werror -Wl,--export-dynamic -fgnu89-inline -lm -o
test-error-get-type-bad-enum.c.exe
/usr/local/bin/ld: skipping incompatible
/export/users/hjl/build/gnu/tools-build/gcc-x32-d-gitlab/build-x86_64-linux/gcc/libgccjit.so
when searching for -lgccjit
/usr/local/bin/ld: cannot find -lgccjit
/usr/local/bin/ld: skipping incompatible
/export/users/hjl/build/gnu/tools-build/gcc-x32-d-gitlab/build-x86_64-linux/gcc/libgccjit.so
when searching for -lgccjit
collect2: error: ld returned 1 exit status
compiler exited with status 1
FAIL: jit.dg/test-error-get-type-bad-enum.c, initial compilation

[Bug bootstrap/94739] GCC won't build on CET enabled Linux OS

[hjl.tools at gmail dot com]

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

--- Comment #5 from H.J. Lu  ---
(In reply to Manfred Schwarb from comment #4)
> This broke my i686 build (only, x86_64 build with same settings is OK), I get
> 
> configure: error: Intel CET must be enabled on Intel CET enabled host
> make[2]: *** [configure-stage2-lto-plugin] Error 1
> make[2]: *** Waiting for unfinished jobs
> configure: error: Intel CET must be enabled on Intel CET enabled host
> make[2]: *** [configure-stage2-libiberty] Error 1

Please show me libiberty/config.log which leads to

configure: error: Intel CET must be enabled on Intel CET enabled host

> 
> both in prev-libiberty/config.log and prev-lto-plugin/config.log there is
> 
> configure:5283: checking for CET support
> configure:5312: gcc -march=i686 -m32 -Wa,--32 -c -g -fcf-protection 
> conftest.c >&5
> gcc: error: unrecognized command line option '-fcf-protection'

[Bug bootstrap/94739] GCC won't build on CET enabled Linux OS

[hjl.tools at gmail dot com]

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

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

Please try this.

[Bug bootstrap/94739] GCC won't build on CET enabled Linux OS

[hjl.tools at gmail dot com]

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

--- Comment #10 from H.J. Lu  ---
(In reply to Manfred Schwarb from comment #9)
> Patch seems to work so far. Do you need any logfiles?

No need for it.

[Bug bootstrap/94739] GCC won't build on CET enabled Linux OS

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

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

[Bug target/93654] Inappropriate "-fcf-protection and -mindirect-branch=thunk are incompatible on x86_64" restriction

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com

--- Comment #2 from H.J. Lu  ---
Created attachment 48394
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48394&action=edit
A proposal to support retpoline and CET

[Bug target/93654] Inappropriate "-fcf-protection and -mindirect-branch=thunk are incompatible on x86_64" restriction

[hjl.tools at gmail dot com]

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

--- Comment #3 from H.J. Lu  ---
Please DO disable -fcf-protection in the kernel build.  We are enabling
CET for the user space first.   The kernel CET will be the next.

I am enclosing a proposal to make -fcf-protection compatible with retpoline.
It targets user space.  It can be made compatible with kernel.

[Bug target/93654] Inappropriate "-fcf-protection and -mindirect-branch=thunk are incompatible on x86_64" restriction

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2020-04-28
   Assignee|unassigned at gcc dot gnu.org  |hjl.tools at gmail dot 
com

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

Please try this.

[Bug target/93654] Inappropriate "-fcf-protection and -mindirect-branch=thunk are incompatible on x86_64" restriction

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

  Attachment #48396|0   |1
is obsolete||

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

I am testing this.

[Bug target/93654] Inappropriate "-fcf-protection and -mindirect-branch=thunk are incompatible on x86_64" restriction

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

   Target Milestone|--- |10.0
URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2020-April/5
   ||44804.html
   Keywords||patch

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

https://gcc.gnu.org/pipermail/gcc-patches/2020-April/544804.html

[Bug target/93654] [9/10 Regression] Inappropriate "-fcf-protection and -mindirect-branch=thunk-extern are incompatible" restriction

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

   Target Milestone|10.0|9.4
Summary|Inappropriate   |[9/10 Regression]
   |"-fcf-protection and|Inappropriate
   |-mindirect-branch=thunk are |"-fcf-protection and
   |incompatible on x86_64" |-mindirect-branch=thunk-ext
   |restriction |ern are incompatible"
   ||restriction
 Status|NEW |RESOLVED
 Target|x86_64-*-*  |i386, x86_64
 Resolution|--- |FIXED

--- Comment #12 from H.J. Lu  ---
Fixed for GCC 10 and GCC 9.4.

[Bug testsuite/84324] objc/execute/exceptions/matcher-1.m:27:10: warning: return with a value, in function returning void

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

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

[Bug target/94118] Undocumented inline assembly [target] operand modifiers

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-05-07

--- Comment #3 from H.J. Lu  ---
(In reply to Hongtao.liu from comment #2)
> Do you mean create a page like *Operand Modifiers for Particular Machines*
> and move the section 6.47.2.8 x86 Operand Modifiers to the page?

We need to update

gcc/doc/extend.texi:@subsubsection x86 Operand Modifiers

to document all x86 operand modifiers.

[Bug target/94118] Undocumented inline assembly [target] operand modifiers

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||craig.topper at gmail dot com

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

[Bug target/94977] Some X86 inline assembly modifiers are not documented in the web documentation

[hjl.tools at gmail dot com]

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

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 94118 ***

[Bug middle-end/94988] New: [11 Regression] FAIL: gcc.target/i386/pr64110.c scan-assembler vmovd[\\t ]

[hjl.tools at gmail dot com]

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

Bug ID: 94988
   Summary: [11 Regression] FAIL: gcc.target/i386/pr64110.c
scan-assembler vmovd[\\t ]
   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: rguenther at suse dot de
  Target Milestone: ---

commit 283cb9ea6293e813e48a1b769e1e0779918ea20a (r11-161)

Author: Richard Biener 
Date:   Mon Apr 27 14:45:54 2020 +0200

tree-optimization/57359 - rewrite SM code

This rewrites store-motion to process candidates where we can
ensure order preserving separately and with no need to disambiguate
against all stores.  Those candidates we cannot handle this way
are validated to be independent on all stores (w/o TBAA) and then
processed as "unordered" (all conditionally executed stores are so
as well).

This will necessary cause
  FAIL: gcc.dg/graphite/pr80906.c scan-tree-dump graphite "isl AST to
Gimple succeeded"
because the SM previously performed is not valid for exactly the PR57359
reason, we still perform SM of qc for the innermost loop but that's not
enough.

There is still room for improvements because we still check some
constraints
for the order preserving cases that are only necessary in the current
strict way for the unordered ones.  Leaving that for the furture.

caused:

FAIL: gcc.target/i386/pr64110.c scan-assembler vmovd[\\t ]

[Bug target/94998] GCC 10 won't configure for host=x86, build!=host, linker=bfd due to CET

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

   Target Milestone|--- |10.2
   Last reconfirmed||2020-05-08
 Ever confirmed|0   |1
 Status|UNCONFIRMED |WAITING
   Assignee|unassigned at gcc dot gnu.org  |hjl.tools at gmail dot 
com

[Bug bootstrap/94998] GCC 10 won't configure for host=x86, build!=host, linker=bfd due to CET

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

   Keywords||patch
URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2020-May/545
   ||392.html

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

https://gcc.gnu.org/pipermail/gcc-patches/2020-May/545392.html

[Bug testsuite/95008] [11 regression] excess errors in gcc.dg/analyzer/pr93382.c and gcc.dg/two-types-6.c after r11-169

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com
   Last reconfirmed||2020-05-08
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Target Milestone|--- |11.0

[Bug jit/94778] All jit tests failed with multilib

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

   Target Milestone|--- |11.0
 Ever confirmed|0   |1
   Last reconfirmed||2020-05-08
   Keywords||patch
 Status|UNCONFIRMED |NEW
URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2020-May/545
   ||425.html

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

https://gcc.gnu.org/pipermail/gcc-patches/2020-May/545425.html

[Bug middle-end/95021] New: [10/11 Regression] Bogus -Wclobbered warning

[hjl.tools at gmail dot com]

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

Bug ID: 95021
   Summary: [10/11 Regression] Bogus -Wclobbered warning
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---

On Linux/x86-64, GCC 10 and 11 give

[hjl@gnu-skx-1 creduce-1]$ cat foo.i
typedef long long a;
struct __jmp_buf_tag   {
};
typedef struct __jmp_buf_tag sigjmp_buf[1];
sigjmp_buf jmp_buf;
int __sigsetjmp (sigjmp_buf, int);
typedef struct {
  a target;
} b;
extern a *target_p;
b *c;
extern void e (a);
void
d(void)
{
  if (__sigsetjmp(jmp_buf, 1)) {
a target = *target_p;
c->target = target;
e(target);
  }
}
[hjl@gnu-skx-1 creduce-1]$ /usr/gcc-10.1.1-x32/bin/gcc -m32 -O2 -W foo.i -S
foo.i: In function ??d??:
foo.i:17:7: warning: variable ??target?? might be clobbered by ??longjmp?? or
??vfork?? [-Wclobbered]
   17 | a target = *target_p;
  |   ^~
[hjl@gnu-skx-1 creduce-1]$ 

GCC 9.3 is OK.

[Bug middle-end/95021] [10/11 Regression] Bogus -Wclobbered warning

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 CC||rguenther at suse dot de
   Last reconfirmed||2020-05-09
   Target Milestone|--- |10.2
 Ever confirmed|0   |1

--- Comment #1 from H.J. Lu  ---
Need -msse2 to trigger the bug.  This caused by r10-2807:

commit 48a31a09839b12127ce7c40d7adc4bd5bf1d3407
Author: Richard Biener 
Date:   Mon Aug 26 10:35:59 2019 +

re PR target/91522 (STV is slow)

2019-08-26  Richard Biener  

PR target/91522
PR target/91527
* config/i386/i386-features.h (general_scalar_chain::defs_map):
New member.
(general_scalar_chain::replace_with_subreg): Remove.
(general_scalar_chain::replace_with_subreg_in_insn): Likewise.
(general_scalar_chain::convert_reg): Adjust signature.
* config/i386/i386-features.c (scalar_chain::add_insn): Do not
iterate over all defs of a reg.
(general_scalar_chain::replace_with_subreg): Remove.
(general_scalar_chain::replace_with_subreg_in_insn): Likewise.
(general_scalar_chain::make_vector_copies): Populate defs_map,
place copy only after defs that are used as vectors in the chain.
(general_scalar_chain::convert_reg): Emit a copy for a specific
def in a specific instruction.
(general_scalar_chain::convert_op): All reg uses are converted
here.
(general_scalar_chain::convert_insn): Emit copies for scalar
uses of defs here.  Replace uses with the copies we created.
Replace and convert the def.  Adjust REG_DEAD notes, remove
REG_EQUIV/EQUAL notes.
(general_scalar_chain::convert_registers): Only handle copies
into the chain here.

[Bug middle-end/95021] [10/11 Regression] Bogus -Wclobbered warning

[hjl.tools at gmail dot com]

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

--- Comment #2 from H.J. Lu  ---
271r.ce2 dump has

;; bb 0 artificial_defs: { d2(0){ }d5(1){ }d8(2){ }d9(6){ }d17(7){ }d34(16){
}d44(19){ }d47(20){ }d50(21){ }d53(22){ }d66(28){ }d69(29){ }d72(30){ }}
;; bb 0 artificial_uses: { }
;; lr  in85
;; lr  use
;; lr  def   0 [ax] 1 [dx] 2 [cx] 6 [bp] 7 [sp] 16 [argp] 19 [frame] 20
[xmm0] 21 [xmm1] 22 [xmm2] 28 [mm0] 29 [mm1] 30 [mm2]
;; live  in 
;; live  gen 0 [ax] 1 [dx] 2 [cx] 6 [bp] 7 [sp] 16 [argp] 19 [frame] 20
[xmm0] 21 [xmm1] 22 [xmm2] 28 [mm0] 29 [mm1] 30 [mm2]
;; live  kill
;; lr  out   6 [bp] 7 [sp] 16 [argp] 19 [frame] 85
;; live  out 6 [bp] 7 [sp] 16 [argp] 19 [frame]
...
;; bb 2 artificial_defs: { }
;; bb 2 artificial_uses: { u0(6){ }u1(7){ }u2(16){ }u3(19){ }}
;; lr  in6 [bp] 7 [sp] 16 [argp] 19 [frame] 85
;; lr  use   6 [bp] 7 [sp] 16 [argp] 19 [frame]
;; lr  def   0 [ax] 1 [dx] 2 [cx] 7 [sp] 8 [st] 9 [st(1)] 10 [st(2)] 11
[st(3)] 12 [st(4)] 13 [st(5)] 14 [st(6)] 15 [st(7)] 17 [flags] 18 [fpsr] 20
[xmm0] 21 [xmm1] 22 [xmm2] 23 [xmm3] 24 [xmm4] 25 [xmm5] 26 [xmm6] 27 [xmm7] 28
[mm0] 29 [mm1] 30 [mm2] 31 [mm3] 32 [mm4] 33 [mm5] 34 [mm6] 35 [mm7] 36 [r8] 37
[r9] 38 [r10] 39 [r11] 40 [r12] 41 [r13] 42 [r14] 43 [r15] 44 [xmm8] 45 [xmm9]
46 [xmm10] 47 [xmm11] 48 [xmm12] 49 [xmm13] 50 [xmm14] 51 [xmm15] 52 [xmm16] 53
[xmm17] 54 [xmm18] 55 [xmm19] 56 [xmm20] 57 [xmm21] 58 [xmm22] 59 [xmm23] 60
[xmm24] 61 [xmm25] 62 [xmm26] 63 [xmm27] 64 [xmm28] 65 [xmm29] 66 [xmm30] 67
[xmm31] 68 [k0] 69 [k1] 70 [k2] 71 [k3] 72 [k4] 73 [k5] 74 [k6] 75 [k7] 88
;; live  in  6 [bp] 7 [sp] 16 [argp] 19 [frame]
;; live  gen 0 [ax] 7 [sp] 17 [flags] 88
;; live  kill17 [flags]
;; lr  out   6 [bp] 7 [sp] 16 [argp] 19 [frame] 85
;; live  out 6 [bp] 7 [sp] 16 [argp] 19 [frame]

Since IRA has

 /* DF_LIVE can't be used in the register allocator, too many other
 parts of the compiler depend on using the "classic" liveness
 interpretation of the DF_LR problem.  See PR38711.
 Remove the problem, so that we don't spend time updating it in
 any of the df_analyze() calls during IRA/LRA.  */
  if (optimize > 1) 
df_remove_problem (df_live);
  gcc_checking_assert (df_live == NULL);

setjmp_vars_warning uses DF_LR info and gets the wrong result.

Why is DF_LR info so way off? Reg 85 isn't live at function entry
nor at BB 2 exit.

[Bug middle-end/95021] [10/11 Regression] Bogus -Wclobbered warning

[hjl.tools at gmail dot com]

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

--- Comment #4 from H.J. Lu  ---
The problem is since df_lr_bb_local_compute has

   /* If the def is to only part of the reg, it does
   not kill the other defs that reach here.  */
if (!(DF_REF_FLAGS (def) & (DF_REF_PARTIAL | DF_REF_CONDITIONAL)))
  {
unsigned int dregno = DF_REF_REGNO (def);
bitmap_set_bit (&bb_info->def, dregno);
bitmap_clear_bit (&bb_info->use, dregno);
  }

it doesn't consider

(insn 40 39 25 3 (set (subreg:SI (reg/v:DI 85 [ target ]) 4)
(subreg:SI (reg:V2DI 90) 0)) "x.i":17:7 -1
 (nil))

as a def.

[Bug target/95076] Failure to tail-call on function call of different return type

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

   Last reconfirmed||2020-05-12
   Target Milestone|--- |11.0
 Status|UNCONFIRMED |NEW
 CC||crazylht at gmail dot com
 Ever confirmed|0   |1

[Bug target/95076] Failure to tail-call on function call of different return type

[hjl.tools at gmail dot com]

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

--- Comment #2 from H.J. Lu  ---
(In reply to Richard Biener from comment #1)
> GCC doesn't tail-call because the return types are not compatible.  With a
> call
> it cannot optimize the stack adjustment because of the ABI.
> 
> Note I'm not sure whether the ABI allows %rax to contain "garbage" in the
> upper half for a function returning in %eax.  So what LLVM does may be wrong.

Don't upper bits of %rax in GCC generate code also contain garbage?

[Bug target/95076] Failure to tail-call on function call of different return type

[hjl.tools at gmail dot com]

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

--- Comment #3 from H.J. Lu  ---
This ia32 psABI return value discussion also applies here:

https://groups.google.com/forum/#!searchin/ia32-abi/return$20value%7Csort:date/ia32-abi/9H4BBrIdkmk/sjWw06ZPnS4J

[Bug middle-end/95021] [10/11 Regression] Bogus -Wclobbered warning

[hjl.tools at gmail dot com]

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

--- Comment #5 from H.J. Lu  ---
STV generates:

8d b6 00 00 00 00   lea0x0(%esi),%esi
a1 00 00 00 00  mov0x0,%eax R_386_32target_p
83 ec 08sub$0x8,%esp
f3 0f 7e 00 movq   (%eax),%xmm0
a1 00 00 00 00  mov0x0,%eax R_386_32c
66 0f 6f c8 movdqa %xmm0,%xmm1
66 0f 7e 44 24 10   movd   %xmm0,0x10(%esp)
66 0f 73 d1 20  psrlq  $0x20,%xmm1
66 0f d6 00 movq   %xmm0,(%eax)
66 0f 7e 4c 24 14   movd   %xmm1,0x14(%esp)
ff 74 24 14 pushl  0x14(%esp)
ff 74 24 14 pushl  0x14(%esp)
e8 fc ff ff ff  callR_386_PC32  e

instead of

8d b6 00 00 00 00   lea0x0(%esi),%esi
a1 00 00 00 00  mov0x0,%eax R_386_32target_p
8b 0d 00 00 00 00   mov0x0,%ecx R_386_32c
83 ec 08sub$0x8,%esp
8b 50 04mov0x4(%eax),%edx
8b 00   mov(%eax),%eax
89 51 04mov%edx,0x4(%ecx)
89 01   mov%eax,(%ecx)
52  push   %edx
50  push   %eax
e8 fc ff ff ff  callR_386_PC32  e

It is hard to tell if vector is faster.

[Bug bootstrap/94998] GCC 10 won't configure for host=x86, build!=host, linker=bfd due to CET

[hjl.tools at gmail dot com]

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

--- Comment #6 from H.J. Lu  ---
Fixed on master branch so far.

[Bug middle-end/95021] [10/11 Regression] Bogus -Wclobbered warning

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||ubizjak at gmail dot com
URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2020-May/545
   ||630.html
   Keywords||patch

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

https://gcc.gnu.org/pipermail/gcc-patches/2020-May/545630.html

[Bug target/94118] Undocumented inline assembly [target] operand modifiers

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

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

[Bug middle-end/95021] [10/11 Regression] Bogus -Wclobbered warning

[hjl.tools at gmail dot com]

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

--- Comment #8 from H.J. Lu  ---
(In reply to rguent...@suse.de from comment #6)
> On Tue, 12 May 2020, hjl.tools at gmail dot com wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95021
> > 
> > --- Comment #4 from H.J. Lu  ---
> > The problem is since df_lr_bb_local_compute has
> > 
> >/* If the def is to only part of the reg, it does
> >not kill the other defs that reach here.  */
> > if (!(DF_REF_FLAGS (def) & (DF_REF_PARTIAL | DF_REF_CONDITIONAL)))
> >   {
> > unsigned int dregno = DF_REF_REGNO (def);
> > bitmap_set_bit (&bb_info->def, dregno);
> > bitmap_clear_bit (&bb_info->use, dregno);
> >   }
> > 
> > it doesn't consider
> > 
> > (insn 40 39 25 3 (set (subreg:SI (reg/v:DI 85 [ target ]) 4)
> > (subreg:SI (reg:V2DI 90) 0)) "x.i":17:7 -1
> >  (nil))
> > 
> > as a def.
> 
> Which it isn't since it sets the upper half of reg:DI 85 only.

True.  But it is clearly incorrect that reg:DI 85 is live at function
entrance.