"Dave Korn" <[EMAIL PROTECTED]> writes:
> It's pretty obvious the moment you read the content of any of the posts
> that it can't be cvs and has to be svn, even more so if you follow one of
> the viewvc links... but it couldn't hurt to make it explicit, I'm sure.
FWIW, the links still use the v
Patches welcome :)
On Tue, Jul 22, 2008 at 3:55 AM, Andreas Schwab <[EMAIL PROTECTED]> wrote:
> "Dave Korn" <[EMAIL PROTECTED]> writes:
>
>> It's pretty obvious the moment you read the content of any of the posts
>> that it can't be cvs and has to be svn, even more so if you follow one of
>> the
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 := 64;
- Mem
Paolo Bonzini <[EMAIL PROTECTED]>:
> I'm not sure how much churn is there in gcc/ada/Makefile.in. If there
> is little, it probably makes more sense to work on a branch. If there
> is much, it probably makes more sense to commit the partially working
> patch. Again, I'll defer to AdaCore people
>> 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
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 attribute.
- Word_Size: co
Selon Arnaud Charlet <[EMAIL PROTECTED]>:
> >> 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
> 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
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
blocking issue with the proposed design since each MULTILIB rt
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
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 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 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
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
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
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
> 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
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
>> 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 again
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
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]
Le-Chun Wu wrote:
Hi,
I haven't heard anything back on my questions. Can any of C++ frontend
maintainers please shed some light (or comment on my proposed patch)?
Thanks a lot.
Le-chun
On Fri, Jul 18, 2008 at 10:22 AM, Le-Chun Wu <[EMAIL PROTECTED]> wrote:
Hi,
In my attribute handlers that h
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
The branch has regressed in terms of memory and compile time.
However, I think the regressions are localized.
I compiled tuples and [EMAIL PROTECTED] with --disable-checking
--enable-gather-detailed-mem-stats. I ran cc1 and cc1plus over the
preprocessed code of cc1-i-files, FF3D, SPEC2000, TRAMP3
Benjamin,
Thanks for looking into this issue. I see what's going on here. It's
basically a phase ordering problem. I am trying to determine whether a
declaration is a class member when attributes are parsed and handled
(in c-common.c), which happens earlier than where the context of a
data member
Le-Chun Wu wrote:
Benjamin,
Thanks for looking into this issue. I see what's going on here. It's
basically a phase ordering problem. I am trying to determine whether a
declaration is a class member when attributes are parsed and handled
(in c-common.c), which happens earlier than where the conte
I noticed today that:
gcc -c -o hw.o hw.c
removes hw.o if failure occurs during the compilation, but:
gcc -c -ohw.o hw.c
does not.
The reason turns out to be that, in the latter case, we record the name
"-ohw.o" as a temporary file, rather than "hw.o". Our confusion comes
from the hand
On Tue, Jul 22, 2008 at 4:53 PM, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> I noticed today that:
>
> gcc -c -o hw.o hw.c
>
> removes hw.o if failure occurs during the compilation, but:
>
> gcc -c -ohw.o hw.c
>
> does not.
>
> The reason turns out to be that, in the latter case, we record the nam
On Tue, Jul 22, 2008 at 04:53:19PM -0700, Mark Mitchell wrote:
> I noticed today that:
>
> gcc -c -o hw.o hw.c
>
> removes hw.o if failure occurs during the compilation, but:
>
> gcc -c -ohw.o hw.c
>
> does not.
Hmm. About 20 years of gcc use, and this is the first time I
learned that the
This looks like interesting work, and I hope something like this gets
folded into a release soon. A few things occurred to me when reading
the writeup at google (sorry, I haven't started looking through the
code much yet):
All the examples seem to be C++ oriented; is it, in fact, a goal fo
31 matches
Mail list logo
