Closed dmik closed 8 years ago
Hi all,
I'm not sure why the i386-arch was maintained/supported for such a long time. IIRC from eCS v1.2? the 386-cpu (or even 486) is not supprted anymore. With regard to Pentium4 (netburst) and the base of the current intel cpus (iirc pentiom m) there is a difference between those wrt the generation of optimized code.
Regards, Ben.
2015-12-14 5:41 GMT+08:00, Dmitriy Kuminov notifications@github.com:
The i386 target is really old and makes problems (some applications like Mozilla are simply cannot be built in this mode) so we should consider switching the default architecture to i686. See also #19 and http://trac.netlabs.org/rpm/ticket/151.
Reply to this email directly or view it on GitHub: https://github.com/psmedley/gcc/issues/20
Hi Guys,
Taking a look at this now. Looks like the target architecture is based on the output of uname -m
The 'easy' way around this is to specify --build=i686-pc-os2-emx --target=i686-pc-os2-emx to gcc's configure
There are also a couple of diffs required where i386-pc-os2-emx is specified instead of i?86-pc-os2-emx
Running a build now - will see if it completes ok.
Cheers,
Paul
On 25/12/15 02:51, Ben Rietbroek wrote:
Hi all,
I'm not sure why the i386-arch was maintained/supported for such a long time. IIRC from eCS v1.2? the 386-cpu (or even 486) is not supprted anymore. With regard to Pentium4 (netburst) and the base of the current intel cpus (iirc pentiom m) there is a difference between those wrt the generation of optimized code.
Regards, Ben.
2015-12-14 5:41 GMT+08:00, Dmitriy Kuminov notifications@github.com:
The i386 target is really old and makes problems (some applications like Mozilla are simply cannot be built in this mode) so we should consider switching the default architecture to i686. See also #19 and http://trac.netlabs.org/rpm/ticket/151.
Reply to this email directly or view it on GitHub: https://github.com/psmedley/gcc/issues/20
— Reply to this email directly or view it on GitHub https://github.com/psmedley/gcc/issues/20#issuecomment-167132604.
Aha, that simple! It's very interesting if it works and which arch it will generate assembly for by default when succeeded :)
[U:\DEV\gcc-4.9.2]gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=U:/usr/local492/bin/../libexec/gcc/i686-pc-os2-emx/4.9.2/lto
-wrapper.exe
Target: i686-pc-os2-emx
Configured with: ./configure --prefix=/usr/local492 --enable-shared --enable-languages=c,c++,fortran --with-gnu-as --enable-frame-pointer --disable-bootstrap --
disable-libstdcxx-pch --enable-threads --build=i686-pc-os2-emx --target=i686-pc-os2-emx
Thread model: os2
gcc version 4.9.2 (GCC)
On 25/12/15 07:22, Dmitriy Kuminov wrote:
Aha, that simple! It's very interesting if it works and which arch it will generate assembly for by default when succeeded :)
— Reply to this email directly or view it on GitHub https://github.com/psmedley/gcc/issues/20#issuecomment-167158826.
Great! Did any patching besides --build=i686-pc-os2-emx --target=i686-pc-os2-emx
become necessary? If so, could you please commit it?
Nope, no other changes required for the gcc-git. I suspect however, that binutils would benefit from a recompile with the same configure changes to ensure gas is built for i686.....
On 25/12/15 07:38, Dmitriy Kuminov wrote:
Great! Did any patching besides |--build=i686-pc-os2-emx --target=i686-pc-os2-emx| become necessary? If so, could you please commit it?
— Reply to this email directly or view it on GitHub https://github.com/psmedley/gcc/issues/20#issuecomment-167159744.
I see. Well, this issue may be closed then I suppose.
The i386 target is really old and makes problems (some applications like Mozilla are simply cannot be built in this mode) so we should consider switching the default architecture to i686. See also #19 and http://trac.netlabs.org/rpm/ticket/151.