[C++11] Reclaiming fixed-point suffixes for user-defined literals.
Greetings, Now that C++11 user-defined literals are in trunk I was thinking about reclaiming some of the numeric suffixes that are currently recognized by gcc in the preprocessor. The C++11 spec stipulates that any suffix that is recognized by the implementation is not allowable as a user-defined literal suffix in c++. This prevents C++ from hijacking 123LL, 1.234L, etc. On the other hand, there are several numeric literal suffixes that are recognized and used as gnu extensions. One class of suffixes stands out in this connection: fixed-point literals. These end in 'k' or 'r' and can optionally be unsigned by starting with 'u' and optionally have a size 'h', 'l', 'll'. The difference for these suffixes is that fixed-point literals are explicitly rejected by the c++ front end. Attempts to use such literals: int i= 1.23k; results in 'error: fixed-point types not supported in C++'. So I ask the question: Should I make a simple change to libcpp to allow fixed-point literal suffixes to pass to the user-defined literal code in c++11 mode? Thanks, Ed Smith-Rowland P.S. There are other suffixes that might be reclaimed as well such as 'i', 'I', 'j', 'J' for complex integral or floating point imaginary numbers and others. These might be more difficult or impossible to reclaim for C++11 because these might be allowed and used in gnu-C++ and it might break existing code.
Re: Re: [RFH] A simple way to figure out the number of bits used by a long double
Feb 26, 2010 01:43:15 PM, sch...@linux-m68k.org wrote: Paolo Carlini writes: > I'm tired. Anyway, I meant of course the size of the *data bits*, using > your terminology. For *some* formats, like x87, where there are no > holes, no padding bits in the middle of the representation, that is all > I would need. In the meanwhile, Andreas made me notice that > unfortunately this is not the general case. Thanks again about that. Even the x87 floating point format has don't-care bits in some cases. Andreas. Is this when denormalizing? Ed -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Re: [C++-0x] User-defined literals.
Sep 21, 2010 03:56:25 PM, rodrigorivasco...@gmail.com wrote:
>> 3. The big one: Getting the integer(long long) and float(long double)
>> suffixes that are not used by gcc out of the preprocessor. Then we
>can
>> build the calls.
>
>Just my two cents:
>Add an output parameter to the function "cpp_classify_number()"
>(libcpp/expr.c) to get the user-defined suffix.
>It should be optional, so that it is ignored when not needed.
>
>unsigned int
>-cpp_classify_number (cpp_reader *pfile, const cpp_token *token)
>+cpp_classify_number (cpp_reader *pfile, const cpp_token *token, char
>**suffix) //exposition only!
>
>Then in the function "c_lex_with_flags()" (c-family/c-lex.c) retrieve
>the suffix and pass it on to the function "interpret_integer()" /
>"interpret_float()", that should add an input parameter accordingly.
>
>The function "interpret_{integer,float}()" calls
>"build_int_cst_wide()" / "build_real()" to build the constant.
>Then
>you can build a tree for the identifier (with "get_identifier()",
>perhaps) and attach it somehow to the constant.
>You may consider creating a new TREE type for that...
>
>I'm afraid that you have quite some job here...
>
>Best regards.
>Rodrigo
>
Rodrigo,
Thank you for taking a look at this. These are helpful hints if I need to go
this route.
What made the string types and the char types so easy is that the suffix was
sent to the parser as a separate token. I was able to look ahead and parse the
name and look for a function (which I got working with cp_parser_lookup_name).
I'm holding out for rolling back the lexer in some way that won't break
everything and emitting the (unrecognized by cpp ) suffix as a separate
identifier token. I'm thinking the cp_lexer_* routines or maybe a new one in
parser.c would be worth trying. Then the code I have now would just work
(except I would still need enhanced lookup rules as discussed earlier). It
would be nice to have all types on the same page too.
Regards,
Ed
Re: Re: [C++-0x] User-defined literals.
Oct 4, 2010 11:26:15 AM, ja...@redhat.com wrote:
>On 09/17/2010 02:25 AM, Ed Smith-Rowland wrote:
>> I am slowly working on user defined literals for C++-0x.
>
>Thanks! Please send future patches to gcc-patches and me directly.
>
>Looking over your patch, I see you're doing a significant amount of it
>in the parser, which is incorrect; the draft says that a user-defined
>literal is a single preprocessing token, so
>
>1.2QQ
>
>(one token) is different from
>
>1.2 QQ
>
>(two tokens).
Right. I've resigned myself to having to scan for these as a single token.
That (and Real Life) is what is slowing me down.
I think I may have to create new tree types for these literals.
>> Anyway, I managed to parse things like
>>
>> long double
>> operator"" _foo(long double x) { return 2.0L * x; }
>>
>> The result is a normal function that I can either call like
>> operator "" _foo(1.2L);
>> or just
>> _foo(1.2L);
>
>You shouldn't be able to call it as just _foo(1.2L); an operator name is
>
>different from a normal function name.
According to 13.5.8/7 :
[ Note: literal operators and literal operator templates are usually invoked
implicitly through user-defined
literals (2.14.8). However, except for the constraints described above, they
are ordinary namespace-scope
functions and function templates. In particular, they are looked up like
ordinary functions and function tem-
plates and they follow the same overload resolution rules. Also, they can be
declared inline or constexpr,
they may have internal or external linkage, they can be called explicitly,
their addresses can be taken, etc.
— end note ]
>> 1. A warning or error if a user chooses a suffix that gcc uses. I was
>surprised that 'w', 'q', 'i', 'j' and several others
>were used by gcc for floats. I won't be the only one.
>> The standard is clear that implementations get first crack at these but
>it shouldn't be a mystery or a surprise when things don't work as expected.
>
>> 2. Should we at least pedwarn about user not starting a suffix with an
>underscore? Probably. Non-underscore suffixen are reserved to the
>implementation
>
>but I think a user should be able to use one if it's not used by gcc
>though the user risks non-portability and potential but unlikely future
>breakage.
>
>Can you point me to the relevant wording? I'm not finding it.
I *always* have trouble finding this ;-)
17.6.3.3.5 User-defined literal suffixes
[usrlit.suffix]
Literal suffix identifiers that do not start with an underscore are reserved for
future standardization.
>> 3. The big one: Getting the integer(long long) and float(long double)
>> suffixes
>that are not used by gcc out of the preprocessor. Then we can build the calls.
>
>Yep, I think we want a new CPP token type for user-defined literals that
>encapsulates both the raw literal and the suffix.
>
>> 4. If, for long long and long double the usual signature is not found,
>first look for a: _suffix(char*) and failing that: template _suffix().
> So we'll need to make the lookup of these two signatures more complex.
>
>Right, this will need a new overload resolution function. 2.14.5 tells
>you how it works; look at the overload set, see if it contains a
>particular signature, and build up a normal call as appropriate.
>
>Jason
>
Thanks for looking this over.
Ed
Re: Re: Merging Apple's Objective-C 2.0 compiler changes
Nov 2, 2010 01:23:28 PM, jwakely@gmail.com wrote: On 2 November 2010 15:13, Ed Smith-Rowland wrote: > > It would be great if you all could update > http://gcc.gnu.org/gcc-4.6/cxx0x_status.html and related with all the great > work that has gone into Objective-C++ recently. http://gcc.gnu.org/gcc-4.6/changes.html would make more sense! That's what I meant, sorry!
Re: Re: Merging Apple's Objective-C 2.0 compiler changes
Nov 2, 2010 01:23:28 PM, jwakely@gmail.com wrote: On 2 November 2010 15:13, Ed Smith-Rowland wrote: > > It would be great if you all could update > http://gcc.gnu.org/gcc-4.6/cxx0x_status.html and related with all the great > work that has gone into Objective-C++ recently. http://gcc.gnu.org/gcc-4.6/changes.html would make more sense! That's what I meant, sorry!
Re: Re: [C++14] Admit C++ keywords as literal suffixes.
On 06/18/13, Jonathan Wakely wrote: On 18 June 2013 07:04, Ed Smith-Rowland wrote: > I understand that the literal operators for complex numbers for C++14 > faltered at least in part because of the perceived ugliness of the float > operator: > > constexpr complex > operator"" i_f(); // fugly > > The obvious choice > constexpr complex > operator"" if(); > > failed because 'if' is a keyword. The 'if' keyword can never be exposed in > this context either by usage in a literal or by explicit call. > > Allowing keywords as literal operator suffixes turns out to be a 6-liner if > gcc. I actually think *disallowing* them is a bit of a bug. (Not sure if > it was me or the standard). The standard disallowed them, but that was changed by DR 1473 so you can define operator ""if now (with no whitespace between the string-literal and suffix, IIUC) See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3675.html#1473 IMHO you should implement exactly that resolution, not just a kluge to allow keywords. I did not see this DR and that it passed. I just heard "something was in the works". This resolution seems eminently sensible. I withdraw my kludge and will work on DR 1473 implementation. Thanks, Ed
Re: Re: C++98/C++11 ABI compatibility for gcc-4.7
On 06/18/12, Paolo Carlini wrote: > > ... I suppose that for 4.8.0 we really want to bump the ABI, for many other > reasons too, and be done with it. > > Paolo. Would this bump include everything? Such as rebasing std::ios_base::failure from std::exception to std::system_error and everything else? I think we'd best get the whole thing over with at once. How is libstdcxx_so_7-2-branch? Perhaps instead of messing with tr2 I should help here? Ed
[4.4 Regression] Boostrap failed on obj-c++ "too many arguments to function 'bui
All, I logged the bootstrap fail on obj-c++ as 37335. Ed Smith-Rowland
Re: contributing advice
3dw...@verizon.net On Monday, January 29, 2024 at 03:13:07 PM EST, Jonathan Wakely via Gcc wrote: On Mon, 29 Jan 2024 at 19:15, Claudio Bantaloukas via Gcc wrote: > > On 26/01/2024 17:51, Florin Mateoc via Gcc wrote: > > Hi all, > > > > I am an experienced software developer, with an interest in compilers, and > > an admirer of gcc. > > I would like to contribute, hopefully reusing some of my existing skills, > > experience and interests, but unfortunately the (current) overlap is not > > great, so I am asking for some guidance/reality check. > > Hi Florin, > I'm also just starting to contribute and it's a bit daunting, you're not > the only one! :). > > Why not start with an existing bug report? https://gcc.gnu.org/bugs/ has > a link to bugzilla, which is full of opportunities! Specifically, have a look at https://gcc.gnu.org/wiki/EasyHacks Which is one of the links from the https://gcc.gnu.org/wiki/GettingStarted page. I seems like the recent additions to the C++ standard library have a lot of things that look like a good first project.Like the flat containers (flat_map and flat_set) for example orInterfacing std::bitset with std::string_view https://wg21.link/P2697R1.OrInterfacing string streams with std::string_view https://wg21.link/P2495R3. Assuming these aren't being worked on by someone else already. > > Cheers, > Claudio > > > While I did start my career (a long time ago (my first programming > > language, in college, was Fortran (77), using punch cards)) writing > > software in assembly for bare metal and debugging it with an oscilloscope > > and a serial interface, and I also wrote (in Borland C++) a remote debugger > > for a micro-controller development board, for a long time now I've only > > been using higher-level languages, and my C is quite rusty. > > I am an expert-level programmer in Smalltalk, Java and JavaScript, but I am > > aware that these are not even client languages, let alone useful/used for > > gcc development. > > As far as compiler-related experience, I have worked on a type inferencer > > for Smalltalk and on a Smalltalk to Java transpiler, part of a proprietary > > tool that has been used to migrate a very large and successful Smalltalk > > financial application to Java. I have also written an open-source > > transpiler from Smalltalk to JavaScript > > (https://github.com/fmateoc/JsSqueak) > > that can compile a Smalltalk image to JavaScript code that can be run in a > > browser. > > > > With regards to potential contribution areas, among the supported > > languages, Objective-C is close enough to Smalltalk that I think I should > > be able to contribute, but I am not sure how much interest there is for it, > > especially in its gcc incarnation. I was also thinking (without looking at > > the code, so this could be just wishful thinking) that I might try to work > > on something Gimple-related. Of course, this is just what I came up with, > > based on very incomplete information > > > > I would appreciate any thoughts/advice. > > > > Thank you, > > Florin
