MacOSX compiling with g++-9 from homebrew UPCXX::upcxx interface fails to properly parse --param LDFLAGS

[Rob Egan]

Hello,

I have two installs of upc++ (20190900) on my Mac, but I am forcing my build to use the bleeding edge version of UPCXXConfig.cmake.

Using clang++ works fine, but using g++-9 from homebrew yields a problem when building with the cmake library interface. This is a minor bug, since the clang++ build is working as is.

‌

Here is the result of the build rule:

cd /Users/regan/workspace/hipmeraculous/src/upcxx-utils/build-gnu/test && /usr/local/Cellar/cmake/3.16.3/bin/cmake -E cmake_link_script CMakeFiles/test_progress_bar.dir/link.txt --verbose=1
/usr/local/bin/g++-9  -O3 -DNDEBUG -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk -mmacosx-version-min=10.14 -Wl,-search_paths_first -Wl,-headerpad_max_install_names --param max-inline-insns-single=35000 inline-unit-growth=10000 large-function-growth=200000 -Wno-unused -Wunused-result -Wno-unused-parameter -Wno-address -Wl,-multiply_defined,suppress CMakeFiles/test_progress_bar.dir/test_progress_bar.cpp.o  -o test_progress_bar  ../src/libupcxx_utils.a -L/Users/regan/install-2019.09-gnu9/upcxx.O3.gasnet_seq.smp/lib -lupcxx -L/Users/regan/install-2019.09-gnu9/gasnet.opt/lib -lgasnet-smp-seq -L/usr/local/Cellar/gcc/9.2.0_3/lib/gcc/9/gcc/x86_64-apple-darwin18/9.2.0 -lgcc
g++-9: error: inline-unit-growth=10000: No such file or directory
g++-9: error: large-function-growth=200000: No such file or directory

‌

And here is what upcxx-meta wants the LDFLAGS to be

$ ~/install-2019.09-gnu9-sysv/bin/upcxx-meta LDFLAGS
-O3 --param max-inline-insns-single=35000 --param inline-unit-growth=10000 --param large-function-growth=200000 -Wno-unused -Wunused-result -Wno-unused-parameter -Wno-address -Wl,-multiply_defined,suppress

‌

And as you can see from the build rule, the last 2 of the 3 --param options loose their respective --param prefixes

--param max-inline-insns-single=35000 --param inline-unit-growth=10000 --param large-function-growth=200000

vs

--param max-inline-insns-single=35000 inline-unit-growth=10000 large-function-growth=200000 

‌

[Paul Hargrove]

Rob,

I believe this is among the many CMake issues we've resolved since the 2019.9.0 release (see commit message below).

We definitely perform automated tests of UPC++ with g++ from Homebrew on macOS, and in our (admittedly limited) testing of CMake on these systems we don't see any issues. In particular the --param seems to be preserved in each of three instances:

-- UPCXX_LINK_OPTIONS: -O3;SHELL:--param max-inline-insns-single=35000;SHELL:--param inline-unit-growth=10000;SHELL:--param large-function-growth=200000;-Wno-unused;-Wunused-result;-Wno-unused-parameter;-Wno-address;-Wl,-multiply_defined,suppress

Are you certain you are testing using the "bleeding edge" CMake package we've provided on Cori in /usr/common/ftg/upcxx/generic/share/cmake/UPCXX?

-Paul

commit 5deb5cf08859f478619694c9e43d3b111f8b228b
Author: bonachea <[e-mail]>
Date:   Fri Nov 22 04:18:21 2019 -0500

    UPCXXConfig.cmake: Add workaround for CMake bug #15826

    This CMake deduplication bug otherwise creates failures with
    grouped compiler options like '--param large-function-growth=200'

    Tweak version checks to workaround the lack of VERSION_GREATER_EQUAL
    before CMake 3.7.

[Rob Egan]

Sorry. This is not a problem with the bleeding edge version of the UPCXXConfig.cmake... Apparently the search algorithm looks for FindUPCXX.cmake in all the CMAKE_MODULE_PATH entries first, and then looks for UPCXXConfig.cmake. In my distro, renaming the file to FindUPCXX.cmake caused it to be found and used properly.