https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113752
--- Comment #2 from H.J. Lu ---
[hjl@gnu-skx-1 gcc]$ cat /tmp/foo.i
char a[10256];
char b;
char *c, *g;
int d, e, f;
int sprintf(char *, char *, ...);
unsigned long strlen(char *);
int h(char *j) {
if (strlen(j) + strlen(c) + strlen(g) + 32 >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113752
H.J. Lu changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113752
Bug ID: 113752
Summary: [14 Regression] warning: ‘%s’ directive writing up to
10218 bytes into a region of size between 0 and 10240
[-Wformat-overflow=]
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113751
Bug ID: 113751
Summary: -mapxf -mfma4 generates wrong assembly code
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113711
--- Comment #9 from H.J. Lu ---
Many NDD patterns have the same issue. Here is another testcase:
[hjl@gnu-cfl-3 pr113711]$ cat apx-ndd-length-X.c
/* { dg-do assemble { target { apxf && { ! ia32 } } } } */
/* { dg-options "-mapxf -O2" } */
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113744
--- Comment #1 from H.J. Lu ---
Other *add patterns may have the same issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113744
Bug ID: 113744
Summary: Unnecessary "m" constraint in *adddi_4
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113733
Bug ID: 113733
Summary: Invalid APX TLS code squence
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113732
Bug ID: 113732
Summary: [14 Regression] FAIL: g++.dg/modules/hello-1_b.C
caused by r14-8710
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113729
Bug ID: 113729
Summary: Missing APX NDD optimization
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113711
--- Comment #8 from H.J. Lu ---
My branch is at
https://gitlab.com/x86-gcc/gcc/-/commits/users/hjl/pr113711/master
We need to add more tests:
1. All NDD instructions are 15 bytes or less.
2. Use "op imm, mem, reg" whenever possible.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113711
--- Comment #7 from H.J. Lu ---
(In reply to Hongyu Wang from comment #6)
> (In reply to H.J. Lu from comment #5)
> > (In reply to Hongyu Wang from comment #4)
> > > Previously I added
> > > https://gcc.gnu.org/git/?p=gcc.git;a=commit;
> > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113711
--- Comment #5 from H.J. Lu ---
(In reply to Hongyu Wang from comment #4)
> Previously I added
> https://gcc.gnu.org/git/?p=gcc.git;a=commit;
> h=d564198f960a2f5994dde3f6b83d7a62021e49c3
>
> to prohibit several *POFF constant usage in NDD add
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113711
H.J. Lu changed:
What|Removed |Added
Attachment #57288|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113711
--- Comment #2 from H.J. Lu ---
Created attachment 57288
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57288=edit
Add BN constraint for APX NDD instructions
Since the instruction length of APX NDD instructions:
op imm, mem, reg
may
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113711
H.J. Lu changed:
What|Removed |Added
Last reconfirmed||2024-02-01
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113711
Bug ID: 113711
Summary: Warning: instruction length of 16 bytes exceeds the
limit of 15
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113689
--- Comment #4 from H.J. Lu ---
A patch is at
https://patchwork.sourceware.org/project/gcc/list/?series=30482
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113684
--- Comment #8 from H.J. Lu ---
(In reply to Jakub Jelinek from comment #7)
> That is fuzzy, because working as or ld can mean a lot of things. Latest
> binutils as/ld can be working, or 5 or 7 years old binutils as well. So
> what exactly we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113706
--- Comment #3 from H.J. Lu ---
On Solaris, when compiling this
#include
__attribute__ ((weak))
int
f (int a)
{
return memchr ("aE", a, 2) != NULL;
}
as C++ source, std::memchr is used and GCC doesn't treat std::memchr as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113684
--- Comment #6 from H.J. Lu ---
Should there be configure options, like
--with-working-gnu-as
--with-working-gnu-ld
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113690
H.J. Lu changed:
What|Removed |Added
Keywords|needs-bisection |
--- Comment #3 from H.J. Lu ---
It is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113684
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113684
--- Comment #2 from H.J. Lu ---
(In reply to Andrew Pinski from comment #1)
> This usecase is only for GCC developers and it might even confuse regular
> users of GCC ...
True, such cross compilers are only for GCC developers. Regular won't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113684
Bug ID: 113684
Summary: Cross compiler without assembler and linker should
assume that all assembler and linker features are
available
Product: gcc
Version:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113675
Bug ID: 113675
Summary: %p modifier doesn't work with PIC
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534
--- Comment #23 from H.J. Lu ---
(In reply to Andrew Burgess from comment #21)
> Setting to DW_CFA_undefined is the right thing to do. DWARF says:
>
> The DW_CFA_undefined instruction takes a single unsigned LEB128 operand
> that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110273
--- Comment #14 from H.J. Lu ---
(In reply to Zeb Figura from comment #13)
> (In reply to Sam James from comment #11)
> > (In reply to Jens-Hanno Schwalm from comment #10)
> > > Hi, i think we found a very-similar issue in darktable code, you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534
--- Comment #22 from H.J. Lu ---
Created attachment 57243
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57243=edit
A patch to generate .cfi_undefined for unsaved callee-saved registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113617
--- Comment #13 from H.J. Lu ---
A patch is posted at
https://patchwork.sourceware.org/project/gcc/list/?series=30277
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534
--- Comment #18 from H.J. Lu ---
(In reply to Jakub Jelinek from comment #17)
> E.g. shouldn't it at least be disabled for -O0 and -Og and shouldn't we
We can disable this for -O0 and -Og.
> somehow indicate in DWARF unwind info that the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113617
H.J. Lu changed:
What|Removed |Added
Attachment #57233|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113617
--- Comment #11 from H.J. Lu ---
Created attachment 57233
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57233=edit
An untested patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113617
--- Comment #5 from H.J. Lu ---
(In reply to Jakub Jelinek from comment #4)
> (In reply to H.J. Lu from comment #3)
> > LEA is changed to load through an indirection. Isn't it a regression?
>
> LEA + moving a GPR register to SSE register.
> So
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113617
H.J. Lu changed:
What|Removed |Added
CC||crazylht at gmail dot com
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113562
Bug ID: 113562
Summary: [14 Regression] FAIL: gcc.dg/guality/pr54796.c
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113554
H.J. Lu changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113554
H.J. Lu changed:
What|Removed |Added
Target Milestone|--- |14.0
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113507
--- Comment #3 from H.J. Lu ---
(In reply to Kewen Lin from comment #2)
> Guessing /usr/local/bin/ld is a gnu ld? Based on what I heard before, gnu ld
> has some problems on aix, people pass object files to aix system and use aix
> ld there.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113507
Bug ID: 113507
Summary: can't build a cross compiler to rs6000-ibm-aix7.2
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113312
--- Comment #26 from H.J. Lu ---
(In reply to Xin Li from comment #25)
> (In reply to Xin Li from comment #22)
> > Per Peter's suggestion, I added __attribute__((no_callee_saved_registers))
> > to a linux source tree containing FRED patches:
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113312
--- Comment #23 from H.J. Lu ---
(In reply to Xin Li from comment #22)
> Per Peter's suggestion, I added __attribute__((no_callee_saved_registers))
> to a linux source tree containing FRED patches:
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113456
Bug ID: 113456
Summary: [14 Regression] Bootstrap comparison failure!
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113369
--- Comment #5 from H.J. Lu ---
Created attachment 57091
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57091=edit
The list of compile tests with -save-temps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113369
--- Comment #4 from H.J. Lu ---
I removed -save-temps from some compile tests I can run on x86-64.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113369
H.J. Lu changed:
What|Removed |Added
Attachment #57063|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534
--- Comment #10 from H.J. Lu ---
(In reply to Lukas Grätz from comment #9)
> Well it is not my testcase. But I added backtracing and observed that the
> printed backtrace is unchanged with your patch. The new
> no_return_to_caller():
>
> void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534
H.J. Lu changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113312
--- Comment #20 from H.J. Lu ---
In Linux kernel 6.7.0 on x86-64, do_exit is changed from
do_exit:
endbr64
call
push %r15
push %r14
push %r13
push %r12
mov%rdi,%r12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113312
--- Comment #18 from H.J. Lu ---
(In reply to H.J. Lu from comment #17)
> Please try users/hjl/pr113312/gcc-13 branch:
>
> https://gitlab.com/x86-gcc/gcc/-/tree/users/hjl/pr113312/gcc-
> 13?ref_type=heads
>
> It supports
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113312
--- Comment #17 from H.J. Lu ---
Please try users/hjl/pr113312/gcc-13 branch:
https://gitlab.com/x86-gcc/gcc/-/tree/users/hjl/pr113312/gcc-13?ref_type=heads
It supports no_callee_saved_registers attribute. It should also avoid saving
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113369
Bug ID: 113369
Summary: Many tests with -save-temps
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113367
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113367
--- Comment #2 from H.J. Lu ---
I don't know if it is a regression. I rebooted machines and am running
"make check" again.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113367
Bug ID: 113367
Summary: g++.dg/tree-prof/indir-call-prof-2.C never finishes
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534
--- Comment #4 from H.J. Lu ---
When I compiled __cxxabiv1::__cxa_throw, which is a noreturn function in
libstdc++-v3/libsupc++/eh_throw.cc not to save callee-saved registers,
most of C++ exception tests crashed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113355
Bug ID: 113355
Summary: [14 Regression] libstdc++ tests leave directories
which can't be removed
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113312
--- Comment #16 from H.J. Lu ---
I updated users/hjl/pr113312/master branch to handle function pointers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113312
--- Comment #14 from H.J. Lu ---
Here is a branch for __attribute__((no_callee_saved_registers)):
https://gitlab.com/x86-gcc/gcc/-/commits/users/hjl/pr113312/master
Calling a function with __attribute__((no_callee_saved_registers))
doesn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113312
--- Comment #9 from H.J. Lu ---
(In reply to H.J. Lu from comment #8)
> (In reply to H.J. Lu from comment #7)
> > (In reply to H. Peter Anvin from comment #6)
> > > Of course. That's not what we want in the Linux kernel specifically,
> > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113312
--- Comment #8 from H.J. Lu ---
(In reply to H.J. Lu from comment #7)
> (In reply to H. Peter Anvin from comment #6)
> > Of course. That's not what we want in the Linux kernel specifically, though.
> > It's really up to the OS.
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113312
--- Comment #7 from H.J. Lu ---
(In reply to H. Peter Anvin from comment #6)
> Of course. That's not what we want in the Linux kernel specifically, though.
> It's really up to the OS.
no_callee_saved_registers attribute is sufficient. One can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103503
H.J. Lu changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113312
--- Comment #5 from H.J. Lu ---
(In reply to H. Peter Anvin from comment #3)
> Created attachment 57032 [details]
> FRED assembly entry stub (example, slightly modified from the Linux kernel)
Can you do
asm_fred_entry_\type:
endbr64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113321
--- Comment #1 from H.J. Lu ---
(In reply to H. Peter Anvin from comment #0)
> __attribute__((interrupt)) on x86 has two prototypes, and picking the wrong
> type "probably will cause a system crash." It turns out that this is
> unavoidable on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113312
H.J. Lu changed:
What|Removed |Added
Last reconfirmed||2024-01-11
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113319
H.J. Lu changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113319
Bug ID: 113319
Summary: Random LTO test failures
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113312
Bug ID: 113312
Summary: Update __attribute__((interrupt)) for Intel FRED
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113040
H.J. Lu changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113040
H.J. Lu changed:
What|Removed |Added
Keywords|needs-bisection |
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113040
H.J. Lu changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113040
--- Comment #2 from H.J. Lu ---
Created attachment 56902
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56902=edit
A testcase
[hjl@gnu-tgl-3 tmp]$
/export/build/gnu/tools-build/gcc-gitlab-debug/release/usr/gcc-14.0.0-x86-64/bin/gcc
x.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113039
--- Comment #2 from H.J. Lu ---
(In reply to H.J. Lu from comment #1)
> This may be caused by r14-2692-g1c6231c05bdcca
This commit changes the behavior of -fcf-protection -fcf-protection=branch.
Workaround is to use -fcf-protection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113039
H.J. Lu changed:
What|Removed |Added
Last reconfirmed||2023-12-16
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113040
Bug ID: 113040
Summary: [14 Regression] libmvec test failures
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113039
Bug ID: 113039
Summary: [14 Regression] -fcf-protection -fcf-protection=branch
doesn't work
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65
--- Comment #15 from H.J. Lu ---
We need a testcase which can be reproduced with glibc since the bug may be in
other parts of dietlibc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109780
H.J. Lu changed:
What|Removed |Added
Attachment #55409|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109780
--- Comment #19 from H.J. Lu ---
(In reply to Xi Ruoyao from comment #17)
> (In reply to H.J. Lu from comment #16)
> > Created attachment 55409 [details]
> > A patch
> >
> > I am stilling trying to find a small testcase.
>
> The patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109780
--- Comment #16 from H.J. Lu ---
Created attachment 55409
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55409=edit
A patch
I am stilling trying to find a small testcase.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110273
--- Comment #5 from H.J. Lu ---
GCC doesn't align stack for Windows. As a workaround, one can pass
-muse-unaligned-vector-move to newer assembler.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109982
H.J. Lu changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #11 from H.J. Lu ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109982
--- Comment #10 from H.J. Lu ---
(In reply to H.J. Lu from comment #9)
> [hjl@gnu-cfl-3 pr109982]$ cat x.c
> struct S0 {
>long long int f0;
> } __attribute__((aligned(128)));
>
> int padding = 1;
> static struct S0 g_2415
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109982
H.J. Lu changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109896
--- Comment #2 from H.J. Lu ---
(In reply to Andrew Pinski from comment #1)
> I suspect the overflow code was added before __builtin_*_overflow were added
> which is why the generated code is this way.
Should the C++ front-end use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109276
--- Comment #10 from H.J. Lu ---
(In reply to Jakub Jelinek from comment #7)
> This started to ICE with r11-508-gdfa4fcdba374ed44 in the newly added pass
> there,
> and since r11-2259-g0a9d711df36b42b6494b73 it ICEs similarly like on the
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109093
--- Comment #21 from H.J. Lu ---
REG_EQUIV is added by IRA:
if (DF_REG_DEF_COUNT (regno) == 1
&& note
&& !rtx_varies_p (XEXP (note, 0), 0)
&& (!may_trap_or_fault_p (XEXP (note, 0))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109093
--- Comment #19 from H.J. Lu ---
.DEFERRED_INIT has
insn 259 261 297 4 (set (reg/f:DI 144)
(plus:DI (reg/f:DI 19 frame)
(const_int -32 [0xffe0]))) 241 {*leadi}
(expr_list:REG_EQUAL (plus:DI (reg/f:DI 19
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109093
--- Comment #17 from H.J. Lu ---
Created attachment 54666
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54666=edit
A patch
Change ix86_find_max_used_stack_alignment to find alignments of all stack slot
accesses.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109093
--- Comment #15 from H.J. Lu ---
The crash went away after r13-6661-gbd6e566e9dc543 which removed variables only
used with .DEFERRED_INIT. If variables are used, they will be captured by
ix86_find_max_used_stack_alignment. Is there a testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109093
--- Comment #12 from H.J. Lu ---
ix86_find_max_used_stack_alignment fails to detect that
(insn 281 152 282 34 (set (mem/c:V16QI (reg/f:DI 2 cx [144]) [0 MEM
[(void *)_109]+0 S16 A128])
(reg:V16QI 21 xmm1 [orig:156 MEM [(void *)_109]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109093
H.J. Lu changed:
What|Removed |Added
CC||crazylht at gmail dot com
--- Comment #10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108922
--- Comment #33 from H.J. Lu ---
(In reply to Uroš Bizjak from comment #20)
> (In reply to Jakub Jelinek from comment #16)
>
> > More questionable is the #Z case, where Table 8-11 just talks about
> > Divide or reverse divide operation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103541
--- Comment #6 from H.J. Lu ---
The change has been reverted by r13-5738-gad2bd0ad0413c2448fee0d4a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105506
--- Comment #13 from H.J. Lu ---
Created attachment 54389
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54389=edit
A patch for GCC 12 branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108436
H.J. Lu changed:
What|Removed |Added
Target Milestone|--- |13.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102566
--- Comment #37 from H.J. Lu ---
It is
if ((__atomic_fetch_xor_4 ((volatile void *) a, (unsigned int) (1 << bit), 0)
& (unsigned int) (1 << bit)) != 0)
vs
if ((__atomic_fetch_xor_4 ((volatile void *) a, 1 << bit, 0) >> bit & 1) != 0)
Why
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102566
--- Comment #36 from H.J. Lu ---
(1 << (x)) works, but (((unsigned int) 1) << (x)) doesn't work:
[hjl@gnu-skx-1 gcc]$ cat bar.c
void bar (void);
#define MASK1(x) (1 << (x))
void
f1 (unsigned int *a, unsigned int bit)
{
if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108436
--- Comment #2 from H.J. Lu ---
Created attachment 54294
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54294=edit
Issue a warning for the invalid 3rd argument
101 - 200 of 1130 matches
Mail list logo
