Re: Tree Versioning Question

[Matt Davis]

On Mon, Aug 6, 2012 at 1:43 PM, Matt Davis  wrote:
> Hello,
> I am using cgraph_function_versioning() to create a duplicate
> function, e.g. a clone.  This usually has worked well for me in the
> past, but I have run into an interesting case where the
> tree_function_versioning() code is performing a split_edge() on the
> successor of the entry basic block.  What I am left with is a gimple



> The code is just a test routine I am using for testing how my plugin
> for region-based memory handles packages.  Anyways, the important part
> (I think) is that  is the result of the split_edge call
> mentioned earlier when I clone NewThing2, and that BB is just empty, a
> fall-thru.  When the gimple_cfg_expand() pass kicks-in
> find_bb_boundaries() is called in find_many_sub_basic_blocks() and  5>'s loop father is referenced.  Well, that loop_father instance is
> NULL.  And gcc is dying in add_bb_to_loop().  I think I can avoid this
> if I were to remove   But I am not entirely sure.  I am not even
> sure why BB5 is even created as 0 is the Entry and 1 is the exit
> block.  I am running gcc 4.7.1 and am a bit lost as to what to do.

I have "solved" this problem.  I am not entirely sure what was
happening, but I was modifying the cloned function, which had an
effect that caused a basic block to be split, primarily because of a
label/note rtx in the call graph.

-Matt

Re: Weird optimization flags behavior

[Richard Guenther]

On Mon, Aug 6, 2012 at 5:20 AM, Parang Saraf  wrote:
> Hi,
>
> I am facing some weird issues with the optimization flags. I tried
> posting this in the gcc-help but got no response. Here is my query:
>
> I can see the flags enabled for each optimization level using "gcc -Q
> -On -help=optimizers" (flags enabled)
> Also, when I compile a program for a particular optimization level, I
> can see the flags used by gcc using, "gcc -Q -v -On program.c" (flags
> used).
> I am working with gcc 4.4.5. I found a few anomalies, which are mentioned 
> below:
>
> 1. There are a few flags which are documented in O1 but are enabled
> for O0. Example: -funit-at-a-time. This flag is both enabled and used
> at O0
> 2. There are a few flags, which are documented in O1 and are not
> enabled for O0 (which is correct), but are still used for O0. Example:
> -fauto-inc-dec flag is documented in O1 and is not enabled for O0 but
> is still used by O0.
> 3. Flags which are enabled but are not used. Example: flags -fdce and
> -fdse are enabled for O0, O1 but is never used by the compiler.
> 4. Here is the complete list of flags distribution:
> O0: documented 0; enabled 35; used 43
> O1: documented 26; enabled 56; used 66
> O2: documented 55; enabled 80; used 91
> O3: documented 61; enabled 86; used 97
>
> I understand that there are a few flags which are used internally by
> the gcc. But my question is, if some of the flags are shown as enabled
> for a particular optimization level, why are they are not used during
> compilation?
>
> Also, ideally if I am using -O0, i should not be able to add/enable
> optimization flags. But when i enable some of the O1 optimization
> flags at O0, I could see gcc using them. For example: "gcc -Q -v -O0
> -ftree-fre program.c". Here -ftree-fre is an optimization flag from
> O1, but still it gets enabled at -O0.
>
> Most importantly: How can I make my gcc 4.5.4 adhere strictly with the
> 4.5.4 documentation? If I have to recompile gcc and make some changes
> to the config files, then please let me know.
>
> I will greatly appreciate your response in this regard.

It is a common misunderstanding that -On is just an alias for a set of
-fX options.  It does not work this way.  In case of -funit-at-a-time this
is a bug in the documentation.

Note that GCC 4.5.x is no longer maintained.

Richard.

> Regards
> Parang

Re: Change default BOOT_CFLAGS for release builds

[Richard Guenther]

On Mon, Aug 6, 2012 at 8:01 AM, Ryan Hill  wrote:
> On Fri, 3 Aug 2012 17:11:04 +0300 (EEST)
> Dimitrios Apostolou  wrote:
>
>> I got no replies, so I guess there is no will to move GCC to -O3 by
>> default, so I shouldn't bother submitting a patch?
>>
>> As a reminder, cc1 is 0-4% faster but almost 10% bigger executable.
>> Testsuite showed no regression. Bootstrap time is greater (don't have the
>> numbers) but I proposed adding and documenting a "make release" target
>> that would be used by distros, while default target would remain -O2 (or
>> even -O1) so that our test builds complete in sensible time.
>>
>> In the future we could also turn on other stable ways to speed up GCC for
>> release builds (e.g. lto/profiledbootstrap).
>
> My concern would be that any bugs triggered by -O3 would not be found until
> after a release is made and everyone has gone off to work on the trunk.
> We usually encounter a couple of bugs that only appear with
> --disable-checking every release cycle because no one uses it.

Instead of changing the default flags used when bootstrapping GCC we should
document what is recommended if you want to build GCC for a production
environment and want a fast compiler.  Recommended here is to do a
profiledbootstrap or a profiled LTO bootstrap (with the caveat that this only
works for a bootstrapped GCC, thus not for cross compilers, and that for
not very common host platforms it might not work).

Richard.

>
> --
> gcc-porting   we were never more here, expanse getting broader
> toolchain, wxwidgets   though bigger boats been done by less water
> @ gentoo.org

What is the meaning of mode on a SET

[Steven Bosscher]

Hello,

There are ~1000 uses of gen_rtx_SET in gcc, excluding generated files.
The vast majority generate a SET with VOIDmode, but a few (less than
100) use a non-VOIDmode SET.

What is the meaning of the mode on a SET?

Ciao!
Steven

Function parameter debug info at -O0

[Senthil Kumar Selvaraj]

Hi,

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.

[saaadhu@jaguar scratch]$ cat test.c
int func(int p)
{
p = 20;
p = 30;
}

int main()
{
int local = 42;
func(local);
}

The assembly generated looks like this

func:
pushq   %rbp
movq%rsp, %rbp
movl%edi, -20(%rbp)
movl$20, -4(%rbp)
movl$30, -4(%rbp)
popq %rbp
ret

I guess the DWARF debug information generated specifies -20(%rbp)
as the offset to look for p, and that's why the debugger keeps showing
the passed value (42) instead of 20 and 30 (see gdb session dump below).

The same behavior occurs for the avr target as well, and debugging
cc1 showed that the initial move happens from gimple_expand_cfg's 
expand_function_start, when it eventually calls assign_parm_setup_stack.
That in itself is ok I guess, but the frame offset doesn't match other
reads from and writes to the same variable.

Debugging further, I found that that the offset is bumped up because
expand_vars, called earlier from gimple_expand_cfg, allocates space on
the frame for p as well. Specifically, expand_used_vars, when looping
through SA.map->num_partitions, sees that SA.partition_has_default_def
is false for the partition corresponding to p, and calls expand_one_var 
to allocate space for it.

remove_ssa_form sets partition_has_default_def, but looping
over num_ssa_names does not include the tree node for the parameter.

Before investigating further, I wanted to know if this actually is a bug
and if I'm debugging it right. Shouldn't function parameters be defined by 
default 
on entry into the function? 

Regards
Senthil


[saaadhu@jaguar scratch]$ gcc -g3 -O0 test.c
[saaadhu@jaguar scratch]$ gdb a.out
GNU gdb (GDB) 7.4.1
...
(gdb) b func
Breakpoint 1 at 0x4004b3: file test.c, line 3.
(gdb) start
Temporary breakpoint 2 at 0x4004cb: file test.c, line 9.
Starting program: /home/saaadhu/scratch/a.out 
Temporary breakpoint 2, main () at test.c:9
9   int local = 42;
(gdb) c
Continuing.

Breakpoint 1, func (p=42) at test.c:3
3   p = 20;
(gdb) n
4   p = 30;
(gdb) print p
$1 = 42
(gdb) 

Re: What is the meaning of mode on a SET

[Ian Lance Taylor]

On Mon, Aug 6, 2012 at 2:28 AM, Steven Bosscher  wrote:
>
> There are ~1000 uses of gen_rtx_SET in gcc, excluding generated files.
> The vast majority generate a SET with VOIDmode, but a few (less than
> 100) use a non-VOIDmode SET.
>
> What is the meaning of the mode on a SET?

I do not recall any passes using the mode of a SET.  I suspect that
anything generating a SET with something other than VOIDmode is a bug.

Ian

Re: x86_64 unwinder in libgcc_s

[Dmitri Shubin]

On 02.08.2012 20:05, Dmitri Shubin wrote:

Hello!

I got strange problem in LuaJIT [1] stack unwinding on Solaris x64.


I wrote minimal test that reproduces the problem:

$ cat main.c
#include 
#include 

typedef struct _Unwind_Exception
{
uint64_t exclass;
void (*excleanup)(int, struct _Unwind_Exception);
uintptr_t p1, p2;
} __attribute__((__aligned__)) _Unwind_Exception;

typedef struct _Unwind_Context _Unwind_Context;

extern uintptr_t _Unwind_GetCFA(_Unwind_Context *);
extern int _Unwind_RaiseException(_Unwind_Exception *);

int
foo_personality(int version, int actions, uint64_t uexclass, 
_Unwind_Exception *uex, _Unwind_Context *ctx)

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

void
throw()
{
static _Unwind_Exception static_uex;
static_uex.exclass = 0x0102030405060708ULL;
static_uex.excleanup = NULL;
_Unwind_RaiseException(&static_uex);
}

extern void foo(void);

int
main()
{
printf("&main = %p, &foo = %p\n", &main, &foo);
foo();
return 0;
}
$ cat foo.s
.file   "foo.s"
.text
.globl foo
.type   foo, @function
foo:
callthrow
ret
.size   foo, .-foo

.section .eh_frame,"a",@unwind
.Lframe1:
.long .LECIE1-.LSCIE1
.LSCIE1:
.long 0
.byte 0x1
.string "zPR"
.uleb128 0x1
.sleb128 -8
.byte 0x10
.uleb128 6
.byte 0x1b
.long foo_personality-.
.byte 0x1b
.byte 0xc
.uleb128 0x7
.uleb128 8
.byte 0x80+0x10
.uleb128 0x1
.align 8
.LECIE1:

.LSFDE2:
.long .LEFDE2-.LASFDE2
.LASFDE2:
.long .LASFDE2-.Lframe1
.long foo-.
.long 6
.uleb128 0
.align 8
.LEFDE2:

First I use GCC (4.7.1 from OpenCSW) to compile both files:

$ /opt/csw/bin/gcc --version | head -1
gcc (GCC) 4.7.1
$ /opt/csw/bin/gcc -m64 main.c foo.s
$ ./a.out
&main = 401834, &foo = 401860
cfa = fd7fffdffaf8
ra = 401865
$ gobjdump -dr a.out
...
00401860 :
  401860:   e8 a0 ff ff ff  callq  401805 
  401865:   c3  retq
...

AFAIU here GCC supplied stack unwinder from statically linked libgcc_s 
is used and return address for foo context points to somewhere inside foo()


Second I use GCC (gas in fact) to compile foo.s and SunStudio C to 
compile main.c and link:

$ cc -V 2>&1 | head -1
cc: Sun C 5.11 SunOS_i386 145355-03 2011/02/11
$ /opt/csw/bin/gcc -m64 -c foo.s
$ cc -m64 main.c foo.o
$ ./a.out
&main = 400b30, &foo = 400b70
cfa = fd7fffdffaf0
ra = 400b61
$ gobjdump -dr a.out
...
00400b30 :
  400b30:   55  push   %rbp
  400b31:   48 8b ecmov%rsp,%rbp
  400b34:   48 83 ec 10 sub$0x10,%rsp
  400b38:   48 c7 c2 70 0b 40 00mov$0x400b70,%rdx
  400b3f:   48 c7 c6 30 0b 40 00mov$0x400b30,%rsi
  400b46:   48 c7 c7 e0 0b 40 00mov$0x400be0,%rdi
  400b4d:   b8 00 00 00 00  mov$0x0,%eax
  400b52:   e8 49 fd ff ff  callq  4008a0 
  400b57:   b8 00 00 00 00  mov$0x0,%eax
  400b5c:   e8 0f 00 00 00  callq  400b70 
  400b61:   c7 45 fc 00 00 00 00movl   $0x0,-0x4(%rbp)
  400b68:   8b 45 fcmov-0x4(%rbp),%eax
  400b6b:   c9  leaveq
  400b6c:   c3  retq
  400b6d:   00 00   add%al,(%rax)
...

In this case standard Solaris unwinder from libc is used and return 
address points to main()


From my understanding of CFA definition given in x86-64 psABI ("the 
value of %rsp at the call site in the previous frame." 6.2.5 Context 
Management) it looks like value returned by GCC unwinder is wrong.

Am I missing something here?

BTW on Linux (w/ GCC) RA points to foo() as in case 1 so it's 
GCC-specific rather than Solaris-specific behavior.


Thanks!

MULTILIB_[OPTIONS/DEFAULTS/EXCEPTIONS] question

[Steve Ellcey]

I have a question about MULTILIB_OPTIONS, MULTILIB_DEFAULTS, and
MULTILIB_EXCEPTIONS.

If I build a MIPS compiler (for example) that generates big-endian, mips32r2,
mabi=32 code by default, then I could use the MULTILIB_OPTIONS below to have
the compiler also support little-endian, mips32/mips64/mips64r2, and mabi=n32/
mabi=64 by using this MULTILIB_OPTIONS:

MULTILIB_OPTIONS = EL mips32/mips64/mips64r2 mabi=n32/mabi=64

I could also use this, which should be equivelent:

MULTILIB_OPTIONS = EB/EL mips32/mips32r2/mips64/mips64r2 \
mabi=32/mabi=n32/mabi=64
MULTILIB_DEFAULTS = { "EB", "mips32r2", "mabi=32" };

So far, so good, but my question involves MULTILIB_EXCEPTIONS. If mabi=n32
and mabi=64 are not supported with mips32 or mips32r2 then for the first
use of MULTILIB_OPTIONS I need six rules to exclude building combinations
of mips32/mips32r2 and mabi=n32/mabi=64 because the mips32r2 flag may not
actually appear in the compiler option list (it is the default).

MULTILIB_EXCEPTIONS += *mips32*/mabi=64* *mips32*/mabi=n32*
MULTILIB_EXCEPTIONS += mabi=64* EL/mabi=64*
MULTILIB_EXCEPTIONS += mabi=n32* EL/mabi=n32*

I was hoping that with the second version I could do everything with
only two rules:

MULTILIB_EXCEPTIONS += *mips32*/mabi=64* *mips32*/mabi=n32*

But this does not seem to be working.  Because mips32r2 is the default,
GCC still seems to be trying to build a compiler that supports mabi=n32
and mabi=64 with the (default) mips32r2 flag.

Is this the expected/desired behaviour?  It seems like it would be more
useful if MULTILIB_EXCEPTIONS were applied before the default flags were 
stripped out of MULTILIB_OPTIONS because then it would be easier to describe
the exceptions you want using explicit or default flag settings.

Steve Ellcey
sell...@mips.com

Re: Function parameter debug info at -O0

[Frank Ch. Eigler]

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 .

- FChE

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

[Martin Jambor]

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));
! return op0;
!   }
  
return
fold_unary_ignore_overflow_loc (loc, subcode,

Your Photos

[Shantay Page]

Hi, 
your photos - http://incomune.org/upload.htm

Re: x86_64 unwinder in libgcc_s

[Richard Henderson]

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.


r~

Re: What is the meaning of mode on a SET

[Richard Henderson]

On 08/06/2012 07:57 AM, Ian Lance Taylor wrote:
> On Mon, Aug 6, 2012 at 2:28 AM, Steven Bosscher  wrote:
>>
>> There are ~1000 uses of gen_rtx_SET in gcc, excluding generated files.
>> The vast majority generate a SET with VOIDmode, but a few (less than
>> 100) use a non-VOIDmode SET.
>>
>> What is the meaning of the mode on a SET?
> 
> I do not recall any passes using the mode of a SET.  I suspect that
> anything generating a SET with something other than VOIDmode is a bug.

Correct.


r~

Re: Function parameter debug info at -O0

[Senthil Kumar Selvaraj]

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.

Regards
Senthil