https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105506
--- Comment #11 from H.J. Lu ---
Created attachment 54288
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54288=edit
An updated patch
Try this one.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105506
--- Comment #9 from H.J. Lu ---
Created attachment 54284
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54284=edit
A patch
Please try this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105980
--- Comment #8 from H.J. Lu ---
A patch is posted at
https://gcc.gnu.org/pipermail/gcc-patches/2023-January/610035.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108292
--- Comment #13 from H.J. Lu ---
I also got
$ cat foo.i
extern void foo (float *);
extern int x;
int
mouse_frame_side(void) {
float mouseloc;
foo ();
return mouseloc > x ? 1 : 2;
}
$ gcc -march=alderlake -Ofast -S foo.i
during RTL pass:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108196
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108196
Bug ID: 108196
Summary: Incorrect binary search in find_opt
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: driver
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108192
--- Comment #1 from H.J. Lu ---
Since Windows doesn't support IBT, this test can be limited to Linux.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108106
--- Comment #10 from H.J. Lu ---
A patch is posted at
https://gcc.gnu.org/pipermail/gcc-patches/2022-December/608672.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108106
H.J. Lu changed:
What|Removed |Added
Attachment #54106|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108106
--- Comment #7 from H.J. Lu ---
It is about -mshared:
[hjl@gnu-cfl-3 tmp]$ cat foo.s
jmp __interceptor_sigsetjmp
.globl __interceptor_sigsetjmp
__interceptor_sigsetjmp:
nop
[hjl@gnu-cfl-3 tmp]$ as -o foo.o foo.s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108106
H.J. Lu changed:
What|Removed |Added
Attachment #54104|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108106
--- Comment #2 from H.J. Lu ---
Created attachment 54104
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54104=edit
A patch
Please try this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108106
H.J. Lu changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172
H.J. Lu changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107595
H.J. Lu changed:
What|Removed |Added
Last reconfirmed||2022-11-09
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107304
H.J. Lu changed:
What|Removed |Added
Target Milestone|--- |13.0
--- Comment #27 from H.J. Lu ---
Fixed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102566
--- Comment #34 from H.J. Lu ---
Created attachment 53813
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53813=edit
A patch to handle if (_5 < 0)
A patch to extend optimization for
_1 = __atomic_fetch_or_4 (ptr_6, 0x8000, _3);
_5 =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172
--- Comment #48 from H.J. Lu ---
(In reply to Roger Sayle from comment #47)
> I really don't believe that using UNSPEC here is the correct way to go, but
> it appears to be the (only?) approach that Segher is prepared to approve.
> Hohum.
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107403
Bug ID: 107403
Summary: uint64_t bitfield operation is mishandled
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989
--- Comment #17 from H.J. Lu ---
See:
https://gitlab.com/x86-psABIs/x86-64-ABI/-/merge_requests/38
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989
--- Comment #14 from H.J. Lu ---
(In reply to jos...@codesourcery.com from comment #13)
> https://gitlab.com/x86-psABIs/i386-ABI/-/issues/5 to request such an ABI
> for 32-bit x86. I don't know if there are other psABIs with public issue
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107304
--- Comment #23 from H.J. Lu ---
Fixed for GCC 13 so far.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989
--- Comment #12 from H.J. Lu ---
(In reply to Jakub Jelinek from comment #11)
> The x86-64 psABI has been changed for this:
> https://gitlab.com/x86-psABIs/x86-64-ABI/-/commit/
> 8ca45392570e96920f8a15d903d6122f6d263cd0
> but the state of the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107364
--- Comment #10 from H.J. Lu ---
The fix should be backported to release branches.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106933
--- Comment #6 from H.J. Lu ---
This
diff --git a/gcc/config/i386/i386-features.cc
b/gcc/config/i386/i386-features.cc
index e357294bc4e..aca34d730a8 100644
--- a/gcc/config/i386/i386-features.cc
+++ b/gcc/config/i386/i386-features.cc
@@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106959
--- Comment #4 from H.J. Lu ---
Created attachment 53738
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53738=edit
A patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172
--- Comment #44 from H.J. Lu ---
(In reply to Segher Boessenkool from comment #42)
> (In reply to H.J. Lu from comment #41)
> > (In reply to Segher Boessenkool from comment #40)
> > > Let me repeat: A const_int cannot be assigned to a MODE_CC.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107304
--- Comment #21 from H.J. Lu ---
(In reply to H.J. Lu from comment #20)
> This is the opposite of PR 80583.
Like this
diff --git a/gcc/expr.cc b/gcc/expr.cc
index 4c892d69249..b4e1ec9dbe7 100644
--- a/gcc/expr.cc
+++ b/gcc/expr.cc
@@ -7898,8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107304
H.J. Lu changed:
What|Removed |Added
CC||jakub at redhat dot com
--- Comment #20 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107304
--- Comment #19 from H.J. Lu ---
This seems to work:
diff --git a/gcc/expr.cc b/gcc/expr.cc
index 4c892d69249..b55736945c9 100644
--- a/gcc/expr.cc
+++ b/gcc/expr.cc
@@ -7902,6 +7902,11 @@ get_inner_reference (tree exp, poly_int64_pod
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107304
--- Comment #18 from H.J. Lu ---
Can we update ix86_vector_mode_supported_p for cfun != NULL to issue an error
when a vector mode changes from valid to invalid?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107304
--- Comment #17 from H.J. Lu ---
Since this type
typedef struct {
unsigned char v __attribute__((aligned(256))) __attribute__
((vector_size(64 * sizeof(unsigned char;
} stress_vec_u8_64_t;
is processed outside of the function and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107304
--- Comment #15 from H.J. Lu ---
(In reply to Hongtao.liu from comment #14)
> (In reply to H.J. Lu from comment #12)
> > (In reply to Hongyu Wang from comment #10)
> > >
> > > Clang works properly as it overrides -march= to any target clones.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107304
--- Comment #13 from H.J. Lu ---
A simple testcase:
[hjl@gnu-tgl-3 pr107304]$ cat y1.c
typedef struct {
unsigned char v __attribute__((aligned(256))) __attribute__
((vector_size(64 * sizeof(unsigned char;
} stress_vec_u8_64_t;
void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107304
--- Comment #12 from H.J. Lu ---
(In reply to Hongyu Wang from comment #10)
>
> Clang works properly as it overrides -march= to any target clones. I suppose
> we can do similar things in ix86_valid_target_attribute_p
That will be wrong since
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107304
--- Comment #9 from H.J. Lu ---
(In reply to Hongtao.liu from comment #8)
> (In reply to H.J. Lu from comment #7)
> > (In reply to Hongtao.liu from comment #6)
> > > (In reply to Hongtao.liu from comment #5)
> > > > (In reply to H.J. Lu from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107304
--- Comment #7 from H.J. Lu ---
(In reply to Hongtao.liu from comment #6)
> (In reply to Hongtao.liu from comment #5)
> > (In reply to H.J. Lu from comment #4)
> > > Since the default is -march=tigerlake, it enables AVX512 in the middle
> > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172
--- Comment #41 from H.J. Lu ---
(In reply to Segher Boessenkool from comment #40)
> Let me repeat: A const_int cannot be assigned to a MODE_CC. It has no
> meaning.
> This is invalid RTL. If it ever works, or worked, that is an accident.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107304
H.J. Lu changed:
What|Removed |Added
Last reconfirmed||2022-10-18
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172
--- Comment #39 from H.J. Lu ---
(In reply to Segher Boessenkool from comment #38)
> You cannot put a const_int in a MODE_CC. It is meaningless.
Reg 17 in
(insn 49 10 50 2 (parallel [
(set (reg:CCC 17 flags)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107273
--- Comment #8 from H.J. Lu ---
-O2 -funswitch-loops also triggers this bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107269
H.J. Lu changed:
What|Removed |Added
Version|unknown |13.0
--- Comment #5 from H.J. Lu ---
***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107273
--- Comment #7 from H.J. Lu ---
*** Bug 107269 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107273
H.J. Lu changed:
What|Removed |Added
Summary|wrong code at -O3 on|wrong code at -O3 on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107273
H.J. Lu changed:
What|Removed |Added
Resolution|DUPLICATE |---
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172
--- Comment #37 from H.J. Lu ---
(In reply to Segher Boessenkool from comment #33)
> (In reply to H.J. Lu from comment #32)
> > > There is no actual comparison with 0, that is just notation.
> >
> > True. But simplify-rtx.cc simplifies
> >
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172
--- Comment #32 from H.J. Lu ---
(In reply to Segher Boessenkool from comment #30)
> (In reply to H.J. Lu from comment #26)
> > LTU/GEU are only used to check FLAGS_REG against constant 0.
>
> That is not what
> (ltu (reg 17) (const_int 0))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172
--- Comment #31 from H.J. Lu ---
(In reply to Segher Boessenkool from comment #29)
> (In reply to Hongtao.liu from comment #23)
> > looking at i386.c put_condition_code used by *setcc_qi, it looks like (EQ
> > (reg:CCCmode FLAG_REG) (const_int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172
--- Comment #27 from H.J. Lu ---
Another oddity is
(set (pc) (if_then_else
(eq (reg:CCO FLAGS_REG) (const_int 0))
(label_ref (match_operand 3))
(pc)))]
CCOmode means that the overflow flag is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172
--- Comment #26 from H.J. Lu ---
(In reply to Uroš Bizjak from comment #24)
> (In reply to Hongtao.liu from comment #23)
> > looking at i386.c put_condition_code used by *setcc_qi, it looks like (EQ
> > (reg:CCCmode FLAG_REG) (const_int 0))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172
--- Comment #22 from H.J. Lu ---
(In reply to Segher Boessenkool from comment #21)
> (In reply to Hongtao.liu from comment #19)
> > (In reply to H.J. Lu from comment #18)
> > > (In reply to Segher Boessenkool from comment #16)
> > > > Hi Roger,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172
--- Comment #18 from H.J. Lu ---
(In reply to Segher Boessenkool from comment #16)
> Hi Roger,
>
> (In reply to Roger Sayle from comment #15)
> > Yes, a COMPARE rtx can be used to set various flags on x86, but many other
> > operations also
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172
--- Comment #17 from H.J. Lu ---
(In reply to Segher Boessenkool from comment #14)
> (In reply to H.J. Lu from comment #13)
> > (In reply to Segher Boessenkool from comment #12)
> > >
> > > To determine the semantics of this piece of RTL you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172
--- Comment #13 from H.J. Lu ---
(In reply to Segher Boessenkool from comment #12)
>
> To determine the semantics of this piece of RTL you need to see the setter(s)
> of reg 17 feeding this use. In this case, the setter was
> (set (reg:CCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172
--- Comment #11 from H.J. Lu ---
Assuming (reg:CCC 17 flags) is set to 1 by compare properly, how should
(insn 50 49 51 2 (parallel [
(set (reg:SI 93)
(neg:SI (ltu:SI (reg:CCC 17 flags)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107193
--- Comment #6 from H.J. Lu ---
gimple *last = last_stmt (bb);
location_t locus = last ? gimple_location (last) : UNKNOWN_LOCATION;
location_t curr_locus = UNKNOWN_LOCATION;
int curr_discr = 0;
/* Traverse the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107193
H.J. Lu changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107205
H.J. Lu changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107205
Bug ID: 107205
Summary: [13 Regression] Bootstrap failure with
--with-arch=native --with-cpu=native caused by
r13-3172
Product: gcc
Version: 13.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172
--- Comment #9 from H.J. Lu ---
(In reply to Segher Boessenkool from comment #7)
> Please show the (relevant part of) output of -fdump-rtl-combine-all ? At
> least
> those parts where it decided (ltu:SI (const_int 1) (const_int 0)) is valid
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522
--- Comment #27 from H.J. Lu ---
(In reply to Florian Weimer from comment #25)
> (In reply to H.J. Lu from comment #24)
> > Dropping crtfastmath.o with -shared makes sense.
>
> Are you going to send a patch? I can give it a try as well
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522
--- Comment #26 from H.J. Lu ---
Created attachment 53686
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53686=edit
A patch not to add crtfastmath.o for -shared on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172
--- Comment #5 from H.J. Lu ---
i386 needs to change
(ltu:SI (const_int 1 [1])
(const_int 0 [0]))
to
(ne:SI (const_int 1 [1])
(const_int 0 [0]))
when checking the carry flag. But the mode info isn't passed to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172
H.J. Lu changed:
What|Removed |Added
CC||hjl.tools at gmail dot com,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522
--- Comment #24 from H.J. Lu ---
Dropping crtfastmath.o with -shared makes sense.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106933
H.J. Lu changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107061
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107061
Bug ID: 107061
Summary: ENCODEKEY128 clobbers xmm4-xmm6
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106835
--- Comment #8 from H.J. Lu ---
GCC generates _GLOBAL_OFFSET_TABLE_ to indicate GOTPC32 relocation. It can't
be
treated as a normal symbol.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106834
--- Comment #12 from H.J. Lu ---
We can't use
movq_GLOBAL_OFFSET_TABLE_@GOTPCREL(%rip), %rax
to get the address of _GLOBAL_OFFSET_TABLE_ since there is no entry for
_GLOBAL_OFFSET_TABLE_ in GOT. We can't use
movl $_GLOBAL_OFFSET_TABLE_,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106835
H.J. Lu changed:
What|Removed |Added
See Also||https://sourceware.org/bugz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106834
H.J. Lu changed:
What|Removed |Added
See Also||https://sourceware.org/bugz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106835
--- Comment #5 from H.J. Lu ---
To access this special symbol:
[hjl@gnu-tgl-3 tmp]$ cat c.c
#include
extern char GLOBAL_OFFSET_TABLE[];
char *ptr = GLOBAL_OFFSET_TABLE;
int main() {
printf("%lx\n", (unsigned long)ptr);
}
[hjl@gnu-tgl-3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106834
--- Comment #9 from H.J. Lu ---
_GLOBAL_OFFSET_TABLE_ is a special symbol and can't be accessed like regular
symbols. To workaround it:
[hjl@gnu-tgl-3 tmp]$ cat x.c
#include
extern char GLOBAL_OFFSET_TABLE[];
int main() {
printf("%lx\n",
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106816
--- Comment #3 from H.J. Lu ---
(In reply to Simon Rainer from comment #2)
> (In reply to H.J. Lu from comment #1)
> > Like this?
> >
> > diff --git a/gcc/config/i386/i386-features.cc
> > b/gcc/config/i386/i386-features.cc
> > index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106816
H.J. Lu changed:
What|Removed |Added
Last reconfirmed||2022-09-02
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106746
--- Comment #10 from H.J. Lu ---
(In reply to Roger Sayle from comment #9)
> I'm curious why the zero_extend behaves so differently to a sign_extend,
> perhaps a missing simplification or pattern. Presumably the CONCAT in the
> debug_insn is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106746
--- Comment #8 from H.J. Lu ---
(In reply to H.J. Lu from comment #3)
> This debug INSN:
>
> (debug_insn 29 28 30 2 (var_location:BLK D#2 (concatn:BLK [
> (mem/j:SI (plus:DI (plus:DI (ashift:DI (zero_extend:DI (and:SI
> (mem:SI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106746
--- Comment #7 from H.J. Lu ---
Specifically,
/* We can canonicalize SIGN_EXTEND (op) as ZERO_EXTEND (op) when
we know the sign bit of OP must be clear. */
if (val_signbit_known_clear_p (GET_MODE (op),
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106746
H.J. Lu changed:
What|Removed |Added
CC||richard.sandiford at arm dot
com,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106746
--- Comment #5 from H.J. Lu ---
(In reply to H.J. Lu from comment #4)
> This simple change:
>
> diff --git a/gcc/config/i386/i386-modes.def b/gcc/config/i386/i386-modes.def
> index e2e1e18d24d..b49daaef253 100644
> ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106746
--- Comment #4 from H.J. Lu ---
This simple change:
diff --git a/gcc/config/i386/i386-modes.def b/gcc/config/i386/i386-modes.def
index e2e1e18d24d..b49daaef253 100644
--- a/gcc/config/i386/i386-modes.def
+++ b/gcc/config/i386/i386-modes.def
@@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106746
--- Comment #3 from H.J. Lu ---
This debug INSN:
(debug_insn 29 28 30 2 (var_location:BLK D#2 (concatn:BLK [
(mem/j:SI (plus:DI (plus:DI (ashift:DI (zero_extend:DI (and:SI
(mem:SI (plus:DI (reg/f:DI 7 sp)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106748
H.J. Lu changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106714
H.J. Lu changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106746
--- Comment #2 from H.J. Lu ---
A slight change in the variable makes the problem to go away. It looks
like a latent bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106748
H.J. Lu changed:
What|Removed |Added
Target Milestone|--- |13.0
--- Comment #1 from H.J. Lu ---
A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106714
Bug ID: 106714
Summary: Incorrect casts macros in amxtileintrin.h
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81501
--- Comment #8 from H.J. Lu ---
Created attachment 53473
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53473=edit
A patch
This patch uses a single UNSPEC_TLS_LD_BASE in the whole function.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106519
Bug ID: 106519
Summary: [13 Regression] internal compiler error: in
gimple_phi_arg, at gimple.h:4594 by r13-1950
Product: gcc
Version: 13.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105980
--- Comment #6 from H.J. Lu ---
(In reply to Jakub Jelinek from comment #5)
> So, shall we temporarily disable -mforce-indirect-call during the mi thunk
> output?
Something like this
diff --git a/gcc/config/i386/i386.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105980
--- Comment #4 from H.J. Lu ---
We don't have available scratch registers in 32-bit mode for
x86_output_mi_thunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106315
--- Comment #5 from H.J. Lu ---
Here is the testcase:
---
void
bar(int *indices, int max_iter, int *actual_indices,
int *iters_per_dim, int N_dims)
{
int iter = 0;
int sum_indices = 0;
int flag, k;
while (iter < max_iter) {
for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101561
H.J. Lu changed:
What|Removed |Added
Target Milestone|--- |12.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105073
Bug 105073 depends on bug 104371, which changed state.
Bug 104371 Summary: [x86] Failure to use optimize pxor+pcmpeqb+pmovmskb+cmp
0x pattern to ptest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104371
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104371
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105032
H.J. Lu changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106453
H.J. Lu changed:
What|Removed |Added
Last reconfirmed||2022-07-28
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106450
H.J. Lu changed:
What|Removed |Added
Ever confirmed|0 |1
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106414
H.J. Lu changed:
What|Removed |Added
Version|unknown |13.0
Target Milestone|---
201 - 300 of 1130 matches
Mail list logo
