Re: c++/1692: -fvtable-gc flag is only meaningful on ELF targets

Re: c++/1692: -fvtable-gc flag is only meaningful on ELF targets

[lerdsuwa]

Synopsis: -fvtable-gc flag is only meaningful on ELF targets

State-Changed-From-To: open->closed
State-Changed-By: lerdsuwa
State-Changed-When: Sun Aug 12 09:29:49 2001
State-Changed-Why:
    -fvtable-gc is no longer supported.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=1692&database=gcc

Re: c++/1692: -fvtable-gc flag is only meaningful on ELF targets

[lerdsuwa]

Synopsis: -fvtable-gc flag is only meaningful on ELF targets

State-Changed-From-To: closed->analyzed
State-Changed-By: lerdsuwa
State-Changed-When: Mon Aug 13 00:46:03 2001
State-Changed-Why:
    The bug report is reopened.  The option is only disable
    for the branch.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=1692&database=gcc

Re: c++/1692: -fvtable-gc flag is only meaningful on ELF targets

[Gabriel Dos Reis]

The following reply was made to PR c++/1692; it has been noted by GNATS.

From: Gabriel Dos Reis <gdr@codesourcery.com>
To: "Joseph S. Myers" <jsm28@cam.ac.uk>
Cc: <lerdsuwa@gcc.gnu.org>, <gcc-bugs@gcc.gnu.org>, <gcc-gnats@gcc.gnu.org>,
   <richard.earnshaw@arm.com>
Subject: Re: c++/1692: -fvtable-gc flag is only meaningful on ELF targets
Date: 12 Aug 2001 19:32:19 +0200

 "Joseph S. Myers" <jsm28@cam.ac.uk> writes:
 
 | As a general matter, checking all PRs closed
 | against both 3.0 and 3.1 might help find some regressions now rather than
 | later.)
 
 Furthermore, a corresponding testcase should be entererd in GCC's
 testsuite, if possible.  That helps spotting regressions.
 
 -- Gaby
 CodeSourcery, LLC                       http://www.codesourcery.com
  

Re: c++/1692: -fvtable-gc flag is only meaningful on ELF targets

[Joseph S. Myers]

The following reply was made to PR c++/1692; it has been noted by GNATS.

From: "Joseph S. Myers" <jsm28@cam.ac.uk>
To: <lerdsuwa@gcc.gnu.org>
Cc: <gcc-bugs@gcc.gnu.org>,  <gcc-gnats@gcc.gnu.org>, 
     <richard.earnshaw@arm.com>
Subject: Re: c++/1692: -fvtable-gc flag is only meaningful on ELF targets
Date: Sun, 12 Aug 2001 18:18:42 +0100 (BST)

 On 12 Aug 2001 lerdsuwa@gcc.gnu.org wrote:
 
 >     -fvtable-gc is no longer supported.
 
 Where did that idea come from?  I thought it had been implemented on the
 mainline, but removed on the branch because it hadn't been implemented
 then.
 
 (In general, don't close mainline bugs on the basis of a fix in 3.0 unless
 the mainline is fixed as well - I suppose this PR predates the branch, but
 when someone reports a bug against post-branch mainline the relevant tree
 to look for a fix in is the mainline, not 3.0 - even though a fix in 3.0
 may be usefule as well.  As a general matter, checking all PRs closed
 against both 3.0 and 3.1 might help find some regressions now rather than
 later.)
 
 -- 
 Joseph S. Myers
 jsm28@cam.ac.uk
 

c++/1692: -fvtable-gc flag is only meaningful on ELF targets

[Richard Earnshaw]

>Number:         1692
>Category:       c++
>Synopsis:       -fvtable-gc flag is only meaningful on ELF targets
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Jan 18 03:16:02 PST 2001
>Closed-Date:
>Last-Modified:
>Originator:     Richard Earnshaw
>Release:        2.97 20010116 (experimental)
>Organization:
ARM
>Environment:
System: NetBSD shark1 1.5H NetBSD 1.5H (SHARK) #57: Mon Oct 30 17:12:12 GMT 2000 rearnsha@shark1:/usr/src/sys/arch/arm32/compile/SHARK arm32


	
host: arm-unknown-netbsd
build: arm-unknown-netbsd
target: arm-unknown-netbsd
configured with: /home/rearnsha/gnusrc/egcs/configure --with-gcc-version-trigger=/home/rearnsha/gnusrc/egcs/gcc/version.c --host=arm-netbsd --prefix=/work/rearnsha/gnu/install --disable-checking
>Description:
	The flag -fvtable-gc in the c++ front-end causes the compiler to emit
	.vtable_inherit and .vtable_entry directives into the assembler file.
	However, these directives are 
	1) Specific to gas
	2) Specific only to ELF targets

	This causes testsuite/g++.dg/vtgc1.C to fail on any non-elf platform
	
>How-To-Repeat:
	Run the aforementioned test on any non-elf platform.
	
>Fix:
	1) We should disable the above test if the target is not known to
	use ELF format; we should probably also XFAIL if we can't guarantee
	use of GAS as the assembler.
	2) We should diagnose use of -fvtable-gc in circumstances where we
	can't assume that we are using gas on an ELF platform, since at
	preseent we generate confusing diagnostics from the assembler.

	See g++.other/crash18.C which filters out some (but not all) of the 
	failing machines.
	
>Release-Note:
>Audit-Trail:
>Unformatted:
>From lucier@math.purdue.edu Sun Apr 01 00:00:00 2001
From: lucier@math.purdue.edu
To: gcc-gnats@gcc.gnu.org
Cc: feeley@iro.umontreal.ca
Subject: optimization/1831: -fprofile-arcs and -fbranch-probabilities don't get along
Date: Sun, 01 Apr 2001 00:00:00 -0000
Message-id: <20010201180633.17740.qmail@sourceware.cygnus.com>
X-SW-Source: 2001-q1/msg00856.html
Content-length: 2646

>Number:         1831
>Category:       optimization
>Synopsis:       -fprofile-arcs and -fbranch-probabilities don't get along
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Feb 01 10:16:00 PST 2001
>Closed-Date:
>Last-Modified:
>Originator:     B. Lucier
>Release:        2.97 20010126
>Organization:
>Environment:
alphaev6-unknown-linux-gnu
>Description:
The machine-generated code I run has a lot of checks
for rarely-occuring conditions (like stack and heap overflows,
interrupt-handlers, etc.), and often complex logic,
so I thought that I would try profile-directed compilation.

That didn't work so well.  Without any computed gotos,
I get

popov-305% gcc -W -Wall -Wno-unused -O2 -mieee -fno-math-errno -D___SINGLE_HOST -fprofile-arcs -ftest-coverage -o reverse reverse.c reverse_.c -lgambc -lm -ldl
popov-307% ./reverse -:m100000
(time (do ((i 0 (+ i 1))) ((= i 100) (void)) (%which (l) (%reverse data l))))
    212 ms real time
    212 ms cpu time (211 user, 1 system)
    no collections
    96263408 bytes allocated
    no minor faults
    no major faults
popov-310% gcc -W -Wall -Wno-unused -O2 -mieee -fno-math-errno -D___SINGLE_HOST -fbranch-probabilities -o reverse reverse.c reverse_.c -lgambc -lm -ldl
reverse.c: In function `___H__20_reverse':
reverse.c:8175: warning: Arc profiling: some edge counts were bad.
reverse.c: At top level:
reverse.c:9061: warning: .da file contents not exhausted
popov-311% !./
./reverse -:m100000
(time (do ((i 0 (+ i 1))) ((= i 100) (void)) (%which (l) (%reverse data l))))
    183 ms real time
    183 ms cpu time (183 user, 0 system)
    no collections
    96263408 bytes allocated
    no minor faults
    no major faults
popov-313% gcc -W -Wall -Wno-unused -O2 -mieee -fno-math-errno -D___SINGLE_HOST  -o reverse reverse.c reverse_.c -lgambc -lm -ldl -save-temps
popov-314% ./reverse -:m100000
(time (do ((i 0 (+ i 1))) ((= i 100) (void)) (%which (l) (%reverse data l))))
    177 ms real time
    178 ms cpu time (178 user, 0 system)
    no collections
    96263408 bytes allocated
    no minor faults
    no major faults

So

1.  gcc -fbranch-probabilities doesn't seem to handle the
    output of previous runs of -fprofile-arcs.

2.  Code compiled with -O2 -fbranch-probabilities runs more
    slowly than code compiled with -O2.

Coupled with the fact that gcc + gcov can't handle
computed goto's, this whole -profile-arcs thing is
nowhere near as useful as it might be.

Brad Lucier
>How-To-Repeat:

>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted:
>From jdennett@gcc.gnu.org Sun Apr 01 00:00:00 2001
From: jdennett@gcc.gnu.org
To: nobody@gcc.gnu.org
Cc: gcc-prs@gcc.gnu.org
Subject: Re: c++/158
Date: Sun, 01 Apr 2001 00:00:00 -0000
Message-id: <20010218162601.24593.qmail@sourceware.cygnus.com>
X-SW-Source: 2001-q1/msg01443.html
Content-length: 642

The following reply was made to PR c++/158; it has been noted by GNATS.

From: jdennett@gcc.gnu.org
To: dvv@egcs.dvv.ru, gcc-gnats@gcc.gnu.org,
  martin@loewis.home.cs.tu-berlin.de, nobody@gcc.gnu.org
Cc:  
Subject: Re: c++/158
Date: 18 Feb 2001 16:16:26 -0000

 Synopsis: weird stuff with pointers to members, casts
 
 State-Changed-From-To: analyzed->closed
 State-Changed-By: jdennett
 State-Changed-When: Sun Feb 18 08:16:26 2001
 State-Changed-Why:
     f is called once only with 
     gcc version 3.0 20010218 (prerelease).
     In other words, the bug is fixed.
 
 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=158&database=gcc