I am also planning to incorporate many Ada improvements (such as
improved support for Ada 2005) and fixes that
I was holding while the 4.2 branch was not created, I assume this is
not an issue (and very localized to the gcc/ada/ directory of course).
Arno
> IIRC, current default max line length for Ada programs is 255, and 32767
> for configuration pragmas. But it's always better to be prepared
> for the worse :).
Actually that's no longer the same. You can have line length much bigger
now with GNAT, assuming you use the proper compiler switch.
As
> I was doing full builds, except for Ada. I should have mentioned that.
> Ada doesn't get configured by default, and I haven't bothered to check
> why. I probably forgot to install the Ada compiler package.
Ada is not enabled by default, you need to include it explicitely,
e.g. --enable-langua
> Some time ago, someone posted a patch which provided beginnings of a
> general-purpose Ada test suite infrastructure (in addition to the
> current ACATS tests, which cannot be used for regression tests). The
Note that this is technically incorrect: the ACATS infrastructure can
be used for regre
> I thought that there were some reservations about changing the ACATS
> test suite.
I do not remember anything like that. Also, we're not talking about changing
the ACATS test suite, but rather expanding it.
> So how we can make sure that this work is not lost? Who would be in a
> position to a
> Everyone's who writes C/C++ should know that overflow of signed is undefined.
>
> Now in Java it is defined, which is the reason why -fwrapv exists in the
> place since GCC has a "Java" compiler.
Right. I also believe that it is conceptually wrong to enable this for
Ada, so until this issue is
> None of the machines I tried even get that far in an ada bootstrap.
x86 has been reported to be buildable now.
on x86-64, there are one or two pending patches (posted), but building
at -O0 or disable -fwrapv should also work around the failures.
> Probably something in the ada frontend is missi
> Ada is quite broken right now - see also:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23646
Right, sorry about that.
I was almost ready to commit the fix on friday, but got stuck because
someone was doing a long cvs operation locking any other use, so
I had to leave before being able to co
> Many thanks to people enabling Ada in their builds!
Indeed, thanks to you, and thanks to Laurent for collecting these
results, and also filing bugzilla PRs when regressions are detected.
Arno
> Now the question is how to fix this for real.
As far as I can see, the binder is indeed generating a call to
osint__m___elabb before osint___elabb, so this is probably working elsewhere
because Running_Program is probably initialized by the loader.
I would suggest reducing the bug as much as po
Here are my first impressions on trying to use subversion.
Note that I didn't go to any doc or wiki page yet, I simply copy/pasted
the commands I saw on the gcc list. I am familiar with cvs commands and
expect most things to be handled similarly.
- first check out:
svn co svn+ssh://gcc.gnu.org/s
Oh I forgot: tied a couple of svn commit operations, which,
after having set the EDITOR env variable, went fine, no troubles.
Arno
Thanks for your reply and suggestion.
A couple of questions, comments below:
> I think people really want to use svk for their day-to-day work, because
> 1. such diffs are then local operations
> 2. you can have local branches which you can use instead of having
> N checked out modified tre
> Most of this is ssh overhead, because your diff is so small.
I disagree, the diff isn't small, it is of a typical/reasonable size I
would say.
> The ssh multiplexing stuff just written up on the wiki should help.
Thanks, I will have a look. This requires an update to OpenSSH >= 4.0,
so I canno
> Out of curiosity, are you comparing anonymous CVS versus svn+ssh? In that
For your curiousity, no. I am comparing two write-access repositories
(CVS and svn+ssh).
> case, it's apple and oranges. Do some ssh multiplexing and get speed back.
I first need to update to openssh 4.0 which will take
> 8.5G seems to be the space needed on the server, *not*
> on your local machine.
I believe you are confused: I was talking about a svk set up (as suggested
by the author of the email I was responding to) with a local
mirror of the repository in this message. 8.5G is for the local mirror,
it is no
A few comments, since your message makes it sound like everything is
better, which is not true in reality.
> > - time to do a diff on mainline/branch
>
> "svn diff" is a disconnected operation, requires no server access, so it takes
> milliseconds. "cvs diff" is dominated by network connection, s
> DanJ put up a wiki page on the OpenSSH configuration (which really could be
> found with 3 minutes of googling, which is shorter than writing a mail asking
> information about it [not speaking of you, gaby]).
Well, with all your respect, you seem to be living in a different world than
mine.
In
> How many of such platforms are available and known to work in the FSF
> tree?
Strange question. The answer is all the platforms currently known to
work with Ada (too many to be listed here).
> One alternative is to have an s-auxdec-empty and use that
> on platforms where s-auxdec is known to po
> RTEMS has networking functions but they are not available at this stage
> during the build. You only have the .h files provided with newlib. So
> this patch is needed to make *-rtems compile again. OK to commit?
Please post the corresponding ChangeLog so that this patch can be reviewed
and ap
> Running make check stops in the Ada ACATS part,
> where it doesn't find the newly created binaries
> after a successful make bootstrap. (And after turning
> the computer off, going to sleep, turning it on and
> *not* again adding the different GNAT installation to
> PATH that was used for bootstr
> How about this? Can I commit it?
Please always remember to provide a changelog when submitting a patch,
thanks ;-)
Patch is OK, assuming reasonable changelog entry.
Arno
> Index: gcc/ada/socket.c
> ===
> --- gcc/ada/socket.c
> Most svn side operations create subpools for loops that may allocate
> per-iteration memory due to calls to other functions, etc, and clear it
> each iteration to avoid such per iteration allocations become too large.
> Some don't.
FWIW, the first (and only) time I tried to do a svn diff on lots
> libaddr2line used to be a proprietary library distributed by AdaCore
> only.
This is wrong, libaddr2line never was proprietary. It can't be in any case,
since it's based on binutils.
> IIRC, libaddr2line never was suitable for tasking.
This is also wrong, GNAT.Traceback.Symbolic is suitable fo
> I can not catch the exception of Ada after gcc-4.1-20051125 on Windows.
> I confirmed with 4.1.0 20051202 and 4.1.0 20051209.
Hmm, I guess the following patch will fix this.
The issue is that we're using GCC dwarf2 EH mechanim by default under Windows,
using yet to be submitted mingw patches, so
> I see there's magic going on in the testsuite/ada/acats/run_acats and
> run_all.sh scripts, but they cannot be invoked directly to set up the
> environment.
The magic is only there to support testing in the build tree,
with the compiler not installed.
Assuming you've done a make install, then c
> This is exactly what I'm trying to do, as I'm testing with the
> stage1 compiler that happens to miscompile the stage2 compiler,
> so I guessed it might be easier to debug the testsuite fallout
> of the stage1 compiler.
>
> I'm used to do ./xgcc -B/whatever in the gcc/ directory, maybe
> gnatmak
> /space/rguenther/obj/obj3/gcc/xgcc -c -B/space/rguenther/obj/obj3/gcc/
> -gnatws -O2 -I/space/rguenther/obj/obj3/gcc/testsuite/ada/acats/support
> /space/rguenther/obj/obj3/gcc/testsuite/ada/acats/tests/c3/c32001e/c32001e.adb
>
> -I/space/rguenther/obj/obj3/gcc/ada/rts
>
> ? This way it wou
> gcc -c -g -I- -I. -Iada -I/cvs/gcc-svn/trunk/gcc/ada
> /cvs/gcc-svn/trunk/gcc/ada/ada.ads -o ada/ada.o
> ada.ads:16:01: language defined units may not be recompiled
> make[3]: *** [ada/ada.o] Error 1
>
> This worked 24 hours ago - with the same bootstrap compiler.
>
> I'm trying to hunt
> ADAFLAGS = -W -Wall -gnatpg -gnata
> ADAFLAGS_FOR_TARGET = -W -Wall -gnatpg -gnata
>
> and changing = to += in config/mt-ppc-aix?
>
> Arnaud, it seems strange that "required" flags like -gnatpg are on
> ADAFLAGS rather than the makefile rules. -c is not in CFLAGS, for
> example. Is it possibl
> Sorry if I don't understand. How is a debugging option related to the
> error Andreas reported, which is:
No relation, but that was not the question you were asking ;-)
> >gcc -c -g -I- -I. -Iada -I/cvs/gcc-svn/trunk/gcc/ada
> >/cvs/gcc-svn/trunk/gcc/ada/ada.ads -o ada/ada.o
> >ada.ads
> So you need a -gnat option, or compilation fails?
You need at the very least -gnatg, although -gnatpg is highly recommended,
and -gnata is highly desirable for development.
Arno
> Ok. For now I'd stick with the patch I proposed to Andreas, but please
> tell me if these assertions are right or wrong:
Note that this patch is really kludgy, since it duplicates the default
value of ADAFLAGS in several (at least 3) places, which means that if/when
we decide to change this de
> Could you please find a more elegant solution ? Thanks in advance.
See e.g. setting of EXTRA_GCC_FLAGS in Makefile.tpl for a way to handle that:
EXTRA_GCC_FLAGS = \
[...]
"`echo 'LANGUAGES=$(LANGUAGES)' | sed -e s'/[^=][^=]*=$$/XFOO=/'`" \
Arno
> >EXTRA_GCC_FLAGS = \
> >[...]
> > "`echo 'LANGUAGES=$(LANGUAGES)' | sed -e s'/[^=][^=]*=$$/XFOO=/'`" \
> >
> >
> Unfortunately, there is no really easy and elegant solution. This one,
> for example, would really oblige targets that want to specify Ada-only
> flags to also include -Wall
> Because the line above, as you know, does not pass LANGUAGES if it is
> not set. But if it is set, the value is reset completely, rather than
> combined with the value in the subdirectory.
Right, as intended.
> So, the AIX makefile fragments config/mh-ppc-aix and config/mt-ppc-aix
> could n
> Yes, but it provides no way to set them globally. That means, if
> something is written in Ada, it has to be in gcc/ada, and if you want to
> change some parameter you more or less have to invoke `make' from the
> gcc/ada directory.
Well, I'm afraid you've lost me...
What is T_ADAFLAGS used fo
> You can set it for gcc/ada only, not for the benefit of the entire
> tree. It makes it hard, for example, to make libada really its own
> toplevel directory, because T_ADAFLAGS is set within the gcc target
> fragments.
Well, so you're saying there will be, in the future, a potential
problem
[thanks for the general info on what minimal-toc is about, I should
have mentioned I am familiar with the general issue and with this option]
> When Ada builds on AIX, libada contains a very large number of TOC
> entries. Even the smallest, simplest executable overflows because the
> entir
> I'm not saying I don't like the idea, but I'm not prepared to do it and
> I surely don't want to "slip it under the door" as obvious.
Well if that's your criteria then sure, your previous change was also not
in the obvious category ;-)
Arno
> Fourth, because toplevel bootstrap is a prerequisite for many further
> cleanups and improvements, including moving libgcc to the toplevel and
> bootstrapping libada.
For my information, what point is there in boostrapping libada ?
BTW, it seems that ADAFLAGS (and BOOT_ADAFLAGS) are no longer p
BTW, I assume someone is working on fixing the fact that currently
there is no simple way to know at which stage the bootstrap is,
while it was obvious with the previous approach:
stage1/xgcc -Bstage1/
That'd be great.
Arno
BTW, did you capture the fact that BOOT_ADAFLAGS are no longer
passed with the new configure; make bootstrap ? FWIW, I can't really do
more testing or give more feedback on the new approach until this is
fixed.
I just verified that it works with --disable-bootstrap; make bootstrap.
As for bootstr
Pat,
Not sure what you are trying to do . Are you trying to generate C code
from Ada? If so, can you clarify why? In other words, what is the high level
problem you are trying to solve and that you'd like to achieve? Is it the
ability to navigate in Ada code?
If you want to generate C from Ada, G
> Thanks for responding to my post. I am not trying to generate C but to follow
> the intermediate representation into the Ada runtime.
>
> So let's just say we had this:
>
> with Ada.Text_IO;
> use Ada.Text_IO;
> procedure Do_Delays is
> begin
> Put_Line("Wait 5 seconds.");
> delay 5.0;
> After rtems initialization a thread is created which calls the gnat_main
> function and then runs the rts and the task.
> What I see so far is that after the hello_tasks delays itself the
> Complete_Master procedure (s-tassta.adb:444) is called, but with
> Self_Id set to the Id of the hello_task.
> > > I would like to know from where Complete_Master is called to break there
> > > and
> > > find out why it uses the wrong id.
> >
> > Why don't you simply put a breakpoint on Complete_Master?
>
> That's how I found out about the wrong/weird Self_Id.
Then you should also get a backtrace which
> @Arnaud: I saw quite a lot of #pragma Debug-lines in the rts-code. Is there a
> simple way of activating them without having to recompile gnat?
No, you need to compile the runtime with -gnata to enable assertions and
enable support for pragma Debug. You can add gnata to GNATLIBFLAGS
in libada/Ma
> > package Import is
> >
> >function Foo return System.Address;
> >pragma Import (C, Foo);
> >
> >function Bar return Integer;
> >
> > end Import;
> >
> > package body Import is
> >
> >function Bar return Integer is
> > function Foo_2 return Integer;
> > pragma Imp
At AdaCore, we have switched most of our product documentation the
rest/sphinx format: http://sphinx-doc.org/
which provides most of the advantages of texinfo (text format,
can generate output in multiple formats, supported by free software), as well
as additional advantages, at least for us (more
Thanks for the quick feedback!
> Given the long term maintenance issues around texlive/texinfo,
> investigation of other formats is wise. The fact that sphinx can
> generate .texi files is a huge win from a flexibility standpoint.
Indeed. We've been looking for a possible replacement format for
> >- the GNAT doc source would be in rest format (.rst files) instead
> > of texinfo (.texi files)
>
> What about the preprocessor for the VMS specifics? Will it go away?
Yes, we are about to baseline VMS maintenance, and the VMS specific doc
will go away in any case.
> >- we would still prov
> cc'ing Eric B since I remember him mentioning that they autogenerated
> texinfo from Sphinx and I am wondering if this is manual or autogenerated.
No, that was me, mentioning that we were planning to do that in the future,
but not yet.
> Other than fixing the manual or downgrading makeinfo, any
> All the reported errors look like the following two:
>
> exp_ch4.adb:6502:07: "Check_Float_Op_Overflow" is undefined (more
> references follow)
> exp_ch4.adb:6852:19: (style) misplaced "then"
That does not ring a bell, but this looks like a transient glitch (or some
kind of inconsistency).
I'd
> >If only the first variant is allowed (with the named parameters in the
> >order declared in the prototype), then this would not affect code
> >generation at all - the designators could only be used for static error
> >checking.
> >
> >If the second variant is allowed, then the parameters could b
> {"@ada",
>"\
> %{pg:%{fomit-frame-pointer:%e-pg and -fomit-frame-pointer are
> incompatible}}\
> %{!S:%{!c:%e-c or -S required for Ada}}\
> gnat1 %{I*} %{k8:-gnatk8} %{Wall:-gnatwa} %{w:-gnatws} %{!Q:-quiet}\
> %{nostdinc*} %{nostdlib*}\
> -dumpbase
> %{.adb:%b.adb}%{.ads:%b.
tainer-scripts update_web_docs_svn as
> follows last year, might this be related?
>
> 2014-08-01 Arnaud Charlet
>
>* update_web_docs_svn: Simplify build of gnat_ugn.
>
> Is the patch below a proper fix?
Your patch looks good to me.
> Index: index.html
> ===
> With the move to git fairly imminent now it would be nice if we
> could agree on a more git-friendly style of commit messages; and,
> ideally, start using them now so that the converted repository can
> benefit from this.
>
> Some tools, particularly gitk or git log --oneline, can use one-line
>
> > (does bootstrapping GNAT with
> > a non-GNAT Ada compiler work? It really should!),
>
> I could work on that if you (or someone else) gives me a non-GNAT Ada compiler
> for my machine :-)
To be more serious: no, bootstraping GNAT with a non-GNAT Ada compiler doesn't
work and isn't supported,
> > There are three main areas that require attention:
> >
> > 1) Regular builds of the SPE configuration and regular GCC testsuite
> > runs that are reported to the gcc-testsuite mailing list.
> >
> > 2) Timely reports of any regressions.
> >
> > 3) An active GCC developer who is the point of c
FWIW, at AdaCore we're using e500v2-wrs-vxworks for our VxWorks
toolchain for SPE.
Arno
> Ideally, you should create a general copyright assignment to GCC -- a
> "futures" assignment of all patches for GCC. you can select which
> patches to contribute.
>
> If you insist on limiting it, you can specify files. But that always
> runs into the potential problem of files that were omitt
Also I forgot to mention: I would recommend putting your GCC 4.7 based
port on e.g. github so that other people can benefit from it, since putting
this code base in gcc.gnu.org isn't on the table as per David's emails. I
think that would be the best compromise.
Arno
> I'm trying (again) to work out how to build a GNAT cross compiler with
> no runtime, but with the tools.
As explained in the documentation, you need to first build a native GNAT
compiler with the same sources before building a GNAT cross compiler.
Arno
> When I configure with
> --enable-build-with-cxx --enable-languages=c,c++,ada
> I get the appended. The problem is that the Ada code is looking for C
> symbol names but the names in the .o files are mangled for C++.
Right, or rather than we want to use the C compiler to compile all those
fil
> I'm not sure because I don't think we want to compile the C files of the Ada
> runtime with the C++ compiler. We want to do that only for the compiler.
Right, we definitely don't want to use the C++ compiler for building the
Ada run-time.
Arno
> But apparently they already are (when building the compiler), otherwise
That's different: some parts of the run-time is used with a native compiler to
bootstrap GNAT.
The GNAT run-time is built separately using the target compiler (potentially
different from the native compiler), so bootstrappi
> Why not? If extern "C" is used correctly, the result will work just the same,
> and the improved type checking etc. would be an asset here just as it is
> elsewhere.
We don't use much C code, so the extra benefits wouldn't really be useful
to us (we already get much more benefits by having most
> I wonder if it might make sense to more strongly suggest to use GNU as
> on AIX? The install manual currently says
>
> The native @command{as} and @command{ld} are recommended for
> bootstrapping
> on AIX@. The GNU Assembler, GNU Linker, and GNU Binutils version 2.20
> is required to bootstrap
> > FWIW, we've recently made this choice/switch for GNAT at AdaCore, which
> > allows us in particular to use dwarf-2/3 debug info.
>
> Is AdaCore maintaining GNU Binutils on AIX?
We're "maintaining" it sufficiently for our needs, yes.
> I do not believe that
> Binutils implements some toolchai
> Is it possible to compile a gnat cross compiler based on gcc 4.5.2
> using my
> pre-installed gnat native compiler based on gcc 3.4.6 ? Or should I try
> to
> build my own local native compiler based on gcc 4.5.2 ?
You needed a matching native compiler first in order to build
> The entries in parens are only covered indirectly and may or may not
> warrant their own components. I'd argue that it would be helpful to
> have libada and libgo components of their own (while libcpp would
> probably be overkill), but of course that's ultimately up to the
> respective maintaine
> I think we should have different components only if we have different
> maintainers for them (or, if they do not naturally belong to another
> component).
Right, precisely for Ada that would be the same set of people.
> Note that most bug submitters confuse the bug component with the
> language
> Ah, and I see you also had an after-thought in a second reply. I'll respin
> this if you think it's horribly ugly, otherwise I'll send it to -patches with
> a changelog once the build has finished.
It is indeed ugly.
I'd use GNAT_STRUCT_STAT and GNAT_FOPEN instead.
Since these are macros, I
> Eh, this exception doesn't change that the GPLv2 program perceives the
> GPLv3 as incompatible. Why would it?
Is it GPLv2 or GPLv2+? If the latter (the license includes something like
"either version 2 of the License, or (at your option) any later version"),
then nothing prevents you from distr
> GPLv2 (I tried to stress by writing "GPLv2-only").
Understood.
> > If the latter (the license includes something like "either version 2
> > of the License, or (at your option) any later version"), then
> > nothing prevents you from distributing the program under GPLv3+
> > instead of GPLv2+.
>
>> ./c35502i.o: In function `_ada_c35502i':
>> c35502i.adb:(.text+0x156): undefined reference to `.L47'
>> collect2: ld returned 1 exit status
>> gnatlink: error when calling /home/rth/work/gcc/bld-sjlj/gcc/xgcc
>> gnatmake: *** link failed.
>> FAIL: c35502i
>
> I haven't been able to figure out
> > 9drpc.adb:-- Copyright (C) 1992-2009, Free Software
> > Foundation, Inc. --
> > a-assert.adb:-- Copyright (C) 2007-2009 Free Software
> > Foundation, Inc. --
> >
> > Are both of these OK? Should they be changed
> > to be the same?
> >
> > I doubt it makes any
Hi,
libcpp/cpplib.h defines:
/* Callbacks for when a macro is expanded, or tested (whether
defined or not at the time) in #ifdef, #ifndef or "defined". */
void (*used_define) (cpp_reader *, unsigned int, cpp_hashnode *);
void (*used_undef) (cpp_reader *, unsigned int, cpp_hashnode *);
Hi,
Back in 2009-12-15, you wrote an interesting patch to take into account
TAB chars and compute column numbers according to GNU standard in GCC:
http://gcc.gnu.org/ml/gcc-patches/2008-12/msg00880.html
I see that this patch is not present in either trunk or in the
diagnostics-branch.
Could you
> I suppose the idea is to emit each used macro a single time only, the
> code seems to confirm this.
Makes sense indeed (and at least matches what the code does).
> Arnaud> so would the addition of a new callback (e.g.
> Arnaud> void (*used) (cpp_reader *, unsigned int, cpp_hashnode *);
> Arna
> I never ran the patch through the test suite. I assume it would require
> some test suite changes.
OK, I can do that and see where things are.
> Also, I've experimented more with Aldy's location improvement patch
> (which is now on mainline, I think diagnostics-branch is closed), and
> Emacs (
> Are rpaths as portable as shared libraries or do we support a host
> architecture that has shared libraries but no equivalent to rpath?
Windows (mingw) comes to mind at least.
Arno
> As the last of the shared GCC runtime libraries, libgnat.so and
> libgnarl.so lack symbol versioning support and a defined ABI.
> Currently, they use libgnat-4.5.so and libgnarl-4.5.so SONAMEs, what
> libtool calls release versioning. If the libgnat/libgnarl ABI is really
> that fluent that it c
> > Since I barely know any Ada, or Ada mangling,
>
> Ada subprogram name mangling depends on the order of declarations in
> the source file. This order is also somewhat constrained by language
> rules. I think this means that defining a stable ABI is rather
> difficult.
Not sure what this part
> One of the advantages of "mangling" overloaded functions C++-style, instead
> of using a simple counter is that the latter makes it basically impossible
> to define a stable ABI.
It actually is not such a problem in Ada, where declarations are first class
citizens with specific rules about pla
> For critical things I did just what -frtl-abstract-sequences did (along
> with some hand optimizing) and I've seen performance improvements of 50%
> and more just by getting my working set of code to fit into the cache-size.
>
> Once the feature is removed: Will there ever be any chance that t
> Is it intended that the GCC C compiler support nested functions?
Yes, it's an extension provided by GNU C, not part of ISO C.
Arno
> Is the following okay to commit if it passes testing?
OK for stage 1 (GCC 4.5), currently pretty much everything is frozen on
mainline, except regressions (I hope stage 1 will open soon, since we have
monthes of backlog of various fixes and new development blocked right now
which will be painful
> > OK for stage 1 (GCC 4.5), currently pretty much everything is frozen on
> > mainline, except regressions (I hope stage 1 will open soon, since we have
> > monthes of backlog of various fixes and new development blocked right now
> > which will be painful to merge).
>
> If the ACATS test fails
The requirement is GCC >= 3.4
This is documented at: http://gcc.gnu.org/install/build.html
('Building the Ada compiler'), except that the online version matches GCC
4.3, not trunk. The trunk version (gcc/doc/install.texi) reads:
<<
In order to build GNAT, the Ada compiler, you need a working GNAT
> > Do we have time (and release-managerial leeway)? I probably couldn't
> > start sending patches until the other side of the weekend.
>
> I think we can take the (small) risk for 4.4.0; it's only the Ada compiler and
> only on Windows.
It's too late for that in my mind, this feature should f
> IMO you cannot backport such an incompatible change to a release branch. If
> the Windows maintainers are confident enough with it and given that we know
> there is no fundamental issue as far as GNAT is concerned, why not try?
Because stage 4 is not the right stage for such experiments.
Als
> I doubt that this can be deemed an experiment, we know that it works.
We know that it works with our sources and GCC 4.3. We have no idea how
well it works with GCC 4.4: we don't do mingw builds there.
> It's not just cygwin, it's also mingw. The Ada compiler is quite broken on
> Windows sinc
> > I doubt that this can be deemed an experiment, we know that it works.
>
> We know that it works with our sources and GCC 4.3. We have no idea how
> well it works with GCC 4.4: we don't do mingw builds there.
BTW, we have local patches not yet integrated that are needed for proper
ZCX support,
> > But I'm against doing more than fixing the merge glitch at this stage.
>
> I think that the Windows maintainers should have the final word though.
This change concerns more Ada than the windows port but in any case, I
can't imagine such change being put in stage 4.
Arno
> > You are missing s390(x) here which is even a secondary architecture.
>
> Yes but this kind of machine is not easily available at least for
> now :).
BTW, for at least some of the target architectures, you might be able to
run an emulator (e.g. qemu) rather than physical hardware.
This also h
> The license wording will soon be changed and Ada gcc/ada/scn.adb
> (function Determine_License) currently checks about licence.
> Any change to the wording breaks Ada bootstrap as Jakub found out.
>
> How should we proceed?
scn.adb needs to be updated to recognize the new text I assume.
What wo
Laurent,
I keep getting the following error when doing an incremental build (the first
time from scratch it works, and then it always fails):
ln -s ../.././gcc/ada/rts adainclude
ln -s ../.././gcc/ada/rts adalib
ln: creating symbolic link `adalib/rts' to `../.././gcc/ada/rts': File exists
make[2]
> The problem is that the dependencies in ada/gcc-interface/Make-lang.in
> are out of date.
Indeed, sorry about that.
Now fixed.
* gcc-interface/Make-lang.in: Update dependencies
The change in sinput.adb itself is actually a change adding two new functions,
not yet used, so with no visi
1 - 100 of 205 matches
Mail list logo
