https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119953
--- Comment #2 from Jonathan Wakely ---
Apparently nobody is testing this target often enough to catch regressions :-(
I was able to build for msp430 before GCC 15, so I'll bisect to find when it
broke.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120527
--- Comment #4 from Jonathan Wakely ---
Also the fact that libc++ is using those APIs probably means they can't be
removed now.
Does the same version of libstdc++.dylib need to work for both cases?
There's already a generic implementation in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120529
Bug ID: 120529
Summary: __reference_{converts,constructs}_from_temporary
ignore access control
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Keywords: accepts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120375
Alex Turjan changed:
What|Removed |Added
CC||aturjan at yahoo dot com
--- Comment #3 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120494
H.J. Lu changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120525
--- Comment #4 from H.J. Lu ---
var-tracking.cc has
if (fndecl == NULL_TREE)
fndecl = MEM_EXPR (XEXP (call, 0));
it doesn't look right.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120494
--- Comment #2 from GCC Commits ---
The master branch has been updated by H.J. Lu :
https://gcc.gnu.org/g:e1390c2c45186e4843b927e77a102d39a599374a
commit r16-1092-ge1390c2c45186e4843b927e77a102d39a599374a
Author: H.J. Lu
Date: Tue Jun 3 05:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120516
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120521
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120521
Andrew Pinski changed:
What|Removed |Added
Summary|wrong code at -O3 with |[14/15/16 Regregression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120522
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120525
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=120525
H.J. Lu changed:
What|Removed |Added
Last reconfirmed||2025-06-03
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120525
--- Comment #2 from Joseph S. Myers ---
Depending on the configuration, you may need -mlong-double-128.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113857
Bug 113857 depends on bug 100165, which changed state.
Bug 100165 Summary: fmov could be used to zero out the upper bits instead of
movi/zip or movi/ins with __builtin_shuffle and zero vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100165
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100165
Pengxuan Zheng changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120526
--- Comment #5 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #4)
> Another workaround is to do:
> ```
> size = strtoimax (str, &end, 10);
> if (!str) __builtin_unreachable();
> ```
This basically emulates what the nonnull a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120526
--- Comment #4 from Andrew Pinski ---
Another workaround is to do:
```
size = strtoimax (str, &end, 10);
if (!str) __builtin_unreachable();
```
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120526
--- Comment #3 from Andrew Pinski ---
Likewise using strtoll instead of strtoimax .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119953
--- Comment #1 from Gabriel Marcano ---
I've also run into this bug, and I've done some debugging. The problem, as the
log states, appears to be a constraint failure. Specifically, it looks like GCC
is trying to use R13 and R14 for the addsi3 in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120526
Andrew Pinski changed:
What|Removed |Added
See Also||https://sourceware.org/bugz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120526
--- Comment #1 from Andrew Pinski ---
>But clearly tuples[i].str is not NULL.
Not to the compiler since it looks like: ...
```
_1 = MEM[(const char * *)_24];
*_15 = 0;
size_16 = strtoimax (_1, &end, 10);
if (size_16 < 0)
goto ; [0.7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120528
Michael Meissner changed:
What|Removed |Added
Host||powerpc64le-unknown-linux-g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120528
Bug ID: 120528
Summary: Optimize zero extend to TImode when value is in a VSX
register on power10
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120527
--- Comment #3 from Iain Sandoe ---
Since XNU is public, it seems reasonable to make use of these.
Do you have anything in mind for a fallback for OS versions < 10.15 (we
certainly have folks building back to 10.13 for $dayjob).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120527
--- Comment #2 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #0)
> Darwin provides __ulock_wait and __ulock_wake which should be sufficient to
> implement the internals needed for efficient std::atomic::wait and
> std::atom
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120527
--- Comment #1 from Jonathan Wakely ---
And as noted at https://shift.click/blog/futex-like-apis/ ...
OpenBSD has a futex syscall so might be able to reuse the linux code:
https://man.openbsd.org/futex
FreeBSD has _umtx_op with similar functio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120527
Bug ID: 120527
Summary: Native platform wait on darwin
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120526
Bug ID: 120526
Summary: false negative warning at -O1 -Wall on fprintf %s
Product: gcc
Version: 15.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120525
Bug ID: 120525
Summary: [16 Regression] ICE in vartrack building glibc
memusage.c for s390-linux-gnu
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120524
Bug ID: 120524
Summary: `(__int128_var >> 127) & 1` is not optimized to
((unsigned __int128)__int128_var ) >> 127 in gimple
level
Product: gcc
Version: 16.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120510
--- Comment #1 from uecker at gcc dot gnu.org ---
A user visible bug is this, which is a regression since GCC 14.
int f(int [_Atomic]);
int f(int [_Atomic]);
int f(int [_Atomic]);
https://godbolt.org/z/fK8e5K6ax
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103750
--- Comment #21 from Thiago Macieira ---
(In reply to Hongtao Liu from comment #19)
> Looks like it's fixed by r16-170-ga670ebde399548.
>
> Now it generates decent code as
Thank you!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120514
--- Comment #6 from Jonathan Wakely ---
That would make sense, you were using something like:
$prefix/lib/gcc/x86_64-pc-linux-gnu/16.0.0/include-fixed/pthread.h
from an older build of GCC trunk, which was installed in Fedora 41 and so used
the o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99838
--- Comment #3 from GCC Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:0768ec0d32f570b1db13ca41b0a1506275c44053
commit r16-1090-g0768ec0d32f570b1db13ca41b0a1506275c44053
Author: Harald Anlauf
Date: Tu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116892
uecker at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99838
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120515
Andrew Pinski changed:
What|Removed |Added
Keywords||documentation
--- Comment #1 from Andre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51579
uecker at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120078
uecker at gcc dot gnu.org changed:
What|Removed |Added
Summary|[12/13/14/15/16 Regression] |[12/13/14/15 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120078
--- Comment #5 from GCC Commits ---
The master branch has been updated by Martin Uecker :
https://gcc.gnu.org/g:ba463f51469529ce4a9500a0c03fa1763a14817c
commit r16-1089-gba463f51469529ce4a9500a0c03fa1763a14817c
Author: Martin Uecker
Date: M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114022
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |15.2
Status|ASSI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101735
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Target Milestone|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120078
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2025-06-03
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102599
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |15.2
Status|ASSI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119856
Jerry DeLisle changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102599
--- Comment #4 from GCC Commits ---
The releases/gcc-15 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:e8a36b051587dccfc7c161ed4fb42c493212c71f
commit r15-9761-ge8a36b051587dccfc7c161ed4fb42c493212c71f
Author: Harald Anlauf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101735
--- Comment #16 from GCC Commits ---
The releases/gcc-15 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:819b6415b639710566e4cc535241d82ccd708f76
commit r15-9760-g819b6415b639710566e4cc535241d82ccd708f76
Author: Harald Anlauf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101735
--- Comment #15 from GCC Commits ---
The releases/gcc-15 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:25e46423bdfdf6e14cc1bc753f05b3b4fb5e8cc8
commit r15-9759-g25e46423bdfdf6e14cc1bc753f05b3b4fb5e8cc8
Author: Harald Anlauf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114022
--- Comment #3 from GCC Commits ---
The releases/gcc-15 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:e8a36b051587dccfc7c161ed4fb42c493212c71f
commit r15-9761-ge8a36b051587dccfc7c161ed4fb42c493212c71f
Author: Harald Anlauf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120523
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
Status|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120523
Bug ID: 120523
Summary: gcc.dg/tree-ssa/cswtch-6.c fails on aarch64
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Keywords: testsuite-fail
Severity: normal
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120518
--- Comment #2 from sandra at gcc dot gnu.org ---
OK, found it. The problem is the newly-added code that wraps the
condition/device_num expr in a cleanup_point. This screws up the code in
omp_device_num_check (in omp-general.cc) that detects sp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120522
Andrew Pinski changed:
What|Removed |Added
Keywords||wrong-code
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120522
--- Comment #1 from Andrew Pinski ---
The first difference between the 2 revisions is:
Before:
_45 = &ac + _31;
after:
_110 = (unsigned long) ∾
...
_69 = _31 + _110;
_45 = (unsigned char[23][23][23][23] *) _69;
in lim2.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120511
--- Comment #8 from Joseph S. Myers ---
Note that for *decimal* floating-point types, {0} should arguably not be
considered a universal zero initializer (it produces a DFP zero with quantum
exponent 0, whereas (positive) 0 with the least possibl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120522
Bug ID: 120522
Summary: [16 Regression] RISC-V: Miscompile at -O3 since
r16-449-gd884e9c5c74
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116892
--- Comment #12 from GCC Commits ---
The master branch has been updated by Martin Uecker :
https://gcc.gnu.org/g:bd773888eafe34fb990041462df6d3a3c8a4217d
commit r16-1087-gbd773888eafe34fb990041462df6d3a3c8a4217d
Author: Martin Uecker
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120514
--- Comment #5 from Jerry DeLisle ---
As a followup. Thanks for the hints about what is going on. I recently
upgraded from Fedora 41 to 42. The build I was attempting was a clean build, I
always start with an empty build directory.
I was susp
-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 16.0.0 20250603 (experimental) (GCC)
[543] %
[543] % gcctk -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116892
--- Comment #11 from uecker at gcc dot gnu.org ---
(In reply to Richard Earnshaw from comment #10)
> (In reply to uecker from comment #9)
> > (In reply to Richard Earnshaw from comment #8)
> > > Forward declarations of enums in C requires c23, wh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116892
--- Comment #10 from Richard Earnshaw ---
(In reply to uecker from comment #9)
> (In reply to Richard Earnshaw from comment #8)
> > Forward declarations of enums in C requires c23, when you can use the size
> > type specifier. For earlier versi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120518
sandra at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |sandra at gcc dot
gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120520
--- Comment #2 from Jakub Jelinek ---
Created attachment 61564
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61564&action=edit
gcc16-pr120520.patch
Untested implementation.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120519
Alfie Richards changed:
What|Removed |Added
CC||alfierichards at gcc dot
gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120516
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |15.2
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120517
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120517
--- Comment #2 from GCC Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:f605165ee4baf65a46a16692e3aaa13046cbd283
commit r16-1079-gf605165ee4baf65a46a16692e3aaa13046cbd283
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116892
--- Comment #9 from uecker at gcc dot gnu.org ---
(In reply to Richard Earnshaw from comment #8)
> Forward declarations of enums in C requires c23, when you can use the size
> type specifier. For earlier versions this isn't valid code.
Is is a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120520
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120520
Bug ID: 120520
Summary: [C2y] Implement N3466, Clarifications on null pointers
in the library
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120479
--- Comment #3 from Jeffrey A. Law ---
Oh, I didn't try the testcase, I was going off the fragments you posted. If
the incoming value in a7 is known to only have values 0/1, then absolutely yes.
In fact I added some support for these kinds of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116892
Richard Earnshaw changed:
What|Removed |Added
Keywords|ice-on-valid-code |ice-on-invalid-code
--- Comment #8 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120519
Bug ID: 120519
Summary: g++.target/powerpc/mvc-symbols1.C fail starting with
r16-965-g83eee43e998d0a
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120517
Richard Biener changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120502
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119692
Rainer Orth changed:
What|Removed |Added
CC||ro at gcc dot gnu.org
--- Comment #8 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120514
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107600
--- Comment #15 from Jonathan Wakely ---
Thanks for the fixes, uses the new built-ins since
r16-1077-gb32bf304793047
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119089
Jonathan Wakely changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120514
--- Comment #3 from Jonathan Wakely ---
This is just Bug 119089 again, which is not a gcc bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104928
Jonathan Wakely changed:
What|Removed |Added
Keywords||patch
--- Comment #18 from Jonathan W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119862
--- Comment #4 from ptomsich at gcc dot gnu.org ---
The runtime calls to __cyg_profile_func_exit and __cyg_profile_func_enter are
inserted for -finstrument-functions-once.
@Konstantinos: Why do we need as "{ dg-do run }" instead of "{ dg-do comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120518
Bug ID: 120518
Summary: nvptx offloading: "OpenMP: Handle more cases in
user/condition selector" regresses C++
'c-c++-common/gomp/metadirective-target-device-2.c'
Product:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119100
Paul-Antoine Arras changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119862
--- Comment #3 from Rainer Orth ---
Now that -mgeneral-regs-only is only passed on targets that support it, the
failure mode on Solaris/SPARC is the same as on Solaris/x86:
Excess errors:
Undefined first referenced
symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120517
Bug ID: 120517
Summary: [16 Regression] "For datarefs with big gap, split them
into different groups" vs. nvptx SLP vectorizer
Product: gcc
Version: 16.0
Status: UNCONFI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119100
--- Comment #5 from GCC Commits ---
The master branch has been updated by Paul-Antoine Arras :
https://gcc.gnu.org/g:b437418bc9547073ec2704398c85c52e060e1fab
commit r16-1071-gb437418bc9547073ec2704398c85c52e060e1fab
Author: Paul-Antoine Arras
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103750
--- Comment #20 from GCC Commits ---
The master branch has been updated by H.J. Lu :
https://gcc.gnu.org/g:4ab36e8e56280d774d4b5ef07b0838020ba20a6a
commit r16-1070-g4ab36e8e56280d774d4b5ef07b0838020ba20a6a
Author: H.J. Lu
Date: Tue Jun 3 17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103750
Hongtao Liu changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120516
--- Comment #1 from congli ---
Missing information: -fno-ivopts works for both issues.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120516
Bug ID: 120516
Summary: [15/16 Regression] wrong code at O3 with
"-fno-tree-slsr -fno-ipa-cp -fno-inline" from 15.1 and
above on x86_64
Product: gcc
Version: 15.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120504
--- Comment #9 from Sergei Trofimovich ---
I confirm gdb and llvm build successfully now. Thank you!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120515
Bug ID: 120515
Summary: darwin warning: ld: warning: -U option is redundant
when using -undefined dynamic_lookup
Product: gcc
Version: 15.1.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120479
--- Comment #2 from Paolo Bonzini ---
a7 is from line (1) which is a sltu instruction, so it has itself only bit 0
set.
I think it should be possible to generate (if_then_else (eq/ne X (const_int 0))
Y (const_int 0)) from (and (eq/ne X (const_i
95 matches
Mail list logo
