Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to index page
Thread view  Board view
RayeR

Homepage

CZ,
10.04.2012, 00:38
(edited by RayeR, 10.04.2012, 02:00)
 

DJGPP/GCC 4.6.2 invalid code generation when -march restrict (Developers)

Post reply

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 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). 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:

1ec15d: 0f 4e 06                cmovle (%esi),%eax
1edf71: 0f 42 05 48 f2 c3 08    cmovb  0x8c3f248,%eax
1f334e: 0f 40 23                cmovo  (%ebx),%esp
1f4b35: 0f 4a 05 b4 fe 61 ef    cmovp  0xef61feb4,%eax
1f7969: 0f 43 2a                cmovae (%edx),%ebp
1fd563: 0f 44 28                cmove  (%eax),%ebp
4024e3: 0f 42 0f                cmovb  (%edi),%ecx
4024e7: 0f 44 0f                cmove  (%edi),%ecx
4024ef: 0f 48 0f                cmovs  (%edi),%ecx
4024f7: 0f 4c 0f                cmovl  (%edi),%ecx
410f31: 0f 41 00                cmovno (%eax),%eax
49af38: 0f 4f 2f                cmovg  (%edi),%ebp
5c275d: 0f 47 3f                cmova  (%edi),%edi
...

I wonder that this bug is known for 1 year and still not fixed. So be carefull if you use new GCC to produce code that must run on older machines! 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.

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?

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!

28.04.2002  01:44   152286 LIBAA.A
01.05.1994  15:42   178728 LIBBCC.A
25.10.2008  14:26   391330 LIBBFD.A
08.05.2011  20:29   782218 LIBGMP.A
13.02.2012  02:04   875212 LIBIBERT.A
21.03.2006  02:03  1191596 LIBICONV.A
19.08.2010  02:04    12904 LIBJB85.A
19.08.2010  02:04    43784 LIBJBIG.A
22.01.2012  02:04   729860 LIBLZMA.A
26.10.2011  10:42   199666 LIBM.A
08.05.2011  20:29   507476 LIBMP.A
19.05.2011  02:04   623148 LIBPNG.A
29.10.2011  10:33   494686 LIBQUADM.A
15.03.1998  16:42   252248 LIBVGA.A
24.01.2012  05:42  1494062 LIBWATT.A
19.02.2012  02:04   104236 LIBZ.A

---
DOS gives me freedom to unlimited HW access.
Rugxulo

Homepage

Usono,
10.04.2012, 02:01

@ RayeR
 

GCC 4.6.x invalid code generation

Post reply

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

Homepage

CZ,
10.04.2012, 03:58

@ Rugxulo
 

GCC 4.6.x invalid code generation

Post reply

> care to minimize targets for such "old" tech, presumably. Esp. since most
> Linux distros don't actively support anything older than 686 anymore.
But there are still used and manufactured various low-power embedded PCs with old and simple x86 core like vortex86 and other SoC with 386/486 core, even may lack FPU. Linux can run on such machines well so they should care...

> 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.
Running the program is not enough good test. Code may branch widely depending on input data so you don't have a chance to test all the code runtime...

> 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]).
As you can see from file dates I use updated/CVS DJDEV. But now I become suspicious to objdump. It detected CMOVs in libm.a even from very old djdev 2.03. I tried older 3.x GCC and still getting CMOVs in some object files. I also found, that X264 use CMOV in some assembler source modules so it cannot be disabled. So this may be the reason why FFMPEG crashed on some compression target and din't crashed on other. But as I said I found CMOV also in .o files compiled from .c files that doesn't have inline ASM or anything else indicating CMOV. Even more confusing is that CMOV was produced also with GCC 3.x. When I tried to compile .C file into assembler .S file I didn't see CMOV there. So objdump is just kidding me or WTF? It seem's the right time to go sleep now... :P

---
DOS gives me freedom to unlimited HW access.
Rugxulo

Homepage

Usono,
10.04.2012, 05:58

@ RayeR
 

GCC 4.6.x invalid code generation

Post reply

> But there are still used and manufactured various low-power embedded PCs
> with old and simple x86 core like vortex86 and other SoC with 386/486 core,
> even may lack FPU. Linux can run on such machines well so they should
> care...
GCC has always assumed an FPU, I think. But also I think Linux kernel has CMOV emulation (presumably via trapping SIGILL), so maybe that's why they don't care, it should always work. Even Clang (I think?) by default targets P4 w/ SSE2.

> Running the program is not enough good test. Code may branch widely
> depending on input data so you don't have a chance to test all the code
> runtime...
True, but I don't know of a better way.

> As you can see from file dates I use updated/CVS DJDEV. But now I become
> suspicious to objdump. It detected CMOVs in libm.a even from very old djdev
> 2.03. I tried older 3.x GCC and still getting CMOVs in some object files. I
> also found, that X264 use CMOV in some assembler source modules so it
> cannot be disabled. So this may be the reason why FFMPEG crashed on some
> compression target and din't crashed on other. But as I said I found CMOV
> also in .o files compiled from .c files that doesn't have inline ASM or
> anything else indicating CMOV. Even more confusing is that CMOV was
> produced also with GCC 3.x. When I tried to compile .C file into assembler
> .S file I didn't see CMOV there. So objdump is just kidding me or WTF? It
> seem's the right time to go sleep now... :P
Dunno, try gcc281b.zip, and see what happens. It shouldn't make any CMOVs ... ever! ;-)

I honestly only know about such regression in 4.6.x, so I would personally trust older versions. However, it's impossible to tell, but I'm not worried (at least without better proof). So I suggest you also not worry. I know it's not much reassurance, esp. from me, but it's all I've got. Also, 4.5.3 is presumably "good enough" for your needs until a fix is found. :-)

EDIT: If it were me, I'd totally revert to a non-buggy patch in GCC trunk, but alas it's not my call (and obviously I don't have repo write access). Also, I think CMOV optimizations are hugely overrated, but silly GCC is obsessed with them for whatever reason.
RayeR

Homepage

CZ,
10.04.2012, 13:44

@ Rugxulo
 

GCC 4.6.x invalid code generation

Post reply

> GCC has always assumed an FPU, I think. But also I think Linux kernel has
> CMOV emulation (presumably via trapping SIGILL), so maybe that's why they
> don't care, it should always work. Even Clang (I think?) by default targets
> P4 w/ SSE2.
FPU is not needed/can be disabled. At work we had 2 small Vortex86 PC (without FPU) running debian linux. The first attempt running precompiled linux crashed on lack of FPU. But when recompiled kernel with disabled FPU and some other settings it started OK...

> True, but I don't know of a better way.
I think it shouln'd be hard to make such tool that will take ASM source, grep some sets of instructions organized by CPU family from newest to oldes and report what was used, e.g. in form of a histogram displaying e.g.
386 opcodes: 90%
486 opcodes: 9%
586 opcodes: 1%
686 opcodes: 0%
...
I wonder if there doesn't exist such tool...

> Dunno, try
> gcc281b.zip,
> and see what happens. It shouldn't make any CMOVs ... ever! ;-)
Hm but old GCC doesn't support C99 and other GNU extension - useless for newer sources.

> EDIT: If it were me, I'd totally revert to a non-buggy patch in GCC trunk,
> but alas it's not my call (and obviously I don't have repo write access).
> Also, I think CMOV optimizations are hugely overrated, but silly GCC is
> obsessed with them for whatever reason.
Now I think that the problem is more caused by invalid objdump disassembly rather than invalid gcc code emision. I compared some programs that objdump reported contain CMOV with IDA disassembler and IDA didn's found any CMOV there. I don't know what other tool use to disassembly djgpp coffs to confirm it. In case of X264 the CMOVs also come from assembler modules that cannot be disabled so there's no way to make fully 586 valid code without further mods in ASM...

---
DOS gives me freedom to unlimited HW access.
marcov

10.04.2012, 16:19

@ RayeR
 

GCC 4.6.x invalid code generation

Post reply

> Now I think that the problem is more caused by invalid objdump disassembly
> rather than invalid gcc code emision.

Afaik objdump also disassembles some non code sections. (e.g. jump tables)

Grepping in disassembled source and concluding gcc produces cmov's could therefore be erroneous.
RayeR

Homepage

CZ,
10.04.2012, 17:44

@ marcov
 

GCC 4.6.x invalid code generation

Post reply

> Afaik objdump also disassembles some non code sections. (e.g. jump tables)
I used -d switch
-d, --disassemble Display assembler contents of executable sections

not -D
-D, --disassemble-all Display assembler contents of all sections

So I belive I should get only disassembled code section.

---
DOS gives me freedom to unlimited HW access.
RayeR

Homepage

CZ,
14.04.2012, 23:28
(edited by RayeR, 15.04.2012, 01:59)

@ RayeR
 

GCC 4.6.x invalid code generation

Post reply

I did some further testing. First I disabled assembler in config.mak to prevent use optimized assembler modules that contained CMOVs. Then I tested 3 GCC version and compare CMOVs occurences in ffmpeg.exe:
gcc 4.1.2 - 191 CMOVs
gcc 4.3.2 - 192 CMOVs
gcc 4.6.2 - 194 CMOVs
IDA also found CMOVs. I let it test my friend on K6 again if will go better...

If someone wants to test it on old pentium download is here:
https://sourceforge.net/projects/ffmpeg-x264-dos/files/

---
DOS gives me freedom to unlimited HW access.
Arjay

15.04.2012, 09:05

@ RayeR
 

GCC 4.6.x invalid code generation: MP [PATCH] configure cmov

Post reply

> I did some further testing. First I disabled assembler in config.mak to
> prevent use optimized assembler modules that contained CMOVs. T
I did some quick searching, e.g "disable cmov", "disable cmov ffmpeg", "disable cmov mplayer" etc. Have you seen this 2006 patch which appears to include entries to disable cmov in the runtime etc.

http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2006-October/046659.html

I do still own some original pentiums, e.g P120, P133. However at this time I'm just too busy to offer any testing-still remind me in a month or two.
RayeR

Homepage

CZ,
15.04.2012, 14:44
(edited by RayeR, 15.04.2012, 18:17)

@ Arjay
 

GCC 4.6.x invalid code generation: MP [PATCH] configure cmov

Post reply

> I did some quick searching, e.g "disable cmov", "disable cmov ffmpeg",
> "disable cmov mplayer" etc. Have you seen this 2006 patch which appears to
> include entries to disable cmov in the runtime etc.
>
> http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2006-October/046659.html
No, but AFAIK DOS mplayer has disabled runtime CPU detection at all. I checked ffmpeg config files and I have
!HAVE_CMOV=yes
#define HAVE_CMOV 0
so it shouldn't be used.

UPDATE:
The last uploaded version was successfully tested on AMD K6-II!
I will make one more test with new gcc 4.6.2 and disabled assembler modules. If it will work then we don't need be so afraid of new gcc.

---
DOS gives me freedom to unlimited HW access.
RayeR

Homepage

CZ,
26.04.2012, 01:50
(edited by RayeR, 26.04.2012, 02:18)

@ RayeR
 

GCC 4.6.x invalid code generation: MP [PATCH] configure cmov

Post reply

> I will make one more test with new gcc 4.6.2 and disabled assembler
> modules. If it will work then we don't need be so afraid of new gcc.
I got confirmed that FFMPEG compiled by GCC 4.6.2 works on AMD K6-II too. Even if binary contains a lot of CMOV but it's propably some dead code that is never called. So I'm happy that new gcc works for old machines.

BTW just see new GCC 4.7.0 is here http://ap1.pp.fi/djgpp/gcc/4.7.0/

---
DOS gives me freedom to unlimited HW access.
Rugxulo

Homepage

Usono,
26.04.2012, 09:06

@ RayeR
 

GCC 4.6.x invalid code generation

Post reply

> > I will make one more test with new gcc 4.6.2 and disabled assembler
> > modules. If it will work then we don't need be so afraid of new gcc.
>
> I got confirmed that FFMPEG compiled by GCC 4.6.2 works on AMD K6-II too.
> Even if binary contains a lot of CMOV but it's propably some dead code that
> is never called. So I'm happy that new gcc works for old machines.
I'm surprised and would still be leery of it (for older targets) personally, but at least it seems to "mostly" work for you, so that's good.

> BTW just see new GCC 4.7.0 is here
> http://ap1.pp.fi/djgpp/gcc/4.7.0/
That's unofficial, and this was a week or two before Juan's latest refresh of GDB and BinUtils, so I'd (blindly hope for) expect a newer version of latest GCC in a week or so, presumably as official on DJGPP mirrors. (But COFF debug info seems broken lately, oh well.)
RayeR

Homepage

CZ,
28.04.2012, 02:14

@ Rugxulo
 

GCC 4.6.x invalid code generation

Post reply

> That's unofficial, and this was a week or two before Juan's latest refresh
> of GDB and BinUtils, so I'd (blindly hope for) expect a newer version of
> latest GCC in a week or so, presumably as official on DJGPP mirrors. (But
> COFF debug info seems broken lately, oh well.)
I tried to compile FFMPEG with it and it works but the binary after pack is about 300kB greater... There's also 4.6.3 that is out longer but not on djgpp site.

---
DOS gives me freedom to unlimited HW access.
RayeR

Homepage

CZ,
01.05.2012, 17:57

@ RayeR
 

x264 0.124 update

Post reply

Small update of x264 0.124
https://sourceforge.net/projects/ffmpeg-x264-dos/files/

---
DOS gives me freedom to unlimited HW access.
DOS386

16.06.2012, 12:53

@ Rugxulo
 

CMOVNTQ and multiple file access

Post reply

> 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!
> In case of X264 the CMOVs also come from assembler modules that
> cannot be disabled
Then wonder why FFMPEG or MPLAYER persistently crash on CMOVNTQ despite reportedly compiled for 486 :-(

http://sf.net/tracker/?func=detail&aid=3000835&group_id=205275&atid=992986
http://sf.net/tracker/?func=detail&aid=3358347&group_id=205275&atid=992986

http://www.freebasic.net/forum/viewtopic.php?t=11066

> BTW just see new GCC 4.7.0 is here http://ap1.pp.fi/djgpp/gcc/4.7.0/
There is a possible new BUG (multiple file access):

http://sf.net/tracker/?func=detail&aid=3530451&group_id=5109&atid=105109

Anyone tested recent DGJPP in DOS ?

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***
ecm

Homepage E-mail

Düsseldorf, Germany,
16.06.2012, 14:31

@ DOS386
 

Multiple file access, FreeDOS file locking support

Post reply

> There is a possible new BUG (multiple file access):
>
> http://sf.net/tracker/?func=detail&aid=3530451&group_id=5109&atid=105109
>
> Anyone tested recent DGJPP in DOS ?
File locking should be part of the kernel and always should be loaded. The one failure even with FreeDOS's "SHARE" loaded is presumably because the FreeDOS file locking interface doesn't seem to account for updates that have to be propagated from SFTs used to write a file to all the other SFTs currently referring to the same file. I'm using "doesn't seem" here because it has been quite a time since I last looked more closely into file locking, and just now I only briefly glanced at FreeDOS's file locking code.

So basically, whenever concurrent writing is involved without file locking support, "bugs" are expected by design. Actual bugs which can and should be fixed are only (a) unexpected behaviour such as file system corruption if file locking support is enabled and (b) the possibility to disable file locking support at all.

---
l
Rugxulo

Homepage

Usono,
16.06.2012, 17:48

@ DOS386
 

multiple file access / IUP 0.67

Post reply

Is this really the same bug as IUP? IIRC, Eric told me once that it was basically just some minor compatibility regarding temporary file name support, e.g. MS-DOS 5 vs 6 (or some such, see int 21h, 5Ah). And the partial workaround was to unpack in the root directory. But I never cared enough to look closer (and probably wouldn't understand it anyways).
DOS386

17.06.2012, 09:33

@ Rugxulo
 

multiple file access / IUP 0.67

Post reply

> Is this really the same bug as IUP
YES. IUP uses AH=$5A to brew a temp file, and then, it reopens it with $3C ... it works now, because:

- FreeDOS behavior was adjusted to other DOS'es
- no data had been written before re-opening

> And the partial workaround was to unpack in the root directory
no

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***
RayeR

Homepage

CZ,
19.06.2012, 20:38

@ DOS386
 

CMOVNTQ and multiple file access

Post reply

> There is a possible new BUG (multiple file access):
>
> http://sf.net/tracker/?func=detail&aid=3530451&group_id=5109&atid=105109
>
> Anyone tested recent DGJPP in DOS ?
I think it's not DJGPP neither even a GCC bug. I think it's on responsibility of DOS and libC. While DJGPP libC didn't changed for long years it must be somewhere else. I use latest DJGPP with GCC 4.7.0 under MSDOS 6.22 and don't have such problem (no share.exe loaded). I remember that I reported some problem with opening some non existing or..., I don't remember, file where the test program got correct error on MSDOS while didn't get error on freedos. This is rerason why I use MSDOS as a reference - less buggy :)

---
DOS gives me freedom to unlimited HW access.
RayeR

Homepage

CZ,
21.06.2012, 04:32

@ RayeR
 

CMOVNTQ and multiple file access

Post reply

I tried to compile and run test program mentioned above under MSDOS 6.22 on FAT16 and it creates 1 lost cluster per every run (instead of returning NULL on second fopen call). I tried gcc 4.7.0, 4.7.1 and very old 2.95 and all behaved the same so it's not new gcc bug but rather libc / DOS bug.

#include <stdio.h>

main() {
FILE *f, *f2;
char test[10000];
f=fopen("test1","wb");
if (f==NULL)
  puts("f1 error");
fwrite(test,1,10000,f);
f2=fopen("test1","wb");
if (f2==NULL)
  puts("f2 error");
fwrite(test,1,10000,f2);
}

---
DOS gives me freedom to unlimited HW access.
ecm

Homepage E-mail

Düsseldorf, Germany,
21.06.2012, 05:06

@ RayeR
 

load SHARE

Post reply

load SHARE?
RayeR

Homepage

CZ,
21.06.2012, 12:40

@ ecm
 

load SHARE

Post reply

> load SHARE?
I tested without share.

---
DOS gives me freedom to unlimited HW access.
ecm

Homepage E-mail

Düsseldorf, Germany,
21.06.2012, 12:47

@ RayeR
 

load SHARE

Post reply

> I tested without share.
Yes, I assumed so. In this case, corruption is expected (intended), as I explained here. Presumably, with the file locking support enabled, your test case would not cause file system corruption.

---
l
RayeR

Homepage

CZ,
21.06.2012, 19:58

@ ecm
 

load SHARE

Post reply

> Yes, I assumed so. In this case, corruption is expected (intended), as I
> explained here. Presumably, with the file locking support
> enabled, your test case would not cause file system corruption.
I'll try again with share. But I would expect that second fopen "wb" call will return NULL when OS cannot support it correctly to prevent FS damage. I also tried win32 code compiled by mingw and it works without failure (writen file size is 10000B). Anyway I never did open a file with more than 1 handle for writing, I can't imagine why I should do this - does some usefull program use it?

---
DOS gives me freedom to unlimited HW access.
RayeR

Homepage

CZ,
21.06.2012, 23:31

@ RayeR
 

load SHARE

Post reply

I tested with share and now it doesn't make any lost clusters. The same when run under Windows XP. So it's definitely problem of OS and not DJGPP/GCC...

---
DOS gives me freedom to unlimited HW access.
ecm

Homepage E-mail

Düsseldorf, Germany,
22.06.2012, 14:03

@ RayeR
 

load SHARE

Post reply

> But I would expect that second fopen "wb" call will return NULL when OS
> cannot support it correctly to prevent FS damage.
Welcome to MS-DOS, where FS damage is a feature rather than a bug.
marcov

10.04.2012, 16:16

@ Rugxulo
 

GCC 4.6.x invalid code generation

Post reply

> > 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,

Correct.

> only lightly borrows or gleans from go32v2
> (whatever that means specifically, I've not looked).
These were originally because of two reasons:

1. usage of the go32v2 extender
2. being mostly linking compatible with djgpp, most importantly because
the textmode IDE incorporates (lib)GDB.

But all that is more runtime library related, the only compiler related bit is that the calling convention of "CDECL" will match djgpp's. (While the native calling convention is register, which is more fastcall like) Without using any gcc code of course.

> P3 priority, so it's far from important to them. GCC 4.8.0 release criteria
> explicitly says "i686" except for "i386-unknown-freebsd",

That's a naming convention of BSD. They always call everything for 32-bit x86 i386, regardless of specific optimazations.

This because "i386" is the general architecture, and optimizations or instruction selecting is not reflected in architecture, which is more a GNU or Linux convention.

So FreeBSD being "i386" has nothing to do with i386 compatibility. And anyway, recent GPL3 gcc releases are afaik irrelevant to most of BSD, since they kept the last GPL2 version, and are now migrating to LLVM.
RayeR

Homepage

CZ,
10.04.2012, 17:49

@ marcov
 

GCC 4.6.x invalid code generation

Post reply

> So FreeBSD being "i386" has nothing to do with i386 compatibility. And
> anyway, recent GPL3 gcc releases are afaik irrelevant to most of BSD, since
> they kept the last GPL2 version, and are now migrating to LLVM.
And AFAIK LLVM/Clang is more targetted od newer CPU so it may not produce valid code for anything less than PIII or so... ?

---
DOS gives me freedom to unlimited HW access.
Back to index page
Thread view  Board view
22049 Postings in 2034 Threads, 396 registered users, 215 users online (0 registered, 215 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum