https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105638
H.J. Lu changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105960
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=105970
--- Comment #2 from H.J. Lu ---
(In reply to Uroš Bizjak from comment #1)
> Probably something like:
>
> diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc
> index 3d189e124e4..f158cc3aaea 100644
> --- a/gcc/config/i386/i386.cc
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105920
H.J. Lu changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105960
--- Comment #6 from H.J. Lu ---
This is caused by r12-5771.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106022
--- Comment #6 from H.J. Lu ---
Created attachment 53169
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53169=edit
A patch
This patch multiplies the vector store cost by the number of scalar elements in
a word to properly compare scalar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106022
--- Comment #7 from H.J. Lu ---
Created attachment 53171
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53171=edit
The v2 patch
Handle vector store.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105877
--- Comment #1 from H.J. Lu ---
"strip -g" removed .gnu.debuglto_.debug_info sections. Should LTO remove the
references of stripped debug info? Or should "strip -g" keep LTO debug info?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105923
Bug ID: 105923
Summary: unsupported return type ‘complex double’ for simd
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81708
--- Comment #17 from H.J. Lu ---
(In reply to Alexandre Oliva from comment #15)
> Uroš,
>
> stack-prot-sym.c fails on ia32 with PIC/PIE: the address/value of my_guard
> is loaded from the GOT, instead of appearing as %gs:my_guard.
>
When
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106303
--- Comment #5 from H.J. Lu ---
The original TImode STV pass only converts load and store. When other
operations were added, timode_remove_non_convertible_regs no longer works
correctly. After an instruction is removed from the candidate list,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106303
--- Comment #6 from H.J. Lu ---
Created attachment 53326
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53326=edit
Something like this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83782
--- Comment #11 from H.J. Lu ---
The problem is that calling an IFUNC class member function via a member
function
pointer needs PLT in 32-bit mode since the IFUNC function pointer points to its
PLT entry. But we don't want to require PLT for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106331
--- Comment #5 from H.J. Lu ---
The memory alignment passed to __builtin_memset shouldn't be 16 bytes in
this case.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106331
--- Comment #6 from H.J. Lu ---
This is a latent bug. GCC 11 RTL expander generates:
(insn 21 20 22 (set (mem/c:TI (reg:DI 92 [ D.3947 ]) [0 MEM [(void
*)]+0 S16 A128])
(const_wide_int 0x20202020202020202020202020202020)) "x.f90":3:6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106331
--- Comment #7 from H.J. Lu ---
Breakpoint 6, expand_builtin_memset_args (dest=0x77b6f1a0,
val=0x77f86978, len=0x77f86960, target=0x77da7400, mode=E_VOIDmode,
orig_exp=0x77da9d38) at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85620
--- Comment #11 from H.J. Lu ---
Created attachment 53299
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53299=edit
A patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106288
Bug ID: 106288
Summary: stack protector fails to check stack canary for
noreturn function
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58245
H.J. Lu changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58245
--- Comment #12 from H.J. Lu ---
Created attachment 53294
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53294=edit
A patch
Something like this?
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=101561
H.J. Lu changed:
What|Removed |Added
Target Milestone|--- |12.0
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=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=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=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
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=105960
H.J. Lu changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83782
--- Comment #9 from H.J. Lu ---
(In reply to Alexandre Oliva from comment #8)
> I'm running into some problems that are related with this PR.
>
> First off, on i686-linux-gnu with --enable-default-pie, attr-ifunc-3.c fails
> to link with e.g.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106414
H.J. Lu changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106414
H.J. Lu changed:
What|Removed |Added
Version|unknown |13.0
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105433
H.J. Lu changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105472
--- Comment #1 from H.J. Lu ---
(In reply to Rainer Orth from comment #0)
>
> The usual way throughout the code base is to guard .note.GNU-stack with
> __ELF__ && __linux__ to avoid all this.
Isn't checking __linux__ sufficient?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105509
--- Comment #1 from H.J. Lu ---
_Float16 was added for AVX512FP16 as a C++ extention. The fN suffixes were
added by
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=c65699efcce48d68ef57ab3ce7fc5420fac5cbf9
which has
C++ note: no support for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105472
H.J. Lu changed:
What|Removed |Added
Status|NEW |WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105472
--- Comment #3 from H.J. Lu ---
Created attachment 52935
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52935=edit
A patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105433
Bug ID: 105433
Summary: FAIL:
gcc.target/i386/iamcu/test_3_element_struct_and_unions
.c
Product: gcc
Version: 12.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105472
H.J. Lu changed:
What|Removed |Added
Resolution|--- |FIXED
Status|WAITING
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=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=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=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 #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
--- 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=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=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=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
H.J. Lu changed:
What|Removed |Added
See Also||https://sourceware.org/bugz
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=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=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=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 #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
--- 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 #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=107273
H.J. Lu changed:
What|Removed |Added
Resolution|DUPLICATE |---
Last reconfirmed|
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 #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=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=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
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 #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=107364
--- Comment #10 from H.J. Lu ---
The fix should be backported to release branches.
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=107304
--- Comment #23 from H.J. Lu ---
Fixed for GCC 13 so far.
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 #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=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=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=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=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=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=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 #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 #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 #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=107273
--- Comment #8 from H.J. Lu ---
-O2 -funswitch-loops also triggers this bug.
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=107061
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Target Milestone|---
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 #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 #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 #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=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=55522
--- Comment #24 from H.J. Lu ---
Dropping crtfastmath.o with -shared makes sense.
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=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
801 - 900 of 1125 matches
Mail list logo
