[Bug preprocessor/24202] [4.0/4.1 Regression] Segfault with #pragma once
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-10-08 13:37 --- *** Bug 24271 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||lothar at tradescape dot biz http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24202 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[Bug c++/24272] strange link error with ACE
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-08 13:42 --- *** This bug has been marked as a duplicate of 19664 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24272 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Comment #69 from pinskia at gcc dot gnu dot org 2005-10-08 13:42 --- *** Bug 24272 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||lothar at tradescape dot biz http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: INSTALLING gcc (and ZOPE) on DEBIAN
[EMAIL PROTECTED] writes: > > > I want to install ZOPE server on my debian OP. Since the CMS that I want to > use requires the ZOPE VERSION 2.7.5 I cannot use the "apt-get install Zope" - > method because it is always version 2.6 installed. > That is why I think that I will have to install ZOPE from sources - is this > true? apt-get install zope2.7 apt-get install zope2.8 'apt-cache -n search zope' is your friend. > Whenever I try to install ZOPE 2.7.5 through "configure - make - make > install", there is always the following error message: > > > command 'gcc' failed with exit status 1 > > -basherror:: command not found > > Why is gcc not preinstalled on DEBIAN? Do I have to install it on my own? you didn't tell the installer that it should be installed (there is a development task or something like this). > Do you have any instructions how to install gcc on DEBIAN? apt-get install gcc apt-get install build-essential -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processed: bug 332683 is forwarded to http://gcc.gnu.org/PR23711 ..., tagging 332683
Processing commands for [EMAIL PROTECTED]: > # Automatically generated email from bts, devscripts version 2.9.7 > forwarded 332683 http://gcc.gnu.org/PR23711 Bug#332683: gcc-snapshot - fails to build Noted your statement that Bug has been forwarded to http://gcc.gnu.org/PR23711. > retitle 332683 [PR 23711] [4.1 regression] [s390] bootstrap error in libjava > (ICE in fixup_eh_region_note) Bug#332683: gcc-snapshot - fails to build Changed Bug title. > tags 332683 upstream fixed-upstream Bug#332683: [PR 23711] [4.1 regression] [s390] bootstrap error in libjava (ICE in fixup_eh_region_note) There were no tags set. Tags added: upstream, fixed-upstream > End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
nature of GOT bugs (was Re: Please reenable GCJ on mips
Thanks *very much* for your help explaining this mess. Thiemo Seufer wrote: > - A too large object file can overflow plain GOT. This is not only > MIPS-specific, it affects several architecture's toolchains, Right, it would affect any architecture which does silly things like having a 16-bit limit for GOT indices. > and > was exposed pre-sarge (IIRC most virulently on sparc) by a > broken/deficient libtool which relinked things into a single huge > object file. > libtool was fixed, and the remaining cases (like a huge blob of > generated C code for python bindings) learned to split the C > source to some smaller pieces, which also helped link speed. > For MIPS, and if the need arises, this could be worked around by > using XGOT, but see below. The real fix would be a MultiGOT > extension to the object format, which is possible in a downward > compatible way but not implemented yet. From your description, I take it this does not apply to shared libraries or executables, only to individual .o files? So there is a MultiGOT extension to the specification for shared libraries and executables, but not for intermediate object files? :-O (Or... see below for my other hypothesis.) > > - MultiGOT works fine, until the limit of 16k _dynamic_ symbols is > hit. A executable/library with larger exported GOT will build > without warning but will cause ld.so to segfault. This is the main > bug, and hard to debug (a statically built gdb may help here). Okay. Is this considered * a bug in the MultiGOT specification -- no specification for how to handle more than 16k global symbols properly on MIPS * or a bug in ld.so -- inability to handle correctly specified multiple GOTs for more than 16k global symbols From your description I'm guessing this one is the case. In which case it's a bug in *glibc* which isn't in glibc Bugzilla. Which is understandable considering how new glibc Bugzilla is. * Or is this actually an artifact of the first problem? Perhaps MultiGOT uses trickery to allow symbols within a single executable or shared library to work -- because they aren't externally visible, they can use whatever convention ld sees fit -- but it can't be used at an interface boundary, because there's not actually a real specification for it. In this case an actual MultiGOT extension to the executable/library format would solve the problem. But wait -- that doesn't make sense. *This* bug does not appear to hit anyone but MIPS. That means that everyone else knows how to advertise more than 16k of exported symbols in a library. (Or that there's something funny about the MIPS ABI which causes it to require the export of a lot more symbols than anyone else requires.) > - XGOT and MultiGOT are mutually exclusive, because the MultiGOT >handling ignores XGOT relocations. This is arguably not a bug, >since MultiGOT is supposed to supersede XGOT. It is arguably a bug, I guess, that MultiGOT does not in actual fact supersede XGOT, failing in significant cases where XGOT works. :-P
Re: Please reenable GCJ on mips
On Fri, Oct 07, 2005 at 05:39:26PM +0200, Thiemo Seufer wrote: > We have for MIPS: > > - The plain GOT mode, where a GOT has a maximum size of 2^16 byte, > with 16k symbols. > > - The XGOT mode, with unlimited (2^32 byte) size, which increases > code size by 15-20%, and reduces perfomance accordingly. > > - MultiGOT, which creates several GOTs in a single binary for the > final link, but uses only one GOT for imports/exports. The object > files still have only plain GOT. > > MultiGOT is supposed to be the current best solution, and XGOT is > supposed to be obsoleted by it. Normally plain GOT is used, and the > linker switches to MultiGOT in the final link if the GOT grows too > big. Yes. > - MultiGOT works fine, until the limit of 16k _dynamic_ symbols is > hit. A executable/library with larger exported GOT will build > without warning but will cause ld.so to segfault. This is the main > bug, and hard to debug (a statically built gdb may help here). > This hits currently (at least) the gcj shared library runtime, > the ghc executable, and libgklayout.so in mozilla*. A workaround > involving XGOT is possible in some cases, and was done for the > mozillae (and some others, grepping for -xgot in build logs seems > to be the most reliable way to find them all). Dynamically linked > executables/shared libraries with any of the different internal GOT > models are freely mixable. If you'll give me an explicit testcase, I will volunteer to debug this for you; I have lots of practice debugging ld.so. Is this really the main bug at this point? I.E. multigot binaries not working rather than not linking? -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processing of gcc-snapshot_20051008-1_i386.changes
gcc-snapshot_20051008-1_i386.changes uploaded successfully to localhost along with the files: gcc-snapshot_20051008-1.dsc gcc-snapshot_20051008.orig.tar.gz gcc-snapshot_20051008-1.diff.gz gcc-snapshot_20051008-1_i386.deb Greetings, Your Debian queue daemon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
gcc-snapshot_20051008-1_i386.changes REJECTED
Rejected: gcc-snapshot_20051008-1_i386.deb: has 3358 file(s) with a time stamp too far into the future (e.g. usr/lib/gcc-snapshot/include/c++/4.1.0/gnu/java/io/PlatformHelper.h [Sat Oct 8 22:28:42 2005]). === If you don't understand why your files were rejected, or if the override file requires editing, reply to this email. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Please reenable GCJ on mips
Daniel Jacobowitz wrote: [snip] > > - MultiGOT works fine, until the limit of 16k _dynamic_ symbols is > > hit. A executable/library with larger exported GOT will build > > without warning but will cause ld.so to segfault. This is the main > > bug, and hard to debug (a statically built gdb may help here). > > This hits currently (at least) the gcj shared library runtime, > > the ghc executable, and libgklayout.so in mozilla*. A workaround > > involving XGOT is possible in some cases, and was done for the > > mozillae (and some others, grepping for -xgot in build logs seems > > to be the most reliable way to find them all). Dynamically linked > > executables/shared libraries with any of the different internal GOT > > models are freely mixable. > > If you'll give me an explicit testcase, I will volunteer to debug this > for you; I have lots of practice debugging ld.so. Unfortunately the "testcase" is mozilla's libgklayout.so, Which isn't exactly handy. I'll try to come up with something better the next days. > Is this really the > main bug at this point? I.E. multigot binaries not working rather than > not linking? It was that way the last time I looked. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Please reenable GCJ on mips
On Sat, Oct 08, 2005 at 09:11:05PM +0200, Thiemo Seufer wrote: > Daniel Jacobowitz wrote: > [snip] > > > - MultiGOT works fine, until the limit of 16k _dynamic_ symbols is > > > hit. A executable/library with larger exported GOT will build > > > without warning but will cause ld.so to segfault. This is the main > > > bug, and hard to debug (a statically built gdb may help here). > > > This hits currently (at least) the gcj shared library runtime, > > > the ghc executable, and libgklayout.so in mozilla*. A workaround > > > involving XGOT is possible in some cases, and was done for the > > > mozillae (and some others, grepping for -xgot in build logs seems > > > to be the most reliable way to find them all). Dynamically linked > > > executables/shared libraries with any of the different internal GOT > > > models are freely mixable. > > > > If you'll give me an explicit testcase, I will volunteer to debug this > > for you; I have lots of practice debugging ld.so. > > Unfortunately the "testcase" is mozilla's libgklayout.so, Which isn't > exactly handy. I'll try to come up with something better the next days. It'll do if you can tell me exactly how to reproduce the problem; I never volunteered to look at this before because I didn't have a Debian/MIPS setup, but now I do. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Please reenable GCJ on mips
On Sat, Oct 08, 2005 at 03:18:23PM -0400, Nathanael Nerode wrote: > What I keep hearing is that no one has reported the bug(s), and nobody except > Thiemo Seufer has even described it/them adequately. This is a bug or bugs > which is not documented in the documentation or bug databases for glibc, > binutils, gcc, Debian, or anywhere else. It's apparently a substantial and > reproducible bug which hits any library or executable with really large > numbers of exported symbols. The GCC documentation suggests a fix (xgot) > which doesn't actually work. No, Nathanael, this is not what you keep _hearing_. It's what you keep _saying_. I'm aware that you seem to spend a lot of time listening to yourself and I've gotten quite tired of hearing you repeat yourself. It doesn't have a clear entry in any bugzilla because there's a lot of confusion over various bits of (A) whether particular things are bugs, or (B) whose bugs they are. But the people who have encountered it, which is not limited strictly to Thiemo obviously, are familiar with the problem. > Now, I understand this sort of stuff not being dealt with for a while. But > the nature of the problem has supposedly been known for a year or more, and > so a little documentation of "known limitations" is really the least I'd > expect. It's free software. You're welcome to figure out the problem, preferably with less insulting the reviewers, and submit a patch to the documentation. > m68k is known to be in a situation where serious toolchain bugs are not > reported upstream. I thought previously that it was the only such > architecture. I'm pretty sure this has been reported upstream. It's not in the bug tracking system upstream. That's not the same thing. Who do you think would fix it? Hint, probably me or Thiemo. No one else has been interested in working on this stuff in the past. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Please reenable GCJ on mips
Daniel Jacobowitz wrote: > It's a lot of work to fix and no one has done it. That's not the same > thing at all. That's nice, but there's still a real problem unrelated to that. An example of a relatively healthy bug which is "a lot of work to fix and no one has done it" is http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6257, the problem of distinguishing between #include and #include in C++ programs and getting the collection of included symbols correct for both cases. There's a fairly substantial amount of information on the problems and attempted solutions. Another example is http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5911 -- the screwball way Ada is built in GCC -- where the work to fix it is totally straightforward, but very large and very tedious. What I keep hearing is that no one has reported the bug(s), and nobody except Thiemo Seufer has even described it/them adequately. This is a bug or bugs which is not documented in the documentation or bug databases for glibc, binutils, gcc, Debian, or anywhere else. It's apparently a substantial and reproducible bug which hits any library or executable with really large numbers of exported symbols. The GCC documentation suggests a fix (xgot) which doesn't actually work. That is bad. * Either ld or gcc (or both) should note in its documentation that xgot is incompatible with multigot. Alternatively, there should be a bug report against ld because of this. I haven't determined which is considered correct yet. * The failure of multigot to support >16K of exported symbols is a bug somewhere, but I'm still not clear whether it's an ABI limitation or or a bug in the dynamic linker. If the latter, it needs to be reported. If the former, it needs to be documented. Now, I understand this sort of stuff not being dealt with for a while. But the nature of the problem has supposedly been known for a year or more, and so a little documentation of "known limitations" is really the least I'd expect. m68k is known to be in a situation where serious toolchain bugs are not reported upstream. I thought previously that it was the only such architecture. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: nature of GOT bugs (was Re: Please reenable GCJ on mips
Nathanael Nerode wrote: > Thanks *very much* for your help explaining this mess. > > Thiemo Seufer wrote: > > - A too large object file can overflow plain GOT. This is not only > > MIPS-specific, it affects several architecture's toolchains, > Right, it would affect any architecture which does silly things like having a > 16-bit limit for GOT indices. > > > and > > was exposed pre-sarge (IIRC most virulently on sparc) by a > > broken/deficient libtool which relinked things into a single huge > > object file. > > libtool was fixed, and the remaining cases (like a huge blob of > > generated C code for python bindings) learned to split the C > > source to some smaller pieces, which also helped link speed. > > For MIPS, and if the need arises, this could be worked around by > > using XGOT, but see below. The real fix would be a MultiGOT > > extension to the object format, which is possible in a downward > > compatible way but not implemented yet. > From your description, I take it this does not apply to shared libraries or > executables, only to individual .o files? So there is a MultiGOT extension > to the specification for shared libraries and executables, but not for > intermediate object files? Yes. > :-O (Or... see below for my other hypothesis.) No need for hypotheses. > > > - MultiGOT works fine, until the limit of 16k _dynamic_ symbols is > > hit. A executable/library with larger exported GOT will build > > without warning but will cause ld.so to segfault. This is the main > > bug, and hard to debug (a statically built gdb may help here). > Okay. > > Is this considered > * a bug in the MultiGOT specification -- no specification for how to handle > more than 16k global symbols properly on MIPS No. > * or a bug in ld.so -- inability to handle correctly specified multiple GOTs > for more than 16k global symbols That (it shouldn't segfault), and/or potentially also a bug in ld which leads to failure for large MultiGOT binaries. > From your description I'm guessing this one is the case. In which case it's > a > bug in *glibc* which isn't in glibc Bugzilla. Which is understandable > considering how new glibc Bugzilla is. > > * Or is this actually an artifact of the first problem? No. It is limited to dynamic symbols. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
latest version of gcc?
Dear All, Which is the latest version of gcc available to debian via apt-get? The gcc.gnu.org site indicates that the latest gcc is 4.0.2 whereas if I apt-get install gcc I get that 3.3.5 is the latest version. I'm not actually hung up about having the latest version. I'm trying to learn how to write and compile modules but I'm getting errors even in hello world programs. I just want to be sure that I'm not using a compiler that's too old. Regards, M. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[Bug preprocessor/24202] [4.0/4.1 Regression] Segfault with #pragma once
--- Comment #7 from janis at gcc dot gnu dot org 2005-10-08 22:10 --- A regression test identified this patch from Neil on 2003-08-02 as thene start of failures: http://gcc.gnu.org/ml/gcc-cvs/2003-08/msg00093.html -- janis at gcc dot gnu dot org changed: What|Removed |Added CC||neil at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24202 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[Bug preprocessor/24202] [4.0/4.1 Regression] Segfault with #pragma once
--- Comment #8 from janis at gcc dot gnu dot org 2005-10-08 22:11 --- Hmm, "regression test" in the last comment should have been "regression hunt". -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24202 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Results for 4.0.2 (Debian 4.0.2-2) testsuite on m68k-unknown-linux-gnu
LAST_UPDATED: Sat Oct 1 13:51:09 UTC 2005 Native configuration is m68k-unknown-linux-gnu === g++ tests === Running target unix FAIL: g++.dg/abi/bitfield4.C execution test FAIL: g++.dg/eh/omit-frame-pointer2.C execution test FAIL: g++.dg/eh/registers1.C execution test FAIL: g++.dg/ext/visibility/noPLT.C scan-assembler-not [EMAIL PROTECTED] FAIL: g++.dg/opt/eh2.C execution test FAIL: g++.old-deja/g++.eh/ia64-1.C execution test XPASS: g++.old-deja/g++.other/init5.C execution test === g++ Summary === # of expected passes11034 # of unexpected failures6 # of unexpected successes 1 # of expected failures 68 # of unsupported tests 92 /home/doko/gcc/gcc-4.0-4.0.2/build/gcc/testsuite/../g++ version 4.0.2 (Debian 4.0.2-2) === gcc tests === Running target unix WARNING: program timed out. FAIL: gcc.c-torture/compile/20001226-1.c -O1 (test for excess errors) WARNING: program timed out. FAIL: gcc.c-torture/compile/20001226-1.c -O2 (test for excess errors) WARNING: program timed out. FAIL: gcc.c-torture/compile/20001226-1.c -O3 -fomit-frame-pointer (test for excess errors) WARNING: program timed out. FAIL: gcc.c-torture/compile/20001226-1.c -O3 -g (test for excess errors) WARNING: program timed out. FAIL: gcc.c-torture/compile/20001226-1.c -Os (test for excess errors) FAIL: gcc.c-torture/execute/20020418-1.c execution, -O1 FAIL: gcc.c-torture/execute/20020418-1.c execution, -O2 FAIL: gcc.c-torture/execute/20020418-1.c execution, -Os FAIL: gcc.c-torture/execute/ashldi-1.c execution, -O0 FAIL: gcc.c-torture/execute/ashrdi-1.c execution, -O0 FAIL: gcc.c-torture/execute/builtin-bitops-1.c execution, -O0 FAIL: gcc.c-torture/execute/loop-2f.c execution, -O0 FAIL: gcc.c-torture/execute/loop-2f.c execution, -O1 FAIL: gcc.c-torture/execute/loop-2f.c execution, -O2 FAIL: gcc.c-torture/execute/loop-2f.c execution, -O3 -fomit-frame-pointer FAIL: gcc.c-torture/execute/loop-2f.c execution, -O3 -fomit-frame-pointer -funroll-loops FAIL: gcc.c-torture/execute/loop-2f.c execution, -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions FAIL: gcc.c-torture/execute/loop-2f.c execution, -O3 -g FAIL: gcc.c-torture/execute/loop-2f.c execution, -Os FAIL: gcc.c-torture/execute/loop-2g.c execution, -O0 FAIL: gcc.c-torture/execute/loop-2g.c execution, -O1 FAIL: gcc.c-torture/execute/loop-2g.c execution, -O2 FAIL: gcc.c-torture/execute/loop-2g.c execution, -O3 -fomit-frame-pointer FAIL: gcc.c-torture/execute/loop-2g.c execution, -O3 -fomit-frame-pointer -funroll-loops FAIL: gcc.c-torture/execute/loop-2g.c execution, -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions FAIL: gcc.c-torture/execute/loop-2g.c execution, -O3 -g FAIL: gcc.c-torture/execute/loop-2g.c execution, -Os FAIL: gcc.c-torture/execute/lshrdi-1.c execution, -O0 FAIL: gcc.c-torture/execute/pr17377.c execution, -O3 -fomit-frame-pointer FAIL: gcc.c-torture/execute/ieee/copysign1.c execution, -O0 FAIL: gcc.c-torture/execute/ieee/copysign1.c execution, -O1 FAIL: gcc.c-torture/execute/ieee/copysign1.c execution, -O2 FAIL: gcc.c-torture/execute/ieee/copysign1.c execution, -O3 -fomit-frame-pointer FAIL: gcc.c-torture/execute/ieee/copysign1.c execution, -O3 -fomit-frame-pointer -funroll-loops FAIL: gcc.c-torture/execute/ieee/copysign1.c execution, -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions FAIL: gcc.c-torture/execute/ieee/copysign1.c execution, -O3 -g FAIL: gcc.c-torture/execute/ieee/copysign1.c execution, -Os FAIL: gcc.c-torture/execute/ieee/copysign2.c execution, -O0 FAIL: gcc.c-torture/execute/ieee/copysign2.c execution, -O1 FAIL: gcc.c-torture/execute/ieee/copysign2.c execution, -O2 FAIL: gcc.c-torture/execute/ieee/copysign2.c execution, -O3 -fomit-frame-pointer FAIL: gcc.c-torture/execute/ieee/copysign2.c execution, -O3 -fomit-frame-pointer -funroll-loops FAIL: gcc.c-torture/execute/ieee/copysign2.c execution, -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions FAIL: gcc.c-torture/execute/ieee/copysign2.c execution, -O3 -g FAIL: gcc.c-torture/execute/ieee/copysign2.c execution, -Os FAIL: gcc.c-torture/execute/ieee/mul-subnormal-single-1.c execution, -O0 FAIL: gcc.c-torture/execute/ieee/mul-subnormal-single-1.c execution, -O1 FAIL: gcc.c-torture/execute/ieee/mul-subnormal-single-1.c execution, -O2 FAIL: gcc.c-torture/execute/ieee/mul-subnormal-single-1.c execution, -O3 -fomit-frame-pointer FAIL: gcc.c-torture/execute/ieee/mul-subnormal-single-1.c execution, -O3 -fomit-frame-pointer -funroll-loops FAIL: gcc.c-torture/execute/ieee/mul-subnormal-single-1.c execution, -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions FAIL: gcc.c-torture/execute/ieee/mul-subnormal-single-1.c execution, -O3 -g FAIL: gcc.c-torture/execute/ieee/mul-subnormal-single-1.c execution, -Os FAIL: gcc.dg/bitfld-3.c execution test FAIL: gcc.
