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
config
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.
Wha
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
> &g
, 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]
>
> I *strongly* suspect:
>
> 2009-10-28 Jerry Quinn
>
> * mangle.c (mangle_type_string_for_rtti): Revert r149964.
> (needs_fake_anon): Likewise.
> (write_name): Likewise.
> (write_nested_name): Likewise.
> * cp-tree.h (mangle_typ
On Wed, 2009-10-28 at 11:35 -0400, Jason Merrill wrote:
> On 10/28/2009 07:29 AM, Jerry Quinn wrote:
> > + length = strlen (name);
> > + if (mark_private)
> > + name_string = build_string (length + 1, buf);
> > + else
> > +name_string = build_string (
PE. */
> >>
> >> const char *
> >> -mangle_type_string_for_rtti (const tree 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
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_n
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
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, sinc
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, sinc
> I think this is new in glibc 2.10, for the reasons given by Jason Merrill
> > above.
> > I've discussed this problem with Jerry Quinn before, and he had a
> > tentative patch that worked for me.
> > As I understand things, this patch is on hold waiting for a s
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
> > wa
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
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 nam
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
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:
> >>>&g
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.
> &
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
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
x86_64-unknown-l
On Wed, 2009-07-15 at 19:07 -0700, Ian Lance Taylor wrote:
> Jerry Quinn 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 w
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 impression
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
On Tue, 2009-06-23 at 20:52 -0700, Andrew Pinski wrote:
> On Tue, Jun 23, 2009 at 8:48 PM, Jerry Quinn 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
t 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-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
ears
to be related. How do these get used and would it even be used in a
C-like language?
Thanks,
Jerry Quinn
C. In this section, 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
someone please clarify how these things are supposed to relate in
GENERIC form, assuming the default conversion to GIMPLE will be used?
Thanks,
Jerry Quinn
Ian Lance Taylor wrote:
Jerry Quinn writes:
2009-03-21 Jerry Quinn
* 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 branch.
Do I need to t
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
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) \
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-x
34 matches
Mail list logo
