possible solutions here: T50165#411274 P434

For a much simpler testcase, apparently demonstrating a similar problem -- non-solid objects resulting from boolean intersect with BMesh -- see T51236 . Again, "Carve" produces the correct result, "BMesh" doesn't.

if bug has been fixed already since then and is no more reproducible with latest master, then we can close the report.

If it was reported in another bug report, why did you report it again?

I see no errors in latest buildbots

I confirm all of this, even the "holes not covered" part, using the supplied test case.

can you confirm that your issue is the same described in T51074?

For a more up-to-date discussion of this issue, see here:

Yes, that's exactly what I said --

It turns out that these compiler warnings --

The two separate compiler errors involved here (neither is actually a Blender issue) are now the subject of two Debian bug reports. Patches are available upstream for both problems, as mentioned above.

It turns out that the "invalid argument type 'X *' to unary expression" compile errors are the result of a known bug in LLVM. It is said to be fixed in LLVM-v5; see here:

This same problem (actually, several problems) has been reported here; it's not distribution- or hardware-specific:

Adding device specific code for a few specific cases does not abstract that away.

The more code we can share between CPU/CUDA/OpenCL the better, every device specific code we add can get out of sync and makes it more work to maintain, so I rather not do this.

I didn't reuse CL_M_*_F since we need the defines for C++ and CUDA too,
and adding an OpenCL specific variation would not simplify the code.

It appears that the openCL standard header file <cl_platform.h> already defines
almost all of these constants:

There's a whole header file with this problem:

modifiers do not affect objects, they affect geometries (i.e. object’s data). Since empties have no data/geometry, they cannot have modifiers...

why is there no way that an empty object can be used to control the visibility of its children?

Is there a reason why this should be so? Can recursive application at least be made an option?