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
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 seekin
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
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 extensio
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?
No
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
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 unders
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
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 s
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
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 m
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.
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 in
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 curr
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 Sa
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
> > though
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 exist
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 pro
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 d
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 o
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 _Flo
(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
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 supp
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 complicate
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 menti
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
26 matches
Mail list logo
