"H.J. Lu" writes:
>> HJ, do you still see a problem here?
>>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12056
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39188
Fine, but those are different problems. And I'm not sure 12056 is a
real problem at all.
Ian
On Fri, Feb 13, 2009 at 4:40 PM, H.J. Lu wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12056
As I mentioned in that bug report, the C++ standard is not even clear
there so it could maybe a bug with the ABI too :).
-- Pinski
On Fri, Feb 13, 2009 at 3:34 PM, Ian Lance Taylor wrote:
> Daniel Jacobowitz writes:
>
>> On Fri, Feb 13, 2009 at 12:00:38PM -0800, Ian Lance Taylor wrote:
>>> > Another issue for scope encoding. C++ ABI:
>>> >
>>> > ---
>>> > Occasionally entities in local scopes must be mangled too
>>> > (e.g.
Daniel Jacobowitz writes:
> On Fri, Feb 13, 2009 at 12:00:38PM -0800, Ian Lance Taylor wrote:
>> > Another issue for scope encoding. C++ ABI:
>> >
>> > ---
>> > Occasionally entities in local scopes must be mangled too
>> > (e.g. because inlining or template compilation causes multiple
>> > trans
Snapshot gcc-4.4-20090213 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20090213/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
Hi,
A port to the Lattice Micro 32 was submitted back
in December and it had some review but not merged.
It is already in binutils, gdb, and newlib. gdb
includes a simulator. So gcc is the last piece.
The last patch posted is:
http://gcc.gnu.org/ml/gcc-patches/2008-12/msg01024.html
What is
On Fri, Feb 13, 2009 at 12:00:38PM -0800, Ian Lance Taylor wrote:
> > Another issue for scope encoding. C++ ABI:
> >
> > ---
> > Occasionally entities in local scopes must be mangled too
> > (e.g. because inlining or template compilation causes multiple
> > translation units to require access to th
On Fri, Feb 13, 2009 at 8:53 AM, Anthony Newnam wrote:
> I asked on gcc-help, but it seems like this list may be more
> appropriate as it deals with the gcc source.
>
> I have noticed that in my g++ <4.3.0, I am able to compile the
> following code without any errors:
> struct A;
> void foo(A);
>
On Fri, Feb 13, 2009 at 11:03:51AM -0800, Anthony Newnam wrote:
> Thanks Joe.
>
> As far as I know the problem I'm seeing isn't a regression but perhaps
> this script could still be useful. I don't really understand how it is
> supposed to work, since it doesn't appear be working off svn updates.
"H.J. Lu" writes:
>>> "_ZZN1N1fEiEs": encoding of N::f::"Itanium C++ ABI" (no discriminator)
>>
>> The discriminator is optional and is up to the discretion of the
>> compiler. This doesn't matter for interoperability purposes, because
>> such names can not be referenced from other translation u
Paolo Bonzini wrote:
As for copies, I think it would be a bad decision to stick only to
original (after the code selection) alternative and generate copies to
satisfy this alternative. For example, if pseudo got memory instead of
hard-register required by the alternative, it would be bad to gen
Ian Lance Taylor wrote:
Paolo Bonzini writes:
That is in brief how I see it and there are a lot of reload details
missed (like virtual register eliminations or addressing displacement
constraints etc).
I suppose those would stay in reload?
I see no reason for those to stay in
On Fri, Feb 13, 2009 at 11:05 AM, Ian Lance Taylor wrote:
> "H.J. Lu" writes:
>
>> It may be a known issue. Does gcc follow Section 5.1.6 Scope Encoding
>> in C++ ABI:
>>
>> http://www.codesourcery.com/public/cxx-abi/abi.html#mangling
>>
>> I tried the example. But it won't compile. I changed it
Anthony Newnam writes:
> Should I do something like a binary svn search between revisions
> 124707 and 132947? It takes such a long amount of time to compile g++,
> almost a half an hour with my quad core, that it didn't seem practical
> try to do build so many times. I guess there is probably a
"H.J. Lu" writes:
> It may be a known issue. Does gcc follow Section 5.1.6 Scope Encoding
> in C++ ABI:
>
> http://www.codesourcery.com/public/cxx-abi/abi.html#mangling
>
> I tried the example. But it won't compile. I changed it to:
>
> [...@gnu-6 tmp]$ cat x.cc
> namespace N {
> inline c
Thanks Joe.
As far as I know the problem I'm seeing isn't a regression but perhaps
this script could still be useful. I don't really understand how it is
supposed to work, since it doesn't appear be working off svn updates.
Should I do something like a binary svn search between revisions
124707 a
Paolo Bonzini writes:
>> That is in brief how I see it and there are a lot of reload details
>> missed (like virtual register eliminations or addressing displacement
>> constraints etc).
>
> I suppose those would stay in reload?
I see no reason for those to stay in reload (especially since I thi
On Fri, Feb 13, 2009 at 08:53:34AM -0800, Anthony Newnam wrote:
> I asked on gcc-help, but it seems like this list may be more
> appropriate as it deals with the gcc source.
>
> I have noticed that in my g++ <4.3.0, I am able to compile the
> following code without any errors:
> struct A;
> void f
Hi,
It may be a known issue. Does gcc follow Section 5.1.6 Scope Encoding
in C++ ABI:
http://www.codesourcery.com/public/cxx-abi/abi.html#mangling
I tried the example. But it won't compile. I changed it to:
[...@gnu-6 tmp]$ cat x.cc
namespace N {
inline char f(int i) {
static c
Paolo Bonzini wrote:
Jeff Law wrote:
We'd want to encode [early insn alternative selection]
information in the conflict graph so that IRA would
allocate registers so as to fit the constraints of the early insn
alternative selection. Right? In the case where the graph is
uncolorable, do we
I asked on gcc-help, but it seems like this list may be more
appropriate as it deals with the gcc source.
I have noticed that in my g++ <4.3.0, I am able to compile the
following code without any errors:
struct A;
void foo(A);
void bar(A* p){foo(*p);}
In g++ 4.3.0 this seems to have been fixed, b
> As for copies, I think it would be a bad decision to stick only to
> original (after the code selection) alternative and generate copies to
> satisfy this alternative. For example, if pseudo got memory instead of
> hard-register required by the alternative, it would be bad to generate a
> copy
Jeff Law wrote:
I've been thinking further about instruction alternative selection
prior to allocation and one of the questions in my mind is how this
interacts with IRA.
We select an alternative for each insn based on some "best guess"
heuristic -- the selection of an alternative will often
Hi,
On Fri, 13 Feb 2009, Paolo Bonzini wrote:
> > We'd want to encode [early insn alternative selection] information in
> > the conflict graph so that IRA would allocate registers so as to fit
> > the constraints of the early insn alternative selection. Right? In
> > the case where the graph
Jeff Law wrote:
> We'd want to encode [early insn alternative selection]
> information in the conflict graph so that IRA would
> allocate registers so as to fit the constraints of the early insn
> alternative selection. Right? In the case where the graph is
> uncolorable, do we allow IRA to over
I've been thinking further about instruction alternative selection prior
to allocation and one of the questions in my mind is how this interacts
with IRA.
We select an alternative for each insn based on some "best guess"
heuristic -- the selection of an alternative will often restrict the
reg
Paolo Bonzini wrote:
"-Wstrict-aliasing
This option is only active when -fstrict-aliasing is active. It
warns about code which might
break the strict aliasing rules that the compiler is using for
optimization. The warning does
not catch all cases, but does attempt to catch the more common
pit
> "-Wstrict-aliasing
> This option is only active when -fstrict-aliasing is active. It
> warns about code which might
> break the strict aliasing rules that the compiler is using for
> optimization. The warning does
> not catch all cases, but does attempt to catch the more common
> pitfalls. I
hi all,
I wrote a simple testcase with some type prunned pointer and
compiled it with -O2 option.
I assumed that gcc would issue some warnings as told in its documents.
But i am afraid that no warnings at all. I have to specify the
-Wstrict-aliasing or -Wall option manually.
Is this a docu
Hi Basile et al,
Thanks a lot for detailed explanations.
In addition to Zbigniew's reply:
I didn't specifically put MELT into new category (I actually just
updated the page and added it to the other categories too),
but I still keep the new pass integration plugin, since
some of our colleagues
Hello everybody,
2009/2/13 Basile STARYNKEVITCH wrote
>Hello All,
>
>I am not sure of the relevance of the "new pass integration plugins"
> examplified by MELT.
>[...]
>In my view, MELT fits quite precisely in the "production plugins"
> definition, while indeed I expect it to b
31 matches
Mail list logo
