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
> 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 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
> 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 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
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
>
> 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
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
"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)" \
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
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
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
Hello All the gurus,
I've been fiddling my luck with gcc 4.3.2 inline assembly on powerpc
There are a few queries
1. asm volatile or simply asm produce the same assembly code.
Tried with a few examples but didnt find any difference by adding
volatile with asm
2. Use of "memory" and clobbered reg
Main changes from binutils 2.19.51.0.10:
Fix strip on static executable with STT_GNU_IFUNC symbol. PR 10337.
Add STB_GNU_UNIQU support.
H.J.
---
This is the beta release of binutils 2.19.51.0.11 for Linux, which is
based on binutils 2009 0627 in CVS on sourceware.org plus various
changes. It is
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 (
Hi, all,
I just tried to build gcc-in-cxx with some older gcc compilers on x86_64
linux. This is Debian testing, with 4.3.3 as the system compiler.
Here's what I've gotten so far:
2.95.3 Doesn't support x86_64
3.0.4 Doesn't support x86_64
3.1.1 Fails to bootstrap
3.2.3 Fails to bootstra
16 matches
Mail list logo
