https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115146
H.J. Lu changed:
What|Removed |Added
Last reconfirmed||2024-05-18
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115146
H.J. Lu changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115011
H.J. Lu changed:
What|Removed |Added
CC||pinskia at gcc dot gnu.org
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114907
--- Comment #5 from H.J. Lu ---
(In reply to H.J. Lu from comment #4)
> (In reply to H.J. Lu from comment #3)
> > convert_mode_scalar has
> >
> > if (GET_MODE_PRECISION (from_mode) == GET_MODE_PRECISION (to_mode))
> > /*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114907
--- Comment #4 from H.J. Lu ---
(In reply to H.J. Lu from comment #3)
> convert_mode_scalar has
>
> if (GET_MODE_PRECISION (from_mode) == GET_MODE_PRECISION (to_mode))
> /* Conversion between decimal float and binary float, same
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114907
H.J. Lu changed:
What|Removed |Added
Summary|Missing __extendhfbf2 in|__trunchfbf2 should be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114907
--- Comment #2 from H.J. Lu ---
[hjl@gnu-cfl-3 pr114907]$ cat foo.c
__bf16
foo (_Float16 x)
{
return x;
}
[hjl@gnu-cfl-3 pr114907]$ make CC=gcc
gcc -O2 -S foo.c
[hjl@gnu-cfl-3 pr114907]$ cat foo.s
.file "foo.c"
.text
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114907
H.J. Lu changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114907
--- Comment #1 from H.J. Lu ---
There is __trunchfbf2. Why does GCC generate __extendhfbf2?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114907
Bug ID: 114907
Summary: Missing __extendhfbf2 in libgcc
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114864
H.J. Lu changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114828
H.J. Lu changed:
What|Removed |Added
Ever confirmed|0 |1
Version|unknown
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114796
H.J. Lu changed:
What|Removed |Added
Summary|wrong code at -O2 with |[11/12/13/14 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114793
--- Comment #3 from H.J. Lu ---
(In reply to Zhendong Su from comment #1)
> The following reproducer is different, but perhaps is the same or related.
>
> Compiler Explorer: https://godbolt.org/z/411rzMP1n
>
> [588] % gcctk -v
> Using
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114793
H.J. Lu changed:
What|Removed |Added
CC||jh at suse dot cz
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114792
H.J. Lu changed:
What|Removed |Added
Last reconfirmed||2024-04-21
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114115
H.J. Lu changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114696
H.J. Lu changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114115
--- Comment #17 from H.J. Lu ---
(In reply to Jan Hubicka from comment #15)
> > Fixed for GCC 14 so far
> It is simple patch, so backporting is OK after a week in mainline.
These are patches which I am backporting:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114696
H.J. Lu changed:
What|Removed |Added
Target Milestone|--- |14.0
--- Comment #3 from H.J. Lu ---
A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114696
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=114696
H.J. Lu changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114646
H.J. Lu changed:
What|Removed |Added
Status|RESOLVED|NEW
Resolution|DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114646
H.J. Lu changed:
What|Removed |Added
Resolution|DUPLICATE |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114646
--- Comment #10 from H.J. Lu ---
Created attachment 57906
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57906=edit
A patch
I am testing this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114646
--- Comment #7 from H.J. Lu ---
r12-5108
commit 80fe172ba9820199c2bbce5d0611ffca27823049
Author: Jonathan Wakely
Date: Tue Nov 9 23:45:36 2021 +
libstdc++: Disable gthreads weak symbols for glibc 2.34 [PR103133]
Since Glibc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39176
H.J. Lu changed:
What|Removed |Added
CC||skpgkp2 at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39176
H.J. Lu changed:
What|Removed |Added
Ever confirmed|0 |1
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114646
H.J. Lu changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114646
Bug ID: 114646
Summary: libgfortran doesn't work with static libpthread
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114590
H.J. Lu changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114599
H.J. Lu changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114599
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=114590
H.J. Lu changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114590
H.J. Lu changed:
What|Removed |Added
Priority|P3 |P2
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114590
Bug ID: 114590
Summary: [14 Regression] FAIL:
gcc.target/i386/apx-ndd-ti-shift.c (test for excess
errors)
Product: gcc
Version: 14.0
Status:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114587
--- Comment #1 from H.J. Lu ---
We should define a macro for each APX command-line option.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114587
H.J. Lu changed:
What|Removed |Added
Target Milestone|--- |14.0
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114587
Bug ID: 114587
Summary: -mapxf should define a macro
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114115
H.J. Lu changed:
What|Removed |Added
Known to work||14.0
--- Comment #14 from H.J. Lu ---
Fixed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114337
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114337
--- Comment #1 from H.J. Lu ---
Maybe linker can deal with it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114337
Bug ID: 114337
Summary: LTO symbol table doesn't include builtin functions
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114116
--- Comment #12 from H.J. Lu ---
(In reply to Lukas Grätz from comment #11)
>
> I applied it, double checked, make distclean, configure, make again.
>
> But your result seems different. Have you applied Jakub Jelinek's patch to
No.
> save
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114116
--- Comment #10 from H.J. Lu ---
(In reply to Lukas Grätz from comment #9)
>
> Not on my computer. When I used -g I got:
>
>
> no_return_to_caller:
> .LFB0:
> .loc 1 16 1 view -0
> .cfi_startproc
> .loc 1 17 3 view .LVU1
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114116
--- Comment #8 from H.J. Lu ---
(In reply to Lukas Grätz from comment #7)
> (In reply to H.J. Lu from comment #6)
> > (In reply to Jakub Jelinek from comment #5)
> > > Yeah. Not to mention, one can call backtrace even if -g0; you just don't
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114098
H.J. Lu changed:
What|Removed |Added
Target Milestone|--- |11.5
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114115
--- Comment #8 from H.J. Lu ---
A patch is posted at
https://patchwork.sourceware.org/project/gcc/list/?series=31343
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114116
H.J. Lu changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|hjl.tools at gmail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114116
--- Comment #3 from H.J. Lu ---
(In reply to Jakub Jelinek from comment #2)
> Created attachment 57545 [details]
> gcc14-pr114116.patch
>
> This seems to fix it, so far tested just on the small testcase, back to the
> expected backtrace there.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114115
--- Comment #7 from H.J. Lu ---
Created attachment 57544
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57544=edit
A patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114115
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114116
H.J. Lu changed:
What|Removed |Added
Last reconfirmed||2024-02-26
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114097
H.J. Lu changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114097
--- Comment #5 from H.J. Lu ---
A patch is submitted:
https://patchwork.sourceware.org/project/gcc/list/?series=31294
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114098
H.J. Lu changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114098
--- Comment #1 from H.J. Lu ---
The problem is that in
extern __inline void
__attribute__((__gnu_inline__, __always_inline__, __artificial__))
_tile_loadconfig (const void *__config)
{
__asm__ volatile ("ldtilecfg\t%X0" :: "m" (*((const void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114098
Bug ID: 114098
Summary: _tile_loadconfig doesn't work
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114097
H.J. Lu changed:
What|Removed |Added
Component|c |target
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114097
--- Comment #3 from H.J. Lu ---
Created attachment 57524
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57524=edit
A patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114097
--- Comment #2 from H.J. Lu ---
I couldn't find a way to access the _Noreturn info in backend.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114097
H.J. Lu changed:
What|Removed |Added
Last reconfirmed||2024-02-25
Version|unknown
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91161
--- Comment #14 from H.J. Lu ---
(In reply to Andrew Pinski from comment #13)
> I looked into the IR between GCC 12 and GCC 13 (with the added attributes),
> before sched2 there is no difference. So it would good to see what change
> "fixes"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113988
--- Comment #13 from H.J. Lu ---
(In reply to Jakub Jelinek from comment #11)
> Though, bet that would mean we punt with -mavx -mno-avx2 on 32-byte copies,
> because there we support just V8SFmode and not V32QImode.
Punt AVX without AVX2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113912
H.J. Lu changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113855
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113912
H.J. Lu changed:
What|Removed |Added
Target Milestone|--- |14.0
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113912
Bug ID: 113912
Summary: push2/pop2 generated when stack isn't aligned to 16
bytes
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113876
H.J. Lu changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113876
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113909
--- Comment #1 from H.J. Lu ---
It fails on Solaris because of:
sol2.h:#undef NO_PROFILE_COUNTERS
Just skip these tests for Solaris.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113874
--- Comment #38 from H.J. Lu ---
The new glibc patch set covers both i386 and x86-64:
https://patchwork.sourceware.org/project/glibc/list/?series=30854
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113874
--- Comment #36 from H.J. Lu ---
(In reply to Andreas Schwab from comment #35)
> ld.so use its internal malloc only during bootstrapping.
___tls_get_addr always uses the internal malloc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113874
--- Comment #34 from H.J. Lu ---
(In reply to H.J. Lu from comment #33)
> (In reply to H.J. Lu from comment #32)
> > (In reply to Michael Matz from comment #31)
> > > (In reply to H.J. Lu from comment #30)
> > > > (In reply to Michael Matz from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113874
--- Comment #33 from H.J. Lu ---
(In reply to H.J. Lu from comment #32)
> (In reply to Michael Matz from comment #31)
> > (In reply to H.J. Lu from comment #30)
> > > (In reply to Michael Matz from comment #29)
> > > > It not only can call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113874
--- Comment #32 from H.J. Lu ---
(In reply to Michael Matz from comment #31)
> (In reply to H.J. Lu from comment #30)
> > (In reply to Michael Matz from comment #29)
> > > It not only can call malloc. As the backtrace of H.J. shows, it quite
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113874
--- Comment #30 from H.J. Lu ---
(In reply to Michael Matz from comment #29)
> It not only can call malloc. As the backtrace of H.J. shows, it quite
> clearly _does_ so :-)
>
ld.so can only call the malloc implementation internal to ld.so.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113874
--- Comment #28 from H.J. Lu ---
(In reply to Jakub Jelinek from comment #27)
> (In reply to H.J. Lu from comment #26)
> > Even if I compile ia32 glibc with -march=skylake, the _dl_tlsdesc_dynamic
> > slow
> > path doesn't touch XMM registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113874
--- Comment #26 from H.J. Lu ---
(In reply to Jakub Jelinek from comment #25)
> (In reply to H.J. Lu from comment #23)
> > > And i386/dl-tlsdesc.S needs to save/restore 387 and SSE regs?
> >
> > i386 doesn't preserve them in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113874
H.J. Lu changed:
What|Removed |Added
Resolution|--- |MOVED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113874
--- Comment #23 from H.J. Lu ---
(In reply to Jakub Jelinek from comment #22)
> BTW, does aarch64 dl-tlsdesc.S save SVE/SME register state (I only see fixed
> offsets in there), or are those call-saved?
> What about floating point registers in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113752
--- Comment #6 from H.J. Lu ---
I can reproduce it with r14-8930-g1e94648ab7b370
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113874
--- Comment #21 from H.J. Lu ---
(In reply to Florian Weimer from comment #20)
> (In reply to H.J. Lu from comment #19)
> > (In reply to Florian Weimer from comment #9)
> > > (In reply to H.J. Lu from comment #7)
> > > > > The __tls_get_addr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113874
--- Comment #19 from H.J. Lu ---
(In reply to Florian Weimer from comment #9)
> (In reply to H.J. Lu from comment #7)
> > > The __tls_get_addr call with the default approach potentially needs to
> > > solve
> > > the same problem, doesn't it?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113874
--- Comment #7 from H.J. Lu ---
(In reply to Florian Weimer from comment #6)
> > (In reply to H.J. Lu from comment #4)
> > > (In reply to H.J. Lu from comment #3)
> > > > Created attachment 57385 [details]
> > > > A patch
> > > >
> > > > Try
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113874
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113874
--- Comment #3 from H.J. Lu ---
Created attachment 57385
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57385=edit
A patch
Try this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113837
--- Comment #9 from H.J. Lu ---
(In reply to Jakub Jelinek from comment #7)
> (In reply to H.J. Lu from comment #5)
> > (In reply to Jakub Jelinek from comment #1)
> > > Ugh no, please don't.
> > > This is significant ABI change.
> > > First of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113837
--- Comment #6 from H.J. Lu ---
(In reply to Jakub Jelinek from comment #4)
> (In reply to H.J. Lu from comment #3)
> > (In reply to Jakub Jelinek from comment #2)
> > > OT, what is the state of the ia32 _BitInt ABI? I'd really like to enable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113837
--- Comment #5 from H.J. Lu ---
(In reply to Jakub Jelinek from comment #1)
> Ugh no, please don't.
> This is significant ABI change.
> First of all, zeroing even for signed _BitInt is very weird, sign extension
> for that case is more natural,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113837
--- Comment #3 from H.J. Lu ---
(In reply to Jakub Jelinek from comment #2)
> OT, what is the state of the ia32 _BitInt ABI? I'd really like to enable it
> in GCC 14 even for ia32 (and perhaps -mx32 if you care about that case).
I think we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113837
Bug ID: 113837
Summary: Zeroing unused bits in _BitInt can improve codegen
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113689
--- Comment #11 from H.J. Lu ---
(In reply to Jakub Jelinek from comment #10)
>
> Just the second hunk. I think with sorry call the compilation fails, so what
> you actually emit doesn't matter (one can see it with -pipe, sure).
Done.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113689
--- Comment #9 from H.J. Lu ---
Like this?
diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc
index f02c6c02ac6..ed0b0e19985 100644
--- a/gcc/config/i386/i386.cc
+++ b/gcc/config/i386/i386.cc
@@ -22785,10 +22785,10 @@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113689
--- Comment #6 from H.J. Lu ---
Fixed for GCC 14 so far.
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" } */
1 - 100 of 1125 matches
Mail list logo
