errors with complex dtype on some Macs

Some kernels using complex types seem to fail on some Macs. Using PyOpenCL pulled from github today, I see the following failures from test_clmath.py on an iMac 17,1 (ca. 2015) with an AMD Radeon R9 M380:

```
planck:~ sg9$ env PYOPENCL_NO_CACHE=1 PYTHONPATH=~/checkedout/pyopencl/build/lib.macosx-10.11-x86_64-2.7:~/checkedout/pyopencl/.eggs/cffi-1.9.1-py2.7-macosx-10.11-x86_64.egg ipython ~/checkedout/pyopencl/test/test_clmath.py
================================== test session starts ==================================
platform darwin -- Python 2.7.11, pytest-3.0.5, py-1.4.32, pluggy-0.4.0
rootdir: /Users/sg9/checkedout/pyopencl, inifile:
collected 54 items `

checkedout/pyopencl/test/test_clmath.py .F.................F.F........................s.sFs.sF
```

The failures are in test_exp, test_log, test_tanh, test_complex_bessel, test_hankel_01_complex.

All the tests succeed on another iMac 14,2 (ca. 2013) with an nVidia GeForce GT 755M.

I could send the full output of the tests, but the following code fails on the AMD Radeon R9 M380:

```
In [2]: import numpy; import pyopencl; import pyopencl.array; ctx = pyopencl.create_some_context(); queue = pyopencl.CommandQueue(ctx); a_g = pyopencl.array.to_device(queue, numpy.array([2], dtype=numpy.complex64)); b_g = pyopencl.array.to_device(queue, numpy.array([2], dtype=numpy.complex64)); c_g = a_g + b_g; print "%s + %s = %s" % (a_g.get(), b_g.get(), c_g.get(),)
Choose platform:
[0]
Choice [0]:0
Choose device(s):
[0]
[1]
Choice, comma-separated [0]:1
Set the environment variable PYOPENCL_CTX='0:1' to avoid being asked again.
[ 2.+0.j] + [ 2.+0.j] = [ 0.+0.j]
```

Obviously, the answer to 2 + 2 should be 4. a_g and b_g seem to be transferring to the device correctly, but the kernel computing the addition does not seem to do the right thing. In my own kernels, when I send a complex-valued array as an argument, the kernel does not seem to see the correct values (I print them with printf's and usually get 0 or something ridiculous like 0 + 0.XXXXe-38). So it seems like the kernels are not getting the correct array as inputs or are interpreting them incorrectly.

Curious to see if anyone else is experiencing this! Thanks!