Complex Arithmetic Issue - with Chapel GCC backend

Users
1

The following code translated into C and compiled with GCC or CLANG is broken. It yields

inf + nan i

when it should yield

inf + inf i

My version of chpl uses the LLVM backend.

Could I ask somebody with a version of chpl with the GCC backend to compile and run this code and tell me what result comes out of that please? Thanks in advance.

proc main64
{   
    const p = -0x1.80a55ep+0 + 0x1.1bfep+80i;
    const q = 0x1.ap+64 - 0x1.54c296p+127i;
    const t = p * q;

    writeln(p);
    writeln(q);
    writeln(t);
}   

proc main32
{   
    const p = -0x1.80a55ep+0:real(32) + 0x1.1bfep+80:imag(32);
    const q = 0x1.ap+64:real(32) - 0x1.54c296p+127:imag(32);
    const t = p * q;

    writeln(p, " ", p.type:string);
    writeln(q, " ", q.type:string);
    writeln(t, " ", t.type:string);
}   

proc main
{   
    main64;
    main32;
}
2

Hi Damian —

On my Mac running clang 14.0.0, I'm getting:

-1.50252 + 1.34112e+24i
2.9976e+19 - 2.26474e+38i
3.03728e+62 + 4.02016e+43i
-1.50252 + 1.34112e+24i complex(64)
2.9976e+19 - 2.26474e+38i complex(64)
inf + infi complex(64)

My main gcc-based system is out of commission for a few days, so I'd have to get back to you on that one. Which versions of clang and gcc are you using?

-Brad

3

You use of an llvm-based chpl agrees with mine. Wonderful.

If you could run that with a gcc-based system, it would be much appreciated.

I am using clang17. I have not build a gcc-based chpl for several years. I use gcc-11 for my C work at the moment although the people who found the problem are using a later version. Any version will do.

4

Oh, I think I misunderstood. When you said:

The following code translated into C and compiled with GCC or CLANG is broken.

I thought you were saying that when the chpl compiler translated your program into C code and Clang was selected as the back-end compiler it got the wrong answer. That's why I tried compiling with the Clang (note: not LLVM) ]back-end (i.e., CHPL_TARGET_COMPILER=clang).

Now, though, I think you're saying that when you manually translate the code into C and use Clang you get the wrong answer. Have I got it right now?

I'll give the gcc-based back-end a try when I can get back onto that system…

-Brad

5

Sorry for my poor explanation.

The Chapel program I provided yields the correct answer.

If I manually rewrite that program in C, I get the wrong answer with GCC and CLANG. The guys in Europe who noticed this problem during their research also get the wrong answer with GCC and CLANG and the Intel C compiler. They also noticed other problems with cpow() and complex division but I just attacked the simplest of the three problems.

I would appreciate it if you or someone else could run the Chapel program I provided with the chpl compiler with a GCC-backend. I have no system with a C compiler beyond GCC-11 with which to build such a chpl variant.

Thanks for your help. Apologies again for my lousy explanation earlier - Damian

1 Like
6

I've run this with GCC 13 on Ubuntu 24.04 using Chapel main (which is 2.2 pre-release) on an AMD x86-64 system. I used CHPL_TARGET_COMPILER=gnu to request the C backend using GCC.

Here is the output I see:

-1.50252 + 1.34112e+24i
2.9976e+19 - 2.26474e+38i
3.03728e+62 + 4.02016e+43i
-1.50252 + 1.34112e+24i complex(64)
2.9976e+19 - 2.26474e+38i complex(64)
inf + infi complex(64)

I see that output with or without --fast.

1 Like
7

Thanks heaps.

That means that both backends, GCC and LLVM handle the complex arithmetic correctly.

The problem recently identified in gcc, clang and icx must lie in the front-ends.

Thanks again.

8

Chapel also gets the right results for complex(128) which is good to know.

1 Like