That is what I missed. Thanks.
This patch should work.
Sure, but it makes the mess even worse. You should instead:
- in config/t-svr4, change the two CFLAGS assignments to use +=
- in config/i386/t-sol2, change the CRTSTUFF_T_CFLAGS assignment to "+=
-O2" and remove the TARGET_LIBGCC2_CFLA
On Wed, Aug 08, 2007 at 10:06:03AM +0200, Paolo Bonzini wrote:
>
> >That is what I missed. Thanks.
> >
> >This patch should work.
>
> Sure, but it makes the mess even worse. You should instead:
>
> - in config/t-svr4, change the two CFLAGS assignments to use +=
There is
CRTSTUFF_T_CFLAGS_S =
CRTSTUFF_T_CFLAGS_S = $(CRTSTUFF_T_CFLAGS) -fPIC
How do you use +=?
Sorry, I was looking at an old checkout.
Could you simply test patching config/i386/t-crtstuff like this:
-CRTSTUFF_T_CFLAGS = -fno-omit-frame-pointer -fno-asynchronous-unwind-tables
+CRTSTUFF_T_CFLAGS += -fno-omit-frame-po
I've updated http://gcc.gnu.org/wiki/tuples to show the items we still
have to go through. To avoid stepping on each other's toes, please
claim the items you are working (or plan to work on) in the list.
I've arranged the items in the plan to reflect the critical path that
should take us to boots
> -Original Message-
> [ ... snip ... ]
>
> > CRTSTUFF_T_CFLAGS_S = $(CRTSTUFF_T_CFLAGS) -fPIC
> >
> > How do you use +=?
>
> Sorry, I was looking at an old checkout.
>
> Could you simply test patching config/i386/t-crtstuff like this:
>
> -CRTSTUFF_T_CFLAGS = -fno-omit-frame-pointer
On Wed, Aug 08, 2007 at 09:45:00AM -0500, Arthur Haas wrote:
>
> > -Original Message-
> > [ ... snip ... ]
> >
> > > CRTSTUFF_T_CFLAGS_S = $(CRTSTUFF_T_CFLAGS) -fPIC
> > >
> > > How do you use +=?
> >
> > Sorry, I was looking at an old checkout.
> >
> > Could you simply test patching c
Making the change above results in a successful build. Quite a
difference what a '+' can make.
This patch works fine on Linux/x86 and Linux/x86-64.
Thanks!
Paolo
Hi,
On Tue, 7 Aug 2007, Ollie Wild wrote:
> In response to a suggestion from Mark Mitchell, I've been attempting to
> migrate pointers to members to the GCC middle end. The goal of this is
> twofold: (a) to enable conversion of pointer to member dereferences to
> direct function calls and mem
Hi,
> Pranav, although there is indeed a bug in the mid-end here, from your point
> of view the simple and effective workaround should be to implement a movdi
> pattern (and movsf and movdf if you don't have them yet: it's an absolute
> requirement to implement movMM for any modes you expect you
with reference to the following:
struct data {
data (long v) : m_data (v) {}
data (const data&) {}
long m_data;
};
data foo (data v) {
return v;
}
my reading of the x86_64 ABI (v .98, sept 2006) on page 17 is that
data should have class MEMORY when passed as argument to
Hello everyone,
I am currently trying to enable GCC to perform compilation without
having to respect any compilation order, i.e. execute some pass to
any function at any time (it is not only pass reordering).
As what I have seen from (trunk version of) GCC, it doesn't seem an
easy task to
On 8/8/07, Cupertino Miranda <[EMAIL PROTECTED]> wrote:
> Hello everyone,
>
> I am currently trying to enable GCC to perform compilation without
> having to respect any compilation order, i.e. execute some pass to
> any function at any time (it is not only pass reordering).
>
> As what I have seen
Hi,
On Wed, 8 Aug 2007, Maurizio Vitale wrote:
> with reference to the following:
>
> struct data {
> data (long v) : m_data (v) {}
> data (const data&) {}
> long m_data;
> };
>
> data foo (data v) {
> return v;
> }
>
> my reading of the x86_64 ABI (v .98, sept 2006) o
I am pleased to announce that the GCC Steering Committee has
promoted Zdenek Dvorak to full maintainership of all of the GCC
loop infrastructure.
Please join me in congratulating Zdenek on his new role.
Zdenek, please update your listing in the MAINTAINERS file.
Happy hacking!
Dav
Michael Matz <[EMAIL PROTECTED]> writes:
> If you were to implement something like virtual functions into the middle
> end, it should be expressed in a fairly low level way IMHO. E.g. a
> virtual table simply being a vector of pointers to function decls (which
> we can express already just fin
On 08 Aug 2007 17:36:43 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> Michael Matz <[EMAIL PROTECTED]> writes:
>
> > If you were to implement something like virtual functions into the middle
> > end, it should be expressed in a fairly low level way IMHO. E.g. a
> > virtual table simply bein
Hi,
On Thu, 8 Aug 2007, Ian Lance Taylor wrote:
those whose runtime type can be any derived one) can not. E.g. I
wouldn't try to model the inheritance relationship.
There is some advantage to knowing class heirarchy relationships in LTO.
Some C++ programs implement different virtual subclas
In stage2,
../../gcc/gcc/tree.c:7694: error: passing argument 1 of 'fixed_zerop' discards
qualifiers from pointer target type
Dave
--
J. David Anglin [EMAIL PROTECTED]
National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
On 8/8/07, Michael Matz <[EMAIL PROTECTED]> wrote:
> So those tree expressions would live throughout the middle-end and only
> then become lowered to RTL directly? I'm not sure that's worthwhile.
> E.g. I'm not sure why there's a need to really get rid of the
> expand_constant langhook. It's only
Ollie Wild wrote:
> On 8/8/07, Michael Matz <[EMAIL PROTECTED]> wrote:
Ollie, thanks for patiently trying out different approaches.
> I think the primary purpose of the middle end is to provide a
> representation which captures the semantics of a program at a
> sufficiently high level to enable e
On 8/8/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> Ollie Wild wrote:
> > On 8/8/07, Michael Matz <[EMAIL PROTECTED]> wrote:
>
> Ollie, thanks for patiently trying out different approaches.
>
> > I think the primary purpose of the middle end is to provide a
> > representation which captures the s
On 8/8/07, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> I also haven't necessarily said what Ollie has proposed is a bad idea.
> I have simply said the way he has come up with what he proposed is
> not the way we should go about this. It may turn out he has come up
> with exactly the representation
22 matches
Mail list logo
