This is on Debian testing. I have a clean tree r164966. I configure as
follows:
../../gcc-in-cxx/configure --enable-build-with-cxx
--enable-languages=c,c++ --with-gold
I just run make and it fails as below. Any ideas what might be wrong?
Thanks,
Jerry
Configuring stage 1 in ./libcpp
Hi, folks.
I'm looking at reworking the sections on trees in the internals manual
and had a question about how to proceed. Right now, the information is
spread between the GENERIC chapter and Trees chapter. The Trees chapter
interleaves a lot of C and C++-specific info in with GENERIC info.
On Fri, 2010-01-22 at 20:17 -0800, Joe Buck wrote:
On Fri, Jan 22, 2010 at 05:31:03PM -0800, Jerry Quinn wrote:
There is renewed interest in getting a D compiler into the GCC sources.
The most direct route for this to happen is to use the existing Digital
Mars DMD front end
, and contribute that
fork under the current license of GCC, do they still possess the freedom
to continue to do what they wish with the original code?
Thanks,
Jerry Quinn
http://gcc.gnu.org/ml/gcc-patches/2009-12/msg00690.html
[cc'ing gcc since it might be the better forum for this]
/gcc-testresults/2009-10/msg02895.html
http://gcc.gnu.org/ml/gcc-testresults/2009-10/msg02903.html
http://gcc.gnu.org/ml/gcc-testresults/2009-10/msg02904.html
I'm adding below some of the many error messages spilled by abi_check.
I *strongly* suspect:
2009-10-28 Jerry Quinn jlqu
type)
+mangle_type_string (const tree type)
Why this change?
This change is part of reverting my earlier fake namespace patch.
I agree with Jakub's other comments, though.
Jason
Here's the updated patch.
2009-10-28 Jerry Quinn jlqu...@optonline.net
* mangle.c
On Wed, 2009-09-23 at 11:05 -0400, Jason Merrill wrote:
On 09/23/2009 09:22 AM, Jerry Quinn wrote:
I'm not really sure how everything fits together here. Am I missing
something obvious?
I notice that you're missing the fix_string_type that tinfo_name does.
But I'd rather not duplicate
On Tue, 2009-09-22 at 09:40 -0400, Jason Merrill wrote:
On 09/22/2009 07:04 AM, Jerry Quinn wrote:
On Mon, 2009-09-21 at 13:06 -0400, Jason Merrill wrote:
On 09/14/2009 11:54 AM, Jason Merrill wrote:
I think the way to go with this is to revert the compiler bits of
r149964, not mess
On Mon, 2009-09-21 at 13:06 -0400, Jason Merrill wrote:
On 09/14/2009 11:54 AM, Jason Merrill wrote:
I think the way to go with this is to revert the compiler bits of
r149964, not mess with mangle.c at all, and insert the initial * if the
typeinfo name won't have TREE_PUBLIC set, since
On Mon, 2009-09-21 at 13:06 -0400, Jason Merrill wrote:
On 09/14/2009 11:54 AM, Jason Merrill wrote:
I think the way to go with this is to revert the compiler bits of
r149964, not mess with mangle.c at all, and insert the initial * if the
typeinfo name won't have TREE_PUBLIC set, since
-correctness.
Could you show the config.log snippet that shows the failed test?
Is this a new error due to the autotools upgrade, or new due to
glibc 2.10?
I think this is new in glibc 2.10, for the reasons given by Jason Merrill
above.
I've discussed this problem with Jerry
On Thu, 2009-08-27 at 00:24 -0400, Jason Merrill wrote:
On 08/15/2009 10:12 AM, Jerry Quinn wrote:
Building with --enable-build-with-cxx fails to bootstrap as follows:
Comparing stages 2 and 3
warning: gcc/cc1plus-checksum.o differs
warning: gcc/cc1-checksum.o differs
Bootstrap
On Fri, 2009-08-21 at 15:25 -0700, Richard Henderson wrote:
On 08/21/2009 02:37 PM, Jerry Quinn wrote:
OK, I've gotten almost this far and can bootstrap (the asterisk is
actually not the very first char and I have to figure that out).
However, in the referenced test case, both typeinfos
On Thu, 2009-08-20 at 15:22 +0100, Dave Korn wrote:
Your patch puts the asterisk into the namespace identifier decl, so it ends
up in both the rtti NTBS name string, and also in the generated asm name for
the objects. What I think you need to do is use an identifier for the
anonymous
On Thu, 2009-08-20 at 11:12 +0100, Dave Korn wrote:
Jerry Quinn wrote:
On Tue, 2009-08-18 at 08:43 -0700, Richard Henderson wrote:
On 08/17/2009 07:40 PM, Jerry Quinn wrote:
On Mon, 2009-08-17 at 16:16 -0400, Jason Merrill wrote:
I'm not sure why GCC sources would need to mangle function
On Thu, 2009-08-20 at 14:05 +0100, Dave Korn wrote:
Jerry Quinn wrote:
On Thu, 2009-08-20 at 11:12 +0100, Dave Korn wrote:
Jerry Quinn wrote:
Apparently my change is too naive, because the assembler doesn't like a
name with '*' in it. Are there any chars that can pass muster
On Tue, 2009-08-18 at 08:43 -0700, Richard Henderson wrote:
On 08/17/2009 07:40 PM, Jerry Quinn wrote:
On Mon, 2009-08-17 at 16:16 -0400, Jason Merrill wrote:
I'm not sure why GCC sources would need to mangle function-local
structs, though.
Would it be helpful to reserve a leading
On Mon, 2009-08-17 at 16:16 -0400, Jason Merrill wrote:
On 08/15/2009 10:12 AM, Jerry Quinn wrote:
Bootstrap comparison failure!
[...]
(write_nested_name): Add a fake anonymous namespace scope if
true.
What I assume is going on here is that use of anonymous namespaces can
Hi, folks,
Building with --enable-build-with-cxx fails to bootstrap as follows:
Comparing stages 2 and 3
warning: gcc/cc1plus-checksum.o differs
warning: gcc/cc1-checksum.o differs
Bootstrap comparison failure!
x86_64-unknown-linux-gnu/32/libstdc++-v3/libsupc++/eh_alloc.o differs
Hi. I started looking at what it would take to convert zlib to build
with c++.
First off, it's not GPL. Are there any issues with modifying the code
checked into the tree?
Next, it uses automake, which seems to assume that a .c file should be
compiled with CC, and not CXX. I get the
On Wed, 2009-07-15 at 19:07 -0700, Ian Lance Taylor wrote:
Jerry Quinn jlqu...@optonline.net writes:
Hi. I started looking at what it would take to convert zlib to build
with c++.
The zlib library in gcc is actually a copy of upstream sources, so I
don't think it would be a good idea
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
, but the docs make it sound like there is no way to be sure what
you'll get.
Theoretically this would mean that you couldn't even reliably link a
structure in two separate compilation units, which is bogus.
Could someone please clear up my confusion?
Thanks,
Jerry Quinn
On Tue, 2009-06-23 at 20:52 -0700, Andrew Pinski wrote:
On Tue, Jun 23, 2009 at 8:48 PM, Jerry Quinnjlqu...@optonline.net wrote:
Hi, folks,
I'm having trouble seeing how layout is specified at the GENERIC level
for RECORD_TYPEs. The docs and comments in tree.def say that you cannot
, it says
that block scopes and variables are declared in BIND_EXPR nodes.
Can someone please clarify how these things are supposed to fit together in
GENERIC form, assuming the default conversion to GIMPLE will be used?
Thanks,
Jerry Quinn
to be related. How do these get used and would it even be used in a
C-like language?
Thanks,
Jerry Quinn
On Tue, 2009-06-16 at 14:43 +0200, Richard Guenther wrote:
BIND_EXPRs are containers for local variables in the GENERIC
function body (they persist until GIMPLE is lowered). BLOCKs
represent the scope tree of the function (which also refers to
local variables). The BLOCK tree is kept live
how these things are supposed to relate in
GENERIC form, assuming the default conversion to GIMPLE will be used?
Thanks,
Jerry Quinn
Hi,
I just tried to bootstrap the gcc-in-cxx branch, but it fails in stage
2. If I expand the macros, the code looks OK to me.
Any suggestions on how to go about tracking this down (if someone else
doesn't get there first)?
Thanks,
Jerry Quinn
/home/jlquinn/gcc/dev/gcc/host-x86_64
Joseph S. Myers wrote:
On Sat, 21 Mar 2009, Ian Lance Taylor wrote:
../.././gcc/config/i386/i386.c:3282: error: comparison is always true
due to limited range of data type
#define IN_RANGE(VALUE, LOWER, UPPER) \
((unsigned HOST_WIDE_INT) (VALUE) - (unsigned HOST_WIDE_INT) (LOWER)
Jerry Quinn wrote:
Joseph S. Myers wrote:
On Sat, 21 Mar 2009, Ian Lance Taylor wrote:
../.././gcc/config/i386/i386.c:3282: error: comparison is always true
due to limited range of data type
#define IN_RANGE(VALUE, LOWER, UPPER) \
((unsigned HOST_WIDE_INT) (VALUE) - (unsigned
Ian Lance Taylor wrote:
Jerry Quinn jlqu...@optonline.net writes:
2009-03-21 Jerry Quinn jlqu...@optonline.net
* config/i386/i386.c (ix86_function_specific_save): Don't check
range of enum values.
I still don't know why I don't see this, but this is OK for the
gcc-in-cxx
33 matches
Mail list logo
