public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* Re: optimization bug in g77
@ 1999-02-16 13:43 Toon Moene
  1999-02-28 23:30 ` Mark Mitchell
  1999-02-28 23:30 ` Gerald Pfeifer
  0 siblings, 2 replies; 27+ messages in thread
From: Toon Moene @ 1999-02-16 13:43 UTC (permalink / raw)
  To: law, egcs-bugs

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/


^ permalink raw reply	[flat|nested] 27+ messages in thread
* Optimization Bug in g77
@ 2004-10-26 19:01 Steven E. Williamson
  2004-10-26 19:04 ` Andrew Pinski
  0 siblings, 1 reply; 27+ messages in thread
From: Steven E. Williamson @ 2004-10-26 19:01 UTC (permalink / raw)
  To: gcc-bugs

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


^ permalink raw reply	[flat|nested] 27+ messages in thread
* Optimization Bug in g77
@ 2004-10-24  3:42 Steven E. Williamson
  0 siblings, 0 replies; 27+ messages in thread
From: Steven E. Williamson @ 2004-10-24  3:42 UTC (permalink / raw)
  To: bug-gcc

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


^ permalink raw reply	[flat|nested] 27+ messages in thread
* Re: optimization bug in g77
@ 1999-02-28 23:30 Toon Moene
  1999-02-28 23:30 ` Toon Moene
  0 siblings, 1 reply; 27+ messages in thread
From: Toon Moene @ 1999-02-28 23:30 UTC (permalink / raw)
  To: Mark Mitchell, law, egcs-bugs

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


^ permalink raw reply	[flat|nested] 27+ messages in thread
* Re: optimization bug in g77
@ 1999-02-22 18:57 Mike Stump
  1999-02-23 12:10 ` Toon Moene
  0 siblings, 1 reply; 27+ messages in thread
From: Mike Stump @ 1999-02-22 18:57 UTC (permalink / raw)
  To: law, mark; +Cc: egcs-bugs, toon

> 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


^ permalink raw reply	[flat|nested] 27+ messages in thread
* optimization bug in g77
@ 1999-02-02 17:54 Steven Hancock
  1999-02-28 23:30 ` craig
  0 siblings, 1 reply; 27+ messages in thread
From: Steven Hancock @ 1999-02-02 17:54 UTC (permalink / raw)
  To: egcs-bugs

[-- 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]# 




^ permalink raw reply	[flat|nested] 27+ messages in thread
end of thread, other threads:[~2004-10-26 20:00 UTC | newest]

Thread overview: 27+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1999-02-16 13:43 optimization bug in g77 Toon Moene
1999-02-28 23:30 ` Mark Mitchell
1999-02-28 23:30 ` Gerald Pfeifer
     [not found]   ` < Pine.GSO.4.10.9902170050150.19547-100000@alphard.dbai.tuwien.ac.at >
1999-02-16 20:09     ` Jeffrey A Law
1999-02-28 23:30   ` Toon Moene
     [not found]     ` < 36CB2719.2F75D9B7@moene.indiv.nluug.nl >
1999-02-19  9:30       ` Gerald Pfeifer
  -- strict thread matches above, loose matches on Subject: below --
2004-10-26 19:01 Optimization Bug " Steven E. Williamson
2004-10-26 19:04 ` Andrew Pinski
2004-10-26 20:00   ` Steven E. Williamson
2004-10-24  3:42 Steven E. Williamson
1999-02-28 23:30 optimization bug " Toon Moene
1999-02-28 23:30 ` Toon Moene
     [not found]   ` < 36D02A11.55617BEE@moene.indiv.nluug.nl >
1999-02-21 14:13     ` Jeffrey A Law
     [not found]       ` < 7542.919635144@hurl.cygnus.com >
1999-02-21 15:38         ` Mark Mitchell
1999-02-22 15:28           ` Toon Moene
1999-02-28 23:30           ` Jeffrey A Law
     [not found]             ` < 7945.919640946@hurl.cygnus.com >
1999-02-21 16:15               ` Mark Mitchell
1999-02-28 23:30                 ` Jeffrey A Law
1999-02-22 18:57 Mike Stump
1999-02-23 12:10 ` Toon Moene
1999-02-02 17:54 Steven Hancock
1999-02-28 23:30 ` craig
1999-02-28 23:30   ` Toon Moene
1999-02-28 23:30     ` Jeffrey A Law
1999-02-28 23:30       ` Toon Moene
1999-02-28 23:30         ` Jeffrey A Law
1999-02-28 23:30         ` Jeffrey A Law

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).