Cannot yet select: 0x411b508c: f64 = fneg 0x411b5950

[llvmbot]

Bugzilla Link	3376
Resolution	FIXED
Resolved on	Jan 28, 2009 11:58
Version	unspecified
OS	MacOS X
Reporter	LLVM Bugzilla Contributor
CC	@asl,@lattner,@sunfishcode

Extended Description

The gfortran compiler in current llvm/llvm-gcc-4.2 ICEs when compiling the xtarget.f sourcefile of xplor-nih with -O3 -ffast-math. The exact -ffast-math option causing the ICE appears to be -ffinite-math-only as -ffast-math -fno-finite-math-only compiles without ICEs. The subroutine causing the ICE with...

lvm-gfortran -c xtarget_reduced.f -O3 -ffast-math -ffixed-line-length-120 -fno-second-underscore
Cannot yet select: 0x411b508c: f64 = fneg 0x411b5950
xtarget_reduced.f:156: internal compiler error: Abort trap
Please submit a full bug report,
with preprocessed source if appropriate.

is attached a xtarget-reduced.f.

[asl]

Isn't it the same as #3746 ?

PS:
Also, you'll get better reduction, if you compile to LLVM IR (via -emit-llvm option) and run through bugpoint.

[llvmbot]

Anton,
This is another variation of the problem in #3746 . Prior to the fix for #3746 several
fortran files in xplor-nih ICEd with -O3 -ffast-math. Now only as single file ICEs. If I understand...

http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20090119/072553.html

correctly #3746 was triggered by -funsafe-math-optimizations whereas llvm/llvm-bugzilla-archive#3376 is
triggered by -ffinite-math-only instead.

[lattner]

Hi Jack,

It will be easier to repro this if you attach the output of gfortran -emit-llvm -o foo.bc, thanks.

[llvmbot]

xtarget_reduced.o: Compiled PSI (v1) data

[llvmbot]

I don't have bugpoint built at the moment. Hopefully the reduced testcase compiled with...

llvm-gfortran -c xtarget_reduced.f -O3 -ffast-math -ffixed-line-length-120 -fno-second-underscore -emit-llvm

is portable (at least between darwin machines).

[llvmbot]

llvm-gfortran -c xtarget_reduced.f -O3 -ffast-math -ffixed-line-length-120 -fno-second-underscore -emit-llvm -o xtarget_reduced.bc

[llvmbot]

xtarget_reduced.f fortran source

[llvmbot]

[log from ./bugpoint https://user-images.githubusercontent.com/60944935/143738738-9a56c55a-fa59-487c-be31-4c48a8dbb442.gz)

[lattner]

The bc file repros the issue with: llc xtarget_reduced.bc -o /dev/null -f -enable-unsafe-fp-math

It should be trivial to bugpoint it now, thanks Jack.

[llvmbot]

[bc file from ./bugpoint https://user-images.githubusercontent.com/60944935/143738737-c2391c41-9306-4369-8fc1-f84cd0b9eae3.gz)

[sunfishcode]

With r62860, the problems in these testcases are effectively avoided,
and they compile clean with -enable-unsafe-fp-math.

The underlying problem still exists though; in many places, the
dagcombiner assumes it can create operations that require "Custom"
lowering even when it's running after Legalize. This doesn't happen
very often, especially when the dagcombiner is thorough and doesn't
miss folding opportunities in earlier runs, but it's still incorrect and
I'm planning to fix it.

[lattner]

Sounds great Dan. So in summary, r62860 should be pulled into 2.5, but you want to keep this bug open to solve the bigger issue on mainline?

[sunfishcode]

Yes. Please pull both r62789 and r62860 into 2.5 so that you get
all of the known cases covered. I'll close this PR when I have a
fix for the underlying problem.

[lattner]

awesome, thanks dan!

[sunfishcode]

The second half of the fix is now done, here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20090126/072817.html

Theoretically, the DAGCombiner and Legalizer could run
iteratively, allowing the DAGCombiner to create new
Custom nodes which are subsequently Legalized, however
situations where this would help are uncommon. In this
PR, it was only visible before the earlier fixes were
applied.