Has FSF stopped processing copyright paperwork?
On Tue, May 5, 2020 at 6:42 PM Kaylee Blake wrote: > > On 2/5/20 11:49 pm, H.J. Lu wrote: > > On Wed, Mar 18, 2020 at 6:46 PM Kaylee Blake via Binutils > > wrote: > >> > >> On 19/3/20 12:02 pm, H.J. Lu wrote: > >>> Kaylee, is your paper work with FSF in order? I will submit the updated > >>> patch set after your paper is on file with FSF. > >> > >> I'm waiting on a response from them at the moment. > >> > > > > Hi Kaylee, > > > > Any update on your paper work with FSF? > > > > Still waiting; apparently their work process has been dramatically > slowed by the whole COVID-19 situation. > > -- > Kaylee Blake > C is the worst language, except for all the others. Hi, I submitted a set of binutils patches: https://sourceware.org/pipermail/binutils/2020-March/13.html including contribution from Kaylee Blake . Can someone check if Kaylee's paperwork is on file with FSF? Thanks. -- H.J.
Re: Has FSF stopped processing copyright paperwork?
On Fri, Aug 7, 2020 at 3:14 PM H.J. Lu via Gcc wrote: > > On Tue, May 5, 2020 at 6:42 PM Kaylee Blake wrote: > > > > On 2/5/20 11:49 pm, H.J. Lu wrote: > > > On Wed, Mar 18, 2020 at 6:46 PM Kaylee Blake via Binutils > > > wrote: > > >> > > >> On 19/3/20 12:02 pm, H.J. Lu wrote: > > >>> Kaylee, is your paper work with FSF in order? I will submit the updated > > >>> patch set after your paper is on file with FSF. > > >> > > >> I'm waiting on a response from them at the moment. > > >> > > > > > > Hi Kaylee, > > > > > > Any update on your paper work with FSF? > > > > > > > Still waiting; apparently their work process has been dramatically > > slowed by the whole COVID-19 situation. > > > > -- > > Kaylee Blake > > C is the worst language, except for all the others. > > Hi, > > I submitted a set of binutils patches: > > https://sourceware.org/pipermail/binutils/2020-March/13.html > > including contribution from Kaylee Blake . > Can someone check if Kaylee's paperwork is on file with FSF? Don't see her in the list. Richard. > Thanks. > > -- > H.J.
Coding style for C++ constructs going forward
Hi, cc-ing the GCC mailing list, as we may want to use the same coding style for GDB and GCC. Yesterday I brought this topic up on IRC. I notice we started using more and more the "auto" keyword. In some cases, this is actually useful and makes the code a bit more compact. GDB has been using those more often, whereas GCC, for example, isn't using those too much. Looking at the coding standards for GCC (https://gcc.gnu.org/codingconventions.html), I don't see anything dictating best practices for "auto" use. I guess it is a consensus that "auto" is a good fit when dealing with iterators, lambda's and gnarly templates (but only when the type is already obvious from its use). There are other situations where "auto" may make things a little more cryptic when one wants to figure out the types of the variables. One example of this is when you have a longer function, and you use "auto" in a variable that lives throughout the scope of the function. This means you'll need to go back to its declaration and try to figure out what type this particular variable has. Pedro has pointed out LLVM's coding standards for "auto", which we may or may not want to follow/adopt: https://llvm.org/docs/CodingStandards.html#use-auto-type-deduction-to-make-code-more-readable It sounds like a reasonable idea to me. Thoughts? Are there other C++ constructs people think would benefit from a more formal style guideline? As we move to newer C++ standards over time, it is more likely we will start using newer constructs, and some of those may make the code potentially less readable.
Re: Coding style for C++ constructs going forward
Hi Luis, > cc-ing the GCC mailing list, as we may want to use the same coding style for > GDB and GCC. > > Yesterday I brought this topic up on IRC. I notice we started using more and > more the "auto" keyword. In some cases, this is actually useful and makes > the code a bit more compact. GDB has been using those more often, whereas > GCC, for example, isn't using those too much. > > Looking at the coding standards for GCC > (https://gcc.gnu.org/codingconventions.html), I don't see anything dictating > best practices for "auto" use. > > I guess it is a consensus that "auto" is a good fit when dealing with > iterators, lambda's and gnarly templates (but only when the type is already > obvious from its use). > > There are other situations where "auto" may make things a little more > cryptic when one wants to figure out the types of the variables. One example > of this is when you have a longer function, and you use "auto" in a variable > that lives throughout the scope of the function. This means you'll need to > go back to its declaration and try to figure out what type this particular > variable has. > > Pedro has pointed out LLVM's coding standards for "auto", which we may or > may not want to follow/adopt: > https://llvm.org/docs/CodingStandards.html#use-auto-type-deduction-to-make-code-more-readable > > It sounds like a reasonable idea to me. Thoughts? Thanks for the pointer to LLVM's CS guideline. FWIW, it's explaining quite nicely what I had in the back of my mind. I think it would be a good starting point, at least for discussing whathever guidelines we might want to adopt in GDB. > Are there other C++ constructs people think would benefit from a more formal > style guideline? As we move to newer C++ standards over time, it is more > likely we will start using newer constructs, and some of those may make the > code potentially less readable. -- Joel
Re: Coding style for C++ constructs going forward
On Fri, Aug 07, 2020 at 07:56:03AM -0700, Joel Brobecker wrote: > > Pedro has pointed out LLVM's coding standards for "auto", which we may or > > may not want to follow/adopt: > > https://llvm.org/docs/CodingStandards.html#use-auto-type-deduction-to-make-code-more-readable Also see the https://gcc.gnu.org/pipermail/gcc-patches/2020-May/545829.html thread on gcc-patches, including subject 'Describe coding conventions surrounding "auto"' later in the thread. Jakub
Re: Coding style for C++ constructs going forward
On Fri, 7 Aug 2020 at 15:08, Luis Machado via Gcc wrote:
>
> Hi,
>
> cc-ing the GCC mailing list, as we may want to use the same coding style
> for GDB and GCC.
>
> Yesterday I brought this topic up on IRC. I notice we started using more
> and more the "auto" keyword. In some cases, this is actually useful and
> makes the code a bit more compact. GDB has been using those more often,
> whereas GCC, for example, isn't using those too much.
>
> Looking at the coding standards for GCC
> (https://gcc.gnu.org/codingconventions.html), I don't see anything
> dictating best practices for "auto" use.
>
> I guess it is a consensus that "auto" is a good fit when dealing with
> iterators, lambda's and gnarly templates (but only when the type is
> already obvious from its use).
GCC only moved to C++11 very recently, so it's unsurprising.
> There are other situations where "auto" may make things a little more
> cryptic when one wants to figure out the types of the variables. One
> example of this is when you have a longer function, and you use "auto"
> in a variable that lives throughout the scope of the function. This
> means you'll need to go back to its declaration and try to figure out
> what type this particular variable has.
>
> Pedro has pointed out LLVM's coding standards for "auto", which we may
> or may not want to follow/adopt:
> https://llvm.org/docs/CodingStandards.html#use-auto-type-deduction-to-make-code-more-readable
>
> It sounds like a reasonable idea to me. Thoughts?
It seems like common sense to me. "Almost always use auto" is a silly
guideline. I can't stand seeing nonsense like:
auto main() -> int
{ ... }
> Are there other C++ constructs people think would benefit from a more
> formal style guideline? As we move to newer C++ standards over time, it
> is more likely we will start using newer constructs, and some of those
> may make the code potentially less readable.
I'm also not a fan of "always use {} for init" rules. There are times
when using {} for initialization is necessary, or more convenient
(e.g. it avoids ambiguities in the grammar that would need clunky
workarounds to avoid otherwise) but that doesn't make it always
better.
On the other hand, I do like:
- nullptr instead of NULL
- constructors and assignment ops defined with = default
- default member initializers i.e.
struct X
{
void* p = nullptr;
size_t num = 0;
};
(especially useful in GCC code where leaving members uninitialized
seems to be the norm)
Re: Coding style for C++ constructs going forward
On Fri, Aug 7, 2020 at 9:06 AM Luis Machado via Gdb wrote: > > Hi, > > cc-ing the GCC mailing list, as we may want to use the same coding style > for GDB and GCC. > > Yesterday I brought this topic up on IRC. I notice we started using more > and more the "auto" keyword. In some cases, this is actually useful and > makes the code a bit more compact. GDB has been using those more often, > whereas GCC, for example, isn't using those too much. > > Looking at the coding standards for GCC > (https://gcc.gnu.org/codingconventions.html), I don't see anything > dictating best practices for "auto" use. > > I guess it is a consensus that "auto" is a good fit when dealing with > iterators, lambda's and gnarly templates (but only when the type is > already obvious from its use). > > There are other situations where "auto" may make things a little more > cryptic when one wants to figure out the types of the variables. One > example of this is when you have a longer function, and you use "auto" > in a variable that lives throughout the scope of the function. This > means you'll need to go back to its declaration and try to figure out > what type this particular variable has. > > Pedro has pointed out LLVM's coding standards for "auto", which we may > or may not want to follow/adopt: > https://llvm.org/docs/CodingStandards.html#use-auto-type-deduction-to-make-code-more-readable > > It sounds like a reasonable idea to me. Thoughts? The LLVM guide seems pretty similar to what the Google C++ guide *used* to say, which was basically "You can use auto for iterators and when the type is explicit on the initializer, e.g. for auto* x = new Foo()". I liked that rule. (The new version says "Use it if it makes the code more readable" with no detailed guidance, which makes me sad) Christian
Changes to allow PowerPC to change the long double type to use the IEEE 128-bit floating point format
I want to discuss changes that I think we need to make across the open source toochain to allow us to change the long double type on PowerPC hardware from using the IBM extended double (i.e. a pair of doubles) to the IEEE 128-bit format defined in IEEE 754. I wasn't sure whom to address this to, so I took a scatter shot approach. I likely missed a few people, and some people were added that may not need to participate in the discussion. Sorry for either not including you initially or for including you by mistake. I added people from the following areas: PowerPC folk Langugage maintainers: At the moment, only the C/C++ front ends have code to support both 128-bit floating point types. The other languages use just the defaults provided by the machine maintainers. However, it may be we will need to think about rules for code being compiled and linked with a different long double format. Arm/x86 maintainers: It is possible that these sorts of changes might mesh with things that are being planned. For example, maybe x86 might want to explore changing the default for long double from the traditional Intel 80-bit format to IEEE 128-bit. And there might be issues with the several different 16-bit floating point formats floating around. Glibc developers: I added Tulio and Carlos, but I suspect there may be others that might want to respond. Binutils developers: I added Alan, Peter, and Nick. I don't know who else might be interested. Gdb developers: I added Pedro and Ulrich, but I don't know if there are others that may be interested. At the moment, this change is only done if you use the following option: --with-long-double-format=ieee option when configuring GCC. There will be some changes need to make this option work as intended. You will also need an up to date glibc and binutils if you want to use this option. In terms of time table, I feel that whatever changes are made NEED to be done by the time GCC 11 is released. Each topic will be done as a followup to this post, so that people can concentrate on individual features via threaded email readers, rather than wading through the whole list over time. For those of you that are not aware, the PowerPC ISA 3.0 (power9) now has instructions that implement IEEE 754 128-bit floating point directly. Over the last few releases, I have been adding support for IEEE 128-bit floating point into GCC. On power7 and power8 hardware we use soft-float emulator to emulate the IEEE 128-bit floating point format. At the moment, we are only considering doing these changes on the little endian PowerPC linux systems. In theory, it could work on big endian 64-bit PowerPC linux systems that are configured with a minimum cpu of power7. You would need to edit the libgcc and gcc support to enable IEEE 128-bit floating point on those systems and build current glibc for those systems. However, I'm not planning to do this work. In addition, the IEEE 128-bit instructions are not enabled on 32-bit systems (you can use the soft-fp emulation, just not the hardware support). This is due to the issue within GCC we don't support TImode on 32-bit systems. Some parts of GCC require a supported integer that is the same size as basic types. If somebody is motivated to do that work, that is fine, but I'm not planning to do that work. -- Michael Meissner, IBM IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797
PowerPC long double Mangling
One issue with doing the transition is what mangling should be used with the new long double. At the moment, the current mangling is: long double "g" __float128 "u9__ieee128" __ibm128"g" Obviously this will have to change in the future. It is unfortunate that we choose "g" to mean IBM extended double many many years ago, when it should have been used for IEEE 128-bit floating point. But that is long ago, so I think we need to keep it. But assuming we want compatibility with libraries like glibc and libstdc++, I think we will have to continue to use "g" for __ibm128. With the long double change, I tend to view this as an ABI change. But if the user doesn't use long double, they should be able to link without changes. I would propose using a new mangling for IEEE 128-bit long double. I would prefer to get agreement on what the new mangling should be so we don't have an issue like we had in GCC 8.1 going to GCC 8.2, where we changed the mangling, and had to provide aliases for the old name. At the moment I think the mangling should be: long double "g" if long double is IBM long double "u12_ieee128_ld"if long double is IEEE __float128 "u9__ieee128" __ibm128"g" If we decide to change the __ibm128 mangling (or the long double when long double is IBM), then we will likely need to generate aliases to bridge the old vs. new support. -- Michael Meissner, IBM IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797
gcc-9-20200807 is now available
Snapshot gcc-9-20200807 is now available on https://gcc.gnu.org/pub/gcc/snapshots/9-20200807/ 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 4e91af9877df9e6b28ea8e50ae9445590363d5b0 You'll find: gcc-9-20200807.tar.xzComplete GCC SHA256=700c79c63a8980277daad9207b2fceb330b7ec7568f57de8986ae2b4b083f80e SHA1=2baaae32e7e9d387f55e053a59360f89ce8cbe48 Diffs from 9-20200731 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.
