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
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 (
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
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
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
16 matches
Mail list logo
