[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 : 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 provided by GCC, assuming that it will play well. However, GCC's needs std::streamsize, and assumes will provide it. , 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 , 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 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 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 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 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 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 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 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 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 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 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 , 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/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 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 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 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 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 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 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 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/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' :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 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] [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 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 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 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)
public unsigned SI
size
unit size
align 32 symtab 79753888 alias set -1 canonical type 041F5D68
pointer_to_this >
BLK
align 32 symtab 0 alias set -1 canonical type 04C0EDD0
pointer_to_this >
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__") ) [2 __CTOR_LIST__+0 A32]) chain >
--
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)
sizes-gimplified asm_written visited QI
size
unit size
align 8 symtab 64062056 alias set -1 canonical type 03D141A0
arg-types >
pointer_to_this >
sizes-gimplified visited unsigned SI
size
unit size
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
unit size
align 32
(mem/v/f/c/i:SI (symbol_ref:SI ("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 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=,
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 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=15987&action=view) Allocate argv array first -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36968
[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 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 debug/17406] [4.0 regression] ICE dwarf2out_frame_debug_expr, at dwarf2out.c:1692
--- Additional Comments From aaronavay62 at aaronwl dot com 2004-10-13 07:27 --- Sorry for the delay. My bootstrap kept breaking, and the full cycle appears to take about 48 hours to complete. I can preliminarily say that this patch does indeed appear to fix this problem, but I have not yet completed regression testing. I will report back when it is done (sometime before the next ice age). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17406
[Bug other/17991] New: [4.0 Regression] Two-process fixincludes broken: pz_mn_name_pat undefined
This patch appears to have broken two-process fixincludes:
<http://gcc.gnu.org/ml/gcc-patches/2004-08/msg02301.html>. When attempting to
link applyfix.exe, link fails because pz_mn_name_pat is undefined.
The two-process mode is only used for MS-DOS and BeOS, which is probably why
noone noticed. I noticed because it appears that, other than this and some
other soon-to-be-fixed problems, two process fixincludes also works for
Windows.
The problem is that mn_name_pat was made into an environment variable, which
are only defined in fixincl.c, which is only included in the fixincl
executable. However, it is used in fixlib.c, which is included in the
applyfix executable in a two-process build.
As I'm not really familiar with fixincludes, I can't say how this should be
fixed. It can be worked around by copying the environment variable
definitions and initializations from fixincl.c to the SEPARATE_FIX_PROC
section of fixfixes.c, but I'm not sure this is appropriate as applyfix
doesn't need any of these environment variables otherwise. Perhaps just this
single environment variable could be defined.
--
Summary: [4.0 Regression] Two-process fixincludes broken:
pz_mn_name_pat undefined
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: critical
Priority: P2
Component: other
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: i?86-*-mingw32, i?86-*-msdosdjgpp, *-*-beos*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17991
[Bug other/17991] [4.0 Regression] Two-process fixincludes broken: pz_mn_name_pat undefined
-- What|Removed |Added Keywords||build http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17991
[Bug other/17991] [4.0 Regression] Two-process fixincludes broken: pz_mn_name_pat undefined
-- What|Removed |Added OtherBugsDependingO||17832 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17991
[Bug bootstrap/17832] [4.0 Regression] Bootstrap broken by fixincludes failures
--- Additional Comments From aaronavay62 at aaronwl dot com 2004-10-14 09:17 --- I think fixincludes is very close to building on Windows, and so probably should not be disabled after all for this target, since its needed in some configurations. Presumably the other targets still should be disabled. All that is needed to make it build is resolution to PR 17991, a patch to enable two-process fixincludes for i?86-*-mingw32*, and a patch that does the equivilent of <http://gcc.gnu.org/ml/gcc-patches/2004-09/msg01393.html>. I will probably resubmit a version of the latter tomorrow that addresses the comments here <http://gcc.gnu.org/ml/gcc-patches/2004-10/msg01045.html>. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17832
[Bug debug/17406] [4.0 regression] ICE dwarf2out_frame_debug_expr, at dwarf2out.c:1692
--- Additional Comments From aaronavay62 at aaronwl dot com 2004-10-15 19:58 --- I can confirm that this patch fixes this bug and causes no testsuite regressions. :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17406
[Bug other/17991] [4.0 Regression] Two-process fixincludes broken: pz_mn_name_pat undefined
--- Additional Comments From aaronavay62 at aaronwl dot com 2004-10-16 00:35 --- Something isn't right with the patch. The ChangeLog mentions a function fix_with_system() that does not appear to exist. The build fails because z_applyfix_prog's initializer doesn't match its type, and fixing that generates some other warnings expecting z_applyfix_prog to be a string rather than an array of strings. Is part of it missing? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17991
[Bug debug/17406] [4.0 regression] ICE dwarf2out_frame_debug_expr, at dwarf2out.c:1692
--- Additional Comments From aaronavay62 at aaronwl dot com 2004-10-07 06:43 --- I've started a bootstrap and regression test cycle of current mainline with this patch. This will probably take about 24 hours on i686-pc-mingw32. (Thats another thing I wouldn't mind seeing fixed.) I'll post again with any regressions or other problems when its done. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17406
[Bug other/17991] [4.0 Regression] Two-process fixincludes broken: pz_mn_name_pat undefined
--- Additional Comments From aaronavay62 at aaronwl dot com 2004-10-19 19:25 --- Yes, this fixes the problems. Thanks! Two-process fixincludes now builds. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17991
[Bug bootstrap/17832] [4.0 Regression] Bootstrap broken by fixincludes failures
--- Additional Comments From aaronavay62 at aaronwl dot com 2004-10-20 08:39 --- One more patch left to be reviewed, besides PR17991: <http://gcc.gnu.org/ml/gcc-patches/2004-10/msg01618.html>. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17832
[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 (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
[Bug libfortran/18103] libgfortran system header conflict breaks bootstrap on MinGW
--- Additional Comments From aaronavay62 at aaronwl dot com 2004-10-22 03:03 --- Oops, that was definitely the wrong URL. The right URL for the patch is: <http://gcc.gnu.org/ml/gcc-patches/2004-09/msg02853.html>. -- 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 03:05 --- Forgot that last message. The original patch URL was correct. Error between keyboard and chair. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18103
[Bug libfortran/18105] New: Compile errors in libgfortran/io/unix.c break Windows bootstrap
MinGW doesn't have the macros S_IRGRP, S_IWGRP, S_IROTH, or S_IWOTH that are used in unix.c. It also does not have mkstemp(). There is a mkstemps() in libiberty, but it does not appear to be usable for this: <http://gcc.gnu.org/ml/gcc/2004-09/msg00949.html>. -- Summary: Compile errors in libgfortran/io/unix.c break Windows bootstrap Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libfortran 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=18105
[Bug libfortran/18105] Compile errors in libgfortran/io/unix.c break Windows bootstrap
--- Additional Comments From aaronavay62 at aaronwl dot com 2004-10-22 03:20 --- Patch here: <http://gcc.gnu.org/ml/gcc-patches/2004-10/msg01171.html>. The identifiers are defined if not, and temporary files are created with mktemp() if mkstemp() is not availible. -- What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18105
[Bug target/18106] New: Weak symbols are unimplemented on Windows
On Windows targets, weak symbols have not supported in GCC, and have never been supported. However, they have been supported in binutils for years, with varying degrees of quality. They are probably now reliable enough to be supported by GCC. -- Summary: Weak symbols are unimplemented on Windows Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: enhancement 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 target triplet: i686-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18106
[Bug target/18106] Weak symbols are unimplemented on Windows
--- Additional Comments From aaronavay62 at aaronwl dot com 2004-10-22 03:42 --- Patch here: <http://gcc.gnu.org/ml/gcc-patches/2004-10/msg01656.html>. -- What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18106
[Bug bootstrap/18107] New: [4.0 Regression] Bootstrap fails on i686-pc-mingw32
This is a meta-bug for all of the things causing a Windows bootstrap to fail. This should be closed when i686-pc-mingw32 successfully completes a full bootstrap. -- Summary: [4.0 Regression] Bootstrap fails on i686-pc-mingw32 Product: gcc Version: 4.0.0 Status: UNCONFIRMED Keywords: meta-bug Severity: critical Priority: P2 Component: bootstrap AssignedTo: aaronavay62 at aaronwl dot com 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 BugsThisDependsOn: 17406,17832,18103,18104,18105 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18107
[Bug bootstrap/17832] [4.0 Regression] Bootstrap broken by fixincludes failures
-- What|Removed |Added OtherBugsDependingO||18107 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17832
[Bug debug/17406] [4.0 regression] ICE dwarf2out_frame_debug_expr, at dwarf2out.c:1692
-- What|Removed |Added OtherBugsDependingO||18107 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17406
[Bug libfortran/18103] libgfortran system header conflict breaks bootstrap on MinGW
-- What|Removed |Added OtherBugsDependingO||18107 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18103
[Bug libfortran/18105] Compile errors in libgfortran/io/unix.c break Windows bootstrap
-- What|Removed |Added OtherBugsDependingO||18107 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18105
[Bug java/18104] Incorrect CLASSPATH separator in libjava breaks bootstrap
-- What|Removed |Added OtherBugsDependingO||18107 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18104
[Bug other/17462] Cannot compile fixincl.c on windows hosts
--- Additional Comments From aaronavay62 at aaronwl dot com 2004-10-22 05:21 --- *** This bug has been marked as a duplicate of 17832 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17462
[Bug bootstrap/17832] [4.0 Regression] Bootstrap broken by fixincludes failures
--- Additional Comments From aaronavay62 at aaronwl dot com 2004-10-22 05:21 --- *** Bug 17462 has been marked as a duplicate of this bug. *** -- 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 Status|UNCONFIRMED |ASSIGNED Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-10-22 05:29:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18107
[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
src/cvs/head/gcc/libjava/../libffi/include -I../libffi/include -O2
-g -O2 -fno-rtti -fnon-call-exceptions -fdollars-in-identifiers -Wswitch-enum
-D_FILE_OFFSET_BITS=64 -ffloat-store -fno-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 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 '¯' ...)
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-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/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
