https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118266
H.J. Lu changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118266
H.J. Lu changed:
What|Removed |Added
Attachment #60072|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118266
--- Comment #17 from H.J. Lu ---
Created attachment 60072
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60072&action=edit
A patch
Try this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118266
--- Comment #16 from H.J. Lu ---
ree turns:
(insn 27 26 139 2 (parallel [
(set (reg/f:SI 7 sp)
(plus:SI (reg/f:SI 7 sp)
(const_int 16 [0x10])))
(clobber (reg:CC 17 flags))
]) "
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118266
--- Comment #15 from H.J. Lu ---
ree generates:
(insn 155 27 139 2 (set (reg:DI 7 sp)
(reg:DI 6 bp)) "x.ii":14:17 discrim 1 -1
(nil))
It restores SP from BP.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118266
--- Comment #13 from H.J. Lu ---
(gdb) call debug_cfi_row (cur_row)
.cfi_def_cfa 7, 80
.cfi_offset 3, -56
.cfi_offset 6, -48
.cfi_offset 12, -40
.cfi_offset 13, -32
.cfi_offset 14, -24
.cfi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118266
--- Comment #11 from H.J. Lu ---
A smaller testcase:
---
void *xmalloc();
void free(void *);
typedef struct {
int a;
int b;
int c;
} mystruct;
int main_j;
int
main()
{
mystruct *m = (mystruct *)xmalloc(), *mref = m;
#pragma acc enter da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118266
H.J. Lu changed:
What|Removed |Added
Summary|[15 Regression] ICE in |[15 Regression] ICE in
|may
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118266
--- Comment #9 from H.J. Lu ---
Created attachment 60069
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60069&action=edit
A testcase
[hjl@gnu-tgl-3 gcc]$ ./xgcc -B./ -S -O2 -mx32 -fopenacc -foffload=disable
/tmp/x.ii
during RTL pass: dwar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118266
H.J. Lu changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #8 from H.J. Lu ---
Confirme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118288
H.J. Lu changed:
What|Removed |Added
Target Milestone|--- |15.0
--- Comment #6 from H.J. Lu ---
FWIW,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118266
--- Comment #7 from H.J. Lu ---
Please upload your auto-host.h.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118266
--- Comment #6 from H.J. Lu ---
I can't reproduce it with x86-64 gcc configured with
--enable-checking=release --enable-cet --with-demangler-in-ld
--prefix=/usr/gcc-15.0.0-x32 --with-local-prefix=/usr/local
--enable-gnu-indirect-function --enab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118266
--- Comment #5 from H.J. Lu ---
I am using binutils master branch with
commit 2b001c799977a97304311df238fe33daa9b8fa7f
Author: GDB Administrator
Date: Mon Dec 30 00:00:19 2024 +
Automatic date update in version.in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118266
--- Comment #4 from H.J. Lu ---
How can I reproduce it with x86-64 gcc? I tried x86-64 gcc configured with
--disable-bootstrap --enable-checking=release --enable-cet
--with-demangler-in-ld --prefix=/usr/gcc-15.0.0-x86-64
--with-local-prefix=/us
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118266
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Ever confirmed|0
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
CC: haochen.jiang at intel dot com
Target Milestone: ---
Target: x86-64
On x86-64 with binutils
commit 2b001c799977a97304311df238fe33daa9b8fa7f
Author: GDB
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48274
Bug 48274 depends on bug 117907, which changed state.
Bug 117907 Summary: Inconsistent usages of TARGET_PROMOTE_PROTOTYPES
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117907
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112877
H.J. Lu changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117907
H.J. Lu changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112877
Bug 112877 depends on bug 117907, which changed state.
Bug 117907 Summary: Inconsistent usages of TARGET_PROMOTE_PROTOTYPES
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117907
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117907
H.J. Lu changed:
What|Removed |Added
Blocks||48274, 112877
Status|UNCONFIRMED
: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
Target Milestone: ---
TARGET_PROMOTE_PROTOTYPES is an optimization hook, which promotes integer
arguments smaller than int to int if TARGET_PROMOTE_PROTOTYPES returns true.
Some frontends
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117901
H.J. Lu changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
Target Milestone: ---
Target: x86-64
$ cat vector_eq-2.c
/* { dg-do compile { target { i?86-*-* x86_64-*-* } } } */
/* { dg-additional-options "-O2 -march=x86-64-v3" } */
typedef int v4si __a
Product: gcc
Version: 15.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: ---
When Go is enabled, r15-5775
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117839
--- Comment #4 from H.J. Lu ---
Created attachment 59744
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59744&action=edit
Add a pass to remove redundant vector load
I am testing it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117839
H.J. Lu changed:
What|Removed |Added
Last reconfirmed||2024-11-29
Ever confirmed|0
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
Target Milestone: ---
Target: x86-64
[hjl@gnu-tgl-3 zero-1]$ cat z.c
#include
#include
float
clear_memory (void *mem, size_t clearsize)
{
/* Unroll clear memory size up to 9 * size_t bytes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117098
H.J. Lu changed:
What|Removed |Added
Status|NEW |RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117547
--- Comment #5 from H.J. Lu ---
Created attachment 59691
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59691&action=edit
A patch
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
Target Milestone: ---
Target: i686
On Linux/i686, r15-5477-gf5a87c8d8c6a8c gave
LC_ALL=C GCC_COLORS=
/export/build/gnu/tools-build/gcc-32bit/build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117547
H.J. Lu changed:
What|Removed |Added
Last reconfirmed||2024-11-13
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117547
--- Comment #3 from H.J. Lu ---
(In reply to Richard Biener from comment #2)
> I think the error is with const_0_to_255_operand which seems to operate
> without context of the mode a VOIDmode CONST_INT is need to be interpreted
> with. Alternat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117547
--- Comment #1 from H.J. Lu ---
Since const_0_to_255_operand returns false on (const_int -1
[0x]),
we need to get (const_int 255 [0xff]) from
co
nstant 255>
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, rguenth at gcc dot gnu.org,
uros at gcc dot gnu.org
Target Milestone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108357
H.J. Lu changed:
What|Removed |Added
Status|REOPENED|NEW
--- Comment #25 from H.J. Lu ---
One dif
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
Target Milestone: ---
If TARGET_PROMOTE_PROTOTYPES returns false or the C frontend doesn't promote
integer argument as implemented in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117300
H.J. Lu changed:
What|Removed |Added
Target Milestone|--- |15.0
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115568
--- Comment #5 from H.J. Lu ---
-mtune=haswell is impacted. -mtune=znver4 is OK.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115568
--- Comment #4 from H.J. Lu ---
(In reply to H.J. Lu from comment #3)
> This is a latent bug in the sched1 pass. This change
>
> diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
> index effab299349..c532f0596c7 100644
> --- a/gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115568
--- Comment #3 from H.J. Lu ---
This is a latent bug in the sched1 pass. This change
diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index effab299349..c532f0596c7 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117416
H.J. Lu changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117387
--- Comment #3 from H.J. Lu ---
Like this?
diff --git a/gcc/calls.cc b/gcc/calls.cc
index f67067acad4..1df064dcef6 100644
--- a/gcc/calls.cc
+++ b/gcc/calls.cc
@@ -2992,8 +2992,6 @@ expand_call (tree exp, rtx target, int ignore)
Normally,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117387
--- Comment #2 from H.J. Lu ---
(In reply to Andrew Pinski from comment #1)
> But then later on it does:
> /* Now possibly adjust the number of named args.
> Normally, don't include the last named arg if anonymous args follow.
> We do
-end
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
Target Milestone: ---
expand_call has
if (type_arg_types != 0)
n_named_args
= (list_length (type_arg_types)
/* Count the struct value address, if it is passed as a parm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14907
--- Comment #7 from H.J. Lu ---
Created attachment 59467
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59467&action=edit
A patch
I am testing this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117310
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14907
--- Comment #6 from H.J. Lu ---
*** Bug 117310 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14907
--- Comment #5 from H.J. Lu ---
(In reply to Nicholas Miell from comment #4)
> This also occurs on AMD64 without any special attributes (the ABI passes
> params in registers already).
>
> When compiling:
> extern char c2(char);
> char c1(char c)
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
CC: crazylht at gmail dot com
Target Milestone: ---
[hjl@gnu-tgl-3 tailcall-1]$ cat x.c
extern int baz (char c1);
int
foo (char c1)
{
return baz (c1);
}
[hjl@gnu-tgl-3 tailcall-1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117300
--- Comment #9 from H.J. Lu ---
Created attachment 59447
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59447&action=edit
A patch
This seems to work.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117301
--- Comment #2 from H.J. Lu ---
Since new AVX10.2 instructions are generated,
check_effective_target_avx10_2_512
doesn't cover them.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117301
H.J. Lu changed:
What|Removed |Added
Last reconfirmed||2024-10-26
CC|
: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
CC: haochen.jiang at intel dot com
Target Milestone: ---
Target: i386
r15-4407-g8b9b696c98def8
commit 8b9b696c98def874139effc0380929df4a4356f0
Author: Haochen Jiang
Date: Wed Oct 16 15
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
Target Milestone: ---
On Fedora 41, gdb defaults to use debuginfod. I got
Spawning: gdb -nx -nw -quiet -batch -x pr36728-2.gdb ./pr36728-2.exe
spawn gdb -nx -nw -quiet -batch -x pr36728-2.gdb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117098
--- Comment #3 from H.J. Lu ---
Created attachment 59328
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59328&action=edit
A patch
I am testing this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117098
H.J. Lu changed:
What|Removed |Added
Component|target |middle-end
--- Comment #2 from H.J. Lu ---
s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117098
H.J. Lu changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
arget
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
Target Milestone: ---
Target: x86-64
[hjl@gnu-tgl-3 tmp]$ cat x.c
struct A { int a[6]; void *p[7]; };
int baz (int a, int b, int c, void *p, struct A s);
int
foo (int a, int b, int c, vo
: 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 me:
FAIL: gcc.target/i386/pr63527.c scan-assembler-not movl[ \t]%[^,]+, %ebx
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
On x86-64, I got
FAIL: gcc.target/i386/stack-check-17.c scan-assembler-not pop
: 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
On x86-64, I got
FAIL: gcc.target/i386/pr91384.c scan-assembler-not testl
Severity: 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
Target Milestone: ---
Target: x86-64
On x86-64, I got
FAIL
: target
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.target/i386/pr105493.c scan-tree-dump-times slp1 " MEM
\\[[^]]*\\] = " 4
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
On x86-64, I got
FAIL: gcc.target/i386/pr101950-2.c scan-assembler-times \txor[ql]\t 2
: 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
On GCC 15 branch, I got
FAIL: gcc.target/i386/pr101716.c scan-assembler leal[\\t ][^\\n]*eax
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
On GCC 15 branch, I got
FAIL: gcc.target/i386/part-vect
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
On GCC 15 branch, I got
FAIL: gcc.target/i386/force-indirect
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
On GCC 15 branch, I got
FAIL: gcc.target/i386
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
On GCC 15 branch, I got
FAIL: gcc.target/i386
: 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
Target Milestone: ---
Target: x86-64
On GCC 15 branch, I got
FAIL: gcc.target/i386
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117069
H.J. Lu changed:
What|Removed |Added
Summary|[14/15 Regression] |[15 Regression]
|gcc.target
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: ---
On GCC 15 and 14 branches, I got
FAIL: gcc.target/i386/apx-ndd-tls-1b.c scan-assembler-times addq[
\t]+%r[a-z0-9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116962
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116962
H.J. Lu changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116839
H.J. Lu changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116839
H.J. Lu changed:
What|Removed |Added
Summary|$fs:(%reg32) is used as |%fs:(%reg32) is used as
|me
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
CC: lili.cui at intel dot com
Target Milestone: ---
Target: x86-64
[hjl@gnu-tgl-3 src]$ cat x.c
typedef long mpfr_prec_t;
typedef long mpfr_exp_t;
typedef struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116621
H.J. Lu changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116614
H.J. Lu changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93117
--- Comment #2 from H.J. Lu ---
(In reply to Richard Biener from comment #1)
> Hmm, we now can parse the extened section stuff but simply
> removing the check
>
> if (new_i - 1 >= SHN_LORESERVE)
> {
> *err = ENOTSUP;
> return "
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116621
H.J. Lu changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116410
H.J. Lu changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116361
H.J. Lu changed:
What|Removed |Added
Target Milestone|--- |14.3
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116410
--- Comment #14 from H.J. Lu ---
(In reply to Sam James from comment #13)
> (In reply to Jan Hubicka from comment #11)
> > > We plan to adopt -ffat-lto-objects ourselves soon for at least a subset of
> > > packages, so this was good timing. :)
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116516
H.J. Lu changed:
What|Removed |Added
Summary|[15 Regression] [lra] ICE |[15 Regression] [lra] ICE
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116516
H.J. Lu changed:
What|Removed |Added
Summary|[lra] ICE in|[15 Regression] [lra] ICE
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63987
H.J. Lu changed:
What|Removed |Added
Target Milestone|--- |6.4
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116410
H.J. Lu changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #6 from H.J. Lu ---
A patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116410
H.J. Lu changed:
What|Removed |Added
Status|NEW |WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116410
--- Comment #5 from H.J. Lu ---
Created attachment 59016
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59016&action=edit
A patch
Please try this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116497
--- Comment #19 from H.J. Lu ---
(In reply to andi from comment #18)
> > > -mgeneral-regs-only works for this case, but breaks SSE.
> >
> > Why is __attribute__((no_caller_saved_registers)) needed on start?
>
> To maintain the standard ABI to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116497
--- Comment #17 from H.J. Lu ---
(In reply to Andi Kleen from comment #16)
> Created attachment 59013 [details]
> test case
>
> This test case using Pinski's clobber trick shows the benefit.
>
> If you compile with -O2 -mgeneral-regs-only the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116497
--- Comment #15 from H.J. Lu ---
(In reply to andi from comment #13)
> > --- Comment #11 from H.J. Lu ---
> > Please provide a small testcase to show the issue.
>
> You mean a test case for no_caller_saved_registers failing with SSE?
No. We
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116497
H.J. Lu changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116470
--- Comment #7 from H.J. Lu ---
(In reply to Bernd Edlinger from comment #5)
> but one thing is funnny, in the bad asm
> both symbols.LM19367 and .LM19368 appear to be in the same section:
>
>
> .section.text.unlikely
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116470
--- Comment #6 from H.J. Lu ---
They are in different sections:
[hjl@gnu-cfl-3 tmp]$ cat foo.s
.text
.align 2
.p2align 4
.LM19367:
pushl %ebp
.section.text.unlikely
.LM19368:
nop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116174
--- Comment #10 from H.J. Lu ---
(In reply to Hongtao Liu from comment #9)
> (In reply to Arnd Bergmann from comment #7)
> > I confirmed that the patch from comment #6 addresses the build warnings I
> > see in the kernel.
>
> Does the commit al
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116361
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
1 - 100 of 2623 matches
Mail list logo
