public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
* Re: c++/1692: -fvtable-gc flag is only meaningful on ELF targets
@ 2001-08-12 10:26 Joseph S. Myers
0 siblings, 0 replies; 5+ messages in thread
From: Joseph S. Myers @ 2001-08-12 10:26 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: c++/1692: -fvtable-gc flag is only meaningful on ELF targets
@ 2001-08-13 0:46 lerdsuwa
0 siblings, 0 replies; 5+ messages in thread
From: lerdsuwa @ 2001-08-13 0:46 UTC (permalink / raw)
To: gcc-bugs, gcc-prs, nobody, richard.earnshaw
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: c++/1692: -fvtable-gc flag is only meaningful on ELF targets
@ 2001-08-12 10:36 Gabriel Dos Reis
0 siblings, 0 replies; 5+ messages in thread
From: Gabriel Dos Reis @ 2001-08-12 10:36 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: c++/1692: -fvtable-gc flag is only meaningful on ELF targets
@ 2001-08-12 9:29 lerdsuwa
0 siblings, 0 replies; 5+ messages in thread
From: lerdsuwa @ 2001-08-12 9:29 UTC (permalink / raw)
To: gcc-bugs, gcc-prs, nobody, richard.earnshaw
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* c++/1692: -fvtable-gc flag is only meaningful on ELF targets
@ 2001-04-01 0:00 Richard Earnshaw
0 siblings, 0 replies; 5+ messages in thread
From: Richard Earnshaw @ 2001-04-01 0:00 UTC (permalink / raw)
To: gcc-gnats
>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
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2001-08-13 0:46 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-08-12 10:26 c++/1692: -fvtable-gc flag is only meaningful on ELF targets Joseph S. Myers
-- strict thread matches above, loose matches on Subject: below --
2001-08-13 0:46 lerdsuwa
2001-08-12 10:36 Gabriel Dos Reis
2001-08-12 9:29 lerdsuwa
2001-04-01 0:00 Richard Earnshaw
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).