On Feb 7, 2008 1:10 AM, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> Doug Gregor wrote:
> > PR c++/34935 illustrates a problem with the way attributes interact
> > with type identity. The example in question looks something like this:
> >
> > typedef int X __attribute((may_alias));
> >
> > void f
On Wed, 6 Feb 2008, Richard Kenner wrote:
> > > (anyone for an Ada tutorial during the summit? ;)
> >
> > (I wish I didn't see that smiley, because)
> > For practical reasons, I'd agree that's a very good idea!
> >
> > I mean, those (hopefully "we") who attend could presumably hear
> > about som
Pavan R wrote:
Can I get some help on this.
Surely you already have an answer. The libgcc on suse 10 isn't
compatible with your RHEL3-compiled program, so you discovered
the fix was to put a better libgcc in your LD_LIBRARY_PATH.
Since you have found a fix that works, why do you still want
he
Andrew,
Thanks for the response. The question was, how was the libgcc that
was shipped with suse 10 SP1
was incompatible with our RHEL3 compiled program , whereas replacing
the libgcc with a latest one works fine ?
Are there any compat issues dealt in libgcc recent releases ?
At the first c
On Feb 7, 2008 11:33 AM, Pavan R <[EMAIL PROTECTED]> wrote:
> Andrew,
>
> Thanks for the response. The question was, how was the libgcc that
> was shipped with suse 10 SP1
> was incompatible with our RHEL3 compiled program , whereas replacing
> the libgcc with a latest one works fine ?
> Are t
On Wed, 6 Feb 2008, Richard Kenner wrote:
> > > (anyone for an Ada tutorial during the summit? ;)
> >
> > (I wish I didn't see that smiley, because)
> > For practical reasons, I'd agree that's a very good idea!
> >
> > I mean, those (hopefully "we") who attend could presumably hear
> > about some s
Having a tutorial during the GCC summit on Ada and how some of its constructs
stress more than other languages the back-end in some cases sounds indeed
like a very good idea, so we will work on this, thanks for the suggestion!
Arno
Hi, Paolo and Ian,
Thanks a lot for your suggestions. I have tried the one suggested by Paolo
It has improved my code considerably, disposing of load and stores.
However, the code produced is still not as efficient as I would like it to be
For the following function
int bar()
{
int r1, r2;
lo
Hi,
> However, _M_impl, _M_start etc are gcc internals and it might be risky for
> Emacs to rely on them. Can anyone say how likely these internals are to
> change? I'm not asking for a guarantee. It would be helpful just to know
> when they last changed as an indication of how volatile this cod
In the response of Paolo I also don't understand how the DI pseudo could be
mapped on two consecutive SI regs. I think gcc always will map a multiword
pseudo on consecutive word-size regs. Am I wrong here ?
Oops, I forgot a part. In the RTL description don't write
[(set (match_operand:D
Richard Guenther wrote:
> I am mostly interested in the Ada <-> middle-end interaction, specially
> where Adas requirements on the middle-end exceed that of C, and how this
> is currently handled. [...]
Thanks. There is indeed a lot to say/discuss on that ground and we'd
certainly be very happy
[(set (subreg:SI (match_operand:DI 0 "register_operand") 0)
(unspec [...] SUPER_LD32_LO))
(set (subreg:SI (match_operand:DI 0 "register_operand") 4)
(unspec [...] SUPER_LD32_HI))]
I finally looked at my code instead of going by memory. :-)
I think you should turn what you h
On Feb 6, 2008 10:46 PM, NightStrike <[EMAIL PROTECTED]> wrote:
> On 12/5/07, Rask Ingemann Lambertsen <[EMAIL PROTECTED]> wrote:
> > On Wed, Dec 05, 2007 at 04:32:00PM -0500, NightStrike wrote:
> > > On 12/5/07, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> > > > Patch manager will be dying for a wee
> > However, _M_impl, _M_start etc are gcc internals and it might be risky for
> > Emacs to rely on them. Can anyone say how likely these internals are to
> > change? I'm not asking for a guarantee. It would be helpful just to know
> > when they last changed as an indication of how volatile thi
> > I would say they are pretty stable, because we have a stable ABI which
> > we are not going to break until C++0x: that means we can only implement
> > limited span changes, we cannot add data members, for example neither
> > change the memory layout of the classes.
Probably an ignorant que
On Thu, 2008-02-07 at 11:21 -0500, Daniel Berlin wrote:
> Yes.
> I currently lack the time to bring it back online for a while)
> (Though im happy to give the code to anyone who wants to give it a try
> on gcc.gnu.org)
Is there a requirement to run it on gcc.gnu.org machine?
If not I can try to
From: "Mike Stump" <[EMAIL PROTECTED]>
Perhaps others are rooted from generic parts of the compiler, not
objc++. Still it would be nice to clean them up.
Agreed. If you want to work on it, I'd be happy to help out, just let
me know.
Okay, I'll file PRs and add you to the CC list. :-)
On Thu, Feb 07, 2008 at 03:18:19PM -0500, Daniel Jacobowitz wrote:
> On Thu, Feb 07, 2008 at 12:08:33PM -0800, Joe Buck wrote:
> > It doesn't need to know that. Any compiler that follows the ABI, whether
> > gcc,
> > icc, or SGI's compiler, will produce the same data members on a GNU/Linux
> > or
On Thu, Feb 07, 2008 at 12:08:33PM -0800, Joe Buck wrote:
> It doesn't need to know that. Any compiler that follows the ABI, whether gcc,
> icc, or SGI's compiler, will produce the same data members on a GNU/Linux
> or BSD platform. It's a portable specification.
I don't believe that the multi-v
> I wanted to recompile gcc for the new target. First I made the changes in
Oops I fogot to write, that I'm talking about a cross compiler from my Linux
x86_64 host to the i386-pc-lost target.
I looked at the specs of the cross compiler and I remarked that it calls as
hardcoded. But it makes th
On 07/02/2008, Doug84 <[EMAIL PROTECTED]> wrote:
>
> Hi folks,
>
> I've been looking at the documentation for writing a GCC front end and the
> common thing I believe I'm seeing is that the GCC front ends are all run
> through GCC (i.e. you're efficiently adding a new section of coding to the
> GCC
Hi Paolo, thanks for the tip.
I tried it and things look different now, but I still didn't achieve
the desired efficiency. Now after subreg lowering the code looks like:
(insn 6 29 7 (parallel [
(set (subreg:SI (reg/v:DI 133 [ tmp ]) 0)
(unspec:SI [ (reg/f:SI 135)] 120
Hi Kaveh,
Andreas Tobler wrote:
On mainline only (not 4.2 or prior) does this work instead?
Yep, trunk.
[ultra10:gcc/testsuite/gcc.dg] andreast% diff -u
/usr/include/iso/math_c99.h.orig /usr/include/iso/math_c99.h
--- /usr/include/iso/math_c99.h.origMon Feb 4 21:55:29 2008
+++ /usr/in
> "Doug84" == Doug84 <[EMAIL PROTECTED]> writes:
Doug84> What I wish to do is create my own front end outside of GCC
Doug84> and then send the partly-processed code through the back end
Doug84> (i.e. an intermediate to assembly code transformation would be
Doug84> done by GCC - the High langu
On Fri, Feb 08, 2008 at 08:28:21AM +1300, Nick Roberts wrote:
>
> > > I would say they are pretty stable, because we have a stable ABI which
> > > we are not going to break until C++0x: that means we can only implement
> > > limited span changes, we cannot add data members, for example neither
Paolo Bonzini <[EMAIL PROTECTED]> writes:
> > In the response of Paolo I also don't understand how the DI pseudo could be
> > mapped on two consecutive SI regs. I think gcc always will map a multiword
> > pseudo on consecutive word-size regs. Am I wrong here ?
>
> Oops, I forgot a part. In th
On Feb 7, 2008 3:48 PM, Laurent GUERBY <[EMAIL PROTECTED]> wrote:
> On Thu, 2008-02-07 at 11:21 -0500, Daniel Berlin wrote:
> > Yes.
> > I currently lack the time to bring it back online for a while)
> > (Though im happy to give the code to anyone who wants to give it a try
> > on gcc.gnu.org)
>
>
On Thu, Feb 7, 2008 at 3:49 AM, Arnaud Charlet <[EMAIL PROTECTED]> wrote:
> Having a tutorial during the GCC summit on Ada and how some of its constructs
> stress more than other languages the back-end in some cases sounds indeed
> like a very good idea, so we will work on this, thanks for the s
.. I don't have much to add to the various informative replies. Only, a
general recommendation. Let's not use in any "official" document the
term "STL": it does *not* exist in any ISO standard, basically dates
back to early nineties HP / SGI code.
Paolo.
Richard Guenther wrote:
I don't think that may_alias is an attribute that needs to be mangled, as its
semantics affect code generation but not interfacing. For example:
void foo(int *x __attribute__((may_alias));
and
void foo(int *x);
are not distinguishable at the point of the caller -- bu
Hi folks,
I've been looking at the documentation for writing a GCC front end and the
common thing I believe I'm seeing is that the GCC front ends are all run
through GCC (i.e. you're efficiently adding a new section of coding to the
GCC program through softcode).
What I wish to do is create my o
Antoine Kaufmann wrote:
after some small changes. But when I tried to compile a simple Hello World,
gcc failed with some assembler error messages about illegal operad size with
some push instructions. As i guessed they seem to come from the host 64bit
as. I compared the error messages by trying
Hi,
while working at graphite I had some problems with the SCoP detection.
It seems to me, that I expect the SCoPs being defined slightly
different.
At the moment a SCoP is defined like this (as I understand):
A SCoP is a part of the CFG wich can be extracted, optimized using the
polyhedral mode
From: "Kaveh R. Ghazi" <[EMAIL PROTECTED]>
From: "Mike Stump" <[EMAIL PROTECTED]>
Perhaps others are rooted from generic parts of the compiler, not
objc++. Still it would be nice to clean them up.
Agreed. If you want to work on it, I'd be happy to help out, just let
me know.
Okay, I'll
34 matches
Mail list logo
