Consider switching the target architecture from i386 to i686 by default

[dmik]

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.

[rousseaux]

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

[psmedley]

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.

[dmik]

Aha, that simple! It's very interesting if it works and which arch it will generate assembly for by default when succeeded :)

[psmedley]

[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.

[dmik]

Great! Did any patching besides --build=i686-pc-os2-emx --target=i686-pc-os2-emx become necessary? If so, could you please commit it?

[psmedley]

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.

[dmik]

I see. Well, this issue may be closed then I suppose.