Re: [Re: optimization/8412: Code generation problem with -march=k6

[Eric Botcazou <ebotcazou at libertysurf dot fr>]

>   I think I'm seeing this same bug, with
> gcc version 3.2.1 20021207 (Gentoo Linux 3.2.1-20021207)
>  I've noticed considerable instability with multimedia things including
> xine, and have been studying an easily reproducible problem with
> xmms. I'd assumed it was 3dnow related, but testing has zeroed me in
> on a combination of -funroll-all-loops and -O[23].
>
>   Here are my crude notes to date. Not yet a good bug-report,
>
> The test is compiling and running xmms and doing a particular
> operation with it. My system is a k6-2.
>
> -finline-functions is used in all tests.
>
> CFLAGS='-march=k6-2 -g -O1' works.
> CFLAGS='-march=k6-2 -g -O1 -ffast-math' works.
> CFLAGS='-march=k6-2 -g -O1 -ffast-math -funroll-all-loops' works.
> CFLAGS='-march=k6-2 -g -O2 -ffast-math -funroll-all-loops' FAILS.
> CFLAGS='-march=k6-2 -g -O2 -ffast-math' works.
> CFLAGS='-march=k6-2 -O2 -ffast-math' works.
>
>   The xmms configuration normally uses -funroll-all-loops, and
> I was seeing consistent failure with any variant of -m{cpu,arch}=
> {k6,k6-2} -O[23], which is not reflected above. The problem went
> away when the k6-specific flags were removed. I did not start
> getting any k6-specific build successes until I started dropping
> below -O2 and -funroll-all-loops.

Very likely a duplicate of PR optimization/8599, which should be fixed in the 
upcoming GCC 3.2.2 release. But I don't think your problem is related to PR 
optimization/8412 which is an ICE, not a wrong-code generation bug.

-- 
Eric Botcazou