Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to the forum
Board view  Mix view

GCC 4.6.x invalid code generation (Developers)

posted by Rugxulo Homepage, Usono, 10.04.2012, 02:01

> This problem was discussed on DJGPP google group. I want to warn other
> users who didn't read it. I don't know if it may affect freepascal too (if
> it shares some optimize code with gcc or not)
I'm pretty sure that FPC doesn't use any GCC sources at all, not code generation nor backends, only lightly borrows or gleans from go32v2 (whatever that means specifically, I've not looked).

> I met this issue by my own when compiling FFMPEG for older machines -
> pentium1 and older. I used -march=pentium -mfpmath=387 -O3 opt.
> options for GCC and recompiled entire package that was cleaned up (any old
> code couldn't be used).
Right, I noticed you did that but I forget entirely about the GCC 4.6.x bug, so I didn't say anything explicitly (though it's already been briefly discussed in the comp.os.msdos.djgpp newsgroup).

> My friend tested it on AMD K6 machine but he got
> crash during MKV compression. MPEG1 went OK. It was illegal opcode
> exception. So I objdumped the EXE and revealed tens of CMOV instruction
> (P6+) in the DASM as I expected:
I swear it's in libcpp/lex.c , AFAICT. Yeah, it's an annoying bug. Sadly, I'm too dumb to fix it (weakly tried, though).

> I wonder that this bug is known for 1 year and still not fixed.
P3 priority, so it's far from important to them. GCC 4.8.0 release criteria explicitly says "i686" except for "i386-unknown-freebsd", and I would be surprised to learn that they indeed forbid 686+ opcodes there. PPro and PII are circa 1995-7, which is "old" to most modern developers, so they don't care to minimize targets for such "old" tech, presumably. Esp. since most Linux distros don't actively support anything older than 686 anymore.

> So be carefull if you use new GCC to produce code that must run on older
> machines!
I don't think many do anymore, even I don't for various silly reasons (hardware failure, mostly). They should run regression tests, but I get the feeling that their tests aren't as exhaustively tested as I'd like. (Though in fairness ten different options makes things exponentially more complex, so it's probably beyond their energy esp. since they presumably have "more important" things to do in "real life", blindly guessing here.)

> I will try some older versions that I had archived and check
> objdump when CMOV disappear. Other option may be disable -O but it's not
> propably good idea.
I think one person reported that using -O1 removed all except one CMOV.. for his test, but I can't confirm that.

> This problem also make me thinking about if there exist some x86 assembler
> code analyser that will recogize what instruction is supported on what CPU
> and will return minimum CPU type that given code will run OK. Do you know
> about something like this?
Only a good emulator perhaps, which will segfault or crash on invalid opcode. Doesn't QEMU have a -cpu flag? Otherwise, it's difficult because of self-modifying code and inadvertently disassembling data (which looks like code but isn't). E.g. DOSBox only supports a 486 DX with CPUID, nothing newer, so it's easy to test (crash!) there, heh.

EDIT: Forgot about dynamic instruction dispatching, e.g. checking CPUID and running appropriate code, e.g. my own lame fork of paq8o8 (paq8o8z). So any blind disassembly won't recognize that.

> EDIT:
> I tried objdump *.a -d |grep cmov in my DJGPP\LIB and found that
> some system libs (like libm.a) are also poluted with CMOV, damn!
I think that's a false positive. I'd be very surprised. I've run "stock" DJGPP on 586 machines before, so that can't be it. Unless you mean a recent compile of CVS snapshot with latest GCC 4.6.x, which is where the bug lies. Certainly "stock" DJGPP libc and libm from 2.03p2 used GCC 2.8.1 (no 686 optimizations available) and GCC 3.3.2 for 2.04 (and IIRC that never had any problems on my 586 [Pentium 166 with no MMX]).

The workaround is probably to just use an older GCC, e.g. 4.5.3 or even older. I don't think the bug exists there (though others might). At least 4.5.3 is still supported (barely) by GCC. 4.4.7 was recently released and dropped, and we don't have any "official" DJGPP mirror binary of that, only older 4.4.4 (or 4.4.5 on Andris' site) because he'd already moved on to newer versions.

Post reply
 

Complete thread:

Back to the forum
Board view  Mix view
22762 Postings in 2122 Threads, 402 registered users (0 online)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum