Comments (14)
So, it seems the bug can be resolved by one of the following:
language-c
should be specified as compatible only with GCC >= 7 or glibc < 2.26- recognition of
_Float128
added in #41 should be predicated on GCC version being >= 7 language-c
should define GCC version-related macros to pretend to be GCC 7 and above
from language-c.
Ok, I do understand that language-c is now incompatible with code that defines a typedef _Float128.
C++ is not supported anyway, but gcc < 7 with a recent glibc might be a problem.
Possible solution would be to add _Float128 as a typedef, not a builtin token (type checker warning only).
This way you could also "predicate" the definition of Float128, not possible with the current implementation as a Lexer token.
from language-c.
The GLIBC announcement says:
* On ia64, powerpc64le, x86-32, and x86-64, the math library now implements
128-bit floating point as defined by ISO/IEC/IEEE 60559:2011 (IEEE
754-2008) and ISO/IEC TS 18661-3:2015. Contributed by Paul E. Murphy,
Gabriel F. T. Gomes, Tulio Magno Quites Machado Filho, and Joseph Myers.
To compile programs that use this feature, the compiler must support
128-bit floating point with the type name _Float128 (as defined by TS
18661-3) or __float128 (the nonstandard name used by GCC for C++, and for
C prior to version 7). _GNU_SOURCE or __STDC_WANT_IEC_60559_TYPES_EXT__
must be defined to make the new interfaces visible.
And after a closer look, it seems that assuming it as a basic_type_name
in the Parser is wrong.
from language-c.
Ping? Will this issue be resolved?
from language-c.
This issue is hard to resolve if you want a "magic" solution that does not ask the language-c client to choose whether _Float128 should be a builtin typedef.
As said before, it would be feasible, although a major change, to remove _Float128 from the lexer and add it to the list of builtin typedefs, and then add a way to select whether _Float128 is a builtin typedef. The major change is that selecting different C dialects is not supported at the moment, so you need a new API. I guess that is not a realistic option.
For the users that are affected because they use glib >= 2.26 and gcc preprocessor < 7, it might be sufficient to call the gcc preprocessor in a way that it pretends to supports _Float128. I do not know if that is possible, but if it can be done via some argument parsed to the preprocessor, that would be a simple and pragmatic solution that does not even require a language-c change.
If it is not possible to workaround the issue with preprocessor options, I would suggest the first option suggested by @jchia, and simply state that code that re-typedefs _Float128 is not supported.
from language-c.
@visq I have been attempting to perform the fix suggested by @jchia:
recognition of _Float128 added in #41 should be predicated on GCC version being >= 7
My current approach is this diff in src/Language/C/Parser/Lexer.x
:
+#if MIN_TOOL_VERSION_gcc(7, 0, 0)
idkwtok ('_' : '_' : 'f' : 'l' : 'o' : 'a' : 't' : '1' : '2' : '8' : []) = tok 10 CTokFloat128
idkwtok ('_' : 'F' : 'l' : 'o' : 'a' : 't' : '1' : '2' : '8' : []) = tok 9 CTokFloat128
+#endif
I am going to play with this approach. Are there any gotchas I need to be worried about? The above patch does build with gcc7
. I don't really have a way of testing gcc <7 with newer glibc, that I can think of... Is there a distro I can whip up a VM with and dig into this scenario deeper? I know we can't really support both types of C code, but if there is a way to suppress lexing the token as a keyword in gcc<7 then I can feel this issue will be put to rest (hopefully).
from language-c.
@krakrjak Good idea! You only want to #if _Float128, not __float128 though. If this works, let's merge it and publish a bugfix release.
In the c2hs issue, @peti reported the problem still affects Nix (haskell/c2hs#192 (comment)).
from language-c.
@krakrjak @visq This seems to be confusing the compiler that's installed at the time that language-c is built, with the compiler that's installed when language-c is running. Those are often the same, but they don't have to be.
I don't really have a better suggestion, however. (In my own downstream project I can afford to do some preprocessor hacks to define _Float128
away when gcc is new enough.)
from language-c.
@lambdageek you are so right... I'm really not sure how we would inject this detection purely at runtime...
from language-c.
@lambdageek you are right, relying on build time gcc version is probably not ideal; if you update to gcc7 later, there is no simple way to specify that you need to update language-c, too.
We could introduce a Cabal flag for _Float128; then it is up to the package manager or the user to decide whether _Float128 is needed.
Alternatively, we could ask (affected) clients to rename _Float128 via #define.
Opinions?
from language-c.
I guess one thing that I'm unclear about is why _Float128
needs to be a lexer token. Can't it just be a tyident
that's optionally available in Language.C.Parser.Builtin.builtinTypeNames
? Is it really important that it has its own token in the lexer? (It will reduce as a typedef_type_specifier
instead of a basic_type_specifier
in the parser, but i'm not sure if there are any consequences to that.)
The next suggestion: can we make builtinTypeNames
a function configurable at runtime and leave it to downstream projects to detect GCC and configure the parser appropriately?
As a practical matter, we can:
- First change
builtinTypeNames
with a preprocessor pragma and do a minor version bump oflanguage-c
just to unblock anyone downstream hampered by GCC 7 + glibc 2.26 - and then do a major version bump where the set of builtin type name is somehow configurable so downstreams can do a runtime check.
from language-c.
@lambdageek No, it does not need its own lexer token. As I wrote before in this thread, adding it to builtin typedefs is a possible solution, but requires an API change to be runtime configurable.
The built-time configured workaround will work either way. If a cabal flag is sufficient, I'd go for that.
from language-c.
In glibc-2.27, there are now also _Float32
, _Float64
, _Float32x
, _Float64x
and _Float123x
(I'm not sure whether this last one is a new addition). I don't think they were present in glibc-2.27. language-c fails to parse them on my Arch Linux machine. I think these are the same problem so I mention them here instead of a new issue.
I'm getting error messages that look like this:
/usr/include/stdlib.h:140: (column 17) [ERROR] >>> Syntax error !
The symbol `strtof32' does not fit here.
This error is for code that looks like this:
#if __HAVE_FLOAT32 && __GLIBC_USE (IEC_60559_TYPES_EXT)
extern _Float32 strtof32 (const char *__restrict __nptr,
char **__restrict __endptr)
__THROW __nonnull ((1));
#endif
from language-c.
@jchia Thanks for the report. The missing types belong to #52, this ticket was about the new types conflicting with typedefs in case of an old gcc preprocessor.
from language-c.
Related Issues (20)
- __label__ LABEL must precede all other declarations in a block HOT 2
- Semantic analysis support for Float128 (Unexpected typespec: CFloat128Type) HOT 1
- Provide NFData instances for AST data types
- Towards a more complete Analysis.Export
- Support all IEC 60559 types (_Float{32,64,128},_Float{32,64,128}x)
- [Analysis] Trav ought to be a monad transformer HOT 2
- Problem generating function binding with c2hs HOT 7
- language-c-0.8 fails to parse fa.h / stdio.h HOT 2
- Update package on hackage HOT 1
- c2hs fails to parse lzlib.h HOT 2
- Make a hackage release for GHC 8.8
- What are TyAny and TyFloatN supposed to represent? HOT 1
- sizeofType is very broken
- GCC preprocessor output generated in non-ASCII locales cannot be processed HOT 2
- 0-based line number directives generate errors. HOT 1
- Possible __asm__ syntax with trailing colon in parameters HOT 1
- Parse errors when parsing macOS system headers HOT 1
- Build failure with GHC 7.8 HOT 2
- Add support for omitting braces in initializer lists HOT 1
- Missing support for `__uint128_t` on ARM64 (Apple M1) HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from language-c.