gforth and gcc 4.7

Jakub Jelinek jakub at redhat.com
Mon Mar 26 16:46:35 UTC 2012


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?

	Jakub


More information about the devel mailing list