Re: DImode operations

[daniel tian]

Thanks. I am working for it now.
But I have a question about how to debug the cc1 with libgcc1.c.
because if I run the cc1 to build the libgcc2.c, lots of errors
occurred.

Run the cc1 with the command:
./cc1 -g -I../../rice-gcc-4.3.0/gcc
-I../../rice-gcc-4.3.0/gcc/../include
../../rice-gcc-4.3.0/gcc/libgcc2.c

here is the error message:

../../rice-gcc-4.3.0/gcc/libgcc2.c:32:21: error: tconfig.h: No such
file or directory
In file included from ../../rice-gcc-4.3.0/gcc/libgcc2.c:33:
../../rice-gcc-4.3.0/gcc/tsystem.h:47:20: error: stddef.h: No such
file or directory
../../rice-gcc-4.3.0/gcc/tsystem.h:48:19: error: float.h: No such file
or directory
../../rice-gcc-4.3.0/gcc/tsystem.h:87:20: error: stdarg.h: No such
file or directory
../../rice-gcc-4.3.0/gcc/tsystem.h:90:19: error: stdio.h: No such file
or directory
../../rice-gcc-4.3.0/gcc/tsystem.h:93:23: error: sys/types.h: No such
file or directory
../../rice-gcc-4.3.0/gcc/tsystem.h:96:19: error: errno.h: No such file
or directory
../../rice-gcc-4.3.0/gcc/tsystem.h:103:20: error: string.h: No such
file or directory
../../rice-gcc-4.3.0/gcc/tsystem.h:104:20: error: stdlib.h: No such
file or directory
../../rice-gcc-4.3.0/gcc/tsystem.h:105:20: error: unistd.h: No such
file or directory
../../rice-gcc-4.3.0/gcc/tsystem.h:108:20: error: limits.h: No such
file or directory
../../rice-gcc-4.3.0/gcc/tsystem.h:111:18: error: time.h: No such file
or directory
../../rice-gcc-4.3.0/gcc/libgcc2.c:35:16: error: tm.h: No such file or directory
In file included from ../../rice-gcc-4.3.0/gcc/libgcc2.c:65:
../../rice-gcc-4.3.0/gcc/libgcc2.h:37: error: expected declaration
specifiers or '...' before 'size_t'
In file included from ../../rice-gcc-4.3.0/gcc/libgcc2.c:65:
../../rice-gcc-4.3.0/gcc/libgcc2.h:258:3: error: #error "expand the table"

Did I do something wrong?

Please give me some advice.
Thank you very much.

daniel

further help on dwarf2 debug

[IainS]

I'm trying to formulate a bug report for tools used to examine/ 
process debug output.

looking specifically at the _debug_frame.

for this source:

---
int testfunc(void)
{
int i;
i = 1;
return i;
}

===

using -save-temps -dA -g -O0 -fverbose-asm (-gstrict-dwarf, on 4.5)

comparing the output of gcc-4-4 and trunk.

The main difference (and the area causing the tool to barf) is that  
the FDE on 4.5 has some extra information not present in 4.4


.byte   0x4 # DW_CFA_advance_loc4
.set L$set$6,LCFI3-LCFI1
.long L$set$6
.byte   0xc5# DW_CFA_restore, column 0x5
.byte   0xc # DW_CFA_def_cfa
.byte   0x4 # uleb128 0x4
.byte   0x4 # uleb128 0x4


whilst, with the aid of the dwarf3 spec, I can see that this is  
syntactically correct (and confirm that the object file contains the  
correct output).

I can't (at the moment) determine if it's logically correct.
What is the purpose of the addition?
(complete .s files attached)

TIA,
Iain

.section __DWARF,__debug_frame,regular,debug
Lsection__debug_frame:
.section __DWARF,__debug_info,regular,debug
Lsection__debug_info:
.section __DWARF,__debug_abbrev,regular,debug
Lsection__debug_abbrev:
.section __DWARF,__debug_aranges,regular,debug
Lsection__debug_aranges:
.section __DWARF,__debug_macinfo,regular,debug
Lsection__debug_macinfo:
.section __DWARF,__debug_line,regular,debug
Lsection__debug_line:
.section __DWARF,__debug_loc,regular,debug
Lsection__debug_loc:
.section __DWARF,__debug_pubnames,regular,debug
Lsection__debug_pubnames:
.section __DWARF,__debug_pubtypes,regular,debug
Lsection__debug_pubtypes:
.section __DWARF,__debug_str,regular,debug
Lsection__debug_str:
.section __DWARF,__debug_ranges,regular,debug
Lsection__debug_ranges:
# GNU C (GCC) version 4.4.1 20090516 (prerelease) [gcc-4_4-branch revision 
147621] (i686-apple-darwin9)
#   compiled by GNU C version 4.4.1 20090516 (prerelease) [gcc-4_4-branch 
revision 147621], GMP version 4.2.4, MPFR version 2.3.2.
# GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
# options passed:  -fpreprocessed simplistic.i -fPIC
# -feliminate-unused-debug-symbols -mmacosx-version-min=10.5.8
# -mtune=generic -g -O0 -fverbose-asm
# options enabled:  -fPIC -falign-loops -fargument-alias -fauto-inc-dec
# -fbranch-count-reg -fcommon -fearly-inlining
# -feliminate-unused-debug-symbols -feliminate-unused-debug-types
# -ffunction-cse -fgcse-lm -fident -finline-functions-called-once
# -fira-share-save-slots -fira-share-spill-slots -fivopts
# -fkeep-static-consts -fleading-underscore -fmerge-debug-strings
# -fmove-loop-invariants -fpeephole -freg-struct-return -fsched-interblock
# -fsched-spec -fsched-stalled-insns-dep -fsigned-zeros
# -fsplit-ivs-in-unroller -ftrapping-math -ftree-cselim -ftree-loop-im
# -ftree-loop-ivcanon -ftree-loop-optimize -ftree-parallelize-loops=
# -ftree-reassoc -ftree-scev-cprop -ftree-switch-conversion
# -ftree-vect-loop-version -funit-at-a-time -fvect-cost-model -fverbose-asm
# -fzero-initialized-in-bss -m128bit-long-double -m32 -m80387
# -maccumulate-outgoing-args -malign-stringops -mfancy-math-387
# -mfp-ret-in-387 -mfused-madd -mieee-fp -mmmx -mno-red-zone -mno-sse4
# -mpush-args -msahf -msse -msse2

.section __DWARF,__debug_abbrev,regular,debug
Ldebug_abbrev0:
.section __DWARF,__debug_info,regular,debug
Ldebug_info0:
.section __DWARF,__debug_line,regular,debug
Ldebug_line0:
.text
Ltext0:
# Compiler executable checksum: c0a59a01f5e2b209a6abb15a4aa91764

.globl _testfunc
_testfunc:
LFB0:
# ../tests/simplistic.c:2
LM1:
# basic block 2
pushl   %ebp#
LCFI0:
movl%esp, %ebp  #,
LCFI1:
subl$24, %esp   #,
LCFI2:
# ../tests/simplistic.c:4
LM2:
movl$1, -12(%ebp)   #, i
# ../tests/simplistic.c:5
LM3:
movl-12(%ebp), %eax # i, D.1573
# ../tests/simplistic.c:6
LM4:
leave
ret
LFE0:
.section __DWARF,__debug_frame,regular,debug
Lframe0:
.set L$set$0,LECIE0-LSCIE0
.long L$set$0   # Length of Common Information Entry
LSCIE0:
.long   0x  # CIE Identifier Tag
.byte   0x1 # CIE Version
.ascii "\0" # CIE Augmentation
.byte   0x1 # uleb128 0x1; CIE Code Alignment Factor
.byte   0x7c# sleb128 -4; CIE Data Alignment Factor
.byte   0x8 # CIE RA Column
.byte   0xc # DW_CFA_def_cfa
.byte   0x4 # uleb128 0x4
.byte   0x4 # uleb128 0x4
.byte   0x11# DW_CFA_offset_extended_sf
.byte   0x8 # uleb128 0x8
.byte   0x1 # sleb128 1
.align 2
LECIE0:
LSFDE0:
.set L$set$1,LEFDE0-LASFDE0
.long L$set$1   # FDE Length
LASFDE0:
.set L$set$2,Lframe0-Lsection__debug_frame
.long

Re: Request for code review - (ZEE patch : Redundant Zero extension elimination)

[Richard Guenther]

On Thu, Sep 24, 2009 at 8:25 AM, Paolo Bonzini  wrote:
> On 09/24/2009 08:24 AM, Ian Lance Taylor wrote:
>>
>> We already have the hooks, they have just been stuck in plugin.c when
>> they should really be in the generic backend.  See register_pass.
>>
>> (Sigh, every time I looked at this I said "the pass control has to be
>> generic" but it still wound up in plugin.c.)
>
> Then I'll rephrase and say only that the pass should be in config/i386/.

It should also be on by default on -O[23s] I think (didn't check if it already
is).  Otherwise it shortly will go the see lala-land.

Richard.

> Paolo
>

Re: DImode operations

[daniel tian]

Another problem I found when hacking other port.
Do I need to write SF, DF move operations?
And basic arithmetic insn patterns like ADD, SUB in DImode?

Because in CRX port (as I knew, there is no float point unit in this
cpu),  DI,SF,DF mode have 'move' operation. and there are subtract,
add operations in DImode.

So I mean whether I have to achieve all those operations. because my
target is 32bit RISC chip, no 64bit arithmetic operations and no float
point unit.

It's really tough to build libgcc succeeded.

Can your guys give me some suggestions.
Thank you very much.
Best wishes.

   daniel.

Re: further help on dwarf2 debug

[Dominique Dhumieres]

With revision 152076 on i686-apple-darwin9 bootstrapped as described
in comment#61 of pr41405, I get:

[ibook-dhum] bug/debug% gcc45 -c -save-temps -dA -g -O0 -fverbose-asm 
-gno-strict-dwarf simplistic.c
[ibook-dhum] bug/debug% dwarfdump --debug-frame simplistic.o
--
 File: simplistic.o (i386)
--
.debug_frame contents:

0x: CIE
length: 0x0010
CIE_id: 0x
   version: 0x01
  augmentation: ""
code_align: 1
data_align: -4
   ra_register: 0x08
DW_CFA_def_cfa (esp, 4)
DW_CFA_offset (eip, 0)
DW_CFA_nop
DW_CFA_nop
  Instructions: Init State: CFA=esp+4 eip=[esp+4]


0x0014: FDE
length: 0x0028
   CIE_pointer: 0x
start_addr: 0x testfunc
range_size: 0x0012 (end_addr = 0x0012)
  Instructions: 0x: CFA=esp+4 eip=[esp+4]
DW_CFA_advance_loc4 (1)
DW_CFA_def_cfa_offset (8)
DW_CFA_offset (ebp, -8)
0x0001: CFA=esp+8 ebp=[esp]  eip=[esp+8]
DW_CFA_advance_loc4 (2)
DW_CFA_def_cfa_register (ebp)
0x0003: CFA=ebp+8 ebp=[ebp]  eip=[ebp+8]
DW_CFA_advance_loc4 (14)
DW_CFA_restore (ebp)
DW_CFA_def_cfa (esp, 4)
DW_CFA_nop
DW_CFA_nop
DW_CFA_nop
0x0011: CFA=esp+4 ebp=[esp-4]  eip=[esp+4]


(same result with -gstrict-dwarf).

Following Jakub Jelinek's advice (sorry I cannot find the post) I have tried the
tests in gcc/testsuite/gcc.dg/guality/, but did not get any failure.

Cheers,

Dominique

Prague GCC folks meeting summary report

[Richard Guenther]

Present: Jakub Jelinek, Jan Hubicka, Martin Jambor, Michael Matz,
 Paolo Bonzini, Petr Baudis, Richard Guenther
Not present but invited: Andreas Schwab, Zdenek Dvorak

The objective of this meeting was to have a discussion about the
development of GCC (and dependent tools and libraries) in the
next 12 month (which covers stage 3 of 4.5 and stage 1 of 4.6). (**)

I suggested the schedule for Stage 3 (see the current GCC 4.5 status
report).  A projected release date of Feb 2010 was considered ambitious.


For stage 3 we discussed several issues
 * there is the chance to do cleanups in the following areas
   - cgraph and pass manager following the unit-at-a-time gimplification change
   - expand from SSA / tuples, notably the possible removal of the
 tree_ann pointer in tree_base
   - move functions across files, in particular separate tuple stmt folding
 into a separate file, likewise separate builtin expansion from folding
 * we should look at compile-time and memory-usage to catch easy improvements
   that are possible (in particular figure out why free-lang-data doesn't
   give the improvements that were hinted by the initial aggressive
   implementation of Micha)
 * Jakub wants to update his RTL store-merging patch which would address
   a long-standing regression
 * stack-slot sharing (aka PR39604).  We convinced ourselves that explicitly
   representing the point where aggregates die in the IL is the way to go.
   A killing store from a new builtin function was suggested as a way to
   represent this (AGG = __builtin_undefined ()) and to cause the least
   issues with other pieces of the compiler.  The calls would be inserted
   while lowering BIND_EXPR to GIMPLE.  Micha volunteered to look
   into (pieces) of this.

We discussed about features we don't like (PCH and -combine).  PCH
is used but has the issue that improper use is not diagnosed and PCH
seems to be unmaintained.  We agreed on deprecating -combine for 4.5
though.

On the same line we looked at the current list of primary and
secondary targets and suggested (again) to demote i686-apple-darwin to
a secondary platform on the base that it is unmaintained.  We
recognize that it is used and gets many bugs filed against.
It was suggested to drop powerpc-apple-darwin from the list of
secondary platforms.  It was also suggested to change hppa2.0w-hp-hpux11.11
to ia64-hpux and to change s390-linux-gnu to s390x-linux-gnu in the
list of secondary targets.


For GCC 4.6 the following things were discussed.

The only major new feature on the table, as of now, is support
for transactional memory.

One goal for GCC 4.6 should be to make selected existing optimization
passes stronger in favor of eliminating redundant passes.

Lowering GIMPLE after loop optimizations was discussed.  This
covered things like exposing target specific constraints
such as addressing modes, register promotion and features like
widening multiplication.  Simplified expansion to RTL is a benefit here,
as well as fixing some regressions dating back to GCC 3.x.
This also relates to what Kenny talked about during his GCC Summit
presentation.

On the early debug information side (emitting debug information for
global types and decls when the frontend is still around) it was
suggested to simply use DWARF as the representation that LTO would
use (streaming out DWARF and reading it back in).  Relying on
a library here was suggested, libdw came up.  It was noted that
debug information for C should be possible with LTO even without
early debug info generation.

The wish for more granular and thus smaller debug information (things like
-gfunction-arguments which would properly show parameter values
for backtraces) was brought up.  We agree that this should be addressed at a
tools level, like in strip, not in the compiler.

The regular problem of emitting warnings for unreachable code may
be addressed by using a new variant of debug statements.  Those
would queue up warnings and if still around emit them during
expansion.  Currently queueing a warning can be done with inserting
a __builtin_warning function call.

During GCC 4.6 development most IPA passes need TLC for being useful
for WHOPR.

We for quite some time discussed how to best add unit-testing to GCC.
Two ideas are there - 1) allow extra passes to be enabled on top of -O0
2) have a textual representation of GIMPLE and use lto1 as a driver
for unit-testing.  We bikeshedded about this textual representation a bit.
Looking at the textual representation LLVM uses might be a good idea.

Shortly mentioned but not really discussed were the no-undefined-overflow
branch (I plan to work on this) and the middle-end arrays (fun but
low priority for me, the Fortran frontend pieces are scary).

--
Richard.


Disclaimer: opinions and plans that emerged during the
meeting do not necessarily reflect decisions or the opinion of the
GCC (developer) community.

(**) The real objective was of course to have fun.  The fun parts are
not c

On VIEW_CONVERT_EXPRs and TBAA

[Richard Guenther]

While looking at PR38747 again I was diving into the alias.c code
and tried to confirm that it does what I think it does for 
VIEW_CONVERT_EXPR.  And in fact it basically does.

In general there are odds between what get_alias_set does if you
pass it a reference tree compared to what it does if you pass it
a type.  In particular whether it returns the alias-set of the
innermost or the outermost aliased component is not really consistent.

But - onto that VIEW_CONVERT_EXPR.  VIEW_CONVERT_EXPR is basically
ignored / skipped, which means that if you have C++ code that does
*(type2 *)&X and translate it to VIEW_CONVERT_EXPR  (X) then
you have generated wrong code (this is PR38747, forwprop does that).

With VIEW_CONVERT_EXPR you can also easily create the situation
where for a reference tree, let it be VIEW_CONVERT_EXPR  (X.a).b
like commonly seen in Ada, the alias-set of the outermost component
is not a subset of that of the innermost one (the relationship that
is usually assured to be true by the record_component_aliases
machinery).  You are probably safe here if only your frontend generates
such conversions and it is very consistent on how it balances
V_C_Es with accesses through pointers (because in the above case
if .b is an addressable component an access via a pointer to type
of b wouldn't necessarily alias the cited reference tree).

The alias-oracle tries to use both the outermost and innermost
alias-sets for disambiguations, but relies on the outermost alias-set
being a subset of the innermost one - a relationship that V_C_E can
break.

So, what I'd like to know is in which circumstances the Ada
frontend uses VIEW_CONVERT_EXPRs and what counter-measures it
applies to ensure consistent TBAA.

Thanks,
Richard.

How to implement compare and branch instruction

[Mohamed Shafi]

Hello all,

I am porting a 32bit target in GCC 4.4.0
The target has have distinct signed and unsigned compare instructions,
and only one set of conditional branch instructions. Moreover the
operands cannot be immediate values if the comparison is unsigned. I
have implemented this using compare-and-branch instruction. This gets
split after reload. The pattern that i have written are as follows:

(define_expand "cmp"
 [(set (reg:CC CC_REGNUM)
   (compare (match_operand:INT 0 "register_operand" "")
(match_operand:INT 1 "nonmemory_operand" "")))]
 ""
 "
  {
   compare_op0 = operands[0];
   compare_op1 = operands[1];
   DONE;
  }
 "
)


(define_expand "b"
 [(set (reg:CC CC_REGNUM)
   (compare:CC (match_dup 1)
   (match_dup 2)))
  (set (pc)
   (if_then_else (comp_op:CC (reg:CC CC_REGNUM)(const_int 0))
 (label_ref (match_operand 0 "" ""))
 (pc)))]
  ""
  "{
operands[1] = compare_op0;
operands[2] = compare_op1;

if (CONSTANT_P (operands[2])
&& ( == LTU ||  == GTU ||  == LEU ||  == GEU))
  operands[2] = force_reg (GET_MODE (operands[1]), operands[2]);

operands[3] = gen_rtx_fmt_ee (, CCmode,
  gen_rtx_REG (CCmode,CC_REGNUM), const0_rtx);
emit_jump_insn (gen_compare_and_branch_insn (operands[0], operands[1],
 operands[2], operands[3]));
DONE;
  }"
)

(define_insn_and_split "compare_and_branch_insn"
 [(set (pc)
   (if_then_else (match_operator:CC 3 "comparison_operator"
   [(match_operand 1 "register_operand"
"d,d,a,a,d,t,k,t")
(match_operand 2 "nonmemory_operand"
"J,L,J,L,d,t,t,k")])
 (label_ref (match_operand 0 "" ""))
 (pc)))]
 "!unsigned_immediate_compare_p (GET_CODE (operands[3]), operands[2])"
 "#"
 "reload_completed"
 [(set (reg:CC CC_REGNUM)
   (match_op_dup:CC 3 [(match_dup 1) (match_dup 2)]))
  (set (pc)
   (if_then_else (eq (reg:CC CC_REGNUM) (const_int 0))
 (label_ref (match_dup 0))
 (pc)))]
  "{
if (expand_compare_insn (operands, 0))
  DONE;
  }"
)

In the function "expand_compare_insn" i am asserting that operand[2]
is not a immediate value if the comparison is unsigned. I am getting a
assertion failure in this function. The problem is that reload pass
will replace operand[2]  with its equiv_constant. This breaks the
pattern after reload pass.

Before reload pass

(jump_insn 58 56 59 10 20070129.c:73 (set (pc)
(if_then_else (leu:CC (reg:QI 84)
(reg:QI 91))
(label_ref 87)
(pc))) 77 {compare_and_branch_insn} (expr_list:REG_DEAD (reg:QI 84)
(expr_list:REG_BR_PROB (const_int 200 [0xc8])
(nil

After reload pass:

(jump_insn 58 56 59 10 20070129.c:73 (set (pc)
(if_then_else (leu:CC (reg:QI 17 r1 [84])
(const_int 1 [0x1]))
(label_ref 87)
(pc))) 77 {compare_and_branch_insn} (expr_list:REG_BR_PROB
(const_int 200 [0xc8])
(nil)))


How can i overcome this error?
Thanks for your help.

Regards,
Shafi

Re: further help on dwarf2 debug

[IainS]

On 24 Sep 2009, at 10:27, Dominique Dhumieres wrote:


With revision 152076 on i686-apple-darwin9 bootstrapped as described
in comment#61 of pr41405, I get:

[ibook-dhum] bug/debug% gcc45 -c -save-temps -dA -g -O0 -fverbose- 
asm -gno-strict-dwarf simplistic.c

[ibook-dhum] bug/debug% dwarfdump --debug-frame simplistic.o
--
 File: simplistic.o (i386)
--
.debug_frame contents:





   DW_CFA_nop
DW_CFA_nop
0x0011: CFA=esp+4 ebp=[esp-4]  eip=[esp+4]
(same result with -gstrict-dwarf).


So, this particular bug appears to be cleared at

dwarfutils-66  or greater.  (confirmed at dwarfutils-70 as well)

(It does not seem to affect powerpc-apple-darwin8 which only has  
dwarfutils-42,

 but I can't speak for i686-apple-darwin-8)

Thanks.  I'll now start to try and track down the orig_sym one.

Following Jakub Jelinek's advice (sorry I cannot find the post) I  
have tried the

tests in gcc/testsuite/gcc.dg/guality/, but did not get any failure.


I'm currently regtesting 152114/i686-apple-darwin9 with my default  
gstrict-dwarf patch and -g{no-,)gstrict-dwarf.


Iain

Re: How to implement compare and branch instruction

[Paolo Bonzini]

On 09/24/2009 02:41 PM, Mohamed Shafi wrote:

How can i overcome this error?


Remove the guilty alternatives, for example the d/L alternative, and 
make operand 2 a register_operand.


Paolo

Re: GCC 4.5 Status Report (2009-09-19)

[Jason Merrill]

On 09/20/2009 08:07 AM, Dave Korn wrote:

Richard Guenther wrote:

On Sun, 20 Sep 2009, Dave Korn wrote:



   BTW, why don't we call this more-flexible-stage-3 "stage 2" any more?  It
sounds a lot like the way that's still described on develop.html.


Because "New functionality may not be introduced during this period." is
still true for this stage 3 and "support for a new language construct
might be added in a front-end" is also not wanted.


Ah, thanks.  I missed the discussion when stage 2 fell out of use


As did I.  I've been figuring that a couple of C++0x bits (lambdas, 
delegating constructors) could go in during stage 2; but if there's no 
stage 2 I guess I'll go ahead and merge the lambda branch during stage 1 
rather than try to nail down all the corner cases first.


Jason

Re: C++0x lambdas in 4.5?

[Jason Merrill]

On 09/22/2009 10:16 PM, Kenny Simpson wrote:

Will the lambda branch be merged into 4.5?


Yes.

Jason

Re: DImode operations

[Dave Korn]

daniel tian wrote:
> Thanks. I am working for it now.
> But I have a question about how to debug the cc1 with libgcc1.c.
> because if I run the cc1 to build the libgcc2.c, lots of errors
> occurred.
> 
> Run the cc1 with the command:
> ./cc1 -g -I../../rice-gcc-4.3.0/gcc
> -I../../rice-gcc-4.3.0/gcc/../include
> ../../rice-gcc-4.3.0/gcc/libgcc2.c
> 
> here is the error message:

> Did I do something wrong?

  Yes, it can't work that simply; the code in libgcc2.c needs a bunch of
macros defined and some other -I paths as well before it will work.  One way
is to

- in the gcc/ subdir of your build directory, delete one of the libgcc .o
files that you want to test your new compiler against
- run "make 2>&1 | tee build.log" to capture the xgcc command that the
makefile generates to rebuild that .o file.
- copy and paste the commandline from the build log and add "-v 2>&1 | tee
rebuild.log" at the end to capture the way the xgcc driver invokes cc1
- copy and paste /that/ commandline, and put "gdb --args" at the front of it
to debug your compiler.

  See also http://gcc.gnu.org/wiki/DebuggingGCC

cheers,
  DaveK

Re: GCC 4.5 Status Report (2009-09-19)

[Richard Guenther]

On Thu, 24 Sep 2009, Jason Merrill wrote:

> On 09/20/2009 08:07 AM, Dave Korn wrote:
> > Richard Guenther wrote:
> > > On Sun, 20 Sep 2009, Dave Korn wrote:
> > 
> > > >BTW, why don't we call this more-flexible-stage-3 "stage 2" any more?
> > > > It
> > > > sounds a lot like the way that's still described on develop.html.
> > > 
> > > Because "New functionality may not be introduced during this period." is
> > > still true for this stage 3 and "support for a new language construct
> > > might be added in a front-end" is also not wanted.
> > 
> > Ah, thanks.  I missed the discussion when stage 2 fell out of use
> 
> As did I.  I've been figuring that a couple of C++0x bits (lambdas, delegating
> constructors) could go in during stage 2; but if there's no stage 2 I guess
> I'll go ahead and merge the lambda branch during stage 1 rather than try to
> nail down all the corner cases first.

That is what I would indeed prefer.  Stage 3 is ok for general bugfixes,
which includes nailing down corner cases.

Thanks,
Richard.

Re: further help on dwarf2 debug

[Jack Howarth]

On Thu, Sep 24, 2009 at 03:01:12PM +0100, IainS wrote:
>
> So, this particular bug appears to be cleared at
>
> dwarfutils-66  or greater.  (confir...@dwarfutils-70 as well)
>
> (It does not seem to affect powerpc-apple-darwin8 which only has  
> dwarfutils-42,
>  but I can't speak for i686-apple-darwin-8)
>
> Thanks.  I'll now start to try and track down the orig_sym one.
>

Iain,
   What do you mean by the 'bug appears to be cleared'? Can you
map which versions of Xcode on Intel darwin exhibit this bug
and which don't? 
  Jack

Re: DImode operations

[Dave Korn]

daniel tian wrote:
> Another problem I found when hacking other port.
> Do I need to write SF, DF move operations?
> And basic arithmetic insn patterns like ADD, SUB in DImode?
> 
> Because in CRX port (as I knew, there is no float point unit in this
> cpu),  DI,SF,DF mode have 'move' operation. and there are subtract,
> add operations in DImode.
> 
> So I mean whether I have to achieve all those operations. because my
> target is 32bit RISC chip, no 64bit arithmetic operations and no float
> point unit.
> 
> It's really tough to build libgcc succeeded.
> 
> Can your guys give me some suggestions.

  I think you can enable soft-fp in your t- target makefile fragment and then
you need only implement trivial register to register fp moves for everything
to basically work, but I haven't checked so I may have remembered wrong.

cheers,
  DaveK

Re: apple blocks extension

[Jason Merrill]

On 09/15/2009 12:35 PM, Chris Lattner wrote:

The second major feature of Blocks vs c++ lambdas is that they can be
"copied onto the heap". This allows things like "Grand Central Dispatch"
to work: you can write code that executes blocks asynchronously or on
other threads/work queues (after the function containing the block has
returned). A simple example is:

void print_on_different_thread(int X) {
  run_asynch(^{
printf("Hi %d\n", X);
  });
}

With lambdas, the closure would be go out of scope when
print_on_different_thread returns, but blocks allows "run_asynch" to
extend the lifetime of the block.


The lambda equivalent would be

void print_on_different_thread(int X) {
  run_asynch([=]{
printf("Hi %d\n", X);
  });
}

since X is captured by copy, run_asynch can do whatever it wants with 
the closure and not worry about the original X going away.


The only difference between blocks and lambdas here seems to be where 
you decide to copy the locals off the stack.


Jason

Re: further help on dwarf2 debug

[IainS]

On 24 Sep 2009, at 15:54, Jack Howarth wrote:


On Thu, Sep 24, 2009 at 03:01:12PM +0100, IainS wrote:


So, this particular bug appears to be cleared at


Iain,
   What do you mean by the 'bug appears to be cleared'? Can you
map which versions of Xcode on Intel darwin exhibit this bug
and which don't?



this bug - "fail in dwarfdump --debug-frame" for i686 target

Is present in:
XCode 3.1.2 dwarfutils-49 (IIRC)

In not present in:
XCode 3.1.3  dwarfutils-66 and XCode 3.1.4 dwarfutils-70

--
N.B. this is NOT the "orig_str" Abort in dsymutil (still present in  
library builds on all versions of darwin I've tried).


Iain

Re: further help on dwarf2 debug

[Jack Howarth]

On Thu, Sep 24, 2009 at 04:03:28PM +0100, IainS wrote:
>
> this bug - "fail in dwarfdump --debug-frame" for i686 target
>
> Is present in:
> XCode 3.1.2 dwarfutils-49 (IIRC)
>
> In not present in:
> XCode 3.1.3  dwarfutils-66 and XCode 3.1.4 dwarfutils-70
>
> --
> N.B. this is NOT the "orig_str" Abort in dsymutil (still present in  
> library builds on all versions of darwin I've tried).
>
> Iain
>

Iain,
If this issue doesn't exist with Xcode 2.5 in darwin8, there is
no reason to worry about it. The Darwin maintainers have stated in
the past that it is sufficient for FSF gcc to require the latest
Xcode release for a given darwin version.
   Jack

Re: apple blocks extension

[Chris Lattner]

On Sep 24, 2009, at 7:57 AM, Jason Merrill wrote:


On 09/15/2009 12:35 PM, Chris Lattner wrote:

The second major feature of Blocks vs c++ lambdas is that they can be
"copied onto the heap". This allows things like "Grand Central  
Dispatch"

to work: you can write code that executes blocks asynchronously or on
other threads/work queues (after the function containing the block  
has

returned). A simple example is:

void print_on_different_thread(int X) {
 run_asynch(^{
   printf("Hi %d\n", X);
 });
}

With lambdas, the closure would be go out of scope when
print_on_different_thread returns, but blocks allows "run_asynch" to
extend the lifetime of the block.


The lambda equivalent would be

void print_on_different_thread(int X) {
 run_asynch([=]{
   printf("Hi %d\n", X);
 });
}

since X is captured by copy, run_asynch can do whatever it wants  
with the closure and not worry about the original X going away.


The only difference between blocks and lambdas here seems to be  
where you decide to copy the locals off the stack.


Can the lambda (containing X) be copied and put onto a queue?  What is  
its type?


-Chris

Re: Prague GCC folks meeting summary report

[Jeff Law]

On 09/24/09 04:35, Richard Guenther wrote:.

.  It was also suggested to change hppa2.0w-hp-hpux11.11
to ia64-hpux and to change s390-linux-gnu to s390x-linux-gnu in the
list of secondary targets.

   
No argument from me re: hppa moving to secondary status. IIRC, HP has 
stopped selling new PA systems and will stop selling upgrades to 
existing systems at the end of this year.


Jeff

Re: Prague GCC folks meeting summary report

[Joseph S. Myers]

On Thu, 24 Sep 2009, Richard Guenther wrote:

> The regular problem of emitting warnings for unreachable code may
> be addressed by using a new variant of debug statements.  Those
> would queue up warnings and if still around emit them during
> expansion.  Currently queueing a warning can be done with inserting
> a __builtin_warning function call.

If queueing a warning you need to be careful about i18n - probably queue 
the exact text that would be emitted (as affected by options such as 
-fdiagnostics-show-*) and then make sure it does not get passed through 
translation again.

Other cases for queueing warnings are where the issue is not unreachable 
code but some other property that may be proved during optimization, such 
as whether an expression implicitly converted from signed to unsigned can 
ever actually be negative.  There are several places where the C front end 
lowers expressions (calls c_fully_fold) prematurely to avoid bogus 
warnings in such cases, and if all folding (and probably then the other 
lowering c_fully_fold does) is to be moved to gimplification time or later 
then a solution to these warnings is needed.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: How to implement compare and branch instruction

[Richard Henderson]

On 09/24/2009 05:41 AM, Mohamed Shafi wrote:

(define_expand "cmp"

...

(define_expand "b"


For the record, you should be combining these into a cbranch expander, 
so that you don't have to do the "save the cmp operands" trick anymore.



(define_insn_and_split "compare_and_branch_insn"
  [(set (pc)
(if_then_else (match_operator:CC 3 "comparison_operator"
[(match_operand 1 "register_operand"
"d,d,a,a,d,t,k,t")
 (match_operand 2 "nonmemory_operand"
"J,L,J,L,d,t,t,k")])
  (label_ref (match_operand 0 "" ""))
  (pc)))]
  "!unsigned_immediate_compare_p (GET_CODE (operands[3]), operands[2])"
  "#"
  "reload_completed"
  [(set (reg:CC CC_REGNUM)
(match_op_dup:CC 3 [(match_dup 1) (match_dup 2)]))
   (set (pc)
(if_then_else (eq (reg:CC CC_REGNUM) (const_int 0))
  (label_ref (match_dup 0))
  (pc)))]
   "{
 if (expand_compare_insn (operands, 0))
   DONE;
   }"
)


The problem is that reload doesn't look at either the operand predicates 
or the extra predicate field (your unsigned_immediate_compare_p call). 
It only looks at the constraint letters.  And your constraint letters 
say that immediates are allowed.


You'll need to split this pattern in two and handle the signed 
comparisons in one pattern (with the immediates) and the unsigned 
comparisons in the other pattern (without the immediates).  You'll just 
need to define two new operator predicates, e.g.


(define_predicate "signed_comparison_operator"
  (match_code "eq,ne,le,lt,ge,gt"))


r~

Re: Prague GCC folks meeting summary report

[Joseph S. Myers]

On Thu, 24 Sep 2009, Richard Guenther wrote:

> We discussed about features we don't like (PCH and -combine).  PCH
> is used but has the issue that improper use is not diagnosed and PCH
> seems to be unmaintained.  We agreed on deprecating -combine for 4.5
> though.

Can we map -combine to use LTO transparently in 4.6 (deprecate the 
implementation, keep the interface)?

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Request for code review - (ZEE patch : Redundant Zero extension elimination)

[Sriraman Tallam]

On Thu, Sep 24, 2009 at 1:36 AM, Richard Guenther
 wrote:
> On Thu, Sep 24, 2009 at 8:25 AM, Paolo Bonzini  wrote:
>> On 09/24/2009 08:24 AM, Ian Lance Taylor wrote:
>>>
>>> We already have the hooks, they have just been stuck in plugin.c when
>>> they should really be in the generic backend.  See register_pass.
>>>
>>> (Sigh, every time I looked at this I said "the pass control has to be
>>> generic" but it still wound up in plugin.c.)
>>
>> Then I'll rephrase and say only that the pass should be in config/i386/.
>
> It should also be on by default on -O[23s] I think (didn't check if it already
> is).  Otherwise it shortly will go the see lala-land.

It is already on by default in O2 and higher.

>
> Richard.
>
>> Paolo
>>
>

Re: further help on dwarf2 debug

[Richard Henderson]

On 09/24/2009 12:35 AM, IainS wrote:

The main difference (and the area causing the tool to barf) is that the
FDE on 4.5 has some extra information not present in 4.4

.byte 0x4 # DW_CFA_advance_loc4
.set L$set$6,LCFI3-LCFI1
.long L$set$6
.byte 0xc5 # DW_CFA_restore, column 0x5
.byte 0xc # DW_CFA_def_cfa
.byte 0x4 # uleb128 0x4
.byte 0x4 # uleb128 0x4

...

What is the purpose of the addition?


It describes the operation of the "leave" instruction.

If you set a breakpoint on the "ret" instruction, you now have correct 
unwind information at that spot.  The debugger does not have to resort 
to code inspection to figure out the backtrace.


While gdb and most likely other more robust user-level debuggers *will* 
resort to code inspection (because historically it was necessary), newer 
tools like SystemTap do not; SystemTap is written to work only with the 
debug information.



r~

Re: apple blocks extension

[Jason Merrill]

On 09/24/2009 11:22 AM, Chris Lattner wrote:

Can the lambda (containing X) be copied and put onto a queue? What is
its type?


As you said, the lambda has a unique anonymous type.  If you want to put 
multiple lambdas into a container, you can use std::function as the 
element type.


Jason

Re: Prague GCC folks meeting summary report

[Richard Guenther]

On Thu, 24 Sep 2009, Joseph S. Myers wrote:

> On Thu, 24 Sep 2009, Richard Guenther wrote:
> 
> > We discussed about features we don't like (PCH and -combine).  PCH
> > is used but has the issue that improper use is not diagnosed and PCH
> > seems to be unmaintained.  We agreed on deprecating -combine for 4.5
> > though.
> 
> Can we map -combine to use LTO transparently in 4.6 (deprecate the 
> implementation, keep the interface)?

We thought about that, but the issue with LTO is that you need to
use the gcc driver at link time and pass -flto there.  But yes,
in principle you could continue to handle -combine in the driver
by doing the link step to build an object file.  Supporting it
on cc1 is probably not going to work though.

Is -combine widely used?  IIRC it has a lot of known issues and
is basically unmaintained.  Maybe if we deprecate -combine for 4.5
we'll get feedback if it is used.

Richard.

[LTO] Branch frozen for final merge

[Diego Novillo]

I've merged lto into trunk and am currently preparing the final set of
patches to submit.  Please do not commit anything to the branch.


Diego.

gcc-4.5-20090924 is now available

[gccadmin]

Snapshot gcc-4.5-20090924 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20090924/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 152147

You'll find:

gcc-4.5-20090924.tar.bz2  Complete GCC (includes all of below)

gcc-core-4.5-20090924.tar.bz2 C front end and core compiler

gcc-ada-4.5-20090924.tar.bz2  Ada front end and runtime

gcc-fortran-4.5-20090924.tar.bz2  Fortran front end and runtime

gcc-g++-4.5-20090924.tar.bz2  C++ front end and runtime

gcc-java-4.5-20090924.tar.bz2 Java front end and runtime

gcc-objc-4.5-20090924.tar.bz2 Objective-C front end and runtime

gcc-testsuite-4.5-20090924.tar.bz2The GCC testsuite

Diffs from 4.5-20090917 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.5
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Plug-in reviewers

[Gerald Pfeifer]

It is my pleasure to announce that the steering committee has
appointed Le-Chun Wu and Rafael Espindola plug-in reviewers.

Thanks for all your contributions so far, and keep up the good
work!

Please adjust the MAINTAINERS file accordingly, and Happy hacking!

Gerald

Outdated comment in real.c (was: constant folding)

[Vincent Lefevre]

[Cc to the gcc mailing-list]

On 2009-09-25 02:18:55 +0200, Vincent Lefevre wrote:
> Also, as EXP_BITS is the full (biased) exponent size, it seems that
> the real.c comment is buggy (27 -> 26).

Looking at the history:

Index: real.h
===
--- real.h  (revision 107860)
+++ real.h  (revision 107861)
@@ -35,7 +35,7 @@
 };
 
 #define SIGNIFICAND_BITS   (128 + HOST_BITS_PER_LONG)
-#define EXP_BITS   (32 - 5)
+#define EXP_BITS   (32 - 6)
 #define MAX_EXP((1 << (EXP_BITS - 1)) - 1)
[...]

but real.c wasn't updated: it still has

   denormal number fits in 17 exponent bits; we store 27.

that comes from r83133.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

Any tips for debugging a GNAT tasking implementation problem?

[Dave Korn]

Hi all,

  Over on the cygwin-improvements branch(*) I've got a fairly nifty fully
POSIX-based port of Ada, but there's one FAIL on the gnat testsuite that I'm
trying to debug.  It could be a bug in the port, or the testcase might have
stressed an underlying bug in Cygwin's pthread functions.  I'm hoping to get
some pointers to help me understand the architecture of the tasking control in
GNAT.

  The failing case is gnat.dg/task_stack_align.adb, which fails like so:

> $ ./task_stack_align.exe
> 
> raised TASKING_ERROR : Failure during activation
> 
> $

  Debugging it suggests that the problem arises in Activate_Tasks
(s-tassta.adb), here:

>   if Self_ID.Common.Activation_Failed then
>  Self_ID.Common.Activation_Failed := False;
>  raise Tasking_Error with "Failure during activation";
>   end if;

which I think is triggering as a consequence of this sequence in
Vulnerable_Complete_Activation (also s-tassta.adb):

>   --  The activator raises a Tasking_Error if any task it is activating
>   --  is completed before the activation is done. However, if the reason
>   --  for the task completion is an abort, we do not raise an exception.
>   --  See RM 9.2(5).
> 
>   if not Self_ID.Callable and then Self_ID.Pending_ATC_Level /= 0 then
>  Activator.Common.Activation_Failed := True;
>   end if;

  If I take a look at the state of the tasks when the exception is raised,
they claim to all have terminated:

> Breakpoint 1, 0x004183ca in <__gnat_raise_exception> (e=0x42c38c,
> message=0x4316e3) at a-exexda.adb:244
> 244procedure Append_Info_Character
> (gdb) call list_tasks
> tasks(50): TERMINATED, parent: main_task, prio: 0, not callable, abort 
> deferred
> tasks(49): TERMINATED, parent: main_task, prio: 0, not callable, abort 
> deferred
> tasks(48): TERMINATED, parent: main_task, prio: 0, not callable, abort 
> deferred
[ ...  snip similar entries  ... ]
> tasks(31): TERMINATED, parent: main_task, prio: 0, not callable, abort 
> deferred
> tasks(30): TERMINATED, parent: main_task, prio: 0, not callable, abort 
> deferred
> tasks(29): TERMINATED, parent: main_task, prio: 0, not callable, abort 
> deferred
> tasks(28): TERMINATED, parent: main_task, prio: 15, not callable, abort 
> deferred
[  I'm not sure if there's any significance in the way the priority fields
change from 0 to 15 at this point yet.  ]
> tasks(27): TERMINATED, parent: main_task, prio: 15, not callable, abort 
> deferred
> tasks(26): TERMINATED, parent: main_task, prio: 15, not callable, abort 
> deferred
[ ...  snip similar entries  ... ]
> tasks(4): TERMINATED, parent: main_task, prio: 15, not callable, abort 
> deferred
> tasks(3): TERMINATED, parent: main_task, prio: 15, not callable, abort 
> deferred
> tasks(2): TERMINATED, parent: main_task, prio: 15, not callable, abort 
> deferred
> tasks(1): TERMINATED, parent: main_task, prio: 15, not callable, abort 
> deferred
> main_task: RUNNABLE, parent: , prio: 15
> (gdb) call print_current_task
> main_task: RUNNABLE, parent: , prio: 15
> (gdb)

  So, if I've understood what I'm seeing, there's this object called an
activator, and it has a whole bunch of threads (ada tasks) that it wants to
start up in parallel, but it doesn't want them to all just start running
straight away; it wants them all to be created at once before any of them have
a chance to finish their work.

  That makes me think that it must be trying to create them in some suspended
state, or gate their progress past a mutex or semaphore of some kind, so that
it can create them all and then wake them all at once when it's done.  Is this
right?  If so, can anyone point me at the mechanism that is supposed to hold
the threads back but appears to be failing in this case?  If not, can someone
tell me how the task activation is supposed to work in this test?

cheers,
  DaveK

wie kann Ich gcc herunterladen ?

[gerhard gangl]

hallo gcc_team suche gcc zum downloaden
wer kann mir helfen ?

liebe grüße u. danke im vorraus _gerhard_ gangl, reichsstr. 77, 8045 graz