Re: RFC: Add 32bit x86-64 support to binutils

[Jakub Jelinek]

On Thu, Dec 30, 2010 at 01:42:05PM -0800, H. Peter Anvin wrote:
> On 12/30/2010 11:57 AM, Jakub Jelinek wrote:
> >>
> >> Would be nice if LFS would be mandatory on the new ABI, thus
> >> off_t being 64bits.
> > 
> > And avoid ambiguous cases that x86-64 ABI has, e.g. whether
> > caller or callee is responsible for sign/zero extension of arguments, to
> > avoid the need to sign/zero extend twice, etc.
> > 
> 
> Ehwhat?  x86-64 is completely unambiguous on that point; the i386 one is
> not.

It is not, sadly, see http://gcc.gnu.org/PR46942
>From what I can see the psABI doesn't talk about it, GCC usually sign/zero
extends on both sides (exception is 32-bit arguments into 64-bit isn't
apparently sign/zero extended on the caller side when doing tail calls),
from what I gathered LLVM expects the caller to sign/zero extend (which is
incompatible with GCC tail calls then), not sure about ICC, and kernel
probably expects for security reasons that the callee sign/zero extends.

Jakub

Re: Behavior change of driver on multiple input assembly files

[Jie Zhang]

On 12/31/2010 01:07 PM, Jie Zhang wrote:

I just found a behavior change of driver on multiple input assembly
files. Previously (before r164357), for the command line

gcc -o t t1.s t2.s

, the driver will call assembler twice, once for t1.s and once for t2.s.
After r164357, the driver will only call assembler once for t1.s and
t2.s. Then if t1.s and t2.s have same symbol, assembler will report an
error, like:

t2.s: Assembler messages:
t2.s:1: Error: symbol `.L1' is already defined

I read the discussion on the mailing list starting by the patch email of
r164357.[1] It seems that this behavior change is not the intention of
that patch. And I think the previous behavior is more useful than the
current behavior. So it's good to restore the previous behavior, isn't?

For a minimal fix, I propose to change combinable fields of assembly
languages in default_compilers[] to 0. See the attached patch
"gcc-not-combine-assembly-inputs.diff". I don't know why the combinable
fields were set to 1 when --combine option was introduced. There is no
explanation about that in that patch email.[2] Does anyone still remember?

For an aggressive fix, how about removing the combinable field from
"struct compiler"? If we change combinable fields of assembly languages
in default_compilers[] to 0, only ".go" and "@cpp-output" set combinable
to 1. I don't see any reason for difference between "@cpp-output" and
".i". So if we can set combinable to 0 for ".go", we have 0 for all
compilers in default_compilers[], thus we can remove that field. Is
there a reason to set 1 for ".go"?

I also attached the aggressive patch "gcc-remove-combinable-field.diff".
Either patch is not tested. Which way should we go?

The minimal fix has no regressions. But the aggressive one has a lot of 
regressions.



[1] http://gcc.gnu.org/ml/gcc-patches/2010-09/msg01322.html
[2] http://gcc.gnu.org/ml/gcc-patches/2004-03/msg01880.html


Regards,



--
Jie Zhang

Re: [MIPS] Test case dspr2-MULT is failed

[Richard Sandiford]

Mingjie Xing  writes:
> There are two test cases failed when run 'make check-gcc
> RUNTESTFLAGS="mips.exp"'.  The log is,
>
> Executing on host: /home/xmj/tools/build-test-trunk-mips/gcc/xgcc
> -B/home/xmj/tools/build-test-trunk-mips/gcc/
> /home/xmj/tools/test-trunk/gcc/testsuite/gcc.target/mips/dspr2-MULT.c
>  -DNOMIPS16=__attribute__((nomips16)) -mabi=32 -mips32r2 -mgp32 -O2
> -mdspr2 -mtune=74kc -ffixed-hi -ffixed-lo -S  -o dspr2-MULT.s
> (timeout = 300)
> PASS: gcc.target/mips/dspr2-MULT.c (test for excess errors)
> PASS: gcc.target/mips/dspr2-MULT.c scan-assembler \tmult\t
> PASS: gcc.target/mips/dspr2-MULT.c scan-assembler ac1
> FAIL: gcc.target/mips/dspr2-MULT.c scan-assembler ac2
> Executing on host: /home/xmj/tools/build-test-trunk-mips/gcc/xgcc
> -B/home/xmj/tools/build-test-trunk-mips/gcc/
> /home/xmj/tools/test-trunk/gcc/testsuite/gcc.target/mips/dspr2-MULTU.c
>   -DNOMIPS16=__attribute__((nomips16)) -mabi=32 -mips32r2 -mgp32 -O2
> -mdspr2 -mtune=74kc -ffixed-hi -ffixed-lo -S  -o dspr2-MULTU.s
> (timeout = 300)
> PASS: gcc.target/mips/dspr2-MULTU.c (test for excess errors)
> PASS: gcc.target/mips/dspr2-MULTU.c scan-assembler \tmultu\t
> PASS: gcc.target/mips/dspr2-MULTU.c scan-assembler ac1
> FAIL: gcc.target/mips/dspr2-MULTU.c scan-assembler ac2
>
> Is it a bug?

It's a register-allocation optimisation regression that's been around
for quite a long time now (probably over a year).  We're not making as
much use of the 4 accumulator registers as we should.

In truth, I don't think we ever really made good use of them anyway.
ISTR that trivial modifications of the testcase failed even before
the regression.

Richard

Re: RFC: Add 32bit x86-64 support to binutils

[H.J. Lu]

On Fri, Dec 31, 2010 at 2:03 AM, Jakub Jelinek  wrote:
> On Thu, Dec 30, 2010 at 01:42:05PM -0800, H. Peter Anvin wrote:
>> On 12/30/2010 11:57 AM, Jakub Jelinek wrote:
>> >>
>> >> Would be nice if LFS would be mandatory on the new ABI, thus
>> >> off_t being 64bits.
>> >
>> > And avoid ambiguous cases that x86-64 ABI has, e.g. whether
>> > caller or callee is responsible for sign/zero extension of arguments, to
>> > avoid the need to sign/zero extend twice, etc.
>> >
>>
>> Ehwhat?  x86-64 is completely unambiguous on that point; the i386 one is
>> not.
>
> It is not, sadly, see http://gcc.gnu.org/PR46942
> From what I can see the psABI doesn't talk about it, GCC usually sign/zero
> extends on both sides (exception is 32-bit arguments into 64-bit isn't
> apparently sign/zero extended on the caller side when doing tail calls),
> from what I gathered LLVM expects the caller to sign/zero extend (which is
> incompatible with GCC tail calls then), not sure about ICC, and kernel
> probably expects for security reasons that the callee sign/zero extends.

I prefer caller to do sign/zero extension so that we don't update partial
register.

-- 
H.J.

Re: RFC: Add 32bit x86-64 support to binutils

[H.J. Lu]

On Thu, Dec 30, 2010 at 4:48 PM, H.J. Lu  wrote:
> On Thu, Dec 30, 2010 at 4:42 PM, H. Peter Anvin  wrote:
>> On 12/30/2010 01:08 PM, Robert Millan wrote:
>>> Hi folks,
>>>
>>> I had this unsubmitted patch in my local filesystem.  It makes Linux
>>> detect ELF32 AMD64 binaries and sets a flag to restrict them to
>>> 32-bit address space.
>>>
>>> It's not rocket science but can save you some work in case you
>>> haven't implemented this already.
>>>
>>
>> I have pushed my old kernel patches to a git tree at:
>>
>> git://git.kernel.org//pub/scm/linux/kernel/git/hpa/linux-2.6-ilp32.git
>>
>> They are currently based on 2.6.31 since that was the released version
>> when I first did this work; they are not intended to be mergeble but
>> rather as a prototype.
>>
>> Note that we have no intention of supporting this ABI for the kernel
>> itself.  The kernel will be a normal x86-64 kernel.
>>
>
> Here is the updated ILP32 patch for 2.6.35.
>
>

I put my ILP32 gdb on hjl/ilp32 branch at

http://git.kernel.org/?p=devel/gdb/hjl/x86.git;a=summary

and my gcc 4.4 ILP32 on hjl/ilp32/gcc-4_4-branch branch at

http://git.kernel.org/?p=devel/gcc/hjl/x86.git;a=summary


-- 
H.J.

[wwwdocs] PATCH for Re: rsync'd repo size

[Gerald Pfeifer]

On Wed, 8 Dec 2010, DJ Delorie wrote:
> http://gcc.gnu.org/rsync.html says 17 Gb.
> 
> I just did it, and it's up to 22 Gb.

Thanks for the heads up, DJ!  I had a look, and it is, in fact,
184 Gb as of today, or 23 GB.  (SCNR. :-)

I am applying the patch below.

Gerald

Index: rsync.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/rsync.html,v
retrieving revision 1.18
diff -u -r1.18 rsync.html
--- rsync.html  22 Jan 2009 10:03:54 -  1.18
+++ rsync.html  31 Dec 2010 16:25:33 -
@@ -18,7 +18,7 @@
 Getting a local copy of GCC repository using rsync
 
 The GCC repository is available at rsync://gcc.gnu.org/gcc-svn.
-The whole repository currently takes about 17G of disk space,
+The whole repository currently takes about 23GB of disk space,
 which takes a substantial time to transfer.
 Subsequent synchronizations will be much faster, though, as rsync uses
 a smart algorithm to only transfer differences over the network.

Re: RFC: Add 32bit x86-64 support to binutils

[H.J. Lu]

On Fri, Dec 31, 2010 at 2:03 AM, Jakub Jelinek  wrote:
> On Thu, Dec 30, 2010 at 01:42:05PM -0800, H. Peter Anvin wrote:
>> On 12/30/2010 11:57 AM, Jakub Jelinek wrote:
>> >>
>> >> Would be nice if LFS would be mandatory on the new ABI, thus
>> >> off_t being 64bits.
>> >
>> > And avoid ambiguous cases that x86-64 ABI has, e.g. whether
>> > caller or callee is responsible for sign/zero extension of arguments, to
>> > avoid the need to sign/zero extend twice, etc.
>> >
>>
>> Ehwhat?  x86-64 is completely unambiguous on that point; the i386 one is
>> not.
>
> It is not, sadly, see http://gcc.gnu.org/PR46942
> From what I can see the psABI doesn't talk about it, GCC usually sign/zero
> extends on both sides (exception is 32-bit arguments into 64-bit isn't
> apparently sign/zero extended on the caller side when doing tail calls),
> from what I gathered LLVM expects the caller to sign/zero extend (which is
> incompatible with GCC tail calls then), not sure about ICC, and kernel
> probably expects for security reasons that the callee sign/zero extends.
>
>        Jakub
>

I added

---
When a value of type signed/unsigned char or short is returned or passed
in a register or on the stack, it should be sign/zero extended to
signed/unsigned
int.
---

to hjl/extension branch at

http://git.kernel.org/?p=devel/binutils/hjl/x86-64-psabi.git;a=summary


-- 
H.J.

Re: RFC: Add 32bit x86-64 support to binutils

[H.J. Lu]

On Fri, Dec 31, 2010 at 8:50 AM, H.J. Lu  wrote:
> On Fri, Dec 31, 2010 at 2:03 AM, Jakub Jelinek  wrote:
>> On Thu, Dec 30, 2010 at 01:42:05PM -0800, H. Peter Anvin wrote:
>>> On 12/30/2010 11:57 AM, Jakub Jelinek wrote:
>>> >>
>>> >> Would be nice if LFS would be mandatory on the new ABI, thus
>>> >> off_t being 64bits.
>>> >
>>> > And avoid ambiguous cases that x86-64 ABI has, e.g. whether
>>> > caller or callee is responsible for sign/zero extension of arguments, to
>>> > avoid the need to sign/zero extend twice, etc.
>>> >
>>>
>>> Ehwhat?  x86-64 is completely unambiguous on that point; the i386 one is
>>> not.
>>
>> It is not, sadly, see http://gcc.gnu.org/PR46942
>> From what I can see the psABI doesn't talk about it, GCC usually sign/zero
>> extends on both sides (exception is 32-bit arguments into 64-bit isn't
>> apparently sign/zero extended on the caller side when doing tail calls),
>> from what I gathered LLVM expects the caller to sign/zero extend (which is
>> incompatible with GCC tail calls then), not sure about ICC, and kernel
>> probably expects for security reasons that the callee sign/zero extends.
>>
>>        Jakub
>>
>
> I added
>
> ---
> When a value of type signed/unsigned char or short is returned or passed
> in a register or on the stack, it should be sign/zero extended to
> signed/unsigned
> int.
> ---
>
> to hjl/extension branch at
>
> http://git.kernel.org/?p=devel/binutils/hjl/x86-64-psabi.git;a=summary
>

According to

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42324

all compilers clears bits 1-31 when passing _Bool to a function.  Also
GCC doesn't
sign/zero extend on char/short return.  I updated x86-64 psABI to


When a value of type _Bool is returned in a register, bit 0 contains the truth
value and bits 1 to 7 shall be zero. When an argument of type _Bool is passed
in a register or on the stack, bit 0 contains the truth value and bits
1 to 31 shall be
zero.

When a value of type signed/unsigned char or short is returned in a register,
bits 0 to 7 for char and bits 0 to 15 for short contain the value and other
bits are left unspecified. When an argument of signed/unsigned type char or
short is passed in a register or on the stack, it shall be sign/zero extended to
signed/unsigned int.
---

on hjl/extension branch at

http://git.kernel.org/?p=devel/binutils/hjl/x86-64-psabi.git;a=summary


-- 
H.J.

Re: [wwwdocs] PATCH for Re: rsync'd repo size

[Mike Stump]

On Dec 31, 2010, at 8:27 AM, Gerald Pfeifer wrote:
> On Wed, 8 Dec 2010, DJ Delorie wrote:
>> http://gcc.gnu.org/rsync.html says 17 Gb.
>> 
>> I just did it, and it's up to 22 Gb.
> 
> Thanks for the heads up, DJ!  I had a look, and it is, in fact,
> 184 Gb as of today, or 23 GB.  (SCNR. :-)

You can replace it with a equation that has a year in it, that way, you don't 
have to fix it as often...  :-)

Re: Behavior change of driver on multiple input assembly files

[H.J. Lu]

On Fri, Dec 31, 2010 at 5:08 AM, Jie Zhang  wrote:
> On 12/31/2010 01:07 PM, Jie Zhang wrote:
>>
>> I just found a behavior change of driver on multiple input assembly
>> files. Previously (before r164357), for the command line
>>
>> gcc -o t t1.s t2.s
>>
>> , the driver will call assembler twice, once for t1.s and once for t2.s.
>> After r164357, the driver will only call assembler once for t1.s and
>> t2.s. Then if t1.s and t2.s have same symbol, assembler will report an
>> error, like:
>>
>> t2.s: Assembler messages:
>> t2.s:1: Error: symbol `.L1' is already defined
>>
>> I read the discussion on the mailing list starting by the patch email of
>> r164357.[1] It seems that this behavior change is not the intention of
>> that patch. And I think the previous behavior is more useful than the
>> current behavior. So it's good to restore the previous behavior, isn't?
>>
>> For a minimal fix, I propose to change combinable fields of assembly
>> languages in default_compilers[] to 0. See the attached patch
>> "gcc-not-combine-assembly-inputs.diff". I don't know why the combinable
>> fields were set to 1 when --combine option was introduced. There is no
>> explanation about that in that patch email.[2] Does anyone still remember?
>>
>> For an aggressive fix, how about removing the combinable field from
>> "struct compiler"? If we change combinable fields of assembly languages
>> in default_compilers[] to 0, only ".go" and "@cpp-output" set combinable
>> to 1. I don't see any reason for difference between "@cpp-output" and
>> ".i". So if we can set combinable to 0 for ".go", we have 0 for all
>> compilers in default_compilers[], thus we can remove that field. Is
>> there a reason to set 1 for ".go"?
>>
>> I also attached the aggressive patch "gcc-remove-combinable-field.diff".
>> Either patch is not tested. Which way should we go?
>>
> The minimal fix has no regressions. But the aggressive one has a lot of
> regressions.
>
>> [1] http://gcc.gnu.org/ml/gcc-patches/2010-09/msg01322.html
>> [2] http://gcc.gnu.org/ml/gcc-patches/2004-03/msg01880.html
>>

I opened:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47137

This simple patch also works for me.

-- 
H.J.
---
diff --git a/gcc/gcc.c b/gcc/gcc.c
index 69bf033..0d633a4 100644
--- a/gcc/gcc.c
+++ b/gcc/gcc.c
@@ -6582,7 +6582,7 @@ warranty; not even for MERCHANTABILITY or
FITNESS FOR A PARTICULAR PURPOSE.\n\n"

   explicit_link_files = XCNEWVEC (char, n_infiles);

-  combine_inputs = have_o || flag_wpa;
+  combine_inputs = flag_wpa;

   for (i = 0; (int) i < n_infiles; i++)
 {

Re: 確認ですが・・・

[前田 篤志]

お疲れ様です。高橋です。

那須ＰＭの件ですが、
退職という話が上がっていましたが、退職することはなくなりました。
来期の体制において、ＰＭ職ではなく営業を行う位置で業務を行っていきます。
本決定ではないですが、来期はインフラをシステム部門に吸収して、
那須君においては、営業（社内案件、外注両方）に専念する形になると思います。
そこで利益を出してもらう形式となる予定です。
そのあたりについては、一度打ち合わせをしたいと考えています。

また、星野の件ですが、6月いっぱいで退職となる予定です。
本人と那須君が話し合った結果、ＩＴ業界ではなくたの業界で仕事をしたいと
いう結論に至ったようです。この話は飯島君の知っています



On Fri, 28 Mar 2008 14:41:35 +0900
"前田　篤志"  wrote:

> お疲れさまです、前田です。
> 
> 
> 那須さんっていつまで（3月？）でしたっけ？
> 
> というのも、鵜沼、星野の方向性を決めないといけないんですが
> 那須さんからのフィードバックが無いので、困ってます。
> 
> 
> 以上、よろしくお願い致します。

Re: 【詳細】決起集会の詳細情報がきまりました！！

[前田 篤志]

> オレと森さんが一緒でいいんだぁ〜。

> ふ〜ん、まぁ、オレが高橋さんの分を
> ちょいと持つってのもアリだから
> 高橋さんと相談します。

そんな、私に言われましても・・・（＾＾；
金額決めたのは私じゃないですし・・・。

すみませんが、宜しくお願いします。

***
   (株)システムクレール
   システム開発事業部
   営業
金子 悟 (Satoru Kaneko)
TEL 03-3851-3931   FAX 03-3851-3944
URL http://www.claire.co.jp
e-mail  skan...@claire.co.jp
　　　〒101-0032
 　　東京都千代田区岩本町3丁目9番地17号 スリーセブンビル５階

- Original Message - 
From: ""前田　篤志"" 
To: "Satoru Kaneko" 
Sent: Tuesday, June 03, 2008 2:00 PM
Subject: Re: 【詳細】決起集会の詳細情報がきまりました！！


> オレと森さんが一緒でいいんだぁ〜。
> ふ〜ん、まぁ、オレが高橋さんの分を
> ちょいと持つってのもアリだから
> 高橋さんと相談します。
>
>
>> お疲れ様です、悟です。
>>
>> 会費負担額の詳細を報告します。
>>
>> 高橋社長：48,000円
>> 森さん　　：11,000円
>> 前田さん ：11,000円
>>
>> 上記のようになっているそうです。
>>
>> 以上、宜しくお願い致します。
>>
>> ***
>> (株)システムクレール
>> システム開発事業部
>> 営業
>>  金子 悟 (Satoru Kaneko)
>>  TEL 03-3851-3931   FAX 03-3851-3944
>>  URL http://www.claire.co.jp
>>  e-mail  skan...@claire.co.jp
>> 　　　〒101-0032
>>   　　東京都千代田区岩本町3丁目9番地17号 スリーセブンビル５階
>> 
>>
>
> 

６月の売上実績並びに手数料の件

[前田 篤志]

(株)プロリンク　福井様

いつもお世話になっています。システムクレール高橋です。

６月の売上実績並びにプロリンク営業手数料について、ご通知致します。
ご不明な点など御座いましたら、ご連絡ください。
宜しくお願い申し上げます。

（株）東京システム技研 10,279,500 
（株）ジャパンコンピュータサービス   2,656,500 
（株）プロリンク1,414,520 
東京エレクトロンＳＴ（株）   3,780,000 
キヤノンネットワークＣｏｍ（株）1,295,090 
（株）NTＴコミュニケーションズ1,496,250 
（株）工芸精機製作所  567,000 
（株）ＧＯＯＹＡ609,000 
（株）ぴーぷる 1,890,000 
（株）ユニケソフトウエアリサーチ2,614,500 
（株）エーアールシー  1,089,880 
（株）ＴＩＳサービス  1,891,760 
（株）ヒューマンネットワーク  3,553,698 
（株）さくらＫＣＳ   735,000 
（株）紀文フレッシュシステム  504,000 
（株）エルバーラスイス 456,750 
（株）シースリーアイ  724,500 
（株）アクトブレーン  661,500 
（株）日本テクノ4,633,353 
（株）コアソフト462,210 
（株）エスワイシステム 883,596 
（株）ＧＳＩ  955,867 
 合計 43,154,474 

　プロリンク営業手数料（４％）  1,641,505  
　プロリンク人件費1,099,520  

以上
$
(株)システムクレール   高橋淳司 Junji Takahashi
 TEL 03-3851-3931  FAX 03-3851-3944
 URL www.claire.co.jp
 E-mail takaha...@claire.co.jp
$

Re: 諸々のこと

[前田 篤志]

お疲れ様です。高橋です。

取り急ぎ、株の件のみ報告します。

本日中に株取得に関しての案内を全社へ送信します。
下記に記述されている事項をある程度含んだものを
こちらでも作成していますのでそれで通知を行います。

宜しくお願い致します。


On Thu, 26 Jun 2008 13:03:08 +0900
"前田　篤志"  wrote:

> 高橋さん
> 
> お疲れさまです、前田です。
> 
> 
> 以下、諸々のことについて、私の考えを記します。
> 
> 
> ■社員持ち株について
> 　先日のスタッフ会議で話が挙がりました
> 　社員持ち株についてですが、これから周知すると思いますが
> 　スタッフ会議での印象として、株を持つことへの意欲や
> 　興味は一定以上はありますが、5株以上という話になった時
> 　正直な印象として、引いていたような感がありました。
> 　これは、金額が思った以上に多いと感じていることが
> 　ありますが、反面、株を持つ前提条件をしっかりと
> 　認識していないことがあります。
> 　株を持つことの意義や責任感が生まれることもそうですが
> 　これまでの配当結果も重要な情報の一つだと思っています。
> 
> ■査定基準について
> 　給与及び賞与の査定基準ですが、一定のところでは
> 　決定できるものですが、やはり、もう少し貢献度を
> 　明確に出せる方法がないか要検討と感じています。
> 　以前、査定基準をベースに再検討できればと思っています。
> 
> ■クレール−プロリンクについて
> 　昨日の打ち合わせでも話しましたが、やはり早急に
> 　対会社として話し合いをするべきだと感じていますので
> 　吉原社長との打ち合わせをセッティングしてもらえますか？
> 　また、前社長のスタンス、昨日の愚痴の続きになっちゃいますが
> 　正直、創業者としてのクレールの愛着や積極的なバックアップを
> 　するという意識負の遺産（という表現をしますが）のリカバリ
> 　するという気持ちが現時点までの行動や言動から、全く無いように
> 　感じています。我関せずでは、役割として顧問は不適格です。
> 　多額の出資をしているプロリンクとの関係も否定するような
> 　発言で、さすがに私も失望感がいっぱいでしたが
> 　とりあえずは、我慢することにしましたが、次回はないですね。
> 　そんなことを払拭するための対会社間の打ち合わせが重要に
> 　なってくると感じています。
> 
> 
> 色々と記しましたが、明日の取締役会の前情報として
> 書きました。
> 
> 
> 以上、よろしくお願い致します。
> 

Re: 社員会要綱修正

[前田 篤志]

おつかれです。

> ■
> スタッフ会議の議事録には・・・
> → 9月までに要綱を変更し、9月から運用開始。（変更内容を高原→高橋常務に連絡）
> って書いてあって、誰が周知とは書いてないので、高橋さんと相談して決めて！

★
御意！！


> ■
> まぁ、変えざる得ない状況を作ればいいってことさ！

★
そのまま失敗しまくれば嫌でも変えざるを得ないかｗ
とりあえず、STは年末までちょー忙しいぜ　orz



> TAKAHARA Ryo wrote:
>> おつかれです。
>>
>> > 了解。あとは周知だね。
>>
>> ういす。
>> 周知は俺やるでOKすか？
> ■
> スタッフ会議の議事録には・・・
> → 9月までに要綱を変更し、9月から運用開始。（変更内容を高原→高橋常務に連絡）
> って書いてあって、誰が周知とは書いてないので、高橋さんと相談して決めて！
>
>> > まぁ、お互いに誤解してるところはあると思うよ。
>> > それを埋め合わせるのは、顔を合わせての話し合いだけだからね。
>> > とはいうものの、森さんはやり方を変えないと・・・ってことは
>> > 変わらないけどね。
>>
>> 今のやり方は変えんと具合悪いよ？っつーことは言っておきましたです。
>> 森ちんの言い分としては意図があるんだからそれを汲み取れ！
>> ↓
>> そんなもん、俺は森ちんじゃないんだから言わないとわかんないでしょー？
>> ↓
>> 1から10まで説明しないといけないのか？
>> ↓
>> 相手がその意図を理解してないし、納得もしてないならそれも必要でしょー？
>>
>> とかとか。
>> まー変える気あるのか、あるとしてどこまで変えるのか？っつーのはわかんないです
>> けどｗ
> ■
> まぁ、変えざる得ない状況を作ればいいってことさ！
>
>
>> > おつ。
>> >
>> >> お疲れ様です。高原です。
>> >>
>> >> 修正したファイルをサイボウズにアップしてもらって確認しました。
>> >>
>> >> トップページ > ファイル管理（ルートフォルダ） > 全社員 > 社員会 > 社員会要綱
>> > ■
>> > 了解。あとは周知だね。
>> >
>> >> あんど、森ちん呼び出しかけてお互いの不満をぶちまけてきました。
>> >> お互いに歩み寄ったかな？
>> >> っつーカンジです。
>> >> だから最初にそれを言えよオマエはよー！ってのがちらほらｗ
>> > ■
>> > まぁ、お互いに誤解してるところはあると思うよ。
>> > それを埋め合わせるのは、顔を合わせての話し合いだけだからね。
>> > とはいうものの、森さんはやり方を変えないと・・・ってことは
>> > 変わらないけどね。
>> >
>> >
>> >> 以上、宜しくお願いします。
>> >>
>> >> >お疲れさまです、前田です。
>> >> >
>> >> >
>> >> >そういえば、これってサイボウズにアップしたんだっけ？？？
>> >> >
>> >> >
>> >> >> お疲れ様です。高原です。
>> >> >>
>> >> >> 昨日のスタッフ会議であった社員会の要綱の修正をお願いします。
>> >> >>
>> >> >> 変更点は
>> >> >> ・グループ構成図シート
>> >> >> 　スポーツグループのリーダーを老松→金子里美に変更
>> >> >>
>> >> >> ・目的・ルールシート
>> >> >> 　49行目
>> >> >> （７）イベント開催回数
>> >> >> 　　　各グループ、年一回は必ずイベントを開催する。
>> >> >>
>> >> >> 　これの削除
>> >> >>
>> >> >> 　52行目
>> >> >> （８）活動報告書の作成
>> >> >> 　　　開催の記録を残すため、イベント毎に活動報告書を作成する。
>> >> >>   サイボウズにＵＰして管理する。
>> >> >>
>> >> >> 　これに活動報告書の置き場所記載
>> >> >>
>> >> >> ついでに変更履歴と、目的・ルールシートの（７）を消しちゃうと番号がズレるんで
>> >> >> 直して貰えると嬉しいです。
>> >> >> ＃版数は2.1版？
>> >> >>
>> >> >> 以上、お手数ですがよろしくお願いします。
>
>
>

Re: ４月５月リリース社員一覧

[前田 篤志]

お疲れさまです、森です。

日本テクノメンバーしか進展ないですが、一応最新を送ります。
なんか那須ＰＭがらみで大変みたいですね〜。
お察しします。。。


> お疲れさまです、前田です。
> 
> 
> 以下の件、了解しました。
> 
> ※今野PRJ.の件、よろしくお願い致します。
> 
> 
> 添付資料内に現況として「◎」を追記しました。（飯野の件）
> その他、那須PMの方からの依頼として、久保の提案をしています。
> 現状、来期の見通しとして開発系要員の体制を十分に検討し
> 慎重にアサインをすることについては、プロリンク側にも
> 話をしております。
> とりあえず、要員のスキルシートをもとに案件照会を行い
> クレール側に提示という方向になっていますので
> 早い段階で対象者に最新スキルシートのアップを
> お願いできればと思いますので、よろしくお願い致します。
> 
> ※ちなみに、那須PM管理のNW構築系に関しては
> 　プロリンクに対して積極的に動いてくださいと念押しして
> 　ありますので、定期的にツッコミを入れてください！
> 
> 
> 以上、よろしくお願い致します。
> 
> 
> > 前田さん
> > 
> > お疲れさまです、森です。
> > 
> > 本日の最新要員テキストを送ります。
> > 「※」にコメントを追加してますのでご確認下さい。
> 
> > > 了解しました！
> 
> > > > 森です。
> > > > 
> > > > 飯野のスキルシートＵＰ完了しております。
> > > > 取り急ぎご連絡しました。
> 
> > > > > お疲れさまです、前田です。
> > > > > 
> > > > > 
> > > > > 以下の件、了解しました。
> > > > > 
> > > > > ちなみに！飯野だけは、なる早でお願いできますか？
> > > > > 
> > > > > 
> > > > > 以上、よろしくお願い致します。
> 
> > > > > > 前田さん
> > > > > > 
> > > > > > お疲れさまです、森です。
> > > > > > 
> > > > > > スキルシートですが、まだ全員最新ではありません。
> > > > > > 休みを取ってるメンバーもいますのでなるべく早い段階
> > > > > > でＵＰさせます。
> > > > > > 
> > > > > > 以上です。
> 
> > > > > > > お疲れさまです、前田です。
> > > > > > > 
> > > > > > > 
> > > > > > > 以下の件、取りまとめ、ご苦労さまです。
> > > > > > > 了解しました。
> > > > > > > 早速ですが、当件に関してProLink側で
> > > > > > > 打ち合わせをしておりまして
> > > > > > > 逐一、状況の報告をしていきますね。
> > > > > > > 
> > > > > > > ちなみに、要員のスキルシートに関しては
> > > > > > > 現状のサイボウズに上がっているものが
> > > > > > > 最新でしょうか？
> > > > > > > （今野、大谷、福田に関しては今日中にアップします。）
> > > > > > > 
> > > > > > > 
> > > > > > > 以上、よろしくお願い致します。
> 
> > > > > > > > 前田さん
> > > > > > > > 
> > > > > > > > お疲れさまです、森です。
> > > > > > > > 
> > > > > > > > 一応、今日の打合せでの４月、５月リリース予定の社員をまとめました。
> > > > > > > > 随時連絡を取り合って決めて行きましょう。
> > > > > > > > よろしくお願いします。
> > > > > > > > 
> > > > > > > > 以上です。
> > > > > > > > 
> > > > > > > > 
> > > > > > > > ***
> > > > > > > > (株)システムクレール
> > > > > > > > ITソリューション営業
> > > > > > > > マネージャー
> > > > > > > >  　森  勝義(Katsuyoshi Mori)  
> > > > > > > >  TEL 03-3851-3931   FAX 03-3851-3944
> > > > > > > >  URL http://www.claire.co.jp
> > > > > > > >  e-mail  m...@claire.co.jp
> > > > > > > > 　　　〒101-0032
> > > > > > > >   　　東京都千代田区岩本町3丁目9番地17号 スリーセブンビル５階 
> > > > > > > >   
> 
> > > > > > ***
> > > > > > (株)システムクレール
> > > > > > ITソリューション営業
> > > > > > マネージャー
> > > > > >  　森  勝義(Katsuyoshi Mori)  
> > > > > >  TEL 03-3851-3931   FAX 03-3851-3944
> > > > > >  URL http://www.claire.co.jp
> > > > > >  e-mail  m...@claire.co.jp
> > > > > > 　　　〒101-0032
> > > > > >   　　東京都千代田区岩本町3丁目9番地17号 スリーセブンビル５階 
> > > > > >   
> 
> > > > ***
> > > > (株)システムクレール
> > > > ITソリューション営業
> > > > マネージャー
> > > >  　森  勝義(Katsuyoshi Mori)  
> > > >  TEL 03-3851-3931   FAX 03-3851-3944
> > > >  URL http://www.claire.co.jp
> > > >  e-mail  m...@claire.co.jp
> > > > 　　　〒101-0032
> > > >   　　東京都千代田区岩本町3丁目9番地17号 スリーセブンビル５階 
> > > >   
> 
> > ***
> > (株)システムクレール
> > ITソリューション営業
> > マネージャー
> >  　森  勝義(Katsuyoshi Mori)  
> >  TEL 03-3851-3931   FAX 03-3851-3944
> >  URL http://www.claire.co.jp
> >  e-mail  m...@claire.co.jp
> > 　　　〒101-0032
> >   　　東京都千代田区岩本町3丁目9番地17号 スリーセブンビル５階 
> >   

***
(株)システムクレール
ITソリューション営業
マネージャー
 　森  勝義(Katsuyoshi Mori)  
 TEL 03-3851-3931   FAX 03-3851-3944
 URL http://www.claire.co.jp
 e-mail  m...@claire.co.jp
　　　〒101-0032
  　　東京都千代田区岩本町3丁目9番地17号 スリーセブンビル５階 
  
 





４月〜要員 _.txt
Description: Binary data

Re: 第５スポーツ企画G の件について

[前田 篤志]

お疲れ様です、大谷です。

下記の件、了解致しました。
ファイルを更新して、サイボウズにアップ致します。

以上です、宜しくお願い致します。


> お疲れさまです、前田です。
>
> ＃土曜日は、ご苦労さま。
>
>
> 以下の件、栗原さん、2009新卒者は対象外ですので
> 外してください。
>
>
> 以上、よろしくお願い致します。
>
>
>> 前田さん
>>
>> お疲れ様です、大谷です。
>>
>> 森永さんから出欠表の更新が依頼されておりますが、
>> 栗原顧問や来年入社予定の方はいかが致しましょうか。
>> 開催のタイミングによるかと思いますが、
>> 個人的には外してしまった方が良いかと考えております。
>> その件につきまして、ご意見を頂けたらと思います。
>>
>> 以上です、宜しくお願い致します。
>>
>>
>> ■□━━┓
>>   株式会社システムクレール
>>   大谷 進 (Sususmu Ootani)
>>   mail: oot...@claire.co.jp
>>   url : http://www.claire.co.jp
>>   tel : 03-3851-3931 fax:03-3851-3944
>> ┗━━━system claire□■

7月の売上実績並びに手数料の件（お待たせいたしました）

[前田 篤志]

(株)プロリンク　福井様

いつもお世話になっています。システムクレール高橋です。


７月の売上実績並びにプロリンク営業手数料について、ご通知致します。
ご不明な点など御座いましたら、ご連絡ください。
宜しくお願い申し上げます。

（株）ジャパンコンピュータサービス   2,656,500 
（株）プロリンク1,414,520 
東京エレクトロンＳＴ（株）   3,780,000 
キヤノンネットワークＣｏｍ（株）1,294,652 
（株）工芸精機製作所  567,940 
（株）ＧＯＯＹＡ609,000 
（株）ぴーぷる 1,890,000 
（株）テクノバン252,000 
（株）ユニケソフトウエアリサーチ2,236,500 
（株）エーアールシー  1,383,480 
（株）ＴＩＳサービス  1,924,681 
（株）ヒューマンネットワーク  3,047,603 
（株）さくらＫＣＳ   785,777 
（株）紀文フレッシュシステム  516,600 
（株）エルバーラスイス 456,750 
（株）シースリーアイ  730,865 
（株）アクトブレーン  661,500 
（株）日本テクノ4,408,859 
（株）エスワイシステム 940,380 
（株）ＧＳＩ  760,536 
（株）DTS  626,787 
 合計 30,944,930 

　プロリンク営業手数料（４％）  1,128,704  
　プロリンク人件費1,099,520  

以上

宜しくお願い致します。
$
(株)システムクレール   高橋淳司 Junji Takahashi
 TEL 03-3851-3931  FAX 03-3851-3944
 URL www.claire.co.jp
 E-mail takaha...@claire.co.jp
$

９月の売上実績並びに手数料の件

[前田 篤志]

(株)プロリンク　福井様

いつもお世話になっています。システムクレール高橋です。


９月の売上実績並びにプロリンク営業手数料について、ご通知致します。
ご不明な点など御座いましたら、ご連絡ください。
宜しくお願い申し上げます。

（株）東京システム技研 12,127,500
（株）アクアキャスト  735,000
東京エレクトロンＳＴ（株）   3,780,000
キヤノンネットワークＣｏｍ（株）1,259,631
（株）工芸精機製作所  432,237
（株）ＧＯＯＹＡ609,000
（株）ぴーぷる 1,627,500
（株）テクノバン462,000
（株）ユニケソフトウエアリサーチ1,911,000
（株）エーアールシー  1,200,985
（株）ＴＩＳサービス  1,905,277
（株）ヒューマンネットワーク  1,480,835
（株）さくらＫＣＳ   747,920
（株）紀文フレッシュシステム  504,000
（株）エルバーラスイス 456,750
（株）シースリーアイ  780,786
（株）日本テクノ5,253,433
（株）エスワイシステム 879,228
（株）ＧＳＩ  661,500
（株）DTS  610,080
パブリックソフトウェア(株)  472,500
その他 1,218,000

合計  39,115,162

プロリンク営業手数料（４％）   1,642,836 
プロリンク人件費 1,099,520  

以上
$
(株)システムクレール   高橋淳司 Junji Takahashi
 TEL 03-3851-3931  FAX 03-3851-3944
 URL www.claire.co.jp
 E-mail takaha...@claire.co.jp
$

Fwd: 5月の売上実績並びに手数料の件

[前田 篤志]

(株)プロリンク　福井様

いつもお世話になっています。システムクレール高橋です。

5月の売上実績並びにプロリンク営業手数料について、ご通知致します。
ご不明な点など御座いましたら、ご連絡ください。
宜しくお願い申し上げます。

（株）ジャパンコンピュータサービス2,656,500
（株）プロリンク 1,579,020
東京エレクトロンＳＴ（株）3,780,000
キヤノンネットワークＣｏｍ（株） 1,258,139
（株）NTTコミュニケーションズ 1,496,250
（株）工芸精機製作所 632,885
（株）ＧＯＯＹＡ   609,000
（株）ぴーぷる  2,047,500
（株）ユニケソフトウエアリサーチ 2,784,180
（株）エーアールシー 754,120
（株）ＴＩＳサービス   1,706,507
（株）ヒューマンネットワーク   2,124,884
（株）さくらＫＣＳ  757,780
（株）紀文フレッシュシステム 504,000
（株）エルバーラスイス456,750
（株）シースリーアイ 735,000
（株）アクトブレーン 661,500
（株）日本テクノ開発   8,780,887
（株）エスワイシステム590,625
　合計 33,915,527

　プロリンク営業手数料（４％）  1,246,560 
　プロリンク人件費1,264,020 

以上
$
(株)システムクレール   高橋淳司 Junji Takahashi
 TEL 03-3851-3931  FAX 03-3851-3944
 URL www.claire.co.jp
 E-mail takaha...@claire.co.jp
$

Re: [Fwd: Re: 自分史]

[前田 篤志]

おつかれです。

1330でいいっすよ。
早い分にはおｋですけどｗ

> お疲れさま。
> 今、今野がいるアクアキャストさんに向かっているところ。携帯でアクセスしとりま
> す。携帯は便利で良く使うんだよね。
>
> 三郷迎車、了解。13:15でええか？
>
>
> TAKAHARA Ryo wrote:
>> おつかれさまです。たかはらです。
>>
>> 諸々りょーかいです。
>>
>> で、話変わるんですが、今週末のふっとさる、三郷駅まで送迎お願いしていいですか？
>> メンツは神山、里美、俺デス。
>>
>> 以上、宜しくお願いします。
>>
>> > お疲れ、前田です。
>> >
>> >
>> > 返事、遅れちゃってすんません。
>> > 昨日は体調不良でお休みしてた。
>> >
>> > まぁ、思うに人それぞれ、自分の経験をもとに物事の判断を
>> > 行うものなのだよ。そこまでは誰でも自分の考えとして
>> > 持っていていいものだけど、それを自分以外の人間に伝える
>> > 場合に考えなければいけないこととして、関わる人間の状況や
>> > 考えを含まなければならないんだよね。
>> > これは、コミュニケーションで埋めるしかない。
>> > 今回、この辺のコミュニケーションがしっかり取れていたとは
>> > いえない状況だし、結果として当然のことながら顔を見て
>> > 話せる本社常駐メンバーの意見が通った感じじゃん？
>> > でも、本来はそういうことではないよね？
>> > そういう意味では、高原としては悔しい思いをしたんだけれど
>> > 高原が考えてたメンバーが参入する状況は変わらないわけで
>> > そのメンバーが高原の出方次第では、嫌な思いをすることも
>> > 考えられたんだよ。でも、高原がグッと堪えることで
>> > 少なからず、高原が考えていた体制にはなっているのだから
>> > 自分の考えに自信を持って、今回の件はいい経験として
>> > 今後のアプローチの仕方を変えていけばいいんだと思うよ。
>> > 自分の性格に合わないスタンスは疲れるものだが、そこは
>> > 策士としてあらゆることを想定して、緻密に考えを練って
>> > 整然と進めていくことが必要だよ。
>> >
>> > 俺が何を言いたいかというと、高原はそれができる人間だし
>> > そうしなければならない立場にいるってことだよ。
>> >
>> > まぁ、メールではこのくらいにしましょう。
>> > 今度、ゆっくり話そう。
>> >
>> >
>> > んじゃ！
>> >
>> >
>> >> お疲れ様です。高原です。
>> >>
>> >> りょーかいデス。
>> >>
>> >> 体制云々はどーでもいいんですけどねｗ
>> >> 今まで俺が出来るゆーて出来なかったことがあったかー！？
>> >> なんでそれを信用しない？
>> >> が一番すねｗ
>> >> あげく、和生入るならOKとか。
>> >> 俺は始めっからウチのチームでやろうと思ってたけど、体制組んだのは森ちんじゃん
>> >> かさー。とか。
>> >>
>> >> まー、前田さんが分かっててくれるならOKですｗ
>> >> 後、大分状況が飲み込めてきました。
>> >> 俺ばっか忙しい。周りはなんもやってない。って駄々コネた輩がいるっぽいです。
>> >> で、それに対するポーズが今回のコレっぽいｗ
>> >> 俺の先月の実働、200近いんだけど、これに加えて自分史やれっつーことかしら？ｗ
>> >> 意思の疎通が図れてない。。。っつーのがそもそもの原因くさいですが、STの作業優
>> >> 先でいいよ。っつー話でこれかよ。っつーｗ
>> >>
>> >> とりあえず、そこら辺のクレームは我慢しときます。
>> >>
>> >> 愚痴聞いてもらってありがとうございました。
>> >> 結構すっきりしましたｗ
>> >
>> >> > お疲れさまです、前田です。
>> >> >
>> >> >
>> >> > 高原、君の気持ちは十分にわかるよ。君の状況やスキルによる
>> >> > 達成見込みもあるだろうと思うよ。
>> >> >
>> >> > 俺自身も仕様に関しても俺からセッティングしたんだし
>> >> > 本来は、新体制のリーダーからあるもんだとも思うところもある。
>> >> >
>> >> > でも、高原。ここはグッと我慢しなさい。
>> >> > 泣き寝入りしろと言ってる訳じゃないからな。
>> >> > 彼らはスキル不足からくる不安感がいっぱいなんだなぁ。
>> >> > 高原が考えてることが理解できないということ。
>> >> > これは、彼らが悪いとかではなく、彼らの経験不足に
>> >> > よるものなんだよ。
>> >> > まぁ、正直なところ、森さんも被害者だよ。
>> >> > 状況は本社にいる人間から聞いたことで判断するしか
>> >> > なかったんだし・・・。森さんをかばってるわけじゃないんだよ。
>> >> > 君に聞こうと思えば聞けたとは思うんだけどね。
>> >> >
>> >> > 言いたいことはわかるよね？
>> >> >
>> >> > 高原、今は我慢しなさい。今は。
>> >> > 君が望んでいる体制になるとは言えないけど
>> >> > 納得できる状況にはするから。
>> >> >
>> >> >
>> >> > んじゃ！
>> >
>> >> >> お疲れ様です。高原デス。
>> >> >>
>> >> >> ということらしいんですが。
>> >> >> 体制変更したから仕様を詰められたそうですよーっと。
>> >> >> すげームカついてきたんで喧嘩売ってきていいですか？
>> >> >
>> >> >> 森です。
>> >> >>
>> >> >> 一応、佐貫さんは別として、和生を追加した形で
>> >> >> 勝算検討して指示を出すので待つように。
>> >> >>
>> >> >> こっちで検討して和生が使えてかつ勝算あるなら
>> >> >> 元々の設計思想でいかせるでしょう。
>> >> >>
>> >> >> ただ勘違いしないように。
>> >> >> どちらの設計でいくかが問題ではなく、先週体制変更し
>> >> >> 仕様をある程度詰める事ができた点と、要員投入による
>> >> >> 点で勝算が見えたのでこの設計思想でいく事を決断した
>> >> >> ので。
>> >> >>
>> >> >> 本来ならもっと早い段階で仕様をつめてゴールまでの
>> >> >> ストーリーを導き出さない限り元々の設計思想含めて
>> >> >> プロジェクトは失敗に終わるでしょう。
>> >> >> 「できたもん」と言うかもしれないが、口だけではなく
>> >> >> 全てのエンドまでの工程・開発担当メンバーのスケジ
>> >> >> ュール・役割・それに伴う列記とした進捗が出ない限り
>> >> >> 後の祭りなので。
>> >> >>
>> >> >> なので、現体制のままチームリーダーの指示に従って
>> >> >> もらい高原と和生には参入してもらいます。
>> >> >>
>> >> >> 以上
>> >
>> >> >> > おつかれ。
>> >> >> > やっと時間が空くようになってきた。
>> >> >> >
>> >> >> > で、自分史。
>> >> >> > 俺はDBアクセサのラッパー作って以上！でええんかい？
>> >> >> > 今週リリースが終われば来週からは手開くからウチチームから和生と佐貫さん手伝い
>> >> >> > 出せるで？
>> >> >> > つか、本社組は既に検収待ちでやることないが。
>> >
>> >
>> >
>>
>>
>
>
>

Re: RFC: Add 32bit x86-64 support to binutils

[H. Peter Anvin]

On 12/31/2010 02:03 AM, Jakub Jelinek wrote:
> On Thu, Dec 30, 2010 at 01:42:05PM -0800, H. Peter Anvin wrote:
>> On 12/30/2010 11:57 AM, Jakub Jelinek wrote:

 Would be nice if LFS would be mandatory on the new ABI, thus
 off_t being 64bits.
>>>
>>> And avoid ambiguous cases that x86-64 ABI has, e.g. whether
>>> caller or callee is responsible for sign/zero extension of arguments, to
>>> avoid the need to sign/zero extend twice, etc.
>>>
>>
>> Ehwhat?  x86-64 is completely unambiguous on that point; the i386 one is
>> not.
> 
> It is not, sadly, see http://gcc.gnu.org/PR46942
> From what I can see the psABI doesn't talk about it, GCC usually sign/zero
> extends on both sides (exception is 32-bit arguments into 64-bit isn't
> apparently sign/zero extended on the caller side when doing tail calls),
> from what I gathered LLVM expects the caller to sign/zero extend (which is
> incompatible with GCC tail calls then), not sure about ICC, and kernel
> probably expects for security reasons that the callee sign/zero extends.
> 

This is weird... we had long discussions about this when the psABI was
originally written, and the decision was that any bits outside the
fundamental type was undefined -- callee extends (caller in the case of
a return value.)  Yet somehow that (and several other discussions) seem
to either never have made it into the document or otherwise have
disappeared somewhere in the process.

There seems to have been problems with closing the loop on a number of
things, and in some cases the compiler writers have gone off and
implemented something completely different from the written document,
yet failed to get the documentation updated to match reality (it took
many years until the definition of _Bool matched what the compilers
actually implemented.)

-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

kfreebsd-gnu etc. issues

[Joseph S. Myers]

I'm trying to stop non-Linux GCC targets from using config/linux.h and
other headers whose names indicate they relate to the Linux kernel,
separating GNU-userspace and Linux-kernel configuration more cleanly.
 is the
initial patch in this series, and in the course of working on the
corresponding changes for i386/linux.h and i386/linux64.h I found
several possible problems with the configurations for *-kfreebsd-gnu,
*-knetbsd-gnu and *-kopensolaris-gnu.

* The headers config/kfreebsd-gnu.h etc. override
  GLIBC_DYNAMIC_LINKER.  But the 64-bit configurations
  x86_64-*-kfreebsd*-gnu and x86_64-*-knetbsd*-gnu do not appear to
  use any header that would override GLIBC_DYNAMIC_LINKER32 and
  GLIBC_DYNAMIC_LINKER64, which are what LINK_SPEC in linux64.h
  actually uses.  Thus those configurations would use Linux-specific
  dynamic linker settings, which seems unlikely to be as intended.

* These configurations use file_end_indicate_exec_stack to use the
  PT_GNU_STACK convention.  While some of the implementation of this
  is in the GNU linker and glibc, it also requires kernel support for
  correct operation.  Do all these kernels support this convention, or
  should this code actually be disabled for them in GCC and glibc?

* The kfreebsd-gnu and knetbsd-gnu configurations use linux-unwind.h
  (kopensolaris-gnu disables this).  They define REG_NAME to adapt
  linux-unwind.h to their system headers.  But linux-unwind.h also
  contains hardcoded checks for the particular instructions, complete
  with hardcoded Linux syscall numbers, in Linux signal trampolines.
  Do the FreeBSD and NetBSD kernels really use identical instructions?
  Does this code do anything useful on those systems?  If it's useful
  (possibly with some fixes) then linux-unwind.h ought to be renamed;
  otherwise those configurations should not be using it.

* A minor point: TARGET_VERSION, referring to Linux, is not overridden
  by these configurations.

If these issues can be fixed by someone who knows what is correct for
those targets then it would help with this cleanup - and while such
rearrangements of headers used on GNU/Linux may best be avoided in
development Stage 4, it should be fine to make changes then that are
only relevant to kfreebsd-gnu, knetbsd-gnu and kopensolaris-gnu.

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

Fwd: r168382 - in /trunk/libstdc++-v3: ChangeLog Mak...

[Dongsheng Song]

I think gcc-cvs mail list should set reply address to gcc@gcc.gnu.org
instead of gcc-...@gcc.gnu.org.

-- Forwarded message --
From: Dongsheng Song 
Date: Sat, Jan 1, 2011 at 11:29
Subject: Re: r168382 - in /trunk/libstdc++-v3: ChangeLog Mak...
To: b...@gcc.gnu.org
Cc: gcc-...@gcc.gnu.org


Hi Benjamin,

Your commit have 2 drawbacks:

1.  insufficient docbook xsl path checker (trunk/libstdc++-v3/configure.ac)

# Check for docbook
AC_CHECK_PROG([XSLTPROC], xsltproc, yes, no)
AC_CHECK_PROG([XMLLINT], xmllint, yes, no)
AC_CHECK_FILE([/usr/share/sgml/docbook/xsl-ns-stylesheets/VERSION],
             [glibcxx_stylesheets=yes], [glibcxx_stylesheets=no])

For Debian, here is the correct path:
-rw-r--r-- 1 root root 4510 Jul 22  2009
/usr/share/xml/docbook/stylesheet/docbook-xsl-ns/VERSION
-rw-r--r-- 1 root root 4504 Jul 21  2009
/usr/share/xml/docbook/stylesheet/docbook-xsl/VERSION

2.  break cross compiling (trunk/libstdc++-v3/configure)

{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for
/usr/share/sgml/docbook/xsl-ns-stylesheets/VERSION" >&5
$as_echo_n "checking for
/usr/share/sgml/docbook/xsl-ns-stylesheets/VERSION... " >&6; }
if test "${ac_cv_file__usr_share_sgml_docbook_xsl_ns_stylesheets_VERSION+set}"
= set; then :
 $as_echo_n "(cached) " >&6
else
 test "$cross_compiling" = yes &&
 as_fn_error "cannot check for file existence when cross compiling" "$LINENO" 5
if test -r "/usr/share/sgml/docbook/xsl-ns-stylesheets/VERSION"; then
 ac_cv_file__usr_share_sgml_docbook_xsl_ns_stylesheets_VERSION=yes
else
 ac_cv_file__usr_share_sgml_docbook_xsl_ns_stylesheets_VERSION=no
fi
fi

After as_fn_error, my cross compiling failed without use hard code path.

--
Dongsheng

On Sat, Jan 1, 2011 at 06:20,   wrote:
> Author: bkoz
> Date: Fri Dec 31 22:20:22 2010
> New Revision: 168382
>
> URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168382
> Log:
> 2010-12-31  Benjamin Kosnik  
>
>        * scripts/run_doxygen: Allow doxygen 1.7.1 again.
>
>        * doc/xml/manual/build_hacking.xml: Update.
>        * doc/xml/images/confdeps.dot: Same.
>        * doc/xml/images/confdeps.png: Same.
>
>        * configure.ac: Define BUILD_INFO, BUILD_XML, BUILD_HTML,
>        BUILD_MAN, BUILD_PDF, BUILD_EPUB conditionally.
>        * Makefile.am (xml, html, pdf, man, info, pd, dvi, epub): Define,
>        and install rules.
>        * doc/Makefile.am: Same. Add stamp rules.
>        (doc-epub-docbook): Add.
>        (stamp-xml-single-docbook): Make set too.
>        * configure: Regenerate.
>        * Makefile.in: Same.
>        * doc/Makefile.in: Same.
>        * include/Makefile.in: Same.
>        * libsupc++/Makefile.in: Same.
>        * po/Makefile.in: Same.
>        * python/Makefile.in: Same.
>        * src/Makefile.in: Same.
>        * testsuite/Makefile.in: Same.
>        * aclocal.m4: Same.
>
> 2010-12-31  Benjamin Kosnik  
>
>        * doc/doxygen/user.cfg.in: Disable PDF_HYPERLINKS.
>
>
> Modified:
>    trunk/libstdc++-v3/ChangeLog
>    trunk/libstdc++-v3/Makefile.am
>    trunk/libstdc++-v3/Makefile.in
>    trunk/libstdc++-v3/aclocal.m4
>    trunk/libstdc++-v3/configure
>    trunk/libstdc++-v3/configure.ac
>    trunk/libstdc++-v3/doc/Makefile.am
>    trunk/libstdc++-v3/doc/Makefile.in
>    trunk/libstdc++-v3/doc/doxygen/user.cfg.in
>    trunk/libstdc++-v3/doc/xml/images/confdeps.dot
>    trunk/libstdc++-v3/doc/xml/manual/build_hacking.xml
>    trunk/libstdc++-v3/include/Makefile.in
>    trunk/libstdc++-v3/libsupc++/Makefile.in
>    trunk/libstdc++-v3/po/Makefile.in
>    trunk/libstdc++-v3/python/Makefile.in
>    trunk/libstdc++-v3/scripts/run_doxygen
>    trunk/libstdc++-v3/src/Makefile.in
>    trunk/libstdc++-v3/testsuite/Makefile.in
>
>