Re: suggestion to use lzma for snapshots, maybe more?

[Vincent Lefevre]

On 2010-01-12 19:40:50 -0500, Kevin Hunter wrote:
> I was idly looking through a couple of snapshots of the gcc -trunk line.
>  I am by no means a compiler developer, but I did notice that you aren't
> using lzma for compression.  I don't know if bandwidth is at all a
> concern, but I can point to a >20% drop in download size:
> 
> $ svn co svn://gcc.gnu.org/svn/gcc/trunk gcc-trunk
>   ...
> $ find gcc-trunk -name ".svn" -type d -print0 | xargs -0 rm -rf
> $ tar -cf - gcc-trunk | lzma  --best > gcc-trunk.tlz &
> $ tar -cf - gcc-trunk | bzip2 --best > gcc-trunk.tbz &
[...]

lzma (the file format) is obsolete and has been replaced by xz.

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

suggestion to use lzma for snapshots, maybe more?

[Kevin Hunter]

Hi GNU GCC folks,

I was idly looking through a couple of snapshots of the gcc -trunk line.
 I am by no means a compiler developer, but I did notice that you aren't
using lzma for compression.  I don't know if bandwidth is at all a
concern, but I can point to a >20% drop in download size:

$ svn co svn://gcc.gnu.org/svn/gcc/trunk gcc-trunk
  ...
$ find gcc-trunk -name ".svn" -type d -print0 | xargs -0 rm -rf
$ tar -cf - gcc-trunk | lzma  --best > gcc-trunk.tlz &
$ tar -cf - gcc-trunk | bzip2 --best > gcc-trunk.tbz &
$ wait
$ ls -lh gcc-trunk.t?z
-rw-r--r-- 1 kevin kevin 58M 2010-01-12 18:44 gcc-trunk.tbz
-rw-r--r-- 1 kevin kevin 46M 2010-01-12 18:41 gcc-trunk.tlz

lzma takes about 6 times as long, but on my machine it takes just over 7
minutes, which I'd say is reasonable:

$ tar -cf - mygcc   | \
>  pv -cN i -s 402m | \
>  lzma --best  | \
>  pv -cN o > gcc-trunk.tlz
  i:  402MB 0:07:09 [ 958kB/s] [===>] 100%
  o: 45.1MB 0:07:10 [ 107kB/s] [  <=>   ]

Anyhoo, since lzma is available on most distros now, I thought I'd
proffer it as a suggestion to y'all.

G'day,

Kevin

gcc-4.4-20100112 is now available

[gccadmin]

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

This snapshot has been generated from the GCC 4.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_4-branch 
revision 155845

You'll find:

gcc-4.4-20100112.tar.bz2  Complete GCC (includes all of below)

gcc-core-4.4-20100112.tar.bz2 C front end and core compiler

gcc-ada-4.4-20100112.tar.bz2  Ada front end and runtime

gcc-fortran-4.4-20100112.tar.bz2  Fortran front end and runtime

gcc-g++-4.4-20100112.tar.bz2  C++ front end and runtime

gcc-java-4.4-20100112.tar.bz2 Java front end and runtime

gcc-objc-4.4-20100112.tar.bz2 Objective-C front end and runtime

gcc-testsuite-4.4-20100112.tar.bz2The GCC testsuite

Diffs from 4.4-20100105 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.4
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.

Re: gcc backend beginner: only -O1 gives 'unrecongnizable insn' error

[Ian Lance Taylor]

Alex  writes:

> I am a beginner on gcc backend. I was performing some experiments
> on .md file using a completly new backend set of files written by
> me. I end up on something I really could not understand. Regarding
> addition, I put the following code on my .md file:
>
> (define_expand "addhi3"
>   [(set (match_operand:HI 0 "nonimmediate_operand" "")
> (plus:HI (match_operand 1 "general_operand" "")
>  (match_operand 2 "general_operand" "")
> )
> )
>   ]
>   ""
>   ""
> )

If you need a register, use a predicate of register_operand for one of
the operands.  Or use force_reg in the define_expand body.


>Using this code, gcc gives the following error only when I use -O1
> (for -O0, -O2 it works OK!):
>
> (insn 16 14 17 0 (set (reg:HI 12)
> (plus:HI (mem/i:HI (symbol_ref:HI ("b")  b>) [0 b+0 S2 A16])
> (mem/i:HI (symbol_ref:HI ("a") [flags 0x2]  0x7fdad430 a>) [0 a+0 S2 A16]))) -1 (nil)
> (nil))
>
>I understood that gcc would like to have a insn which accepts "reg
> = mem + mem", but I really can not understand why gcc works OK with
> -O2 and with -O0, but not with -O1.

gcc is a complex tool.  There are any number of reasons why this might
happen.  If you really want to know, -da will give you a lot of dump
files to look over.

Ian

Re: anti-optimization of _DecimalXX by -ffast-math

[Andrew Pinski]

On Tue, Jan 12, 2010 at 12:59 PM, Roman Kononov  wrote:
> Is there a good reason to place something on the stack? Why does
> -funsafe-math-optimizations (which is a part of -ffast-math) make things
> even worse? It actually swaps the arguments for __bid_a3().

Because it turns on re-association which causes a+b to be b+a in your
case.  And nothing turns it back for better register allocation.

Thanks,
Andrew Pinski

anti-optimization of _DecimalXX by -ffast-math

[Roman Kononov]

Hi,

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/rk/gcc/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ./configure --prefix=/home/rk/gcc --enable-languages=c,c++
Thread model: posix
gcc version 4.5.0 20100112 (experimental) (GCC)
$ cat test.c
_Decimal64 foo(_Decimal64 a,_Decimal64 b) { return a+b; }
$ gcc -c -O3 -save-temps test.c
$ cat test.s
  ...
foo:subq$24, %rsp
movq%xmm0, 8(%rsp)
call__bid_a3
movq%xmm0, 8(%rsp)
addq$24, %rsp
ret
  ...
$ gcc -c -O3 -funsafe-math-optimizations -save-temps test.c
$ cat test.s
  ...
foo:subq$24, %rsp
movq%xmm0, 8(%rsp)
movq%xmm1, 8(%rsp)
movq8(%rsp), %rcx
movdqa  %xmm0, %xmm1
movq%rcx, 8(%rsp)
movq8(%rsp), %xmm0
call__bid_a3
movq%xmm0, 8(%rsp)
addq$24, %rsp
ret
  ...

Is there a good reason to place something on the stack? Why does 
-funsafe-math-optimizations (which is a part of -ffast-math) make things 
even worse? It actually swaps the arguments for __bid_a3().


Thanks :)

gcc backend beginner: only -O1 gives 'unrecongnizable insn' error

[Alex]

Hi,

I am a beginner on gcc backend. I was performing some experiments 
on .md file using a completly new backend set of files written by me. I 
end up on something I really could not understand. Regarding addition, I 
put the following code on my .md file:


(define_expand "addhi3"
  [(set (match_operand:HI 0 "nonimmediate_operand" "")
(plus:HI (match_operand 1 "general_operand" "")
 (match_operand 2 "general_operand" "")
)
)
  ]
  ""
  ""
)

(define_insn "*addhi3_2"
[(set (match_operand:HI 0 "nonimmediate_operand" "=r,r,d")
  (plus:HI (match_operand:HI 1 "register_operand" "r,r,0")
   (match_operand:HI 2 "nonmemory_operand" "r,K,K")
  )
   )]
  ""
  "@
   add \\t%0, %1, %2
   add \\t%0, %1, #%c2
   add \\t%0, #%c2"
)

   Using this code, gcc gives the following error only when I use -O1 
(for -O0, -O2 it works OK!):


(insn 16 14 17 0 (set (reg:HI 12)
(plus:HI (mem/i:HI (symbol_ref:HI ("b") b>) [0 b+0 S2 A16])
(mem/i:HI (symbol_ref:HI ("a") [flags 0x2] 0x7fdad430 a>) [0 a+0 S2 A16]))) -1 (nil)

(nil))

   I understood that gcc would like to have a insn which accepts "reg = 
mem + mem", but I really can not understand why gcc works OK with -O2 
and with -O0, but not with -O1.


thank you!
Alex Prado

Re: g++ and _DecimalXX types

[Janis Johnson]

On Tue, 2010-01-12 at 12:47 +0100, Paolo Carlini wrote:
> Hi,
> 
> thanks Janis for your complete summary of the current status.
> > Instead of dec32/64/128 you could use _Decimal32/64/128, but the C++
> > TR requires that float.h define those symbols as typedefs to the
> > classes so you'd run into conflicts later.
> >   
> therefore, do I understand correctly that eventually the OP will be able
> to achieve what he wants by including  first and otherwise
> proceeding exactly like in C99?

I think that's the eventual plan, but until C++0x features are available
(and the TR authors think they shouldn't be used yet), casts from
decimal float types to generic float types must use conversion
functions.  In addition I couldn't get conversions from decimal float to
long long to work without allowing otherwise invalid conversions to
float, so currently those also need function calls.

In addition, support for decimal floating-point constants is optional.

Janis

Re: g++ and _DecimalXX types

[Janis Johnson]

On Mon, 2010-01-11 at 19:05 -0800, Benjamin Kosnik wrote:
> >  Some of the support for those
> > classes is in current trunk, but a crucial change to the compiler to
> > allow binary compatibility between those classes and the C builtin
> > types wasn't approved before the 4.5 feature cutoff (see
> > http://gcc.gnu.org/ml/gcc-patches/2009-11/msg01321.html).
> 
> Am a bit alarmed to see this patch dropped on the floor. It seem silly
> to me to have C++ DFP support broken like this, when 4.5 is the first
> release that claims support for this feature. It seems to me like we
> should be trying to generate non-obvious bug reports with this new
> feature, instead of the current unsatisfactory situation which prompted
> this original message.
> 
> From what I can tell, this was patch was posted, approved for 4.5 by
> Jason, then delayed while the C++ ABI mailing list reached consensus. I
> see that on 2009-11-24 Mark checked in the ABI change to the official
> document. But then, the patch wasn't pinged, and was forgotten over the
> holidays? 
> 
> What am I missing?

Jason never responded to the modified patch, and I thought it needed his
approval.  I pinged it before the end of stage 3 (or 2, or whatever).

Can you ask Jason if it can still go in?  I'm leaving on Thursday for a
3.5 week vacation when I'll be out of touch, but I could test it again
before I go.

Janis

Re: GCC aliasing rules: more aggressive than C99?

[Michael Matz]

Hi,

[oh my, coming late to this thread, I'm sorry about restarting it but I 
feel the urge to comment on some misconceptions I read, I believe ;-) ]

Commenting on the first mail where I think one subthread went down the 
wrong path:

On Tue, 5 Jan 2010, Andrew Haley wrote:

> On 01/05/2010 02:09 AM, Joshua Haberman wrote:
> > Erik Trulsson  student.uu.se> writes:
> >> On Mon, Jan 04, 2010 at 08:17:00PM +, Joshua Haberman wrote:
> >>> The text you quoted does not contain any "shall not" language about
> >>> dereferencing, so this conclusion does not follow.
> >>
> >> It doesn't have to use any "shall not" language.  If the standard does not
> >> say that any particular action is allowed or otherwise defines what it
> >> does, then that action implicitly has undefined behaviour.
> > 
> > Section 6.5 does define circumstances under which converted pointers may
> > be dereferenced.
> 
> No.  It says
> 
> "An object shall have its stored value accessed only by an lvalue
> expression that has one of the following types:
> 
> but
> 
>  (union u*)&i
> 
> is not a legal lvalue expression because the dereference is undefined
> behaviour.  You may only dereference a pointer as permitted by 6.3.2.3.

I'm very sure this is a misunderstanding on your part, which then results 
in your discount of the other arguments.  It's really 6.5 that makes the 
above dereference invalid, not 6.3.2.3.  You seem to interpret 6.3.2.3 p7 
as somehow limiting what operations can be done with the converted 
pointer.  This is wrong.  Let's look at it in detail:

-
A pointer to an object or incomplete type may be converted to a pointer to 
a different object or incomplete type.
-

Ignore incomplete types, so let's assume we have a pointer P to an object 
type T (let's assume it points to object O of type T), and we convert it 
to a pointer P1 to object type T1:

P1 = (T1 *) P;

-
If the resulting pointer is not correctly aligned for the pointed-to type, 
the behavior is undefined.
-

Good good, let's assume this isn't the case, hence we invoke this 
sentence:

-
Otherwise, when converted back again, the result shall compare equal to 
the original pointer.
-

Okay, this tells us the following:

P == (T *) P1;

_When_ converted back it's the same pointer (IOW it again points to O).  
It doesn't say the slightest about what other operations might be allowed 
on the pointer.  It restricts the possible outcomes of a back-conversion.  

That's all it says (the other sentences here deal with char types, let's 
ignore these too).

In particular, if alignment was correct, we have a pointer to object type 
T1.  Pointers to object types may be dereferenced and then yield a value 
or object-reference of type T1, if that pointer is valid (6.5.3.2 p4), 
where pointer validity has several cases (not null, aligned enough, object 
lifetime must not have ended, and some other things which we'll come to in 
a moment).

In order to establish the existence of O1 (the up to now hypothetical 
object that P1 points to), and hence validity of P1, we really need to 
consult 6.5.  Only that one tells us when we may access the value in 
object O with the type typeof(O1).

At that point also the access "*(unsigned *)ptr-to-int" is valid (wondered 
about downthread).  Not because anything in the pointer conversion was 
valid (it is valid), but specifically because 6.5p7 (and nothing else) 
tells us so.

The original poster is not correct in believing that 6.5p7 only talks 
about dereferencing converted pointers (I think this was held to his 
disfavor downthread), it talks about _all_ accesses of values of objects, 
however you come to access them; converted pointers are just one case.

Having said all this, the original poster is correct that GCC doesn't 
implement C99 aliasing as written in the standard regarding unions.  We 
don't do so because we determined that this can't possibly have been the 
intent of the standard as it makes type-based aliasing relatively useless.


Ciao,
Michael.

Re: PATCH: Support --enable-gold=both --with-linker=[bfd|gold]

[H.J. Lu]

On Tue, Jan 5, 2010 at 8:23 PM, H.J. Lu  wrote:
> On Tue, Jan 5, 2010 at 11:08 AM, Ian Lance Taylor  wrote:
>> "H.J. Lu"  writes:
>
>>
>>> diff --git a/configure.ac b/configure.ac
>>> index 407ab59..b349633 100644
>>> --- a/configure.ac
>>> +++ b/configure.ac
>>> @@ -311,10 +311,11 @@ esac
>>>  # Handle --enable-gold.
>>>
>>>  AC_ARG_ENABLE(gold,
>>> -[  --enable-gold           use gold instead of ld],
>>> +[  --enable-gold[[=ARG]]     build gold [[ARG={yes,both}]]],
>>>  ENABLE_GOLD=$enableval,
>>>  ENABLE_GOLD=no)
>>> -if test "${ENABLE_GOLD}" = "yes"; then
>>> +case "${ENABLE_GOLD}" in
>>> +yes|both)
>>>    # Check for ELF target.
>>>    is_elf=no
>>>    case "${target}" in
>>> @@ -334,11 +335,17 @@ if test "${ENABLE_GOLD}" = "yes"; then
>>>      # Check for target supported by gold.
>>>      case "${target}" in
>>>        i?86-*-* | x86_64-*-* | sparc*-*-* | powerpc*-*-* | arm*-*-*)
>>> -        configdirs="`echo " ${configdirs} " | sed -e 's/ ld / gold /'`"
>>> +        if test "${ENABLE_GOLD}" = both; then
>>> +          configdirs="$configdirs gold"
>>> +     else
>>> +          configdirs="`echo " ${configdirs} " | sed -e 's/ ld / gold /'`"
>>> +     fi
>>>          ;;
>>>      esac
>>>    fi
>>> -fi
>>> +  ENABLE_GOLD=yes
>>> +  ;;
>>> +esac
>>
>> You should have an error case here to ensure that --enable-gold only
>> has the values "yes", "both", or "no".  --enable-gold=foo should give
>> an error.
>>
>> This patch uses two configure options: one to build both gold and ld,
>> and one to select which linker is the default.  Why not use just one
>> configure option?  Perhaps something like:
>>    --enable-gold              Build only gold, gold is default
>>    --disable-gold [default]   Build only GNU ld, GNU ld is default
>>    --enable-gold=no           Same
>>    --enable-gold=both         Build both gold and GNU ld, gold is default
>>    --enable-gold=both/gold    Same
>>    --enable-gold=both/bfd     Build both gold and GNU ld, GNU ld is default
>
> Done.
>
>> But of course this approach is conditional on whether there should be
>> some way to select the linker to use at runtime.
>>
>>
>>
>>> diff --git a/gold/Makefile.am b/gold/Makefile.am
>>> index 8d8b617..85b103b 100644
>>> --- a/gold/Makefile.am
>>> +++ b/gold/Makefile.am
>>> @@ -163,12 +163,20 @@ check: libgold.a
>>>
>>>  install-exec-local: ld-new$(EXEEXT)
>>>       $(mkinstalldirs) $(DESTDIR)$(bindir) $(DESTDIR)$(tooldir)/bin
>>> -     n=`echo ld | sed '$(transform)'`; \
>>> +     n=`echo @installed_linker@ | sed '$(transform)'`; \
>>>       $(INSTALL_PROGRAM) ld-new$(EXEEXT) 
>>> $(DESTDIR)$(bindir)/$${n}$(EXEEXT); \
>>> -     if test "$(bindir)" != "$(tooldir)/bin"; then \
>>> -       rm -f $(DESTDIR)$(tooldir)/bin/ld$(EXEEXT); \
>>> -       ln $(DESTDIR)$(bindir)/$${n}$(EXEEXT) 
>>> $(DESTDIR)$(tooldir)/bin/ld$(EXEEXT) >/dev/null 2>/dev/null \
>>> +     if test "@linker@" = "ld.gold"; then \
>>> +       if test "@installed_linker@" != "ld"; then \
>>> +         ld=`echo ld | sed '$(transform)'`; \
>>> +         rm -f $(DESTDIR)$(bindir)/$${ld}$(EXEEXT); \
>>> +         ln $(DESTDIR)$(bindir)/$${n}$(EXEEXT) 
>>> $(DESTDIR)$(bindir)/$${ld}$(EXEEXT) >/dev/null 2>/dev/null \
>>> +         || $(INSTALL_PROGRAM) ld-new$(EXEEXT) 
>>> $(DESTDIR)$(bindir)/$${ld}$(EXEEXT); \
>>> +       fi; \
>>> +       if test "$(bindir)" != "$(tooldir)/bin"; then \
>>> +         rm -f $(DESTDIR)$(tooldir)/bin/ld$(EXEEXT); \
>>> +         ln $(DESTDIR)$(bindir)/$${n}$(EXEEXT) 
>>> $(DESTDIR)$(tooldir)/bin/ld$(EXEEXT) >/dev/null 2>/dev/null \
>>>           || $(INSTALL_PROGRAM) ld-new$(EXEEXT) 
>>> $(DESTDIR)$(tooldir)/bin/ld$(EXEEXT); \
>>> +       fi; \
>>>       fi
>>
>> In Makefile.am you don't need to use @@ quoting in rules.  You can
>> just use $(installed_linker) and $(linker).
>>
>
> Done.
>
>>
>>> diff --git a/gold/configure.ac b/gold/configure.ac
>>> index 85e23f9..10389a9 100644
>>> --- a/gold/configure.ac
>>> +++ b/gold/configure.ac
>>> @@ -38,6 +38,29 @@ AC_DEFINE_UNQUOTED(TARGET_SYSTEM_ROOT, "$sysroot",
>>>  AC_DEFINE_UNQUOTED(TARGET_SYSTEM_ROOT_RELOCATABLE, $sysroot_relocatable,
>>>    [Whether the system root can be relocated])
>>>
>>> +AC_ARG_ENABLE(gold,
>>> +[  --enable-gold[[=ARG]]     build gold [[ARG={yes,both}]]],
>>> +[if test "${enableval}" = "both"; then
>>> +   bfd_linker=ld.bfd
>>> +   installed_linker=ld.gold
>>> + else
>>> +   bfd_linker=ld.gold
>>> +   installed_linker=ld
>>> + fi],
>>> +[bfd_linker=ld.bfd
>>> + installed_linker=ld])
>>> +AC_SUBST(installed_linker)
>>
>> It seems rather weird to set a variable named bfd_linker to be
>> ld.gold.  What does that mean?
>
> Rewritten.
>
>>
>>> +AC_ARG_ENABLE(linker,
>>> +[  --enable-linker=[[ARG]]   specify the default linker 
>>> [[ARG={bfd,gold}]]],
>>> +[if test "${enableval}" = "gold"; then
>>> +   linker=ld.gold
>>> + else
>>> +   linker=$bfd_linker
>>> + fi],
>>> +[linker=$bfd_linker])
>>> +AC_SUBST(linker)
>>
>> You should give an error if --enable-linker is used with an
>

Re: Looping through the gimple for CALL_EXPR

[Paulo J. Matos]

On Tue, Jan 12, 2010 at 11:30 AM, Richard Guenther
 wrote:
>
> There is walk_tree.
>

Thanks! Guess I should have guessed that! :)

> Richard.
>



-- 
Paulo Jorge Matos - pocmatos at gmail.com
http://www.pmatos.net

GCC-How does the coding style affect the insv pattern recognization?

[fanqifei]

Hi,
I am working on a micro controller and trying to port gcc(4.3.2) for it.
There is insv instruction in our micro controller and I have add
define_insn to machine description file.
However, the insv instruction can only be generated when the code
is written like below.  If the code is written using logical shift and
or operators, the insv instruction will not be generated.
For the statement: x= (x&0xFF00) | ((i<<16)&0x00FF);
6 RTL instructions are generated after combine pass and 8
instructions are generated in the assembly file.
Paolo Bonzini said that insv instruction might be synthesized
later by combine. But combine only works on at most 3 instructions and
insv is not generated in such case.
So exactly when will the insv pattern be recognized and how does
the coding style affect it?
Is there any open bug report about this?

struct test_foo {
unsigned int a:18;
unsigned int b:2;
unsigned int c:12;
};

struct test_foo x;

unsigned int foo()
{
unsigned int a=x.b;
x.b=2;
return a;
}

Thanks!
fanqifei

Re: g++ and _DecimalXX types

[Paolo Carlini]

Hi,

thanks Janis for your complete summary of the current status.
> Instead of dec32/64/128 you could use _Decimal32/64/128, but the C++
> TR requires that float.h define those symbols as typedefs to the
> classes so you'd run into conflicts later.
>   
therefore, do I understand correctly that eventually the OP will be able
to achieve what he wants by including  first and otherwise
proceeding exactly like in C99?

Paolo.

Re: Looping through the gimple for CALL_EXPR

[Richard Guenther]

On Tue, Jan 12, 2010 at 12:13 PM, Paulo J. Matos  wrote:
> On Tue, Jan 12, 2010 at 10:43 AM, Richard Guenther
>  wrote:
>>
>> Because it talks about trees as used by the C / C++ frontends
>> and it is way out of date anyway.
>>
>
> Thanks, the tree iterator did the trick.
> I was wondering if there is a tree-walker which walks through the
> whole tree, going through all the possible nested statements and
> expressions instead of just iterating through a list of statements.
> I know tree-pretty-print.c implements  something to print a tree but I
> am wondering if there's something like an iterator for doing this or
> if I have to implement it myself.

There is walk_tree.

Richard.

Re: Looping through the gimple for CALL_EXPR

[Paulo J. Matos]

On Tue, Jan 12, 2010 at 10:43 AM, Richard Guenther
 wrote:
>
> Because it talks about trees as used by the C / C++ frontends
> and it is way out of date anyway.
>

Thanks, the tree iterator did the trick.
I was wondering if there is a tree-walker which walks through the
whole tree, going through all the possible nested statements and
expressions instead of just iterating through a list of statements.
I know tree-pretty-print.c implements  something to print a tree but I
am wondering if there's something like an iterator for doing this or
if I have to implement it myself.

Thanks,


-- 
Paulo Jorge Matos - pocmatos at gmail.com
http://www.pmatos.net

Re: Looping through the gimple for CALL_EXPR

[Richard Guenther]

On Mon, Jan 11, 2010 at 8:39 PM, Paulo J. Matos  wrote:
> On Mon, 2010-01-11 at 17:51 +0100, Richard Guenther wrote:
>> On Mon, Jan 11, 2010 at 4:46 PM, Paulo J. Matos  wrote:
>> > Hi all,
>> >
>> > I am using gcc 4.3.4 to loop through the gimple tree to find
>> > CALL_EXPR. This is what I have (even though I tried several variants,
>> > none of which worked):
>> > tree body_stmt = DECL_SAVED_TREE (current_function_decl);
>> >    while (body_stmt) //
>> >    {
>> >        if (TREE_CODE (body_stmt) == CALL_EXPR)
>> >        {
>> >            printf("CALL_EXPR found in %s\n",
>> > IDENTIFIER_POINTER(DECL_NAME(current_function_decl)));
>> >        }
>> >
>> >        body_stmt = TREE_CHAIN (body_stmt);
>> >    }
>> >
>> > I have read in the internals doc about EXPR_STMT and EXPR_STMT_EXPR
>> > but using them to access the expression through the statement and then
>> > checking if the expressions is a CALL expression doesn't work either.
>> > In fact, EXPR_STMT doesn't even seem to be defined.
>> >
>> > Any tips?
>>
>> statements are chained in STATEMENT_LIST nodes, you need to
>> iterate through them using iterators - see tree-iterator.h.
>>
>
> Thanks for the tip. I used the code found in
> http://gcc.gnu.org/onlinedocs/gccint/Function-Bodies.html#Function-Bodies
>
> Why doesn't that apply?

Because it talks about trees as used by the C / C++ frontends
and it is way out of date anyway.

Richard.

> Cheers,
>
> Paulo Matos
>
>> Richard.
>>
>> > --
>> > Paulo Jorge Matos - pocmatos at gmail.com
>> > http://www.pmatos.net
>> >
>
>
>

Re: rebuild test of Debian packages with GCC trunk 20100107

[Richard Guenther]

On Mon, Jan 11, 2010 at 7:15 PM, Matthias Klose  wrote:
> A rebuild test of the current Debian unstable distribution on
> x86_64-linux-gnu was done, one rebuild test with the current gcc-4.4 from
> the branch, and another one with GCC trunk 20100107. The latter did show
> about 200 additional build failures, which are listed in [1] (minus some
> already known failures due to misconfiguration for the rebuild with
> gcc-4.5). The GCC test packages used for the test rebuild are available for
> i386 and amd64 at [2].
>
> Lucas did do the test rebuild and a quick analysis of the results, repeated
> here:
>
>  - some symbols problems (sqlxx, strigi)
>  - tests failure (incorrect code generation?)
>  - many new gcc errors (compiler becoming stricter, as usual?)
>  - some ICEs
>  - several builds where g++ hanged (e.g fwbuilder, but there are others).
>   the timeout for the builds was set to 60min.
>
> I'll go through the list of build failures this week, trying to file
> appropriate bug reports for GCC or the distribution.

I am currently also rebuilding openSUSE for ia64, powerpc(64) and s390(x).

Richard.

>  Matthias
>
> [1] https://wiki.ubuntu.com/GCC/Rebuild20100107
> [2] deb http://people.debian.org/~doko/archive/ experimental/
>

Re: Exception object access

[Piotr Wyderski]

Jonathan Wakely wrote:

> Do you mean like std::current_exception(), available in c++0x mode?

No, the main purpose of std::exception_ptr is to allow
passing exceptions between threads, but it is pretty
useless if it comes to reasoning about the exception
itself (i.e. it's not dereferencable). What I mean is the
exception value itself, for example:

   throw std::error("bug");

it will be a pointer to the std::error instance. But I was
partly wrong, the __cxa* functions are exported from
libstdc++, but in extern "C" mode. Now I have full access
to the __cxa_exception structure:

struct __cxa_exception {

std::type_info* exceptionType;
void (*exceptionDestructor) (void *);
std::unexpected_handler unexpectedHandler;
std::terminate_handler  terminateHandler;
__cxa_exception*nextException;

int handlerCount;
int handlerSwitchValue;
const char* actionRecord;
const char* languageSpecificData;
void*   catchTemp;
void*   adjustedPtr;

_Unwind_Exception   unwindHeader;
};

But a question arises: may I assume that the adjustedPtr
field is always correctly filled by the compiler in contexts like this:

void remap_exception() {

__cxa_eh_globals* const pEHGlobals = __cxa_get_globals();
__cxa_exception* const pEHDescriptor = pEHGlobals->caughtExceptions;

try {

throw;

} catch(...) {

auto p = pEHDescriptor->adjustedPtr;

// HERE
}
}

?

The ABI specification says that __cxa_get_exception_ptr()
should be called in order to get the unwrapped object, but
when explicitly called, it returns null. On the other hand it
says that catches emit a call to this function together with
__cxa_begin_catch() and store the value in the current
__cxa_exception instance. So the answer to my question
should be "yes, the value of adjustedPtr is correct", but
it's better to ask in order to be sure.

Best regards
Piotr Wyderski