Re: Problem with x64 SEH macro implementation for ReactOS

[Kai Tietz]

Hi Ross,

I am very interested to learn, which parts in calling convention aren't 
implemented for w64? Do you mean the SEH stack reservation? If you could 
specify it more detailed, I could correct it for 4.5. I am a bit curious, 
as I found that the unwind mechanism of Windows itself working quite well 
on gcc compiled code, so I assumed, that the most important parts of its 
calling convention are implemented.

Cheers,
Kai

|  (\_/)  This is Bunny. Copy and paste Bunny
| (='.'=) into your signature to help him gain
| (")_(") world domination.

Re: __Unwind_GetIPInfo on Darwin 8.11

[IainS]

On 27 Nov 2008, at 01:13, Geoff Keating wrote:



On 26/11/2008, at 4:16 PM, Jack Howarth wrote:


On Wed, Nov 26, 2008 at 01:22:35PM -0800, Geoffrey Keating wrote:

Jack Howarth <[EMAIL PROTECTED]> writes:


Iain,
  The use of the system libgcc simply won't work on Mac OS X 10.4.
The missing __Unwind_GetIPInfo only exists in libgcc_s.10.5.dylib
and not libgcc_s.10.4.dylib...


Replacing or modifying the system libgcc is not recommended and may
break in the next version of Mac OS X.  It's not clear to me what  
this

will mean for GCC development.

You can see the exact commands the regression tester used in the  
build

log file at
;  
basically,


+ /Users/regress/tbox/svn-gcc/configure --prefix=/Users/regress/ 
tbox/objs --target=powerpc-apple-darwin8.5.0

+ make -j2 bootstrap
+ make -j2 -k check

No extra flags, no moving stuff around, nothing added or deleted  
from

the GCC source tree; that would defeat the purpose of the regression
tester, which is to test the actual GCC in the repository.  There is
some strangeness in the system configuration: GMP and MPFR are
installed in /usr/local as static libraries, and I seem to
remember the system is running with a modified kernel, containing a
patch which makes dejagnu work, which is why it's running 10.4.5.

10.4.11 is significantly different from 10.4.5 and from 10.5.  I
believe it adds a shared libgcc and libstdc++.  It may be that GCC
does not work on 10.4.11.

You can find the exact scripts the tester uses to run the build in
contrib/regression in the GCC source tree.  The tester checks out  
the

tree and runs the scripts from the checkout.


Geoff,
  I think you misunderstood my intention with that statement. I  
wasn't
suggesting that Iain move a libgcc.so.10.5.dylib onto a different  
machine.
Rather I meant that the offending symbol, __Unwind_GetIPInfo, was  
only added
to the system libgcc for 10.5 so that Tiger's system libgcc would  
never

be able to provide it.


I should correct an earlier statement of mine: 10.4.11 does not add  
a shared libgcc.  My 10.4.5 machine has a shared libgcc which  
indeed does not have __Unwind_GetIPInfo.  However, this does not  
prevent GCC building on it.



Geoff,

Thanks for pointing to the scripts; I'll examine them in more detail.

There was never  a problem *building* gcc, nor is there apparently  
any problem once installed to the correct place.
[ i.e. Once the compiler is installed (and it is used to generate  
code from its installed position) everything is apparently OK.]


The problem was failures in "make check" (esp. with an uninstalled,  
newly built, compiler)
the failures were caused by the fact that the newly-built libgcc was  
not being found - and the symbol(s) are not present in /usr/lib/libgcc*


In fact, as far as g++ and libstdc++ tests are concerned, this was  
apparently a temporary glitch and the test results are looking the  
same as "regress" now.


===

However, I still find similar a problem with libgomp (see http:// 
gcc.gnu.org/ml/fortran/2008-11/msg00320.html )


This is repeatable on several machines...

.. so there is something I've got installed, or something I'm doing  
differently (or wrong) and I'd like to get to the bottom of it.  This  
is a very time-consuming activity - it would be a shame to waste the  
processor cycles and man-hours.


As far as the OS is concerned - I take care not to interfere with it;  
any added stuff is in /opt,  /sw, /xusr and very occasionally /usr/ 
local.
These are, however, in-use live systems with 3rd party apps and  
drivers - so it's not impossible that something has been horked by  
one of those.


FWIW I am using dejagnu-1-4-4 which seems to build and install  
without any change or addition to OSX.


the PATH I use (on darwin8) for the configure/build/check is:
"/usr/local/dejagnu-1-4-4/bin:/bin:/sbin:/usr/bin:/usr/sbin"

I'm building GMP (4.2.4) and MPFR(2.3.2) in the gcc tree - but that  
makes no material difference to the observation AFAICT.


thanks,
Iain

Re: Problem with x64 SEH macro implementation for ReactOS

[Ross Ridge]

Kai Tietz writes:
>I am very interested to learn, which parts in calling convention aren't 
>implemented for w64? 

Well, maybe I'm missing something but I can't any see code in GCC for
generating prologues, epilogues and unwind tables in the format required
by the Windows x64 ABI.

http://msdn.microsoft.com/en-us/library/tawsa7cb.aspx

>I am a bit curious, as I found that the unwind mechanism of Windows
>itself working quite well on gcc compiled code, so I assumed, that the
>most important parts of its calling convention are implemented.

How exactly are you testing this?  Without SEH support Windows wouldn't
ordinarily ever need to unwind through GCC compiled code.  I assumed
that's why it was never implemented.

Ross Ridge

GCC 4.4.0 Status Report (2008-11-27)

[Joseph S. Myers]

Status
==

Trunk is in Stage 4 (regression and documentation fixes mode).

GCC 4.4 will be branched when there are no open P1 regressions for 4.4
and the total number of P1, P2 and P3 regressions for 4.4 is 100 or
below.  Trunk will open for Stage 1 for GCC 4.5 immediately after 4.4
branches, and 4.4.0-rc1 will be made from the branch shortly after
branching.

The old register allocator has not yet been removed but should be
removed soon.  The list of targets not yet converted to IRA is
unchanged from the previous report:

arc
m32c
m68hc11
mmix
pdp11
score
vax

Unconverted targets will be added to the deprecation list when the old
allocator is removed, and removed from trunk along with the other
deprecated targets shortly after 4.4 branches; until then, target
maintainers may remove them from the deprecation list as part of the
patch converting them to IRA without any further approval for the
undeprecation being needed.  Although some people have suggested they
might work on conversion of some of these targets, the only one I am
aware of actual activity on converting is m32c.

Vladimir, is there any news on the patch to remove the old allocator
since , or on getting
m32c and IRA working together?

There is as yet no installation documentation in install.texi pointing
to the libraries required for Graphite, but since a suitable PPL
release is now available it should be possible for a corresponding
Cloog release to be made, tarballs to be placed in the infrastructure
directory and documentation updated.

Quality Data


Priority  # Change from Last Report
--- ---
P19 -  4
P2  105 -  9
P3   11 +  8
--- ---
Total   125 -  5

There are a total of 5150 open bugs in Bugzilla, counting both
regressions and non-regressions.  It seems quite likely that many of
the older bugs have in fact been fixed since they were filed, but we
don't have any good procedures for occasionally reviewing bugs to see
if they are still applicable to current trunk.

Previous Report
===

http://gcc.gnu.org/ml/gcc/2008-11/msg00187.html

The next report for 4.4.0 will be sent by Mark.

-- 
Joseph S. Myers
[EMAIL PROTECTED]

Re: Problem with x64 SEH macro implementation for ReactOS

[Kai Tietz]

2008/11/27 Ross Ridge <[EMAIL PROTECTED]>:
> Kai Tietz writes:
>>I am very interested to learn, which parts in calling convention aren't
>>implemented for w64?
>
> Well, maybe I'm missing something but I can't any see code in GCC for
> generating prologues, epilogues and unwind tables in the format required
> by the Windows x64 ABI.
>
>http://msdn.microsoft.com/en-us/library/tawsa7cb.aspx
>
>>I am a bit curious, as I found that the unwind mechanism of Windows
>>itself working quite well on gcc compiled code, so I assumed, that the
>>most important parts of its calling convention are implemented.
>
> How exactly are you testing this?  Without SEH support Windows wouldn't
> ordinarily ever need to unwind through GCC compiled code.  I assumed
> that's why it was never implemented.
>
>Ross Ridge
>
>

Well, you mean the SEH tables on stack. Well, those aren't implemented
(as they aren't for 32-bit). But the the unwinding via  RtlUnwind and
RtlUnwindEx do their job even for gcc compiled code quite well.

Cheers,
Kai
-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination

Re: GCC 4.4.0 Status Report (2008-11-27)

[Jeff Law]

Joseph S. Myers wrote:

Vladimir, is there any news on the patch to remove the old allocator
since , or on getting
m32c and IRA working together?
  
Vlad is relatively busy dealing with PRs as they're reported, the 
optimization regressions in particular take considerable time due to 
benchmarking.


It's my understanding Vlad has a patch to remove the old allocator, but 
it's become somewhat dated and probably doesn't apply to the trunk.  If 
Vlad will pass that patch along, I'll pick it up.


For the m32c, Vlad has a patch which was supposed to help deal with 
specific issues that arise on the m32c; that patch needs updating so 
that DJ & I can look at the m32c again.



Jeff

Re: GCC 4.4.0 Status Report (2008-11-27)

[Vladimir Makarov]

Jeff Law wrote:

Joseph S. Myers wrote:

Vladimir, is there any news on the patch to remove the old allocator
since , or on getting
m32c and IRA working together?
  
Vlad is relatively busy dealing with PRs as they're reported, the 
optimization regressions in particular take considerable time due to 
benchmarking.



That is right, Jeff.  The most time takes optimization regression PRs.
It's my understanding Vlad has a patch to remove the old allocator, 
but it's become somewhat dated and probably doesn't apply to the 
trunk.  If Vlad will pass that patch along, I'll pick it up.


Yes, that is right.  I have the patch to remove old RA ready.  The last 
time it was synchronized a week ago.  So it is pretty fresh.  I need a 
day to check it again.
For the m32c, Vlad has a patch which was supposed to help deal with 
specific issues that arise on the m32c; that patch needs updating so 
that DJ & I can look at the m32c again.


I am working on m32c and mostly done with that.  I am going to submit 
the patch tomorrow.  It makes small changes to IRA and implements Chow's 
priority coloring (for regional or all function RA) which permits to use 
intersected register classes.  In fact, it permits not to describe 
IRA_COVER_CLASESS for some weird targets (like m32c).  But without 
description of this macro, target can not use a better Chaitin-Briggs 
RA.  This patch will permit to use IRA for all targets even without 
porting them to IRA.


So if nobody objects, I could submit the patch removing the old RA on 
next week for review and commit it after getting an approval and after 
committing patch for priority coloring.

Re: Problem with x64 SEH macro implementation for ReactOS

[Ross Ridge]

Kai Tietz writes:
>Well, you mean the SEH tables on stack.

No, I mean the ABI required unwind information. 

> Well, those aren't implemented (as they aren't for 32-bit).

64-bit SEH handling is completely different from 32-bit SEH handling.
In the 64-bit Windows ABI exceptions are handled using unwind tables
similar in concept to DWARF2 exceptions.  There are no SEH tables on
the stack.  In the 32-bit ABI exceptions are handled using a linked list
of records on the stack, similar to SJLJ exceptions.

> But the the unwinding via  RtlUnwind and RtlUnwindEx do their job even
>for gcc compiled code quite well

I don't see how it would be possible in the general case.  Without the
unwind talbes Windows doesn't have the required information to unwind
through GCC compiled functions.

Ross Ridge

gcc-4.3-20081127 is now available

[gccadmin]

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

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

You'll find:

gcc-4.3-20081127.tar.bz2  Complete GCC (includes all of below)

gcc-core-4.3-20081127.tar.bz2 C front end and core compiler

gcc-ada-4.3-20081127.tar.bz2  Ada front end and runtime

gcc-fortran-4.3-20081127.tar.bz2  Fortran front end and runtime

gcc-g++-4.3-20081127.tar.bz2  C++ front end and runtime

gcc-java-4.3-20081127.tar.bz2 Java front end and runtime

gcc-objc-4.3-20081127.tar.bz2 Objective-C front end and runtime

gcc-testsuite-4.3-20081127.tar.bz2The GCC testsuite

Diffs from 4.3-20081120 are available in the diffs/ subdirectory.

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

Several puzzles about gcc top level makefile

[Cheng bin]

Hi Groups:
Right now I am studying the procedure of building gcc(mipsel cross
compiler), so I look into the makefiles generated by configure
procedure.
This message is about the top level makefile, I got most of it (It's
some kind of well structured) except several puzzles as following

1  : At the end of that makefile , There is a section noted as
"Regenerating top level configury".
  It is clear what it do, but for what? Where is this piece of
code used in building procedure?
2  : At lines around 462, There is a variable named "RECURSE_FLAGS", I
also puzzled
  about its usage. It says that "When doing recursive invocations
of the top-level Makefile,
  we don't want the outer make to evaluate them, so we pass these
variables down
  unchanged. " Does it mean we will recall the top level makefile?
  if so, Is "RECURSE_FLAGS" have any relations with the first
question. Maybe both
  "Regenerating top level configury" and "RECURSE_FLAGS" is used
to  compile gcc
  several times in bootstrap.
  Here I need a confirmation.
3  : For the cross compiler, I configured and compiled gcc twice, once
with just language C
  supported, once with languages C/C++ supported. I compared the
two top level makefile
  generated by configure and found the difference is that
libiberty and libstdc++-v3 is
  compiled for target at the second time. So here is the question:
libstdc++v3 is compiled
  for target as the c++ runtime library, but what libiberty for? I
can only infer that libstdc++v3
  needs it(otherwise why the first time which only supports c
language do not have it
  compiled?). Unfortunately, I did not find any code in
libstdc++-v3 which calls functions
  in libiberty.

Following is the arguments I used to configure makefile two times, if it useful.
   First time (for C):

/cygdrive/e/work/buildroot/buildroot/toolchain_build_mipsel_nofpu/gcc-3.4.2/configure
--prefix=/cygdrive/e/work/buildroot/buildroot/build_mipsel_nofpu/staging_dir
--build=i386-pc-linux-gnu --host=i386-pc-linux-gnu
--target=mipsel-linux-uclibc --enable-languages=c
--with-sysroot=/cygdrive/e/work/buildroot/buildroot/toolchain_build_mipsel_nofpu/uClibc_dev/
--disable-__cxa_atexit --enable-target-optspace --with-gnu-ld
--disable-shared --disable-nls --enable-threads --enable-multilib
--with-float=soft
---
   Second time (for C&C++):

/cygdrive/e/work/buildroot/buildroot/toolchain_build_mipsel_nofpu/gcc-3.4.2/configure
--prefix=/cygdrive/e/work/buildroot/buildroot/build_mipsel_nofpu/staging_dir
--build=i386-pc-linux-gnu --host=i386-pc-linux-gnu
--target=mipsel-linux-uclibc --enable-languages=c
--disable-__cxa_atexit --enable-target-optspace --with-gnu-ld
--enable-shared --disable-nls --enable-threads --enable-multilib
--with-float=soft
---

Thanks is advance and any messages will be appreciated.

Best wishes.

Re: GCC 4.4.0 Status Report (2008-11-27)

[liqin]

Joseph S. Myers wrote: 
> Unconverted targets will be added to the deprecation list when the old
> allocator is removed, and removed from trunk along with the other
> deprecated targets shortly after 4.4 branches; until then, target
> maintainers may remove them from the deprecation list as part of the
> patch converting them to IRA without any further approval for the
> undeprecation being needed.

I am working on gcc score target maintain,
because we are busy on port linux for score chip,
so have not pay attention to gcc upgrade recently.

I will update gcc score backend soon, if it could
not catch up gcc 4.4 release, i will move it to lastest
gcc(4.4) from undeprection list.

liqin