Optimization Bug in g77

Optimization Bug in g77

[Steven E. Williamson]

I have run into a strange problem with g77 when run with the -O or -O1
option but NOT with -O2, -O3, or no optimization.  Below is piece
of Fortran code (removed from a larger program) which illustrates the
problem.  The basic function of the code is to go through a list
of data (the RAW array) and accumulate an average and uncertainty
in the average, excluding "outlier points".  This is done iteratively
by calculating an average and standard deviation using only points
that differ by less than some number (NSIG) of standard deviations
from the average calculated by the previous iteration (in the first
iteration all points are accumulated).  The iteration is repeted until
the average does not change between two iterations or until some
maximum number of iterations is reached.  In the program below, some
fake data is first generated.  For technical reasons, the number of
"rejected points" and the number of iterations (normally integers) are
accumulated in double precision reals.

The problem with this code is that when compiled with either the -O or -O1
options, the maximum number of iterations is performed.  When compiled
with -O2, -O3, or no optimization options, only 2 iterations are done.
Some how the check for the averages of two successive iterations is
being disabled when -O or -O1 is selected.

Two other symptoms that I have noticed: if the -ffloat-store option is
used, then the program always works correctly (does only 2 iterations).
And, if the write statement immediately preceding the check for
equal averages is un-commented, the program also works correctly.

-----------Program optimization-test.F CUT HERE--------------------------
C	This program produces two different results depending on
C	the g77 optimization.
	IMPLICIT NONE
C	Maximum number of iterations of the filtering process
	INTEGER NITRMX
	PARAMETER (NITRMX = 50)
C	Number of SIGMA outside of which data is rejected.
	INTEGER NSIG
	PARAMETER (NSIG = 40)
C	Number of data points
	INTEGER NDAT
	PARAMETER (NDAT = 200)
C
	INTEGER I
	REAL RAW(200)
	DOUBLE PRECISION AV,SD,AVOLD,SDOLD,FIL(2),SUM,SUM2
C
	FIL(2) = 1.D0
	SDOLD = 1.D37
	AVOLD = 0.D0
C	Generate some fake data (Gaussian tail with flat-top)
	DO 100 I = 1,NDAT
	    RAW(I) = EXP(-((I-100.)/10.)**2)
100	CONTINUE
	DO 110 I = NDAT/2-20,NDAT/2+20
	    RAW(I) = 1
110	CONTINUE
C
C	Scan data to calculate mean and uncertainty.  Reject
C	any data that is NSIG SIGMA from the mean (unless this
C	is the first iteration).
10	SUM = 0.D0
	SUM2 = 0.D0
	FIL(1) = 0.D0
	DO 70 I = 1,NDAT
	    IF (FIL(2).LE.1.D0.OR.ABS(RAW(I)-AVOLD).LE.NSIG*SDOLD) THEN
	        SUM = SUM+RAW(I)
	        SUM2 = SUM2+RAW(I)**2
	    ELSE
	        FIL(1) = FIL(1)+1.D0
	    ENDIF
70	CONTINUE
C	Calculate a new mean and SIGMA.
	AV = SUM/(NDAT-FIL(1))
C	This is the standard deviation of the mean (which is not the
C	same as the standard deviation of the measurement distribution,
C	i.e. the sample standard deviation.).
	SD = SQRT(SUM2/(NDAT-FIL(1))-AV**2)/SQRT(NDAT-1-FIL(1))
c	write (6,*) av
	IF (FIL(2).LE.1.D0.OR.AV.NE.AVOLD) THEN
	    IF (FIL(2).LT.NITRMX) THEN
C	        If this is the first iteration, or if the process
C	        hasn't converged, go back and re-scan.
	        FIL(2) = FIL(2)+1.D0
	        AVOLD = AV
	        SDOLD = SD
	        GO TO 10
	    ENDIF
	ENDIF
	write (6,*) fil(2),av,fil(1)
	if (fil(2).eq.nitrmx) then
	    write (6,*) 'Wrong answer!'
	else
	    write (6,*) 'Right answer.'
	endif
	STOP 'All done.'
	END
------------------------------------------------------------------------

Here is the Makefile that I use to genererate the executable of the
above program.  It assumes that the above Fortran is in a file
called optimization-test.F.  A number of different choices for
the FFLAGS (most commented out) are divided into a group that doesn't
work and a group that works.

-----------------------Makefile CUT HERE--------------------------------
# This is a make file for optimization-test.  The following commands are
# defined:
# make			Create program on source directory (don't install
#                       in destination)
# make all			"
# make program			"
# make clean		Remove object files from the source directory
# make install		Move the program from the source directory to the
#                       destination
# make update		Combines program creation with installation in
#                       destination directory

# Final result of this make file
PROGRAM=optimization-test

OBJS=optimization-test.o

# Source file names (syntax is the same as SRCS=$(patsubst %.o,%.F,$(OBJS)))
SRCS=$(OBJS:%.o=%.F)

# Place to store the final result (no last /)
DEST=$(HOME)/bin/$(OSNAME)

# Name of this file
MAKEFILE=Makefile

# Library directories 
LIBDIR=

# Libraries to link to (other operating system specific libraries are defined
# by OSLIBS).
LIBS=

# Fortran command
FC=g77

# Fortran (g77) flags for Linux
# -fcase-lower		Map to lower case (case insensitive)
#			(note that most libraries are compiled
#			with lower case symbols).
# -O			Optimize the code -- same as O1 (could be O2 for even
#			beter optimization, or O3 for the best optimization)
# -Wall			Warn when variables are unused (except
#			for declaration) and when uninitialized
# 			variables are used. 
# The following options produce a program that does NOT work
# FFLAGS=-W -Wall -fcase-lower -O
# FFLAGS=-W -Wall -fcase-lower -O1
#
# The following options produce a program that works:
# FFLAGS=-W -Wall -fcase-lower -O2
# FFLAGS=-W -Wall -fcase-lower -O3
# FFLAGS=-W -Wall -fcase-lower -ffloat-store -O1
# FFLAGS=-W -Wall -fcase-lower -ffloat-store -O
# FFLAGS=-W -Wall -fcase-lower -ffloat-store
# FFLAGS=-W -Wall -fcase-lower -ffloat-store -O2
# FFLAGS=-W -Wall -fcase-lower -ffloat-store -O3
FFLAGS=-W -Wall -fcase-lower

# Loader options for Linux
# -L <directory>        Look in <directory> for libraries
LDFLAGS=

# Libraries required on this operating system
OSLIBS=

# "make all" and "make program" are the same as "make"
all:		$(PROGRAM)
program:        $(PROGRAM)
$(PROGRAM):     $(OBJS)
		$(FC) $(LDFLAGS) $(OBJS) $(LIBS) $(OSLIBS) -o $(PROGRAM)

# "make install" transfers the program to the destination directory
install:	$(PROGRAM)
		mv $(PROGRAM) $(DEST)

# "make update" combines the creation of the program with its installation.
update:		$(DEST)/$(PROGRAM)
$(DEST)/$(PROGRAM): $(SRCS)
		@make -f $(MAKEFILE) DEST=$(DEST) install

# "make clean" removes all old object files.  This uses a "phony target"
# (ie target without dependencies)
.PHONY:		clean
clean:
		rm -f $(OBJS)

Here is the result of doing g77 -v on my system:


------------------------------------------------------------------------
>g77 -v
g77 version 2.95.4 20011002 (Debian prerelease) (from FSF-g77 version
0.5.25 20010319 (prerelease))
Driving: g77 -v -c -xf77-version /dev/null -xnone
Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.4/specs
gcc version 2.95.4 20011002 (Debian prerelease)
 /usr/lib/gcc-lib/i386-linux/2.95.4/cpp0 -lang-c -v -D__GNUC__=2
-D__GNUC_MINOR__=95 -D__ELF__ -D__unix__ -D__i386__ -D__linux__ -D__unix
-D__linux -Asystem(posix) -D_LANGUAGE_FORTRAN -traditional
-Acpu(i386) -Amachine(i386) -Di386 -D__i386 -D__i386__ /dev/null /dev/null
GNU CPP version 2.95.4 20011002 (Debian prerelease) (i386 Linux/ELF)
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include
 /usr/lib/gcc-lib/i386-linux/2.95.4/include
 /usr/include
End of search list.
The following default directories have been omitted from the search path:
 /usr/lib/gcc-lib/i386-linux/2.95.4/../../../../include/g++-3
 /usr/lib/gcc-lib/i386-linux/2.95.4/../../../../i386-linux/include
End of omitted list.
 /usr/lib/gcc-lib/i386-linux/2.95.4/f771 -fnull-version -quiet -dumpbase
g77-version.f -version -fversion -o /tmp/ccCss7xb.s /dev/null
GNU F77 version 2.95.4 20011002 (Debian prerelease) (i386-linux) compiled
by GNU C version 2.95.4 20011002 (Debian prerelease).
GNU Fortran Front End version 0.5.25 20010319 (prerelease)
 as -V -Qy -o /tmp/ccOS8gud.o /tmp/ccCss7xb.s
GNU assembler version 2.12.90.0.1 (i386-linux) using BFD version
2.12.90.0.1 20020307 Debian/GNU Linux
 ld -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -o /tmp/cc8iVYBd
/tmp/ccOS8gud.o /usr/lib/crt1.o /usr/lib/crti.o
/usr/lib/gcc-lib/i386-linux/2.95.4/crtbegin.o
-L/usr/lib/gcc-lib/i386-linux/2.95.4 -lg2c -lm -lgcc -lc -lgcc
/usr/lib/gcc-lib/i386-linux/2.95.4/crtend.o /usr/lib/crtn.o
 /tmp/cc8iVYBd
__G77_LIBF77_VERSION__: 0.5.25 20010319 (prerelease)
@(#)LIBF77 VERSION 19990503
__G77_LIBI77_VERSION__: 0.5.25 20010319 (prerelease)
@(#) LIBI77 VERSION pjw,dmg-mods 19990503
__G77_LIBU77_VERSION__: 0.5.25 20010319 (prerelease)
@(#) LIBU77 VERSION 19980709
-----------------------------------------------------------------------

Obvously I have a work-around to make my code do what I want it to do,
but this makes me worry that there are other programs, compiled with
-O, that are not really doing what they are supposed to do.

Thank you for any help (patches, suggestions, etc.).  Let me know if I can
supply more information.

				Steve Williamson
				Physics Dept.
				University of Illinois

Re: Optimization Bug in g77

[Andrew Pinski]

On Oct 26, 2004, at 3:01 PM, Steven E. Williamson wrote:

> Two other symptoms that I have noticed: if the -ffloat-store option is
> used, then the program always works correctly (does only 2 iterations).
> And, if the write statement immediately preceding the check for
> equal averages is un-commented, the program also works correctly.

There you said how to fix your problem -ffloat-store.  The point is that
gcc (and g77) is using the additional precision which you are not 
expecting
to be used.  I am going to assume you are on x86 where this problem 
comes
up all the time.

Thanks,
Andrew Pinski

Re: Optimization Bug in g77

[Steven E. Williamson]

Thanks for the quick response.  I have altered my code so that it
does not depend on the way extended precision is handled.  It
gives the right answer no mater how it is compiled.

I guess the moral is: don't try to check for exact equality between two
double precision numbers that have been calculated because one
may be in memory and the other may be stored with extra precision
in registers (in which case they will never come out equal).  Is
that a fair way to understand the behavior of g77/gcc/the CPU/the FPU?

				Steve

On Tue, 26 Oct 2004, Andrew Pinski wrote:

> 
> On Oct 26, 2004, at 3:01 PM, Steven E. Williamson wrote:
> 
> > Two other symptoms that I have noticed: if the -ffloat-store option is
> > used, then the program always works correctly (does only 2 iterations).
> > And, if the write statement immediately preceding the check for
> > equal averages is un-commented, the program also works correctly.
> 
> There you said how to fix your problem -ffloat-store.  The point is that
> gcc (and g77) is using the additional precision which you are not 
> expecting
> to be used.  I am going to assume you are on x86 where this problem 
> comes
> up all the time.
> 
> Thanks,
> Andrew Pinski
> 

Optimization Bug in g77

[Steven E. Williamson]

I have run into a strange problem with g77 when run with the -O or -O1
option but NOT with -O2, -O3, or no optimization.  Below is piece
of Fortran code (removed from a larger program) which illustrates the
problem.  The basic function of the code is to go through a list
of data (the RAW array) and accumulate an average and uncertainty
in the average, excluding "outlier points".  This is done iteratively
by calculating an average and standard deviation using only points
that differ by less than some number (NSIG) of standard deviations
from the average calculated by the previous iteration (in the first
iteration all points are accumulated).  The iteration is repeted until
the average does not change between two iterations or until some
maximum number of iterations is reached.  In the program below, some
fake data is first generated.  For technical reasons, the number of
"rejected points" and the number of iterations (normally integers) are
accumulated in double precision reals.

The problem with this code is that when compiled with either the -O or -O1
options, the maximum number of iterations is performed.  When compiled
with -O2, -O3, or no optimization options, only 2 iterations are done.
Some how the check for the averages of two successive iterations is
being disabled when -O or -O1 is selected.

Two other symptoms that I have noticed: if the -ffloat-store option is
used, then the program always works correctly (does only 2 iterations).
And, if the write statement immediately preceding the check for
equal averages is un-commented, the program also works correctly.

-----------Program optimization-test.F CUT HERE--------------------------
C	This program produces two different results depending on
C	the g77 optimization.
	IMPLICIT NONE
C	Maximum number of iterations of the filtering process
	INTEGER NITRMX
	PARAMETER (NITRMX = 50)
C	Number of SIGMA outside of which data is rejected.
	INTEGER NSIG
	PARAMETER (NSIG = 40)
C	Number of data points
	INTEGER NDAT
	PARAMETER (NDAT = 200)
C
	INTEGER I
	REAL RAW(200)
	DOUBLE PRECISION AV,SD,AVOLD,SDOLD,FIL(2),SUM,SUM2
C
	FIL(2) = 1.D0
	SDOLD = 1.D37
	AVOLD = 0.D0
C	Generate some fake data (Gaussian tail with flat-top)
	DO 100 I = 1,NDAT
	    RAW(I) = EXP(-((I-100.)/10.)**2)
100	CONTINUE
	DO 110 I = NDAT/2-20,NDAT/2+20
	    RAW(I) = 1
110	CONTINUE
C
C	Scan data to calculate mean and uncertainty.  Reject
C	any data that is NSIG SIGMA from the mean (unless this
C	is the first iteration).
10	SUM = 0.D0
	SUM2 = 0.D0
	FIL(1) = 0.D0
	DO 70 I = 1,NDAT
	    IF (FIL(2).LE.1.D0.OR.ABS(RAW(I)-AVOLD).LE.NSIG*SDOLD) THEN
	        SUM = SUM+RAW(I)
	        SUM2 = SUM2+RAW(I)**2
	    ELSE
	        FIL(1) = FIL(1)+1.D0
	    ENDIF
70	CONTINUE
C	Calculate a new mean and SIGMA.
	AV = SUM/(NDAT-FIL(1))
C	This is the standard deviation of the mean (which is not the
C	same as the standard deviation of the measurement distribution,
C	i.e. the sample standard deviation.).
	SD = SQRT(SUM2/(NDAT-FIL(1))-AV**2)/SQRT(NDAT-1-FIL(1))
c	write (6,*) av
	IF (FIL(2).LE.1.D0.OR.AV.NE.AVOLD) THEN
	    IF (FIL(2).LT.NITRMX) THEN
C	        If this is the first iteration, or if the process
C	        hasn't converged, go back and re-scan.
	        FIL(2) = FIL(2)+1.D0
	        AVOLD = AV
	        SDOLD = SD
	        GO TO 10
	    ENDIF
	ENDIF
	write (6,*) fil(2),av,fil(1)
	if (fil(2).eq.nitrmx) then
	    write (6,*) 'Wrong answer!'
	else
	    write (6,*) 'Right answer.'
	endif
	STOP 'All done.'
	END
------------------------------------------------------------------------

Here is the Makefile that I use to genererate the executable of the
above program.  It assumes that the above Fortran is in a file
called optimization-test.F.  A number of different choices for
the FFLAGS (most commented out) are divided into a group that doesn't
work and a group that works.

-----------------------Makefile CUT HERE--------------------------------
# This is a make file for optimization-test.  The following commands are
# defined:
# make			Create program on source directory (don't install
#                       in destination)
# make all			"
# make program			"
# make clean		Remove object files from the source directory
# make install		Move the program from the source directory to the
#                       destination
# make update		Combines program creation with installation in
#                       destination directory

# Final result of this make file
PROGRAM=optimization-test

OBJS=optimization-test.o

# Source file names (syntax is the same as SRCS=$(patsubst %.o,%.F,$(OBJS)))
SRCS=$(OBJS:%.o=%.F)

# Place to store the final result (no last /)
DEST=$(HOME)/bin/$(OSNAME)

# Name of this file
MAKEFILE=Makefile

# Library directories 
LIBDIR=

# Libraries to link to (other operating system specific libraries are defined
# by OSLIBS).
LIBS=

# Fortran command
FC=g77

# Fortran (g77) flags for Linux
# -fcase-lower		Map to lower case (case insensitive)
#			(note that most libraries are compiled
#			with lower case symbols).
# -O			Optimize the code -- same as O1 (could be O2 for even
#			beter optimization, or O3 for the best optimization)
# -Wall			Warn when variables are unused (except
#			for declaration) and when uninitialized
# 			variables are used. 
# The following options produce a program that does NOT work
# FFLAGS=-W -Wall -fcase-lower -O
# FFLAGS=-W -Wall -fcase-lower -O1
#
# The following options produce a program that works:
# FFLAGS=-W -Wall -fcase-lower -O2
# FFLAGS=-W -Wall -fcase-lower -O3
# FFLAGS=-W -Wall -fcase-lower -ffloat-store -O1
# FFLAGS=-W -Wall -fcase-lower -ffloat-store -O
# FFLAGS=-W -Wall -fcase-lower -ffloat-store
# FFLAGS=-W -Wall -fcase-lower -ffloat-store -O2
# FFLAGS=-W -Wall -fcase-lower -ffloat-store -O3
FFLAGS=-W -Wall -fcase-lower

# Loader options for Linux
# -L <directory>        Look in <directory> for libraries
LDFLAGS=

# Libraries required on this operating system
OSLIBS=

# "make all" and "make program" are the same as "make"
all:		$(PROGRAM)
program:        $(PROGRAM)
$(PROGRAM):     $(OBJS)
		$(FC) $(LDFLAGS) $(OBJS) $(LIBS) $(OSLIBS) -o $(PROGRAM)

# "make install" transfers the program to the destination directory
install:	$(PROGRAM)
		mv $(PROGRAM) $(DEST)

# "make update" combines the creation of the program with its installation.
update:		$(DEST)/$(PROGRAM)
$(DEST)/$(PROGRAM): $(SRCS)
		@make -f $(MAKEFILE) DEST=$(DEST) install

# "make clean" removes all old object files.  This uses a "phony target"
# (ie target without dependencies)
.PHONY:		clean
clean:
		rm -f $(OBJS)

Here is the result of doing g77 -v on my system:


------------------------------------------------------------------------
>g77 -v
g77 version 2.95.4 20011002 (Debian prerelease) (from FSF-g77 version
0.5.25 20010319 (prerelease))
Driving: g77 -v -c -xf77-version /dev/null -xnone
Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.4/specs
gcc version 2.95.4 20011002 (Debian prerelease)
 /usr/lib/gcc-lib/i386-linux/2.95.4/cpp0 -lang-c -v -D__GNUC__=2
-D__GNUC_MINOR__=95 -D__ELF__ -D__unix__ -D__i386__ -D__linux__ -D__unix
-D__linux -Asystem(posix) -D_LANGUAGE_FORTRAN -traditional
-Acpu(i386) -Amachine(i386) -Di386 -D__i386 -D__i386__ /dev/null /dev/null
GNU CPP version 2.95.4 20011002 (Debian prerelease) (i386 Linux/ELF)
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include
 /usr/lib/gcc-lib/i386-linux/2.95.4/include
 /usr/include
End of search list.
The following default directories have been omitted from the search path:
 /usr/lib/gcc-lib/i386-linux/2.95.4/../../../../include/g++-3
 /usr/lib/gcc-lib/i386-linux/2.95.4/../../../../i386-linux/include
End of omitted list.
 /usr/lib/gcc-lib/i386-linux/2.95.4/f771 -fnull-version -quiet -dumpbase
g77-version.f -version -fversion -o /tmp/ccCss7xb.s /dev/null
GNU F77 version 2.95.4 20011002 (Debian prerelease) (i386-linux) compiled
by GNU C version 2.95.4 20011002 (Debian prerelease).
GNU Fortran Front End version 0.5.25 20010319 (prerelease)
 as -V -Qy -o /tmp/ccOS8gud.o /tmp/ccCss7xb.s
GNU assembler version 2.12.90.0.1 (i386-linux) using BFD version
2.12.90.0.1 20020307 Debian/GNU Linux
 ld -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -o /tmp/cc8iVYBd
/tmp/ccOS8gud.o /usr/lib/crt1.o /usr/lib/crti.o
/usr/lib/gcc-lib/i386-linux/2.95.4/crtbegin.o
-L/usr/lib/gcc-lib/i386-linux/2.95.4 -lg2c -lm -lgcc -lc -lgcc
/usr/lib/gcc-lib/i386-linux/2.95.4/crtend.o /usr/lib/crtn.o
 /tmp/cc8iVYBd
__G77_LIBF77_VERSION__: 0.5.25 20010319 (prerelease)
@(#)LIBF77 VERSION 19990503
__G77_LIBI77_VERSION__: 0.5.25 20010319 (prerelease)
@(#) LIBI77 VERSION pjw,dmg-mods 19990503
__G77_LIBU77_VERSION__: 0.5.25 20010319 (prerelease)
@(#) LIBU77 VERSION 19980709
-----------------------------------------------------------------------

Obvously I have a work-around to make my code do what I want it to do,
but this makes me worry that there are other programs, compiled with
-O, that are not really doing what they are supposed to do.

Thank you for any help (patches, suggestions).  Let me know if I can
supply more information.

				Steve Williamson
				Physics Dept.
				University of Illinois

Re: optimization bug in g77

[Toon Moene]

I wrote:

> Jeff wrote, debugging a piece of Fortran with EQUIVALENCE in it:

>     >> This is our old friend MEM_IN_STRUCT_P.

> And Mark replied:

> > We could disable this optimization in 1.1.2.  It seems to be biting
> > reasonably many of us in nasty, hard to track down ways.  It seems to
> > me that saying:
> 
> >  We have noticed that some optimizations in 1.1.1 were invalid, and
> >  have disabled them.  We have fixed the problems with these
> >  optimizations, so that they will be present, in corrected form, in
> >  1.2.

Wherefore I asked:

> Mark, could you produce a patch, so that I might be able to look at
> which Fortran problems that would solve ?

I went ahead and tried the following (patch against a CVS'd copy of the
egcs_1_1_branch obtained a few hours ago):

*** alias.c.orig        Sat Feb 20 16:57:35 1999
--- alias.c     Sun Feb 21 15:57:07 1999
*************** true_dependence (mem, mem_mode, x, varie
*** 943,950 ****
       If either memory reference is a variable structure the other is a
       fixed scalar and there is no aliasing.  */
    if ((MEM_IN_STRUCT_P (mem) && varies (mem_addr))
        || (MEM_IN_STRUCT_P (x) && varies (x_addr)))
      return 0;
! 
    return 1;
  }
--- 943,951 ----
       If either memory reference is a variable structure the other is a
       fixed scalar and there is no aliasing.  */
+ /*
    if ((MEM_IN_STRUCT_P (mem) && varies (mem_addr))
        || (MEM_IN_STRUCT_P (x) && varies (x_addr)))
      return 0;
! */
    return 1;
  }

Although this doesn't kill all of the MEM_IN_STRUCT_P && varies
combinations in alias.c, this one is probably the most harmful.  With
this patch, g77 compiles the testcase correctly, whether using
optimisation or not:

[toon@moene g77-bugs]$ /usr/rel/bin/g77 -O2 h.f
[toon@moene g77-bugs]$ ./a.out
 131073 262147 393221 524295 655369
[toon@moene g77-bugs]$ /usr/rel/bin/g77 h.f
[toon@moene g77-bugs]$ ./a.out
 131073 262147 393221 524295 655369

For easy reference - here's the testcase:

      program wrbug
      common/buf3d/id3d(10,1)
      do j=1,10
        id3d(j,1) = j
      enddo
      call wr3d
      end
      subroutine wr3d
      integer ip(10)
      integer irec(5,1)                                               
      common/buf3d/id3d(10,1)
      common/temp2/i1,i2,i3,i4,i5,i6,i7,i8,i9,i10
      equivalence (i1,ip)
      n = 1
      do 100 n=1,1
         do 10 j=1,10
            ip(j)=id3d(j,n)
   10    continue
         irec(1,n)=or(i1,lshift(i2,16))
         irec(2,n)=or(i3,lshift(i4,16))
         irec(3,n)=or(i5,lshift(i6,16))
         irec(4,n)=or(i7,lshift(i8,16))
         irec(5,n)=or(i9,lshift(i10,16))
  100 continue
      print*,irec
      return
      end

-- 
Toon Moene (toon@moene.indiv.nluug.nl)
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Phone: +31 346 214290; Fax: +31 346 214286
g77 Support: fortran@gnu.org; egcs: egcs-bugs@cygnus.com

Re: optimization bug in g77

[Gerald Pfeifer]

On Tue, 16 Feb 1999, Toon Moene wrote:
> OK, so it *is* a very general bug.  In that case I (re)propose to open a
> Web page "Known Bugs". 

That's fine with me. Please submit such a patch. 

In general, we can
 a) rename c++-bugs.html to bugs.html and add it there;
 b) create a new bugs.html for everything except C++;
 c) create a new fortran-bugs.html.

Personally, I prefer both a) and b) over c), but among these two I have no
strong preference.

Gerald
-- 
Gerald Pfeifer (Jerry)      Vienna University of Technology
pfeifer@dbai.tuwien.ac.at   http://www.dbai.tuwien.ac.at/~pfeifer/

Re: optimization bug in g77

[Mark Mitchell]

>>>>> "Toon" == Toon Moene <toon@moene.indiv.nluug.nl> writes:

    >> This is our old friend MEM_IN_STRUCT_P.

We could disable this optimization in 1.1.2.  It seems to be biting
reasonably many of us in nasty, hard to track down ways.  It seems to
me that saying:

  We have noticed that some optimizations in 1.1.1 were invalid, and
  have disabled them.  We have fixed the problems with these
  optimizations, so that they will be present, in corrected form, in
  1.2. 

is a better thing to tell our users as opposed to silently, knowingly,
generating bad code.

-- 
Mark Mitchell 			mark@markmitchell.com
Mark Mitchell Consulting	http://www.markmitchell.com

Re: optimization bug in g77

[Jeffrey A Law]

I just tried this one with the current sources and I get the same results
with -O0, -O1, -O2, -O2 -funroll-loops on my i686 linux box.  It may be
the case that this was being mis-compiled due to the two strength reduction
bugs Joern fixed yesterday.


  In message < 36B8C2A7.7304B9B@moene.indiv.nluug.nl >you write:
  > craig@jcb-sc.com wrote:
  > 
  > > Could you be more specific about just what the bug is?  We aren't
  > > normally able to try to debug other peoples' programs, assuming that
  > > the bug will turn out to be in the compiler.  (We do it on occasion,
  > > though.)
  > 
  > I've downsized the code a bit :-)
  > 
  >       program wrbug
  >       common/buf3d/id3d(10,1)
  >       do j=1,10
  >         id3d(j,1) = j
  >       enddo
  >       call wr3d
  >       end
  >       subroutine wr3d
  >       integer ip(10)
  >       integer irec(5,1)                                               
  >       common/buf3d/id3d(10,1)
  >       common/temp2/i1,i2,i3,i4,i5,i6,i7,i8,i9,i10
  >       equivalence (i1,ip)
  >       n = 1
  > c     do 100 n=1,1
  >          do 10 j=1,10
  >             ip(j)=id3d(j,n)
  >    10    continue
  >          irec(1,n)=or(i1,lshift(i2,16))
  >          irec(2,n)=or(i3,lshift(i4,16))
  >          irec(3,n)=or(i5,lshift(i6,16))
  >          irec(4,n)=or(i7,lshift(i8,16))
  >          irec(5,n)=or(i9,lshift(i10,16))
  > c 100 continue
  >       print*,irec
  >       return
  >       end
  > 
  > This code works when compiled with option -O using:
  > 
  > [toon@moene g77-bugs]$ g77 -v
  > g77 version egcs-2.91.59 19981124 (egcs-1.1.1 pre-release #3) (from
  > FSF-g77 version 0.5.24-19980804)
  > Driving: g77 -v -c -xf77-version /dev/null -xnone
  > Reading specs from
  > /usr/local/lib/gcc-lib/i686-pc-linux-gnu/egcs-2.91.59/specs
  > gcc version egcs-2.91.59 19981124 (egcs-1.1.1 pre-release #3)
  > 
  > If you remove the two comment `c`s and thereby enable the outer loop,
  > the final print statement will print 5 zero's, which definitely is not
  > TRTTD.
  > 
  > However,
  > 
  > [toon@moene g77-bugs]$ /usr/snp/bin/g77 -v
  > g77 version egcs-2.93.04 19990203 (gcc2 ss-980929 experimental) (from
  > FSF-g77 version 0.5.24-19980804)
  > Driving: /usr/snp/bin/g77 -v -c -xf77-version /dev/null -xnone
  > Reading specs from
  > /usr/snp/lib/gcc-lib/i686-pc-linux-gnu/egcs-2.93.04/specs
  > gcc version egcs-2.93.04 19990203 (gcc2 ss-980929 experimental)
  > 
  > gives the correct answers.
  > 
  > HTH,
  > 
  > -- 
  > Toon Moene (toon@moene.indiv.nluug.nl)
  > Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
  > Phone: +31 346 214290; Fax: +31 346 214286
g77 Support: fortran@gnu.org; egcs: egcs-bugs@cygnus.com

Re: optimization bug in g77

[Toon Moene]

Jeff wrote, debugging a piece of Fortran with EQUIVALENCE in it:

    >> This is our old friend MEM_IN_STRUCT_P.

And Mark replied:

> We could disable this optimization in 1.1.2.  It seems to be biting
> reasonably many of us in nasty, hard to track down ways.  It seems to
> me that saying:

>  We have noticed that some optimizations in 1.1.1 were invalid, and
>  have disabled them.  We have fixed the problems with these
>  optimizations, so that they will be present, in corrected form, in
>  1.2. 

Mark, could you produce a patch, so that I might be able to look at
which Fortran problems that would solve ?

TIA,

-- 
Toon Moene (toon@moene.indiv.nluug.nl)
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Phone: +31 346 214290; Fax: +31 346 214286
g77 Support: fortran@gnu.org; egcs: egcs-bugs@cygnus.com

Re: optimization bug in g77

[Toon Moene]

Gerald Pfeifer wrote:

> On Tue, 16 Feb 1999, Toon Moene wrote:

> > OK, so it *is* a very general bug.  In that case I (re)propose to open a
> > Web page "Known Bugs".

> That's fine with me. Please submit such a patch.

> In general, we can
>  a) rename c++-bugs.html to bugs.html and add it there;
>  b) create a new bugs.html for everything except C++;
>  c) create a new fortran-bugs.html.

> Personally, I prefer both a) and b) over c), but among these two I have no
> strong preference.

On further reading this thread, I think I agree with Mark Mitchell's
standpoint that this "optimization" should be disabled (the reason I
didn't state this earlier is that 1. I wasn't sure what was wrong and 2.
I didn't know it was easy to disable the faulty parts of the compiler).

However, I still think that it would be useful if the c++-bugs.html page
were turned into a general "Known Bugs" page, with subsections for the
various languages.  Could you organize that ?  Then we'll fill the
(initially empty if the above suggestion is taken over) Fortran section.

TIA,

-- 
Toon Moene (toon@moene.indiv.nluug.nl)
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Phone: +31 346 214290; Fax: +31 346 214286
g77 Support: fortran@gnu.org; egcs: egcs-bugs@cygnus.com

PS: This is g77's fourth birthday: HEEEP HEEEP HURRRRAY !

Re: optimization bug in g77

[Jeffrey A Law]

  In message < 36C6B4DC.7E106BCF@moene.indiv.nluug.nl >you write:
  > >   > FSF-g77 version 0.5.24-19980804)
  > >   > Driving: /usr/snp/bin/g77 -v -c -xf77-version /dev/null -xnone
  > >   > Reading specs from
  > >   > /usr/snp/lib/gcc-lib/i686-pc-linux-gnu/egcs-2.93.04/specs
  > >   > gcc version egcs-2.93.04 19990203 (gcc2 ss-980929 experimental)
  > >   >
  > >   > gives the correct answers.
  > 
  > The point of this error is that it is in egcs-1.1.1 and a fix for 1.1.2
  > would be very welcome (as long as we do not know _what_ fixed it in the
  > current mainline sources, it could well be a very general bug ...)
With egcs-1.1.x it looks like the loads associated with these statements got
hoisted out of the loops

         irec(1,n)=or(i1,lshift(i2,16))                                    1
         irec(2,n)=or(i3,lshift(i4,16))                                    1
         irec(3,n)=or(i5,lshift(i6,16))                                    1
         irec(4,n)=or(i7,lshift(i8,16))                                    1
         irec(5,n)=or(i9,lshift(i10,16))                                   1


Which presumably is bad since ip & i1 are equivalenced and thus the inner loop
changes i1 and friends :(

This is our old friend MEM_IN_STRUCT_P.

Basically we pass these two addresses to true_dependence:

(gdb) p debug_rtx(x)

(mem:SI (const:SI (plus:SI (symbol_ref:SI ("temp2_"))
            (const_int 4))))
$29 = void
(gdb) p debug_rtx(mem)

(mem/s:SI (plus:SI (reg:SI 26)
        (reg:SI 28)))


And we know that (reg 26) == (symbol_ref ("temp2_"))

The base alias check fails to disambiguate the addresses (correctly).  So we
fall into the code to check MEM_IN_STRUCT_P.  The basic algorithm for checking
MEM_IN_STRUCT_P in this era code is:

       /* One memory reference is to a constant address, one is not.
          One is to a structure, the other is not.

          If either memory reference is a variable structure the other is a
          fixed scalar and there is no aliasing.  */


Which is precisely what we have.  One memory address which is constant, the
other varies.  One is to a "structure", one is not.  So we think the two
addresses can never refer to the same memory location.  Wrongo.


Fixing this would require backmerging the mainline code which added
MEM_SCALAR_P to the compiler.  Nontrivial at best.  I don't expect we'll fix
this one for egcs-1.1.2.

Not using an equivalence in this manner would probably avoid the bug in 
the short term.


jeff

Re: optimization bug in g77

[craig]

>I hope this is the correct email address for bugs with g77 based on
>egcs.  I have attached a short fortran file which demonstrates an
>optimization bug with g77.

Could you be more specific about just what the bug is?  We aren't
normally able to try to debug other peoples' programs, assuming that
the bug will turn out to be in the compiler.  (We do it on occasion,
though.)

If you could debug your program yourself, perhaps you'll find that
the bug is in the code, not the compiler, or elsewhere.  But, if it
is in the compiler, at least you will be able to be much more specific
about just what the bug *is*, e.g. point to wrong assembler code
generated by the compiler, or similar.

The g77/gcc documentation has information on this sort of thing
when it comes to reporting bugs.

        tq vm, (burley)

Re: optimization bug in g77

[Toon Moene]

craig@jcb-sc.com wrote:

> Could you be more specific about just what the bug is?  We aren't
> normally able to try to debug other peoples' programs, assuming that
> the bug will turn out to be in the compiler.  (We do it on occasion,
> though.)

I've downsized the code a bit :-)

      program wrbug
      common/buf3d/id3d(10,1)
      do j=1,10
        id3d(j,1) = j
      enddo
      call wr3d
      end
      subroutine wr3d
      integer ip(10)
      integer irec(5,1)                                               
      common/buf3d/id3d(10,1)
      common/temp2/i1,i2,i3,i4,i5,i6,i7,i8,i9,i10
      equivalence (i1,ip)
      n = 1
c     do 100 n=1,1
         do 10 j=1,10
            ip(j)=id3d(j,n)
   10    continue
         irec(1,n)=or(i1,lshift(i2,16))
         irec(2,n)=or(i3,lshift(i4,16))
         irec(3,n)=or(i5,lshift(i6,16))
         irec(4,n)=or(i7,lshift(i8,16))
         irec(5,n)=or(i9,lshift(i10,16))
c 100 continue
      print*,irec
      return
      end

This code works when compiled with option -O using:

[toon@moene g77-bugs]$ g77 -v
g77 version egcs-2.91.59 19981124 (egcs-1.1.1 pre-release #3) (from
FSF-g77 version 0.5.24-19980804)
Driving: g77 -v -c -xf77-version /dev/null -xnone
Reading specs from
/usr/local/lib/gcc-lib/i686-pc-linux-gnu/egcs-2.91.59/specs
gcc version egcs-2.91.59 19981124 (egcs-1.1.1 pre-release #3)

If you remove the two comment `c`s and thereby enable the outer loop,
the final print statement will print 5 zero's, which definitely is not
TRTTD.

However,

[toon@moene g77-bugs]$ /usr/snp/bin/g77 -v
g77 version egcs-2.93.04 19990203 (gcc2 ss-980929 experimental) (from
FSF-g77 version 0.5.24-19980804)
Driving: /usr/snp/bin/g77 -v -c -xf77-version /dev/null -xnone
Reading specs from
/usr/snp/lib/gcc-lib/i686-pc-linux-gnu/egcs-2.93.04/specs
gcc version egcs-2.93.04 19990203 (gcc2 ss-980929 experimental)

gives the correct answers.

HTH,

-- 
Toon Moene (toon@moene.indiv.nluug.nl)
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Phone: +31 346 214290; Fax: +31 346 214286
g77 Support: fortran@gnu.org; egcs: egcs-bugs@cygnus.com

Re: optimization bug in g77

[Jeffrey A Law]

  > Nope, because I wrote (perhaps it was too hidden - at the end):
  > 
  > >   > However,
  > >   >
  > >   > [toon@moene g77-bugs]$ /usr/snp/bin/g77 -v
  > >   > g77 version egcs-2.93.04 19990203 (gcc2 ss-980929 experimental) (from
  > >   > FSF-g77 version 0.5.24-19980804)
  > >   > Driving: /usr/snp/bin/g77 -v -c -xf77-version /dev/null -xnone
  > >   > Reading specs from
  > >   > /usr/snp/lib/gcc-lib/i686-pc-linux-gnu/egcs-2.93.04/specs
  > >   > gcc version egcs-2.93.04 19990203 (gcc2 ss-980929 experimental)
  > >   >
  > >   > gives the correct answers.
  > 
  > The point of this error is that it is in egcs-1.1.1 and a fix for 1.1.2
  > would be very welcome (as long as we do not know _what_ fixed it in the
  > current mainline sources, it could well be a very general bug ...)
I must have missed this.  Opps.  I'll retry with the latest 1.1.2 bits :-)

jeff

Re: optimization bug in g77

[Jeffrey A Law]

  In message < 199902212341.PAA21225@adsl-206-170-148-33.dsl.pacbell.net >you wri
te:
  >     Jeffrey> For those codes which do trip the problem folks can
  >     Jeffrey> disable this optimization.
  > 
  > But, for most users, it's very difficult, if not impossible, to figure
  > out *what* optimization is causing the problem.  Most likely, they'll
  > compile a large program and find it behave unexpectedly, and just not
  > know why.  This reflects poorly on EGCS.
Good point.  Though given that this bug has been in gcc for ~10 years now
and we've probably had less than a dozen bugs says something about how often
it triggers.  Interestingly enough, most of the problems have shown up over
the last 18 months -- because our alias analysis is getting better and our
scheduler is getting more agressive.


  > I think it's a good deal more responsible to invert your suggestion:
  > disable the (known to be broken) optimization by default, and then
  > provide an option to *enable* it.  Thus, the "power users", who want
  > maximum speed, can know what they're getting into: the documentation
  > will say explicitly that the option is, in general, known to be
  > unsafe.
I think this is a little overly conservative, but I can live with it.  
-f[no]structure-alias or something like that?  

The docs might look something like:

-fstructure-alias:
Allow the compiler to assume that a structure or array reference at a 
varying address can never conflict with a scalar reference at a fixed
address.  In the vast majority of programs this is safe, but in a small
number programs a bug in GCC's alias analysis can cause incorrect code
generation.  Thus the default is -fno-structure-alias.

This option is only found in the egcs-1.1.2 release.  egcs-1.2 and newer
releases have fixed the alias analysis bug and always assume that a
structure/array reference at a varying address can never conflict with
a scalar reference at a fixed address.

Jeff

Re: optimization bug in g77

[Toon Moene]

Jeffrey A Law wrote:
> 
> I just tried this one with the current sources and I get the same results
> with -O0, -O1, -O2, -O2 -funroll-loops on my i686 linux box.  It may be
> the case that this was being mis-compiled due to the two strength reduction
> bugs Joern fixed yesterday.

Nope, because I wrote (perhaps it was too hidden - at the end):

>   > However,
>   >
>   > [toon@moene g77-bugs]$ /usr/snp/bin/g77 -v
>   > g77 version egcs-2.93.04 19990203 (gcc2 ss-980929 experimental) (from
>   > FSF-g77 version 0.5.24-19980804)
>   > Driving: /usr/snp/bin/g77 -v -c -xf77-version /dev/null -xnone
>   > Reading specs from
>   > /usr/snp/lib/gcc-lib/i686-pc-linux-gnu/egcs-2.93.04/specs
>   > gcc version egcs-2.93.04 19990203 (gcc2 ss-980929 experimental)
>   >
>   > gives the correct answers.

The point of this error is that it is in egcs-1.1.1 and a fix for 1.1.2
would be very welcome (as long as we do not know _what_ fixed it in the
current mainline sources, it could well be a very general bug ...)

-- 
Toon Moene (toon@moene.indiv.nluug.nl)
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Phone: +31 346 214290; Fax: +31 346 214286
g77 Support: fortran@gnu.org; egcs: egcs-bugs@cygnus.com

Re: optimization bug in g77

[Jeffrey A Law]

  In message < 199902220017.QAA04512@adsl-206-170-148-33.dsl.pacbell.net >you wri
te:
  > This is good.  I would suggest a minor modification.  Instead of the
  > part from `In the vast majority' on, how about
Fine.

  > 
  >    Although this optimization is safe, GCC can occasionally lose track
  >    of which references refer to scalars and which to structures,
  >    leading it to perform unsafe transformations.  Release 1.2 of EGCS
  >    will incorporate changes which allow GCC to track the
  >    scalar/structure distinction safely.  Thus, the optimization will
  >    always be same, and this option will likely be removed.
                 ^^^^ safe

jeff

Re: optimization bug in g77

[Toon Moene]

Mike Stump wrote:

> > Date: Sun, 21 Feb 1999 15:41:05 -0800
> > From: Mark Mitchell <mark@markmitchell.com>

> > I think it's a good deal more responsible to invert your suggestion:
> > disable the (known to be broken) optimization by default, and then
> > provide an option to *enable* it.  Thus, the "power users", who want
> > maximum speed, can know what they're getting into: the documentation
> > will say explicitly that the option is, in general, known to be
> > unsafe.

> No, I prefer to ship a compiler with a known bug in it when
> optimizing, then to introduce a flag that is documented as being
> dangerous and known to generate bad code.  This is non-negotiable.

> Only flags that last 10 years should ever be put in, because they
> will.

> All compilers have bugs, all compilers ship with bugs, this is just a
> fact of life.  The `badness' of the bug drives the resources to fix
> it, if it is unfixed, it means it isn't that bad.  (fatalist
> viewpoint) If it is so bad, then it should just be disabled.

I do not agree.  My favorite unfixed bug is the COMPLEX problem on
64-bit targets.  Because it has been known and unfixed for a long time,
g77 defaults to "emulating complex arithmetic in the front-end", enabled
(by default) with the flag -femulate-complex.

This doesn't stop me from explaining to people who run into the
performance problems this brings about to try and compile their stuff
with -fno-emulate-complex *iff* they have a means to compare the
resulting output of the compiled program against some known correct
output or know how to check otherwise that -f[no-]emulate-complex gives
the same answers in all known paths through the program (yes, I know
that in general this is unsolvable, but in practice this is sometimes
possible).

In fact, with such options, one wants to stress two issues:

1. Do expect the option to go away, and hence:
2. Do not put it in makefiles, etc.

The latter is even easier with the flag Mark proposes, because we
already know exactly at which version of the compiler the flag will go
away (1.2), something we don't know for the -f[no-]emulate-complex flag.

Cheers,

-- 
Toon Moene (toon@moene.indiv.nluug.nl)
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Phone: +31 346 214290; Fax: +31 346 214286
g77 Support: fortran@gnu.org; egcs: egcs-bugs@cygnus.com
>From oliva@dcc.unicamp.br Tue Feb 23 13:04:00 1999
From: Alexandre Oliva <oliva@dcc.unicamp.br>
To: Stefan Hoehne <s_hoehne@informatik.uni-kl.de>
Cc: egcs-bugs@egcs.cygnus.com
Subject: Re: Solaris-problem with setting the appropriate LD/AS
Date: Tue, 23 Feb 1999 13:04:00 -0000
Message-id: <orpv70g7j2.fsf@araguaia.dcc.unicamp.br>
In-reply-to: Stefan Hoehne's message of "Mon, 22 Feb 1999 22:31:06 +0100 (MET)"
References: <Pine.SO4.4.05.9902222148420.1661-100000@domino.informatik.uni-kl.de>
X-SW-Source: 1999-02/msg00722.html
Content-length: 1158

On Feb 22, 1999, Stefan Hoehne <s_hoehne@informatik.uni-kl.de> wrote:

> So I got some binutils 2.9.1 from somewhere and installed it. I tried to
> put the real-ld, real-as - links in /usr/ccs/bin, but egcs kept using
> solaris-as/ld. (So long I didnt recompile.)

The links should be put in one of the program search dirs, as printed
by `gcc -print-search-dirs', such as
/usr/local/lib/gcc-lib/sparc-sun-solaris2.5/egcs-2.91.60

> Then I configured egcs with --with-as=/opt/gnu/bin/as and

--with-as and --with-ld are only supported in the upcoming egcs 1.2 tree
(not 1.1.2)

> Another "bug" ... nobody tells me something about bug-reporting within
> egcs. This list is hidden on the website, and wether there nor in the
> sources nor in the faq is a "send-you-bug-report-to" - hint, as far as I
> see (thats not very far, indeed, but I really couldnt find it).

How about the manual, gcc.info ?  It also supplies the bug-reporting
address when an internal compiler error occurs.

-- 
Alexandre Oliva  http://www.dcc.unicamp.br/~oliva  aoliva@{acm.org}
oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org}
Universidade Estadual de Campinas, SP, Brasil

Re: optimization bug in g77

[Mike Stump]

> Date: Sun, 21 Feb 1999 15:41:05 -0800
> From: Mark Mitchell <mark@markmitchell.com>

> I think it's a good deal more responsible to invert your suggestion:
> disable the (known to be broken) optimization by default, and then
> provide an option to *enable* it.  Thus, the "power users", who want
> maximum speed, can know what they're getting into: the documentation
> will say explicitly that the option is, in general, known to be
> unsafe.

No, I prefer to ship a compiler with a known bug in it when
optimizing, then to introduce a flag that is documented as being
dangerous and known to generate bad code.  This is non-negotiable.

Only flags that last 10 years should ever be put in, because they
will.

All compilers have bugs, all compilers ship with bugs, this is just a
fact of life.  The `badness' of the bug drives the resources to fix
it, if it is unfixed, it means it isn't that bad.  (fatalist
viewpoint) If it is so bad, then it should just be disabled.
>From ian@airs.com Mon Feb 22 21:28:00 1999
From: Ian Lance Taylor <ian@airs.com>
To: egcs-bugs@egcs.cygnus.com
Subject: g++ virtual table bug in egcs 1.1.1 on GNU/Linux
Date: Mon, 22 Feb 1999 21:28:00 -0000
Message-id: <19990223052831.17664.qmail@comton.airs.com>
X-SW-Source: 1999-02/msg00705.html
Content-length: 876

The following code fails to link when using egcs 1.1.1 on GNU/Linux:

class a
{
public:
  virtual ~a () { }
  virtual int operator() () = 0;
};

int
main ()
{
  class b : public a
  {
  public:
    int operator() () { return 0; }
  };

  b c;
  return c ();
}

I put this into foo.cc, and built it as follows:

tweety> g++ -g -c -O foo.cc
tweety> g++ -o foobar foo.o
foo.o: In function `a type_info function':
/disk2/home/ian/foo.cc(.gnu.linkonce.d.__vt_Q26main.0_1b+0x8): undefined reference to `_._Q26main.0_1b.5'
/disk2/home/ian/foo.cc(.gnu.linkonce.d.__vt_Q26main.0_1b+0xc): undefined reference to `__cl__Q26main.0_1b.4'
collect2: ld returned 1 exit status

These errors only occur when compiling with -O.  Without -O, there is
no error.

I don't actually know whether using a local classl like this is legal
C++.  If it isn't, this is an inappropriate failure mode.

Ian
>From law@hurl.cygnus.com Mon Feb 22 22:01:00 1999
From: Jeffrey A Law <law@hurl.cygnus.com>
To: Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at>
Cc: egcs-bugs@egcs.cygnus.com
Subject: Re: Bootstrap failure: gcc/install.texi:1074: Unknown command `uref 
Date: Mon, 22 Feb 1999 22:01:00 -0000
Message-id: <11787.919749548@hurl.cygnus.com>
In-reply-to: Your message of Mon, 22 Feb 1999 18:24:34 MST.            < Pine.GSO.4.10.9902221815471.23139-100000@markab.dbai.tuwien.ac.at > 
References: <Pine.GSO.4.10.9902221815471.23139-100000@markab.dbai.tuwien.ac.at>
X-SW-Source: 1999-02/msg00706.html
Content-length: 1221

  In message < Pine.GSO.4.10.9902221815471.23139-100000@markab.dbai.tuwien.ac.at
>you write:
  > Instead of bootstrap comparison failures (as of a couple of hours ago),
  > on sparc-sun-solaris2.6 I do now get the following error:
  > 
  > makeinfo  -I/sw/swtest/egcs/egcs/gcc -o cpp.info /sw/swtest/egcs/egcs/gcc/c
  > pp.texi
  > Making info file `cpp.info' from `/sw/swtest/egcs/egcs/gcc/cpp.texi'.
  > makeinfo  -I/sw/swtest/egcs/egcs/gcc -o gcc.info
  > /sw/swtest/egcs/egcs/gcc/gcc.texi
  > /sw/swtest/egcs/egcs/gcc/install.texi:1074: Unknown command `uref'.
  > /sw/swtest/egcs/egcs/gcc/install.texi:1074: Misplaced `{'.
  > /sw/swtest/egcs/egcs/gcc/install.texi:1074: Misplaced `}'.
  > Making info file `gcc.info' from `/sw/swtest/egcs/egcs/gcc/gcc.texi'.
  > gmake[2]: *** [gcc.info] Error 2
  > gmake[2]: Leaving directory `/files/pfeifer/OBJ-2202-17:58/gcc'
  > gmake[1]: *** [bootstrap] Error 2
  > gmake[1]: Leaving directory `/files/pfeifer/OBJ-2202-17:58/gcc'
  > gmake: *** [bootstrap] Error 2
  > 
  > I did another egcs_update, but strangle enough, install.texi still is at
  > Jan 31 21:34. (No, I haven't set any sticky tag.)
This looks like you're not picking up makeinfo from the build tree.

jeff
>From post@innovative-systems.de Mon Feb 22 22:59:00 1999
From: "innovative systems" <post@innovative-systems.de>
To: <amylaar@cygnus.com>, <egcs-bugs@egcs.cygnus.com>
Subject: egcs-1.1.2-pre1 problems on Hitachi SH
Date: Mon, 22 Feb 1999 22:59:00 -0000
Message-id: <000001be5ef9$ed320ae0$23c735d4@internet>
X-SW-Source: 1999-02/msg00707.html
Content-length: 242

Hi,

Two problems with the Hitachi SH target in ecgs-1.1.2-pre1

-- egcs will generate illegal "braf" instruction on SH-1 Target
-- va-sh.h breaks with -ansi option due to "asm" instead of "__asm__"

Hartmut Schirmer
hs@innovative-systems.de
>From martin@mira.isdn.cs.tu-berlin.de Tue Feb 23 00:31:00 1999
From: "Martin v. Loewis" <martin@mira.isdn.cs.tu-berlin.de>
To: ian@airs.com
Cc: egcs-bugs@egcs.cygnus.com
Subject: Re: g++ virtual table bug in egcs 1.1.1 on GNU/Linux
Date: Tue, 23 Feb 1999 00:31:00 -0000
Message-id: <199902230824.JAA00583@mira.isdn.cs.tu-berlin.de>
In-reply-to: < 19990223052831.17664.qmail@comton.airs.com > (message from IanLance Taylor on 23 Feb 1999 00:28:31 -0500)
References: <19990223052831.17664.qmail@comton.airs.com> <19990223052831.17664.qmail@comton.airs.com>
X-SW-Source: 1999-02/msg00708.html
Content-length: 296

> I don't actually know whether using a local classl like this is legal
> C++.  If it isn't, this is an inappropriate failure mode.

This is well-formed, and egcs-2.93.08 19990219 processes it correctly
on my system (i586-pc-linux-gnu). I don't know whether it's fixed in
1.1.2.

Regards,
Martin
>From tigra@klo.re.com.ua Tue Feb 23 01:12:00 1999
From: Alexey Tigarev <tigra@klo.re.com.ua>
To: egcs-bugs@cygnus.com
Subject: Bug with using of %z0 in inline asm directives
Date: Tue, 23 Feb 1999 01:12:00 -0000
Message-id: <Pine.BSI.3.91.950218110500.26461A-100000@klo.re.com.ua>
X-SW-Source: 1999-02/msg00709.html
Content-length: 1748

Hello ! 

I have found such a bug in GCC compiler (egcs-2.90.29 980515 (egcs-1.0.3
release))

Here's bug description :

I defined a template function :

template <class Value>
void test()
{
 Value arg;
 int shift;
 scanf("%d%d", &shift, &arg);
 ROR(shift, arg); 
 printf("%d\n", arg);
}

and used in it the following macro :

#define ROR(arg, shift) \
        __asm__ volatile ("ror%z0 %b1, %0" : "=r" (arg) : "c" (shift), "0" (arg))


GCC output was:

test_asm_macro.cc: In function `void test()':
test_asm_macro.cc:11: Internal compiler error 40.
test_asm_macro.cc:11: Please submit a full bug report to `egcs-bugs@cygnus.com'.

Version of compiler :
egcs-2.90.29 980515 (egcs-1.0.3 release)

Here's 'test_asm_macro.cc' :

//////////////////////////// test_asm_macro.cc ////////////////////////////
#include <stdio.h>

#define ROR(arg, shift) \
     __asm__ volatile ("ror%z0 %b1, %0" : "=r" (arg) : "c" (shift), "0" (arg))

template <class Value>
void test()
{
 Value arg;
 int shift;
 scanf("%d%d", &shift, &arg);
 ROR(shift, arg); 
 printf("%d\n", arg);
}

void main()
{
 test<int>();
}

////////////////////////// End of test_asm_macro.cc ///////////////////////

The same error occured when I removed template function :

///////////////////////////////////////////////////////////////////////////
#include <stdio.h>

#define ROR(arg, shift) \
    __asm__ volatile ("ror%z0 %b1, %0" : "=r" (arg) : "c" (shift), "0" (arg))

void main()
{
 int arg;
 int shift;
 scanf("%d%d", &shift, &arg);
 ROR(shift, arg); 
 printf("%d\n", arg);
}
////////////////////////////////////////////////////////////////////////////


SY: Tigra           [ UNIX ]  [ RL ]  [ IMEM ]  [ OHN ]  [ ACM ] 
atigarev@acm.org    http://www.rl.odessa.ua/~tigra  ICQ #95550

Re: optimization bug in g77

[Toon Moene]

Mark Mitchell wrote:

> I wrote:

>     >> I went ahead and tried the following (patch against a CVS'd
>     >> copy of the egcs_1_1_branch obtained a few hours ago):

> Toone, I'm sorry I didn't get back to you sooner.  I was out of town
> for a couple of days.

Ah, this wasn't meant as criticism - it's just that I had some spare
time on a rainy sunday afternoon :-)

>     Jeffrey> For those codes which do trip the problem folks can
>     Jeffrey> disable this optimization.
> 
> But, for most users, it's very difficult, if not impossible, to figure
> out *what* optimization is causing the problem.  Most likely, they'll
> compile a large program and find it behave unexpectedly, and just not
> know why.  This reflects poorly on EGCS.

Exactly my feelings.  On reflection, I *think* I have a pretty good
handle on how to describe the situation to Fortran users:

	An EQUIVALENCE of an array and a sequence of scalars,
	of which either the array or the sequence of scalars
	resides in COMMON.

... but I'm still not sure this covers all the failure modes.

> I think it's a good deal more responsible to invert your suggestion:
> disable the (known to be broken) optimization by default, and then
> provide an option to *enable* it.  Thus, the "power users", who want
> maximum speed, can know what they're getting into: the documentation
> will say explicitly that the option is, in general, known to be
> unsafe.

Agree (as with the followup mails on this subject).

Thanks,

-- 
Toon Moene (toon@moene.indiv.nluug.nl)
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Phone: +31 346 214290; Fax: +31 346 214286
g77 Support: fortran@gnu.org; egcs: egcs-bugs@cygnus.com
>From martin@mira.isdn.cs.tu-berlin.de Mon Feb 22 15:41:00 1999
From: "Martin v. Loewis" <martin@mira.isdn.cs.tu-berlin.de>
To: nathan@compsci.bristol.ac.uk
Cc: egcs-bugs@egcs.cygnus.com, egcs-patches@egcs.cygnus.com
Subject: Re: namespace alias and using directive
Date: Mon, 22 Feb 1999 15:41:00 -0000
Message-id: <199902222340.AAA00669@mira.isdn.cs.tu-berlin.de>
In-reply-to: < 36D026CA.EEC08F49@acm.org > (message from Nathan Sidwell on Sun,21 Feb 1999 15:31:22 +0000)
References: <36D026CA.EEC08F49@acm.org> <36D026CA.EEC08F49@acm.org>
X-SW-Source: 1999-02/msg00698.html
Content-length: 862

> Is this a bug, or more C++ namespace weirdness?

I'd say this is a bug. Here is a patch.

Thanks,
Martin

1999-02-22  Martin von Loewis  <loewis@informatik.hu-berlin.de>

	* decl.c (lookup_namespace_name): Resolve namespace aliases.

//Build don't link:
namespace A{
  namespace B{int i;}
  using namespace B;
}

namespace C=A;

void f(){
  C::i = 1;
}

Index: decl.c
===================================================================
RCS file: /egcs/carton/cvsfiles/egcs/gcc/cp/decl.c,v
retrieving revision 1.312
diff -u -p -r1.312 decl.c
--- decl.c	1999/02/21 16:38:14	1.312
+++ decl.c	1999/02/22 17:54:20
@@ -5029,6 +5029,8 @@ lookup_namespace_name (namespace, name)
       return error_mark_node;
     }
 
+  namespace = ORIGINAL_NAMESPACE (namespace);
+
   my_friendly_assert (TREE_CODE (name) == IDENTIFIER_NODE, 373);
   
   val = binding_init (&_b);

Re: optimization bug in g77

[Mark Mitchell]

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

    Jeffrey> I think this is a little overly conservative, but I can
    Jeffrey> live with it.  -f[no]structure-alias or something like
    Jeffrey> that?

    Jeffrey> The docs might look something like:

    Jeffrey> -fstructure-alias: Allow the compiler to assume that a
    Jeffrey> structure or array reference at a varying address can
    Jeffrey> never conflict with a scalar reference at a fixed
    Jeffrey> address.  In the vast majority of programs this is safe,
    Jeffrey> but in a small number programs a bug in GCC's alias
    Jeffrey> analysis can cause incorrect code generation.  Thus the
    Jeffrey> default is -fno-structure-alias.

This is good.  I would suggest a minor modification.  Instead of the
part from `In the vast majority' on, how about

   Although this optimization is safe, GCC can occasionally lose track
   of which references refer to scalars and which to structures,
   leading it to perform unsafe transformations.  Release 1.2 of EGCS
   will incorporate changes which allow GCC to track the
   scalar/structure distinction safely.  Thus, the optimization will
   always be same, and this option will likely be removed.

?

-- 
Mark Mitchell 			mark@markmitchell.com
Mark Mitchell Consulting	http://www.markmitchell.com
>From law@hurl.cygnus.com Sun Feb 21 16:24:00 1999
From: Jeffrey A Law <law@hurl.cygnus.com>
To: mark@markmitchell.com
Cc: toon@moene.indiv.nluug.nl, egcs-bugs@cygnus.com
Subject: Re: optimization bug in g77 
Date: Sun, 21 Feb 1999 16:24:00 -0000
Message-id: <8052.919643009@hurl.cygnus.com>
In-reply-to: Your message of Sun, 21 Feb 1999 16:17:54 MST.            < 199902220017.QAA04512@adsl-206-170-148-33.dsl.pacbell.net > 
References: <199902220017.QAA04512@adsl-206-170-148-33.dsl.pacbell.net>
X-SW-Source: 1999-02/msg00666.html
Content-length: 670

  In message < 199902220017.QAA04512@adsl-206-170-148-33.dsl.pacbell.net >you wri
te:
  > This is good.  I would suggest a minor modification.  Instead of the
  > part from `In the vast majority' on, how about
Fine.

  > 
  >    Although this optimization is safe, GCC can occasionally lose track
  >    of which references refer to scalars and which to structures,
  >    leading it to perform unsafe transformations.  Release 1.2 of EGCS
  >    will incorporate changes which allow GCC to track the
  >    scalar/structure distinction safely.  Thus, the optimization will
  >    always be same, and this option will likely be removed.
                 ^^^^ safe

jeff
>From jbertram@bydgoszcz.cs.iastate.edu Sun Feb 21 16:52:00 1999
From: Josh Bertram <jbertram@bydgoszcz.cs.iastate.edu>
To: egcs-bugs@cygnus.com
Subject: egcs bug
Date: Sun, 21 Feb 1999 16:52:00 -0000
Message-id: <199902220056.SAA27475@bydgoszcz.cs.iastate.edu>
X-SW-Source: 1999-02/msg00667.html
Content-length: 455

Apparently, I found a bug:
In file included from gaptracker.C:1:
gaptracker.h:18: warning: ANSI C++ forbids initialization of member `m_W'
gaptracker.h:18: Internal compiler error.
gaptracker.h:18: Please submit a full bug report to `egcs-bugs@cygnus.com'.

Here's the code that caused the bug:
class gaptracker
{
  // unimportant stuff
 private:
  window m_W( WINDOW_SIZE, WINDOW_SIZE, "Sensor Based Viewpoint");
};



Yours,
Josh - jbertram@iastate.edu
>From nathan@acm.org Sun Feb 21 18:15:00 1999
From: Nathan Sidwell <nathan@acm.org>
To: egcs-bugs@egcs.cygnus.com
Subject: namespace alias and using directive
Date: Sun, 21 Feb 1999 18:15:00 -0000
Message-id: <36D026CA.EEC08F49@acm.org>
X-SW-Source: 1999-02/msg00668.html
Content-length: 1439

Hi,
When employing a namspace alias, using directives in the aliased
namespace don't appear to be searched. Here's an example program,

namespace Foo { 
  namespace Baz {
    int i;
  }
  using namespace Baz;
}
namespace Bar = Foo;

void fn() 
{
  Foo::i = 1;
  Bar::i = 1;
} 

and here's what g++ says,
nathan@manao:1089>devel-g++ -v alias.ii 
Reading specs from /home/staff/nathan/solaris/local/sparc-SunOS_5/lib/gcc-lib/sparc-sun-solaris2.6/egcs-2.93.08/specs
gcc version egcs-2.93.08 19990219 (gcc2 ss-980929 experimental)
 /home/staff/nathan/solaris/local/sparc-SunOS_5/lib/gcc-lib/sparc-sun-solaris2.6/egcs-2.93.08/cc1plus alias.ii -quiet -version -o /var/tmp/ccLJcaaa.s
GNU C++ version egcs-2.93.08 19990219 (gcc2 ss-980929 experimental) (sparc-sun-solaris2.6) compiled by GNU C version egcs-2.91.57 19980901 (egcs-1.1 release).
alias.ii: In function `void Foo::fn()':
alias.ii:12: `i' undeclared in namespace `Bar'

The using directive works for locating Foo::Baz::i  with Foo::i, but not
when Foo's alias Bar is used.

The CD2 doesn't mention that this won't work, and the language used in defining a
namespace alias leads me to believe it should work.

Is this a bug, or more C++ namespace weirdness?

nathan
--
Dr Nathan Sidwell :: Computer Science Department :: Bristol University
      You can up the bandwidth, but you can't up the speed of light      
nathan@acm.org  http://www.cs.bris.ac.uk/~nathan/  nathan@cs.bris.ac.uk
>From jstern@citilink.com Sun Feb 21 18:51:00 1999
From: Josh Stern <jstern@citilink.com>
To: egcs-bugs@egcs.cygnus.com, jstern@citilnk.com
Subject: basic_string termination failure in libstdc++
Date: Sun, 21 Feb 1999 18:51:00 -0000
Message-id: <199902220251.UAA26334@foshay.citilink.com>
X-SW-Source: 1999-02/msg00669.html
Content-length: 1149

I've experienced bugs in several pieces of C++ code where
a basic_string<char> was not properly terminated with a '\0'
character.  This is true for both the last release and the
pre-release code, and I think that I have tracked down the
problem.

Several basic_string routines call versions of 'replace' to
implement their functions.  These sometimes call, other
versions, and in particular, the function

template <class charT, class traits, class Allocator>
basic_string <charT, traits, Allocator>&
basic_string <charT, traits, Allocator>::
replace (size_type pos, size_type n1, const charT* s, size_type n2)

is a key piece of the implementation.  Often it will be the
case that n2=strlen(s).  So when (pos + n2) > n1 > basic_string.length()
it is necessary to extend the string and add null termination.

I believe that the egcs implementation of this function fails to
do this, resulting in a pervasive bug.  I'm not sure whether
any other routines are also problematic.

I have verified that correcting this particular routine fixed problems
in my code.  Please let me know if this analysis is correct.

Thanks,

- Josh

jstern@citilink.com

Re: optimization bug in g77

[Mark Mitchell]

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

    Jeffrey>   In message < 36D02A11.55617BEE@moene.indiv.nluug.nl >you
    Jeffrey> write:

    >> > Mark, could you produce a patch, so that I might be able to
    >> look at > which Fortran problems that would solve ?
    >> 
    >> I went ahead and tried the following (patch against a CVS'd
    >> copy of the egcs_1_1_branch obtained a few hours ago):

Toone, I'm sorry I didn't get back to you sooner.  I was out of town
for a couple of days.

    Jeffrey> 99.9% of code will not trigger this kind of problem, we
    Jeffrey> don't want all that code to suffer because a few programs
    Jeffrey> do trigger this kind of problem.

I see your point.

    Jeffrey> For those codes which do trip the problem folks can
    Jeffrey> disable this optimization.

But, for most users, it's very difficult, if not impossible, to figure
out *what* optimization is causing the problem.  Most likely, they'll
compile a large program and find it behave unexpectedly, and just not
know why.  This reflects poorly on EGCS.

I think it's a good deal more responsible to invert your suggestion:
disable the (known to be broken) optimization by default, and then
provide an option to *enable* it.  Thus, the "power users", who want
maximum speed, can know what they're getting into: the documentation
will say explicitly that the option is, in general, known to be
unsafe.

-- 
Mark Mitchell 			mark@markmitchell.com
Mark Mitchell Consulting	http://www.markmitchell.com
>From law@hurl.cygnus.com Sun Feb 21 15:53:00 1999
From: Jeffrey A Law <law@hurl.cygnus.com>
To: mark@markmitchell.com
Cc: toon@moene.indiv.nluug.nl, egcs-bugs@cygnus.com
Subject: Re: optimization bug in g77 
Date: Sun, 21 Feb 1999 15:53:00 -0000
Message-id: <7945.919640946@hurl.cygnus.com>
In-reply-to: Your message of Sun, 21 Feb 1999 15:41:05 MST.            < 199902212341.PAA21225@adsl-206-170-148-33.dsl.pacbell.net > 
References: <199902212341.PAA21225@adsl-206-170-148-33.dsl.pacbell.net>
X-SW-Source: 1999-02/msg00664.html
Content-length: 1961

  In message < 199902212341.PAA21225@adsl-206-170-148-33.dsl.pacbell.net >you wri
te:
  >     Jeffrey> For those codes which do trip the problem folks can
  >     Jeffrey> disable this optimization.
  > 
  > But, for most users, it's very difficult, if not impossible, to figure
  > out *what* optimization is causing the problem.  Most likely, they'll
  > compile a large program and find it behave unexpectedly, and just not
  > know why.  This reflects poorly on EGCS.
Good point.  Though given that this bug has been in gcc for ~10 years now
and we've probably had less than a dozen bugs says something about how often
it triggers.  Interestingly enough, most of the problems have shown up over
the last 18 months -- because our alias analysis is getting better and our
scheduler is getting more agressive.


  > I think it's a good deal more responsible to invert your suggestion:
  > disable the (known to be broken) optimization by default, and then
  > provide an option to *enable* it.  Thus, the "power users", who want
  > maximum speed, can know what they're getting into: the documentation
  > will say explicitly that the option is, in general, known to be
  > unsafe.
I think this is a little overly conservative, but I can live with it.  
-f[no]structure-alias or something like that?  

The docs might look something like:

-fstructure-alias:
Allow the compiler to assume that a structure or array reference at a 
varying address can never conflict with a scalar reference at a fixed
address.  In the vast majority of programs this is safe, but in a small
number programs a bug in GCC's alias analysis can cause incorrect code
generation.  Thus the default is -fno-structure-alias.

This option is only found in the egcs-1.1.2 release.  egcs-1.2 and newer
releases have fixed the alias analysis bug and always assume that a
structure/array reference at a varying address can never conflict with
a scalar reference at a fixed address.

Jeff

Re: optimization bug in g77

[Jeffrey A Law]

  In message < 36D02A11.55617BEE@moene.indiv.nluug.nl >you write:

  > > Mark, could you produce a patch, so that I might be able to look at
  > > which Fortran problems that would solve ?
  > 
  > I went ahead and tried the following (patch against a CVS'd copy of the
  > egcs_1_1_branch obtained a few hours ago):
I think this is a bad thing to do.

We have enough performance issues with egcs-1.1.x.  Make it a flag (specific
to the branch).

99.9% of code will not trigger this kind of problem, we don't want all that
code to suffer because a few programs do trigger this kind of problem.

For those codes which do trip the problem folks can disable this optimization.

jeff
>From ajh8@doc.ic.ac.uk Sun Feb 21 15:04:00 1999
From: "Alastair J. Houghton" <ajh8@doc.ic.ac.uk>
To: nasser abbasi <nabbasi@pacbell.net>, EGCS-bugs <egcs-bugs@cygnus.com>
Subject: Re: missing header files for ISO C++ standard
Date: Sun, 21 Feb 1999 15:04:00 -0000
Message-id: <36D02032.937D25F9@doc.ic.ac.uk>
References: <36CFC587.1B18DE71@pacbell.net>
X-SW-Source: 1999-02/msg00661.html
Content-length: 1687

nasser abbasi wrote:
> 
> Hello,
> 
> First, thanks for your work on egcs.
> 
> I am using egcs/g++ on linux 2.0.36.
> 
> %g++ --version
> egcs-2.93.08
> 
> I have the ISO/IEC I4882  C++ standard in front of me. And I find
> that the g++ include/ is missing a number of header files according to
> the standard. This is a table of all C++ standard header files showing
> which are missing.
> 
> The following are the 12 missing headers:
> limits, new, typeinfo, exception, locale, valarray, ios, streambuf
> istream, ostream, iomanip, sstream.
> 
> The following is a complete list:
> 
> Any idea when we might get the missing header files?

As already pointed out, libstdc++ isn't completely ISO C++
compliant yet; however, you actually have a few of the
files that you complain are missing...

If you look in

  "/usr/[local/]lib/gcc-lib/<arch>/<version>/include"

(replace <arch> with e.g. i386-redhat-linux, version with
 egcs-2.93.08 in your case) you'll find that "new",
"typeinfo" and "exception" live there, and not in the
main G++ include directory (because their contents are
machine dependent). Some other files from the C library are
also stored here, for the same reason (e.g. "stdarg.h").

I don't know why you don't have "iomanip" (it's on the
machine I'm using to write this, which has an earlier
EGCS build), both with and without ".h".

The FAQ is a good place to look for information about
this sort of thing, rather than just mailing egcs-bugs.
(This is a common question it seems).

____________________________________________________________
Alastair Houghton                              ajh8@ic.ac.uk
(ISE 3)                             Imperial College, London
>From kcarlson@arsc.edu Sun Feb 21 15:15:00 1999
From: Kurt Carlson <kcarlson@arsc.edu>
To: egcs-bugs@egcs.cygnus.com
Subject: subscribe kcarlson@arsc.edu
Date: Sun, 21 Feb 1999 15:15:00 -0000
Message-id: <v03110702b2f636665646@[137.229.8.162]>
X-SW-Source: 1999-02/msg00662.html
Content-length: 235

subscribe kcarlson@arsc.edu

___________________________________________________________________
Kurt Carlson   University of Alaska, ARSC         kcarlson@arsc.edu
(907)474-5763  910 Yukon Drive, Suite 108  Fairbanks, AK 99775-6020

Re: optimization bug in g77

[Gerald Pfeifer]

On Wed, 17 Feb 1999, Toon Moene wrote:
> However, I still think that it would be useful if the c++-bugs.html page
> were turned into a general "Known Bugs" page, with subsections for the
> various languages.  Could you organize that ?

I'll take care of that early next week...

Gerald
-- 
Gerald Pfeifer (Jerry)      Vienna University of Technology
pfeifer@dbai.tuwien.ac.at   http://www.dbai.tuwien.ac.at/~pfeifer/

Re: optimization bug in g77

[Jeffrey A Law]

  In message <Pine.GSO.4.10.9902170050150.19547-100000@alphard.dbai.tuwien.ac.a
t>you write:
  > That's fine with me. Please submit such a patch. 
  > 
  > In general, we can
  >  a) rename c++-bugs.html to bugs.html and add it there;
  >  b) create a new bugs.html for everything except C++;
  >  c) create a new fortran-bugs.html.
  > 
  > Personally, I prefer both a) and b) over c), but among these two I have no
  > strong preference.
I think "a" is the way to go.

If someone wants to submit a patch to allow this optimization to be selectively
disabled via a runtime flag for the egcs-1.1.2 release, I will accept it.

jeff
>From oliva@dcc.unicamp.br Tue Feb 16 21:33:00 1999
From: Alexandre Oliva <oliva@dcc.unicamp.br>
To: "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu>
Cc: egcs-bugs@egcs.cygnus.com, egcs@egcs.cygnus.com
Subject: Re: egcs-2.93.08 19990215 sparc-sun-solaris2.5 bootstrap fails (genrecog)
Date: Tue, 16 Feb 1999 21:33:00 -0000
Message-id: <orogmt61i8.fsf@araguaia.dcc.unicamp.br>
In-reply-to: "Kaveh R. Ghazi"'s message of "Mon, 15 Feb 1999 21:35:19 -0500 (EST)"
References: <199902160235.VAA22211@caip.rutgers.edu>
X-SW-Source: 1999-02/msg00519.html
Content-length: 2042

On Feb 16, 1999, "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu> wrote:

> 	I am getting bootstrap failures on sparc's for egcs-2.93.08
> 19990215.  I initially reported an identical problem on SunOS4 with
> --enable-c-cpplib, however it occurs even with no special options.  I.e. 
> its not specific to cpplib.  Both solaris and SunOS4 have this error.

Yep, any target with strict alignment requirements should be
presenting this kind of error for code such as

#include <stdlib.h>
main() {
    char c[5];
    memset(c, 0, sizeof(c));
}

The problem is a side-effect of:

Thu Feb 11 00:08:17 1999  John Wehle  (john@feith.com)

	* function.c (assign_stack_temp_for_type): Clear best_p
	when an exact match is found.

	* i386.h (LOCAL_ALIGNMENT): Define.
	* function.c (assign_stack_local, assign_outer_stack_local): Use it.
	(assign_stack_temp_for_type): New function based on assign_stack_temp.
	(assign_stack_temp): Call it.
	(assign_temp): Use assign_stack_temp_for_type, not assign_stack_temp.
	* stmt.c: Use assign_temp, not assign_stack_temp.
	* tm.texi: Document LOCAL_ALIGNMENT.

It causes the array c to be unaligned.  This wouldn't be a problem if
the inlined version of memset() didn't assume that its argument is
properly aligned in this case.  This patch is probably also causing
slow-downs on other targets that do not reject unaligned data, just
run slower.

Reverting the patch is an obvious temporary fix, since it causes
assign_stack_temp[_for_type] to call assign_stack_local with
align==-1, so that size is rounded up and becomes properly aligned for 
sparc, but it would defeat the purpose of the patch.  So we should
probably fix the code that inlines memset() et al. so as to properly
handle such misalignments.

For your convenience, here's the relevant part of John Wehle's patch,
that should be reverted in order to bootstrap on sparc targets.

-- 
Alexandre Oliva  http://www.dcc.unicamp.br/~oliva  aoliva@{acm.org}
oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org}
Universidade Estadual de Campinas, SP, Brasil
>From scrappy@hub.org Tue Feb 16 21:42:00 1999
From: The Hermit Hacker <scrappy@hub.org>
To: craig@jcb-sc.com
Cc: egcs-bugs@cygnus.com
Subject: Re: Current CVS tree builds, but doesn't install...
Date: Tue, 16 Feb 1999 21:42:00 -0000
Message-id: <Pine.BSF.4.05.9902170141290.59717-100000@thelab.hub.org>
In-reply-to: < 19990217013221.3540.qmail@deer >
References: <19990217013221.3540.qmail@deer>
X-SW-Source: 1999-02/msg00520.html
Content-length: 1341

On 17 Feb 1999 craig@jcb-sc.com wrote:

> Try updating.  Ulrich noticed this and nicely fixed the email addresses
> I'd botched.  Don't know why I didn't realize I was edited .texi
> input when I entered the new addresses.  Anyway, as of "16 Feb 1999
> 10:46:24 -0800" the fix should be in the repository.
> 
>         tq vm, (burley)
> 
> P.S. Thanks, Ulrich!

make bootstrap as of tonight, under FreeBSD 3.0-STABLE...note that there
have been no changes to the system since my last successful 'make
bootstrap', only updated the source tree for egcs:


test x"yes" != xyes ||  /usr/dev/egcs/egcs/gcc/xgcc -B/usr/dev/egcs/egcs/gcc/ -B/usr/local/i386-unknown-freebsdelf/bin/ -c -g -O2 -fno-implicit-templates -I. -I./stl -I../libio -I./../libio -nostdinc++  -fpic stdexcepti.cc -o pic/stdexcepti.o
In file included from std/straits.h:138,
                 from std/bastring.h:36,
                 from string:6,
                 from stdexcept:36,
                 from stdexcepti.cc:8:
cwctype:6: wctype.h: No such file or directory
In file included from std/straits.h:139,
                 from std/bastring.h:36,
                 from string:6,
                 from stdexcept:36,
                 from stdexcepti.cc:8:
cwchar:6: wchar.h: No such file or directory
*** Error code 1

Stop.
*** Error code 1

Stop.
*** Error code 1

Stop.

Re: optimization bug in g77

[Toon Moene]

I wrote:

  > The point of this error is that it is in egcs-1.1.1 and a fix for
1.1.2
  > would be very welcome (as long as we do not know _what_ fixed it in
the
  > current mainline sources, it could well be a very general bug ...)

And Jeff replied:

> With egcs-1.1.x it looks like the loads associated with these 
> statements got hoisted out of the loops

>         irec(1,n)=or(i1,lshift(i2,16))                                   
>         irec(2,n)=or(i3,lshift(i4,16))                                    
>         irec(3,n)=or(i5,lshift(i6,16))                                    
>         irec(4,n)=or(i7,lshift(i8,16))                                    
>         irec(5,n)=or(i9,lshift(i10,16))                                   

> Which presumably is bad since ip & i1 are equivalenced and thus the 
> inner loop changes i1 and friends :(

> This is our old friend MEM_IN_STRUCT_P.

OK, so it *is* a very general bug.  In that case I (re)propose to open a
Web page "Known Bugs".  I have to think a bit how to formulate this such
that the average Fortran user understands what the issues are (and the
temporary workarounds, which might not be "Remove the EQUIVALENCE" -
it's not given to all our users to muck around with the sources that
way).

Compiling with -O0 seems to work ...

-- 
Toon Moene (toon@moene.indiv.nluug.nl)
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Phone: +31 346 214290; Fax: +31 346 214286
g77 Support: fortran@gnu.org; egcs: egcs-bugs@cygnus.com
>From toa@pop.agri.ch Tue Feb 16 14:34:00 1999
From: Andreas Tobler <toa@pop.agri.ch>
To: egcs-list <egcs@egcs.cygnus.com>, egcs-bugs@egcs.cygnus.com, Franz Sirl <Franz.Sirl-kernel@lauterbach.com>, John Lindal <jafl@alice.wonderland.caltech.edu>, Gary Thomas <gdt@linuxppc.org>
Subject: vtable bug again
Date: Tue, 16 Feb 1999 14:34:00 -0000
Message-id: <36C9F39B.26D2A928@pop.agri.ch>
X-SW-Source: 1999-02/msg00506.html
Content-length: 1751

I read through the mailing lists and all the subjects about vtable I read more
or less. Since 97.
My question is simple, will there be a fix for this bug in near future?
I do not know the details about this bug, means, I'm not familiar with the
effort which have to be spent. I'm a LinuxPPC user who tries to get some code
built under the latest LinuxPPC release. (right now still pre R5) In a few
weeks I expect the R5 which bases on the new glibc2. This glibc needs the
vtable as I read. So the advice to build the egcs & the libstdc++ under the
option -fno-vtable-thunks wouldn't help, since I have to build the glibc too.
And the whole SYSTEM will follow...

I'ts not my intention to blame people, but advices such as MS did to us when
we upgraded to VC++6.0 I don't need. They suggested to install another copy of
NT.??? (Situation was: we had VC++5 projects and VC++6 projects. When we did
the install of 6.0 it clutched all the important dll's in the Sys folder; they
got the same name as under VC 5.0. So a compile/debug under V5.0 wasn't
possible) 

In the meantime I spent spent lots of hours to find out that it isn't possible
to do the work I expected do solve under LinuxPCC. I don't worry to spend
hours of work when there is a solution, but when I see I can't work/come
further I feel a bit frustrated. 

Regards 
Andreas

P.S. I'm not on the bugs list... only on egcs@egcs.cygnus.com
-- 
------------------
| Andreas Tobler                                                              
 
| CH-8004 Zuerich       
| E-mail: toa@pop.agri.ch               
------------------------------------------
-- 
------------------
| Andreas Tobler								
| CH-8004 Zuerich	
| E-mail: toa@pop.agri.ch		
------------------------------------------
>From mark@markmitchell.com Tue Feb 16 14:39:00 1999
From: Mark Mitchell <mark@markmitchell.com>
To: toon@moene.indiv.nluug.nl
Cc: law@cygnus.com, egcs-bugs@cygnus.com
Subject: Re: optimization bug in g77
Date: Tue, 16 Feb 1999 14:39:00 -0000
Message-id: <199902162241.OAA17063@adsl-206-170-148-33.dsl.pacbell.net>
In-reply-to: < 36C9E5AC.39E34755@moene.indiv.nluug.nl > (message from Toon Moeneon Tue, 16 Feb 1999 22:39:56 +0100)
References: <36C9E5AC.39E34755@moene.indiv.nluug.nl> <36C9E5AC.39E34755@moene.indiv.nluug.nl>
X-SW-Source: 1999-02/msg00507.html
Content-length: 664

>>>>> "Toon" == Toon Moene <toon@moene.indiv.nluug.nl> writes:

    >> This is our old friend MEM_IN_STRUCT_P.

We could disable this optimization in 1.1.2.  It seems to be biting
reasonably many of us in nasty, hard to track down ways.  It seems to
me that saying:

  We have noticed that some optimizations in 1.1.1 were invalid, and
  have disabled them.  We have fixed the problems with these
  optimizations, so that they will be present, in corrected form, in
  1.2. 

is a better thing to tell our users as opposed to silently, knowingly,
generating bad code.

-- 
Mark Mitchell 			mark@markmitchell.com
Mark Mitchell Consulting	http://www.markmitchell.com
>From mrs@wrs.com Tue Feb 16 14:46:00 1999
From: mrs@wrs.com (Mike Stump)
To: egcs-bugs@egcs.cygnus.com, james@sublime.com.au
Cc: amacleod@cygnus.com
Subject: Re: -fno-rtti BUG Solaris/Linux
Date: Tue, 16 Feb 1999 14:46:00 -0000
Message-id: <199902162246.OAA21978@kankakee.wrs.com>
X-SW-Source: 1999-02/msg00508.html
Content-length: 994

> Date: Tue, 16 Feb 1999 15:27:12 +1100
> To: egcs-bugs@egcs.cygnus.com
> From: James Bourne <james@sublime.com.au>

> Compile the very simple program below as follows: "g++ -fno-rtti crash.cxx".
> Run it and you will get a segmentation violation. Looking at the stack back
> trace:

> #0  0x14e50 in __is_pointer (p=0x15cd8)
> #1  0x12954 in __cp_pop_exception (p=0x27670)
> #2  0x118d8 in main ()

> "When -frtti is used, rtti is used to do exception object type checking,
> when it isn't used, the encoded name for the type of the object being
> thrown is used instead."

This looks like it was broken by:

1998-10-23  Andrew MacLeod  <amacleod@cygnus.com>

	    * exception.cc (__cp_pop_exception): Free the original exception
	    value, not the potentially coerced one.

I haven't been tracking all the recent EH changes so others will have
to say if it is a design limitation.  If it is, the doc should be
updated.  It it isn't, the code should be fixed to allow -fno-rtti
-fexceptions.
>From amacleod@cygnus.com Tue Feb 16 16:00:00 1999
From: Andrew Macleod <amacleod@cygnus.com>
To: egcs-bugs@egcs.cygnus.com, james@sublime.com.au, mrs@wrs.com
Subject: Re: -fno-rtti BUG Solaris/Linux
Date: Tue, 16 Feb 1999 16:00:00 -0000
Message-id: <199902170000.QAA14897@rtl.cygnus.com>
X-SW-Source: 1999-02/msg00510.html
Content-length: 739

>> 
>> > "When -frtti is used, rtti is used to do exception object type checking,
>> > when it isn't used, the encoded name for the type of the object being
>> > thrown is used instead."
>> 
>> This looks like it was broken by:
>> 
>> 1998-10-23  Andrew MacLeod  <amacleod@cygnus.com>
>> 
>> 	    * exception.cc (__cp_pop_exception): Free the original exception
>> 	    value, not the potentially coerced one.
>> 
>> I haven't been tracking all the recent EH changes so others will have
>> to say if it is a design limitation.  If it is, the doc should be
>> updated.  It it isn't, the code should be fixed to allow -fno-rtti
>> -fexceptions.

Hmmm, thats not so good is it...  I'll take a look, it shouldn't be
broken like that. 

Andrew
>From pfeifer@dbai.tuwien.ac.at Tue Feb 16 16:00:00 1999
From: Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at>
To: Toon Moene <toon@moene.indiv.nluug.nl>
Cc: law@cygnus.com, egcs-bugs@cygnus.com
Subject: Re: optimization bug in g77
Date: Tue, 16 Feb 1999 16:00:00 -0000
Message-id: <Pine.GSO.4.10.9902170050150.19547-100000@alphard.dbai.tuwien.ac.at>
In-reply-to: < 36C9E5AC.39E34755@moene.indiv.nluug.nl >
References: <36C9E5AC.39E34755@moene.indiv.nluug.nl>
X-SW-Source: 1999-02/msg00509.html
Content-length: 592

On Tue, 16 Feb 1999, Toon Moene wrote:
> OK, so it *is* a very general bug.  In that case I (re)propose to open a
> Web page "Known Bugs". 

That's fine with me. Please submit such a patch. 

In general, we can
 a) rename c++-bugs.html to bugs.html and add it there;
 b) create a new bugs.html for everything except C++;
 c) create a new fortran-bugs.html.

Personally, I prefer both a) and b) over c), but among these two I have no
strong preference.

Gerald
-- 
Gerald Pfeifer (Jerry)      Vienna University of Technology
pfeifer@dbai.tuwien.ac.at   http://www.dbai.tuwien.ac.at/~pfeifer/

optimization bug in g77

[Steven Hancock]

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

Hi,

I hope this is the correct email address for bugs with g77 based on
egcs.  I have attached a short fortran file which demonstrates an
optimization bug with g77.

Regards,
S.Hancock
c
c
c     This file demonstrates an optimization bug with g77
c     I localized this from a finite element code which failed
c     when compiled with optimization.
c
c     To illustrate the bug:
c
c       g77 -O optbug.f
c       ./a.out
c
c     which gives the output:
c
c         file is BAD
c
c       g77  optbug.f
c       ./a.out
c
c     which gives the output:
c
c          file is GOOD
c
c     steve hancock
c     shancock@home.com
c     2-feb-99
c
c  here is the version information:
c
c---------------------------------------------------------------------------
c
c g77 version egcs-2.91.60 Debian 2.1 (egcs-1.1.1 release) (from FSF-g77 version 0.5.24-19980804)
c Driving: g77 -v -c -xf77-version /dev/null -xnone
c Reading specs from /usr/lib/gcc-lib/i486-linux/egcs-2.91.60/specs
c gcc version egcs-2.91.60 Debian 2.1 (egcs-1.1.1 release)
c /usr/lib/gcc-lib/i486-linux/egcs-2.91.60/cpp -lang-c -v -undef -D__GNUC__=2 -D__GNUC_MINOR__=91 -D__ELF__ -D__unix__ -D__i386__ -D__i386__ -D__linux__ -D__unix -D__i386 -D__linux -Asystem(posix) -D_LANGUAGE_FORTRAN -traditional -Asystem(unix) -Acpu(i386) -Amachine(i386) -Di386 -D__i386 -D__i386__ -Di486 -D__i486 -D__i486__ /dev/null /dev/null
c GNU CPP version egcs-2.91.60 Debian 2.1 (egcs-1.1.1 release) (i386 Linux/ELF)
c #include "..." search starts here:
c #include <...> search starts here:
c  /usr/local/include
c /usr/lib/gcc-lib/i486-linux/egcs-2.91.60/include
c /usr/include
c End of search list.
c /usr/lib/gcc-lib/i486-linux/egcs-2.91.60/f771 -fnull-version -quiet -dumpbase g77-version.f -version -fversion -o /tmp/cche7m43.s /dev/null
c GNU F77 version egcs-2.91.60 Debian 2.1 (egcs-1.1.1 release) (i486-linux) compiled by GNU C version egcs-2.91.60 Debian 2.1 (egcs-1.1.1 release).
c GNU Fortran Front End version 0.5.24-19980804
c as -V -Qy -o /tmp/ccSVEuVY.o /tmp/cche7m43.s
c GNU assembler version 2.9.1 (i486-linux), using BFD version 2.9.1.0.19
c ld -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -o /tmp/ccbM11iV /tmp/ccSVEuVY.o /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/gcc-lib/i486-linux/egcs-2.91.60/crtbegin.o -L/usr/lib/gcc-lib/i486-linux/egcs-2.91.60 -lg2c -lm -lgcc -lc -lgcc /usr/lib/gcc-lib/i486-linux/egcs-2.91.60/crtend.o /usr/lib/crtn.o
c /tmp/ccbM11iV
c__G77_LIBF77_VERSION__: 0.5.24
c@(#)LIBF77 VERSION 19970919
c__G77_LIBI77_VERSION__: 0.5.24-19980920
c@(#) LIBI77 VERSION pjw,dmg-mods 19980617
c__G77_LIBU77_VERSION__: 0.5.24
c@(#) LIBU77 VERSION 19980709
c
c---------------------------------------------------------------------------
      program wrbug
      common/buf3d/ji(4),ib3d,id3d(10,100),ig3d(100)
      open( unit= 9, file='tape9   ', status='unknown',
     2      form='unformatted')
c
c     setup some initial values
      ib3d = 10
      do n=1,ib3d
        do j=1,10
          id3d(j,n) = j
        enddo
      enddo
c
c     call the problem routine
      call wr3d
c
c     now test the file
      rewind 9
      call rd3d( ierr) 
      if (ierr.eq.0) then
          write(*,*) 'file is GOOD'
      else
          write(*,*) 'file is BAD'
      endif
      stop 
      end

      subroutine wr3d
c
c     this routine fails when compiled under optimization
c     it writes a blank file
c     note the equivalence statement, which may have something to
c     do with the problem
c
      integer ip(10)
      integer irec(5,100)                                               
      common/buf3d/ji(4),ib3d,id3d(10,100),ig3d(100)
      common/temp2/i1,i2,i3,i4,i5,i6,i7,i8,i9,i10
      equivalence (i1,ip)
      do 100 n=1,ib3d
         do 10 j=1,10
            ip(j)=id3d(j,n)
   10    continue
         irec(1,n)=or(i1,lshift(i2,16))                                    1
         irec(2,n)=or(i3,lshift(i4,16))                                    1
         irec(3,n)=or(i5,lshift(i6,16))                                    1
         irec(4,n)=or(i7,lshift(i8,16))                                    1
         irec(5,n)=or(i9,lshift(i10,16))                                   1
  100 continue
      write(9)irec 
      return
      end

      subroutine rd3d(ierr)
c
c     read the file back in and check it
c
      common/buf3d/ji(4),ib3d,id3d(10,100),ig3d(100)
      integer jrec(5,100) 
      integer ip(10)
      ierr=0
      read(9)jrec
      do n=1,ib3d
      ip(1)=and(jrec(1,n),65535)  
      ip(2)=and(rshift(jrec(1,n), 16),65535)                          
      ip(4)=and(rshift(jrec(2,n), 16),65535)                          
      ip(3)=and(jrec(2,n),65535)                                      
      ip(5)=and(jrec(3,n),65535)                                      
      ip(6)=and(rshift(jrec(3,n), 16),65535)                          
      ip(7)=and(jrec(4,n),65535)                                     
      ip(8)=and(rshift(jrec(4,n), 16),65535)                          
      ip(9)=and(jrec(5,n),65535)                                      
      ip(10)=and(rshift(jrec(5,n), 16),65535)                         
      do kk=1,10
      if (ip(kk).ne.id3d(kk,n)) then
         ierr=ierr+1
      endif
      enddo
      enddo
      return
      end
>From nick@jive.org Tue Feb 02 18:29:00 1999
From: Nick Rasmussen <nick@jive.org>
To: egcs-bugs@cygnus.com
Subject: Internal compiler error in egcs-1.1.1
Date: Tue, 02 Feb 1999 18:29:00 -0000
Message-id: <199902030229.UAA22583@athena.jive.org>
X-SW-Source: 1999-02/msg00039.html
Content-length: 661

The following code causes an internal compiler error in egcs-1.1.1:

-----------------------------------------

class C1
{
  public:
    C1(float foo1, float foo2) { }
};

class C2
{
  public:
    static const C1 var(0.0f, 1.0f);
};

-----------------------------------------

If the code is changed to:

-----------------------------------------

class C1
{
  public:
    C1(float foo1) { }
};

class C2
{
  public:
    static const C1 var(0.0f);
};

-----------------------------------------

g++ reports:

initializer_bug.C:10: initializer invalid for static member with constructor
initializer_bug.C:10: (you really want to initialize it separately)

-nick
>From vonbrand@sleipnir.valparaiso.cl Tue Feb 02 18:54:00 1999
From: Horst von Brand <vonbrand@sleipnir.valparaiso.cl>
To: egcs-bugs@cygnus.com, linux-kernel@vger.rutgers.edu
Subject: linux-2.2.1-ac3 and egcs-19990131
Date: Tue, 02 Feb 1999 18:54:00 -0000
Message-id: <199902030238.XAA18554@sleipnir.valparaiso.cl>
X-SW-Source: 1999-02/msg00040.html
Content-length: 1402

This combination (and probably others) won't work, since the inlining
changed. The following snippet out of net/unix/af_unix.c (heavily hacked to
reduce its size) will inline skb_put() under egcs-1999012, but not under
19990131. I assume the kernel source isn't quite right, as it assumes that
functions declared "extern inline" will always be inlined with -O2
-fomit-frame-pointer, and no real function is being provided anywhere for
linking to. OTOH, it declares functions inline so they _will_ be inlined
for performance.

I've been away for some time, and can't take up the lists just now. So if
this has already been discussed to death, sorry.

struct iovec;

extern int memcpy_fromiovec(unsigned char *kdata, struct iovec *iov, int len);

struct sk_buff {
	unsigned int 	len;			 
	unsigned char	*tail;			 
	unsigned char 	*end;			 
};

extern __inline__ unsigned char *skb_put(struct sk_buff *skb, unsigned int len)
{
	unsigned char *tmp=skb->tail;
	skb->tail+=len;
	skb->len+=len;
	if(skb->tail>skb->end)
	{
		__label__ here; 
		skb_over_panic(skb, len, &&here); 
here:		;
	}
	return tmp;
}
static int unix_dgram_sendmsg(struct iovec *msg_iov, int len)
{
	struct sk_buff *skb;

        memcpy_fromiovec(skb_put(skb,len), msg_iov, len);
}
-- 
Horst von Brand                             vonbrand@sleipnir.valparaiso.cl
Casilla 9G, Viña del Mar, Chile                               +56 32 672616
>From law@hurl.cygnus.com Tue Feb 02 19:07:00 1999
From: Jeffrey A Law <law@hurl.cygnus.com>
To: Horst von Brand <vonbrand@sleipnir.valparaiso.cl>
Cc: egcs-bugs@cygnus.com, linux-kernel@vger.rutgers.edu
Subject: Re: linux-2.2.1-ac3 and egcs-19990131 
Date: Tue, 02 Feb 1999 19:07:00 -0000
Message-id: <9374.918011016@hurl.cygnus.com>
In-reply-to: Your message of Tue, 02 Feb 1999 23:38:13 MST.            < 199902030238.XAA18554@sleipnir.valparaiso.cl > 
References: <199902030238.XAA18554@sleipnir.valparaiso.cl>
X-SW-Source: 1999-02/msg00041.html
Content-length: 1023

  In message < 199902030238.XAA18554@sleipnir.valparaiso.cl >you write:
  > This combination (and probably others) won't work, since the inlining
  > changed. The following snippet out of net/unix/af_unix.c (heavily hacked to
  > reduce its size) will inline skb_put() under egcs-1999012, but not under
  > 19990131. I assume the kernel source isn't quite right, as it assumes that
  > functions declared "extern inline" will always be inlined with -O2
  > -fomit-frame-pointer, and no real function is being provided anywhere for
  > linking to. OTOH, it declares functions inline so they _will_ be inlined
  > for performance.
  > 
  > I've been away for some time, and can't take up the lists just now. So if
  > this has already been discussed to death, sorry.
It's an issue rth and davem are on the hook for dealing with.

It's not strictly correct for any function to assume that specifying "inline"
will force the function to be inlined.  That may or may not change depending
on what rth & davem decide to do.

jeff
>From k_fukui@highway.ne.jp Tue Feb 02 19:08:00 1999
From: Kaoru Fukui <k_fukui@highway.ne.jp>
To: egcs-bugs@cygnus.com
Subject: egcs-2.93.04  which compile fail with egcs-2.93.04
Date: Tue, 02 Feb 1999 19:08:00 -0000
Message-id: <19990203120643.Postino-030652@smtp01.highway.ne.jp>
X-SW-Source: 1999-02/msg00042.html
Content-length: 1317

Hi!
Fisrt time I have success compileing egcs-2.93.04 with egcs-1.1.1.
But I could not compile egcs-2.03.04 useing with the egcs-2.93.04.
The egcs-2.93.4  is downloaded from cvs.
Jeff,do you know the problem?

My system is glibc-2.0.112
Binutils-2.9.1.0.19a on Mklinux.

Kaoru Fukui
Thanks

gcc  -DIN_GCC -DHAIFA    -O2 -fsigned-char  -DHAVE_CONFIG_H    -I. -I/usr/src/
redhat/BUILD/egcs/gcc -I/usr/src/redhat/BUILD/egcs/gcc/config -I/usr/src/redhat/
BUILD/egcs/gcc/../include -c insn-opinit.c
gcc -c  -DIN_GCC -DHAIFA    -O2 -fsigned-char  -DHAVE_CONFIG_H    -I. -I/usr/
src/redhat/BUILD/egcs/gcc -I/usr/src/redhat/BUILD/egcs/gcc/config -I/usr/src/
redhat/BUILD/egcs/gcc/../include /usr/src/redhat/BUILD/egcs/gcc/genrecog.c
gcc  -DIN_GCC -DHAIFA    -O2 -fsigned-char  -DHAVE_CONFIG_H  -o genrecog \
 genrecog.o rtl.o bitmap.o print-rtl.o ` case "obstack.o" in ?*) echo obstack.o ;
; esac ` ` case "" in ?*) echo  ;; esac ` ` case "" in ?*) echo  ;; esac `  
` case "" in ?*) echo  ;; esac ` ` case "" in ?*) echo  ;; esac ` 
./genrecog /usr/src/redhat/BUILD/egcs/gcc/config/rs6000/rs6000.md > tmp-recog.c
make[1]: *** [s-recog] Error 139
make[1]: Leaving directory `/usr/src/redhat/BUILD/obj-ppc-linux/gcc'
make: *** [all-gcc] Error 2
Bad exit status from /var/tmp/rpm-tmp.30335 (%build)
[root@localhost SPECS]#