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
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 .
Ok for t
> > 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
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 master and gcc-
> * 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
Hi,
This is a bootstrap regression on 7,8 and trunk for Ada on [X86 and PowerPC]
Darwin9 (and earlier, although I don’t test much there).
Changes were made to __gnat_lwp_self to use a facility that’s only available
from Darwin10 onwards.
The patch makes this conditional on the target Darwin ve
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
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
===
--- gcc/gimple-fold.c
> > 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
Hi!
Honza's recent change to use the libiberty demangler inside of gcc
broke Ada bootstrap. The issue is that there is a symbol clash,
libiberty contains ada_demangle symbol (with one API), and ada/adadecode.c
(since around 3.3 time, claimed for compatibility) contains another one,
with incompati
> this patch fixes the ada bootstrap under cygwin-64.
>
> Boot-strapped under x86_64-pc-cygwin.
> OK for trunk?
OK
Hi,
this patch fixes the ada bootstrap under cygwin-64.
Boot-strapped under x86_64-pc-cygwin.
OK for trunk?
Thanks
Bernd.
2015-01-27 Bernd Edlinger
Fix build under cygwin/64.
* adaint.h: Add check for __CYGWIN__.
* mingw32.h
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
That's what I get for assuming front-ends don't touch back-end things
like optabs and libcalls...
I'm reasonably certain that a better solution would be to move the
set_stack_check_libfunc declaration elsewhere and/or totally rearrange
that specific interface: c.f. lang_hooks.eh_protect_cleanup_ac
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
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-size special
> 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
Hi!
One of the Ada changes committed today, most likely
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=178176
(couldn't find it posted on gcc-patches) broke x86_64-linux
bootstrap, with errors like:
ctrl_c.c:34:21: fatal error: tsystem.h: No such file or directory
compilation terminated.
make[9]
50 matches
Mail list logo
