There is something wrong around the array access on m68k. If in body of the ?: operator the array "t" is accessed more than once in same way the compiler'll drop some errors. I made several crosscompiler, and I only found that m68k-*-elf doesn't handle the following c code: float *t, a; void good() { a = (t[0] < 0 ? 0 : (a > 1 ? 1 : t[1])); } void bad() { a = (t[0] < 0 ? 0 : (a > 1 ? 1 : t[0])); } Command line: m68k-elf-gcc -O1 -o pr.o pr.c And I got: pr.c: In function `bad': pr.c:11: internal compiler error: in output_325, at insn-output.c:3475 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://gcc.gnu.org/bugs.html> for instructions.
Confirmed.
The problem is that gcc is now using the IEEE aware conditions which only work with CC in the FPU, but notice_update_cc still sets cc_status for the SET even if the destination is a DATA_REG in SFmode.
I have another testcase. Is it a similar problem? Source: int bar(float *e) { if (!(e[0] > 0 && e[1] > 0)) return 1; return 0; } Command line (version:2004-08-30 12:00:00 UTC): m68k-elf-gcc -c -O2 pr.i Output: pr.i: In function `bar': pr.i:6: internal compiler error: in output_348, at insn-output.c:3487
Subject: Re: [3.5.0 regression] [m68k] segmentation fault on identical array accesses in the ?: operators' body loki at inf dot u-szeged dot hu wrote: > ------- Additional Comments From loki at inf dot u-szeged dot hu 2004-08-31 09:21 ------- > I have another testcase. Is it a similar problem? > pr.i:6: internal compiler error: in output_348, at insn-output.c:3487 Yes, it is the same problem. By the way, this problem goes away with my flag_trapping_math bug fix (it should be on by default but is not). However, the underlying problem remains, and can still be triggered if you use the -fno-trapping-math option. The underlying problem seems to be that we have two condition codes, one integer one and one FP one, and cc_status can only track one of them at a time. If we clobber cc_status when CC_IN_68881 is set, then this problem will be fixed, but we won't be able to optimize away FP compares anymore, and hence there will be some performance loss. However, the current code looks like it will handle negative-zero incorrectly, and probably also signalling NaNs, and maybe some other stuff too, so this may be a good idea anyways in order to fix some IEEE math correctness problems.
Created attachment 7020 [details] Patch for m68k.c This patch is only lightly tested but fixes the test cases. If it looks ok I'll send it to gcc-patches. A possible refinement might be to check for flag_unsafe_math_optimizations and only do CC_STATUS_INIT if it is not set, but I haven't tested that yet.
The bug has been fixed at Sep 3.
See comment #4, this is still not fixed with -fno-trapping-math.
See last comment.
Is the remaining bug a regression? In fact, is this a regression at all or merely a bug that was latent and somehow got exposed now? Andreas, are you going to post your patch from comment #5?
m68k is not a primary or secondary target; removing target milestone.
Andreas, what are your plans with this bug and with the patch from comment #5?
m68k is not a primary or secondary platform; removing target milestone.
This is still a bug.
Created attachment 10451 [details] Test case
I cannot reproduce the problem even with -O2 -fno-trapping-math.
Disregard my last comment. The original testcase still fails if I use -fno-trapping-math. The testcase in #3 doesn't fail with or without -fno-trapping-math.
Andreas, are you going to submit your patch?
Will not be fixed in 4.1.1; adjust target milestone to 4.1.2.
Fixed by <http://gcc.gnu.org/ml/gcc-patches/2007-01/msg00808.html>.