On Wed, 23 Sep 2020 at 16:40, Richard Biener wrote:
>
> On Wed, Sep 23, 2020 at 12:11 PM Prathamesh Kulkarni
> wrote:
> >
> > On Wed, 23 Sep 2020 at 13:22, Richard Biener
> > wrote:
> > >
> > > On Tue, Sep 22, 2020 at 6:25 PM Prathamesh Kulkarni
> > > wrote:
> > > >
> > > > On Tue, 22 Sep 2020
On Thu, Sep 24, 2020 at 12:36 PM Prathamesh Kulkarni
wrote:
>
> On Wed, 23 Sep 2020 at 16:40, Richard Biener
> wrote:
> >
> > On Wed, Sep 23, 2020 at 12:11 PM Prathamesh Kulkarni
> > wrote:
> > >
> > > On Wed, 23 Sep 2020 at 13:22, Richard Biener
> > > wrote:
> > > >
> > > > On Tue, Sep 22, 2
On Wed, 23 Sep 2020 at 17:50, Christophe Lyon
wrote:
>
> On Wed, 23 Sep 2020 at 17:33, Martin Sebor wrote:
> >
> > On 9/23/20 2:54 AM, Christophe Lyon wrote:
> > > On Wed, 23 Sep 2020 at 01:47, Martin Sebor wrote:
> > >>
> > >> On 9/22/20 9:15 AM, Christophe Lyon wrote:
> > >>> On Tue, 22 Sep 20
"Hu, Jiangping" writes:
> Hi,
>
> I find there are many "ATTRIBUTE_UNUSED" macros in the function parameter
> lists,
> but some of the parameters are used in the function bodies in fact. E.g.
>
> @@gcc/final.c
> void
> output_operand (rtx x, int code ATTRIBUTE_UNUSED)
> {
> if (x &&
I posted version 1 of the patches of the stuff needed to allow little endian
64-bit GCC on Linux to be configured to use long double.
As per the discussion in this thread, I did decide to keep things to two types
within the compiler. This means that an explicit __float128 or _Float128 will
use th
Snapshot gcc-8-20200924 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/8-20200924/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 8 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
Hi, Richard
> "Hu, Jiangping" writes:
> > Hi,
> >
> > I find there are many "ATTRIBUTE_UNUSED" macros in the function
> parameter lists,
> > but some of the parameters are used in the function bodies in fact. E.g.
> >
> > @@gcc/final.c
> > void
> > output_operand (rtx x, int code ATTRIBUTE
Hello world,
for review of its patches, gfortran relies on a group of people
who can approve patches. Unfortuntately, many of them are not
active. Others, who have the capability and who have acted as
de facto approvers (without anybody minding) are missing.
This (somewhat overdue) patch rectif
On 9/25/20 8:02 AM, Thomas Koenig via Fortran wrote:
Hello world,
for review of its patches, gfortran relies on a group of people
who can approve patches. Unfortuntately, many of them are not
active. Others, who have the capability and who have acted as
de facto approvers (without anybody mind