https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120494
H.J. Lu changed:
What|Removed |Added
Last reconfirmed||2025-05-30
Status|UNCONFIRMED
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
Target Milestone: ---
There are
/* Return the CALL in X if there is one. */
rtx
get_call_rtx_from (const rtx_insn *insn)
{
rtx x = PATTERN (insn);
if (GET_CODE (x) == PARALLEL
: other
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
Target Milestone: ---
/* Get the declaration of the function called by INSN. */
tree
get_call_fndecl (const rtx_insn *insn)
{
rtx note, datum;
note = find_reg_note (insn, REG_CALL_DECL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120427
--- Comment #2 from H.J. Lu ---
Another issue with the commit:
+;; With -Oz, transform mov $imm,reg to the shorter push $imm; pop reg.
+(define_peephole2
+ [(set (match_operand:SWI248 0 "general_reg_operand")
+ (match_operand:SWI248 1 "const_
y: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
CC: liuhongt at gcc dot gnu.org, ubizjak at gmail dot com
Target Milestone: ---
[hjl@gnu-zen4-1 pr117839]$ cat dl-3.c
struct __pthread_mutex_s
{
int __lock;
unsigne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120426
--- Comment #3 from H.J. Lu ---
(In reply to Andrew Pinski from comment #2)
> With -mtune=sapphirerapids we get:
>
>[local count: 1073741824]:
> MEM [(union *)lock_2(D)] = 0;
> MEM [(union *)lock_2(D) + 8B] = 0;
> MEM [(union *)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120427
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
ty: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
CC: liuhongt at gcc dot gnu.org, roger at nextmovesoftware dot
com,
ubizjak at gmail dot com
Target
ignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
CC: liuhongt at gcc dot gnu.org
Target Milestone: ---
Target: x86-64
[hjl@gnu-zen4-1 pr117839]$ cat dl-1.c
struct __pthread_mutex_s
{
int __lock;
unsigned int __count;
int __
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110180
H.J. Lu changed:
What|Removed |Added
Target Milestone|--- |16.0
Version|unknown
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110180
H.J. Lu changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
Target Milestone: ---
When building GCC on Fedora 42, I got many
grep: warning: egrep is obsolescent; using grep -E
++
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
Target Milestone: ---
Target: x32
I got
FAIL: g++.dg/coroutines/torture/pr119916.C -O0 execution test
FAIL: g++.dg/coroutines/torture/pr119916.C -O1 execution test
FAIL: g++.dg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120252
H.J. Lu changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120252
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120252
--- Comment #1 from H.J. Lu ---
Created attachment 61415
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61415&action=edit
A patch
ormal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
Target Milestone: ---
-fpatchable-function-entry doesn't work with -ffunction-sections since
a single __patchable_function_entries section i
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
CC: hubicka at ucw dot cz, liuhongt at gcc dot gnu.org,
ubizjak at gmail dot com
Target Milestone: ---
Target: x86-64
On x86-64, I got
FAIL
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
CC: hubicka at ucw dot cz, liuhongt at gcc dot gnu.org,
ubizjak at gmail dot com
Target Milestone
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
CC: liuhongt at gcc dot gnu.org
Target Milestone: ---
Target: x86-64
i386 backend has codes like
set_insn = emit_insn_before (set, insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120217
H.J. Lu changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120217
--- Comment #1 from H.J. Lu ---
Never mind. It was caused by my local changes.
: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
Target Milestone: ---
Target: x86-64
On x86-64, r16-520-ga3f5aac402a7ef gave
spawn -ignore SIGHUP
/export/build/gnu/tools-build
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
Target Milestone: ---
Target: x86-64
On x86-64, r16-517-g993aa0bd28722c gave:
FAIL: gcc.target/i386/pr78794.c scan-assembler pandn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92080
H.J. Lu changed:
What|Removed |Added
Attachment #61392|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120207
H.J. Lu changed:
What|Removed |Added
Ever confirmed|1 |0
Component|middle-end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92080
H.J. Lu changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |hjl.tools at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92080
H.J. Lu changed:
What|Removed |Added
Target Milestone|--- |16.0
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
Target Milestone: ---
rtl.h has
extern void print_rtl_single_with_indent (FILE *, const_rtx, int);
But it isn't defined. It looks like an over
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120201
H.J. Lu changed:
What|Removed |Added
Component|target |sanitizer
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120167
H.J. Lu changed:
What|Removed |Added
Summary|[16 Regression] FAIL: |[16 Regression] FAIL:
|libg
Priority: P3
Component: libgomp
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
CC: jakub at gcc dot gnu.org
Target Milestone: ---
On x86-64, I got
FAIL: libgomp.graphite/force-parallel-1.c scan-tree-dump-times graphite &q
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120036
H.J. Lu changed:
What|Removed |Added
Status|ASSIGNED|WAITING
--- Comment #8 from H.J. Lu ---
Plea
: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
CC: liuhongt at gcc dot gnu.org
Target Milestone: ---
On x86-64, I got
FAIL: g++.dg/coroutines/torture
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
CC: liuhongt at gcc dot gnu.org
Target Milestone: ---
On x86-64, I got
FAIL: gcc.dg/vla-1.c scan-tr
: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
CC: liuhongt at gcc dot gnu.org
Target Milestone: ---
On x86-64, I got
FAIL: gcc.dg/vect/pr101145.c scan-tree-dump-times vect "vectorized 1 loops" 7
FAIL: g
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
CC: liuhongt at gcc dot gnu.org
Target Milestone: ---
Target: i386
On x86-64, -m32 gave
FAIL: gcc.target/i386/pr119919.c scan-tree-dump vect "loop vectorized using 8
byte vectors"
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
CC: liuhongt at gcc dot gnu.org
Target Milestone: ---
Target: i386
On x86-64, -m32 gave:
FAIL: gcc.target/i386/avx512bw-pr103750-2.c scan-assembler-not kmov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120036
H.J. Lu changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |hjl.tools at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119985
H.J. Lu changed:
What|Removed |Added
Target Milestone|--- |16.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117547
H.J. Lu changed:
What|Removed |Added
Status|NEW |RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117839
H.J. Lu changed:
What|Removed |Added
Target Milestone|--- |16.0
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117547
--- Comment #6 from H.J. Lu ---
We have
[hjl@gnu-tgl-3 pr117547]$ cat x.c
#include
__mmask64
foo (__mmask64 d)
{
d = __builtin_ia32_kshiftridi (d, 0xff);
return d;
}
[hjl@gnu-tgl-3 pr117547]$ make
/export/build/gnu/tools-build/gcc-gitlab-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119979
--- Comment #6 from H.J. Lu ---
We need to make sure that incoming argument isn't promoted by
TARGET_PROMOTE_FUNCTION_MODE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119979
--- Comment #5 from H.J. Lu ---
(In reply to Jeffrey A. Law from comment #3)
> sh4eb is showing similar failures
Is this the same issue:
static machine_mode
sh_promote_function_mode (const_tree type, machine_mode mode,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119979
H.J. Lu changed:
What|Removed |Added
Last reconfirmed||2025-04-28
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119979
--- Comment #4 from H.J. Lu ---
Created attachment 61231
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61231&action=edit
A patch
Please try this. I suspect that all targets using
default_promote_function_mode_always_promote are broken.
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
Target Milestone: ---
target.def has
If @code{TARGET_PROMOTE_FUNCTION_RETURN} returns true, you must apply\n\
the same promotion rules specified in @code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119982
H.J. Lu changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
: 16.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: ---
On x86-64, r16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117863
H.J. Lu changed:
What|Removed |Added
Target Milestone|--- |15.0
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119784
H.J. Lu changed:
What|Removed |Added
Target Milestone|--- |14.3
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119628
--- Comment #13 from H.J. Lu ---
(In reply to Ken Jin from comment #9)
> I tried this out with CPython's interpreter that uses tail calls with the
> patch at
> https://gitlab.com/x86-gcc/gcc/-/tree/users/hjl/saved/master?ref_type=heads
> applied
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119628
H.J. Lu changed:
What|Removed |Added
Attachment #61120|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119628
--- Comment #11 from H.J. Lu ---
(In reply to Ken Jin from comment #9)
> I tried this out with CPython's interpreter that uses tail calls with the
> patch at
> https://gitlab.com/x86-gcc/gcc/-/tree/users/hjl/saved/master?ref_type=heads
> applied
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119628
--- Comment #8 from H.J. Lu ---
Created attachment 61120
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61120&action=edit
A tested patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119628
H.J. Lu changed:
What|Removed |Added
Attachment #61093|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119784
--- Comment #1 from H.J. Lu ---
Created attachment 61098
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61098&action=edit
A patch
I am testing this.
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
CC: liuhongt at gcc dot gnu.org
Target Milestone: ---
Target: x86-64
[hjl@gnu-tgl-3 pr119628]$ cat x1.c
#define DONT_SAVE_REGS __attribute__((no_callee_saved_registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119628
--- Comment #6 from H.J. Lu ---
no_caller_saved_registers only works with XMM and ZMM, not YMM, since YMM load
will clear the upper 256 bits of ZMM.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119628
H.J. Lu changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |hjl.tools at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119628
H.J. Lu changed:
What|Removed |Added
Last reconfirmed||2025-04-09
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119628
--- Comment #3 from H.J. Lu ---
(In reply to ak from comment #2)
> The existing attributes could just handle this case?
Caller needs to know what registers are saved by callee. But caller doesn't
know what ISAs are used by callee.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119628
--- Comment #1 from H.J. Lu ---
no_calle(e|r)_saved_registers=gpr(16|32)?
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
CC: liuhongt at gcc dot gnu.org
Target Milestone: ---
Target: x86-64
On x86-64, r15-9029-geb26b667518c95 gave
FAIL
: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
CC: haochen.jiang at intel dot com, liuhongt at gcc dot gnu.org
Target Milestone: ---
Target: x86-64
On x86-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #13 from H.J. Lu ---
(In reply to Michael Matz from comment #11)
> access to the respective GOT slot). Upstream binutils now silently do emit a
> route via PLT, our binutils complain. I'm not sure that upstream behaviour
> is
> i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
H.J. Lu changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117069
--- Comment #10 from H.J. Lu ---
(In reply to Hongtao Liu from comment #8)
> (In reply to Hongtao Liu from comment #6)
> > It looks like the testcase is fragile, it's supposed to check the compiler
> > ability of generating code_6_gottpoff_reloc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117069
--- Comment #11 from H.J. Lu ---
(In reply to H.J. Lu from comment #10)
> (In reply to Hongtao Liu from comment #8)
> > (In reply to Hongtao Liu from comment #6)
> > > It looks like the testcase is fragile, it's supposed to check the compiler
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119299
--- Comment #3 from H.J. Lu ---
(In reply to AK from comment #0)
...
> https://godbolt.org/z/3xh6Mxq4j
FYI,
https://gitlab.com/x86-gcc/gcc/-/tree/users/hjl/condjmp/gcc-16?ref_type=heads
generates:
.globl g1
.type g1, @func
ormal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
Target Milestone: ---
[hjl@gnu-tgl-3 gcc]$ cat /tmp/y.c
typedef char vec_t __attribute__((vector_size(16)));
extern void func1(vec_t);
extern void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119294
--- Comment #5 from H.J. Lu ---
CSE turns
(insn 18 16 19 2 (set (mem/c:V16QI (plus:DI (reg/f:DI 19 frame)
(const_int -16 [0xfff0])) [0 MEM
[(void *)&x]+0 S16 A128])
(subreg:V16QI (reg:V4SI 111) 0)) "x.c":11:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119297
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Component|middle-end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119171
H.J. Lu changed:
What|Removed |Added
Resolution|INVALID |FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119171
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
Target Milestone: ---
On x86-64, r15-7900-g622968990beee7 gave:
[hjl@gnu-tgl-3 pr119083]$ cat x.i
long
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119142
--- Comment #8 from H.J. Lu ---
Created attachment 60673
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60673&action=edit
A patch
I am testing this with
if (GENERAL_REGNO_P (hard_regno))
{
/* push is 1 byte while typical spil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119142
--- Comment #7 from H.J. Lu ---
Something like
diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc
index 661e71b032c..8e599bb22fc 100644
--- a/gcc/config/i386/i386.cc
+++ b/gcc/config/i386/i386.cc
@@ -20613,11 +20613,10 @@ ix86_calle
|NEW
CC||hjl.tools at gmail dot com
Ever confirmed|0 |1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119083
--- Comment #8 from H.J. Lu ---
Created attachment 60647
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60647&action=edit
A patch to remove CREG and BREG from ix86_class_likely_spilled_p
Hongtao, can you measure its impact on SPEC CPU 201
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119083
--- Comment #6 from H.J. Lu ---
(In reply to H.J. Lu from comment #4)
> (In reply to Uroš Bizjak from comment #1)
> > SSE_FIRST_REG is in ic86_class_likely_spilled_p because it is a
> > single-member class. It is there because of SSE4 pcmpistrm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118996
--- Comment #15 from H.J. Lu ---
(In reply to Hongtao Liu from comment #14)
> (In reply to H.J. Lu from comment #13)
> > (In reply to H.J. Lu from comment #11)
> > > Created attachment 60609 [details]
> > > An untested patch
> >
> > Hongtao, do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118996
--- Comment #13 from H.J. Lu ---
(In reply to H.J. Lu from comment #11)
> Created attachment 60609 [details]
> An untested patch
Hongtao, do you have SPEC CPU2017 data on this patch?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119083
H.J. Lu changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119083
--- Comment #3 from H.J. Lu ---
Created attachment 60640
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60640&action=edit
A patch to remove SSE_FIRST_REG from ix86_class_likely_spilled_p
Hongtao, can you measure its impact on SPEC CPU2017
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
CC: liuhongt at gcc dot gnu.org
Target Milestone: ---
Target: x86
SSE_FIRST_REG was added to CLASS_LIKELY_SPILLED_P, which became
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118996
--- Comment #12 from H.J. Lu ---
(In reply to H.J. Lu from comment #11)
> Created attachment 60609 [details]
> An untested patch
Tested on x86-64 with RUNTESTFLAGS="--target_board='unix{-m32,}'".
There are no regressions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118996
H.J. Lu changed:
What|Removed |Added
Attachment #60607|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118996
--- Comment #9 from H.J. Lu ---
(In reply to H.J. Lu from comment #8)
> Created attachment 60607 [details]
> A patch
>
> Here is the patch to change TARGET_SMALL_REGISTER_CLASSES_FOR_MODE_P to
> return false for x86-64.
This doesn't work:
/ex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118996
--- Comment #10 from H.J. Lu ---
Testing this:
diff --git a/gcc/ira.cc b/gcc/ira.cc
index 885239d1b43..e93a596e2a9 100644
--- a/gcc/ira.cc
+++ b/gcc/ira.cc
@@ -2158,6 +2158,10 @@ decrease_live_ranges_number (void)
|| (targetm.small_regis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118996
--- Comment #8 from H.J. Lu ---
Created attachment 60607
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60607&action=edit
A patch
Here is the patch to change TARGET_SMALL_REGISTER_CLASSES_FOR_MODE_P to
return false for x86-64.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118996
--- Comment #6 from H.J. Lu ---
SMALL_REGISTER_CLASSES was added by
commit c98f874233428d7e6ba83def7842fd703ac0ddf1
Author: James Van Artsdalen
Date: Sun Feb 9 13:28:48 1992 +
Initial revision
which became TARGET_SMALL_REGISTER_CLA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118992
H.J. Lu changed:
What|Removed |Added
Attachment #60590|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118992
--- Comment #14 from H.J. Lu ---
(In reply to Hongtao Liu from comment #13)
> (In reply to H.J. Lu from comment #11)
> > Created attachment 60590 [details]
> > A patch
> >
> > Can you try this on SPEC CPU?
>
> No big impact for both O2 and Ofa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118992
--- Comment #11 from H.J. Lu ---
Created attachment 60590
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60590&action=edit
A patch
Can you try this on SPEC CPU?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118992
--- Comment #10 from H.J. Lu ---
(In reply to Hongtao Liu from comment #9)
>
>
> Remove check of 2 hooks regressed
>
> gcc: gcc.target/i386/pr111673.c check-function-bodies advance
> unix/-m32: gcc: gcc.target/i386/pr49095.c scan-assembler-not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118992
--- Comment #8 from H.J. Lu ---
(In reply to Richard Biener from comment #7)
>
> >else if (targetm.small_register_classes_for_mode_p (GET_MODE (x)))
> > record = false;
> >else if (targetm.class_likely_spilled_p (REGNO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118996
H.J. Lu changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
CC: liuhongt at gcc dot gnu.org
Target Milestone: ---
Target: x86-64
i386 has
#define
1 - 100 of 2780 matches
Mail list logo
