Bug 20991 - __int128 type support
Summary: __int128 type support
Status: NEW
Alias: None
Product: gdb
Classification: Unclassified
Component: exp (show other bugs)
Version: HEAD
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on: 16225
Blocks: 21185
  Show dependency treegraph
 
Reported: 2016-12-22 21:52 UTC by Tom Tromey
Modified: 2018-04-30 16:32 UTC (History)
0 users

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tom Tromey 2016-12-22 21:52:25 UTC
I tried a couple experiments with __int128 and found some gdb issues.

My test code:

__int128 x = 72;

I compiled with -g -c then ran gdb on the .o.

Printing kind of works, but chooses hex by default and zero-pads:

(gdb) p x
$1 = 0x00000000000000000000000000000048

Specifying decimal still zero-pads, which looks very weird:

(gdb) p/d x
$2 = 00000000000000000000000000000072

Addition doesn't work:

(gdb) p x + 5
That operation is not available on integers of more than 8 bytes.
Comment 1 Tom Tromey 2017-02-21 22:19:47 UTC
One super intrusive option would be to use GMP everywhere.

Another possibility would be to redefine LONGEST as __int128
where available.
Comment 2 Tom Tromey 2017-06-02 19:22:42 UTC
Handling the printing in bug 16225, so maybe this bug could be
for the operations.  See some discussion in bug 21185 for how to do that.
Comment 3 Tom Tromey 2018-04-30 16:32:55 UTC
Another issue is that c-exp.y has productions for things like
"unsigned long" and "long unsigned" -- but there isn't one for
__int128.  This came up during the alignment patch.