On Mon, Jun 29, 2009 at 5:39 AM, NightStrike wrote:
> On Sat, Jun 27, 2009 at 6:25 PM, Ian Lance Taylor wrote:
>> Richard Guenther writes:
>>
>>> All that above said - do you expect us to carry both vec.h (for VEC in
>>> GC memory) and std::vector (for VECs in heap memory) (and vec.h
>>> for the a
NightStrike wrote:
> On Sat, Jun 27, 2009 at 6:25 PM, Ian Lance Taylor wrote:
>> Richard Guenther writes:
>>
>>> All that above said - do you expect us to carry both vec.h (for VEC in
>>> GC memory) and std::vector (for VECs in heap memory) (and vec.h
>>> for the alloca trick ...)? Or do you thin
On Sat, Jun 27, 2009 at 6:25 PM, Ian Lance Taylor wrote:
> Richard Guenther writes:
>
>> All that above said - do you expect us to carry both vec.h (for VEC in
>> GC memory) and std::vector (for VECs in heap memory) (and vec.h
>> for the alloca trick ...)? Or do you think we should try to make th
Richard Guenther writes:
> All that above said - do you expect us to carry both vec.h (for VEC in
> GC memory) and std::vector (for VECs in heap memory) (and vec.h
> for the alloca trick ...)? Or do you think we should try to make the GTY
> machinery C++ aware and annotate the standard library (
On Sat, Jun 27, 2009 at 11:51, David Edelsohn wrote:
> 2) The Graphite CLooG headers are not C++-clean, so enabling Graphite
> fails in CXX mode.
I did applied the patches from Ian to the cloog-ppl git.
The git version should compile with a C++ compiler.
Sebastian
On Thu, Jun 25, 2009 at 4:32 PM, Ian Lance Taylor wrote:
> I would like to encourage people to try using --enable-build-with-cxx in
> other configuration--other bootstraps, cross-compilers--to see how well
> it works. Please let me know if you run into problems that you don't
> know how, or don't
Ian Lance Taylor writes:
> I would like to encourage people to try using --enable-build-with-cxx in
> other configuration--other bootstraps, cross-compilers--to see how well
> it works. Please let me know if you run into problems that you don't
> know how, or don't have time, to fix.
MIPS bootst
"CC=../../xgcc -B../../" \
+ "LINKER=$(CXX)" \
"CFLAGS=$(CFLAGS) $(WARN_CFLAGS)" \
I think you should rather do
"CC=../../xgcc -B../../" \
+ "CXX=../../g++ -B../../" \
"CFLAGS=$(CFLAGS) $(WARN_CFLAGS)" \
+ "CXXFLAGS=$(CXXFLAGS) $(WARN_CFLAGS)" \
Daniel Berlin wrote:
All that above said - do you expect us to carry both vec.h (for VEC in
GC memory) and std::vector (for VECs in heap memory) (and vec.h
for the alloca trick ...)? Or do you think we should try to make the GTY
machinery C++ aware and annotate the standard library (ick...)?
S
>
> All that above said - do you expect us to carry both vec.h (for VEC in
> GC memory) and std::vector (for VECs in heap memory) (and vec.h
> for the alloca trick ...)? Or do you think we should try to make the GTY
> machinery C++ aware and annotate the standard library (ick...)?
Since the conta
On Sat, 2009-06-27 at 13:51 +0200, Laurent GUERBY wrote:
> On Sat, 2009-06-27 at 13:25 +0200, Eric Botcazou wrote:
> > > This was the only va_arg usage, may be we should apply it on trunk too
> > > as the patched version is supposed to work for both C and C++.
> >
> > Yes, but I'm testing a patch
On Sat, 2009-06-27 at 13:25 +0200, Eric Botcazou wrote:
> > This was the only va_arg usage, may be we should apply it on trunk too
> > as the patched version is supposed to work for both C and C++.
>
> Yes, but I'm testing a patch for trunk with more changes.
For reference here is my current draf
> This was the only va_arg usage, may be we should apply it on trunk too
> as the patched version is supposed to work for both C and C++.
Yes, but I'm testing a patch for trunk with more changes.
--
Eric Botcazou
On Fri, 2009-06-26 at 12:52 -0700, Ian Lance Taylor wrote:
> Arnaud Charlet writes:
>
> >> 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 t
> Interesting. I've been testing my -Wc++-compat patches with full
> bootstraps including Ada, but I just looked at my make log and it does
> indeed appear that -Wc++-compat doesn't make it onto the Ada files.
>
> It seems to be because of this line in ada/gcc-interface/Make-lang.in:
>
> ada-warn
On Sat, Jun 27, 2009 at 2:55 AM, Ian Lance Taylor wrote:
> Matt writes:
>
>>> * Develop some trial patches which require C++, e.g., convert VEC to
>>> std::vector.
>>
>> Do you have any ideas for the easiest starting points? Is there
>> anywhere that is decently self-contained, or will if have to
Matt writes:
>> * Develop some trial patches which require C++, e.g., convert VEC to
>> std::vector.
>
> Do you have any ideas for the easiest starting points? Is there
> anywhere that is decently self-contained, or will if have to be a big
> bang?
Thanks for your interest.
I think the one I m
* Develop some trial patches which require C++, e.g., convert VEC to
std::vector.
Do you have any ideas for the easiest starting points? Is there anywhere
that is decently self-contained, or will if have to be a big bang?
I'd love to see this happen so there's more exercising of template
Arnaud Charlet writes:
>> 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
> 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
On Fri, 2009-06-26 at 14:07 -0400, Robert Dewar wrote:
> Ian Lance Taylor wrote:
>
> > gnatbind -C appears to be used when bootstrapping gcc to generate .c
> > files. With --enable-build-with-cxx, those .c files will be compiled
> > with a C++ compiler. The symbols emitted by that compilation ne
Ian Lance Taylor writes:
> I would like to encourage people to try using --enable-build-with-cxx in
> other configuration--other bootstraps, cross-compilers--to see how well
> it works. Please let me know if you run into problems that you don't
> know how, or don't have time, to fix.
With GMP 4.
Ian Lance Taylor wrote:
gnatbind -C appears to be used when bootstrapping gcc to generate .c
files. With --enable-build-with-cxx, those .c files will be compiled
with a C++ compiler. The symbols emitted by that compilation need to be
linkable with the symbols emitted when compiling Ada code, s
Robert Dewar writes:
> Ian Lance Taylor wrote:
>
>> I think the function to change is Gen_Output_File_C in bindgen.adb.
>
> 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
> 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
Ian Lance Taylor wrote:
I think the function to change is Gen_Output_File_C in bindgen.adb.
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 thi
> 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
Laurent GUERBY writes:
> Next issue is that gnat1 link fails on many missing symbols:
>
> ada/b_gnat1.o: In function `adainit()':
> ada/b_gnat1.c:287: undefined reference to `system__soft_links___elabb()'
> ada/b_gnat1.c:291: undefined reference to
> `system__secondary_stack___elabb()'
>
> a
> > 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
Laurent GUERBY writes:
> 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: c
On Fri, Jun 26, 2009 at 01:33:06AM -0500, Gabriel Dos Reis wrote:
> On Thu, Jun 25, 2...@5:47 PM, Joe Buck wrote:
> > On Thu, Jun 25, 2...@03:19:19PM -0700, Joseph S. Myers wrote:
> >> On Thu, 25 Jun 2009, Ian Lance Taylor wrote:
> >>
> >> > * Test starting the bootstrap with earlier versions of th
On Thu, 2009-06-25 at 15:28 -0700, Ian Lance Taylor wrote:
> Richard Guenther writes:
>
> >> I guess this has to do with reserved word conflict on "new":
> >>
> >> <<
> >> tree
> >> substitute_in_type (tree t, tree f, tree r)
> >> {
> >> tree new;
>
> >>
> >> Do you have some way to deal wi
On Thu, Jun 25, 2009 at 5:47 PM, Joe Buck wrote:
> On Thu, Jun 25, 2009 at 03:19:19PM -0700, Joseph S. Myers wrote:
>> On Thu, 25 Jun 2009, Ian Lance Taylor wrote:
>>
>> > * Test starting the bootstrap with earlier versions of the compiler to
>> > see which C++ compiler version is required, and d
Laurent GUERBY writes:
> Wanting to test Ada on the branch, after checkout I did on x86_64-linux:
>
> ../gcc/configure --enable-languages=c,c++,ada --enable-__cxa_atexit
> --disable-nls --enable-threads=posix --with-mpfr=/opt/cfarm/mpfr-2.4.1/
> --with-gmp=/opt/cfarm/gmp-4.2.4/ --prefix=/n/16/gu
On Thu, Jun 25, 2009 at 03:19:19PM -0700, Joseph S. Myers wrote:
> On Thu, 25 Jun 2009, Ian Lance Taylor wrote:
>
> > * Test starting the bootstrap with earlier versions of the compiler to
> > see which C++ compiler version is required, and document that.
>
> I think the right approach is not d
> I think the right approach is not documenting observations like that, but
> investigating the causes of failures with older compilers and making it
> build with as wide a range of versions of GCC (and ideally at least one
> non-GCC C++ compiler, probably an EDG-based one such as the Intel
> compi
Richard Guenther writes:
>> I guess this has to do with reserved word conflict on "new":
>>
>> <<
>> tree
>> substitute_in_type (tree t, tree f, tree r)
>> {
>> tree new;
>>
>> Do you have some way to deal with this?
>
> Use a non-reserved identifier. I guess on trunk Ada doesn't build
> w
On Thu, 25 Jun 2009, Ian Lance Taylor wrote:
> * Test starting the bootstrap with earlier versions of the compiler to
> see which C++ compiler version is required, and document that.
I think the right approach is not documenting observations like that, but
investigating the causes of failures
On Thu, Jun 25, 2009 at 11:50 PM, Laurent GUERBY wrote:
> On Thu, 2009-06-25 at 13:32 -0700, Ian Lance Taylor wrote:
>> I am pleased to report that if you configure gcc with
>> --enable-build-with-cxx, which causes the core compiler to be built
>> using a C++ compiler, a bootstrap on x86_64-unknown
On Thu, 2009-06-25 at 13:32 -0700, Ian Lance Taylor wrote:
> I am pleased to report that if you configure gcc with
> --enable-build-with-cxx, which causes the core compiler to be built
> using a C++ compiler, a bootstrap on x86_64-unknown-linux-gnu now
> completes.
>
> I would like to encourage pe
On Thu, Jun 25, 2009 at 10:32 PM, Ian Lance Taylor wrote:
> I am pleased to report that if you configure gcc with
> --enable-build-with-cxx, which causes the core compiler to be built
> using a C++ compiler, a bootstrap on x86_64-unknown-linux-gnu now
> completes.
>
> I would like to encourage peop
I am pleased to report that if you configure gcc with
--enable-build-with-cxx, which causes the core compiler to be built
using a C++ compiler, a bootstrap on x86_64-unknown-linux-gnu now
completes.
I would like to encourage people to try using --enable-build-with-cxx in
other configuration--other
42 matches
Mail list logo
