nized into three basic phases, a parser, a
>> > semantic analyzer, and an expander. In the sources, these are
>> represented
>> > by source files par-ch*.adb, sem_ch*.{ads,adb}, and exp_ch*.{ads,adb},
>> > where "ch*" is short-hand for the various chapters
es par-ch*.adb, sem_ch*.{ads,adb}, and exp_ch*.{ads,adb},
> > where "ch*" is short-hand for the various chapters of the Ada reference
> > manual. For this project the intent is to augment primarily the "chapter
> > 5" components, given that loop and parallel-d
t; by source files par-ch*.adb, sem_ch*.{ads,adb}, and exp_ch*.{ads,adb},
> where "ch*" is short-hand for the various chapters of the Ada reference
> manual. For this project the intent is to augment primarily the "chapter
> 5" components, given that loop and parallel-do
Thank you! Yes, I realize we need to submit the proposal to the GSoC
program, and I believe we can do so starting today.
Take care,
-Tuck
On Sun, Mar 23, 2025 at 11:28 PM Sam James wrote:
> Tucker Taft via Gcc writes:
>
> > Proposal: Google Summer of Code on GCC A
Tucker Taft via Gcc writes:
> Proposal: Google Summer of Code on GCC Ada Front end
>
>-
>
>Goal : Implement some of the light-weight parallelism features of Ada
>2022 in the GNAT front end
>-
>
>Contributor: Ethan Luis McDonough, PSU '2025 (
&
Proposal: Google Summer of Code on GCC Ada Front end
-
Goal : Implement some of the light-weight parallelism features of Ada
2022 in the GNAT front end
-
Contributor: Ethan Luis McDonough, PSU '2025 (
ethanluismcdono...@gmail.com)
-
Mentors: S. Tucker Taft (Lexi
在 2023/5/23 04:08, Achim Gratz 写道:
I've backported the patch _and_ defined both WIN32_LEAN_AND_MEAN and
COM_NO_WINDOWS_H (of which I find no reference anywhere in the sources,
so it's probably doing something in the Windows headers?) and the build
has been working through stage 3.
That look lik
gnu.org/bugzilla/show_bug.cgi?id=108300.
Apparently yes. Thanks for pointing that out.
> It's because GCC defines `abort` as a macro; and the Windows header
> 'msxml.h', which is included indirectly by 'accctrl.h' (within Ada and
> GCC JIT), has a member function with
nes `abort` as a macro; and the Windows header 'msxml.h', which is included
indirectly by 'accctrl.h' (within Ada and GCC JIT), has a member function with that same name.
Previously, mingw-w64 had a distinct 'msxml.h' which did `push_macro` and `pop_macro`, but it&
I've recently recovered Ada into gcc-11.3 on Cygwin and am now trying to
update the whole compiler suite to 12.3. The build runs into a problem
in stage 2:
--8<---cut here---start->8---
make[3]: Entering directory '/mnt/share/cygpkgs/gcc/gcc.
Hi Paul,
> On 26 Nov 2022, at 18:06, Paul Koning via Gcc wrote:
>
>> On Nov 26, 2022, at 11:42 AM, Arnaud Charlet via Gcc wrote:
>>
>>>> The current statement (https://gcc.gnu.org/install/prerequisites.html) is:
>>>>
>>>> GNAT
>
> On 26 Nov 2022, at 18:06, Paul Koning wrote:
>
>
>
>> On Nov 26, 2022, at 11:42 AM, Arnaud Charlet via Gcc wrote:
>>
>>
>>>> The current statement (https://gcc.gnu.org/install/prerequisites.html) is:
>>>>
>>>> GNAT
> On Nov 26, 2022, at 11:42 AM, Arnaud Charlet via Gcc wrote:
>
>
>>> 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
>&g
> On Nov 26, 2022, at 11:52 AM, Iain Sandoe wrote:
>
>
>
>> On 26 Nov 2022, at 16:42, Arnaud Charlet wrote:
>>
>>
>>>> The current statement (https://gcc.gnu.org/install/prerequisites.html) is:
>>>>
>>>> GNAT
>
> On 26 Nov 2022, at 16:42, Arnaud Charlet wrote:
>
>
>>> 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
>>>
>> 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 P
nt
>> sources.
>>
>> I wonder if this incompatibility was intentional. If not it would be good
>> for the Ada maintainers to fix these and ensure that the current code can
>> still be built with the most recent public release of Gnat. Conversely, if
>> it
gt;>>
>>>>> On Nov 25, 2022, at 3:03 PM, Andrew Pinski wrote:
>>>>>
>>>>> On Fri, Nov 25, 2022 at 11:59 AM Paul Koning via Gcc
>>>>> wrote:
>>>>>>
>>>>>> I'm trying to use fairly recent GCC
wrote:
>>>>
>>>> On Fri, Nov 25, 2022 at 11:59 AM Paul Koning via Gcc
>>>> wrote:
>>>>>
>>>>> I'm trying to use fairly recent GCC sources (the gcc-darwin branch to be
>>>>> precise) to build Ada, starting with
>> wrote:
>>>>
>>>> I'm trying to use fairly recent GCC sources (the gcc-darwin branch to be
>>>> precise) to build Ada, starting with the latest (2020) release of Gnat
>>>> from Adacore.
>>>
>>> Are you building a cross
On Nov 25, 2022, Paul Koning via Gcc wrote:
> They don't seem to have anything to do with missing compilers, but
> rather with the use of language features too new for the available
> (downloadable) Gnat.
The gnat1 front-end requires some of the Ada runtime (libgnat)
components.
On Fri, Nov 25, 2022 at 3:09 PM Paul Koning via Gcc wrote:
> But in any case, how does that relate to the error messages I got? They
> don't seem to have anything to do with missing compilers, but rather with the
> use of language features too new for the available (downloadable) Gnat.
General
gcc-darwin branch to be
>>> precise) to build Ada, starting with the latest (2020) release of Gnat from
>>> Adacore.
>>
>> Are you building a cross compiler or a native compiler?
>> If you are building a cross, you need to bootstrap a native compiler first.
On Fri, Nov 25, 2022 at 12:08 PM Paul Koning wrote:
>
>
>
> > On Nov 25, 2022, at 3:03 PM, Andrew Pinski wrote:
> >
> > On Fri, Nov 25, 2022 at 11:59 AM Paul Koning via Gcc
> > wrote:
> >>
> >> I'm trying to use fairly recent GCC sources
> On Nov 25, 2022, at 3:03 PM, Andrew Pinski wrote:
>
> On Fri, Nov 25, 2022 at 11:59 AM Paul Koning via Gcc wrote:
>>
>> I'm trying to use fairly recent GCC sources (the gcc-darwin branch to be
>> precise) to build Ada, starting with the latest (2020)
On Fri, Nov 25, 2022 at 11:59 AM Paul Koning via Gcc wrote:
>
> I'm trying to use fairly recent GCC sources (the gcc-darwin branch to be
> precise) to build Ada, starting with the latest (2020) release of Gnat from
> Adacore.
Are you building a cross compiler or a native com
I'm trying to use fairly recent GCC sources (the gcc-darwin branch to be
precise) to build Ada, starting with the latest (2020) release of Gnat from
Adacore.
It fails for several reasons. One is that two source files use [ ] for array
initializer brackets when ( ) is apparently supposed
Hello David,
> I am pleased to announce that the GCC Steering Committee has appointed
> Marc Poulhies as Ada co-maintainer.
Thank you :)
> Marc, please update your listing in the MAINTAINERS file.
I've updated the MAINTAINERS file accordingly in
f4ed610d02aaf8cfcdcb5cf03e0cde65f
Congratulations Marc!
Very happy for you. You deserve all the best.
Félicitations :)
--
Arthur
On Mon, Jul 18, 2022, 19:35 David Edelsohn via Gcc wrote:
> I am pleased to announce that the GCC Steering Committee has appointed
> Marc Poulhies as Ada co-maintainer.
>
> Pleas
I am pleased to announce that the GCC Steering Committee has appointed
Marc Poulhies as Ada co-maintainer.
Please join me in congratulating Marc on his new role.
Marc, please update your listing in the MAINTAINERS file.
Happy hacking!
David
On Tue, May 18, 2021 at 11:41 AM Eric Botcazou wrote:
>
> > I noticed while debugging why my "A?CST1:CST0" patch was broken for
> > Ada, I noticed the following ranges for boolean types:
> > # RANGE [0, 1] NONZERO 1
> > _14 = checks__saved_checks_tos.482_
> I noticed while debugging why my "A?CST1:CST0" patch was broken for
> Ada, I noticed the following ranges for boolean types:
> # RANGE [0, 1] NONZERO 1
> _14 = checks__saved_checks_tos.482_2 > 0;
> # RANGE [0, 255] NONZERO 1
> _18 = _14 == 0;
> _19 = ~
On Tue, May 18, 2021 at 4:51 AM Andrew Pinski via Gcc wrote:
>
> On Mon, May 17, 2021 at 6:52 PM Andrew Pinski wrote:
> >
> > I noticed while debugging why my "A?CST1:CST0" patch was broken for
> > Ada, I noticed the following ranges for boolean types:
> &
On Mon, May 17, 2021 at 6:52 PM Andrew Pinski wrote:
>
> I noticed while debugging why my "A?CST1:CST0" patch was broken for
> Ada, I noticed the following ranges for boolean types:
> # RANGE [0, 1] NONZERO 1
> _14 = checks__saved_checks_tos.482_2 > 0;
> # R
I noticed while debugging why my "A?CST1:CST0" patch was broken for
Ada, I noticed the following ranges for boolean types:
# RANGE [0, 1] NONZERO 1
_14 = checks__saved_checks_tos.482_2 > 0;
# RANGE [0, 255] NONZERO 1
_18 = _14 == 0;
_19 = ~_18;
# RANGE [0, 1] NONZERO
tin Sebor wrote:
Could someone either point me to directions or explain how to
start the Ada front end in GDB? I've searched the GCC Wiki
but couldn't find anything useful and no matter what I do I get
errors, either:
fatal error, run-time library not installed correctly
cannot locate fi
Could someone either point me to directions or explain how to
start the Ada front end in GDB? I've searched the GCC Wiki
but couldn't find anything useful and no matter what I do I get
errors, either:
fatal error, run-time library not installed correctly
cannot locate file
> I see check-gnat in some of the makefile input files but I do not see it
> in the ones that are built. Is there something needed to specify when
> configure is run to get it included?
No, this works with some generic magic like for gcc; g++, gfortran and so on.
--
Eric Botcazou
On 7/31/20 7:57 AM, Eric Botcazou wrote:
Is there a way to run a single ada test? The documentation mentions hows to
"run a subset of the tests by specifying which chapter to run" but not
individual tests. I tried this (and some variations)
make -k check-ada RUNTESTFLAGS=gnat.e
> Is there a way to run a single ada test? The documentation mentions hows to
> "run a subset of the tests by specifying which chapter to run" but not
> individual tests. I tried this (and some variations)
>
> make -k check-ada RUNTESTFLAGS=gnat.exp=gnat.dg/opt86a.ad
On 7/28/20 2:57 PM, Andreas Schwab wrote:
On Jul 28 2020, William Seurer wrote:
There does not appear to be a check-gnat in any of the makefiles.
See LANG_MAKEFRAGS.
I see some stuff about that (and check-gnat, too) in some of the
makefile input files but it doesn't seem to do anything when
On Jul 28 2020, William Seurer wrote:
> There does not appear to be a check-gnat in any of the makefiles.
See LANG_MAKEFRAGS.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
On 7/28/20 12:04 PM, Andreas Schwab wrote:
On Jul 28 2020, William Seurer wrote:
Thanks. That did run the specific test I wanted BUT also ran thousands
more.
The acats testsuite doesn't respect RUNTESTFLAGS (it doesn't use the
dejagnu framework). If you only want to run the gnat testsuite, u
On Jul 28 2020, William Seurer wrote:
> Thanks. That did run the specific test I wanted BUT also ran thousands
> more.
The acats testsuite doesn't respect RUNTESTFLAGS (it doesn't use the
dejagnu framework). If you only want to run the gnat testsuite, use
check-gnat.
Andreas.
--
Andreas Schw
William Seurer via Gcc writes:
> On 7/28/20 9:48 AM, Andreas Schwab wrote:
>> On Jul 28 2020, William Seurer via Gcc wrote:
>>
>>> make -k check-ada RUNTESTFLAGS=gnat.exp=gnat.dg/opt86a.adb
>> gnat.exp isn't a testsuite driver, it's a lib file. You wan
On 7/28/20 9:48 AM, Andreas Schwab wrote:
On Jul 28 2020, William Seurer via Gcc wrote:
make -k check-ada RUNTESTFLAGS=gnat.exp=gnat.dg/opt86a.adb
gnat.exp isn't a testsuite driver, it's a lib file. You want to use
dg.exp instead.
Thanks. That did run the specific test I wante
On Jul 28 2020, William Seurer via Gcc wrote:
> make -k check-ada RUNTESTFLAGS=gnat.exp=gnat.dg/opt86a.adb
gnat.exp isn't a testsuite driver, it's a lib file. You want to use
dg.exp instead.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D
Is there a way to run a single ada test? The documentation mentions hows to
"run a subset of the tests by specifying which chapter to run" but not
individual tests. I tried this (and some variations)
make -k check-ada RUNTESTFLAGS=gnat.exp=gnat.dg/opt86a.adb
but it ran a whole bunc
building Ada?
With long path names the build failed (path includes full Git hashes).
Then I move the source and build roots to a shorter path, then build
was successful using the same configure options.
I reduced the path lengths via short Git hashes. I was able to build GCC
597c6d15f88
for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
This would suggest that bldtools/oscons/xoscons is miscompiled by the trunk
native compiler. How did you configure this latter compiler?
Are there some build/source path limits involved while building Ada?
With long path names the build
> I can build the trunk with a native
>
> gnat --version
> GNAT 8.2.1 20190103 [gcc-8-branch revision 267549]
> Copyright (C) 1996-2018, Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.
> There is NO warranty; not even for MERCHANTABILITY or FITNESS FO
On 17/01/2019 09:56, Sebastian Huber wrote:
Hello,
I tried to build the arm-rtems target with Ada support on the trunk
yesterday. It fails with:
/home/user/rtems-source-builder/rtems/build/arm-rtems6-gcc-0ca47588bd2e38bbfa427503968e08a6b8ab3166-newlib-068182e26c7b397df579b69a18f745092844d1b4
Hello,
I tried to build the arm-rtems target with Ada support on the trunk
yesterday. It fails with:
/home/user/rtems-source-builder/rtems/build/arm-rtems6-gcc-0ca47588bd2e38bbfa427503968e08a6b8ab3166-newlib-068182e26c7b397df579b69a18f745092844d1b4-x86
_64-linux-gnu-1/build/./gcc/xgcc
-B
PR for the first
one? It seems a regression however. I am not familiar with Ada so I am
looking forward to your help. Thanks.
[1]
https://github.com/Alexpux/MINGW-packages/pull/3877#issuecomment-408651809
[2]
https://github.com/Alexpux/MINGW-packages/pull/3877#issuecomment-408667559
--
Best
Hi Simon,
> On 5 Jul 2018, at 20:08, Richard Biener wrote:
>>
>> On July 5, 2018 6:37:58 PM GMT+02:00, Martin Sebor wrote:
>>> Ada tests don't seem to respond to the INT signal: when
>>> I interrupt a parallel make check while the Ada tests are
>>>
On 5 Jul 2018, at 20:08, Richard Biener wrote:
>
> On July 5, 2018 6:37:58 PM GMT+02:00, Martin Sebor wrote:
>> Ada tests don't seem to respond to the INT signal: when
>> I interrupt a parallel make check while the Ada tests are
>> running, other test suites a
On July 5, 2018 6:37:58 PM GMT+02:00, Martin Sebor wrote:
>Ada tests don't seem to respond to the INT signal: when
>I interrupt a parallel make check while the Ada tests are
>running, other test suites are interrupted as well and go
>away, but ada tests keep running. Is there so
Ada tests don't seem to respond to the INT signal: when
I interrupt a parallel make check while the Ada tests are
running, other test suites are interrupted as well and go
away, but ada tests keep running. Is there some trick to
have Ctrl-C have the expected effect on the Ada test suite
as
On 03/07/18 09:10, Eric Botcazou wrote:
It seems the a-except.adb was replaced by a-except-2005.adb in this commit:
Right, it's by design, the old support for SJLJ exceptions has been ditched
for full runtimes. You probably just need to swap the values of
Frontend_Exceptions : const
> It seems the a-except.adb was replaced by a-except-2005.adb in this commit:
Right, it's by design, the old support for SJLJ exceptions has been ditched
for full runtimes. You probably just need to swap the values of
Frontend_Exceptions : constant Boolean := True;
ZCX_By_Default
On 02/07/18 22:03, Eric Botcazou wrote:
I cannot find it in the GCC sources:
grep -ri raise_nodefer_with_msg
gcc/ada/gcc-interface/trans.c: (get_identifier
("__gnat_raise_nodefer_with_msg"), NULL_TREE, ftype,
Who is supposed to provide an implementation of
__gnat_raise_nodefe
> I cannot find it in the GCC sources:
>
> grep -ri raise_nodefer_with_msg
> gcc/ada/gcc-interface/trans.c: (get_identifier
> ("__gnat_raise_nodefer_with_msg"), NULL_TREE, ftype,
>
> Who is supposed to provide an implementation of
> __gnat_raise_nodefe
Hello,
I get the following link-time error while building an Ada test program
on RISC-V and RTEMS:
riscv64-rtems5-gnatlink hello.ali -march=rv64imafd -mabi=lp64d
-mcmodel=medany -O2 -g -ffunction-sections -fdata-sections -Wall
-Wmissing-prototypes -Wimplicit-function-declaration -Wstrict
> Hmm there would be a huge amount of code to check.
Compare the *build* with a known working version, not the code.
> BTW it is quite strange that both stage2 and stage3 didn't fail and the
> comparison was successful.
It's not the compiler build, it's the gnattools build (gnatdll to be precise
knowledge
about Ada stuff I need some information about how it is built and how it
is invoked.
BTW it is quite strange that both stage2 and stage3 didn't fail and the
comparison was successful.
--
Best regards,
LH_Mouse
> Any ideas about how to resolve this?
Compare with a known working version (e.g. GCC 7) and find the discrepancy.
--
Eric Botcazou
Dear developers,
(This issue is originally reported at
<https://github.com/Alexpux/MINGW-packages/pull/3877#issuecomment-393931161>.)
On mingw-w64, bootstrapping GCC 8 with Ada enabled results in the
following error after stage 3:
```
GNATLINK 8.1.1 20180602
Copyright (C) 1995-2018
On 04/01/18 16:03, Andreas Schwab wrote:
On Jan 04 2018, Sebastian Huber wrote:
/home/sh/src/gcc/gcc/config/nios2/nios2.h:436:31: error: expected '=',
',', ';', 'asm' or '__attribute__' before 'nios2_section_threshold'
extern unsigned HOST_WIDE_INT nios2_section_threshold;
Change the prepro
On Jan 04 2018, Sebastian Huber wrote:
> /home/sh/src/gcc/gcc/config/nios2/nios2.h:436:31: error: expected '=',
> ',', ';', 'asm' or '__attribute__' before 'nios2_section_threshold'
> extern unsigned HOST_WIDE_INT nios2_section_threshold;
Change the preprocessor conditional to check USED_FOR_TA
> This HOST_WIDE_INT is defined in gcc/hwint.h. Who is supposed to include
> this file? Is this done via an #include or via a tm_file (gcc/config.gcc)?
Nobody I'd say, the declaration shouldn't be compiled for the target.
--
Eric Botcazou
Hello,
I tried to build an Ada compiler for nios2-rtems5 and ended up with this:
/run/user/10351/b-gcc-nios2/./gcc/xgcc
-B/run/user/10351/b-gcc-nios2/./gcc/ -nostdinc
-B/run/user/10351/b-gcc-nios2/nios2-rtems5/newlib/ -isystem
/run/user/10351/b-gcc-nios2/nios2-rtems5/newlib/targ-include
t for me to understand how this works on
64-bit PowerPC. This was no problem up to now since nobody used long
double with RTEMS on this target. I tried to build a GCC with Ada
support today for the powerpc-rtems5 target. It ends up in infinite
loops while building the Ada run-time multilib for a 6
works on
> 64-bit PowerPC. This was no problem up to now since nobody used long
> double with RTEMS on this target. I tried to build a GCC with Ada
> support today for the powerpc-rtems5 target. It ends up in infinite
> loops while building the Ada run-time multilib for a 64-bit Pow
long
double with RTEMS on this target. I tried to build a GCC with Ada
support today for the powerpc-rtems5 target. It ends up in infinite
loops while building the Ada run-time multilib for a 64-bit PowerPC
variant (similar a-coteio.ads):
gdb --args /build/git-build/b-gcc-git-powerpc-rtems5/
On 10/11/2017 10:43 PM, Martin Sebor wrote:
Hi Vladimir,
On a hunch I backed out r253656. That let the Ada and Go bootstrap
complete. It looks like your fix for bug 82353 is triggering this
ICE.
Martin, thank you for informing me. I used the default bootstrap.
I've reverted LRA ch
Hi Vladimir,
On a hunch I backed out r253656. That let the Ada and Go bootstrap
complete. It looks like your fix for bug 82353 is triggering this
ICE.
Martin
On 10/11/2017 06:45 PM, Martin Sebor wrote:
I've been running into the following errors during the bootstrap
of the top of tru
_REGION (const_int 1 [0x1])
(nil))
during RTL pass: reload
and in Ada:
s-stposu.adb:343:8: error: unable to find a register to spill
s-stposu.adb:343:8: error: this is the insn:
(insn 187 591 592 34 (parallel [
(set (reg:SI 185 [156])
(div:SI (reg:SI 185 [156])
On 09/15/2017 07:22 PM, David Edelsohn wrote:
I am pleased to announce that the GCC Steering Committee has
appointed Pierre-Marie de Rodat as Ada co-maintainer.
Please join me in congratulating Pierre-Marie on his new role.
P-M, please update your listing in the MAINTAINERS file
I am pleased to announce that the GCC Steering Committee has
appointed Pierre-Marie de Rodat as Ada co-maintainer.
Please join me in congratulating Pierre-Marie on his new role.
P-M, please update your listing in the MAINTAINERS file.
Happy hacking!
David
On 7 Jul 2017, at 22:31, Martin Sebor wrote:
>
> I see large numbers of timeouts in Ada tests on trunk in parallel
> run s (make -j96) on x86_64. Messages like the one below appear
> in the logs, suggesting some sort of heap corruption. I'm having
> trouble reproducing it
On 7/7/2017 17:38, Eric Botcazou wrote:
I see large numbers of timeouts in Ada tests on trunk in parallel
run s (make -j96) on x86_64. Messages like the one below appear
in the logs, suggesting some sort of heap corruption. I'm having
trouble reproducing it outside the rest of the test
> I see large numbers of timeouts in Ada tests on trunk in parallel
> run s (make -j96) on x86_64. Messages like the one below appear
> in the logs, suggesting some sort of heap corruption. I'm having
> trouble reproducing it outside the rest of the test suite (i.e.,
> by
I see large numbers of timeouts in Ada tests on trunk in parallel
run s (make -j96) on x86_64. Messages like the one below appear
in the logs, suggesting some sort of heap corruption. I'm having
trouble reproducing it outside the rest of the test suite (i.e.,
by just running the Ada tes
On 05/15/2017 10:01 PM, David Edelsohn wrote:
Your understanding is correct. GCC never accepts patches for a
specific version / release -- even if it is the current release.
Patches for new features or support must be contributed to the current
development version.
Can't the patches be put on
7;s just survival
kit. I don't know how all others Gnat Pro VMS users will survive, but
I'm opened on any negociation with Adacore to help them, if Adacore
helps transfering revenue of their support to help making my survival
kits survive.
I unsderstand Adacore could think about
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
way
of further enhancements and clean ups for other platforms.
That's why we completely removed all support for Ada in our current toolset
as well as in the FSF GCC a few years ago, to stop having the burden to
maintain this complex part of the technology.
We welcomed AdaLabs initiative
gt;>> Dear GCC Steering Committee,
>>>>
>>>> I am David, founder of AdaLabs Ltd, a software engineering startup
>>>> having expertise in Ada programming language technologies. As a summary,
>>>> we would like to know if gcc has interest in an assignment
daLabs Ltd, a software engineering startup
>>> having expertise in Ada programming language technologies. As a summary,
>>> we would like to know if gcc has interest in an assignment of copyright
>>> to FSF from our work. We are not used to this process, and are kindly
>
On 04/28/2017 06:47 PM, David Edelsohn wrote:
> On Thu, Apr 27, 2017 at 10:55 AM, David SAUVAGE - AdaLabs Ltd
> wrote:
>> Dear GCC Steering Committee,
>>
>> I am David, founder of AdaLabs Ltd, a software engineering startup
>> having expertise in Ada programmi
On Thu, Apr 27, 2017 at 10:55 AM, David SAUVAGE - AdaLabs Ltd
wrote:
>
> Dear GCC Steering Committee,
>
> I am David, founder of AdaLabs Ltd, a software engineering startup
> having expertise in Ada programming language technologies. As a summary,
> we would like to know if gcc
Dear GCC Steering Committee,
I am David, founder of AdaLabs Ltd, a software engineering startup
having expertise in Ada programming language technologies. As a summary,
we would like to know if gcc has interest in an assignment of copyright
to FSF from our work. We are not used to this process
On 05/03/2016 04:44 PM, Eric Botcazou wrote:
There is no /build/gcc-trunk/gcc/gcc but presumably you meant
/build/gcc-trunk/gcc/ada (which does exist). But there is no
rts directory anywhere under the build tree.
Then the build failed at some point and this should be in the log.
Actually, I
> There is no /build/gcc-trunk/gcc/gcc but presumably you meant
> /build/gcc-trunk/gcc/ada (which does exist). But there is no
> rts directory anywhere under the build tree.
Then the build failed at some point and this should be in the log.
--
Eric Botcazou
On 05/03/2016 03:47 PM, Eric Botcazou wrote:
In my builds lately I've been noticing many Ada tests failing
that didn't use to fail before. I don't think I'm doing
anything different than before. The failures all seem to be
due to the error below. Has something changed abou
> In my builds lately I've been noticing many Ada tests failing
> that didn't use to fail before. I don't think I'm doing
> anything different than before. The failures all seem to be
> due to the error below. Has something changed about how to
> run the Ada
In my builds lately I've been noticing many Ada tests failing
that didn't use to fail before. I don't think I'm doing
anything different than before. The failures all seem to be
due to the error below. Has something changed about how to
run the Ada test suite or how to con
w (but most FEs use sizetype or
> ssizetype).
Using ssizetype in Ada would already be a net progress, I'll investigate.
> ISTR also doing some Ada adjustments but they may have been dumped for
> "interesting" changes to stor-layout.c instead:
>
>
On Wed, Oct 14, 2015 at 5:57 PM, Eric Botcazou wrote:
>> I'm having fun with arrays in Ada ;) and wondering if anyone can tell me
>> what's right here.
>
> No surprise, arrays are probably the base types for which there is the largest
> gap between Ada and the C fam
> I'm having fun with arrays in Ada ;) and wondering if anyone can tell me
> what's right here.
No surprise, arrays are probably the base types for which there is the largest
gap between Ada and the C family of languages, for which GCC was written.
You can see in the E_Array
1 - 100 of 1092 matches
Mail list logo
