View Issue Details

IDProjectCategoryView StatusLast Update
0001723OpenFOAM[All Projects] Bugpublic2015-05-30 21:06
Reporteruser1155Assigned Tohenry 
PrioritynormalSeveritycrashReproducibilityalways
Status resolvedResolutionfixed 
PlatformAnyOSAnyOS VersionAny
Product Version 
Fixed in Version 
Summary0001723: Use of null references is incompatible with Clang/LLVM 3.5+ -- causes segfaults
DescriptionThis problem was first reported here:
  http://www.openfoam.org/mantisbt/view.php?id=427

And the bug was closed because it was not currently causing a demonstrable problem. Now it is. As of Clang/LLVM 3.5, the optimizer will remove checks that the address of a reference is null.

The underlying problem is that a function like this:

  bool foo(int &x) {
    return &x;
  }

will always return true when optimizations are enabled. Running, on the above function: clang -O3 -S -emit-llvm -o - will yield:

...

define zeroext i1 @_Z3fooRi(i32* nocapture readnone dereferenceable(4) %x) #0 {
entry:
  ret i1 true
}

...

Clang 3.5 also added a warning for this, as discussed here:
  http://llvm.org/releases/3.5.0/tools/clang/docs/ReleaseNotes.html#major-new-features

on the above function, you'll see:

warning: reference cannot be bound to dereferenced null pointer in well-defined C++ code; pointer may be assumed to always convert to true
      [-Wundefined-bool-conversion]

This warning now is triggered in many places when compiling OpenFOAM (I'm specifically testing using the 2.3.x dev branch).
Steps To ReproduceWhen compiling OpenFOAM with Clang/LLVM 3.5+ (including trunk), using, for example, bgclang build r238097-20150523 on the IBM BG/Q supercomputer, this can cause reconstructPar to crash.

More details can certainly be provided if necessary. There are plenty of places in OpenFOAM that have statements like this:

 if (&iF && iF.size()) {
   ..
 }

that now crash because the first check is removed by the optimizer. For example, in finiteVolume/fields/fvPatchFields/fvPatchField/fvPatchField.C we have the above code in one of the Foam::fvPatchField<Type>::fvPatchField constructors.
TagsNo tags attached.

Activities

henry

2015-05-30 21:06

manager   ~0004852

This is a well known problem and required substantial changes which are all in OpenFOAM-dev. If you want to use Clang OpenFOAM-2.3.? or 2.4.? you will have to use version 3.4.? otherwise you will have to upgrade to OpenFOAM-dev which compiles with Clang-3.[4-6].?

Issue History

Date Modified Username Field Change
2015-05-30 19:42 user1155 New Issue
2015-05-30 21:06 henry Note Added: 0004852
2015-05-30 21:06 henry Status new => resolved
2015-05-30 21:06 henry Resolution open => fixed
2015-05-30 21:06 henry Assigned To => henry