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
Hello,
Actually, this port is a survival initiative. I was part of a VMS port
from Alpha to Itanium, which was finally launched... the month Adacore
decided to stop its support.
I had long negociations with Quentin Ochem in France, hoping to get the
Adacore compiler even without support, and
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
On Mon, May 15, 2017 at 12:54 PM, David SAUVAGE - AdaLabs Ltd
wrote:
> On 04/29/2017 06:31 PM, David SAUVAGE - AdaLabs Ltd wrote:
>> 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,
>>
On 04/29/2017 06:31 PM, David SAUVAGE - AdaLabs Ltd wrote:
> 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
>>> havi
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 programming language technologies. As a summary
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 has interest in an
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 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 configure GCC to
> Doesn't common.opt serve this purpose? But if I understand you
> correctly, the Ada front end alters semantics of flags in common.opt,
> which means we are in a bit of a difficult position here.
No, I meant splitting cc1_options into a base_options and cc1_options and
adding base_options only
On 04/01/2015 12:02 PM, Eric Botcazou wrote:
>> All the other in-tree front ends use it, including Java, Fortran, and Go.
>
> Out of laziness I'd say. ;-) AFAIK the Ada FE never did it.
Would it make sense to add “%(gnat1_options)”, so that Fedora can use it
specs-file-based injection for Ada pr
> All the other in-tree front ends use it, including Java, Fortran, and Go.
Out of laziness I'd say. ;-) AFAIK the Ada FE never did it.
> Would it be possible to add some other injection mechanism so that it is
> possible customize the gnat1 flags using the specs file mechanism?
Yes, defining a
On 04/01/2015 11:38 AM, Arnaud Charlet wrote:
> Well cc1_options are relevant to C (C family?) language(s), and not
> necessarily
> for Ada.
All the other in-tree front ends use it, including Java, Fortran, and Go.
> In other words, not all C or C++ switches are relevant or recognized
> by gnat
> Can we just add “%(cc1_options)”, or is there a reason why it is missing?
It is not missing, reusing cc1_options is simply problematic because different
FEs can have different needs. In particular, in Ada we need to echo the order
of -g* and -m* switches (the "%{g*&m*}" thing) and cc1_options
> {"@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.
> 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
BELBACHIR Selim writes:
> Hi,
>
> I'm working on a gcc/gnat port for a private target (gcc 4.5.2, gnat 6.4.2).
> On this target, scalar values shall be stored in $R registers whereas
> pointer values shall be stored in $C registers. My current ABI for
> procedure/function calls uses $R an
On Tue, Oct 30, 2012 at 2:04 PM, Eric Botcazou wrote:
>> 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 that would explain this
>> change in behavior?
> 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 that would explain this
> change in behavior?
No changes as far as I know, but maybe Diego got a brand n
On Tue, Oct 30, 2012 at 12:45 PM, Arnaud Charlet wrote:
> Diego, can you confirm that it's indeed seh_init.o which is failing?
Yes. The error was given on seh_init.c:48
Thanks. Diego.
> 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
> I'll have a look.
I cannot reproduce, but this might come from missing dependencies in Make-
lang.in for the affected files.
--
Eric Botcazou
On Tue, Oct 30, 2012 at 11:44 AM, Arnaud Charlet wrote:
> I'll have a look.
Thanks!
> 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
On Thu, 14 Jul 2011, Eric Botcazou wrote:
> > and from looking at SET_TYPE_RM_VALUEs definition it doesn't
> > touch TYPE_MAX_VALUE. So TYPE_MAX_VALUE is as set from
> > make_unsigned_type (8) which should set it to 255, not 1.
> >
> > So ... how can it be a no-op?
>
> Look a few lines below. :-
> and from looking at SET_TYPE_RM_VALUEs definition it doesn't
> touch TYPE_MAX_VALUE. So TYPE_MAX_VALUE is as set from
> make_unsigned_type (8) which should set it to 255, not 1.
>
> So ... how can it be a no-op?
Look a few lines below. :-) In gigi we manipulate both full-fledged Ada types
wit
On Thu, 14 Jul 2011, Eric Botcazou wrote:
> > I'm wondering why for Ada boolean_true_node has a value that is
> > not in the range of the Ada type but is, for the specific case,
> > 255 instead of 1. Is there a specific reason for that?
>
> None, boolean_true_node must be 1, that's why we (re)se
> I'm wondering why for Ada boolean_true_node has a value that is
> not in the range of the Ada type but is, for the specific case,
> 255 instead of 1. Is there a specific reason for that?
None, boolean_true_node must be 1, that's why we (re)set it in gnat_init.
> Does the following patch make s
On Wed, May 26, 2010 at 6:08 PM, Eric Botcazou wrote:
>> You could "fix" this by walking all functions and check if only
>> one real language personality routine remains and promote
>> the generic C personality uses to that. Of course you need then
>> to be able to identify the C personality whic
> You could "fix" this by walking all functions and check if only
> one real language personality routine remains and promote
> the generic C personality uses to that. Of course you need then
> to be able to identify the C personality which you can't (well,
> you could by name).
Can't we simply r
On Wed, May 26, 2010 at 5:38 PM, Eric Botcazou wrote:
>> When I run the test suite with Ada, I have two test suite failures,
>> for lto6.adb and lto8.adb. The failure mode is the same for both, see
>> end of this mail. Are these failures expected?
>
> That's an LTO bug: it can change the personali
> When I run the test suite with Ada, I have two test suite failures,
> for lto6.adb and lto8.adb. The failure mode is the same for both, see
> end of this mail. Are these failures expected?
That's an LTO bug: it can change the personality routine without any real
reasons. You don't need several
Steven Bosscher writes:
> Hi,
>
> When I run the test suite with Ada, I have two test suite failures,
> for lto6.adb and lto8.adb. The failure mode is the same for both, see
> end of this mail. Are these failures expected? This is on Debian Lenny
> x86_64.
See PR middle-end/44230 and this thread
> > 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
Joel Sherrill writes:
> In checking my local changes, I noticed a minor
> difference in how the Ada source files have their
> Copyright notice. Some have a comma between the
> years and party, others do not.
>
> 9drpc.adb:-- Copyright (C) 1992-2009, Free Software
> Foundation, Inc.
On Tue, 22 Sep 2009, Joel Sherrill wrote:
> It appears to be unsigned char or at least sizeof(bool)=1
> on the architectures I tried this test program on.
The size is determined by BOOL_TYPE_SIZE (and is not 1 byte for
powerpc-darwin).
--
Joseph S. Myers
jos...@codesourcery.com
* Joel Sherrill:
>> Whatever the answer is, it should be used to define Interfaces.C.Bool.
>> (I don't know what GCC's options for representing _Bool are, sorry.)
> It appears to be unsigned char or at least sizeof(bool)=1
> on the architectures I tried this test program on.
That's only half of
On Tue, Sep 22, 2009 at 12:54 PM, Joel Sherrill
wrote:
> Florian Weimer wrote:
>>
>> * Joel Sherrill:
>>
>>
>>>
>>> What is the proper type to use in an Ada binding
>>> for a C method that returns a C99 bool?
>>>
>>
>> Whatever the answer is, it should be used to define Interfaces.C.Bool.
>> (I do
Florian Weimer wrote:
* Joel Sherrill:
What is the proper type to use in an Ada binding
for a C method that returns a C99 bool?
Whatever the answer is, it should be used to define Interfaces.C.Bool.
(I don't know what GCC's options for representing _Bool are, sorry.)
It appears t
* Joel Sherrill:
> What is the proper type to use in an Ada binding
> for a C method that returns a C99 bool?
Whatever the answer is, it should be used to define Interfaces.C.Bool.
(I don't know what GCC's options for representing _Bool are, sorry.)
Richard Guenther wrote:
> On Fri, Sep 4, 2009 at 1:00 AM, Richard Henderson wrote:
>> Can someone tell me how to debug this:
>>
>>> splitting
>>> /home/rth/work/gcc/bld-sjlj/gcc/testsuite/ada/acats0/tests/c3/c35502i.ada
>>> FAIL: c35502i
>> I haven't been able to figure out what command to issue
On 09/04/2009 02:51 AM, Eric Botcazou wrote:
I haven't been able to figure out what command to issue from the command
line to reproduce this. Cut and paste from the dejagnu log doesn't
work, which is more than annoying...
There is a blurb about this on http://gcc.gnu.org/wiki/DebuggingGCC
Th
> I haven't been able to figure out what command to issue from the command
> line to reproduce this. Cut and paste from the dejagnu log doesn't
> work, which is more than annoying...
There is a blurb about this on http://gcc.gnu.org/wiki/DebuggingGCC
--
Eric Botcazou
On Fri, Sep 4, 2009 at 1:00 AM, Richard Henderson wrote:
> Can someone tell me how to debug this:
>
>> splitting
>> /home/rth/work/gcc/bld-sjlj/gcc/testsuite/ada/acats0/tests/c3/c35502i.ada
>> into:
>> c35502i.adb
>> BUILD c35502i.adb
>> gnatmake --GCC="/home/rth/work/gcc/bld-sjlj/gcc/xgcc
>> -B/
>> ./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
If you pass -v to gnatmake, it will output the gcc invocations.
This should be sufficient to find the problem.
Basically, just go to the directory containing c35502i.adb, and
execute the gnatmake command as listed below, with -v added in.
If you only have the 35502i.ada file available, use "gnatc
Richard Henderson wrote:
> Can someone tell me how to debug this:
>
>> splitting
>> /home/rth/work/gcc/bld-sjlj/gcc/testsuite/ada/acats0/tests/c3/c35502i.ada
>> into:
>>c35502i.adb
>> BUILD c35502i.adb
>> gnatmake --GCC="/home/rth/work/gcc/bld-sjlj/gcc/xgcc
>> -B/home/rth/work/gcc/bld-sjlj/gcc
Mikael Pettersson writes:
> Laurent GUERBY writes:
> > On Sat, 2009-08-22 at 23:33 +0200, Laurent GUERBY wrote:
> > > On Mon, 2009-08-17 at 12:00 +0200, Mikael Pettersson wrote:
> > > > On Wed, 12 Aug 2009 23:08:00 +0200, Matthias Klose
> wrote:
> > > > >On 12.08.2009 23:07, Martin Guy
Laurent GUERBY writes:
> On Sat, 2009-08-22 at 23:33 +0200, Laurent GUERBY wrote:
> > On Mon, 2009-08-17 at 12:00 +0200, Mikael Pettersson wrote:
> > > On Wed, 12 Aug 2009 23:08:00 +0200, Matthias Klose
> > > wrote:
> > > >On 12.08.2009 23:07, Martin Guy wrote:
> > > >> On 8/12/09, Joel She
On Sat, 2009-08-22 at 23:33 +0200, Laurent GUERBY wrote:
> On Mon, 2009-08-17 at 12:00 +0200, Mikael Pettersson wrote:
> > On Wed, 12 Aug 2009 23:08:00 +0200, Matthias Klose wrote:
> > >On 12.08.2009 23:07, Martin Guy wrote:
> > >> On 8/12/09, Joel Sherrill wrote:
> > >>> So any ACATS results f
On Mon, 2009-08-17 at 12:00 +0200, Mikael Pettersson wrote:
> On Wed, 12 Aug 2009 23:08:00 +0200, Matthias Klose wrote:
> >On 12.08.2009 23:07, Martin Guy wrote:
> >> On 8/12/09, Joel Sherrill wrote:
> >>> So any ACATS results from any other ARM target would be
> >>> appreciated.
> >>
> >> I
Hi Laurent,
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?
I have already changed the patch under development so that the te
> 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
> I agree--please put in at least the date of the change being reverted,
> which should be the date of the ChangeLog entry.
There is no ChangeLog entry at all. I've replaced the rev by the date.
--
Eric Botcazou
Ben Elliston writes:
> On Sat, 2009-02-28 at 18:31 +0100, Eric Botcazou wrote:
>
>> * gcc-interface/Makefile.in (cygwin/mingw): Revert accidental
>> EH_MECHANISM change in r130816.
>
> I've seen a few ChangeLog entries like this of late, so thought I would
> raise something: is it now a
On Sat, 2009-02-28 at 18:31 +0100, Eric Botcazou wrote:
> * gcc-interface/Makefile.in (cygwin/mingw): Revert accidental
> EH_MECHANISM change in r130816.
I've seen a few ChangeLog entries like this of late, so thought I would
raise something: is it now accepted practice to mention SVN
On Wed, 2009-02-18 at 10:23 +0100, Laurent GUERBY wrote:
> On Wed, 2009-02-18 at 08:56 +0100, Arnaud Charlet wrote:
> > > > 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
> > > > mon
With the two patches I submitted 4.4 produces
100% clean ACATS and gnat.dg results on mipsel-linux:
http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg01730.html
Which is way better than 4.3 :).
Laurent
On Wed, 2009-02-18 at 08:56 +0100, Arnaud Charlet wrote:
> > > OK for stage 1 (GCC 4.5), curre
On Wed, 2009-02-18 at 08:56 +0100, Arnaud Charlet wrote:
> > > 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
> >
> > 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
> 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 on ia64-linu
> 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
Laurent GUERBY wrote:
On Tue, 2009-02-17 at 16:05 -0500, Robert Dewar wrote:
Laurent GUERBY wrote:
Two obvious solutions: use Unsupress locally since there's already a others
handler or add explicit length checks.
analysis looks right, an explicit length check is more appropriate,
better to a
On Tue, 2009-02-17 at 16:05 -0500, Robert Dewar wrote:
> Laurent GUERBY wrote:
>
> > Two obvious solutions: use Unsupress locally since there's already a others
> > handler or add explicit length checks.
>
> analysis looks right, an explicit length check is more appropriate,
> better to avoid the
Laurent GUERBY wrote:
Two obvious solutions: use Unsupress locally since there's already a others
handler or add explicit length checks.
analysis looks right, an explicit length check is more appropriate,
better to avoid the exception.
To reach quickly the interesting point under gdb:
break
On Thu, 2008-08-28 at 16:02 +0200, Richard Guenther wrote:
> On Thu, Aug 28, 2008 at 12:36 PM, Manuel López-Ibáñez
> <[EMAIL PROTECTED]> wrote:
> > Dear all,
> >
> > I get the following errors when running the GNAT testsuite on
> > x86_64-unknown-linux-gnu with make check -j2
> > --target_board=\{-
On Thu, Aug 28, 2008 at 12:36 PM, Manuel López-Ibáñez
<[EMAIL PROTECTED]> wrote:
> Dear all,
>
> I get the following errors when running the GNAT testsuite on
> x86_64-unknown-linux-gnu with make check -j2
> --target_board=\{-m32,-m64\}.
>
> Executing on host: /home/manuel/test/139674M/build/gcc/gn
On Thu, 2008-07-31 at 18:42 +0200, Daniel Kraft wrote:
> With Ada, however, I'm at least not aware of another compiler I could
> bootstrap using my C compiler and use that one subsequentally to
> bootstrap GNAT. At the moment, I'm trying to bootstrap it using a
> binary GNAT 3.15p which was als
> 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
Arnaud Charlet wrote:
For half a year now, I've been working on the GCC Fortran front-end; but
I'm also quite interested in Ada as a language. However, I don't quite
like the idea that one needs a working Ada compiler to bootstrap the Ada
front-end. Well, it's the same with a C compiler to bo
Laurent GUERBY wrote:
Joel did test (a previous iteration of) this patch on many RTEMS
multilibed targets and it worked (RTEMS system.ads already use Standard
attributes to be portable so no issue there).
I thought I would follow up with some details. I tested
on mips, powerpc, x86, and spar
Laurent GUERBY wrote:
On Fri, 2008-07-25 at 10:55 +, Joseph S. Myers wrote:
i686-linux-gnu --enable-targets=all and x86_64-linux-gnu are equivalent,
differing only in whether the default is 32-bit or 64-bit. Do you select
the right files for both multilibs of i686-linux-gnu, as well as for
On Fri, 2008-07-25 at 10:55 +, Joseph S. Myers wrote:
> i686-linux-gnu --enable-targets=all and x86_64-linux-gnu are equivalent,
> differing only in whether the default is 32-bit or 64-bit. Do you select
> the right files for both multilibs of i686-linux-gnu, as well as for both
> multilibs
On Fri, 25 Jul 2008, Laurent GUERBY wrote:
> The attached patch implements Arnaud suggestion of changing the arch
> to select the appropriate source (done and tested for x86_64-linux only
> for now) and doesn't touch anymore system-*.ads.
As a general comment on x86_64 handling, not having checke
On Fri, 2008-07-25 at 09:35 +0200, Arnaud Charlet wrote:
> > I think this will help review and this is useful change on its own,
> > should I test and submit this first part separately?
>
> Yes, although I'd wait for the tuples branch and gcc-interface restructuration
> which will happen end of ju
>>> 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 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).
Does that mean that libgcc is implicitely multilibed if --enable-multilib=
is
Paolo Bonzini <[EMAIL PROTECTED]> writes:
> Arnaud Charlet wrote:
>>> 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-multil
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
Arnaud Charlet wrote:
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.
> 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
On Fri, 2008-07-25 at 09:00 +0200, Arnaud Charlet wrote:
> > 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 ca
> 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
What triggers the passing of -imultilib to a language driver?
It is passed together with -isystem, -iprefix and friends when %I is in
a spec. I'm sure you can define a new spec function and use it to pass
the multilib_dir variable down to the Ada driver (see default_compilers,
I guess you
On Tue, 22 Jul 2008, Laurent GUERBY wrote:
> What triggers the passing of -imultilib to a language driver?
The handling of the %I spec. -imultilib is a preprocessor option used to
get the fixed headers corresponding to a particular multilib.
--
Joseph S. Myers
[EMAIL PROTECTED]
On Tue, 2008-07-22 at 13:41 +0200, Paolo Bonzini wrote:
> > [EMAIL PROTECTED]:~/tmp$ gnatmake -f -g
> > -aO/home/guerby/build-mlib7/gcc/ada/rts32 -m32 p
>
> I guess this fixing this requires duplicating in gnatmake and gnatbind
> the logic in gcc.c that uses the info produced by genmultilib. Se
Arnaud Charlet wrote:
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 again
>> 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
Arnaud Charlet wrote:
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
automatic
> 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
Selon Paolo Bonzini <[EMAIL PROTECTED]>:
>
> > There is a Standard'Default_Bit_Order so it's the same as Word_Size: we
> just
> > loose "source" documentation (and gain less diff between target file).
>
> Yes, but Arnaud said that system-* constants are written down for a
> reason. I don't unders
I think you will end up having to support generating different
source trees for each multilib variant to be safe and correct.
Yes, that comes out naturally if the RTS is built in libada. In fact,
Arnaud said:
The idea currently is to make these values
explicit so that when people read sys
There is a Standard'Default_Bit_Order so it's the same as Word_Size: we just
loose "source" documentation (and gain less diff between target file).
Yes, but Arnaud said that system-* constants are written down for a
reason. I don't understand *what* is the reason, but that's just
because I
Paolo Bonzini wrote:
Arnaud Charlet wrote:
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 attribut
Selon Paolo Bonzini <[EMAIL PROTECTED]>:
>
> > This will need some additionals tests on MULTILIB in the
> LIBGNAT_TARGET_PAIRS
> > machinery (3 files for x86 vs x86_64, solaris looks like already done,
> powerpc
> > seem 32 bits only right now, s390/s390x, others?) but it doesn't seem like
> a
> >
Paolo, do you know where to look for the list of multilibs on a given platform
in the GCC sources? And if we want to disable some of them for Ada?
In the makefile fragments t-*, in places like config/i386/t-linux64
MULTILIB_OPTIONS = m64/m32
MULTILIB_DIRNAMES = 64 32
MULTILIB_OSDIRNAMES = ../
Selon Arnaud Charlet <[EMAIL PROTECTED]>:
> Well, also the issue is that currently the Makefile for building the run-time
> is not prepared to handle all the possible combinations currently supported
> by GCC on some platforms, so things will also break in various places if
> you enable multilibs b
1 - 100 of 443 matches
Mail list logo
