June 2019 - discuss - mailman3.cels.anl.gov

Re: [mpich-discuss] Cross-compile mpich-3.2 with Intel compilers collection
by yurij 26 Jun '19

26 Jun '19

The problem has been solved by appending to /root/fort.types the following variables: CROSS_F90_OFFSET_KIND=8 CROSS_F90_REAL_MODEL=6,37 CROSS_F90_DOUBLE_MODEL=15,307 CROSS_F90_INTEGER_MODEL=9 CROSS_F90_ALL_INTEGER_MODELS=2,1,4,2,9,4,18,8, CROSS_F90_INTEGER_MODEL_MAP={2,1,1},{4,2,2},{9,4,4},{18,8,8}, It seems configure from MPICH-3.2 isn't ready jet to build cross compile version without little "magic". On 6/26/19 8:15 AM, Yurij Goncharuk wrote: > Hello! > > I'm using Intel compilers collection from Parallel Studio 2019 and trying to build MPICH-3.2 against it for the recent CPU. My configure scenario: > > MPICHLIB_CFLAGS="-xCORE-AVX512" \ > MPICHLIB_CXXFLAGS="-xCORE-AVX512" \ > MPICHLIB_FCFLAGS="-xCORE-AVX512" \ > MPICHLIB_FFLAGS="-xCORE-AVX512" \ > LDFLAGS="-Wl,--disable-new-dtags" \ > ./configure \ > CC="/opt/intel/bin/icc" \ > CXX="/opt/intel/bin/icpc" \ > FC="/opt/intel/bin/ifort" \ > F77="/opt/intel/bin/ifort" \ > --with-pic \ > --enable-shared \ > AR="ar" \ > RANLIB="ranlib" \ > --enable-f77 \ > --enable-fc \ > --enable-cxx \ > --enable-fast=all,nompit \ > --prefix=/usr \ > --host=x86_64-pc-linux-gnu \ > --with-cross=/root/fort.types > > /root/fort.types contains: > > CROSS_F77_SIZEOF_INTEGER=4 > CROSS_F77_SIZEOF_REAL=4 > CROSS_F77_SIZEOF_DOUBLE_PRECISION=8 > CROSS_F77_TRUE_VALUE=1 > CROSS_F77_FALSE_VALUE=0 > CROSS_F90_ADDRESS_KIND=8 > CROSS_F90_INTEGER_KIND=4 > > configure completes successfully but build fails with the following error: > > CC src/glue/romio/lib_libmpi_la-all_romio_symbols.lo > src/binding/fortran/use_mpi/create_f90_real.c(75): error: expected an expression > { MPIR_F90_REAL_MODEL, MPI_REAL}, > ^ > > src/binding/fortran/use_mpi/create_f90_real.c(76): error: expected an expression > { MPIR_F90_DOUBLE_MODEL, MPI_DOUBLE_PRECISION } }; > ^ > > compilation aborted for src/binding/fortran/use_mpi/create_f90_real.c (code 2) > make[2]: *** [src/binding/fortran/use_mpi/lib_libmpi_la-create_f90_real.lo] Error 1 > make[2]: *** Waiting for unfinished jobs.... > src/binding/fortran/use_mpi/create_f90_complex.c(76): error: expected an expression > { MPIR_F90_REAL_MODEL, MPI_COMPLEX}, > ^ > > src/binding/fortran/use_mpi/create_f90_complex.c(77): error: expected an expression > { MPIR_F90_DOUBLE_MODEL, MPI_DOUBLE_COMPLEX } }; > ^ > > compilation aborted for src/binding/fortran/use_mpi/create_f90_complex.c (code 2) > make[2]: *** [src/binding/fortran/use_mpi/lib_libmpi_la-create_f90_complex.lo] Error 1 > make[2]: Leaving directory `/root/mpich-3.2' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/root/mpich-3.2' > make: *** [all] Error 2 > > I google about this and have founded that mpif90model.h isn't initialized and therefore macros MPIR_F90_* is undefined. Also there was mentioned that: > > "More specifically, the binaries that are supposed to run and tell configure what it wants to know fail to link because configure tries to set rpath." > > How can I done cross compile MPICH-3.2 against Intel compilers without disabling fortran libraries? > > I compile MPICH-3.2 in Docker environment with SLES 11 SP4 as container OS > > Thank’s to all for any help! > > /*-----------------------* > Best regards! > Yurij Goncharuk > lnkgyv(a)gmail.com > /*-----------------------* > /*-----------------------* Best regards! Yurij Goncharuk lnkgyv(a)gmail.com /*-----------------------*

1 0

Cross-compile mpich-3.2 with Intel compilers collection
by Yurij Goncharuk 26 Jun '19

26 Jun '19

Hello! I'm using Intel compilers collection from Parallel Studio 2019 and trying to build MPICH-3.2 against it for the recent CPU. My configure scenario: MPICHLIB_CFLAGS="-xCORE-AVX512" \ MPICHLIB_CXXFLAGS="-xCORE-AVX512" \ MPICHLIB_FCFLAGS="-xCORE-AVX512" \ MPICHLIB_FFLAGS="-xCORE-AVX512" \ LDFLAGS="-Wl,--disable-new-dtags" \ ./configure \ CC="/opt/intel/bin/icc" \ CXX="/opt/intel/bin/icpc" \ FC="/opt/intel/bin/ifort" \ F77="/opt/intel/bin/ifort" \ --with-pic \ --enable-shared \ AR="ar" \ RANLIB="ranlib" \ --enable-f77 \ --enable-fc \ --enable-cxx \ --enable-fast=all,nompit \ --prefix=/usr \ --host=x86_64-pc-linux-gnu \ --with-cross=/root/fort.types /root/fort.types contains: CROSS_F77_SIZEOF_INTEGER=4 CROSS_F77_SIZEOF_REAL=4 CROSS_F77_SIZEOF_DOUBLE_PRECISION=8 CROSS_F77_TRUE_VALUE=1 CROSS_F77_FALSE_VALUE=0 CROSS_F90_ADDRESS_KIND=8 CROSS_F90_INTEGER_KIND=4 configure completes successfully but build fails with the following error: CC src/glue/romio/lib_libmpi_la-all_romio_symbols.lo src/binding/fortran/use_mpi/create_f90_real.c(75): error: expected an expression { MPIR_F90_REAL_MODEL, MPI_REAL}, ^ src/binding/fortran/use_mpi/create_f90_real.c(76): error: expected an expression { MPIR_F90_DOUBLE_MODEL, MPI_DOUBLE_PRECISION } }; ^ compilation aborted for src/binding/fortran/use_mpi/create_f90_real.c (code 2) make[2]: *** [src/binding/fortran/use_mpi/lib_libmpi_la-create_f90_real.lo] Error 1 make[2]: *** Waiting for unfinished jobs.... src/binding/fortran/use_mpi/create_f90_complex.c(76): error: expected an expression { MPIR_F90_REAL_MODEL, MPI_COMPLEX}, ^ src/binding/fortran/use_mpi/create_f90_complex.c(77): error: expected an expression { MPIR_F90_DOUBLE_MODEL, MPI_DOUBLE_COMPLEX } }; ^ compilation aborted for src/binding/fortran/use_mpi/create_f90_complex.c (code 2) make[2]: *** [src/binding/fortran/use_mpi/lib_libmpi_la-create_f90_complex.lo] Error 1 make[2]: Leaving directory `/root/mpich-3.2' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/root/mpich-3.2' make: *** [all] Error 2 I google about this and have founded that mpif90model.h isn't initialized and therefore macros MPIR_F90_* is undefined. Also there was mentioned that: "More specifically, the binaries that are supposed to run and tell configure what it wants to know fail to link because configure tries to set rpath." How can I done cross compile MPICH-3.2 against Intel compilers without disabling fortran libraries? I compile MPICH-3.2 in Docker environment with SLES 11 SP4 as container OS Thank’s to all for any help! /*-----------------------* Best regards! Yurij Goncharuk lnkgyv(a)gmail.com /*-----------------------*

1 0

Re: [mpich-discuss] mpich-3.3.1 cannot launch hydra_pmi_proxy in SGE
by Reuti 24 Jun '19

24 Jun '19

Hi, > Am 14.06.2019 um 02:59 schrieb Shuwei Zhao via discuss <discuss(a)mpich.org>: > > Hi mpich team, > > > > My team had a issue met in mpich-3.2.1 as Xiaopeng mentioned before. As you replied, the bug was fixed in mpich-3.3.1. > > However as I installed mpich-3.3.1, finished integration and launched test. > > Single machine is fine. But cross machine only doesn’t work in SGE environment while it works well in lsf. For me it still works fine. We have no SSH in the cluster and all is started solely by `qrsh -inherit …` on the slave nodes. Master of the parallel job: 11870 ? S 0:00 \_ sge_shepherd-308116 -bg 11933 ? SNs 0:00 \_ /bin/sh /var/spool/sge/node26/job_scripts/308116 11934 ? SN 0:00 \_ mpiexec ./mpihello 11935 ? SNs 0:00 \_ /home/reuti/local/mpich-3.3.1_gcc-6.5.0/bin/hydra_pmi_proxy --control-port node26:40054 --rmk sge --launcher sge --demux poll --pgid 0 --retries 10 --usize -2 --proxy-id 0 11942 ? RNs 1:43 | \_ ./mpihello 11943 ? RNs 1:43 | \_ ./mpihello 11936 ? SNsl 0:00 \_ /usr/sge/bin/lx24-em64t/qrsh -inherit -V node28 "/home/reuti/local/mpich-3.3.1_gcc-6.5.0/bin/hydra_pmi_proxy" --control-port node26:40054 --rmk sge --launcher sge --demux poll --pgid 0 --retries 10 --usize -2 --proxy-id 1 11937 ? SNsl 0:00 \_ /usr/sge/bin/lx24-em64t/qrsh -inherit -V node27 "/home/reuti/local/mpich-3.3.1_gcc-6.5.0/bin/hydra_pmi_proxy" --control-port node26:40054 --rmk sge --launcher sge --demux poll --pgid 0 --retries 10 --usize -2 --proxy-id 2 11938 ? SNsl 0:00 \_ /usr/sge/bin/lx24-em64t/qrsh -inherit -V node25 "/home/reuti/local/mpich-3.3.1_gcc-6.5.0/bin/hydra_pmi_proxy" --control-port node26:40054 --rmk sge --launcher sge --demux poll --pgid 0 --retries 10 --usize -2 --proxy-id 3 11939 ? SNsl 0:00 \_ /usr/sge/bin/lx24-em64t/qrsh -inherit -V node24 "/home/reuti/local/mpich-3.3.1_gcc-6.5.0/bin/hydra_pmi_proxy" --control-port node26:40054 --rmk sge --launcher sge --demux poll --pgid 0 --retries 10 --usize -2 --proxy-id 4 11940 ? SNsl 0:00 \_ /usr/sge/bin/lx24-em64t/qrsh -inherit -V node29 "/home/reuti/local/mpich-3.3.1_gcc-6.5.0/bin/hydra_pmi_proxy" --control-port node26:40054 --rmk sge --launcher sge --demux poll --pgid 0 --retries 10 --usize -2 --proxy-id 5 11941 ? SNsl 0:00 \_ /usr/sge/bin/lx24-em64t/qrsh -inherit -V node23 "/home/reuti/local/mpich-3.3.1_gcc-6.5.0/bin/hydra_pmi_proxy" --control-port node26:40054 --rmk sge --launcher sge --demux poll --pgid 0 --retries 10 --usize -2 --proxy-id 6 One of the slaves: 3904 ? Sl 958:10 /usr/sge/bin/lx24-em64t/sge_execd 4012 ? S 14:55 \_ /bin/sh /usr/sge/cluster/tmpspace.sh 17401 ? Sl 0:00 \_ sge_shepherd-308116 -bg 17402 ? SNs 0:00 \_ /usr/sge/utilbin/lx24-em64t/qrsh_starter /var/spool/sge/node23/active_jobs/308116.1/1.node23 17409 ? SN 0:00 \_ /home/reuti/local/mpich-3.3.1_gcc-6.5.0/bin/hydra_pmi_proxy --control-port node26:40054 --rmk sge --launcher sge --demux poll --pgid 0 --retries 10 --usize -2 --proxy-id 6 17410 ? RNs 0:38 \_ ./mpihello -- Reuti > mpich-3.2.1 > > mpich-3.3.1 > > Relevant processes greped out using “ps -eo user,pid,ppid,cmd” > > sgeadmin 2288 3938 sge_shepherd-768144 -bg > > sgeadmin 2317 3938 sge_shepherd-768145 -bg > > szhao 2367 2317 /remote/swefs1/PE/products/cktsim/p2019.06_rel/image/nightly/finesim_optimize/D20190611_5647184/Testing/finesim/bin/mpich/mpiexec -n 1 /remote/swefs1/PE/products/cktsim/p2019.06_rel/image/nightly/finesim_optimize/D20190611_5647184/Testing/bin/finesim my_command_line_argument > > szhao 2368 2288 /remote/swefs1/PE/products/cktsim/p2019.06_rel/image/nightly/finesim_optimize/D20190611_5647184/Testing/finesim/bin/mpich/mpiexec -n 1 /remote/swefs1/PE/products/cktsim/p2019.06_rel/image/nightly/finesim_optimize/D20190611_5647184/Testing/bin/finesim my_command_line_arguments > > szhao 2372 2368 /remote/swefs1/PE/products/cktsim/p2019.06_rel/image/nightly/finesim_optimize/D20190611_5647184/Testing/finesim/bin/mpich/hydra_pmi_proxy --control-port broad1029.internal.synopsys.com:39346 --rmk sge --launcher sge --demux poll --pgid 0 --retries 10 --usize -2 --proxy-id 0 > > szhao 2373 2367 /remote/swefs1/PE/products/cktsim/p2019.06_rel/image/nightly/finesim_optimize/D20190611_5647184/Testing/finesim/bin/mpich/hydra_pmi_proxy --control-port broad1029.internal.synopsys.com:44694 --rmk sge --launcher sge --demux poll --pgid 0 --retries 10 --usize -2 --proxy-id 0 > > szhao 2374 2372 /remote/swefs1/PE/products/cktsim/p2019.06_rel/image/nightly/finesim_optimize/D20190611_5647184/Testing/finesim/platform/linux64/finesim my_command_line_arguments > > szhao 2375 2373 /remote/swefs1/PE/products/cktsim/p2019.06_rel/image/nightly/finesim_optimize/D20190611_5647184/Testing/finesim/platform/linux64/finesim my_command_line_arguments > > sgeadmin 3938 1 /remote/sge3/default/bin/lx-amd64/sge_execd > > sgeadmin 11119 3158 sge_shepherd-801927 -bg > > sgeadmin 11151 3158 sge_shepherd-801928 -bg > > szhao 11149 11119 /slowfs/finesim6/users/szhao/src/finesim/cktsim_dev/snps/finesim/optimize/finesim/bin/mpich/mpiexec -n 1 /slowfs/finesim6/users/szhao/src/finesim/cktsim_dev/snps/finesim/optimize/bin/finesim my_command_line_argument > > szhao 11180 11151 /slowfs/finesim6/users/szhao/src/finesim/cktsim_dev/snps/finesim/optimize/finesim/bin/mpich/mpiexec -n 1 /slowfs/finesim6/users/szhao/src/finesim/cktsim_dev/snps/finesim/optimize/bin/finesim -o xxx -new_flow input.sp -DEBUG -ns 1 -dpmt_flow -dscale xxx.dynamic -pmc > > szhao 11150 11149 [qrsh] <defunct> > > szhao 11181 11180 [qrsh] <defunct> > > sgeadmin 3158 1 /remote/sge3/default/bin/lx-amd64/sge_execd > > Processes spawned procedure > > From above, we can see that process spawned like this: > > Sge_execd -> sge_shepherd > mpiexec -> hydra_pmi_proxy -> my_process > > > > From above, we can see that process spawned like this: > > Sge_execd -> sge_shepherd > mpiexec -X-> hydra_pmi_proxy -> my_process > > > > > If you are able to track the pid and ppid, Looks like hydra_pmi_proxy is unable to spawn when run with mpich-3.3 on sge environment. Could you please help confirm is it a potential bug or there is something that I didn’t take care of? > > > > Thanks, > > Shuwei > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss

1 0

Re: [mpich-discuss] [WARNING: UNSCANNABLE EXTRACTION FAILED]libmpi.so: undefined reference to `memcpy@GLIBC_2.14'
by Phạm Ngọc Kiên 24 Jun '19

24 Jun '19

Dear Joseph, Yes, I will check it again. I think that I can overcome this problem. Thank you very much Best regards, Kien Vào Th 2, 24 thg 6, 2019 vào lúc 16:24 Joseph Schuchart via discuss < discuss(a)mpich.org> đã viết: > Kien, > > In my experience, this type of error is typically caused by a version > mismatch between the compiler used to build the library (libmpi.so) and > the compiler used to build the application (anaconda3). Can you check > that both MPICH and Anaconda are built using the same compiler? > > Cheers, > Joseph > > On 6/24/19 2:41 AM, Phạm Ngọc Kiên via discuss wrote: > > Hi all, > > When installing MPICH-3.3.1, I got the error like: > > > /home/kien/anaconda3/bin/../lib/gcc/x86_64-conda_cos6-linux-gnu/7.3.0/../../../../x86_64-conda_cos6-linux-gnu/bin/ld: > > > lib/.libs/libmpi.so: undefined reference to `memcpy(a)GLIBC_2.14' > > > > I don't know how to find the above reference in anacoda3. > > Could you please tell me how to fix this? > > > > Thank you very much. > > Best regards. > > Kien > > > > _______________________________________________ > > discuss mailing list discuss(a)mpich.org > > To manage subscription options or unsubscribe: > > https://lists.mpich.org/mailman/listinfo/discuss > > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss >

1 0

Re: [mpich-discuss] [WARNING: UNSCANNABLE EXTRACTION FAILED]libmpi.so: undefined reference to `memcpy@GLIBC_2.14'
by Joseph Schuchart 24 Jun '19

24 Jun '19

Kien, In my experience, this type of error is typically caused by a version mismatch between the compiler used to build the library (libmpi.so) and the compiler used to build the application (anaconda3). Can you check that both MPICH and Anaconda are built using the same compiler? Cheers, Joseph On 6/24/19 2:41 AM, Phạm Ngọc Kiên via discuss wrote: > Hi all, > When installing MPICH-3.3.1, I got the error like: > /home/kien/anaconda3/bin/../lib/gcc/x86_64-conda_cos6-linux-gnu/7.3.0/../../../../x86_64-conda_cos6-linux-gnu/bin/ld: > lib/.libs/libmpi.so: undefined reference to `memcpy(a)GLIBC_2.14' > > I don't know how to find the above reference in anacoda3. > Could you please tell me how to fix this? > > Thank you very much. > Best regards. > Kien > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss >

1 0

[WARNING: UNSCANNABLE EXTRACTION FAILED]libmpi.so: undefined reference to `memcpy@GLIBC_2.14'
by Phạm Ngọc Kiên 23 Jun '19

23 Jun '19

Hi all, When installing MPICH-3.3.1, I got the error like: /home/kien/anaconda3/bin/../lib/gcc/x86_64-conda_cos6-linux-gnu/7.3.0/../../../../x86_64-conda_cos6-linux-gnu/bin/ld: lib/.libs/libmpi.so: undefined reference to `memcpy(a)GLIBC_2.14' I don't know how to find the above reference in anacoda3. Could you please tell me how to fix this? Thank you very much. Best regards. Kien

1 0

Re: [mpich-discuss] Incorrect error checking?
by Zhou, Hui 20 Jun '19

20 Jun '19

> Still, the check is dependent on a non-cross-compile safe configure test. In the cross-compile case, configure will also not set that macro. However, one has to explicitly pass in different `—host=` and `—build=` to trigger cross compile. — Hui Zhou T: 630-252-3430 On Jun 20, 2019, at 2:38 PM, Raffenetti, Kenneth J. via discuss <discuss(a)mpich.org<mailto:[email protected]>> wrote: Still, the check is dependent on a non-cross-compile safe configure test.

1 0

Re: [mpich-discuss] Incorrect error checking?
by Raffenetti, Kenneth J. 20 Jun '19

20 Jun '19

FWIW, the example below does generate a warning with clang. The unaligned access would probably cause a SIGBUS on sparc. $ clang foo.c foo.c:14:18: warning: taking address of packed member 'b' of class or structure '' may result in an unaligned pointer value [-Waddress-of-packed-member] c = (int *)&s.b; ^~~ 1 warning generated. Still, the check is dependent on a non-cross-compile safe configure test. Ken On 6/20/19 2:09 PM, Raffenetti, Kenneth J. via discuss wrote: > Hmm, interesting. I think this example false-positive is pretty good > reason to remove the check from MPICH. > > Ken > > On 6/20/19 1:42 PM, Nick Radcliffe via discuss wrote: >> Hui, >> >> >> The library was built on one of our internal build servers, and run on a >> different machine of course. But I don't think it's a configure issue. I >> did a quick test and it's definitely possible for the address of a >> pointer to not be 8-byte aligned: >> >> >> [nradclif@heron ~]$ cat test_align.c >> #include <stdlib.h> >> #include <stdio.h> >> >> int main() >> { >> int *c; >> >> struct >> { >> int a; >> int *b; >> } __attribute__((packed)) s; >> >> c = (int *)&s.b; >> >> fprintf(stdout, "c = %p\n", c); >> >> return 0; >> } >> [nradclif@heron ~]$ ./test_align.x >> c = 0x7ffe3d4e2c44 >> >> >> I'll have to talk to the user to get more details about their code. >> >> >> >> Nick Radcliffe  Software Engineer| Cray Inc. >> >> 2131 Lindau Ln #1000 | Bloomington, MN55425 >> >> +1-651-605-8864  nradclif(a)cray.com <mailto:[email protected]>  www.cray.com >> <http://www.cray.com> >> >> ------------------------------------------------------------------------ >> *From:* Zhou, Hui <zhouh(a)anl.gov> >> *Sent:* Thursday, June 20, 2019 1:13:43 PM >> *To:* discuss(a)mpich.org >> *Cc:* Nick Radcliffe >> *Subject:* Re: [mpich-discuss] Incorrect error checking? >> That’s interesting. It means the `configure` was finding pointers has to >> 8-bytes aligned but the user code is having pointers that are 4-byte >> aligned. I suspect the user did not build the library on the same >> machine it runs? I am also curious that which architecture actually are >> not allowing the 4-byte aligned pointers. Nick, is it possible to trace >> where the questioned mpi library was configured? >> >> — >> Hui Zhou >> T: 630-252-3430 >> >> >> >> >> >> >> >> >>> On Jun 20, 2019, at 1:04 PM, Nick Radcliffe via discuss >>> <discuss(a)mpich.org <mailto:[email protected]>> wrote: >>> >>> Ken, >>> >>> The reason I brought this up is that a user's (valid) code was failing >>> due to this parameter check. It's possible to use an address that's >>> not 8 byte aligned to store a pointer to an int, i.e., >>> >>> int *x; >>> int *y; >>> >>> x = malloc(16); >>> y = &x[1]; >>> >>> I would generally expect y to be 4 byte aligned in the above case. So >>> sometimes this parameter check will cause a correct program to fail, >>> right? >>> >>> >>> Nick Radcliffe  Software Engineer| Cray Inc. >>> 2131 Lindau Ln #1000|Bloomington,MN55425 >>> +1-651-605-8864  nradclif(a)cray.com >>> <mailto:[email protected]>  www.cray.com <http://www.cray.com/> >>> >>> ------------------------------------------------------------------------ >>> *From:*Raffenetti, Kenneth J. via discuss <discuss(a)mpich.org >>> <mailto:[email protected]>> >>> *Sent:*Wednesday, June 19, 2019 2:44:40 PM >>> *To:*[email protected] <mailto:[email protected]> >>> *Cc:*Raffenetti, Kenneth J. >>> *Subject:*Re: [mpich-discuss] Incorrect error checking? >>> Upon further thought, it's just trying to catch a common error, and uses >>> alignment to detect it since the type information is lost thru the >>> interface. In testing on x86_64, it doesn't appear that it will catch >>> the intended error. >>> >>> As Thomas pointed out in another reply, there are also some issues with >>> the implementation, though it is correct that we require intptr_t to >>> build MPICH. At the very least, we could patch to use sizeof(void *) vs. >>> sizeof(intptr_t). Or we can still remove the check since the use-case is >>> so narrow. The preprocessor guard also depends on a AC_TRY_RUN that I'd >>> prefer to delete, to be honest. >>> >>> Ken >>> >>> On 6/19/19 9:27 AM, Raffenetti, Kenneth J. via discuss wrote: >>>> Nick, >>>> >>>> I agree this check looks like nonsense. IMO, we can just delete it and >>>> the others like it. I will create a PR. >>>> >>>> Ken >>>> >>>> On 6/18/19 5:25 PM, Nick Radcliffe via discuss wrote: >>>>> I recently noticed that a parameter check in MPII_Win_get_attr looks a >>>>> bit off: >>>>> >>>>> >>>>> /* A common user error is to pass the address of a 4-byte >>>>> * int when the address of a pointer (or an address-sized int) >>>>> * should have been used. We can test for this specific >>>>> * case. Note that this code assumes sizeof(intptr_t) is >>>>> * a power of 2. */ >>>>> if ((intptr_t) attribute_val & (sizeof(intptr_t) - 1)) { >>>>> MPIR_ERR_SETANDSTMT(mpi_errno, MPI_ERR_ARG, goto >>>>> fn_fail, "**attrnotptr"); >>>>> } >>>>> >>>>> >>>>> The comment indicates that the check is testing "attribute_val" to see >>>>> if a pointer to int was passed in, rather than a double pointer or >>>>> pointer to an integer that can store an address. But the check seems to >>>>> only be testing for 8 byte alignment (and failing if not aligned). Am I >>>>> missing something here? >>>>> >>>>> >>>>> >>>>> Nick Radcliffe  Software Engineer| Cray Inc. >>>>> >>>>> 2131 Lindau Ln #1000 | Bloomington, MN55425 >>>>> >>>>> +1-651-605-8864  nradclif(a)cray.com <http://cray.com> <mailto:[email protected]>  www.cray.com >>>>> <http://www.cray.com <http://www.cray.com/>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> discuss mailing list discuss(a)mpich.org <mailto:[email protected]> >>>>> To manage subscription options or unsubscribe: >>>>> https://lists.mpich.org/mailman/listinfo/discuss >>>>> >>>> _______________________________________________ >>>> discuss mailing list discuss(a)mpich.org <mailto:[email protected]> >>>> To manage subscription options or unsubscribe: >>>> https://lists.mpich.org/mailman/listinfo/discuss >>>> >>> _______________________________________________ >>> discuss mailing list discuss(a)mpich.org <mailto:[email protected]> >>> To manage subscription options or unsubscribe: >>> https://lists.mpich.org/mailman/listinfo/discuss >>> _______________________________________________ >>> discuss mailing list discuss(a)mpich.org <mailto:[email protected]> >>> To manage subscription options or unsubscribe: >>> https://lists.mpich.org/mailman/listinfo/discuss >> >> >> _______________________________________________ >> discuss mailing list discuss(a)mpich.org >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/discuss >> > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss >

1 0

Re: [mpich-discuss] Incorrect error checking?
by Raffenetti, Kenneth J. 20 Jun '19

20 Jun '19

Hmm, interesting. I think this example false-positive is pretty good reason to remove the check from MPICH. Ken On 6/20/19 1:42 PM, Nick Radcliffe via discuss wrote: > Hui, > > > The library was built on one of our internal build servers, and run on a > different machine of course. But I don't think it's a configure issue. I > did a quick test and it's definitely possible for the address of a > pointer to not be 8-byte aligned: > > > [nradclif@heron ~]$ cat test_align.c > #include <stdlib.h> > #include <stdio.h> > > int main() > { > int *c; > > struct > { > int a; > int *b; > } __attribute__((packed)) s; > > c = (int *)&s.b; > > fprintf(stdout, "c = %p\n", c); > > return 0; > } > [nradclif@heron ~]$ ./test_align.x > c = 0x7ffe3d4e2c44 > > > I'll have to talk to the user to get more details about their code. > > > > Nick Radcliffe  Software Engineer| Cray Inc. > > 2131 Lindau Ln #1000 | Bloomington, MN55425 > > +1-651-605-8864  nradclif(a)cray.com <mailto:[email protected]>  www.cray.com > <http://www.cray.com> > > ------------------------------------------------------------------------ > *From:* Zhou, Hui <zhouh(a)anl.gov> > *Sent:* Thursday, June 20, 2019 1:13:43 PM > *To:* discuss(a)mpich.org > *Cc:* Nick Radcliffe > *Subject:* Re: [mpich-discuss] Incorrect error checking? > That’s interesting. It means the `configure` was finding pointers has to > 8-bytes aligned but the user code is having pointers that are 4-byte > aligned. I suspect the user did not build the library on the same > machine it runs? I am also curious that which architecture actually are > not allowing the 4-byte aligned pointers. Nick, is it possible to trace > where the questioned mpi library was configured? > > — > Hui Zhou > T: 630-252-3430 > > > > > > > > >> On Jun 20, 2019, at 1:04 PM, Nick Radcliffe via discuss >> <discuss(a)mpich.org <mailto:[email protected]>> wrote: >> >> Ken, >> >> The reason I brought this up is that a user's (valid) code was failing >> due to this parameter check. It's possible to use an address that's >> not 8 byte aligned to store a pointer to an int, i.e., >> >> int *x; >> int *y; >> >> x = malloc(16); >> y = &x[1]; >> >> I would generally expect y to be 4 byte aligned in the above case. So >> sometimes this parameter check will cause a correct program to fail, >> right? >> >> >> Nick Radcliffe  Software Engineer| Cray Inc. >> 2131 Lindau Ln #1000|Bloomington,MN55425 >> +1-651-605-8864  nradclif(a)cray.com >> <mailto:[email protected]>  www.cray.com <http://www.cray.com/> >> >> ------------------------------------------------------------------------ >> *From:*Raffenetti, Kenneth J. via discuss <discuss(a)mpich.org >> <mailto:[email protected]>> >> *Sent:*Wednesday, June 19, 2019 2:44:40 PM >> *To:*[email protected] <mailto:[email protected]> >> *Cc:*Raffenetti, Kenneth J. >> *Subject:*Re: [mpich-discuss] Incorrect error checking? >> Upon further thought, it's just trying to catch a common error, and uses >> alignment to detect it since the type information is lost thru the >> interface. In testing on x86_64, it doesn't appear that it will catch >> the intended error. >> >> As Thomas pointed out in another reply, there are also some issues with >> the implementation, though it is correct that we require intptr_t to >> build MPICH. At the very least, we could patch to use sizeof(void *) vs. >> sizeof(intptr_t). Or we can still remove the check since the use-case is >> so narrow. The preprocessor guard also depends on a AC_TRY_RUN that I'd >> prefer to delete, to be honest. >> >> Ken >> >> On 6/19/19 9:27 AM, Raffenetti, Kenneth J. via discuss wrote: >> > Nick, >> > >> > I agree this check looks like nonsense. IMO, we can just delete it and >> > the others like it. I will create a PR. >> > >> > Ken >> > >> > On 6/18/19 5:25 PM, Nick Radcliffe via discuss wrote: >> >> I recently noticed that a parameter check in MPII_Win_get_attr looks a >> >> bit off: >> >> >> >> >> >> /* A common user error is to pass the address of a 4-byte >> >> * int when the address of a pointer (or an address-sized int) >> >> * should have been used. We can test for this specific >> >> * case. Note that this code assumes sizeof(intptr_t) is >> >> * a power of 2. */ >> >> if ((intptr_t) attribute_val & (sizeof(intptr_t) - 1)) { >> >> MPIR_ERR_SETANDSTMT(mpi_errno, MPI_ERR_ARG, goto >> >> fn_fail, "**attrnotptr"); >> >> } >> >> >> >> >> >> The comment indicates that the check is testing "attribute_val" to see >> >> if a pointer to int was passed in, rather than a double pointer or >> >> pointer to an integer that can store an address. But the check seems to >> >> only be testing for 8 byte alignment (and failing if not aligned). Am I >> >> missing something here? >> >> >> >> >> >> >> >> Nick Radcliffe  Software Engineer| Cray Inc. >> >> >> >> 2131 Lindau Ln #1000 | Bloomington, MN55425 >> >> >> >> +1-651-605-8864  nradclif(a)cray.com <http://cray.com> <mailto:[email protected]>  www.cray.com >> >> <http://www.cray.com <http://www.cray.com/>> >> >> >> >> >> >> _______________________________________________ >> >> discuss mailing list discuss(a)mpich.org <mailto:[email protected]> >> >> To manage subscription options or unsubscribe: >> >>https://lists.mpich.org/mailman/listinfo/discuss >> >> >> > _______________________________________________ >> > discuss mailing list discuss(a)mpich.org <mailto:[email protected]> >> > To manage subscription options or unsubscribe: >> >https://lists.mpich.org/mailman/listinfo/discuss >> > >> _______________________________________________ >> discuss mailing list discuss(a)mpich.org <mailto:[email protected]> >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/discuss >> _______________________________________________ >> discuss mailing list discuss(a)mpich.org <mailto:[email protected]> >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/discuss > > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss >

1 0

Re: [mpich-discuss] Incorrect error checking?
by Zhou, Hui 20 Jun '19

20 Jun '19

This is the exact code used in configure: struct foo { int a; void *b; }; int main() { int buf[10]; struct foo *p1; p1=(struct foo*)&buf[0]; p1->b = (void *)0; p1=(struct foo*)&buf[1]; p1->b = (void *)0; return 0; } If the macro `NEEDS_POINTER_ALIGNMENT_ADJUST` gets set, the above program is supposed to crash (I believe). Nick, could you confirm that on your build machine? If the test code didn’t crash (and exits 0), then I wonder how the macro gets activated. Anyway, for the potential of user machine differ from build machine, it might be a good idea to remove this check. — Hui Zhou T: 630-252-3430 On Jun 20, 2019, at 1:42 PM, Nick Radcliffe <nradclif(a)cray.com<mailto:[email protected]>> wrote: Hui, The library was built on one of our internal build servers, and run on a different machine of course. But I don't think it's a configure issue. I did a quick test and it's definitely possible for the address of a pointer to not be 8-byte aligned: [nradclif@heron ~]$ cat test_align.c #include <stdlib.h> #include <stdio.h> int main() { int *c; struct { int a; int *b; } __attribute__((packed)) s; c = (int *)&s.b; fprintf(stdout, "c = %p\n", c); return 0; } [nradclif@heron ~]$ ./test_align.x c = 0x7ffe3d4e2c44 I'll have to talk to the user to get more details about their code. Nick Radcliffe  Software Engineer | Cray Inc. 2131 Lindau Ln #1000 | Bloomington, MN 55425 +1-651-605-8864  nradclif(a)cray.com<mailto:[email protected]>  www.cray.com<http://www.cray.com/> ________________________________ From: Zhou, Hui <zhouh(a)anl.gov<mailto:[email protected]>> Sent: Thursday, June 20, 2019 1:13:43 PM To: discuss(a)mpich.org<mailto:[email protected]> Cc: Nick Radcliffe Subject: Re: [mpich-discuss] Incorrect error checking? That’s interesting. It means the `configure` was finding pointers has to 8-bytes aligned but the user code is having pointers that are 4-byte aligned. I suspect the user did not build the library on the same machine it runs? I am also curious that which architecture actually are not allowing the 4-byte aligned pointers. Nick, is it possible to trace where the questioned mpi library was configured? — Hui Zhou T: 630-252-3430 On Jun 20, 2019, at 1:04 PM, Nick Radcliffe via discuss <discuss(a)mpich.org<mailto:[email protected]>> wrote: Ken, The reason I brought this up is that a user's (valid) code was failing due to this parameter check. It's possible to use an address that's not 8 byte aligned to store a pointer to an int, i.e., int *x; int *y; x = malloc(16); y = &x[1]; I would generally expect y to be 4 byte aligned in the above case. So sometimes this parameter check will cause a correct program to fail, right? Nick Radcliffe  Software Engineer | Cray Inc. 2131 Lindau Ln #1000 | Bloomington, MN 55425 +1-651-605-8864  nradclif(a)cray.com<mailto:[email protected]>  www.cray.com<http://www.cray.com/> ________________________________ From: Raffenetti, Kenneth J. via discuss <discuss(a)mpich.org<mailto:[email protected]>> Sent: Wednesday, June 19, 2019 2:44:40 PM To: discuss(a)mpich.org<mailto:[email protected]> Cc: Raffenetti, Kenneth J. Subject: Re: [mpich-discuss] Incorrect error checking? Upon further thought, it's just trying to catch a common error, and uses alignment to detect it since the type information is lost thru the interface. In testing on x86_64, it doesn't appear that it will catch the intended error. As Thomas pointed out in another reply, there are also some issues with the implementation, though it is correct that we require intptr_t to build MPICH. At the very least, we could patch to use sizeof(void *) vs. sizeof(intptr_t). Or we can still remove the check since the use-case is so narrow. The preprocessor guard also depends on a AC_TRY_RUN that I'd prefer to delete, to be honest. Ken On 6/19/19 9:27 AM, Raffenetti, Kenneth J. via discuss wrote: > Nick, > > I agree this check looks like nonsense. IMO, we can just delete it and > the others like it. I will create a PR. > > Ken > > On 6/18/19 5:25 PM, Nick Radcliffe via discuss wrote: >> I recently noticed that a parameter check in MPII_Win_get_attr looks a >> bit off: >> >> >> /* A common user error is to pass the address of a 4-byte >> * int when the address of a pointer (or an address-sized int) >> * should have been used. We can test for this specific >> * case. Note that this code assumes sizeof(intptr_t) is >> * a power of 2. */ >> if ((intptr_t) attribute_val & (sizeof(intptr_t) - 1)) { >> MPIR_ERR_SETANDSTMT(mpi_errno, MPI_ERR_ARG, goto >> fn_fail, "**attrnotptr"); >> } >> >> >> The comment indicates that the check is testing "attribute_val" to see >> if a pointer to int was passed in, rather than a double pointer or >> pointer to an integer that can store an address. But the check seems to >> only be testing for 8 byte alignment (and failing if not aligned). Am I >> missing something here? >> >> >> >> Nick Radcliffe  Software Engineer| Cray Inc. >> >> 2131 Lindau Ln #1000 | Bloomington, MN55425 >> >> +1-651-605-8864  nradclif(a)cray.com<http://cray.com/> <mailto:[email protected]>  www.cray.com >> <http://www.cray.com<http://www.cray.com/>> >> >> >> _______________________________________________ >> discuss mailing list discuss(a)mpich.org<mailto:[email protected]> >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/discuss >> > _______________________________________________ > discuss mailing list discuss(a)mpich.org<mailto:[email protected]> > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss > _______________________________________________ discuss mailing list discuss(a)mpich.org<mailto:[email protected]> To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss _______________________________________________ discuss mailing list discuss(a)mpich.org<mailto:[email protected]> To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0