>> The current statement (https://gcc.gnu.org/install/prerequisites.html) is:
>>
>> GNAT
>> In order to build GNAT, the Ada compiler, you need a working GNAT compiler
>> (GCC version 5.1 or later).
>>
>> so, if 5.1 is not working, then perhaps a PR is in order.
>
> I will do that, if the "sh
> Hi Arnaud, do I have permission to take/copy the code examples from
> AdaCore's blog entries? I could not find a "copy"right section or
> disclaimer. I know this is a very minor detail, but still. It would save
> me quite a bit of time :)
Yes, that’s fine.
Arno
> The wwwdocs repo is documented at https://gcc.gnu.org/about.html#git
>
> A change to those pages should be sent to the gcc-patc...@gcc.gnu.org
> mailing list like any other patch for GCC. You should include
> "wwwdocs" in the email Subject so people know to pay attention (or
> ignore it as appro
> >In particular can you explain the motivation behind all the changes in the
> >gcc/ada/doc directory?
>
> Sure:
> 1) All Sphinx manuals live in a directory where index page is called
> index.rst. That's why
> I moved e.g. this: gcc/ada/doc/{gnat_rm.rst => gnat_rm/index.rst}
> 2) I moved latex_e
> I've got something that is very close to be a patch candidate that can be
> eventually merged. Right now, the patches are available here:
> https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;a=log;h=refs/users/marxin/heads/sphinx-v3
FWIW I would prefer to review the changes posted here directly with a
> 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;
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
> 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
>
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
> 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
FWIW, at AdaCore we're using e500v2-wrs-vxworks for our VxWorks
toolchain for SPE.
Arno
> > 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
> > (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,
> > 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
> @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
> > > 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
> 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.
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
> ===
> {"@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.
> >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
> 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
> 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
> >- 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
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
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
> This is exactly the patch referenced in the pointer to the upstream repo.
> Arno, does this fix the build for you?
Well now I encounter:
/users/charlet/fsf/trunk/libsanitizer/sanitizer_common/sanitizer_linux.cc: In
function '__sanitizer::uptr __sanitizer::internal_filesize(__sanitizer::fd_t)':
> > Would appreciate a fix/work around!
>
> Configure with --disable-libsanitizer.
Will do, thanks.
> >>> Looks like another issue for the libsanitizer maintainers.
> >>
> >> I've been doing bootstraps, but didn't see this because the
> >> kernel header linux/vt.h use on the RHEL6 system I was doing
> >> builds on has that field renamed. Looking at our SLES11
> >> devel system I do see the probl
>>>
>>>
>>>
>> Or alternatively you could use the Ada language where integer overflow
>> and buffer overflows are built into the language are fully handled by
>> the compiler.
>>
> Yeah, I will suggest my boss in our project that cost $1 000 000 to
> fire all C programmers, hire ada programmer
> Hi, as I brainstormed how prevent possible overflows in memory allocation I
> came with heretic idea:
>
> For gcc -D_FORTIFY_SOURCE=2 we expand all multiplication with size_t
> type by one that checks for integer overflow and aborts on it. This
> would prevent most overflow at cost of breaking s
> I want to run the Ada Conformity Assessment Test Suite in
> gcc/testsuite/ada/acats on a ZFP runtime.
> But the ACATS uses packages such as ADA.TEXT_IO which are not available on a
> ZFP runtime.
> Is there any way to configure the ACATS for a ZFP runtime environment?
Not really, this wouldn't m
On Wed, Jan 09, 2013 at 08:43:11AM +, Luke A. Guest wrote:
> Hi,
>
> I'm trying to add GNAT to Yocto and still coming across problems. I have
> a number of questions about GNAT as a cross compiler, I know it wasn't
> designed as one within the GCC tree, but I think it needs to be capable
> of
> Okay. If there is no direct use of TLS in GNAT, then testing with the
> new support would not provide any additional feedback and sanity
> checks of the support.
Right.
> It would be helpful for Adacore to contribute the support upstream
> into the FSF tree, not only to make GNU Binutils more useful on AIX
> but to avoid others duplicating your work -- especially in
> incompatible ways.
Indeed.
> The large TOC feature (cmodel=large) is not used by default and th
> The purpose of this discussion (whoa, 30+ thread in the gcc mailing
> list for being b@d@ss) is that I will learn the sufficient amount of
> things so I WON'T "commit the crime".
>
> I would like to be clear from the start so I won't have any
> problems; I really want to serve my one trillion us
> I cannot reproduce, but this might come from missing dependencies in Make-
> lang.in for the affected files.
Right, there's no explicit dependencies for seh_init.o at all, although
this is not something new. Has something changed recently in the way
e.g. system.h or similar are generated/handled
> On IRC, Richi says that this is a parallel make issue. Re-starting
> make works around the issue.
>
> For now, I'm forced to disable Ada bootstraps. Could someone in ada
> land take a look at this?
I'll have a look.
Arno
> I added some reference returning member functions in cgraph.h,
> and now Ada appears to break while including cgraph.h. Huh?
I suspect you are doing a parallel build (make -jxx), and the error is actually
unrelated to the lines you quoted, but occurs above.
Do a 'make' and you'll see the error
> --- single/blanks_to_underscores.ali 2012-06-23 18:15:09
> +++ multi/blanks_to_underscores.ali 2012-06-23 19:07:39
> @@ -7,20 +7,17 @@
> .
> -X 3 blanks_to_underscores.adb
> +X 1 blanks_to_underscores.adb
>
> In multi source compilations, main units may get assigned different
> unit numb
> I will now start looking into the second problem,
>
> > 2) The 'X' lines in the ALI files are not what they should be.
> > This is due to the fact that Lib.Xref.Generate_(Definition|Reference)
> > is
> > called during semantic analysis. However, when I discover that a
> > tree was already built
> Well, if you write code so obvious that -Wuninitialized is annoying then:
No, the code is certainly not obvious, and improving -Wuninitialized although
a nice goal is likely to require lots of effort, likely at the expense of
removing some useful warnings.
> either the implementation of -Wunini
> From the list I gave earlier:
>
> -Wformat
> -Wimplicit
> -Wreturn-type
> -Wsequence-point
> -Wswitch
> -Waddress
> -Wstrict-aliasing
> -Wenum-compare
> -Wreorder
> -Wpointer-sign
OK, the above list looks reasonable to me at least as a starting point
that could be a bit refi
> The simpler requests are -Wall by default. (there are some occasional
> -pedantic).
>
> The ones I've heard in person -- with the requesters quite competent and
> respectable programmers -- are in less polite words what I can possibly
> convey in this discussion. Adding more options isn't on t
Can someone summarize what the most useful warnings people are expecting
that -Wall would bring?
I suspect not all of -Wall would actually be welcome/a good idea by default,
and we might be looking for a better compromise where most warnings are
enabled by default, but not "all".
In particular, I
>>> Has anybody tried to build 4.7 on Ubuntu 11.10 system. I am getting the
>>> following linking problem (no special configure switches):
>>>
>>> /usr/bin/ld: cannot find crt1.o: No such file or directory
>>> /usr/bin/ld: cannot find crti.o: No such file or directory
>>> /usr/bin/ld: cannot find
> 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
> 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
> 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
> > 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
> 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
> 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
> 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
> 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
> 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 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
> I wouldn't mind this change. It is still the case that Ada will
> selectively turn itself off when it cannot find a stage0 gnat
> compiler, right?
Right.
> > I'd like to reiterate a request from the summit that is related to the
> > default languages discussion: Add Ada to the default languages in
> > exchange
> > for java+libjava. It builds nicely parallel (and fairly quick), doesn't
>
> I should point out while supporting this (and, in general,
> To be clear, it's code maintained by Adacore that has run afoul of the
> change. I don't believe gprbuild is part of Adacore's public repository,
> so I'm not quite sure how I'm supposed to obtain a version of gprbuild that
> will compile with GCC 4.6.0. This version was released with GNAT GPL
> Given the current limitations of Gimple, another area to focus on could be
> task parallelism (rather than data parallelism). In that case a language
> like [Google] Go (via GCC) might make a better talking point than C or
> Fortran.
An even better starting point would be Ada which has built-in
> In function output_type_enum of gcc/gengtype.c, we replaced
>
> - if (s->kind == TYPE_PARAM_STRUCT && s->u.s.line.file != NULL)
> + if (s->kind == TYPE_PARAM_STRUCT && s->u.param_struct.line.file !=
> NULL)
>
> And Gengtype works like before with c,c++, lto enabled.
>
> Do you think we have
> Allowing the same option to behave differently in the driver and in cc1
> regarding whether it takes operands seems like error-prone complexity;
> every piece of code that now or in the future looks at CL_SEPARATE will
> need also to check whether it is in the driver or in cc1. Why is this
> cod
> > I hit the following problem when trying to build a ppc64 Linux kernel
> > from svn today:
> >
> > # gcc -Wp,-MD,scripts/basic/.fixdep.d -Wall -Wmissing-prototypes
> > -Wstrict-prototypes -O2 -fomit-frame-pointer -o
> > scripts/basic/fixdep scripts/basic/fixdep.c
>
> The options passed to inte
> The trunk is frozen for all changes starting this Wednesday, 20:00 UTC
Web will be the 30th, not the 28th, can you confirm the date?
Arno
> 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
> > 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
> 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
> 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
> 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 (
> 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
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
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 *);
> > 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
>> ./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
> 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+.
>
> 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
> 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
> Switching gnatbind to generate Ada if there's nothing against
> it might be a better solution since stage1 uses the system gnatbind, so
> a patch to current gnatbind will not help (unless we push it to branches
> and tell user to install a fairly recent gnatbind first).
This does create a bootst
> I don't really see any urgency for this change, yes gnatbind has
> the option to generate C, but it is not the normal path, and only
> of use in unusual circumstances, so I don't really see the need
> for this output to be C++ compatible. The documentation doesn't
> claim this after all.
We're t
> I don't really know how the Ada compiler works, but it looks like this
> code is generated by the gnatbind program. I bet it would work if
> gnatbind -C emitted this at the start of the output:
>
> #ifdef __cplusplus
> extern "C" {
> #endif
>
> and emitted this at the end:
>
> #ifdef __cplusp
> > What is the way forward: fixing in some way the Ada Makefile? Or doing
> > search and replace in case of keyword/identifier conflict? If
> > search/replace, do AdaCore people have an opinion on the best way
> > to proceed to avoid maintenance issues in the various trees? (eg: commit
> > of thos
> 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
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 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
> > 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
> > 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
> > 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,
> 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
> 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
> > 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
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
> > 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
> 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
> 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
> 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
> RTEMS has BSPs for a couple of simulators that
> do not have a source for clock tick interrupts.
> We simulate the passage of time by having a special
> IDLE task advance time. This works well enough
> when all tasks block but if a test depends on
> something like timeslice expiration, that won'
> My point is that if the rest of the compiler extends diagnostics.c to
> handle caret and ranges and all other features, Ada would need carry
> all that around even if gnat has its own diagnostics machinery. But
> perhaps that is OK.
Certainly OK, what possible (noticeable) issue would you forese
> > Well, clearly, the preprocessor and handling of #include is very
> > C/C++ specific, and not used by Ada or Fortran.
>
> Both Ada and Fortran are linked with libcpp.a.
Sure, because as we've said, libcpp is not modular enough. Clearly Ada does not
need to link with A C preprocessor at all.
>
> Not just that, probably Fortran/Ada are already duplicating stuff that
> is in libcpp or they are implementing their own version of stuff that
> C/C++ are lacking (caret diagnostics? character encodings?).
Well, clearly, the preprocessor and handling of #include is very
C/C++ specific, and not u
> If we want to implement re-opening files and reading strings given
> locations, then opening/reading files should also be moved out of CCP
> to its own module/namespace/object.
Agreed. Other modules may find these APIs very handy.
Currently many features are only available very deep or hidden in
> Would your implementation also handle two locations for tokens that
> come from macro expansion?
macro expansion are tricky to handle as far as I could see, so currently
this is not handled. It's tricky because some locations are "real" in
the source, and some are "virtual" from the macro.
Cons
1 - 100 of 205 matches
Mail list logo
