[Bug bootstrap/39572] x86_64-*-openbsd* is not supported yet
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39572 --- Comment #4 from Rob rob1weld at aol dot com 2012-09-08 15:17:11 UTC --- Thank you, one and all.
[Bug inline-asm/38804] libgcj multilib fails if not able to exec non native programs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38804 --- Comment #13 from Rob rob1weld at aol dot com 2011-07-24 19:19:22 UTC --- (In reply to comment #12) It has always been the case that configure needs to be able to execute code for all multilibs. If you have a target where this is not possible (like Solaris or IRIX), you need to configure with --disable-multilibs (or on some targets restrict the set of multilibs built). This has nothing to do with libgcj, but affects most target libraries. A documentation issue probably. Rainer It has been over 2 and a half years since the Post prior to yours. A lot has changed since then (I don't think we compile LibJava anymore and we now have (proper) 64-Bit support for this Platform). As long as the Docs are up to date (assuming 64-Bit Compile is working) then this Bug could be closed. I've been waiting to get a Bulldozer running before I contribute here further as my current Computer is too old to be of much help here. I expect to be back in 6 months.
[Bug libmudflap/38738] libmudflap could be enabled for Solaris when using GNU ld
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38738 --- Comment #8 from Rob rob1weld at aol dot com 2011-06-28 06:18:04 UTC --- Thanks for FIXing, every little bit helps. Rob
[Bug middle-end/28734] gather stats vs PCH
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28734 Rob rob1weld at aol dot com changed: What|Removed |Added CC||rob1weld at aol dot com --- Comment #10 from Rob rob1weld at aol dot com 2011-01-19 04:36:37 UTC --- (In reply to comment #3) Can you attach the preprocessed testcase as this is most likely this is a bug still? The source in the Testsuite Directory contains an error (misnamed file) which when corrected will allow gcc to compile correctly. It is the File Not Found error that causes the ICE and NOT an error in the Testsuite source itself. If you alter the Source to correct it then the ICE goes away. This message suggests that this Bug still occurs on the Trunk and purports a Fix: http://readlist.com/lists/gcc.gnu.org/gcc/8/41545.html I get this Bug on a preRelease SVN version: # /usr/local/gcc-4_5-branch_build/gcc/xgcc -v Using built-in specs. COLLECT_GCC=/usr/local/gcc-4_5-branch_build/gcc/xgcc Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4_5-branch/configure --enable-multiarch --enable-nls --with-tls --enable-static --enable-shared --enable-plugin --enable-lto --enable-linker-build-id --with-system-zlib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-stage1-checking=release --enable-checking=release --enable-gather-detailed-mem-stats --enable-libssp --enable-libmudflap --enable-libgomp --enable-decimal-float --enable-languages=c,c++,ada Thread model: posix gcc version 4.5.3 20110117 (prerelease) [gcc-4_5-branch revision 168886] (GCC) # uname -a Linux debian 2.6.32-5-amd64 #1 SMP Wed Jan 12 05:14:59 UTC 2011 x86_64 GNU/Linux # cat /usr/local/gcc-4_5-branch/gcc/testsuite/gcc.dg/pch/common-1.c #include common-1.h int foo2 = 3; int zz = 2; # cat /usr/local/gcc-4_5-branch/gcc/testsuite/gcc.dg/pch/common-1.hs static int foo1 = 9; int foo2; extern int zz; If I edit a copy of common-1.c and include common-1.hs (instead of common-1.h) then the ICE does not occur (so no preprocessed source included). Here is a small portion of gcc.log: PASS: gcc.dg/noncompile/voidparam-1.c -O2 -fwhopr (test for excess errors) testcase /usr/local/gcc-4_5-branch/gcc/testsuite/gcc.dg/noncompile/noncompile.exp completed in 54 seconds Running /usr/local/gcc-4_5-branch/gcc/testsuite/gcc.dg/pch/pch.exp ... Executing on host: /usr/local/gcc-4_5-branch_build/gcc/xgcc -B/usr/local/gcc-4_5-branch_build/gcc/ ./common-1.h -O0 -g -m32 -o common-1.h.gch(timeout = 300) spawn /usr/local/gcc-4_5-branch_build/gcc/xgcc -B/usr/local/gcc-4_5-branch_build/gcc/ ./common-1.h -O0 -g -m32 -o common-1.h.gch PASS: ./common-1.h -O0 -g (test for excess errors) Executing on host: /usr/local/gcc-4_5-branch_build/gcc/xgcc -B/usr/local/gcc-4_5-branch_build/gcc/ /usr/local/gcc-4_5-branch/gcc/testsuite/gcc.dg/pch/common-1.c -O0 -g -I. -S -m32 -o common-1.s(timeout = 300) spawn /usr/local/gcc-4_5-branch_build/gcc/xgcc -B/usr/local/gcc-4_5-branch_build/gcc/ /usr/local/gcc-4_5-branch/gcc/testsuite/gcc.dg/pch/common-1.c -O0 -g -I. -S -m32 -o common-1.s /usr/local/gcc-4_5-branch/gcc/testsuite/gcc.dg/pch/common-1.c:3:1: internal compiler error: in ggc_record_overhead, at ggc-common.c:939 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. compiler exited with status 1 output is: /usr/local/gcc-4_5-branch/gcc/testsuite/gcc.dg/pch/common-1.c:3:1: internal compiler error: in ggc_record_overhead, at ggc-common.c:939 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. FAIL: gcc.dg/pch/common-1.c -O0 -g -I. (internal compiler error) FAIL: gcc.dg/pch/common-1.c -O0 -g -I. (test for excess errors) Excess errors: /usr/local/gcc-4_5-branch/gcc/testsuite/gcc.dg/pch/common-1.c:3:1: internal compiler error: in ggc_record_overhead, at ggc-common.c:939 assembly file 'common-1.s' missing FAIL: gcc.dg/pch/common-1.c -O0 -g assembly comparison Executing on host: /usr/local/gcc-4_5-branch_build/gcc/xgcc -B/usr/local/gcc-4_5-branch_build/gcc/ ./common-1.h-O0-m32 -o common-1.h.gch(timeout = 300) spawn /usr/local/gcc-4_5-branch_build/gcc/xgcc -B/usr/local/gcc-4_5-branch_build/gcc/ ./common-1.h -O0 -m32 -o common-1.h.gch PASS: ./common-1.h -O0 (test for excess errors) Executing on host: /usr/local/gcc-4_5-branch_build/gcc/xgcc -B/usr/local/gcc-4_5-branch_build/gcc/ /usr/local/gcc-4_5-branch/gcc/testsuite/gcc.dg/pch/common-1.c-O0 -I. -S -m32 -o common-1.s(timeout = 300) spawn /usr/local/gcc-4_5-branch_build/gcc/xgcc -B/usr/local/gcc-4_5-branch_build/gcc/ /usr/local/gcc-4_5-branch/gcc/testsuite/gcc.dg/pch/common-1.c -O0 -I. -S -m32 -o common-1.s /usr/local/gcc-4_5-branch/gcc/testsuite/gcc.dg/pch/common-1.c:3:1: internal compiler error: in ggc_record_overhead
[Bug libstdc++/41816] ldconfig warnings vs. libstdc++.so.6.0.14-gdb.py
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41816 Rob rob1weld at aol dot com changed: What|Removed |Added CC||rob1weld at aol dot com --- Comment #5 from Rob rob1weld at aol dot com 2011-01-09 03:23:40 UTC --- (In reply to comment #4) would it be possible to get a configure flag specifying where to install these files, which we could then set to gdb's auto-load directory? Google has a tough time with the search string unless you break it up since _some_ WebPages add spaces between various parts of the string. (EG: / usr / local / lib / libstdc + +. so.6.0.14-gdb.py). There is this (as best I can tell from the translation) suggested fix: Korean - English: http://translate.google.ca/translate?hl=ensl=kou=http://lunatine.springnote.com/pages/6524343ei=PCcpTanIOITWtQOU18H9Bgsa=Xoi=translatect=resultresnum=1ved=0CB4Q7gEwAAprev=/search%3Fq%3D%2522/usr/local/lib/libstdc%252B%252B.so.6.0.14-gdb.py%2522%2BGDB%2B7.2%2Binstallation%26hl%3Den%26biw%3D1177%26bih%3D764%26prmd%3Divns Origonal URL: http://lunatine.springnote.com/pages/6524343 Rob
[Bug preprocessor/39213] [4.4/4.5/4.6 regression] Preprocessor ICE with -m64 and --traditional-cpp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39213 --- Comment #22 from Rob rob1weld at aol dot com 2011-01-05 16:26:43 UTC --- (In reply to comment #21) At long last. It was only 2 years... I have some older than that. Thank you for your work on my Bug Report, Rob
[Bug testsuite/39655] autogen fixinclude test FAILURES - trunk revision 145337
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39655 Rob rob1weld at aol dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #3 from Rob rob1weld at aol dot com 2010-12-22 04:09:22 UTC --- Thanks Ralf, this being fixed I shall close it. Rob
[Bug testsuite/38946] [4.4/4.5/4.6 Regression] gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously
--- Comment #37 from rob1weld at aol dot com 2010-07-23 08:43 --- (In reply to comment #31) Please refrain from fiddling with the bug status: whoever does the backport will do this himself. Thanks. Rainer I have no interest in your posts and have marked your emails to me as SPAM. Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38946
[Bug bootstrap/39150] Configure scripts have no 64-Bit Solaris defined (only i386-solaris*).
--- Comment #19 from rob1weld at aol dot com 2010-07-22 11:50 --- (In reply to comment #10) Adding an additional 64-bit default configuration (like amd64-pc-solaris2* or whatever) doubles the testing burden on me for no real benefit. In fact, I believe that the sparcv9-sun-solaris2 configurations were a mistake and should be removed, rather than adding this for Solaris 2/x86, too. While the advantages of sparc64-sun-solaris2.* are limited, I don't think we should remove it now since it can handle more memory and 64-bit computing is becoming the norm. Similarly, I think adding a 64-bit compiler on x86 would be desirable. And it would be faster than the 32-bit one because of the 64-bit ABI. As a matter of fact, we already have the few required patches at AdaCore. Eric, here were my results when I tried a year and a half ago. Not too bad, actually fairly good for a first attempt: http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg01526.html Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39150
[Bug bootstrap/39150] Configure scripts have no 64-Bit Solaris defined (only i386-solaris*).
--- Comment #18 from rob1weld at aol dot com 2010-07-21 23:17 --- (In reply to comment #17) Subject: Re: Configure scripts have no 64-Bit Solaris defined (only i386-solaris*). --- Comment #16 from rob1weld at aol dot com 2010-07-20 19:02 --- (In reply to comment #15) (In reply to comment #13) OpenSolaris recently added support for the ARM Processor, so that adds a few more 'multi-lib modes' that need to be supported, along with the expanded line True, but irrelevant: each port only supports the multilibs it needs, and not several different configurations with each from the set of multilibs becoming the default. Arm has thumb, and not, and either endian. It is not irrelevant and we do understand you don't want the extra work - even reading the prior posts in this thread. Noted. of SPARC Processors now being supported. The OpenSolaris Group also has a 'call for Ports', so in theory our mechanism _must_ be general enough to support any possible Processor ... The mechanism is, of course. If it were, we (meaning more people than only you and I) would not be debating this. Additional note for this RFE (which _might_ get re-opened, someday): OpenSolaris now runs on mips-sun-solaris2.11 http://hub.opensolaris.org/bin/view/Project+mips/Tools Far from it: there are minimal binutils and gcc patches yet, nothing more. Rainer More for you to do ;) . We wish you all the best, happy programming. Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39150
[Bug testsuite/38946] [4.4/4.5/4.6 Regression] gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously
--- Comment #30 from rob1weld at aol dot com 2010-07-20 18:46 --- (In reply to comment #28) Subject: Bug 38946 Author: jvdelisle Date: Fri Jun 25 21:32:37 2010 New Revision: 161416 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161416 Log: 2010-06-25 Jerry DeLisle jvdeli...@gcc.gnu.org PR testsuite/38946 * gfortran.dg/array_constructor_23.f: Update test to allow for small error in comparing reals. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/array_constructor_23.f Thanks for fixing the Trunk, when http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38946#c29 is complete I (or someone else) will close this Bug. Rob -- rob1weld at aol dot com changed: What|Removed |Added Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38946
[Bug bootstrap/39150] Configure scripts have no 64-Bit Solaris defined (only i386-solaris*).
--- Comment #16 from rob1weld at aol dot com 2010-07-20 19:02 --- (In reply to comment #15) (In reply to comment #13) Subject: Re: Configure scripts have no 64-Bit Solaris defined (only i386-solaris*). --- Comment #12 from rob1weld at aol dot com 2010-05-04 07:20 --- This is an Enhancement (EG: I wish (someday in the future) that we had this feature) and I would have preferred it remain open ... ... OpenSolaris recently added support for the ARM Processor, so that adds a few more 'multi-lib modes' that need to be supported, along with the expanded line of SPARC Processors now being supported. The OpenSolaris Group also has a 'call for Ports', so in theory our mechanism _must_ be general enough to support any possible Processor ... ... Rob Additional note for this RFE (which _might_ get re-opened, someday): OpenSolaris now runs on mips-sun-solaris2.11 http://hub.opensolaris.org/bin/view/Project+mips/Tools Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39150
[Bug tree-optimization/36281] vector code is not parallelized
--- Comment #3 from rob1weld at aol dot com 2010-07-19 08:25 --- ... this does not get parallelized at all ... Also see 34501 Perhaps we could make some use of Pluto. It is a fully automatic (C to OpenMP C) parallelizer that makes code amenable to auto-vectorization. http://pluto-compiler.sourceforge.net/ Also see these Parallelizers: http://cri.ensmp.fr/pips/ or http://pips4u.org/ There was something I found a few days ago from here that I can no longer locate http://en.wikipedia.org/wiki/Automatic_parallelization It would be great to take that inner loop (if it were much larger) and 'Kernelize' it for co-processing on our Graphics Card. We could expand GCCs 'x-parallelize-x' and threading options to automatically find the sweeter spots to offload for co=processing (on a GPU, using OpenCL). Barra - NVIDIA G80 GPU Functional Simulator http://gpgpu.univ-perp.fr/index.php/Barra If we were 'allowed' to call a post-processor (like LTO used to do) we could call ATI's GPU SDK which supports OpenCL and outputs code BOTH to x86 and it's own GPUs. Commercial Projects: Auto-parallelizer and SIMDinator by Dalsoft http://www.dalsoft.com/documentation_simdinator.html NVidia's PTX http://en.wikipedia.org/wiki/Parallel_Thread_Execution Cray's work with LLVM http://llvm.org/devmtg/2009-10/Greene_180k_Cores.pdf Larrabee http://www.drdobbs.com/architecture-and-design/216402188?pgno=5 Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36281
[Bug testsuite/32062] Some MASKs aren't sufficient in certain sse4_1 tests
--- Comment #10 from rob1weld at aol dot com 2010-07-16 14:31 --- (In reply to comment #7) Subject: Bug 32062 Author: hjl Date: Thu May 24 14:12:18 2007 New Revision: 125025 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125025 Log: 2007-05-24 H.J. Lu hongjiu...@intel.com PR testsuite/32062 * gcc.target/i386/sse4_1-check.h (MASK): New. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/i386/sse4_1-check.h Here is a link to a Library from AMD that allows SSE5 for everyone: http://sseplus.sourceforge.net/ Thanks, Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32062
[Bug preprocessor/39213] [4.4/4.5/4.6 regression] Preprocessor ICE with -m64 and --traditional-cpp
--- Comment #9 from rob1weld at aol dot com 2010-07-14 17:27 --- Thanks for working on this guys, Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39213
[Bug testsuite/38946] [4.4/4.5/4.6 Regression] gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously
--- Comment #20 from rob1weld at aol dot com 2010-06-20 02:05 --- (In reply to comment #16) Confirmed: fails for 32-bit and Solaris 10+, unsupported on Solaris 8 and 9. Thanks for looking into this, Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38946
[Bug preprocessor/39213] Regression [3.4.3] Preprocessor ICE with -m64 and --traditional-cpp
--- Comment #2 from rob1weld at aol dot com 2010-06-20 02:10 --- (In reply to comment #1) Fails on 64-bit Solaris 10, 11/SPARC, too. Tossing Regression onto the Summary, thanks for confirming, Rob -- rob1weld at aol dot com changed: What|Removed |Added Summary|Preprocessor ICE with -m64 |Regression [3.4.3] |and --traditional-cpp |Preprocessor ICE with -m64 ||and --traditional-cpp http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39213
[Bug bootstrap/39150] Configure scripts have no 64-Bit Solaris defined (only i386-solaris*).
--- Comment #15 from rob1weld at aol dot com 2010-05-17 02:34 --- (In reply to comment #13) Subject: Re: Configure scripts have no 64-Bit Solaris defined (only i386-solaris*). --- Comment #12 from rob1weld at aol dot com 2010-05-04 07:20 --- This is an Enhancement (EG: I wish (someday in the future) that we had this feature) and I would have preferred it remain open ... But what's the *point* of having such a configuration, except as a prove of `we can do that'? Any actual problem that would be solved this way? Rainer (In reply to comment #13) Same as on Linux: the compiler will be faster and able to handle more memory. OpenSolaris is 64 Bit; it's ability to run on older Hardware is a convenience, not a requirement. Similarly gcc could output 80286 / 80387 code ONLY, for Intel Platforms, as that would be easier also ... Support for both modes (and more to come) is not so much proof we can do that as it is the normal thing (compared to other Platforms) to do. The inability of the Build Mechanism to operate in a similar manner (logic) as it does on Linux is support of a third way of building gcc rather than proof that doing it one way is easier. OpenSolaris recently added support for the ARM Processor, so that adds a few more 'multi-lib modes' that need to be supported, along with the expanded line of SPARC Processors now being supported. The OpenSolaris Group also has a 'call for Ports', so in theory our mechanism _must_ be general enough to support any possible Processor (in the future, you don't need to do everything today!). I would be more than happy to request from Oracle a gcc Team be created and dispatched here. The result of a successful request _might_ be a tiny Team of experts (OS Design / Compiler Writers) that would assist with Testing, Patching, Solaris Expertise, and bring with them an assignment to a share of the Server Farm. They have such a Liaison for most larger Programs and supported Hardware. I can foresee one or two getting assigned and a half dozen or so volunteer when they hear of your hardship (... rather the time it takes to analyze and fix problems. This is practically doubled if you have two different configurations to test, and I simply cannot afford that ...). Do one of you wish to ask or shall I ? (Note: It might take 3-6 months to get approved as some may be paid; so lets get started). Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39150
[Bug libgcj/39161] gcc 4.4.0 20090210 - The 'copy-vmresources.sh' script can't find the 'mkinstalldirs' script.
--- Comment #7 from rob1weld at aol dot com 2010-05-04 06:37 --- Rainer Orth Please try this with an absolute path to configure. Perhaps we should simply document that relative paths aren't supported here. Rainer, I noticed this is marked as Waiting. If it is waiting for the Reporter (me) then the Bug is over one year old and I do not save a backups past one year. Rob -- rob1weld at aol dot com changed: What|Removed |Added Status|WAITING |UNCONFIRMED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39161
[Bug target/38924] gcc 4.4.0 20090117 - init_priority incorrect for GNU ld in gcc/config/sol2.h
--- Comment #5 from rob1weld at aol dot com 2010-05-04 06:52 --- Rainer: Fixed for 4.5.0. Thanks to our Solaris Expert for fixing that. It is (was) great fun to have to build (at least we used to, have to) gcc with both GNU's ld and Sun's to ensure there is (was) no breakage. Recently I was able to use only GNU's ld (except when trying to build _some_ of Sun's Source), which cut down on ifdef'ing (uglifying) patches. Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38924
[Bug boehm-gc/37017] Using --enable-threads=solaris breaks near end of build in boehm-gc configury
--- Comment #6 from rob1weld at aol dot com 2010-05-04 07:00 --- Unless there are very important reasons (and I don't see any since the underlying libthread and libpthread implementation on Solaris 2 is identical, just the interfaces differ), please stick with the default, posix. _My_ reasons to test it for the gcc group was that --enable-threads=solaris _was_ a legal configuration option and so I tested it and made a BR. My reasons were set out in comments 2 and 4, I have nothing to add. This is now documented in install.texi to deter people who think they should use solaris on Solaris 2. Thanks for fixing the DOCs, can we pull the code too (or ifdef it out for OpenSolaris) to avoid having code in gcc that is no longer supported. Rob -- rob1weld at aol dot com changed: What|Removed |Added Status|WAITING |UNCONFIRMED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37017
[Bug bootstrap/39111] gcc 4.4.0 20090204 - Configury from GNU linker to Operating System's Linker broke (reverse works OK)
--- Comment #8 from rob1weld at aol dot com 2010-05-04 07:05 --- As I've said before: please file *clear individual bug reports* for each single issue you find. Dealing with reports like this, with dozens of issues and non- issues mixed, is close to impossible. I'll stick with comment #1 describes the Bug. Further comments were workarounds and to report a Flag Day on the Sun Linker. Rob -- rob1weld at aol dot com changed: What|Removed |Added Status|WAITING |UNCONFIRMED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39111
[Bug bootstrap/39150] Configure scripts have no 64-Bit Solaris defined (only i386-solaris*).
--- Comment #12 from rob1weld at aol dot com 2010-05-04 07:20 --- ... the time it takes to analyze and fix problems. This is practically doubled if you have two different configurations to test, and I simply cannot afford that, given that this is a spare-time activity. That's why I'm even opposed to take patches, since than I'm forced to deal with issues as well. We hear you on that. This is an Enhancement (EG: I wish (someday in the future) that we had this feature) and I would have preferred it remain open until the need for the feature exceeded the lack of available time to implement it (as Eric pointed out we may cross that line shortly). I can settle for this being re-opening in the future and will accept WONTFIX for now, (since it would be a fair bit of work to get everything working correctly). Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39150
[Bug target/32180] Paranoia UCB GSL TestFloat libm tests fail - accuracy of recent gcc math poor
--- Comment #26 from rob1weld at aol dot com 2010-04-12 01:54 --- (In reply to comment #25) I understand that this is INVALID because all the points raised by comment #21. If crlibm is better than what we have, but we cannot use it, it is the same as if it didn't exist. It is possible to use various other Programs (or Libraries with a bit of programming) and run them seperately on a test script to check that both programs give the same result. We could compile and run 'crlibm' (and some other programs) _without_ incorporating it's code into gcc and compare the results of the two Programs with each other using 'diff' . Doing the above is useful for _testing_ but ultimatley we should either 'fix' our code to use the default flags (so the math is not broken) _or_ use the flags that I suggested as the defaults and avoid the problem altogether. We could (but do not have to) use a different math Library. The existance of other code that works correctly proves that we could write our own code differently (properly) and have correct results instead of insisting that we can only have a wrong result and that we should accept it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32180
[Bug testsuite/31846] Logs are not being parsed correctly by testsuite and test_summary scripts.
--- Comment #5 from rob1weld at aol dot com 2010-04-12 02:23 --- (In reply to comment #4) Rob, this is very old. Is it still a problem? Thank you kindly for being the one to reply to my Report. Due to the fact that it often takes a year for some replies, and in this case three years, I am working with another group that is producing a free Operating System rather than sitting idle. It is _great_ of you to go through these old reports and try to close (resolve) them. I have done that job previously and know that sometimes it can be frustrating. Some three years later we might expect I am unable to assist further and might focus my efforts where they are more productive. Thanks, Rob Reporter: Changing status from Waiting to New (since I can not choose Old) and you are welcome to change the Resolution to Wontfix (since you can not choose Abandoned). :) -- rob1weld at aol dot com changed: What|Removed |Added Status|WAITING |UNCONFIRMED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31846
[Bug libobjc/30445] Fix for FIXME in gcc-4_2-branch/libobjc/Makefile.in
--- Comment #10 from rob1weld at aol dot com 2010-03-25 10:29 --- (In reply to comment #9) I don't think you have any bug. Enjoy your DLL! Thanks for fixing this _2_ year old Bug. GCC 4.2.x (especially 4.2.1) is an important version of our compiler since: * It is able to compile most of the old (Andrew might say poorly written, pre-Standard) C++ source that is over a few years old -- IE: Most C++, except recently written (and especially GCC ;) available on the Internet ). * It works fairly well -- _Some_ of the _months_ showed very few Bugs (with only a rare bad day) in User-submitted Test Reports. * Many patches, Operating System Driver Code (Debian), plug-ins, etc. were written for non-bleeding-edge GCC and would need porting. So yes the Bug is 2 years old but I _really_ appreciate you fixing it and wanted to make this extra effort to thank you as we close this one out. Thanks, Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30445
[Bug tree-optimization/38816] graphite undocumented
--- Comment #2 from rob1weld at aol dot com 2009-10-16 10:46 --- Thanks, Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38816
[Bug middle-end/40028] RFE - Add GPU acceleration library to gcc
--- Comment #4 from rob1weld at aol dot com 2009-10-07 11:21 --- (In reply to comment #1) Yes GPU libraries would be nice but this needs a lot of work to begin with. First you have to support the GPUs. This also amounts to doubling the support. If you really want them, since this is open source, start contributing. Here is a contribution from my buds at NVidia ... Quote from the Article: ... support for native execution of C++. For the first time in history, a GPU can run C++ code with no major issues or performance penalties ... nVidia GT300's Fermi architecture unveiled: 512 cores, up to 6GB GDDR5 http://www.brightsideofnews.com/news/2009/9/30/nvidia-gt300s-fermi-architecture-unveiled-512-cores2c-up-to-6gb-gddr5.aspx That should be more than 3/4 of the job done; only took 6 months. Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40028
[Bug bootstrap/39316] [lto] revision 144454 - Configure should check for elf support (similar to gmp/mpfr/PPL/CLooG)
--- Comment #6 from rob1weld at aol dot com 2009-10-04 10:25 --- (In reply to comment #5) I see. This particular issue should be fixed as libelf and the clone from elfutils use different SONAMEs and the configure test in GCC checks for the actual features it uses with a link test. The only thing that may happen is that with broken installations (headers from one lib, shared library from the other) things will break and we'd need to run a test program to detect this weird case. It is my Request for Enhancement that the 'Configury' detect if there is enough elf support to build gcc - in a similar manner that gmp, mpfr, PPL and CLooG are tested for. ... I suggest that gmp, mpfr, PPL, CLooG and LTOable ELF all use similar configury to check that each will work correctly with GCC _WHEN_ we later get to the portion of the build that actually uses the feature. The similar configury can each call a different snippet of code (obviously) to test that _whatever_ the configure script thinks it has detected will actually compile a program that will execute and produce an expected result. Program code that can only be compiled (without warnings or errors) but are not executable should be maked as compilable but not executable (for cross compiling). _IF_ we can not get whatever we thought we detected to compile we need to signal this in the _FIRST_ configure script and _not_ leave it to be discovered by some configure script that get ran 3/4 though the build days later, that is annoying and happens too frequently. Richard, if you are closing this can you post the Changelog for this BR. Thanks, Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39316
[Bug lto/39276] [lto] - Testsuite gcc.log shows many getconf: Invalid argument (_NPROCESSORS_ONLN)
--- Comment #12 from rob1weld at aol dot com 2009-09-25 23:58 --- (In reply to comment #11) Fixed. Thanks, Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39276
[Bug lto/39279] [lto] - Werror in ../lto_trunk/gcc/lto/lto.c
--- Comment #4 from rob1weld at aol dot com 2009-07-17 06:43 --- (In reply to comment #2) Confirmed. The proposed fix is not correct, though, as the type of the first argument to munmap _is_ void* according to POSIX. Thanks for applying the patch. I've not looked at 'LTO' source in a few months, we could 'cast in the other direction' (fix everything else), but I imagine _we_ had a reason not to fix this properly ... People need to test their code on a few versions of GCC (3.4.x 4.x.x). Thanks Ben Rainer, Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39279
[Bug middle-end/40028] RFE - Add GPU acceleration library to gcc
--- Comment #3 from rob1weld at aol dot com 2009-05-20 13:10 --- Some of the newest cards will run at over a PetaFLOP ... I meant a TeraFLOP :( . -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40028
[Bug middle-end/40028] RFE - Add GPU acceleration library to gcc
--- Comment #2 from rob1weld at aol dot com 2009-05-18 17:36 --- (In reply to comment #1) Yes GPU libraries would be nice but this needs a lot of work to begin with. First you have to support the GPUs. This also amounts to doubling the support. If you really want them, since this is open source, start contributing. I'm planning a full hardware upgrade in the coming months. I plan to get an expensive Graphics Card to try this. Some of the newest cards will run at over a PetaFLOP (only for embarrassingly parallel code - http://en.wikipedia.org/wiki/Embarrassingly_parallel ). Some of the newest Motherboards will accept _FOUR_ Graphics Cards. It seems less expensive to use GPUs and recompile a few apps than trying to purchase a Motherboard with multiple CPUs or trying to find a chip faster than the 'i7'. If we could only double our Computer's speed this endeavor would be well worth doing. I suspect that Fortran's vector math could be easily converted and benefit greatly. Look for this feature in gcc in a few years (Sooner with everyone's help). Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40028
[Bug middle-end/40028] New: RFE - Add GPU acceleration library to gcc
RFE - It would be great if gcc had a couple (ATI / NVidia) of GPU libraries that gcc could use to speed up programs similar to what is done here: http://www.pgroup.com/resources/accel.htm The PGI 8.0 x64+GPU compilers automatically analyze whole program structure and data, split portions of the application between the x64 CPU and GPU as specified by user directives, and define and generate an optimized mapping of loops to automatically use the parallel cores, hardware threading capabilities and SIMD vector capabilities of modern GPUs. In addition to directives and pragmas that specify regions of code or functions to be accelerated, the PGI Fortran and C compilers will support user directives that give the programmer fine-grained control over the mapping of loops, allocation of memory, and optimization for the GPU memory hierarchy. The PGI compilers generate unified x64+GPU object files and executables that manage all movement of data to and from the GPU device while leveraging all existing host-side utilitieslinker, librarians, makefilesand require no changes to the existing standard HPC Linux/x64 programming environment. A demo of a program written in the OpenCL Language is here: http://www.youtube.com/watch?v=r1sN1ELJfNofeature=channel_page The GPGPU Programming Developer Webpage is here: http://gpgpu.org/developer Some applications can be ran hundreds of times faster, see this page at NVidia. http://www.nvidia.com/object/cuda_home.html If we could use run-time-linking to select either the ATI or NVidia (PlayStation?) library at run-time then gcc would remain portable and offer the speedup on any platform that utilized a graphics card with a GPU (not just x86). The middle end could attempt to determine which functions (or groups of code, inlinable, functions, loops, etc.) would be best to offload to the GPU (if a supported one were detected) and then resulting program would run much faster for most people by using the GPU as a coprocessor. Thanks, Rob -- Summary: RFE - Add GPU acceleration library to gcc Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rob1weld at aol dot com GCC build triplet: * GCC host triplet: * GCC target triplet: * http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40028
[Bug tree-optimization/21485] [4.3/4.4/4.5 Regression] missed load PRE, PRE makes i?86 suck
--- Comment #40 from rob1weld at aol dot com 2009-04-21 12:30 --- (In reply to comment #0) I've found a major performance regression in gcc 4.0.0's optimization ... (In reply to comment #11) We need more analysis on these kinds of issues. So, we're doing a worse job on register allocation. Is that because the register allocator got worse, or because we're giving it a harder problem to solve? (In reply to comment #12) It is the latter and the pass which is responsible ... (In reply to comment #13) Tough, there is really not much that can be done about this ... Is this of any use ? Register Allocation by Puzzle Solving http://compilers.cs.ucla.edu/fernando/projects/puzzles/ This project consists in developing a new model for register allocation that has fast compilation time, produces code of good quality, is able to address the many irregularities found in common computer architectures and is intuitive enough to be easily understood. Our implementation produces Pentium code that is of similar quality to the code produced by the slower, state-of-the-art iterated register coalescing algorithm of George and Appel augmented with extensions by Smith, Ramsey, and Holloway. YT, Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21485
[Bug target/39584] Default configure options for i686 OpenBSD produce gcc that FAILs too many Tests
--- Comment #1 from rob1weld at aol dot com 2009-04-18 12:49 --- Thanks for adjusting the Severity for me Andrew. There have been _small_ improvements in the Testsuite Results recently. The C compiler has gone from 828 errors a couple of months ago to a new low of only 742, but the C++ compiler went from 53 to 2198 errors. Results for 4.5.0 20090417 (experimental) [trunk revision 146277] (GCC) testsuite on i386-unknown-openbsd4.5 http://gcc.gnu.org/ml/gcc-testresults/2009-04/msg01867.html Results for 4.5.0 20090407 (experimental) [trunk revision 145649] (GCC) testsuite on i686-unknown-linux-gnu http://gcc.gnu.org/ml/gcc-testresults/2009-04/msg00745.html Results for 4.4.0 20090224 (experimental) [trunk revision 144400] (GCC) testsuite on i386-unknown-openbsd4.5 http://gcc.gnu.org/ml/gcc-testresults/2009-04/msg00420.html Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39584
[Bug bootstrap/39810] New: [melt] - revision 146327 - compiler-probe.c:106: undefined reference to `unlikely'
There are excess warnings and a build breaking error in revision 146327 on i386-pc-solaris2.11 (and perhaps other Platforms too). Host compiler: # gcc -v Using built-in specs. Target: i386-pc-solaris2.11 Configured with: ../gcc_trunk/configure --prefix=/usr/local/gcc4 --enable-languages=ada,c,c++,fortran,java,objc,obj-c++ --enable-shared --disable-static --enable-multilib --enable-decimal-float --with-long-double-128 --with-included-gettext --disable-stage1-checking --enable-checking=release --with-tune=k8 --with-cpu=k8 --with-arch=k8 --with-gnu-as --with-as=/usr/local/bin/as --with-gnu-ld --with-ld=/usr/local/bin/ld --with-gmp=/usr/local --with-mpfr=/usr/local Thread model: posix gcc version 4.5.0 20090406 (experimental) [trunk revision 145592] (GCC) Breaks here: # gmake ... ranlib libbackend.a gcc -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition -Wc++-compat -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -rdynamic -o cc1-dummy c-lang.o stub-objc.o attribs.o c-errors.o c-lex.o c-pragma.o c-decl.o c-typeck.o c-convert.o c-aux-info.o c-common.o c-opts.o c-format.o c-semantics.o c-ppoutput.o c-cppbuiltin.o c-objc-common.o c-dump.o c-pch.o c-parser.o i386-c.o sol2-c.o c-gimplify.o tree-mudflap.o c-pretty-print.o c-omp.o dummy-checksum.o \ main.o compiler-probe.o libbackend.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a ../libcpp/libcpp.a ./../intl/libintl.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -L/lib -lcloog -L/usr/local/lib -lppl_c -lppl -lgmpxx -L/usr/local/lib -L/usr/local/lib -lmpfr -lgmp -L/usr/local/lib -lltdl -L/usr/local/lib -lgdbm gcc: unrecognized option '-rdynamic' compiler-probe.o: In function `__drand48_iterate': /usr/share/src/melt-branch_build/gcc/../../melt-branch/gcc/compiler-probe.c:106: undefined reference to `unlikely' libbackend.a(basilys.o): In function `basilysgc_ppstrbuf_ppl_varnamvect': /usr/share/src/melt-branch_build/gcc/../../melt-branch/gcc/basilys.c:8707: undefined reference to `ppl_io_asprint_Coefficient' /usr/share/src/melt-branch_build/gcc/../../melt-branch/gcc/basilys.c:8712: undefined reference to `ppl_io_asprint_Linear_Expression' /usr/share/src/melt-branch_build/gcc/../../melt-branch/gcc/basilys.c:8717: undefined reference to `ppl_io_asprint_Constraint' /usr/share/src/melt-branch_build/gcc/../../melt-branch/gcc/basilys.c:8722: undefined reference to `ppl_io_asprint_Constraint_System' /usr/share/src/melt-branch_build/gcc/../../melt-branch/gcc/basilys.c:8727: undefined reference to `ppl_io_asprint_Generator' /usr/share/src/melt-branch_build/gcc/../../melt-branch/gcc/basilys.c:8731: undefined reference to `ppl_io_asprint_Generator_System' /usr/share/src/melt-branch_build/gcc/../../melt-branch/gcc/basilys.c:8736: undefined reference to `ppl_io_asprint_Polyhedron' collect2: ld returned 1 exit status gmake[3]: *** [cc1-dummy] Error 1 gmake[3]: Leaving directory `/usr/share/src/melt-branch_build/gcc' gmake[2]: *** [all-stage1-gcc] Error 2 gmake[2]: Leaving directory `/usr/share/src/melt-branch_build' gmake[1]: *** [stage1-bubble] Error 2 gmake[1]: Leaving directory `/usr/share/src/melt-branch_build' gmake: *** [all] Error 2 Also there are still plenty of warnings in: ../melt-branch/gcc/compiler-probe.c: ../melt-branch/gcc/basilys.c Thanks, Rob -- Summary: [melt] - revision 146327 - compiler-probe.c:106: undefined reference to `unlikely' Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rob1weld at aol dot com GCC build triplet: i386-pc-solaris2.11 GCC host triplet: i386-pc-solaris2.11 GCC target triplet: i386-pc-solaris2.11 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39810
[Bug middle-end/39625] [4.5 Regression] Revision 145338 breaks ability to build Ada
--- Comment #39 from rob1weld at aol dot com 2009-04-17 23:32 --- (In reply to comment #38) Maybe fixed now (the reduced testcase is). Please re-open if not. Confirmed. Thank you Richard. # uname -a OpenBSD openbsd.localdomain 4.5 GENERIC#19 i386 Host Compiler: # egcc -v Reading specs from /usr/local/lib/gcc-lib/i386-unknown-openbsd4.5/3.3.6/specs Configured with: /usr/obj/i386/gcc-3.3.6/gcc-3.3.6/configure --verbose --program-transform-name=s,^,e, --disable-nls --with-system-zlib --enable-languages=c,c++,f77,objc,ada --enable-cpp --with-gnu-as --with-gnu-ld --enable-shared --prefix=/usr/local --sysconfdir=/etc --mandir=/usr/local/man --infodir=/usr/local/info Thread model: single gcc version 3.3.6 # gcc/xgcc -v Using built-in specs. Target: i386-unknown-openbsd4.5 Configured with: /home/user/gcc_trunk/configure --prefix=/usr/obj/gcc_installed --enable-languages=c,ada,c++ --with-as=/usr/bin/as --with-ld=/usr/bin/ld --with-gnu-as --with-gnu-ld --enable-sjlj-exceptions --enable-shared --enable-multilib --enable-decimal-float --with-long-double-128 --with-tune=k8 --with-cpu=k8 --with-arch=k8 --enable-threads --sysconfdir=/etc --mandir=/usr/local/man --infodir=/usr/local/info --disable-stage1-checking --enable-checking=release --with-gmp=/usr/local --with-mpfr=/usr/local Thread model: posix gcc version 4.5.0 20090417 (experimental) [trunk revision 146277] (GCC) Thanks, Rob PS: The middle-end now permits the _build_ of gcc with the Language Ada selected to complete without failure, except for this unrelated issue: http://gcc.gnu.org/ml/gcc-patches/2008-06/msg00444.html . The actual ability of the Ada Language to operate correctly or pass the Testsuites is a _different_ issue that needs a separate RFE unrelated to #39625 . -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39625
[Bug c++/35652] [4.3 Regression] offset warning should be given in the front-end
--- Comment #27 from rob1weld at aol dot com 2009-04-11 17:01 --- Ping: gcc version 4.5.0 20090407 trunk revision 145649 gcc_trunk/libiberty/cplus-dem.c:2651: warning: offset 3 outside bounds of constant string Noticed while building binutils (with -Werror): ../binutils-2.19.1/bfd/elf.c: In function '_bfd_elf_print_private_bfd_data': ../binutils-2.19.1/bfd/elf.c:1236: error: offset '2' outside bounds of constant string Thanks, Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35652
[Bug middle-end/39625] [4.5 regression] Revision 145338 breaks ability to build Ada
--- Comment #25 from rob1weld at aol dot com 2009-04-09 15:16 --- That is good news, (that hppa2.0w-hp-hpux11.11 (PA-RISC 2.0.), which we claim is supported, is not the same/similar to hpux-ia64, which has two ZCX = False entries). We don't want to break that. Nice machine. Is the (small amount of ?) code in Gnat Pro going to be available (someday) for gcc Ada. That may fix these problems. - I wondered why we had: # diff -Naur /mnt/drive2/gcc_trunk/gcc/ada/system-mingw.ads /mnt/drive2/gcc_trunk/gcc/ada/system-mingw-x86_64.ads | tail -9 | head -6 @@ -141,7 +141,7 @@ Always_Compatible_Rep : constant Boolean := False; Suppress_Standard_Library : constant Boolean := False; Use_Ada_Main_Program_Name : constant Boolean := False; - ZCX_By_Default: constant Boolean := False; + ZCX_By_Default: constant Boolean := True; and found this thread: http://www.nabble.com/gcc-4.3.x-Ada-compiler-td22192698.html where Danny Smith (using gcc version 4.4.0-dw2 20090221) says he modified system-mingw.ads with this: Index: system-mingw.ads === --- system-mingw.ads (revision 144345) +++ system-mingw.ads (working copy) @@ -141,7 +141,7 @@ Always_Compatible_Rep : constant Boolean := False; Suppress_Standard_Library : constant Boolean := False; Use_Ada_Main_Program_Name : constant Boolean := False; - ZCX_By_Default: constant Boolean := False; + ZCX_By_Default: constant Boolean := True; GCC_ZCX_Support : constant Boolean := True; which both Rolf Ebert and Danny Smith claim fixes gcc 4.4.0 20090221, but Danny compiled using --disable-sjlj-exceptions. We still have the issue that all Platforms accept the (usually non-default) ./configure option --enable-sjlj-exceptions which leads to this Bug on supported Platforms (and leads us down the path of breaking that Option). I'll log out of my Debian 5.0 OS and go back to my OpenBSD OS and look at this from there. Thank you for your answers, Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39625
[Bug middle-end/39625] [4.5 regression] Revision 145338 breaks ability to build Ada
--- Comment #22 from rob1weld at aol dot com 2009-04-09 03:51 --- (In reply to comment #21) It looks like this would affect: hpux-ia64, lynxos-ppc, lynxos-x86, ... ... You can exclude all cross platforms; moreover hpux-ia64 is not really supported. URL http://gcc.gnu.org/gcc-4.5/criteria.html claims that hppa2.0w-hp-hpux11.11 is a Secondary Platform and URL http://en.wikipedia.org/wiki/PA-RISC says: The ISA was extended in 1996 to 64-bits, with this revision named PA-RISC 2.0. and also says Newer Itanium-based machines are intended to succeed PA-RISC . Would that be what we refer to as hpux-ia64 ? They seems to be much newer versions of that Operating System, I can Google references to HP-UX 11.31. Does our Criteria page need an update? The URL http://en.wikipedia.org/wiki/HP-UX says (11.31) release supports both PA-RISC and IA-64 [http://h20338.www2.hp.com/hpux11i/downloads/HP-UX_Binary_Compatibility.pdf] (July 23 2008). This URL says: http://h21007.www2.hp.com/portal/site/dspp/menuitem.5179cc2b5bf6406ac6713f8da973a801/?jumpid=reg_R1002_USENproductId=19356 GNAT Pro is the natural Ada solution for HPs Alpha server and Integrity server (I64) platforms or is gcc's Ada not quite GNAT Pro. Thanks, Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39625
[Bug middle-end/39625] [4.5 regression] Revision 145338 breaks ability to build Ada
--- Comment #20 from rob1weld at aol dot com 2009-04-07 04:00 --- (In reply to comment #8) Bug is not in an FSF-GCC supported port. Does the problem reproduce on supported targets? Otherwise this bug should be closed as INVALID. (In reply to comment #12) As for the backend issue, may be it will show up on i386-unknown-freebsd too (a primary platform), and there's a gcc/ada/system-freebsd-x86.ads in the FSF tree. Most probably not, you need FE SJLJ exceptions. I did some studying ;) . The current Docs do not show this info but 4.2.4 does. These 'quotes' are derived from this URL: http://gcc.gnu.org/onlinedocs/gcc-4.2.4/gnat_ugn_unw/Exception-Handling-Control.html 0. Any Target may be configured to use SJLJ. 1. GNAT uses two methods for handling exceptions at run-time. The setjmp/longjmp method and zero cost exception handling. 2. The setjmp/longjmp approach is available on all targets, while the zero cost approach is available on selected targets. With ZCX to propagate an exception through a C/C++ code, the C/C++ code must be compiled with the -funwind-tables GCC's option. 3. To determine whether zero cost exceptions can be used for a particular target, look at the private part of the file system.ads. Either GCC_ZCX_Support or Front_End_ZCX_Support must be True to use the zero cost approach. If both of these switches are set to False, this means that zero cost exception handling is not yet available for that target. So ... Two strikes and your out: # grep ZCX /mnt/drive2/gcc_trunk/gcc/ada/system* | grep False /mnt/drive2/gcc_trunk/gcc/ada/system.ads: ZCX_By_Default: constant Boolean := False; /mnt/drive2/gcc_trunk/gcc/ada/system.ads: GCC_ZCX_Support : constant Boolean := False; /mnt/drive2/gcc_trunk/gcc/ada/system.ads: Front_End_ZCX_Support : constant Boolean := False; /mnt/drive2/gcc_trunk/gcc/ada/system-aix.ads: ZCX_By_Default: constant Boolean := False; /mnt/drive2/gcc_trunk/gcc/ada/system-hpux-ia64.ads: ZCX_By_Default : constant Boolean := False; /mnt/drive2/gcc_trunk/gcc/ada/system-hpux-ia64.ads: GCC_ZCX_Support : constant Boolean := False; /mnt/drive2/gcc_trunk/gcc/ada/system-linux-alpha.ads: Front_End_ZCX_Support : constant Boolean := False; /mnt/drive2/gcc_trunk/gcc/ada/system-linux-mips.ads: Front_End_ZCX_Support : constant Boolean := False; /mnt/drive2/gcc_trunk/gcc/ada/system-linux-mipsel.ads: Front_End_ZCX_Support : constant Boolean := False; /mnt/drive2/gcc_trunk/gcc/ada/system-linux-s390.ads: Front_End_ZCX_Support : constant Boolean := False; /mnt/drive2/gcc_trunk/gcc/ada/system-linux-s390x.ads: Front_End_ZCX_Support : constant Boolean := False; /mnt/drive2/gcc_trunk/gcc/ada/system-linux-sparc.ads: Front_End_ZCX_Support : constant Boolean := False; /mnt/drive2/gcc_trunk/gcc/ada/system-linux-sparcv9.ads: Front_End_ZCX_Support : constant Boolean := False; /mnt/drive2/gcc_trunk/gcc/ada/system-lynxos-ppc.ads: ZCX_By_Default : constant Boolean := False; /mnt/drive2/gcc_trunk/gcc/ada/system-lynxos-ppc.ads: GCC_ZCX_Support : constant Boolean := False; /mnt/drive2/gcc_trunk/gcc/ada/system-lynxos-x86.ads: ZCX_By_Default : constant Boolean := False; /mnt/drive2/gcc_trunk/gcc/ada/system-lynxos-x86.ads: GCC_ZCX_Support : constant Boolean := False; /mnt/drive2/gcc_trunk/gcc/ada/system-mingw.ads: ZCX_By_Default: constant Boolean := False; /mnt/drive2/gcc_trunk/gcc/ada/system-rtems.ads: ZCX_By_Default: constant Boolean := False; /mnt/drive2/gcc_trunk/gcc/ada/system-vms.ads: GCC_ZCX_Support : constant Boolean := False; /mnt/drive2/gcc_trunk/gcc/ada/system-vxworks-arm.ads: ZCX_By_Default : constant Boolean := False; /mnt/drive2/gcc_trunk/gcc/ada/system-vxworks-arm.ads: GCC_ZCX_Support : constant Boolean := False; /mnt/drive2/gcc_trunk/gcc/ada/system-vxworks-m68k.ads: ZCX_By_Default : constant Boolean := False; /mnt/drive2/gcc_trunk/gcc/ada/system-vxworks-m68k.ads: GCC_ZCX_Support : constant Boolean := False; /mnt/drive2/gcc_trunk/gcc/ada/system-vxworks-mips.ads: ZCX_By_Default : constant Boolean := False; /mnt/drive2/gcc_trunk/gcc/ada/system-vxworks-mips.ads: GCC_ZCX_Support : constant Boolean := False; /mnt/drive2/gcc_trunk/gcc/ada/system-vxworks-ppc.ads: ZCX_By_Default : constant Boolean := False; /mnt/drive2/gcc_trunk/gcc/ada/system-vxworks-sparcv9.ads: ZCX_By_Default : constant Boolean := False; /mnt/drive2/gcc_trunk/gcc/ada/system-vxworks-sparcv9.ads: GCC_ZCX_Support : constant Boolean := False; /mnt/drive2/gcc_trunk/gcc/ada/system-vxworks-x86.ads: ZCX_By_Default : constant Boolean := False; /mnt/drive2/gcc_trunk/gcc/ada/system-vxworks-x86.ads: GCC_ZCX_Support : constant Boolean := False; It looks like this would affect
[Bug ada/39625] Unable to coalesce ssa_names 96 and 455 which are marked as MUST COALESCE.
--- Comment #5 from rob1weld at aol dot com 2009-04-05 09:46 --- (In reply to comment #4) (In reply to comment #1) ... Broken: 145350 Working: 145300 Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39625
[Bug ada/39625] Unable to coalesce ssa_names 96 and 455 which are marked as MUST COALESCE.
--- Comment #6 from rob1weld at aol dot com 2009-04-05 17:08 --- (In reply to comment #3) The Ada compiler hasn't been ported to OpenBSD yet. While we may not have ported Ada, the OpenBSD Group has it in Ports. # pkg_add gnat-3.3.6p9 # egcc -v Reading specs from /usr/local/lib/gcc-lib/i386-unknown-openbsd4.5/3.3.6/specs Configured with: /usr/obj/i386/gcc-3.3.6/gcc-3.3.6/configure --verbose --program-transform-name=s,^,e, --disable-nls --with-system-zlib --enable-languages=c,c++,f77,objc,ada --enable-cpp --with-gnu-as --with-gnu-ld --enable-shared --prefix=/usr/local --sysconfdir=/etc --mandir=/usr/local/man --infodir=/usr/local/info Thread model: single gcc version 3.3.6 Using the BSD Ports I was able to build Ada, up until revision 145338 . While I do not use Ada it would be unfortunate to lose this Language. The revision causing the build to fail has no updates to Ada, only in the middle-end. I am going to change the Component accordingly and revise the Subject to correctly reflect the issues. Thanks for your input Eric, Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39625
[Bug middle-end/39625] [4.5 regression] Revision 145338 breaks ability to build Ada
--- Comment #7 from rob1weld at aol dot com 2009-04-05 17:31 --- I can build gcc with the Ada Language using Trunk revision 145337 but the changes made in the next revision cause the build to fail. The Changelog indicates Richard Guenther made the changes on 2009-03-31. There were no changes made to Ada, only to the middle-end (AFAIK). # ./contrib/gcc_update -r 145338 Updating SVN tree Ugcc/java/java-gimplify.c Ugcc/java/ChangeLog Ugcc/tree.h Ugcc/ChangeLog Agcc/testsuite/gcc.dg/tree-ssa/pr23401.c Agcc/testsuite/gcc.dg/tree-ssa/pr27810.c Ugcc/testsuite/ChangeLog Ugcc/tree-eh.c Ugcc/gimplify.c Ugcc/tree-ssa-pre.c Ugcc/tree-mudflap.c Ugcc/gimple.c Ugcc/gimple.h Ugcc/tree-cfg.c Updated to revision 145338. I do not know the middle-end well enough to tamper with it. I would appreciate if the remainder of this work could be undertaken by someone else. I do not think that this is entirely Operating System specific, others may be affected too. # gcc/xgcc -v Using built-in specs. Target: i386-unknown-openbsd4.5 Configured with: /home/user/gcc_trunk/configure --prefix=/usr/obj/gcc_installed --enable-languages=c,ada,c++ --with-as=/usr/bin/as --with-ld=/usr/bin/ld --with-gnu-as --with-gnu-ld --enable-sjlj-exceptions --enable-shared --enable-multilib --enable-decimal-float --with-long-double-128 --with-tune=k8 --with-cpu=k8 --with-arch=k8 --enable-threads --sysconfdir=/etc --mandir=/usr/local/man --infodir=/usr/local/info --disable-stage1-checking --enable-checking=release --with-gmp=/usr/local --with-mpfr=/usr/local Thread model: posix gcc version 4.5.0 20090331 (experimental) [trunk revision 145338] (GCC) ../../xgcc -B../../ -c -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -gnatpg -gnata -I- -I../rts -I. -I/home/user/gcc_trunk/gcc/ada /home/user/gcc_trunk/gcc/ada/prj-part.adb -o prj-part.o /home/user/gcc_trunk/gcc/ada/prj-part.adb: In function 'Prj.Part.Parse_Single_Project': /home/user/gcc_trunk/gcc/ada/prj-part.adb:159: warning: 'Project' may be used uninitialized in this function /home/user/gcc_trunk/gcc/ada/prj-part.adb:159: note: 'Project' was declared here /home/user/gcc_trunk/gcc/ada/prj-part.adb:160: warning: 'Extends_All' may be used uninitialized in this function /home/user/gcc_trunk/gcc/ada/prj-part.adb:160: note: 'Extends_All' was declared here /home/user/gcc_trunk/gcc/ada/prj-part.adb:952: warning: 'Canonical_Path_Name' may be used uninitialized in this function /home/user/gcc_trunk/gcc/ada/prj-part.adb:953: warning: 'Project_Directory' may be used uninitialized in this function /home/user/gcc_trunk/gcc/ada/prj-part.adb:957: warning: 'Extending' may be used uninitialized in this function /home/user/gcc_trunk/gcc/ada/prj-part.adb:959: warning: 'Extended_Project' may be used uninitialized in this function /home/user/gcc_trunk/gcc/ada/prj-part.adb:965: warning: 'Name_From_Path' may be used uninitialized in this function /home/user/gcc_trunk/gcc/ada/prj-part.adb:966: warning: 'Name_Of_Project' may be used uninitialized in this function /home/user/gcc_trunk/gcc/ada/prj-part.adb:968: warning: 'Duplicated' may be used uninitialized in this function /home/user/gcc_trunk/gcc/ada/prj-part.adb:970: warning: 'First_With' may be used uninitialized in this function /home/user/gcc_trunk/gcc/ada/prj-part.adb:971: warning: 'Imported_Projects' may be used uninitialized in this function /home/user/gcc_trunk/gcc/ada/prj-part.adb:977: warning: 'Proj_Qualifier' may be used uninitialized in this function /home/user/gcc_trunk/gcc/ada/prj-part.adb:978: warning: 'Qualifier_Location' may be used uninitialized in this function /home/user/gcc_trunk/gcc/ada/prj-part.adb:939: warning: 'anonymous' may be used uninitialized in this function /home/user/gcc_trunk/gcc/ada/prj-part.adb:939: warning: 'anonymous' may be used uninitialized in this function /home/user/gcc_trunk/gcc/ada/prj-part.adb:961: warning: 'a_project_name_and_node.node' may be used uninitialized in this function Unable to coalesce ssa_names 96 and 455 which are marked as MUST COALESCE. first_with_96(ab) and first_with_455(ab) +===GNAT BUG DETECTED==+ | 4.5.0 20090331 (experimental) [trunk revision 145338] (i386-unknown-openbsd4.5) GCC error:| | SSA corruption | | Error detected around /home/user/gcc_trunk/gcc/ada/prj-part.adb:939 | | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact gcc or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files
[Bug testsuite/39655] New: autogen fixinclude test FAILURES - trunk revision 145337
FAILURES - trunk revision 145337 Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rob1weld at aol dot com GCC build triplet: i386-unknown-openbsd4.5 GCC host triplet: i386-unknown-openbsd4.5 GCC target triplet: i386-unknown-openbsd4.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39655
[Bug middle-end/39625] [4.5 regression] Revision 145338 breaks ability to build Ada
--- Comment #14 from rob1weld at aol dot com 2009-04-05 20:03 --- (In reply to comment #10) I think this should be kept open as an enhancement request, if we have a willing tester on openbsd I'll try to help. I'll do my best to help but I know that there are numerous people who are more qualified than me (knows Ada, the middle-end, etc.) _and_ who have an long term interest in keeping this alive (someone from Adacore /OpenBSD). If you want me to test Patches, fire away, Rob -- rob1weld at aol dot com changed: What|Removed |Added Status|WAITING |UNCONFIRMED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39625
[Bug middle-end/39625] [4.5 regression] Revision 145338 breaks ability to build Ada
--- Comment #15 from rob1weld at aol dot com 2009-04-05 20:10 --- (In reply to comment #9) Using the BSD Ports I was able to build Ada, up until revision 145338 . While I do not use Ada it would be unfortunate to lose this Language. This language is not supported in the FSF tree on OpenBSD, i.e. there is no appropriate system-*.ads file in the ada/ sub-directory. Version: 3.3.6, Package name: gcc-3.3.6 Maintained by: Marc Espie es...@openbsd.org http://openports.se/lang/gcc/3.3 Is this what we need ? [PATCH] ada: Add support for OpenBSD http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00079.html Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39625
[Bug middle-end/39625] [4.5 regression] Revision 145338 breaks ability to build Ada
--- Comment #17 from rob1weld at aol dot com 2009-04-05 20:53 --- I've found machines and hosting to add i686 What a great guy! More patches / support files / etc. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34717 ports/lang/gcc/4.3/patches/ http://www.openbsd.org/cgi-bin/cvsweb/ports/lang/gcc/4.3/patches/ ports/lang/gcc/3.3/ http://www.openbsd.org/cgi-bin/cvsweb/ports/lang/gcc/3.3/ Back in an hour, Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39625
[Bug ada/39625] Revision 145488 - Ada - Unable to coalesce ssa_names 96 and 455 which are marked as MUST COALESCE.
--- Comment #2 from rob1weld at aol dot com 2009-04-04 17:26 --- (In reply to comment #1) Working: 144400 While '144400' compiled properly the Testsuite was not as kind: Results for 4.4.0 20090224 (experimental) [trunk revision 144400] (GCC) testsuite on i386-unknown-openbsd4.5 http://gcc.gnu.org/ml/gcc-testresults/2009-04/msg00420.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39625
[Bug bootstrap/39483] [melt] - revision 144904 - Configuring with --with-gc=zone fails in ggc-zone.c
--- Comment #3 from rob1weld at aol dot com 2009-04-03 13:53 --- (In reply to comment #2) Thanks. Patch commited as rev 144905 of MELT branch. Closing, FIXED. Rob -- rob1weld at aol dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39483
[Bug driver/39439] The Driver hides undefined reference messages from shared libs (but not object files) in linker phase
--- Comment #4 from rob1weld at aol dot com 2009-04-03 13:59 --- (In reply to comment #3) Subject: Re: The Driver hides undefined reference messages from shared libs (but not object files) in linker phase Sent from my iPhone On Mar 13, 2009, at 8:54 PM, rob1weld at aol dot com gcc-bugzi...@gcc.gnu.org wrote: ... (lengthy quoted text) The linker, upon 'discovering' the problem, simply prints: ../../interfaces/C/.libs/libppl_c.so: undefined reference to `typeinfo for int' collect2: ld returned 1 exit status The linker is suppressing the undefined reference in the first place when creating the .so. I think this is a bug in ppl's make file and not gcc. OK. It's not gcc's fault. Closing, INVALID. Rob -- rob1weld at aol dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39439
[Bug ada/39625] New: Revision 145488 - Ada - Unable to coalesce ssa_names 96 and 455 which are marked as MUST COALESCE.
/user/gcc_trunk/gcc/ada/uintp.ads /home/user/gcc_trunk/gcc/ada/urealp.ads /home/user/gcc_trunk/gcc/ada/prj-tree.ads /home/user/gcc_trunk/gcc/ada/prj-attr.ads /home/user/gcc_trunk/gcc/ada/err_vars.ads /home/user/gcc_trunk/gcc/ada/opt.ads /home/user/gcc_trunk/gcc/ada/debug.ads /home/user/gcc_trunk/gcc/ada/osint.ads /home/user/gcc_trunk/gcc/ada/output.ads /home/user/gcc_trunk/gcc/ada/prj-com.ads /home/user/gcc_trunk/gcc/ada/prj-dect.ads /home/user/gcc_trunk/gcc/ada/prj-err.ads /home/user/gcc_trunk/gcc/ada/scng.ads /home/user/gcc_trunk/gcc/ada/styleg.ads /home/user/gcc_trunk/gcc/ada/errutil.ads /home/user/gcc_trunk/gcc/ada/prj-ext.ads /home/user/gcc_trunk/gcc/ada/sinput.ads /home/user/gcc_trunk/gcc/ada/sinput-p.ads /home/user/gcc_trunk/gcc/ada/snames.ads /home/user/gcc_trunk/gcc/ada/table.adb /home/user/gcc_trunk/gcc/ada/tree_io.ads raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:424 gmake[3]: *** [prj-part.o] Error 1 gmake[3]: Leaving directory `/usr/gcc_build/gcc/ada/tools' gmake[2]: *** [gnattools-native] Error 2 gmake[2]: Leaving directory `/usr/gcc_build/gnattools' gmake[1]: *** [all-gnattools] Error 2 gmake[1]: Leaving directory `/usr/gcc_build' gmake: *** [all] Error 2 Thanks, Rob -- Summary: Revision 145488 - Ada - Unable to coalesce ssa_names 96 and 455 which are marked as MUST COALESCE. Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rob1weld at aol dot com GCC build triplet: i386-unknown-openbsd4.5 GCC host triplet: i386-unknown-openbsd4.5 GCC target triplet: i386-unknown-openbsd4.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39625
[Bug ada/39138] Fix Copyright Dates Before 4.5.0 Branch (or sooner)
--- Comment #2 from rob1weld at aol dot com 2009-04-03 15:27 --- There has been some progress in this Bug Report: http://gcc.gnu.org/viewcvs/trunk/gcc/ada/?sortby=date mlib-tgt-specific-solaris.adb144324 5 weeks jakub Update Copyright years for files modified in 2008 and/or 2009. If I spot any more that were missed I will post here. Thanks to the various persons involved, a consistent format for the Notice and a Maintainer script that seded everything would make this go much quicker next year. I thought FSF was particular about it's Copyrights, I can't speculate why this was lowered to a minor. Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39138
[Bug ada/39625] Revision 145488 - Ada - Unable to coalesce ssa_names 96 and 455 which are marked as MUST COALESCE.
--- Comment #1 from rob1weld at aol dot com 2009-04-04 01:59 --- Broken: 145488 Working: 144400 I'll continue to narrow it down some more. Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39625
[Bug bootstrap/39616] New: Stage 2 Werror - trunk revision 145459 - libcpp/identifiers.c:113: error: variably modified 'proxy_assertion_broken' at file scope
The build is blocked by a Stage 2 Werror (we reject our own code). I can continue with an exclusion. Workaround is to compile single file without -Werror. # cat stage_current stage2 # uname -a OpenBSD openbsd.localdomain 4.5 GENERIC#19 i386 # prev-gcc/xgcc -v Using built-in specs. Target: i386-unknown-openbsd4.5 Configured with: /home/user/gcc_trunk/configure --prefix=/usr/obj/gcc_installed --enable-languages=c,c++,fortran,java,objc,obj-c++ --with-as=/usr/bin/as --with-ld=/usr/bin/ld --with-gnu-as --with-gnu-ld --enable-sjlj-exceptions --enable-shared --sysconfdir=/etc --mandir=/usr/local/man --infodir=/usr/local/man --enable-multilib --disable-stage1-checking --enable-checking=release --with-system-zlib --with-gmp=/usr/local --with-mpfr=/usr/local Thread model: single gcc version 4.5.0 20090402 (experimental) [trunk revision 145459] (GCC) /usr/gcc_build/./prev-gcc/xgcc -B/usr/gcc_build/./prev-gcc/ -B/usr/obj/gcc_installed/i386-unknown-openbsd4.5/bin/ -I/home/user/gcc_trunk/libcpp -I. -I/home/user/gcc_trunk/libcpp/../include -I./../intl -I/home/user/gcc_trunk/libcpp/include -g -O2 -fomit-frame-pointer -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -pedantic -Wno-long-long -Werror -I/home/user/gcc_trunk/libcpp -I. -I/home/user/gcc_trunk/libcpp/../include -I./../intl -I/home/user/gcc_trunk/libcpp/include -c -o identifiers.o -MT identifiers.o -MMD -MP -MF .deps/identifiers.Tpo /home/user/gcc_trunk/libcpp/identifiers.c cc1: warnings being treated as errors /home/user/gcc_trunk/libcpp/identifiers.c:113: error: variably modified 'proxy_assertion_broken' at file scope /home/user/gcc_trunk/libcpp/identifiers.c:113: error: ISO C90 forbids array 'proxy_assertion_broken' whose size can't be evaluated gmake[3]: *** [identifiers.o] Error 1 gmake[3]: Leaving directory `/usr/gcc_build/libcpp' gmake[2]: *** [all-stage2-libcpp] Error 2 gmake[2]: Leaving directory `/usr/gcc_build' gmake[1]: *** [stage2-bubble] Error 2 gmake[1]: Leaving directory `/usr/gcc_build' gmake: *** [all] Error 2 Thanks, Rob -- Summary: Stage 2 Werror - trunk revision 145459 - libcpp/identifiers.c:113: error: variably modified 'proxy_assertion_broken' at file scope Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rob1weld at aol dot com GCC build triplet: * GCC host triplet: * GCC target triplet: * http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39616
[Bug bootstrap/39618] New: trunk revision 145459 - The configure of libstdc++-v3 hangs while checking for PCH support
The build is stuck in the Third Stage of configuring 'libstdc++-v3'. I hope I selected the correct Component, it is either 'bootstrap', 'pch' or 'c++' (still investigating). I had no such problem with the previous stages and can build gcc 4.2.0 on this Platform using the same ./configure options. I have an unsatisfactory workaround below. # uname -a OpenBSD openbsd.localdomain 4.5 GENERIC#19 i386 # gcc/xgcc -v Using built-in specs. Target: i386-unknown-openbsd4.5 Configured with: /home/user/gcc_trunk/configure --prefix=/usr/obj/gcc_installed --enable-languages=c,c++,fortran,java,objc,obj-c++ --with-as=/usr/bin/as --with-ld=/usr/bin/ld --with-gnu-as --with-gnu-ld --enable-sjlj-exceptions --enable-shared --sysconfdir=/etc --mandir=/usr/local/man --infodir=/usr/local/man --enable-multilib --disable-stage1-checking --enable-checking=release --with-system-zlib --with-gmp=/usr/local --with-mpfr=/usr/local Thread model: single gcc version 4.5.0 20090402 (experimental) [trunk revision 145459] (GCC) The KDE Process Monitor says that the hung Process is gcc/cc1plus . I have over 900MB free and am not using any swap. Here is where it hangs, it has been stuck here for over half an hour: Checking multilib configuration for libstdc++-v3... mkdir i386-unknown-openbsd4.5/libstdc++-v3 Configuring in i386-unknown-openbsd4.5/libstdc++-v3 configure: creating cache ./config.cache checking build system type... i386-unknown-openbsd4.5 ... checking whether the /usr/gcc_build/./gcc/xgcc -shared-libgcc -B/usr/gcc_build/./gcc -nostdinc++ -L/usr/gcc_build/i386-unknown-openbsd4.5/libstdc++-v3/src -L/usr/gcc_build/i386-unknown-openbsd4.5/libstdc++-v3/src/.libs -B/usr/obj/gcc_installed/i386-unknown-openbsd4.5/bin/ -B/usr/obj/gcc_installed/i386-unknown-openbsd4.5/lib/ -isystem /usr/obj/gcc_installed/i386-unknown-openbsd4.5/include -isystem /usr/obj/gcc_installed/i386-unknown-openbsd4.5/sys-include linker (/usr/gcc_build/./gcc/collect-ld) supports shared libraries... yes checking dynamic linker characteristics... cc1: warning: command line option -nostdinc++ is valid for C++/ObjC++ but not for C openbsd4.5 ld.so checking how to hardcode library paths into programs... immediate checking for exception model to use... sjlj checking for compiler with PCH support... [HUNG] I killed the process and this is the result: checking for compiler with PCH support... no checking for enabled PCH... no checking for thread model used by GCC... single checking for atomic builtins for bool... no ... I loose PCH support but the build and configury can now continue. I'll see if I can go back and determine why this occurs once the build is completed and make -i check is running. Thanks, Rob -- Summary: trunk revision 145459 - The configure of libstdc++-v3 hangs while checking for PCH support Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rob1weld at aol dot com GCC build triplet: i386-unknown-openbsd4.5 GCC host triplet: i386-unknown-openbsd4.5 GCC target triplet: i386-unknown-openbsd4.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39618
[Bug bootstrap/39619] New: ICE - trunk revision 145459 - libstdc++-v3/src/functexcept.cc:97: ICE SEGFAULT
There is an ICE while compiling 'libstdc++-v3'. # uname -a OpenBSD openbsd.localdomain 4.5 GENERIC#19 i386 # gcc/xgcc -v Using built-in specs. Target: i386-unknown-openbsd4.5 Configured with: /home/user/gcc_trunk/configure --prefix=/usr/obj/gcc_installed --enable-languages=c,c++,fortran,java,objc,obj-c++ --with-as=/usr/bin/as --with-ld=/usr/bin/ld --with-gnu-as --with-gnu-ld --enable-sjlj-exceptions --enable-shared --sysconfdir=/etc --mandir=/usr/local/man --infodir=/usr/local/man --enable-multilib --disable-stage1-checking --enable-checking=release --with-system-zlib --with-gmp=/usr/local --with-mpfr=/usr/local Thread model: single gcc version 4.5.0 20090402 (experimental) [trunk revision 145459] (GCC) libtool: compile: /usr/gcc_build/./gcc/xgcc -shared-libgcc -B/usr/gcc_build/./gcc -nostdinc++ -L/usr/gcc_build/i386-unknown-openbsd4.5/libstdc++-v3/src -L/usr/gcc_build/i386-unknown-openbsd4.5/libstdc++-v3/src/.libs -B/usr/obj/gcc_installed/i386-unknown-openbsd4.5/bin/ -B/usr/obj/gcc_installed/i386-unknown-openbsd4.5/lib/ -isystem /usr/obj/gcc_installed/i386-unknown-openbsd4.5/include -isystem /usr/obj/gcc_installed/i386-unknown-openbsd4.5/sys-include -I/usr/gcc_build/i386-unknown-openbsd4.5/libstdc++-v3/include/i386-unknown-openbsd4.5 -I/usr/gcc_build/i386-unknown-openbsd4.5/libstdc++-v3/include -I/home/user/gcc_trunk/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -g -O2 -std=gnu++0x -c /home/user/gcc_trunk/libstdc++-v3/src/functexcept.cc -fPIC -DPIC -o .libs/functexcept.o /home/user/gcc_trunk/libstdc++-v3/src/functexcept.cc: In function 'void std::__throw_underflow_error(const char*)': /home/user/gcc_trunk/libstdc++-v3/src/functexcept.cc:97: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. gmake[4]: *** [functexcept.lo] Error 1 gmake[4]: Leaving directory `/usr/gcc_build/i386-unknown-openbsd4.5/libstdc++-v3/src' gmake[3]: *** [all-recursive] Error 1 gmake[3]: Leaving directory `/usr/gcc_build/i386-unknown-openbsd4.5/libstdc++-v3' gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory `/usr/gcc_build/i386-unknown-openbsd4.5/libstdc++-v3' gmake[1]: *** [all-target-libstdc++-v3] Error 2 gmake[1]: Leaving directory `/usr/gcc_build' gmake: *** [all] Error 2 Thanks, Rob -- Summary: ICE - trunk revision 145459 - libstdc++- v3/src/functexcept.cc:97: ICE SEGFAULT Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rob1weld at aol dot com GCC build triplet: i386-unknown-openbsd4.5 GCC host triplet: i386-unknown-openbsd4.5 GCC target triplet: i386-unknown-openbsd4.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39619
[Bug target/25255] packed structure: pointers to self result in error: initializer for integer value is too complicated
--- Comment #4 from rob1weld at aol dot com 2009-03-30 23:35 --- I ran into this Bug on the Trunk for Platform x64_86-unknown-openbsd4.5 . I tried the test C code from http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25255#c1 and got this: /home/user/gcc_build/test_gcc_2.c:18: error: initializer for integer/fixed-point value is too complicated /home/user/gcc_build/test_gcc_2.c:18: error: initializer for integer/fixed-point value is too complicated This error does not occur with gcc version 3.3.5 on: # uname -a OpenBSD openbsd.localdomain 4.5 GENERIC#5 amd64 # gcc/xgcc -v Using built-in specs. Target: amd64-unknown-openbsd4.5 Configured with: /usr/src/gcc_trunk/configure --prefix=/home/user/gcc_installed --target=amd64-unknown-openbsd4.5 --enable-languages=c,c++ --disable-multilib --enable-threads=posix --enable-static --enable-shared --with-gnu-ld --with-gnu-as --with-long-double-128 --disable-stage1-checking --enable-checking=release --with-gmp=/usr/local --with-mpfr=/usr/local Thread model: posix gcc version 4.5.0 20090330 (experimental) [trunk revision 145313] (GCC) # gmake ... /usr/src/gcc_trunk/libgcc/../gcc/unwind-dw2-fde.c:848: warning: dereferencing type-punned pointer will break strict-aliasing rules /home/user/gcc_build/./gcc/xgcc -B/home/user/gcc_build/./gcc/ -B/home/user/gcc_installed/amd64-unknown-openbsd4.5/bin/ -B/home/user/gcc_installed/amd64-unknown-openbsd4.5/lib/ -isystem /home/user/gcc_installed/amd64-unknown-openbsd4.5/include -isystem /home/user/gcc_installed/amd64-unknown-openbsd4.5/sys-include -g -O2 -O2 -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../.././gcc -I/usr/src/gcc_trunk/libgcc -I/usr/src/gcc_trunk/libgcc/. -I/usr/src/gcc_trunk/libgcc/../gcc -I/usr/src/gcc_trunk/libgcc/../include -DHAVE_CC_TLS -o unwind-sjlj.o -MT unwind-sjlj.o -MD -MP -MF unwind-sjlj.dep -fexceptions -c /usr/src/gcc_trunk/libgcc/../gcc/unwind-sjlj.c /home/user/gcc_build/./gcc/xgcc -B/home/user/gcc_build/./gcc/ -B/home/user/gcc_installed/amd64-unknown-openbsd4.5/bin/ -B/home/user/gcc_installed/amd64-unknown-openbsd4.5/lib/ -isystem /home/user/gcc_installed/amd64-unknown-openbsd4.5/include -isystem /home/user/gcc_installed/amd64-unknown-openbsd4.5/sys-include -g -O2 -O2 -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../.././gcc -I/usr/src/gcc_trunk/libgcc -I/usr/src/gcc_trunk/libgcc/. -I/usr/src/gcc_trunk/libgcc/../gcc -I/usr/src/gcc_trunk/libgcc/../include -DHAVE_CC_TLS -o gthr-gnat.o -MT gthr-gnat.o -MD -MP -MF gthr-gnat.dep -fexceptions -c /usr/src/gcc_trunk/libgcc/../gcc/gthr-gnat.c /usr/src/gcc_trunk/libgcc/../gcc/gthr-gnat.c:87: error: initializer for integer/fixed-point value is too complicated /usr/src/gcc_trunk/libgcc/../gcc/gthr-gnat.c:87: error: initializer for integer/fixed-point value is too complicated gmake[3]: *** [gthr-gnat.o] Error 1 gmake[3]: Leaving directory `/home/user/gcc_build/amd64-unknown-openbsd4.5/libgcc' gmake[2]: *** [all-stage1-target-libgcc] Error 2 gmake[2]: Leaving directory `/home/user/gcc_build' gmake[1]: *** [stage1-bubble] Error 2 gmake[1]: Leaving directory `/home/user/gcc_build' gmake: *** [all] Error 2 Thanks, Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25255
[Bug bootstrap/39470] [melt] - lrand48_r() and srand48_r() are GNU extensions and are not portable
--- Comment #8 from rob1weld at aol dot com 2009-03-30 03:37 --- (In reply to comment #7) fopencookie is removed in rev145010 of MELT branch. I'm using a temporary kludge , calling an unstable function inside PPL. So You'll need a recent PPL snapshot (obtained thru GIT). http://www.cs.unipr.it/pipermail/ppl-devel/2009-March/014162.html Better fix will be available after PPL gets a better function to debugprint inside a string buffer. Thanks. OK, I'll change this from a BLOCKER to FIXED. Please note that the Trunk (not the melt-branch) _currently_ (last week) _requires_ PPL 0.10 and the 'configury' tests the version. You will benefit from creating a Patch for the Trunk to use newer PPL and getting it approved so that your melt-branch does not stray too far from the Trunk. You need to make a 'diff' of the melt-branch versus the Trunk that is as SMALL as is possible so that it is simpler and faster for others to approve the melt-branch Patch and allow it to merge. Rob -- rob1weld at aol dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39470
[Bug bootstrap/39572] New: RFE - Gcc is incomplete for 64 Bit Targets - Need support for x86_64 OpenBSD
The Target x86_64-unknown-openbsd4.5 is not supported in Trunk. # uname -a OpenBSD openbsd.localdomain 4.5 GENERIC#5 amd64 The file ../gcc_trunk/gcc/config.gcc supports both x86_64-*-freebsd* and x86_64-*-netbsd* but NOT x86_64-*-openbsd*. The file ../gcc_trunk/gcc/config.gcc does support i[34567]86-*-freebsd*, i[34567]86-*-netbsd* and i[34567]86-*-openbsd*. Thanks, Rob -- Summary: RFE - Gcc is incomplete for 64 Bit Targets - Need support for x86_64 OpenBSD Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rob1weld at aol dot com GCC build triplet: x86_64-unknown-openbsd4.5 GCC host triplet: x86_64-unknown-openbsd4.5 GCC target triplet: x86_64-*-openbsd* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39572
[Bug bootstrap/36545] Type _uleb128_t doesn't defined properly in /gcc/unwind-dw2.c
--- Comment #3 from rob1weld at aol dot com 2009-03-29 04:31 --- (In reply to comment #1) How did you configure GCC and how did you invoke make? I am getting the exact same error on the Trunk for OpenBSD 4.5 . # gmake ... (Errors) # gcc/xgcc -v Using built-in specs. Target: i686-unknown-openbsd4.5 Configured with: /usr/src/gcc_trunk/configure --prefix=/home/usr/gcc_installed --build=x86_64-unknown-openbsd4.5 --host=x86_64-unknown-openbsd4.5 --targeti686-unknown-openbsd4.5 --enable-languages=c,c++,fortran,java,objc,obj-c++ --enable-multilib --disable-stage1-checking --enable-checking=release --with-gmp=/usr/local --with-mpfr=/usr/local Thread model: single gcc version 4.5.0 20090328 (experimental) [trunk revision 145157] (GCC) Thanks, Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36545
[Bug bootstrap/36545] Type _uleb128_t doesn't defined properly in /gcc/unwind-dw2.c
--- Comment #4 from rob1weld at aol dot com 2009-03-29 04:38 --- Another person has the same complaint as Andrey here: http://www.mail-archive.com/g...@gcc.gnu.org/msg23970.html -- rob1weld at aol dot com changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36545
[Bug bootstrap/39484] [melt] - revision 144904 - BASILYS INFORM [#198595]: warmelt-first-1.c - SIGSEGV
--- Comment #6 from rob1weld at aol dot com 2009-03-22 09:26 --- This Bug has been FIXED by Revision 144917. http://gcc.gnu.org/viewcvs/*checkout*/branches/melt-branch/gcc/ChangeLog.melt?revision=144917 Rob -- rob1weld at aol dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39484
[Bug bootstrap/39470] [melt] - lrand48_r() and srand48_r() are GNU extensions and are not portable
--- Comment #4 from rob1weld at aol dot com 2009-03-22 09:57 --- I am aware that the _r issues have been addressed and will test the 'soon to arrive' fopencookie() code next week on i386-pc-solaris2.11 to ensure that non-Linux Platforms have a chance to vompile 'melt'. Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39470
[Bug bootstrap/39484] [melt] - revision 144904 - BASILYS INFORM [#198595]: warmelt-first-1.c - SIGSEGV
--- Comment #5 from rob1weld at aol dot com 2009-03-18 06:19 --- Nearly perfect results: (better than the Trunk last week) Results for 4.4.0 20090313 (experimental) [melt-branch revision 144923] (GCC) testsuite on i686-unknown-linux-gnu http://gcc.gnu.org/ml/gcc-testresults/2009-03/msg01839.html Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39484
[Bug bootstrap/39483] New: [melt] - revision 144904 - Configuring with --with-gc=zone fails in ggc-zone.c
This is a blocker but I only set the Severity to major since I used a non-default configure option, _and_ I have the patch included. Configuring with --with-gc=zone fails due to a coding error in ggc-zone.c . Apply the patch to fix this. If the patch is OK, remove comment lines /* */. Thanks, Rob -- Summary: [melt] - revision 144904 - Configuring with --with- gc=zone fails in ggc-zone.c Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rob1weld at aol dot com GCC build triplet: i686-unknown-linux-gnu GCC host triplet: i686-unknown-linux-gnu GCC target triplet: i686-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39483
[Bug bootstrap/39483] [melt] - revision 144904 - Configuring with --with-gc=zone fails in ggc-zone.c
--- Comment #1 from rob1weld at aol dot com 2009-03-17 15:45 --- Created an attachment (id=17478) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17478action=view) Patch ggc-zone.c to support ggc_collect_1()'s call to ggc_mark_roots_extra_marking() -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39483
[Bug bootstrap/39484] New: [melt] - revision 144904 - BASILYS INFORM [#198595]: warmelt-first-1.c - SIGSEGV
) at ../../melt-branch/gcc/toplev.c:2283 #11 0x08190482 in main (argc=Cannot access memory at address 0x18 ) at ../../melt-branch/gcc/main.c:35 (gdb) I'm not familiar enough with this branch to offer a patch. Thanks, Rob -- Summary: [melt] - revision 144904 - BASILYS INFORM [#198595]: warmelt-first-1.c - SIGSEGV Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rob1weld at aol dot com GCC build triplet: i686-unknown-linux-gnu GCC host triplet: i686-unknown-linux-gnu GCC target triplet: i686-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39484
[Bug bootstrap/39484] [melt] - revision 144904 - BASILYS INFORM [#198595]: warmelt-first-1.c - SIGSEGV
--- Comment #2 from rob1weld at aol dot com 2009-03-17 17:48 --- Created an attachment (id=17479) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17479action=view) A patch to ignore NULL *mi-iniframp from VEC_iterate() - shortcuts the issue I am very unfamiliar with this branch and offer this very naive patch which seems to work thus far. I'm not checking the Patch checkbox nor suggesting it is OK. # ../melt-branch_build/gcc/xgcc -v Using built-in specs. Target: i686-unknown-linux-gnu Configured with: ../melt-branch/configure --build=i686-unknown-linux-gnu --prefix=/usr/local/melt-gcc --enable-languages=c --enable-shared --disable-static --disable-multilib --enable-stage1-checking=all --enable-checking=release --with-arch=k8 --with-gc=zone --with-gnu-as --with-as=/usr/bin/as --with-gnu-ld --with-ld=/usr/bin/ld --with-gmp=/usr/local --with-mpfr=/usr/local --with-ltdl=/usr/local --with-gdbm=/usr/local --with-ppl=/usr --enable-maintainer-mode --enable-compile-probe --enable-basilysmelt --enable-gather-detailed-memory-stats Thread model: posix gcc version 4.4.0 20090313 (experimental) [melt-branch revision 144904] (GCC) Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39484
[Bug bootstrap/39484] [melt] - revision 144904 - BASILYS INFORM [#198595]: warmelt-first-1.c - SIGSEGV
--- Comment #4 from rob1weld at aol dot com 2009-03-17 22:30 --- (In reply to comment #3) I applied a slightly simplified variant of melt-patch-2.patch above as rev144917 Thanks Rob. It probably works! Great. The code may receive a better following if there were fewer warnings. :) Related to this issue is the Wiki says to use: --enable-checks=tree,gc but 'basilys.h', on line 2352 has #if ENABLE_ASSERT_CHECKING which implies we need: --enable-checks=assert,tree,gc due to the way that '../melt-branch/configure' (on lines 7924-7966) handles the checks. Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39484
[Bug bootstrap/39470] [melt] - lrand48_r() and srand48_r() are GNU extensions and are not portable
--- Comment #2 from rob1weld at aol dot com 2009-03-16 22:08 --- My next difficulty (on OpenSolaris) is the lack of a fopencookie() function (and the related support in FILE). I'm now building melt on i686-pc-linux-gnu and running into a few other errors; thus melt does need some fixing, even on a Linux Operating System. Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39470
[Bug bootstrap/37013] gcc-4.2.1 build breaks in fortran when using --with-mpfr=
--- Comment #4 from rob1weld at aol dot com 2009-03-15 07:57 --- (In reply to comment #2) From ka...@gcc.gnu.org 4.2.1 is history and is completely and utterly unsupported. OK. Directory ftp://ftp.gnu.org/gnu/gcc/ says the date is 07/20/07 so it is barely over one year old. ... Support for old versions of gcc is a _requirement_ to build some of the Branches: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38626#c4 Some Branches use code from a year ago; with all the updates made to the particular section of gcc that the Branch Group is working on. The entirety of the Branch is _not_ necessarily synced to the Trunk. Since Bootstrapping GNAT with a more recent GNAT is not supported you are _required_ to use a version of gcc that is old enough to compile the file gcc/ada/ali.adb without causing the obscure error message: ali.adb:1825:41: (style) bad casing of NUL declared in Standard. It would be great if the main ./configure checked if the host Gnat being used to Bootstrap the built Gnat is a usable version so we did not get a compilation error much later in the build. Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37013
[Bug bootstrap/39470] New: [melt] - lrand48_r() and srand48_r() are GNU extensions and are not portable
initializer ../../melt-branch/gcc/compiler-probe.c:2194: warning: (near initialization for gsi.seq) ../../melt-branch/gcc/compiler-probe.c:2196: warning: unused variable gotpos ../../melt-branch/gcc/compiler-probe.c: In function comprobe_unique_index_of_basic_block: ../../melt-branch/gcc/compiler-probe.c:2243: warning: cast from pointer to integer of different size ../../melt-branch/gcc/compiler-probe.c: In function add_infopoint_basic_block: ../../melt-branch/gcc/compiler-probe.c:2289: warning: missing initializer ../../melt-branch/gcc/compiler-probe.c:2289: warning: (near initialization for gsi.seq) ../../melt-branch/gcc/compiler-probe.c: At top level: ../../melt-branch/gcc/compiler-probe.c:1442: warning: tree_ending_displayer defined but not used ../../melt-branch/gcc/compiler-probe.c:214: error: storage size of randata isnt known gmake[3]: *** [compiler-probe.o] Error 1 gmake[3]: Leaving directory `/usr/share/src/melt-branch_build/gcc' gmake[2]: *** [all-stage1-gcc] Error 2 gmake[2]: Leaving directory `/usr/share/src/melt-branch_build' gmake[1]: *** [stage1-bubble] Error 2 gmake[1]: Leaving directory `/usr/share/src/melt-branch_build' gmake: *** [all] Error 2 ( Note: MELT = http://gcc.gnu.org/wiki/MiddleEndLispTranslator + ADB + http://gcc.gnu.org/viewcvs/branches/?sortby=date#dirlist = !flames ) :) -- Summary: [melt] - lrand48_r() and srand48_r() are GNU extensions and are not portable Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rob1weld at aol dot com GCC build triplet: i386-pc-solaris2.11 GCC host triplet: i386-pc-solaris2.11 GCC target triplet: i386-pc-solaris2.11 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39470
[Bug middle-end/34300] gcc 4.2.2 miscompiles code that uses global register variables
--- Comment #6 from rob1weld at aol dot com 2009-03-13 20:30 --- Confirmed on the Trunk. In the Bug mentioned at http://bugs.gentoo.org/54738 and here this fails on gcc version 4.4.0 20090312 [trunk revision 144821]. Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34300
[Bug driver/39439] The Driver hides undefined reference messages from shared libs (but not object files) in linker phase
--- Comment #2 from rob1weld at aol dot com 2009-03-14 03:54 --- (In reply to comment #1) Subject: Re: New: The Driver hides undefined reference messages from shared libs (but not object files) in linker phase Sent from my iPhone Hurray for Phones with large screens. On Mar 11, 2009, at 9:27 PM, rob1weld at aol dot com gcc-bugzi...@gcc.gnu.org wrote: The Driver hides undefined reference messages from shared libs but not from object files. This seems inconsistent and is not helpful. Why do you think the driver is doing instead of the linker? The linker, upon 'discovering' the problem, simply prints: ../../interfaces/C/.libs/libppl_c.so: undefined reference to `typeinfo for int' collect2: ld returned 1 exit status By using the Objects, instead of the Shared Library, I force it to make the discovery early and report ALL the details instead of trying to unmangle the C++, resulting in this more verbose message: ../../interfaces/C/.libs/ppl_c__BD_Shape_mpq_class.o: In function `sgnParma_Polyhedra_Library::Checked_Number__gmp_expr__mpz_struct [1], __mpz_struct [1], Parma_Polyhedra_Library::Extended_Number_Policy ': /usr/share/src/ppl-build/interfaces/C/../../src/ppl.hh:11187: undefined reference to `typeinfo for int' My ld is: # ld --version GNU ld (GNU Binutils) 2.19.1 I'm building with -g and the Shared Library is not stripped: # file /usr/share/src/ppl-build/interfaces/C/.libs/libppl_c.so /usr/share/src/ppl-build/interfaces/C/.libs/libppl_c.so:ELF 32-bit LSB dynamic lib 80386 Version 1, dynamically linked, not stripped I say it is the Driver and not xgcc / gcc, or ld since if the Driver took the _ridiculous_ step of noticing the Linker error and re-running the compile (using the objects used to create the Shared Library) the the Driver could produce the more verbose output that I RFE'd in favour of. Notice I mentioned that actually implementing that behavior by re-running the compiler is not efficient. Using -g needs to pass _more_ info to the Linker, to be included in the Shared Libraries produced, so that if there is a Linker error then 'ld' can reference the source code where the error was caused and display it. The way we are producing Shared Libraries gives us very terse error messages that seem as though the Shared Library were stripped (when they are not). Is there a problem with the manner in which the PPL source is written ? I'm not very fluent in C++. Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39439
[Bug driver/39439] New: The Driver hides undefined reference messages from shared libs (but not object files) in linker phase
/ppl_c__BD_Shape_mpq_class.o: In function `sgnParma_Polyhedra_Library::Checked_Number__gmp_expr__mpz_struct [1], __mpz_struct [1], Parma_Polyhedra_Library::Extended_Number_Policy ': /usr/share/src/ppl-build/interfaces/C/../../src/ppl.hh:11187: undefined reference to `typeinfo for int' ../../interfaces/C/.libs/ppl_c__BD_Shape_mpq_class.o: In function `sgnParma_Polyhedra_Library::Checked_Number__gmp_expr__mpq_struct [1], __mpq_struct [1], Parma_Polyhedra_Library::WRD_Extended_Number_Policy ': /usr/share/src/ppl-build/interfaces/C/../../src/ppl.hh:11187: undefined reference to `typeinfo for int' ../../interfaces/C/.libs/ppl_c__BD_Shape_mpq_class.o: In function `sgnParma_Polyhedra_Library::Checked_Number__gmp_expr__mpz_struct [1], __mpz_struct [1], Parma_Polyhedra_Library::WRD_Extended_Number_Policy ': /usr/share/src/ppl-build/interfaces/C/../../src/ppl.hh:11187: undefined reference to `typeinfo for int' ../../interfaces/C/.libs/ppl_c__BD_Shape_mpq_class.o: In function `sgnParma_Polyhedra_Library::Checked_Number__gmp_expr__mpq_struct [1], __mpq_struct [1], Parma_Polyhedra_Library::Extended_Number_Policy ': /usr/share/src/ppl-build/interfaces/C/../../src/ppl.hh:11187: undefined reference to `typeinfo for int' /usr/share/src/ppl-build/interfaces/C/../../src/ppl.hh:11187: undefined reference to `typeinfo for int' ../../interfaces/C/.libs/ppl_c__BD_Shape_mpq_class.o:/usr/share/src/ppl-build/interfaces/C/../../src/ppl.hh:11187: more undefined references to `typeinfo for int' follow collect2: ld returned 1 exit status See how gcc now gives line numbers that show exactly were the undefined references may be located instead of just complaining that there are some, somewhere. Rob -- Summary: The Driver hides undefined reference messages from shared libs (but not object files) in linker phase Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: driver AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rob1weld at aol dot com GCC build triplet: * GCC host triplet: * GCC target triplet: * http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39439
[Bug ada/39138] Fix Copyright Dates Before 4.5.0 Branch (or sooner)
--- Comment #1 from rob1weld at aol dot com 2009-03-09 06:36 --- Also in contrib/test_summary : # (C) 1998, 1999, 2000, 2002 Free Software Foundation -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39138
[Bug lto/39279] [lto] - Werror in ../lto_trunk/gcc/lto/lto.c
--- Comment #1 from rob1weld at aol dot com 2009-03-09 06:40 --- Fix: /* munmap ((void *)computed_offset, computed_len); */ munmap ((caddr_t)computed_offset, computed_len); Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39279
[Bug bootstrap/39019] Solaris and IRIX libelf cause trouble for build
--- Comment #4 from rob1weld at aol dot com 2009-03-10 04:22 --- (In reply to comment #3) Dismal Testsuite results are here: http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg02284.html Rob Great results are here: http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg02375.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39019
[Bug libmudflap/38738] libmudflap could be enabled for Solaris when using GNU ld
--- Comment #4 from rob1weld at aol dot com 2009-03-10 04:27 --- (In reply to comment #3) (In reply to comment #1) MIRO: Mudflap Improved with Referent Objects - Works on OpenSolaris also. http://gcc.gnu.org/wiki/MIRO Results for gcc version 4.4.0 20080520 (experimental) [miro revision 144368] (GCC) testsuite on i386-pc-solaris2.11 http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg02215.html Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38738
[Bug lto/39317] [lto] - cannot compute suffix of object files - cannot represent relocation type BFD_RELOC_64
--- Comment #9 from rob1weld at aol dot com 2009-03-06 11:07 --- (In reply to comment #8) (In reply to comment #7) (In reply to comment #6) After the workaround we get 10 failures on i686 and 33 failures on x86_64 when compiling trunk revision 144629, results here: Results for 4.4.0 20090304 (experimental) [trunk revision 144629] (GCC) testsuite on i686-pc-linux-gnu http://gcc.gnu.org/ml/gcc-testresults/2009-03/msg00511.html Results for 4.4.0 20090304 (experimental) [trunk revision 144629] (GCC) testsuite on x86_64-unknown-linux-gnu http://gcc.gnu.org/ml/gcc-testresults/2009-03/msg00598.html Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39317
[Bug libstdc++/39382] New: FAIL: abi_check on trunk revision 144629
+++ This bug was initially created as a clone of Bug #38834 +++ abi_check is failing on Debian 5.0 (booted 32-Bit) with newer Kernel: # uname -a Linux debian 2.6.28-i386 #1 SMP PREEMPT Wed Mar 4 12:42:00 PST 2009 i686 GNU/Linux # /lib/libc.so.6 GNU C Library stable release version 2.7, by Roland McGrath et al. Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled by GNU CC version 4.3.2. Compiled on a Linux 2.6.26.1 system on 2009-01-04. Available extensions: crypt add-on version 2.1 by Michael Glad and others GNU Libidn by Simon Josefsson Native POSIX Threads Library by Ulrich Drepper et al BIND-8.2.3-T5B # gcc/xgcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc_trunk/configure --prefix=/mnt/drive2/gcc_installed --enable-languages=c,ada,c++,fortran,java,objc,obj-c++ --enable-multilib --disable-stage1-checking --enable-checking=release --with-gmp=/usr/local --with-mpfr=/usr/local Thread model: posix gcc version 4.4.0 20090304 (experimental) [trunk revision 144629] (GCC) === libstdc++ tests === Running target unix FAIL: abi_check XPASS: 26_numerics/headers/cmath/c99_classification_macros_c.cc (test for excess errors) Results for 4.4.0 20090304 (experimental) [trunk revision 144629] (GCC) testsuite on i686-pc-linux-gnu http://gcc.gnu.org/ml/gcc-testresults/2009-03/msg00511.html Rob -- Summary: FAIL: abi_check on trunk revision 144629 Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rob1weld at aol dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39382
[Bug bootstrap/39388] New: trunk revision 144629 - Multilibs missing
In trunk revision 144629 there is a large size discrepancy of _installed_ gcc depending on first part of triplet when building Multi-lib which is neither explained by size of executables nor differencing of the directories. To reproduce (on Debian Lenny 5.0): 1. Boot 32-Bit using Grub entry Debian GNU/Linux, kernel 2.6.xx-i386: 2. Configure and build gcc like this: # gcc/xgcc -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../gcc_trunk/configure --prefix=/mnt/drive2/gcc_installed --enable-languages=c,ada,c++,fortran,java,objc,obj-c++ --enable-multilib --disable-stage1-checking --enable-checking=release --with-gmp=/usr/local --with-mpfr=/usr/local 3. Boot 64-Bit using Grub entry Debian GNU/Linux, kernel 2.6.xx-amd64: 4. Configure and build gcc like this: # gcc/xgcc -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../gcc_trunk/configure --prefix=/mnt/drive2/gcc_installed_64 --enable-languages=c,ada,c++,fortran,java,objc,obj-c++ --enable-multilib --disable-stage1-checking --enable-checking=release --with-gmp=/usr/local --with-mpfr=/usr/local 5. Note that only the --prefix (and Boot Mode) is changed. Now check the sizes on the installed directories, see a BIG difference: # du -ah /mnt/drive2/gcc_build/ | tail -1 2.4G # du -ah /mnt/drive2/gcc_installed/ | tail -1 541M # du -ah /mnt/drive2/gcc_build_64/ | tail -1 3.9G/mnt/drive2/gcc_build_64/ # du -ah /mnt/drive2/gcc_installed_64/ | tail -1 931M/mnt/drive2/gcc_installed_64/ 6. Check why the installed sizes are so different: # find /mnt/drive2/gcc_installed/ | sort list_gcc_installed.txt # find /mnt/drive2/gcc_installed_64/ | sort list_gcc_installed_64.txt # diff -Naur list_gcc_installed.txt list_gcc_installed_64.txt list_gcc_installed_32vs64.txt 7. Now use Gedit (or other editor) to match up the directories and check why the sizes are so different. It seems that even though we use --enable-multilib we do not build the same alternate libraries in both Modes, we are lazier in the 32-Bit Mode. 8. The result is this: When we build gcc, with the OS in the 64-Bit Boot Mode, we also build a couple of 32 directories (but not others that maybe we should build). When we build gcc, with the OS in the 32-Bit Boot Mode, we fail to build some 64 directories and this results in an incomplete Multilib-version of gcc. I am not confused that a few more features are available in one Boot Mode or the other, nor that the size of the executables are going to be different, this has been taken into consideration. I examined the 'diffs' and see that we are building a x86_64-pc-linux-gnu/32/bits directory but no corresponding i686-pc-linux-gnu/64/bits directory. I examined the 'diffs' and see that we are building a x86_64-pc-linux-gnu/4.4.0/32 directory but no corresponding i686-pc-linux-gnu/4.4.0/32 directory. The x86_64-pc-linux-gnu/4.4.0/32/ directory ONLY contains: x86_64-pc-linux-gnu/4.4.0/32/adainclude/* x86_64-pc-linux-gnu/4.4.0/32/adalib/* x86_64-pc-linux-gnu/4.4.0/32/crt* and these _few_ files: x86_64-pc-linux-gnu/4.4.0/32/libgcc.a x86_64-pc-linux-gnu/4.4.0/32/libgcc_eh.a x86_64-pc-linux-gnu/4.4.0/32/libgcov.a x86_64-pc-linux-gnu/4.4.0/32/libgfortranbegin.a x86_64-pc-linux-gnu/4.4.0/32/libgfortranbegin.la where are the rest (of the libraries and alternate directories) for the multilibs on Platform i686-pc-linux-gnu ? See the attachment. Rob -- Summary: trunk revision 144629 - Multilibs missing Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rob1weld at aol dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39388
[Bug bootstrap/39388] trunk revision 144629 - Multilibs missing
--- Comment #1 from rob1weld at aol dot com 2009-03-05 22:23 --- Created an attachment (id=17402) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17402action=view) Edited diff of comparison between Multilibs produced -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39388
[Bug lto/39317] [lto] - cannot compute suffix of object files - cannot represent relocation type BFD_RELOC_64
--- Comment #8 from rob1weld at aol dot com 2009-03-05 22:59 ---
(In reply to comment #7)
(In reply to comment #6)
Broken: x86_64-pc-linux-gnu
Works: i686-pc-linux-gnu
Rob
Here is someone who had much better luck on 64-Bit (ia64-suse-linux-gnu):
Results for 4.4.0 20090218 (experimental) [lto revision 144462] (lto merged
with rev 144262) testsuite on ia64-suse-linux-gnu
http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg02766.html
Rob
I tried with the 'trunk' (instead of 'lto') and found the same issue.
Here is my Host Compiler and the head of it's 'spec':
# gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.2-1.1'
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3
--program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug
--enable-objc-gc --enable-mpfr --enable-targets=all --enable-cld
--enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu
--target=i486-linux-gnu
Thread model: posix
gcc version 4.3.2 (Debian 4.3.2-1.1)
# gcc -dumpspecs 21 | head -2
*asm:
%{v:-V} %{Qy:} %{!Qn:-Qy} %{n} %{T} %{Ym,*} %{Yd,*} %{Wa,*:%*} %{m32:--32}
%{m64:--64}
The workaround that I applied enabled me to compile gcc _without_ making
any changes to the source code. I utilized a bit of spec file magic
and a bit of Environment trickery.
1. Build and install gmp / mpfr in default location.
2. Set LD_LIBRARY_PATH=/usr/local/lib
3. Build gcc and it will fail here:
checking for suffix of object files... configure: error: in
`/mnt/drive2/gcc_build_64/x86_64-unknown-linux-gnu/libgcc':
configure: error: cannot compute suffix of object files: cannot compile
...
The config.log will say:
/tmp/cc21sHKa.s:35: Error: cannot represent relocation type BFD_RELOC_64
4. Fix your ../gcc_build/gcc/specs file so the top two lines are this:
*asm:
%{v:-V} %{Qy:} %{!Qn:-Qy} %{n} %{T} %{Ym,*} %{Yd,*} %{Wa,*:%*} %{m32:--32}
%{!m32:%{!m64:--64}} %{!mno-sse2avx:%{mavx:-msse2avx}}
%{msse2avx:%{!mavx:-msse2avx}}
(You may need to adjust it to suit your ./configure options. The important
part is to change %{m64:--64} to %{!m32:%{!m64:--64}} ).
5. Continue the make and it will fail here:
checking for x86_64-unknown-linux-gnu-gcc...
/mnt/drive2/gcc_build_64/./gcc/xgcc -B/mnt/drive2/gcc_build_64/./gcc/
-B/mnt/drive2/gcc_installed_64/x86_64-unknown-linux-gnu/bin/
-B/mnt/drive2/gcc_installed_64/x86_64-unknown-linux-gnu/lib/ -isystem
/mnt/drive2/gcc_installed_64/x86_64-unknown-linux-gnu/include -isystem
/mnt/drive2/gcc_installed_64/x86_64-unknown-linux-gnu/sys-include
checking for suffix of object files... configure: error: in
`/mnt/drive2/gcc_build_64/x86_64-unknown-linux-gnu/libgcc':
configure: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.
...
This time the config.log will not seem to indicate the problem but if
you add a -v to the gcc command that fails you will see that 'cc1'
is looking for libgmp in /usr/local/lib . If you use the file
command on 'xgcc' or the new 'cc1' you will find that they are 64-Bit
executables. Set 'LD_LIBRARY_PATH=/usr/local/lib64' and re-make.
6. When stage2 finishes and everything is moved to prev-gcc check
that you don't loose you 'spec' setting of %{!m32:%{!m64:--64}}
or you will need to type make again.
The build will complete without further intervention and without
having made any alterations to the trunk source code.
I grepped the trunk and found that some parts of some scripts do check
if one is using LD_LIBRARY_PATH_32 and LD_LIBRARY_PATH_64 but these
'unofficial' (and useful) Environment Variables are not used in all parts
of the gcc build -- thus the need to hand-alter your LD_LIBRARY_PATH as
the compiler second-stages itself and converts from a 32-Bit gcc (your
Host Compiler) and becomes a full-fledged 64-Bit executable.
Solution:
If the Makefile's $(SPECS) target would check that the dumpspecs
it is getting (from a prior version of gcc (the Host Compiler)) is
compatible with a 64 bit build (and fix it if needed) _and_ if
the scripts / Makefiles would toss a 64 on the tail of any
LD_LIBRARY_PATH paths as the compiler evolves from 32 to 64 bit
then it would all work without any intervention.
I'll leave it to _others_ to decide if gcc 4.4.x is a Regression for
not having their spec files suitable to build later revisions of gcc.
This revision of gcc (4.4.x) needs a 'sed' script to rewrite the 'spec'
file and do sanity checking. The scripts also need to 'promote' the
library directory path from 32 to 64 as the Compiler changes it's strips.
Rob
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39317
[Bug lto/39009] [LTO] ICE: in make_decl_rtl, at varasm.c:1288
--- Comment #2 from rob1weld at aol dot com 2009-03-02 11:00 --- (In reply to comment #1) Subject: Re: New: [LTO] ICE: in make_decl_rtl, at varasm.c:1288 Thanks for the bug reports. At this stage, I'm not sure if it's useful to file a bug report for every test in the GCC testsuite. These failures are highly visible already and there are about 1,200 of them, so having a separate bug report for each of them may be excessive. Diego. I was looking for 'dupes' and this is one of two Bugs I would have filed. Confirmed on i686-pc-linux-gnu (Debian 5.0). having a separate bug report for each of them may be excessive # grep make_decl_rtl,\ at\ varasm.c:1288 gcc.log.txt | wc -l 698 Fix this and we fix ~700 errors, likely resulting in the rest of gcc working better and shortening the mail considerably. In the same file we can sometimes get past that line and stuck on the next: # grep make_decl_rtl,\ at\ varasm.c:1295 gcc.log_20090218-601.txt | wc -l 24 The other errors are (for the most part): # grep output_expr_operand,\ at\ lto-function-out.c:1259 gcc.log | wc -l 39 # grep output_tree_with_context,\ at\ lto-function-out.c:3241 gcc.log | wc -l 20 Thanks, Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39009
[Bug lto/39317] [lto] - cannot compute suffix of object files - cannot represent relocation type BFD_RELOC_64
--- Comment #7 from rob1weld at aol dot com 2009-03-02 03:19 --- (In reply to comment #6) Broken: x86_64-pc-linux-gnu Works: i686-pc-linux-gnu Rob Here is someone who had much better luck on 64-Bit (ia64-suse-linux-gnu): Results for 4.4.0 20090218 (experimental) [lto revision 144462] (lto merged with rev 144262) testsuite on ia64-suse-linux-gnu http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg02766.html Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39317
[Bug middle-end/32258] Testsuite reports - FAIL: gcc.dg/torture/builtin-pow-mpfr-1.c
--- Comment #21 from rob1weld at aol dot com 2009-02-28 14:10 --- (In reply to comment #20) Created an attachment (id=13766) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13766action=view) [edit] Patch main configure script to use mpfr 2.2.1, also detect mpfr library and header version mismatch - submitted to gcc-patc...@gcc.gnu.org This also affects 'lto' (since the patch submitted was never applied). # gcc/xgcc -v Using built-in specs. COLLECT_GCC=gcc/xgcc Target: x86_64-unknown-linux-gnu Configured with: ../lto_trunk/configure --prefix=/usr/local/lto --enable-languages=lto,c++ --enable-multilib --disable-stage1-checking --enable-checking=release --with-gmp=/usr/local --with-mpfr=/usr/local Thread model: posix gcc version 4.4.0 20090218 (experimental) [lto revision 144460] (lto merged with rev 144262) # touch delete.c # gcc/xgcc -v -I/usr/local/include -B/usr/src/lto_build/prev-gcc/ delete.c 21 | head -29 | tail #include ... search starts here: /usr/src/lto_build/./prev-gcc/include /usr/src/lto_build/./prev-gcc/include-fixed /usr/local/include /usr/include End of search list. GNU C (lto merged with rev 144262) version 4.4.0 20090218 (experimental) [lto revision 144460] (x86_64-unknown-linux-gnu) compiled by GNU C version 4.3.2, GMP version 4.2.4, MPFR version 2.4.1-p1. warning: GMP header version 4.2.4 differs from library version 4.2.2. warning: MPFR header version 2.4.1-p1 differs from library version 2.3.1. Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32258
[Bug lto/39317] [lto] - cannot compute suffix of object files - cannot represent relocation type BFD_RELOC_64
--- Comment #6 from rob1weld at aol dot com 2009-02-28 17:34 --- I rebooted Debian and chose the 32-bit Kernel, then re-configured in an _identical_ manner. I rebuilt gcc (using un-modified source) with no extra effort with the 32-Bit Kernel. Host Compiler: # gcc -v Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.2-1.1' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-targets=all --enable-cld --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu Thread model: posix gcc version 4.3.2 (Debian 4.3.2-1.1) Broken on 64-bit: # gcc/xgcc -v Using built-in specs. COLLECT_GCC=gcc/xgcc Target: x86_64-pc-linux-gnu Configured with: ../lto_trunk/configure --prefix=/usr/local/lto --enable-languages=lto,c++ --enable-multilib --disable-stage1-checking --enable-checking=release --with-gmp=/usr/local --with-mpfr=/usr/local Thread model: posix gcc version 4.4.0 20090218 (experimental) [lto revision 144460] (lto merged with rev 144262) Works on 32-bit: # gcc/xgcc -v Using built-in specs. COLLECT_GCC=gcc/xgcc Target: i686-pc-linux-gnu Configured with: ../lto_trunk/configure --prefix=/usr/local/lto --enable-languages=lto,c++ --enable-multilib --disable-stage1-checking --enable-checking=release --with-gmp=/usr/local --with-mpfr=/usr/local Thread model: posix gcc version 4.4.0 20090218 (experimental) [lto revision 144460] (lto merged with rev 144262) Broken: x86_64-pc-linux-gnu Works: i686-pc-linux-gnu Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39317
[Bug lto/39317] [lto] - cannot compute suffix of object files - cannot represent relocation type BFD_RELOC_64
--- Comment #5 from rob1weld at aol dot com 2009-02-28 03:53 ---
(In reply to comment #4)
In addition to the lack of -L... this is also a 'spec' issue :
...
The issue with the spec file is caused by this in the Makefile.in:
# Dump a specs file to make -B./ read these specs over installed ones.
$(SPECS): xgcc$(exeext)
$(GCC_FOR_TARGET) -dumpspecs tmp-specs
mv tmp-specs $(SPECS)
Debian's supplied gcc 4.3 is built androgynous:
# gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.2-1.1'
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3
--program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug
--enable-objc-gc --enable-mpfr --enable-targets=all --enable-cld
--enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu
--target=i486-linux-gnu
Thread model: posix
gcc version 4.3.2 (Debian 4.3.2-1.1)
# gcc -dumpspecs | head -2
*asm:
%{v:-V} %{Qy:} %{!Qn:-Qy} %{n} %{T} %{Ym,*} %{Yd,*} %{Wa,*:%*} %{m32:--32}
%{m64:--64}
We need to check that the host-compiler's spec is correct and fix it.
Here is some pseudo-code:
if ' gcc -dumpspecs | grep \{m32:--32 | grep \{m64:--64 ' then # not correct
if test x`(hostname || uname -n) 2/dev/null | sed 1q` == xopensolaris ;
then
if 'isainfo -k' = 'i386' then
gcc -dumpspecs | sed 2s/m32:--32/!m32:--32/1p
fi
if 'isainfo -k' = 'amd_64' | 'x86_64' then
gcc -dumpspecs | sed 2s/m64:--64/!m64:--64/1p
fi
else # Not OpenSolaris' uname
if 'uname -m' = 'i386' then
gcc -dumpspecs | sed 2s/m32:--32/!m32:--32/1p
fi
if 'uname -m' = 'amd_64' | 'x86_64' then
gcc -dumpspecs | sed 2s/m64:--64/!m64:--64/1p
fi
fi
fi
Rob
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39317
[Bug bootstrap/39316] New: [lto] revision 144454 - Configure should check for elf support (similar to gmp/mpfr/PPL/CLooG)
It is my Request for Enhancement that the 'Configury' detect if there is enough elf support to build gcc - in a similar manner that gmp, mpfr, PPL and CLooG are tested for. The configury is waiting until it gets past configuring the gcc directory, and even detecting that gelf.h is not present, before the build fails. This Operating System (Debian GNU/Linux) does have /usr/include/elf.h in a default installation but is 'lacking enough elf' to build without failing. This should be checked in ../lto_trunk/configure . # make ... Configuring stage 1 in ./gcc configure: creating cache ./config.cache checking build system type... x86_64-unknown-linux-gnu ... checking for pthread.h... yes checking for libelf.h... no checking for libelf/libelf.h... no checking for gelf.h... no checking for libelf/gelf.h... no checking for CHAR_BIT... yes ... make[3]: Entering directory `/usr/src/lto_build/lto-plugin' if /bin/sh ./libtool --tag=CC --mode=compile gcc -DPACKAGE_NAME=\LTO\ plugin\ for\ ld\ -DPACKAGE_TARNAME=\lto-plugin\ -DPACKAGE_VERSION=\0.1\ -DPACKAGE_STRING=\LTO\ plugin\ for\ ld\ 0.1\ -DPACKAGE_BUGREPORT=\\ -DPACKAGE=\lto-plugin\ -DVERSION=\0.1\ -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\.libs/\ -I. -I../../lto_trunk/lto-plugin -I../../lto_trunk/lto-plugin/../include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -Wall -Werror -g -fkeep-inline-functions -MT lto-plugin.lo -MD -MP -MF .deps/lto-plugin.Tpo -c -o lto-plugin.lo ../../lto_trunk/lto-plugin/lto-plugin.c; \ then mv -f .deps/lto-plugin.Tpo .deps/lto-plugin.Plo; else rm -f .deps/lto-plugin.Tpo; exit 1; fi libtool: compile: gcc -DPACKAGE_NAME=\LTO plugin for ld\ -DPACKAGE_TARNAME=\lto-plugin\ -DPACKAGE_VERSION=\0.1\ -DPACKAGE_STRING=\LTO plugin for ld 0.1\ -DPACKAGE_BUGREPORT=\\ -DPACKAGE=\lto-plugin\ -DVERSION=\0.1\ -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\.libs/\ -I. -I../../lto_trunk/lto-plugin -I../../lto_trunk/lto-plugin/../include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -Wall -Werror -g -fkeep-inline-functions -MT lto-plugin.lo -MD -MP -MF .deps/lto-plugin.Tpo -c ../../lto_trunk/lto-plugin/lto-plugin.c -fPIC -DPIC -o .libs/lto-plugin.o ../../lto_trunk/lto-plugin/lto-plugin.c:56:4: error: #error gelf.h not available ../../lto_trunk/lto-plugin/lto-plugin.c:170: error: expected =, ,, ;, asm or __attribute__ before * token ... ../../lto_trunk/lto-plugin/lto-plugin.c:619: error: EV_NONE undeclared (first use in this function) make[3]: *** [lto-plugin.lo] Error 1 make[3]: Leaving directory `/usr/src/lto_build/lto-plugin' make[2]: *** [all-stage1-lto-plugin] Error 2 make[2]: Leaving directory `/usr/src/lto_build' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/usr/src/lto_build' make: *** [all] Error 2 # ls -l /usr/include/elf.h -rw-r--r-- 1 root root 110896 2009-01-04 10:10 /usr/include/elf.h # ls -l /usr/include/gelf.h ls: cannot access /usr/include/gelf.h: No such file or directory # locate gelf.h (Nothing printed) # locate elf.h /usr/include/elf.h /usr/include/linux/elf.h /usr/include/sys/elf.h # gcc/xgcc -v Using built-in specs. COLLECT_GCC=gcc/xgcc Target: x86_64-unknown-linux-gnu Configured with: ../lto_trunk/configure --prefix=/usr/local/lto --enable-languages=lto,c++ --enable-stage1-checking=all --enable-checking=release Thread model: posix gcc version 4.4.0 20090218 (experimental) [lto revision 144454] (lto merged with rev 144262) -- Summary: [lto] revision 144454 - Configure should check for elf support (similar to gmp/mpfr/PPL/CLooG) Product: gcc Version: lto Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rob1weld at aol dot com GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39316
[Bug libstdc++/39238] trunk revision 144279 - cfenv:54: error: �::fenv_t� has not been declared
--- Comment #6 from rob1weld at aol dot com 2009-02-26 23:01 --- (In reply to comment #5) Any chance you could narrow this down? The revision stated as problematic has nothing to do with libstdc++. The file implicated, cfenv, has not had a change in 3 months. Was this a temporary blip? If so, please close. If not, please provide some more detail. I am fairly convinced that this blip was a manifestation of the Build Machinery's confusion resulting from Linker issues that are best handled in the URL given in Comment #4 . I will close this since fixing the other Bug seems to make this unreproducible. Rob -- rob1weld at aol dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39238
[Bug bootstrap/39316] [lto] revision 144454 - Configure should check for elf support (similar to gmp/mpfr/PPL/CLooG)
--- Comment #1 from rob1weld at aol dot com 2009-02-26 23:44 --- This Bug Report is about the failure to detect that the proper headers and libraries are present _before_ building can be attempted. Even after the extra effort to install libelf (to ensure that the scripts would work) still results in the same error message: # locate gelf.h /usr/local/include/gelf.h /usr/local/include/libelf/gelf.h /usr/src/libelf-0.8.10/lib/gelf.h but there is already a report made for _after_ installing libelf: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39019 Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39316
[Bug lto/39317] New: [lto] - cannot compute suffix of object files - cannot represent relocation type BFD_RELOC_64
# uname -a Linux debian 2.6.26-1-amd64 #1 SMP Sat Jan 10 19:55:48 UTC 2009 x86_64 GNU/Linux # gcc/xgcc -v Using built-in specs. COLLECT_GCC=gcc/xgcc Target: x86_64-unknown-linux-gnu Configured with: ../lto_trunk/configure --prefix=/usr/local/lto --enable-languages=lto,c++ --enable-multilib --enable-stage1-checking=all --enable-checking=release CPPFLAGS=-I/usr/local/include Thread model: posix gcc version 4.4.0 20090218 (experimental) [lto revision 144454] (lto merged with rev 144262) # make ... make[3]: Leaving directory `/usr/src/lto_build/lto-plugin' mkdir -p -- x86_64-unknown-linux-gnu/libgcc Checking multilib configuration for libgcc... Configuring stage 1 in x86_64-unknown-linux-gnu/libgcc configure: creating cache ./config.cache checking for --enable-version-specific-runtime-libs... no checking for a BSD-compatible install... /usr/bin/install -c checking for gawk... gawk checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu checking for x86_64-unknown-linux-gnu-ar... ar checking for x86_64-unknown-linux-gnu-lipo... lipo checking for x86_64-unknown-linux-gnu-nm... /usr/src/lto_build/./gcc/nm checking for x86_64-unknown-linux-gnu-ranlib... ranlib checking for x86_64-unknown-linux-gnu-strip... strip checking whether ln -s works... yes checking for x86_64-unknown-linux-gnu-gcc... /usr/src/lto_build/./gcc/xgcc -B/usr/src/lto_build/./gcc/ -B/usr/local/lto/x86_64-unknown-linux-gnu/bin/ -B/usr/local/lto/x86_64-unknown-linux-gnu/lib/ -isystem /usr/local/lto/x86_64-unknown-linux-gnu/include -isystem /usr/local/lto/x86_64-unknown-linux-gnu/sys-include checking for suffix of object files... configure: error: in `/usr/src/lto_build/x86_64-unknown-linux-gnu/libgcc': configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details. make[2]: *** [configure-stage1-target-libgcc] Error 1 make[2]: Leaving directory `/usr/src/lto_build' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/usr/src/lto_build' make: *** [all] Error 2 The config.log says: ... xgcc: '-V' must come at the start of the command line configure:2396: $? = 1 configure:2415: /usr/src/lto_build/./gcc/xgcc -B/usr/src/lto_build/./gcc/ -B/usr/local/lto/x86_64-unknown-linux-gnu/bin/ -B/usr/local/lto/x86_64-unknown-linux-gnu/lib/ -isystem /usr/local/lto/x86_64-unknown-linux-gnu/include -isystem /usr/local/lto/x86_64-unknown-linux-gnu/sys-include -o conftest -g -O2 conftest.c 5 /tmp/ccEBgRfq.s: Assembler messages: /tmp/ccEBgRfq.s:35: Error: cannot represent relocation type BFD_RELOC_64 /tmp/ccEBgRfq.s:36: Error: cannot represent relocation type BFD_RELOC_64 /tmp/ccEBgRfq.s:44: Error: cannot represent relocation type BFD_RELOC_64 /tmp/ccEBgRfq.s:45: Error: cannot represent relocation type BFD_RELOC_64 /tmp/ccEBgRfq.s:123: Error: cannot represent relocation type BFD_RELOC_64 configure:2418: $? = 1 configure:2590: checking for suffix of object files ... This is similar to the problem described in these Bug Reports: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38743 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38804 Andrew has some input on fixing these type of problems, here: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38804#c4 (and c5) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38743#c2 Thanks, Rob -- Summary: [lto] - cannot compute suffix of object files - cannot represent relocation type BFD_RELOC_64 Product: gcc Version: lto Status: UNCONFIRMED Severity: major Priority: P3 Component: lto AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rob1weld at aol dot com GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39317
[Bug lto/39317] [lto] - cannot compute suffix of object files - cannot represent relocation type BFD_RELOC_64
--- Comment #3 from rob1weld at aol dot com 2009-02-27 01:29 --- I'm running Debian Lenny 5.0 released 14 Feb 2009, with updates. # ld --version GNU ld (GNU Binutils for Debian) 2.18.0.20080103 # as --version GNU assembler (GNU Binutils for Debian) 2.18.0.20080103 Simply tossing in an -m64 alerts us to another issue: # /usr/src/lto_build/./gcc/xgcc -B/usr/src/lto_build/./gcc/ -B/usr/local/lto/x86_64-unknown-linux-gnu/bin/ -B/usr/local/lto/x86_64-unknown-linux-gnu/lib/ -isystem /usr/local/lto/x86_64-unknown-linux-gnu/include -isystem /usr/local/lto/x86_64-unknown-linux-gnu/sys-include -o conftest -g -O2 -m64 test_delete.c /usr/bin/ld: crtbegin.o: No such file: No such file or directory collect2: ld returned 1 exit status but (with the default installation of Debian's gcc version 4.3.2 (Debian 4.3.2-1.1) ), a workaround is to add this to the file ../lto_trunk/libgcc/configure: -m64 -L/usr/lib/gcc/i486-linux-gnu/4.3/64 That ensures we can access crt*.o and libgcc*, etc., for Linking. Once I get it built, for the first time on this Platform, I will go back and determine correct fixes and try to produce cross-Platform compatible patches. Thanks, Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39317
[Bug lto/39317] [lto] - cannot compute suffix of object files - cannot represent relocation type BFD_RELOC_64
--- Comment #4 from rob1weld at aol dot com 2009-02-27 06:08 ---
# uname -m
x86_64
In addition to the lack of -L... this is also a 'spec' issue :
Original (head -2 ../lto_build/prev-gcc/specs) :
*asm:
%{v:-V} %{Qy:} %{!Qn:-Qy} %{n} %{T} %{Ym,*} %{Yd,*} %{Wa,*:%*} %{m32:--32}
%{m64:--64} %{!mno-sse2avx:%{mavx:-msse2avx}} %{msse2avx:%{!mavx:-msse2avx}}
Fixed:
*asm:
%{v:-V} %{Qy:} %{!Qn:-Qy} %{n} %{T} %{Ym,*} %{Yd,*} %{Wa,*:%*} %{m32:--32}
%{!m64:--64} %{!mno-sse2avx:%{mavx:-msse2avx}} %{msse2avx:%{!mavx:-msse2avx}}
If I am:
# uname -m
x86_64
I need the ! before the m64.
If I am:
# uname -m
i386
I need the ! before the m32.
That defaults the compiler to build executables that match the
Boot-mode (32 or 64 bit). To build in the mode _not_ booted into
should require the appropriate -m64 _OR_ -m32. We should not
be required to _always_ specify either -m64 _OR_ -m32, there
must be a default.
Rob
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39317
[Bug c/39276] [lto] - Testsuite gcc.log shows many getconf: Invalid argument (_NPROCESSORS_ONLN)
--- Comment #5 from rob1weld at aol dot com 2009-02-24 16:53 --- On OpenSolaris 2009.06 (snv_106) I get improved results with the Patch. Before my Patch (awful, posted for comparison purposes only): Results for 4.4.0 20090218 (experimental) [lto revision 144375] (lto merged with rev 144262) testsuite on i386-pc-solaris2.11 http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg02284.html === gcc Summary === # of expected passes 59196 # of unexpected failures 3865 # of unexpected successes 4 # of expected failures 186 # of unresolved testcases 2405 # of unsupported tests 564 - After my Patch: Results for 4.4.0 20090218 (experimental) [lto revision 144375] (lto merged with rev 144262) testsuite on i386-pc-solaris2.11 (Patched) http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg02375.html === gcc Summary === # of expected passes64141 # of unexpected failures1201 # of unexpected successes 4 # of expected failures 186 # of unresolved testcases 115 # of unsupported tests 564 Rob -- rob1weld at aol dot com changed: What|Removed |Added Component|driver |c http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39276
[Bug bootstrap/39019] Solaris and IRIX libelf cause trouble for build
--- Comment #3 from rob1weld at aol dot com 2009-02-23 14:52 --- Dismal Testsuite results are here: http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg02284.html Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39019
[Bug c/39276] New: [lto] - Testsuite gcc.log shows many getconf: Invalid argument (_NPROCESSORS_ONLN)
# gcc/xgcc -v Using built-in specs. COLLECT_GCC=gcc/xgcc Target: i386-pc-solaris2.11 Configured with: ../lto_trunk/configure --prefix=/usr/local/lto --enable-languages=lto,c++ --enable-shared --disable-static --enable-multilib --with-gnu-as --with-as=/usr/local/bin/as --with-gnu-ld --with-ld=/usr/local/bin/ld --with-gmp=/usr/local --with-mpfr=/usr/local --without-ppl Thread model: posix gcc version 4.4.0 20090218 (experimental) [lto revision 144375] (lto merged with rev 144262) The Testsuite gcc.log shows many getconf: Invalid argument (_NPROCESSORS_ONLN) errors. Here is one example: PASS: gcc.c-torture/execute/builtins/20010124-1.c execution, -O0 -flto Executing on host: /usr/share/src/lto_build/gcc/xgcc -B/usr/share/src/lto_build/gcc/ /usr/share/src/lto_trunk/gcc/testsuite/gcc.c-torture/execute/builtins/20010124-1.c /usr/share/src/lto_trunk/gcc/testsuite/gcc.c-torture/execute/builtins/20010124-1-lib.c /usr/share/src/lto_trunk/gcc/testsuite/gcc.c-torture/execute/builtins/lib/main.c -w -O0 -fwhopr -lm -o /usr/share/src/lto_build/gcc/testsuite/gcc/20010124-1.x1(timeout = 300) getconf: Invalid argument (_NPROCESSORS_ONLN) /usr/share/src/lto_build/gcc/ltrans-driver[99]: [: argument expected output is: getconf: Invalid argument (_NPROCESSORS_ONLN) /usr/share/src/lto_build/gcc/ltrans-driver[99]: [: argument expected FAIL: gcc.c-torture/execute/builtins/20010124-1.c compilation, -O0 -fwhopr UNRESOLVED: gcc.c-torture/execute/builtins/20010124-1.c execution, -O0 -fwhopr On Solaris if you execute this, you get this: # /usr/bin/getconf _NPROCESSORS_ONLN getconf: Invalid argument (_NPROCESSORS_ONLN) # /usr/xpg4/bin/getconf _NPROCESSORS_ONLN getconf: Invalid argument (_NPROCESSORS_ONLN) But, if you execute this, you get this: # /bin/ksh93 -c getconf | grep NPROCESSORS_ONLN NPROCESSORS_ONLN=1 # /bin/ksh93 -c getconf NPROCESSORS_ONLN 1 The last result is probably what is wanted. Rob -- Summary: [lto] - Testsuite gcc.log shows many getconf: Invalid argument (_NPROCESSORS_ONLN) Product: gcc Version: lto Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rob1weld at aol dot com GCC build triplet: i386-pc-solaris2.11 GCC host triplet: i386-pc-solaris2.11 GCC target triplet: i386-pc-solaris2.11 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39276
