Re: gcc-in-cxx branch created

[Gabriel Dos Reis]

On Sun, Jun 22, 2008 at 6:24 PM, Bruno Haible <[EMAIL PROTECTED]> wrote:
> Dear Ian,
>
> A comment regarding the GCC-in-C++ idea. In slide 16 you merely answer
>
>  "C++ is too complicated!"
>
> with
>
>  "Maintainers will ensure that gcc continues to be maintainable."
>
> C++ has, for example, 12 different ways to represent or invoke a function.
> It has no buikt-in typesafe "enum"s. Sooner or later developers will think

C++ enums are certainly improvements over C enums.  Below you
mentioned dynamic_cast working with enum sets, I don't what
you mean by that -- since any attempt to dynamic_cast an
enum is rejected at compile time.

-- Gaby

Re: gcc-in-cxx branch created

[Gabriel Dos Reis]

On Mon, Jun 23, 2008 at 6:14 AM, Bruno Haible <[EMAIL PROTECTED]> wrote:
> Arnaud Charlet wrote:
>> One possibility is to do what we do for Ada: have a style/coding checker
>> built into the compiler (C++ front-end) as a special switch, and enable this
>> switch during bootstrap, so that any such coding style violation is 
>> transformed
>> into an error
>
> Yes, this can be the technical implementation of limiting the set of C++
> features.
>
> Additionally, it needs to be avoided that the limits get pushed out year
> after year, allowing, for example, inline templates in one year, template
> member functions the next year, and complete template metaprogramming the
> year after that. To this end, it must be made very hard to extend this
> subset of C++. Possibly it should require agreement from the Steering Comittee
> to do so.
>
> Bruno

while `creative' uses of templates are certainly a problem -- we don't
really want
people to start writing clever (which most of the time means brittle)
codes, we should
also refrain from putting FUD on templates.  There is a subset of C++ templates
stable enough over the years, that can be used without fear,
uncertainty and doubt.

I don't see banning inline template as increasing the readability of
GCC codebase.

-- Gaby


>
>

Re: gcc-in-cxx branch created

[Richard Guenther]

On Tue, Jun 24, 2008 at 3:54 AM, Tom Tromey <[EMAIL PROTECTED]> wrote:
>> "Ian" == Ian Lance Taylor <[EMAIL PROTECTED]> writes:
>
> Ian> The other major TODO is to work out the details of using STL
> Ian> containers with GC allocated objects.  This means teaching gengtype
> Ian> how to generate code to traverse STL containers, which would then be
> Ian> used during GC.  This is not a task for the faint-hearted.
>
> A related (and IMO probably more difficult) problem is that of
> serializing such containers for PCH.

One more reason to get rid of our current PCH implementation ...

:)

Richard.

Re: RFA and RFC: tweak -fstrict-aliasing docs, provide pointer-cast example

[Andrew Haley]

Hans-Peter Nilsson wrote:
> There's background in
> .  Neither
> Richi nor me could find the union-assignment "gcc extension" at
> a glance, probably because it's not an *extension* but an
> implementation-defined behavior, and actually duly documented as
> such.  However, to cross-reference that section together with
> the clarifying type-punning blurb in the -fstrict-aliasing
> documentation seems would be an improvement, and apparently
> there's enough confusion about casting, pointers and unions to
> call for an extra example, covering the offending code in the
> PR.
> 
> So far the RFA.  The RFC is whether (to reject this patch and
> call for another) to allow the cast-through-pointer-to-union in
> the example and the PR as a variant of the blessed
> implementation-defined type-punning using unions.  IMHO not, but
> the offending code is from a canonical strtod implementation
> imported into newlib, and enough people are confused already,

I thought cast-through-pointer-to-union didn't work and was already
disallowed; we've been around all this already.  This patch of yours
already documents uncontroversial behaviour.

I don't like the phrase "might not work".  It's better just to say "is not
allowed".

Andrew.

Re: RFA and RFC: tweak -fstrict-aliasing docs, provide pointer-cast example

[Hans-Peter Nilsson]

> Date: Tue, 24 Jun 2008 10:36:15 +0100
> From: Andrew Haley <[EMAIL PROTECTED]>

> I thought cast-through-pointer-to-union didn't work and was already
> disallowed; we've been around all this already.

We also bless assignments through unions, and this could be
argued as assigning through a union, albeit casted.

>  This patch of yours
> already documents uncontroversial behaviour.

That's what I hope, but the existence of that code together in
an *else* clause of #ifdef YES_ALIAS by a well-known author
makes it de-facto controversial IMHO.  Note also that another
maintainer thought the code to be valid; see the PR.

> I don't like the phrase "might not work".  It's better just to say "is not
> allowed".

I thought the wording to be uncontroversial :) as I copied it
from the previous example: "So, the code above will work as
expected.  However, this code might not".

But, I agree with your sentiment and hope a reviewer agrees that
your wording is preferred.

brgds, H-P

Re: RFA and RFC: tweak -fstrict-aliasing docs, provide pointer-cast example

[Joseph S. Myers]

On Tue, 24 Jun 2008, Hans-Peter Nilsson wrote:

> There's background in
> .  Neither
> Richi nor me could find the union-assignment "gcc extension" at
> a glance, probably because it's not an *extension* but an
> implementation-defined behavior, and actually duly documented as
> such.  However, to cross-reference that section together with

And also explicitly described in a footnote added in C99 TC3:

15. Page 073, 6.5.2.3
Attach a new footnote to the words "named member" in paragraph 3:

*) If the member used to access the contents of a union object is not 
the same as the member last used to store a value in the object, the 
appropriate part of the object representation of the value is 
reinterpreted as an object representation in the new type as described 
in 6.2.6 (a process sometimes called "type punning"). This might be a 
trap representation.

The doc patch is OK.  (I think "is not allowed" is misleading when 
describing code that is compile-time valid but had undefined behavior if 
executed, but feel free to put "has undefined behavior" in place of "might 
not work" if you wish.)

-- 
Joseph S. Myers
[EMAIL PROTECTED]

Re: gcc-in-cxx branch created

[Bruno Haible]

Gabriel Dos Reis wrote:
> There is a subset of C++ templates stable enough over the years, that can be
> used without fear, uncertainty and doubt.

Absolutely. Can you specify this "usable" subset of C++ templates formally?
That would be valuable advice for maintainers. So that maintainers can decide
whether they should write code like gmpxx [1] inside GCC.

Bruno

[1] 
http://www.google.com/codesearch?hl=en&q=show:G8p0bPmV-oQ:iB2K8u4XbxM:9D2oeU5g1Qo&sa=N&cd=1&ct=rc&cs_p=http://gcc-hk.internet.bs/infrastructure/gmp-4.2.1.tar.bz2&cs_f=gmp-4.2.1/gmpxx.h

Re: gcc-in-cxx branch created

[Bruno Haible]

Ian Lance Taylor wrote:
> Whether we use C or C++, we need to try to ensure that interfaces are
> easy to understand, that the code is reasonably modular, that the
> internal documentation corresponds to the code, that it is possible
> for new developers to write new passes and to fix bugs.

Fully agreed.

> it is possible for most compiler developers to use the vec.h routines
> without understanding how they actually work.

Understood.

What is the level of C++ that "new developers" need to master, in order to
understand the code in general and to fix bugs in average areas?

Bruno

Re: gcc-in-cxx branch created

[Gabriel Dos Reis]

On Tue, Jun 24, 2008 at 5:47 AM, Bruno Haible <[EMAIL PROTECTED]> wrote:
> Gabriel Dos Reis wrote:
>> There is a subset of C++ templates stable enough over the years, that can be
>> used without fear, uncertainty and doubt.
>
> Absolutely. Can you specify this "usable" subset of C++ templates formally?

formally, probably not, but I rely on the common sense of my fellow
maintainers.  To give concreteness to what I mean, I suspect that
most *uses* of the template uses in the STL -- before we get to rvalue
references
and the like are OK.  They don't require cleverness.

> That would be valuable advice for maintainers. So that maintainers can decide
> whether they should write code like gmpxx [1] inside GCC.

the code gmpxx was inpired by my implementation of valarray that comes with
GCC.  I don't think such `execessive cleverness' is needed in the
compiler itself.
In fact, most codes in the compiler should be `dull'.

>
> Bruno
>
> [1] 
> http://www.google.com/codesearch?hl=en&q=show:G8p0bPmV-oQ:iB2K8u4XbxM:9D2oeU5g1Qo&sa=N&cd=1&ct=rc&cs_p=http://gcc-hk.internet.bs/infrastructure/gmp-4.2.1.tar.bz2&cs_f=gmp-4.2.1/gmpxx.h
>
>

Re: gcc-in-cxx branch created

[Gabriel Dos Reis]

On Tue, Jun 24, 2008 at 6:20 AM, Bruno Haible <[EMAIL PROTECTED]> wrote:
>
> What is the level of C++ that "new developers" need to master, in order to
> understand the code in general and to fix bugs in average areas?
>
> Bruno

What is covered in `Accelerated C++' by A. Koenig should be enough, I would
think; but that is only me.

Re: gcc-in-cxx branch created

[Tom Tromey]

> "Kaveh" == Kaveh R GHAZI <[EMAIL PROTECTED]> writes:

Kaveh> We could also extend -Wc++-compat to warn about more things, using C++
Kaveh> reserved keywords like "class" in C comes to mind.

This isn't super hard, and IMO is worth doing (right now -Wc++-compat
seems almost silly in its limitations), but in lieu of implementing
this I've just been using #pragma GCC poison.

Tom

Re: [PATCH,rs6000] split up crtsavres into individual files

[Nathan Froyd]

On Tue, Jun 24, 2008 at 10:42:57AM +1000, Ben Elliston wrote:
> On Mon, 2008-06-23 at 15:52 -0700, Andrew Pinski wrote:
> > This introduced a few warnings while building libgcc for 
> > powerpc64-linux-gnu:
> 
> I see lots and lots of these myself:
>
> Please fix! :-)

I believe this patch fixes things; there are Makefile rules
automagically generated for files in LIB2ADD{,_ST} and these rules were
conflicting with the manually specified ones in t-ppccomm.  With the
patch, no warnings are emitted when make'ing in the libgcc/ directory
and the resulting object/library files are identical to what they were
previously.

OK to commit as is?  Or should I do a testing run as well?

-Nathan

libgcc/
2008-06-24  Nathan Froyd  <[EMAIL PROTECTED]>

* config/rs6000/t-ppccomm: Remove rules that conflict with
auto-generated rules.

Index: config/rs6000/t-ppccomm
===
--- config/rs6000/t-ppccomm (revision 136762)
+++ config/rs6000/t-ppccomm (working copy)
@@ -101,63 +101,3 @@ ncrti$(objext): ncrti.S
 
 ncrtn$(objext): ncrtn.S
$(crt_compile) -c ncrtn.S
-
-crtsavres$(objext): crtsavres.S
-   $(crt_compile) -c crtsavres.S
-
-crtsavfpr$(objext): crtsavfpr.S
-   $(crt_compile) -c crtsavfpr.S
-
-crtresfpr$(objext): crtresfpr.S
-   $(crt_compile) -c crtresfpr.S
-
-crtsavgpr$(objext): crtsavgpr.S
-   $(crt_compile) -c crtsavgpr.S
-
-crtresgpr$(objext): crtresgpr.S
-   $(crt_compile) -c crtresgpr.S
-
-crtresxfpr$(objext): crtresxfpr.S
-   $(crt_compile) -c crtresxfpr.S
-
-crtresxgpr$(objext): crtresxgpr.S
-   $(crt_compile) -c crtresxgpr.S
-
-e500crtres32gpr$(objext): e500crtres32gpr.S
-   $(crt_compile) -c e500crtres32gpr.S
-
-e500crtres64gpr$(objext): e500crtres64gpr.S
-   $(crt_compile) -c e500crtres64gpr.S
-
-e500crtres64gprctr$(objext): e500crtres64gprctr.S
-   $(crt_compile) -c e500crtres64gprctr.S
-
-e500crtrest32gpr$(objext): e500crtrest32gpr.S
-   $(crt_compile) -c e500crtrest32gpr.S
-
-e500crtrest64gpr$(objext): e500crtrest64gpr.S
-   $(crt_compile) -c e500crtrest64gpr.S
-
-e500crtresx32gpr$(objext): e500crtresx32gpr.S
-   $(crt_compile) -c e500crtresx32gpr.S
-
-e500crtresx64gpr$(objext): e500crtresx64gpr.S
-   $(crt_compile) -c e500crtresx64gpr.S
-
-e500crtsav32gpr$(objext): e500crtsav32gpr.S
-   $(crt_compile) -c e500crtsav32gpr.S
-
-e500crtsav64gpr$(objext): e500crtsav64gpr.S
-   $(crt_compile) -c e500crtsav64gpr.S
-
-e500crtsav64gprctr$(objext): e500crtsav64gprctr.S
-   $(crt_compile) -c e500crtsav64gprctr.S
-
-e500crtsavg32gpr$(objext): e500crtsavg32gpr.S
-   $(crt_compile) -c e500crtsavg32gpr.S
-
-e500crtsavg64gpr$(objext): e500crtsavg64gpr.S
-   $(crt_compile) -c e500crtsavg64gpr.S
-
-e500crtsavg64gprctr$(objext): e500crtsavg64gprctr.S
-   $(crt_compile) -c e500crtsavg64gprctr.S

Re: gcc-in-cxx branch created

[Ian Lance Taylor]

Bruno Haible <[EMAIL PROTECTED]> writes:

> What is the level of C++ that "new developers" need to master, in order to
> understand the code in general and to fix bugs in average areas?

I don't know.  I think we will have to find out.

I expect that we will find it appropriate to use STL containers, as in
  for (Type::iterator p = container.begin(); p != container.end(); ++p)

I expect we will find it appropriate to use simple class inheritance,
as in
  class Target
  {
virtual bool handle_option(size_t, const char*, int)
{ return true; }
  };

  class Target_i386 : public Target
  {
bool handle_option(size_t code, const char* arg, int value)
{
  ...
};
  };

When it comes to fixing bugs, I doubt that any special C++ knowledge
will be required at all.  When it comes to writing the code in gcc's
compilation passes, it will pretty much all be C.  Anybody patient
enough to understand the uses of the tree and RTL data structures can
certainly understand C++.

Ian

Re: Some bugs in the GCC 4.3 release notes

[Benjamin Kosnik]

> > Also, the parallel mode page is somewhat unclear as to exactly _how_
> > to substitute the parallel algorithms "on a piecemeal basis."
> 
> Let me add the libstdc++ list where the experts are.  Usually, user
> support questions should go to [EMAIL PROTECTED], not the general
> lists which is about the development _of_ GCC as opposed to _with_
> GCC, but this may be something to hilight better in our documentation.

Hey, sorry for the delay on this...

I've checked in a patch that will hopefully clarify this stuff. Please
let me know if you think it still unclear.

Here's the patch:
http://gcc.gnu.org/ml/gcc-patches/2008-06/msg01526.html

or you can just read the new text here:
http://gcc.gnu.org/onlinedocs/libstdc++/manual/parallel_mode.html

best,
benjamin

Re: Cross-compiler for Alpha architecture

[venetis]

Hello again,

Does no one have any idea about the problem I described in my previous
message? Do you need more information to check it? If so, let me know.

Thanks!

Ioannis

gcc4.3.1 optimizations with restrict / -fargument-noalias / VLA

[Markus]

I've been experimenting which optimizations gcc is willing to apply  
depending on the kind of function arguments and compiler flags.  
Perhaps someone can comment on what strange behavior I experienced:


If I understand the concept of C99's "restrict" qualifier for  
function arguments correctly, it gives basically the same  
"guarantees" to the compiler as -fargument-noalias-global.


However, gcc applies much more aggressive optimizations (for my test  
kernels the new predictive commoning seems to be most benefical) for - 
fargument-noalias, and seems to take no advantage of "restrict" in  
C99 (or the __restrict__ extension, in C99 as well as in C++).


Quite strange, optimization seems to be at least as good for C99's  
VLAs, even without restrict and without -fargument-noalias. I don't  
have the C99 standard to read that up, but could not find a hint on  
the web that VLA arguments are forbidden to alias.


Am I overlooking something here? Why is "restrict" not useful in that  
context (but -fargument-noalias is)? And why does it work for VLAs  
without any of both?


Regards,
Markus

Re: Cross-compiler for Alpha architecture

[Yann E. MORIN]

Ioannis, all,

On Tuesday 24 June 2008 20:50:11 [EMAIL PROTECTED] wrote:
> > I am trying to build a cross-compiler for an alphaev56-unknown-linux-gnu
> > system, using crosstool-ng. The host is a i686-unknown-linux-gnu.
[--SNIP--]
> > I managed to get as far as described here:
> > http://sourceware.org/ml/libc-help/2008-06/msg00061.html [1]
> > http://sourceware.org/ml/libc-help/2008-06/msg00062.html
> > The errors in [1] are coming from glibc. Ryan Arnold replied with this
> > message:
> > http://sourceware.org/ml/libc-help/2008-06/msg00063.html

Those were committed this evening (UTC+0200), as revisions 747 and 748.

> > source='/root/Temp/crosstool-ng/crosstool-ng-2008-06-19/targets/src/gcc-4.3.1/libdecnumber/dpd/decimal128.c'
> > object='decimal128.o' libtool=no i686-pc-linux-gnu-gcc
> > -I/root/Temp/crosstool-ng/crosstool-ng-2008-06-19/targets/src/gcc-4.3.1/libdecnumber
> > -I.  -pipe -W -Wall -Wwrite-strings -Wstrict-prototypes
> > -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute
> > -Wcast-qual -pedantic -Wno-long-long
> > -I/root/Temp/crosstool-ng/crosstool-ng-2008-06-19/targets/src/gcc-4.3.1/libdecnumber
> > -I.  -c
> > /root/Temp/crosstool-ng/crosstool-ng-2008-06-19/targets/src/gcc-4.3.1/libdecnumber/dpd/decimal128.c
> > [ALL  ]rm -f libdecnumber.a
> > [ALL  ]ar cru libdecnumber.a decNumber.o decContext.o decimal32.o
> > decimal64.o decimal128.o
> > [ALL  ]i686-pc-linux-gnu-ranlib libdecnumber.a
> > [ALL  ]make[1]: Leaving directory
> > `/root/Temp/crosstool-ng/crosstool-ng-2008-06-19/targets/alphaev56-unknown-linux-gnu/build/build-cc-core-shared/libdecnumber'
> > [ALL  ]make[1]: Entering directory
> > `/root/Temp/crosstool-ng/crosstool-ng-2008-06-19/targets/alphaev56-unknown-linux-gnu/build/build-cc-core-shared/gcc'
> > [ERROR]make[1]: *** No rule to make target `libgcc.mk'.  Stop.
> > [ALL  ]make[1]: Leaving directory
> > `/root/Temp/crosstool-ng/crosstool-ng-2008-06-19/targets/alphaev56-unknown-linux-gnu/build/build-cc-core-shared/gcc'
> > [ERROR]Build failed in step 'Installing shared core C compiler'
> >
> > I couldn't find any references to this problem in the mailing list
> > archives and the Web. Any ideas?

I've looked, but haven't yet done the switch to gcc-4.3. Seems the way to
build libgcc.mk has changed between 4.2 and 4.3...

Regards,
Yann E. MORIN.

-- 
.-..--..
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +0/33 662376056 | Software  Designer | \ / CAMPAIGN |   ^|
| --==< °_° >==-- °.---:  X  AGAINST  |  /e\  There is no  |
| http://ymorin.is-a-geek.org/ | * _ * | / \ HTML MAIL|  """  conspiracy.  |
°--°---°--°°

how can I contribute ?

[Fabien Chêne]

Hi!

I would like to contribute to GCC. For now, I plan to fix bugs in
the C++ FE. Later, I will be pleased to contribute to libstdc++.
I have started to work on PR32519 and I've got a patch for
it. How can I process ? Do I need GNU copyright assignment ? Do I
need SVN right access after approval ? Otherwise, can I send the
patch on gcc-patches so that someone else will commit it for me ?

Thanks in advance,

--
Fab

Re: how can I contribute ?

[Diego Novillo]

On Wed, Jun 25, 2008 at 03:36, Fabien Chêne <[EMAIL PROTECTED]> wrote:

> How can I process ? Do I need GNU copyright assignment ? Do I
> need SVN right access after approval ? Otherwise, can I send the
> patch on gcc-patches so that someone else will commit it for me ?

I suggest reading the introductory material in
http://gcc.gnu.org/wiki/GettingStarted/

That page will point you to the legal prerequisites for contributing.
Essentially, you need to assign your copyright to the FSF unless you
are working for an institution that already has an assignment in
place.

You will also get a description of the technical aspects of the
contributing process, how to format patches, coding conventions, etc.


Diego.

CFA expression failure

[Ye, Joey]

Daniel,

We generate following DWARF2 instructions for stack alignment prologue.
Basically we use expression to calculate CFA. But it run into some
segfault in libmudflap and libjava. Do you have any hints what's wrong?

  DW_CFA_def_cfa: r4 (esp) ofs 4
  DW_CFA_offset: r8 (eip) at cfa-4
  DW_CFA_nop
  DW_CFA_nop

001c 002c 0020 FDE cie= pc=..0083
  DW_CFA_advance_loc: 1 to 0001
  DW_CFA_def_cfa_offset: 8
  DW_CFA_offset: r7 (edi) at cfa-8
  DW_CFA_advance_loc: 4 to 0005
  DW_CFA_def_cfa: r7 (edi) ofs 0
  DW_CFA_advance_loc: 7 to 000c
  DW_CFA_expression: r5 (ebp) (DW_OP_breg5: 0)
  DW_CFA_advance_loc: 37 to 0031
  DW_CFA_def_cfa_expression (DW_OP_breg5: -4; DW_OP_deref)
  DW_CFA_expression: r6 (esi) (DW_OP_breg5: -8)
  DW_CFA_expression: r3 (ebx) (DW_OP_breg5: -12)

 <_Z3bariii>:
   0:   57  push   %edi
   1:   8d 7c 24 08 lea0x8(%esp),%edi
   5:   83 e4 e0and$0xffe0,%esp
   8:   ff 77 fcpushl  -0x4(%edi)
   b:   55  push   %ebp
   c:   89 e5   mov%esp,%ebp
   e:   81 ec 88 00 00 00   sub$0x88,%esp
  14:   89 45 c4mov%eax,-0x3c(%ebp)
  17:   89 c8   mov%ecx,%eax
  19:   83 c0 1eadd$0x1e,%eax
  1c:   83 e0 f0and$0xfff0,%eax
  1f:   89 5c 24 7c mov%ebx,0x7c(%esp)
  23:   89 b4 24 80 00 00 00mov%esi,0x80(%esp)
  2a:   89 bc 24 84 00 00 00mov%edi,0x84(%esp)
  31:   29 c4   sub%eax,%esp

Thanks - Joey

Re: gcc-in-cxx branch created

[Ivan Levashew]

Ian Lance Taylor пишет:

Ivan Levashew <[EMAIL PROTECTED]> writes:


Ian Lance Taylor пишет:

The other major TODO is to work out the details of using STL
containers with GC allocated objects.  This means teaching gengtype
how to generate code to traverse STL containers, which would then be
used during GC.  This is not a task for the faint-hearted.


That's one of the many reasons against C++. Even damn Cyclone will
beat C++ here.


Your comment makes little sense in context.  Nobody could claim that
the existing gengtype code is simple.  Not many people understand how
it works at all.  In order to support STL containers holding GC
objects, it will need to be modified.


I'm sure there is a library of GC-managed components in C++.


The fact that modifying it is
nontrivial is not an argument either for or against C++.


Bruno has a better critique on C++.



I don't know what you mean by your reference to the Cyclone variant of
C, unless you are trying to say something about gcc's use of garbage
collection.



Cyclone has many options for memory management. I don't know for sure if 
there is a need for GC in GCC at all.
Cyclone has a roots not only in C, but also ML. Some techniques like 
pattern matching, aggregates, variadic arrays, tuples looks to be more 
appropriate here than their C++'s metaprogrammed template analogues.


I'm just trying to be constructive.

Compilation is IMHO a task for functional PLs, and ML heritage is a plus.
Cyclone's current implementation compiles into C, so there will be no 
bootstrapping problem as soon as there are C output in the tarballs.
Complexity of porting existing code base to C++ is comparable to one of 
porting it to Cyclone (in contrast to moving it to a functional PL).


--
If you want to get to the top, you have to start at the bottom

Re: CFA expression failure

[H.J. Lu]

On Wed, Jun 25, 2008 at 10:02:40AM +0800, Joey Ye wrote:
> Daniel,
> 
> We generate following DWARF2 instructions for stack alignment prologue.
> Basically we use expression to calculate CFA. But it run into some
> segfault in libmudflap and libjava. Do you have any hints what's wrong?
> 
>   DW_CFA_def_cfa: r4 (esp) ofs 4
>   DW_CFA_offset: r8 (eip) at cfa-4
>   DW_CFA_nop
>   DW_CFA_nop
> 
> 001c 002c 0020 FDE cie= pc=..0083
>   DW_CFA_advance_loc: 1 to 0001
>   DW_CFA_def_cfa_offset: 8
>   DW_CFA_offset: r7 (edi) at cfa-8
>   DW_CFA_advance_loc: 4 to 0005
>   DW_CFA_def_cfa: r7 (edi) ofs 0
>   DW_CFA_advance_loc: 7 to 000c
>   DW_CFA_expression: r5 (ebp) (DW_OP_breg5: 0)
>   DW_CFA_advance_loc: 37 to 0031
>   DW_CFA_def_cfa_expression (DW_OP_breg5: -4; DW_OP_deref)
>   DW_CFA_expression: r6 (esi) (DW_OP_breg5: -8)
>   DW_CFA_expression: r3 (ebx) (DW_OP_breg5: -12)
> 
>  <_Z3bariii>:
>0:   57  push   %edi
>1:   8d 7c 24 08 lea0x8(%esp),%edi
>5:   83 e4 e0and$0xffe0,%esp
>8:   ff 77 fcpushl  -0x4(%edi)
>b:   55  push   %ebp
>c:   89 e5   mov%esp,%ebp
>e:   81 ec 88 00 00 00   sub$0x88,%esp
>   14:   89 45 c4mov%eax,-0x3c(%ebp)
>   17:   89 c8   mov%ecx,%eax
>   19:   83 c0 1eadd$0x1e,%eax
>   1c:   83 e0 f0and$0xfff0,%eax
>   1f:   89 5c 24 7c mov%ebx,0x7c(%esp)
>   23:   89 b4 24 80 00 00 00mov%esi,0x80(%esp)
>   2a:   89 bc 24 84 00 00 00mov%edi,0x84(%esp)
>   31:   29 c4   sub%eax,%esp
> 

I think the problem is in uw_update_context_1.  REG_SAVED_EXP
and REG_SAVED_VAL_EXP may use other registers as shown above:

   DW_CFA_expression: r6 (esi) (DW_OP_breg5: -8)

They should be handle last.  I am testing this patch. Does it
make senses?

Joey, Xuepeng, please check out our stack branch.

Thanks.


H.J.
---
2008-06-24  H.J. Lu  <[EMAIL PROTECTED]>

* unwind-dw2.c (uw_update_context_1): Handle REG_SAVED_EXP and
REG_SAVED_VAL_EXP after other registers.

Index: gcc/unwind-dw2.c
===
--- gcc/unwind-dw2.c(revision 3051)
+++ gcc/unwind-dw2.c(working copy)
@@ -1258,6 +1258,7 @@ uw_update_context_1 (struct _Unwind_Cont
   struct _Unwind_Context orig_context = *context;
   void *cfa;
   long i;
+  long j, nexps, exps[DWARF_FRAME_REGISTERS + 1];
 
 #ifdef EH_RETURN_STACKADJ_RTX
   /* Special handling here: Many machines do not use a frame pointer,
@@ -1307,12 +1308,21 @@ uw_update_context_1 (struct _Unwind_Cont
   context->cfa = cfa;
 
   /* Compute the addresses of all registers saved in this frame.  */
+  nexps = 0;
   for (i = 0; i < DWARF_FRAME_REGISTERS + 1; ++i)
 switch (fs->regs.reg[i].how)
   {
   case REG_UNSAVED:
break;
 
+  case REG_SAVED_EXP:
+  case REG_SAVED_VAL_EXP:
+   /* Handle registers saved with REG_SAVED_EXP and
+  REG_SAVED_VAL_EXP last since they may use other
+  registers.  */
+   exps[nexps++] = i;
+   break;
+
   case REG_SAVED_OFFSET:
_Unwind_SetGRPtr (context, i,
  (void *) (cfa + fs->regs.reg[i].loc.offset));
@@ -1329,38 +1339,42 @@ uw_update_context_1 (struct _Unwind_Cont
  fs->regs.reg[i].loc.reg));
break;
 
-  case REG_SAVED_EXP:
-   {
- const unsigned char *exp = fs->regs.reg[i].loc.exp;
- _uleb128_t len;
- _Unwind_Ptr val;
-
- exp = read_uleb128 (exp, &len);
- val = execute_stack_op (exp, exp + len, &orig_context,
- (_Unwind_Ptr) cfa);
- _Unwind_SetGRPtr (context, i, (void *) val);
-   }
-   break;
-
   case REG_SAVED_VAL_OFFSET:
_Unwind_SetGRValue (context, i,
(_Unwind_Internal_Ptr)
(cfa + fs->regs.reg[i].loc.offset));
break;
+  }
 
-  case REG_SAVED_VAL_EXP:
+  if (nexps)
+{
+  const unsigned char *exp;
+  _uleb128_t len;
+  _Unwind_Ptr val;
+
+  /* Compute the addresses of registers saved with REG_SAVED_EXP
+and REG_SAVED_VAL_EXP.  They may use other registers.  */
+  orig_context = *context;
+  for (j = 0; j < nexps; ++j)
{
- const unsigned char *exp = fs->regs.reg[i].loc.exp;
- _uleb128_t len;
- _Unwind_Ptr val;
-
+ i = exps[j];
+ exp = fs->regs.reg[i].loc.exp;
  exp = read_uleb128 (exp, &len);
  val = execute_stack_op (exp, exp + len, &orig_context,
  (_Unwind_Ptr) cfa);
- _Unwind_SetGRValue (context, i, val);
+ switch (fs->regs.reg[i].how)
+   {
+   case REG_SAVED_EXP:
+   

Re: CFA expression failure

[H.J. Lu]

On Tue, Jun 24, 2008 at 08:40:18PM -0700, H.J. Lu wrote:
> On Wed, Jun 25, 2008 at 10:02:40AM +0800, Joey Ye wrote:
> > Daniel,
> > 
> > We generate following DWARF2 instructions for stack alignment prologue.
> > Basically we use expression to calculate CFA. But it run into some
> > segfault in libmudflap and libjava. Do you have any hints what's wrong?
> > 
> >   DW_CFA_def_cfa: r4 (esp) ofs 4
> >   DW_CFA_offset: r8 (eip) at cfa-4
> >   DW_CFA_nop
> >   DW_CFA_nop
> > 
> > 001c 002c 0020 FDE cie= pc=..0083
> >   DW_CFA_advance_loc: 1 to 0001
> >   DW_CFA_def_cfa_offset: 8
> >   DW_CFA_offset: r7 (edi) at cfa-8
> >   DW_CFA_advance_loc: 4 to 0005
> >   DW_CFA_def_cfa: r7 (edi) ofs 0
> >   DW_CFA_advance_loc: 7 to 000c
> >   DW_CFA_expression: r5 (ebp) (DW_OP_breg5: 0)
> >   DW_CFA_advance_loc: 37 to 0031
> >   DW_CFA_def_cfa_expression (DW_OP_breg5: -4; DW_OP_deref)
> >   DW_CFA_expression: r6 (esi) (DW_OP_breg5: -8)
> >   DW_CFA_expression: r3 (ebx) (DW_OP_breg5: -12)
> > 
> >  <_Z3bariii>:
> >0:   57  push   %edi
> >1:   8d 7c 24 08 lea0x8(%esp),%edi
> >5:   83 e4 e0and$0xffe0,%esp
> >8:   ff 77 fcpushl  -0x4(%edi)
> >b:   55  push   %ebp
> >c:   89 e5   mov%esp,%ebp
> >e:   81 ec 88 00 00 00   sub$0x88,%esp
> >   14:   89 45 c4mov%eax,-0x3c(%ebp)
> >   17:   89 c8   mov%ecx,%eax
> >   19:   83 c0 1eadd$0x1e,%eax
> >   1c:   83 e0 f0and$0xfff0,%eax
> >   1f:   89 5c 24 7c mov%ebx,0x7c(%esp)
> >   23:   89 b4 24 80 00 00 00mov%esi,0x80(%esp)
> >   2a:   89 bc 24 84 00 00 00mov%edi,0x84(%esp)
> >   31:   29 c4   sub%eax,%esp
> > 
> 
> I think the problem is in uw_update_context_1.  REG_SAVED_EXP
> and REG_SAVED_VAL_EXP may use other registers as shown above:
> 
>DW_CFA_expression: r6 (esi) (DW_OP_breg5: -8)
> 
> They should be handle last.  I am testing this patch. Does it
> make senses?
> 
> Joey, Xuepeng, please check out our stack branch.
> 
> Thanks.
> 
> 
> H.J.
> ---
> 2008-06-24  H.J. Lu  <[EMAIL PROTECTED]>
> 
>   * unwind-dw2.c (uw_update_context_1): Handle REG_SAVED_EXP and
>   REG_SAVED_VAL_EXP after other registers.
> 
> +
> +  /* Compute the addresses of registers saved with REG_SAVED_EXP
> +  and REG_SAVED_VAL_EXP.  They may use other registers.  */
> +  orig_context = *context;

It doesn't work with C++ exceptions.


H.J.

Re: gcc-in-cxx branch created

[Ross Smith]

Ian Lance Taylor wrote:


I expect that we will find it appropriate to use STL containers, as in
  for (Type::iterator p = container.begin(); p != container.end(); ++p)


For loops like this I'd recommend using some kind of FOREACH macro (the 
functional equivalent of BOOST_FOREACH; this is easy to write when you 
can use GCC's typeof feature). I've found that using a FOREACH macro 
improves code readability significantly. Not only is the normal case 
shorter and clearer, but it also means that when you do spell out a for 
loop explicitly, it acts as a signal to the reader that "we're doing 
something more complicated than straightforward iteration here, so read 
carefully".


-- Ross Smith