> > 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
> 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
> 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
> 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
> 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
> > 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
> 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
> 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
> 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
> 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
> > 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,
> 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.
> LIBGNAT=../rts/libgnat.a
> GCC_LINK="$(CC) -static-libgcc $(ADA_INCLUDES)"
> +TOOL_CC=$(CC) -static-libgcc
I'd rather avoid code duplication and reuse GCC_LINK if possible, or
split GCC_LINK in two if needed.
Otherwise the tools part is generally fine with me (passing -static-libgcc
to build
> I thought so too, and indeed tried it this way at first, but got:
> "../../xgcc -B../../ -static-libgcc -I- -I../rts -I.
> -I/Users/peter/cvsco.build/gcc-4.1/gcc-4_1-branch/gcc/ada" -DIN_GCC
>
> /bin/sh: line 1: ../../xgcc -B../../ -static-libgcc -I- -I../rts -I.
> -I/Users/peter/cvsco
> Attached is a patch to the 4.1 branch, I think it will apply to mainline
> too. Branch built fine on powerpc-apple-darwin8.4.0 with c,ada enabled.
OK to commit, thanks for taking my comments into account.
Arno
> Then set a var in link.c for darwin and use that as the conditional?
>
> #elif defined(__APPLE__)
> const char *__gnat_run_path_option = "-Wl,-filelist";
> const char *__gnat_object_file_option = "";
> char __gnat_shared_libgnat_default = STATIC;
> int __gnat_link_max = 262144;
> unsigned char _
> I'm not sure we'd be willing to trade minimal dependencies for "future binary
> compatibility", but I see your point. I'll let Arnaud decide.
Well if you ask me, I'd rather not put anything special for Darwin.
Failing that, I'd rather see a very minimal change.
Having systematically a depende
> You mean value of zero or one, zero everywhere but if on darwin (what's
> the define for this target?), imported in gnatlink.adb, if one then if
> GNAT_Static add -static-libgcc elsif GNAT_Shared add -shared-libgcc?
Right, something like that.
But then, I am more and more inclined to think that
> As an additional note, this is Bug ada/13408. Although the change
> affects the ADA "ABI"
Note that there is no clear Ada ABI at this stage, and no guarantee of
stability. It's a long term goal to achieve Ada ABI stability, but it's
a huge work.
So changing this is certainly fine.
Arno
> This has already been reported as PR 26348 and it looks like a bug
> in the Ada front-end.
Note that technically, its still a regression caused by a non Ada patch.
Anyway, hopefully Eric and Jeff can work together in identifying the
proper fix.
Arno
> I'm wondering if this affects the testsuite in any way.
No, that's expected. The script is simply compiling all .ads and then all
.adb files without worrying whether .ads files should actually be compiled
or not.
Arno
> Returning to a single system.ads as before is not an option here because the
> split was done for a good reason:
Right, definitely not an option. In particular since there are potentially
many other files that will be different between configurations.
Ada currently does not have built-in suppor
> I believe you that this is not an easy job. Maybe it is eased a bit by the
> recent toplevel bootstrap changes?!
I do not think so. The situation wrt multilib has not changed AFAIK.
And in any case, this toplevel bootstrap change is still incomplete wrt
Ada (missing passing flags to Ada Makefil
> gcc -c -g -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes
> -Wmissing-prototypes -fno-common -DHAVE_CONFIG_H -I. -Iada
> -I../../gcc/gcc -I../../gcc/gcc/ada -I../../gcc/gcc/../include
> -I../../gcc/gcc/../libcpp/include -I../../gcc/gcc/../libdecnumber
> -I../libdecnumber../..
> Any ideas? Is this perhaps related to FC5 memory access rather than gcc?
Right. You likely need to enable execution on stack.
Arno
> It's that time again... I just want to ask if there's any progress on
> Ada being multilibbed?
Are you working on it perhaps ?
Arno
>
> I'm experiencing ACATS failures that manifest in
>
> splitting
> /abuild/rguenther/obj4/gcc/testsuite/ada/acats/tests/a/ada101a.ada into:
>ada101a.adb
> BUILD
> FAIL: ada101a
> BUILD
> FAIL: c760009
> splitting
> /abuild/rguenther/obj4/gcc/testsuite/ada/acats/tests/cd/cd2a22i.ada in
> In the same vein as my 20050418 patch, may be the following will help.
> Tested on x86_64-linux.
Looks reasonable to me. Of course it would be nice if the underlying bug
were fixed at some point, but that's another issue.
> 2005-05-15 Laurent GUERBY <[EMAIL PROTECTED]>
>
> * ada/acats/
> I don't think it's a good idea to compile in rpaths to non-standard
> (user-specific) directories by default.
Whether it should be the default is debatable and different people will
have different opinions.
Whether there should be an option to do that seems very useful and
desirable to me. That
I can no longer configure/build GCC with Ada enabled after your change:
r115145 | bonzini | 2006-07-03 09:58:08 +0200 (Mon, 03 Jul 2006) | 24 lines
2006-07-03 Paolo Bonzini <[EMAIL PROTECTED]>
PR other/27063
* configure.in: Test subdir_requires and give an appropriate
e
> The attached patch moves the basic installation of the compiler
> drivers from gcc/*/Make-lang.in to gcc/Makefile.in. The Make-lang.in
> has only to inform the driver's name.
What about Ada ? Will things still work after your change ?
It would seem cleaner (if not mandatory) to take all language
> > We are working on a project to add fixed-point arithmetic support to GCC.
> > A GCC project description page is available here
> > http://gcc.gnu.org/wiki/FixedPointArithmetic
> > and we will create a GCC branch in the near future. If you have
> > any suggestions or comments, please respond.
> 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
> >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 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
> 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
>>>
>>>
>>>
>> 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
> >>> 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
> > Would appreciate a fix/work around!
>
> Configure with --disable-libsanitizer.
Will do, thanks.
> 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)':
>>> 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
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
> 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
> 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
> 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
> 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
> --- 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 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
> 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 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
> 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
> 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
> 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.
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
> For reference, the last test results posted for either of these seem to be
> yours last July, so given your deprecation proposal we can take it there
> is no evidence of current GCC users for these platforms at present. If
> these targets are removed, I believe we can remove
> --enable-threa
Having a tutorial during the GCC summit on Ada and how some of its constructs
stress more than other languages the back-end in some cases sounds indeed
like a very good idea, so we will work on this, thanks for the suggestion!
Arno
> I tried to build Ada at trunk revision 131899 on Linux/ia32. It failed
> on RHEL4/ia32 and Fedora 8/ia32. But I can build Ada on Linux/Intel64.
> Is there a known problem?
It should work AFAIK. What kind of error did you get ?
Arno
> /export/build/gnu/gcc-ada/build-i686-linux/./gcc/xgcc
> -B/export/build/gnu/gcc-ada/build-i686-linux/./gcc/
> -B/usr/gcc-4.3/i686-pc-linux-gnu/bin/ -B/usr/gcc-4.3/i686-pc-linux-gnu/lib/
> -isystem /usr/gcc-4.3/i686-pc-linux-gnu/include -isystem
> /usr/gcc-4.3/i686-pc-linux-gnu/sys-include -c
I can confirm that I had no troubles building i686-linux with latest
sources.
I suspect a miscompilation of the previous stage compiler, possibly caused
by a bad initial compiler used to start the bootstrap, or the use of
"dangerous" compiler option during bootstrap.
I'd suggest trying again with
> 1) Is it supposed to work? (i.e. building an Ada cross compiler 4.3 by a
> 4.2 compiler)
No, as documented, you need a matching native compiler to build a cross Ada
compiler (e.g. build from the same 4.3 sources a native compiler first, and
then use it to build the cross compiler).
> 2) does i
> gnat.dg/socket1.adb and socket2.adb are identical AFAICT, is there a
> special reason to have both?
Probably none. Feel free to remove one of them.
Arno
> Still no answer after two PING (December and February, for patches
> submitted in November, and there are others not mentionned here). Is
> there any Ada front-end maintainer handling patches proposals?
Yes, as can be seen by other discussions on other patches.
> Since 2007-12-19, which is the
> Did you ever get around to looking at my hardware
> interrupt task patch? I know it dates back to Nov/Dec
> but I quite asking about it during stage 2. I submitted
I reviewed it during stage 2 and gave you my comments (the patch was not quite
ready at this time).
> it a couple of times this m
> Since 2007-12-19, which is the date of the latest AdaCore batch
> merge (three months ago), the Ada front end has only received the
> following patches:
>
> - platform-specific and build-related patches
>
> - gigi (Ada structures -> GCC structures) patches from Éric Botcazou
> in *.c fi
> - large merges done in a very short period of time
> - no corresponding test cases or non-regression tests
> - no reference to existing PR
> - no closing of corresponding bugzilla entries
I'm sorry, but that's simply wrong. Test cases are posted, and when suitable,
are added to the test
> In Interfaces.Fortran.Blas, there is a reference to libgnalasup. It has
> been introduced by this commit:
>
> Author: charlet <[EMAIL PROTECTED]>
> Date: Tue Aug 14 08:50:51 2007 +
>
> 2007-08-14 Geert Bosch <[EMAIL PROTECTED]>
>
> * i-forbla.ads, i-forbla.adb, a-ng
> I confess I know little about Ada except that it has a formal syntax
> longer than the bible...
That's probably true. And the C++ one is about 30 or 40% bigger.
Arno
> I want to point out that the current implementation of lto is not
> compatible with "ln -r", and will need to be modified to support
> "cherry picking" the function bodies.
I assume you mean "ld -r", right ?
Arno
> Without Ada (=all) bootstrap gets down to 1h54 at -j1 so Ada is 0h24, or
> 17% of =all, without Ada and Java (=c,c++,fortran,objc) it gets down to
> 1h17 at -j1 so java is 0h37 or 27% of =all.
Note that I recently made the ada build parallel on trunk, so these figures
should be very different on
>> How can maintainers ensure this does not happen?
>
> What is your suggestion, stay with C? It doesn't have type safe enums
> either.
One possibility is to do what we do for Ada: have a style/coding checker
built into the compiler (C++ front-end) as a special switch, and enable this
switch du
> I've thought such a thing would be useful for C style as well.
Right. It just becomes more of an issue if people start using C++
which is a much more complex and large language, but it would also benefit
gcc developers today to have C coding standard checked automatically.
> One slight complica
> Thanks for taking the time to update this, Santiago!
>
> Let me ask our Ada maintainers to have a look as well, since this is not
> exactly my area of expertise. Geert/Robert/Arnaud, I'll be happy to apply
> that patch and make some tweaks based on your review.
Yes, the suggested changes are g
> The Ada status on tuples is now that you can build it (on i686 at least)
> but gnatmake is miscompiled (or rather, the global initializer stuff
> doesn't work - all the ___elabs are missing, as you can see in
> for example gnat.dg/renaming3.adb failing if you just use gnat1 from
> tuples in a tru
>> I had to solve one rts source issue though:
>> gcc/ada/system-linux-x86_64.ads and x86.ads do hardcode the number of
>> bits for a word (64 and 32 respectively), I changed them both to be
>> completely the same and use GNAT defined Standard'Word_Size attribute.
>>
>> - Word_Size: constant
> They can still read the wrong system.ads in case of multiple rts installed,
> the
> only way to be sure is to use gcc -c -gnatdg with your flags on your source
> :).
Not if they are using a proper IDE :-)
> This will need some additionals tests on MULTILIB in the LIBGNAT_TARGET_PAIRS
> machin
> The idea currently is to make these values
> explicit so that when people read system.ads, they know right away what
> the right value is.
>
> That's "when people read system.ads", not "when people read
> system-linux-x86.ads". In other words, he's not necessarily against
> automa
>> Right, that's one possibility, although people seem to be focusing
>> in system.ads alot, which is actually only the tip of the iceberg, and not
>> a real issue per se.
>
> Still it's the biggest problem so far.
No, the issue is setting the proper target when building gnatlib, most things
will
> In this same vein, I am very interested in using the gimple type
> system as a way to start moving gcc from being a C compiler that
> accommodates other languages to a compiler that handles different
> languages on an equal footing. The freedom that C and C++ "enjoy" to
> basically take a pointe
>> I do not know Fortran but from the description above, this is similar in Ada:
>> you cannot freely mix different pointers, and you cannot make a pointer out
>> of any variable, unless variables are marked 'aliased'. This semantic is
>> already expressed today in GCC trees, so I'm not sure what m
> 1/ Ada multilib build is enabled unless --disable-multilib is used in
> configure: this means that the Ada build has more opportunity to fail
> because of code generation bugs or libada source selection issue, but in
> this later case it will be a only few lines in gcc/ada/Makefile.in to
> fix it
> When danny and it wrote the ipa-type-escape pass, mark mitchell was all
> over us because we assumed that the type system had some semantic meaning.
> We ended up with a pass that generally finds nothing useful. I would very
> much like to redo that pass once we can mark a type as coming fro
> Yes I volunteer. We're in stage1 so we have some time to sort out
> reported issues before release.
OK. I'm still concerned that there is no simple fallback for all targets
that will break, except for --disable-multilib which is too strong since
it impacts other languages.
I'd be much more conf
Thanks Paolo for your explanations, things are getting much clearer!
> I volunteer to check if there is support for
> --enable-multilib=libstdc++-v3,libjava and if not add it. Unfortunately,
> --disable-multilib=ada cannot work (because --disable-xxx is the same as
> --enable-multilib=no).
Doe
>>> As an alternative, people that don't want multilibbed libada can not use
>>> libada altogether. More on this in a second.
>>
>> Still not clear to me what you mean here.
>
> I was thinking about using --disable-libada and instead using the "make -C
> gcc gnatlib" target. You will get no m
I'm including Doug Rupp who is our VMS expert and is one of the people
at AdaCore maintaining the VMS port.
> I stumbled in this while looking at how x-* host files are used. There are
> two files in this configuration that "must be compiled with DEC C".
>
> One is vcrt0.o, which has about 5 li
> Well, the point is, I'm using a GNU/Linux system I mainly built from
> scratch, so there's no easy package-installer available for me and I've to
> built everything from source (which is, of course, "my own fault"). My
> system started out with a gcc C compiler, so I could easily bootstrap and
> Any suggestions?
I would double check that you are indeed using the freshly built
corresponding native. Maybe your native installation didn't work as
expected and your building from an older compiler. That's the
most likely explanation.
Alternatively, there have been changes recently in the lib
> > 2008-08-01 Eric Botcazou <[EMAIL PROTECTED]>
> >
> > * gcc-interface/utils.c (convert_vms_descriptor): Add
> > gnu_expr_alt_type parameter.
> > Convert the expression to it instead of changing its type in place.
> > (build_function_stub): Adjust call to above function.
> As I warned in http://gcc.gnu.org/ml/gcc/2008-07/msg00387.html,
> the new technique for generating s-oscons.ads does not work
> for RTEMS. The OS .h files are not available when the compiler
> is built -- only those strictly owned by the newlib C library.
>
> As indicated by this from the build
> As an alternative to Arno's suggestion, maybe you could use the
> --with-sysroot configure parameter to make the required headers
> available to the build process. I know others have used this method on
> some cross targets.
Another (at least short term) solution would be to use
DUMMY_SOCKETS_TA
> That is clear. Thanks. I personally would be perfectly happy if the
> compiler said
> bug.c:4.COLUMN: error: called object is not a function
> That is, fixing the compiler to includes parts of the source code in
> the error message itself is, for me, of considerably lower priority
> than fi
> Oh yes. Well, there is a lot of fine-tunning to do but I think that
> would be covered by A.1 and the binary_op expression would have at
> least two locations begin/end pointing to X and r. If we are able to
> print ({break;}), in the example I gave earlier, then we will be able
> to print nice r
> 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
> 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
> 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
> > 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.
>
> 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
> 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'
> > make[2]: Entering directory `/home/revital/mainline_ccp/build'
> > make[3]: Entering directory `/home/revital/mainline_ccp/build'
> > rm -f stage_current
> > make[3]: Leaving directory `/home/revital/mainline_ccp/build'
> > Comparing stages 2 and 3
> > warning: ./cc1-checksum.o differs
> > Boot
> I've many times succesfully bootstrapped GCC with other (older!) versions
> (2.8.1, 3.4.6) so it's just random bad luck we ran into this now. I also
> verified that your tree.i file compiles with 4.1.3 (prerelease) and 4.2.2
> (prerelease). Mainline obviously works too or nobody could bootstrap
101 - 200 of 205 matches
Mail list logo
