1.0 sucessfull, install params questions

1.0 sucessfull, install params questions

[Hermann Lauer]

Hello,

MANY THANKS FOR YOUR WORK ON EGCS !

on a i686-pc-linux-gnulibc1 (something between Redhat 4.2 and Redhat 5.0, with
libc 5.3.12 as development lib):

in the egcs dir I used the following to build:

mkdir objekts
cd objekts

../configure --program-prefix=e
make bootstrap

make install prefix=/tmp/usr/local program-prefix=e

The so generated egcs was then packed with rpm and installed to /usr/local.

egcs works, but the --program-prefix=e seems to be ignored -- all binaries
in /tmp/usr/local/bin alias /usr/local/bin have there default names !

Any comments on this - should this work in principle ?

If the "make install prefix=/tmp/usr/local" trick is not legal with egcs (works
with gcc-2.7.x), please tell me the correct way to achieve the same.

Thanks for any help.

Greetings
   Hermann


Output from tests:

                === libio Summary ===

# of expected passes            40

                === libstdc++ Summary ===

# of expected passes            30

                === gcc Summary ===

# of expected passes            4883
# of expected failures          5
# of unsupported tests          7

                === g++ Summary ===

# of expected passes            3400
# of unexpected successes       3
# of expected failures          80
# of untested testcases         6

                === g77 tests ===

FAIL: g77.f-torture/execute/dnrm2.f execution,  -O2 -fomit-frame-pointer
-finline-functions -funroll-loops
FAIL: g77.f-torture/execute/dnrm2.f execution,  -O2 -fomit-frame-pointer
-finline-functions -funroll-all-loops

                === g77 Summary ===

# of expected passes            130
# of unexpected failures        2



-- 
	Hermann Lauer

Bildverarbeitungsgruppe des Interdiziplinaeren Zentrums fuer
wissenschaftliches Rechnen, Universitaet Heidelberg
INF 368; 69120 Heidelberg; Tel: (06221)548826  Fax: (06221)548850
Email: Hermann.Lauer@iwr.uni-heidelberg.de

Re: 1.0 sucessfull, install params questions

[Jeffrey A Law]

  In message < 9712121155.ZM312@giotto.iwr.uni-heidelberg.de >you write:
  > on a i686-pc-linux-gnulibc1 (something between Redhat 4.2 and Redhat 5.0,
  > withlibc 5.3.12 as development lib):
Congrats.

  > make install prefix=/tmp/usr/local program-prefix=e
--prefix must be used at configure time, not at install time.  Trying
to do it at install time is just going to lead to problems later.

Test results look good.

jeff

Re: 1.0 sucessfull, install params questions

[Michael Poole]

On Fri, 12 Dec 1997, Jeffrey A Law wrote:

> 
>   In message < 9712121155.ZM312@giotto.iwr.uni-heidelberg.de >you write:
>   > on a i686-pc-linux-gnulibc1 (something between Redhat 4.2 and Redhat 5.0,
>   > withlibc 5.3.12 as development lib):
> Congrats.
> 
>   > make install prefix=/tmp/usr/local program-prefix=e
> --prefix must be used at configure time, not at install time.  Trying
> to do it at install time is just going to lead to problems later.

	Why is this?  Tools like Stow (which manages symlink trees
for you) and Depot (which does quite a bit more) generally require
separate a prefix and install-prefix; is having $(prefix)/foo a symlink to
some other location going to cause problems with egcs (for each foo in
the installed egcs files) in and of itself?

- Michael

Re: 1.0 sucessfull, install params questions

[Hermann Lauer]

On Dec 12,  9:10am, Jeffrey A Law wrote:
...
>   > make install prefix=/tmp/usr/local program-prefix=e
> --prefix must be used at configure time, not at install time.  Trying
> to do it at install time is just going to lead to problems later.

So what is the recommended way to compile for a given location but to first
install to another location ? (for example, if /usr/local is exported read-only
via NFS ? (with AFS I have heard similar things can happen)
Also for package builder's this should be an possible option, as you don't want
to destroy another egcs at the same location...

Thanks for any advice.

  Hermann

Re: porting EGCS to the Cray T3E

[Jeffrey A Law]

  In message < 9807141122.ZM4885@vapor.acl.lanl.gov >you write:
  > I guess I don't understand your comment.  There are other Cray platforms listed
  > as possibilities in the config.sub file, such as the Cray X-MP, Y-MP, Cray  2,
  > and Cray [C,J,T]90.  Why would these options be listed if Cray is
  > not supported?
They may be supported as host or build machines, but that does not
mean they are supported as a target.

ie, gcc does not know how to generate code for any cray that I'm aware of.

jeff

Re: porting EGCS to the Cray T3E

[Julian C. Cummings]

>> It probably failed because it thought you also wanted to *target* for
>> a cray, which isn't supported.
>>
>> jeff

I guess I don't understand your comment.  There are other Cray platforms listed
as possibilities in the config.sub file, such as the Cray X-MP, Y-MP, Cray 2,
and Cray [C,J,T]90.  Why would these options be listed if Cray is not
supported?

Julian C.


-- 
Julian C. Cummings
Advanced Computing Laboratory
Los Alamos National Laboratory
(505) 667-6064
julianc@acl.lanl.gov

Re: porting EGCS to the Cray T3E

[Jeffrey A Law]

  In message < 9807141146.ZM5055@vapor.acl.lanl.gov >you write:

  > OK.  As far as I can tell, the egcs build instructions do not make any sort of
  > distinction like this between "host" and "target".  The instructions imply that
  > these are the same thing.  Nevertheless, I tried the suggestion I received of
  > setting the host to "alpha-cray-unicosmk" to see if that works.  It does not.
No, look at configure.html



To configure egcs: 


     % mkdir objdir 
     % cd objdir 
     % srcdir/configure [target] [options] 

target specification 

     egcs has code to correctly determine the correct value for target for nearly all native
     systems. Therefore, we highly recommend you not provide a configure target when
     configuring a native compiler. 
     target must be specified when configuring a cross compiler; examples of valid targets
     would be i960-rtems, m68k-coff, sh-elf, etc. 


  >  I get the exact same behavior as before.  It works for a while, then says
  > 
  > Configuration alpha-cray-unicosmk not supported
This isn't going to help your problem -- there is no support for cray
targets.  As long as you continue to try and build for a cray target
this is going to fail.
jeff

Re: porting EGCS to the Cray T3E

[Jeffrey A Law]

  In message < 9807141424.ZM5539@vapor.acl.lanl.gov >you write:
  > So what would it take for Cygnus to make egcs portable to the Cray T3E?
  > (i.e., how hard is it?, what would it cost?, etc.)
  > egcs would be extremely useful on Cray machines, since Cray CC is terrible
  > and KAI is very slow to update versions of KCC on the T3E.
Note that Cygnus != egcs.

egcs is a project to help build a better free compiler.  Cygnus happens
to be donating various resources to the project (both manpower and
physical resources).

--

Now, having said that, you would need to contact sales@cygnus.com to
get information about a port to the Cray T3E.


jeff

Re: porting EGCS to the Cray T3E

[Julian C. Cummings]

On Jul 14, 11:20am, Jeffrey A Law wrote:
> Subject: Re: porting EGCS to the Cray T3E
>
>   In message < 9807141122.ZM4885@vapor.acl.lanl.gov >you write:
>   > I guess I don't understand your comment.  There are other Cray platforms
listed
>   > as possibilities in the config.sub file, such as the Cray X-MP, Y-MP,
Cray  2,
>   > and Cray [C,J,T]90.  Why would these options be listed if Cray is
>   > not supported?
> They may be supported as host or build machines, but that does not
> mean they are supported as a target.
>
> ie, gcc does not know how to generate code for any cray that I'm aware of.

OK.  As far as I can tell, the egcs build instructions do not make any sort of
distinction like this between "host" and "target".  The instructions imply that
these are the same thing.  Nevertheless, I tried the suggestion I received of
setting the host to "alpha-cray-unicosmk" to see if that works.  It does not.
 I get the exact same behavior as before.  It works for a while, then says

Configuration alpha-cray-unicosmk not supported
Configure in /usr/tmp/julianc/EGCS/egcs-objdir-alpha/gcc failed, exiting.

It sounds like you're saying that egcs cannot generate code for a Cray.  But
these are DEC Alpha processors, so I don't see why not.

Is there some sort of verbosity switch I can throw that might tell me why this
is failing?  There is nothing telltale in the config.log file, as you saw.

Julian C.




-- 
Julian C. Cummings
Advanced Computing Laboratory
Los Alamos National Laboratory
(505) 667-6064
julianc@acl.lanl.gov

Re: porting EGCS to the Cray T3E

[Julian C. Cummings]

On Jul 14, 12:00pm, Jeffrey A Law wrote:
> Subject: Re: porting EGCS to the Cray T3E
>
>   >  I get the exact same behavior as before.  It works for a while, then
says
>   >
>   > Configuration alpha-cray-unicosmk not supported
> This isn't going to help your problem -- there is no support for cray
> targets.  As long as you continue to try and build for a cray target
> this is going to fail.
> jeff

I see now why choosing "alpha" as a target won't work.  There is a small
assembly language program in config.guess used to distinguish different
types of Alpha processors.  But this does not compile on the T3E; the
assembly language is different.

So what would it take for Cygnus to make egcs portable to the Cray T3E?
(i.e., how hard is it?, what would it cost?, etc.)
egcs would be extremely useful on Cray machines, since Cray CC is terrible
and KAI is very slow to update versions of KCC on the T3E.

Julian C.



-- 
Julian C. Cummings
Advanced Computing Laboratory
Los Alamos National Laboratory
(505) 667-6064
julianc@acl.lanl.gov

Re: [Q] alpha egc -> motorolla dragonball

[Scott Howard]

I haven't tried it, so I'm not really on top of the details, but the gnu
documentation warns about problems when you host a cross-compiler for a
32-bit target on a 64-bit host (which I believe applies to the Alpha).

These issues may soon be (or may have already been) resolved by the EGCS
project.  Can anyone on the EGCS list provide some insight?

Kari Davidsson wrote:
> 
> Hi
> 
> I understand that a crosscompiler hosted on Alpha (Linux Alpha) is somewhat
> difficult to build. Is this something that is absolutly undoable?
> Target would be Motorolla dragonball CPU.
> 
> Thanks,
> 
> K.D.
> _______________________________________________
> New CrossGCC FAQ: http://www.objsw.com/CrossGCC
> _______________________________________________
> To remove yourself from the crossgcc list, send
> mail to crossgcc-request@cygnus.com with the
> text 'unsubscribe' (without the quotes) in the
> body of the message.

Re: [Q] alpha egc -> motorolla dragonball

[Jeffrey A Law]

  In message < 36CD1CD3.1FC47334@objsw.com >you write:
  > I haven't tried it, so I'm not really on top of the details, but the gnu
  > documentation warns about problems when you host a cross-compiler for a
  > 32-bit target on a 64-bit host (which I believe applies to the Alpha).
  > 
  > These issues may soon be (or may have already been) resolved by the EGCS
  > project.  Can anyone on the EGCS list provide some insight?
What problems are you referring to?  As far as I know it's supposed to work.

It's had bugs in the past, and no doubt it'll have bugs in the future, but
that's no different than building a 32x32 or 32x64 cross compiler.



jeff

Re: [Q] alpha egc -> motorola dragonball

[David Edelsohn]

	64-bit -> 32-bit cross-compiling is not inherently a problem.
Some ports are not 64-bit safe.  The PowerPC port in egcs-1.1 release is
not 64-bit safe although the development sources should be fixed.  The
ability to cross-compile from a 64-bit host to a 32-bit target is not a
fundamental limitation in EGCS, but it does depend on the particular port
in question.

David

Re: [Q] alpha egc -> motorola dragonball

[David Edelsohn]

	64-bit -> 32-bit cross-compiling is not inherently a problem.
Some ports are not 64-bit safe.  The PowerPC port in egcs-1.1 release is
not 64-bit safe although the development sources should be fixed.  The
ability to cross-compile from a 64-bit host to a 32-bit target is not a
fundamental limitation in EGCS, but it does depend on the particular port
in question.

David

Re: [Q] alpha egc -> motorolla dragonball

[Jeffrey A Law]

  In message < 36CD1CD3.1FC47334@objsw.com >you write:
  > I haven't tried it, so I'm not really on top of the details, but the gnu
  > documentation warns about problems when you host a cross-compiler for a
  > 32-bit target on a 64-bit host (which I believe applies to the Alpha).
  > 
  > These issues may soon be (or may have already been) resolved by the EGCS
  > project.  Can anyone on the EGCS list provide some insight?
What problems are you referring to?  As far as I know it's supposed to work.

It's had bugs in the past, and no doubt it'll have bugs in the future, but
that's no different than building a 32x32 or 32x64 cross compiler.



jeff

Re: [Q] alpha egc -> motorolla dragonball

[Scott Howard]

I haven't tried it, so I'm not really on top of the details, but the gnu
documentation warns about problems when you host a cross-compiler for a
32-bit target on a 64-bit host (which I believe applies to the Alpha).

These issues may soon be (or may have already been) resolved by the EGCS
project.  Can anyone on the EGCS list provide some insight?

Kari Davidsson wrote:
> 
> Hi
> 
> I understand that a crosscompiler hosted on Alpha (Linux Alpha) is somewhat
> difficult to build. Is this something that is absolutly undoable?
> Target would be Motorolla dragonball CPU.
> 
> Thanks,
> 
> K.D.
> _______________________________________________
> New CrossGCC FAQ: http://www.objsw.com/CrossGCC
> _______________________________________________
> To remove yourself from the crossgcc list, send
> mail to crossgcc-request@cygnus.com with the
> text 'unsubscribe' (without the quotes) in the
> body of the message.

gcc-2.7 creates faster code than pgcc-1.1.1

[Терехин Вячеслав]

As I wrote previously gcc-2.7.2.3 generates faster gzip
than egcs-1.1.1/pgcc-1.1.1 on PentiumPro.
The slowdown is greater than 10% on decompression operation.
This can be easily checked if you have RedHat 5.2.
The shipped gzip is gcc-2.7.2.3 compiled.

After several day of search I finally find out offending
instruction that slow down gzip compiled with egcs-1.1.1/pgcc-1.1.1
on PentiumPro 180MHz (132MB RAM) but the result seems crazy to me.

This instruction is:
andl $255, %eax
in flush_window (util.c) function body (it is inlined from updcrc)

if you manually replace it with
movzbl %al, $eax
this will boost decompression by 20%.

All the below staff is made in gzip-1.2.4a source folder.

$ make CFLAGS="-O6 -mpentiumpro"
$ time ./gzip -cd egcs-1.1.1.tar.gz > /dev/null

real    0m8.047s
user    0m7.970s
sys     0m0.070s

$time ./gzip -c egcs-1.1.1.tar.gz > /dev/null

real    0m12.646s
user    0m12.470s
sys     0m0.160s

$
gcc -c -DASMV -DSTDC_HEADERS=1 -DHAVE_UNISTD_H=1 -DDIRENT=1 -O6 -mpentiumpro
util.c -S
$ sed 's/andl $255,%eax/movzbl %al, %eax/g' util.s > util.S
$
gcc -c -DASMV -DSTDC_HEADERS=1 -DHAVE_UNISTD_H=1 -DDIRENT=1 -O6 -mpentiumpro
util.S
$ make CFLAGS="-O6 -mpentiumpro"

$ time ./gzip -cd egcs-1.1.1.tar.gz > /dev/null

real    0m6.658s
user    0m6.540s
sys     0m0.110s

$ time ./gzip -c egcs-1.1.1.tar.gz > /dev/null

real    0m12.688s
user    0m12.490s
sys     0m0.180s

All this staff do not apply to Pentium processor as far as I know
(I test it Pentium MMX 200MHz)

I do not know why this happens.
Anybody who knows how to deal with it, please, reply me
as soon as possible.

And finally if you have Pentium Pro or Pentium II please
do this check and report result to me.
I wonder whether I have brain damaged Pentium Pro.

Sincerely Yours, Eugene.


PS I am not on this mailing list.
Also it will be better if you will sent reply to bom@classic.iki.rssi.ru
I can not use it directly as mail can not be delivered by it to this list.

Re: gcc-2.7 creates faster code than pgcc-1.1.1

[Jamie Lokier]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 801 bytes --]

ôÅÒÅÈÉÎ ÷ÑÞÅÓÌÁ× wrote:
> After several day of search I finally find out offending
> instruction that slow down gzip compiled with egcs-1.1.1/pgcc-1.1.1
> on PentiumPro 180MHz (132MB RAM) but the result seems crazy to me.
> 
> This instruction is:
> andl $255, %eax
> in flush_window (util.c) function body (it is inlined from updcrc)
> 
> if you manually replace it with
> movzbl %al, $eax
> this will boost decompression by 20%.

In the past I have written hand-optimised assembly language, tuned for
the different x86 families, and I found movzbl to be a very effective
instruction on the Pentium Pro.  So what you describe sounds correct.

Another is to do xorl %eax,%eax just before loading something into %al.
That is fast on the PPro too.

-- Jamie

Re: gcc-2.7 creates faster code than pgcc-1.1.1

[Zack Weinberg]

On Thu, 4 Mar 1999 22:20:18 +0100, Jamie Lokier wrote:
>> After several day of search I finally find out offending
>> instruction that slow down gzip compiled with egcs-1.1.1/pgcc-1.1.1
>> on PentiumPro 180MHz (132MB RAM) but the result seems crazy to me.
>> 
>> This instruction is:
>> andl $255, %eax
>> in flush_window (util.c) function body (it is inlined from updcrc)
>> 
>> if you manually replace it with
>> movzbl %al, $eax
>> this will boost decompression by 20%.
>
>In the past I have written hand-optimised assembly language, tuned for
>the different x86 families, and I found movzbl to be a very effective
>instruction on the Pentium Pro.  So what you describe sounds correct.
>
>Another is to do xorl %eax,%eax just before loading something into %al.
>That is fast on the PPro too.

A related issue:  I see us generate a lot of code like this for loops over
strings:

loop:
	xorl %eax, %eax
	movb (%esi), %al
	incl %esi
	movb %al, (%edi)
	incl %edi
	testl %eax
	jne loop

After the first iteration, the xorl is unnecessary.  We ought to be able to
hoist it out of the loop.

zw

Re: gcc-2.7 creates faster code than pgcc-1.1.1

[Jeffrey A Law]

  In message < 199903050104.UAA15335@octiron.phys.columbia.edu >you write:
  > A related issue:  I see us generate a lot of code like this for loops over
  > strings:
  > 
  > loop:
  > 	xorl %eax, %eax
  > 	movb (%esi), %al
  > 	incl %esi
  > 	movb %al, (%edi)
  > 	incl %edi
  > 	testl %eax
  > 	jne loop
  > 
  > After the first iteration, the xorl is unnecessary.  We ought to be able to
  > hoist it out of the loop.
True, but I don't believe the loop optimizer is prepared to do that since it
doesn't keep track of what bits are active vs what bits are inactive in a 
value.

jeff

Re: gcc-2.7 creates faster code than pgcc-1.1.1

[David Edelsohn]

>>>>> Jeffrey A Law writes:

Jeff> True, but I don't believe the loop optimizer is prepared to do that since it
Jeff> doesn't keep track of what bits are active vs what bits are inactive in a 
Jeff> value.

	GCC is missing a general feature of value propagation which would
help with a lot of optimizations like this.  Hopefully this infrastructure
will be added or contributed someday.

David

Re: gcc-2.7 creates faster code than pgcc-1.1.1

[Jeffrey A Law]

  In message < 9903050403.AA36338@marc.watson.ibm.com >you write:
  > 	GCC is missing a general feature of value propagation which would
  > help with a lot of optimizations like this.  Hopefully this infrastructure
  > will be added or contributed someday.
Most of the papers I've read have indicated only trivial gains from value
range propagation.  I've also had discussions with folks that have implemented
this opt in a commercial compiler -- it's so minor of a win that they didn't
consider it worth the effort.

It's best use appears to be for optimizing array bounds checking in languages
that require such checks.


jeff

Re: gcc-2.7 creates faster code than pgcc-1.1.1

[craig]

>Most of the papers I've read have indicated only trivial gains from value
>range propagation.  I've also had discussions with folks that have implemented
>this opt in a commercial compiler -- it's so minor of a win that they didn't
>consider it worth the effort.

If that we really true *generally*, i.e. for floating-point as well,
then we could happily make -mieee the default for egcs/gcc on Alphas,
for example.  (This would make Alpha-generated floating-point code
much slower, of course, which is why I mention it: if it was possible
to use value-range propagation to determine when the special code-
generation normally needed for full IEEE range wasn't needed after all,
then some of that performance could be regained.)

But, I have to admit I can't document any really clear performance
wins from my own hand-tuned assembly code (written over the past few
decades) deriving solely from value-range propagation, especially
for *integer* (versus floating-point) values.

Generally, I think being able to avoid even checking for exceptional
values might be one source of performance wins from this: e.g. if
we knew it was "impossible" to divide by zero here, square-root a
negative number there, and so on, we could save generated extra
code, thus making Icache misses theoretically less frequent.

        tq vm, (burley)

Re: gcc-2.7 creates faster code than pgcc-1.1.1

[Jeffrey A Law]

  In message < 19990305143358.4747.qmail@deer >you write:
  > If that we really true *generally*, i.e. for floating-point as well,
  > then we could happily make -mieee the default for egcs/gcc on Alphas,
  > for example.  (This would make Alpha-generated floating-point code
  > much slower, of course, which is why I mention it: if it was possible
  > to use value-range propagation to determine when the special code-
  > generation normally needed for full IEEE range wasn't needed after all,
  > then some of that performance could be regained.)
None of the papers discussed it in a floating point context, merely from an
integer context.  The basics were you had a range [min,max] and a bit which
indicated that the value was in or out of the range which was built up on a
basic block level for each expression.

The ranges were then propagated through the flow graph like any other local 
local property.  A trivial example, at a flow merge point where we had
one path with a range 0..4 inclusive and a range 6...12 inclusive the
resulting range would be 0..12 inclusive. [ It didn't try to track the hole
at 5. ]


As you mention it could be used to detect and eliminate things like domain
checks which depend solely on the range, not the precision.

Knowing that certain numbers can't be a NaN or Inf would lead to being able
to apply more identity operations on floating point values.

It'd be a lot of work though.  I suspect there's other lower hanging fruit
we can/should go after (assignment motion, partial dead code elimination,
sparse conditional constant propagation, etc).


jeff

Re: gcc-2.7 creates faster code than pgcc-1.1.1

[Joe Buck]

> None of the papers discussed it in a floating point context, merely from an
> integer context.  The basics were you had a range [min,max] and a bit which
> indicated that the value was in or out of the range which was built up on a
> basic block level for each expression.
> ...
> As you mention it could be used to detect and eliminate things like domain
> checks which depend solely on the range, not the precision.

There's been work on fixed point optimization for embedded DSP that also
propagates precision information.  e.g. we have [min,max,prec] which means
that the value is known to be a multiple of pow(2,prec), as well as being
in [min,max].  The idea is that we want to eliminate both the
overflow-check operations and the rounding operations in generated code.

Re: gcc-2.7 creates faster code than pgcc-1.1.1

[craig]

>It'd be a lot of work though.  I suspect there's other lower hanging fruit
>we can/should go after (assignment motion, partial dead code elimination,
>sparse conditional constant propagation, etc).

No analysis to offer, but: my instincts say you're right.

        tq vm, (burley)

Re: gcc-2.7 creates faster code than pgcc-1.1.1

[Zack Weinberg]

On Thu, 04 Mar 1999 23:03:58 -0500, David Edelsohn wrote:
>>>>>> Jeffrey A Law writes:
>
>Jeff> True, but I don't believe the loop optimizer is prepared to do that sinc
>e it
>Jeff> doesn't keep track of what bits are active vs what bits are inactive in 
>a 
>Jeff> value.
>
>	GCC is missing a general feature of value propagation which would
>help with a lot of optimizations like this.  Hopefully this infrastructure
>will be added or contributed someday.

For the case I'm interested in, we don't need general value propagation,
only to recognize that we are loading QImode values into a register without
sign extension.  Mode-based range analysis ought to be simpler than full
value propagation.

If we knew how to generate QImode compares, we wouldn't need to clear the
register at all.  That may be something fixable in i386.md, I'm not sure.

zw

Re: gcc-2.7 creates faster code than pgcc-1.1.1

[Jeffrey A Law]

  In message < 19990305143358.4747.qmail@deer >you write:
  > If that we really true *generally*, i.e. for floating-point as well,
  > then we could happily make -mieee the default for egcs/gcc on Alphas,
  > for example.  (This would make Alpha-generated floating-point code
  > much slower, of course, which is why I mention it: if it was possible
  > to use value-range propagation to determine when the special code-
  > generation normally needed for full IEEE range wasn't needed after all,
  > then some of that performance could be regained.)
None of the papers discussed it in a floating point context, merely from an
integer context.  The basics were you had a range [min,max] and a bit which
indicated that the value was in or out of the range which was built up on a
basic block level for each expression.

The ranges were then propagated through the flow graph like any other local 
local property.  A trivial example, at a flow merge point where we had
one path with a range 0..4 inclusive and a range 6...12 inclusive the
resulting range would be 0..12 inclusive. [ It didn't try to track the hole
at 5. ]


As you mention it could be used to detect and eliminate things like domain
checks which depend solely on the range, not the precision.

Knowing that certain numbers can't be a NaN or Inf would lead to being able
to apply more identity operations on floating point values.

It'd be a lot of work though.  I suspect there's other lower hanging fruit
we can/should go after (assignment motion, partial dead code elimination,
sparse conditional constant propagation, etc).


jeff

Re: gcc-2.7 creates faster code than pgcc-1.1.1

[craig]

>It'd be a lot of work though.  I suspect there's other lower hanging fruit
>we can/should go after (assignment motion, partial dead code elimination,
>sparse conditional constant propagation, etc).

No analysis to offer, but: my instincts say you're right.

        tq vm, (burley)

Re: gcc-2.7 creates faster code than pgcc-1.1.1

[David Edelsohn]

>>>>> Jeffrey A Law writes:

Jeff> True, but I don't believe the loop optimizer is prepared to do that since it
Jeff> doesn't keep track of what bits are active vs what bits are inactive in a 
Jeff> value.

	GCC is missing a general feature of value propagation which would
help with a lot of optimizations like this.  Hopefully this infrastructure
will be added or contributed someday.

David

Re: gcc-2.7 creates faster code than pgcc-1.1.1

[Jamie Lokier]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 801 bytes --]

ôÅÒÅÈÉÎ ÷ÑÞÅÓÌÁ× wrote:
> After several day of search I finally find out offending
> instruction that slow down gzip compiled with egcs-1.1.1/pgcc-1.1.1
> on PentiumPro 180MHz (132MB RAM) but the result seems crazy to me.
> 
> This instruction is:
> andl $255, %eax
> in flush_window (util.c) function body (it is inlined from updcrc)
> 
> if you manually replace it with
> movzbl %al, $eax
> this will boost decompression by 20%.

In the past I have written hand-optimised assembly language, tuned for
the different x86 families, and I found movzbl to be a very effective
instruction on the Pentium Pro.  So what you describe sounds correct.

Another is to do xorl %eax,%eax just before loading something into %al.
That is fast on the PPro too.

-- Jamie

Re: gcc-2.7 creates faster code than pgcc-1.1.1

[Jeffrey A Law]

  In message < 9903050403.AA36338@marc.watson.ibm.com >you write:
  > 	GCC is missing a general feature of value propagation which would
  > help with a lot of optimizations like this.  Hopefully this infrastructure
  > will be added or contributed someday.
Most of the papers I've read have indicated only trivial gains from value
range propagation.  I've also had discussions with folks that have implemented
this opt in a commercial compiler -- it's so minor of a win that they didn't
consider it worth the effort.

It's best use appears to be for optimizing array bounds checking in languages
that require such checks.


jeff

gcc-2.7 creates faster code than pgcc-1.1.1

[Терехин Вячеслав]

As I wrote previously gcc-2.7.2.3 generates faster gzip
than egcs-1.1.1/pgcc-1.1.1 on PentiumPro.
The slowdown is greater than 10% on decompression operation.
This can be easily checked if you have RedHat 5.2.
The shipped gzip is gcc-2.7.2.3 compiled.

After several day of search I finally find out offending
instruction that slow down gzip compiled with egcs-1.1.1/pgcc-1.1.1
on PentiumPro 180MHz (132MB RAM) but the result seems crazy to me.

This instruction is:
andl $255, %eax
in flush_window (util.c) function body (it is inlined from updcrc)

if you manually replace it with
movzbl %al, $eax
this will boost decompression by 20%.

All the below staff is made in gzip-1.2.4a source folder.

$ make CFLAGS="-O6 -mpentiumpro"
$ time ./gzip -cd egcs-1.1.1.tar.gz > /dev/null

real    0m8.047s
user    0m7.970s
sys     0m0.070s

$time ./gzip -c egcs-1.1.1.tar.gz > /dev/null

real    0m12.646s
user    0m12.470s
sys     0m0.160s

$
gcc -c -DASMV -DSTDC_HEADERS=1 -DHAVE_UNISTD_H=1 -DDIRENT=1 -O6 -mpentiumpro
util.c -S
$ sed 's/andl $255,%eax/movzbl %al, %eax/g' util.s > util.S
$
gcc -c -DASMV -DSTDC_HEADERS=1 -DHAVE_UNISTD_H=1 -DDIRENT=1 -O6 -mpentiumpro
util.S
$ make CFLAGS="-O6 -mpentiumpro"

$ time ./gzip -cd egcs-1.1.1.tar.gz > /dev/null

real    0m6.658s
user    0m6.540s
sys     0m0.110s

$ time ./gzip -c egcs-1.1.1.tar.gz > /dev/null

real    0m12.688s
user    0m12.490s
sys     0m0.180s

All this staff do not apply to Pentium processor as far as I know
(I test it Pentium MMX 200MHz)

I do not know why this happens.
Anybody who knows how to deal with it, please, reply me
as soon as possible.

And finally if you have Pentium Pro or Pentium II please
do this check and report result to me.
I wonder whether I have brain damaged Pentium Pro.

Sincerely Yours, Eugene.


PS I am not on this mailing list.
Also it will be better if you will sent reply to bom@classic.iki.rssi.ru
I can not use it directly as mail can not be delivered by it to this list.

Re: gcc-2.7 creates faster code than pgcc-1.1.1

[Jeffrey A Law]

  In message < 199903050104.UAA15335@octiron.phys.columbia.edu >you write:
  > A related issue:  I see us generate a lot of code like this for loops over
  > strings:
  > 
  > loop:
  > 	xorl %eax, %eax
  > 	movb (%esi), %al
  > 	incl %esi
  > 	movb %al, (%edi)
  > 	incl %edi
  > 	testl %eax
  > 	jne loop
  > 
  > After the first iteration, the xorl is unnecessary.  We ought to be able to
  > hoist it out of the loop.
True, but I don't believe the loop optimizer is prepared to do that since it
doesn't keep track of what bits are active vs what bits are inactive in a 
value.

jeff

Re: gcc-2.7 creates faster code than pgcc-1.1.1

[Joe Buck]

> None of the papers discussed it in a floating point context, merely from an
> integer context.  The basics were you had a range [min,max] and a bit which
> indicated that the value was in or out of the range which was built up on a
> basic block level for each expression.
> ...
> As you mention it could be used to detect and eliminate things like domain
> checks which depend solely on the range, not the precision.

There's been work on fixed point optimization for embedded DSP that also
propagates precision information.  e.g. we have [min,max,prec] which means
that the value is known to be a multiple of pow(2,prec), as well as being
in [min,max].  The idea is that we want to eliminate both the
overflow-check operations and the rounding operations in generated code.

Re: gcc-2.7 creates faster code than pgcc-1.1.1

[Zack Weinberg]

On Thu, 4 Mar 1999 22:20:18 +0100, Jamie Lokier wrote:
>> After several day of search I finally find out offending
>> instruction that slow down gzip compiled with egcs-1.1.1/pgcc-1.1.1
>> on PentiumPro 180MHz (132MB RAM) but the result seems crazy to me.
>> 
>> This instruction is:
>> andl $255, %eax
>> in flush_window (util.c) function body (it is inlined from updcrc)
>> 
>> if you manually replace it with
>> movzbl %al, $eax
>> this will boost decompression by 20%.
>
>In the past I have written hand-optimised assembly language, tuned for
>the different x86 families, and I found movzbl to be a very effective
>instruction on the Pentium Pro.  So what you describe sounds correct.
>
>Another is to do xorl %eax,%eax just before loading something into %al.
>That is fast on the PPro too.

A related issue:  I see us generate a lot of code like this for loops over
strings:

loop:
	xorl %eax, %eax
	movb (%esi), %al
	incl %esi
	movb %al, (%edi)
	incl %edi
	testl %eax
	jne loop

After the first iteration, the xorl is unnecessary.  We ought to be able to
hoist it out of the loop.

zw

Re: gcc-2.7 creates faster code than pgcc-1.1.1

[Zack Weinberg]

On Thu, 04 Mar 1999 23:03:58 -0500, David Edelsohn wrote:
>>>>>> Jeffrey A Law writes:
>
>Jeff> True, but I don't believe the loop optimizer is prepared to do that sinc
>e it
>Jeff> doesn't keep track of what bits are active vs what bits are inactive in 
>a 
>Jeff> value.
>
>	GCC is missing a general feature of value propagation which would
>help with a lot of optimizations like this.  Hopefully this infrastructure
>will be added or contributed someday.

For the case I'm interested in, we don't need general value propagation,
only to recognize that we are loading QImode values into a register without
sign extension.  Mode-based range analysis ought to be simpler than full
value propagation.

If we knew how to generate QImode compares, we wouldn't need to clear the
register at all.  That may be something fixable in i386.md, I'm not sure.

zw

Re: gcc-2.7 creates faster code than pgcc-1.1.1

[craig]

>Most of the papers I've read have indicated only trivial gains from value
>range propagation.  I've also had discussions with folks that have implemented
>this opt in a commercial compiler -- it's so minor of a win that they didn't
>consider it worth the effort.

If that we really true *generally*, i.e. for floating-point as well,
then we could happily make -mieee the default for egcs/gcc on Alphas,
for example.  (This would make Alpha-generated floating-point code
much slower, of course, which is why I mention it: if it was possible
to use value-range propagation to determine when the special code-
generation normally needed for full IEEE range wasn't needed after all,
then some of that performance could be regained.)

But, I have to admit I can't document any really clear performance
wins from my own hand-tuned assembly code (written over the past few
decades) deriving solely from value-range propagation, especially
for *integer* (versus floating-point) values.

Generally, I think being able to avoid even checking for exceptional
values might be one source of performance wins from this: e.g. if
we knew it was "impossible" to divide by zero here, square-root a
negative number there, and so on, we could save generated extra
code, thus making Icache misses theoretically less frequent.

        tq vm, (burley)

Re: porting EGCS to the Cray T3E

[Toon Moene]

> > [ Whadusay ?  Virtual memory ?  Hah, I could quote Seymour
> >    Cray's opinion on virtual memory here, but this is a decent
> >    mailing list without explicit adult material, so I'll refrain ]

> PLEASE quote, or give a pointer. We all need to lighten up :-)

Huh ?  I thought that, now that we had decided to extend our  
support to Supercomputers, everyone would immediately rush out to  
study the comp.sys.super FAQs.

More specifically, search for

	cray AND memory

in http://www.dejanews.com and thou shalt be enlightened :-)

Cheers,
Toon.

Re: porting EGCS to the Cray T3E

[Martin Knoblauch]

---Toon Moene <toon@moene.indiv.nluug.nl> wrote:
>
> 
> 2. The T3E has a single global address space.  This means that any
>    processing element can access (read/write) the memory belonging
>    to any other PE; the necessary physical transfer of data is
>    handled by the interconnect.  I think I recall (!) that the global
>    addressing is accomplished by encoding the PE number in the upper 
>    bits of the address.
> 
>    [ Whadusay ?  Virtual memory ?  Hah, I could quote Seymour
>      Cray's opinion on virtual memory here, but this is a decent
>      mailing list without explicit adult material, so I'll refrain ]
>

 PLEASE quote, or give a pointer. We all need to lighten up :-)
 
Martin
===
------------------------------------------------------
Martin Knoblauch
email: knobi@knobisoft.de or knobi@rocketmail.com
www:   http://www.knobisoft.de
_________________________________________________________
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com

Re: porting EGCS to the Cray T3E

[Toon Moene]

I wrote:

>  A T3E is just a bunch of 21164 Alpha's interconnected in
>  an interesting way.  If the C library on the system is
>  not really botched up beyond repair, it shouldn't be
>  impossible to create an alphaev5-unicosmk-cray target.
>  However, this is about as much as I know about this topic,
>  so people with more info are kindly requested to step
>  forward.

As pointed out by Martin Knoblauch <knobi@rocketmail.com>, it  
should be alphaev5-cray-unicosmk, and as Julian C. Cummings  
<julianc@acl.lanl.gov> pointed out, the assembly language on the  
Cray is different from that on Digital Unix and the Free Unixen that  
have an Alpha port.  In fact, even though I only spent a few hours  
on a T3E January last year - and didn't have time to dig into the  
assembly language outcome of my compiles - I wouldn't be surprised [  
given previous experience with products from Mr. Cray ] that

	mulf	$f21, $f22, $f23

should be encoded as

	FX23	X21*X22

and

	shl	$11, $12, $13

as

	BA13	A11<A12

:-)

Some more serious observations vis-a-vis the T3E (all IIRC):

1. The operating system is micro-kernel based, but it's UNICOS (the
   vector computer's OS) compatible, i.e. it has a SYSV
   attitude^H^H^H^H^H^Hpersonality.

2. The T3E has a single global address space.  This means that any
   processing element can access (read/write) the memory belonging
   to any other PE; the necessary physical transfer of data is
   handled by the interconnect.  I think I recall (!) that the global
   addressing is accomplished by encoding the PE number in the upper 
   bits of the address.

   [ Whadusay ?  Virtual memory ?  Hah, I could quote Seymour
     Cray's opinion on virtual memory here, but this is a decent
     mailing list without explicit adult material, so I'll refrain ]

3. Last but not least, the Alpha's inside a T3E are operated in
   big-endian mode.  Little-endian is for peecee's (it's not called
   *little*-endian for nothing).

Hope this helps,
Toon.

Re: porting EGCS to the Cray T3E

[Julian C. Cummings]

>>  not 100% sure, but as the T3D/E are Alpha based systems,
>> the name should probably be "alpha-cray-unicosmk". Then you
>> should go to the "gcc/config/alpha" directory and create
>> the necessary config files. Next step would be to step-by-step
>> eliminate the error messages from "configure" ... It seems
>> that you are at least missing a few libraries and header
>> files. They may have different names, or are at different places.

OK, I will try this.  I don't quite understand your comment about
eliminating error messages from the configure output.  I thought
the purpose of the configure script was to determine what capabilities
the system does and does not have.  An "error" should not be fatal; it
just directs the configure script not to use features that are not
available on the system.

>>  What kind of Unix (BSD, SYSV, OSF) is unicosmk? Never got
>> in touch with it when I was working for SGI/Cray.
>>
>> Martin

I'm not sure how to answer your question.  UnicosMK is a microkernel
variant of Cray's Unicos operating system, designed to fit on individual
nodes of an MPP machine like the T3E.  Unicos has been around for a while.

Julian C.


-- 
Julian C. Cummings
Advanced Computing Laboratory
Los Alamos National Laboratory
(505) 667-6064
julianc@acl.lanl.gov

Re: porting EGCS to the Cray T3E

[Toon Moene]

  In message < 9807131529.ZM1628@vapor.acl.lanl.gov >you write:
  > the config.log output from egcs-objdir/gcc.  I don't see offhand 
  > why the configuration failed.

  > configure --prefix=/usr/tmp/julianc/EGCS/egcs-objdir
  > --host=crayt3e

>  It probably failed because it thought you also wanted to
>  *target* for a cray, which isn't supported.

Some Crays are more equal than others :-)

A T3E is just a bunch of 21164 Alpha's interconnected in an  
interesting way.  If the C library on the system is not really  
botched up beyond repair, it shouldn't be impossible to create an  
alphaev5-unicosmk-cray target.  However, this is about as much as I  
know about this topic, so people with more info are kindly requested  
to step forward.

[ I never did more than building diffutils-2.7, make-3.75 and rcs-5.7
  on it ]

Cheers,
Toon.

Re: porting EGCS to the Cray T3E

[Benjamin Redelings I]

I once tried to compile gcc for the cray.  I told it the cray was an
alpha/OSF2 or something like that.  I actually did get an executable, but
the Cray assembler couldn't understand the assembly.  I think I gave up
then.  Or perhaps I tried to build the GNU binutils and failed...
	But since the cray is just an alpha, I'd think that you should be able to
make egcs work if they have a supported binary format for the files and
libraries.

-benRI

Re: porting EGCS to the Cray T3E

[Martin Knoblauch]

Julian,

 not 100% sure, but as the T3D/E are Alpha based systems,
the name should probably be "alpha-cray-unicosmk". Then you
should go to the "gcc/config/alpha" directory and create
the necessary config files. Next step would be to step-by-step
eliminate the error messages from "configure" ... It seems
that you are at least missing a few libraries and header
files. They may have different names, or are at different places.

 What kind of Unix (BSD, SYSV, OSF) is unicosmk? Never got
in touch with it when I was working for SGI/Cray.


Martin
===
------------------------------------------------------
Martin Knoblauch
email: knobi@knobisoft.de or knobi@rocketmail.com
www:   http://www.knobisoft.de







---"Julian C. Cummings" <julianc@acl.lanl.gov> wrote:
>
> Hi,
> 
> I am interested in trying to port the EGCS compiler to the Cray T3E.
 I am
> using a June 13th snapshot of the EGCS sources.  I unpacked the
sources and
> created a directory egcs-objdir for building the compiler.  The
first thing I
> discovered when I tried to run the configure script was that it is
not familiar
> with the Cray T3E architecture.  So I edited the config.sub file and
added a
> case for the host type "crayt3e" which sets basic_machine to
"crayt3e-cray" and
> sets os to
> "-unicosmk".  (This is based on what you get when you run "uname -m"
and "uname
> -v" on the T3E.)  Then I ran configure like this:
> 
> configure --prefix=/usr/tmp/julianc/EGCS/egcs-objdir --host=crayt3e
> 
> It told me it was creating a Makefile, then it whirred for a while,
and finally
> it came back and reported a failure in configuring egcs-objdir/gcc. 
Below is
> the config.log output from egcs-objdir/gcc.  I don't see offhand why
the
> configuration failed.  If anyone can help me with interpreting the
configure
> output and understanding this problem, I would very much appreciate
it.  Is the
> EGCS compiler supposed to be directly portable to Cray platforms in
this way?
> 
> Thanks, Julian C.
> 
> 
> 
> This file contains any messages produced by compilers while
> running configure, to aid debugging if configure makes a mistake.
> 

_________________________________________________________
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com

Re: porting EGCS to the Cray T3E

[Jeffrey A Law]

  In message < 9807131529.ZM1628@vapor.acl.lanl.gov >you write:
  > the config.log output from egcs-objdir/gcc.  I don't see offhand why the
  > configuration failed.
 
  > configure --prefix=/usr/tmp/julianc/EGCS/egcs-objdir --host=crayt3e

It probably failed because it thought you also wanted to *target* for
a cray, which isn't supported.

jeff

porting EGCS to the Cray T3E

[Julian C. Cummings]

Hi,

I am interested in trying to port the EGCS compiler to the Cray T3E.  I am
using a June 13th snapshot of the EGCS sources.  I unpacked the sources and
created a directory egcs-objdir for building the compiler.  The first thing I
discovered when I tried to run the configure script was that it is not familiar
with the Cray T3E architecture.  So I edited the config.sub file and added a
case for the host type "crayt3e" which sets basic_machine to "crayt3e-cray" and
sets os to
"-unicosmk".  (This is based on what you get when you run "uname -m" and "uname
-v" on the T3E.)  Then I ran configure like this:

configure --prefix=/usr/tmp/julianc/EGCS/egcs-objdir --host=crayt3e

It told me it was creating a Makefile, then it whirred for a while, and finally
it came back and reported a failure in configuring egcs-objdir/gcc.  Below is
the config.log output from egcs-objdir/gcc.  I don't see offhand why the
configuration failed.  If anyone can help me with interpreting the configure
output and understanding this problem, I would very much appreciate it.  Is the
EGCS compiler supposed to be directly portable to Cray platforms in this way?

Thanks, Julian C.



This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

configure:757: checking host system type
configure:778: checking target system type
configure:796: checking build system type
configure:823: checking for gcc
configure:900: checking whether the C compiler (cc -g ) works
configure:914: cc -o conftest -g   conftest.c  1>&5
configure:934: checking whether the C compiler (cc -g ) is a cross-compiler
configure:939: checking whether we are using GNU C
configure:991: checking whether make sets ${MAKE}
configure:1024: checking for mawk
configure:1024: checking for gawk
configure:1024: checking for nawk
configure:1055: checking for flex
configure:1088: checking for yywrap in -lfl
configure:1107: cc -o conftest -g   conftest.c -lfl   1>&5
cld-315 cld: ERROR
  The library file `libfl.a' was not found.
cld-117 cld: FATAL
  Errors occurred processing the input files.
configure: failed program was:
#line 1096 "configure"
#include "confdefs.h"
/* Override any gcc2 internal prototype to avoid an error.  */
/* We use char because int might match the return type of a gcc2
    builtin and then its argument prototype would still apply.  */
char yywrap();

int main() {
yywrap()
; return 0; }
configure:1130: checking whether ln works
configure:1162: checking whether ln -s works
configure:1194: checking for volatile
configure:1206: cc -c -g  conftest.c 1>&5
configure:1229: checking for ranlib
configure:1260: checking for bison
configure:1300: checking for a BSD compatible install
configure:1351: checking how to run the C preprocessor
configure:1412: checking for ANSI C header files
configure:1516: checking whether time.h and sys/time.h may both be included
configure:1530: cc -c -g  conftest.c 1>&5
configure:1554: checking for limits.h
configure:1554: checking for stddef.h
configure:1564: cc -E  conftest.c >/dev/null 2>conftest.out
configure:1554: checking for string.h
configure:1554: checking for strings.h
configure:1554: checking for stdlib.h
configure:1554: checking for time.h
configure:1564: cc -E  conftest.c >/dev/null 2>conftest.out
configure:1554: checking for fcntl.h
configure:1554: checking for unistd.h
configure:1554: checking for stab.h
configure:1564: cc -E  conftest.c >/dev/null 2>conftest.out
CC-5 cc: ERROR File = configure, Line = 1560
  The source file "stab.h" is unavailable.

  #include <stab.h>
                   ^

1 catastrophic error detected in the compilation of "conftest.c".
Compilation terminated.
configure: failed program was:
#line 1559 "configure"
#include "confdefs.h"
#include <stab.h>
configure:1554: checking for sys/file.h
configure:1554: checking for sys/time.h
configure:1554: checking for sys/resource.h
configure:1564: cc -E  conftest.c >/dev/null 2>conftest.out
configure:1554: checking for sys/param.h
configure:1554: checking for sys/times.h
configure:1564: cc -E  conftest.c >/dev/null 2>conftest.out
configure:1554: checking for wait.h
configure:1564: cc -E  conftest.c >/dev/null 2>conftest.out
CC-5 cc: ERROR File = configure, Line = 1560
  The source file "wait.h" is unavailable.

  #include <wait.h>
                   ^

1 catastrophic error detected in the compilation of "conftest.c".
Compilation terminated.
configure: failed program was:
#line 1559 "configure"
#include "confdefs.h"
#include <wait.h>
configure:1554: checking for sys/wait.h
configure:1594: checking for thread.h
configure:1604: cc -E  conftest.c >/dev/null 2>conftest.out
CC-5 cc: ERROR File = configure, Line = 1600
  The source file "thread.h" is unavailable.

  #include <thread.h>
                     ^

1 catastrophic error detected in the compilation of "conftest.c".
Compilation terminated.
configure: failed program was:
#line 1599 "configure"
#include "confdefs.h"
#include <thread.h>
configure:1628: checking for pthread.h
configure:1638: cc -E  conftest.c >/dev/null 2>conftest.out
configure:1664: checking whether cpp understands the stringify operator
configure:1677: cc -c -g  conftest.c 1>&5
configure:1700: checking for inttypes.h
configure:1713: cc -c -g  conftest.c 1>&5
CC-5 cc: ERROR File = configure, Line = 1707
  The source file "inttypes.h" is unavailable.

  #include <inttypes.h>
                       ^

1 catastrophic error detected in the compilation of "conftest.c".
Compilation terminated.
configure: failed program was:
#line 1705 "configure"
#include "confdefs.h"
#include <sys/types.h>
#include <inttypes.h>
int main() {
intmax_t i = -1;
; return 0; }
configure:1736: checking for strtoul
configure:1736: checking for bsearch
configure:1764: cc -o conftest -g   conftest.c  1>&5
configure:1736: checking for strerror
configure:1736: checking for putenv
configure:1736: checking for popen
configure:1764: cc -o conftest -g   conftest.c  1>&5
configure:1736: checking for bcopy
configure:1736: checking for bzero
configure:1736: checking for bcmp
configure:1736: checking for index
configure:1736: checking for rindex
configure:1736: checking for strchr
configure:1736: checking for strrchr
configure:1736: checking for kill
configure:1764: cc -o conftest -g   conftest.c  1>&5
configure:1736: checking for getrlimit
configure:1764: cc -o conftest -g   conftest.c  1>&5
cld-404 cld: WARNING
  The symbol `getrlimit' referenced in relocatable object
`conftest.o:conftest$c' is not defined.
cld-431 cld: WARNING
  The resulting output file `conftest' is not executable because of previous
WARNING messages.
configure: failed program was:
#line 1741 "configure"
#include "confdefs.h"
/* System header to define __stub macros and hopefully few prototypes,
    which can conflict with char getrlimit(); below.  */
#include <assert.h>
/* Override any gcc2 internal prototype to avoid an error.  */
/* We use char because int might match the return type of a gcc2
    builtin and then its argument prototype would still apply.  */
char getrlimit();

int main() {

/* The GNU C library defines this for functions which it implements
    to always fail with ENOSYS.  Some functions are actually named
    something starting with __ and the normal name is an alias.  */
#if defined (__stub_getrlimit) || defined (__stub___getrlimit)
choke me
#else
getrlimit();
#endif

; return 0; }
configure:1736: checking for setrlimit
configure:1764: cc -o conftest -g   conftest.c  1>&5
cld-404 cld: WARNING
  The symbol `setrlimit' referenced in relocatable object
`conftest.o:conftest$c' is not defined.
cld-431 cld: WARNING
  The resulting output file `conftest' is not executable because of previous
WARNING messages.
configure: failed program was:
#line 1741 "configure"
#include "confdefs.h"
/* System header to define __stub macros and hopefully few prototypes,
    which can conflict with char setrlimit(); below.  */
#include <assert.h>
/* Override any gcc2 internal prototype to avoid an error.  */
/* We use char because int might match the return type of a gcc2
    builtin and then its argument prototype would still apply.  */
char setrlimit();

int main() {

/* The GNU C library defines this for functions which it implements
    to always fail with ENOSYS.  Some functions are actually named
    something starting with __ and the normal name is an alias.  */
#if defined (__stub_setrlimit) || defined (__stub___setrlimit)
choke me
#else
setrlimit();
#endif

; return 0; }
configure:1736: checking for atoll
configure:1764: cc -o conftest -g   conftest.c  1>&5
configure:1736: checking for atoq
configure:1764: cc -o conftest -g   conftest.c  1>&5
cld-404 cld: WARNING
  The symbol `atoq' referenced in relocatable object `conftest.o:conftest$c' is
not defined.
cld-431 cld: WARNING
  The resulting output file `conftest' is not executable because of previous
WARNING messages.
configure: failed program was:
#line 1741 "configure"
#include "confdefs.h"
/* System header to define __stub macros and hopefully few prototypes,
    which can conflict with char atoq(); below.  */
#include <assert.h>
/* Override any gcc2 internal prototype to avoid an error.  */
/* We use char because int might match the return type of a gcc2
    builtin and then its argument prototype would still apply.  */
char atoq();

int main() {

/* The GNU C library defines this for functions which it implements
    to always fail with ENOSYS.  Some functions are actually named
    something starting with __ and the normal name is an alias.  */
#if defined (__stub_atoq) || defined (__stub___atoq)
choke me
#else
atoq();
#endif

; return 0; }
configure:1736: checking for sysconf
configure:1736: checking for isascii
configure:1764: cc -o conftest -g   conftest.c  1>&5
configure:1790: checking for vprintf
configure:1906: checking whether the printf functions support %p
configure:1927: cc -o conftest -g   conftest.c  1>&5
configure:1955: checking whether malloc must be declared
configure:1987: cc -c -g  conftest.c 1>&5
configure:1955: checking whether realloc must be declared
configure:1987: cc -c -g  conftest.c 1>&5
configure:1955: checking whether calloc must be declared
configure:1987: cc -c -g  conftest.c 1>&5
configure:1955: checking whether free must be declared
configure:1987: cc -c -g  conftest.c 1>&5
configure:1955: checking whether bcopy must be declared
configure:1987: cc -c -g  conftest.c 1>&5
configure:1955: checking whether bzero must be declared
configure:1987: cc -c -g  conftest.c 1>&5
configure:1955: checking whether bcmp must be declared
configure:1987: cc -c -g  conftest.c 1>&5
configure:1955: checking whether index must be declared
configure:1987: cc -c -g  conftest.c 1>&5
configure:1955: checking whether rindex must be declared
configure:1987: cc -c -g  conftest.c 1>&5
configure:1955: checking whether getenv must be declared
configure:1987: cc -c -g  conftest.c 1>&5
configure:1955: checking whether atol must be declared
configure:1987: cc -c -g  conftest.c 1>&5
configure:1955: checking whether sbrk must be declared
configure:1987: cc -c -g  conftest.c 1>&5
configure:1955: checking whether abort must be declared
configure:1987: cc -c -g  conftest.c 1>&5
configure:1955: checking whether atof must be declared
configure:1987: cc -c -g  conftest.c 1>&5
configure:2014: checking for sys_siglist declaration in signal.h or unistd.h
configure:2031: cc -c -g  conftest.c 1>&5
CC-20 cc: ERROR File = configure, Line = 2027
  The identifier "sys_siglist" is undefined.

  char *msg = *(sys_siglist + 1);
                ^

1 error detected in the compilation of "conftest.c".
configure: failed program was:
#line 2019 "configure"
#include "confdefs.h"
#include <sys/types.h>
#include <signal.h>
/* NetBSD declares sys_siglist in unistd.h.  */
#ifdef HAVE_UNISTD_H
#include <unistd.h>
#endif
int main() {
char *msg = *(sys_siglist + 1);
; return 0; }

-- 
Julian C. Cummings
Advanced Computing Laboratory
Los Alamos National Laboratory
(505) 667-6064
julianc@acl.lanl.gov