[Bug libstdc++/37522] New: [4.4 regression] Incorrect vswprintf prototype breaks __to_xstring
When attempting a bootstrap including libstdc++-v3, the following error will be encountered. libtool: compile: /mingw/src/gccf/./gcc/xgcc -shared-libgcc -B/mingw/src/gccf/./gcc -nostdinc++ -L/mingw/src/gccf/i386-pc-mingw32/libstdc++-v3/src -L/mingw/src/gccf/i386-pc-mingw32/libstdc++-v3/src/.libs -L/mingw/src/gccf/i386-pc-mingw32/winsup/mingw -L/mingw/src/gccf/i386-pc-mingw32/winsup/w32api/lib -isystem /mingw/src/svn/winsup/mingw/include -isystem /mingw/src/svn/winsup/w32api/include -B/mingw/i386-pc-mingw32/bin/ -B/mingw/i386-pc-mingw32/lib/ -isystem /mingw/i386-pc-mingw32/include -isystem /mingw/i386-pc-mingw32/sys-include -I/mingw/src/gccf/i386-pc-mingw32/libstdc++-v3/include/i386-pc-mingw32 -I/mingw/src/gccf/i386-pc-mingw32/libstdc++-v3/include -I/mingw/src/svn/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -g -O2 -std=gnu++0x -c ../../../../svn/libstdc++-v3/src/functexcept.cc -DDLL_EXPORT -DPIC -o .libs/functexcept.o In file included from /mingw/src/gccf/i386-pc-mingw32/libstdc++-v3/include/string:58, from /mingw/src/gccf/i386-pc-mingw32/libstdc++-v3/include/stdexcept:44, from ../../../../svn/libstdc++-v3/src/functexcept.cc:31: /mingw/src/gccf/i386-pc-mingw32/libstdc++-v3/include/bits/basic_string.h: In function 'std::wstring std::to_wstring(long long int)': /mingw/src/gccf/i386-pc-mingw32/libstdc++-v3/include/bits/basic_string.h:2675: error: no matching function for call to '__to_xstring(int (*)(wchar_t*, const wchar_t*, char*), unsigned int, const wchar_t [5], long long int)' /mingw/src/gccf/i386-pc-mingw32/libstdc++-v3/include/bits/basic_string.h: In function 'std::wstring std::to_wstring(long long unsigned int)': /mingw/src/gccf/i386-pc-mingw32/libstdc++-v3/include/bits/basic_string.h:2681: error: no matching function for call to '__to_xstring(int (*)(wchar_t*, const wchar_t*, char*), unsigned int, const wchar_t [5], long long unsigned int)' /mingw/src/gccf/i386-pc-mingw32/libstdc++-v3/include/bits/basic_string.h: In function 'std::wstring std::to_wstring(long double)': /mingw/src/gccf/i386-pc-mingw32/libstdc++-v3/include/bits/basic_string.h:2689: error: no matching function for call to '__to_xstring(int (*)(wchar_t*, const wchar_t*, char*), const int, const wchar_t [4], long double)' make[4]: *** [functexcept.lo] Error 1 The problem is that MSVCRT's prototype for vswprintf is incorrect, and differs from the standard C version. This may not be easy to fix in mingwrt. However, the _vsnwprintf function has the correct prototype and works with __to_xstring. I guess the solution is to make libstdc++ use _vsnwprintf instead of vswprintf on *-mingw32. -- Summary: [4.4 regression] Incorrect vswprintf prototype breaks __to_xstring Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: build Severity: major Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: aaronavay62 at aaronwl dot com GCC target triplet: *-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37522
[Bug libstdc++/37522] [4.4 regression] Incorrect vswprintf prototype breaks __to_xstring
-- aaronavay62 at aaronwl dot com changed: What|Removed |Added CC||dannysmith at users dot ||sourceforge dot net OtherBugsDependingO||36216 nThis|| AssignedTo|unassigned at gcc dot gnu |aaronavay62 at aaronwl dot |dot org |com Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Known to fail||4.4.0 Known to work||4.3.2 Last reconfirmed|-00-00 00:00:00 |2008-09-14 23:27:34 date|| Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37522
[Bug bootstrap/25502] I64d format Werror problem in build
--- Comment #20 from aaronavay62 at aaronwl dot com 2008-09-14 03:27 --- Danny has recommended that we wait until 4.5 to add -Wno-pedantic-ms-format which will resolve this problem. http://gcc.gnu.org/ml/gcc-patches/2008-09/msg00664.html. In the meantime, I'll keep the patch at http://gcc.gnu.org/ml/gcc-patches/2008-09/msg00594.html in my tree to allow bootstraps from trunk to work without using --disable-werror. It's important we keep keep using -Werror so that more problems don't creep into Windows-specific code, whether they're bona fide bugs or just false positives. (Previously, I was adding __extension__ to each the site of each printf to allow the build to work.) Anyway, this shouldn't affect 4.4.x release builds, for which --disable-werror is the default. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25502
[Bug tree-optimization/36218] [4.2/4.3/4.4 regression] VRP causes stack overflow while building libgcj
--- Comment #16 from aaronavay62 at aaronwl dot com 2008-08-23 18:06 --- (In reply to comment #15) This should be fixed on the trunk by 2008-08-20 Richard Guenther [EMAIL PROTECTED] can someone verify this? Thanks. Yes and no. On revision 139510 (2008-08-23), the compilation of cipher.lo is successful in a normal build, so I presume that the VRP problem has been fixed. Yay! However, there is a new (since April 2008) stack overflow now in HTML_401F.lo. This one does not seem to be VRP-related, as -fno-tree-vrp does not seem to help. It does, however, compile with -O0. Here is the backtrace: #0 0x00a61805 in htab_find_slot_with_hash (htab=0x5745038, element=0x83060, hash=13718576, insert=INSERT) at ../../svn/libiberty/hashtab.c:610 #1 0x00a61a82 in htab_find_slot (htab=0x5745038, element=0x83060, insert=INSERT) at ../../svn/libiberty/hashtab.c:678 #2 0x0076562a in set_livein_block (var=0x68aa180, bb=0x54c3dc0) at ../../svn/gcc/tree-into-ssa.c:503 #3 0x00766ae1 in prepare_block_for_update (bb=0x54c3dc0, insert_phi_p=1 '\001') at ../../svn/gcc/tree-into-ssa.c:2364 #4 0x00766cf0 in prepare_block_for_update (bb=0x54c3d00, insert_phi_p=1 '\001') at ../../svn/gcc/tree-into-ssa.c:2450 #5 0x00766cf0 in prepare_block_for_update (bb=0x54c3c00, insert_phi_p=1 '\001') at ../../svn/gcc/tree-into-ssa.c:2450 ... #10851 0x00766cf0 in prepare_block_for_update (bb=0x4f63600, insert_phi_p=1 '\001') at ../../svn/gcc/tree-into-ssa.c:2450 #10852 0x00766cf0 in prepare_block_for_update (bb=0x4f63580, insert_phi_p=1 '\001') at ../../svn/gcc/tree-into-ssa.c:2450 #10853 0x00766cf0 in prepare_block_for_update (bb=0x4f63500, insert_phi_p=1 '\001') at ../../svn/gcc/tree-into-ssa.c:2450 #10854 0x00769e62 in update_ssa (update_flags=2048) at ../../svn/gcc/tree-into-ssa.c:3230 #10855 0x00762164 in compute_may_aliases () at ../../svn/gcc/tree-ssa-alias.c:1842 #10856 0x0052644d in execute_function_todo (data=0x11) at ../../svn/gcc/passes.c:943 #10857 0x005265a0 in do_per_function ( callback=0x52629c execute_function_todo, data=0x11) at ../../svn/gcc/passes.c:837 #10858 0x00526670 in execute_todo (flags=1048577) at ../../svn/gcc/passes.c:1021 #10859 0x00526954 in execute_one_pass (pass=0xb05150) at ../../svn/gcc/passes.c:1297 #10860 0x00526b48 in execute_pass_list (pass=0xb05150) at ../../svn/gcc/passes.c:1323 #10861 0x00526b5b in execute_pass_list (pass=0xb04f10) at ../../svn/gcc/passes.c:1324 #10862 0x00759fb0 in tree_rest_of_compilation (fndecl=0x28c6c80) at ../../svn/gcc/tree-optimize.c:418 #10863 0x0058796f in cgraph_expand_function (node=0x47acc80) at ../../svn/gcc/cgraphunit.c:1039 #10864 0x0058968a in cgraph_optimize () at ../../svn/gcc/cgraphunit.c:1101 #10865 0x00443615 in java_parse_file (set_yydebug=0) at ../../svn/gcc/java/jcf-parse.c:1961 #10866 0x0047907d in toplev_main (argc=32, argv=0x31934e8) at ../../svn/gcc/toplev.c:959 #10867 0x0040124b in __mingw_CRTStartup () #10868 0x00401298 in mainCRTStartup () Should I open a new PR for this different stack overflow, and close this one? I still have not had a chance to see why Joseph's change to LDFLAGS to make MinGW use the same stack allocation as Linux when building GCC does not propagate into libjava. Once that is fixed, this entire catagory of MinGW-specific problems should go away. So alternately we could close this one, and open a new one just for the LDFLAGS issue. -- aaronavay62 at aaronwl dot com changed: What|Removed |Added Last reconfirmed|2008-07-14 08:03:23 |2008-08-23 18:06:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36218
[Bug bootstrap/25502] I64d format Werror problem in build
--- Comment #19 from aaronavay62 at aaronwl dot com 2008-08-24 01:17 --- Kai, I'm assigning this to you because you said on IRC a month or two ago that you were working on a patch for this. I've been working around this with a local patch that adds __extension__ everywhere that needs it. -- aaronavay62 at aaronwl dot com changed: What|Removed |Added AssignedTo|aaronavay62 at aaronwl dot |ktietz at gcc dot gnu dot |com |org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25502
[Bug bootstrap/37091] Rev 138207 causes ICE using bootstrap for crt for win64
--- Comment #3 from aaronavay62 at aaronwl dot com 2008-08-12 05:02 --- This failure comes up whenever GCC 3.4.x is used to build GCC 4.4 on Windows. I'm not sure if it affects any non-Windows targets. -- aaronavay62 at aaronwl dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|i686-pc-cygwin |*-mingw*, *-cygwin GCC host triplet|i686-pc-cygwin | GCC target triplet|x86_64-pc-mingw32 |*-mingw*, *-cygwin Last reconfirmed|-00-00 00:00:00 |2008-08-12 05:02:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37091
[Bug bootstrap/37091] Rev 138207 causes ICE using bootstrap for crt for win64
--- Comment #4 from aaronavay62 at aaronwl dot com 2008-08-12 05:04 --- To clarify, GCC 3.4.x miscompiles GCC 4.4 when not being bootstrapped. A normal bootstrap won't show this failure, but a cross build or --disable-bootstrap will. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37091
[Bug other/36968] [4.4 regression] malloc corruption building jv-convert.exe
--- Comment #2 from aaronavay62 at aaronwl dot com 2008-08-11 00:22 --- Fixed. -- aaronavay62 at aaronwl dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36968
[Bug driver/36968] [4.4 regression] malloc corruption building jv-convert.exe
--- Comment #1 from aaronavay62 at aaronwl dot com 2008-07-31 22:59 --- Created an attachment (id=15987) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15987action=view) Allocate argv array first -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36968
[Bug ada/36207] [4.4 regression] Ada bootstrap fails in uintp.adb:1595
--- Comment #13 from aaronavay62 at aaronwl dot com 2008-07-29 19:43 --- Eric, this failure seems to be fixed now on trunk. Thanks! Ada is back in business now on mingw32, modulo some Makefile.in problems which I'm fixing now. -- aaronavay62 at aaronwl dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36207
[Bug driver/36968] New: [4.4 regression] malloc corruption building jv-convert.exe
When bootstrapping: /bin/sh ./libtool --tag=GCJ --mode=link /mingw/src/gccf/gcc/gcj -B/mingw/src/gcc f/i386-pc-mingw32/libjava/ -B/mingw/src/gccf/gcc/ -L/mingw/src/gccf/i386-pc-ming w32/libjava -ffloat-store -fomit-frame-pointer -Usun -fno-omit-frame-pointer -g -O2 -o jv-convert.exe --main=gnu.gcj.convert.Convert -rpath /mingw/lib/gcc/i386 -pc-mingw32/4.4.0 -shared-libgcc -L/mingw/src/gccf/i386-pc-mingw32/libjava/.l ibs libgcj.la libtool: link: /mingw/src/gccf/gcc/gcj -B/mingw/src/gccf/i386-pc-mingw32/libjava / -B/mingw/src/gccf/gcc/ -ffloat-store -fomit-frame-pointer -Usun -fno-omit-fram e-pointer -g -O2 -o .libs/jv-convert.exe --main=gnu.gcj.convert.Convert -shared- libgcc -L/mingw/src/gccf/i386-pc-mingw32/libjava/.libs -L/mingw/src/gccf/i386-p c-mingw32/libjava ./.libs/libgcj.a -L/mingw/lib/gcc/i386-pc-mingw32/4.4.0 gcj.exe: out of memory allocating 160 bytes make[3]: *** [jv-convert.exe] Error 1 With mpatrol, we can isolate the actual bug: MPATROL_OPTIONS='PAGEALLOC=LOWER' gdb /mingw/src/gccf/gcc/gcj (gdb) set args -B/mingw/src/gccf/i386-pc-mingw32/libjava/ -B/mingw/src/gccf/gcc/ -ffloat-store -fomit-frame-pointer -Usun -fno-omit-frame-pointer -g -O2 -o .libs/jv-convert.exe --main=gnu.gcj.convert.Convert -shared-libgcc -L/mingw/src/gccf/i386-pc-mingw32/libjava/.libs -L/mingw/src/gccf/i386-pc-mingw32/libjava ./.libs/libgcj.a -L/mingw/lib/gcc/i386-pc-mingw32/4.4.0 (gdb) run Program received signal SIGSEGV, Segmentation fault. 0x00414ed8 in spawn_script (executable=0x36a7000 /mingw/src/gccf/gcc/as, argv=0x12a3ffc, env=0x0, dwCreationFlags=0, si=0x27fb60, pi=0x27fb50) at ../../svn/libiberty/pex-win32.c:654 654 *avhere = executable1; (gdb) bt #0 0x00414ed8 in spawn_script ( executable=0x36a7000 /mingw/src/gccf/gcc/as, argv=0x12a3ffc, env=0x0, dwCreationFlags=0, si=0x27fb60, pi=0x27fb50) at ../../svn/libiberty/pex-win32.c:654 #1 0x00415113 in pex_win32_exec_child (obj=0x36aa000, flags=1, executable=0x36a7000 /mingw/src/gccf/gcc/as, argv=0x12a4000, env=0x0, in=0, out=1, errdes=2, toclose=-1, errmsg=0x27fcc8, err=0x27fdb4) at ../../svn/libiberty/pex-win32.c:784 #2 0x0041cc55 in pex_run_in_environment (obj=0x36aa000, flags=value optimized out, executable=0x36a7000 /mingw/src/gccf/gcc/as, argv=0x12a4000, env=0x0, orig_outname=0x0, errname=0x0, err=0x27fdb4) at ../../svn/libiberty/pex-common.c:342 #3 0x0041ce3f in pex_run (obj=0x36aa000, flags=1, executable=0x36a7000 /mingw/src/gccf/gcc/as, argv=0x12a4000, orig_outname=0x0, errname=0x0, err=0x27fdb4) at ../../svn/libiberty/pex-common.c:372 #4 0x004040cb in execute () at ../../svn/gcc/gcc.c:3005 #5 0x0040d0be in lang_specific_pre_link () at ../../svn/gcc/java/jvspec.c:673 #6 0x0040c42c in main (argc=1852400220, argv=0x68735c) at ../../svn/gcc/gcc.c:6825 The problem is clearly on pex-win32.c:646: const char ** avhere = (const char **) --argv; Then we hit the fault a few statements down at 654: *avhere = executable1; This is writing at (argv-1) which overrides the heap block header and causes the corruption. I'm going to look at this more tomorrow and see if I can figure out why its doing this. I'm a little curious how this code has been like this since 2005 without ever causing trouble before. -- Summary: [4.4 regression] malloc corruption building jv- convert.exe Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: driver AssignedTo: aaronavay62 at aaronwl dot com ReportedBy: aaronavay62 at aaronwl dot com GCC host triplet: i386-pc-mingw32 OtherBugsDependingO 36216 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36968
[Bug driver/36968] [4.4 regression] malloc corruption building jv-convert.exe
-- aaronavay62 at aaronwl dot com changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-07-30 02:17:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36968
[Bug tree-optimization/36218] [4.2/4.3/4.4 regression] VRP causes stack overflow while building libgcj
--- Comment #13 from aaronavay62 at aaronwl dot com 2008-07-14 08:03 --- Joseph's patch doesn't work for me, because the --stack parameter never makes it to the link line for some reason, and I get the same crash building cipher.o. This is the relevant output of bootstrap: rm -f jc1.exe /mingw/src/gccf/./prev-gcc/xgcc -B/mingw/src/gccf/./prev-gcc/ -B/mingw/i386-pc-mingw32/bin/ -g -O2 -D__USE_MINGW_ACCESS -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition -Wc++-compat -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE _CONFIG_H -o jc1.exe \ java/class.o java/decl.o java/expr.o java/constants.o java/lang.o java/typeck.o java/except.o java/verify-glue.o java/verify-impl.o java/zextract.o java/jcf-io.o java/win32-host.o java/jcf-parse.o java/mangle.o java/mangle_name.o java/builtins.o java/resource.o java/jcf-depend.o java/jcf-path.o java/boehm.o java/java-gimplify.o main.o tree-browser.o libbackend.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a -L../zlib -lz ../libcpp/libcpp.a ./../intl/libintl.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a attribs.o -L/mingw/src/gmp-mpfr/root/lib -L/mingw/src/gmp-mpfr/root/lib -lmpfr -lgmp I don't know if there is something particular to the way I've configured that might be making this break for me. As an additional data point, for some reason when I tried overriding LDFLAGS previously, the stack parameter also did not propagate properly to jc1.exe, although it propagated just fine to some of the other link lines outside of Java. ../svn/configure --enable-languages=c,c++,fortran,java,objc,obj-c++ --disable-sjlj-exceptions --enable-libgcj --enable-libgomp --with-dwarf2 --disable-win32-registry --enable-libstdcxx-debug --enable-concept-checks --enable-version-specific-runtime-libs --prefix=/mingw --with-gmp=/mingw/src/gmp-mpfr/root --with-mpfr=/mingw/src/gmp-mpfr/root --with-libiconv-prefix=/mingw/src/libiconv/root make -- aaronavay62 at aaronwl dot com changed: What|Removed |Added Last reconfirmed|2008-06-11 10:50:09 |2008-07-14 08:03:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36218
[Bug ada/36207] [4.4 regression] Ada bootstrap fails in uintp.adb:1595
--- Comment #8 from aaronavay62 at aaronwl dot com 2008-07-14 08:57 --- Eric, with that change, I see this: ../../../svn/libgcc/../gcc/libgcc2.c: In function '__do_global_ctors': ../../../svn/libgcc/../gcc/libgcc2.c:2161: internal compiler error: in i386_pe_binds_local_p, at config/i386/winnt.c:337 debug_tree(exp) var_decl 04C036E0 __CTOR_LIST__ type array_type 04C0EC98 type pointer_type 04C0EC30 func_ptr type function_type 03CC4888 public unsigned SI size integer_cst 03C987C0 constant 32 unit size integer_cst 03C98560 constant 4 align 32 symtab 79753888 alias set -1 canonical type 041F5D68 pointer_to_this pointer_type 04C0ED00 BLK align 32 symtab 0 alias set -1 canonical type 04C0EDD0 pointer_to_this pointer_type 04C12270 addressable used public external common BLK file ../../../svn/libgcc/../gcc/ gbl-ctors.h line 48 col 17 align 32 (mem/s/c:BLK (symbol_ref:SI (__CTOR_LIST__) var_decl 04C036E0 __CTOR_LIST __) [2 __CTOR_LIST__+0 A32]) chain var_decl 04C03738 __DTOR_LIST__ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36207
[Bug ada/36207] [4.4 regression] Ada bootstrap fails in uintp.adb:1595
--- Comment #10 from aaronavay62 at aaronwl dot com 2008-07-14 14:38 --- (In reply to comment #9) gcc_assert (!(TREE_CODE (exp) == VAR_DECL TREE_STATIC (exp) DECL_EXTERNAL (exp))); Eric, OK, now I get: /mingw/src/gccada/./prev-gcc/xgcc -B/mingw/src/gccada/./prev-gcc/ -B/mingw/i386-pc-mingw32/bin/ -c -g -O2 -D__USE_MINGW_ACCESS -gnatpg -gnata -gnatwns -g -O1 -fno-inline \ -nostdinc -I- -I. -Iada -I../../svn/gcc/ada ../../svn/gcc/ada/a-except.adb -o ada/a-except.o +===GNAT BUG DETECTED==+ | 4.4.0 20080713 (experimental) (i386-pc-mingw32) GCC error: | | in i386_pe_binds_local_p, at config/i386/winnt.c:339 | | Error detected around ../../svn/gcc/ada\a-exexda.adb:647 | ... raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:424 debug_tree(exp) var_decl 03D11D68 system__soft_links__get_current_excep type pointer_type 03D142D8 system__soft_links__get_eoa_call type function_type 03D141A0 system__soft_links__T10s type pointer_type 038E5A90 ada__exceptions__exception_occurrence_access sizes-gimplified asm_written visited QI size integer_cst 000C8520 constant 8 unit size integer_cst 000C8540 constant 1 align 8 symtab 64062056 alias set -1 canonical type 03D141A0 arg-types tree_list 03D16DC0 value void_type 000DA7B8 void pointer_to_this pointer_type 03D142D8 system__soft_links__get_eoa_call sizes-gimplified visited unsigned SI size integer_cst 000C86E0 constant 32 unit size integer_cst 000C8480 constant 4 align 32 symtab 64062280 alias set -1 canonical type 03D142D8 side-effects addressable volatile public static unsigned external SI file ../../svn/gcc/ada\s-soflin.ads line 255 col 4 size integer_cst 000C86E0 32 unit size integer_cst 000C8480 4 align 32 (mem/v/f/c/i:SI (symbol_ref:SI (system__soft_links__get_current_excep) var_decl 03D11D68 system__soft_links__get_current_excep) [0 system__soft_links__get_current_excep+0 S4 A32]) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36207
[Bug tree-optimization/36218] [4.2/4.3/4.4 regression] VRP causes stack overflow while building libgcj
--- Comment #12 from aaronavay62 at aaronwl dot com 2008-06-14 15:43 --- (In reply to comment #9) There aren't any obvious instructions on how to reproduce this bug. Andrew, which file(s) in libgcj do you see problems with? If you build libjava on a Win32 (mingw32 or Cygwin) target without altering ld's default stack reserve, cipher.o will fail to build with a stack overflow. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36218
[Bug bootstrap/36216] [meta-bug] Bootstrap problems on mingw32
-- aaronavay62 at aaronwl dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-06-03 19:30:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36216
[Bug ada/36207] [4.4 regression] Ada bootstrap fails in uintp.adb:1595
--- Comment #5 from aaronavay62 at aaronwl dot com 2008-06-03 19:32 --- Apparently not related to PR35493, because its still present. I'll give debugging this another shot later. -- aaronavay62 at aaronwl dot com changed: What|Removed |Added Last reconfirmed|2008-05-13 13:50:21 |2008-06-03 19:32:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36207
[Bug ada/36207] [4.4 regression] Ada bootstrap fails in uintp.adb:1595
--- Comment #3 from aaronavay62 at aaronwl dot com 2008-05-13 13:50 --- Here is the information. I included the stage1 compiler as well just for comparison purposes. For some reason, the source line information is missing from both, but I suspect thats not very important. Unfortunately, I don't see anything wrong here, so I'm not quite sure how to proceed. stage1 0014 _get_target_char_size: 14: 55 push %ebp 15: 89 e5 mov%esp,%ebp 17: b8 08 00 00 00 mov$0x8,%eax 1c: 5d pop%ebp 1d: c3 ret _ttypes___elabs: 0: 55 push %ebp 1: 89 e5 mov%esp,%ebp 3: 83 ec 08sub$0x8,%esp 6: e8 00 00 00 00 call b _ttypes___elabs+0xb 7: DISP32 _get_target_char_size b: a3 00 00 00 00 mov%eax,0x0 c: dir32.bss 10: a1 00 00 00 00 mov0x0,%eax 11: dir32 .bss 15: 89 04 24mov%eax,(%esp) 18: e8 00 00 00 00 call 1d _ttypes___elabs+0x1d stage2 0018 _get_target_char_size: 18: 55 push %ebp 19: 89 e5 mov%esp,%ebp 1b: b8 08 00 00 00 mov$0x8,%eax 20: c9 leave 21: c3 ret 22: 66 90 xchg %ax,%ax _ttypes___elabs: 0: 55 push %ebp 1: 89 e5 mov%esp,%ebp 3: 83 ec 08sub$0x8,%esp 6: e8 00 00 00 00 call b _ttypes___elabs+0xb 7: DISP32 _get_target_char_size b: a3 00 00 00 00 mov%eax,0x0 c: dir32.bss 10: 89 04 24mov%eax,(%esp) 13: e8 00 00 00 00 call 18 _ttypes___elabs+0x18 -- aaronavay62 at aaronwl dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-05-13 13:50:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36207
[Bug ada/36207] [4.4 regression] Ada bootstrap fails in uintp.adb:1595
-- aaronavay62 at aaronwl dot com changed: What|Removed |Added Severity|major |critical http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36207
[Bug fortran/36215] [4.4 regression] Fortran bootstrap fails on _abs_c4.F90
-- aaronavay62 at aaronwl dot com changed: What|Removed |Added Severity|major |critical http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36215
[Bug libgcj/36218] New: [4.4 regression] libgcj causes stack overflow in jc1.exe
Several files in libgcj will cause jc1.exe to exhaust its stack space allocation. This can be worked around by compiling jc1.exe with -Wl,--stack,0x200, which can be accomplished by including it in LDFLAGS when compiling. (This exact size is arbitrary; it's big enough to work, but perhaps much too big.) The cause seems to be massive recursion between find_assert_locations() and find_conditional_asserts(). I'm not sure if this is intended behavior. If this is intended behavior, it's not clear to me what the right thing to do to fix this is. What negative consequences does increasing the default allocation have? Is it possible to adjust this limit at runtime, perhaps as needed? -- Summary: [4.4 regression] libgcj causes stack overflow in jc1.exe Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: build, memory-hog Severity: critical Priority: P3 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: aaronavay62 at aaronwl dot com GCC host triplet: i386-pc-mingw32 OtherBugsDependingO 36216 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36218
[Bug libgcj/36218] [4.4 regression] libgcj causes stack overflow in jc1.exe
--- Comment #1 from aaronavay62 at aaronwl dot com 2008-05-12 11:03 --- cipher.o at least fails for this reason. I'm not sure when this last worked, but it at least worked sometime around 2004. -- aaronavay62 at aaronwl dot com changed: What|Removed |Added Known to fail||4.4.0 4.3.0 4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36218
[Bug ada/36207] New: [4.4 regression] Ada bootstrap fails in uintp.adb:1595
The type size seems to be getting set to zero when calling Build_Signed_Integer_Type in cstand.adb. It's possible that the stage2 gnat has been miscompiled. /mingw/src/gccsvn/obj/./prev-gcc/xgcc -B/mingw/src/gccsvn/obj/./prev-gcc/ -B/mingw/i386-pc-mingw32/bin/ -c -g -O2 -D__USE_MINGW_ACCESS -gnatpg -gnata -gnatws -nostdinc -I- -I. -Iada -I../../svn/gcc/ada ../../svn/gcc/ada/ada.ads -o ada/ada.o -v -save-temps Reading specs from /mingw/src/gccsvn/obj/./prev-gcc/specs Target: i386-pc-mingw32 Configured with: ../svn/configure --enable-languages=c,ada,c++,fortran,java,objc,obj-c++ --disable-sjlj-exceptions --enable-libgcj --enable-libgomp --with-dwarf2 --disable-win32-registry --enable-libstdcxx-debug --enable-concept-checks --enable-version-specific-runtime-libs --prefix=/mingw --with-gmp=/mingw/src/gcc/gmp-mpfr-root --with-mpfr=/mingw/src/gcc/gmp-mpfr-root --with-libiconv-prefix=/mingw/src/gcc/libiconv-root Thread model: win32 gcc version 4.4.0 20080510 (experimental) (GCC) COLLECT_GCC_OPTIONS='-B/mingw/src/gccsvn/obj/./prev-gcc/' '-B/mingw/i386-pc-mingw32/bin/' '-c' '-g' '-O2' '-D__USE_MINGW_ACCESS' '-gnatpg' '-gnata' '-gnatws' '-nostdinc' '-I-' '-I.' '-Iada' '-I../../svn/gcc/ada' '-o' 'ada/ada.o' '-v' '-save-temps' '-mtune=i386' /mingw/src/gccsvn/obj/./prev-gcc/gnat1.exe -I- -I. -Iada -I../../svn/gcc/ada -quiet -nostdinc -dumpbase ada.ads -O2 -g -gnatpg -gnata -gnatws -mtune=i386 -gnatO ada/ada.o ../../svn/gcc/ada/ada.ads -o ada.s +===GNAT BUG DETECTED==+ | 4.4.0 20080510 (experimental) (i386-pc-mingw32) Assert_Failure uintp.adb:1595| | No source file position information available| | 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). | +==+ (gdb) run Starting program: /mingw/src/gccsvn/obj/./prev-gcc/gnat1.exe -I- -I. -Iada -I../../svn/gcc/ada -quiet -nostdinc -dumpbase ada.ads -O2 -g -gnatpg -gnata -gnatws -mtune=i386 -gnatO ada/ada.o ../../svn/gcc/ada/ada.ads -o ada.s [New thread 1908.0x11bc] Breakpoint 5, uintp.ui_expon (left=600032770, right=600032767) at ../../svn/gcc/ada/uintp.adb:1595 1595 pragma Assert (Right = Uint_0); (gdb) print Right $7 = 600032767 (gdb) print Uint_0 $8 = 600032768 (gdb) bt #0 uintp.ui_expon (left=600032770, right=600032767) at ../../svn/gcc/ada/uintp.adb:1595 #1 0x00497451 in cstand.build_signed_integer_type (e=17, siz=0) at ../../svn/gcc/ada/cstand.adb:160 #2 0x00498917 in cstand.create_standard () at ../../svn/gcc/ada/cstand.adb:473 #3 0x005556d5 in frontend () at ../../svn/gcc/ada/frontend.adb:88 #4 0x006a0b37 in gnat1drv () at ../../svn/gcc/ada/gnat1drv.adb:432 #5 0x00422657 in gnat_parse_file (set_yydebug=0) at ../../svn/gcc/ada/misc.c:240 #6 0x006fe03e in toplev_main (argc=20, argv=0x3d42f8) at ../../svn/gcc/toplev.c:962 #7 0x006a14d9 in main (argc=) at ../../svn/gcc/main.c:35 (gdb) frame 2 #2 0x00498917 in cstand.create_standard () at ../../svn/gcc/ada/cstand.adb:473 (gdb) print Standard_Short_Short_Integer $9 = 694 (gdb) print Standard_Short_Short_Integer_Size $10 = 8 -- Summary: [4.4 regression] Ada bootstrap fails in uintp.adb:1595 Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: build Severity: major Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: aaronavay62 at aaronwl dot com GCC host triplet: i386-pc-mingw32 GCC target triplet: i386-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36207
[Bug bootstrap/25502] I64d format Werror problem in build
--- Comment #17 from aaronavay62 at aaronwl dot com 2008-05-11 21:24 --- (In reply to comment #16) -Wno-long-long disables warnings in gnu89 -pedantic mode for certain standard C99 usages, not for non-standard usages. You could add -Wno-long-long-windows-formats to disable warning for I64d in both gnu89 and gnu99 modes. I like this idea; it lets us resolve this issue without having to neuter this port in one way or another. If there are no objections, I will prepare a patch for this. On naming, this isn't so much a Windowsism as a MSVCism. Maybe this should be named -Wlong-long-ms-formats similarly to -fms-extension or -fvisibility-ms-compat? -- aaronavay62 at aaronwl dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |aaronavay62 at aaronwl dot |dot org |com Status|NEW |ASSIGNED Last reconfirmed|2008-05-11 04:48:20 |2008-05-11 21:24:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25502
[Bug fortran/36215] New: [4.4 regression] Fortran bootstrap fails on _abs_c4.F90
I've had at least three different (but possibly related) problems when trying to bootstrap Fortran in 4.4 20080510 1) I get a popup message telling me gfortran.exe has crashed in some configure scripts, which I have not investigated further 2) When compiling _abs_c4.F90, build fails. Strangely, when using the build driver, no output is visible, but when f951.exe is invoked directly, the error message is visible. /mingw/src/gccsvn/obj/./gcc/gfortran -B/mingw/src/gccsvn/obj/./gcc/ -L/mingw/src/gccsvn/obj/i386-pc-mingw32/winsup/mingw -L/mingw/src/gccsvn/obj/i386-pc-mingw32/winsup/w32api/lib -isystem /mingw/src/gccsvn/svn/winsup/mingw/include -isystem /mingw/src/gccsvn/svn/winsup/w32api/include -B/mingw/i386-pc-mingw32/bin/ -B/mingw/i386-pc-mingw32/lib/ -isystem /mingw/i386-pc-mingw32/include -isystem /mingw/i386-pc-mingw32/sys-include -DHAVE_CONFIG_H -I. -I../../../svn/libgfortran -I. -iquote../../../svn/libgfortran/io -I../../../svn/libgfortran/../gcc -I../../../svn/libgfortran/../gcc/config -I../.././gcc -D_GNU_SOURCE -I . -Wall -fno-repack-arrays -fno-underscoring -fallow-leading-underscore -g -O2 -c ../../../svn/libgfortran/generated/_abs_c4.F90 -DDLL_EXPORT -o .libs/_abs_c4.o -save-temps -v Reading specs from /mingw/src/gccsvn/obj/./gcc/specs Target: i386-pc-mingw32 Configured with: ../svn/configure --enable-languages=c,c++,fortran,java,objc,obj-c++ --disable-sjlj-exceptions --enable-libgcj --enable-libgomp --with-dwarf2 --disable-win32-registry --enable-libstdcxx-debug --enable-concept-checks --enable-version-specific-runtime-libs --prefix=/mingw --with-gmp=/mingw/src/gcc/gmp-mpfr-root --with-mpfr=/mingw/src/gcc/gmp-mpfr-root --with-libiconv-prefix=/mingw/src/gcc/libiconv-root Thread model: win32 gcc version 4.4.0 20080510 (experimental) (GCC) ...collect2 and cpp noise omitted... /mingw/src/gccsvn/obj/./gcc/f951.exe _abs_c4.f95 -ffree-form -quiet -dumpbase _abs_c4.F90 -mtune=i386 -auxbase-strip .libs/_abs_c4.o -g -O2 -Wall -version -fno-repack-arrays -fno-underscoring -fallow-leading-underscore -I. -I../../../svn/libgfortran -I. -I../../../svn/libgfortran/../gcc -I../../../svn/libgfortran/../gcc/config -I../.././gcc -I . -fpreprocessed -fintrinsic-modules-path finclude -o _abs_c4.s GNU Fortran (GCC) version 4.4.0 20080510 (experimental) (i386-pc-mingw32) compiled by GNU C version 4.4.0 20080510 (experimental), GMP version 4.2.2, MPFR version 2.3.1. GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Error: Can't open file '_abs_c4.f95' built-in:0: fatal error: can't open input file: _abs_c4.f95 compilation terminated. However, the output file _abs_c4.f95 is actually there. 3) When I attempted to re-run the above command in GDB, I got a crash in malloc: Program received signal SIGSEGV, Segmentation fault. 0x7c91b3fb in wcsncat () from C:\WINDOWS\system32\ntdll.dll (The above message is incorrect due to GDB limitations) #0 xmalloc (size=54) at ../../svn/libiberty/xmalloc.c:147 #1 0x00440ea8 in gfc_getmem (n=54) at ../../svn/gcc/fortran/misc.c:37 #2 0x0045ed50 in gfc_widechar_to_char (s=0x282a788, length=-1) at ../../svn/gcc/fortran/scanner.c:198 #3 0x0046058a in preprocessor_line (c=0x282ab4c) at ../../svn/gcc/fortran/scanner.c:1606 #4 0x00460870 in load_file ( filename=0x282aa00 ../../../svn/libgfortran/generated/_abs_c4.F90, initial=1 '\001') at ../../svn/gcc/fortran/scanner.c:1800 #5 0x00460dd9 in gfc_new_file () at ../../svn/gcc/fortran/scanner.c:1912 #6 0x004768e2 in gfc_init () at ../../svn/gcc/fortran/f95-lang.c:288 #7 0x00527e16 in toplev_main (argc=29, argv=0x3d4518) at ../../svn/gcc/toplev.c:2039 #8 0x004bfa09 in main (argc=) at ../../svn/gcc/main.c:35 So, it looks like there is some sort of heap corruption. I'm going to look at this more after I've resolved some other issues, and I'm going to re-bootstrap with more conservative options to see if that helps. -- Summary: [4.4 regression] Fortran bootstrap fails on _abs_c4.F90 Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: build Severity: major Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: aaronavay62 at aaronwl dot com GCC host triplet: i386-pc-mingw32 GCC target triplet: i386-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36215
[Bug libgcj/20654] exception.o is not included in libgcj.a due to case-insensitivity
--- Comment #9 from aaronavay62 at aaronwl dot com 2008-05-11 23:21 --- I didn't fix it, but this apparently has been resolved some sort of way in 4.3.0. -- aaronavay62 at aaronwl dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20654
[Bug bootstrap/36216] New: [meta-bug] Bootstrap problems on mingw32
Meta bug for issues blocking all languages, all subdirectories bootstrap on i386-pc-mingw32 on 4.4.0 experimental. These should all be regressions, as this works (except for libmudflap) in 4.3.0. -- Summary: [meta-bug] Bootstrap problems on mingw32 Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: meta-bug Severity: major Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: aaronavay62 at aaronwl dot com GCC build triplet: i386-pc-mingw32 GCC host triplet: i386-pc-mingw32 GCC target triplet: i386-pc-mingw32 BugsThisDependsOn: 25502,36207,36215 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36216
[Bug bootstrap/25502] Werror problem in build
--- Comment #13 from aaronavay62 at aaronwl dot com 2008-05-11 03:04 --- What would be an acceptable solution other than having bootstrap perpetually broken, and other than --disable-werror? 1) We could only enable this warning when in strict mode, eg -std=c99 -pedantic. -std=gnu99 -pedantic would not warn. This seems like it might be best. 2) Adding __extension__ will silence this warning. Should we make a macro to decorate these uses of HOST_WIDEST_INT_PRINT_DEC? 3) Worse case, can we just HOST_WIDEST_INT long? -- aaronavay62 at aaronwl dot com changed: What|Removed |Added CC||aaronavay62 at aaronwl dot ||com Last reconfirmed|2005-12-23 05:44:30 |2008-05-11 03:04:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25502
[Bug bootstrap/25502] I64d format Werror problem in build
--- Comment #14 from aaronavay62 at aaronwl dot com 2008-05-11 04:48 --- Another question: why does lld not cause warnings on linux here? I don't see what the difference is. Whatever the situation is, I don't see any reason that I64d should behave differently from lld in gnu89 mode. -- aaronavay62 at aaronwl dot com changed: What|Removed |Added GCC build triplet|i686-pc-mingw32 | GCC target triplet|i686-pc-mingw32 | Last reconfirmed|2008-05-11 03:04:43 |2008-05-11 04:48:20 date|| Summary|Werror problem in build |I64d format Werror problem ||in build http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25502
[Bug ada/18302] ACATS tests hang: c74004a, c960004, and others
--- Comment #19 from aaronavay62 at aaronwl dot com 2008-05-04 07:32 --- On i386-pc-mingw32, these are the tests that fail on 4.3.0. Hanging idle (at 0% CPU): c74004a c940010 c94002f c94002g c94008a c953001 Hanging busy (at 100% CPU): c960004 c974001 c974002 c974013 -- aaronavay62 at aaronwl dot com changed: What|Removed |Added GCC build triplet|i?86-*-*| Last reconfirmed|2004-12-08 19:44:18 |2008-05-04 07:32:53 date|| Summary|ACATS test c953002 (and |ACATS tests hang: c74004a, |others) hangs |c960004, and others Target Milestone|4.0.0 |--- Version|4.0.0 |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18302
[Bug debug/33155] _stdcall assembler names in win32 vs gdb
--- Comment #3 from aaronavay62 at aaronwl dot com 2008-04-26 04:13 --- (In reply to comment #2) (In reply to comment #1) What is the status on this? Does reverting the langhooks.c change remanifest PR27067? No. PR27067 is fixed by cp/mangle.c (mangle_decl): Call targetm.mangle_decl_assembler_name. I see; then should the langhooks.c bit be reverted to fix this bug, or do you think it will be able to be solved soon some other way? -- aaronavay62 at aaronwl dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-04-26 04:13:31 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33155
[Bug debug/33155] _stdcall assembler names in win32 vs gdb
--- Comment #1 from aaronavay62 at aaronwl dot com 2008-04-13 19:48 --- What is the status on this? Does reverting the langhooks.c change remanifest PR27067? -- aaronavay62 at aaronwl dot com changed: What|Removed |Added CC||aaronavay62 at aaronwl dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33155
[Bug ada/18302] ACATS test c953002 (and others) hangs
--- Comment #18 from aaronavay62 at aaronwl dot com 2008-04-12 07:11 --- (In reply to comment #17) OK, but sweeping the problem under the rug is not the solution on mainline. I'm not advocating making these failures disappear; I'd just prefer they FAIL rather than hanging, which disinclines one from running Ada tests at all. Normal dejagnu tests have a time limit; why should the ACATS testsuite be different? Probably no reason. If there's no reason, then perhaps we can commit James' patch? Allowing any random Ada bug, particularly these which are probably not likely to be fixed soon, to hang the testsuite on MinGW, doesn't seem sensible. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18302
[Bug target/35921] Con/de-structor definition fails to override dllimport declaration
--- Comment #2 from aaronavay62 at aaronwl dot com 2008-04-13 01:46 --- Note at present, implicit inline within the class definition will work; it's only out-of-line that fails. Also, if we fix this bug in the suggested way, we need to change the documentation to state that the 'inline' is not ignored, and state that this has probably has different behavior from MSVC's dllimport. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35921
[Bug ada/18302] ACATS test c953002 (and others) hangs
--- Comment #14 from aaronavay62 at aaronwl dot com 2008-04-05 05:09 --- A bunch of tests hang for me, some with 0% cpu, some with 100% cpu, on i386-pc-mingw32 of 4.3.0. Among the 0% CPU hangers is c960004 Among the 100% CPU hangers is c974013 Is there some reason that the proposed timeout fix that was applied to the RH branch can't be applied to trunk? -- aaronavay62 at aaronwl dot com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18302
[Bug ada/18302] ACATS test c953002 (and others) hangs
--- Comment #16 from aaronavay62 at aaronwl dot com 2008-04-05 05:39 --- Yes, but it's still possible they might hang from time to time as bugs are introduced, which is fairly bad for automated testing etc. Normal dejagnu tests have a time limit; why should the ACATS testsuite be different? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18302
[Bug c++/29365] Unnecessary anonymous namespace warnings
--- Comment #20 from aaronavay62 at aaronwl dot com 2007-05-03 13:00 --- It looks like this will not be backported to 4.2 as its not strictly a regression. See http://gcc.gnu.org/ml/gcc/2007-05/msg00067.html. If you use this sort of pimpl and anonymous namespaces or similar, and you want to use -Werror, you'll need to patch your own sources for now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29365
[Bug target/27067] Compile errors with multiple inheritance where the stdcall attribute is applied to virtual functions.
--- Comment #8 from aaronavay62 at aaronwl dot com 2007-04-05 08:05 --- What is the status on this? I'm pretty sure this is a regression; it would be great if this fix could get into 4.2, but it might be too late for that. This is a serious problem for many/most users on Windows as it breaks COM. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27067
[Bug libstdc++/31481] New: GCC 4.2.0 incompatible with STLport 5.1.3
GCC 4.2.0 is unable to compile STLport due to a header conflict. When compiling any C++ program that includes iostream: In file included from c:/aaronwl/gcc/root/bin/../lib/gcc/i686-pc-mingw32/4.2.0/../../../../include/c++/4.2.0/../4.2.0/cmath:52, from /aaronwl/stlport/STLport-5.1.3/stlport/stl/_cmath.h:31, from /aaronwl/stlport/STLport-5.1.3/stlport/stl/_cstdlib.h:162, from /aaronwl/stlport/STLport-5.1.3/stlport/stl/_locale.h:27, from /aaronwl/stlport/STLport-5.1.3/stlport/stl/_ios_base.h:30, from /aaronwl/stlport/STLport-5.1.3/stlport/stl/_ios.h:23, from /aaronwl/stlport/STLport-5.1.3/stlport/stl/_istream.h:27, from /aaronwl/stlport/STLport-5.1.3/stlport/iostream:39, from stuff.cpp:1: c:/aaronwl/gcc/root/bin/../lib/gcc/i686-pc-mingw32/4.2.0/../../../../include/c++/4.2.0/ext/type_traits.h:184: error: 'streamsize' in namespace 'std' does not name a type c:/aaronwl/gcc/root/bin/../lib/gcc/i686-pc-mingw32/4.2.0/../../../../include/c++/4.2.0/ext/type_traits.h:189: error: expected initializer before '__numeric_traits_floating' The problem here is that STLport is including cmath provided by GCC, assuming that it will play well. However, GCC's cmath needs std::streamsize, and assumes iosfwd will provide it. iosfwd, provided by STLport, declares it as stlpmtx_std::streamsize. std is later redefined to be stlpmtx_std, but this doesn't happen in time for cmath, because this doesn't happen until we exit from STLport-provided system headers. Thus the declaration can't be found. I'm not sure who's problem this is, or whether GCC is inclined to do anything to fix it. But I thought I'd report it because STLport works with previous versions, and this will probably be a problem for many users. -- Summary: GCC 4.2.0 incompatible with STLport 5.1.3 Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: aaronavay62 at aaronwl dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31481
[Bug libstdc++/31481] GCC 4.2.0 incompatible with STLport 5.1.3
--- Comment #1 from aaronavay62 at aaronwl dot com 2007-04-05 05:34 --- OK, mainline just uses an 'int' here instead of 'streamsize.' Also, N1822 just has 'int.' Why is 'streamsize' here? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31481
[Bug c/20784] New: Impossible to mute warning: imaginary constants are a GCC extension
float complex c = 1.if; // warning: imaginary constants are a GCC extension This warning is generated when -pedantic is specified. This creates problems with perfectly valid standard C99 code such as the following. double complex d = I; No particular placement of __extension__ seems to be able to make this warning go away. -- Summary: Impossible to mute warning: imaginary constants are a GCC extension Product: gcc Version: 4.1.0 Status: UNCONFIRMED Keywords: diagnostic Severity: minor Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: aaronavay62 at aaronwl dot com CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20784
[Bug c/20785] New: Pragma STDC CX_LIMITED_RANGE unimplemented
#pragma STDC CX_LIMITED_RANGE off is currently unimplemented, and generates the warning: warning: ignoring #pragma STDC CX_LIMITED_RANGE -- Summary: Pragma STDC CX_LIMITED_RANGE unimplemented Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: aaronavay62 at aaronwl dot com CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20785
[Bug c/20785] Pragma STDC CX_LIMITED_RANGE unimplemented
--- Additional Comments From aaronavay62 at aaronwl dot com 2005-04-06 12:13 --- I opened the PR so I would have a tangible place to point to in a FIXME in some code, saying when this bug is fixed, uncomment this. Perhaps though, for things of this sort, it would be better to point to the status page. However, one can add oneself to the CC list for a bug much easier than he can add himself to the CC list for a webpage. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20785
[Bug libgcj/20654] exception.o is not included in libgcj.a due to case-insensitivity
--- Additional Comments From aaronavay62 at aaronwl dot com 2005-03-30 21:10 --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2005-03/msg02804.html. -- What|Removed |Added Keywords||patch Last reconfirmed|2005-03-28 12:42:10 |2005-03-30 21:10:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20654
[Bug libgcj/20654] exception.o is not included in libgcj.a due to case-insensitivity
--- Additional Comments From aaronavay62 at aaronwl dot com 2005-03-28 12:42 --- Thanks Danny. So there is already machinery to fix this; it just needs to be adapted to be case-insensitive. I'm working on a patch. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |aaronavay62 at aaronwl dot |dot org |com Status|NEW |ASSIGNED Last reconfirmed|2005-03-27 13:01:38 |2005-03-28 12:42:10 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20654
[Bug java/20654] New: exception.o is not included in libgcj.a due to case-insensitivity
binutils ar was recently changed to exclude path when comparing object filenames, to agree with POSIX. This combines with Windows' case-insensitive filesystem to cause java/lang/Exception.o to replace exception.o in the following command while creating libgcj.a. ar rc .libs/libgcj0_convenience.a prims.o jni.o exception.o ... java/lang/Exception.o ... This causes bootstrap to fail when linking jv-convert. make[4]: Entering directory `/aaronwl/cs/env/mingw- head/20050325/build/gcc/i686-pc-mingw32/libjava' /bin/sh ./libtool --tag=GCJ --mode=link /aaronwl/cs/env/mingw- head/20050325/build/gcc/./gcc/gcj -B/aaronwl/cs/env/mingw- head/20050325/build/gcc/./gcc/ -B/aaronwl/cs/env/mingw-head/20050325/i686-pc- mingw32/bin/ -B/aaronwl/cs/env/mingw-head/20050325/i686-pc-mingw32/lib/ - isystem /aaronwl/cs/env/mingw-head/20050325/i686-pc-mingw32/include - isystem /aaronwl/cs/env/mingw-head/20050325/i686-pc-mingw32/sys-include - L/aaronwl/cs/env/mingw-head/20050325/build/gcc/i686-pc-mingw32/libjava -ffloat- store -fno-omit-frame-pointer -g -O2 -o jv-convert.exe -- main=gnu.gcj.convert.Convert -rpath /aaronwl/cs/env/mingw-head/20050325/lib - shared-libgcc -L/aaronwl/cs/env/mingw-head/20050325/build/gcc/i686-pc- mingw32/libjava/.libs libgcj.la /aaronwl/cs/env/mingw-head/20050325/build/gcc/./gcc/gcj - B/aaronwl/cs/env/mingw-head/20050325/build/gcc/./gcc/ -B/aaronwl/cs/env/mingw- head/20050325/i686-pc-mingw32/bin/ -B/aaronwl/cs/env/mingw-head/20050325/i686- pc-mingw32/lib/ -isystem /aaronwl/cs/env/mingw-head/20050325/i686-pc- mingw32/include -isystem /aaronwl/cs/env/mingw-head/20050325/i686-pc- mingw32/sys-include -ffloat-store -fno-omit-frame-pointer -g -O2 -o jv- convert.exe --main=gnu.gcj.convert.Convert -shared-libgcc - L/aaronwl/cs/env/mingw-head/20050325/build/gcc/i686-pc-mingw32/libjava - L/aaronwl/cs/env/mingw-head/20050325/build/gcc/i686-pc- mingw32/libjava/.libs ./.libs/libgcj.a -L/aaronwl/cs/env/mingw- head/20050325/build/gcc/i686-pc-mingw32/libstdc++-v3/src - L/aaronwl/cs/env/mingw-head/20050325/build/gcc/i686-pc-mingw32/libstdc++- v3/src/.libs -L/aaronwl/cs/env/mingw-head/20050325/build/gcc/./gcc - L/aaronwl/cs/env/mingw-head/20050325/i686-pc-mingw32/bin - L/aaronwl/cs/env/mingw-head/20050325/i686-pc-mingw32/lib - L/aaronwl/cs/env/mingw-head/20050325/lib/../i686-pc-mingw32/lib - L/aaronwl/cs/env/mingw-head/20050325/lib -L/mingw/lib -lmingw32 -lgcc - lmoldname -lmingwex -lmsvcrt -luser32 -lkernel32 -ladvapi32 -lshell32 - lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt -Wl,--rpath - Wl,/aaronwl/cs/env/mingw-head/20050325/lib ./.libs/libgcj.a(prims.o): In function `Z17_Jv_ThrowNoMemoryv': /aaronwl/cs/compilers/gcc/src/cvs/head/gcc/libjava/prims.cc:369: undefined reference to `_Jv_Throw' ./.libs/libgcj.a(prims.o): In function `Jv_Malloc': /aaronwl/cs/compilers/gcc/src/cvs/head/gcc/libjava/prims.cc:1276: undefined reference to `_Jv_Throw' ... Since, depending on how you look at it, 'ar' is doing the right thing, I think the easiest way to fix this to rename exception.cc to exceptions.cc. -- Summary: exception.o is not included in libgcj.a due to case- insensitivity Product: gcc Version: 4.1.0 Status: UNCONFIRMED Keywords: build Severity: normal Priority: P2 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: aaronavay62 at aaronwl dot com CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org GCC target triplet: i?86-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20654
[Bug java/20654] exception.o is not included in libgcj.a due to case-insensitivity
-- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-03-27 13:01:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20654
[Bug libgcj/20654] exception.o is not included in libgcj.a due to case-insensitivity
--- Additional Comments From aaronavay62 at aaronwl dot com 2005-03-28 06:09 --- This also happens with gnu/java/security/OID.o and org/ietf/jgss/Oid.o, again causing build to break in jv-collect. These files are less easily renamed, though. I don't know how to fix this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20654
[Bug libgcj/20654] exception.o is not included in libgcj.a due to case-insensitivity
--- Additional Comments From aaronavay62 at aaronwl dot com 2005-03-28 07:40 --- I just checked against Microsoft (R) Library Manager Version 7.10.3052 and binutils's case-insensitivity replacement semantics are consistant with Microsoft's implementation. LIB also has the same path-preserving semantics of the previous non-POSIX ar. I think a better way to fix this would be to check if the P to ar is availible, and use it, if it is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20654
[Bug bootstrap/14316] collect2 doesnt build on windows hosts
--- Additional Comments From aaronavay62 at aaronwl dot com 2005-03-01 06:06 --- Nope. Ian Lance Taylor or DJ Delorie must approve the libiberty portions of this patch, or someone must suggest (and implement) an alternate implementation. I don't know why Ian Lance Taylor doesn't approve it, as he's the one who wrote it. It might be more appropriate to fix this in a direct manner by simply having #ifdef sections for Windows in collect2.c, which isn't that bad because: 1) The changes are actually rather minimal, mostly slight tweaks and using spawn rather than fork. 2) The file already has much worse OS-specific code in it. The trouble is that a global maintainer may still be disinclined to approve a patch such as this; in a perfect world, this isn't the right way to fix this problem. I beleive there is actually a third implementation by Zack Weinberg, but DJ Delorie has specific problems with it. I beleive this implementation is used on the csl-arm branch. So, as I understand it, the situation is basically deadlocked until someone suggests another way to fix this problem. In the meantime, most of us who care about this issue have left the GCC process behind and have been using one of these three fixes for years. -- What|Removed |Added Last reconfirmed|2004-02-27 02:52:47 |2005-03-01 06:06:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14316
[Bug ada/20226] New: [4.0, 4.1 Regression] Error in __gnat_install_SEH_handler breaks bootstrap
When bootstrapping GCC mainline 20050226, the build breaks here: ../../gnatbind -C -I- -I../rts -I. - I/aaronwl/cs/compilers/gcc/src/cvs/head/gcc/gcc/ada -o b_gnatm.c gnatmake.ali make[3]: *** [b_gnatm.c] Error 5 make[3]: Leaving directory `/aaronwl/cs/env/mingw- head/20050226/build/gcc/gcc/ada/tools' gdb shows: Program received signal SIGSEGV, Segmentation fault. __gnat_install_SEH_handler (ER=0x77c3aead) at /aaronwl/cs/compilers/gcc/src/cvs/head/gcc/gcc/ada/seh_init.c:220 220 ((int *)ER)[1] = (int)__gnat_SEH_error_handler; /* new handler */ (gdb) bt #0 __gnat_install_SEH_handler (ER=0x77c3aead) at /aaronwl/cs/compilers/gcc/src/cvs/head/gcc/gcc/ada/seh_init.c:220 #1 0x00401595 in main (argc=9, argv=0x3d4238, envp=0x3d2fc8) at ada/b_gnatb.c:260 (gdb) quit This may be related to this recent patch: http://gcc.gnu.org/ml/gcc- patches/2005-02/msg00428.html. I can't tell superficially what the problem is, as set ((int *)ER)[1] = (int) __gnat_SEH_error_handler appears to work just fine. Target: i686-pc-mingw32 Configured with: /aaronwl/cs/compilers/gcc/src/cvs/head/gcc/configure --enable- languages=ada,c,c++,f95,java,objc --with-dwarf2 --enable-libmudflap --enable- libgcj --enable-libstdcxx-allocator=mt --enable-libstdcxx-debug --enable- concept-checks --with-included-gettext --prefix=/aaronwl/cs/env/mingw- head/20050226 --with-libiconv-prefix=/aaronwl/cs/internat/iconv/install --with- gmp=/aaronwl/cs/math/gmp/gmp-4.1.4 --with-mpfr=/aaronwl/cs/math/mpfr/mpfr-2.1.0 Thread model: win32 gcc version 4.1.0 20050226 (experimental) i686-pc-mingw32 Windows XP SP2 Professional Pentium 4 256MB Cygwin Current Thu Feb 24 03:40:25 2005 host gcc 3.4.1 (mingw special) host binutils 2.15.91 20040904 (mingw) host mingwrt 3.5 host w32api 3.1 msvcrt 7.0.2600.2180 libiconv 1.9.1 GNU Make 3.80 expect 5.26 tcl 8.4 dejagnu 1.4.2.x ln with softlinks disabled -- Summary: [4.0, 4.1 Regression] Error in __gnat_install_SEH_handler breaks bootstrap Product: gcc Version: 4.1.0 Status: UNCONFIRMED Keywords: build Severity: critical Priority: P2 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: aaronavay62 at aaronwl dot com CC: charlet at adacore dot com,gcc-bugs at gcc dot gnu dot org GCC target triplet: i686-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20226
[Bug ada/20226] [4.0/4.1 Regression] Error in __gnat_install_SEH_handler breaks bootstrap
--- Additional Comments From aaronavay62 at aaronwl dot com 2005-02-27 02:35 --- Since you asked, I noticed that I had used 'make' instead of 'make bootstrap' by accident. I will try again using 'make bootstrap'. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20226
[Bug ada/20226] [4.0/4.1 Regression] Error in __gnat_install_SEH_handler breaks bootstrap
--- Additional Comments From aaronavay62 at aaronwl dot com 2005-02-27 04:41 --- OK, I tried again with make bootstrap, and I get a nearly identical problem: stage1/gnatbind -C -I- -I. -Iada -I/aaronwl/cs/compilers/gcc/src/cvs/head/gcc/gcc/ada -o ada/b_gnat1.c -n ada/gnat1drv.ali make[3]: *** [ada/b_gnat1.c] Error 5 make[3]: Leaving directory `/aaronwl/cs/env/mingw-head/20050226/build/gcc/gcc' make[2]: *** [stage2_build] Error 2 In gdb: Program received signal SIGSEGV, Segmentation fault. 0x004034e9 in __gnat_install_SEH_handler (ER=0x77c3b814) at /aaronwl/cs/compilers/gcc/src/cvs/head/gcc/gcc/ada/seh_init.c:219 219 ((int *)ER)[0] = (int)ptr; /* previous handler */ #0 0x004034e9 in __gnat_install_SEH_handler (ER=0x77c3b814) at /aaronwl/cs/compilers/gcc/src/cvs/head/gcc/gcc/ada/seh_init.c:219 #1 0x0040321b in __gnat_initialize (eh=0x77c3b814) at /aaronwl/cs/compilers/gcc/src/cvs/head/gcc/gcc/ada/init.c:840 #2 0x004015a8 in main (argc=10, argv=0x3d4250, envp=0x3d2fc0) at ada/b_gnatb.c:260 Inspecting the values above yield nothing apparently abnormal. In particular, ((int *)ER)[0] appears to be valid. Is this a codegen bug? -- What|Removed |Added CC||dannysmith at users dot ||sourceforge dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20226
[Bug libfortran/19074] libgfortran bootstrap fails on Windows
--- Additional Comments From aaronavay62 at aaronwl dot com 2004-12-19 18:59 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19074
[Bug libfortran/16991] [meta-bug] libgfortran does not build every where
-- Bug 16991 depends on bug 19074, which changed state. Bug 19074 Summary: libgfortran bootstrap fails on Windows http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19074 What|Old Value |New Value Status|UNCONFIRMED |NEW Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16991
[Bug bootstrap/18107] [4.0 Regression] [meta-bug] Bootstrap fails on i686-pc-mingw32
-- Bug 18107 depends on bug 19074, which changed state. Bug 19074 Summary: libgfortran bootstrap fails on Windows http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19074 What|Old Value |New Value Status|UNCONFIRMED |NEW Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18107
[Bug bootstrap/18107] [4.0 Regression] [meta-bug] Bootstrap fails on i686-pc-mingw32
-- What|Removed |Added BugsThisDependsOn||19074 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18107
[Bug libfortran/19074] New: [4.0 Regression] libgfortran bootstrap fails on Windows
This patch http://gcc.gnu.org/ml/gcc-patches/2004-12/msg00851.html breaks bootstrap on i686-pc-mingw32 due to the name itoa in libgfortran conflicting with MinGW runtime headers. A patch is here http://gcc.gnu.org/ml/gcc-patches/2004-12/msg01278.html, awaiting approval. -- Summary: [4.0 Regression] libgfortran bootstrap fails on Windows Product: gcc Version: 4.0.0 Status: UNCONFIRMED Keywords: patch Severity: critical Priority: P2 Component: libfortran AssignedTo: aaronavay62 at aaronwl dot com ReportedBy: aaronavay62 at aaronwl dot com CC: gcc-bugs at gcc dot gnu dot org,rth at gcc dot gnu dot org GCC target triplet: i686-pc-mingw32 OtherBugsDependingO 16991,18107 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19074
[Bug libfortran/16991] [meta-bug] libgfortran does not build every where
-- What|Removed |Added BugsThisDependsOn||19074 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16991
[Bug ada/18302] ACATS test c953002 (and others) hangs
--- Additional Comments From aaronavay62 at aaronwl dot com 2004-12-08 19:44 --- On i686-pc-mingw32, these three tests hang: ExecutableRun time Memory Usage c94002f.exe 0s 1112KB c974012.exe 0s 1080KB c980001.exe 0s 604KB Andrew Pinski says: I have the same problem with c94002f and c974012 on ppc-darwin These are the following which hang for me on ppc-darwin: c37402a c94002f c94002g c953002 c954020 c954021 c954022 c954023 c954024 c954026 c974012 -- What|Removed |Added Last reconfirmed|2004-11-16 08:29:05 |2004-12-08 19:44:18 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18302
[Bug ada/17666] Ada tests hanging during make check
--- Additional Comments From aaronavay62 at aaronwl dot com 2004-12-08 19:44 --- *** This bug has been marked as a duplicate of 18302 *** -- What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17666
[Bug ada/18302] ACATS test c953002 (and others) hangs
--- Additional Comments From aaronavay62 at aaronwl dot com 2004-12-08 19:44 --- *** Bug 17666 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||aaronavay62 at aaronwl dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18302
[Bug target/18469] New: configure incorrectly defines gid_t
When building a cross compiler from a Windows host to sparc-sun-solaris2.8, make fails here: /aaronwl/cs/compilers/gcc/build/solaris8-head/gcc/xgcc - B/aaronwl/cs/compilers/gcc/build/solaris8-head/gcc/ -B/aaronwl/cs/env/solaris- head/sparc-sun-solaris2.8/bin/ -B/aaronwl/cs/env/solaris-head/sparc-sun- solaris2.8/lib/ -isystem /aaronwl/cs/env/solaris-head/sparc-sun- solaris2.8/include -isystem /aaronwl/cs/env/solaris-head/sparc-sun- solaris2.8/sys-include -O2 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite- strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition - isystem ./include -I. -I. -I../../../src/cvs/head/gcc/gcc - I../../../src/cvs/head/gcc/gcc/. -I../../../src/cvs/head/gcc/gcc/../include - I../../../src/cvs/head/gcc/gcc/../libcpp/include -g0 -finhibit-size- directive -fno-inline-functions -fno-exceptions -fno-zero-initialized-in-bss - fno-unit-at-a-time -fPIC \ -c ../../../src/cvs/head/gcc/gcc/crtstuff.c -DCRT_BEGIN \ -o crtbegin.o In file included from ../../../src/cvs/head/gcc/gcc/tsystem.h:93, from ../../../src/cvs/head/gcc/gcc/crtstuff.c:62: /aaronwl/cs/env/solaris-head/root/usr/include/sys/types.h:340: error: two or more data types in declaration specifiers make[1]: *** [crtbegin.o] Error 1 make[1]: Leaving directory `/aaronwl/cs/compilers/gcc/build/solaris8-head/gcc' make: *** [all-gcc] Error 2 The line in question is: typedef uid_t gid_t; /* GID type */ However, auto-host.h defines: /* Define to `int' if sys/types.h doesn't define. */ #define gid_t int I can't figure out from config.log why this is being defined. Removing the define for gid_t fixes this problem. i686-pc-mingw32 Windows XP SP2 Professional Pentium 4 1.4GHz 256MB binutils 2.15 mingwrt 3.5 msvcrt 7.0.2600.2180 w32api 3.1 libiconv 1.9.1 GNU Make 3.80 expect 5.26 tcl 8.4 dejagnu 1.4.2.x Misc tools and environment from Cygwin Current Fri Oct 22 01:50:41 2004 ln with softlinks disabled host gcc 4.0.0 20041028 (experimental) host binutils 2.15.94 20041028 host mingwrt head 20041028 host w32api head 20041028 Configured with: ../../src/cvs/head/gcc/configure -- prefix=/aaronwl/cs/env/solaris-head --target=sparc-sun-solaris2.8 --disable- nls --enable-languages=c --with-sysroot=/aaronwl/cs/env/solaris-head/root Thread model: single gcc version 4.0.0 20041113 (experimental) -- Summary: configure incorrectly defines gid_t Product: gcc Version: 4.0.0 Status: UNCONFIRMED Keywords: build Severity: normal Priority: P2 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: aaronavay62 at aaronwl dot com CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: i686-pc-mingw32 GCC host triplet: i686-pc-mingw32 GCC target triplet: sparc-sun-solaris2.8 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18469
[Bug target/18106] Weak symbols are unimplemented on Windows
--- Additional Comments From aaronavay62 at aaronwl dot com 2004-11-06 04:29 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18106
[Bug libfortran/18103] libgfortran system header conflict breaks bootstrap on MinGW
--- Additional Comments From aaronavay62 at aaronwl dot com 2004-11-06 04:33 --- Still waiting for patch in comment #1 to be approved. -- What|Removed |Added Last reconfirmed|2004-10-22 11:40:31 |2004-11-06 04:33:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18103
[Bug libfortran/18105] Compile errors in libgfortran/io/unix.c break Windows bootstrap
--- Additional Comments From aaronavay62 at aaronwl dot com 2004-11-06 04:34 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18105
[Bug libfortran/16991] [meta-bug] libgfortran does not build every where
-- Bug 16991 depends on bug 18105, which changed state. Bug 18105 Summary: Compile errors in libgfortran/io/unix.c break Windows bootstrap http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18105 What|Old Value |New Value Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16991
[Bug bootstrap/18107] [4.0 Regression] Bootstrap fails on i686-pc-mingw32
-- Bug 18107 depends on bug 18105, which changed state. Bug 18105 Summary: Compile errors in libgfortran/io/unix.c break Windows bootstrap http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18105 What|Old Value |New Value Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18107
[Bug target/18106] Weak symbols are unimplemented on Windows
--- Additional Comments From aaronavay62 at aaronwl dot com 2004-11-03 21:12 --- For what its worth, the issue in comment #2 was resolved. This patch can again be safely applied. It is awaiting review. -- What|Removed |Added Last reconfirmed|2004-10-22 11:43:25 |2004-11-03 21:12:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18106
[Bug libgcj/18104] Incorrect CLASSPATH separator in libjava breaks bootstrap
--- Additional Comments From aaronavay62 at aaronwl dot com 2004-11-02 22:31 --- I agree with you with regards to the ugliness. The entire situation is really too bad; the mutually incompatible path separators used by Unix and Windows is definitely one of the top ten compatibility problems in build systems. GCJ definitely needs to accept ; on Windows, as whats what javac does. I think it would also be excellent if it accepted :, but I don't know the whole story behind this. In particular, I think there was some sort of code that could handle nontrivial Windows path separator parsing, somewhere in GCC, but it was removed, or something. I really don't know enough about the issue to fix it myself. Maybe there is some other way to fix this in the Makefiles, to make it so it isn't so ugly? Should a bug be opened for CLASSPATH_SEPARATOR in Makefiles is ugly? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18104
[Bug regression/18246] New: struct-layout-1 generator broken on i686-pc-mingw32
= 3000 -- Summary: struct-layout-1 generator broken on i686-pc-mingw32 Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: regression AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: aaronavay62 at aaronwl dot com CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: i686-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18246
[Bug other/18246] struct-layout-1 generator broken on i686-pc-mingw32
--- Additional Comments From aaronavay62 at aaronwl dot com 2004-10-31 19:16 --- Ugh, forgot about that. It's time to fix this problem the right way. I've been meaning to get this out of the way for a while. I'll get back to you on this. -- What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-10-31 19:16:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18246
[Bug target/18106] Weak symbols are unimplemented on Windows
--- Additional Comments From aaronavay62 at aaronwl dot com 2004-10-31 03:40 --- As of 2004-10-25, weak symbols will break libstdc++-v3. See http://gcc.gnu.org/ml/gcc-patches/2004-10/msg02723.html. I'm not sure what to do about this yet. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18106
[Bug libmudflap/18243] New: Link fails with -fmudflap on Windows
libmudflap has never worked on Windows. There appear to be two problems: 1) There is a problem with the specs file, and the proper options, such as -- wrap, never get passed to the linker. 2) Dependencies are introduced on mmap, munmap, and kill. The first two Windows supports through a separate interface, but Windows does not have interprocess signals and has nothing similar to kill() outside of raise(). -- Summary: Link fails with -fmudflap on Windows Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libmudflap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: aaronavay62 at aaronwl dot com CC: gcc-bugs at gcc dot gnu dot org GCC target triplet: i686-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18243
[Bug libmudflap/18243] Link fails with -fmudflap on Windows
--- Additional Comments From aaronavay62 at aaronwl dot com 2004-10-31 04:43 --- If I pass -static on the link line, link will succeed for an empty C program. But hello world still fails with an undefined reference to _mfwrap_puts. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18243
[Bug bootstrap/18107] [4.0 Regression] Bootstrap fails on i686-pc-mingw32
-- What|Removed |Added BugsThisDependsOn||18226 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18107
[Bug ada/18226] New: [4.0 regression] EXCEPTION_STACK_OVERFLOW compiling make.adb
While building GCC 20041028 with Ada enabled, bootstrap fails while building libada: ../../xgcc -B../../ -c -O2 -g -O2 -W -Wall -Wwrite-strings -Wstrict- prototypes -Wmissing-prototypes -fno-common -gnatpg -gnata -I- -I../rts - I. - I/aaronwl/cs/compilers/gcc/src/cvs/head/gcc/gcc/ada /aaronwl/cs/compilers/gcc/s rc/cvs/head/gcc/gcc/ada/make.adb -o make.o raised STORAGE_ERROR : EXCEPTION_STACK_OVERFLOW make[4]: *** [make.o] Error 1 From gdb: Program received signal SIGSEGV, Segmentation fault. gt_ggc_mx_lang_tree_node (x_p=0x3f9edc0) at ./gtype-ada.h:27 27if (ggc_test_and_set_mark (x)) #0 gt_ggc_mx_lang_tree_node (x_p=0x3f9edc0) at ./gtype-ada.h:27 x = (union lang_tree_node * const) 0x3f9edc0 __FUNCTION__ = gt_ggc_mx_lang_tree_node #1 0x0042b215 in gt_ggc_mx_lang_tree_node (x_p=0x41510a0) at ./gtype-ada.h:178 x = (union lang_tree_node * const) 0x41510a0 __FUNCTION__ = gt_ggc_mx_lang_tree_node #2 0x0042b215 in gt_ggc_mx_lang_tree_node (x_p=0x3c84af0) at ./gtype-ada.h:178 x = (union lang_tree_node * const) 0x3c84af0 __FUNCTION__ = gt_ggc_mx_lang_tree_node ... Reading specs from /aaronwl/cs/env/mingw-head-head-head-20041028/lib/gcc/i686- pc-mingw32/4.0.0/specs Configured with: ../../src/cvs/head/gcc/configure --enable- languages=ada,c,c++,f95,java,objc --with-dwarf2 --enable-libmudflap --enable- libgcj --with-win32-nlsapi=unicows --enable-libstdcxx-allocator=mt --enable- libstdcxx-debug --enable-concept-checks --prefix=/aaronwl/cs/env/mingw-head- head-head-20041028 --with-included-gettext --with-libiconv- prefix=/aaronwl/cs/internat/iconv/install --with-gmp=/aaronwl/cs/env/mingw- head-head-head-20041028 --with-mpfr=/aaronwl/cs/env/mingw-head-head-head- 20041028 Thread model: win32 gcc version 4.0.0 20041028 (experimental) i686-pc-mingw32 Windows XP SP2 Professional Pentium 4 1.4GHz 256MB binutils 2.15.94 20041028 mingwrt mainline 20041028 msvcrt 7.0.2600.2180 w32api mainline 20041028 libiconv 1.9.1 gmp 4.1.4 mpfr 2.0.3 GNU Make 3.80 expect 5.26 tcl 8.4 dejagnu 1.4.2.x Misc tools and environment from Cygwin Current Fri Oct 22 01:50:41 2004 ln with softlinks disabled host gcc 3.4.1 (mingw special) host binutils 2.15.91 20040904 (mingw) host mingwrt 3.5 host w32api 3.1 -- Summary: [4.0 regression] EXCEPTION_STACK_OVERFLOW compiling make.adb Product: gcc Version: 4.0.0 Status: UNCONFIRMED Keywords: ice-on-valid-code, build Severity: critical Priority: P2 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: aaronavay62 at aaronwl dot com CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: i686-pc-mingw32 GCC host triplet: i686-pc-mingw32 GCC target triplet: i686-pc-mingw32 OtherBugsDependingO 18107 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18226
[Bug ada/18226] [4.0 regression] EXCEPTION_STACK_OVERFLOW compiling make.adb
--- Additional Comments From aaronavay62 at aaronwl dot com 2004-10-29 19:22 --- Created an attachment (id=7432) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7432action=view) Backtrace and tree node. Full backtrace (up until gdb crashed), printed tree node (gdb encountered Dwarf2 errors with pt) output, and other misc. information attached. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18226
[Bug ada/17666] Ada tests hanging during make check
--- Additional Comments From aaronavay62 at aaronwl dot com 2004-10-30 05:02 --- GCC mainline 20041028 still has hangs on these three tests. (Complete test results are coming when the check completes, which might not be for another day.) Its also still the same three tests hanging: ExecutableRun time Memory Usage c94002f.exe 0s 1112KB c974012.exe 0s 1080KB c980001.exe 0s 604KB The test configuration is: Reading specs from /aaronwl/cs/env/mingw-head-head-head-20041028/lib/gcc/i686- pc-mingw32/4.0.0/specs Configured with: ../../src/cvs/head/gcc/configure --enable- languages=ada,c,c++,f95,java,objc --with-dwarf2 --enable-libmudflap --enable- libgcj --with-win32-nlsapi=unicows --enable-libstdcxx-allocator=mt --enable- libstdcxx-debug --enable-concept-checks --prefix=/aaronwl/cs/env/mingw-head- head-head-20041028 --with-included-gettext --with-libiconv- prefix=/aaronwl/cs/internat/iconv/install --with-gmp=/aaronwl/cs/env/mingw- head-head-head-20041028 --with-mpfr=/aaronwl/cs/env/mingw-head-head-head- 20041028 Thread model: win32 gcc version 4.0.0 20041028 (experimental) i686-pc-mingw32 Windows XP SP2 Professional Pentium 4 1.4GHz 256MB binutils 2.15.94 20041028 mingwrt mainline 20041028 msvcrt 7.0.2600.2180 w32api mainline 20041028 libiconv 1.9.1 gmp 4.1.4 mpfr 2.0.3 GNU Make 3.80 expect 5.26 tcl 8.4 dejagnu 1.4.2.x Misc tools and environment from Cygwin Current Fri Oct 22 01:50:41 2004 ln with softlinks disabled host gcc 3.4.1 (mingw special) host binutils 2.15.91 20040904 (mingw) host mingwrt 3.5 host w32api 3.1 Is there any particular debugging information you'd like for me to give you? -- What|Removed |Added Last reconfirmed|-00-00 00:00:00 |2004-10-30 05:02:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17666
[Bug ada/17666] Ada tests hanging during make check
--- Additional Comments From aaronavay62 at aaronwl dot com 2004-10-30 05:05 --- Oops, for what its worth, those configuration specs are completely wrong--copied and pasted from the wrong place. These are the correct specs for the configuration that the bug was reconfirmed on for 20041028: Reading specs from /aaronwl/cs/env/mingw-head-head-head-20041028/lib/gcc/i686- pc-mingw32/4.0.0/specs Configured with: ../../src/cvs/head/gcc/configure --enable- languages=ada,c,c++,f95,java,objc --with-dwarf2 --enable-libmudflap --enable- libgcj --with-win32-nlsapi=unicows --enable-libstdcxx-allocator=mt --enable- libstdcxx-debug --enable-concept-checks --prefix=/aaronwl/cs/env/mingw-head- head-head-20041028 --with-included-gettext --with-libiconv- prefix=/aaronwl/cs/internat/iconv/install --with-gmp=/aaronwl/cs/env/mingw- head-head-head-20041028 --with-mpfr=/aaronwl/cs/env/mingw-head-head-head- 20041028 Thread model: win32 gcc version 4.0.0 20041028 (experimental) i686-pc-mingw32 Windows XP SP2 Professional Pentium 4 1.4GHz 256MB binutils 2.15.94 20041028 mingwrt mainline 20041028 msvcrt 7.0.2600.2180 w32api mainline 20041028 libiconv 1.9.1 gmp 4.1.4 mpfr 2.0.3 GNU Make 3.80 expect 5.26 tcl 8.4 dejagnu 1.4.2.x Misc tools and environment from Cygwin Current Fri Oct 22 01:50:41 2004 ln with softlinks disabled host gcc 3.4.1 (mingw special) host binutils 2.15.91 20040904 (mingw) host mingwrt 3.5 host w32api 3.1 -- What|Removed |Added Last reconfirmed|2004-10-30 05:02:32 |2004-10-30 05:05:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17666
[Bug target/18151] Disable building of fixincludes for avr target.
--- Additional Comments From aaronavay62 at aaronwl dot com 2004-10-28 19:49 --- Oops, I beat you to it. :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18151
[Bug bootstrap/17832] [4.0 Regression] Bootstrap broken by fixincludes failures
--- Additional Comments From aaronavay62 at aaronwl dot com 2004-10-27 20:17 --- Fixed on mainline. I think this is the end of fixincludes problems for Windows. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17832
[Bug other/17462] Cannot compile fixincl.c on windows hosts
-- Bug 17462 depends on bug 17832, which changed state. Bug 17832 Summary: [4.0 Regression] Bootstrap broken by fixincludes failures http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17832 What|Old Value |New Value Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17462
[Bug bootstrap/18107] [4.0 Regression] Bootstrap fails on i686-pc-mingw32
-- Bug 18107 depends on bug 17832, which changed state. Bug 17832 Summary: [4.0 Regression] Bootstrap broken by fixincludes failures http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17832 What|Old Value |New Value Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18107
[Bug libfortran/18103] libgfortran system header conflict breaks bootstrap on MinGW
--- Additional Comments From aaronavay62 at aaronwl dot com 2004-10-27 20:36 --- In addition to the patch in comment #1, this patch is also needed to fix this bug: http://gcc.gnu.org/ml/gcc-patches/2004-10/msg02416.html. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18103
[Bug libfortran/18105] Compile errors in libgfortran/io/unix.c break Windows bootstrap
--- Additional Comments From aaronavay62 at aaronwl dot com 2004-10-27 20:37 --- Revised patch here: http://gcc.gnu.org/ml/gcc-patches/2004-10/msg02417.html. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18105
[Bug libfortran/18105] Compile errors in libgfortran/io/unix.c break Windows bootstrap
--- Additional Comments From aaronavay62 at aaronwl dot com 2004-10-27 21:19 --- Revised patch here: http://gcc.gnu.org/ml/gcc-patches/2004-10/msg02422.html (honest). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18105
[Bug bootstrap/17832] [4.0 Regression] Bootstrap broken by fixincludes failures
--- Additional Comments From aaronavay62 at aaronwl dot com 2004-10-26 21:51 --- Sorry, I missed putting the PR tag in the commit log. However, no, this bug really should not be closed yet. That patch just disabled building fixincludes. The real patch that needs to be committed is in #8, which will make fixincludes build appropriately when its needed, such as in *-mingw32's case, when crosscompiling. It needs to be reviewed by Bruce Korb, I think. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17832
[Bug bootstrap/18107] [4.0 Regression] Bootstrap fails on i686-pc-mingw32
-- What|Removed |Added BugsThisDependsOn||18139 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18107
[Bug c/18139] New: [4.0 Regression] GCC miscompiles libcpp/charset.c
-omit-frame-pointer -Wextra -Wall -D_GNU_SOURCE -DPREFIX=\/aaronwl/cs/env/mingw-head-head-head-20041023\ -DLIBDIR=\/aaronwl/cs/env/mingw-head-head-head-20041023/lib\ -DBOOT_CLASS_PATH=\/aaronwl/cs/env/mingw-head-head-head-20041023/share/java/libgcj-4.0.0.jar\ -DJAVA_EXT_DIRS=\/aaronwl/cs/env/mingw-head-head-head-20041023/share/java/ext\ -g -O2 -MT java/io/natFile.lo -MD -MP -MF java/io/.deps/natFile.Tpo -c java/io/natFile.cc -o java/io/natFile.o In file included from ./include/java-gc.h:29, from ../../../../src/cvs/head/gcc/libjava/include/jvm.h:25, from ./include/platform.h:33, from java/io/natFile.cc:12: ../boehm-gc/include/gc_config.h:113:1: warning: PACKAGE_NAME redefined In file included from java/io/natFile.cc:11: ./include/config.h:399:1: warning: this is the location of the previous definition In file included from ./include/java-gc.h:29, from ../../../../src/cvs/head/gcc/libjava/include/jvm.h:25, from ./include/platform.h:33, from java/io/natFile.cc:12: ../boehm-gc/include/gc_config.h:116:1: warning: PACKAGE_STRING redefined In file included from java/io/natFile.cc:11: ./include/config.h:402:1: warning: this is the location of the previous definition In file included from ./include/java-gc.h:29, from ../../../../src/cvs/head/gcc/libjava/include/jvm.h:25, from ./include/platform.h:33, from java/io/natFile.cc:12: ../boehm-gc/include/gc_config.h:119:1: warning: PACKAGE_TARNAME redefined In file included from java/io/natFile.cc:11: ./include/config.h:405:1: warning: this is the location of the previous definition In file included from ./include/java-gc.h:29, from ../../../../src/cvs/head/gcc/libjava/include/jvm.h:25, from ./include/platform.h:33, from java/io/natFile.cc:12: ../boehm-gc/include/gc_config.h:122:1: warning: PACKAGE_VERSION redefined In file included from java/io/natFile.cc:11: ./include/config.h:408:1: warning: this is the location of the previous definition java/io/natFile.cc:170: 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[3]: *** [java/io/natFile.lo] Error 1 Program received signal SIGSEGV, Segmentation fault. 0x in ?? () from (gdb) bt #0 0x in ?? () from #1 0x0092b892 in cpp_interpret_string (pfile=0x1791a00, from=0x1791c68, count=1, to=0x22fe34, wide=1 '\001') at ../../../src/cvs/head/gcc/libcpp/charset.c:1168 #2 0x0092c05c in cpp_interpret_charconst (pfile=0x1791a00, token=0x1791c60, pchars_seen=0x22fea4, unsignedp=0x22fea8) at ../../../src/cvs/head/gcc/libcpp/charset.c:1347 #3 0x0053cdad in c_lex_with_flags (value=0x1882054, cpp_flags=0x1882052 '¯' repeats 200 times...) at ../../../src/cvs/head/gcc/gcc/c-lex.c:800 #4 0x0049d11d in cp_lexer_get_preprocessor_token (lexer=Variable lexer is not available. ) at ../../../src/cvs/head/gcc/gcc/cp/parser.c:384 #5 0x004b374c in c_parse_file () at ../../../src/cvs/head/gcc/gcc/cp/parser.c:281 #6 0x00545245 in c_common_parse_file (set_yydebug=0) at ../../../src/cvs/head/gcc/gcc/c-opts.c:1095 #7 0x00666c20 in toplev_main (argc=0, argv=0x3d41f0) at ../../../src/cvs/head/gcc/gcc/toplev.c:986 #8 0x00401183 in __mingw_CRTStartup () at ../../../src/cvs/runtime/crt1.c:207 #9 0x00401208 in mainCRTStartup () at ../../../src/cvs/runtime/crt1.c:227 Due to optimization, GDB wasn't able to print any of the interesting-looking variables. -- Summary: [4.0 Regression] GCC miscompiles libcpp/charset.c Product: gcc Version: 4.0.0 Status: UNCONFIRMED Keywords: wrong-code, build Severity: critical Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: aaronavay62 at aaronwl dot com CC: gcc-bugs at gcc dot gnu dot org GCC target triplet: i686-pc-mingw32 OtherBugsDependingO 18107 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18139
[Bug c/18139] [4.0 Regression] GCC miscompiles libcpp/charset.c
--- Additional Comments From aaronavay62 at aaronwl dot com 2004-10-25 06:31 --- For what its worth, this bug wasn't introduced recently. It was failing at least since June 1st, 2004. I'll continue to search for offending changes. This may take a few days. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18139
[Bug c++/17526] [4.0 Regression] locale_facets.cc:47: internal compiler error
--- Additional Comments From aaronavay62 at aaronwl dot com 2004-10-25 19:48 --- I also don't think this is a C++ bug: its a bug in whatever compiled libcpp, which probably wasn't a C++ compiler. Also, does this affect all x86 targets? Does it affect i?86-pc-linux*? The testcase can be simplified; parsing any wide character literal with the miscompiled libcpp will cause the ICE, such as simply L'c'. -- What|Removed |Added GCC target triplet|i386-freebsd5.1, i?86- |i386-freebsd5.1, i?86- |openbsd3.1 |openbsd3.1, i?86-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17526
[Bug bootstrap/17832] [4.0 Regression] Bootstrap broken by fixincludes failures
--- Additional Comments From aaronavay62 at aaronwl dot com 2004-10-21 21:28 --- Well, I was a little confused earlier, and perhaps I still am. Should fixincludes be built on target=mingw bootstraps? I don't think so; as far as I know, its only needed for crosses. But perhaps there might be some good reason to enable it anyway? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17832
[Bug other/17462] Cannot compile fixincl.c on windows hosts
--- Additional Comments From aaronavay62 at aaronwl dot com 2004-10-21 21:30 --- I think this is actually a duplicate of PR17832, but I don't appear to have the ability to alter the state of bugs. Can someone mark this as a duplicate? -- What|Removed |Added BugsThisDependsOn||17832 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17462
[Bug other/17462] Cannot compile fixincl.c on windows hosts
-- What|Removed |Added CC||aaronavay62 at aaronwl dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17462
[Bug fortran/18103] New: libgfortran system header conflict breaks bootstrap on MinGW
mingw-runtime has a system header called io.h (low-level UNIXish I/O routines). This conflicts with libgfortran/io/io.h when io.h is included, causing bootstrap to fail when libgfortran is built. -- Summary: libgfortran system header conflict breaks bootstrap on MinGW Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: aaronavay62 at aaronwl dot com CC: gcc-bugs at gcc dot gnu dot org GCC target triplet: i686-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18103
[Bug libfortran/18103] libgfortran system header conflict breaks bootstrap on MinGW
--- Additional Comments From aaronavay62 at aaronwl dot com 2004-10-22 02:56 --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2004-09/msg01609.html -- What|Removed |Added Component|fortran |libfortran Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18103
[Bug java/18104] New: Incorrect CLASSPATH separator in libjava breaks bootstrap
The libjava Makefiles are hardwired to use ':' as a CLASSPATH separator. Gcj, however, picks the separator based on system-specific configuration, and so correctly chooses ';' on MinGW. This will cause bootstrap in libjava to fail when the incorrect CLASSPATH separator as used, as it sees all components of the CLASSPATH as a single file, and so cannot find any files. -- Summary: Incorrect CLASSPATH separator in libjava breaks bootstrap Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: aaronavay62 at aaronwl dot com CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org GCC target triplet: i686-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18104
[Bug java/18104] Incorrect CLASSPATH separator in libjava breaks bootstrap
--- Additional Comments From aaronavay62 at aaronwl dot com 2004-10-22 03:03 --- A proposed patch is here: http://gcc.gnu.org/ml/gcc-patches/2004-09/msg02853.html. The Windows GCC Java community has been using a patch similar to this for years. -- What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18104
