How to disable inf in gfortran? - gfortran

Using gfortran, is there a compiler option to not use inf? Currently, a divide by zero returns an inf result. I would prefer a run-time error, as was typical with legacy compilers.
My default compiler command is:
gfortran -fno-automatic -std=legacy -g -O0 -c

Related

The clang compiler does not support a feature it reportedly supports

I'm trying to tailor compiler flags of clang-11 to the apple-m1 CPU, which clang-11 doesn't know about yet.
The output of /usr/bin/clang -E - -mcpu=apple-m1 -### on macOS outputs a command with flags like these in it: "-target-feature" "+zcz"
From that you can infer the following features of the CPU:
armv8.5a+fp-armv8+neon+crc+crypto+dotprod+fp16fml+ras+lse+rdm+rcpc+zcm+zcz+fullfp16+sm4+sha3+sha2+aes
However, out of these, +fp-armv8+neon+zcm+zcz+fullfp16 are not recognised to be valid by any clang compiler:
$ cc -march=armv8.5a+zcz test.c
clang-11: error: the clang compiler does not support '-march=armv8.5a+zcz'
How can I tell clang to optimise for those target flags?

How to exclude old version library in /usr/local?

Disclamer: using -nostdcincl isn't possible because it excludes needed system libraries. Here instead the problem seems to be that tthe compiler ignores my -I directives
I have installed a library (OpenCV) in ~/local on a remote machine, since I don't have sudo access there. Notice that an older version of the same library is installed in /usr/local.
I'm trying to compile this code:
g++ -DCC_DISABLE_CUDA -I/home/spm1428/CloudCache -I/home/spm1428/local/include/opencv -I/home/spm1428/local/include/opencv2 -I/usr/include/boost -I/home/spm1428/vlfeat -O3 -g -Wall -c -fopenmp -std=c++11 -c -o Descriptor.o ../Descriptors/Descriptor.cpp
However, the returned error is:
In file included from /usr/local/include/opencv2/opencv.hpp:77:0,
from /home/spm1428/CloudCache/Utilities/Utility.hpp:11,
from ../Descriptors/Descriptor.cpp:17:
/usr/local/include/opencv2/highgui/highgui.hpp:165:25: error: redeclaration of ‘IMREAD_UNCHANGED’
IMREAD_UNCHANGED =-1,
^
In file included from ../Descriptors/Descriptor.cpp:13:0:
/home/spm1428/local/include/opencv2/imgcodecs.hpp:65:8: note: previous declaration ‘cv::ImreadModes IMREAD_UNCHANGED’
IMREAD_UNCHANGED = -1, //!< If set, return the loaded image as is (with alpha channel,
^
In file included from /usr/local/include/opencv2/opencv.hpp:77:0,
from /home/spm1428/CloudCache/Utilities/Utility.hpp:11,
from ../Descriptors/Descriptor.cpp:17:
/usr/local/include/opencv2/highgui/highgui.hpp:167:24: error: redeclaration of ‘IMREAD_GRAYSCALE’
IMREAD_GRAYSCALE =0,
I think that this happens because there is another version installed. How can I solve this?
I think this error happens for the same reason (the old version doesn't have cv::xfeatures2d::SURF).

AM_PROG_LEX and undefined yywrap

My program uses the documented autoconf macro AM_PROG_LEX. It builds fine on RHEL 6.5 and other distros, but fails on RHEL 6.6 and later.
The configure script cannot compile its tests. When it tries gcc with -ll, -lfl, linking fails with:
/usr/bin/ld: cannot find -lfl
When it tries gcc without extra libraries, linking fails with:
undefined reference to `yywrap'
libfl.a or libfl.so is missing from official repos of those systems. On RHEL 6.5 it's part of flex package.
RHEL 6.5
configure:5334: checking whether yytext is a pointer
configure:5351: gcc -o conftest -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -O0 conftest.c -lfl >&5
configure:5351: $? = 0
configure:5359: result: yes
RHEL 6.8
configure:5196: checking whether yytext is a pointer
configure:5217: gcc -o conftest -g -O2 conftest.c >&5
/tmp/ccNJtVgv.o: In function `input':
/home/git/rpmbuild/BUILD/snacc-1.3.1_16_g23ba7a6/lex.yy.c:1168: undefined reference to `yywrap'
/tmp/ccNJtVgv.o: In function `yylex':
/home/git/rpmbuild/BUILD/snacc-1.3.1_16_g23ba7a6/lex.yy.c:867: undefined reference to `yywrap'
/tmp/ccNJtVgv.o: In function `main':
/home/git/rpmbuild/BUILD/snacc-1.3.1_16_g23ba7a6/conftest.l:17: undefined reference to `yywrap'
collect2: ld returned 1 exit status
configure:5224: $? = 1
configure: failed program was:
...
configure:5246: result: no
libfl contains two and only two functions, both of which are normally unnecessary in production use of flex:
int main() { extern int yylex(void); while (yylex()) ; return 0; }
int yywrap(void) { return 1; }
The yywrap implementation (which essentially disables the yywrap functionality) is not necessary if you use the option
%option noyywrap
in your flex definition, or if you pass the command-line option --noyywrap to flex.
For quick-and-dirty flex scanners, or for debugging, it is sometimes handy to be able to use libfl to fill in the above functions. But it also can create problems on systems which provide both 32- and 64-bit environments. For this reason, libfl was removed from the RHEL flex rpm in 2014. See this RedHat bug fix advisory for details.
So you could install the appropriate flex-devel rpm in order to have libfl available. Or you could compile it yourself using the above code (which is not precisely the source code you'll find in the flex source bundle, but should produce precisely the same library).
Or you could try to fix autoconf so that it doesn't depend on libfl. It didn't used to have any such dependency; if it couldn't find libfl, it would just assume that it wasn't required for the program being compiled.
Workaround is to install flex-devel package containing libfl.a. RHEL version available to subscribers ony. Alternative is CentOS package or recompiling from source.

what are the args that are being passed from clang to llc?

I am working on the llvm project. Recently I tryed to compiler one of my .c files using clang command line into an .s file by using the next command:
clang --target=arch -S -O0 select.c -o select.s
and it crashed in the backend in the function ARCHInstrInfo::storeRegToStackSlot with the backtrace of the stack.
However when I tryed to do it in steps:
clang -O0 -emit-llvm select.c -c -o select.bc
llc -filetype=asm -march=arch ./select.bc -o ./select.s -print-after-all -debug-only isel
it succeeded !! (?)
How can I see how the clang is calling to the backend (llc) ?
I tryed to run the clang with -v flag but it didn't printed how it is calling to the backend...
So the first one that sticks out is that llc defaults to O2 rather than O0 so you might want to look there first.

getMetadata("dbg") returns NULL despite producing IR with "clang -g -S -emit-llvm"

I'm trying to get line information for an instruction.
I have
const CallInst* callInst = dyn_cast<const CallInst>(&*I);
MDNode *N = callInst->getMetadata("dbg");
N is evidently NULL, but I have compiled the input IR with "clang -g -S -emit-llvm"
Does anyone know why this might be the case?
Probably your instruction doesn't correspond to any statement of the source program and thus has no debug metadata.
For example it was generated by one or another optimization as passing -emit-llvm not only emits llvm, but applies bundle of optimizations to your program first.
To exclude optimizations influence and to see the pure code just after the front-end do clang -g -S -emit-llvm -mllvm -disable-llvm-optzns and ensure your instruction has the metadata required.

Resources