gcc-2.95 status

gcc-2.95 status

[Jeffrey A Law]

Just to let folks who do not read the schedule & regression status pages
know where we stand on the gcc-2.95 release.

The critical bugfreeze date was originally scheduled for July 15th.  We
slipped that 1 week to July 22 to give us more time to address some of the
problems encountered during testing.

Since we are now past the critical bug-freeze date we are only accepting
patches for critical bugs and all patches have to be run by me before
they are to be installed on the gcc-2.95 branch.

--

We also slipped the proposed release date by one week from July 1 to July 8.

-


Outstanding testing related issues for the release (ie, stuff you can help 
with!)

  Regressions on i686-pc-sco3.2v5.0.5.  Robert Lipe is currently on vacation,
  but returns July 1 I believe.  I'm going to try and simulate some of those
  failures by building a Linux system with dwarf1 debug symbols by default.
  Otherwise we'll have to wait for Robert to return before we can attack these
  problems.

  We need libg++ tested on the following platforms:

   i686-pc-sco3.2v5.0.5 (Robert Lipe)
   i686-pc-linux-gnulibc1


  libgcj/libjava has exposed a compiler bug on mips-sgi-irix6.5 that needs
  to be fixed.  Other build failures have been libgcj portability problems.
  libgjc/libjava build issues will not hold up the release unless they are
  compiler bugs.

  glibc-2.1.1 needs to be built & tested on a sparc-linux machine.  Alexandre
  Oliva is taking care of this.

  linux-2.2.10 needs to be built installed and booted on an alpha, powerpc and
  sparc system.  Note that you should build the kernel "-fno-strict-aliasing".


  The few remaining failures for a redhat-6.0 build on the x86 need to
  be resolved.  If someone wants to do redhat-6.0 builds on one of the other
  processors it supports, please do so and let me know the results.  Note
  several C++ packages need "-fpermissive" to build.

  Any additional Fortran and C++ testing needs to be hashed out in the very
  near future.  ie, what package, where can folks get it, how to build and
  test, etc.


There's still a few non-testing related bugs that need to be fixed.  I'll
be making a pass over my pending bugs directory this weekend to flush the
critical ones out and try to nail them down.


We're in the home stretch.  I'd like to thank everyone that has contributed
fixes, test results, bug analysis, build reports, etc etc.  Believe me, none
of this would be possible without your help.

jeff

Re: gcc-2.95 status

[Marc Espie]

In article < 4032.930228776@upchuck.cygnus.com > you write:
>
>
>Just to let folks who do not read the schedule & regression status pages
>know where we stand on the gcc-2.95 release.
>
>The critical bugfreeze date was originally scheduled for July 15th.  We
>slipped that 1 week to July 22 to give us more time to address some of the
>problems encountered during testing.

>Since we are now past the critical bug-freeze date we are only accepting
>patches for critical bugs and all patches have to be run by me before
>they are to be installed on the gcc-2.95 branch.


There's still some highly critical stuff for me. I'd really like m68k
pic to work a little bit more reliably for floating point.

This is a large, critical problem for OpenBSD... we'd rather not put the m68k
platforms in the list of `dead' machines, but we can't really ship releases
with two distinct compilers with different features.

See http://egcs.cygnus.com/ml/egcs-bugs/1999-05/msg00764.html
for an example of how critical it is.

I must stress that if this bug remains in gcc 2.95, there's a chance we will
have to revert our recent changes and ship the next OpenBSD release with
gcc 2.8.1 (as you know, egcs 1.1 is unsuitable for us, since code bloat is
an issue for boot floppies) :(

There's also that netbsd sparc problem I forwarded to the list, with a
potential fix (removing some egcs-1.1.2 code, 
http://egcs.cygnus.com/ml/egcs-bugs/1999-06/msg00238.html )

I'm available for helping checking/elucidating stuff, but I'm nowhere near the
level of analysing and fixing those problems... 
... plus, I still have quite a few linker/assembler related problems to fix,
and a bunch of ports to adapt to g++-2.95...

Re: gcc-2.95 status

[Toon Moene]

Jeffrey A Law wrote:

> The critical bugfreeze date was originally scheduled for July 15th.  We
> slipped that 1 week to July 22 to give us more time to address some of the
> problems encountered during testing.

You probably mean "June" here, or you have just invented a time warp :-)

>   Any additional Fortran and C++ testing needs to be hashed out in the very
>   near future.  ie, what package, where can folks get it, how to build and
>   test, etc.

One thing that would be interesting is to test LAPACK - available from:

http://www.netlib.org/lapack/lapack.tgz (note: 4 Mbyte)

- on 64-bit architectures.

It stress-tests the COMPLEX / DOUBLE COMPLEX stuff in the backend (and
the inlined (DOUBLE) COMPLEX division :-)

It passes on i686-pc-linux-gnu with the flags: -g -O3 -funroll-loops
-fomit-frame-pointer.

Some caveats:

1. The code uses MAX(I,J,K) in PARAMETER statements in some places.
   G77 doesn't grok this yet.  Because (lemma follows):

   max(i,j,k) <= i + j + k, for all i, j, k => 0

   you can safely replace the `max' statement with i+j+k.
   [ It only deals with sizes (of arrays), so overestimating is OK ]

2. The build process assumes . is in your PATH (though not necessarily
   in first position).

3. After successful completion, some files ending in .SUMM are left
   in various subdirectories.  Since these files are opened with
   "STATUS='NEW'", they have to be removed before the next trial
   run.

You have to specify the location of the compiler and the linker (both
the g77 you want to test) and the compiler flags, in a `make.inc' file
in the main directory.

So the chain of events is:

1. Get lapack.tgz.

2. tar zxvf lapack.tgz.

3. cd LAPACK

4. vi make.inc

5. (PATH=$PATH:. export PATH; make)

6. g77 finds problematic MAX statements - repair as indicated above.

7. (PATH=$PATH:. export PATH; rm `find . -name '*.SUMM' -print`; \
    make clean; make)

Success !

-- 
Toon Moene (toon@moene.indiv.nluug.nl)
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Phone: +31 346 214290; Fax: +31 346 214286
GNU Fortran: http://world.std.com/~burley/g77.html

Re: gcc-2.95 status

[Jeffrey A Law]

  In message < 199906241346.PAA01577@quatramaran.ens.fr >you write:
  > See http://egcs.cygnus.com/ml/egcs-bugs/1999-05/msg00764.html
  > for an example of how critical it is.
I've already stated that bug is unlikely to get fixed.

gcc-2.x has the same bug, you just have been lucky and haven't tripped
over it.

jeff

Re: gcc-2.95 status

[Martin Kahlert]

Quoting Jeffrey A Law (law@cygnus.com):

>   linux-2.2.10 needs to be built installed and booted on an alpha, powerpc and
>   sparc system.  Note that you should build the kernel "-fno-strict-aliasing".

I tried that at home last weekend on Linux AXP (Ruffian),
but i didn't succeed.  I didn't specify the -fno-strict-aliasing.
Is it that important?

Thanks for clarification.
Martin.

-- 
esa$ gcc -Wall -o ariane5 ariane5.c
ariane5.c: 666: warning: long float implicitly truncated to unsigned type
esa$ ariane5

Re: gcc-2.95 status

[Jeffrey A Law]

  In message < 19990625094648.A9270@keksy.mchp.siemens.de >you write:
  > I tried that at home last weekend on Linux AXP (Ruffian),
  > but i didn't succeed.  I didn't specify the -fno-strict-aliasing.
  > Is it that important?
It is definitely important.  The linux kernel does things with memory
access that violate the ANSI/ISO aliasing rules.  GCC depends on those
rules to determine when it is safe to reorder certain memory accesses.

jeff

Re: gcc-2.95 status

[Marc Espie]

In article < 5777.930270167@upchuck.cygnus.com > you write:

>  In message < 199906241346.PAA01577@quatramaran.ens.fr >you write:
>  > See http://egcs.cygnus.com/ml/egcs-bugs/1999-05/msg00764.html
>  > for an example of how critical it is.
>I've already stated that bug is unlikely to get fixed.

>gcc-2.x has the same bug, you just have been lucky and haven't tripped
>over it.

Sure, some bug that kills utterly simple X windows code on m68k code...
that already existed in gcc 2.8.x, but that I *never* encountered with
2.8.1.

Why don't we declare the m68k dead while we're at it ? scrap mac68k,
exit amiga, no more atari St, and sell hp300 for scrap metal.

Now, bother about some fucked up linux code instead that does stuff it's
not supposed to, which isn't portable at all, and for which there is even
a known technique using union...

Not wanting to start a flamewar, don't bother answering... I just need
to get this out of my system.

m68k-openbsd -fpic fix

[Richard Henderson]

On Thu, Jun 24, 1999 at 06:22:47PM -0600, Jeffrey A Law wrote:
>   > See http://egcs.cygnus.com/ml/egcs-bugs/1999-05/msg00764.html
>   > for an example of how critical it is.
>
> I've already stated that bug is unlikely to get fixed.

I had a look at this this morning.  Unless I'm dreadfully mistaken,
this is not a difficult bug, but in fact quite simple.

m68k can load arbitrary floating point constants directly.  There's
no need to spill them to memory, pic or non-pic.  It would probably
make for smaller code if constants that appeared more than once 
were spilled to memory earlier, but no effort has been made to do
this.  In any case, there's no need to do it during reload.

So a simple tweek to PREFERRED_RELOAD_CLASS seems to be all that's
necessary.


r~


	* m68k.h (PREFERRED_RELOAD_CLASS): Don't force any FP const_doubles
	to memory.

Index: m68k.h
===================================================================
RCS file: /egcs/carton/cvsfiles/egcs/gcc/config/m68k/m68k.h,v
retrieving revision 1.32
diff -c -p -d -r1.32 m68k.h
*** m68k.h	1999/03/01 15:06:46	1.32
--- m68k.h	1999/06/26 22:32:58
*************** extern enum reg_class regno_reg_class[];
*** 772,794 ****
     in some cases it is preferable to use a more restrictive class.
     On the 68000 series, use a data reg if possible when the
     value is a constant in the range where moveq could be used
!    and we ensure that QImodes are reloaded into data regs.
!    Also, if a floating constant needs reloading, put it in memory.
!    Don't do this for !G constants, since all patterns in the md file
!    expect them to be loaded into a register via fpmovecr.  See above.  */
  
! #define PREFERRED_RELOAD_CLASS(X,CLASS)  \
!   ((GET_CODE (X) == CONST_INT			\
!     && (unsigned) (INTVAL (X) + 0x80) < 0x100	\
!     && (CLASS) != ADDR_REGS)			\
!    ? DATA_REGS					\
!    : (GET_MODE (X) == QImode && (CLASS) != ADDR_REGS) \
!    ? DATA_REGS					\
!    : (GET_CODE (X) == CONST_DOUBLE		\
!       && GET_MODE_CLASS (GET_MODE (X)) == MODE_FLOAT) \
!    ? (! CONST_DOUBLE_OK_FOR_LETTER_P (X, 'G')	\
!       && (CLASS == FP_REGS || CLASS == DATA_OR_FP_REGS) \
!       ? FP_REGS : NO_REGS)			\
     : (CLASS))
  
  /* Force QImode output reloads from subregs to be allocated to data regs,
--- 772,790 ----
     in some cases it is preferable to use a more restrictive class.
     On the 68000 series, use a data reg if possible when the
     value is a constant in the range where moveq could be used
!    and we ensure that QImodes are reloaded into data regs.  */
  
! #define PREFERRED_RELOAD_CLASS(X,CLASS)					\
!   ((GET_CODE (X) == CONST_INT						\
!     && (unsigned) (INTVAL (X) + 0x80) < 0x100				\
!     && (CLASS) != ADDR_REGS)						\
!    ? DATA_REGS								\
!    : (GET_MODE (X) == QImode && (CLASS) != ADDR_REGS)			\
!    ? DATA_REGS								\
!    : (GET_CODE (X) == CONST_DOUBLE					\
!       && GET_MODE_CLASS (GET_MODE (X)) == MODE_FLOAT)			\
!    ? (TARGET_68881 && (CLASS == FP_REGS || CLASS == DATA_OR_FP_REGS)	\
!       ? FP_REGS : NO_REGS)						\
     : (CLASS))
  
  /* Force QImode output reloads from subregs to be allocated to data regs,

Re: m68k-openbsd -fpic fix

[Jeffrey A Law]

  In message < 19990626153434.A28430@cygnus.com >you write:
  > On Thu, Jun 24, 1999 at 06:22:47PM -0600, Jeffrey A Law wrote:
  > >   > See http://egcs.cygnus.com/ml/egcs-bugs/1999-05/msg00764.html
  > >   > for an example of how critical it is.
  > >
  > > I've already stated that bug is unlikely to get fixed.
  > 
  > I had a look at this this morning.  Unless I'm dreadfully mistaken,
  > this is not a difficult bug, but in fact quite simple.
  > 
  > m68k can load arbitrary floating point constants directly.  There's
  > no need to spill them to memory, pic or non-pic. 
  > It would probably
  > make for smaller code if constants that appeared more than once 
  > were spilled to memory earlier, but no effort has been made to do
  > this.  In any case, there's no need to do it during reload.
  > So a simple tweek to PREFERRED_RELOAD_CLASS seems to be all that's
  > necessary.
It the tip of the iceberg, though it probably is worth including to deal with
this instance of one of the more general problems with the m68k PIC code.

The other simple things we can do to greatly improve the m68k PIC support
would be to mark the PIC register as fixed and kill the FINALIZE_PIC
nonsense (those generate wrong code as opposed to compiler aborts).

jeff

Re: m68k-openbsd -fpic fix

[Jeffrey A Law]

  In message < 19990626153434.A28430@cygnus.com >you write:
  > On Thu, Jun 24, 1999 at 06:22:47PM -0600, Jeffrey A Law wrote:
  > >   > See http://egcs.cygnus.com/ml/egcs-bugs/1999-05/msg00764.html
  > >   > for an example of how critical it is.
  > >
  > > I've already stated that bug is unlikely to get fixed.
  > 
  > I had a look at this this morning.  Unless I'm dreadfully mistaken,
  > this is not a difficult bug, but in fact quite simple.
  > 
  > m68k can load arbitrary floating point constants directly.  There's
  > no need to spill them to memory, pic or non-pic.  It would probably
  > make for smaller code if constants that appeared more than once 
  > were spilled to memory earlier, but no effort has been made to do
  > this.  In any case, there's no need to do it during reload.
  > 
  > So a simple tweek to PREFERRED_RELOAD_CLASS seems to be all that's
  > necessary.
  > 
  > 
  > r~
  > 
  > 
  > 	* m68k.h (PREFERRED_RELOAD_CLASS): Don't force any FP const_doubles
  > 	to memory.
I went ahead and installed this (mainline and branch).
jeff

Re: m68k-openbsd -fpic fix

[Marc Espie]

In article < 16202.930569196@upchuck.cygnus.com > you write:

>  > 	* m68k.h (PREFERRED_RELOAD_CLASS): Don't force any FP const_doubles
>  > 	to memory.
>I went ahead and installed this (mainline and branch).
>jeff

The amiga hasn't finished compiling yet, but it looks like this fixes
*EVERY* pic failure I had so far.

Basically, m68k-openbsd looks in much nicer shape now... I'll probably
have one last bug-report for it (which looks completely unrelated) in
a week (vacation...)

Thanks for a great job !    Pity I had to whine to get my fix (there's
no justice ;-) ), but I'm very, very happy with the result.

Re: m68k-openbsd -fpic fix

[Joe Buck]

[ 68k bug with forcing constants to memory ]

Marc Espie writes:
> Thanks for a great job !    Pity I had to whine to get my fix (there's
> no justice ;-) ), but I'm very, very happy with the result.

Especially for the lesser-used platforms, it seems that bugs often won't
get fixed unless the priority is somehow raised.  Whining by a respected
person is one of the more efficient ways to accomplish this. :-)

Re: m68k-openbsd -fpic fix

[Andreas Schwab]

Jeffrey A Law <law@cygnus.com> writes:

|> The other simple things we can do to greatly improve the m68k PIC support
|> would be to mark the PIC register as fixed and kill the FINALIZE_PIC
|> nonsense (those generate wrong code as opposed to compiler aborts).

That would be bad.  Unlike other targets, on the m68k there is actually no
fixed PIC register (you can use any other address register instead), and a
function that accesses no global data does not need it at all (function
calls don't need the PIC register).

Andreas.

-- 
Andreas Schwab                                      "And now for something
schwab@issan.cs.uni-dortmund.de                      completely different"
schwab@gnu.org

Re: m68k-openbsd -fpic fix

[Jeffrey A Law]

  In message < vyzaetj7t7u.fsf@issan.cs.uni-dortmund.de >you write:
  > That would be bad.  Unlike other targets, on the m68k there is actually no
  > fixed PIC register
Most targets do not have a PIC register either.

  > (you can use any other address register instead), and a
  > function that accesses no global data does not need it at all (function
  > calls don't need the PIC register).
True, but the current state of our compiler is if you don't make the PIC
register fixed, then you're going to get incorrect code.  The m68k is no
different.

jeff

Re: gcc-2.95 status

[Robert Lipe]

>   Regressions on i686-pc-sco3.2v5.0.5.  Robert Lipe is currently on vacation,
>   but returns July 1 I believe.  I'm going to try and simulate some of those

I'm back.  The weirdness in cp/init.c that was introduced just before I
left seems to be fixed.  (Thank you, Mark!)  

The OpenServer testsuite results as of this morning are identical to
those of 6/18.

>   We need libg++ tested on the following platforms:
>    i686-pc-sco3.2v5.0.5 (Robert Lipe)

I'll try to spin a build and test of that today.  Historically I ignore
libg++ becuase it's a discontinued package and the testsuite catches on
fire when run on a multiliberated host.   If I remember correctly I can
do the tests manually.

> We're in the home stretch.  I'd like to thank everyone that has contributed
> fixes, test results, bug analysis, build reports, etc etc.  Believe me, none
> of this would be possible without your help.

Thanx for all your hard work, Jeff.  On behalf of the EGCS user
community I hereby award you a full night of sleep. :-)

RJL

Re: gcc-2.95 status

[Robert Lipe]

>   We need libg++ tested on the following platforms:
> 
>    i686-pc-sco3.2v5.0.5 (Robert Lipe)

COFF and the testsuite won't play nicely together (and neither Manfred
nor I could get excited about dumping a lot of time into a discontinued
package to fix this) so this result is only for ELF.   Here is  the tail
of a 'make check-target-libg++'

                === libg++ Summary ===

# of expected passes            72


Is that the test needed?   There were lots of warnings and grousing during
the libg++ build, but it looks like those are expected.

RJL

Re: m68k-openbsd -fpic fix

[Andreas Schwab]

Jeffrey A Law <law@cygnus.com> writes:

|> The other simple things we can do to greatly improve the m68k PIC support
|> would be to mark the PIC register as fixed and kill the FINALIZE_PIC
|> nonsense (those generate wrong code as opposed to compiler aborts).

That would be bad.  Unlike other targets, on the m68k there is actually no
fixed PIC register (you can use any other address register instead), and a
function that accesses no global data does not need it at all (function
calls don't need the PIC register).

Andreas.

-- 
Andreas Schwab                                      "And now for something
schwab@issan.cs.uni-dortmund.de                      completely different"
schwab@gnu.org

Re: gcc-2.95 status

[Robert Lipe]

>   Regressions on i686-pc-sco3.2v5.0.5.  Robert Lipe is currently on vacation,
>   but returns July 1 I believe.  I'm going to try and simulate some of those

I'm back.  The weirdness in cp/init.c that was introduced just before I
left seems to be fixed.  (Thank you, Mark!)  

The OpenServer testsuite results as of this morning are identical to
those of 6/18.

>   We need libg++ tested on the following platforms:
>    i686-pc-sco3.2v5.0.5 (Robert Lipe)

I'll try to spin a build and test of that today.  Historically I ignore
libg++ becuase it's a discontinued package and the testsuite catches on
fire when run on a multiliberated host.   If I remember correctly I can
do the tests manually.

> We're in the home stretch.  I'd like to thank everyone that has contributed
> fixes, test results, bug analysis, build reports, etc etc.  Believe me, none
> of this would be possible without your help.

Thanx for all your hard work, Jeff.  On behalf of the EGCS user
community I hereby award you a full night of sleep. :-)

RJL

m68k-openbsd -fpic fix

[Richard Henderson]

On Thu, Jun 24, 1999 at 06:22:47PM -0600, Jeffrey A Law wrote:
>   > See http://egcs.cygnus.com/ml/egcs-bugs/1999-05/msg00764.html
>   > for an example of how critical it is.
>
> I've already stated that bug is unlikely to get fixed.

I had a look at this this morning.  Unless I'm dreadfully mistaken,
this is not a difficult bug, but in fact quite simple.

m68k can load arbitrary floating point constants directly.  There's
no need to spill them to memory, pic or non-pic.  It would probably
make for smaller code if constants that appeared more than once 
were spilled to memory earlier, but no effort has been made to do
this.  In any case, there's no need to do it during reload.

So a simple tweek to PREFERRED_RELOAD_CLASS seems to be all that's
necessary.


r~


	* m68k.h (PREFERRED_RELOAD_CLASS): Don't force any FP const_doubles
	to memory.

Index: m68k.h
===================================================================
RCS file: /egcs/carton/cvsfiles/egcs/gcc/config/m68k/m68k.h,v
retrieving revision 1.32
diff -c -p -d -r1.32 m68k.h
*** m68k.h	1999/03/01 15:06:46	1.32
--- m68k.h	1999/06/26 22:32:58
*************** extern enum reg_class regno_reg_class[];
*** 772,794 ****
     in some cases it is preferable to use a more restrictive class.
     On the 68000 series, use a data reg if possible when the
     value is a constant in the range where moveq could be used
!    and we ensure that QImodes are reloaded into data regs.
!    Also, if a floating constant needs reloading, put it in memory.
!    Don't do this for !G constants, since all patterns in the md file
!    expect them to be loaded into a register via fpmovecr.  See above.  */
  
! #define PREFERRED_RELOAD_CLASS(X,CLASS)  \
!   ((GET_CODE (X) == CONST_INT			\
!     && (unsigned) (INTVAL (X) + 0x80) < 0x100	\
!     && (CLASS) != ADDR_REGS)			\
!    ? DATA_REGS					\
!    : (GET_MODE (X) == QImode && (CLASS) != ADDR_REGS) \
!    ? DATA_REGS					\
!    : (GET_CODE (X) == CONST_DOUBLE		\
!       && GET_MODE_CLASS (GET_MODE (X)) == MODE_FLOAT) \
!    ? (! CONST_DOUBLE_OK_FOR_LETTER_P (X, 'G')	\
!       && (CLASS == FP_REGS || CLASS == DATA_OR_FP_REGS) \
!       ? FP_REGS : NO_REGS)			\
     : (CLASS))
  
  /* Force QImode output reloads from subregs to be allocated to data regs,
--- 772,790 ----
     in some cases it is preferable to use a more restrictive class.
     On the 68000 series, use a data reg if possible when the
     value is a constant in the range where moveq could be used
!    and we ensure that QImodes are reloaded into data regs.  */
  
! #define PREFERRED_RELOAD_CLASS(X,CLASS)					\
!   ((GET_CODE (X) == CONST_INT						\
!     && (unsigned) (INTVAL (X) + 0x80) < 0x100				\
!     && (CLASS) != ADDR_REGS)						\
!    ? DATA_REGS								\
!    : (GET_MODE (X) == QImode && (CLASS) != ADDR_REGS)			\
!    ? DATA_REGS								\
!    : (GET_CODE (X) == CONST_DOUBLE					\
!       && GET_MODE_CLASS (GET_MODE (X)) == MODE_FLOAT)			\
!    ? (TARGET_68881 && (CLASS == FP_REGS || CLASS == DATA_OR_FP_REGS)	\
!       ? FP_REGS : NO_REGS)						\
     : (CLASS))
  
  /* Force QImode output reloads from subregs to be allocated to data regs,

Re: gcc-2.95 status

[Marc Espie]

In article < 5777.930270167@upchuck.cygnus.com > you write:

>  In message < 199906241346.PAA01577@quatramaran.ens.fr >you write:
>  > See http://egcs.cygnus.com/ml/egcs-bugs/1999-05/msg00764.html
>  > for an example of how critical it is.
>I've already stated that bug is unlikely to get fixed.

>gcc-2.x has the same bug, you just have been lucky and haven't tripped
>over it.

Sure, some bug that kills utterly simple X windows code on m68k code...
that already existed in gcc 2.8.x, but that I *never* encountered with
2.8.1.

Why don't we declare the m68k dead while we're at it ? scrap mac68k,
exit amiga, no more atari St, and sell hp300 for scrap metal.

Now, bother about some fucked up linux code instead that does stuff it's
not supposed to, which isn't portable at all, and for which there is even
a known technique using union...

Not wanting to start a flamewar, don't bother answering... I just need
to get this out of my system.

Re: m68k-openbsd -fpic fix

[Jeffrey A Law]

  In message < 19990626153434.A28430@cygnus.com >you write:
  > On Thu, Jun 24, 1999 at 06:22:47PM -0600, Jeffrey A Law wrote:
  > >   > See http://egcs.cygnus.com/ml/egcs-bugs/1999-05/msg00764.html
  > >   > for an example of how critical it is.
  > >
  > > I've already stated that bug is unlikely to get fixed.
  > 
  > I had a look at this this morning.  Unless I'm dreadfully mistaken,
  > this is not a difficult bug, but in fact quite simple.
  > 
  > m68k can load arbitrary floating point constants directly.  There's
  > no need to spill them to memory, pic or non-pic.  It would probably
  > make for smaller code if constants that appeared more than once 
  > were spilled to memory earlier, but no effort has been made to do
  > this.  In any case, there's no need to do it during reload.
  > 
  > So a simple tweek to PREFERRED_RELOAD_CLASS seems to be all that's
  > necessary.
  > 
  > 
  > r~
  > 
  > 
  > 	* m68k.h (PREFERRED_RELOAD_CLASS): Don't force any FP const_doubles
  > 	to memory.
I went ahead and installed this (mainline and branch).
jeff

Re: gcc-2.95 status

[Toon Moene]

Jeffrey A Law wrote:

> The critical bugfreeze date was originally scheduled for July 15th.  We
> slipped that 1 week to July 22 to give us more time to address some of the
> problems encountered during testing.

You probably mean "June" here, or you have just invented a time warp :-)

>   Any additional Fortran and C++ testing needs to be hashed out in the very
>   near future.  ie, what package, where can folks get it, how to build and
>   test, etc.

One thing that would be interesting is to test LAPACK - available from:

http://www.netlib.org/lapack/lapack.tgz (note: 4 Mbyte)

- on 64-bit architectures.

It stress-tests the COMPLEX / DOUBLE COMPLEX stuff in the backend (and
the inlined (DOUBLE) COMPLEX division :-)

It passes on i686-pc-linux-gnu with the flags: -g -O3 -funroll-loops
-fomit-frame-pointer.

Some caveats:

1. The code uses MAX(I,J,K) in PARAMETER statements in some places.
   G77 doesn't grok this yet.  Because (lemma follows):

   max(i,j,k) <= i + j + k, for all i, j, k => 0

   you can safely replace the `max' statement with i+j+k.
   [ It only deals with sizes (of arrays), so overestimating is OK ]

2. The build process assumes . is in your PATH (though not necessarily
   in first position).

3. After successful completion, some files ending in .SUMM are left
   in various subdirectories.  Since these files are opened with
   "STATUS='NEW'", they have to be removed before the next trial
   run.

You have to specify the location of the compiler and the linker (both
the g77 you want to test) and the compiler flags, in a `make.inc' file
in the main directory.

So the chain of events is:

1. Get lapack.tgz.

2. tar zxvf lapack.tgz.

3. cd LAPACK

4. vi make.inc

5. (PATH=$PATH:. export PATH; make)

6. g77 finds problematic MAX statements - repair as indicated above.

7. (PATH=$PATH:. export PATH; rm `find . -name '*.SUMM' -print`; \
    make clean; make)

Success !

-- 
Toon Moene (toon@moene.indiv.nluug.nl)
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Phone: +31 346 214290; Fax: +31 346 214286
GNU Fortran: http://world.std.com/~burley/g77.html

Re: m68k-openbsd -fpic fix

[Joe Buck]

[ 68k bug with forcing constants to memory ]

Marc Espie writes:
> Thanks for a great job !    Pity I had to whine to get my fix (there's
> no justice ;-) ), but I'm very, very happy with the result.

Especially for the lesser-used platforms, it seems that bugs often won't
get fixed unless the priority is somehow raised.  Whining by a respected
person is one of the more efficient ways to accomplish this. :-)

Re: gcc-2.95 status

[Jeffrey A Law]

  In message < 199906241346.PAA01577@quatramaran.ens.fr >you write:
  > See http://egcs.cygnus.com/ml/egcs-bugs/1999-05/msg00764.html
  > for an example of how critical it is.
I've already stated that bug is unlikely to get fixed.

gcc-2.x has the same bug, you just have been lucky and haven't tripped
over it.

jeff

Re: m68k-openbsd -fpic fix

[Jeffrey A Law]

  In message < 19990626153434.A28430@cygnus.com >you write:
  > On Thu, Jun 24, 1999 at 06:22:47PM -0600, Jeffrey A Law wrote:
  > >   > See http://egcs.cygnus.com/ml/egcs-bugs/1999-05/msg00764.html
  > >   > for an example of how critical it is.
  > >
  > > I've already stated that bug is unlikely to get fixed.
  > 
  > I had a look at this this morning.  Unless I'm dreadfully mistaken,
  > this is not a difficult bug, but in fact quite simple.
  > 
  > m68k can load arbitrary floating point constants directly.  There's
  > no need to spill them to memory, pic or non-pic. 
  > It would probably
  > make for smaller code if constants that appeared more than once 
  > were spilled to memory earlier, but no effort has been made to do
  > this.  In any case, there's no need to do it during reload.
  > So a simple tweek to PREFERRED_RELOAD_CLASS seems to be all that's
  > necessary.
It the tip of the iceberg, though it probably is worth including to deal with
this instance of one of the more general problems with the m68k PIC code.

The other simple things we can do to greatly improve the m68k PIC support
would be to mark the PIC register as fixed and kill the FINALIZE_PIC
nonsense (those generate wrong code as opposed to compiler aborts).

jeff

Re: gcc-2.95 status

[Robert Lipe]

>   We need libg++ tested on the following platforms:
> 
>    i686-pc-sco3.2v5.0.5 (Robert Lipe)

COFF and the testsuite won't play nicely together (and neither Manfred
nor I could get excited about dumping a lot of time into a discontinued
package to fix this) so this result is only for ELF.   Here is  the tail
of a 'make check-target-libg++'

                === libg++ Summary ===

# of expected passes            72


Is that the test needed?   There were lots of warnings and grousing during
the libg++ build, but it looks like those are expected.

RJL

Re: gcc-2.95 status

[Marc Espie]

In article < 4032.930228776@upchuck.cygnus.com > you write:
>
>
>Just to let folks who do not read the schedule & regression status pages
>know where we stand on the gcc-2.95 release.
>
>The critical bugfreeze date was originally scheduled for July 15th.  We
>slipped that 1 week to July 22 to give us more time to address some of the
>problems encountered during testing.

>Since we are now past the critical bug-freeze date we are only accepting
>patches for critical bugs and all patches have to be run by me before
>they are to be installed on the gcc-2.95 branch.


There's still some highly critical stuff for me. I'd really like m68k
pic to work a little bit more reliably for floating point.

This is a large, critical problem for OpenBSD... we'd rather not put the m68k
platforms in the list of `dead' machines, but we can't really ship releases
with two distinct compilers with different features.

See http://egcs.cygnus.com/ml/egcs-bugs/1999-05/msg00764.html
for an example of how critical it is.

I must stress that if this bug remains in gcc 2.95, there's a chance we will
have to revert our recent changes and ship the next OpenBSD release with
gcc 2.8.1 (as you know, egcs 1.1 is unsuitable for us, since code bloat is
an issue for boot floppies) :(

There's also that netbsd sparc problem I forwarded to the list, with a
potential fix (removing some egcs-1.1.2 code, 
http://egcs.cygnus.com/ml/egcs-bugs/1999-06/msg00238.html )

I'm available for helping checking/elucidating stuff, but I'm nowhere near the
level of analysing and fixing those problems... 
... plus, I still have quite a few linker/assembler related problems to fix,
and a bunch of ports to adapt to g++-2.95...

Re: m68k-openbsd -fpic fix

[Marc Espie]

In article < 16202.930569196@upchuck.cygnus.com > you write:

>  > 	* m68k.h (PREFERRED_RELOAD_CLASS): Don't force any FP const_doubles
>  > 	to memory.
>I went ahead and installed this (mainline and branch).
>jeff

The amiga hasn't finished compiling yet, but it looks like this fixes
*EVERY* pic failure I had so far.

Basically, m68k-openbsd looks in much nicer shape now... I'll probably
have one last bug-report for it (which looks completely unrelated) in
a week (vacation...)

Thanks for a great job !    Pity I had to whine to get my fix (there's
no justice ;-) ), but I'm very, very happy with the result.

gcc-2.95 status

[Jeffrey A Law]

Just to let folks who do not read the schedule & regression status pages
know where we stand on the gcc-2.95 release.

The critical bugfreeze date was originally scheduled for July 15th.  We
slipped that 1 week to July 22 to give us more time to address some of the
problems encountered during testing.

Since we are now past the critical bug-freeze date we are only accepting
patches for critical bugs and all patches have to be run by me before
they are to be installed on the gcc-2.95 branch.

--

We also slipped the proposed release date by one week from July 1 to July 8.

-


Outstanding testing related issues for the release (ie, stuff you can help 
with!)

  Regressions on i686-pc-sco3.2v5.0.5.  Robert Lipe is currently on vacation,
  but returns July 1 I believe.  I'm going to try and simulate some of those
  failures by building a Linux system with dwarf1 debug symbols by default.
  Otherwise we'll have to wait for Robert to return before we can attack these
  problems.

  We need libg++ tested on the following platforms:

   i686-pc-sco3.2v5.0.5 (Robert Lipe)
   i686-pc-linux-gnulibc1


  libgcj/libjava has exposed a compiler bug on mips-sgi-irix6.5 that needs
  to be fixed.  Other build failures have been libgcj portability problems.
  libgjc/libjava build issues will not hold up the release unless they are
  compiler bugs.

  glibc-2.1.1 needs to be built & tested on a sparc-linux machine.  Alexandre
  Oliva is taking care of this.

  linux-2.2.10 needs to be built installed and booted on an alpha, powerpc and
  sparc system.  Note that you should build the kernel "-fno-strict-aliasing".


  The few remaining failures for a redhat-6.0 build on the x86 need to
  be resolved.  If someone wants to do redhat-6.0 builds on one of the other
  processors it supports, please do so and let me know the results.  Note
  several C++ packages need "-fpermissive" to build.

  Any additional Fortran and C++ testing needs to be hashed out in the very
  near future.  ie, what package, where can folks get it, how to build and
  test, etc.


There's still a few non-testing related bugs that need to be fixed.  I'll
be making a pass over my pending bugs directory this weekend to flush the
critical ones out and try to nail them down.


We're in the home stretch.  I'd like to thank everyone that has contributed
fixes, test results, bug analysis, build reports, etc etc.  Believe me, none
of this would be possible without your help.

jeff

Re: gcc-2.95 status

[Jeffrey A Law]

  In message < 19990625094648.A9270@keksy.mchp.siemens.de >you write:
  > I tried that at home last weekend on Linux AXP (Ruffian),
  > but i didn't succeed.  I didn't specify the -fno-strict-aliasing.
  > Is it that important?
It is definitely important.  The linux kernel does things with memory
access that violate the ANSI/ISO aliasing rules.  GCC depends on those
rules to determine when it is safe to reorder certain memory accesses.

jeff

Re: gcc-2.95 status

[Martin Kahlert]

Quoting Jeffrey A Law (law@cygnus.com):

>   linux-2.2.10 needs to be built installed and booted on an alpha, powerpc and
>   sparc system.  Note that you should build the kernel "-fno-strict-aliasing".

I tried that at home last weekend on Linux AXP (Ruffian),
but i didn't succeed.  I didn't specify the -fno-strict-aliasing.
Is it that important?

Thanks for clarification.
Martin.

-- 
esa$ gcc -Wall -o ariane5 ariane5.c
ariane5.c: 666: warning: long float implicitly truncated to unsigned type
esa$ ariane5

Re: m68k-openbsd -fpic fix

[Jeffrey A Law]

  In message < vyzaetj7t7u.fsf@issan.cs.uni-dortmund.de >you write:
  > That would be bad.  Unlike other targets, on the m68k there is actually no
  > fixed PIC register
Most targets do not have a PIC register either.

  > (you can use any other address register instead), and a
  > function that accesses no global data does not need it at all (function
  > calls don't need the PIC register).
True, but the current state of our compiler is if you don't make the PIC
register fixed, then you're going to get incorrect code.  The m68k is no
different.

jeff

Re: gcc-2.95 status

[Jeffrey A Law]

  In message <19990629122643.I1215@rjlhome.sco.com>you write:
  > >   We need libg++ tested on the following platforms:
  > > 
  > >    i686-pc-sco3.2v5.0.5 (Robert Lipe)
  > 
  > COFF and the testsuite won't play nicely together (and neither Manfred
  > nor I could get excited about dumping a lot of time into a discontinued
  > package to fix this) so this result is only for ELF.   Here is  the tail
  > of a 'make check-target-libg++'
Makes perfect sense to me.

  > 
  >                 === libg++ Summary ===
  > 
  > # of expected passes            72
  > 
  > 
  > Is that the test needed?   There were lots of warnings and grousing during
  > the libg++ build, but it looks like those are expected.
Precisely.  Thanks.
jeff

Re: m68k-openbsd -fpic fix

[Andreas Schwab]

Jeffrey A Law <law@cygnus.com> writes:

|>   In message <vyzaetj7t7u.fsf@issan.cs.uni-dortmund.de>you write:
|>   > That would be bad.  Unlike other targets, on the m68k there is actually no
|>   > fixed PIC register
|> Most targets do not have a PIC register either.

Ok, I was thinking about the x86, where %ebx is needed by the PLT.  I
would expect that especially RISC cpus need a dedicated register as well,
unless they use a self-modifying PLT like the sparc.

|>   > (you can use any other address register instead), and a
|>   > function that accesses no global data does not need it at all (function
|>   > calls don't need the PIC register).
|> True, but the current state of our compiler is if you don't make the PIC
|> register fixed, then you're going to get incorrect code.  The m68k is no
|> different.

What I had in mind is that the pic register is allocated like every other
register, except that it needs something special for initialization.
Don't know how that fits in the current concepts, though.

Andreas.

-- 
Andreas Schwab                                  "And now for something
schwab@suse.de                                   completely different."
SuSE GmbH, Schanzaeckerstr. 10

Re: m68k-openbsd -fpic fix

[Jeffrey A Law]

  In message < jeso77z5c1.fsf@hawking.suse.de >you write:
  > Jeffrey A Law <law@cygnus.com> writes:
  > 
  > |>   In message <vyzaetj7t7u.fsf@issan.cs.uni-dortmund.de>you write:
  > |>   > That would be bad.  Unlike other targets, on the m68k there is actua
  > lly no
  > |>   > fixed PIC register
  > |> Most targets do not have a PIC register either.
  > 
  > Ok, I was thinking about the x86, where %ebx is needed by the PLT.  I
  > would expect that especially RISC cpus need a dedicated register as well,
  > unless they use a self-modifying PLT like the sparc.
Most machines use a general purpose register for the PIC register.  We do
dedicate a register to for PIC usage on most/all targets because that is the
only way we can guarantee that the compiler will generate correct code in
certain obscure hard to fix cases.

Maybe we have a misunderstanding about what "having a PIC register" meant.
I only meant that the PIC register is usually just a general purpose register
that is set aside due to software convention, not hardware need to hold
magic values for PIC code generation.



  > What I had in mind is that the pic register is allocated like every other
  > register, except that it needs something special for initialization.
  > Don't know how that fits in the current concepts, though.
That won't work with our current reload pass.  That is the model that a few
ports have tried to take and in each case we had to dedicate one of the
general purpose registers to keep reload from generating incorrect code or
aborting.

jeff

Re: m68k-openbsd -fpic fix

[Joern Rennecke]

>   > What I had in mind is that the pic register is allocated like every other
>   > register, except that it needs something special for initialization.
>   > Don't know how that fits in the current concepts, though.
> That won't work with our current reload pass.  That is the model that a few
> ports have tried to take and in each case we had to dedicate one of the
> general purpose registers to keep reload from generating incorrect code or
> aborting.

We could use a (const (unspec ...)) to initialize the pic register, and
make LEGITIMATE_CONSTANT_P return true for this 'magic' value.

Then reload should be able to handle it just like any old constant.

Re: gcc-2.95 status

[Jeffrey A Law]

  In message <37729A94.6675D1FE@moene.indiv.nluug.nl>you write:
  > One thing that would be interesting is to test LAPACK - available from:
  > 
  > http://www.netlib.org/lapack/lapack.tgz (note: 4 Mbyte)
  > 
  > - on 64-bit architectures.
  > 
  > It stress-tests the COMPLEX / DOUBLE COMPLEX stuff in the backend (and
  > the inlined (DOUBLE) COMPLEX division :-)
  > 
  > It passes on i686-pc-linux-gnu with the flags: -g -O3 -funroll-loops
  > -fomit-frame-pointer.
Good.  I note that you didn't use -fno-f2c as appears in the prototype
linux make.inc.  It didn't seem to make any different for x86-linux, but it
made a world of difference on the HPPA tests.

  > 1. The code uses MAX(I,J,K) in PARAMETER statements in some places.
  >    G77 doesn't grok this yet.  Because (lemma follows):
  > 
  >    max(i,j,k) <= i + j + k, for all i, j, k => 0
  > 
  >    you can safely replace the `max' statement with i+j+k.
  >    [ It only deals with sizes (of arrays), so overestimating is OK ]
?!?  I didn't see anything like this when I built lapack.  There were some
problems with building cblat3 and zblat3.  Both had complaints like this:
blat3.f: In subroutine `zchke':
zblat3.f:1995: 
         ALPHA = ( ONE, -ONE )
                   ^
Real part of complex constant at (^) must be a real or integer constant -- 
otherwise use CMPLX() or COMPLEX() in place of ()


  > 2. The build process assumes . is in your PATH (though not necessarily
  >    in first position).
Thanks.  That saved me some time ;-)


  > 3. After successful completion, some files ending in .SUMM are left
  >    in various subdirectories.  Since these files are opened with
  >    "STATUS='NEW'", they have to be removed before the next trial
  >    run.
Similarly.

lapack ran fine on my x86 -O3 -funroll-loops

The PA failed with -O3 -funroll-loops, but passed with -O2.  I'd bet there's
an unroller bug since I doubt there's a lot of opportunity for inlining in
the lapack code :-)

A ppc-linux box I've got access to is having some problems too.  There's an
abort in the backend that has shown up on a dozen or so files.  We also seem 
to be generating incorrect code somewhere that's causing a bunch of tests to
fail.

jeff

Re: gcc-2.95 status

[Toon Moene]

Jeffrey A Law wrote:
  
>   In message <37729A94.6675D1FE@moene.indiv.nluug.nl>you write:

>   > 1. The code uses MAX(I,J,K) in PARAMETER statements in some places.
>   >    G77 doesn't grok this yet.  Because (lemma follows):
>   >
>   >    max(i,j,k) <= i + j + k, for all i, j, k => 0
>   >
>   >    you can safely replace the `max' statement with i+j+k.
>   >    [ It only deals with sizes (of arrays), so overestimating is OK ]
> ?!?  I didn't see anything like this when I built lapack.  There were some
> problems with building cblat3 and zblat3.  Both had complaints like this:
> blat3.f: In subroutine `zchke':
> zblat3.f:1995:
>          ALPHA = ( ONE, -ONE )
>                    ^
> Real part of complex constant at (^) must be a real or integer constant --
> otherwise use CMPLX() or COMPLEX() in place of ()

Well, you wouldn't believe this, but we are actually talking about two
different versions of LAPACK, in spite of the fact that I sent the
correct URL.  The library was updated on the 30th of June 1999, after
about 4.5 years ...

Obviously, they fixed one non-standard construct and put another one in
its stead ;-)

>   > 2. The build process assumes . is in your PATH (though not necessarily
>   >    in first position).
> Thanks.  That saved me some time ;-)

However, it might be that this isn't necessary with the new version.

>   > 3. After successful completion, some files ending in .SUMM are left
>   >    in various subdirectories.  Since these files are opened with
>   >    "STATUS='NEW'", they have to be removed before the next trial
>   >    run.
> Similarly.

Even this could have been fixed.  I'm sorry, I haven't been able to make
the modem in this laptop function long enough to download 5 Mbytes of
data in one stretch.

> lapack ran fine on my x86 -O3 -funroll-loops
> 
> The PA failed with -O3 -funroll-loops, but passed with -O2.  I'd bet there's
> an unroller bug since I doubt there's a lot of opportunity for inlining in
> the lapack code :-)

Obviously, I haven't read all the code, but the majority seems to be in
the form of "one subroutine per file".

> A ppc-linux box I've got access to is having some problems too.  There's an
> abort in the backend that has shown up on a dozen or so files.  We also seem
> to be generating incorrect code somewhere that's causing a bunch of tests to
> fail.

Yep, it's a pretty severe test - and with a clear license (I mean, we
cannot include it as it is in our testsuite, but we might simply include
a reference in our Web documents where to find it and how to run it).

HTH,

-- 
Toon Moene (toon@moene.indiv.nluug.nl)
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Phone: +31 346 214290; Fax: +31 346 214286
GNU Fortran: http://world.std.com/~burley/g77.html

Re: gcc-2.95 status

[Jeffrey A Law]

  In message < 378A64F0.8DC9B8CF@moene.indiv.nluug.nl >you write:
  > Well, you wouldn't believe this, but we are actually talking about two
  > different versions of LAPACK, in spite of the fact that I sent the
  > correct URL.  The library was updated on the 30th of June 1999, after
  > about 4.5 years ...
Amazing.

  > Obviously, they fixed one non-standard construct and put another one in
  > its stead ;-)
Yup.  Fixing the one I ran into was fairly easy, even for a C guy like myself.


  > >   > 2. The build process assumes . is in your PATH (though not necessaril
  > y
  > >   >    in first position).
  > > Thanks.  That saved me some time ;-)
  > 
  > However, it might be that this isn't necessary with the new version.
It is necessary.  I got bit by this gem, went back and found your message
for the solution.

[ .SUMM files] 
  > Even this could have been fixed.  I'm sorry, I haven't been able to make
  > the modem in this laptop function long enough to download 5 Mbytes of
  > data in one stretch.
Nope.  Got bit by this one too.  Went back to your message for the solution.


  > Obviously, I haven't read all the code, but the majority seems to be in
  > the form of "one subroutine per file".
I can confirm now, it's an unroller problem that is causing the test
failures on the PA. I can (and will) live with that for this release, though
it's worth keeping in mind so that we can fix it :-)

  > Yep, it's a pretty severe test - and with a clear license (I mean, we
  > cannot include it as it is in our testsuite, but we might simply include
  > a reference in our Web documents where to find it and how to run it).
I can confirm the the ppc code gen issue is not an unroller problem.  I get
the same failures with and without the unroller enabled.

Yes, it's a good stress tester.  Good to see the license is clear, even if we
can't include it directly it's free and we can point folks at the canonical
sources with instructions for testing.

Thanks for the help.
jeff

Re: gcc-2.95 status

[David Edelsohn]

>>>>> Jeffrey A Law writes:

>> Yep, it's a pretty severe test - and with a clear license (I mean, we
>> cannot include it as it is in our testsuite, but we might simply include
>> a reference in our Web documents where to find it and how to run it).
Jeff> I can confirm the the ppc code gen issue is not an unroller problem.  I get
Jeff> the same failures with and without the unroller enabled.

Jeff> Yes, it's a good stress tester.  Good to see the license is clear, even if we
Jeff> can't include it directly it's free and we can point folks at the canonical
Jeff> sources with instructions for testing.

	Are you performing the PowerPC tests with -ffloat-store?
Otherwise it will use the FP multiply-add instructions and give excess
precision.  The "iee" C torture tests were failing on the PowerPC port
until that flag was used for those tests.

David

Re: gcc-2.95 status

[Jeffrey A Law]

  In message < 9907122317.AA31616@marc.watson.ibm.com >you write:
  > 	Are you performing the PowerPC tests with -ffloat-store?
  > Otherwise it will use the FP multiply-add instructions and give excess
  > precision.  The "iee" C torture tests were failing on the PowerPC port
  > until that flag was used for those tests.
I hadn't thought of that.  I'll give it a spin tonight.  Thanks for the tip.
jeff

Re: gcc-2.95 status

[Geoff Keating]

David Edelsohn <dje@watson.ibm.com> writes:

> >>>>> Jeffrey A Law writes:
> 
> >> Yep, it's a pretty severe test - and with a clear license (I mean, we
> >> cannot include it as it is in our testsuite, but we might simply include
> >> a reference in our Web documents where to find it and how to run it).
> Jeff> I can confirm the the ppc code gen issue is not an unroller problem.  I get
> Jeff> the same failures with and without the unroller enabled.
> 
> Jeff> Yes, it's a good stress tester.  Good to see the license is clear, even if we
> Jeff> can't include it directly it's free and we can point folks at the canonical
> Jeff> sources with instructions for testing.
> 
> 	Are you performing the PowerPC tests with -ffloat-store?
> Otherwise it will use the FP multiply-add instructions and give excess
> precision.  The "iee" C torture tests were failing on the PowerPC port
> until that flag was used for those tests.

You mean '-mno-fused-madd', don't you?  -ffloat-store will be much worse
for efficiency, and should otherwise have no visible effect over
-mno-fused-madd.

-- 
Geoffrey Keating <geoffk@ozemail.com.au>

Re: gcc-2.95 status

[David Edelsohn]

	Either -ffloat-store or the new -mno-fused-madd should address
this.  The C torture execute/ieee tests use -ffloat-store to be extra
careful.  The original POWER architecture only defined double-precision
floating-point, so one needed to store to memory to restrict the precision
for complete accuracy.  For that case, including AIX common-mode,
-ffloat-store is necessary.

David

Re: gcc-2.95 status

[Jeffrey A Law]

  In message < m3so6tpab4.fsf@geoffk.wattle.id.au >you write:
  > > 	Are you performing the PowerPC tests with -ffloat-store?
  > > Otherwise it will use the FP multiply-add instructions and give excess
  > > precision.  The "iee" C torture tests were failing on the PowerPC port
  > > until that flag was used for those tests.
  > 
  > You mean '-mno-fused-madd', don't you?  -ffloat-store will be much worse
  > for efficiency, and should otherwise have no visible effect over
  > -mno-fused-madd.
To be on the safe side I tried with -ffloat-store -mno-fused-add and its
still barfing.  Time to start up gdb :-)

jeff

Re: gcc-2.95 status

[Jeffrey A Law]

  In message <19990629122643.I1215@rjlhome.sco.com>you write:
  > >   We need libg++ tested on the following platforms:
  > > 
  > >    i686-pc-sco3.2v5.0.5 (Robert Lipe)
  > 
  > COFF and the testsuite won't play nicely together (and neither Manfred
  > nor I could get excited about dumping a lot of time into a discontinued
  > package to fix this) so this result is only for ELF.   Here is  the tail
  > of a 'make check-target-libg++'
Makes perfect sense to me.

  > 
  >                 === libg++ Summary ===
  > 
  > # of expected passes            72
  > 
  > 
  > Is that the test needed?   There were lots of warnings and grousing during
  > the libg++ build, but it looks like those are expected.
Precisely.  Thanks.
jeff

Re: m68k-openbsd -fpic fix

[Joern Rennecke]

>   > What I had in mind is that the pic register is allocated like every other
>   > register, except that it needs something special for initialization.
>   > Don't know how that fits in the current concepts, though.
> That won't work with our current reload pass.  That is the model that a few
> ports have tried to take and in each case we had to dedicate one of the
> general purpose registers to keep reload from generating incorrect code or
> aborting.

We could use a (const (unspec ...)) to initialize the pic register, and
make LEGITIMATE_CONSTANT_P return true for this 'magic' value.

Then reload should be able to handle it just like any old constant.

Re: gcc-2.95 status

[Toon Moene]

Jeffrey A Law wrote:
  
>   In message <37729A94.6675D1FE@moene.indiv.nluug.nl>you write:

>   > 1. The code uses MAX(I,J,K) in PARAMETER statements in some places.
>   >    G77 doesn't grok this yet.  Because (lemma follows):
>   >
>   >    max(i,j,k) <= i + j + k, for all i, j, k => 0
>   >
>   >    you can safely replace the `max' statement with i+j+k.
>   >    [ It only deals with sizes (of arrays), so overestimating is OK ]
> ?!?  I didn't see anything like this when I built lapack.  There were some
> problems with building cblat3 and zblat3.  Both had complaints like this:
> blat3.f: In subroutine `zchke':
> zblat3.f:1995:
>          ALPHA = ( ONE, -ONE )
>                    ^
> Real part of complex constant at (^) must be a real or integer constant --
> otherwise use CMPLX() or COMPLEX() in place of ()

Well, you wouldn't believe this, but we are actually talking about two
different versions of LAPACK, in spite of the fact that I sent the
correct URL.  The library was updated on the 30th of June 1999, after
about 4.5 years ...

Obviously, they fixed one non-standard construct and put another one in
its stead ;-)

>   > 2. The build process assumes . is in your PATH (though not necessarily
>   >    in first position).
> Thanks.  That saved me some time ;-)

However, it might be that this isn't necessary with the new version.

>   > 3. After successful completion, some files ending in .SUMM are left
>   >    in various subdirectories.  Since these files are opened with
>   >    "STATUS='NEW'", they have to be removed before the next trial
>   >    run.
> Similarly.

Even this could have been fixed.  I'm sorry, I haven't been able to make
the modem in this laptop function long enough to download 5 Mbytes of
data in one stretch.

> lapack ran fine on my x86 -O3 -funroll-loops
> 
> The PA failed with -O3 -funroll-loops, but passed with -O2.  I'd bet there's
> an unroller bug since I doubt there's a lot of opportunity for inlining in
> the lapack code :-)

Obviously, I haven't read all the code, but the majority seems to be in
the form of "one subroutine per file".

> A ppc-linux box I've got access to is having some problems too.  There's an
> abort in the backend that has shown up on a dozen or so files.  We also seem
> to be generating incorrect code somewhere that's causing a bunch of tests to
> fail.

Yep, it's a pretty severe test - and with a clear license (I mean, we
cannot include it as it is in our testsuite, but we might simply include
a reference in our Web documents where to find it and how to run it).

HTH,

-- 
Toon Moene (toon@moene.indiv.nluug.nl)
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Phone: +31 346 214290; Fax: +31 346 214286
GNU Fortran: http://world.std.com/~burley/g77.html

Re: m68k-openbsd -fpic fix

[Jeffrey A Law]

  In message < jeso77z5c1.fsf@hawking.suse.de >you write:
  > Jeffrey A Law <law@cygnus.com> writes:
  > 
  > |>   In message <vyzaetj7t7u.fsf@issan.cs.uni-dortmund.de>you write:
  > |>   > That would be bad.  Unlike other targets, on the m68k there is actua
  > lly no
  > |>   > fixed PIC register
  > |> Most targets do not have a PIC register either.
  > 
  > Ok, I was thinking about the x86, where %ebx is needed by the PLT.  I
  > would expect that especially RISC cpus need a dedicated register as well,
  > unless they use a self-modifying PLT like the sparc.
Most machines use a general purpose register for the PIC register.  We do
dedicate a register to for PIC usage on most/all targets because that is the
only way we can guarantee that the compiler will generate correct code in
certain obscure hard to fix cases.

Maybe we have a misunderstanding about what "having a PIC register" meant.
I only meant that the PIC register is usually just a general purpose register
that is set aside due to software convention, not hardware need to hold
magic values for PIC code generation.



  > What I had in mind is that the pic register is allocated like every other
  > register, except that it needs something special for initialization.
  > Don't know how that fits in the current concepts, though.
That won't work with our current reload pass.  That is the model that a few
ports have tried to take and in each case we had to dedicate one of the
general purpose registers to keep reload from generating incorrect code or
aborting.

jeff

Re: gcc-2.95 status

[Jeffrey A Law]

  In message < 9907122317.AA31616@marc.watson.ibm.com >you write:
  > 	Are you performing the PowerPC tests with -ffloat-store?
  > Otherwise it will use the FP multiply-add instructions and give excess
  > precision.  The "iee" C torture tests were failing on the PowerPC port
  > until that flag was used for those tests.
I hadn't thought of that.  I'll give it a spin tonight.  Thanks for the tip.
jeff

Re: gcc-2.95 status

[Geoff Keating]

David Edelsohn <dje@watson.ibm.com> writes:

> >>>>> Jeffrey A Law writes:
> 
> >> Yep, it's a pretty severe test - and with a clear license (I mean, we
> >> cannot include it as it is in our testsuite, but we might simply include
> >> a reference in our Web documents where to find it and how to run it).
> Jeff> I can confirm the the ppc code gen issue is not an unroller problem.  I get
> Jeff> the same failures with and without the unroller enabled.
> 
> Jeff> Yes, it's a good stress tester.  Good to see the license is clear, even if we
> Jeff> can't include it directly it's free and we can point folks at the canonical
> Jeff> sources with instructions for testing.
> 
> 	Are you performing the PowerPC tests with -ffloat-store?
> Otherwise it will use the FP multiply-add instructions and give excess
> precision.  The "iee" C torture tests were failing on the PowerPC port
> until that flag was used for those tests.

You mean '-mno-fused-madd', don't you?  -ffloat-store will be much worse
for efficiency, and should otherwise have no visible effect over
-mno-fused-madd.

-- 
Geoffrey Keating <geoffk@ozemail.com.au>

Re: gcc-2.95 status

[David Edelsohn]

>>>>> Jeffrey A Law writes:

>> Yep, it's a pretty severe test - and with a clear license (I mean, we
>> cannot include it as it is in our testsuite, but we might simply include
>> a reference in our Web documents where to find it and how to run it).
Jeff> I can confirm the the ppc code gen issue is not an unroller problem.  I get
Jeff> the same failures with and without the unroller enabled.

Jeff> Yes, it's a good stress tester.  Good to see the license is clear, even if we
Jeff> can't include it directly it's free and we can point folks at the canonical
Jeff> sources with instructions for testing.

	Are you performing the PowerPC tests with -ffloat-store?
Otherwise it will use the FP multiply-add instructions and give excess
precision.  The "iee" C torture tests were failing on the PowerPC port
until that flag was used for those tests.

David

Re: gcc-2.95 status

[Jeffrey A Law]

  In message <37729A94.6675D1FE@moene.indiv.nluug.nl>you write:
  > One thing that would be interesting is to test LAPACK - available from:
  > 
  > http://www.netlib.org/lapack/lapack.tgz (note: 4 Mbyte)
  > 
  > - on 64-bit architectures.
  > 
  > It stress-tests the COMPLEX / DOUBLE COMPLEX stuff in the backend (and
  > the inlined (DOUBLE) COMPLEX division :-)
  > 
  > It passes on i686-pc-linux-gnu with the flags: -g -O3 -funroll-loops
  > -fomit-frame-pointer.
Good.  I note that you didn't use -fno-f2c as appears in the prototype
linux make.inc.  It didn't seem to make any different for x86-linux, but it
made a world of difference on the HPPA tests.

  > 1. The code uses MAX(I,J,K) in PARAMETER statements in some places.
  >    G77 doesn't grok this yet.  Because (lemma follows):
  > 
  >    max(i,j,k) <= i + j + k, for all i, j, k => 0
  > 
  >    you can safely replace the `max' statement with i+j+k.
  >    [ It only deals with sizes (of arrays), so overestimating is OK ]
?!?  I didn't see anything like this when I built lapack.  There were some
problems with building cblat3 and zblat3.  Both had complaints like this:
blat3.f: In subroutine `zchke':
zblat3.f:1995: 
         ALPHA = ( ONE, -ONE )
                   ^
Real part of complex constant at (^) must be a real or integer constant -- 
otherwise use CMPLX() or COMPLEX() in place of ()


  > 2. The build process assumes . is in your PATH (though not necessarily
  >    in first position).
Thanks.  That saved me some time ;-)


  > 3. After successful completion, some files ending in .SUMM are left
  >    in various subdirectories.  Since these files are opened with
  >    "STATUS='NEW'", they have to be removed before the next trial
  >    run.
Similarly.

lapack ran fine on my x86 -O3 -funroll-loops

The PA failed with -O3 -funroll-loops, but passed with -O2.  I'd bet there's
an unroller bug since I doubt there's a lot of opportunity for inlining in
the lapack code :-)

A ppc-linux box I've got access to is having some problems too.  There's an
abort in the backend that has shown up on a dozen or so files.  We also seem 
to be generating incorrect code somewhere that's causing a bunch of tests to
fail.

jeff

Re: gcc-2.95 status

[Jeffrey A Law]

  In message < 378A64F0.8DC9B8CF@moene.indiv.nluug.nl >you write:
  > Well, you wouldn't believe this, but we are actually talking about two
  > different versions of LAPACK, in spite of the fact that I sent the
  > correct URL.  The library was updated on the 30th of June 1999, after
  > about 4.5 years ...
Amazing.

  > Obviously, they fixed one non-standard construct and put another one in
  > its stead ;-)
Yup.  Fixing the one I ran into was fairly easy, even for a C guy like myself.


  > >   > 2. The build process assumes . is in your PATH (though not necessaril
  > y
  > >   >    in first position).
  > > Thanks.  That saved me some time ;-)
  > 
  > However, it might be that this isn't necessary with the new version.
It is necessary.  I got bit by this gem, went back and found your message
for the solution.

[ .SUMM files] 
  > Even this could have been fixed.  I'm sorry, I haven't been able to make
  > the modem in this laptop function long enough to download 5 Mbytes of
  > data in one stretch.
Nope.  Got bit by this one too.  Went back to your message for the solution.


  > Obviously, I haven't read all the code, but the majority seems to be in
  > the form of "one subroutine per file".
I can confirm now, it's an unroller problem that is causing the test
failures on the PA. I can (and will) live with that for this release, though
it's worth keeping in mind so that we can fix it :-)

  > Yep, it's a pretty severe test - and with a clear license (I mean, we
  > cannot include it as it is in our testsuite, but we might simply include
  > a reference in our Web documents where to find it and how to run it).
I can confirm the the ppc code gen issue is not an unroller problem.  I get
the same failures with and without the unroller enabled.

Yes, it's a good stress tester.  Good to see the license is clear, even if we
can't include it directly it's free and we can point folks at the canonical
sources with instructions for testing.

Thanks for the help.
jeff

Re: m68k-openbsd -fpic fix

[Andreas Schwab]

Jeffrey A Law <law@cygnus.com> writes:

|>   In message <vyzaetj7t7u.fsf@issan.cs.uni-dortmund.de>you write:
|>   > That would be bad.  Unlike other targets, on the m68k there is actually no
|>   > fixed PIC register
|> Most targets do not have a PIC register either.

Ok, I was thinking about the x86, where %ebx is needed by the PLT.  I
would expect that especially RISC cpus need a dedicated register as well,
unless they use a self-modifying PLT like the sparc.

|>   > (you can use any other address register instead), and a
|>   > function that accesses no global data does not need it at all (function
|>   > calls don't need the PIC register).
|> True, but the current state of our compiler is if you don't make the PIC
|> register fixed, then you're going to get incorrect code.  The m68k is no
|> different.

What I had in mind is that the pic register is allocated like every other
register, except that it needs something special for initialization.
Don't know how that fits in the current concepts, though.

Andreas.

-- 
Andreas Schwab                                  "And now for something
schwab@suse.de                                   completely different."
SuSE GmbH, Schanzaeckerstr. 10

Re: gcc-2.95 status

[David Edelsohn]

	Either -ffloat-store or the new -mno-fused-madd should address
this.  The C torture execute/ieee tests use -ffloat-store to be extra
careful.  The original POWER architecture only defined double-precision
floating-point, so one needed to store to memory to restrict the precision
for complete accuracy.  For that case, including AIX common-mode,
-ffloat-store is necessary.

David

Re: gcc-2.95 status

[Jeffrey A Law]

  In message < m3so6tpab4.fsf@geoffk.wattle.id.au >you write:
  > > 	Are you performing the PowerPC tests with -ffloat-store?
  > > Otherwise it will use the FP multiply-add instructions and give excess
  > > precision.  The "iee" C torture tests were failing on the PowerPC port
  > > until that flag was used for those tests.
  > 
  > You mean '-mno-fused-madd', don't you?  -ffloat-store will be much worse
  > for efficiency, and should otherwise have no visible effect over
  > -mno-fused-madd.
To be on the safe side I tried with -ffloat-store -mno-fused-add and its
still barfing.  Time to start up gdb :-)

jeff

gcc-2.95 status

[Jeffrey A Law]

I will be making another snapshot tomorrow morning.  I am not planning
any additional changes for gcc-2.95 except for documentation updates once
that snapshot is made.

jeff

Re: gcc-2.95 status

[Richard Henderson]

On Mon, Jul 12, 1999 at 03:17:50AM -0600, Jeffrey A Law wrote:
>   5. alpha (ev56?) glibc problem reported by rth.  I'm guessing this is ev56
>      specific since I did a glibc testrun a short time ago on an ev6.

I could not reproduce this today with any of ev4, ev56 or ev6.
The compiler that had built the failing library turned out to
be a late june snapshot.

So I guess this one's fixed...


r~

Re: gcc-2.95 status

[Gerald Pfeifer]

On Mon, 12 Jul 1999, Jeffrey A Law wrote:
> Other issues that need to be resolved before we can make the release:
> 
>   a. Mail list reorganization.
>   b. Documentation review and updates
>   c. Release announcement, new features pages and the like
>   d. Minor updates to release script to deal with various changes we've
>      made since the last release.

Is there anything I could/should do for the web pages?

Currently I'm working on unifying and GCCifying htdocs/install for
the release.

> I'm starting a snapshot right now, then going to bed.  I will spin
> another one as soon as #1-#5 are resolved., then another once a, b & d
> are resolved.

What do you think about handling d before spinning the next snapshot, so
we have two (instead of one) pre-release with the new scripts in case we
need to make further adjustments?

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

gcc-2.95 status

[Jeffrey A Law]

Just a quick update on where we stand.

Technical issues with the compiler itself that need to be resolved:

  1. alpha ev56 mis-compilation of lapack code
  2. ppc-linux port is aborting regularly on lapack code and also appears
     to be generating incorrect code for many lapack tests
  3. Resolution of -femulate-complex vs -fno-emulate-complex
  4. x86 mis-compilation of texinfo (we may not get to this one for gcc-2.95)
  5. alpha (ev56?) glibc problem reported by rth.  I'm guessing this is ev56
     specific since I did a glibc testrun a short time ago on an ev6.


That's it.  I'm sorry if your favorite issue is not on that list.  We could
stay in the "one more bugfix" mode forever, but in the end that does not
help the project.  This release has been delayed enough already and needs to
go out the door.

We will have a gcc-2.95.1 release to fix critical bugs found in gcc-2.95.


Other issues that need to be resolved before we can make the release:

  a. Mail list reorganization.
  b. Documentation review and updates
  c. Release announcement, new features pages and the like
  d. Minor updates to release script to deal with various changes we've
     made since the last release.


I'm starting a snapshot right now, then going to bed.  I will spin another
one as soon as #1-#5 are resolved., then another once a, b & d are resolved.

jeff

gcc-2.95 status

[Jeffrey A Law]

I will be making another snapshot tomorrow morning.  I am not planning
any additional changes for gcc-2.95 except for documentation updates once
that snapshot is made.

jeff

Re: gcc-2.95 status

[Gerald Pfeifer]

On Mon, 12 Jul 1999, Jeffrey A Law wrote:
> Other issues that need to be resolved before we can make the release:
> 
>   a. Mail list reorganization.
>   b. Documentation review and updates
>   c. Release announcement, new features pages and the like
>   d. Minor updates to release script to deal with various changes we've
>      made since the last release.

Is there anything I could/should do for the web pages?

Currently I'm working on unifying and GCCifying htdocs/install for
the release.

> I'm starting a snapshot right now, then going to bed.  I will spin
> another one as soon as #1-#5 are resolved., then another once a, b & d
> are resolved.

What do you think about handling d before spinning the next snapshot, so
we have two (instead of one) pre-release with the new scripts in case we
need to make further adjustments?

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: gcc-2.95 status

[Richard Henderson]

On Mon, Jul 12, 1999 at 03:17:50AM -0600, Jeffrey A Law wrote:
>   5. alpha (ev56?) glibc problem reported by rth.  I'm guessing this is ev56
>      specific since I did a glibc testrun a short time ago on an ev6.

I could not reproduce this today with any of ev4, ev56 or ev6.
The compiler that had built the failing library turned out to
be a late june snapshot.

So I guess this one's fixed...


r~

gcc-2.95 status

[Jeffrey A Law]

Just a quick update on where we stand.

Technical issues with the compiler itself that need to be resolved:

  1. alpha ev56 mis-compilation of lapack code
  2. ppc-linux port is aborting regularly on lapack code and also appears
     to be generating incorrect code for many lapack tests
  3. Resolution of -femulate-complex vs -fno-emulate-complex
  4. x86 mis-compilation of texinfo (we may not get to this one for gcc-2.95)
  5. alpha (ev56?) glibc problem reported by rth.  I'm guessing this is ev56
     specific since I did a glibc testrun a short time ago on an ev6.


That's it.  I'm sorry if your favorite issue is not on that list.  We could
stay in the "one more bugfix" mode forever, but in the end that does not
help the project.  This release has been delayed enough already and needs to
go out the door.

We will have a gcc-2.95.1 release to fix critical bugs found in gcc-2.95.


Other issues that need to be resolved before we can make the release:

  a. Mail list reorganization.
  b. Documentation review and updates
  c. Release announcement, new features pages and the like
  d. Minor updates to release script to deal with various changes we've
     made since the last release.


I'm starting a snapshot right now, then going to bed.  I will spin another
one as soon as #1-#5 are resolved., then another once a, b & d are resolved.

jeff

RE: gcc-2.95 status

[Billinghurst, David (RTD)]

LAPACK passes on mips-sgi-irix6.5 with egcs-19990616 - egcs-19990623 running
now.

My other test package - octave-2.0.14 - still fails using egcs-19990616 with
an ICE, which is a regression from egcs-1.1.2
See http://egcs.cygnus.com/ml/egcs-bugs/1999-05/msg00736.html

+++++++++++++++++++++++++++++++++++++++++
(Mr) David Billinghurst
Comalco Research Centre
PO Box 316, Thomastown, Vic, Australia, 3074
Phone:	+61 3 9469 0642
FAX:	+61 3 9462 2700
Email:	David.Billinghurst@riotinto.com.au



> -----Original Message-----
> From:	Toon Moene [SMTP:toon@moene.indiv.nluug.nl]
> Sent:	Friday, 25 June 1999 6:53
> To:	law@cygnus.com
> Cc:	egcs@egcs.cygnus.com
> Subject:	Re: gcc-2.95 status
> 
> Jeffrey A Law wrote:
> 
> > The critical bugfreeze date was originally scheduled for July 15th.  We
> > slipped that 1 week to July 22 to give us more time to address some of
> the
> > problems encountered during testing.
> 
> You probably mean "June" here, or you have just invented a time warp :-)
> 
> >   Any additional Fortran and C++ testing needs to be hashed out in the
> very
> >   near future.  ie, what package, where can folks get it, how to build
> and
> >   test, etc.
> 
> One thing that would be interesting is to test LAPACK - available from:
> 
> http://www.netlib.org/lapack/lapack.tgz (note: 4 Mbyte)
> 
> - on 64-bit architectures.
> 
> 

RE: gcc-2.95 status

[Billinghurst, David (RTD)]

LAPACK passes on mips-sgi-irix6.5 with egcs-19990616 - egcs-19990623 running
now.

My other test package - octave-2.0.14 - still fails using egcs-19990616 with
an ICE, which is a regression from egcs-1.1.2
See http://egcs.cygnus.com/ml/egcs-bugs/1999-05/msg00736.html

+++++++++++++++++++++++++++++++++++++++++
(Mr) David Billinghurst
Comalco Research Centre
PO Box 316, Thomastown, Vic, Australia, 3074
Phone:	+61 3 9469 0642
FAX:	+61 3 9462 2700
Email:	David.Billinghurst@riotinto.com.au



> -----Original Message-----
> From:	Toon Moene [SMTP:toon@moene.indiv.nluug.nl]
> Sent:	Friday, 25 June 1999 6:53
> To:	law@cygnus.com
> Cc:	egcs@egcs.cygnus.com
> Subject:	Re: gcc-2.95 status
> 
> Jeffrey A Law wrote:
> 
> > The critical bugfreeze date was originally scheduled for July 15th.  We
> > slipped that 1 week to July 22 to give us more time to address some of
> the
> > problems encountered during testing.
> 
> You probably mean "June" here, or you have just invented a time warp :-)
> 
> >   Any additional Fortran and C++ testing needs to be hashed out in the
> very
> >   near future.  ie, what package, where can folks get it, how to build
> and
> >   test, etc.
> 
> One thing that would be interesting is to test LAPACK - available from:
> 
> http://www.netlib.org/lapack/lapack.tgz (note: 4 Mbyte)
> 
> - on 64-bit architectures.
> 
>