https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103623
--- Comment #34 from Segher Boessenkool ---
*** Bug 105334 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103623
Kewen Lin changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103623
--- Comment #32 from CVS Commits ---
The master branch has been updated by Segher Boessenkool :
https://gcc.gnu.org/g:0508f0b810985f4a8543ce44701ec7330ef29796
commit r12-8091-g0508f0b810985f4a8543ce44701ec7330ef29796
Author: Segher Boessenkool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103623
--- Comment #31 from Kewen Lin ---
Thanks for the comments, Segher and Peter! Your comments answered my question
in mind that the current unpack/pack pattern supports are complete or not.
IIUC, to cover it for both soft-float and hard-float case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103623
--- Comment #30 from Segher Boessenkool ---
Btw, does this issue exist for the corresponding __builtin_{un,}pack_ibm128
builtins as well?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103623
--- Comment #29 from Segher Boessenkool ---
(In reply to Peter Bergner from comment #28)
> (In reply to Segher Boessenkool from comment #27)
> > OTOH, it makes no sense to test if we have hard float. The pack and unpack
> > builtins should work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103623
--- Comment #28 from Peter Bergner ---
(In reply to Segher Boessenkool from comment #27)
> OTOH, it makes no sense to test if we have hard float. The pack and unpack
> builtins should work (and work the same) whenever long double is
> double-do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103623
--- Comment #27 from Segher Boessenkool ---
OTOH, it makes no sense to test if we have hard float. The pack and unpack
builtins should work (and work the same) whenever long double is double-double.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103623
--- Comment #26 from Kewen Lin ---
Created attachment 52474
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52474&action=edit
Untested patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103623
--- Comment #25 from Kewen Lin ---
The key difference from the previous bif support is that: previously we checked
TARGET_HARD_FLOAT but now we didn't. I think we still need to check it, as the
document here
https://gcc.gnu.org/onlinedocs/gcc/Ba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103623
Kewen Lin changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103623
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103623
--- Comment #23 from Arseny Solokha ---
And, for the record:
(gdb) p TARGET_LONG_DOUBLE_128
$1 = true
(gdb) p TARGET_HARD_FLOAT
$2 = false
(gdb) p TARGET_IEEEQUAD
$3 = 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103623
--- Comment #22 from Arseny Solokha ---
(In reply to Kewen Lin from comment #21)
> After typing these checks, I just tried and realized that my local
> cross-build on ppc64le can reproduce this if I specify -mlong-double-128. So
> Arseny's local
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103623
Kewen Lin changed:
What|Removed |Added
Last reconfirmed|2021-12-10 00:00:00 |2021-12-27
--- Comment #21 from Kewen Lin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103623
--- Comment #20 from Kewen Lin ---
(In reply to Arseny Solokha from comment #19)
> (In reply to Kewen Lin from comment #17)
> > (In reply to Arseny Solokha from comment #16)
> > > Could there be any ld, or as, or glibc features involved that gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103623
--- Comment #19 from Arseny Solokha ---
(In reply to Kewen Lin from comment #17)
> (In reply to Arseny Solokha from comment #16)
> > Could there be any ld, or as, or glibc features involved that gcc's
> > configure detects at build time?
>
> bt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103623
--- Comment #18 from Arseny Solokha ---
(In reply to Kewen Lin from comment #17)
> (In reply to Arseny Solokha from comment #16)
> > Could there be any ld, or as, or glibc features involved that gcc's
> > configure detects at build time?
>
> Go
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103623
--- Comment #17 from Kewen Lin ---
(In reply to Arseny Solokha from comment #16)
> Could there be any ld, or as, or glibc features involved that gcc's
> configure detects at build time?
Good point, what's the version of binutils you used? Does
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103623
--- Comment #16 from Arseny Solokha ---
Could there be any ld, or as, or glibc features involved that gcc's configure
detects at build time?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103623
--- Comment #15 from Kewen Lin ---
>
> I tried it on a x86_64 cfarm machine:
>
> /home/linkw/gcc/gcc-test/configure --host=x86_64-pc-linux-gnu
> --target=powerpc-e300c3-linux-gnu --build=x86_64-pc-linux-gnu
> --prefix=/home/linkw/gcc/install/g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103623
--- Comment #14 from Kewen Lin ---
> % powerpc-e300c3-linux-gnu-gcc-12.0.0 -v
> Using built-in specs.
> COLLECT_GCC=powerpc-e300c3-linux-gnu-gcc-12.0.0
> COLLECT_LTO_WRAPPER=/usr/libexec/gcc/powerpc-e300c3-linux-gnu/12.0.0/lto-
> wrapper
> Targe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103623
--- Comment #13 from Arseny Solokha ---
(In reply to Kewen Lin from comment #12)
> Could you double check? If it still failed, could you share your
> configuration?
% powerpc-e300c3-linux-gnu-gcc-12.0.0 -v
Using built-in specs.
COLLECT_GCC=pow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103623
--- Comment #12 from Kewen Lin ---
(In reply to Arseny Solokha from comment #11)
> Unfortunately, I still have exactly the same ICE on this testcase w/ 12.0.0
> alpha20211219 snapshot:
>
> % powerpc-e300c3-linux-gnu-gcc-12.0.0 -mcpu=401 tt.c
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103623
Arseny Solokha changed:
What|Removed |Added
Resolution|FIXED |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103623
Bill Schmidt changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103623
--- Comment #9 from CVS Commits ---
The master branch has been updated by William Schmidt :
https://gcc.gnu.org/g:74aeb9726756aa79c21028712c26910866e33026
commit r12-5963-g74aeb9726756aa79c21028712c26910866e33026
Author: Bill Schmidt
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103623
--- Comment #8 from Bill Schmidt ---
Patch posted here:
https://gcc.gnu.org/pipermail/gcc-patches/2021-December/586712.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103623
--- Comment #7 from Arseny Solokha ---
> Arseny, does this properly diagnose the issue for you?
Sure, thanks. But please note that I don't do any real computations on 32-bit
powerpc. I've filed this series of PRs during my regular testing of th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103623
--- Comment #6 from Bill Schmidt ---
With a quick and dirty patch to implement this, I get:
$ /home/wschmidt/gcc/build/gcc-e300/gcc/xgcc -c -O2 pr103623.c
-B/home/wschmidt/gcc/build/gcc-e300/gcc -mcpu=401
pr103623.c: In function 'main':
pr10362
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103623
--- Comment #5 from Bill Schmidt ---
Agreed that this needs a new attribute, and digging through the macros used to
guard the associated patterns, this really does need to be restricted to the
case when long double is implemented by IBM-128. Sa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103623
Peter Bergner changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103623
Bill Schmidt changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |wschmidt at gcc dot
gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103623
--- Comment #2 from Kewen Lin ---
> One fix seems to introduce one stanza for 128bit long double like previous
> RS6000_BTM_LDBL128 which is enabled only if (TARGET_LONG_DOUBLE_128 &&
> TARGET_HARD_FLOAT && !TARGET_IEEEQUAD), and guard
> __buil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103623
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |12.0
Summary|error: unable t
35 matches
Mail list logo