On Mon, Mar 26, 2012 at 04:54:05PM +0200, Adrian Reber wrote: > Trying to build gforth with gcc 4.7 fails currently. The forth engine is > build but it fails its included tests. The problem is that every newline > the forth engine writes is replaced with 0x00 as seen in following diff: > > 0000010: 6566 696e 6564 2047 4458 2020 594f 5520 efined GDX YOU > 0000020: 5348 4f55 4c44 2053 4545 2054 4845 2053 SHOULD SEE THE S > 0000030: 5441 4e44 4152 4420 4752 4150 4849 4320 TANDARD GRAPHIC > -0000040: 4348 4152 4143 5445 5253 3a00 2021 2223 CHARACTERS:. !"# > ^^ actual output > +0000040: 4348 4152 4143 5445 5253 3a0a 2021 2223 CHARACTERS:. !"# > ^^ expected output > 0000050: 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 $%&'()*+,-./0123 > > Removing -O2 from the compiler commandline fixes it, but I have no idea > why this happens. Does anyone have an idea how this can be solved? If -O0 works and -O2 doesn't, first narrow it down using a binary search between -O0 and -O2 compiled objects to at least a single compilation unit, then you could use __attribute__((optimize (0))) (resp. __attribute__((optimize (2))) ) and/or -fno-inline to narrow it even further, read the problematic code, see if there aren't any e.g. aliasing warnings (-O2 enables -fstrict-aliasing), if you don't spot a bug in the gforth code after this and still suspect the compiler, turn that into self-contained minimal testcase (for the problematic routine add main that calls it with the right arguments, make the problematic routine __attribute__((noinline, noclone)) and stub out anything it calls, then file a gcc bugreport?