Re: need help on analysis config.log in MAC OS X 7.9, gcc-5250

[Eric Christopher]

On May 16, 2006, at 7:39 PM, fsshl plinlin wrote:


Dear gcc and/or apple OS X 7.9 users:

Union-Souths-Computer:~/gcc-5250 UnionSouth$ cat config.log
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

configure:595: checking host system type
configure:616: checking target system type
configure:634: checking build system type
configure:689: checking for a BSD compatible install
configure:742: checking whether ln works
configure:766: checking whether ln -s works

please help to fix these configure mistakes to install cc or gcc in my
MAC OS X 7.9, thanks in advance, eric


What problem? You've not shown a problem, said what you're trying to  
do, or anything. Honestly you should just download the latest copy of  
Xcode from the Apple website which has a version of gcc.


And, I have no idea what version of MacOS X you're using. The number  
doesn't make sense.


-eric

localization for Chinese language.

[Eric Fisher]

hi,
Does gcc support Simple Chinese language for now? Is there anyone
working on this?

Thanks.

libgcc-math and the gcc 4.2 release

[Richard Guenther]

Hi,

Following RMS request of removing source copies of other projects I
asked him if he considers it ok to have copies of the generic math
transcendentals routines of glibc in libgcc-math and to distribute
them under GPL + libgcc exception clause license.  He denied that
request and so, after doing the emergency-removal of the wrongly
licensed double parts from libgcc-math I am going to remove the float
parts as well.  This renders the SSE2 abi math functions support
unusable, so I am going forward and remove the following middle-end
patches as well:

2006-01-31  Richard Guenther  <[EMAIL PROTECTED]>

* doc/invoke.texi (-msselibm): Document.
* target.h (expand_library_builtin): New target hook.
* builtins.c (expand_builtin): Use expand_library_builtin.
(default_expand_library_builtin): New function.
* gcc.c (LINK_GCC_MATH_SPEC): Define.
(LINK_COMMAND_SPEC): Handle %(link_gcc_math).
(link_gcc_math_spec): Declare.
(static_specs): Add link_gcc_math_spec.
* expr.h (default_expand_library_builtin): Declare.
* target-def.h (TARGET_EXPAND_LIBRARY_BUILTIN): Define.
(TARGET_INITIALIZER): Add TARGET_EXPAND_LIBRARY_BUILTIN.
* config/i386/i386.h: Provide LINK_GCC_MATH_SPEC.
* config/i386/i386.opt (msselibm): New target option.
* config/i386/i386.c (ix86_builtin_function_variants): New array.
(ix86_init_sse_abi_builtins): New function.
(ix86_expand_library_builtin): Likewise.
(TARGET_EXPAND_LIBRARY_BUILTIN): Define.
(override_options): Handle error conditions wrt -msselibm.
(ix86_builtins): Add function codes for SSE2 ABI builtins.
(ix86_init_builtins): Call ix86_init_sse_abi_builtins.
* doc/extend.texi (__builtin_sse2_*): Document new target specific
builtins.

2006-01-31  Richard Guenther  <[EMAIL PROTECTED]>
Paolo Bonzini  <[EMAIL PROTECTED]>

* doc/install.texi (--disable-libgcc-math): Document.

Unfortunately this leaves libgcc-math empty for the moment, even if
patches for further utilizing this container were proposed (though after
entering stage3), namely

http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01611.html
http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01655.html

While I'm now in a position to approve the first one, the second one
is still unreviewed and the first one is of no use if the second one
does not go in for 4.2.

As we're far into stage3 now I propose to remove libgcc-math from the
mainline again and re-instantiate it at the beginning of stage1 again.
In the mean time it would be nice to have it live on autovect branch
where the two patches above could go in now, as I am aware of at least
Andrew Pinskia planning to use the libgcc-math container for Cell work.

Another option would be to remove the library only after branching
for 4.2 and only on that branch.

I will go forward with the first part of this plan (removal of libgcc-math
from the mainline) next week if no serious objections come up.

Thanks,
Richard.

--
Richard Guenther <[EMAIL PROTECTED]>
Novell / SUSE Labs

Re: SPEC2000 x86 test machine down

[Diego Novillo]

Diego Novillo wrote on 05/01/06 12:07:

> The x86 box that runs SPEC2000 daily has hardware problems.
>
It's now working again.

http://people.redhat.com/dnovillo/spec2000.i686/gcc/

Re: libgcc-math and the gcc 4.2 release

[Gabriel Dos Reis]

Richard Guenther <[EMAIL PROTECTED]> writes:

| Hi,
| 
| Following RMS request of removing source copies of other projects I
| asked him if he considers it ok to have copies of the generic math
| transcendentals routines of glibc in libgcc-math and to distribute
| them under GPL + libgcc exception clause license.  He denied that
| request and so, after doing the emergency-removal of the wrongly
| licensed double parts from libgcc-math I am going to remove the float
| parts as well.  This renders the SSE2 abi math functions support
| unusable, so I am going forward and remove the following middle-end
| patches as well:

Sigh.

[...]

| As we're far into stage3 now I propose to remove libgcc-math from the
| mainline again and re-instantiate it at the beginning of stage1 again.

Please clarify things for me.  
Does that mean that in the future we (GG) have to develop our own
codes independently of glibc?  Or is that a no-no-no end?

-- Gaby

Re: libgcc-math and the gcc 4.2 release

[Richard Guenther]

On Wed, 17 May 2006, Gabriel Dos Reis wrote:

> Richard Guenther <[EMAIL PROTECTED]> writes:
> 
> | Hi,
> | 
> | Following RMS request of removing source copies of other projects I
> | asked him if he considers it ok to have copies of the generic math
> | transcendentals routines of glibc in libgcc-math and to distribute
> | them under GPL + libgcc exception clause license.  He denied that
> | request and so, after doing the emergency-removal of the wrongly
> | licensed double parts from libgcc-math I am going to remove the float
> | parts as well.  This renders the SSE2 abi math functions support
> | unusable, so I am going forward and remove the following middle-end
> | patches as well:
> 
> Sigh.
> 
> [...]
> 
> | As we're far into stage3 now I propose to remove libgcc-math from the
> | mainline again and re-instantiate it at the beginning of stage1 again.
> 
> Please clarify things for me.  
> Does that mean that in the future we (GG) have to develop our own
> codes independently of glibc?  Or is that a no-no-no end?

As far as I understand we (GCC) have to develop our own codes 
independently of glibc unless RMS agrees to have copies/forks of
glibc code in GCC (this includes license changes to GPL + libgcc exception
like in this case).  What is fine as far as I understand is extend/modify
glibc itself to suit our needs - which is of course usually pointless
because GCC is not in a glibc-only world.

Richard.

--
Richard Guenther <[EMAIL PROTECTED]>
Novell / SUSE Labs

Re: libgcc-math and the gcc 4.2 release

[Gabriel Dos Reis]

Richard Guenther <[EMAIL PROTECTED]> writes:

[...]

| As far as I understand we (GCC) have to develop our own codes 
| independently of glibc unless RMS agrees to have copies/forks of
| glibc code in GCC (this includes license changes to GPL + libgcc exception
| like in this case).  What is fine as far as I understand is extend/modify
| glibc itself to suit our needs - which is of course usually pointless
| because GCC is not in a glibc-only world.

Thanks for the clarification.

I hope you're still interested in and motivated by the ligcc-math project.

-- Gaby

Re: configure error : libffi has not been por ted to mipsel-unkown-linux-gnu

[David Daney]

王 启 wrote:
> Hi,
> 
> I am building the cross-toolchain for mipsel on x86 redhat pc. Now I can 
> build the gcc for c using following configuration. ./configure 
> --prefix=/opt/xuelian-toolchain/mipsel-linux-glibc --target=mipsel-linux 
> --enable-shared --enable-threads --enable-languages=c 
> --with-headers=/opt/xuelian-toolchain/mipsel-linux-glibc/mipsel-linux/include 
> 
> make make install
> But if I want to build it for C++, it failed.
> ./configure --prefix=/opt/xuelian-toolchain/mipsel-linux-glibc 
> --target=mipsel-linux --enable-shared --enable-threads 
> --enable-languages=c,c++ 
> --with-headers=/opt/xuelian-toolchain/mipsel-linux-glibc/mipsel-linux/include 
> 
> make make install
> The error is: configure error: libffi has not been ported to 
> mipsel-unknown-linux-gnu
> How should I do to solve this problem.
> 

This is quite odd.  It worked for me several weeks ago.

What version of GCC would you be using?


David Daney.

Re: can't run C compiled programs

[Bernd Jendrissek]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tue, May 16, 2006 at 01:11:54PM +0200, Mohamed Boukaa wrote:
> --->Also when I compile a simple program by myself I got :
> 
>  ~ $ ./testaz   
> bash: ./testaz: Permission denied
> However the portage is working fine , it can compile C and c++
> programs

How very odd.  Make sure that your filesystem is mounted exec, not
noexec.  Try to run a known working executable from the same directory
as above:

~ $ cp /bin/cat .
~ $ ./cat /dev/null

- -- 
You can't truly consider yourself a mad scientist until you have seriously
considered transmutation of base metals into gold.  (By neutron bombardment,
of course.) - me
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Please fetch my new key 804177F8 from hkp://wwwkeys.eu.pgp.net/

iD8DBQFEauZlwyMv24BBd/gRAvWAAJ9vC7uJGuuQmy7ar3QYOnjS1jbRqACgkAJ3
0RFHKx/PDY9WGsgf74dg1zs=
=ns9o
-END PGP SIGNATURE-

Re: localization for Chinese language.

[Mike Stump]

On May 17, 2006, at 1:06 AM, Eric Fisher wrote:

Does gcc support Simple Chinese language for now? Is there anyone
working on this?


I think you'll want to talk with the GNU translation project, they do  
all of this stuff, we just add whatever they do to gcc.

Re: libgcc-math and the gcc 4.2 release

[Mark Mitchell]

Richard Guenther wrote:
> Hi,
> 
> Following RMS request of removing source copies of other projects I
> asked him if he considers it ok to have copies of the generic math
> transcendentals routines of glibc in libgcc-math and to distribute
> them under GPL + libgcc exception clause license.  He denied that
> request and so, after doing the emergency-removal of the wrongly
> licensed double parts from libgcc-math I am going to remove the float
> parts as well.  This renders the SSE2 abi math functions support
> unusable, so I am going forward and remove the following middle-end
> patches as well:

Yes, that seems like the right plan, given RMS' decision.

> As we're far into stage3 now I propose to remove libgcc-math from the
> mainline again and re-instantiate it at the beginning of stage1 again.

Again, I think that's a good idea.

> Another option would be to remove the library only after branching
> for 4.2 and only on that branch.

I think it's better to remove it from mainline, just so that if there
are any build issues we catch them before we branch.

Thanks,

-- 
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

RE: RFC cse weirdness

[Dave Korn]

On 15 May 2006 15:47, Andreas Krebbel wrote:

> [rA + rB] = [rA + rB] & 3;

> 1. SRC rB -> rD
> 2. SRC rA -> RC
> 3. DEST rB -> rD
> 4. DEST rA -> RC

> last 3 changes. If the subsequent call to apply_change_group fails we
> end up with:
> 
> [rA + rB] = [rA + rD] & 3;

> Which now could still be invalid as it is on s390 because we want
> MEM operands in these kind of instructions to be the same on both
> sides.

  Doesn't this mean that your insn patterns should be using numerical (aka
"matching") constraints?  After all, what CSE has done is valid in general
given that rD contains the same value as rB; if it's a requirement of the s390
backend that all mem operands in a single instruction are identical, it should
specify so in the .md file, or it should offer expanders for mem->mem
operations so that reload can deal with them.

  Then again, I don't quite understand your question, because as far as I can
see that's not a mem on the RHS, that's an and operation between a mem and an
immediate; can you clarify showing before and after RTL, and the relevant md
patterns?


cheers,
  DaveK
-- 
Can't think of a witty .sigline today

Re: Segment registers support for i386

[Rask Ingemann Lambertsen]

On Mon, May 15, 2006 at 12:09:00AM +0800, Rémy Saissy wrote:
 
> To manage the manipulation of the register class, I added entries in
> the i386.md file.
> 
> ;; get a value from a segment register.
> (define_insn "store_seg"
>  [(set (match_operand:SI 0 "nonimmediate_operand" "")
>(match_operand:SI 1 "general_operand" "s"))]
>""
>"movl\t%1,%0")
> 
> ;; set a value in a segment register.
> (define_insn "load_seg"
>  [(set (match_operand:SI 0 "general_operand" "=s")
>(match_operand:SI 1 "register_operand" ""))]
>""
>"movl\t%1,%0")

I think you'll have to add "s" alternatives to the *movhi pattern instead of
adding two new patterns, since otherwise there will be two nearly identical
patterns and GCC might use the wrong one. If you need patterns named
"store_seg" and "load_seg", use an expander.

-- 
Rask Ingemann Lambertsen

Re: RFC cse weirdness

[Andreas Krebbel]

Hi Dave,

thanks for your comments.

>  Doesn't this mean that your insn patterns should be using numerical (aka
> "matching") constraints? 

Oh we are using matching constraints. But of course nobody except reload does 
care
about them. If the only constraints for an operand are matching constraints
you can use match_dup what would be honored by validate_canon_reg. But we
have 3 operand ANDs for registers and 2 operand ANDs for memory operands.
To give reload full choice we have put them together in one pattern.
For the memory variants we are using matching constraints and use the
insn condition to make sure that the MEMs on both sides match. 
Btw. this is not a s390 back end invention. You can see the same in the 
i386.md file for "anddi3".

> After all, what CSE has done is valid in general
> given that rD contains the same value as rB; if it's a requirement of the s390
> backend that all mem operands in a single instruction are identical, it should
> specify so in the .md file, or it should offer expanders for mem->mem
> operations so that reload can deal with them.

I'm not that sure that the changes done by cse are valid. Usually changing
rtxs should always be followed by a call to recog. Yes I know there are
exceptions like regrename but they are coming with workarounds like leaving
the constraint string empty to protect the insn which I don't see here at the
moment.

>  Then again, I don't quite understand your question, because as far as I can
> see that's not a mem on the RHS, that's an and operation between a mem and an
> immediate; can you clarify showing before and after RTL, and the relevant md
> patterns?

Not on this system but I could send the rtl pieces tomorrow.

Bye,

-Andreas-

GCC 4.1 branch frozen

[Mark Mitchell]

I am (finally...) starting the 4.1.1 RC1 build.

Please do not check in any changes on the 4.1 branch, even if previous
approved.

Thanks,

-- 
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

Build status page out of date

[Martin Michlmayr]

I noticed that http://gcc.gnu.org/buildstat.html only lists the build
status of GCC up to 4.0.x.  Do you need a volunteer to create a page
for 4.1.x?
-- 
Martin Michlmayr
http://www.cyrius.com/

need help on analysis config.log in MAC OS X 7.9, gcc-5250

[fsshl plinlin]

good question, actually I did not know where is the error too.
to solve by easy, can you just email me a cc binary of (MAC OS X 7.9,
apple G5)yours by email?

compile error about exec 'cc1', please help

[fsshl plinlin]

Union-Souths-Computer:~/Developer/usr/local/bin UnionSouth$ ./gcc
../../../try.cgcc: error trying to exec 'cc1': execvp: No such file or
directory

Re: Build status page out of date

[Janis Johnson]

On Thu, May 18, 2006 at 12:17:33AM +0200, Martin Michlmayr wrote:
> I noticed that http://gcc.gnu.org/buildstat.html only lists the build
> status of GCC up to 4.0.x.  Do you need a volunteer to create a page
> for 4.1.x?

I maintain the GCC build status lists and have gotten way, way behind.
Creating the page is easy, keeping up with build reports and test
results can become time-consuming if you get behind.

If you're interested, send me private e-mail and I'll tell you what's
involved and we can talk to Gerald, the web pages maintainer.

Janis Johnson
[EMAIL PROTECTED]

Re: compile error about exec 'cc1', please help

[Eric Christopher]

On May 17, 2006, at 4:32 PM, fsshl plinlin wrote:



Union-Souths-Computer:~/Developer/usr/local/bin UnionSouth$ ./gcc
../../../try.cgcc: error trying to exec 'cc1': execvp: No such file or
directory


This list is for developers of gcc. You should be using gcc-help.  
FWIW you need more than just the gcc executable.


-eric

Re: libgcc-math and the gcc 4.2 release

[John David Anglin]

> Richard Guenther <[EMAIL PROTECTED]> writes:

> | As far as I understand we (GCC) have to develop our own codes 
> | independently of glibc unless RMS agrees to have copies/forks of
> | glibc code in GCC (this includes license changes to GPL + libgcc exception
> | like in this case).  What is fine as far as I understand is extend/modify
> | glibc itself to suit our needs - which is of course usually pointless
> | because GCC is not in a glibc-only world.

This is sad.  I've always believed that it was important to support both
worlds in a balanced manner.  I do believe that making the generic code
available to the non-glibc world is in fact extending its usage.  There
is the suggestion in the above that there may be considerations beyond
licensing and copyright involved.

> I hope you're still interested in and motivated by the ligcc-math project.

My impression is that this is blocked.

Dave
-- 
J. David Anglin  [EMAIL PROTECTED]
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)

Re: configure error : libffi has not been por ted to mipsel-unkown-linux-gnu

[David Daney]

qwangpolestar wrote:
> Hi, David
>
> Thanks a lot.
>
> I am using gcc-3.2.2 and glibc-2.3.2. Maybe it's too old.
> How about yours?
>

I never used anything earlier than 3.3.0 on mips. Basic ffi call support
for mips existed in that version. We added ffi closures in 4.0 IIRC
(although I have back ported closures to 3.4 in my private tree). In GCC
4.0 and later ffi is fully supported for the MIPS o32 ABI (which
includes mipsel-linux). The glibc version is irrelevant as far as I know.

David Daney

> Thanks
>
> Polestar
>
> 王 启 wrote:
> > Hi,
> >
> > I am building the cross-toolchain for mipsel on x86 redhat pc. Now I
> can
> > build the gcc for c using following configuration. ./configure
> > --prefix=/opt/xuelian-toolchain/mipsel-linux-glibc
> --target=mipsel-linux
> > --enable-shared --enable-threads --enable-languages=c
> >
> --with-headers=/opt/xuelian-toolchain/mipsel-linux-glibc/mipsel-linux/include
>
> >
> > make make install
> > But if I want to build it for C++, it failed.
> > ./configure --prefix=/opt/xuelian-toolchain/mipsel-linux-glibc
> > --target=mipsel-linux --enable-shared --enable-threads
> > --enable-languages=c,c++
> >
> --with-headers=/opt/xuelian-toolchain/mipsel-linux-glibc/mipsel-linux/include
>
> >
> > make make install
> > The error is: configure error: libffi has not been ported to
> > mipsel-unknown-linux-gnu
> > How should I do to solve this problem.
> >
>
> This is quite odd. It worked for me several weeks ago.
>
> What version of GCC would you be using?
>
>
> David Daney.
>
>
>
>
>
>
>
> 你 不 想 试 试 今 夏 最 “酷” 的邮 箱 吗 ？
> 蕴 涵 中 华 传 统 文化 于 世 界 一 流 科 技 之 中，创 新 Ajax 技 术，
> 126 “D 计 划”火 热 体 验 中 ！