[hwloc-users] Tags for pre-releases
Folks, [resending to this mailing list; my email to the devel list failed] There don't seem to be any tags associated with hwloc prereleases (such as hwloc-2.0rc1). As you know, we embed hwloc into mpich, and we tend to use the git version (through git submodules) rather than release tarballs. Not having tags for prereleases is making it hard for us to pick a prerelease version. Can you add tags for the previous prereleases of hwloc? Or, can you at least add them for 2.0rc1 and other prereleases going forward? Thanks, -- Pavan ___ hwloc-users mailing list hwloc-users@lists.open-mpi.org https://lists.open-mpi.org/mailman/listinfo/hwloc-users
Re: [hwloc-users] Tags for pre-releases
Thanks, Brice. 2.0rc1 is sufficient for now. In the past, we only used full releases. -- Pavan > On Jan 23, 2018, at 3:56 PM, Brice Goglin wrote: > > Hello > > I didn't know you use submodule. I just pushed tag "hwloc-2.0.0rc1" and > I'll try to remember pushing one for each future rc. If I don't, please > remind me. > > I am not going to push all the previous ones because there are just too > many of them. If you need some specific ones, please let me know. > > Brice > > > > > Le 23/01/2018 à 22:39, Balaji, Pavan a écrit : >> Folks, >> >> [resending to this mailing list; my email to the devel list failed] >> >> There don't seem to be any tags associated with hwloc prereleases (such as >> hwloc-2.0rc1). As you know, we embed hwloc into mpich, and we tend to use >> the git version (through git submodules) rather than release tarballs. Not >> having tags for prereleases is making it hard for us to pick a prerelease >> version. >> >> Can you add tags for the previous prereleases of hwloc? Or, can you at >> least add them for 2.0rc1 and other prereleases going forward? >> >> Thanks, >> >> -- Pavan >> >> ___ >> hwloc-users mailing list >> hwloc-users@lists.open-mpi.org >> https://lists.open-mpi.org/mailman/listinfo/hwloc-users > ___ hwloc-users mailing list hwloc-users@lists.open-mpi.org https://lists.open-mpi.org/mailman/listinfo/hwloc-users
[hwloc-users] hwloc-2.0rc1 build warnings
Folks, I'm seeing these warnings on the mac os when building hwloc-2.0rc1 with clang: 8< CC lstopo-lstopo.o lstopo.c: In function 'usage': lstopo.c:425:7: warning: "CAIRO_HAS_XLIB_SURFACE" is not defined, evaluates to 0 [-Wundef] #elif CAIRO_HAS_XLIB_SURFACE && (defined HWLOC_HAVE_X11_KEYSYM) ^~ lstopo.c: In function 'main': lstopo.c:1041:5: warning: "CAIRO_HAS_XLIB_SURFACE" is not defined, evaluates to 0 [-Wundef] #if CAIRO_HAS_XLIB_SURFACE && defined HWLOC_HAVE_X11_KEYSYM 8< 8< % clang --version Apple LLVM version 9.0.0 (clang-900.0.39.2) Target: x86_64-apple-darwin17.4.0 Thread model: posix InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin 8< Thanks, -- Pavan ___ hwloc-users mailing list hwloc-users@lists.open-mpi.org https://lists.open-mpi.org/mailman/listinfo/hwloc-users
Re: [hwloc-users] hwloc-2.0rc1 build warnings
Hi Brice, Here are the other patches that we are currently maintaining for hwloc. Can you see if these can be integrated upstream too: https://github.com/pmodels/hwloc/commit/44fe0a500e7828bcb2390fbd24656a7a26b450ed https://github.com/pmodels/hwloc/commit/5b6d776a1226148030dcf4e26bd13fe16cc885f9 https://github.com/pmodels/hwloc/commit/9bf3ff256511ea4092928438f5718904875e65e1 The first one is definitely not usable as-is, since that breaks standalone builds. But I'm interested in hearing about any better solution that you might have. Thanks, -- Pavan > On Jan 24, 2018, at 4:43 PM, Brice Goglin wrote: > > Thanks, I am fixing this for rc2 tomorrow. > > Brice > > > > Le 24/01/2018 à 22:59, Balaji, Pavan a écrit : >> Folks, >> >> I'm seeing these warnings on the mac os when building hwloc-2.0rc1 with >> clang: >> >> 8< >> CC lstopo-lstopo.o >> lstopo.c: In function 'usage': >> lstopo.c:425:7: warning: "CAIRO_HAS_XLIB_SURFACE" is not defined, evaluates >> to 0 [-Wundef] >> #elif CAIRO_HAS_XLIB_SURFACE && (defined HWLOC_HAVE_X11_KEYSYM) >> ^~ >> lstopo.c: In function 'main': >> lstopo.c:1041:5: warning: "CAIRO_HAS_XLIB_SURFACE" is not defined, evaluates >> to 0 [-Wundef] >> #if CAIRO_HAS_XLIB_SURFACE && defined HWLOC_HAVE_X11_KEYSYM >> 8< >> >> 8< >> % clang --version >> Apple LLVM version 9.0.0 (clang-900.0.39.2) >> Target: x86_64-apple-darwin17.4.0 >> Thread model: posix >> InstalledDir: >> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin >> 8< >> >> Thanks, >> >> -- Pavan >> >> ___ >> hwloc-users mailing list >> hwloc-users@lists.open-mpi.org >> https://lists.open-mpi.org/mailman/listinfo/hwloc-users > ___ hwloc-users mailing list hwloc-users@lists.open-mpi.org https://lists.open-mpi.org/mailman/listinfo/hwloc-users
[hwloc-users] hwloc-2.0rc1 failure on Solaris
Hello, hwloc-2.0rc1 build seems to fail on Solaris, with the following CFLAGS: CFLAGS="-Werror-implicit-function-declaration -std=c99" I'm using gcc-4.8.2 Thanks, -- Pavan ___ hwloc-users mailing list hwloc-users@lists.open-mpi.org https://lists.open-mpi.org/mailman/listinfo/hwloc-users
Re: [hwloc-users] hwloc-2.0rc1 failure on Solaris
Thanks, Brice. FYI, yes, 1.11.8 has no problem building with those flags. — Pavan Sent from my iPhone > On Jan 25, 2018, at 5:50 AM, Brice Goglin wrote: > > It is actually easy to fix, we just need to move hwloc's #include before > what base64.c actually #include's. That'll be fixed in rc2 too. > > Brice > > > >> Le 25/01/2018 à 10:56, Brice Goglin a écrit : >> Like the error below? >> >> This code hasn't changed recently. Did you ever build with these flags >> before? >> >> I am not sure I'll have time to fix yet another header crazyness before rc2. >> >> Brice >> >> >> >> CC base64.lo >> In file included from >> /builds/hwloc-master-20180124.2347.gitf53fe3a/include/private/private.h:29:0, >> from base64.c:128: >> /builds/hwloc-master-20180124.2347.gitf53fe3a/include/private/misc.h: In >> function 'hwloc_strncasecmp': >> /builds/hwloc-master-20180124.2347.gitf53fe3a/include/private/misc.h:370:10: >> error: implicit declaration of function 'strncasecmp'; did you mean >> 'strncmp'? [-Werror=implicit-function-declaration] >>return strncasecmp(s1, s2, n); >> ^~~ >> strncmp >> cc1: some warnings being treated as errors >> >> >>> Le 25/01/2018 à 10:45, Balaji, Pavan a écrit : >>> Hello, >>> >>> hwloc-2.0rc1 build seems to fail on Solaris, with the following CFLAGS: >>> >>> CFLAGS="-Werror-implicit-function-declaration -std=c99" >>> >>> I'm using gcc-4.8.2 >>> >>> Thanks, >>> >>> -- Pavan >>> >>> ___ >>> hwloc-users mailing list >>> hwloc-users@lists.open-mpi.org >>> https://lists.open-mpi.org/mailman/listinfo/hwloc-users > > ___ > hwloc-users mailing list > hwloc-users@lists.open-mpi.org > https://lists.open-mpi.org/mailman/listinfo/hwloc-users ___ hwloc-users mailing list hwloc-users@lists.open-mpi.org https://lists.open-mpi.org/mailman/listinfo/hwloc-users
Re: [hwloc-users] Netloc integration with hwloc
Brice, We want to use both hwloc and netloc in mpich. What are our options here? Move back to hwloc-1.x? That’d be a bummer because we already invested a lot of effort to migrate to hwloc-2.x. — Pavan Sent from my iPhone > On Apr 3, 2018, at 6:19 PM, Brice Goglin wrote: > > It's not possible now but that would certainly be considered whenever > people start using the API and linking against libnetloc. > > Brice > > > > >> Le 03/04/2018 à 21:34, Madhu, Kavitha Tiptur a écrit : >> Hi >> A follow up question, is it possible to build netloc along with hwloc in >> embedded mode? >> >> >>> On Mar 30, 2018, at 1:34 PM, Brice Goglin wrote: >>> >>> Hello >>> >>> In 2.0, netloc is still highly experimental. Hopefully, a large rework >>> will be merged in git master next month for being released in hwloc 2.1. >>> >>> Most of the API from the old standalone netloc was made private when >>> integrated in hwloc because there wasn't any actual user. The API was >>> quite large (things for traversing the graph of both the fabric and the >>> servers' internals). We didn't want to expose such a large API before >>> getting actual user feedback. >>> >>> In short, in your need features, please let us know, so that we can >>> discuss what to expose in the public headers and how. >>> >>> Brice >>> >>> >>> >>> Le 30/03/2018 à 20:14, Madhu, Kavitha Tiptur a écrit : Hi I need some info on the status of netloc integration with hwloc. I see the include/netloc.h header is almost empty in hwloc 2.0 and lots of functionality missing compared to the previous standalone netloc release, even in private/netloc.h. Am I missing something here? Thanks Kavitha >>> ___ >>> hwloc-users mailing list >>> hwloc-users@lists.open-mpi.org >>> https://lists.open-mpi.org/mailman/listinfo/hwloc-users >> ___ >> hwloc-users mailing list >> hwloc-users@lists.open-mpi.org >> https://lists.open-mpi.org/mailman/listinfo/hwloc-users > > ___ > hwloc-users mailing list > hwloc-users@lists.open-mpi.org > https://lists.open-mpi.org/mailman/listinfo/hwloc-users ___ hwloc-users mailing list hwloc-users@lists.open-mpi.org https://lists.open-mpi.org/mailman/listinfo/hwloc-users
Re: [hwloc-users] Netloc integration with hwloc
Brice, We don't actually care if it is a graph or a different API. We'll anyway simply parse the graph and create our own internal structures that we can map to our internal algorithms. We simply need some model (any model) to retrieve the network topology. That's it. We'll take care of everything else in MPICH. -- Pavan > On Apr 4, 2018, at 12:46 AM, Brice Goglin wrote: > > If you really want the old netloc API now, you could try hwloc 2.x with > the old netloc. But that's certainly not maintained anymore, and that > only works for IB while the new netloc should have OPA and Cray support > soon. > > The plan should rather be to tell us what you need from netloc so that > we can reenable it with a good API. We hear lots of people saying they > are interested in netloc, but *nobody* ever told us anything about what > they want to do for real. And I am not even sure anybody ever played > with the old API. This software cannot go forward unless we know where > it's going. There are many ways to design the netloc API. > > * We had an explicit graph API in the old netloc but that API implied > expensive graph algorithmics in the runtimes using it. It seemed > unusable for taking decision at runtime anyway, but again ever nobody > tried. Also it was rather strange to expose the full graph when you know > the fabric is a 3D dragonfly on Cray, etc. > > * In the new netloc, we're thinking of having higher-level implicit > topologies for each class of fabric (dragon-fly, fat-tree, clos-network, > etc) that require more work on the netloc side and easier work in the > runtime using it. However that's less portable than exposing the full > graph. Not sure which one is best, or if both are needed. > > * There are also issues regarding nodes/links failure etc. How do we > expose topology changes at runtime? Do we have a daemon running as root > in the background, etc? > > Lots of question that need to be discussed before we expose a new API In > the wild. Unfortunately, we lost several years because of the lack of > users' feedback. I don't want to invest time and rush for a new API if > MPICH never actually uses it like other people did in the past. > > Brice > > > > > Le 04/04/2018 à 01:36, Balaji, Pavan a écrit : >> Brice, >> >> We want to use both hwloc and netloc in mpich. What are our options here? >> Move back to hwloc-1.x? That’d be a bummer because we already invested a >> lot of effort to migrate to hwloc-2.x. >> >> — Pavan >> >> Sent from my iPhone >> >>> On Apr 3, 2018, at 6:19 PM, Brice Goglin wrote: >>> >>> It's not possible now but that would certainly be considered whenever >>> people start using the API and linking against libnetloc. >>> >>> Brice >>> >>> >>> >>> >>>> Le 03/04/2018 à 21:34, Madhu, Kavitha Tiptur a écrit : >>>> Hi >>>> A follow up question, is it possible to build netloc along with hwloc in >>>> embedded mode? >>>> >>>> >>>>> On Mar 30, 2018, at 1:34 PM, Brice Goglin wrote: >>>>> >>>>> Hello >>>>> >>>>> In 2.0, netloc is still highly experimental. Hopefully, a large rework >>>>> will be merged in git master next month for being released in hwloc 2.1. >>>>> >>>>> Most of the API from the old standalone netloc was made private when >>>>> integrated in hwloc because there wasn't any actual user. The API was >>>>> quite large (things for traversing the graph of both the fabric and the >>>>> servers' internals). We didn't want to expose such a large API before >>>>> getting actual user feedback. >>>>> >>>>> In short, in your need features, please let us know, so that we can >>>>> discuss what to expose in the public headers and how. >>>>> >>>>> Brice >>>>> >>>>> >>>>> >>>>> >>>>>> Le 30/03/2018 à 20:14, Madhu, Kavitha Tiptur a écrit : >>>>>> Hi >>>>>> >>>>>> I need some info on the status of netloc integration with hwloc. I see >>>>>> the include/netloc.h header is almost empty in hwloc 2.0 and lots of >>>>>> functionality missing compared to the previous standalone netloc >>>>>> release, even in private/netloc.h. Am I missing something here? >>>>>> >>>>>>
[hwloc-users] Build warnings with hwloc-2.0.3
Folks, I'm getting the below build warnings with hwloc-2.0.3, gcc-7.3 on Ubuntu (with -Wall -O2): 8< ../../../../../../../../../mpich/src/pm/hydra/tools/topo/hwloc/hwloc/hwloc/distances.c: In function 'hwloc__groups_by_distances': ../../../../../../../../../mpich/src/pm/hydra/tools/topo/hwloc/hwloc/hwloc/distances.c:817:1: warning: stack usage might be unbounded [-Wstack-usage=] hwloc__groups_by_distances(struct hwloc_topology *topology, ^~ ../../../../../../../../../mpich/src/pm/hydra/tools/topo/hwloc/hwloc/hwloc/topology.c: In function 'hwloc_propagate_symmetric_subtree': ../../../../../../../../../mpich/src/pm/hydra/tools/topo/hwloc/hwloc/hwloc/topology.c:2388:1: warning: stack usage might be unbounded [-Wstack-usage=] hwloc_propagate_symmetric_subtree(hwloc_topology_t topology, hwloc_obj_t root) ^ ../../../../../../../../../mpich/src/pm/hydra/tools/topo/hwloc/hwloc/hwloc/topology-synthetic.c: In function 'hwloc_synthetic_process_indexes': ../../../../../../../../../mpich/src/pm/hydra/tools/topo/hwloc/hwloc/hwloc/topology-synthetic.c:71:1: warning: stack usage might be unbounded [-Wstack-usage=] hwloc_synthetic_process_indexes(struct hwloc_synthetic_backend_data_s *data, ^~~ ../../../../../../../../../mpich/src/pm/hydra/tools/topo/hwloc/hwloc/hwloc/topology-xml.c: In function 'hwloc__xml_export_object_contents': ../../../../../../../../../mpich/src/pm/hydra/tools/topo/hwloc/hwloc/hwloc/topology-xml.c:1920:1: warning: stack usage might be unbounded [-Wstack-usage=] hwloc__xml_export_object_contents (hwloc__xml_export_state_t state, hwloc_topology_t topology, hwloc_obj_t obj, unsigned long flags) ^ ../../../../../../../../../mpich/src/pm/hydra/tools/topo/hwloc/hwloc/hwloc/topology-linux.c: In function 'hwloc_linux_get_area_membind': ../../../../../../../../../mpich/src/pm/hydra/tools/topo/hwloc/hwloc/hwloc/topology-linux.c:1883:1: warning: stack usage might be unbounded [-Wstack-usage=] hwloc_linux_get_area_membind(hwloc_topology_t topology, const void *addr, size_t len, hwloc_nodeset_t nodeset, hwloc_membind_policy_t *policy, int flags __hwloc_attribute_unused) ^~~~ ../../../../../../../../../mpich/src/pm/hydra/tools/topo/hwloc/hwloc/hwloc/topology-linux.c: In function 'hwloc_linux_set_thisthread_membind': ../../../../../../../../../mpich/src/pm/hydra/tools/topo/hwloc/hwloc/hwloc/topology-linux.c:1737:1: warning: stack usage might be unbounded [-Wstack-usage=] hwloc_linux_set_thisthread_membind(hwloc_topology_t topology, hwloc_const_nodeset_t nodeset, hwloc_membind_policy_t policy, int flags) ^~ ../../../../../../../../../mpich/src/pm/hydra/tools/topo/hwloc/hwloc/hwloc/topology-linux.c: In function 'hwloc_linux_get_thisthread_membind': ../../../../../../../../../mpich/src/pm/hydra/tools/topo/hwloc/hwloc/hwloc/topology-linux.c:1848:1: warning: stack usage might be unbounded [-Wstack-usage=] hwloc_linux_get_thisthread_membind(hwloc_topology_t topology, hwloc_nodeset_t nodeset, hwloc_membind_policy_t *policy, int flags __hwloc_attribute_unused) ^~ ../../../../../../../../../mpich/src/pm/hydra/tools/topo/hwloc/hwloc/hwloc/topology-linux.c: In function 'hwloc_linux__get_allowed_resources': ../../../../../../../../../mpich/src/pm/hydra/tools/topo/hwloc/hwloc/hwloc/topology-linux.c:4426:13: warning: stack usage might be unbounded [-Wstack-usage=] static void hwloc_linux__get_allowed_resources(hwloc_topology_t topology, const char *root_path, int root_fd, char **cpuset_namep) ^~ ../../../../../../../../../mpich/src/pm/hydra/tools/topo/hwloc/hwloc/hwloc/topology-x86.c: In function 'cpuiddump_read': ../../../../../../../../../mpich/src/pm/hydra/tools/topo/hwloc/hwloc/hwloc/topology-x86.c:69:1: warning: stack usage might be unbounded [-Wstack-usage=] cpuiddump_read(const char *dirpath, unsigned idx) ^~ ../../../../../../../../../mpich/src/pm/hydra/tools/topo/hwloc/hwloc/hwloc/topology-x86.c: In function 'hwloc_x86_component_instantiate': ../../../../../../../../../mpich/src/pm/hydra/tools/topo/hwloc/hwloc/hwloc/topology-x86.c:1456:1: warning: stack usage might be unbounded [-Wstack-usage=] hwloc_x86_component_instantiate(struct hwloc_disc_component *component, ^~~ 8< -- Pavan ___ hwloc-users mailing list hwloc-users@lists.open-mpi.org https://lists.open-mpi.org/mailman/listinfo/hwloc-users
Re: [hwloc-users] Build warnings with hwloc-2.0.3
Hi Brice, > On Feb 25, 2019, at 2:27 AM, Brice Goglin wrote: > Are you sure you're not passing -Wstack-usage? My Ubuntu 18.04 with > latest gcc-7 (7.3.0-27ubuntu1~18.04) doesn't show any of those warnings. Yes, you are right, -Wstack-usage was explicitly added too. Sorry, I missed the fact that it wasn't default in -Wall. > It looks like all these warnings are caused by C99 variable-length > arrays (except 2 that I don't understand). I know the kernel devs > stopped using VLA recently, and it looks like C11 made them optional. > But are we really supposed to stop using VLA already? They are optional, which means we cannot assume them for portability reasons. FWIW, we have made the rest of mpich stack-usage clean. -- Pavan ___ hwloc-users mailing list hwloc-users@lists.open-mpi.org https://lists.open-mpi.org/mailman/listinfo/hwloc-users
Re: [hwloc-users] Build warnings with hwloc-2.0.3
Brice, all, Any update on this? Are you guys planning on fixing these? -- Pavan > On Feb 25, 2019, at 7:33 AM, Balaji, Pavan via hwloc-users > wrote: > > Hi Brice, > >> On Feb 25, 2019, at 2:27 AM, Brice Goglin wrote: >> Are you sure you're not passing -Wstack-usage? My Ubuntu 18.04 with >> latest gcc-7 (7.3.0-27ubuntu1~18.04) doesn't show any of those warnings. > > Yes, you are right, -Wstack-usage was explicitly added too. Sorry, I missed > the fact that it wasn't default in -Wall. > >> It looks like all these warnings are caused by C99 variable-length >> arrays (except 2 that I don't understand). I know the kernel devs >> stopped using VLA recently, and it looks like C11 made them optional. >> But are we really supposed to stop using VLA already? > > They are optional, which means we cannot assume them for portability reasons. > FWIW, we have made the rest of mpich stack-usage clean. > > -- Pavan > > ___ > hwloc-users mailing list > hwloc-users@lists.open-mpi.org > https://lists.open-mpi.org/mailman/listinfo/hwloc-users ___ hwloc-users mailing list hwloc-users@lists.open-mpi.org https://lists.open-mpi.org/mailman/listinfo/hwloc-users
Re: [hwloc-users] Build warnings with hwloc-2.0.3
> On Mar 18, 2019, at 9:14 AM, Brice Goglin wrote: > I am planning to fix this in 2.1 (to be released before summer). I'll > backport the trivial pieces to 2.0.x too. > > Do you care about a specific value passed to -Wstack-usage=X? or do you > just want to avoid dynamic/unbounded allocs on the stack? Thanks, Brice. The specific value is not so important as long as it's not crazy high. FYI, we use 256K in mpich, but that was somewhat arbitrarily chosen. -- Pavan ___ hwloc-users mailing list hwloc-users@lists.open-mpi.org https://lists.open-mpi.org/mailman/listinfo/hwloc-users
[hwloc-users] hwloc LDFLAGS in embedded builds
Folks, We ran into an issue with the hwloc integration for MPICH. On Mac OS, hwloc detects that OpenCL is available, but the corresponding LDFLAGS are not exported upstream to MPICH, causing application builds to fail at the link stage. See this issue, for example: https://github.com/pmodels/mpich/issues/3449 We were able to fix this by having HWLOC export LDFLAGS upstream: https://github.com/pmodels/hwloc/commit/c2e5db2a47 Please consider integrating this patch into your next release. Thanks, -- Pavan ___ hwloc-users mailing list hwloc-users@lists.open-mpi.org https://lists.open-mpi.org/mailman/listinfo/hwloc-users
Re: [hwloc-users] hwloc LDFLAGS in embedded builds
Thanks, Brice. -- Pavan > On May 25, 2019, at 1:43 AM, Brice Goglin wrote: > > Thanks Pavan, I am pushing this. > > Brice > > > > Le 25/05/2019 à 08:19, Balaji, Pavan via hwloc-users a écrit : >> Folks, >> >> We ran into an issue with the hwloc integration for MPICH. On Mac OS, hwloc >> detects that OpenCL is available, but the corresponding LDFLAGS are not >> exported upstream to MPICH, causing application builds to fail at the link >> stage. >> >> See this issue, for example: https://github.com/pmodels/mpich/issues/3449 >> >> We were able to fix this by having HWLOC export LDFLAGS upstream: >> https://github.com/pmodels/hwloc/commit/c2e5db2a47 >> >> Please consider integrating this patch into your next release. >> >> Thanks, >> >> -- Pavan >> >> ___ >> hwloc-users mailing list >> hwloc-users@lists.open-mpi.org >> https://lists.open-mpi.org/mailman/listinfo/hwloc-users > ___ > hwloc-users mailing list > hwloc-users@lists.open-mpi.org > https://lists.open-mpi.org/mailman/listinfo/hwloc-users ___ hwloc-users mailing list hwloc-users@lists.open-mpi.org https://lists.open-mpi.org/mailman/listinfo/hwloc-users
[hwloc-users] Unused function
Hello, We are maintaining this patch for hwloc internally in mpich. Can this be upstreamed? https://github.com/pmodels/hwloc/commit/a6d7018f092a0754433a0a2b17a527e64a125d38 It was throwing a warning when compiled with clang (and our usual strict flags): 8< CC topology-hardwired.lo topology-linux.c:458:1: warning: unused function 'hwloc_lstat' [-Wunused-function] hwloc_lstat(const char *p, struct stat *st, int d __hwloc_attribute_unused) ^ CC topology-x86.lo 1 warning generated. In directory: /var/lib/jenkins-slave/workspace/mpich-warnings-gpu/compiler/clang-8/config/strict/device/ch4-ucx/gpu/cuda/label/centos64_review/src/pm/hydra/tools/topo/hwloc/hwloc/hwloc CC topology-hardwired.lo topology-linux.c:458:1: warning: unused function 'hwloc_lstat' [-Wunused-function] hwloc_lstat(const char *p, struct stat *st, int d __hwloc_attribute_unused) ^ CC topology-x86.lo 8< Thanks, -- Pavan ___ hwloc-users mailing list hwloc-users@lists.open-mpi.org https://lists.open-mpi.org/mailman/listinfo/hwloc-users
Re: [hwloc-users] Unused function
Hi Brice, > On May 29, 2020, at 3:51 AM, Brice Goglin wrote: > Oh sure, I thought we fixed this a while ago. I pushed it to master. Do > you need in 2.2 only or also earlier stable series? I don't we need a backport for now. We are currently at 2.0.3, but we'll likely upgrade to 2.2 before our next release. Regards, -- Pavan ___ hwloc-users mailing list hwloc-users@lists.open-mpi.org https://lists.open-mpi.org/mailman/listinfo/hwloc-users
[hwloc-users] One more silly warning squash
Folks, We are seeing some warnings with the Intel compiler with hwloc (listed below). The warnings seem to be somewhat silly because there already is a cast to "char *" from the string literal, but it seems to expect a cast to "const char *" before casting to "char *". We are maintaining the below patch to workaround it. Can you either integrate this or a better fix for the warning? https://github.com/pmodels/hwloc/commit/fb27dc6e21bac14754d1b50b57f752e37d475704 This is with icc 19.0.3.199. Regards, -- Pavan 8< In directory: /var/lib/jenkins-slave/workspace/balaji-wip-mpich-warnings/compiler/intel/config/ch3-nemesis-tcp/label/centos64_review/modules/hwloc/hwloc CC topology-linux.lo topology-xml-nolibxml.c(228): warning #3179: deprecated conversion of string literal to char* (should be const char*) *beginp = (char *) ""; ^ topology-xml-nolibxml.c(304): warning #3179: deprecated conversion of string literal to char* (should be const char*) nstate->tagname = (char *) "topology"; ^ topology-xml.c(707): warning #3179: deprecated conversion of string literal to char* (should be const char*) char *buffer = (char *) ""; ^ topology-xml-libxml.c(158): warning #3179: deprecated conversion of string literal to char* (should be const char*) *beginp = (char *) ""; ^ CC topology-hardwired.lo traversal.c(598): warning #3179: deprecated conversion of string literal to char* (should be const char*) const char *quote = strchr(info->value, ' ') ? "\"" : ""; ^ CC topology-x86.lo topology-linux.c(4764): warning #3179: deprecated conversion of string literal to char* (should be const char*) data->dumped_hwdata_dirname = (char *) RUNSTATEDIR "/hwloc/"; 8< ___ hwloc-users mailing list hwloc-users@lists.open-mpi.org https://lists.open-mpi.org/mailman/listinfo/hwloc-users
Re: [hwloc-users] One more silly warning squash
Hi Samuel, > On Jun 1, 2020, at 4:06 AM, Samuel Thibault wrote: > could you check whether the attached patch avoids the warning? > (we should really not need a cast to const char*) The attached patch is basically the same as what we are using, isn't it? It does avoid the warning. -- Pavan ___ hwloc-users mailing list hwloc-users@lists.open-mpi.org https://lists.open-mpi.org/mailman/listinfo/hwloc-users
Re: [hwloc-users] One more silly warning squash
> On Jun 1, 2020, at 4:10 AM, Balaji, Pavan wrote: >> On Jun 1, 2020, at 4:06 AM, Samuel Thibault wrote: >> could you check whether the attached patch avoids the warning? >> (we should really not need a cast to const char*) > > The attached patch is basically the same as what we are using, isn't it? It > does avoid the warning. Oh, sorry, I see now that you skipped the extra cast in that case. Let me try it out and get back to you. -- Pavan ___ hwloc-users mailing list hwloc-users@lists.open-mpi.org https://lists.open-mpi.org/mailman/listinfo/hwloc-users
Re: [hwloc-users] One more silly warning squash
> On Jun 1, 2020, at 4:11 AM, Balaji, Pavan via hwloc-users > wrote: >> On Jun 1, 2020, at 4:10 AM, Balaji, Pavan wrote: >>> On Jun 1, 2020, at 4:06 AM, Samuel Thibault >>> wrote: >>> could you check whether the attached patch avoids the warning? >>> (we should really not need a cast to const char*) >> >> The attached patch is basically the same as what we are using, isn't it? It >> does avoid the warning. > > Oh, sorry, I see now that you skipped the extra cast in that case. Let me > try it out and get back to you. I've verified that the patch works. Thanks, -- Pavan ___ hwloc-users mailing list hwloc-users@lists.open-mpi.org https://lists.open-mpi.org/mailman/listinfo/hwloc-users
