[RFC] Appropriate portable data type for IEEE half-precision on C/C++

[Kito Cheng via Gcc]

Hi:

It's Kito, a RISC-V folks, recently RISC-V has an ISA extension draft
for IEEE half-precision operations [4], including arithmetic,
conversion, comparison...a full set of support for IEEE
half-precision.

So we are seeking the data type for IEEE half-precision, and then we
have few candidates for that:
1. _Float16
2. __fp16 (Same as ACLE)
3. Other type names maybe __float16_t

_Float16 was the best candidate since it kind of standard types from
ISO/IEC TS 18661-3, and it already supported by both clang and gcc,
however the issue is GCC don't support that on C++ mode and seems like
[1-2] it not intend to support that due to the decimal floating point
issue, C++ also has another proposal for extended floating-point types
(https://wg21.link/p1467), which included half-precision types, so in
my understanding, _Float16 won't be a portable typen between C/C++.

And the second candidate __fp16, which is the typename come from ACLE,
it has no C/C++ portable issue due to its target specific type, the
only issue is ACLE has defined that promote to float before operation,
which is not fully utilized the hardware features, so one possible
solution is RISC-V also defined __fp16 type, but with different
semantics, no promotion if HW fp16 are enabled, like _Float16 has
flexible evaluation format, then we can gain most advantage,
compilable for ARM source code, also benefit with the hardware
capability.
But users might get different slight results than ARM, since we might
not do float promotion before evaluation for __fp16.

So the last candidate is defined another typename like __float16_t,
and define the behavior almost same as _Float16 but with default
promotion rule like __fp16 from ACLE, it also has no C/C++ portable
issue, but lose a little bit compatibility with the ARM code.

What do you think about this? I guess ideally we could wait for
P1467[3] to be included in C++ standard, but it seems like we need to
wait another couple years to land.

Or maybe add a target specific type to resolve that immediate is more
realistic solution?

Thanks

[1] See "C++ note:" in commit log
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=c65699efcce48d68ef57ab3ce7fc5420fac5cbf9
[2] https://gcc.gnu.org/pipermail/gcc/2021-March/234965.html
[3] https://wg21.link/p1467
[4] https://github.com/riscv/riscv-isa-manual/pull/496

Re: [RFC] Appropriate portable data type for IEEE half-precision on C/C++

[Jonathan Wakely via Gcc]

On Fri, 12 Mar 2021 at 09:10, Kito Cheng via Gcc  wrote:
>
> Hi:
>
> It's Kito, a RISC-V folks, recently RISC-V has an ISA extension draft
> for IEEE half-precision operations [4], including arithmetic,
> conversion, comparison...a full set of support for IEEE
> half-precision.
>
> So we are seeking the data type for IEEE half-precision, and then we
> have few candidates for that:
> 1. _Float16
> 2. __fp16 (Same as ACLE)
> 3. Other type names maybe __float16_t
>
> _Float16 was the best candidate since it kind of standard types from
> ISO/IEC TS 18661-3, and it already supported by both clang and gcc,
> however the issue is GCC don't support that on C++ mode and seems like
> [1-2] it not intend to support that due to the decimal floating point
> issue,

I am not aware of any motivation in the C++ committee for using class
types for new floating-point types. I don't think the C++ decimal
floating-point TR is considered a success.

> C++ also has another proposal for extended floating-point types
> (https://wg21.link/p1467), which included half-precision types, so in
> my understanding, _Float16 won't be a portable typen between C/C++.

Why not just make _Float16 available in C++ as a GCC extension?

P1467 specifically says:
"The C++ implementation could use _Float16, _Float32, etc. as the
names of the extended floating-point types behind the std:: type
aliases, allowing the use of the C names in both languages."

If/when P1467 (or something like it) gets into the C++ standard we can
add std::float16 to libstdc++ as a typedef for _Float16, but even
before then we can start to add support to std::to_chars,
std::is_floating_point, std::complex, std::abs etc.

> And the second candidate __fp16, which is the typename come from ACLE,
> it has no C/C++ portable issue due to its target specific type, the

This isn't a standard name, so to use it would mean relying on
GCC-specific extensions, so I don't see why it would be better than
relying on "_Float16" as a GCC extension for C++ (and standard for C).

Similarly for __float16_t.

GSoC

[ΓΙΩΡΓΟΣ ΛΙΑΚΟΠΟΥΛΟΣ via Gcc]

To whom it may concern ,

My name is George Liakopoulos and I am an undergraduate student in the
Department of Informatics at the University of Athens .
The past 4 years I code in C/C++ , as my department is focused very much in
these languages .

I would like to contribute to one of your GSoc 2021 projects and more precisely
in the "Rust Front-End" project . The last few days ( from the
organizations announcing ) I look into the git-repo code and I am quite
excited .

I would like to ask you if there is something that i could do from now , to
warm up and get more familiar with the project . Can you point me to a more
specific direction ?

I look forward to hearing from you ,
George Liakopoulos

Re: IEEE Interchange floating point and extended floating point for C++

[Jonathan Wakely via Gcc]

On Thu, 11 Mar 2021 at 15:32, Joseph Myers  wrote:
>
> On Thu, 11 Mar 2021, Kito Cheng wrote:
>
> > I've read the note about C++ support from the initial commit log[1],
> > so I know there is some concern about C++ support for that, is it
> > possible to enable that for C++ like a language extension for C++?
>
> I don't know if C++ has reached any conclusions about what form C++
> support for such types should take, but my expectation was that something
> library-based, similar to the support for decimal floating-point types,
> might be used.

I don't think a pure library solution is likely. It's definitely not
the direction taken by the recent proposals in the area.

Re: [RFC] Appropriate portable data type for IEEE half-precision on C/C++

[Kito Cheng via Gcc]

Hi Jonathan:

> > C++ also has another proposal for extended floating-point types
> > (https://wg21.link/p1467), which included half-precision types, so in
> > my understanding, _Float16 won't be a portable typen between C/C++.
>
> Why not just make _Float16 available in C++ as a GCC extension?

Not sure it would introduce any ABI issue or not? Especially the function
name mangling for _Decimal* types, or maybe we could just implement the
interchanged floating point type (_FloatN) part to C++ is fine?

I am happy to implement that if it's an acceptable way to go, and
I guess it could be used when GCC implements P1467 in future.

Re: [RFC] Appropriate portable data type for IEEE half-precision on C/C++

[Jonathan Wakely via Gcc]

On Fri, 12 Mar 2021 at 09:38, Kito Cheng  wrote:
>
> Hi Jonathan:
>
> > > C++ also has another proposal for extended floating-point types
> > > (https://wg21.link/p1467), which included half-precision types, so in
> > > my understanding, _Float16 won't be a portable typen between C/C++.
> >
> > Why not just make _Float16 available in C++ as a GCC extension?
>
> Not sure it would introduce any ABI issue or not? Especially the function
> name mangling for _Decimal* types, or maybe we could just implement the
> interchanged floating point type (_FloatN) part to C++ is fine?

I would forget about the decimal types. I thought you were just
talking about _Float16?

You will need to decide on a mangling for it in C++, which should be
co-ordinated with other compilers that are likely to support the type.
You could mangle it as "u8_Float16" which is in the namespace reserved
for vendor-extensions but if you wanted to assign a new shorter,
non-extension then it should be discussed at
https://github.com/itanium-cxx-abi/cxx-abi/issues (which will need to
happen anyway if std::float16 is expected to go into the C++
standard).

Are you planning to support this in Clang too?

Re: [RFC] Appropriate portable data type for IEEE half-precision on C/C++

[Jonathan Wakely via Gcc]

On Fri, 12 Mar 2021 at 09:44, Jonathan Wakely  wrote:
>
> On Fri, 12 Mar 2021 at 09:38, Kito Cheng  wrote:
> >
> > Hi Jonathan:
> >
> > > > C++ also has another proposal for extended floating-point types
> > > > (https://wg21.link/p1467), which included half-precision types, so in
> > > > my understanding, _Float16 won't be a portable typen between C/C++.
> > >
> > > Why not just make _Float16 available in C++ as a GCC extension?
> >
> > Not sure it would introduce any ABI issue or not? Especially the function
> > name mangling for _Decimal* types, or maybe we could just implement the
> > interchanged floating point type (_FloatN) part to C++ is fine?
>
> I would forget about the decimal types. I thought you were just
> talking about _Float16?
>
> You will need to decide on a mangling for it in C++, which should be
> co-ordinated with other compilers that are likely to support the type.
> You could mangle it as "u8_Float16" which is in the namespace reserved
> for vendor-extensions

That's documented at
http://itanium-cxx-abi.github.io/cxx-abi/abi.html#mangling-builtin

Re: [RFC] Appropriate portable data type for IEEE half-precision on C/C++

[Kito Cheng via Gcc]

Hi Jonathan:

> I would forget about the decimal types. I thought you were just
> talking about _Float16?
>
> You will need to decide on a mangling for it in C++, which should be
> co-ordinated with other compilers that are likely to support the type.
> You could mangle it as "u8_Float16" which is in the namespace reserved
> for vendor-extensions but if you wanted to assign a new shorter,
> non-extension then it should be discussed at
> https://github.com/itanium-cxx-abi/cxx-abi/issues (which will need to
> happen anyway if std::float16 is expected to go into the C++
> standard).
>
> Are you planning to support this in Clang too?

clang already supports _Float16 on C++ for a while, but only very few targets,
ARM, AArch64, SPIR and AMDGPU.

> That's documented at
> http://itanium-cxx-abi.github.io/cxx-abi/abi.html#mangling-builtin

Seems like it is already defined for _FloatN types, and clang already
follow that.

::= DF  _ # ISO/IEC TS 18661 binary floating point type _FloatN (N bits)

Thank you, Jonathan, I'll start to add that to C++ :)

Re: [RFC] Appropriate portable data type for IEEE half-precision on C/C++

[Jonathan Wakely via Gcc]

On Fri, 12 Mar 2021 at 09:58, Kito Cheng  wrote:
>
> Hi Jonathan:
>
> > I would forget about the decimal types. I thought you were just
> > talking about _Float16?
> >
> > You will need to decide on a mangling for it in C++, which should be
> > co-ordinated with other compilers that are likely to support the type.
> > You could mangle it as "u8_Float16" which is in the namespace reserved
> > for vendor-extensions but if you wanted to assign a new shorter,
> > non-extension then it should be discussed at
> > https://github.com/itanium-cxx-abi/cxx-abi/issues (which will need to
> > happen anyway if std::float16 is expected to go into the C++
> > standard).
> >
> > Are you planning to support this in Clang too?
>
> clang already supports _Float16 on C++ for a while, but only very few targets,
> ARM, AArch64, SPIR and AMDGPU.
>
> > That's documented at
> > http://itanium-cxx-abi.github.io/cxx-abi/abi.html#mangling-builtin
>
> Seems like it is already defined for _FloatN types, and clang already
> follow that.
>
> ::= DF  _ # ISO/IEC TS 18661 binary floating point type _FloatN (N 
> bits)
>
> Thank you, Jonathan, I'll start to add that to C++ :)

Oh good, that makes it easy then!

Re: GSoC

[Philip Herron]

Hi George,

I am the maintainer for GCC Rust, please feel free to join our zulip server
https://gcc-rust.zulipchat.com/, there are other students on the server
also. In terms of getting involved, the first thing to do is make sure you
are able to download the code via git, compile and run the test suite.

After you are able to do that I would suggest writing some test cases and
running the compiler yourself to get familiar with it. As part of helping
students get started, I have been trying to create issues tagged with
good-first-pr
https://github.com/Rust-GCC/gccrs/issues?q=is%3Aissue+is%3Aopen+label%3Agood-first-pr
and feel free to ask questions and guidance on those specific issues as a
coding starting point.

Does this help?

Thanks

--Phil

On Fri, 12 Mar 2021 at 09:26, ΓΙΩΡΓΟΣ ΛΙΑΚΟΠΟΥΛΟΣ via Gcc 
wrote:

> To whom it may concern ,
>
> My name is George Liakopoulos and I am an undergraduate student in the
> Department of Informatics at the University of Athens .
> The past 4 years I code in C/C++ , as my department is focused very much in
> these languages .
>
> I would like to contribute to one of your GSoc 2021 projects and more
> precisely
> in the "Rust Front-End" project . The last few days ( from the
> organizations announcing ) I look into the git-repo code and I am quite
> excited .
>
> I would like to ask you if there is something that i could do from now , to
> warm up and get more familiar with the project . Can you point me to a more
> specific direction ?
>
> I look forward to hearing from you ,
> George Liakopoulos
>

Re: IEEE Interchange floating point and extended floating point for C++

[Sjoerd Meijer via Gcc]

Hello GCC,

Greetings from Clang community! :-) I implemented _Float16 support in Clang.

On the Clang mailing list the request was made if we could rebrand __fp16 to a 
native half-precision type in Clang, but only for RISC-V. I objected to that 
for a few different reasons, and learned that the motivation was the 
unavailability of _Float16 in C++ mode in GCC. My request and proposal on the 
Clang list were to see about _Float16 support in C++ mode in GCC.

In Clang, _Float16 is available in both C and C++ mode. Thus, while _Float16 is 
indeed a C ISO/IEC TS 18661-3 extension, we have also enabled it for C++ ahead 
of the outcome of the C++ standardisation story. The obvious benefit is that we 
have, for quite some time now, a good C/C++ story to target Arm hardware with 
native FP16 support from Clang, which we do not have for GCC. This divergence 
between GCC and Clang is something we would like to address, or at lease 
explore what the possibilities are.

Very briefly about different half-precision source language types, in Arm we 
considering deprecating storage-only type __fp16, because with _Float16 and 
FP16 architecture extensions (RISC-V, ARM, etc.) there is no real good use-case 
for __fp16 anymore. Using it on modern hardware with FP16 support results in 
suboptimal results, and deprecating __fp16 addresses this and also the 
educational problem that we have of different behaving half-types.

This is all a bit of a side story, but illustrates that for FP16 architecture 
extensions we want a native half-precision source language type. And our 
current best guess is that this is _Float16, also in C++ mode. There's 
undeniably a standardisation gap here for C++ (and also in C), but if we 
speculate about possible outcomes for C++, then I think it would have to behave 
largely the same as _Float16 (in C mode). And in case of changes, then I hope 
they are small, and implementations can easily adapt. While the latter would 
obviously not be entirely ideal, (early) implementations might also steer and 
benefit the standarisation story.

So here's finally my concrete question: what do we think about making _Float16 
available in C++ mode?

Thanks,
Sjoerd.




From: Gcc  on behalf of Kito Cheng via Gcc 

Sent: 11 March 2021 09:07
To: GCC 
Cc: Joseph S. Myers 
Subject: IEEE Interchange floating point and extended floating point for C++

Hi:

Would it be possible to support interchange floating point and/or
extended floating point for C++, which is introduced by ISO/IEC TS
18661-3?

I've read the note about C++ support from the initial commit log[1],
so I know there is some concern about C++ support for that, is it
possible to enable that for C++ like a language extension for C++?

The main demand comes from the data type for half-precision, ISO/IEC
TS 18661-3 is the only common spec which supports half-precision and
both GCC and clang are supported.

However it can't be used on C++ for GCC, so it's hard to use that as a
workable solution for half-precision data types.

Or maybe ISO/IEC JTC1 SC22 WG14 N2016[2] is a better way for
half-precision data types?


Thanks

[1] 
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=c65699efcce48d68ef57ab3ce7fc5420fac5cbf9
[2] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2016.pdf

Re: IEEE Interchange floating point and extended floating point for C++

[Jonathan Wakely via Gcc]

On Fri, 12 Mar 2021 at 12:26, Sjoerd Meijer via Gcc  wrote:
> So here's finally my concrete question: what do we think about making 
> _Float16 available in C++ mode?

I think GCC should do it.

Re: GSoC project idea

[David Malcolm via Gcc]

On Thu, 2021-03-11 at 12:59 +0530, srishty bedi via Gcc wrote:
> Greetings,

Hi Srishty

Various remarks inline below...

> First of all Congratulations to the gcc community on being selected
> for
> GSOC 2021.
> 
> My name is Srishty Bedi, I am a sophomore pursuing btech CSE in
> India. .I
> am interested in web development and have worked with
> JS,HTML,CSS,bootstrap
> for front end and php,pug for backend.

It sounds like your skillset is more on web development than on
compilers.  We don't do much HTML/JS within GCC [1], so I'd recommend
looking at another project that's more aligned to your interests,
especially given that GSoC is much shorter than usual this year - we
are looking for people who are already up-to-speed on C++ and on
compiler internals, and there simply isn't time if you don't already
have some skills in those areas.

> The ideas for gsoc 21 :
> 
> 
> 
> 1) I was thinking that whenever we run a code on gcc compiler its
> beautify
> feature doesn't work well it shifts the whole code to the left
> instead so
> thought of creating a good beautify feature as we have in vs code so
> that
> the code is easily understandable .

I'm not sure what you mean by the "beautify feature" shifting "the
whole code to the left".

Are you referring to the way GCC quotes the user's source code when GCC
emits warnings and errors?  I maintain that part of the code, so I'm
interested in hearing of ideas for improvement, but I don't see it
being a GSoC project this year.


> 2) And we can also make the gcc compiler accessible to phones and
> ipads so
> that it may be compatible for touch devices also as it will be very
> beneficial.

It's possible to use GCC from such devices using the excellent
godbolt.org website.


> 
> I am very fascinated by the world of open source and I am looking
> forward
> to contributing to this community .
> 
> Looking forward to your help and guidance.
> 
> Hoping for a positive response from you.
> 
> Here is my github link: https://github.com/srishty-07
> 
> 
> Regards,
> 
> Srishty

Hope this is helpful; good luck finding a suitable project
David

[1] FWIW I've been working on adding HTML/JS output to GCC:
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/558603.html
but the main issues there are on what a web developer would call the
"backend", in terms of populating the HTML with meaningful content, as
opposed to what a web developer would call the "frontend" (templates,
CSS and JS).  i.e. there's some gnarly C++ code that needs overhauling

[RFC][GCC][Vect] Add support for minmax + index pattern.

[Joel Hutton via Gcc]

Hi all,

Some community members have shown interest in a patch I made a while back but 
didn't submit. 

I'm not looking to commit this at the moment, just to make it available (hence 
why I haven't sent it to gcc-patches)>   

This patch was based on master at the following commit and doesn't currently 
apply to the head of master:
90f7636bf8df50940e0f749af60a6b374a8f09b4 libstdc++: Make C++17 ignore 
--disable-libstdcxx-filesystem-ts [PR 94681]

This patch adds support to vectorize the following snippet to find the max and 
corresponding index from an array:

void foo (int *data, int n) {
  int best_i=0, best = 0;

  for (int i = 0; i < n; i++) {
if (data[i] > best) {
  best = data[i];
  best_i = i;
}
  }
  data[best_i] = data[0];
  data[0] = best;
}



minmax.patch
Description: minmax.patch

Re: DWZ 0.14 released

[Nick Alcock via Gcc]

On 9 Mar 2021, Jakub Jelinek via Binutils spake thusly:

> On Tue, Mar 09, 2021 at 11:38:07AM +, Hannes Domani via Dwz wrote:
>>  Am Dienstag, 9. März 2021, 10:10:47 MEZ hat Mark Wielaard  
>> Folgendes geschrieben:
>> 
>> > Hi Allan,
>> >
>> > On Tue, Mar 09, 2021 at 09:06:54AM +0100, Allan Sandfeld Jensen wrote:
>> > > Btw, question for gcc/binutils
>> > >
>> > > Any reason the work done by tools like dwz couldn't be done in the 
>> > > compiler or
>> > > linker? Seems a bit odd to have a post-linker that optimizes the 
>> > > generated
>> > > code, when optimizations should already be enabled.
>> >
>> >
>> > dwz does two kinds of optimization. First it attempts to optimize the
>> > DWARF debugging information for a given object (executable or shared
>> > library). Secondly it tries to put shared pieces of a list of given
>> > objects into a supplemental file that gets referenced from all the
>> > given object files.
>> >
>> > Technically the first optimization could be done by the linker. But
>> > the second optimization is really a post-linker step.
>> 
>> Related question: If it were part of binutils, maybe it could be adapted to
>> optimize DWARF debugging information of PE files as well.
>
> dwz intentionally uses libelf, it often deals with very large amounts of
> debug info that only barely fit into the address space limitations on
> certain arches or physical memory for good performance, and any kind of
> abstraction penalty (e.g. bfd) would make it slower and more memory hungry.

Well, it's not *impossible*. You could in theory do what CTF has done:
move the dedup machinery into a library which is then called both from
the linker (providing its input via BFD and explicitly not supporting
multifile unification of DWARF) and from a separate dedup tool still
called 'dwz' (providing its input via libelf, and flipping a switch
allowing dedup across files and producing an additional output which the
tool then writes to the unified file).

Howver, link speed would likely be affected if dedup is on by default
(it's still a concern of mine with libctf even though none of my
testcases take more than a couple of seconds to dedup: I know how to
shave a *lot* of time off that, I just haven't done it yet). It's quite
possible that you'll save as much time by not having to write as much
DWARF out as you lose deduplicating -- but the write time is usually
hidden from the user anyway since writeback is usually buffered on most
operating systems. So this is probably not as helpful as it might appear
:(

Also, it might not be acceptable to have dwz depend on a shared library
provided by binutils, nor to have binutils depend (even optionally?) on
a shared library provided by dwz...

Re: GSoC project idea

[Jonathan Wakely via Gcc]

On Fri, 12 Mar 2021 at 15:35, David Malcolm via Gcc wrote:
> On Thu, 2021-03-11 at 12:59 +0530, srishty bedi via Gcc wrote:
> > 1) I was thinking that whenever we run a code on gcc compiler its
> > beautify
> > feature doesn't work well it shifts the whole code to the left
> > instead so
> > thought of creating a good beautify feature as we have in vs code so
> > that
> > the code is easily understandable .
>
> I'm not sure what you mean by the "beautify feature" shifting "the
> whole code to the left".

I wonder if this is actually referring to a feature in an IDE which
happens to use GCC, maybe Code::Blocks of Dev-C++ or something.

> > 2) And we can also make the gcc compiler accessible to phones and
> > ipads so
> > that it may be compatible for touch devices also as it will be very
> > beneficial.
>
> It's possible to use GCC from such devices using the excellent
> godbolt.org website.

I find godbolt.org unusable on an Android phone, the UI just doesn't
fit on a small screen, but that's not a GCC problem.

Re: IEEE Interchange floating point and extended floating point for C++

[Joseph Myers]

On Fri, 12 Mar 2021, Jonathan Wakely wrote:

> On Fri, 12 Mar 2021 at 12:26, Sjoerd Meijer via Gcc  wrote:
> > So here's finally my concrete question: what do we think about making 
> > _Float16 available in C++ mode?
> 
> I think GCC should do it.

What about types with the same format as an existing type (but which are 
nevertheless distinct types in C), such as _Float64 (typically same format 
as double) or _Float32 (typically same format as float, but not promoted 
when passed in variable arguments)?

When those types escape into C++ code, they cause an ICE in name mangling; 
see bug 85518.

(Incidental note on _Float16: various architectures have some hardware 
support for that format that don't have support for the type in GCC, 
although they may well have GCC built-in functions corresponding to the 
hardware support; also library support in glibc hasn't yet been 
implemented.  In the case of x86_64 (F16C hardware conversion instructions 
from Ivy Bridge onwards), the psABI document defines an ABI for _Float16 
and the corresponding complex type; in general such an ABI should be 
agreed with interested parties when adding _Float16 support for an 
architecture.)

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [RFC] Appropriate portable data type for IEEE half-precision on C/C++

[Joseph Myers]

On Fri, 12 Mar 2021, Jonathan Wakely via Gcc wrote:

> Why not just make _Float16 available in C++ as a GCC extension?

There may be questions about promotions from _Float16 to wider formats for 
arithmetic.

For C, there are no such promotions at the level of types (adding two 
_Float16 values produces a result of type _Float16), but the excess 
precision mechanism is used in some cases to cause a result of _Float16 
arithmetic, although of semantic type _Float16, to be represented with the 
range and precision of _Float32, to reduce the number of conversions of 
intermediate results back to the range and precision of _Float16 that are 
needed on hardware that doesn't have arithmetic operating directly on 
_Float16.  Specifically, on AArch64, the excess precision mechanism is 
used before ARMv8.2-A; v8.2-A adds direct arithmetic on _Float16 so no 
excess precision is used from then on (see aarch64_excess_precision).

As we don't have excess precision support in the C++ front end, supporting 
_Float16 for C++ will require a decision about how to handle _Float16 
arithmetic on hardware where there aren't actual _Float16 arithmetic 
operations.

(The RISC-V document linked to suggests that won't be an issue for RISC-V 
with hardware _Float16 support, though obviously it's still necessary to 
decide what to do when using _Float16 on RISC-V systems without the 
hardware support, if that is allowed at all.)

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: IEEE Interchange floating point and extended floating point for C++

[Joseph Myers]

On Fri, 12 Mar 2021, Joseph Myers wrote:

> On Fri, 12 Mar 2021, Jonathan Wakely wrote:
> 
> > On Fri, 12 Mar 2021 at 12:26, Sjoerd Meijer via Gcc  wrote:
> > > So here's finally my concrete question: what do we think about making 
> > > _Float16 available in C++ mode?
> > 
> > I think GCC should do it.
> 
> What about types with the same format as an existing type (but which are 
> nevertheless distinct types in C), such as _Float64 (typically same format 
> as double) or _Float32 (typically same format as float, but not promoted 
> when passed in variable arguments)?

And also the _Float32x, _Float64x types (we don't have any targets 
supporting _Float128x).  (On all systems supporting those types in GCC, 
_Float32x has the same format as double and _Float64, and _Float64x has 
the same format as either long double or _Float128, but again they are 
different types.)

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [RFC] Appropriate portable data type for IEEE half-precision on C/C++

[Gabriel Ravier via Gcc]

On 3/12/21 7:07 PM, Joseph Myers wrote:

On Fri, 12 Mar 2021, Jonathan Wakely via Gcc wrote:


Why not just make _Float16 available in C++ as a GCC extension?

There may be questions about promotions from _Float16 to wider formats for
arithmetic.

For C, there are no such promotions at the level of types (adding two
_Float16 values produces a result of type _Float16), but the excess
precision mechanism is used in some cases to cause a result of _Float16
arithmetic, although of semantic type _Float16, to be represented with the
range and precision of _Float32, to reduce the number of conversions of
intermediate results back to the range and precision of _Float16 that are
needed on hardware that doesn't have arithmetic operating directly on
_Float16.  Specifically, on AArch64, the excess precision mechanism is
used before ARMv8.2-A; v8.2-A adds direct arithmetic on _Float16 so no
excess precision is used from then on (see aarch64_excess_precision).

As we don't have excess precision support in the C++ front end,


Couldn't that just be made into shared code between the C and C++ 
frontends ?



supporting
_Float16 for C++ will require a decision about how to handle _Float16
arithmetic on hardware where there aren't actual _Float16 arithmetic
operations.

(The RISC-V document linked to suggests that won't be an issue for RISC-V
with hardware _Float16 support, though obviously it's still necessary to
decide what to do when using _Float16 on RISC-V systems without the
hardware support, if that is allowed at all.)

Re: IEEE Interchange floating point and extended floating point for C++

[Jonathan Wakely via Gcc]

On Fri, 12 Mar 2021, 18:14 Joseph Myers,  wrote:

> On Fri, 12 Mar 2021, Joseph Myers wrote:
>
> > On Fri, 12 Mar 2021, Jonathan Wakely wrote:
> >
> > > On Fri, 12 Mar 2021 at 12:26, Sjoerd Meijer via Gcc 
> wrote:
> > > > So here's finally my concrete question: what do we think about
> making _Float16 available in C++ mode?
> > >
> > > I think GCC should do it.
> >
> > What about types with the same format as an existing type (but which are
> > nevertheless distinct types in C), such as _Float64 (typically same
> format
> > as double) or _Float32 (typically same format as float, but not promoted
> > when passed in variable arguments)?
>
> And also the _Float32x, _Float64x types (we don't have any targets
> supporting _Float128x).  (On all systems supporting those types in GCC,
> _Float32x has the same format as double and _Float64, and _Float64x has
> the same format as either long double or _Float128, but again they are
> different types.)
>

I see less value in adding additional distinct types that don't add
anything you can't already do. _Float16 gives you access to an entirely new
data type. _Float32 just complicates overloading of it's a new type with
the same representation as an existing one. With the proposed std::float32
typedef for C++ users will still be able to write code that definitely uses
an IEEE binary32 type without needing a new type to be introduced. ISTM
that what users really want is "a type guaranteed to be IEEE binary32" and
whether that is float or _Float32 is mostly irrelevant.

[RFC][VECT] vectorising ppc64 scalar operations, assembly syntax guidance needed

[Luke Kenneth Casson Leighton via Gcc]

(please do cc me to preserve thread, i am subscribed digest, thank you)

https://bugs.libre-soc.org/show_bug.cgi?id=615

summary: Libre-SOC needs an assembly syntax for SVP64 which is acceptable
for all parties, gcc and binutils primarily.

background: the Libre-SOC team, funded by NLnet, is adding Cray-style
Vectorisation (SVP64) to the OpenPOWER ISA under the guidance of the
OpenPOWER Foundation.  the work is to be submitted to the OPF ISA WG and
last week the first successful instructions were executed under both the
hardware and simulator.

we are therefore working on gcc and binutils and need guidance on what
assembly syntax is acceptable for SVP64.

extreme brief conceptual summary of SVP64: a Sub-Program-Counter which
walks sequentially through the regfile executing a *SCALAR* instruction
multiple times (0 to VectLen-1) before moving to the next instruction (PC+8)

this is done by prefixing *SCALAR* OpenPOWER v3.0B instructions
*UNMODIFIED* with 24 bits of additional Vectorisation Context, embedded
into a 32 bit (OpenPOWER v3.1) format.

we have a program already written which understands a draft SVP64 assembly
syntax, and we need help in evaluating it to find a form that is acceptable
to all (link at the bugreport at top of post).  examples:

sv.isel 64.v, 3, 2, 65.v

this embeds the ppc64 scalar v3.0B "isel" instruction (isel RT,RA,RB,BC) into
a Vectorisation Contexts that extends:

* BC as a Vector of Condition Register fields
* leaves RB and RA as scalar
* RT as a Vector INTs (GPR)

sv.add. 5.v, 2.v, 1.

this one embeds "add Rc=1" into a Vectorisation Context that extends CR0,
RA and RT as Vector whilst leaving RB as Scalar

sv.extsw./pr=eq 5.v, 31

this one embeds "extsw" whilst making CR0 and RT Vectorised and RA scalar
but *also applies Condition Register Predication* to all Vectorised extsw
operations, using the CR field "eq" bit

Segher kindly already informed me a couple hours ago for example that using
"." in register names has to go.

the bottom line here is that we will soon be submitting upstream patches
and would like to engage in dialog with the right people to ensure that
what is submitted is understood, reviewed and acceptable to all.

thus we need guidance on what format of syntax will be acceptable, that
also correctly and successfully represents the SVP64 concept in a way that
makes sense.

i do appreciate that this will take time: SVP64 is conceptually
unprecedented in the history of computing.  the closest conceptual
equivalents are a hybrid of:

* Cray-style Vectors (without any actual Vector opcodes)
* Zero Overhead Loops from TI DSPs
* Intel MMX and OpenPOWER VSX reuse of the FP regfile to overlay registers
of completely different type and size.

whilst those are similar they are also completely wrong :)

any questions please do not hesitate to ask.

l.


-- 
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

Re: IEEE Interchange floating point and extended floating point for C++

[Joseph Myers]

On Fri, 12 Mar 2021, Jonathan Wakely via Gcc wrote:

> I see less value in adding additional distinct types that don't add
> anything you can't already do. _Float16 gives you access to an entirely new
> data type. _Float32 just complicates overloading of it's a new type with

So would you then support _Float128, and the corresponding f128/F128 
literal suffixes, in C++, as a "more standard" version of __float128, in 
the case where it has a different format from long double (e.g. x86_64) 
but not when it has the same format as long double?

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: IEEE Interchange floating point and extended floating point for C++

[Jonathan Wakely via Gcc]

On Fri, 12 Mar 2021, 21:55 Joseph Myers,  wrote:

> On Fri, 12 Mar 2021, Jonathan Wakely via Gcc wrote:
>
> > I see less value in adding additional distinct types that don't add
> > anything you can't already do. _Float16 gives you access to an entirely
> new
> > data type. _Float32 just complicates overloading of it's a new type with
>
> So would you then support _Float128, and the corresponding f128/F128
> literal suffixes, in C++, as a "more standard" version of __float128, in
> the case where it has a different format from long double (e.g. x86_64)
> but not when it has the same format as long double?
>

Or support it in both cases, but for the latter case as an alias for long
double rather than as a distinct type.

I can ask the WG21 Numerics study group what they think makes sense for
C++, because I'm not certain my choices are the right ones.

The old designated initializer syntax

[Joseph Myers]

GCC supports an old, pre-C99 designated initializer syntax in C, where 
array designators need not be followed by '=' and members may use 
'member_name :' rather than '.member_name ='.

I hoped to obsolete that syntax more forcefully (making the pedwarns for 
it unconditional) back in 2000 as mentioned in 
, but at 
the time it was still widely used.  I'd like to know how widely used it 
still is.  Is someone able to do a distribution rebuild with a patch such 
as the one below (untested) and see how much the warnings (especially the 
second one in the patch, for array initializer) appear?

Specific motivation: there's a C2x proposal for a form of C++ lambdas.  
The syntax for lambdas is ambiguous with that for the old style of array 
designated initializers in certain cases, when combined with other GCC 
extensions, so if lambdas are accepted for C2x it would not be possible to 
accept all cases of the old array designated initializer syntax any more, 
at least not in C2x mode.

diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c
index 5cdeb21a458..f8905090caf 100644
--- a/gcc/c/c-parser.c
+++ b/gcc/c/c-parser.c
@@ -5300,7 +5300,7 @@ c_parser_initelt (c_parser *parser, struct obstack * 
braced_init_obstack)
  c_parser_peek_token (parser)->location,
  braced_init_obstack);
   /* Use the colon as the error location.  */
-  pedwarn (c_parser_peek_2nd_token (parser)->location, OPT_Wpedantic,
+  pedwarn (c_parser_peek_2nd_token (parser)->location, 0,
   "obsolete use of designated initializer with %<:%>");
   c_parser_consume_token (parser);
   c_parser_consume_token (parser);
@@ -5465,7 +5465,7 @@ c_parser_initelt (c_parser *parser, struct obstack * 
braced_init_obstack)
  else
{
  if (des_seen == 1)
-   pedwarn (c_parser_peek_token (parser)->location, OPT_Wpedantic,
+   pedwarn (c_parser_peek_token (parser)->location, 0,
 "obsolete use of designated initializer without 
%<=%>");
  else
{


-- 
Joseph S. Myers
jos...@codesourcery.com

gcc-9-20210312 is now available

[GCC Administrator via Gcc]

Snapshot gcc-9-20210312 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/9-20210312/
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 6c3fdc59687c2eadb2aa391b60c7b75fe633d12b

You'll find:

 gcc-9-20210312.tar.xzComplete GCC

  SHA256=485f077361b3063a62267287b59262af79b9c00f6a395a7ec204b73fbd622b95
  SHA1=f751c8fd119361957cde2bd62ff67edfbbb06d9d

Diffs from 9-20210305 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.