Re: x86_64 unwinder in libgcc_s

[Dmitri Shubin]

On 06.08.2012 21:13, Richard Henderson wrote:

On 08/06/2012 08:23 AM, Dmitri Shubin wrote:

 char *cfa = (char *) _Unwind_GetCFA(ctx);
 printf("cfa = %p\nra = %p\n", cfa, *(void **)(cfa - 8));

Use _Unwind_GetIP here, for one.
In fact I'm not interested in IP or RA here, I need some context stored 
by assembly routine on the stack relative to its CFA.
I use RA only to illustrate that I got "wrong" (from my pov) CFA from 
libgcc unwinder.
And the question is is it a bug (or deviation from x86-64 psABI) in 
libgcc or I misunderstand what CFA is.

Re: Function parameter debug info at -O0

[Richard Guenther]

On Tue, Aug 7, 2012 at 4:54 AM, Senthil Kumar Selvaraj
 wrote:
> On Mon, Aug 06, 2012 at 01:40:57PM -0400, Frank Ch. Eigler wrote:
>> Senthil Kumar Selvaraj  writes:
>>
>> > [...]
>> > The following program, when compiled with -O0 -g3 (x86_64 target, but
>> > doesn't seem to matter), shows wrong values for p (function parameter)
>> > when debugging. [...]
>>
>> This sounds like .
>>
>
> I guess that's a different issue - that bug talks about debug info for
> formal parameters being invalid before they are pushed on the stack. In
> the case I described, it stays wrong for the entire body of the
> function.
>
> The core of the problem appears to be that a formal parameter
> that is not read from but written to, is allocated space on the stack twice -
> once when expand_used_vars runs, and once when expand_function_start
> runs. The debug information generated for the formal parameter only
> points to the space allocated by the former, and thus does not reflect
> writes to the variable that occur on the space allocated by the
> latter.

Please open a bugreport.

Richard.

> Regards
> Senthil

Re: at exit alternative for AIX

[Perry Smith]

On Aug 5, 2012, at 3:50 PM, Perry Smith wrote:

> 
> On Aug 5, 2012, at 1:09 PM, David Edelsohn wrote:
> 
>> On Sun, Aug 5, 2012 at 9:56 AM, Perry Smith  wrote:
>> 
>>> I was planning on exploring when _GLOBAL__FD was called today.  I
>>> need to figure out when gcc puts the call to the dtor in _GLOBAL__FD
>>> path rather than in the atexit path.  The net implies that "static" uses
>>> atexit while a global non-static uses _GLOBAL__FD
>>> 
>>> I'm also exploring what it would take to port a version of GNU's
>>> __cxa_atexit to AIX.  I think after I figure out when various dtors
>>> get called, I should be able to figure out if / how to do that.
>>> 
>>> Part of my confusion / concern is "why have two methods?"
>>> Does the spec say that dtors much be called at different times?
>> 
>> Destructors are added to _GLOBAL__FD by collect2 at link time.  It
>> scans the object files for destructor functions, sorts them by
>> priority and creates a function connected to _GLOBAL__FD to call them.
>> Collect2 performs the same grouping for constructors, creates a
>> function and connects it to _GLOBAL__FI.  The uniquely named functions
>> are added to the AIX linker command line as arguments to the
>> -binitfini option to establish them as initializer/finalizer functions
>> for the shared object.
>> 
>> AIX does not have a ctor/dtor or init/fini section in object files,
>> nor _cxa_atexit.
>> 
>> AIX dlclose() should call AIX terminateAndUnload() service that will
>> call the fini routine registered by -binitfini.  If something else in
>> GCC is trying to register the termination function for systems without
>> _cxa_atexit() using atexit(), it probably is conflicting and trying to
>> run the destructors twice.
>> 
>> Another difference between AIX and SVR4 is AIX invokes init and fini
>> functions for multiple, dependent shared objects breadth first, while
>> SVR4 invokes them depth first based on library dependencies.  There is
>> an old Bugzilla entry with a proposal to push init functions onto a
>> stack as they are seen when libraries are loaded and then run them in
>> SVR4 dependency order.
> 
> Thank you both for helping.
> 
> I understand when atexit is used.  I believe the _GLOBAL__FD method
> could be used instead and would be more correct but it somehow needs to
> be conditionalized.
> 
> To get the atexit to be used, you need a function that returns a static
> that is declared inside the function.  In my code below, this is
> "func".
> 
> The function registered with atexit is called tcf_0 (I'm sure that
> would increment if there are more than one).  I mention that hoping it
> might help in tracking down where it is being created.
> 
> There are other parts to this program that I left because, to me, it
> was interesting when atexit is called and all the places where it is
> not called.
> 
> I call the program x1.cpp.  x1 with no argument does not create
> "func".  x1 with an argument does.  Note that if func is not created,
> the dtor is not called (which seems obvoius but that is where the
> difficulty is going to come from).
> 
> My thoughts on how to solve this would call tcf_0 from the _GLOBAL_FD
> and have tcf_0 check a flag.  If not set, it does nothing.  In the
> special ctor where atexit is now being called, just set that flag
> instead of calling atexit.
> 
> Here is the program:
> 
> #include 
> using namespace std;
> 
> class foo {
> private:
>const char *name;
>void mess(const char *s) {
>cout << s << " " << name << endl;
>}
> 
> public:
>foo(const char *s) {
>name = s;
>mess("ctor");
>}
> 
>~foo() {
>mess("dtor");
>}
> };
> 
> class bar {
>static foo surf;
> };
> foo bar::surf("bar");
> 
> foo g("global");
> static foo s("static");
> 
> foo& func()
> {
>static foo val("func");
>return val;
> }
> 
> int main (int argc, char *argv[])
> {
>cout << "Hello World!" << endl;
>foo a("auto");
> 
>if (argc > 1)
>foo &f = func();
> 
>cout << "Good Bye World!" << endl;
>return 0;
> }
> 
> Output with x1 called with no argument:
> ctor bar
> ctor global
> ctor static
> Hello World!
> ctor auto
> Good Bye World!
> dtor auto
> dtor static
> dtor global
> dtor bar
> 
> Output with x1 called with an argument:
> ctor bar
> ctor global
> ctor static
> Hello World!
> ctor auto
> ctor func << atexit called just after this prints.
> Good Bye World!
> dtor auto
> dtor func
> dtor static
> dtor global
> dtor bar
> 
> I'm happy to create a bug report if anyone wants me to.

Not sure why this thread died.  I've been looking at the code trying to gain
the courage to try and implement the changes I suggested but was 
also waiting to hear back from others.

Thank you,
Perry

Re: pr45605.C devirtualize call failure in ia64-hp-hpux?

[Richard Guenther]

On Mon, Aug 6, 2012 at 8:21 PM, Martin Jambor  wrote:
> Hi,
>
> I've had this flagged to look at "later" for quite long now...
>
> On Mon, Apr 30, 2012 at 07:34:24AM +, Mailaripillai, Kannan Jeganathan 
> wrote:
>> Hi,
>>
>> This is related to pr45605.C test.
>>
>>  Reduced testcase
>>
>> struct B {
>>   virtual void Run(){};
>> };
>>
>> struct D : public B {
>>   virtual void Run() { };
>> };
>>
>> int main() {
>>   D d;
>>   static_cast(d).Run();
>> }
>>
>> With x86_64 linux the call to Run through object d is devirtualized.
>> Whereas it looks like in ia64 hp-ux it is not devirtualized.
>>
>> -fdump-tree-fre1 output for both:
>>
>>  x86_64 linux:
>>
>>   MEM[(struct B *)&d]._vptr.B = &MEM[(void *)&_ZTV1B + 16B];
>>   d.D.2197._vptr.B = &MEM[(void *)&_ZTV1D + 16B];
>>   D.2248_1 = &MEM[(void *)&_ZTV1D + 16B];
>>   D.2249_2 = Run;
>>   D::Run (&d.D.2197);
>>   d ={v} {CLOBBER};
>>   return 0;
>>
>>  ia64 hp-ux:
>>
>>   MEM[(struct B *)&d]._vptr.B = &MEM[(void *)&_ZTV1B + 16B];
>>   d.D.1878._vptr.B = &MEM[(void *)&_ZTV1D + 16B];
>>   D.1929_1 = &MEM[(void *)&_ZTV1D + 16B];
>>   D.1930_2 = (int (*__vtbl_ptr_type) ()) &MEM[(void *)&_ZTV1D + 16B];
>>   OBJ_TYPE_REF(D.1930_2;&d.D.1878->0) (&d.D.1878);
>>
>> Is it a bug (unexpected with O1 compilation) that it is not optimized to 
>> direct call?
>
>
> There are two important and related differences.  The first one is
> that virtual method tables on ia64 constist of FDESC_EXPRs rather than
> mere ADDR_EXPRs.  The second one can be seen in the dumps just before
> fre1 (i.e. esra):
>
> i686:
>   d.D.1854._vptr.B = &MEM[(void *)&_ZTV1D + 8B];
>   D.1961_4 = d.D.1854._vptr.B;
>   D.1962_5 = *D.1961_4;
>   OBJ_TYPE_REF(D.1962_5;&d.D.1854->0) (&d.D.1854);
>
> ia64:
>   d.D.1883._vptr.B = &MEM[(void *)&_ZTV1D + 16B];
>   D.1991_4 = d.D.1883._vptr.B;
>   D.1992_5 = (int (*__vtbl_ptr_type) ()) D.1991_4;
>   OBJ_TYPE_REF(D.1992_5;&d.D.1883->0) (&d.D.1883);
>
> The main difference is not the type cast in the third assignment but
> the fact that there is no dereference there, which means that gimple
> folder has to deal with it at a different place.
>
> I played with it a bit this afternoon and came up with the following
> untested patch to fix the pr45605.C testcase.  I can bootstrap and
> test it on ia64 if we do not mind this special casing of FDESC_EXPRs
> in the midle end (I hope that all platforms that use it use it in the
> same way, I only know ia64...)
>
> Thanks,
>
> Martin
>
>
> 2012-08-06  Martin Jambor  
>
> * gimple-fold.c (gimple_fold_stmt_to_constant_1): Also fold
> assignments of V_C_Es of addresses of FDESC_EXPRs.
>
>
> *** gcc/gimple-fold.c   Mon Aug  6 14:36:37 2012
> --- /tmp/FcpIKb_gimple-fold.c   Mon Aug  6 20:17:26 2012
> *** gimple_fold_stmt_to_constant_1 (gimple s
> *** 2542,2548 
>  == TYPE_ADDR_SPACE (TREE_TYPE (op0))
>   && TYPE_MODE (TREE_TYPE (lhs))
>  == TYPE_MODE (TREE_TYPE (op0)))
> !   return op0;
>
> return
> fold_unary_ignore_overflow_loc (loc, subcode,
> --- 2542,2556 
>  == TYPE_ADDR_SPACE (TREE_TYPE (op0))
>   && TYPE_MODE (TREE_TYPE (lhs))
>  == TYPE_MODE (TREE_TYPE (op0)))
> !   {
> ! tree t;
> ! if (TREE_CODE (op0) != ADDR_EXPR)
> !   return op0;
> ! t = fold_const_aggregate_ref_1 (TREE_OPERAND (op0, 0), 
> valueize);
> ! if (t && TREE_CODE (t) == FDESC_EXPR)
> !   return build_fold_addr_expr_loc (loc, TREE_OPERAND (t, 
> 0));

FDESC_EXPR has two operands ... is it really ok to ignore the 2nd?

/* Operand0 is a function constant; result is part N of a function
   descriptor of type ptr_mode.  */
DEFTREECODE (FDESC_EXPR, "fdesc_expr", tcc_expression, 2)

I suppose yes, from what I see in the uses in the C++ frontend.  In fact
_all_ users of FDESC_EXPR seem to ignore the 2nd operand ...!?
(I would have expected users in machine specific code ...

Thus,

Ok!

Thanks,
Richard.


> ! return op0;
> !   }
>
> return
> fold_unary_ignore_overflow_loc (loc, subcode,

Re: Merging the cxx-conversion branch into trunk

[Diego Novillo]

On 12-08-03 03:55 , Richard Guenther wrote:


I am currently debugging this change. After I fix the remaining PCH
failures, I will send the patch for review.


Please make sure to send a patch doing 4. for review separate of the cxx-branch
merging.


That's the patch I was referring to, yes.


Micha worked on the plugin API for some time and I believe has something
ready already (also introspection only).


Excellent!


Sure, I expect that most of the special GTY annotations should be handled
by user-provided walkers.  I suppose it would be useful to allow to specify
that only certain fields of a struct are handled by the user walker?  Like


Possible. The current approach only generates user-callable entry points 
to types that are referred to in template parameters. We can make it so 
every type gets a user entry point.




/* Base of all entries in the symbol table.
The symtab_node is inherited by cgraph and varpol nodes.  */
struct GTY(()) symtab_node_base
{
...
   /* Linked list of symbol table entries starting with symtab_nodes.  */
   symtab_node next GTY((specialized));
   symtab_node previous GTY((specialized));
...

and then have gengtype generate


Or this, but we can probably do this just as easily without the markers. 
I'll discuss this more in the patch I'll be sending later today.



Diego.

Re: pr45605.C devirtualize call failure in ia64-hp-hpux?

[Martin Jambor]

Hi,


On Tue, Aug 07, 2012 at 03:14:21PM +0200, Richard Guenther wrote:
> On Mon, Aug 6, 2012 at 8:21 PM, Martin Jambor  wrote:
> > I've had this flagged to look at "later" for quite long now...
> >
> > On Mon, Apr 30, 2012 at 07:34:24AM +, Mailaripillai, Kannan Jeganathan 
> > wrote:
> >> Hi,
> >>
> >> This is related to pr45605.C test.
> >>
> >>  Reduced testcase
> >>
> >> struct B {
> >>   virtual void Run(){};
> >> };
> >>
> >> struct D : public B {
> >>   virtual void Run() { };
> >> };
> >>
> >> int main() {
> >>   D d;
> >>   static_cast(d).Run();
> >> }
> >>
> >> With x86_64 linux the call to Run through object d is devirtualized.
> >> Whereas it looks like in ia64 hp-ux it is not devirtualized.
> >>
> >> -fdump-tree-fre1 output for both:
> >>
> >>  x86_64 linux:
> >>
> >>   MEM[(struct B *)&d]._vptr.B = &MEM[(void *)&_ZTV1B + 16B];
> >>   d.D.2197._vptr.B = &MEM[(void *)&_ZTV1D + 16B];
> >>   D.2248_1 = &MEM[(void *)&_ZTV1D + 16B];
> >>   D.2249_2 = Run;
> >>   D::Run (&d.D.2197);
> >>   d ={v} {CLOBBER};
> >>   return 0;
> >>
> >>  ia64 hp-ux:
> >>
> >>   MEM[(struct B *)&d]._vptr.B = &MEM[(void *)&_ZTV1B + 16B];
> >>   d.D.1878._vptr.B = &MEM[(void *)&_ZTV1D + 16B];
> >>   D.1929_1 = &MEM[(void *)&_ZTV1D + 16B];
> >>   D.1930_2 = (int (*__vtbl_ptr_type) ()) &MEM[(void *)&_ZTV1D + 16B];
> >>   OBJ_TYPE_REF(D.1930_2;&d.D.1878->0) (&d.D.1878);
> >>
> >> Is it a bug (unexpected with O1 compilation) that it is not optimized to 
> >> direct call?
> >
> >
> > There are two important and related differences.  The first one is
> > that virtual method tables on ia64 constist of FDESC_EXPRs rather than
> > mere ADDR_EXPRs.  The second one can be seen in the dumps just before
> > fre1 (i.e. esra):
> >
> > i686:
> >   d.D.1854._vptr.B = &MEM[(void *)&_ZTV1D + 8B];
> >   D.1961_4 = d.D.1854._vptr.B;
> >   D.1962_5 = *D.1961_4;
> >   OBJ_TYPE_REF(D.1962_5;&d.D.1854->0) (&d.D.1854);
> >
> > ia64:
> >   d.D.1883._vptr.B = &MEM[(void *)&_ZTV1D + 16B];
> >   D.1991_4 = d.D.1883._vptr.B;
> >   D.1992_5 = (int (*__vtbl_ptr_type) ()) D.1991_4;
> >   OBJ_TYPE_REF(D.1992_5;&d.D.1883->0) (&d.D.1883);
> >
> > The main difference is not the type cast in the third assignment but
> > the fact that there is no dereference there, which means that gimple
> > folder has to deal with it at a different place.
> >
> > I played with it a bit this afternoon and came up with the following
> > untested patch to fix the pr45605.C testcase.  I can bootstrap and
> > test it on ia64 if we do not mind this special casing of FDESC_EXPRs
> > in the midle end (I hope that all platforms that use it use it in the
> > same way, I only know ia64...)
> >
> > Thanks,
> >
> > Martin
> >
> >
> > 2012-08-06  Martin Jambor  
> >
> > * gimple-fold.c (gimple_fold_stmt_to_constant_1): Also fold
> > assignments of V_C_Es of addresses of FDESC_EXPRs.
> >
> >
> > *** gcc/gimple-fold.c   Mon Aug  6 14:36:37 2012
> > --- /tmp/FcpIKb_gimple-fold.c   Mon Aug  6 20:17:26 2012
> > *** gimple_fold_stmt_to_constant_1 (gimple s
> > *** 2542,2548 
> >  == TYPE_ADDR_SPACE (TREE_TYPE (op0))
> >   && TYPE_MODE (TREE_TYPE (lhs))
> >  == TYPE_MODE (TREE_TYPE (op0)))
> > !   return op0;
> >
> > return
> > fold_unary_ignore_overflow_loc (loc, subcode,
> > --- 2542,2556 
> >  == TYPE_ADDR_SPACE (TREE_TYPE (op0))
> >   && TYPE_MODE (TREE_TYPE (lhs))
> >  == TYPE_MODE (TREE_TYPE (op0)))
> > !   {
> > ! tree t;
> > ! if (TREE_CODE (op0) != ADDR_EXPR)
> > !   return op0;
> > ! t = fold_const_aggregate_ref_1 (TREE_OPERAND (op0, 0), 
> > valueize);
> > ! if (t && TREE_CODE (t) == FDESC_EXPR)
> > !   return build_fold_addr_expr_loc (loc, TREE_OPERAND (t, 
> > 0));
> 
> FDESC_EXPR has two operands ... is it really ok to ignore the 2nd?
> 
> /* Operand0 is a function constant; result is part N of a function
>descriptor of type ptr_mode.  */
> DEFTREECODE (FDESC_EXPR, "fdesc_expr", tcc_expression, 2)
> 
> I suppose yes, from what I see in the uses in the C++ frontend.  In fact
> _all_ users of FDESC_EXPR seem to ignore the 2nd operand ...!?
> (I would have expected users in machine specific code ...
> 
> Thus,
> 
> Ok!

So I did the testing and unfortunately this only works for the first
virtual function of a class, the sequence calling any other virtual
function has one more statement which adds VMT offset to the
typecasted pointer and after folding we end up calling stuff like
MEM[f1+16B]() instead of f2() in g++.dg/template/ptrmem18.C.

I'll have another look at this when I have a spare while, I think
we'll need to look for these cases from the call statement "upwards."
BTW, an interesting thing about this testcase is that neither on ia64
nor on i686 are the virtual ca

Re: at exit alternative for AIX

[Ian Lance Taylor]

On Tue, Aug 7, 2012 at 5:43 AM, Perry Smith  wrote:
>
> Not sure why this thread died.  I've been looking at the code trying to gain
> the courage to try and implement the changes I suggested but was
> also waiting to hear back from others.

Sorry, I'm not sure what you are waiting to hear.  Sounds like you
have all the information you need, and the next step is to try to
implement it and see what happens.  I'm not an AIX user myself, but we
can try to answer specific questions.  If your question is: "does this
sound like the right approach" my answer is "it seems worth a try."

I guess you did ask whether to open a bug report.  Sure.  You probably
won't get any better answers there, though.

Ian

Re: at exit alternative for AIX

[Perry Smith]

On Aug 7, 2012, at 10:52 AM, Ian Lance Taylor wrote:

> On Tue, Aug 7, 2012 at 5:43 AM, Perry Smith  wrote:
>> 
>> Not sure why this thread died.  I've been looking at the code trying to gain
>> the courage to try and implement the changes I suggested but was
>> also waiting to hear back from others.
> 
> Sorry, I'm not sure what you are waiting to hear.  Sounds like you
> have all the information you need, and the next step is to try to
> implement it and see what happens.  I'm not an AIX user myself, but we
> can try to answer specific questions.  If your question is: "does this
> sound like the right approach" my answer is "it seems worth a try."
> 
> I guess you did ask whether to open a bug report.  Sure.  You probably
> won't get any better answers there, though.

Thanks.  You just provide what I wanted / needed which is a sanity check.

I'll open a bug report and that might get me some help.

I think I've concocted a plan to get __cxa_atexit to work.  I am going to try 
that
first.  That may have utility in other ways.

I'm studying the GCC code at night.  What beautiful code.  I can't understand
most of it but it is so well polished.  Very nice code from what I've seen so 
far.

Is there any documentation about cxa_gaurd and its associated routines?  I
think I gather what all it is doing, etc but a general description would help.

Thank you,
Perry

The Linux binutils 2.23.51.0.1 is released

[H.J. Lu]

This is the beta release of binutils 2.23.51.0.1 for Linux, which is
based on binutils 2012 0806 in CVS on sourceware.org plus various
changes. It is purely for Linux.

All relevant patches in patches have been applied to the source tree.
You can take a look at patches/README to see what have been applied and
in what order they have been applied.

Starting from the 2.21.51.0.3 release, you must remove .ctors/.dtors
section sentinels when building glibc or other C run-time libraries.
Otherwise, you will run into:

http://sourceware.org/bugzilla/show_bug.cgi?id=12343

Starting from the 2.21.51.0.2 release, BFD linker has the working LTO
plugin support. It can be used with GCC 4.5 and above. For GCC 4.5, you
need to configure GCC with --enable-gold to enable LTO plugin support.

Starting from the 2.21.51.0.2 release, binutils fully supports compressed
debug sections.  However, compressed debug section isn't turned on by
default in assembler. I am planning to turn it on for x86 assembler in
the future release, which may lead to the Linux kernel bug messages like

WARNING: lib/ts_kmp.o (.zdebug_aranges): unexpected non-allocatable section.

But the resulting kernel works fine.

Starting from the 2.20.51.0.4 release, no diffs against the previous
release will be provided.

You can enable both gold and bfd ld with --enable-gold=both.  Gold will
be installed as ld.gold and bfd ld will be installed as ld.bfd.  By
default, ld.bfd will be installed as ld.  You can use the configure
option, --enable-gold=both/gold to choose gold as the default linker,
ld.  IA-32 binary and X64_64 binary tar balls are configured with
--enable-gold=both/ld --enable-plugins --enable-threads.

Starting from the 2.18.50.0.4 release, the x86 assembler no longer
accepts

fnstsw %eax

fnstsw stores 16bit into %ax and the upper 16bit of %eax is unchanged.
Please use

fnstsw %ax

Starting from the 2.17.50.0.4 release, the default output section LMA
(load memory address) has changed for allocatable sections from being
equal to VMA (virtual memory address), to keeping the difference between
LMA and VMA the same as the previous output section in the same region.

For

.data.init_task : { *(.data.init_task) }

LMA of .data.init_task section is equal to its VMA with the old linker.
With the new linker, it depends on the previous output section. You
can use

.data.init_task : AT (ADDR(.data.init_task)) { *(.data.init_task) }

to ensure that LMA of .data.init_task section is always equal to its
VMA. The linker script in the older 2.6 x86-64 kernel depends on the
old behavior.  You can add AT (ADDR(section)) to force LMA of
.data.init_task section equal to its VMA. It will work with both old
and new linkers. The x86-64 kernel linker script in kernel 2.6.13 and
above is OK.

The new x86_64 assembler no longer accepts

monitor %eax,%ecx,%edx

You should use

monitor %rax,%ecx,%edx

or
monitor

which works with both old and new x86_64 assemblers. They should
generate the same opcode.

The new i386/x86_64 assemblers no longer accept instructions for moving
between a segment register and a 32bit memory location, i.e.,

movl (%eax),%ds
movl %ds,(%eax)

To generate instructions for moving between a segment register and a
16bit memory location without the 16bit operand size prefix, 0x66,

mov (%eax),%ds
mov %ds,(%eax)

should be used. It will work with both new and old assemblers. The
assembler starting from 2.16.90.0.1 will also support

movw (%eax),%ds
movw %ds,(%eax)

without the 0x66 prefix. Patches for 2.4 and 2.6 Linux kernels are
available at

http://www.kernel.org/pub/linux/devel/binutils/linux-2.4-seg-4.patch
http://www.kernel.org/pub/linux/devel/binutils/linux-2.6-seg-5.patch

The ia64 assembler is now defaulted to tune for Itanium 2 processors.
To build a kernel for Itanium 1 processors, you will need to add

ifeq ($(CONFIG_ITANIUM),y)
CFLAGS += -Wa,-mtune=itanium1
AFLAGS += -Wa,-mtune=itanium1
endif

to arch/ia64/Makefile in your kernel source tree.

Please report any bugs related to binutils 2.23.51.0.1 to
hjl.to...@gmail.com

and

http://www.sourceware.org/bugzilla/

Changes from binutils 2.22.52.0.4:

1. Update from binutils 2012 0806.
2. Add Intel ADX, RDSEED and PRFCHW new instruction support.
3. Support 'rep bsf', 'rep bsr', and 'rep ret' syntax in x86 assembler.
4. Mark 256-bit vmovntdqa as AVX2 instruction for x86 assembler.
5. Improve x86 assembler error handling.
6. Improve the repeat directive support in assembler.  PR 14201.
7. Improve x86-64 disassembler on superfluous prefixes.
8. Fix x86 disassembler crash on bad XOP instructions.  PR 14355.
9. Support STB_SECONDARY:

https://groups.google.com/forum/?hl=en&fromgroups#!forum/generic-abi

10. Added SORT_NONE to the linker script language to disable section
sorting and properly handle .init/.fini sections.  PR 14156.
11. Fix a weak alias linker bug.  PR 14323.
12. Fix the NULL GNU_REL

Re: at exit alternative for AIX

[Jonathan Wakely]

On 07/08/2012, Perry Smith wrote:
>
> Is there any documentation about cxa_gaurd and its associated routines?  I
> think I gather what all it is doing, etc but a general description would
> help.

The __cxa_guard stuff is part of the Itanium C++ ABI, see
http://refspecs.linuxfoundation.org/cxxabi-1.83.html#once-ctor (or a
slightly newer version at http://www.swag.uwaterloo.ca/asx/ABI.html)

Neither of those is the official version of the doc, but Codesourcery
seem to have moved the page and broken old links to it, and search
engines haven't caught up yet.

Re: at exit alternative for AIX

[Ian Lance Taylor]

On Tue, Aug 7, 2012 at 1:36 PM, Jonathan Wakely  wrote:
>
> The __cxa_guard stuff is part of the Itanium C++ ABI, see
> http://refspecs.linuxfoundation.org/cxxabi-1.83.html#once-ctor (or a
> slightly newer version at http://www.swag.uwaterloo.ca/asx/ABI.html)
>
> Neither of those is the official version of the doc, but Codesourcery
> seem to have moved the page and broken old links to it, and search
> engines haven't caught up yet.

The official link at http://codesourcery.com/cxx-abi/ (note trailing
slash) still works.

Ian

POINTER_PLUS_EXPR Vs. PLUS_EXPR

[a b]

I hit a problem about the 2 operands of a addr-plus instruction. My instruction 
is special because it is not commutative and requries address be the 2nd 
operand and the offset in the 3rd one. But my port generates PLUS_EXPR instead 
of POINTER_PLUS_EXPR and finally mistakenly switches the order of the address 
and offset.
The relevant code is in fold-const.c:
10281   switch (code)
10282 {
10283 case POINTER_PLUS_EXPR:

10292   /* INT +p INT -> (PTR)(INT + INT).  Stripping types allows for 
this. */
10293   if (INTEGRAL_TYPE_P (TREE_TYPE (arg1))
10294&& INTEGRAL_TYPE_P (TREE_TYPE (arg0)))
10295 return fold_convert_loc (loc, type,
10296  fold_build2_loc (loc, PLUS_EXPR, 
uintptrtype,
10297   fold_convert_loc (loc, 
uintptrtype,
10298 arg1),
10299   fold_convert_loc (loc, 
uintptrtype,
10300 arg0)));

the code seems to force gcc to generate a PLUS_EXPR instead of 
POINTER_PLUS_EXPR and I am not clear what is the context for the piece of code. 
The code was checked in by Andrew in 2007 
(http://gcc.gnu.org/ml/fortran/2007-06/msg00163.html)
Could anybody kindly explain me what was going on with that piece of code?
or more specifically:
1. what does INT +p INT mean? shouldn't POINTER_PLUS_EXPR always better than 
PLUS_EXPR? why change to PLUS_EXPR?
2. In general, when we should use POINTER_PLUS_EXPR and PLUS_EXPR. I understand 
the good of POINTER_PLUS_EXPR in my case. but it seems that it is not strictly 
enforced that address+offset should always represented by POINTER_PLUS_EXPR . 
Then can anybody tell me what the rule that a POINTER_PLUS_EXPR should be or 
happens to be used?

Another irlevant question is where I can find the regression test result of the 
gcc releases such as 4.5/4.7? I try to find out which dejagnu tests have 
known-failures. 

thanks

libgfortran.so and libgfortra.a statically link program

[benzhi cao]

Hi,
recently I use the gcc 4.4 to  compile  fortran programs.and then
I use ld to link these programs .But the ELF I get is a dynamic link
file.However I want to link these files statically for the reason that
I want the VirtAdd of LOAD to be determined in an ELF,so I use the
-Bstatic -lgfortran. But some problems occurs,and it means that some
libraries cannot be found.So I see the files in the gcc directory. I
find there is a libgfortran.a and libgfortran.so as well.And I know
the former is a static library and the latter is a shared library.But
what is the difference between them and how can I just use the
libgfortran.a to link the fortran programs.
The  follows is the errors when i use the -Bstatic -lgfortran:
/usr/lib/gcc/x86_64-linux-gnu/4.4//libgfortran.a(compile_options.o):
In function `_gfortran_set_options':
(.text+0x165): undefined reference to `signal'
/usr/lib/gcc/x86_64-linux-gnu/4.4//libgfortran.a(compile_options.o):
In function `_gfortran_set_options':
(.text+0x174): undefined reference to `signal'
/usr/lib/gcc/x86_64-linux-gnu/4.4//libgfortran.a(compile_options.o):
In function `_gfortran_set_options':
(.text+0x183): undefined reference to `signal'
/usr/lib/gcc/x86_64-linux-gnu/4.4//libgfortran.a(compile_options.o):
In function `_gfortran_set_options':
 So I am wondering what is the difference between libgfortran.so
and libgortran.a except that the former is a dynamic library and the
latter is a static library,does libgfortran.so contains any functions
that libgfortran.a don't include? I am a newer ,and thanks for your
help in advance~
Hope anyone can help me ,thankyou so much~
Best~

The Extension to ELF

[Fumiaki Isoya]

I'd just sent mail to r...@gnu.org and he replied.

> I know nothing abnout ELF format, and I have not worked on GCC since
> 1991.  Thus, I simply am not in a position to judge the merits of your
> suggestion.  How about writing to g...@gnu.org, which is the discussion
> list for GCC?

My original message is below.  I'd like to hear your opinion.

> Hello.
>
> This is the 3rd time to send email in this topic.  My first
> purpose in 1994 was to make a simple and lightweight OO language
> which can run on 32bit native DOS.  I planned the implementation
> of C structure which has the first variable of a pointer to its
> class.  And I considered about the class which contains a pointer
> table for instance methods.
>
> 
> class Object {
> int a, b;   /* instance variable */
> void do0 ();/* instance method */
> void do1 ();
> void do2 ();
> void do3 ();
> void do4 ();
> };
>
> Object obj;
>
> 
> [MEMORY IMAGE]
>
> Object
> +---+
> | Ptr super |
> | Ptr do0   |
> | Ptr do1   |
> | Ptr do2   |
> | Ptr do3   |
> | Ptr do4   |
> +---+
>
> obj
> +---+
> | Ptr class |---> Object
> | int a |
> | int b |
> +---+
>
> 
> class Point extends Object {
> int x, y, z;/* instance variable */
> void do2 ();/* instance method (override) */
> void do5 ();/* instance method */
> void do6 ();/* instance method */
> };
>
> Point  pt;
>
> 
> [MEMORY IMAGE]
>
> Point
> ++
> | Ptr super  |---> Object
> | Ptr do0|
> | Ptr do1|
> | Ptr do2|
> | Ptr do3|
> | Ptr do4|
> | Ptr do5|
> | Ptr do6|
> ++
>
> pt
> +---+
> | Ptr class |---> Point
> | int a |
> | int b |
> | int x |
> | int y |
> | int z |
> +---+
>
> 
>
> Even with this simple plan, trying to implement was very difficult
> because I was going to keep the principle "What is necessary is to
> re-compile only the source files you touched".
>
> Consider the class, for example, which has 5 instance methods.
> The derived class adds 2 methods and overrides 1 method.  The
> object files are separate into two.  The symbols of indices (in
> asm file) will be something like the below.
>
> Object_super.define 0
> Object_do0  .define 4
> Object_do1  .define 8
> Object_do2  .define 12
> Object_do3  .define 16
> Object_do4  .define 20
> Object_MMAX .define 24  /* Method MAX */
>
> Object_class.define 0
> Object_a.define 4
> Object_b.define 8
> Object_VMAX .define 12  /* Variable MAX */
>
>
> Point_super .define Object_super
> Point_do0   .define Object_do0
> Point_do1   .define Object_do1
> Point_do2   .define Object_do2
> Point_do3   .define Object_do3
> Point_do4   .define Object_do4
> Point_do5   .define Object_MMAX .+ 0
> Point_do6   .define Object_MMAX .+ 4
> Point_MMAX  .define Object MMAX .+ 8
>
> Point_a .define Object_a
> Point_b .define Object_b
> Point_x .define Object_VMAX .+ 0
> Point_y .define Object_VMAX .+ 4
> Point_z .define Object_VMAX .+ 8
> Point_VMAX  .define Object_VMAX .+ 12
>
>
> The object file of the derived class doesn't know the length of
> the method table of the super class, nor the index of the method
> to override.  The calculation of constants to generate a suitable
> method table must be ld's job as long as we keep the principle.
> Take care this is not about the method dispatch.  This is about
> the classes as global variables which is generated by ld.  It
> contains a flat pointer table of instance methods.  How do you
> think about this principle?
>
> I suspect we should make decision of solving all symbols by the
> calculation.  That is, all symbols should be solved by the
> calculation of the information that stored in Reverse Polish which
> consists of constants, other symbols, and their arithmetic.  It
> also contains the information of shared libraries possibly.  I
> suppose this decision gives unified implementation of object
> files, static libraries, and shared libraries.  In fact it will be
> the extended ELF.
>
> Please forgive me because I'm not any linker expert.  I don't know
> very much the details of ELF format.  I know m68k asm, but I only
> regards ld as a kind of constant resolver.  I even don't know
> really well about dynamic linking.  But I believe this kind of
> solution will be the best infrastructure (binutils, and the
> mechanism of shared library) fo

Re: libgfortran.so and libgfortra.a statically link program

[Ian Lance Taylor]

On Tue, Aug 7, 2012 at 7:49 PM, benzhi cao  wrote:
> Hi,
> recently I use the gcc 4.4 to  compile  fortran programs.and then
> I use ld to link these programs .

Please never send messages to both gcc@gcc.gnu.org and
gcc-h...@gcc.gnu.org.  This message is appropriate for gcc-help; it is
not appropriate for gcc.  Please continue the discussion on gcc-help.
Thanks.

Ian

Re: The Extension to ELF

[Ian Lance Taylor]

On Tue, Aug 7, 2012 at 10:38 PM, Fumiaki Isoya  wrote:

>> I suspect we should make decision of solving all symbols by the
>> calculation.  That is, all symbols should be solved by the
>> calculation of the information that stored in Reverse Polish which
>> consists of constants, other symbols, and their arithmetic.  It
>> also contains the information of shared libraries possibly.  I
>> suppose this decision gives unified implementation of object
>> files, static libraries, and shared libraries.  In fact it will be
>> the extended ELF.

The details matter.

ELF is designed to permit fast program loading at runtime, and to
permit fast linking.  Changing symbol and relocation values to take
general expressions works against that goal.

> I imagine the goal of this infrastructure
> is to provide seamless linking of OO language's object files, C's
> object files, and Asm's object files.

We can already link all these object files together.

I'm sure it is possible to improve on ELF in various ways.  However,
ELF is pretty good.  I very strongly recommend that you understand how
the format works before you attempt to extend it.

Ian