headers
Alan Ong | 1 Dec 2006 03:35
Picon

Help on compiling with Japanese Text

Hello,
    I am trying to compile my code with hard-coded Japanese Kanji and
full-width katakana string text but the compiler view some of the text
as escape characters.
    An example would be the full-width Katakana "so" = ソ which is
viewed as \201. Is there a compiler option to view Japanese text
correctly? I check the --help options but there are none. Any
suggestions would be very helpful. Thank you.
Permalink | Reply | 0 comments |
headers
Fabian Cenedese | 1 Dec 2006 08:28
Picon

Re: Dwarf in assembler file

At 09:12 30.11.2006 -0800, Ian Lance Taylor wrote:
>Fabian Cenedese <Cenedese <at> indel.ch> writes:
>
>> Why are there three symbols _ZN17_TASK_CLASS_NAME_D{0,1,2}Ev? They're all
>> placed on the same source line .loc 3 120 0, contain exactly the same code. So what
>> is the meaning/difference between these three? I also get two symbols for the constructor,
>> also only differing in the last number.
>
>These are required by the C++ ABI:
>    http://codesourcery.com/cxx-abi/

Thanks for the link, I will have a look at it.

>base object destructor of a class T
>complete object destructor of a class T
>deleting destructor of a class T
>
>The compiler should do a better job of combining them, since they are
>often the same.

This was compiled unoptimized, I'm sure with some -O option it could
optimize them. I can try and see what changes.

Thanks

bye   Fabi
Permalink | Reply | 0 comments |
headers
Rohit Arul Raj | 1 Dec 2006 08:45
Picon

Invoking static library automatically

Hi all,

I have built a static runtime library and i want the linker to access
it automatically without having to pass it explicitly.

Are there any environmental variables available to make this happen?

Regards,
Rohit
Permalink | Reply | 1 comment |
headers
Philippe Combes | 1 Dec 2006 10:15
Picon
Picon

Reference to pointer and cast - is this a bug ?


Hi all,

Here is code that works exactly as I think it should with g++-2.95, but
not with
g++-4.0/4.1

#include <iostream>
using namespace std;

class parent
{
public:
         parent():i(0){}
         parent(int i_):i(i_){}
private:
         int i;
};

class child : public parent
{
public:
         child():parent() {}
         child(int i_):parent(i_){}
};

void trace( const parent* const& p_ptr )
{
         cout << "trace called on a reference tp pointer  <at> "
              << (void*)&p_ptr << ": pointer = " << (void*)p_ptr << endl;
(Continue reading)

Permalink | Reply | 1 comment |
headers
Fabian Cenedese | 1 Dec 2006 11:53
Picon

Re: Comments in assember output

At 12:02 30.11.2006 -0500, Tony Wetmore wrote:
>Artur,
>
>I just tried playing around with this, and it appears the the "-S" flag is interfering.  Perhaps by stopping
the compilation process in that way, it prevents the generation of the "listing file".
>
>I tried compiling your example function as follows:
>
>  gcc -c -g -O3 -Wa,-adhls=func.list func.c
>
>And got the following output (in func.list):
>
>   1                            .file   "func.c"
>   4                            .text
>   5                    Ltext0:
>  28                            .p2align 4,,15
>  32                    .globl _func
>  34                    _func:
>   1:func.c        **** float func( float a, float b )
>   2:func.c        **** {
>  36                    LM1:
>  37 0000 55                    pushl   %ebp
>  38 0001 89E5                  movl    %esp, %ebp
>  40                    LM2:
>  41 0003 D9450C                flds    12(%ebp)
>   3:func.c        ****   return a * b;
>  43                    LM3:
>  44 0006 D84D08                fmuls   8(%ebp)
>   4:func.c        **** }
>  46                    LM4:
(Continue reading)

Permalink | Reply | 5 comments |
headers
Andrew Haley | 1 Dec 2006 12:03
Picon
Favicon

Re: Comments in assember output

Fabian Cenedese writes:
 > At 12:02 30.11.2006 -0500, Tony Wetmore wrote:
 > >Artur,
 > >
 > >I just tried playing around with this, and it appears the the "-S" flag is interfering.  Perhaps by
stopping the compilation process in that way, it prevents the generation of the "listing file".
 > >
 > >I tried compiling your example function as follows:
 > >
 > >  gcc -c -g -O3 -Wa,-adhls=func.list func.c
 > >
 > >And got the following output (in func.list):
 > >
 > >   1                            .file   "func.c"
 > >   4                            .text
 > >   5                    Ltext0:
 > >  28                            .p2align 4,,15
 > >  32                    .globl _func
 > >  34                    _func:
 > >   1:func.c        **** float func( float a, float b )
 > >   2:func.c        **** {
 > >  36                    LM1:
 > >  37 0000 55                    pushl   %ebp
 > >  38 0001 89E5                  movl    %esp, %ebp
 > >  40                    LM2:
 > >  41 0003 D9450C                flds    12(%ebp)
 > >   3:func.c        ****   return a * b;
 > >  43                    LM3:
 > >  44 0006 D84D08                fmuls   8(%ebp)
 > >   4:func.c        **** }
(Continue reading)

Permalink | Reply | 4 comments |
headers
Fabian Cenedese | 1 Dec 2006 12:15
Picon

Re: Comments in assember output


> > >   1:func.c        **** float func( float a, float b )
> > >   2:func.c        **** {
> > >  36                    LM1:
> > >  37 0000 55                    pushl   %ebp
> > >  38 0001 89E5                  movl    %esp, %ebp
> > >  40                    LM2:
> > >  41 0003 D9450C                flds    12(%ebp)
> > >
> > >This appears to be the sort of output you are looking for, right?
> > 
> > That sounds usefull, I could use that as well. But when I tried it
> > it didn't mix the lines, I just got (almost) all lines from the cpp
> > source file and after that the assembler code. There are several
> > functions in the cpp file, so at least those should be separatable
> > in the assembler code. I compiled without optimization so the
> > functions should not be intermingled. I tried the various -a flags
> > but it didn't work so far.
>
>That's the way that gcc works.  The optimizers rearrange the functions
>and output them in dependency order.  "-fno-unit-at-a-time" might
>help.

Even if I don't use optimization? But it didn't help either, still big
blocks of code. With -fverbose-asm I see the switch on and off,
but the rest of the output is exactly the same.

bye   Fabi
(Continue reading)

Permalink | Reply | 3 comments |
headers
Andrew Haley | 1 Dec 2006 12:22
Picon
Favicon

Re: Comments in assember output

Fabian Cenedese writes:
 > 
 > > > >   1:func.c        **** float func( float a, float b )
 > > > >   2:func.c        **** {
 > > > >  36                    LM1:
 > > > >  37 0000 55                    pushl   %ebp
 > > > >  38 0001 89E5                  movl    %esp, %ebp
 > > > >  40                    LM2:
 > > > >  41 0003 D9450C                flds    12(%ebp)
 > > > >
 > > > >This appears to be the sort of output you are looking for, right?
 > > > 
 > > > That sounds usefull, I could use that as well. But when I tried it
 > > > it didn't mix the lines, I just got (almost) all lines from the cpp
 > > > source file and after that the assembler code. There are several
 > > > functions in the cpp file, so at least those should be separatable
 > > > in the assembler code. I compiled without optimization so the
 > > > functions should not be intermingled. I tried the various -a flags
 > > > but it didn't work so far.
 > >
 > >That's the way that gcc works.  The optimizers rearrange the functions
 > >and output them in dependency order.  "-fno-unit-at-a-time" might
 > >help.
 > 
 > Even if I don't use optimization?

Yes, we always output stuff in dep order.

 > But it didn't help either, still big blocks of code. With
 > -fverbose-asm I see the switch on and off, but the rest of the
(Continue reading)

Permalink | Reply | 2 comments |
headers
Fabian Cenedese | 1 Dec 2006 13:20
Picon

Re: Comments in assember output


> > >That's the way that gcc works.  The optimizers rearrange the functions
> > >and output them in dependency order.  "-fno-unit-at-a-time" might
> > >help.
> > 
> > Even if I don't use optimization?
>
>Yes, we always output stuff in dep order.
>
> > But it didn't help either, still big blocks of code. With
> > -fverbose-asm I see the switch on and off, but the rest of the
> > output is exactly the same.
>
>Don't know why this is.

I think it's because of some static initializing code. Here's a snippet
(Last code line in cpp is on 161):

 159:N:/Indel-PPC/Tests/gccext3/applicat/src/CTaskTemplateClass.cpp **** 
 160:N:/Indel-PPC/Tests/gccext3/applicat/src/CTaskTemplateClass.cpp ****        // end _TASK_CLASS_NAME_::Action
 161:N:/Indel-PPC/Tests/gccext3/applicat/src/CTaskTemplateClass.cpp **** }
 153                            .loc 3 161 0
 154 0000 9421FFD8              stwu 1,-40(1)    #,,
 155                    .LCFI8:
 156 0004 7C0802A6              mflr 0   #,
 157                    .LCFI9:
 158 0008 93E10024              stw 31,36(1)     #,
 159                    .LCFI10:
 160 000c 9001002C              stw 0,44(1)      #,
 161                    .LCFI11:
(Continue reading)

Permalink | Reply | 0 comments |
headers
John Love-Jensen | 1 Dec 2006 13:46
Picon
Favicon

Re: Reference to pointer and cast - is this a bug ?

Hi Philippe,

> If this is a bug, I did not find it in the bug database.
> If not, can anybody tell me why ?

Not a bug.

A child is a parent.

A child pointer, itself, is a type.
A parent pointer, itself, is a type.

A child pointer is not a parent pointer.

Put ten more trace(c_ptr_r); in your source.  Notice that each one has a
different address.  Anonymous variables are being created - anonymous
variables that have a different type.

Take out the const part of the const& to trace, and you'll notice that the
compiler indicates that is an error - because a child pointer is not a
parent pointer.

Since you used a const&, the child pointer will be treated as if it is a
parent pointer (via the magic of the anonymous variable introduced and
implicit conversion).

The trace statement is printing the address of the anonymous variable, which
is why it differs.

May have something to do with the scaffolding for the SSA optimization, even
(Continue reading)

Permalink | Reply | 0 comments |

Gmane