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
> > If there is an issue, it would be in "s-oscons-tmplt.c" which is supposed
> > to define Serial_Port_Descriptor as:
> >
> >subtype Serial_Port_Descriptor is System.Win32.HANDLE;
> >
> > See:
> >
> > #if defined (__MINGW32__) || defined (__CYGWIN__)
> > # define TARGET_OS "Windows"
> > # defi
On Sat, May 2, 2020 at 9:46 PM Arnaud Charlet wrote:
>
> > This fixes three compilation errors preventing bootstrap of gcc-10/11
> > with Ada on x86_64-pc-cygwin. See PR bootstrap/94918 for details.
> >
> > Tested by bootstrapping on x86_64-pc-cygwin, and since it touches code
> > shared with min
> This fixes three compilation errors preventing bootstrap of gcc-10/11
> with Ada on x86_64-pc-cygwin. See PR bootstrap/94918 for details.
>
> Tested by bootstrapping on x86_64-pc-cygwin, and since it touches code
> shared with mingw, also by building a cross to x86_64-w64-mingw32.
>
> Ok for m
> * adaint.c (__gnat_lwp_self): Ensure that the system interface used
> is available on the target.
OK for all active branches, modulo the couple of following nits:
The ChangeLog must make it clear that this is for Darwin only:
* adaint.c [__APPLE__] (__gnat_lwp_self): Ensure
On Fri, 25 Nov 2016, Eric Botcazou wrote:
> > Martin reported a profiledbootstrap issue with a SSA coalescing issue
> > with a
> >
> > return _17(ab);
>
> OK.
>
> > Yeah, seeing this one as well.
>
> It fails at -O0 with just:
>
> eric@polaris:~/build/gcc/native> cat p.adb
> procedure P is
> Martin reported a profiledbootstrap issue with a SSA coalescing issue
> with a
>
> return _17(ab);
OK.
> Yeah, seeing this one as well.
It fails at -O0 with just:
eric@polaris:~/build/gcc/native> cat p.adb
procedure P is
subtype Char is Character range 'W' .. 'Z';
type Arr is array (
On Fri, 25 Nov 2016, Eric Botcazou wrote:
> > 2016-11-25 Richard Biener
> >
> > * gimple-fold.c (fold_stmt_1): Check may_propagate_copy
> > before valueizing return stmts.
>
> What failure is it supposed to fix? The compiler bootstraps for me at
> r242863
> although there is 1 ACAT
On 11/25/2016 10:20 AM, Richard Biener wrote:
>
> Bootstrap and testing in progress.
>
> Richard.
>
> 2016-11-25 Richard Biener
>
> * gimple-fold.c (fold_stmt_1): Check may_propagate_copy
> before valueizing return stmts.
>
> Index: gcc/gimple-fold.c
> ==
> 2016-11-25 Richard Biener
>
> * gimple-fold.c (fold_stmt_1): Check may_propagate_copy
> before valueizing return stmts.
What failure is it supposed to fix? The compiler bootstraps for me at r242863
although there is 1 ACATS regression (c41104a):
+===GNA
> > In any case, for compatibility, this patch just changes the guard so that
> > adadecode.c's ada_demangle is compiled only into libgnat*.{a,so} and not
> > into gnat1, which can then successfully link against libiberty
> > cplus-dem.o.
> >
> > The ipa-devirt.c change is obvious IMHO, the same h
> In any case, for compatibility, this patch just changes the guard so that
> adadecode.c's ada_demangle is compiled only into libgnat*.{a,so} and not
> into gnat1, which can then successfully link against libiberty
> cplus-dem.o.
>
> The ipa-devirt.c change is obvious IMHO, the same header is inc
> this patch fixes the ada bootstrap under cygwin-64.
>
> Boot-strapped under x86_64-pc-cygwin.
> OK for trunk?
OK
On Wed, Jul 25, 2012 at 5:20 PM, Richard Henderson wrote:
> That's what I get for assuming front-ends don't touch back-end things
> like optabs and libcalls...
That is _almost_ the case. In fact, this is one of the last problems...
$ egrep
"\"optabs\.h|\"libfuncs\.h|\"expr\.h|\"rtl|\"recog|\"ba
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
> The following patch fixed the bootstrap for me, will commit it
> as obvious once also regtesting finishes.
>
> 2011-08-29 Jakub Jelinek
>
> * gcc-interface/Makefile.in (../stamp-gnatlib1-$(RTSDIR)): Copy
> tsystem.h into $(RTSDIR) instead of rts.
Patch is certainly fine, thanks
41 matches
Mail list logo
