[Bug java/26390] Problem dispatching method call when method does not exist in superclass
--- Comment #12 from rob1weld at aol dot com 2006-12-28 15:45 --- (In reply to comment #11) Fix checked in. I'm not an expert with Java but am trying to compile gcc 4_2 branch (CVS) and I have the same problem as is described in this bug report. The fixes mentioned in this report _seem_ to have been applied but am getting a 'similar' error message: Here is the part of the make where it fails: /bin/sh ./libtool --mode=compile /cygdrive/c/gcc-4_2-branch-build/gcc/gcj -B/cygdrive/c/gcc-4_2-branch-build/athlon_xp-pc-cygwin/libjava/ -B/cygdrive/c/gcc-4_2-branch-build/gcc/ -ffloat-store -fomit-frame-pointer -fclasspath= -fbootclasspath=/cygdrive/c/gcc-4_2-branch-build/athlon_xp-pc-cygwin/libjava/classpath/lib --encoding=UTF-8 -Wno-deprecated -fbootstrap-classes -g -O2 -fjni -findirect-dispatch -fno-indirect-classes -c -o gnu-java-awt-peer-swing.lo @gnu-java-awt-peer-swing.list /cygdrive/c/gcc-4_2-branch-build/gcc/gcj -B/cygdrive/c/gcc-4_2-branch-build/athlon_xp-pc-cygwin/libjava/ -B/cygdrive/c/gcc-4_2-branch-build/gcc/ -ffloat-store -fomit-frame-pointer -fclasspath= -fbootclasspath=/ cygdrive/c/gcc-4_2-branch-build/athlon_xp-pc-cygwin/libjava/classpath/lib --encoding=UTF-8 -Wno-deprecate d -fbootstrap-classes -g -O2 -fjni -findirect-dispatch -fno-indirect-classes -c @gnu-java-awt-peer-swing.list -o gnu-java-awt-peer-swing.o gnu/java/awt/peer/swing/SwingFramePeer.java: In class 'gnu.java.awt.peer.swing.SwingFramePeer': gnu/java/awt/peer/swing/SwingFramePeer.java: In method 'gnu.java.awt.peer.swing.SwingFramePeer.setBounds(int,int,int,int)': gnu/java/awt/peer/swing/SwingFramePeer.java:118: error: verification failed at PC=6: didn't see expected constant make[3]: *** [gnu-java-awt-peer-swing.lo] Error 1 make[3]: Target `all-am' not remade because of errors. make[3]: Leaving directory `/cygdrive/c/gcc-4_2-branch-build/athlon_xp-pc-cygwin/libjava' I'll leave any 'fixing' to someone more expert at java (so I don't break gcc somewhere else :( ). I tried changing to above to simply use system's gcj: gcj -c -o gnu-java-awt-peer-swing.lo @gnu-java-awt-peer-swing.list This is the message I got: gnu/java/awt/peer/swing/SwingFramePeer.java: In class 'gnu.java.awt.peer.swing.SwingFramePeer': gnu/java/awt/peer/swing/SwingFramePeer.java: In method 'gnu.java.awt.peer.swing.SwingFramePeer.setBounds(int,int,int,int)': gnu/java/awt/peer/swing/SwingFramePeer.java:118: error: verification failed at PC=6: didn't see expected constant gnu/java/awt/peer/swing/SwingFramePeer.java:118: error: class 'java.awt.peer.WindowPeer' has no method named 'setBounds' matching signature '()V' gnu/java/awt/peer/swing/SwingFramePeer.java:119: confused by earlier errors, bailing out -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26390
[Bug bootstrap/30341] New: Makefile using mv instead of ln not working on WinXP Cygwin Bash
; \ set stage1-libdecnumber libdecnumber ; \ ln -s $$1 $$2 @cd $(HOST_SUBDIR); [ -d stage1-libiberty ] || \ mkdir stage1-libiberty; \ set stage1-libiberty libiberty ; \ ln -s $$1 $$2 @cd $(HOST_SUBDIR); [ -d stage1-zlib ] || \ mkdir stage1-zlib; \ set stage1-zlib zlib ; \ ln -s $$1 $$2 stage1-end:: @rm -f stage_current @cd $(HOST_SUBDIR); set gcc stage1-gcc ; \ rm -f $$1 @cd $(HOST_SUBDIR); set intl stage1-intl ; \ rm -f $$1 @cd $(HOST_SUBDIR); set libcpp stage1-libcpp ; \ rm -f $$1 @cd $(HOST_SUBDIR); set libdecnumber stage1-libdecnumber ; \ rm -f $$1 @cd $(HOST_SUBDIR); set libiberty stage1-libiberty ; \ rm -f $$1 @cd $(HOST_SUBDIR); set zlib stage1-zlib ; \ rm -f $$1 # Bubble a bugfix through all the stages up to stage 1. They are -- Summary: Makefile using mv instead of ln not working on WinXP Cygwin Bash Product: gcc Version: 4.2.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-cygwin GCC host triplet: i686-pc-cygwin GCC target triplet: i686-pc-cygwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30341
[Bug bootstrap/30342] New: Tough time building 4.2.0 (CVS) on WinXP with Cygwin
/LOCALS~1/Temp/ccDK0dpQ.i:8 8 /cygdrive/c/DOCUME~1/HP_ADM~1/LOCALS~1/Temp/ccDK0dpQ.i: No such file or directory. in /cygdrive/c/DOCUME~1/HP_ADM~1/LOCALS~1/Temp/ccDK0dpQ.i (gdb) Notice that gdb thinks it is running /cygdrive/c/DOCUME~1/HP_ADM~1/LOCALS~1/Temp/ccDK0dpQ.i. That is the output from jvgenmain, not collect2 (which is last in the chain). I don't know a lot about java but it looks as though it is confused about it's name and trying to dynamically load the wrong name. The compile and linking seem OK (often) when I run make check but the execution tests often (but not always) fail. This gives a lot of fails for java and the summary does not distinguish between fail modes. -- After all that everything works fairly well. There are very few errors in c even less with fortran, not tooo many elsewhere and ada won't compile (yet!). I hope I have encouraged some WinXP cygwin users to try a compile and submit a report of your results so gcc will be better for this platform. YT, Rob -- Summary: Tough time building 4.2.0 (CVS) on WinXP with Cygwin Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rob1weld at aol dot com GCC build triplet: i686-pc-cygwin GCC host triplet: i686-pc-cygwin GCC target triplet: i686-pc-cygwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30342
[Bug bootstrap/30342] Tough time building 4.2.0 (CVS) on WinXP with Cygwin
--- Comment #2 from rob1weld at aol dot com 2007-01-12 05:12 --- Thank you kindly for your comments and e-mails everyone. Firstly, I am NOT building in the source directory. My result (as of a while ago) for libmudflap are: === libmudflap Summary === # of expected passes 1194 # of unexpected failures 588 Complete result (for an OLD build) are here: http://gcc.gnu.org/ml/gcc-testresults/2007-01/msg00052.html I since have it working so well I can type make check (without the -k) and I am able to type make install with only a single warning. I removed some of the fancy optimization parameters from the CFLAGS I was building with and built a less optimized but more stable bootstrap. The extra optimizations worked well for the most part but Ada did not enjoy them. My patch for gomp (as you refer to it) is simply to enable it in the ./configure script - I did NOT change one line of the source for gomp. Mmap does NOT work when compiling java with the flags _I_ was using. The error I was getting was java.io.IOException: mmap not implemented and that was with the CVS AS-IS, with no changes. Much of mmap DOES work but __some__ portion of it does not work with a small portion of java (on the particular day I obtained the CVS and then built it - it _might_ be OK now - I'll try re-enabling it). I have a newer build that I will post the results of shortly. Nearly everything is nearly OK - except the pch (which _I_ don't use) doesn't pass many tests. I do have the newest cygwin and do check their site for updates. Thanks again to everyone who read my post. I hope more people are encouraged to try a WinXP cygwin build of 4.2.0 and post the (FULL) test results. Please note (with the CVS from a few days ago) that make check misses some things. To get all the logs you need to type: make check make check-target-boehm-gc make check-target-libffi make check-target-libgomp make check-target-libmudflap make check-target-zlib -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30342
[Bug libobjc/30445] New: Fix for FIXME in gcc-4_2-branch/libobjc/Makefile.in
/makecygwin/gcc-4_2-branch/libobjc/../boehm-gc/include -I../boehm-gc/include /cygdrive/C/makecygwin/gcc-4_2-branch/libobjc/libobjc_entry.c -o libobjc_entry.o /cygdrive/C/makecygwin/gcc-4_2-branch/libobjc/libobjc_entry.c: In function 'DllMain': /cygdrive/C/makecygwin/gcc-4_2-branch/libobjc/libobjc_entry.c:34: warning: unused parameter 'hInst' /cygdrive/C/makecygwin/gcc-4_2-branch/libobjc/libobjc_entry.c:35: warning: unused parameter 'lpReserved' /cygdrive/c/gcc-4_2-branch-build/./gcc/xgcc -B/cygdrive/c/gcc-4_2-branch-build/./gcc/ -B/usr/athlon_xp-pc-cygwin/bin/ -B/usr/athlon_xp-pc-cygwin/lib/ -isystem /usr/athlon_xp-pc-cygwin/include -isystem /usr/athlon_xp-pc-cygwin/sys-include -mdll -Wl,--base-file -Wl,libobjc.base \ -o libobjc.dll libobjc_s.a libobjc_entry.o -lkernel32 -lobjc dlltool --dllname libobjc.dll --def /cygdrive/C/makecygwin/gcc-4_2-branch/libobjc/libobjc.def \ --base-file libobjc.base --output-exp libobjc.exp /cygdrive/c/gcc-4_2-branch-build/gcc/xgcc -B/cygdrive/c/cygwin/lib/gcc/athlon_xp-pc-cygwin/4.1.1/ -B/cygdrive/c/gcc-4_2-branch-build/gcc/ -B/usr/athlon_xp-pc-cygwin/bin/ -B/usr/athlon_xp-pc-cygwin/lib/ -isystem /usr/athlon_xp-pc-cygwin/include -isystem /usr/athlon_xp-pc-cygwin/sys-include -mdll -Wl,--base-file libobjc.base libobjc.exp \ -o libobjc.dll libobjc_s.a libobjc_entry.o -lkernel32 -lobjc dlltool --dllname libobjc.dll --def /cygdrive/C/makecygwin/gcc-4_2-branch/libobjc/libobjc.def \ --base-file libobjc.base --output-exp libobjc.exp /cygdrive/c/gcc-4_2-branch-build/gcc/xgcc -B/cygdrive/c/cygwin/lib/gcc/athlon_xp-pc-cygwin/4.1.1/ -B/cygdrive/c/gcc-4_2-branch-build/gcc/ -B/usr/athlon_xp-pc-cygwin/bin/ -B/usr/athlon_xp-pc-cygwin/lib/ -isystem /usr/athlon_xp-pc-cygwin/include -isystem /usr/athlon_xp-pc-cygwin/sys-include libobjc.exp -mdll \ -o libobjc.dll libobjc_s.a libobjc_entry.o -lkernel32 -lobjc dlltool --dllname libobjc.dll --def /cygdrive/C/makecygwin/gcc-4_2-branch/libobjc/libobjc.def \ --output-lib libobjc.a Note: You DO need to define DLLTOOL and GCC_FOR_TARGET since neither is defined and you MUST use 4.1.1's libobjc.a since 4.2.0's libobjc.a does not seem to have the hash_* functions. Failing to add -B/cygdrive/c/cygwin/lib/gcc/athlon_xp-pc-cygwin/4.1.1/ (or wherever the gcc 4.1.1 libobjc.a file is on YOUR system) gives these errors: libobjc.exp:fake:(.edata+0xb0): undefined reference to `_hash_add' libobjc.exp:fake:(.edata+0xb4): undefined reference to `_hash_delete' libobjc.exp:fake:(.edata+0xb8): undefined reference to `_hash_is_key_in_hash' libobjc.exp:fake:(.edata+0xbc): undefined reference to `_hash_new' libobjc.exp:fake:(.edata+0xc0): undefined reference to `_hash_next' libobjc.exp:fake:(.edata+0xc4): undefined reference to `_hash_remove' libobjc.exp:fake:(.edata+0xc8): undefined reference to `_hash_value_for_key' It may be an omission in the gcc-4_2-branch CVS that these functions are unavailable. They are mentioned in the source code in file gcc-4_2-branch/libobjc/libobjc.def and nowhere else. I imagine we need to add these functions from 4.1.1 so 4.2.0 will be able to make this .dll . -- Summary: Fix for FIXME in gcc-4_2-branch/libobjc/Makefile.in Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: libobjc AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rob1weld at aol dot com GCC build triplet: i686-pc-cygwin GCC host triplet: i686-pc-cygwin GCC target triplet: i686-pc-cygwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30445
[Bug java/30448] New: libjava configure script mix up with .c / .java using gcj /gcc
:6654: cc -c conftest.c 5 configure:6657: $? = 0 configure:6660: cc -c conftest.c -o conftest.o 5 configure:6663: $? = 0 configure:6665: cc -c conftest.c -o conftest.o 5 configure:6668: $? = 0 configure:6686: result: yes configure:6867: checking for exception model to use configure:6926: result: sjlj configure:7075: checking how to run the C preprocessor configure:7110: /cygdrive/c/gcc-4_2-branch-build/./gcc/xgcc -B/cygdrive/c/gcc-4_2-branch-build/./gcc/ -B/usr/i686-pc-cygwin/bin/ -B/usr/i686-pc-cygwin/lib/ -isystem /usr/i686-pc-cygwin/include -isystem /usr/i686-pc-cygwin/sys-include -E conftest.c configure:7116: $? = 0 configure:7148: /cygdrive/c/gcc-4_2-branch-build/./gcc/xgcc -B/cygdrive/c/gcc-4_2-branch-build/./gcc/ -B/usr/i686-pc-cygwin/bin/ -B/usr/i686-pc-cygwin/lib/ -isystem /usr/i686-pc-cygwin/include -isystem /usr/i686-pc-cygwin/sys-include -E conftest.c conftest.c:22:28: error: ac_nonexistent.h: No such file or directory configure:7154: $? = 1 configure: failed program was: | /* confdefs.h. */ | | #define PACKAGE_NAME libjava | #define PACKAGE_TARNAME libjava | #define PACKAGE_VERSION version-unused | #define PACKAGE_STRING libjava version-unused | #define PACKAGE_BUGREPORT | #ifdef __cplusplus | extern C void exit (int); | #endif | #define PACKAGE libjava | #define VERSION version-unused | #define LTDL_SHLIBPATH_VAR PATH | #define DEBUG 1 | #define USE_LTDL 1 | #define LIBGCJ_GC_DEBUG 1 | #define INTERPRETER 1 | #define SJLJ_EXCEPTIONS 1 | #define USE_LIBFFI 1 | #define ENABLE_JVMPI 1 | /* end confdefs.h. */ | #include ac_nonexistent.h configure:7193: result: /cygdrive/c/gcc-4_2-branch-build/./gcc/xgcc -B/cygdrive/c/gcc-4_2-branch-build/./gcc/ -B/usr/i686-pc-cygwin/bin/ -B/usr/i686-pc-cygwin/lib/ -isystem /usr/i686-pc-cygwin/include -isystem /usr/i686-pc-cygwin/sys-include -E configure:7217: /cygdrive/c/gcc-4_2-branch-build/./gcc/xgcc -B/cygdrive/c/gcc-4_2-branch-build/./gcc/ -B/usr/i686-pc-cygwin/bin/ -B/usr/i686-pc-cygwin/lib/ -isystem /usr/i686-pc-cygwin/include -isystem /usr/i686-pc-cygwin/sys-include -E conftest.c configure:7223: $? = 0 I'll leave this in the capable hands of someone more knowledgable than I am; about what they are trying to accomplish in this part of the configure and how best to do it. I am still able to compile java with this problem present. Thanks for reading this and fixing it, Rob -- Summary: libjava configure script mix up with .c / .java using gcj /gcc Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rob1weld at aol dot com GCC build triplet: i686-pc-cygwin GCC host triplet: i686-pc-cygwin GCC target triplet: i686-pc-cygwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30448
[Bug libgcj/27823] Found a problem with the JNI methods declared and implemented
--- Comment #23 from rob1weld at aol dot com 2007-01-18 23:52 --- I compiled 4.1.1 on Windows XP (Cygwin) a couple of days ago and did not have the Found a problem with the JNI methods declared and implemented. message occur. Last week when I compiled gcc-4_2-branch (SVN) the error did not occur. Today, when I recompiled 4.2.0 it DID occur. I am using the same parameters to configure (and compiling in a different directory than the source) as I did previously so either the SVN source breakage is recent (for i686-pc-cygwin platform) or my system had something occur recently to change things. I am using the same (lengthy) parameters for both 4.1.1 and 4.2.0 (though 4.2.0 has more implemented when these same parameters are used). I am concerned that the list is rather long, here is part of it: make[6]: Entering directory `/cygdrive/c/gcc-4_2-branch-build/i686-pc-cygwin/libjava/classpath/native/jni' cd /cygdrive/C/makecygwin/gcc-4_2-branch/libjava/classpath /bin/sh ./scripts/check_jni_methods.sh Found a problem with the JNI methods declared and implemented. (-) missing in implementation, (+) missing in header files +Java_gnu_java_awt_peer_gtk_CairoGraphics2D_cairoArc +Java_gnu_java_awt_peer_gtk_CairoGraphics2D_cairoClip +Java_gnu_java_awt_peer_gtk_CairoGraphics2D_cairoClosePath +Java_gnu_java_awt_peer_gtk_CairoGraphics2D_cairoCurveTo +Java_gnu_java_awt_peer_gtk_CairoGraphics2D_cairoDrawGlyphVector +Java_gnu_java_awt_peer_gtk_CairoGraphics2D_cairoDrawLine ... +Java_gnu_xml_libxmlj_sax_GnomeLocator_systemId +Java_gnu_xml_libxmlj_sax_GnomeXMLReader_parseStream +Java_gnu_xml_libxmlj_transform_GnomeTransformerFactory_freeLibxsltGlobal +Java_gnu_xml_libxmlj_transform_GnomeTransformer_free +Java_gnu_xml_libxmlj_transform_GnomeTransformer_newStylesheet +Java_gnu_xml_libxmlj_transform_GnomeTransformer_newStylesheetFromDoc +Java_gnu_xml_libxmlj_transform_GnomeTransformer_newStylesheetFromStream +Java_gnu_xml_libxmlj_transform_GnomeTransformer_transformDocToDoc +Java_gnu_xml_libxmlj_transform_GnomeTransformer_transformDocToSAX +Java_gnu_xml_libxmlj_transform_GnomeTransformer_transformDocToStream +Java_gnu_xml_libxmlj_transform_GnomeTransformer_transformStreamToDoc +Java_gnu_xml_libxmlj_transform_GnomeTransformer_transformStreamToSAX +Java_gnu_xml_libxmlj_transform_GnomeTransformer_transformStreamToStream make[6]: *** [all-local] Error 1 Looking through the long list I noticed this group and set out to find it: +Java_gnu_java_util_prefs_gconf_GConfNativePeer_gconf_1client_1add_1dir +Java_gnu_java_util_prefs_gconf_GConfNativePeer_gconf_1client_1dir_1exists +Java_gnu_java_util_prefs_gconf_GConfNativePeer_gconf_1client_1gconf_1client_1all_1keys +Java_gnu_java_util_prefs_gconf_GConfNativePeer_gconf_1client_1gconf_1client_1all_1nodes +Java_gnu_java_util_prefs_gconf_GConfNativePeer_gconf_1client_1get_1string +Java_gnu_java_util_prefs_gconf_GConfNativePeer_gconf_1client_1remove_1dir +Java_gnu_java_util_prefs_gconf_GConfNativePeer_gconf_1client_1set_1string +Java_gnu_java_util_prefs_gconf_GConfNativePeer_gconf_1client_1suggest_1sync +Java_gnu_java_util_prefs_gconf_GConfNativePeer_gconf_1client_1unset I found it in my SOURCE directory (not my build directry). It is odd that make runs commands that toss files into your source directory - seems to run against general principles of having the directories seperate. I looked at this file that gcjh had created - /cygdrive/C/makecygwin/gcc-4_2-branch/libjava/classpath/include/gnu_java_util_prefs_gconf_GConfNativePeer.h and found this in it: extern JNIEXPORT void JNICALL Java_gnu_java_util_prefs_gconf_GConfNativePeer_init_1id_1cache (JNIEnv *env, jclass); extern JNIEXPORT void JNICALL Java_gnu_java_util_prefs_gconf_GConfNativePeer_init_1class (JNIEnv *env, jclass); extern JNIEXPORT void JNICALL Java_gnu_java_util_prefs_gconf_GConfNativePeer_finalize_1class (JNIEnv *env, jclass); extern JNIEXPORT jboolean JNICALL Java_gnu_java_util_prefs_gconf_GConfNativePeer_gconf_1client_1dir_1exists (JNIEnv *env, jclass, jstring); extern JNIEXPORT void JNICALL Java_gnu_java_util_prefs_gconf_GConfNativePeer_gconf_1client_1add_1dir (JNIEnv *env, jclass, jstring); extern JNIEXPORT void JNICALL Java_gnu_java_util_prefs_gconf_GConfNativePeer_gconf_1client_1remove_1dir (JNIEnv *env, jclass, jstring); extern JNIEXPORT jboolean JNICALL Java_gnu_java_util_prefs_gconf_GConfNativePeer_gconf_1client_1set_1string (JNIEnv *env, jclass, jstring, jstring); extern JNIEXPORT jstring JNICALL Java_gnu_java_util_prefs_gconf_GConfNativePeer_gconf_1client_1get_1string (JNIEnv *env, jclass, jstring); extern JNIEXPORT jboolean JNICALL Java_gnu_java_util_prefs_gconf_GConfNativePeer_gconf_1client_1unset (JNIEnv *env, jclass, jstring); extern JNIEXPORT void JNICALL Java_gnu_java_util_prefs_gconf_GConfNativePeer_gconf_1client_1suggest_1sync (JNIEnv *env, jclass); extern JNIEXPORT jobject JNICALL Java_gnu_java_util_prefs_gconf_GConfNativePeer_gconf_1client_1gconf_1client_1all_1nodes (JNIEnv *env, jclass
[Bug libobjc/30445] Fix for FIXME in gcc-4_2-branch/libobjc/Makefile.in
--- Comment #2 from rob1weld at aol dot com 2007-01-19 12:48 --- Thank you for your assistance. I've looked into this and found the new names. If someone wished to either fix or delete (hopefully not) the libobjc.dll support I'd consider this resolved (for me) and this complaint could be closed. This is the suggestion I came up with. Files gcc-4_2-branch/libobjc/hash.c and gcc-4_2-branch/libobjc/objc/hash.h define: objc_hash_new(), objc_hash_delete(), objc_hash_add(), objc_hash_remove(), objc_hash_next(), objc_hash_value_for_key(), and objc_hash_is_key_in_hash() . The file gcc-4_2-branch/libobjc/libobjc.def defines both the 4.1.1 versions (which do not exist) and the 4.2.0 versions (same name as 4.1.1 version with objc_ prepended) of these functions. Running the make as described above creates the file (depending on your build directory and target name) /gcc-4_2-branch-build/i686-pc-cygwin/libobjc/libobjc.exp which contains the 4.1.1 and 4.2.0. named functions. One of the authors mentions not having a Windows system to test the above on - I hope I have helped. Based on the above it is my suggestion to fix this bug by doing the following: 1) delete all 4.1.1 references of the function names from gcc-4_2-branch/libobjc/libobjc.def . 2) Make the above changes to the makefile AND, in addition, delete or rename the file /gcc-4_2-branch-build/i686-pc-cygwin/libobjc/libobjc.a (Please Note: I do NOT say to delete or rename /gcc-4_2-branch-build/i686-pc-cygwin/libobjc/.libs/libobjc.a , only the copy). It is neccesary to copy (and not move) libobjc.a from the .libs directory because the makefile (as it was written) uses the file for input and eventually overwrites it as the output - but the file size is different from the input. For the rest of gcc's makefiles and tests to operate the .a file should be in the .libs directory. 3) Consider creating .dll (and .dll.a) files in addition to the .a file for _every_ library. I am using --enable-shared --enable-static when running configure but I don't get any .so or .dll files. The configure script rejects --enable-shared for Cygwin. I need to look into that more before filing a report on that. Both the sources for Mplayer-1.0rc1 and ffmpeg are GPL and show great examples of using .dll files under Cygwin - in the event someone needs somes code to refer to. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30445
[Bug java/30570] New: Word DEBUG used as a variable in VMAccessController.java breaks build
/../../include/w32api test.c -quiet -dumpbase test.c -mtune=athlon-xp -march=athlon-xp -auxbase test -g -version -o /cygdrive/c/DOCUME~1/HP_ADM~1/LOCALS~1/Temp/ccu73DRz.s The is no -DDEBUG anywhere and only the one DEBUG in the .h file. The compiler (both version 3.4.4 and 4.2.0) will not accept a .h file with the word DEBUG in it. I'm not a java expert and I don't want to break the person's work. Even if the fix is to add a sed command to the Makefile (for the cygwin) platform I'd be happy. I can't help but imagine that the word DEBUG is a protected word - much like unix, __CYGWIN__, __GNUC__, WINVER - and should not be used as a variable. -- Summary: Word DEBUG used as a variable in VMAccessController.java breaks build Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rob1weld at aol dot com GCC build triplet: i686-pc-cygwin GCC host triplet: i686-pc-cygwin GCC target triplet: i686-pc-cygwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30570
[Bug bootstrap/30342] Tough time building 4.2.0 (CVS) on WinXP with Cygwin
--- Comment #4 from rob1weld at aol dot com 2007-01-24 04:26 --- The newest test results for building according to these instructions are here: http://gcc.gnu.org/ml/gcc-testresults/2007-01/msg00811.html Most tests are completed with a dozen (or less) errors - that is not too bad with _every_ possible option enabled. Libmudflap is usable (for debugging, then recompile with the feature off) and most of the errors are output pattern test errors (which, to ME, means that the expect script is not catching the output correctly) discounting those errors there are very few errors remaining. I'm looking into the Java test to see why there are so many errors. I did make a couple of bug reports but Java is not my strongest language - I can only hope that someone else will fix it for the cygwin platform :) . Overall 4.2.0 is testing very well (on _my_ platform), there are fewer errors reported than make -k check on 4.1.1 (release) - this does not mean it actually works better, only that the error checking does not find errors ;) . -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30342
[Bug libgcj/30570] Word DEBUG used as a variable in VMAccessController.java breaks build
--- Comment #3 from rob1weld at aol dot com 2007-02-08 20:56 --- I found out exactly what the trouble is - it _likely_ affects ALL platforms. I use a very long set of configure options (to enable as much as possible) but the one that is causing the trouble is: --enable-libgcj-debug . I proved this by altering the file: gcc-4_2-branch/libjava/java/security/natVMAccessController.cc I added this around the #include config.h statement: static const jint DEBUG = 1L; #include config.h static const jint DEBUG = 1L; I then compiled the file using the exact same command that make shows on screen plus I added -E to show the error and examined the resulting file: # 11 /cygdrive/C/makecygwin/gcc-4_2-branch/libjava/java/security/natVMAccessController.cc static const jint DEBUG = 1L; # 1 ./include/config.h 1 # 14 /cygdrive/C/makecygwin/gcc-4_2-branch/libjava/java/security/natVMAccessController.cc 2 static const jint 1 = 1L; The second 'jint' statement is wrong so that means that the included config.h wrecked things. Looking at file: /gcc-4_2-branch-build/i686-pc-cygwin/libjava/include/config.h we have this: /* include/config.h. Generated by configure. */ /* include/config.h.in. Generated from configure.ac by autoheader. */ /* Define this if you want runtime debugging enabled. */ #define DEBUG 1 Note: We have the same definition (without causing the error, since _this_ config.h is not included) here in /gcc-4_2-branch-build/i686-pc-cygwin/libjava/classpath/include/config.h. /* include/config.h. Generated by configure. */ /* include/config.h.in. Generated from configure.ac by autoheader. */ /* Define to 1 if you want native library runtime debugging code enabled */ #define DEBUG 1 That second one does not cause any trouble but _IF_ you are going to change the word DEBUG be sure to change them both if they should both be the same word. This problem comes from the file: /gcc-4_2-branch/libjava/include/config.h.in so this _IS_ a 'gcc problem' and not a problem with either classpath's source or Cygwin's headers. Here is the part of config.h.in at fault: /* include/config.h.in. Generated from configure.ac by autoheader. */ /* Define to one of `_getb67', `GETB67', `getb67' for Cray-2 and Cray-YMP systems. This function is required for `alloca.c' support on those systems. */ #undef CRAY_STACKSEG_END /* Define to 1 if using `alloca.c'. */ #undef C_ALLOCA /* Define this if you want runtime debugging enabled. */ #undef DEBUG /* Define if system properties shouldn't be read from getenv(GCJ_PROPERTIES). */ #undef DISABLE_GETENV_PROPERTIES Now that _MAY_ seem inocent enough but what happens when you run /gcc-4_2-branch/configure --enable-libgcj-debug is that /gcc-4_2-branch/libjava/configure gets passed the --enable-libgcj-debug and creates a confdefs.h file (that gets deleted - thus hiding the problem from searching). When the /gcc-4_2-branch/libjava/configure script gets near the end it does the sed script routine (to substitute variables in the *.in files) it uses the confdefs.h file as well. Here is the part of the configure script that says it does this: # Transform confdefs.h into two sed scripts, `conftest.defines' and # `conftest.undefs', that substitutes the proper values into # config.h.in to produce config.h. The first handles `#define' # templates, and the second `#undef' templates. That tells me that configure is replacing the #undef DEBUG in config.h.in with #define DEBUG 1 if configure uses the parameter --enable-libgcj-debug. This creates the problem in the java/security/VMAccessController.h file that is made by gcjh (I hope I explained that correctly). I just got through re-running /gcc-4_2-branch/configure (with all my long list of parameters) without using --enable-libgcj-debug and make runs without causing the error (while compiling gcc-4_2-branch/libjava/java/security/natVMAccessController.cc) it still breaks _elsewhere_ ;( . I am not an expert on Java and I will leave it to the experts as how best to fix this. My 2 cents is that the file /gcc-4_2-branch/libjava/configure is wrong since it sets #define DEBUG 1 ; and in doing so it breaks the file java/security/VMAccessController.h (created by gcjh). I suggest that this is _equally_ applicable to _all_ platforms and would halt the build for anyone who uses --enable-libgcj-debug (_AND_ also uses other parameters that cause /gcc-4_2-branch/libjava/java/security/natVMAccessController.cc to be compiled). Since this should happen on any platform can someone else confirm it? (As a point of interest I am using this /gcc-4_2-branch/configure command: /cygdrive/C/makecygwin/gcc-4_2-branch/configure --disable-werror --verbose --target=i686-pc-cygwin --enable-languages=c,ada,c++,fortran,java,objc,obj-c++ --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-static --enable-nls --enable
[Bug libgcj/31650] New: gcc-4_2-branch uses class that has been removed - breaks make
that you don't have this, that or the other installed (or it is not a new enough version). OF _course_ installing the suggested package then makes new dependencies on other packages being installed with newer versions. Here is some of the files I had to get to compile with the above options fed to the main ./configure script (and it did NOT even bother to run pkg-config to check and tell me until hours into the compile when a sub-configure script tells you). -rw-r--r-- 1 root root 1321109 Feb 26 11:07 GConf-2.16.1.tar.bz2 -rw-r--r-- 1 root root 483363 Apr 20 01:13 atk-1.9.1.tar.bz2 -rw-r--r-- 1 root root 2973689 Apr 20 01:31 cairo-1.2.6.tar.gz -rw-r--r-- 1 root root 2925342 Apr 20 01:42 glib-2.12.11.tar.bz2 -rw-r--r-- 1 root root 15031543 Apr 20 00:00 gtk+-2.10.11.tar.bz2 -rw-r--r-- 1 root root 1356322 Apr 20 01:47 pango-1.16.2.tar.bz2 -rw-r--r-- 1 root root 969993 Apr 20 14:21 pkg-config-0.20.tar.gz I can't apt-get these (without modifying /etc/apt/sources.list) since they are not stable) but gcc-4_2-branch requires all these bleading edge versions to compile. Don't get me wrong. I don't mind getting and installing them ! - My complaint is that the ./configure script should mention (before typing make) that I need to spend some time upgrading and installing various new versions of packages I already have. I also need to read the docs and google the web to determine what order to install everything in so that each package can ./configure itself with all features available. I found this order worked for me: Cairo, GLib, Pango, ATK, then GTK+. I (am reasonably certain that I) can fix all this myself so please no one rush to help me. I will post the build-log shortly and put a link on this page to the output of make -i check. Just letting the 'powers that be' know that ./configure should check dependancies better and it would be kind if configure could offer a little advice (simply You need to install 'xyz version 123.21.2' or newer) or point us to a web page that gives detailed instructions. I am using gnu/Linux as an OS, it would be great if I could simply type make and then make install (no matter what my ./configure options are). Failing that a warning that the compile can't be completed without doing this that and the other thing would be better than the make breaking when it is nearly finished. PS: Not angry. I've compiled gcc-4_2-branch a couple of dozen times over the past few months. Just discovered this bug (by adding new ./comfigure options and trying a new OS) and am happy to report it and offer suggestions. Thanks all for the great compiler. The C compiler is what I used to compile my kernel - that is how much I trust gcc-4_2-branch - my system has had no trouble and all the modules work fine. -- Summary: gcc-4_2-branch uses class that has been removed - breaks make Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcj 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=31650
[Bug libstdc++/31717] New: libstdc++-v3 - Make fails with: ./c++locale.h:69: error: '__locale_t' does not name a type
/cygdrive/c/gcc-4_2-branch-build/i686-pc-cygwin/libstdc++-v3/include/ostream:45, from /cygdrive/c/gcc-4_2-branch-build/i686-pc-cygwin/libstdc++-v3/include/bitset:59, from /cygdrive/C/makecygwin/gcc-4_2-branch/libstdc++-v3/include/precompiled/stdc++.h:56: /cygdrive/c/gcc-4_2-branch-build/i686-pc-cygwin/libstdc++-v3/include/bits/locale_classes.h: At global scope: /cygdrive/c/gcc-4_2-branch-build/i686-pc-cygwin/libstdc++-v3/include/bits/locale_classes.h:351: error: '__c_locale' does not name a type /cygdrive/c/gcc-4_2-branch-build/i686-pc-cygwin/libstdc++-v3/include/bits/locale_classes.h:382: error: '__c_locale' has not been declared /cygdrive/c/gcc-4_2-branch-build/i686-pc-cygwin/libstdc++-v3/include/bits/locale_classes.h:383: error: '__c_locale' has not been declared /cygdrive/c/gcc-4_2-branch-build/i686-pc-cygwin/libstdc++-v3/include/bits/locale_classes.h:385: error: '__c_locale' does not name a type /cygdrive/c/gcc-4_2-branch-build/i686-pc-cygwin/libstdc++-v3/include/bits/locale_classes.h:389: error: '__c_locale' has not been declared /cygdrive/c/gcc-4_2-branch-build/i686-pc-cygwin/libstdc++-v3/include/bits/locale_classes.h:393: error: '__c_locale' does not name a type In file included from /cygdrive/c/gcc-4_2-branch-build/i686-pc-cygwin/libstdc++-v3/include/bits/basic_ios.h:44, from /cygdrive/c/gcc-4_2-branch-build/i686-pc-cygwin/libstdc++-v3/include/ios:50, from /cygdrive/c/gcc-4_2-branch-build/i686-pc-cygwin/libstdc++-v3/include/ostream:45, from /cygdrive/c/gcc-4_2-branch-build/i686-pc-cygwin/libstdc++-v3/include/bitset:59, from /cygdrive/C/makecygwin/gcc-4_2-branch/libstdc++-v3/include/precompiled/stdc++.h:56: /cygdrive/c/gcc-4_2-branch-build/i686-pc-cygwin/libstdc++-v3/include/bits/locale_facets.h:68: error: expected ',' or '...' before '' token /cygdrive/c/gcc-4_2-branch-build/i686-pc-cygwin/libstdc++-v3/include/bits/locale_facets.h:74: error: expected ',' or '...' before '' token /cygdrive/c/gcc-4_2-branch-build/i686-pc-cygwin/libstdc++-v3/include/bits/locale_facets.h:79: error: expected ',' or '...' before '' token /cygdrive/c/gcc-4_2-branch-build/i686-pc-cygwin/libstdc++-v3/include/bits/locale_facets.h:84: error: expected ',' or '...' before '' token /cygdrive/c/gcc-4_2-branch-build/i686-pc-cygwin/libstdc++-v3/include/bits/locale_facets.h:685: error: '__c_locale' does not name a type Errors resulting from that issue continue to cause a few pages of warnings that would likely not be shown if that problem did not occur (so I deleted them from this report) - the end of the messages is this: /cygdrive/c/gcc-4_2-branch-build/i686-pc-cygwin/libstdc++-v3/include/bits/locale_facets.tcc:1556: error: there are no arguments to '_S_get_c_locale' that depend on a template parameter, so a declaration of '_S_get_c_locale' must be available /cygdrive/c/gcc-4_2-branch-build/i686-pc-cygwin/libstdc++-v3/include/bits/locale_facets.tcc: In member function 'virtual _OutIter std::money_put_CharT, _OutIter::do_put(_OutIter, bool, std::ios_base, _CharT, long double) const': /cygdrive/c/gcc-4_2-branch-build/i686-pc-cygwin/libstdc++-v3/include/bits/locale_facets.tcc:1780: error: there are no arguments to '_S_get_c_locale' that depend on a template parameter, so a declaration of '_S_get_c_locale' must be available make[4]: *** [bits/stdc++.h.gch/O0g.gch] Error 1 make[4]: Leaving directory `/cygdrive/c/gcc-4_2-branch-build/i686-pc-cygwin/libstdc++-v3/include' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/cygdrive/c/gcc-4_2-branch-build/i686-pc-cygwin/libstdc++-v3' make[2]: *** [all] Error 2 make[2]: Leaving directory `/cygdrive/c/gcc-4_2-branch-build/i686-pc-cygwin/libstdc++-v3' make[1]: *** [all-target-libstdc++-v3] Error 2 make[1]: Leaving directory `/cygdrive/c/gcc-4_2-branch-build' make: *** [all] Error 2 I'll look into this myself and see what I come up with. -- Summary: libstdc++-v3 - Make fails with: ./c++locale.h:69: error: '__locale_t' does not name a type Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rob1weld at aol dot com GCC build triplet: i686-pc-cygwin GCC host triplet: i686-pc-cygwin GCC target triplet: i686-pc-cygwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31717
[Bug libstdc++/31717] libstdc++-v3 - Make fails with: ./c++locale.h:69: error: '__locale_t' does not name a type
--- Comment #2 from rob1weld at aol dot com 2007-04-26 21:33 ---
Thank you Paolo Carlini.
Previously I _did_ let ./configure guess (on successful builds) but _this_
_time_ I used _exactly_ the same ./configure parameters as I did for Linux (to
duplicate the GCC compiler for both systems [and the success]).
I was just checking my stdc++.ii file (for a problem with line # _69_ and this
is what it looks like:
# 67
/cygdrive/c/gcc-4_2-branch-build/i686-pc-cygwin/libstdc++-v3/include/bits/c++locale.h
3
namespace std {
typedef __locale_t __c_locale;
Previous to that part (in the .ii file) there is nothing to say what __locale_t
is so it is as though it were blank (IE: the line would read: typedef
__c_locale; and thus fail).
I guess this bug would be fixed if the 'root' ./configure script did not allow
one to use --enable-clocale=gnu on this platform (and kindly suggested to
ONLY use --enable-clocale=generic).
If that is the correct solution then I would consider this resolved _after_ the
./configure script is changed.
Thanks for the quick response - I might have had a lot of trouble tracking that
down. Now to re-make the compiler (and just [OF COURSE] when the build was
nearly finished (crying)). :)(Used to it.)
--
rob1weld at aol dot com changed:
What|Removed |Added
Severity|blocker |minor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31717
[Bug libstdc++/31717] libstdc++-v3 - Make fails with: ./c++locale.h:69: error: '__locale_t' does not name a type
--- Comment #4 from rob1weld at aol dot com 2007-04-27 04:47 --- I do agree with removing that option when configuring for Cygwin and I did so. I put in extra spaces and re-sorted the order of these options so you can use an editor (like kwrite or notepad) to view the changed options easily. I do not see ANY options that would affect C / C++ etc - only Java options added. My previous (working) ./configure was (with SVN from 2 weeks prior - IE: different): configure --verbose --enable-languages=c,ada,c++,fortran,java,objc,obj-c++ --with-tune=athlon-xp --prefix=/usr --enable-objc-gc --enable-concept-checks --exec-prefix=/usr --sysconfdir=/etc --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-gxx-include-dir=/usr/include/c++/4.2 --enable-libstdcxx-debug --enable-shared --enable-static --enable-threads=posix --enable-version-specific-runtime-libs --enable-libssp --enable-libmudflap --enable-libgomp --disable-werror --enable-nls --with-included-gettext --enable-sjlj-exceptions --enable-java-gc=boehm --with-x --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --enable-java-awt=gtk,xlib--enable-qt-peer --enable-xmlj --enable-gconf-peer --enable-tool-wrappers --enable-libgcj--enable-hash-synchronization --enable-gc-debug --enable-interpreter --with-system-zlib --enable-libada --with-tls --enable-win32-registry --with-cpu=athlon-xp --with-arch=athlon-xp --target=i686-pc-cygwin --enable-multilib --enable-checking My current (broken, and different SVN version) options are: configure --verbose --enable-languages=c,ada,c++,fortran,java,objc,obj-c++ --with-tune=athlon-xp --prefix=/usr --enable-objc-gc --enable-concept-checks --exec-prefix=/usr --sysconfdir=/etc --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-gxx-include-dir=/usr/include/c++/4.2 --enable-libstdcxx-debug --enable-static --enable-shared --enable-initfini-array --enable-__cxa_atexit --enable-threads=posix --enable-version-specific-runtime-libs --enable-libssp --enable-libmudflap --enable-libgomp --disable-werror --enable-nls --without-included-gettext --enable-decimal-float --with-long-double-128 --enable-debug --disable-sjlj-exceptions --enable-java-gc=boehm --with-x --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --enable-java-awt=gtk,xlib --enable-gtk-cairo --enable-qt-peer --enable-xmlj --enable-gconf-peer --enable-tool-wrappers --with-gjdoc --enable-portable-native-sync --enable-libgcj-multifile --with-stabs I didn't just make clean, I deleted the whole directory and re-made from the begining using the second ./configure string above. I got make to break in EXACTLY the SAME location - but different error message. This makes me question that PCH might be broken (last week) and working previously (two weeks ago). This is not unheard of as it _was_ broken for a few days a few months ago. Here are the new errors, same spot much fewer and completly different: make[2]: Leaving directory `/cygdrive/c/gcc-4_2-branch-build/i686-pc-cygwin/libiberty' make[2]: Entering directory `/cygdrive/c/gcc-4_2-branch-build/i686-pc-cygwin/libstdc++-v3' make AR_FLAGS=rc CC_FOR_BUILD=gcc CC_FOR_TARGET=/cygdrive/c/gcc-4_2-branch-build/./gcc/xgcc -B/cygdrive/c/gcc-4_2-branch-build/./gcc/ -B/usr//bin/ -B/usr//lib/ -isystem /usr//include -isystem /usr//sys-include CFLAGS=-O2 -g -O2 CXXFLAGS=-g -O2 CFLAGS_FOR_BUILD=-g -O2 CFLAGS_FOR_TARGET=-O2 -g -O2 INSTALL=/usr/bin/install -c INSTALL_DATA=/usr/bin/install -c -m 644 INSTALL_PROGRAM=/usr/bin/install -c INSTALL_SCRIPT=/usr/bin/install -c LDFLAGS= LIBCFLAGS=-O2 -g -O2 LIBCFLAGS_FOR_TARGET=-O2 -g -O2 MAKE=make MAKEINFO=makeinfo --split-size=500 --split-size=500 PICFLAG= PICFLAG_FOR_TARGET= SHELL=/bin/sh RUNTESTFLAGS= exec_prefix=/usr infodir=/usr/share/info libdir=/usr/lib includedir=/usr/include prefix=/usr tooldir=/usr/ gxx_include_dir=/usr/include/c++/4.2 AR=/usr/i686-pc-cygwin/bin/ar AS=/cygdrive/c/gcc-4_2-branch-build/./gcc/as LD=/cygdrive/c/gcc-4_2-branch-build/./gcc/collect-ld RANLIB=/usr/i686-pc-cygwin/bin/ranlib NM=/cygdrive/c/gcc-4_2-branch-build/./gcc/nm NM_FOR_BUILD= NM_FOR_TARGET=/usr/i686-pc-cygwin/bin/nm DESTDIR= WERROR= all-recursive make[3]: Entering directory `/cygdrive/c/gcc-4_2-branch-build/i686-pc-cygwin/libstdc++-v3' Making all in include make[4]: Entering directory `/cygdrive/c/gcc-4_2-branch-build/i686-pc-cygwin/libstdc++-v3/include' if [ ! -d .//bits/extc++.h.gch ]; then \ mkdir -p .//bits/extc++.h.gch; \ fi; \ /cygdrive/c/gcc-4_2-branch-build/./gcc/xgcc -shared-libgcc -B/cygdrive/c/gcc-4_2-branch-build/./gcc -nostdinc++ -L/cygdrive/c/gcc-4_2-branch-build/i686-pc-cygwin/libstdc++-v3/src -L/cygdrive/c/gcc-4_2-branch-build/i686-pc-cygwin
[Bug c/31741] New: dfp tests failing - internal compiler error
It looks like ALL the DFP tests are failing. This is an early notification. I will e-mail full make -i check results after all the tests have completed. There are also a few errors in C we did not have last week. === gcc Summary === # of expected passes42626 # of unexpected failures124 --- Ouch, was only a few before # of expected failures 116 # of unresolved testcases 87 # of untested testcases 28 # of unsupported tests 287 #/opt/gcc-4_2-build# gcc/xgcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-4_2-branch/configure --verbose --enable-languages=c,ada,c++,fortran,java,objc,obj-c++ --with-tune=athlon-xp --prefix=/usr --enable-objc-gc --enable-concept-checks --disable-multilib --with-gxx-include-dir=/usr/include/c++/4.2 --enable-libstdcxx-debug --enable-static --enable-shared --enable-initfini-array --enable-__cxa_atexit --enable-threads=posix --enable-version-specific-runtime-libs --enable-libssp --enable-libmudflap --enable-libgomp --disable-werror --enable-nls --with-included-gettext --enable-decimal-float --with-long-double-128 --enable-debug --disable-sjlj-exceptions --enable-java-gc=boehm --with-x --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --enable-java-awt=gtk,xlib --enable-gtk-cairo --enable-qt-peer --enable-xmlj --enable-gconf-peer --enable-tool-wrappers --with-gjdoc --enable-portable-native-sync --enable-libgcj-multifile --with-stabs --enable-hash-synchronization --enable-gc-debug --enable-interpreter --with-system-zlib --enable-libada --with-tls --with-cpu=athlon-xp --with-arch=athlon-xp --enable-checking Thread model: posix gcc version 4.2.0 20070427 (prerelease) (Note: you'll need a lot of new libraries to actually compile with all those options enabled - you might try just using --enable-decimal-float (possibly --with-long-double-128 too)). Here is a _small_ portion of gcc.log : PASS: gcc.dg/compat/scalar-by-value-dfp c_compat_main_tst.o compile Executing on host: /opt/gcc-4_2-build/gcc/xgcc -B/opt/gcc-4_2-build/gcc/ -fno-show-column -c -o c_compat_x_tst.o /r$ /root/downloads/gcc-4_2-branch/gcc/testsuite/gcc.dg/compat/scalar-by-value-dfp_x.c: In function 'checkd128': /root/downloads/gcc-4_2-branch/gcc/testsuite/gcc.dg/compat/scalar-by-value-dfp_x.c:149: error: unrecognizable insn: (insn 24 23 25 3 (set (subreg:TI (reg:TD 68) 0) (subreg:TI (const_double:TD 0 [0x0] 123.456 [N/A]) 0)) -1 (nil) (insn_list:REG_LIBCALL 32 (nil))) /root/downloads/gcc-4_2-branch/gcc/testsuite/gcc.dg/compat/scalar-by-value-dfp_x.c:149: internal compiler error: in ext$ Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. compiler exited with status 1 output is: /root/downloads/gcc-4_2-branch/gcc/testsuite/gcc.dg/compat/scalar-by-value-dfp_x.c: In function 'checkd128': /root/downloads/gcc-4_2-branch/gcc/testsuite/gcc.dg/compat/scalar-by-value-dfp_x.c:149: error: unrecognizable insn: (insn 24 23 25 3 (set (subreg:TI (reg:TD 68) 0) (subreg:TI (const_double:TD 0 [0x0] 123.456 [N/A]) 0)) -1 (nil) (insn_list:REG_LIBCALL 32 (nil))) /root/downloads/gcc-4_2-branch/gcc/testsuite/gcc.dg/compat/scalar-by-value-dfp_x.c:149: internal compiler error: in ext$ Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. ...(many more)... -- Summary: dfp tests failing - internal compiler error Product: gcc Version: 4.2.0 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: 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=31741
[Bug libstdc++/31717] libstdc++-v3 - Make fails with: ./c++locale.h:69: error: '__locale_t' does not name a type
--- Comment #6 from rob1weld at aol dot com 2007-04-29 07:31 --- I was only trying to clairify that another problem occurred in that exact same spot AFTER I followed your advice - IE: that is was possible that your solution was not the only thing needed to fix the problem. I downloaded a more recent SVN (I only update once a week to save the server) and followed your advice. I do not have a problem in _that_ particular portion of the build. The NEW problems _are_ filed in seperate reports. That option was used because I copied the script from the Linux part of my system over to the WinXP side and built with Cygwin using the same options. I appreciate you pointing out that the oversight I made would not work with Cygwin since I spent a some time trying to determine what the problem was and how to fix it. I did search the bug reports before posting. Sorry for any confusion (that I had lump[ed] together many different issues in a single report). I thought I only made a complaint about _one_ thing. This report is only supposed to be a complaint that: The main ./configure does not check if the user has chosen options that are not suitable for the platform. It lets you do a make that works fine for _many_ hours and then fails when it is _almost_ finished. One example of this behaviour is that it is possible to choose '--enable-clocale=gnu' when compiling for the Cygwin platform. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31717
[Bug libgcj/31650] gcc-4_2-branch uses class that has been removed - breaks make
--- Comment #2 from rob1weld at aol dot com 2007-04-29 10:51 --- Prevously I posted: I will post the build-log shortly and put a link on this page ... I finally got it compiled (using an enormous number of features) and got my best results yet for Java: === libjava Summary === # of expected passes7006 # of expected failures 12 # of untested testcases 8 runtest completed at Sun Apr 29 01:23:19 2007 Using _similar_ (but NOT the same) options to compile for Cygwin platform results in an internal compiler error (in the start of making library libstdc++-v3), otherwise I would post test results for that platform also. To see (Java with nearly every option enabled) the results of make -i check click here: http://gcc.gnu.org/ml/gcc-testresults/2007-04/msg01490.html Thanks for your help, Tom. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31650
[Bug libgcj/30448] libjava configure script mix up with .c / .java using gcj /gcc
--- Comment #2 from rob1weld at aol dot com 2007-04-29 11:05 --- Dear Andrew: I am sorry I did not include my gcc -v in the report. Judging from the date I _MIGHT_ have used one of these configure lines: /cygdrive/C/makecygwin/gcc-4_2-branch/configure --disable-werror --verbose --target=i686-pc-cygwin --enable-languages=c,ada,c++,fortran,java,objc,obj-c++ --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-static --enable-nls --enable-multilib --with-included-gettext --enable-version-specific-runtime-libs --enable-checking --with-gxx-include-dir=/usr/include/c++/4.2.0 --enable-concept-checks --enable-sjlj-exceptions --enable-libstdcxx-debug --enable-libgcj --enable-libgcj-debug --enable-java-awt=gtk,xlib --enable-java-gc=boehm --enable-gconf-peer --enable-hash-synchronization --enable-gc-debug --enable-interpreter --enable-xmlj --enable-qt-peer --enable-regen-headers --enable-tool-wrappers --enable-objc-gc --with-system-zlib --enable-threads=posix --enable-libada --enable-libssp --enable-libmudflap --with-tls --enable-win32-registry --with-x --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --with-cpu=athlon-xp --with-arch=athlon-xp --with-tune=athlon-xp _OR_ /cygdrive/C/makecygwin/gcc-4_2-branch/configure --disable-werror --verbose --target=i686-pc-cygwin --enable-languages=c,ada,c++,fortran,java,objc,obj-c++ --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-static --enable-nls --enable-multilib --without-included-gettext --enable-version-specific-runtime-libs --enable-checking --with-gxx-include-dir=/usr/include/c++/4.2.0 --enable-concept-checks --enable-sjlj-exceptions --enable-libstdcxx-debug --enable-__cxa_atexit --enable-libgcj --enable-libgcj-debug --enable-java-awt=gtk,xlib --enable-java-gc=boehm --enable-plugin --enable-gconf-peer --enable-hash-synchronization --enable-gc-debug --enable-interpreter --enable-xmlj --enable-qt-peer --enable-regen-headers --enable-tool-wrappers --enable-objc-gc --with-system-zlib --enable-threads=posix --enable-libada --enable-libssp --enable-libmudflap --with-tls --enable-win32-registry --with-x --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --with-cpu=athlon-xp --with-arch=athlon-xp --with-tune=athlon-xp Those are from a list of tried and failed attempts. They might not be what I used. Again, I am sorry I did not include that info; if someone had e-mailed me directly I could have given a better guess ... I have not seen the problem re-occur and I do keep altering my configure options regualrly to add as many as possible (so to test as best I can). If it is any consolation I DID recently compile GCC with _tons_ of options enabled and Java (almost) passed perfectly ! (first time ever, for me). The results are here (and they are for Linux, instead of Cygwin): http://gcc.gnu.org/ml/gcc-testresults/2007-04/msg01490.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30448
[Bug libgcj/30448] libjava configure script mix up with .c / .java using gcj /gcc
--- Comment #3 from rob1weld at aol dot com 2007-04-29 11:13 --- I am going to change the resolution to WORKSFORME. This does not mean that whatever problem that occurred at _that_ particular time was actually fixed, only that I am not able to reproduce it with the __current__ SVN (nor do I wish to go back to a broken version and attempt to figure out a forgotten configure script). _IF_ the error re-occurs I'll come back here. The current SVN works (for Java). -- rob1weld at aol dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30448
[Bug c/31741] dfp tests failing - internal compiler error
--- Comment #1 from rob1weld at aol dot com 2007-04-29 11:25 --- I completed all tests. Current SVN builds on Linux OK, but has internal compiler error when build with _similar_ (but not same) options on Cygwin platform (when it gets to libstdc++-v3). Full results at this link: http://gcc.gnu.org/ml/gcc-testresults/2007-04/msg01490.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31741
[Bug ada/31744] New: Ada has way TOO MANY may be used uninitialized warnings.
. Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rob1weld at aol dot com GCC build triplet: i686-pc-cygwin GCC host triplet: i686-pc-cygwin GCC target triplet: i686-pc-cygwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31744
[Bug bootstrap/31746] New: Broken ./configure sed scripting affecting *gcc/configargs.h construction.
This occurs on platforms i686-pc-linux-gnu _AND_ i686-pc-cygwin but I can only choose to report for a single platform at a time. I will not file a second identical report for i686-pc-cygwin, just this one report. The file gcc/configargs.h does not get made properly. That causes the compiler to not show how it was created when xgcc -v is typed. The configargs.h file has this erroneous line: static const char configuration_arguments[] = /root/downloads/gcc-4_2-branch/configure linux gnu gcc/xgcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: /root/downloads/gcc-4_2-branch/configure linux gnu Thread model: posix gcc version 4.2.0 20070427 (prerelease) When starting ./configure and then make, this happens in less than a minute or two (depending on system speed), it whips by quickly without error. checking assembler for --gdwarf2 option... (cached) yes checking assembler for --gstabs option... (cached) yes checking linker read-only and read-write section mixing... read-write checking linker PT_GNU_EH_FRAME support... yes checking linker position independent executable support... yes checking linker --as-needed support... (cached) yes checking linker --sysroot support... (cached) yes checking __stack_chk_fail in target GNU C library... (cached) no Using ggc-page for garbage collection. checking whether to enable maintainer-specific portions of Makefiles... no Links are now set up to build a native compiler for i686-pc-linux-gnu. updating cache ./config.cache configure: creating ./config.status config.status: creating Makefile sed: file ./confstatt11667/subs-4.sed line 38: unterminated `s' command config.status: creating gccbug sed: file ./confstatt11667/subs-4.sed line 38: unterminated `s' command config.status: creating mklibgcc sed: file ./confstatt11667/subs-4.sed line 38: unterminated `s' command config.status: creating libada-mk sed: file ./confstatt11667/subs-4.sed line 38: unterminated `s' command config.status: creating ada/Makefile sed: file ./confstatt11667/subs-4.sed line 38: unterminated `s' command config.status: creating auto-host.h config.status: executing default commands Configuring stage 1 in ./libiberty configure: loading cache ./config.cache checking whether to enable maintainer-specific portions of Makefiles... no The rest of the configargs.h file uses sed scripts correctly and sets the default_options variable properly on both platforms. -- Summary: Broken ./configure sed scripting affecting *gcc/configargs.h construction. Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: minor 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=31746
[Bug bootstrap/31746] Broken ./configure sed scripting affecting *gcc/configargs.h construction.
--- Comment #2 from rob1weld at aol dot com 2007-04-29 17:12 --- # sed --version GNU sed version 4.1.5 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31746
[Bug libstdc++/31761] New: Build fails with exception.hpp:84: internal compiler error: Segmentation fault
error: Segmentation fault Product: gcc Version: 4.2.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-cygwin GCC host triplet: i686-pc-cygwin GCC target triplet: i686-pc-cygwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31761
[Bug bootstrap/31746] Broken ./configure sed scripting affecting *gcc/configargs.h construction.
--- Comment #3 from rob1weld at aol dot com 2007-04-29 18:19 --- The problem seems to be that the ./configure script is including --enable-languages TWO times and the second time it is NOT quoting it - thus breaking sed. # grep _configargs ../gcc-4_2-build/config.log build_configargs='--cache-file=../config.cache --build= --host= --target= '\''--verbose'\'' '\''--enable-languages=c,ada,c++,fortran,java,objc,obj-c++'\'' '\''--with-tune=athlon-xp'\'' '\''--prefix=/usr'\'' '\''--enable-objc-gc'\'' '\''--enable-concept-checks'\'' '\''--mandir=/usr/share/man'\'' '\''--infodir=/usr/share/info'\'' '\''--with-gxx-include-dir=/usr/include/c++/4.2'\'' '\''--enable-libstdcxx-debug'\'' '\''--enable-static'\'' '\''--enable-shared'\'' '\''--enable-initfini-array'\'' '\''--enable-__cxa_atexit'\'' '\''--enable-threads'\'' '\''--enable-version-specific-runtime-libs'\'' '\''--enable-libssp'\'' '\''--enable-libmudflap'\'' '\''--enable-libgomp'\'' '\''--disable-werror'\'' '\''--enable-nls'\'' '\''--without-included-gettext'\'' '\''--enable-decimal-float'\'' '\''--with-long-double-128'\'' '\''--enable-clocale=gnu'\'' '\''--enable-debug'\'' '\''--disable-sjlj-exceptions'\'' '\''--enable-java-gc=boehm'\'' '\''--with-x'\'' '\''--enable-java-awt=gtk,xlib'\'' '\''--enable-gtk-cairo'\'' '\''--enable-qt-peer'\'' '\''--enable-xmlj'\'' '\''--enable-gconf-peer'\'' '\''--enable-tool-wrappers'\'' '\''--with-gjdoc'\'' '\''--enable-portable-native-sync'\'' '\''--enable-libgcj-multifile'\'' '\''--with-stabs'\'' --enable-languages=c,ada,c++,fortran,java,objc,obj-c++ --program-transform-name='\''s,y,y,'\''' host_configargs=(SAME STRING) target_configargs=(SAME STRING) My ./configure command line (I use a shell script, I don't type it in :) ) is: /root/downloads/gcc-4_2-branch/configure --verbose --enable-languages=c,ada,c++,fortran,java,objc,obj-c++ --with-tune=athlon-xp --prefix=/usr --enable-objc-gc --enable-concept-checks --disable-multilib --with-gxx-include-dir=/usr/include/c++/4.2 --enable-libstdcxx-debug --enable-static --enable-shared --enable-initfini-array --enable-__cxa_atexit --enable-threads=posix --enable-version-specific-runtime-libs --enable-libssp --enable-libmudflap --enable-libgomp --disable-werror --enable-nls --with-included-gettext --enable-decimal-float --with-long-double-128 --enable-debug --disable-sjlj-exceptions --enable-java-gc=boehm --with-x --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --enable-java-awt=gtk,xlib --enable-gtk-cairo --enable-qt-peer --enable-xmlj --enable-gconf-peer --enable-tool-wrappers --with-gjdoc --enable-portable-native-sync --enable-libgcj-multifile --with-stabs --enable-hash-synchronization --enable-gc-debug --enable-interpreter --with-system-zlib --enable-libada --with-tls --with-cpu=athlon-xp --with-arch=athlon-xp --enable-checking Note I only specify --enable-languages=c,ada,c++,fortran,java,objc,obj-c++ a _single_ time, but even if I did specify it ten times the *_configargs=XYZ should only show it once and it should be single quoted. Perhaps our shells are different and yours is not affected. I compile through a X11 window - here is my xterm and bash versions (for Linux both are apt-get recent, for Cygwin both are Setup.exe recently updated): For gnu/Linux (Debian): /opt/gcc-4_2-build# xterm -version XTerm(222) /opt/gcc-4_2-build# bash --version GNU bash, version 3.1.17(1)-release (i486-pc-linux-gnu) Copyright (C) 2005 Free Software Foundation, Inc. /opt/gcc-4_2-build# For WinXP (Cygwin): $ xterm -version Cygwin 6.8.2.0(202) $ bash --version GNU bash, version 3.2.15(13)-release (i686-pc-cygwin) Copyright (C) 2005 Free Software Foundation, Inc. My X11 is: $ x --version Welcome to the XWin X Server Vendor: The Cygwin/X Project Release: 6.8.99.901-4 My window-manager is OpenBox. This problem poped up in the last month. I tried to not complain and see if it would be fixed after a few updates - but like you said, some other people don't have this problem. It is NOT a visible problem unless you type gcc -v. The compiler works fine with this error. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31746
[Bug c++/31761] Build fails with exception.hpp:84: internal compiler error: Segmentation fault
--- Comment #3 from rob1weld at aol dot com 2007-04-30 00:14 --- Did some more testing. The results that follow are from the output of a shell script to catch each error and defeat it. I have edited it down for this report. There is a bug in gcc-4_2 in that it won't let you make a new ABI (with a three stage build). So how can you switch ABIs? I was able to convert Cygwin from coff-pe object file format to elf object file format (so I can use TLS and other superior elf features). That is similar to an ABI conversion but was more of a binutils issue (and then recompiling gcc over the new as and ld). At the moment I am back to using normal Cygwin (so others can duplicate what I am doing :) ). There is a similar problem with using all those fancy options (EG: --enable-java-awt=gtk,xlib --enable-gtk-cairo --enable-qt-peer --enable-xmlj --enable-gconf-peer _AND_ also using --enable-multilib) that involves gcc looking for 64 bit libraries (that don't even exist) in /usr/lib when it should look in /lib64. EG: # objdump -a /usr/lib/libreadline.so /usr/lib/libreadline.so: file format elf32-i386 # objdump -a /lib64/libreadline.so.5 /lib64/libreadline.so.5: file format elf64-x86-64 So if I use --enable-multilib and need -lreadline then I am OK, but later in the compile when I need -lxslt it looks for it in /usr/lib/libxslt.so BUT I need it to look in /lib64 (which is linked to from /usr/lib64) but the ./configure script does not catch that. _THIS_ bug-report is about trying to switch ABIs (and using a three stage compile so it has a chance of working). When I tried to do this I discovered that the compiler would seg-fault INSTEAD of giving a correct error message. --- Here is the result of my attempt to prove this: cd /cygdrive/c/gcc-4_2-branch-build/ $ gcc/xgcc -v Using built-in specs. Target: i686-pc-cygwin Configured with: ../gcc-4_2-branch/configure --verbose --enable-languages=c,ada,c++,fortran,java,objc,obj-c++ --with-tune=athlon-xp --prefix=/usr --enable-objc-gc --enable-concept-checks --disable-multilib --exec-prefix=/usr --sysconfdir=/etc --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-gxx-include-dir=/usr/include/c++/4.2 --enable-libstdcxx-debug --enable-static --enable-shared --enable-initfini-array --enable-__cxa_atexit --enable-threads=posix --enable-version-specific-runtime-libs --enable-libssp --enable-libmudflap --enable-libgomp --disable-werror --enable-nls --with-included-gettext --enable-decimal-float --with-long-double-128 --enable-debug --disable-sjlj-exceptions --enable-java-gc=boehm --with-x --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --enable-java-awt=gtk,xlib --enable-gtk-cairo --enable-qt-peer --enable-xmlj --enable-gconf-peer --enable-tool-wrappers --enable-portable-native-sync --enable-libgcj-multifile --with-stabs --enable-hash-synchronization --enable-gc-debug --enable-interpreter --with-system-zlib --enable-libada --with-tls --enable-win32-registry --with-cpu=athlon-xp --with-arch=athlon-xp --enable-checking Thread model: posix gcc version 4.2.0 20070427 (prerelease) $ Echo Use xgcc (prerelease 20070427) $ cd /cygdrive/c/gcc-4_2-branch-build/i686-pc-cygwin/libstdc++-v3/include $ /cygdrive/c/gcc-4_2-branch-build/./gcc/xgcc -shared-libgcc -B/cygdrive/c/gcc-4_2-branch-build/./gcc -nostdinc++ -L/cygdrive/c/gcc-4_2-branch-build/i686-pc-cygwin/libstdc++-v3/src -L/cygdrive/c/gcc-4_2-branch-build/i686-pc-cygwin/libstdc++-v3/src/.libs -B/usr//bin/ -B/usr//lib/ -isystem /usr//include -isystem /usr//sys-include -Winvalid-pch -Wno-deprecated -x c++-header -g -O2 -I/cygdrive/c/gcc-4_2-branch-build/i686-pc-cygwin/libstdc++-v3/include/ -I/cygdrive/c/gcc-4_2-branch-build/i686-pc-cygwin/libstdc++-v3/include -I/cygdrive/C/makecygwin/gcc-4_2-branch/libstdc++-v3/libsupc++ -O2 -g /cygdrive/C/makecygwin/gcc-4_2-branch/libstdc++-v3/include/precompiled/extc++.h -o bits/extc++.h.gch/O2g.gch In file included from /cygdrive/C/makecygwin/gcc-4_2-branch/libstdc++-v3/include/precompiled/extc++.h:60: /cygdrive/c/gcc-4_2-branch-build/i686-pc-cygwin/libstdc++-v3/include/ext/pb_ds/exception.hpp: In function 'void pb_ds::__throw_join_error()': /cygdrive/c/gcc-4_2-branch-build/i686-pc-cygwin/libstdc++-v3/include/ext/pb_ds/exception.hpp:84: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. make[4]: *** [bits/extc++.h.gch/O2g.gch] Error 1 make[4]: Leaving directory `/cygdrive/c/gcc-4_2-branch-build/i686-pc-cygwin/libstdc++-v3/include' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/cygdrive/c/gcc-4_2-branch-build/i686-pc-cygwin/libstdc++-v3' make[2]: *** [all] Error 2 make[2]: Leaving directory `/cygdrive/c/gcc-4_2-branch-build/i686-pc-cygwin/libstdc++-v3' make[1]: *** [all-target-libstdc++-v3] Error 2 make[1]: Leaving directory `/cygdrive/c/gcc-4_2-branch-build' make: *** [all
[Bug libgcj/30570] Word DEBUG used as a variable in VMAccessController.java breaks build
--- Comment #5 from rob1weld at aol dot com 2007-05-01 09:16 --- This make -i check report shows Java compiled with ZERO errors: http://gcc.gnu.org/ml/gcc-testresults/2007-04/msg01490.html gcc version 4.2.0 20070427 (prerelease) --- === libjava tests === Running target unix === libjava Summary === # of expected passes 7006 # of expected failures 12 # of untested testcases 8 --- Unfortunatly there are problems with the other tests but this is an instance of the SVN (in combination with the correctness of the tests) giving a supposed perfect result for Java (in compination with the many configure flags). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30570
[Bug c/31741] dfp tests failing - internal compiler error
--- Comment #2 from rob1weld at aol dot com 2007-05-01 10:19 --- Successfully _forced_ the compile on Cygwin platform and posted a seperate report about the segmentation fault issue at: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31761 After running make -i check on Cygwin compile I also got many dfp errors. Due to the use of the _exact_ same options for Cygwin as I used for Linux and _forcing_ the compile to complete I got an enormous number of error messages in other parts (not dfp) of the compile which made the make check report HUGE - so it was not posted. Suffice to say that the dfp errors occur on both platforms (when compiled with these ./configure options). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31741
[Bug bootstrap/31746] Broken ./configure sed scripting affecting *gcc/configargs.h construction.
--- Comment #5 from rob1weld at aol dot com 2007-05-02 05:08 --- Thanks Andreas, The annoying un-quoted second occurance of the languages is now fixed. Somehow AutoConf decided that it was going to rebuild ./configure . I renamed my current configure and then did a new SVN to get the official one. They are very different. Mine says: Generated by GNU Autoconf 2.61. SVN says: Generated automatically using autoconf version 2.13 There are _many_ other differences. My SVN was able to merge what I had with it's comparison of the origonal SVN version and not complaint. I'm not going to concern myself with _why_ the regenerated file from the SVN's configure.in file produced a configure file that was broken. I'll just eye the two up and re-enable gomp and mudflaps for the Cygwin target (yes, they work) and leave the rest alone. This means that the configure.in file needs a once over. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31746
[Bug bootstrap/30341] Makefile using mv instead of ln not working on WinXP Cygwin Bash
--- Comment #2 from rob1weld at aol dot com 2007-05-03 09:49 --- Reviewing my old bug reports I noticed a reply may be needed here... I _do_ build in a directory that is different from the source. It is my guess that part of the problem is that Cygwin is attempting to make unix-LIKE commands operate on the WinXP platform - the other part of the trouble is that WinXP creates a ghost file in 8.3 format that lives for a moment to facilitate programs that might need 8.3 names. IE: if I access a file called long_name_file.txt the ghost called long_n~1.txt is also created. There is an explanation on msn developer (that I would need to google to re-visit) that explains this better than the above. In short, the links don't work if you create them and then re-name (or mv) them immediately. It confuses the OS (no jokes please :) ). Here is the resulting dorectory structure: What you (the creators of the source code) might have expected is: gcc prev-gcc etc. What you end up with is: gcc If you look in the gcc directory you then see ugly things like gcc (again) and prev-gcc. The make process will continue like this and eventually fail. If you stop it and restart it then you can (sometimes) get things like gcc/gcc/prev-gcc show up. If you have lots of other load running at the same time then you might not create/rename quick enough and the ghost disappears (thus the mv commands works as expected. You can't expect to get through a whole make and not get nailed at least once (which is enough to break it). Searching my HD for a Makefile that uses sleep between mv commands (I know I had one at one time), I found the ACL2 Rules for Writing Makefiles in their port to MinGW. file://C:\ACL2-3.1\mingw\info\make.info\Utilities-in-Makefiles.html (you probably don't have it and it is quite short, so I will quote it): --- Node:Utilities in Makefiles, Next:Command Variables, Previous:Makefile Basics, Up:Makefile Conventions Utilities in Makefiles Write the Makefile commands (and any shell scripts, such as configure) to run in sh, not in csh. Don't use any special features of ksh or bash. The configure script and the Makefile rules for building and installation should not use any utilities directly except these: cat cmp cp diff echo egrep expr false grep install-info ln ls mkdir mv pwd rm rmdir sed sleep sort tar test touch true The compression program gzip can be used in the dist rule. Stick to the generally supported options for these programs. For example, don't use mkdir -p, convenient as it may be, because most systems don't support it. It is a good idea to avoid creating symbolic links in makefiles, since a few systems don't support them. The Makefile rules for building and installation can also use compilers and related programs, but should do so via make variables so that the user can substitute alternatives. Here are some of the programs we mean: ar bison cc flex install ld ldconfig lex make makeinfo ranlib texi2dvi yacc Use the following make variables to run those programs: $(AR) $(BISON) $(CC) $(FLEX) $(INSTALL) $(LD) $(LDCONFIG) $(LEX) $(MAKE) $(MAKEINFO) $(RANLIB) $(TEXI2DVI) $(YACC) When you use ranlib or ldconfig, you should make sure nothing bad happens if the system does not have the program in question. Arrange to ignore an error from that command, and print a message before the command to tell the user that failure of this command does not mean a problem. (The Autoconf AC_PROG_RANLIB macro can help with this.) If you use symbolic links, you should implement a fallback for systems that don't have symbolic links. Additional utilities that can be used via Make variables are: chgrp chmod chown mknod It is ok to use other utilities in Makefile portions (or scripts) intended only for particular systems where you know those utilities exist. --- Usually GCC makefiles _do_ follow those rules. Not everything that works for Unix bash works for Cygwin's bash (I do have the most current version). This only occurs on Cygwin. The makefile that ./configure creates works fine on the i686-pc-linux-gnu target, with it's bash shell. Strangely the MinGW bash also does NOT have any trouble - only the _current_ Cygwin bash. My point is that the method used in the 4.1.1 Makefile (generated by ./configure) works on all these platforms and the NEW 4.2.0 Makefile method breaks on Cygwin. This bug report is an explanation of the problem and how either it can be fixed by the maintainers _OR_ people (who use Cygwin) can search the bug reports and make their own repairs; in the event that the maintainers do not desire to alter the way the makefile is created to accommadate this peculiar problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30341
[Bug libgcj/31650] gcc-4_2-branch uses class that has been removed - breaks make
--- Comment #3 from rob1weld at aol dot com 2007-05-03 09:55 --- Another test results report (4.2.0 20070501 on i686-pc-linux-gnu) is here: http://gcc.gnu.org/ml/gcc-testresults/2007-05/msg00135.html Almost every option enabled, almost all tests passed (except dfp, in C). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31650
[Bug c/31741] dfp tests failing - internal compiler error
--- Comment #3 from rob1weld at aol dot com 2007-05-03 10:00 --- Another test results report for i686-pc-linux-gnu (4.2.0 20070501): http://gcc.gnu.org/ml/gcc-testresults/2007-05/msg00135.html Nearly all options are enabled. Nearly all tests pass. A few have ZERO errors! (hurray). DFP still broken. :( Contains a decent explanation of the many libraries needed to compile GCC. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31741
[Bug ada/31744] Ada has way TOO MANY may be used uninitialized warnings.
--- Comment #2 from rob1weld at aol dot com 2007-05-03 10:09 --- Confirmed. My Linux system has gcc 4.2.0 installed and I do NOT get that many warnings, only a couple. I _do_ have the _newest_ possible version of all programs for Cygwin. In any event, on _any_ platform, it is actually gcc/xgcc that is used to compile that portion of Ada that has the enormous number of warnings and not /usr/bin/gcc. My test results for i686-pc-linux-gnu are here (nearly no Ada errors): http://gcc.gnu.org/ml/gcc-testresults/2007-05/msg00135.html Previous results on the Cygwin platform for Ada had results like this: gcc version 4.2.0 20070202 (prerelease) =-= stage3-gcc/testsuite/ada/acats/acats.log === acats Summary === # of expected passes1937 # of unexpected failures22 # of unsupported tests 356 *** FAILURES: c23003b c23003g c23003i c35507m cd2a23e cdd2a02 cxg2002 cxg2003 cxg2004 cxg2006 cxg2007 cxg2010 cxg2011 cxg2012 cxg2013 cxg2015 cxg2016 cxg2017 cxg2018 cxg2019 cxg2020 cxg2021 gcc version 4.2.0 20070427 (prerelease) =-= stage3-gcc/testsuite/ada/acats/acats.log === acats Summary === # of expected passes1940 # of unexpected failures19 # of unsupported tests 356 *** FAILURES: c23003b c23003g c23003i cxg2002 cxg2003 cxg2004 cxg2006 cxg2007 cxg2010 cxg2011 cxg2012 cxg2013 cxg2015 cxg2016 cxg2017 cxg2018 cxg2019 cxg2020 cxg2021 Simply searching http://gcc.gnu.org/ml/gcc-testresults/ for i686-pc-cygwin should show that there are not quite as good results for Ada on that target. If you want Ada to run on WinXP it will need to either work on Cygwin or MinGW. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31744
[Bug c/31741] dfp tests failing - internal compiler error
--- Comment #4 from rob1weld at aol dot com 2007-05-05 18:55 --- Results for Cygwin are very similar (for DFP) - other areas have differing errors: Results for 4.2.0 20070501 (prerelease) testsuite on i686-pc-cygwin http://gcc.gnu.org/ml/gcc-testresults/2007-05/msg00258.html May I suggest that this problem (on two platforms) needs to be independantly confirmed. With this fixed we we have very few errors remaining in 4.2.0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31741
[Bug libmudflap/31845] New: Need to adjust libmudflap timeout values in testsuite.
On one of the longer tests ( libmudflap.cth/pass40-frag.c ) the testsuite reports a timeout but looking at the logfile the test seem to be working. My computer is fairly fast. I propose that the values be increased for that test. http://gcc.gnu.org/ml/gcc-testresults/2007-05/msg00314.html -- Summary: Need to adjust libmudflap timeout values in testsuite. Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libmudflap 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=31845
[Bug testsuite/31846] New: Logs are not being parsed correctly by testsuite and test_summary scripts.
In the first place the .log files are not being created correctly by the testsuite in all cases. This results in the test_summary script failing to mail all the errors that could be reported. Problem 1): The boehm-gc tests are not included by the test_summary, script (and never were previously, to my recolection). This is likely because make -i check does not create a .log file (but does test boehm-gc). I saved the screen output and here is what I see: make[3]: Leaving directory `/opt/gcc-4_2-build/i686-pc-linux-gnu/boehm-gc/include' make[3]: Entering directory `/opt/gcc-4_2-build/i686-pc-linux-gnu/boehm-gc' /bin/sh ./libtool --mode=link /opt/gcc-4_2-build/./gcc/xgcc -B/opt/gcc-4_2-build/./gcc/ -B/usr/i686-pc-linux-gnu/bin/ -$ /opt/gcc-4_2-build/./gcc/xgcc -B/opt/gcc-4_2-build/./gcc/ -B/usr/i686-pc-linux-gnu/bin/ -B/usr/i686-pc-linux-gnu/lib/ -$ tests/test.o: In function `mktree': /root/downloads/gcc-4_2-branch/boehm-gc/tests/test.c:798: undefined reference to `GC_local_malloc' /root/downloads/gcc-4_2-branch/boehm-gc/tests/test.c:807: undefined reference to `GC_local_malloc_atomic' tests/test.o: In function `local_cons': /root/downloads/gcc-4_2-branch/boehm-gc/tests/test.c:264: undefined reference to `GC_local_malloc' /root/downloads/gcc-4_2-branch/boehm-gc/tests/test.c:267: undefined reference to `GC_local_gcj_malloc' collect2: ld returned 1 exit status make[3]: [gctest] Error 1 (ignored) make AR_FLAGS=rc CC_FOR_BUILD=gcc CFLAGS=-O2 -g -O2 CXXFLAGS=-g -O2 -D_GNU_SOURCE CFLAGS_FOR_BUILD=-g -O2 $ make[4]: Entering directory `/opt/gcc-4_2-build/i686-pc-linux-gnu/boehm-gc' /bin/sh ./libtool --mode=link /opt/gcc-4_2-build/./gcc/xgcc -B/opt/gcc-4_2-build/./gcc/ -B/usr/i686-pc-linux-gnu/bin/ -$ /opt/gcc-4_2-build/./gcc/xgcc -B/opt/gcc-4_2-build/./gcc/ -B/usr/i686-pc-linux-gnu/bin/ -B/usr/i686-pc-linux-gnu/lib/ -$ tests/test.o: In function `mktree': /root/downloads/gcc-4_2-branch/boehm-gc/tests/test.c:798: undefined reference to `GC_local_malloc' /root/downloads/gcc-4_2-branch/boehm-gc/tests/test.c:807: undefined reference to `GC_local_malloc_atomic' tests/test.o: In function `local_cons': /root/downloads/gcc-4_2-branch/boehm-gc/tests/test.c:264: undefined reference to `GC_local_malloc' /root/downloads/gcc-4_2-branch/boehm-gc/tests/test.c:267: undefined reference to `GC_local_gcj_malloc' collect2: ld returned 1 exit status make[4]: [gctest] Error 1 (ignored) /bin/sh: line 8: /root/downloads/gcc-4_2-branch/boehm-gc/gctest: No such file or directory FAIL: gctest === 1 of 1 tests failed === make[4]: [check-TESTS] Error 1 (ignored) make[4]: Leaving directory `/opt/gcc-4_2-build/i686-pc-linux-gnu/boehm-gc' Problem 2): The testsuite scripts fails in the parsing of the libstdc+-v3 .log file. There is some breakage in grabbing the .log file that results in the compiler output filling up part of the logs. The other difficulty is that the expect is unprepared for the libstdc++-v3 check-abi Summary. It's final output is in a format that seems compatable with the test_summary script but it's result is not included in mail to [EMAIL PROTECTED] . Here is what it looks like in i686-pc-linux-gnu/libstdc++-v3/testsuite/libstdc++.log : === libstdc++-v3 check-abi Summary === # of added symbols: 114 # of missing symbols:46 # of incompatible symbols: 92 My last make -i check (with notes at the end) is here: http://gcc.gnu.org/ml/gcc-testresults/2007-05/msg00314.html -- Summary: Logs are not being parsed correctly by testsuite and test_summary scripts. Product: gcc Version: 4.2.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: 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=31846
[Bug java/31890] New: Java Namespace error - javaprims.h out of sync
; class MemoryHandler; class SimpleFormatter; @@ -538,134 +534,3 @@ } } } -} - -typedef struct java::lang::Object* jobject; In the namespace java section should all the -'s be removed and the +'s added ? Is it incorrect to follow those instructions to test the javaprims.h file ? -- Summary: Java Namespace error - javaprims.h out of sync Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: java 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=31890
[Bug bootstrap/30341] Makefile using mv instead of ln not working on WinXP Cygwin Bash
--- Comment #3 from rob1weld at aol dot com 2007-05-10 06:43 --- I tried an un-modified Makefile on WinXP, running X11 under Cygwin, with Xterm running bash, compiling with cygwin (whew!) - the problem does NOT occur there. This problem only seems to occur under a Cygwin MSDOS shell running bash (the usual / normal way Cygwin provides a running environment for bash). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30341
[Bug bootstrap/30342] Tough time building 4.2.0 (CVS) on WinXP with Cygwin
--- Comment #5 from rob1weld at aol dot com 2007-05-10 06:51 --- Having great success compiling GCC (with nearly every option enabled) using the above instructions. More recent compile test results are here: Results for 4.2.0 20070501 (prerelease) testsuite on i686-pc-cygwin http://gcc.gnu.org/ml/gcc-testresults/2007-05/msg00258.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30342
[Bug libgcj/31891] New: Libjava configuration scripts out of sync for pkg-config tests
on your system.\n);
printf(*** If pkg-config was wrong, set the environment variable
PKG_CONFIG_PATH\n);
printf(*** to point to the correct configuration files\n);
}
else if ((gtk_major_version != GTK_MAJOR_VERSION) ||
(gtk_minor_version != GTK_MINOR_VERSION) ||
(gtk_micro_version != GTK_MICRO_VERSION))/*
Compare with installed headers */
{
printf(*** GTK+ header files (version %d.%d.%d) do not match\n,
GTK_MAJOR_VERSION, GTK_MINOR_VERSION, GTK_MICRO_VERSION);
printf(*** library (version %d.%d.%d)\n,
gtk_major_version, gtk_minor_version, gtk_micro_version);
}
else
{
if ((gtk_major_version major) ||
((gtk_major_version == major) (gtk_minor_version minor)) ||
((gtk_major_version == major) (gtk_minor_version == minor)
(gtk_micro_version = micro)))
{
return 0;
}
else
{
printf(\n*** An old version of GTK+ (%d.%d.%d) was found.\n,
gtk_major_version, gtk_minor_version, gtk_micro_version);
printf(*** You need a version of GTK+ newer than %d.%d.%d. The latest
version of\n,
major, minor, micro);
printf(*** GTK+ is always available from ftp://ftp.gtk.org.\n;);
printf(***\n);
printf(*** If you have already installed a sufficiently new version,
this error\n);
printf(*** probably means that the wrong copy of the pkg-config shell
script is\n);
printf(*** being found. The easiest way to fix this is to remove the
old version\n);
printf(*** of GTK+, but you can also set the PKG_CONFIG environment to
point to the\n);
printf(*** correct copy of pkg-config. (In this case, you will have
to\n);
printf(*** modify your LD_LIBRARY_PATH enviroment variable, or edit
/etc/ld.so.conf\n);
printf(*** so that the correct libraries are found at run-time))\n);
}
}
return 1;
}
The old method was to create a program and make a call to the library to get
it to tell you it's version. The modern way is to use pkg-config (which
usually requires you to get the xyz-DEVEL-version just to get the .pc file).
Note that the above code is not perfect. First it tests != and if true,
fails. It does not get to the test further on that checks . The code (as
written) requires that the version of the headers match the version of the
.dlls, but the (windows) gtk site
(http://www.gimp.org/~tml/gimp/win32/downloads.html) says it is OK to use old
headers and new .dlls.
It _might_ be OK to change the test to allow older headers with the newer .dlls
for _some_ versions (no doubt there are versions of each that this would not
work - it is easier not to check a compatability list but leads to more work to
install dev libs).
A good place to get gtk for Cygwin (ready to roll) is from:
GTK+ and The GIMP installers for Windows
http://sourceforge.net/project/showfiles.php?group_id=121075
First install the Cygwin setup.exe Gtk (and other needed files), then install
the sourceforge version using directory c:\cygwin\gtk\2.0\ (instead of the
installer program's default).
Next, alter your C:\cygwin\lib\pkgconfig\gtk+-2.0.pc file and fix these two
lines like this:
libdir=/gtk/2.0/bin/
Version: 2.10.11
(You might also need to impgen the .dll files.)
Java seems to be configuring fine (for Cygwin) and compiling without error.
For Linux I used a non-stable gtk (and all the other gtk dependancies) obtained
with Aptitude (and a LOT of dependancy tweaking). Evrything _IS_ compiling and
testing very well under Linux (for the JAVA portion of gcc).
--
Summary: Libjava configuration scripts out of sync for pkg-config
tests
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcj
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=31891
[Bug libgcj/31910] New: Trouble with libtool and libjava/classpath/native/jni/gtk-peer/Makefile
/libatk-1.0.dll.a /usr/lib/libpangoxft-1.0.dll.a -lXft -lz -lXrender -lXext -lfontconfig /usr/lib/libpangox-1.0.dll.a -lX11 -lm -lintl -liconv -lz /usr/lib/libpangoft2-1.0.dll.a -lfontconfig /usr/lib/libfreetype.dll.a -lz /usr/lib/libpango-1.0.dll.a -lm /usr/lib/libgobject-2.0.dll.a /usr/lib/libgmodule-2.0.dll.a /usr/lib/libglib-2.0.dll.a -lintl -liconv -lSM -lICE -lXrender -lXrandr -lX11 -lXtst -lcairo -Wl,-soname -Wl,libgtkpeer.dll.a -o .libs/libgtkpeer.dll.a Typing that produces _only_ an information message (no errors or warnings!), which is normal: Info: resolving _gdk_display by linking to __imp__gdk_display (auto-import) $ls -l /cygdrive/c/gcc-4_2-branch-build/i686-pc-cygwin/libjava/classpath/native/jni/gtk-peer/.libs/libgtkpeer.dll.a -rwxr-xr-x 1 HP_Administrator None 1340108 May 12 19:31 libgtkpeer.dll.a So all the messing around worked, the file is created and correct. I can go on to make in the next directory. :^( --- The specific bug complaint is that the Makefile creates libtool's which have a broken pipe and produce ZERO byte length impgen.c files. These (obviously) can not be compiled and cause an error for xgcc when it tries to compile them. That breaks the make. Simply copying a 'known good' impgen.c (or .exe), and touching it doesn't work since the Makefile insists on re-creating the impgen.c file (it's not checking the timestamp). Running the commands by hand is annoying but provides working libraries (.dll.a) and other files (.dll-def) that the Makefile needs to see in each directory so it can continue on to the next step. The gcc-4_2-branch ./configures and subsequent Makefiles are not creating a libtool that works well enough with the broken Makefile - so it is hard to know where to begin fixing. It would be great if (on the cygwin platform) we could avoid the impgening steps (Linux does not do it, it simply uses .so files). On Cygwin we could use .dll files instead of .dll.a files since GCC (and even xgcc) knows to pass them to the linker. We may not need the .dll-def files that impgen creates either. Someone came up with this scheme of doing things this way (and I can see it working) but it needs some maintenance. I imagine the .a files are needed with the export lists (the .dll-def files) so something, somewhere, can know what functions are available without having to use a seperate list for each gtk version. For some reason this scheme is NOT used on the i686-pc-linux-gnu target. I do have every language compiled and make -i check tested on the i686-pc-linux-gnu target and it is working reasonably well (very few errors). It had been some months since I upgraded my gtk (and since gcc-4_2-branch wants 2.8) I decided to upgrade cygwin to the newest gtk 2.10.11 - and thus need to 'impgen it' again. Without this working better it is tough to get Java working on WinXP. Since the method used on the Cygwin target is very different from the method used on the Linux target it is tough to convert one way of doing things to the other way (and makes maintaining it tough - this is why it works on Linux and not on cygwin). It _could_ work on both platforms better and would be easier to maintain if we homogenized the make scheme to adopt one way of doing it and chose between .so, .dll or .a based on whether we where building static or shared (and if testing if shared libraries were suffixed with .so or .dll). The GCC make scheme does NOT have this complexity in other areas, this bi-polar scheme is making me bi-polar :) -- Summary: Trouble with libtool and libjava/classpath/native/jni/gtk-peer/Makefile Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rob1weld at aol dot com GCC build triplet: i686-pc-cygwin GCC host triplet: i686-pc-cygwin GCC target triplet: i686-pc-cygwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31910
[Bug c/31741] dfp tests failing - internal compiler error
--- Comment #5 from rob1weld at aol dot com 2007-05-13 05:47 --- Thanks - the most recent SVN has fewer DFP errors. If we _really_ don't want DFP on any platform except PowerPC then we should change ./configure for it to be prohibited. I can't see why it could not be supported on other (modern) uP's. I'm in favour of keeping it for the Intel chips. Getting an internal compiler error is clearly not desired - supported or not. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31741
[Bug testsuite/31912] New: Using included gettext changes number of dump-noaddr tests being ran with make -i check.
-double-128 --enable-debug --enable-java-gc=boehm --with-x --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --enable-java-awt=gtk,xlib --enable-gtk-cairo --enable-qt-peer --enable-xmlj --enable-gconf-peer --enable-tool-wrappers --enable-portable-native-sync --enable-libgcj-multifile --enable-libgcj --with-stabs --enable-hash-synchronization --enable-gc-debug --enable-interpreter --with-system-zlib --enable-libada --with-tls --enable-win32-registry --with-cpu=athlon-xp --with-arch=athlon-xp --disable-checking --enable-languages=c,ada,c++,fortran,java,objc,obj-c++ --without-included-gettext configure flags: --verbose --with-tune=athlon-xp --prefix=/usr --enable-objc-gc --enable-concept-checks --disable-multilib --exec-prefix=/usr --sysconfdir=/etc --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-gxx-include-dir=/usr/include/c++/4.2 --enable-libstdcxx-debug --enable-static --enable-shared --enable-initfini-array --enable-__cxa_atexit --enable-threads=posix --enable-version-specific-runtime-libs --enable-libssp --enable-libmudflap --enable-libgomp --disable-werror --enable-nls --without-included-gettext --enable-decimal-float --with-long-double-128 --enable-debug --enable-java-gc=boehm --with-x --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --enable-java-awt=gtk,xlib --enable-gtk-cairo --enable-qt-peer --enable-xmlj --enable-gconf-peer --enable-tool-wrappers --enable-portable-native-sync --enable-libgcj-multifile --enable-libgcj --with-stabs --enable-hash-synchronization --enable-gc-debug --enable-interpreter --with-system-zlib --enable-libada --with-tls --enable-win32-registry --with-cpu=athlon-xp --with-arch=athlon-xp --disable-checking --enable-languages=c,ada,c++,fortran,java,objc,obj-c++ The enter_bug.cgi page doesn't let you make attachments (on your first post) so I need to wait until the Create a New Attachment (proposed patch, testcase, etc.) text appears and make a _second_ post to add the .log files. -- Summary: Using included gettext changes number of dump-noaddr tests being ran with make -i check. Product: gcc Version: 4.2.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: i686-pc-cygwin GCC host triplet: i686-pc-cygwin GCC target triplet: i686-pc-cygwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31912
[Bug testsuite/31912] Using included gettext changes number of dump-noaddr tests being ran with make -i check.
--- Comment #2 from rob1weld at aol dot com 2007-05-13 14:29 --- Created an attachment (id=13548) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13548action=view) gcc.log (configured using with) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31912
[Bug testsuite/31912] Using included gettext changes number of dump-noaddr tests being ran with make -i check.
--- Comment #1 from rob1weld at aol dot com 2007-05-13 14:27 --- Created an attachment (id=13547) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13547action=view) gcc.log (configured using without) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31912
[Bug libgcj/31890] Java Namespace error - javaprims.h out of sync
--- Comment #2 from rob1weld at aol dot com 2007-05-15 05:29 --- Thanks. If someone with write-access runs the script and tosses the result into the SVN I'll consider this bug resolved (for me). I changed severity to minor. The maintainers _might_ want to update the Makefile maintainer scripts (or whatever scripts you use to test GCC prior to sending in your changes to the SVN) so that the script gets ran when changes are made to the appropriate files (don't forget the check_jni_methods.sh problem while your there :) ). -- rob1weld at aol dot com changed: What|Removed |Added Severity|major |minor http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31890
[Bug libgcj/31910] Trouble with libtool and libjava/classpath/native/jni/gtk-peer/Makefile
--- Comment #1 from rob1weld at aol dot com 2007-05-15 05:54 ---
I did some hacking to push the make through and find all occurances of the
problem, then I rebuild from a fresh directory and condensed my changes.
It came down to a few problems all interacting together - changes and updates
were made to the code over time but were not tested on all platforms. The
breakage on the Cygwin platform became imense.
This probably affects other platforms supported by gcc-4.2 that use .dlls - EG:
arm-none-symbian
---
Problem 1):
The variable BUILD_CC is not defined for this portion of
/gcc-4_2-branch-build/i686-pc-cygwin/libjava/classpath/libtool
# The commands to extract the exported symbol list from a shared archive.
extract_expsyms_cmds=test -f \$output_objdir/impgen.c ||
sed -e \\\/^# /* impgen.c starts here *//,/^#
/* impgen.c ends here *// { s/^# //; p; }\\\ -e d \$0
\$output_objdir/impgen.c~
test -f \$output_objdir/impgen.exe || (cd \$output_objdir
if test \\\x\$BUILD_CC\\\ != \\\x\\\ ; then \$BUILD_CC -o impgen
impgen.c ;
else \$CC -o impgen impgen.c ; fi)~
\$output_objdir/impgen \$dir/\$soroot \$output_objdir/\$soname-def
Check the build directory - here are two potential problems:
$ grep -r BUILD_CC /cygdrive/c/gcc-4_2-branch-build-9b/i686-pc-cygwin/libjava/*
/cygdrive/c/gcc-4_2-branch-build/i686-pc-cygwin/libjava/classpath/libtool: if
test \\\x\$BUILD_CC\\\ != \\\x\\\ ; then \$BUILD_CC -o impgen impgen.c ;
/cygdrive/c/gcc-4_2-branch-build/i686-pc-cygwin/libjava/libtool: if test
\\\x\$BUILD_CC\\\ != \\\x\\\ ; then \$BUILD_CC -o impgen impgen.c ;
Check the source directory - here is the answer:
$ grep -r BUILD_CC /cygdrive/c/gcc-4_2-branch/*
/cygdrive/c/gcc-4_2-branch/ChangeLog: note known problems; set CONFIG_SHELL;
don't set BUILD_CC; relocate
/cygdrive/c/gcc-4_2-branch/ChangeLog: * Makefile.tpl: Remove BUILD_CC stuff.
/cygdrive/c/gcc-4_2-branch/gcc/ChangeLog-1998: * configure.in: Use
CC_FOR_BUILD, not BUILD_CC.
/cygdrive/c/gcc-4_2-branch/gcc/ChangeLog-2003: * configure.in: Replace
BUILD_CC references with CC_FOR_BUILD.
/cygdrive/c/gcc-4_2-branch/gcc/ChangeLog-2003: * Makefile.in: Replace BUILD_CC
references with CC_FOR_BUILD.
/cygdrive/c/gcc-4_2-branch/gcc/ChangeLog-2003: Set BUILD_CC to the same as CC.
/cygdrive/c/gcc-4_2-branch/libjava/classpath/ltcf-c.sh: if test x$BUILD_CC
!= x ; then $BUILD_CC -o impgen impgen.c ; \
/cygdrive/c/gcc-4_2-branch/libjava/classpath/ltcf-gcj.sh: if test x$BUILD_CC
!= x ; then $BUILD_CC -o impgen impgen.c ; \
/cygdrive/c/gcc-4_2-branch/ltcf-c.sh: if test x$BUILD_CC != x ; then
$BUILD_CC -o impgen impgen.c ; \
/cygdrive/c/gcc-4_2-branch/ltcf-gcj.sh: if test x$BUILD_CC != x ; then
$BUILD_CC -o impgen impgen.c ; \
/cygdrive/c/gcc-4_2-branch/ChangeLog
2004-03-22 Nathanael Nerode [EMAIL PROTECTED]
* Makefile.tpl: Clean up experimental top level bootstrap support:
note known problems; set CONFIG_SHELL; don't set BUILD_CC; relocate
prev-gcc in configure- targets as well as all- targets.
* Makefile.in: Regenerate.
2003-06-18 Nathanael Nerode [EMAIL PROTECTED]
* Makefile.tpl: Remove BUILD_CC stuff.
* Makefile.in: Regenerate.
It would seem that BUILD_CC was removed some time ago but there are still 4
files using it.
Temp fix C:\gcc-4_2-branch-build\i686-pc-cygwin\libjava\classpath\libtool by
adding this near top of file:
BUILD_CC=gcc
Problem 2):
The error above (../../../libtool: eval: line 2680: syntax error near
unexpected token `fi') is caused by this command being used (even _after_
fixing BUILD_CC there is more):
$ (cd .libs \ if test xgcc != x ; then gcc -o impgen impgen.c ; \ else
/cygdrive/c/gcc-4_2-branch-build-9b/./gcc/xgcc
-B/cygdrive/c/gcc-4_2-branch-build-9b/./gcc/ -B/usr/i686-pc-cygwin/bin/
-B/usr/i686-pc-cygwin/lib/ -isystem /usr/i686-pc-cygwin/include -isystem
/usr/i686-pc-cygwin/sys-include -o impgen impgen.c ; fi)
-bash: syntax error near unexpected token `then'
Remove all the \'s and try again:
$ (cd .libs if test xgcc != x ; then gcc -o impgen impgen.c ; else
/cygdrive/c/gcc-4_2-branch-build-9b/./gcc/xgcc
-B/cygdrive/c/gcc-4_2-branch-build-9b/./gcc/ -B/usr/i686-pc-cygwin/bin/
-B/usr/i686-pc-cygwin/lib/ -isystem /usr/i686-pc-cygwin/include -isystem
/usr/i686-pc-cygwin/sys-include -o impgen impgen.c ; fi)
That worked - so here is the change for libtool (alter to \ on three
lines):
## The commands to extract the exported symbol list from a shared archive.
#extract_expsyms_cmds=test -f \$output_objdir/impgen.c ||
# sed -e \\\/^# /* impgen.c starts here *//,/^#
/* impgen.c ends here *// { s/^# //; p; }\\\ -e d \$0
\$output_objdir/impgen.c~
# test -f \$output_objdir/impgen.exe || (cd \$output_objdir
# if test \\\x\$BUILD_CC\\\ != \\\x\\\ ; then \$BUILD_CC -o impgen
impgen.c ;
# else \$CC -o
[Bug testsuite/31928] New: Libjava testsuite not setting test environment parameters correctly.
Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rob1weld at aol dot com GCC build triplet: i686-pc-cygwin GCC host triplet: i686-pc-cygwin GCC target triplet: i686-pc-cygwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31928
[Bug testsuite/31928] Libjava testsuite not setting test environment parameters correctly.
--- Comment #1 from rob1weld at aol dot com 2007-05-15 06:23 --- Created an attachment (id=13556) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13556action=view) Log of testsuite failures on Cygwin - 1,000 KB -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31928
[Bug libgcj/16662] IllegalMonitorStateException in EventQueue.getNextEvent(): possible hash synchronization bug?
--- Comment #11 from rob1weld at aol dot com 2007-05-15 10:46 --- Here are my results with gcc version 4.2.0 20070505 (prerelease). /wonka# ./vte logMessage is called /root/downloads/gcc-4_2-branch/libjava/classpath/native/jni/gtk-peer/gthread-jni.c:1242: AWT JNI failure (BROKEN): cannot exit monitor Description follows to System.err: java.lang.IllegalMonitorStateException: current thread not owner No stacktrace available /root/downloads/gcc-4_2-branch/libjava/classpath/native/jni/gtk-peer/gthread-jni.c:1242: Aborting execution; BROKEN: cannot exit monitor Aborting execution Aborted I tried to chose reopen bug but that is not allowed (for me). I will file a new report and reference this bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16662
[Bug libgcj/31931] New: Mauve test wonka causes java.lang.IllegalMonitorStateException: current thread not owner error
I compiled gcc version 4.2.0 20070505 (prerelease) and decided to try some of the Mauve tests ( http://sources.redhat.com/mauve/ ) as suggested on http://gcc.gnu.org/install/test.html . I did read http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16662 but when I tried to re-open the bug it was not allowed. I tried to download the testcase attachment on that page but it seems that the file is missing. Here is the problem: wonka# ./vte logMessage is called /root/downloads/gcc-4_2-branch/libjava/classpath/native/jni/gtk-peer/gthread-jni.c:1242: AWT JNI failure (BROKEN): cannot exit monitor Description follows to System.err: java.lang.IllegalMonitorStateException: current thread not owner No stacktrace available /root/downloads/gcc-4_2-branch/libjava/classpath/native/jni/gtk-peer/gthread-jni.c:1242: Aborting execution; BROKEN: cannot exit monitor Aborting execution Aborted I have tried other programs and _did_ get a stacktrace, I don't know why this program says it is not available. I did some googling which led me to bug 16662 - there are not many hits for the error message given. $xgcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: /root/downloads/gcc-4_2-branch/configure --verbose --enable-languages=c,ada,c++,fortran,java,objc,obj-c++ --with-tune=athlon-xp --prefix=/usr --enable-objc-gc --enable-concept-checks --disable-multilib --with-gxx-include-dir=/usr/include/c++/4.2 --enable-libstdcxx-debug --enable-static --enable-shared --enable-initfini-array --enable-__cxa_atexit --enable-threads=posix --enable-version-specific-runtime-libs --enable-libssp --enable-libmudflap --enable-libgomp --disable-werror --enable-nls --with-included-gettext --enable-decimal-float --with-long-double-128 --enable-debug --enable-java-gc=boehm --with-x --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --enable-java-awt=gtk,xlib --enable-gtk-cairo --enable-qt-peer --enable-xmlj --enable-gconf-peer --enable-tool-wrappers --with-gjdoc --enable-portable-native-sync --enable-libgcj-multifile --with-stabs --enable-hash-synchronization --enable-gc-debug --enable-interpreter --with-system-zlib --enable-libada --with-tls --with-cpu=athlon-xp --with-arch=athlon-xp --enable-checking : (reconfigured) /root/downloads/gcc-4_2-branch/configure --verbose --enable-languages=c,ada,c++,fortran,java,objc,obj-c++ --with-tune=athlon-xp --prefix=/usr --enable-objc-gc --enable-concept-checks --disable-multilib --with-gxx-include-dir=/usr/include/c++/4.2 --enable-libstdcxx-debug --enable-static --enable-shared --enable-initfini-array --enable-__cxa_atexit --enable-threads=posix --enable-version-specific-runtime-libs --enable-libssp --enable-libmudflap --enable-libgomp --disable-werror --enable-nls --with-included-gettext --enable-decimal-float --with-long-double-128 --enable-debug --enable-java-gc=boehm --with-x --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --enable-java-awt=gtk,xlib --enable-gtk-cairo --enable-qt-peer --enable-xmlj --enable-gconf-peer --enable-tool-wrappers --with-gjdoc --enable-portable-native-sync --enable-libgcj-multifile --with-stabs --enable-hash-synchronization --enable-gc-debug --enable-interpreter --with-system-zlib --enable-libada --with-tls --with-cpu=athlon-xp --with-arch=athlon-xp --enable-checking=assert,fold,gc,gcac,misc,rtl,rtlflag,runtime,tree Thread model: posix gcc version 4.2.0 20070505 (prerelease) -- Summary: Mauve test wonka causes java.lang.IllegalMonitorStateException: current thread not owner error Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcj 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=31931
[Bug driver/31963] New: The configure option --enable-stage1-checking is undocumented (and incorrectly named)
This bug report is listed for the HTB i686-pc-linux-gnu but actually affects ALL platforms. The reason I chose to put this under the Component choice driver is because there is no choice for documentation and it does involve renaming one of the compiler command line options. --- When I compile with --enable-checking=? the checking is performed on stages 2,3 and the libraries - it is NOT performed on stage 1. When I compile with --enable-stage1-checking the checking is performed on stage TWO only, and NOT on any other stages (or the libraries). To _actually_ check stage 1 you would need the Operating System's GCC to have been compiled using the checking options - otherwise stage 1 is never checked. Correct ? BUG 1): The configure option --enable-stage1-checking is named incorrectly. We need to change the configure script and make it a depreciated or obsoleted option and add an option that is instead called --enable-stage2-checking (does the same thing, just correct the name). BUG 2): The configure option --enable-stage1-checking (or --enable-stage2-checking) is not documented. Using grep I find the word in these files: # grep -r stage1-checking gcc-4_2-branch/* gcc-4_2-branch/ChangeLog gcc-4_2-branch/autom4te.cache/output.0 gcc-4_2-branch/configure gcc-4_2-branch/configure.in The file gccinstall.info (and any .html DOCs) and the files that create them are the correct location to document this feature - directly under the notes for --enable-checking. Suggestion 1): Use --enable-stage2-checking to enable a few more checks by default. The gccinstall.info file says this for the `--enable-checking' option: The full set of flags available are: assert, fold, gc, gcac misc, rtl, rtlflag, runtime, tree, and valgrind. The rtl, gcac and valgrind checks are very expensive. (NOTE: See below! fold is expensive - DOCs are wrong?) When building from SVN or snapshots we use assert, gc, misc, rtlflag, runtime and tree. The release versions use only assert and runtime. Thus, according to the DOCs (which do need updating), when we build the SVN we are not using: fold, gcac rtl, and valgrind. I suggest that when building the SVN version we could use, (on all stages), the flags --enable-checking=assert,misc,rtlflag,runtime,tree, and the additional flag (now called) --enable-stage2-checking=fold,gc,rtl for better, faster checking. Would we want to add misc and rtlflag to the release version checks ? The gcac (GC_ALWAYS_COLLECT) flag could probably be left off the list. The file, gcc-4_2-branch\gcc\config.in documents checking a little differently (and each type more thoroughly) than the file gccinstall.info does. ENABLE_ASSERT_CHECKING - assert /* Define if you want assertions enabled. This is a cheap check. */ ENABLE_CHECKING - misc /* Define if you want more run-time sanity checks. This one gets a grab bag of miscellaneous but relatively cheap checks. */ ENABLE_FOLD_CHECKING- fold /* Define if you want fold checked that it never destructs its argument. This is quite expensive. */ ENABLE_GC_ALWAYS_COLLECT- gcac /* Define if you want the garbage collector to operate in maximally paranoid mode, validating the entire heap and collecting garbage at every opportunity. This is extremely expensive. */ ENABLE_GC_CHECKING - gc /* Define if you want the garbage collector to do object poisoning and other memory allocation checks. This is quite expensive. */ ENABLE_RTL_CHECKING - rtl /* Define if you want all operations on RTL (the basic data structure of the optimizer and back end) to be checked for dynamic type safety at runtime. This is quite expensive. */ ENABLE_RTL_FLAG_CHECKING- rtlflag /* Define if you want RTL flag accesses to be checked against the RTL codes that are supported for each access macro. This is relatively cheap. */ ENABLE_RUNTIME_CHECKING - runtime /* Define if you want runtime assertions enabled. This is a cheap check. */ ENABLE_TREE_CHECKING- tree /* Define if you want all operations on trees (the basic data structure of the front ends) to be checked for dynamic type safety at runtime. This is moderately expensive. The tree browser debugging routines will also be enabled by this option. */ ENABLE_VALGRIND_CHECKING- valgrind /* Define if you want to run subprograms and generated programs through valgrind (a memory checker). This is extremely expensive. */ -- Summary: The configure option --enable-stage1-checking is undocumented (and incorrectly named) Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: minor Priority: P3 Component: driver AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rob1weld at aol dot com GCC build triplet: i686
[Bug bootstrap/31963] The configure option --enable-stage1-checking is undocumented (and incorrectly named)
--- Comment #2 from rob1weld at aol dot com 2007-05-18 03:54 --- I just read 29544 (against 4.2.0) - as you would say: what was your (x)gcc -v ?. I used --enable-stage1-checking=assert,fold,gc,gcac,misc,rtl,rtlflag,runtime,tree and got these test results: http://gcc.gnu.org/ml/gcc-testresults/2007-05/msg00812.html I create a log of the build using make 21 | tee made_1_log.txt here is the line from the log for the _same_ file you made (the file occurs 3 times): Line 2361: gcc -c -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wmissing-format-attribute -fno-common -DHAVE_CONFIG_H -I. -I. -I/root/downloads/gcc-4_2-branch/gcc -I/root/downloads/gcc-4_2-branch/gcc/. -I/root/downloads/gcc-4_2-branch/gcc/../include -I./../intl -I/root/downloads/gcc-4_2-branch/gcc/../libcpp/include -I/root/downloads/gcc-4_2-branch/gcc/../libdecnumber -I../libdecnumber /root/downloads/gcc-4_2-branch/gcc/tree-ssa.c -o tree-ssa.o Line 5802: /opt/gcc-4_2-build/./prev-gcc/xgcc -B/opt/gcc-4_2-build/./prev-gcc/ -B/usr/i686-pc-linux-gnu/bin/ -c -O2 -g -fomit-frame-pointer -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wmissing-format-attribute-DHAVE_CONFIG_H -I. -I. -I/root/downloads/gcc-4_2-branch/gcc -I/root/downloads/gcc-4_2-branch/gcc/. -I/root/downloads/gcc-4_2-branch/gcc/../include -I./../intl -I/root/downloads/gcc-4_2-branch/gcc/../libcpp/include -I/root/downloads/gcc-4_2-branch/gcc/../libdecnumber -I../libdecnumber /root/downloads/gcc-4_2-branch/gcc/tree-ssa.c -o tree-ssa.o Line 9311 of my 'make log' is identical to Line 5802, so I won't repeat it. If I type # grep --color=always _CHECKING made_1_log.txt I can only see (shortened): make DESTDIR= RPATH_ENVVAR=LD_LIBRARY_PATH TARGET_SUBDIR=i686-pc-linux-gnu .. STAGE1_CFLAGS=-g -fkeep-inline-functions STAGE1_CHECKING=--enable-checking=assert,fold,gc,gcac,misc,rtl,rtlflag,runtime,tree STAGE1_LANGUAGES=c,ada .. No place in the file does -DENABLE_CHECKING -DENABLE_ASSERT_CHECKING occur. Despite the mechanics of it (how it _really_ should work) when I built it yesterday stage1 was fast, stage2 was slow (but OK - especially since I used EVERY checking (except valgrind)), and stage3 was fast - the libraries were quick too. It took ~ 32 hours to build. Documented many bugs (which either have been or will be filed). See URL above. If I type this, I see: #cd /opt/gcc-4_2-build # grep -r --color=always ENABLE_CHECKING * gcc/Makefile:STAGE1_CHECKING_CFLAGS = -DENABLE_CHECKING -DENABLE_ASSERT_CHECKING gcc/auto-host.h:/* #undef ENABLE_CHECKING */ Binary file gcc/build/genconditions.o matches Binary file gcc/build/genconditions matches gcc/build/gencondmd.c:#undef ENABLE_CHECKING Binary file gcc/build/genextract.o matches Binary file gcc/build/genextract matches gcc/insn-extract.c:#ifdef ENABLE_CHECKING According to the above my genconditions and genextract execs have the text fragment ENABLE_CHECKING in them. After 20 minutes of grep running I see nothing else come up in my build directory. But it might have been overwritten. Back in 4.1.1 the Makefile created directories that looked like this: ... drwxr-xr-x+ 14 HP_Administrator None 0 May 13 16:09 stage1-gcc drwxr-xr-x+ 2 HP_Administrator None 0 May 13 15:46 stage1-intl drwxr-xr-x+ 4 HP_Administrator None 0 May 13 15:53 stage1-libcpp drwxr-xr-x+ 2 HP_Administrator None 0 May 13 15:54 stage1-libdecnumber drwxr-xr-x+ 3 HP_Administrator None 0 May 13 15:49 stage1-libiberty drwxr-xr-x+ 2 HP_Administrator None 0 May 13 15:52 stage1-zlib drwxr-xr-x+ 14 HP_Administrator None 0 May 13 18:41 stage2-gcc drwxr-xr-x+ 2 HP_Administrator None 0 May 13 16:14 stage2-intl drwxr-xr-x+ 4 HP_Administrator None 0 May 13 16:52 stage2-libcpp drwxr-xr-x+ 2 HP_Administrator None 0 May 13 16:55 stage2-libdecnumber drwxr-xr-x+ 3 HP_Administrator None 0 May 13 16:41 stage2-libiberty drwxr-xr-x+ 2 HP_Administrator None 0 May 13 16:44 stage2-zlib drwxr-xr-x+ 14 HP_Administrator None 0 May 13 21:43 stage3-gcc drwxr-xr-x+ 2 HP_Administrator None 0 May 13 18:45 stage3-intl drwxr-xr-x+ 4 HP_Administrator None 0 May 13 19:14 stage3-libcpp drwxr-xr-x+ 2 HP_Administrator None 0 May 13 19:18 stage3-libdecnumber drwxr-xr-x+ 3 HP_Administrator None 0 May 13 19:04 stage3-libiberty drwxr-xr-x+ 2 HP_Administrator None 0 May 16 21:50 stage3-zlib -rw-r--r-- 1 HP_Administrator None 7 May 14 19:53 stage_current ... (that is from 4.2.0 i686-pc-cygwin) But, now, with 4.2.0 and 4.2.1 Linux builds create directories that look like: ... drwxr-xr-x 14 root root 12288 May 16 18:15 prev-gcc drwxr-xr-x 2 root root1024 May 15 13:53 prev-i686-pc
[Bug testsuite/31846] Logs are not being parsed correctly by testsuite and test_summary scripts.
--- Comment #1 from rob1weld at aol dot com 2007-05-18 03:57 --- A recent compile of 4.2.1 with complaints about log file parsing at the end is here: http://gcc.gnu.org/ml/gcc-testresults/2007-05/msg00812.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31846
[Bug libgcj/31891] Libjava configuration scripts out of sync for pkg-config tests
--- Comment #1 from rob1weld at aol dot com 2007-05-18 04:01 --- A recent gcc 4.2.1 compile (20070515 - revision 124745) for Linux is here: http://gcc.gnu.org/ml/gcc-testresults/2007-05/msg00812.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31891
[Bug bootstrap/31963] The configure option --enable-stage1-checking is undocumented (and incorrectly named)
--- Comment #4 from rob1weld at aol dot com 2007-05-18 05:57 --- --- Comment #3 From Andrew Pinski 2007-05-18 04:10 [reply] --- I have no idea what you are talking about overwritting. In the 4.1.1 AND 4.2.0/1 configure file we have: --enable-bootstrap[=lean] Enable bootstrapping [no] In the 4.1.1 AND 4.2.0/1 gcc/doc/gccinstall.info file we have: If you are short on disk space you might consider `make bootstrap-lean' instead. This is identical to `make bootstrap' except that object files from the stage1 and stage2 of the 3-stage bootstrap of the compiler are deleted as soon as they are no longer needed. The DOCs are the same but the way the stages build are different. See my ls -l above. - The 4.1.1 Makefile _leaves_ all the stages _after_ the make is finished. --- We end up with stage1-gcc, stage2-gcc and stage3-gcc (and the other directories). - The 4.2.0/1 Makefile _moves_ all the stages _after_ each stage - this is _similar_ to a lean bootstrap but instead of rm (deleting is the word used in the info DOCs above) the stages are moved (overwrite the prior stage) by shuffling the links. --- We end up with gcc, and prev-gcc (and the other directories) - We have fewer directories - IE: no intermediates to examine. --- Comment #3 From Andrew Pinski 2007-05-18 04:10 [reply] --- So that means we can configure the gcc subdirectory differently for the two different stages which is exactly what happens with --enable-stage1-checking=*. When stage1 is configured, the toplevel makefile passes down the --enable-checking=x for what --enable-stage1-checking= says to do (defaults to yes). So you will not see a -DENABLE_CHECKING on the command line when compiling stage1 at all. You will see in stage1-gcc (when the build finishes if you don't use make bootstrap-lean) in auto-host.h, a define for ENABLE_CHECKING. This option is really only useful for disable checking for stage1 when you are short on resources (memory/time). I used make to make gcc - I saved the whole log of the make when I typed: make 21 | tee made_1_log.txt I also saved ls -l 's of each stage of the build to compare how long it took to compile with the --enable-stage1-checking=... option fed _directly_ to ./configure and the --enable-checking option NOT given to ./configure . When I previously used --enable-checking it took way too long, the worst part was the libjava libraries (since they have PICs and use @lists). I tried using --enable-stage1-checking instead of using --enable-checking with _every_ possible check (except valgrind) - It was quite fast. --- Comment #3 From Andrew Pinski 2007-05-18 04:10 [reply] --- Plus configure is setup correctly to enable more checking for stage1. Also this is the help from configure: choose additional checking for stage1 of the compiler. Which is exactly what it does. It means enable checking in the product of stage1 (the stage1 compiler) which is a good description I think. It means compiling stage2 is going to be slower if you enable all checking for stage1. When we use the command ./configure --enable-stage1-checking=all we are building the stage1 compiler with the operating system's gcc which (most likely) was NOT compiled with *-checking=all -- _IF_ the OS's gcc compiler _was_ compiled with checking then when we used the OS's gcc to compile we would get additional checks made on the OS's gcc output (whether we configured the SVN we are building to have checking or not). If our OS has only gcc-3.3 installed and we want to build GCC 4.2.0/1 the _first_ stage will not be built with the features available in gcc4. When we make bootstrap and use gcc/xgcc during the _second_ (and subsequent) stages we _DO_ use gcc4 and _if_ we turned on the use of checking then the gcc built in stage1 (which then gets called gcc/xgcc in stage2) will build stage TWO with checking - stage ONE is only built with checking _IF_ the OS's gcc was built with checking (sometimes scoundrels build and release binaries with --disable-checking). So the stage ONE compiler we build has the ABILITY to check stage TWO (and later stages depending if we use --enable-checking or --enable-stage1-checking - but it does not have itself checked (there is no stage ONE checking) Similarly I can use gcc-3.3 to build GCC-5.0.0-branch (maybe) and I can build gcc5 with every command line option and feature _supported_ by gcc3 - if I configure GCC5 to use gomp the FIRST stage of GCC5 is not going to have gomp. If I built GCC5 with GCC4 (and configured GCC4 using --enable-libgomp) then stage ONE of GCC5 _could_ be built with gomp. You say the DOCs say: choose additional checking for stage1 of the compiler. If I tell you the FIRST time you come to my restraunt I will give you a free meal does that mean you need to come a second time to get the meal ? If I tell you the SECOND time you come to my restraunt I will give you a free meal does that mean
[Bug bootstrap/31998] New: Incorrect Unreachable statement turns off optimizing + spec file in error
-v ...
/opt/gcc-4_2-build/gcc/jc1
/root/downloads/gcc-4_2-branch/libjava/classpath/gnu/java/security/util/Base64.java
-quiet -dumpbase Base64.java -mtune=athlon-xp -march=athlon-xp -auxbase-strip
Base64.o -g -O2 -Wno-deprecated -version -ffloat-store -fomit-frame-pointer
-fclasspath=
-fbootclasspath=/opt/gcc-4_2-build/i686-pc-linux-gnu/libjava/classpath/lib
-fencoding=UTF-8 -fbootstrap-classes -fPIC -MD_ -MT gnu/java/security/util.lo
-MF Base64.deps -o /tmp/ccWfMiuA.s
It seems xgcc chooses different commands for jc1 than gcj would use. Lets try
it anyways. When I use xgcc to process the file here is what happens:
#/opt/gcc-4_2-build/gcc/xgcc -B/opt/gcc-4_2-build/i686-pc-linux-gnu/libjava/
-B/opt/gcc-4_2-build/gcc/ -ffloat-store -fomit-frame-pointer -fclasspath=
-fbootclasspath=/opt/gcc-4_2-build/i686-pc-linux-gnu/libjava/classpath/lib
--encoding=UTF-8 -Wno-deprecated -fbootstrap-classes -g -O2 -c -MT
gnu/java/security/util.lo -MD -MP -MF Base64.deps
/root/downloads/gcc-4_2-branch/libjava/classpath/gnu/java/security/util/Base64.java
-fPIC -o Base64.o
Base64.java: In class 'gnu.java.security.util.Base64':
Base64.java: In method 'gnu.java.security.util.Base64.decode(byte[],int,int)':
Base64.java:200: warning: Unreachable statement.
for (i = off; i off + len; i++)
^
1 warning
Base64.java: At top level:
Base64.java:50: internal compiler error: in uses_jv_markobj_p, at
java/boehm.c:245
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
Curious, doing that gives the same warning in the same location, but triggers
an ICE. It would seem there is a sore spot when gcc runs into that sort of
code.
Someone else might want to shorten that Java code and make a testcase. I am not
expert enough with Java or I would offer something.
I tried that on gcc-4.1 to see what would happen:
# gcc-4.1 -v -O0 -c Base64.java -o Base64.o 21 | grep internal
Base64.java:50: internal compiler error: in uses_jv_markobj_p, at
java/boehm.c:245
# gcc-4.1 -fuse-boehm-gc -v -O0 -c Base64.java -o Base64.o 21 | grep internal
# (nothing printed)
It would seem that the spec file needs -fuse-boehm-gc added to it so gcc can
compile Java and avoid the error message internal compiler error: in
uses_jv_markobj_p, at java/boehm.c:245
That led me to discover that boehm-gc _might_ have some trouble - it certainly
makes debugging much harder. The boehm-gc issue is the subject of a different
bug report. (It will be somewhere a few bug #'s higher than this one).
The file: /root/downloads/gcc-4_2-branch/gcc/java/boehm.c has a FIXME at 245.
/* The fourth (index of 3) element in the vtable is the GC descriptor.
A value of 2 indicates that the class uses _Jv_MarkObj. */
bool
uses_jv_markobj_p (tree dtable)
{
tree v;
/* FIXME: what do we return if !flag_use_boehm_gc ? */
gcc_assert (flag_use_boehm_gc);
/* FIXME: this is wrong if TARGET_VTABLE_USES_DESCRIPTORS. However,
this function is only used with flag_reduced_reflection. No
point in asserting unless we hit the bad case. */
gcc_assert (!flag_reduced_reflection || TARGET_VTABLE_USES_DESCRIPTORS == 0);
v = VEC_index (constructor_elt, CONSTRUCTOR_ELTS (dtable), 3)-value;
return (PROCEDURE_OBJECT_DESCRIPTOR == TREE_INT_CST_LOW (v));
}
---
Short version (with no proof):
The lack of -fuse-boehm-gc in the spec file (or the internal spec) is
triggering the gcc_assert() in boehm.c at line 245.
This occurs when gcc is built with the above ./configure options (likely
--enable-java-gc=boehm) and used to compile a file with a .java extension.
--
Summary: Incorrect Unreachable statement turns off optimizing +
spec file in error
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
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=31998
[Bug boehm-gc/31999] New: Make -i check finds one, and fails to find another, boehm-gc problem
/downloads/gcc-4_2-branch/gcc/gcc.c:4635
4635value = execute ();
(gdb) where
#0 do_spec_1 (spec=0x807e018 -o %|.s |\n as %(asm_options) %|.s %A,
inswitch=0, soft_matched_part=0x0)
at /root/downloads/gcc-4_2-branch/gcc/gcc.c:4635
#1 0x080534b7 in handle_braces (p=0x8082585 -o %|.s |\n as %(asm_options)
%|.s %A })
at /root/downloads/gcc-4_2-branch/gcc/gcc.c:5814
#2 0x08050c19 in do_spec_1 (spec=0x8082580 %{!S:-o %|.s |\n as %(asm_options)
%|.s %A }, inswitch=0,
soft_matched_part=0x0) at /root/downloads/gcc-4_2-branch/gcc/gcc.c:5204
#3 0x08050d9b in do_spec_1 (spec=0x8086048 %(invoke_as), inswitch=0,
soft_matched_part=0x0)
at /root/downloads/gcc-4_2-branch/gcc/gcc.c:5303
#4 0x080534b7 in handle_braces (p=0x8085fa9 %(invoke_as)}) at
/root/downloads/gcc-4_2-branch/gcc/gcc.c:5814
#5 0x08050c19 in do_spec_1 (
spec=0x8085f20 jc1 %i %(jc1) %(cc1_options) %{+e*} %{I*}, ' ' repeats 13
times, %{MD:-MD_} %{MMD:-MMD_} %{M} %{MM} %{MA} %{MT*} %{MF*}, ' ' repeats
13 times, %{!fsyntax-only:%(invoke_as)}, inswitch=0, soft_matched_part=0x0)
at /root/downloads/gcc-4_2-branch/gcc/gcc.c:5204
#6 0x080534b7 in handle_braces (
p=0x8069046 jc1 %i %(jc1) %(cc1_options) %{+e*} %{I*}, ' ' repeats 13
times, %{MD:-MD_} %{MMD:-MMD_} %{M} %{MM} %{MA} %{MT*} %{MF*}, ' ' repeats
13 times, %{!fsyntax-only:%(invoke_as)}})
at /root/downloads/gcc-4_2-branch/gcc/gcc.c:5814
#7 0x08050c19 in do_spec_1 (
spec=0x8068ee0 %{fjni:%{femit-class-files:%e-fjni and -femit-class-files
are incompatible}}%{fjni:%{femit-class-file:%e-fjni and -femit-class-file
are incompatible}}%{femit-class-file:%{!fsyntax-only:%e-femi...,
inswitch=0,
soft_matched_part=0x0) at /root/downloads/gcc-4_2-branch/gcc/gcc.c:5204
#8 0x08053a3d in do_spec_2 (
spec=0x8068ee0 %{fjni:%{femit-class-files:%e-fjni and -femit-class-files
are incompatible}}%{fjni:%{femit-class-file:%e-fjni and -femit-class-file
are incompatible}}%{femit-class-file:%{!fsyntax-only:%e-femi...)
at /root/downloads/gcc-4_2-branch/gcc/gcc.c:4420
#9 0x08053e6c in do_spec (
spec=0x8068ee0 %{fjni:%{femit-class-files:%e-fjni and -femit-class-files
are incompatible}}%{fjni:%{femit-class-file:%e-fjni and -femit-class-file
are incompatible}}%{femit-class-file:%{!fsyntax-only:%e-femi...)
at /root/downloads/gcc-4_2-branch/gcc/gcc.c:4388
#10 0x08054ae1 in main (argc=Cannot access memory at address 0x0
) at /root/downloads/gcc-4_2-branch/gcc/gcc.c:6628
(gdb) step
execute () at /root/downloads/gcc-4_2-branch/gcc/gcc.c:2797
2797 gcc_assert (!processing_spec_function);
1): I think that is clear. Load the Base64.o Java file and start the debugger.
2): List two parts of the code to show that your line numbers are the same as
mine. I did not alter the source but you might want to try on a different
version of gcc.
3): Place the two breakpoints on those same lines.
4): Run the program and hit the breakpoint.
5): On _that_ particular run of _GDB_ the memory was in a state where I
_usually_ (but sometimes not) had to use c 36 to jump the breakpoint.
Because boehm-gc is changing things (along with the OS) sometimes I need
to use a different number after the c. Once I found out the number I
could use r to restart gdb and then use c # to jump the breakpoints.
6): AFTER figuring out the number for c for a _particular_ run of gdb I could
easily get to the point where I simply add one more breakpoint and type
c (without a following number) to land exactly on the instruction that
caused the ICE when I typed n at the gdb prompt.
Those problems with boehm-gc (the boehm-gc DOCs admit to random occurances of
trouble) make debugging tough _AND_ might have been the cause of some of the
languages and libraries make -i check tests failing.
We did not seem to follow all the DOCs when integrating boehm with gcc - I will
check more carefully. _EVEN_ _IF_ we did, the DOCs says that random failures
occur that have not been tracked down.
The gctest is not getting built when ./configure uses the above options.
--
Summary: Make -i check finds one, and fails to find another,
boehm-gc problem
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: boehm-gc
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=31999
[Bug bootstrap/32024] New: ICE - libgcc2.c:557: internal compiler error: in fold_checksum_tree, at fold-const.c:12652
The bootstrap hardly runs for a few minutes and then I get an ICE. Screen output: ... make[3]: Leaving directory `/opt/gcc-4_3-build/gcc' mkdir -p -- i686-pc-linux-gnu/libgcc Checking multilib configuration for libgcc... Configuring stage 1 in i686-pc-linux-gnu/libgcc configure: creating cache ./config.cache ... checking whether decimal floating point is supported... yes checking for __attribute__((visibility(hidden)))... yes updating cache ./config.cache configure: creating ./config.status config.status: creating Makefile config.status: executing default commands make[3]: Entering directory `/opt/gcc-4_3-build/i686-pc-linux-gnu/libgcc' # If this is the top-level multilib, build all the other # multilibs. /opt/gcc-4_3-build/./gcc/xgcc -B/opt/gcc-4_3-build/./gcc/ -B/usr/i686-pc-linux-gnu/bin/ -B/usr/i686-pc-linux-gnu/lib/ -isystem /usr/i686-pc-linux-gnu/include -isystem /usr/i686-pc-linux-gnu/sys-include -g -fkeep-inline-functions -O2 -O2 -g -O2 -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../.././gcc -I/root/downloads/gcc-4_3-trunk/libgcc -I/root/downloads/gcc-4_3-trunk/libgcc/. -I/root/downloads/gcc-4_3-trunk/libgcc/../gcc -I/root/downloads/gcc-4_3-trunk/libgcc/../include -I/root/downloads/gcc-4_3-trunk/libgcc/../libdecnumber/bid -I/root/downloads/gcc-4_3-trunk/libgcc/../libdecnumber -I../../libdecnumber -o _muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep -DL_muldi3 -c /root/downloads/gcc-4_3-trunk/libgcc/../gcc/libgcc2.c \ -fvisibility=hidden -DHIDE_EXPORTS /root/downloads/gcc-4_3-trunk/libgcc/../gcc/libgcc2.c: In function '__muldi3': /root/downloads/gcc-4_3-trunk/libgcc/../gcc/libgcc2.c:557: internal compiler error: in fold_checksum_tree, at fold-const.c:12652 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. make[3]: *** [_muldi3.o] Error 1 make[3]: Leaving directory `/opt/gcc-4_3-build/i686-pc-linux-gnu/libgcc' make[2]: *** [all-stage1-target-libgcc] Error 2 make[2]: Leaving directory `/opt/gcc-4_3-build' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/opt/gcc-4_3-build' make: *** [all] Error 2 # gcc/xgcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: /root/downloads/gcc-4_3-trunk/configure --verbose --enable-languages=c,ada,c++,fortran,java,objc,obj-c++ --with-tune=athlon-xp --prefix=/usr --enable-objc-gc --enable-concept-checks --disable-multilib --with-gxx-include-dir=/usr/include/c++/4.3 --enable-libstdcxx-debug --enable-static --enable-shared --enable-initfini-array --enable-__cxa_atexit --enable-threads=posix --enable-version-specific-runtime-libs --enable-libssp --enable-libmudflap --enable-libgomp --disable-werror --enable-nls --with-included-gettext --enable-decimal-float --with-long-double-128 --enable-debug --enable-java-gc=boehm --with-x --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --enable-java-awt=gtk,xlib --enable-gtk-cairo --enable-qt-peer --enable-xmlj --enable-gconf-peer --enable-tool-wrappers --with-gjdoc --enable-portable-native-sync --enable-libgcj-multifile --with-stabs --enable-hash-synchronization --enable-gc-debug --enable-interpreter --with-system-zlib --enable-libada --with-tls --with-cpu=athlon-xp --with-arch=athlon-xp --enable-stage1-checking=assert,fold,gc,misc,rtl,rtlflag,runtime,tree Thread model: posix gcc version 4.3.0 20070521 (experimental) The _exact_ same ./configure commands work on gcc 4.2.0/1 (last few weeks). I have saved a make screen output log (and the whole build directory). No rush, I'll play with 4.2.1 while I wait to see if this clears up. -- Summary: ICE - libgcc2.c:557: internal compiler error: in fold_checksum_tree, at fold-const.c:12652 Product: gcc Version: 4.3.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-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=32024
[Bug middle-end/32024] ICE - libgcc2.c:557: internal compiler error: in fold_checksum_tree, at fold-const.c:12652
--- Comment #1 from rob1weld at aol dot com 2007-05-21 19:09 --- I did some more testing on this issue. I started pulling off configure option a half dozen at a time. 1st I removed: --enable-initfini-array --enable-__cxa_atexit --enable-threads=posix --enable-decimal-float --with-long-double-128 --with-tls Next I removed: --enable-objc-gc --enable-concept-checks --enable-libstdcxx-debug --enable-static --enable-shared --enable-version-specific-runtime-libs --enable-gc-debug Then I removed: --enable-libssp --enable-libmudflap --enable-libgomp --enable-nls --with-included-gettext --enable-debug --enable-java-gc=boehm --with-x --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --enable-java-awt=gtk,xlib --enable-gtk-cairo --enable-qt-peer --enable-xmlj --enable-gconf-peer --enable-tool-wrappers --with-gjdoc --enable-portable-native-sync --enable-libgcj-multifile --with-stabs --enable-hash-synchronization --enable-interpreter --with-system-zlib --enable-libada It still broke each time in the _exact_ same place. Finally I removed _ALL_ options and simply used ./configure. A grep of the Makefile's BUILD_CONFIGARGS says: '--enable-languages=c,c++,fortran,java,objc' which are not enough for what I prefer - but now it builds I can add some more options back in. So now my xgcc says this: #gcc/xgcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: /root/downloads/gcc-4_3-trunk/configure Thread model: posix gcc version 4.3.0 20070521 (experimental) The make of gcc has now passed the point where the prior ICE occurred. I did a diff -q of the ICE'd build directory and the (so far) successful directory and came up with this output (hand-edited output of diff): Files ../gcc-4_3-build-ICE-1/Makefile and ../gcc-4_3-build/Makefile differ Files ../gcc-4_3-build-ICE-1/build-i686-pc-linux-gnu/fixincludes/config.log and ../gcc-4_3-build/build-i686-pc-linux-gnu/fixincludes/config.log differ Files ../gcc-4_3-build-ICE-1/build-i686-pc-linux-gnu/fixincludes/config.status and ../gcc-4_3-build/build-i686-pc-linux-gnu/fixincludes/config.status differ Files ../gcc-4_3-build-ICE-1/build-i686-pc-linux-gnu/fixincludes/mkheaders Files ../gcc-4_3-build-ICE-1/build-i686-pc-linux-gnu/fixincludes/mkheaders.almost Files ../gcc-4_3-build-ICE-1/build-i686-pc-linux-gnu/libiberty/Makefile Files ../gcc-4_3-build-ICE-1/build-i686-pc-linux-gnu/libiberty/config.log Files ../gcc-4_3-build-ICE-1/build-i686-pc-linux-gnu/libiberty/config.status Files ../gcc-4_3-build-ICE-1/build-i686-pc-linux-gnu/libiberty/libiberty.a Files ../gcc-4_3-build-ICE-1/config.log Files ../gcc-4_3-build-ICE-1/config.status Files ../gcc-4_3-build-ICE-1/gcc/Make-hooks Files ../gcc-4_3-build-ICE-1/gcc/Makefile Files ../gcc-4_3-build-ICE-1/gcc/ada/Makefile Files ../gcc-4_3-build-ICE-1/gcc/auto-host.h Files ../gcc-4_3-build-ICE-1/gcc/config.cache Files ../gcc-4_3-build-ICE-1/gcc/config.log Files ../gcc-4_3-build-ICE-1/gcc/config.status Files ../gcc-4_3-build-ICE-1/gcc/configargs.h Files ../gcc-4_3-build-ICE-1/gcc/gccbug Files ../gcc-4_3-build-ICE-1/gcc/libada-mk Files ../gcc-4_3-build-ICE-1/intl/Makefile Files ../gcc-4_3-build-ICE-1/intl/config.cache Files ../gcc-4_3-build-ICE-1/intl/config.h Files ../gcc-4_3-build-ICE-1/intl/config.intl Files ../gcc-4_3-build-ICE-1/intl/config.log Files ../gcc-4_3-build-ICE-1/intl/config.status Files ../gcc-4_3-build-ICE-1/libiberty/Makefile Files ../gcc-4_3-build-ICE-1/libiberty/alloca.o Files ../gcc-4_3-build-ICE-1/libiberty/argv.o Files ../gcc-4_3-build-ICE-1/libiberty/choose-temp.o Files ../gcc-4_3-build-ICE-1/libiberty/concat.o Files ../gcc-4_3-build-ICE-1/libiberty/config.cache Files ../gcc-4_3-build-ICE-1/libiberty/config.log Files ../gcc-4_3-build-ICE-1/libiberty/config.status Files ../gcc-4_3-build-ICE-1/libiberty/cp-demangle.o Files ../gcc-4_3-build-ICE-1/libiberty/cp-demint.o Files ../gcc-4_3-build-ICE-1/libiberty/cplus-dem.o Files ../gcc-4_3-build-ICE-1/libiberty/dyn-string.o Files ../gcc-4_3-build-ICE-1/libiberty/fdmatch.o Files ../gcc-4_3-build-ICE-1/libiberty/fibheap.o Files ../gcc-4_3-build-ICE-1/libiberty/filename_cmp.o Files ../gcc-4_3-build-ICE-1/libiberty/floatformat.o Files ../gcc-4_3-build-ICE-1/libiberty/fnmatch.o Files ../gcc-4_3-build-ICE-1/libiberty/fopen_unlocked.o Files ../gcc-4_3-build-ICE-1/libiberty/getopt.o Files ../gcc-4_3-build-ICE-1/libiberty/getopt1.o Files ../gcc-4_3-build-ICE-1/libiberty/getpwd.o Files ../gcc-4_3-build-ICE-1/libiberty/getruntime.o Files ../gcc-4_3-build-ICE-1/libiberty/hashtab.o Files ../gcc-4_3-build-ICE-1/libiberty/hex.o Files ../gcc-4_3-build-ICE-1/libiberty/lbasename.o Files ../gcc-4_3-build-ICE-1/libiberty/libiberty.a Files ../gcc-4_3-build-ICE-1/libiberty/lrealpath.o Files ../gcc-4_3-build-ICE-1/libiberty/make-relative-prefix.o Files ../gcc-4_3-build-ICE-1/libiberty/make-temp-file.o Files ../gcc-4_3-build-ICE-1/libiberty/md5.o Files ../gcc-4_3-build-ICE-1/libiberty/mkstemps.o Files ../gcc-4_3-build-ICE-1/libiberty/objalloc.o Files ../gcc-4_3
[Bug middle-end/32024] ICE - libgcc2.c:557: internal compiler error: in fold_checksum_tree, at fold-const.c:12652
--- Comment #2 from rob1weld at aol dot com 2007-05-21 21:05 --- The BUG is somewhere in here: I put back ALL my origonal (lengthy) configure options but left off the checking. It gets past the ICE. That is not good though... Situation A): The checker is working fine and the code produced is incorrect and this is being caught by the checker. Situation B): The checker is incorrect and the code produced is OK, the checker is wrongly complaining about code that is OK. I check back in a day or two ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32024
[Bug middle-end/32024] ICE - libgcc2.c:557: internal compiler error: in fold_checksum_tree, at fold-const.c:12652
--- Comment #3 from rob1weld at aol dot com 2007-05-22 03:17 --- Created an attachment (id=13598) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13598action=view) Notes: diffs of 4.2.1 and 4.3.0 fold-const.c and ICE -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32024
[Bug libgcj/32028] New: Make fails at gjdoc - gnu.classpath.tools.gjdoc.ParseException: unmatched input in line 1: @Retention(SOURCE) @Target(METHOD)
='_top'GNU Classpath/a (0.92) -footer span class='logo'a href='http://www.gnu.org/software/classpath' target='_top'GNU Classpath/a (0.92) \ -subpackages java:javax:org Loading classes for package java.applet... Loading classes for package java.awt... Loading classes for package java.awt.color... ... (MANY lines) Loading classes for package org.xml.sax.ext... Loading classes for package org.xml.sax.helpers... Constructing Javadoc information... Resolving references in comments... Resolving references in classes... Resolving references in packages... Resolving references in class comments... Null tags for [EMAIL PROTECTED], text=, tagMap=null] Null tags for [EMAIL PROTECTED], text=, tagMap=null] Null tags for [EMAIL PROTECTED], text=, tagMap=null] Null tags for [EMAIL PROTECTED], text=, tagMap=null] Null tags for [EMAIL PROTECTED], text=, tagMap=null] Null tags for [EMAIL PROTECTED], text=, tagMap=null] Null tags for [EMAIL PROTECTED], text=, tagMap=null] Null tags for [EMAIL PROTECTED], text=, tagMap=null] Null tags for [EMAIL PROTECTED], text=, tagMap=null] Null tags for [EMAIL PROTECTED], text=, tagMap=null] Null tags for [EMAIL PROTECTED], text=, tagMap=null] Resolving references in package comments... Running doclet... Building cross-reference information... Writing overview files... Writing full tree... Writing index... Writing HTML files for package java.applet Writing HTML files for package java.awt Writing HTML files for package java.awt.color Writing HTML files for package java.awt.datatransfer ... (MANY lines) Writing HTML files for package org.xml.sax.ext Writing HTML files for package org.xml.sax.helpers touch create_html make[5]: Leaving directory `/opt/gcc-4_2-build/i686-pc-linux-gnu/libjava/classpath/doc/api' make[5]: Entering directory `/opt/gcc-4_2-build/i686-pc-linux-gnu/libjava/classpath/doc' make[5]: Nothing to be done for `all-am'. make[5]: Leaving directory `/opt/gcc-4_2-build/i686-pc-linux-gnu/libjava/classpath/doc' make[4]: Leaving directory `/opt/gcc-4_2-build/i686-pc-linux-gnu/libjava/classpath/doc' ... To get around this problem I typed: # cd i686-pc-linux-gnu/libjava/classpath/doc/api # touch create_html # cd ../../../../.. # make -- Summary: Make fails at gjdoc - gnu.classpath.tools.gjdoc.ParseException: unmatched input in line 1: @Retention(SOURCE) @Target(METHOD) Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: libgcj 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=32028
[Bug testsuite/32031] New: The 'status' of using the LAST_UPDATED file is unclear or inconsistent
I obtained the gcc 4.3 trunk as per the instructions on the web site
(http://gcc.gnu.org/svn.html) using SVN. After all the files arrive and the
checkout is completed it would _seem_ that the file LAST_UPDATED is missing.
One (old) changelog says that the file is .cvsignore (don't get it) and
another (newer) changelog says the file is used. Various scripts use it.
The script file gcc-4_3-trunk/contrib/test_summary uses the file
gcc-4_3-trunk/LAST_UPDATED and if that file is missing it e-mails test
results with an incorrect (or peculiar, but possibly correct?) line that says
LAST_UPDATED: (BLANK INFO):.
After using grep to search for files that require (or mention) this file I came
up with confusing or inconsistent information.
If the file does not exist (on the user's system, not the svn server) then the
test_summary script e-mails a line with LAST_UPDATED: (BLANK INFO):
and that seems to have little purpose.
It seems that one way you could have the file is to run the script
gcc-4_3-trunk/maintainer-scripts/gcc_release or
gcc-4_3-trunk/contrib/gcc_update but most people probably don't run those
scripts (judging from the various test reports).
When I run gcc-4_3-trunk/contrib/gcc_update on my system (Debian) I end up
with a double date (lucky me). Just UTC would be better.
# cat LAST_UPDATED
Tue May 22 01:38:20 PDT 2007
Tue May 22 08:38:20 UTC 2007 (revision 124939)
# date --version
date (GNU coreutils) 5.97
_I_ prefer the test_summary reports to have the info it provides at the top of
the report. It is useful to know the date, time, and revision number.
What is unclear (or inconsistent) is that if we should have it then why don't
we. If we should NOT have it then why is it in the script test_summary and
the _newest_ changelogs? To have or not to have.
# grep -r LAST_UPDATED /root/downloads/gcc-4_3-trunk/*
File: gcc-4_3-trunk/contrib/test_summary
printf LAST_UPDATED: ;
system(tail -1 srcdir /LAST_UPDATED);
File: gcc-4_3-trunk/ChangeLog
2001-07-27 Richard Henderson [EMAIL PROTECTED]
* .cvsignore: Add LAST_UPDATED.
File: gcc-4_3-trunk/maintainer-scripts/ChangeLog
2005-11-06 Joseph S. Myers [EMAIL PROTECTED]
* gcc_release: Further update for SVN. Don't set EXPORTTAG or
EXPORTDATE; always determine SVNREV the same way. Correct message
about what sources are being retrived. Include branch information
in LAST_UPDATED.
2003-08-24 Gerald Pfeifer [EMAIL PROTECTED]
* gcc_release (build_sources): Create/update the LAST_UPDATED file
in the source directory with information how sources were obtained.
File: /root/downloads/gcc-4_3-trunk/maintainer-scripts/gcc_release
# Run gcc_update on them to set up the timestamps nicely, and (re)write
# the LAST_UPDATED file containing the SVN tag/revision used.
changedir gcc-${RELEASE}
contrib/gcc_update --touch
echo Obtained from SVN: ${SVNBRANCH} revision ${SVNREV} LAST_UPDATED
File: gcc-4_3-trunk/contrib/.svn/text-base/ChangeLog.svn-base
2005-11-01 Joseph S. Myers [EMAIL PROTECTED]
* gcc_update: Include revision number in LAST_UPDATED.
2001-07-27 Richard Henderson [EMAIL PROTECTED]
* test_summary: Copy LAST_UPDATED UTC time to head of summary.
2001-07-27 Richard Henderson [EMAIL PROTECTED]
* gcc_update: Dump timestamp in LAST_UPDATED.
Just a comment in File: gcc-4_3-trunk/gcc/config/cris/cris.h
/* Same, but with swapped arguments (no canonical \
ordering between e.g. REG and MEM as of LAST_UPDATED \
Thu May 12 03:59:11 UTC 2005). */ \
--
Summary: The 'status' of using the LAST_UPDATED file is unclear
or inconsistent
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: trivial
Priority: P3
Component: testsuite
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=32031
[Bug libgcj/32034] New: Use of deprecated classes in gcc-4_2-build/i686-pc-linux-gnu/libjava/classpath/tools
:75: warning: The class 'java.rmi.server.Operation' has been deprecated. new Operation(Remote lookup(java.lang.String), ^ /root/downloads/gcc-4_2-branch/libjava/classpath/tools/gnu/classpath/tools/rmi/registry/RegistryImpl_Skel.java:76: warning: The class 'java.rmi.server.Operation' has been deprecated. new Operation(void rebind(java.lang.String, Remote), ^ /root/downloads/gcc-4_2-branch/libjava/classpath/tools/gnu/classpath/tools/rmi/registry/RegistryImpl_Skel.java:77: warning: The class 'java.rmi.server.Operation' has been deprecated. new Operation(void unbind(java.lang.String) ^ 13 warnings (cd classes; \ /opt/gcc-4_2-build/i686-pc-linux-gnu/libjava/scripts/jar cf ../tools.jar .; \ cd ..) rm -rf classes make all-am make[5]: Entering directory `/opt/gcc-4_2-build/i686-pc-linux-gnu/libjava/classpath/tools' make[5]: Nothing to be done for `all-am'. make[5]: Leaving directory `/opt/gcc-4_2-build/i686-pc-linux-gnu/libjava/classpath/tools' make[4]: Leaving directory `/opt/gcc-4_2-build/i686-pc-linux-gnu/libjava/classpath/tools' make[4]: Entering directory `/opt/gcc-4_2-build/i686-pc-linux-gnu/libjava/classpath' If it were not for those messages I would have no warnings. Important enough to fix (someday) but a minor issue. -- Summary: Use of deprecated classes in gcc-4_2-build/i686-pc- linux-gnu/libjava/classpath/tools Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: minor Priority: P3 Component: libgcj 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=32034
[Bug middle-end/32024] ICE - libgcc2.c:557: internal compiler error: in fold_checksum_tree, at fold-const.c:12652
--- Comment #5 from rob1weld at aol dot com 2007-05-22 16:02 --- Thanks for confirming, Richard. It works on 4.2.0/1 and I've enclosed notes in the prior message that _probably_ explain why it is failing. In addition I just did a build (one day newer version) _without_ fold and it still halted the make and trigger a GNAT BUG in verify_flow_info. If the bootstrap is that touchy then we won't be getting many good compiles finishing (and test results submitted, and bugs fixed). Yesterday it worked, today I added --enable-stage1-checking=assert,gc,misc,rtl,rtlflag,runtime,tree and it broke. --- I'm placing this here because I am reasonably certain that it is related to the problems with the fold-const.c after examining the code. Here is the output: make profiledbootstrap 21 | tee make_1_log.txt ...(Many Many lines) ranlib libdecnumber.a make[3]: Leaving directory `/opt/gcc-4_3-build/libdecnumber' make[3]: Entering directory `/opt/gcc-4_3-build/gcc' test -d po || mkdir po /usr/bin/msgfmt --statistics -o po/be.gmo /root/downloads/gcc-4_3-trunk/gcc/po/be.po 114 translated messages, 1159 fuzzy translations, 4632 untranslated messages. ...(Many lines) build/genrecog /root/downloads/gcc-4_3-trunk/gcc/config/i386/i386.md \ insn-conditions.md tmp-recog.c /root/downloads/gcc-4_3-trunk/gcc/config/i386/i386.md:18884: warning: operand 1 missing mode? /bin/sh /root/downloads/gcc-4_3-trunk/gcc/../move-if-change tmp-recog.c insn-recog.c echo timestamp s-recog ...(Many lines) ranlib libbackend.a ...(Few lines) build/genchecksum cc1-dummy cc1-checksum.c ...(Some lines) /opt/gcc-4_3-build/./prev-gcc/xgcc -B/opt/gcc-4_3-build/./prev-gcc/ -B/usr/i686-pc-linux-gnu/bin/ -c -O2 -g -fomit-frame-pointer -fprofile-generate -gnatpg -gnata -I- -I. -Iada -I/root/downloads/gcc-4_3-trunk/gcc/ada /root/downloads/gcc-4_3-trunk/gcc/ada/ali.adb -o ada/ali.o /root/downloads/gcc-4_3-trunk/gcc/ada/ali.adb: In function 'ALI.SCAN_ALI': /root/downloads/gcc-4_3-trunk/gcc/ada/ali.adb:2265: error: control flow in the middle of basic block 126 /root/downloads/gcc-4_3-trunk/gcc/ada/ali.adb:2265: error: control flow in the middle of basic block 126 /root/downloads/gcc-4_3-trunk/gcc/ada/ali.adb:2265: error: control flow in the middle of basic block 126 /root/downloads/gcc-4_3-trunk/gcc/ada/ali.adb:2265: error: control flow in the middle of basic block 126 /root/downloads/gcc-4_3-trunk/gcc/ada/ali.adb:2265: error: control flow in the middle of basic block 126 /root/downloads/gcc-4_3-trunk/gcc/ada/ali.adb:2265: error: control flow in the middle of basic block 664 /root/downloads/gcc-4_3-trunk/gcc/ada/ali.adb:2265: error: control flow in the middle of basic block 664 /root/downloads/gcc-4_3-trunk/gcc/ada/ali.adb:2265: error: control flow in the middle of basic block 664 /root/downloads/gcc-4_3-trunk/gcc/ada/ali.adb:2265: error: control flow in the middle of basic block 664 /root/downloads/gcc-4_3-trunk/gcc/ada/ali.adb:2265: error: control flow in the middle of basic block 664 +===GNAT BUG DETECTED==+ | 4.3.0 20070522 (experimental) (i686-pc-linux-gnu) verify_flow_info failed| | Error detected around /root/downloads/gcc-4_3-trunk/gcc/ada/ali.adb:2265 | | 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). | +==+ (blank line) Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. (blank line) /root/downloads/gcc-4_3-trunk/gcc/ada/ali.adb /root/downloads/gcc-4_3-trunk/gcc/ada/ali.ads /root/downloads/gcc-4_3-trunk/gcc/ada/casing.ads /root/downloads/gcc-4_3-trunk/gcc/ada/types.ads /root/downloads/gcc-4_3-trunk/gcc/ada/gnatvsn.ads /root/downloads/gcc-4_3-trunk/gcc/ada/rident.ads /root/downloads/gcc-4_3-trunk/gcc/ada/table.ads /root/downloads/gcc-4_3-trunk/gcc/ada/butil.ads /root/downloads/gcc-4_3-trunk/gcc/ada/debug.ads /root/downloads/gcc-4_3-trunk/gcc/ada/fname.ads /root/downloads/gcc-4_3-trunk/gcc/ada/namet.ads /root/downloads/gcc-4_3-trunk/gcc/ada/alloc.ads /root/downloads/gcc-4_3-trunk/gcc/ada/hostparm.ads /root/downloads/gcc-4_3-trunk/gcc/ada/opt.ads /root/downloads/gcc-4_3-trunk/gcc/ada/osint.ads /root/downloads/gcc-4_3-trunk/gcc/ada/output.ads /root/downloads/gcc-4_3-trunk/gcc/ada/table.adb /root/downloads/gcc-4_3-trunk/gcc/ada/tree_io.ads (blank line) (blank line) raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:398 make[3]: *** [ada/ali.o] Error 1 make[3
[Bug other/32051] New: Patch: Add GCC Extension Modules (GEM) to 4.1.1 4.2.1 4.3.0
Page http://gcc.gnu.org/readings.html links to GNU C Compiler Internals (Wikibook) http://en.wikibooks.org/wiki/GNU_C_Compiler_Internals , which in turn links to: GNU C Compiler Internals/GEM Framework 4 1 http://en.wikibooks.org/wiki/GNU_C_Compiler_Internals/GEM_Framework_4_1 . On that page, it says (in part) this: GEM framework is designed to facilitate development of compiler extensions. GEM defines a number of hooks throughout GCC's source code. It is implemented as a patch to GCC. With GEM, a compiler extension is developed as a stand-alone program. It is compiled into a dynamically-linked module which is specified as the command line argument when GCC is invoked. GCC loads the module and calls its initialization function. The module then registers its hooks that are call-back functions in GCC. In addition to the compiler hooks, GEM provides macros and functions that simplify extension development. The current version of GEM defines a set of hooks in the preprocessor, the AST, and the assembly code generation components of GCC. The wiki links to http://www.ecsl.cs.sunysb.edu/gem/ which provides http://www.ecsl.cs.sunysb.edu/gem/gem-1.7.tar.gz - the subject of this patch enhancement. Using GEM and DIRA you can protect your code against attacks (and presumably any other crashes) similar to SSP or Mudflaps. GEM with DIRA claims to only slow down the code it is used on some 20-50% (better than most other methods). What is really great is that it can: First, the memory state of the program is restored to a pre-attack state. Second, a proper restart point is chosen and the control is transferred to that point. This allows your program to rollback and restart. Imagine you are using an editor and saving your work. A fatal error occurs and crashes the program poping up an (otherwise) annoying little window. Now after you dismiss the message your program will simply continue. TRUE, if you do _exactly_ the same thing again you might well expect the same result. What if you copied the text to the clipboard and pasted it into another editor, then saved it - that is not the same as you did before, thus the result should be different (IE: you can save your text, exit the program and re-install a prior version if you wish). Programs (and programmers) that went the extra mile (instead of simply adding a compiler switch to the build) could write two subroutines (or different methods) and when the crash occurred you could rollback and the program could try the alternate routine for you. No more ICE errors (in _end_ products, we still want bug-reports for GCC so we can improve it :) ), the optimizers can backtrack to where the were last successful and continue on a different path. --- Currently GEM only supports GCC 3.4.1 and 4.1.0 so I made some patches for: GCC 4.1.1 release revision 114100 GCC 4.2.1 Mon May 21 14:05:54 UTC 2007 (revision 124902) GCC 4.3.0 Tue May 22 09:28:18 UTC 2007 (revision 124940) I propose it would be a great idea to incorporate GEM into GCC. GEM alone does not cause a significant speed penalty on GCC. (The DIRA loadable module can make code run 20-50% slower _if_ it is loaded). I am posting a note to [EMAIL PROTECTED] and enclosing the patches here: -- Summary: Patch: Add GCC Extension Modules (GEM) to 4.1.1 4.2.1 4.3.0 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: other 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=32051
[Bug other/32051] Patch: Add GCC Extension Modules (GEM) to 4.1.1 4.2.1 4.3.0
--- Comment #1 from rob1weld at aol dot com 2007-05-23 06:06 --- Created an attachment (id=13604) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13604action=view) gem-1.7/patch/gem-4.1.1.patch - Add GEM to GCC 4.1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32051
[Bug other/32051] Patch: Add GCC Extension Modules (GEM) to 4.1.1 4.2.1 4.3.0
--- Comment #2 from rob1weld at aol dot com 2007-05-23 06:07 --- Created an attachment (id=13605) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13605action=view) gem-1.7/patch/gem-4.2.1.patch - Add GEM to GCC 4.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32051
[Bug other/32051] Patch: Add GCC Extension Modules (GEM) to 4.1.1 4.2.1 4.3.0
--- Comment #3 from rob1weld at aol dot com 2007-05-23 06:07 --- Created an attachment (id=13606) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13606action=view) gem-1.7/patch/gem-4.3.0.patch - Add GEM to GCC 4.3.0 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32051
[Bug other/32051] Patch: Add GCC Extension Modules (GEM) to 4.1.1 4.2.1 4.3.0
--- Comment #5 from rob1weld at aol dot com 2007-05-23 06:29 --- The patch for 4.1.1 was created by simply using the GEM revision 4.1.0 patch on the release version of the GCC 4.1.1 source. All hunks succeeded with minimal offsets. The patch for 4.2.1 was created by simply using the GEM revision 4.1.0 patch on the 124902 version of the GCC 4.2.1 source. Most hunks succeeded with small offsets, some with larger offsets. The were rejects in: gcc/calls.c (1 hunk), gcc/c-common.c (1 hunk) and gcc/Makefile.in (2 hunks). All the rejects were repaired. The patch for 4.3.0 was created by (not so) simply using the GEM revision 4.1.0 patch on the 124940 version of the GCC 4.3.0 source and referring to the 4.2.1 source. Most hunks succeeded with moderate (under 200 max) offsets, some went together easily. The were rejects in: gcc/c-decl.c, gcc/gimplify.c, gcc/calls.c, gcc/cfgexpand.c, gcc/c-common.c and gcc/Makefile.in . I did my best to try and apply the 4.3.0 fixes, I am more familiar with 4.2.0. All the rejects were repaired, I hope they are OK. Search for /* Added to see a couple of spots were the patch should be fine were it is _OR_ needs to go one line down. It would be great if someone with more 4.3.0 experience could check them out for us and post any fixes. Thanks and enjoy. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32051
[Bug other/32051] Patch: Add GCC Extension Modules (GEM) to 4.1.1 4.2.1 4.3.0
--- Comment #6 from rob1weld at aol dot com 2007-05-23 06:31 --- Got mid-air colision message when clicking submit. I understand this is closed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32051
[Bug other/32051] Patch: Add GCC Extension Modules (GEM) to 4.1.1 4.2.1 4.3.0
--- Comment #8 from rob1weld at aol dot com 2007-05-23 17:57 --- Thanks Manuel. I imagined that since I read it at http://gcc.gnu.org/readings.html that the GEM would (or _might_) be incorporated in future. My purpose in posting: 1): The patches were posted MORE with the thought that the general public would apply the patches, do some tests, submit any fixes - and AFTER all that, then (and only then) _might_ the maintainers _consider_ adding GEM. 2): To avoid the possiblility that people who write code (maintainers) would avoid writing code that shut GEM out (_if_ it _might_ be coming in the future). One example of this happening is that I tried to add boehm-gc 7 to GCC but the _Java_ code was written in such a way that you can't add gc-7 without some re-writing (if you compile GCC _WITHOUT_ Java it compiles fine). The Java maintainers went under the ABI and snooped in GC's .h files and used features that have been discontinued and did not follow exactly what is on http://gcc.gnu.org/contribute.html . 3): I thought it was GPL. 4): It was _never_ my thought that one of the maintainers were simply going to apply the patches to the SVN and unleash it on everyone. I agree with Andrew that were not putting it in SVN today - if that is what you thought I meant. I thought it was something that _might_ be coming and so made the patches for people to play with it. I'll fiddle with something else. Maybe have another look at GC7. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32051
[Bug testsuite/32060] New: gcc/testsuite/gcc/gcc.log - WARNING: Could not compile gcc.dg/compat/struct-layout-1 generator
/struct-layout-1 generator FAIL: gcc.dg/debug/dwarf2/dwarf-dfp.c (internal compiler error) FAIL: gcc.dg/debug/dwarf2/dwarf-dfp.c (test for excess errors) ERROR: gcc.dg/debug/dwarf2/dwarf-dfp.c: error executing dg-final: couldn't open dwarf-dfp.s: no such file or directory UNRESOLVED: gcc.dg/debug/dwarf2/dwarf-dfp.c: error executing dg-final: couldn't open dwarf-dfp.s: no such file or directory FAIL: gcc.dg/dfp/Wtraditional-conversion-2.c (internal compiler error) FAIL: gcc.dg/dfp/Wtraditional-conversion-2.c (test for excess errors) The testsuite _CLAIMS_ it could not open the file but actually it is an ICE. Here is a bit of the log: # grep -A 8 testsuite/gcc.dg/debug/dwarf2/dwarf-dfp.c gcc/testsuite/gcc/gcc.log Executing on host: /opt/gcc-4_3-build/gcc/xgcc -B/opt/gcc-4_3-build/gcc/ /root/downloads/gcc-4_3-trunk/gcc/testsuite/gcc.dg/debug/dwarf2/dwarf-dfp.c -O0 -gdwarf-2 -dA -fno-show-column -S -o dwarf-dfp.s(timeout = 300) /root/downloads/gcc-4_3-trunk/gcc/testsuite/gcc.dg/debug/dwarf2/dwarf-dfp.c: In function 'foo': /root/downloads/gcc-4_3-trunk/gcc/testsuite/gcc.dg/debug/dwarf2/dwarf-dfp.c:16: error: unrecognizable insn: (insn 7 6 8 3 /root/downloads/gcc-4_3-trunk/gcc/testsuite/gcc.dg/debug/dwarf2/dwarf-dfp.c:15 (set (subreg:TI (reg:TD 58) 0) (subreg:TI (const_double:TD 0 [0x0] 1.5 [N/A]) 0)) -1 (nil) (nil)) /root/downloads/gcc-4_3-trunk/gcc/testsuite/gcc.dg/debug/dwarf2/dwarf-dfp.c:16: internal compiler error: in extract_insn, at recog.c:2119 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. compiler exited with status 1 output is: /root/downloads/gcc-4_3-trunk/gcc/testsuite/gcc.dg/debug/dwarf2/dwarf-dfp.c: In function 'foo': /root/downloads/gcc-4_3-trunk/gcc/testsuite/gcc.dg/debug/dwarf2/dwarf-dfp.c:16: error: unrecognizable insn: (insn 7 6 8 3 /root/downloads/gcc-4_3-trunk/gcc/testsuite/gcc.dg/debug/dwarf2/dwarf-dfp.c:15 (set (subreg:TI (reg:TD 58) 0) (subreg:TI (const_double:TD 0 [0x0] 1.5 [N/A]) 0)) -1 (nil) (nil)) /root/downloads/gcc-4_3-trunk/gcc/testsuite/gcc.dg/debug/dwarf2/dwarf-dfp.c:16: internal compiler error: in extract_insn, at recog.c:2119 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. FAIL: gcc.dg/debug/dwarf2/dwarf-dfp.c (internal compiler error) FAIL: gcc.dg/debug/dwarf2/dwarf-dfp.c (test for excess errors) Excess errors: /root/downloads/gcc-4_3-trunk/gcc/testsuite/gcc.dg/debug/dwarf2/dwarf-dfp.c:16: error: unrecognizable insn: (insn 7 6 8 3 /root/downloads/gcc-4_3-trunk/gcc/testsuite/gcc.dg/debug/dwarf2/dwarf-dfp.c:15 (set (subreg:TI (reg:TD 58) 0) (subreg:TI (const_double:TD 0 [0x0] 1.5 [N/A]) 0)) -1 (nil) (nil)) /root/downloads/gcc-4_3-trunk/gcc/testsuite/gcc.dg/debug/dwarf2/dwarf-dfp.c:16: internal compiler error: in extract_insn, at recog.c:2119 ERROR: gcc.dg/debug/dwarf2/dwarf-dfp.c: error executing dg-final: couldn't open dwarf-dfp.s: no such file or directory UNRESOLVED: gcc.dg/debug/dwarf2/dwarf-dfp.c: error executing dg-final: couldn't open dwarf-dfp.s: no such file or directory Executing on host: /opt/gcc-4_3-build/gcc/xgcc -B/opt/gcc-4_3-build/gcc/ /root/downloads/gcc-4_3-trunk/gcc/testsuite/gcc.dg/debug/dwarf2/dwarf-die1.c -O2 -gdwarf-2 -dA -fno-show-column -S -o dwarf-die1.s(timeout = 300) PASS: gcc.dg/debug/dwarf2/dwarf-die1.c (test for excess errors) PASS: gcc.dg/debug/dwarf2/dwarf-die1.c scan-assembler-not DW_AT_inline Executing on host: /opt/gcc-4_3-build/gcc/xgcc -B/opt/gcc-4_3-build/gcc/ /root/downloads/gcc-4_3-trunk/gcc/testsuite/gcc.dg/debug/dwarf2/dwarf-die2.c -O0 -gdwarf-2 -dA -fno-show-column -S -o dwarf-die2.s(timeout = 300) PASS: gcc.dg/debug/dwarf2/dwarf-die2.c (test for excess errors) This little section of the testsuite needs a once over. -- Summary: gcc/testsuite/gcc/gcc.log - WARNING: Could not compile gcc.dg/compat/struct-layout-1 generator Product: gcc Version: 4.3.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: 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=32060
[Bug testsuite/32062] New: gcc revision 20070523 - Non-existant sse4 test (with wrong path) causes UNSUPPORTED for working tests
I have 4.3.0 SVN 20070523 and just updated it a minute ago to revision 125011. I ran make -i check and noticed a number of UNSUPPORTED in the C tests. # grep -B 5 -A 0 15233 gcc/testsuite/gcc/gcc.log PASS: gcc.target/i386/sse3-movshdup.c execution test Executing on host: /opt/gcc-4_3-build/gcc/xgcc -B/opt/gcc-4_3-build/gcc/ /root/downloads/gcc-4_3-trunk/gcc/testsuite/gcc.target/i386/sse3-movsldup.c -O2 -msse3 -fno-show-column -lm -o ./sse3-movsldup.exe(timeout = 300) PASS: gcc.target/i386/sse3-movsldup.c (test for excess errors) Setting LD_LIBRARY_PATH to :/opt/gcc-4_3-build/gcc::/opt/gcc-4_3-build/gcc:/opt/gcc-4_3-build/i686-pc-linux-gnu/libstdc++-v3/.libs:/opt/gcc-4_3-build/i686-pc-linux-gnu/libmudflap/.libs:/opt/gcc-4_3-build/i686-pc-linux-gnu/libssp/.libs:/opt/gcc-4_3-build/i686-pc-linux-gnu/libgomp/.libs:/opt/gcc-4_3-build/./gcc:/opt/gcc-4_3-build/./prev-gcc PASS: gcc.target/i386/sse3-movsldup.c execution test Executing on host: /opt/gcc-4_3-build/gcc/xgcc -B/opt/gcc-4_3-build/gcc/ -O2 -msse4.1 -fno-show-column -c -o sse4.15233.o sse4.15233.c(timeout = 300) Notice that the test of sse3-movsldup.c uses the path gcc.target/i386/ . Notice that the test of sse4.15233.c uses the path . In addition, the file sse4.15233.c did not exist the other day when I got the SVN _AND_ it still does not exist now when I re-got the SVN a few minutes ago. I checked my HD to see if it was generated, it does not exist. When the compilation of sse4.15233.c fails it causes a number of tests that follow to be ASSUMED (or at least reported) as unsupported. Here are a few: UNSUPPORTED: gcc.target/i386/sse4_1-blendpd.c UNSUPPORTED: gcc.target/i386/sse4_1-blendps.c UNSUPPORTED: gcc.target/i386/sse4_1-blendvpd.c _MY_ test method: # ls -l sse4_1* ls: sse4_1*: No such file or directory # /opt/gcc-4_3-build/gcc/xgcc -B/opt/gcc-4_3-build/gcc/ -O2 -msse4.1 -fno-show-column -c -o sse4_1-blendpd.o /root/downloads/gcc-4_3-trunk/gcc/testsuite/gcc.target/i386/sse4_1-blendpd.c # /opt/gcc-4_3-build/gcc/xgcc -B/opt/gcc-4_3-build/gcc/ -O2 -msse4.1 -fno-show-column -c -o sse4_1-blendps.o /root/downloads/gcc-4_3-trunk/gcc/testsuite/gcc.target/i386/sse4_1-blendps.c # /opt/gcc-4_3-build/gcc/xgcc -B/opt/gcc-4_3-build/gcc/ -O2 -msse4.1 -fno-show-column -c -o sse4_1-blendvpd.o /root/downloads/gcc-4_3-trunk/gcc/testsuite/gcc.target/i386/sse4_1-blendvpd.c : Assembler messages: :187: Error: no such instruction: `blendvpd %xmm0,-1000(%ebx,%ebp),%xmm1' # ls -l sse4_1* -rw-r--r-- 1 root root 1648 May 23 17:38 sse4_1-blendpd.o -rw-r--r-- 1 root root 1664 May 23 17:39 sse4_1-blendps.o So the more correct message would be: PASS: gcc.target/i386/sse4_1-blendpd.c PASS: gcc.target/i386/sse4_1-blendps.c UNSUPPORTED: gcc.target/i386/sse4_1-blendvpd.c The testsuite thinks that the failure of a non-existant file means the rest of the tests won't pass. I'm not an SSE expert but with so many processors types and variables you _might_ need to test for processor capability with a _COORECT_ program. Then use a huge chart that says exactly what is supported by the manufacturer - unless you actually wish to test unsupported but working instructions. Many cpuid programs are not bleading edge and you don't want to keep updating. Keeping a chart is a pain. Using cat /proc/cpuinfo is not reliable. cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 43 ... fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt lm 3dnowext 3dnow up pni lahf_lm cmp_legacy ts fid vid ttp I bet you think I have an Opteron, many programs do. There were so many problems with the gcc tests that I'll need to poke around and type make -i check-gcc to re-check gcc only. The other tests are not as bad. It is important that C work as it affects all the other compilers - and thus the results. We need ZERO errors in C (and Ada since it is a first-stager). -- Summary: gcc revision 20070523 - Non-existant sse4 test (with wrong path) causes UNSUPPORTED for working tests Product: gcc Version: 4.3.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: 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=32062
[Bug testsuite/32063] New: contrib/test_summary script could output results more neatly
This affects any HTB triplet if the person runs the contrib/test_summary script. The script creates results that are not pretty-printed and mails them to [EMAIL PROTECTED] which automatically generates ugly web pages. We might improved the line spacing in the mailer script, here is an example: ---START--- /opt/gcc-4_3-build/gcc/testsuite/gfortran/../../gfortran version 4.3.0 20070523 (experimental) === gnat tests === Running target unix FAIL: gnat.dg/address_conversion.adb execution test === gnat Summary === # of expected passes168 # of unexpected failures1 === obj-c++ tests === Running target unix --- END --- I suggest it would look better if it were like this: ---START--- /opt/gcc-4_3-build/gcc/testsuite/gfortran/../../gfortran version 4.3.0 20070523 (experimental) (Add a blank line here) === gnat tests === (Subtract a blank line here) Running target unix FAIL: gnat.dg/address_conversion.adb execution test === gnat Summary === # of expected passes168 # of unexpected failures1 (Add a blank line here) (Add a blank line here) === obj-c++ tests === (Subtract a blank line here) Running target unix --- END --- That is only a dozen line example. The _whole_ output is like that; with extra C/R's where they are not needed and too few C/R's in some spots. I realize that the output is supposed to be machine readable, so is our ource code. We have _standards_ for the appearance of the source, why not the output. While this is trivial we should have pride in our great compiler and the usually great results. Even if there are failures we should still present them neatly. See here for many examples: http://gcc.gnu.org/ml/gcc-testresults/2007-05/ -- Summary: contrib/test_summary script could output results more neatly Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rob1weld at aol dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32063
[Bug testsuite/32062] gcc revision 20070523 - Non-existant sse4 test (with wrong path) causes UNSUPPORTED for working tests
--- Comment #3 from rob1weld at aol dot com 2007-05-24 04:39 --- # as --version GNU assembler 2.17 Debian GNU/Linux That is the _newest_ apt-get from Debian. My test results are here: http://gcc.gnu.org/ml/gcc-testresults/2007-05/msg01171.html This is not really a bug, as the unsupported test means it is not supported on your configuration which is true (too of a fine checking is just causes more problems than it solves). You know I am big fan of everything ON, and working ;) It seems a shame that the test works when ran manually but that the automated mechanism is not going to be too fine grained. Another interesting command to run is this: # grep -B 5 -A 5 Assembler\ messages gcc/testsuite/gcc/gcc.log Executing on host: /opt/gcc-4_3-build/gcc/xgcc -B/opt/gcc-4_3-build/gcc/ /root/downloads/gcc-4_3-trunk/gcc/testsuite/gcc.target/i386/sse3-movsldup.c -O2 -msse3 -fno-show-column -lm -o ./sse3-movsldup.exe(timeout = 300) PASS: gcc.target/i386/sse3-movsldup.c (test for excess errors) Setting LD_LIBRARY_PATH to :/opt/gcc-4_3-build/gcc::/opt/gcc-4_3-build/gcc:/opt/gcc-4_3-build/i686-pc-linux-gnu/libstdc++-v3/.libs:/opt/gcc-4_3-build/i686-pc-linux-gnu/libmudflap/.libs:/opt/gcc-4_3-build/i686-pc-linux-gnu/libssp/.libs:/opt/gcc-4_3-build/i686-pc-linux-gnu/libgomp/.libs:/opt/gcc-4_3-build/./gcc:/opt/gcc-4_3-build/./prev-gcc PASS: gcc.target/i386/sse3-movsldup.c execution test Executing on host: /opt/gcc-4_3-build/gcc/xgcc -B/opt/gcc-4_3-build/gcc/ -O2 -msse4.1 -fno-show-column -c -o sse4.125141.o sse4.125141.c(timeout = 300) /tmp/ccKqTs3N.s: Assembler messages: /tmp/ccKqTs3N.s:8: Error: no such instruction: `pmulld %xmm1,%xmm0' compiler exited with status 1 output is: /tmp/ccKqTs3N.s: Assembler messages: /tmp/ccKqTs3N.s:8: Error: no such instruction: `pmulld %xmm1,%xmm0' UNSUPPORTED: gcc.target/i386/sse4_1-blendpd.c UNSUPPORTED: gcc.target/i386/sse4_1-blendps.c UNSUPPORTED: gcc.target/i386/sse4_1-blendvpd.c -- UNSUPPORTED: gcc.target/i386/sse4_1-roundss-1.c UNSUPPORTED: gcc.target/i386/sse4_1-roundss-2.c UNSUPPORTED: gcc.target/i386/sse4_1-roundss-3.c UNSUPPORTED: gcc.target/i386/sse4_1-roundss-4.c Executing on host: /opt/gcc-4_3-build/gcc/xgcc -B/opt/gcc-4_3-build/gcc/ -O2 -msse4a -fno-show-column -c -o sse4a25141.o sse4a25141.c(timeout = 300) /tmp/ccMwoETb.s: Assembler messages: /tmp/ccMwoETb.s:8: Error: no such instruction: `insertq %xmm1,%xmm0' compiler exited with status 1 output is: /tmp/ccMwoETb.s: Assembler messages: /tmp/ccMwoETb.s:8: Error: no such instruction: `insertq %xmm1,%xmm0' UNSUPPORTED: gcc.target/i386/sse4a-extract.c UNSUPPORTED: gcc.target/i386/sse4a-insert.c UNSUPPORTED: gcc.target/i386/sse4a-montsd.c Even though the assembler does not support _some_ instructions I can manually compile _some_ of the test programs. I guess ./configure must test as . It is not the fault of the (average) user if they have the newest apt-get of Debian GNU/Linux and something is broken. I am not average and I would be more than happy to compile binutils. I would want to use the same ./configure flags so I don't screw my as .(TM) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32062
[Bug testsuite/32062] gcc revision 20070523 - Non-existant sse4 test (with wrong path) causes UNSUPPORTED for working tests
--- Comment #4 from rob1weld at aol dot com 2007-05-24 06:01 ---
According to this page: http://www.gnu.org/software/binutils/
The newest version is being called binutils-2.17.50 (name for snapshot).
ftp://sourceware.org/pub/binutils/snapshots/
05/17/2006 12:00AM 13,716,872 binutils-2.16.93.tar.bz2
06/12/2006 12:00AM 13,814,217 binutils-2.16.94.tar.bz2
05/22/2007 05:47AM 14,958,122 binutils-2.17.50.tar.bz2
The best solution for Debian _might_ be:
cvs -z 9 -d :pserver:[EMAIL PROTECTED]:/cvs/src login
{enter anoncvs as the password}
cvs -z 9 -d :pserver:[EMAIL PROTECTED]:/cvs/src co binutils
and then go here: http://packages.debian.org/unstable/source/binutils and apply
http://ftp.debian.org/debian/pool/main/b/binutils/binutils_2.17cvs20070426-5.diff.gz
- making sure not to _undo_ anything, just planning to get the Debian'isms and
GNU/Linix'ishness .
After I do this it can not be my fault, correct ?
Do you have better advice?
I maintain that this should not be neccesary. It is like this for a lot of
parts of GCC, requiring bleeding edge (Like GTK libs). I can do it and don't
mind but it reduces the number of people who can do everything and increases
tech-support / bug reports.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32062
[Bug bootstrap/30341] Makefile using mv instead of ln not working on WinXP Cygwin Bash
--- Comment #4 from rob1weld at aol dot com 2007-05-24 06:05 --- I have found that with very low system load that it _can_ occur using an XTerm window afterall - infrequently. If your compiling for Cygwin it is best to make the mod to the Makefile. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30341
[Bug libmudflap/31845] Need to adjust libmudflap timeout values in testsuite.
--- Comment #1 from rob1weld at aol dot com 2007-05-24 06:15 --- This has not happened in the last few weeks. It _might_ be fixed. I would need to wait until I'm doing a half a dozen things at once and had a high load; while compiling gcc. If a maintainer happens across this bug report and needs to close it for the purposes of making a release - be my guest. Since there are other tests with timeout errors I will leave this open. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31845
[Bug bootstrap/31998] Incorrect Unreachable statement turns off optimizing + spec file in error
--- Comment #1 from rob1weld at aol dot com 2007-05-24 06:33 --- Added keywords ice-on-valid-code rejects-valid since when the spec file is modified the ICE does not occur. We need a new function that ouputs a message that the spec (internal or external file) is incorrect. It is not _really_ correct to call it an ICE since it is not an internal compiler error but an internal (or external) spec info omission that cause the abort which claims it is an ICE. -- rob1weld at aol dot com changed: What|Removed |Added Keywords||ice-on-valid-code, rejects- ||valid http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31998
[Bug middle-end/32024] ICE - libgcc2.c:557: internal compiler error: in fold_checksum_tree, at fold-const.c:12652
--- Comment #6 from rob1weld at aol dot com 2007-05-24 06:41 --- make profiledbootstrap is broken. Newest compile uses --enable-stage1-checking=assert,gc,misc,rtl,rtlflag,runtime since both fold and tree have some issues. Results for 4.3.0 20070523 (experimental) testsuite on i686-pc-linux-gnu http://gcc.gnu.org/ml/gcc-testresults/2007-05/msg01171.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32024
[Bug libgcj/32028] Make fails at gjdoc - gnu.classpath.tools.gjdoc.ParseException: unmatched input in line 1: @Retention(SOURCE) @Target(METHOD)
--- Comment #2 from rob1weld at aol dot com 2007-05-24 19:48 --- The configure script ought to check for gjdoc version - I _do_ have the newest version from using apt-get update apt-get upgrade - how are people supposed to use the --with-gjdoc if it is not better documaented? The gcc SVN needs to include the neccesary version of gjdoc source to compile the Java documentation that is in the SVN. Here is some info from Classpath (not gcc) that might help in future so I will put this here for reference: How to generate API Documentation with gjdoc/libxmlj: http://www.gnu.org/software/classpath/faq/faq/faq.html#faq5_1 Here is some info on building NEWER gjdoc: http://gcc.gnu.org/ml/java/2004-11/msg00169.html I'll try this and get back in a while ... Thanks for your help. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32028
[Bug testsuite/32062] Some MASKs aren't sufficient in certain sse4_1 testsA MASK is non-efficient in certain sse4_1 testsSome MASKs aren't sufficient in certain sse4_1 tests
--- Comment #9 from rob1weld at aol dot com 2007-05-24 20:03 --- Thank you for looking into this, everyone. I do appreciate it working correctly. Here is the extreme steps I took to fix my problem. It is not reasonable that the average person would be assumed to know this (something is broken and it's not my fault ;) ), but here it is for the sake of documentaion ... --- # wget http://ftp.debian.org/debian/pool/main/b/binutils/binutils_2.17cvs20070426-7_i386.deb # dpkg -i binutils_2.17cvs20070426-7_i386.deb Preparing to replace binutils 2.17-3 (using binutils_2.17cvs20070426-7_i386.deb) ... Unpacking replacement binutils ... dpkg: dependency problems prevent configuration of binutils: binutils depends on libc6 (= 2.5-5); however: Version of libc6 on system is 2.3.6.ds1-13. dpkg: error processing binutils (--install): dependency problems - leaving unconfigured Errors were encountered while processing: binutils # apt-get install libc6 Reading package lists... Done Building dependency tree... Done libc6 is already the newest version. You might want to run `apt-get -f install' to correct these: The following packages have unmet dependencies: binutils: Depends: libc6 (= 2.5-5) but 2.3.6.ds1-13 is to be installed --- NFG ! --- So instead do this. # dpkg-deb -x binutils_2.17cvs20070426-7_i386.deb tmp # cp tmp/usr/lib/libopcodes-2.17.50.20070426.so /usr/lib # cp tmp/usr/lib/libbfd-2.17.50.20070426.so /usr/lib # mv /usr/bin/as /usr/bin/as-Origonal # cp tmp/usr/bin/as /usr/bin # as --version GNU assembler (GNU Binutils for Debian) 2.17.50.20070426 # diff -u gcc/testsuite/gcc/gcc-try2-log.txt gcc/testsuite/gcc/gcc-try3-log.txt | tail -n 20 === gcc Summary === -# of expected passes 45242 +# of expected passes 45374 # of unexpected failures 90 # of unexpected successes 2 # of expected failures 134 # of unresolved testcases 38 # of untested testcases28 -# of unsupported tests 372 +# of unsupported tests 306 Target: i686-pc-linux-gnu gcc version 4.3.0 20070523 (experimental) # grep -n Assembler\ messages gcc/testsuite/gcc/gcc-try*-log.txt gcc/testsuite/gcc/gcc-try1-log.txt:114819:/tmp/cceBAOxd.s: Assembler messages: gcc/testsuite/gcc/gcc-try1-log.txt:114823:/tmp/cceBAOxd.s: Assembler messages: gcc/testsuite/gcc/gcc-try1-log.txt:114891:/tmp/ccV6VpRr.s: Assembler messages: gcc/testsuite/gcc/gcc-try1-log.txt:114895:/tmp/ccV6VpRr.s: Assembler messages: gcc/testsuite/gcc/gcc-try2-log.txt:114850:/tmp/ccKqTs3N.s: Assembler messages: gcc/testsuite/gcc/gcc-try2-log.txt:114854:/tmp/ccKqTs3N.s: Assembler messages: gcc/testsuite/gcc/gcc-try2-log.txt:114922:/tmp/ccMwoETb.s: Assembler messages: gcc/testsuite/gcc/gcc-try2-log.txt:114926:/tmp/ccMwoETb.s: Assembler messages: gcc/testsuite/gcc/gcc-try3-log.txt: (NOTHING) That is as fixed as it gets. _Unless_ you have some advice to offer. -- rob1weld at aol dot com changed: What|Removed |Added Status|RESOLVED|VERIFIED Summary|Some MASKs aren't sufficient|Some MASKs aren't sufficient |in certain sse4_1 tests |in certain sse4_1 testsA |A MASK is non-efficient in |MASK is non-efficient in |certain sse4_1 tests|certain sse4_1 testsSome |Some MASKs aren't sufficient|MASKs aren't sufficient in |in certain sse4_1 tests |certain sse4_1 tests http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32062
[Bug bootstrap/31746] Broken ./configure sed scripting affecting *gcc/configargs.h construction.
--- Comment #7 from rob1weld at aol dot com 2007-05-24 20:05 --- Thanks, works OK. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31746
[Bug other/32078] New: Make FAILURE in 4.3.0 - `CXXFLAGS' has changed error causes libltdl: No such file or directory
/libltdl/configure --enable-languages=c,ada,c++,fortran,java,objc,obj-c++ ... Yes, in that _particular_ example you might have gotten away with leaving out the --enable-languages= stuff and just typed configure. _IF_ you use _many_ configure options then do NOT leave them out. Use them all to avoid strange errors. Now change back to the build directory and continue without error. # cd ../../.. # make Usually that would work, but not _this_ week. Depends of state of SVN, and might of been a result of attempting to try ./config.status --recheck . Now getting this error: make[3]: Leaving directory `/opt/gcc-4_3-build/i686-pc-linux-gnu/libjava/gcj' Making all in include make[3]: Entering directory `/opt/gcc-4_3-build/i686-pc-linux-gnu/libjava/include' make all-am make[4]: Entering directory `/opt/gcc-4_3-build/i686-pc-linux-gnu/libjava/include' make[4]: Leaving directory `/opt/gcc-4_3-build/i686-pc-linux-gnu/libjava/include' make[3]: Leaving directory `/opt/gcc-4_3-build/i686-pc-linux-gnu/libjava/include' Making all in classpath make[3]: Entering directory `/opt/gcc-4_3-build/i686-pc-linux-gnu/libjava/classpath' make[3]: *** No rule to make target `all'. Stop. make[3]: Leaving directory `/opt/gcc-4_3-build/i686-pc-linux-gnu/libjava/classpath' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/opt/gcc-4_3-build/i686-pc-linux-gnu/libjava' make[1]: *** [all-target-libjava] Error 2 make[1]: Leaving directory `/opt/gcc-4_3-build' make: *** [all] Error 2 # cd /opt/gcc-4_3-build/i686-pc-linux-gnu/libjava Perform the same .../configure trick as you did for libltdl. # cd ../.. # make The make continues normally. The first error _might_ be fixed before many people read this, the second error is months old. It is annoying that make is not restartable in the libjava directory. -- Summary: Make FAILURE in 4.3.0 - `CXXFLAGS' has changed error causes libltdl: No such file or directory Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: other 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=32078
[Bug libgcj/32028] Make fails at gjdoc - gnu.classpath.tools.gjdoc.ParseException: unmatched input in line 1: @Retention(SOURCE) @Target(METHOD)
--- Comment #3 from rob1weld at aol dot com 2007-05-25 09:55 ---
Ran accros this interesting post, seems we've had this a while ...
gjdoc in libgcj
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19612
After some messing with trying to access the gjdoc SVN according to the above
advice from those links (without a password); I went elsehere.
Here are some programs I had already (from gcc 4.2.0 install);
# gcj --version
gcj (GCC) 4.2.0 20070501 (prerelease)
# gij --version
java version 1.4.2
gij (GNU libgcj) version 4.2.0 20070501 (prerelease)
Here is what worked and what it looked like:
# wget ftp://ftp.gnu.org/gnu/classpath/gjdoc-0.7.8.tar.gz
# gunzip -d gjdoc-0.7.8.tar.gz
# tar -xf gjdoc-0.7.8.tar.gz
# cd gjdoc-0.7.8
# ./configure
...
checking if gij works... yes
checking for gcj... gcj -C
checking if gcj -C works... yes
configure: WARNING:
The build seems to be using gcj for bytecode generation. Some
versions of gcj are known to produce bad bytecode. See here for a
list of bugs that may be relevant:
http://gcc.gnu.org/bugzilla/buglist.cgi?component=javakeywords=wrong-codeorder=default
At least bug 19921 is known to affect gjdoc (in Feb 2005).
You may want to set the environment variable JAVAC to an alternate
compiler, such as jikes, to make sure that you end up with valid
bytecode.
...
checking for antlr 2.7.1 or better... 2.7.6
checking for java.util.regex.Pattern class... yes
configure: creating ./config.status
config.status: creating gjdoc.sh
config.status: WARNING: gjdoc.sh.in seems to ignore the --datarootdir setting
# make
# make install
works OK despite warnings.
Now getting this screen output:
make[4]: Leaving directory
`/opt/gcc-4_3-build/i686-pc-linux-gnu/libjava/classpath/lib'
Making all in doc
make[4]: Entering directory
`/opt/gcc-4_3-build/i686-pc-linux-gnu/libjava/classpath/doc'
Making all in api
make[5]: Entering directory
`/opt/gcc-4_3-build/i686-pc-linux-gnu/libjava/classpath/doc/api'
/bin/mkdir html /dev/null 21
/usr/local/bin/gjdoc \
-use \
-sourcepath
../..:/root/downloads/gcc-4_3-trunk/libjava/classpath:/root/downloads/gcc-4_3-trunk/libjava/classpath/vm/reference:/root/downloads/gcc-4_3-trunk/libjava/classpath/external/w3c_dom:/root/downloads/gcc-4_3-trunk/libjava/classpath/external/sax
\
-encoding UTF-8 \
-breakiterator \
-licensetext \
-linksource \
-splitindex \
-validhtml \
-d html \
-doctitle GNU Classpath 0.94-pre \
-windowtitle GNU Classpath 0.94-pre Documentation \
-header span class='logo'a
href='http://www.gnu.org/software/classpath' target='_top'GNU Classpath/a
(0.94-pre) -footer span class='logo'a
href='http://www.gnu.org/software/classpath' target='_top'GNU Classpath/a
(0.94-pre) \
-subpackages java:javax:org
WARNING: unknown modifier '@Retention(SOURCE)'
WARNING: unknown modifier '@Target(METHOD)'
WARNING: unknown modifier '@Retention(SOURCE)'
WARNING: unknown modifier '@Target({TYPE, FIELD, METHOD, PARAMETER,
CONSTRUCTOR, LOCAL_VARIABLE})'
WARNING: unknown modifier '@Documented'
WARNING: unknown modifier '@Retention(RUNTIME)'
ARGH! public
ARGH! static
ARGH! S
ARGH! extends
ARGH! EnumS
ARGH! S
ARGH! valueOf(ClassS
ARGH! String
ARGH! s)
Loading classes for package java.sql...
Loading classes for package java.lang...
Loading classes for package java.lang.reflect...
Loading classes for package java.lang.instrument...
Loading classes for package java.lang.ref...
Loading classes for package java.lang.annotation...
WARNING: unknown modifier '@Documented'
WARNING: unknown modifier '@Retention(RUNTIME)'
WARNING: unknown modifier '@Target(ANNOTATION_TYPE)'
WARNING: unknown modifier '@Documented'
WARNING: unknown modifier '@Retention(RUNTIME)'
WARNING: unknown modifier '@Documented'
WARNING: unknown modifier '@Retention(RUNTIME)'
WARNING: unknown modifier '@Target(ANNOTATION_TYPE)'
WARNING: unknown modifier '@Documented'
WARNING: unknown modifier '@Retention(RUNTIME)'
WARNING: unknown modifier '@Target(ANNOTATION_TYPE)'
Loading classes for package java.lang.management...
Loading classes for package java.text...
Loading classes for package java.applet...
Loading classes for package java.nio...
Loading classes for package java.nio.charset...
According to some web pages those errors are to be expected.
Which version _should_ we use so that we don't get any warnings or errors?
The fix for this bug is that gcc 4.2.0 and 4.2.1 main configure MUST test for
gjdoc version 0.7.7 _minimum_ and gcc 4.3.0 main configure MUST test for gjdoc
0.7.8 _minimum (a newer version, it easily available would be better).
A version that worked properly in directory ftp://ftp.gnu.org/gnu/classpath/
would be a good idea. Would you be allowed to do that Tom?
Thanks
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32028
[Bug other/32078] Make FAILURE in 4.3.0 - `CXXFLAGS' has changed error causes libltdl: No such file or directory
--- Comment #1 from rob1weld at aol dot com 2007-05-25 10:49 --- Found an additional problem. After all the stages are done and we are building the libraries in the target name directory (EG: in _my_ case the directory is called i686-pc-linux-gnu) we must _always_ use xgcc and NOT gcc (the OS's compiler). Correct? Here is a bit of screen output: make[2]: Leaving directory `/opt/gcc-4_3-build/i686-pc-linux-gnu/boehm-gc' make[2]: Entering directory `/opt/gcc-4_3-build/i686-pc-linux-gnu/libobjc' : make ; exec true AR=ar AR_FLAGS=rc CC=/opt/gcc-4_3-build/./gcc/xgcc -B/opt/gcc-4_3-build/./gcc/ -B/usr/i686-pc-linux-gnu/bin/ -B/usr/i686-pc-linux-gnu/lib/ -isystem /usr/i686-pc-linux-gnu/include -isystem /usr/i686-pc-linux-gnu/sys-include CFLAGS=-O2 -g -O2 DESTDIR= LIBCFLAGS=-O2 -g -O2 EXTRA_OFILES= That is OK. Here is some more (from the build log): # grep -A 4 /opt/gcc-4_3-build/i686-pc-linux-gnu/libjava/classpath/native/fdlibm gcc-4_3-build/make_6* gcc-4_3-build/make_6b_log.txt:make[5]: Entering directory `/opt/gcc-4_3-build/i686-pc-linux-gnu/libjava/classpath/native/fdlibm' gcc-4_3-build/make_6b_log.txt-if /bin/sh ../../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I/root/downloads/gcc-4_3-trunk/libjava/classpath/native/fdlibm -I../../include -O2 -g -O2 -MT dtoa.lo -MD -MP -MF .deps/dtoa.Tpo -c -o dtoa.lo /root/downloads/gcc-4_3-trunk/libjava/classpath/native/fdlibm/dtoa.c; \ gcc-4_3-build/make_6b_log.txt- then mv -f .deps/dtoa.Tpo .deps/dtoa.Plo; else rm -f .deps/dtoa.Tpo; exit 1; fi gcc-4_3-build/make_6b_log.txt-mkdir .libs gcc-4_3-build/make_6b_log.txt-gcc -DHAVE_CONFIG_H -I. -I/root/downloads/gcc-4_3-trunk/libjava/classpath/native/fdlibm -I../../include -O2 -g -O2 -MT dtoa.lo -MD -MP -MF .deps/dtoa.Tpo -c /root/downloads/gcc-4_3-trunk/libjava/classpath/native/fdlibm/dtoa.c -fPIC -DPIC -o .libs/dtoa.o Notice that is uses gcc to build dtoa ... When I compiled gcc previously it didn't do that: # grep -A 4 /opt/gcc-4_3-build/i686-pc-linux-gnu/libjava/classpath/native/fdlibm make_5* make_5c_log.txt:make[5]: Entering directory `/opt/gcc-4_3-build/i686-pc-linux-gnu/libjava/classpath/native/fdlibm' make_5c_log.txt-if /bin/sh ../../libtool --mode=compile /opt/gcc-4_3-build/./gcc/xgcc -B/opt/gcc-4_3-build/./gcc/ -B/usr/i686-pc-linux-gnu/bin/ -B/usr/i686-pc-linux-gnu/lib/ -isystem /usr/i686-pc-linux-gnu/include -isystem /usr/i686-pc-linux-gnu/sys-include -DHAVE_CONFIG_H -I. -I/root/downloads/gcc-4_3-trunk/libjava/classpath/native/fdlibm -I../../include -O2 -g -O2 -MT dtoa.lo -MD -MP -MF .deps/dtoa.Tpo -c -o dtoa.lo /root/downloads/gcc-4_3-trunk/libjava/classpath/native/fdlibm/dtoa.c; \ make_5c_log.txt-then mv -f .deps/dtoa.Tpo .deps/dtoa.Plo; else rm -f .deps/dtoa.Tpo; exit 1; fi make_5c_log.txt-mkdir .libs make_5c_log.txt-/opt/gcc-4_3-build/./gcc/xgcc -B/opt/gcc-4_3-build/./gcc/ -B/usr/i686-pc-linux-gnu/bin/ -B/usr/i686-pc-linux-gnu/lib/ -isystem /usr/i686-pc-linux-gnu/include -isystem /usr/i686-pc-linux-gnu/sys-include -DHAVE_CONFIG_H -I. -I/root/downloads/gcc-4_3-trunk/libjava/classpath/native/fdlibm -I../../include -O2 -g -O2 -MT dtoa.lo -MD -MP -MF .deps/dtoa.Tpo -c /root/downloads/gcc-4_3-trunk/libjava/classpath/native/fdlibm/dtoa.c -fPIC -DPIC -o .libs/dtoa.o That is not the only library where this occurs. The tests will be invalid if gcc is used instead of xgcc. The gcc-bugs scripts will be sending out false e-mails about breakages. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32078
[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 bootstrap/38693] gcc 4.4.0 20090101 - gcc/config/i386/sol2-10.h uses USE_GAS which is undefined
--- Comment #1 from rob1weld at aol dot com 2009-01-02 13:46 --- Prior to changing gcc/config/i386/sol2-10.h: u...@opensolaris:/usr/share/src/gcc_build# /usr/share/src/gcc_build/gcc/xgcc -v -B/usr/share/src/gcc_build/gcc/ -B/usr/local/i386-pc-solaris2.11/bin/ -B/usr/local/i386-pc-solaris2.11/lib/ -isystem /usr/local/i386-pc-solaris2.11/include -isystem /usr/local/i386-pc-solaris2.11/sys-include -m64 -c -g -O2 test_gcc_1.c ... GNU C (GCC) version 4.4.0 20090101 (experimental) (i386-pc-solaris2.11) compiled by GNU C version 4.2.2, GMP version 4.2.1, MPFR version 2.3.2. GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 0e3e878a55369e9ed157733a6752ae45 COLLECT_GCC_OPTIONS='-v' '-B/usr/share/src/gcc_build/gcc/' '-B/usr/local/i386-pc-solaris2.11/bin/' '-B/usr/local/i386-pc-solaris2.11/lib/' '-isystem' '/usr/local/i386-pc-solaris2.11/include' '-isystem' '/usr/local/i386-pc-solaris2.11/sys-include' '-m64' '-c' '-g' '-O2' '-mtune=generic' /usr/share/src/gcc_build/gcc/as -V -Qy -xarch=generic64 -s -o test_gcc_1.o /var/tmp//cc2mayli.s GNU assembler version 2.19 (i386-pc-solaris2.11) using BFD version (GNU Binutils) 2.19 /usr/local/i386-pc-solaris2.11/bin/as: unrecognized option `-xarch=generic64' u...@opensolaris:/usr/share/src/gcc_build# After changing gcc/config/i386/sol2-10.h: u...@opensolaris:/usr/share/src/gcc_build# /usr/share/src/gcc_build/gcc/xgcc -v -B/usr/share/src/gcc_build/gcc/ -B/usr/local/i386-pc-solaris2.11/bin/ -B/usr/local/i386-pc-solaris2.11/lib/ -isystem /usr/local/i386-pc-solaris2.11/include -isystem /usr/local/i386-pc-solaris2.11/sys-include -m64 -c -g -O2 test_gcc_1.c ... GNU C (GCC) version 4.4.0 20090101 (experimental) (i386-pc-solaris2.11) compiled by GNU C version 4.2.2, GMP version 4.2.1, MPFR version 2.3.2. GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 0e3e878a55369e9ed157733a6752ae45 COLLECT_GCC_OPTIONS='-v' '-B/usr/share/src/gcc_build/gcc/' '-B/usr/local/i386-pc-solaris2.11/bin/' '-B/usr/local/i386-pc-solaris2.11/lib/' '-isystem' '/usr/local/i386-pc-solaris2.11/include' '-isystem' '/usr/local/i386-pc-solaris2.11/sys-include' '-m64' '-c' '-g' '-O2' '-mtune=generic' /usr/share/src/gcc_build/gcc/as -V -Qy --64 -s -o test_gcc_1.o /var/tmp//ccU3aynm.s GNU assembler version 2.19 (i386-pc-solaris2.11) using BFD version (GNU Binutils) 2.19 COMPILER_PATH=/usr/share/src/gcc_build/gcc/:/usr/local/i386-pc-solaris2.11/bin/:/usr/local/i386-pc-solaris2.11/lib/:/usr/ccs/bin/ LIBRARY_PATH=/lib/amd64/:/usr/lib/amd64/:/usr/share/src/gcc_build/gcc/:/usr/local/i386-pc-solaris2.11/bin/:/usr/local/i386-pc-solaris2.11/lib/:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-v' '-B/usr/share/src/gcc_build/gcc/' '-B/usr/local/i386-pc-solaris2.11/bin/' '-B/usr/local/i386-pc-solaris2.11/lib/' '-isystem' '/usr/local/i386-pc-solaris2.11/include' '-isystem' '/usr/local/i386-pc-solaris2.11/sys-include' '-m64' '-c' '-g' '-O2' '-mtune=generic' u...@opensolaris:/usr/share/src/gcc_build# If USE_GAS in gcc/config/i386/sol2-10.h was set in the root ./configure on the basis of --with-as=/usr/gnu/bin/as and --with-gnu-as in a combination of whether the platform was sparc or i386 then we could get past this block in the build. It is unclear (to me) if the original author intended that Sun's assembler could be used instead of binutils' as (unlikely?) or if they were uncertain of which commands are used by each version (unlikely?). OpenSolaris' as (one of them) is called fbe (sunas) and accepts -m32 and -m64. The man page (2008/04/23) also says that this as only will accept -xarch= arguments for the Sparc Platform. If I knew what the original author intended I could suggest a proper fix. It would seem that either the root configure.ac needs to be modified to set USE_GAS correctly _or_ line 27 (the #ifndef USE_GAS) in the file gcc/config/i386/sol2-10.h could check if we are x86 or sparc . Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38693
[Bug java/38717] New: gcc 4.4.0 20090102 - jc1: out of memory allocating ... (with 1 G of RAM)
Similar to this bug: jc1: out of memory allocating 4072 bytes after a total of 708630224 bytes http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29587 I am compiling gcc on a machine with 1024 MB of memory and can't get past here: gmake[5]: Leaving directory `/usr/share/src/gcc_build/i386-pc-solaris2.11/amd64/libjava/testsuite' gmake[5]: Entering directory `/usr/share/src/gcc_build/i386-pc-solaris2.11/amd64/libjava' /bin/sh ./libtool --tag=GCJ --mode=compile /usr/share/src/gcc_build/gcc/gcj -B/usr/share/src/gcc_build/i386-pc-solaris2.11/amd64/libjava/ -B/usr/share/src/gcc_build/gcc/ -ffloat-store -fomit-frame-pointer -Usun -fclasspath= -fbootclasspath=../../../../gcc_trunk/libjava/classpath/lib --encoding=UTF-8 -Wno-deprecated -fbootstrap-classes -g -O2 -m64 -c -o gnu/javax/swing/text/html/parser/HTML_401F.lo -fsource-filename=/usr/share/src/gcc_build/i386-pc-solaris2.11/amd64/libjava/classpath/lib/classes -MT gnu/javax/swing/text/html/parser/HTML_401F.lo -MD -MP -MF gnu/javax/swing/text/html/parser/HTML_401F.deps @gnu/javax/swing/text/html/parser/HTML_401F.list libtool: compile: /usr/share/src/gcc_build/gcc/gcj -B/usr/share/src/gcc_build/i386-pc-solaris2.11/amd64/libjava/ -B/usr/share/src/gcc_build/gcc/ -ffloat-store -fomit-frame-pointer -Usun -fclasspath= -fbootclasspath=../../../../gcc_trunk/libjava/classpath/lib --encoding=UTF-8 -Wno-deprecated -fbootstrap-classes -g -O2 -m64 -c -fsource-filename=/usr/share/src/gcc_build/i386-pc-solaris2.11/amd64/libjava/classpath/lib/classes -MT gnu/javax/swing/text/html/parser/HTML_401F.lo -MD -MP -MF gnu/javax/swing/text/html/parser/HTML_401F.deps @gnu/javax/swing/text/html/parser/HTML_401F.list -fPIC -o gnu/javax/swing/text/html/parser/.libs/HTML_401F.o jc1: out of memory allocating 4072 bytes after a total of 312090624 bytes gmake[5]: *** [gnu/javax/swing/text/html/parser/HTML_401F.lo] Error 1 gmake[5]: Leaving directory `/usr/share/src/gcc_build/i386-pc-solaris2.11/amd64/libjava' gmake[4]: *** [all-recursive] Error 1 gmake[4]: Leaving directory `/usr/share/src/gcc_build/i386-pc-solaris2.11/amd64/libjava' gmake[3]: *** [multi-do] Error 1 gmake[3]: Leaving directory `/usr/share/src/gcc_build/i386-pc-solaris2.11/libjava' gmake[2]: *** [all-multi] Error 2 gmake[2]: Leaving directory `/usr/share/src/gcc_build/i386-pc-solaris2.11/libjava' gmake[1]: *** [all-target-libjava] Error 2 gmake[1]: Leaving directory `/usr/share/src/gcc_build' gmake: *** [all] Error 2 I shutdown VirtualBox, increased the memory to 1600MB and rebooted. During the build I ran the System Performance Monitor and monitored the amount of memory used. The memory peaked at 1.3 GBs. The build is now able to continue correctly with this memory size. Will ./configure be getting a memory test to see if we have enough available to compile? ;) Rob -- Summary: gcc 4.4.0 20090102 - jc1: out of memory allocating ... (with 1 G of RAM) Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: java 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=38717
[Bug bootstrap/38693] gcc 4.4.0 20090101 - gcc/config/i386/sol2-10.h uses USE_GAS which is undefined
--- Comment #2 from rob1weld at aol dot com 2009-01-03 19:15 --- Since this bug is related to the assembler I tried setting the --with-gnu-as --with-as= options for configure and while that allowed the build to continue it then went down a path of uncharted waters (and numerous problems with the scripts not creating/copying libtool, not building the 64 directories, etc.). What I finally ended up doing was this: ../gcc_trunk/configure --enable-languages=ada,c,c++,fortran,java,objc,obj-c++ --enable-multilib --enable-shared --disable-static --enable-decimal-float --enable-nls --with-gnu-as --with-as=/usr/local/bin/as --with-gnu-ld --with-ld=/usr/local/bin/ld Note that I set 'as' and 'ld' to the binutils-2.19 version (it is first in the path). On the Solaris Platform it is common (and recommended) to set --with-gnu-as --with-as=binutils-as --without-gnu-ld --with-ld=/usr/ccs/bin/ld when compiling gcc -- since I had not set these configure options the later scripts tooks paths that are untested on this platform (and therefore failed). It would seem that this is a second bug; that the configure script does not have the same effect if it detects options automatically that it would have if the user manually set the configure option to the same value. I should not have to actually set configure options (to their automatically determined (default) value) in order that later scripts will work correctly. I have completed make install and now for a little testing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38693
[Bug target/27880] [4.2/4.3 regression] undefined reference to `_Unwind_GetIPInfo'
--- Comment #33 from rob1weld at aol dot com 2009-01-03 19:53 --- With gcc version 4.4.0 20090102 on i386-pc-solaris2.11 I'm getting: # gcc -v -o test_gmp_1 test_gmp_1.cc -lgmp -lstdc++ /usr/local/lib/gcc/i386-pc-solaris2.11/4.4.0/../../../libstdc++.so: undefined reference to `_unwind_getipi...@gcc_4.2.0' collect2: ld returned 1 exit status -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27880
[Bug c/38730] New: gcc 4.4.0 20090104 - make -i check - over 60 FAILs in C compiler
configuration === ... === acats tests === Running chapter a ... Running chapter c2 ... Running chapter c3 ... FAIL: c34009l Running chapter c4 ... Running chapter c5 ... Running chapter c6 ... Running chapter c7 ... FAIL: c761006 Running chapter c8 ... Running chapter c9 ... Running chapter ca ... Running chapter cb ... Running chapter cc ... Running chapter cd ... Running chapter ce ... FAIL: ce3410a FAIL: ce3410e Running chapter cxa ... FAIL: cxa5a05 FAIL: cxa5a06 Running chapter cxb ... Running chapter cxf ... Running chapter cxg ... FAIL: cxg2004 FAIL: cxg2013 Running chapter cxh ... Running chapter cz ... Running chapter d ... Running chapter e ... Running chapter gcc ... Running chapter l ... === acats Summary === # of expected passes2307 # of unexpected failures8 *** FAILURES: c34009l c761006 ce3410a ce3410e cxa5a05 cxa5a06 cxg2004 cxg2013 ... -- Thanks, Rob -- Summary: gcc 4.4.0 20090104 - make -i check - over 60 FAILs in C compiler Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: critical 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=38730
[Bug libgomp/38086] [4.2/4.3/4.4 Regression] libgomp fails to build if assembler doesn't support .symver
--- Comment #2 from rob1weld at aol dot com 2009-01-05 17:07 --- I noticed this is a P1. Rainer Orth says: Building current mainline on Solaris 11/SPARC with GNU ld 2.19 and Sun as fails when building libgomp: The Official Position of Sun is: You must use Sun's ld. Andrew, on that basis you _might_ want to mark this Bug Report as INVALID. The Reporter is (according to the Manufacturer of his Operating System) trying to configure a compiler (to interface with Sun's Operating System) in a manner that in not supported. For that reason this should not be a P1 - but it should be fixed nonetheless. You are allowed to do it, it just is not recommended, and thus should this be a P1 ? I (like Rainer) compiled gcc (but it is a more recent version) using binutils 2.19 ld and I _also_ used binutils 2.19 as (unlike what Rainer did). I am also configuring the compiler in a manner that in not supported by Sun, but it _is_ supported by GNU; and that is what I am testing. NOTE: There is a reason (for Sun) to recommend the use of Sun's ld and no reason (for us) to require Sun's as be used. That statement is even more true if you are using binutils 2.19 ld (and thus have 'as' version 2.19) and not using Sun's ld (as is recommended). The only exception to this would either be to: 1. Test using binutils 2.19 ld instead of Sun's ld (which is NOT recommended (by Sun) and uncommented on, but permitted by GNU). 2. Try something that is not recommended and get it to work. I (who have a few years of building / porting GCC) can build gcc 4.4.0 20090104 on i386-pc-solaris2.11 (OpenSolaris 2008.11) this way: # /usr/local/bin/ld --version | grep Binutils GNU ld (GNU Binutils) 2.19 # /usr/local/bin/as --version | grep Binutils GNU ld (GNU Binutils) 2.19 # /usr/local/bin/gcc -v Using built-in specs. Target: i386-pc-solaris2.11 Configured with: ../gcc_trunk/configure --enable-languages=ada,c,c++,fortran,java,objc,obj-c++ --enable-shared --disable-static --enable-decimal-float --enable-nls --without-system-libunwind --with-gnu-as --with-as=/usr/local/bin/as --with-gnu-ld --with-ld=/usr/local/bin/ld Thread model: posix gcc version 4.4.0 20090104 (experimental) (GCC) I have built gcc previously using --with-as=/usr/sfw/bin/gas --with-gnu-as --with-ld=/usr/ccs/bin/ld --without-gnu-ld (that is a portion of Sun's recommended configure argument list) and libgomp built correctly using Sun's as so, Andrew, I believe this regression goes back only as far as 4.2.1 . Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38086
[Bug bootstrap/38727] New: gcc 4.4.0 20090104 - make -i check autogen fixinclude test FAILURES
The autogen program (Ver. 5.7) finds fixinclude test failures. # /usr/local/bin/gcc -v Using built-in specs. Target: i386-pc-solaris2.11 Configured with: ../gcc_trunk/configure --enable-languages=ada,c,c++,fortran,java,objc,obj-c++ --enable-shared --disable-static --enable-decimal-float --enable-nls --without-system-libunwind --with-gnu-as --with-as=/usr/local/bin/as --with-gnu-ld --with-ld=/usr/local/bin/ld Thread model: posix gcc version 4.4.0 20090104 (experimental) (GCC) # make -i check gmake[1]: Entering directory `/usr/share/src/gcc_build' gmake[2]: Entering directory `/usr/share/src/gcc_build/fixincludes' autogen -T ../../gcc_trunk/fixincludes/check.tpl ../../gcc_trunk/fixincludes/inclhack.def /bin/sh ./check.sh ../../gcc_trunk/fixincludes/tests/base Fixed: testing.h Fixed: testing.h Fixed: */sys/getppdp.h Fixed: AvailabilityMacros.h Fixed: X11/ShellP.h ... Fixed: tinfo.h Fixed: types/vxTypesBase.h Fixed: unistd.h Fixed: wchar.h */sys/getppdp.h /usr/share/src/gcc_trunk/fixincludes/tests/base/ia64/sys/getppdp.h differ: char 98, line 5 *** */sys/getppdp.h Mon Jan 5 05:03:21 2009 --- /usr/share/src/gcc_trunk/fixincludes/tests/base/ia64/sys/getppdp.h Thu Jan 1 14:09:22 2009 *** *** 2,8 It has been auto-edited by fixincludes from: ! fixinc/tests/inc/*/sys/getppdp.h This had to be done to correct non-standard usages in the original, manufacturer supplied header file. */ --- 2,8 It has been auto-edited by fixincludes from: ! fixinc/tests/inc/ia64/sys/getppdp.h This had to be done to correct non-standard usages in the original, manufacturer supplied header file. */ Newly fixed header: locale.h Newly fixed header: stdarg.h Missing header fix: ia64/sys/getppdp.h There were fixinclude test FAILURES gmake[2]: [check] Error 1 (ignored) gmake[2]: Leaving directory `/usr/share/src/gcc_build/fixincludes' gmake[2]: Entering directory `/usr/share/src/gcc_build/gcc' Making a new config file... echo set tmpdir /usr/share/src/gcc_build/gcc/testsuite ./tmp0 gmake[3]: Entering directory `/usr/share/src/gcc_build/gcc' # slocate sys/getppdp.h /usr/share/src/gcc_trunk/fixincludes/tests/base/ia64/sys/getppdp.h /usr/share/src/gcc_build/fixincludes/tests/res/*/sys/getppdp.h /usr/share/src/gcc_build/fixincludes/tests/inc/*/sys/getppdp.h I don't know why the scripts created the * directories in: /usr/share/src/gcc_build/fixincludes/tests/???/x . # ls -l /usr/share/src/gcc_build/fixincludes/tests/res/ | head -3 total 174 drwxr-xr-x 3 root root 3 Jan 5 05:03 * drwxr-xr-x 2 root root 4 Jan 5 05:03 ansi There must be a better choice for the directory name, other than * ? Rob -- Summary: gcc 4.4.0 20090104 - make -i check autogen fixinclude test FAILURES Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal 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=38727
[Bug bootstrap/38728] New: gcc 4.4.0 20090104 - make install is relinking `libgij.la'
Nearly all the libraries (and all executables) can be installed by typing
make install, except for libgij which seems to require relinking.
# make install
...
libtool: install: /usr/bin/ginstall -c .libs/libjvm.soT
/usr/local/lib/amd64/gcj-4.4.0-10/libjvm.so
libtool: install: chmod +x /usr/local/lib/amd64/gcj-4.4.0-10/libjvm.so
libtool: install: /usr/bin/ginstall -c .libs/libjvm.lai
/usr/local/lib/amd64/gcj-4.4.0-10/libjvm.la
--
Libraries have been installed in:
/usr/local/lib/amd64/gcj-4.4.0-10
...
libtool: install: (cd /usr/local/lib/amd64 { ln -s -f libgcj.so.10.0.0
libgcj.so || { rm -f libgcj.so ln -s libgcj.so.10.0.0 libgcj.so; }; })
libtool: install: chmod +x /usr/local/lib/amd64/libgcj.so.10.0.0
libtool: install: /usr/bin/ginstall -c .libs/libgcj.lai
/usr/local/lib/amd64/libgcj.la
--
Libraries have been installed in:
/usr/local/lib/amd64
...
See any operating system documentation about shared libraries for
more information, such as the ld(1) and ld.so(8) manual pages.
--
/bin/sh ./libtool --mode=install /usr/bin/ginstall -c 'libgij.la'
'/usr/local/lib/amd64/libgij.la'
libtool: install: warning: relinking `libgij.la'
libtool: install: (cd
/usr/share/src/gcc_build/i386-pc-solaris2.11/amd64/libjava; /bin/sh
/usr/share/src/gcc_build/i386-pc-solaris2.11/amd64/libjava/libtool --tag CXX
--mode=relink /usr/share/src/gcc_build/./gcc/xgcc ...
...
/usr/lib/amd64/crtn.o -m64 -m64 -m64 -Wl,-Bsymbolic-functions -Wl,-soname
-Wl,libgij.so.10 -o .libs/libgij.so.10.0.0
libtool: install: /usr/bin/ginstall -c .libs/libgij.so.10.0.0T
/usr/local/lib/amd64/libgij.so.10.0.0
libtool: install: (cd /usr/local/lib/amd64 { ln -s -f libgij.so.10.0.0
libgij.so.10 || { rm -f libgij.so.10 ln -s libgij.so.10.0.0 libgij.so.10; };
})
libtool: install: (cd /usr/local/lib/amd64 { ln -s -f libgij.so.10.0.0
libgij.so || { rm -f libgij.so ln -s libgij.so.10.0.0 libgij.so; }; })
libtool: install: chmod +x /usr/local/lib/amd64/libgij.so.10.0.0
libtool: install: /usr/bin/ginstall -c .libs/libgij.lai
/usr/local/lib/amd64/libgij.la
--
Libraries have been installed in:
/usr/local/lib/amd64
...
This 'relinking' occurs for both /usr/local/lib/libgij* and
/usr/local/lib/amd64/libgij*.
Thanks,
Rob
--
Summary: gcc 4.4.0 20090104 - make install is relinking
`libgij.la'
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
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=38728
[Bug libgcj/24403] --enable-java-awt=qt fails to build
--- Comment #17 from rob1weld at aol dot com 2009-01-05 22:58 --- (In reply to comment #16) ping... This missed 4.3 again, it should probably get in now before 4.4 enters freeze mode... How about 4.5 ? Re the moc - moc-qt4 change suggested in comment #14: This should be detected by the configure script, moc-qt4 is a nonstandard way some distributions use to tell moc 3.x apart from moc 4.x, other candidates for the correct moc include moc4 and simply launching moc from a different path (/usr/lib/qt4/bin/moc) if the default moc is from 3.x a nonstandard way some distributions... I was using GNU/Linux with GNU's gcc - nonstandard or The Standard. There are no Docs for having both QT3 _and_ QT4 but it is permissible. Read these Docs here: http://doc.trolltech.com/4.4/moc.html -- use -v to check that the moc you found (on path, and check the usual directories too) is for QT4 and not QT3. On OpenSolaris 2008.11 Qt4 is using this to check the version: # /usr/local/Trolltech/Qt-4.4.3/bin/moc -v Qt Meta Object Compiler version 59 (Qt 4.4.3) Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24403
[Bug libmudflap/38738] New: gcc 4.4.0 20090104 - OpenSolaris can enable libmudflaps (if gcc is configured to use GNU ld)
Enable mudflaps for Solaris _IF_ gcc is configured to use GNU's ld . Here is the final result: # make check ... === libmudflap Summary === # of expected passes1131 # of unexpected failures293 I am running i386-pc-solaris2.11 (OpenSolaris 2008.11) and configured the trunk like this: # /usr/local/bin/gcc -v Using built-in specs. Target: i386-pc-solaris2.11 Configured with: ../gcc_trunk/configure --enable-languages=ada,c,c++,fortran,java,objc,obj-c++ --enable-shared --disable-static --enable-decimal-float --enable-nls --without-system-libunwind --with-gnu-as --with-as=/usr/local/bin/as --with-gnu-ld --with-ld=/usr/local/bin/ld Thread model: posix gcc version 4.4.0 20090104 (experimental) (GCC) # /usr/local/bin/ld -v GNU ld (GNU Binutils) 2.19 # /usr/local/bin/as -v GNU assembler version 2.19 (i386-pc-solaris2.11) using BFD version (GNU Binutils) 2.19 I modified gcc_build/i386-pc-solaris2.11/libmudflap/Makefile to add -lsocket to LIBS which allows most of the tests to work. This was not necessary for any other testsuites, they worked as-is. # LIBS = -ldl LIBS = -ldl -lsocket Some of the unexpected failures are simple compilation errors in the tests which, when fixed, will likely become expected passes. Example: ... output is: /usr/share/src/gcc_trunk/libmudflap/testsuite/libmudflap.c/pass47-frag.c:10: warning: mudflap cannot track unknown size extern '__ctype' _or_ Excess errors: /usr/share/src/gcc_trunk/libmudflap/testsuite/libmudflap.c/pass-stratcliff.c:261: error: invalid operands to binary - (have 'int' and 'char *') /usr/share/src/gcc_trunk/libmudflap/testsuite/libmudflap.c/pass-stratcliff.c:281: error: invalid operands to binary - (have 'int' and 'char *') /usr/share/src/gcc_trunk/libmudflap/testsuite/libmudflap.c/pass-stratcliff.c:309: warning: comparison between pointer and integer ... A few of the unexpected failures are only in the execution test and are the result of a Segmentation Fault. For the most part it is working. The root configure script needs to be modified to allow mudflaps on this platform _IF_ gcc is configured to use GNU ld (usually it does not) and there needs a bit of fixing in the Makefile of libmudflap's testsuite. Thanks, Rob -- Summary: gcc 4.4.0 20090104 - OpenSolaris can enable libmudflaps (if gcc is configured to use GNU ld) Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: libmudflap 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=38738
