On 2/26/21 8:24 AM, Mikael Pettersson via Gcc-patches wrote:
> On Fri, Feb 5, 2021 at 2:59 PM Arnaud Charlet wrote:
We'd rather not have PR references in the source files, so please remove it
(it will be there as part of the commit log and git annotate).
OK with the comment
On Fri, Feb 5, 2021 at 2:59 PM Arnaud Charlet wrote:
>
> > > We'd rather not have PR references in the source files, so please remove
> > > it
> > > (it will be there as part of the commit log and git annotate).
> > >
> > > OK with the comment updated.
> >
> > Thanks, here's the revised patch.
>
> > We'd rather not have PR references in the source files, so please remove it
> > (it will be there as part of the commit log and git annotate).
> >
> > OK with the comment updated.
>
> Thanks, here's the revised patch.
OK, thanks.
> gcc/ada/
>
> 2021-02-05 Mikael Pettersson
>
> P
On Fri, Feb 5, 2021 at 9:35 AM Arnaud Charlet wrote:
>
> > This fixes the bootstrap failure with Ada on Cygwin since the switch
> > to C++11. The configure checks detect that fileno_unlocked () is
> > present, but when Ada's cstreams.c is compiled in C++11 mode,
> > does not declare it, causing a
> This fixes the bootstrap failure with Ada on Cygwin since the switch
> to C++11. The configure checks detect that fileno_unlocked () is
> present, but when Ada's cstreams.c is compiled in C++11 mode,
> does not declare it, causing a hard error.
>
> Fixed by defining _GNU_SOURCE before including
Hi,
On Sat, 3 Sep 2011, Richard Guenther wrote:
> > your patch and apply mine entirely, as eliminating alloca (0) early
> > looks a interesting simplification. What do you think?
>
> I'm not sure we want to create a the replacement decl with DECL_SIZE
> zero though, so I suppose instead of ma
> Then your original patch is ok with removing the size == 0 check I added.
Bootstrapped/regtested on x86_64-suse-linux and applied, thanks.
--
Eric Botcazou
On Sat, Sep 3, 2011 at 11:09 AM, Eric Botcazou wrote:
>> I'm not sure we want to create a the replacement decl with DECL_SIZE zero
>> though, so I suppose instead of making sure align is BITS_PER_UNIT
>> shouldn't we make sure that size is at least 1? I fear we might run into
>> other odd problem
> I'm not sure we want to create a the replacement decl with DECL_SIZE zero
> though, so I suppose instead of making sure align is BITS_PER_UNIT
> shouldn't we make sure that size is at least 1? I fear we might run into
> other odd problems with zero-size autos.
The cfgexpand.c code already does
On Fri, Sep 2, 2011 at 6:55 PM, Eric Botcazou wrote:
>> And this is the real fix. Richard, do you want me to apply (part of it)?
A varaint of the patch is ok,
> In fact I'd even propose to revert the fold_builtin_alloca_for_var part of
> your patch and apply mine entirely, as eliminating alloca
On 09/02/2011 07:13 PM, H.J. Lu wrote:
> On Fri, Sep 2, 2011 at 9:40 AM, Eric Botcazou wrote:
>>> so accessing the With_Flags array (which is not empty) yields a SEGV
>>> because the base pointer is equal to Last_Unit (i.e. 2). In other words,
>>> the GIMPLE code looks legitimate and the bug is v
On Fri, Sep 2, 2011 at 9:40 AM, Eric Botcazou wrote:
>> so accessing the With_Flags array (which is not empty) yields a SEGV
>> because the base pointer is equal to Last_Unit (i.e. 2). In other words,
>> the GIMPLE code looks legitimate and the bug is very likely in the stack
>> slot allocation c
> And this is the real fix. Richard, do you want me to apply (part of it)?
In fact I'd even propose to revert the fold_builtin_alloca_for_var part of
your patch and apply mine entirely, as eliminating alloca (0) early looks a
interesting simplification. What do you think?
--
Eric Botcazou
> so accessing the With_Flags array (which is not empty) yields a SEGV
> because the base pointer is equal to Last_Unit (i.e. 2). In other words,
> the GIMPLE code looks legitimate and the bug is very likely in the stack
> slot allocation code (maybe triggered by the newly created zero-sized
> arr
> This fixes the Ada bootstrap failure introduced by alloca folding.
> We now fold alloca (0) to &auto-with-size-zero which confuses us.
> I didn't exactly investigate but what I think happens is that we
> expand that &auto-with-size-zero to NULL instead of
> virtual_stack_dynamic_rtx (see zero-siz
Hi,
On Fri, 2 Sep 2011, Arnaud Charlet wrote:
> > Given the nature of the work-around which makes Ada work again it's fairly
> > sure that the Ada frontend does emit accesses to an alloca'ed area of
> > memory even if its size is zero. I.e. definitely a real bug.
>
> Well, it's not clear whethe
On 9/2/2011 11:47 AM, Michael Matz wrote:
Hi,
On Fri, 2 Sep 2011, Robert Dewar wrote:
On 9/2/2011 9:16 AM, Richard Guenther wrote:
Might be interesting to pursue, but we don't know that the null pointers
being dereferenced are in fact the ones returned by alloca. May not be
worth the effort.
> Given the nature of the work-around which makes Ada work again it's fairly
> sure that the Ada frontend does emit accesses to an alloca'ed area of
> memory even if its size is zero. I.e. definitely a real bug.
Well, it's not clear whether it's the Ada frontend or the middle which is
emitting th
Hi,
On Fri, 2 Sep 2011, Robert Dewar wrote:
> On 9/2/2011 9:16 AM, Richard Guenther wrote:
>
> Might be interesting to pursue, but we don't know that the null pointers
> being dereferenced are in fact the ones returned by alloca. May not be
> worth the effort.
Given the nature of the work-aro
On 9/2/2011 9:16 AM, Richard Guenther wrote:
The bootstrap failure showed NULL pointer dereferences (which
probably easily points to the affected part of the RTS).
Might be interesting to pursue, but we don't know that the null
pointers being dereferenced are in fact the ones returned by
alloc
On Fri, 2 Sep 2011, Robert Dewar wrote:
> On 9/2/2011 8:58 AM, Arnaud Charlet wrote:
> > > > In Ada, it's quite natural to end up with a dynamically sized object of
> > > > size 0. For instance, if you declare an array with a dynamic bound:
> > > >
> > > > Table : Unit_Table (1 .. Last_Unit);
On 9/2/2011 8:58 AM, Arnaud Charlet wrote:
In Ada, it's quite natural to end up with a dynamically sized object of
size 0. For instance, if you declare an array with a dynamic bound:
Table : Unit_Table (1 .. Last_Unit);
and Last_Unit happens to be 0 at run-time
But are we expected to read
On Fri, 2 Sep 2011, Arnaud Charlet wrote:
> > > In Ada, it's quite natural to end up with a dynamically sized object of
> > > size 0. For instance, if you declare an array with a dynamic bound:
> > >
> > >Table : Unit_Table (1 .. Last_Unit);
> > >
> > > and Last_Unit happens to be 0 at run-t
On 9/2/2011 8:52 AM, Arnaud Charlet wrote:
Thanks!
In Ada, it's quite natural to end up with a dynamically sized object of
size 0. For instance, if you declare an array with a dynamic bound:
Table : Unit_Table (1 .. Last_Unit);
and Last_Unit happens to be 0 at run-time
Arno
But isn't i
> > In Ada, it's quite natural to end up with a dynamically sized object of
> > size 0. For instance, if you declare an array with a dynamic bound:
> >
> >Table : Unit_Table (1 .. Last_Unit);
> >
> > and Last_Unit happens to be 0 at run-time
>
> But are we expected to read/store from the sto
On Fri, 2 Sep 2011, Arnaud Charlet wrote:
> > This fixes the Ada bootstrap failure introduced by alloca folding.
> > We now fold alloca (0) to &auto-with-size-zero which confuses us.
> > I didn't exactly investigate but what I think happens is that we
> > expand that &auto-with-size-zero to NULL i
> This fixes the Ada bootstrap failure introduced by alloca folding.
> We now fold alloca (0) to &auto-with-size-zero which confuses us.
> I didn't exactly investigate but what I think happens is that we
> expand that &auto-with-size-zero to NULL instead of
> virtual_stack_dynamic_rtx (see zero-siz
27 matches
Mail list logo
