Skip to content

add support for __int128, __int128_t, __uint128_t#49

Merged
vogler merged 7 commits intodevelopfrom
int128
Oct 12, 2021
Merged

add support for __int128, __int128_t, __uint128_t#49
vogler merged 7 commits intodevelopfrom
int128

Conversation

@vogler
Copy link
Copy Markdown
Collaborator

@vogler vogler commented Oct 1, 2021 •
edited
Loading

Closes #41.
I left some TODOs where I wasn't sure.
Esp. if long long is already 128 bit on the machine, do we then want ikind ILongLong or IInt128?

(This machine-dependent ambiguity is a source of errors if one does not use CIL's functions but assumes e.g. long long to be of a certain size - might be better to let CIL just emit concrete int sizes like int32_t.)

vogler added 4 commits October 1, 2021 12:05
@vogler
Parse error: re-raise with captured inner backtrace
f565521
@vogler
add ikinds for __int128 and handle type specifiers
940d655 
Fixes 'Error: Invalid combination of type specifiers' for __int128.
TODO: still fails for any type starting with __ in structs:

~~~c
struct __darwin_arm_neon_state64
{
  int foo; // works
  __uint32_t __fpsr; // Parse error
}
~~~
@vogler
handle __int128 ikind in non-exhaustive pattern matchings
780b89c
@vogler
also handle __int128 where long long appeared (ag longlong src)
8b0d5d1
@vogler vogler requested a review from michael-schwarz October 1, 2021 10:56
@vogler
Copy link
Copy Markdown
Collaborator Author

vogler commented Oct 5, 2021

Works as intended. The Parse error for fields starting with __ was just due to a typo in the typedef.

michael-schwarz
michael-schwarz reviewed Oct 6, 2021
View reviewed changes
@MaskRay
Copy link
Copy Markdown

MaskRay commented Oct 9, 2021 •
edited
Loading

__int128_t and __uint128_t are also recognized as built-in types.

In particular, Nim generated C uses __uint128_t (e.g. with import tables) which I need to produce a self-contained C source file.

@vogler
Copy link
Copy Markdown
Collaborator Author

vogler commented Oct 12, 2021

Mh, the lexer/parser is a bit hard to understand. I just wanted to return two tokens UNSIGNED INT128 for __uint128_t, but then how should the lexer's state be adjusted?
Alternative would be an extra token, but that would require some special handling outside of the type_spec rule, which is also messy.

cil/src/frontc/cparser.mly

Line 959 in 7a912dd

| type_spec decl_spec_list_opt_no_named { SpecType (fst $1) :: $2, snd $1 }

@MaskRay For now you can use the option cppflags to include a header file with typedefs for __int128_t and __uint128_t like done here: https://github.com/goblint/analyzer/pull/311/files

@vogler
Copy link
Copy Markdown
Collaborator Author

vogler commented Oct 12, 2021

Added them as built-in named types on init and handled in cabs2cil. Should be fine to merge now.

michael-schwarz
michael-schwarz reviewed Oct 12, 2021
View reviewed changes
@vogler vogler changed the title add support for __int128 add support for __int128, __int128_t, __uint128_t Oct 12, 2021
@vogler vogler merged commit c16dddf into develop Oct 12, 2021
@vogler vogler mentioned this pull request Oct 12, 2021
Closed
@vogler vogler deleted the int128 branch October 13, 2021 07:33
vogler added a commit to goblint/analyzer that referenced this pull request Oct 14, 2021
@vogler
rm includes/arm64.h; use cil which supports 128bit ints
519405d 
goblint/cil#49
@michael-schwarz michael-schwarz mentioned this pull request Apr 1, 2022
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@michael-schwarz michael-schwarz michael-schwarz left review comments

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

Frontc.ParseError for arm/_structs.h on Apple M1

3 participants

@vogler @MaskRay @michael-schwarz