[Openmp-dev] Bug in clang/openmp: max-reduction fails if data type is "long double"

[Alexey Bataev via Openmp-dev]

Yes, though it has width 80 bits, we're using 128 bit to perform atomic operations on this data (alignment allows us to do that).

Best regards,
Alexey Bataev
=============
Software Engineer
Intel Compiler Team

15.03.2016 13:15, Stefan Illy via Openmp-dev пишет:
Thanks for the reply,

in fact "long double" is the x86 extended precision which needs 80 bits (10 bytes) only. It is not a full 128 bit floating point data type (as the quad precision provided by gcc and the Intel compiler).
Nevertheless, sizeof(long double) gives a value of 16 (due to alignment reasons, I assume); 6 bytes are unused.

-- Stefan

Am 15.03.2016 um 10:43 schrieb Cownie, James H:
This looks like an inconsistency in our knowledge of LLVM/Clang.

Historically LLVM did not support 16 byte floating point, so the OpenMP runtime does not have support for them when compiled with clang (because the necessary routines couldn't be compiled!).

If your code really is using 16 byte floating point numbers, then the tests in the runtime that don't compile those routines need to be enabled.

It'd be worth checking, though, that the "long double" really is 16 bytes, so maybe you could just check sizeof(real_t).

p.s. You don't need to initialize max_val; whatever value you put there will be ignored anyway, since the OpenMP standard says that the per-thread reduction values are initialized with the most negative value of the type.
Thanks for the hint - I was not aware of that!


-- Jim

James Cownie <james.h.cownie at intel.com><mailto:james.h.cownie at intel.com>
SSG/DPD/TCAR (Technical Computing, Analyzers and Runtimes)
Tel: +44 117 9071438

-----Original Message-----
From: Openmp-dev [mailto:openmp-dev-bounces at lists.llvm.org] On Behalf Of Stefan Illy via Openmp-dev
Sent: Friday, March 11, 2016 7:36 AM
To: openmp-dev at lists.llvm.org<mailto:openmp-dev at lists.llvm.org>
Subject: [Openmp-dev] Bug in clang/openmp: max-reduction fails if data type is "long double"

Hello everybody,

When I compile the simple test program attached below I get the
following error message:

openmpbug.cc:(.text+0x2de): undefined reference to
`__sync_val_compare_and_swap_16'
openmpbug.cc:(.text+0x3a7): undefined reference to
`__sync_val_compare_and_swap_16'
clang-3.8: error: linker command failed with exit code 1 (use -v to see
invocation)

This is caused by the OMP max-reduction statement. It also fails if I
switch from "max" to "min".
I use version 3.8 of clang on an Ubuntu 14.04 LTS system. It also fails
with version 3.9 (trunk, self-compiled).
If I switch the floating point data type (real_t) from "long double" to
"double" or "float", the code compiles and runs without problems.

I hope this helps to make clang+openmp even better!


Here comes the simple test program:
---------------------------------------SNIP-------------------------------------------
#include <iostream>

using namespace std;

//typedef float real_t;
//typedef double real_t;
typedef long double real_t;

int
main()
{
    real_t maxval = -1.0e-10;
#pragma omp parallel for reduction(max: maxval)
    for (int i = 1; i <= 1000; i++) maxval = max(maxval, real_t(i));
    cout << maxval << endl;
    return 0;
}
------------------------------------SNIP------------------------------------------------

---------------------------------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.






_______________________________________________
Openmp-dev mailing list
Openmp-dev at lists.llvm.org<mailto:Openmp-dev at lists.llvm.org>
http://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/openmp-dev/attachments/20160316/579c336c/attachment.html>