[Bug boehm-gc/43682] libgcj don't support Win x64?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43682 --- Comment #2 from Chen Chen 2011-01-07 17:17:05 UTC --- I know it's about boehm-gc, and I've found that they have been solved in the upstream. I come here one year ago to ask for a merge. I cannot handle the multilib Makefile of boehm-gc... This problem made us hard to port the complete workbench from MSVC to gcc because we need pure win64 platform. We want a tool to convert Java directly into fast-running binarys, comparing to Sun's or OpenJDK.
[Bug boehm-gc/43682] libgcj don't support Win x64?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43682 --- Comment #4 from Chen Chen 2011-11-20 07:18:28 UTC --- I've noticed the gc-7.2alpha6.tar.gz have released. The Boehm-GC has been a major obscure for the gcj port of Mingew64 I think... (embarrassed) http://www.hpl.hp.com/personal/Hans_Boehm/gc/gc_source/
[Bug bootstrap/43420] New: a small miscode in binutils/readelf.c
on line 6197 to 6205:
unsigned char buf[5];
unsigned int i, len;
unsigned long offset;
for (i = 0; i < 9; i++)
{
GET_OP (buf[i]);
if ((buf[i] & 0x80) == 0)
break;
}
An obviously small wrong definition on the size of buf, which will cause
cc1.exe to treat warnings as errors.
Change size [5] to [9], am I right?
--
Summary: a small miscode in binutils/readelf.c
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: trivial
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: aflyhorse at foxmail dot com
GCC build triplet: i686-pc-mingw32
GCC host triplet: i686-pc-mingw32
GCC target triplet: x86_64-w64-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43420
[Bug target/42886] [4.5 Regression] GCC is not relocatable anymore on Windows (mingw32)
--- Comment #6 from aflyhorse at foxmail dot com 2010-03-22 01:00 --- In my recent build I configured the binutils as: ../src/configure --target=x86_64-w64-mingw32 --enable-targets=x86_64-w64-mingw32,i686-w64-mingw32 --disable-shared --enable-static --disable-nls --with-mpc=/local --with-gmp=/local --with-mpfr=/local --with-ppl=/local --with-cloog=/local --prefix=/mingw64 --with-sysroot=/mingw64 CFLAGS="-O3 -fomit-frame-pointer -pipe -march=k8 -mfpmath=sse -mmmx -m3dnow -m64 -Wa,-march=k8" LDFLAGS="-s -Wl,--as-needed" and the gcc as: ../src/configure --target=x86_64-w64-mingw32 --enable-targets=all --enable-multilib --enable-64bit --prefix=/mingw64 --with-sysroot=/mingw64 --disable-shared --enable-static --disable-nls --enable-version-specific-runtime-libs --with-dwarf --with-mpc=/local --with-mpfr=/local --with-gmp=/local --with-ppl=/local --with-cloog=/local --enable-fully-dynamic-string --enable-languages=c,c++,fortran,java --disable-libgomp --enable-libjava-multilib --with-host-libstdcxx='-lstdc++ -lsupc++' --with-pkgversion='LunarShaddow - for my Helen' CFLAGS='-O3 -fomit-frame-pointer -pipe -march=k8 -mfpmath=sse -mmmx -m3dnow -Wa,-march=k8' LDFLAGS='-s -Wl,--as-needed' Just omit the optimization options and you'll find the use of prefix and sysroot. ensure that you use the same sysroot while building binutils. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42886
[Bug rtl-optimization/43477] New: -march=k8-sse3 on turion-rm75 failed
i'm using amd turion RM75 CPU under msys-mingw64
i want to make a fully optimized gcc of my own, so first i generated a general
version of gcc. when i was making binutils the second time with -march=k8-sse3,
i got this message:
gcc -o chew.$$ -O3 -fomit-frame-pointer -pipe -march=k8-sse3 -mfpmath=sse -m64
-
mthreads -minline-stringops-dynamically -mcmodel=large -s -Wl,--as-needed \
-I.. -I../../../src/bfd/doc/.. -I../../../src/bfd/doc/../../include
-
I../../../src/bfd/doc/../../intl -I../../intl ../../../src/bfd/doc/chew.c; \
/bin/sh ../../../src/bfd/doc/../../move-if-change chew.$$ chew.exe
../../../src/bfd/doc/chew.c: In function 'push_number':
../../../src/bfd/doc/chew.c:403:10: warning: cast from pointer to integer of
dif
ferent size
../../../src/bfd/doc/chew.c: In function 'compile':
../../../src/bfd/doc/chew.c:1364:29: warning: cast to pointer from integer of
di
fferent size
../../../src/bfd/doc/chew.c: In function 'bang':
../../../src/bfd/doc/chew.c:1386:4: warning: cast to pointer from integer of
dif
ferent size
../../../src/bfd/doc/chew.c: In function 'atsign':
../../../src/bfd/doc/chew.c:1395:13: warning: cast to pointer from integer of
di
fferent size
../../../src/bfd/doc/chew.c:1571:1: error: unable to find a register to spill
in
class 'AREG'
../../../src/bfd/doc/chew.c:1571:1: error: this is the insn:
(insn 1666 1663 1668 74 ../../../src/bfd/doc/chew.c:1235 (set (mem/f/c/i:DI
(sym
bol_ref:DI ("tos") [flags 0x2] ) [10 tos+0 S8
A12
8])
(symbol_ref:DI ("stack") [flags 0x2] ))
90 {*movabsdi_1_rex64} (expr_list:REG_EQUAL (symbol_ref:DI ("stack") [flags
0x2
] )
(nil)))
../../../src/bfd/doc/chew.c:1571:1: internal compiler error: in spill_failure,
a
t reload1.c:2158
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
i don't know whether it's a bug of gcc or simply AMD hadn't fully supported
SSE3
thx
--
Summary: -march=k8-sse3 on turion-rm75 failed
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: aflyhorse at foxmail dot com
GCC host triplet: x86_64-w64-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43477
[Bug rtl-optimization/43477] -march=k8-sse3 on turion-rm75 failed
--- Comment #1 from aflyhorse at foxmail dot com 2010-03-22 15:08 --- in additional, i'm using the 20100317 version of gcc 4.5.0 and binutils 2.20.51 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43477
[Bug rtl-optimization/43477] -march=k8-sse3 on turion-rm75 failed
--- Comment #3 from aflyhorse at foxmail dot com 2010-03-23 16:30 --- (In reply to comment #2) > We need a testcase to reproduce the bug (preprocessed source). You also > might want to try removing -mcmodel=large (you really shouldn't need that). I've tryed to remove all newly added optimize option seperately, and only remove the -mcmodel doesn't work. The resolving way is to remove all the options concerning sse3 (including -march=k8-sse3 -mtune=k8-sse3 -Wa,march=k8+sse3; use -march=k8 and -nsse3 produce the same error). I am building binutils (SVN 20100317) at that time. I have tried various way of CCFLAGS struggling to avoid this problem. In addition, file: /libcpp/files.c: Line 609-614: comparison is always false under win x64 and /gcc/emit-rtl.c: Line 361: /gcc/ggc-common.c: Line 310: /gcc/graphite-dependences.c: Line 107: /gcc/src/gcc/ira-conflicts.c: Line 125: /gcc/src/gcc/pointer-set.c: Line 67: /gcc/src/gcc/tree dump: Line 168: /gcc/src/gcc/cp/class.c: Line 6740, 6742, 6764, 6767, 6900: all have host-dependent code such as explictly cast a pointer to long (in win x64 means long long to long) and use %ld or &lx to fprintf a pointer. they cause the cc1 treat warnings as error and stop the make procedure, though they are easy to fix manually but quite annoying while making bootstrap. (These are gcc 4.5.0 20100322 version source) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43477
[Bug rtl-optimization/43477] -march=k8-sse3 on turion-rm75 failed
--- Comment #4 from aflyhorse at foxmail dot com 2010-03-24 00:26 --- Hmmm... i don't know if it is useful to give you the configure option i did at that time... Happy i have a habit of recording every command i used during installation: $ ../src/configure --build=x86_64-w64-mingw32 --enable-targets=x86_64-w64-mingw32,i686-w64-mingw32 --disable-shared --enable-static --disable-nls --with-mpc=/local --with-gmp=/local --with-mpfr=/local --with-ppl=/local --with-cloog=/local --prefix=/mingw64 --with-sysroot=/mingw64 CFLAGS="-march=k8-sse3 -mfpmath=sse -m64 -mthreads -minline-stringops-dynamically -mcmodel=large -Wa,-march=k8+sse3" LDFLAGS="-s -Wl,--as-needed" maybe it's not gcc's fault because the libc mingw-w64 migrated is so old... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43477
[Bug target/43613] New: Some architecture-dependent codes
Sorry to duplicately reporting this bug, but i failed to get a feedback after i announced it after another small bug unfortunately. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43477 /libcpp/files.c: Line 609-614: comparison is always false under win x64 and /gcc/emit-rtl.c: Line 361: /gcc/ggc-common.c: Line 310: /gcc/graphite-dependences.c: Line 107: /gcc/src/gcc/ira-conflicts.c: Line 125: /gcc/src/gcc/pointer-set.c: Line 67: /gcc/src/gcc/tree dump: Line 168: /gcc/src/gcc/cp/class.c: Line 6740, 6742, 6764, 6767, 6900: all have host-dependent code such as explictly cast a pointer to long (in win x64 means long long to long) and use %ld or &lx to fprintf a pointer. they cause the cc1 treat warnings as error and stop the make procedure, though they are easy to fix manually but quite annoying while making bootstrap. maybe needs to change their type to be ssize_t & size_t? (These are gcc 4.5.0 20100322 version source) -- Summary: Some architecture-dependent codes Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: aflyhorse at foxmail dot com GCC build triplet: x86_64-w64-mingw32 GCC host triplet: x86_64-w64-mingw32 GCC target triplet: x86_64-w64-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43613
[Bug rtl-optimization/43477] -march=k8-sse3 on turion-rm75 failed
--- Comment #5 from aflyhorse at foxmail dot com 2010-04-01 01:04 --- Failed to build with sse3, i surrounded... -- aflyhorse at foxmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43477
[Bug target/43613] Some architecture-dependent codes
--- Comment #2 from aflyhorse at foxmail dot com 2010-04-01 08:23 --- Got your ideas and be sorry for i chobber the building tree of my computer and the tree of package, there shouldn't be /gcc/src in the path (I was confused when i'm looking for the file myself) that time i'm testing the --enable-hash-synchronization option And could you please tell me why I always fail to build libgcj (after make install type "gcj -v" it tells me that libgcj.spec is missing and i find no libgcj.a & .la in my lib directory) even if i added "--enable-libgcj --enable-libjava" in configure? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43613
[Bug target/43613] Some architecture-dependent codes
--- Comment #3 from aflyhorse at foxmail dot com 2010-04-01 08:26 --- Also, the compiler do stopped and treat warnings as errors while compiling ira-conflicts.c until i changed these 2 "%ld" to "%I64u" -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43613
[Bug other/43617] New: cloog-ppl 0.15.9's configure corrupts with funny codes
Sorry to distrub you all, but when i downloaded and untar the latest cloog-ppl
(which is one of the infrastructure of gcc). when i ./configure it, it fails to
find ppl (with --with-ppl=/local) and break down asking for PolyLib. When i
look into the configure script itself, i found it is corrupted.
12694: if test "x$with_ppl" != "x" -a "x$with_ppl" != "xno"; then
12702: if test "x$with_ppl" != "xyes" ; then
12843: if test "x$ac_cv_header_ppl_c_h" = x""yes; then
the last one is especially funny, isn't it?
Sorry i don't know where to report it, so i reported it here...
--
Summary: cloog-ppl 0.15.9's configure corrupts with funny codes
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: aflyhorse at foxmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43617
[Bug other/43617] cloog-ppl 0.15.9's configure corrupts with funny codes
--- Comment #2 from aflyhorse at foxmail dot com 2010-04-01 13:42 --- Sorry sir I've made a mistake... But since I've successfully build gmp & mpfr & mpc & ppl so i think there might be an error here... I configured it with: ../src/configure --build=x86_64-w64-mingw32 --with-ppl="" --with-gmp="" --prefix="" --with-host-libstdcxx="-lstdc++ -lsupc++" --disable-shared --enable-static CFLAGS="-O3 -fomit-frame-pointer -pipe -march=k8 -mfpmath=sse -m64 -Wa,-march=k8 -Wa,-mtune=k8" LDFLAGS="-s -Wl,--as-needed" it works for me on cloog-ppl 0.15.8 so i think it's a mistake of the tarball at that time... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43617
[Bug target/42886] [4.5 Regression] GCC is not relocatable anymore on Windows (mingw32)
--- Comment #9 from aflyhorse at foxmail dot com 2010-04-01 13:48 --- (In reply to comment #8) > I'd recommend closing this as invalid. We build 12 relocatable toolchains for > windows daily for http://mingw-w64.sf.net/ > > I'm pretty sure it works :) > Agree. I've made a bootstrap a week before and copied and merged it with the dev-cpp. Before i did this version i've moved a cross-compiled version from /msys/1.0/mingw64 to /msys/1.0/mingw for pretty look :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42886
[Bug target/42886] [4.5 Regression] GCC is not relocatable anymore on Windows (mingw32)
--- Comment #10 from aflyhorse at foxmail dot com 2010-04-01 13:58 --- night-strike can i ask a question that had x86_64-w64-mingw32 supported libgcj yet? I failed even explictly --enable-libgcj... and a so-called wiki of mingw-w64 (http://www.cadforte.com/wiki/index.php/Java) said "Java is, unfortunately, not supported in 64-bit by gcc at this time.", i don't know if it's true... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42886
[Bug other/43617] cloog-ppl 0.15.9's configure corrupts with funny codes
--- Comment #4 from aflyhorse at foxmail dot com 2010-04-02 10:33 --- (In reply to comment #3) > (In reply to comment #2) > > I configured it with: > > ../src/configure --build=x86_64-w64-mingw32 --with-ppl="" --with-gmp="" > > --prefix="" > that can't be right Why? I had also configured the gmp, mpc, mpfr & ppl with --prefix="" But the code is really working, with --ppl=/lib (I don't know why because I used to use /local instead of /local/lib but no error found...) Thanks you all! I've change the bug as invalid. -- aflyhorse at foxmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43617
[Bug boehm-gc/43682] New: libgcj don't support Win x64?
in /boehm-gc/mark.c, line 428-434:
context->Esp = context->Ebp;
context->Ebp = *((DWORD *)context->Esp);
context->Esp = context->Esp - 8;
context->Eip = (DWORD )(xer->alt_path);
So much x86-oriented register (E** but no R** for _WIN64),
does it mean libgcj (because of its default gc's fault or both) had not been
ported to Win x64?
In addition, a small bug:
in /boehm-gc/gc.h, line 87-89:
should explicitly add #include since no can be found
above,
and the second GC_word should be changed to GC_signed_word
Thx.
--
Summary: libgcj don't support Win x64?
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: boehm-gc
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: aflyhorse at foxmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43682
[Bug target/43613] Some architecture-dependent codes
--- Comment #4 from aflyhorse at foxmail dot com 2010-04-12 10:44 --- Maybe I should still choose the proprietary compiler of M$ for my Win_x64-target platform... -- aflyhorse at foxmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43613
[Bug target/43613] Some architecture-dependent codes
--- Comment #6 from aflyhorse at foxmail dot com 2010-04-13 10:58 --- (In reply to comment #5) > I don't get why you closed this bug. Anyways if you have a patch, post it to > gcc-patc...@. Sorry, I see nobody concerns this, and I'm more anxious about how to port the libgcj (especially boehm-gc) to win64, so I closed it. Maybe i should use the diff to release a patch for it~ (Since I'm a newbee I've never done so :P) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43613
[Bug target/43613] Some architecture-dependent codes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43613 Chen Chen changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #11 from Chen Chen --- Sure. After years I have to click "forgot my pwd" to regain this account. Thanks for all the hard works done by everyone.
