Nimrod Beginner - Fizzbuzz - Compiling and Running - nim-lang

I tried writing compiling and running my first nimrod program a fizzbuzz.
Nimrod is installed from git and version is.
[sayth nimrod]$ nimrod --version
Nimrod Compiler Version 0.9.4 (2014-04-28) [Linux: amd64]
Copyright (c) 2006-2014 by Andreas Rumpf
So here is a fizzbuzz
proc fizzBuzz(x, y: int) =
for i in x .. y:
if i mod 15 == 0:
echo("FizzBuzz")
elif i mod 3 == 0:
echo("Fizz")
elif i mod 5 == 0:
echo("Buzz")
else:
echo(i)
I compiled to c (is there a better option?) and it appeared ok to me.
[sayth nimrod]$ nimrod c fizzbuzz.nim
config/nimrod.cfg(37, 2) Hint: added path: '/home/sayth/.babel/pkgs/' [Path]
Hint: used config file '/home/sayth/Nimrod/config/nimrod.cfg' [Conf]
Hint: system [Processing]
Hint: fizzbuzz [Processing]
fizzbuzz.nim(1, 5) Hint: 'fizzbuzz.fizzBuzz(x: int, y: int)' is declared but not used [XDeclaredButNotUsed]
gcc -c -w -I/home/sayth/Nimrod/lib -o /home/sayth/Scripts/nimrod/nimcache/fizzbuzz.o /home/sayth/Scripts/nimrod/nimcache/fizzbuzz.c
gcc -c -w -I/home/sayth/Nimrod/lib -o /home/sayth/Scripts/nimrod/nimcache/stdlib_system.o /home/sayth/Scripts/nimrod/nimcache/stdlib_system.c
gcc -o /home/sayth/Scripts/nimrod/fizzbuzz /home/sayth/Scripts/nimrod/nimcache/stdlib_system.o /home/sayth/Scripts/nimrod/nimcache/fizzbuzz.o -ldl
Hint: operation successful (8181 lines compiled; 1.065 sec total; 13.138MB) [SuccessX]
But running it produces no output. Is there something I am doing wrong?
[sayth nimrod]$ ./fizzbuzz
[sayth nimrod]$

You simply forgot to call it. Note the compiler hint:
fizzbuzz.nim(1, 5) Hint: 'fizzbuzz.fizzBuzz(x: int, y: int)' is declared but not used [XDeclaredButNotUsed]
And no, your best option is compiling to C. There may be an LLVM backend in the future, but the general opinion is that it is more trouble than it is worth. Intermediate C output is more portable (gcc runs in many more plataforms than LLVM) and you can chose the compiler that can best optimize your code.

Related

Use tinygo to compile arm binary from x64 Linux : undefined reference problems

I am trying to compile a program with tinygo from Linux, when I enter the following command :
GOARCH=arm tinygo build -o <OutputName> ./main.go
I got :
/usr/lib/gcc-cross/arm-linux-gnueabihf/9/../../../../arm-linux-gnueabihf/bin/ld: /tmp/tinygo859602615/main.o: in function `syscall.Seek':
/usr/local/go/src/syscall/syscall_linux_arm.go:60: undefined reference to `syscall.seek'
The relevant codes indicated here above are :
// Underlying system call writes to newoffset via pointer.
// Implemented in assembly to avoid allocation.
func seek(fd int, offset int64, whence int) (newoffset int64, err Errno)
func Seek(fd int, offset int64, whence int) (newoffset int64, err error) {
newoffset, errno := seek(fd, offset, whence)
if errno != 0 {
return 0, errno
}
return newoffset, nil
}
I have just use sudo apt-get install arm-linux-gnueabihf to install this package.
However, GOARCH=arm go build -o ./main.go works without any problem.
Using CGO_ENABLED="0" flag doesn't change anything.
I have searched on the Internet and found no similar issues. Thank you for any possible information.
Environment :
Linux 5.4.0-73-generic #82-Ubuntu SMP Wed Apr 14 17:39:42 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
go version go1.16.3 linux/amd64
CGO_ENABLED="1"
GOROOT="/usr/local/go"
TINYGOROOT="/usr/local/lib/tinygo"

can't compile OpenFOAM v1912 with intel icc and intelmpi

! UPDATE on 28 Feb, 2020:
The problem is solved. please refer to :https://develop.openfoam.com/Development/openfoam/issues/1608
Summary
I'm new to OpenFOAM and I'm trying to compile OpenFOAM-v1912 using Icc and IntelMPI, only to find the following confusing error. It seems like an error in codes. But it just makes no sense, because I have successfully compiled it with gcc(v4.8.5) and openmpi(1.10.7), and it worked just fine. I'd be more than delighted to hear any suggestions. Ideas about what the problem might be will also be of great help. THANKS A LOT!
wallBoundedStreamLine/wallBoundedParticleTemplates.C(121): error: no operator "==" matches these operands
Steps to reproduce
I edited OpenFOAM-v1912/etc/bashrc from
...
export WM_COMPILER=Gcc
...
export WM_MPLIB=OPENMPI
...
to
...
export WM_COMPILER=Icc
...
export WM_MPLIB=INTELMPI
...
and I got "ld: cannot find -lmpi" error so I edit OpenFOAM-v1912/wmake/rules/General/Icc/c++
CC = icpc -std=c++11
to
CC = mpiicc -std=c++11
then under directory OpenFOAM-v1912/ , I ran
./Allwmake
What I've tried
Compiling with $WM_LABEL_SIZE=64
But it just seemed irrelevant and it got stuck on building libscotch. Doesn't seem to help at all.
Details of the error from the promts:
wmake reactingEulerFoam/phaseSystems
wmake reactingEulerFoam/interfacialModels
wmake reactingEulerFoam/interfacialCompositionModels
wmake reactingEulerFoam/derivedFvPatchFields
wmake reactingEulerFoam/reactingMultiphaseEulerFoam/multiphaseSystem
wmake reactingEulerFoam/reactingMultiphaseEulerFoam/multiphaseCompressibleTurbulenceModels
wmake reactingEulerFoam/reactingTwoPhaseEulerFoam/twoPhaseSystem
wmake reactingEulerFoam/reactingTwoPhaseEulerFoam/twoPhaseCompressibleTurbulenceModels
wmake field
mpiicc -std=c++11 -fp-trap=common -fp-model precise -DOPENFOAM=1912 -DWM_DP -DWM_LABEL_SIZE=32 -Wall -Wextra -Wnon-virtual-dtor -Wno-unused-parameter -Wno-invalid-offsetof -Wno-unknown-pragmas -diag-disable 327,654,1125,1292,2289,2304,11062,11074,11076 -O3 -DNoRepository -ftemplate-depth-100 -I/share/software/OpenFOAM/OpenFOAM-v1912-ICC/src/finiteVolume/lnInclude -I/share/software/OpenFOAM/OpenFOAM-v1912-ICC/src/fileFormats/lnInclude -I/share/software/OpenFOAM/OpenFOAM-v1912-ICC/src/surfMesh/lnInclude -I/share/software/OpenFOAM/OpenFOAM-v1912-ICC/src/meshTools/lnInclude -I/share/software/OpenFOAM/OpenFOAM-v1912-ICC/src/sampling/lnInclude -I/share/software/OpenFOAM/OpenFOAM-v1912-ICC/src/lagrangian/basic/lnInclude -I/share/software/OpenFOAM/OpenFOAM-v1912-ICC/src/lagrangian/distributionModels/lnInclude -I/share/software/OpenFOAM/OpenFOAM-v1912-ICC/src/thermophysicalModels/basic/lnInclude -I/share/software/OpenFOAM/OpenFOAM-v1912-ICC/src/transportModels -I/share/software/OpenFOAM/OpenFOAM-v1912-ICC/src/transportModels/compressible/lnInclude -I/share/software/OpenFOAM/OpenFOAM-v1912-ICC/src/TurbulenceModels/turbulenceModels/lnInclude -I/share/software/OpenFOAM/OpenFOAM-v1912-ICC/src/TurbulenceModels/incompressible/lnInclude -I/share/software/OpenFOAM/OpenFOAM-v1912-ICC/src/TurbulenceModels/compressible/lnInclude -I/share/software/OpenFOAM/OpenFOAM-v1912-ICC/src/transportModels/compressible/lnInclude -I/share/software/OpenFOAM/OpenFOAM-v1912-ICC/src/thermophysicalModels/basic/lnInclude -I/share/software/OpenFOAM/OpenFOAM-v1912-ICC/src/thermophysicalModels/solidThermo/lnInclude -I/share/software/OpenFOAM/OpenFOAM-v1912-ICC/src/thermophysicalModels/chemistryModel/lnInclude -I/share/software/OpenFOAM/OpenFOAM-v1912-ICC/src/thermophysicalModels/reactionThermo/lnInclude -I/share/software/OpenFOAM/OpenFOAM-v1912-ICC/src/thermophysicalModels/specie/lnInclude -I/share/software/OpenFOAM/OpenFOAM-v1912-ICC/src/fvAgglomerationMethods/pairPatchAgglomeration/lnInclude -IlnInclude -I. -I/share/software/OpenFOAM/OpenFOAM-v1912-ICC/src/OpenFOAM/lnInclude -I/share/software/OpenFOAM/OpenFOAM-v1912-ICC/src/OSspecific/POSIX/lnInclude -fPIC -c wallBoundedStreamLine/wallBoundedStreamLine.C -o /share/software/OpenFOAM/OpenFOAM-v1912-ICC/build/linux64IccDPInt32Opt/src/functionObjects/field/wallBoundedStreamLine/wallBoundedStreamLine.o
wallBoundedStreamLine/wallBoundedParticleTemplates.C(121): error: no operator "==" matches these operands
operand types are: Foam::cell == const Foam::label
cell() == mesh().faceOwner()[face()]
^
/share/software/OpenFOAM/OpenFOAM-v1912-ICC/src/lagrangian/basic/lnInclude/particle.H(70): note: this candidate was rejected because arguments do not match
bool operator==(const particle&, const particle&);
^
/share/software/OpenFOAM/OpenFOAM-v1912-ICC/src/OpenFOAM/lnInclude/labelBits.H(123): note: this candidate was rejected because function is not visible
inline friend bool operator==(const labelBits& a, const labelBits& b)
^
/share/software/OpenFOAM/OpenFOAM-v1912-ICC/src/OpenFOAM/lnInclude/objectMapI.H(85): note: this candidate was rejected because arguments do not match
inline bool Foam::operator==(const objectMap& a, const objectMap& b)
^
/share/software/OpenFOAM/OpenFOAM-v1912-ICC/src/OpenFOAM/lnInclude/triFaceI.H(406): note: this candidate was rejected because arguments do not match
inline bool Foam::operator==(const triFace& a, const triFace& b)
^
(followed by lots of rejected candidates)
instantiation of "bool Foam::wallBoundedStreamLineParticle::move(TrackCloudType &, Foam::wallBoundedStreamLineParticle::trackingData &, Foam::scalar={Foam::doubleScalar={double}}) [with TrackCloudType=Foam::wallBoundedStreamLineParticleCloud]" at line 212 of "/share/software/OpenFOAM/OpenFOAM-v1912-ICC/src/lagrangian/basic/lnInclude/Cloud.C"
instantiation of "void Foam::Cloud<ParticleType>::move(TrackCloudType &, ParticleType::trackingData &, Foam::scalar={Foam::doubleScalar={double}}) [with ParticleType=Foam::wallBoundedStreamLineParticle, TrackCloudType=Foam::wallBoundedStreamLineParticleCloud]" at line 275 of "wallBoundedStreamLine/wallBoundedStreamLine.C"
wallBoundedStreamLine/wallBoundedParticleTemplates.C(138): error: no operator "=" matches these operands
operand types are: Foam::cell = Foam::label
cell() = nbrCelli;
^
detected during:
instantiation of "bool Foam::wallBoundedStreamLineParticle::move(TrackCloudType &, Foam::wallBoundedStreamLineParticle::trackingData &, Foam::scalar={Foam::doubleScalar={double}}) [with TrackCloudType=Foam::wallBoundedStreamLineParticleCloud]" at line 212 of "/share/software/OpenFOAM/OpenFOAM-v1912-ICC/src/lagrangian/basic/lnInclude/Cloud.C"
instantiation of "void Foam::Cloud<ParticleType>::move(TrackCloudType &, ParticleType::trackingData &, Foam::scalar={Foam::doubleScalar={double}}) [with ParticleType=Foam::wallBoundedStreamLineParticle, TrackCloudType=Foam::wallBoundedStreamLineParticleCloud]" at line 275 of "wallBoundedStreamLine/wallBoundedStreamLine.C"
compilation aborted for wallBoundedStreamLine/wallBoundedStreamLine.C (code 2)
make: *** [/share/software/OpenFOAM/OpenFOAM-v1912-ICC/build/linux64IccDPInt32Opt/src/functionObjects/field/wallBoundedStreamLine/wallBoundedStreamLine.o] Error 2
Environment information
OpenFOAM: v1912 (codes from https://sourceforge.net/projects/openfoam/files/v1912/OpenFOAM-v1912.tgz)
ThirdParty from https://sourceforge.net/projects/openfoam/files/v1912/ThirdParty-v1912.tgz
Intel suite: parallel_studio_xe_2020_cluster_edition
Intel icc: icc (ICC) 19.1.0.166 20191121
Intel MPI lib: for Linux* OS, Version 2019 Update 6 Build 20191024
OS Kernel: Linux version 3.10.0-1062.el7.x86_64 (gcc version 4.8.5 20150623 (Red Hat 4.8.5-36) (GCC) )
OS: CentOS 7.7.1908
CPU: 72 * Intel(R) Xeon(R) Gold 6240 CPU # 2.60GHz
Solution
The problem is solved! Please refer to https://develop.openfoam.com/Development/openfoam/issues/1608.

Fortran/OpenMP comparison on 2 platforms (GCC and PGI compilers). Unexpected execution times

I compiled (with GCC and PGI compilers) and run a small Fortran/OpenMP program on two different platforms (Haswell- and Skylake-based), just to get a feeling of the difference of the performance. I do not know how to interpret the results - they are a mistery to me.
Here is the small program (taken from Nvidia Developer website and slightly adapted).
PROGRAM main
use, intrinsic :: iso_fortran_env, only: sp=>real32, dp=>real64
use, intrinsic :: omp_lib
implicit none
real(dp), parameter :: tol = 1.0d-6
integer, parameter :: iter_max = 1000
real(dp), allocatable :: A(:,:), Anew(:,:)
real(dp) :: error
real(sp) :: cpu_t0, cpu_t1
integer :: it0, it1, sys_clock_rate, iter, i, j
integer :: N, M
character(len=8) :: arg
call get_command_argument(1, arg)
read(arg, *) N !!! N = 8192 provided from command line
call get_command_argument(2, arg)
read(arg, *) M !!! M = 8192 provided from command line
allocate( A(N,M), Anew(N,M) )
A(1,:) = 1
A(2:N,:) = 0
Anew(1,:) = 1
Anew(2:N,:) = 0
iter = 0
error = 1
call cpu_time(cpu_t0)
call system_clock(it0)
do while ( (error > tol) .and. (iter < iter_max) )
error = 0
!$omp parallel do reduction(max: error) private(i)
do j = 2, M-1
do i = 2, N-1
Anew(i,j) = (A(i+1,j)+A(i-1,j)+A(i,j-1)+A(i,j+1)) / 4
error = max(error, abs(Anew(i,j)-A(i,j)))
end do
end do
!$omp end parallel do
!$omp parallel do private(i)
do j = 2, M-1
do i = 2, N-1
A(i,j) = Anew(i,j)
end do
end do
!$omp end parallel do
iter = iter + 1
end do
call cpu_time(cpu_t1)
call system_clock(it1, sys_clock_rate)
write(*,'(a,f8.3,a)') "...cpu time :", cpu_t1-cpu_t0, " s"
write(*,'(a,f8.3,a)') "...wall time:", real(it1 it0)/real(sys_clock_rate), " s"
END PROGRAM
The two platforms I used are:
Intel i7-4770 # 3.40GHz (Haswell), 32 GB RAM / Ubuntu 16.04.2 LTS
Intel i7-6700 # 3.40GHz (Skylake), 32 GB RAM / Linux Mint 18.1 (~ Ubuntu 16.04)
On each platform I compiled the Fortran program with
GCC gfortran 6.2.0
PGI pgfortran 16.10 community edition
I obviously compiled the program independently on each platform (I only moved the .f90 file; I did not move any binary file)
I ran 5 times each of the 4 executables (2 for each platform), collecting the wall times measured in seconds (as printed out by the program). (Well, I ran the whole test several times, and the timings below are definitely representative)
Sequential execution. Program compiled with:
gfortran -Ofast main.f90 -o gcc-seq
pgfortran -fast main.f90 -o pgi-seq
Timings (best of 5):
Haswell > gcc-seq: 150.955, pgi-seq: 165.973
Skylake > gcc-seq: 277.400, pgi-seq: 121.794
Multithread execution (8 threads). Program compiled with:
gfortran -Ofast -fopenmp main.f90 -o gcc-omp
pgfortran -fast -mp=allcores main.f90 -o pgi-omp
Timings (best of 5):
Haswell > gcc-omp: 153.819, pgi-omp: 151.459
Skylake > gcc-omp: 113.497, pgi-omp: 107.863
When compiling with OpenMP, I checked the number of threads in the parallel regions with omp_get_num_threads(), and there are actually always 8 threads, as expected.
There are several things I don't get:
Using the GCC compiler: why on Skylake OpenMP has a substantial benefit (277 vs 113 s), while on Haswell it has no benefit at all? (150 vs 153 s) What's happening on Haswell?
Using the PGI compiler: Why OpenMP has such a small benefit (if any) on both platforms?
Focusing on the sequential runs, why are there such huge differences in execution times between Haswell and Skylake (especially when the program is compiled with GCC)? Why this difference is still so relevant - but with the role of Haswell and Skylake reversed! - when OpenMP is enabled?
Also, when OpenMP is enabled and GCC is used, the cpu time is always much larger than the wall time (as I expect), but when PGI is used, the cpu and wall times are always the same, also then the program used multiple threads.
How can I make some sense out of these results?

Compile error: ` fatal error: gfc_todo: `

When I compile my code with
gfortran -O2 calpuff.for -o calpuff.exe
The following code:
REAL FUNCTION R1MACH (I)
C***BEGIN PROLOGUE R1MACH
C ...
real SMALL(2)
real LARGE(2)
real RIGHT(2)
real DIVER(2)
real LOG10(2)
c --- Set up for IBM PC: declare as reals ..........(DGS)
C
REAL RMACH(5)
SAVE RMACH
C
EQUIVALENCE (RMACH(1),SMALL(1))
EQUIVALENCE (RMACH(2),LARGE(1))
EQUIVALENCE (RMACH(3),RIGHT(1))
EQUIVALENCE (RMACH(4),DIVER(1))
EQUIVALENCE (RMACH(5),LOG10(1))
C ...
DATA SMALL(1) / 1.18E-38 /
DATA LARGE(1) / 3.40E+38 /
DATA RIGHT(1) / 0.595E-07 /
DATA DIVER(1) / 1.19E-07 /
DATA LOG10(1) / 0.30102999566 /
C ...
C***FIRST EXECUTABLE STATEMENT R1MACH
IF (I .LT. 1 .OR. I .GT. 5) CALL XERMSG ('SLATEC', 'R1MACH',
+ 'I OUT OF BOUNDS', 1, 2)
C
R1MACH = RMACH(I)
RETURN
C
END
Result shows in the following error:
calpuff.for: In function ‘r1mach’:
calpuff.for:58522: fatal error: gfc_todo: Not Implemented: Initialization of overlapping variables
compilation terminated.
Line 58522 corresponds to the first line of the code shown.
Why does this error occur?
Some information about my compiler: gcc version 4.1.2 20080704 (Red Hat 4.1.2-54)
This is a known compiler bug in gfortran, see here and here. This bug has been fixed in 2007.
Please update to a more recent version of gfortran.

Linux kernel compilation error: undefined reference to `__udivdi3' & `__umoddi3'

Here is the error I've got:
http://pastebin.com/VadUW6fy
drivers/built-in.o: In function `gem_rxmac_reset':
clkdev.c:(.text+0x212238): undefined reference to `__bad_udelay'
drivers/built-in.o: In function `divide.part.4':
clkdev.c:(.text.unlikely+0x7214): undefined reference to `__udivdi3'
clkdev.c:(.text.unlikely+0x7244): undefined reference to `__umoddi3'
I googled and found this patch: https://lkml.org/lkml/2008/4/7/82
--- a/include/linux/time.h
+++ b/include/linux/time.h
## -174,6 +174,10 ## static inline void timespec_add_ns(struct timespec *a, u64 ns)
{
ns += a->tv_nsec;
while(unlikely(ns >= NSEC_PER_SEC)) {
+ /* The following asm() prevents the compiler from
+ * optimising this loop into a modulo operation. */
+ asm("" : "+r"(ns));
+
ns -= NSEC_PER_SEC;
a->tv_sec++;
}
but failed to apply (may be due to new version of the file).
patching file linux/time.h
Hunk #1 FAILED at 174.
1 out of 1 hunk FAILED -- saving rejects to file linux/time.h.rej
surprisingly, the file time.h.rej is not present!
I should have read more closely. The patch is for timespec_add_ns(), and you have gem_rxmac_reset() and divide.part.4 functions failing. Probably unrelated to the patch you found -- instead, probably standard 64-bit div / mod functions don't have an implementation on your target platform.
Do you have a Sun GEM or Apple GMAC NIC? If not, you can probably just disable that driver and get rid of the first error message.
For the second, you might need to implement a similar asm trick in the clkdev.c file -- when I skimmed my copy for a repeated subtraction operation I didn't spot one -- but maybe you can simply steal a newer clkdev.c or clkdev.h to fix this problem? (It's a long shot, there's only one entry in git log drivers/clk/clkdev.c.)

Resources