Re: Two new proposals to the upcoming C2X standard
On 28/05/2020 23:01, Xavier Del Campo Romero via Gcc wrote: Hello gcc team, I have sent the following proposals to the committee, but they require them to be implemented at least into two major compilers, so I am proposing them to be implemented into gcc. This is going to be a rather lengthy e-mail, so TL;DR: Proposal 1: New pointer-proof keyword _Lengthof to determine array length Motivation: solve silent bugs when a pointer is accidentally used instead of an array In gcc, the simple "#define ARRAY_SIZE(a) sizeof (a) / sizeof *(a)" gives a compile-time warning if passed a pointer, since the introduction of "-Wsizeof-pointer-div" in -Wall in gcc 8. I am not convinced that anyone who would be careful enough in their coding to use such a new "_Lengthof" feature would not already be using "-Wall" at least. So for gcc, the new keyword would, I think, be useless. And for any compiler without an equivalent warning (clang has it from version 7), it would likely to be easier to add the warning rather than the keyword. Many people have figured out alternative "ARRAY_SIZE" macros that work with existing compilers and give compile-time warnings on naked pointers. But like your suggestion below, they rely on compiler extensions such as gcc's "typeof". So my counter-proposal for you would be to recommend gcc's "typeof" as a new keyword (spelt "_Typeof", with "typeof" as a macro in , in solid C tradition). Then you have a feature that has a long-established history in two major compilers (gcc and clang, at least), has been massively used in real-world code for decades, and has a huge range of useful use-cases. Get "typeof" into the C standards and many people will thank you! And then your _Lengthof becomes a simple macro that can be put in a standard header file, and needs no established implementation to be acceptable. (And you don't need any help from gcc or clang, except perhaps for describing the details of the semantics of "typeof".)
Re: PCH test errors
On 29/05/2020 01:00, Alexandre Oliva wrote: I understand the problem, and I'm tempted to say it was a latent preexisting problem. gcn-hsa.h defines -mlocal-symbol-id=%b in CC1_SPEC. This is a target option not marked as pch_ignore, so option_affects_pch_p returns true for it, and default_pch_valid_p in targhooks.c compares the saved option in the PCH file with the active option in the current compilation. Thank you for the careful analysis. I would have struggled to get there myself. That option is the vestige of a horrible, ugly workaround for an ELF loader bug in the GPU drivers, in which it would refuse to load a binary that had the same local symbol defined multiple times (e.g. from linking together .o files each containing the same local name). That bug has been fixed in the driver, and I don't think the name mangling was ever committed to the upstream toolchain, but the (now inactive) option remains. I don't recall why; it may have been for backward compatibility, or it may have been an unintentional omission. Either way, I don't think we need it in GCC 11, so I can just rip it out. Thanks again Andrew
Re: Two new proposals to the upcoming C2X standard
On Mai 29 2020, David Brown wrote: > So my counter-proposal for you would be to recommend gcc's "typeof" as a > new keyword (spelt "_Typeof", with "typeof" as a macro in , > in solid C tradition). Or call it _Decltype/decltype, following C++. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: Two new proposals to the upcoming C2X standard
* Andreas Schwab: > On Mai 29 2020, David Brown wrote: > >> So my counter-proposal for you would be to recommend gcc's "typeof" as a >> new keyword (spelt "_Typeof", with "typeof" as a macro in , >> in solid C tradition). > > Or call it _Decltype/decltype, following C++. But please only if it cannot be applied to types. (__typeof works for both types and expressions, decltype only for expressions.) Thanks, Florian
Re: Two new proposals to the upcoming C2X standard
* Xavier Del Campo Romero via Gcc: > I have sent the following proposals to the committee, but they require > them to be implemented at least into two major compilers, That seems to be an odd requirement. Once implement in GCC and Clang, there is every incentive not submit it for standardization because it will likely be standardized in an incompatible way. Thanks, Florian
Re: Two new proposals to the upcoming C2X standard
在 2020/5/29 18:35, Andreas Schwab 写道: > On Mai 29 2020, David Brown wrote: > >> So my counter-proposal for you would be to recommend gcc's "typeof" as a >> new keyword (spelt "_Typeof", with "typeof" as a macro in , >> in solid C tradition). > > Or call it _Decltype/decltype, following C++. > > Andreas. > They are not the same thing. When applied on an expression, C++ `decltype()` may yield a reference type, but GCC's `typeof()` doesn't. -- Best regards, LH_Mouse signature.asc Description: OpenPGP digital signature
Re: [PATCH 0/5] some vxworks patches
Hi Rasmus, > On 26 May 2020, at 16:52, Rasmus Villemoes wrote: > > Hi Olivier et al > > I'm having quite a bit of trouble getting gcc 10 to build for our > vxworks 5 (5.5.1) target. Thanks for your message. VxWorks 5 was transitioned to End Of Life long ago so we're not testing for it any more. I have more input to convey but can't do this just now. I'll get back to you on this next week, probably through the gcc-patches list. Thanks, Olivier
gcc-9-20200529 is now available
Snapshot gcc-9-20200529 is now available on https://gcc.gnu.org/pub/gcc/snapshots/9-20200529/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 9 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-9 revision 2631d84ba7dedc3c5c9f77e7065fbfbc11876ca6 You'll find: gcc-9-20200529.tar.xzComplete GCC SHA256=9e4a344ec74e91d4d8263bc84012733f2b6d3d272a19d2059c8312cda02894f2 SHA1=01917363e16e52478f737d9aea7fd7e0c118d347 Diffs from 9-20200522 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-9 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
