Wrong application results on ppc64

[PHHargrove]

Extracted from issue #36:

Steven Watanabe wrote:

On 03/06/2014 06:57 PM, Paul H. Hargrove wrote:

Hmm... clang-upc doesn't seem to be working to well on PP64 (big-endian) either:

This is almost certainly a mismatch between the library and clang CodeGen representations of pointers-to-shared.

$ clangupc upc-runtime/upc-examples/cpi/mcpi.upc $ ./a.out -n 4 PI estimated to 0.0000000 from 1000000 trials on 4 threads.

Paul responded:

Gary had indicated in email previously that he was unsure the vaddr=first/last logic was right for big-endian. So, that would be a good place to look if somebody wants to pursue this.

[PHHargrove]

I have tried each the following without any change in application output:

• -fupc-pts=struct
• -fupc-pts-vaddr-order=first
• -fupc-pts-vaddr-order=last

If nothing else, I would have expected the struct PTS rep to be independent of endian issues. So, it might not be as simple as we are hoping.

[nenadv]

After fixing #45, #47, and #48 we are passing PPC harness tests with -O0 and -O3.

logroot/20140319_171544
  Compile:
    SUCCESS:  1724
      KNOWN:  1
        NEW:  0
  Run:
    SUCCESS:  1116
      KNOWN:  0
       TIME:  0
        NEW:  0

For the record, I used the following compile options:

clang-upc -O3 -I. -Wno-duplicate-decl-specifier -Werror=pointer-arith -Wno-deprecated

and the following features:

feature_list = gupc,upc_all_free,upc_atomics,upc_castable,upc_collective,upc_nb,upc_tick,upc_types,os_linux,cpu_x86_64,c
pu_64,cc_gnu,packedsptr,upc_io_64

[PHHargrove]

That is great news.

I see packedsptr in the feature list. What is the status of -fpts=packed (with its potential sensitivity to endianness)? Is that still blocked by a remaining function calling ABI issue?

BTW, for which tests did '-Wno-deprecated' become important? If there are tests that can/should be updated I'd like to know.

[nenadv]

By default we are packed pointer representation. If you are referring to #45 (ABI for return shared poiner) it is closed now. I did not run struct pointer representation - will do that next but as we had no issues on x86 I do not expect them here either.

If you use "clang-upc" on .c file extensions clang will complain that this option is deprecated. I do not recall specifics on this but I think that this just copies the behavior of the C++ compiler when .c files are compiled.