How to add -Wuninitialized in a gnatcheck report? - coding-style

I want to have the uninitialized variables in my gnatcheck report but the format of this warning is incompatible with the format:
+RWarnings:xxxx (with xxxx the differents warnings switches)
I have try to write this programming rules like the others: +RWuninitialized but it don't work.
And the switch -Wuninitialized doesn't exist for gnatcheck.

The documentation for adding the results of compiler checks to Gnatcheck’s output says about Warnings (with some editing)
To record compiler warnings (see Warning Message Control section in GNAT User’s Guide), use the Warnings rule with a parameter that is a valid static_string_expression argument of the GNAT pragma Warnings (see “Pragma Warnings” in the GNAT Reference Manual). Note that [the]in case of gnatcheck s parameter, that corresponds to the GNAT -gnatws option, disables all the specific warnings, but [does] not suppresses the warning mode, and [the] e parameter, corresponding to -gnatwe that means "treat warnings as errors", does not have any effect.
If you go to look up "pragma Warnings” in the GNAT Reference Manual, you’ll find it sends you off to the compiler:
The string is a list of letters specifying which warnings are to be activated and which deactivated. The code for these letters is the same as the string used in the command line switch controlling warnings [-gnatw]. For a brief summary, use the gnatmake command with no arguments, which will generate usage information containing the list of warnings switches supported.
Following this advice, there seems to be no -gnatwx to give you the effect of -Wuninitialized. However, if you turn on all warnings
project Checks is
for Source_Files use ("checks.adb");
package Check is
for Default_Switches ("ada") use
(
"-rules",
"+RWarnings:.e"
);
end Check;
end Checks;
and run it on
procedure Checks (Input : Integer; Result : out Integer) is
X : Integer;
Y : Integer;
Z : Integer;
begin
if (Y > 0) = True then
Result := X;
end if;
end Checks;
you get
checks.adb:1:19: warning: formal parameter "Input" is not referenced
checks.adb:2:04: warning: variable "X" is read but never assigned
checks.adb:3:04: warning: variable "Y" is read but never assigned
checks.adb:4:04: warning: variable "Z" is never read and never assigned
checks.adb:6:15: warning: comparison with True is redundant
where the warnings on lines 2, 3 (and 4) mean the same as “uninitialized”, I think.
You can then turn off the warnings you don’t want; for example, "+RWarnings:.eF” will "turn off warnings for unreferenced formal”, and suppresses the warning on line 1.

Related

Override GCC linker symbols in c code using weak declaration

I am building an elf target. I have a linker script where I input some of the symbol locations like(these symbols are defined in a different locations like ROM whose address is provided below),
A = 0x12345678;
B = 0x1234567c;
D = 0x1234568c;
In the C code I can use these variables A and B without declaring them which is expected.
I want to know if I can override the symbol D i.e., My current executable can have its own declaration of D. In that case the linker should ignore D. Is there a way to declare the symbols in linker script as 'weak'? so that the linker can use 'input symbols' only if it is not declared in any of the linked objects.
Use PROVIDE directive
PROVIDE(D = 0x1234568c);
From ld documentation
In some cases, it is desirable for a linker script to define a symbol only if it is referenced and is not defined by any object included in the link.
…
If, on the other hand, the program defines … the linker will silently use the definition in the program.

is there a way to have the compiler warn/err if an attribute section is not defined in the linker script?

Using arm-none-eabi-gcc compiler toolchain for arm microcontrollers, and am defining a specific section in FLASH where this foo variable should live.
Let's say I have the example definition:
int foo __attribute__((section(".bar"))) = 5;
What I have observed is that if .bar is not assigned in the linker script, than the build will successfully succeed and foo will live in RAM instead as initialized data (the constant initial value will of course add to the FLASH size as well). The annoying part is, the linker does not complain when the section does not exist and so if expecting data to reside in FLASH it may silently live in a non-fixed location in RAM. Is there a compile/linker option to force a failure if this occurs?
According to GNU ld documentation, ld can be told to handle orphan linker sections as errors using the --orphan-handling=error command-line option.
Assuming orphan.c does contain the following code:
int foo __attribute__((section(".bar"))) = 5;
int main(void)
{
return 0;
}
The following command does succeed:
aarch64-elf-gcc --specs=rdimon.specs -o orphan orphan.c
But that one does fail:
aarch64-elf-gcc --specs=rdimon.specs -Wl,--orphan-handling=error -o orphan orphan.c
c:/git/cortex-baremetal/opt/gcc-linaro-7.3.1-2018.05-i686-mingw32_aarch64-elf/bin/../lib/gcc/aarch64-elf/7.3.1/../../../../aarch64-elf/bin/ld.exe: error: unplaced orphan section `.tm_clone_table' from `c:/git/cortex-baremetal/opt/gcc-linaro-7.3.1-2018.05-i686-mingw32_aarch64-elf/bin/../lib/gcc/aarch64-elf/7.3.1/crtbegin.o'.
c:/git/cortex-baremetal/opt/gcc-linaro-7.3.1-2018.05-i686-mingw32_aarch64-elf/bin/../lib/gcc/aarch64-elf/7.3.1/../../../../aarch64-elf/bin/ld.exe: error: unplaced orphan section `.bar' from `C:\Users\user\AppData\Local\Temp\cc6aRct8.o'.
c:/git/cortex-baremetal/opt/gcc-linaro-7.3.1-2018.05-i686-mingw32_aarch64-elf/bin/../lib/gcc/aarch64-elf/7.3.1/../../../../aarch64-elf/bin/ld.exe: error: unplaced orphan section `.tm_clone_table' from `c:/git/cortex-baremetal/opt/gcc-linaro-7.3.1-2018.05-i686-mingw32_aarch64-elf/bin/../lib/gcc/aarch64-elf/7.3.1/crtend.o'.
It seems the default linker script I used for the purpose of this example is missing another section, '.tm_clone_table'. It would have to be fixed in order not to trigger an error when '.bar' section is properly defined.

Compiling using gfortran on older code

I need to run an old program found here: http://netlib.sandia.gov/conformal/ under the title "kirch1" in the list. I have absolutely no experience running fortran code, but I would like to do so from my Mac OS X 10.10 command line.
I know I have the 'gfortan' compiler installed on my system, but I'm not sure if this doesn't like this older code. When I run gfortran KIRCH1.f (this file is the one above) I get the following error:
KIRCH1.f:266.8:
x(2) = -1. + dx
1
Warning: Array reference at (1) is out of bounds (2 > 1) in dimension 1
KIRCH1.f:200.21:
common /param1/ nq2,c2,x2(20),z2(20),qwork2(460),betam2(20)
1
Warning: Padding of 4 bytes required before 'c2' in COMMON 'param1' at (1); reorder elements or use -fno-align-commons
KIRCH1.f:285.21:
common /param1/ nq,c,x(20),z(20),qwork(460),betam(20)
1
Warning: Padding of 4 bytes required before 'c' in COMMON 'param1' at (1); reorder elements or use -fno-align-commons
Undefined symbols for architecture x86_64:
"_gaussj_", referenced from:
_qinitx_ in ccoKtvwZ.o
"_ns01a_", referenced from:
_ksolv_ in ccoKtvwZ.o
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status
This error seems to be do to the syntax in the code? I doubt there is anything wrong with the code itself, so I'm thinking its something to do with my systems interpretation of the code (for lack of a better way of phrasing this)
I have no fortran programming experience, I should mention. What am I doing wrong?
EDIT
As suggested by Ed Smith
I run gfortran sclibdbl.f KIRCH1.f but I still get the following warnings:
KIRCH1.f:266.8:
x(2) = -1. + dx
1
Warning: Array reference at (1) is out of bounds (2 > 1) in dimension 1
KIRCH1.f:200.21:
common /param1/ nq2,c2,x2(20),z2(20),qwork2(460),betam2(20)
1
Warning: Padding of 4 bytes required before 'c2' in COMMON 'param1' at (1); reorder elements or use -fno-align-commons
KIRCH1.f:285.21:
common /param1/ nq,c,x(20),z(20),qwork(460),betam(20)
1
Warning: Padding of 4 bytes required before 'c' in COMMON 'param1' at (1); reorder elements or use -fno-align-commons
The following compiled for me:
gfortran sclibdbl.f KIRCH1.f
where KIRCH1.f is the code from http://netlib.sandia.gov/conformal/kirch1 and sclibdb1.f is the code from http://netlib.org/conformal/sclibdbl.
You were just missing the required subroutines gaussj and ns01a which are referenced in the KIRCH1 source code but included in sclibdbl. The code from netlib.org/conformal/sclibdbl includes both the gaussj and ns01a subroutine (note the underscore is added to routine names by default in gfortran).
As #francescalus noted, it's modern fortran compiler and old school FORTRAN code. The warning is because modern fortran is far more explicit about array extents. In this code, x is passed with size 1 to yxtran() which is okay as passing is a reference to the start of array. When element 2 is accessed the modern fortran compiler gets worried. You can remove the two common block errors by adding the -fno-align-commons flag to the compiler. The x(1) error could be removed by replacing x(1) on line 258 with x(n-1). Personally, I wouldn't worry unless you notice problems/unexpected behavior when you run the code (especially as it's from netlib).

warning switch for condition function as a variable

I have errornously forgotten to put the parameter List after the call to a function, and the gcc did not intercept (because he believes it is a TRUTH-value). Is there a gcc warning/error switch, which helps me to locate those places? example:
short function(short arg);
main() {
if (function) { // I wanted to write function(arg)
//do something
}
}
The Version of the gcc I am using is 3.2.1.
Looking at the GCC man page, it seems that what you need is -Waddress.
-Waddress
Warn about suspicious uses of memory addresses. These include using the address of a function in a conditional
expression, such as "void func(void); if (func)", and comparisons against the memory address of a string literal, such as
"if (x == "abc")". Such uses typically indicate a programmer error: the address of a function always evaluates to true,
so their use in a conditional usually indicate that the programmer forgot the parentheses in a function call; and
comparisons against string literals result in unspecified behavior and are not portable in C, so they usually indicate
that the programmer intended to use "strcmp". This warning is enabled by -Wall.
As stated there, you can enable this flag with -Wall too.
Use "-Wall" option with gcc. This option force gcc to show all kinds of warnings at compilation.
You may get following warning when you compile your code by 'gcc -Wall' command.
`function' undeclared (first use in this function)

Debugging Makefile

Some Makefile contains this -
ifneq ($(call try-cc,$(SOURCE_LIBUNWIND),$(FLAGS_UNWIND),libunwind),y)
msg := $(warning No libunwind found, disabling post unwind support. Please install libunwind-dev[el] >= 0.99);
NO_LIBUNWIND := 1
and
whenever I run this make , I get the error message as
warning No libunwind found, disabling post unwind support. Please install libunwind-dev[el] >= 0.99
I want to debug this problem - I want to know the values of SOURCE_LIBUNWIND, FLAGS_UNWIND
which are causing this problem - how do I get these values printed on the stdout for debugging purpose ?
GNU make provides several functions that you can use to print the value of a variable: $(error ...), $(warning ...) and $(info ...). The manual mentions them in section 8.12 Functions That Control Make.
Additionally, you can use the command-line parameter -p or --print-data-base to have make print the values of all rules and variables. Redirecting the output to a file and analyzing that might give you a better understanding of why the values are what they are. See section 9.7 Summary of Options for some extra information.
to print value of macro X in the makefile - just add line. ( kind of printf )
$(warning X is $(X))
Reinier and Shraddha have the right answers for the question as asked but I'm not sure that's the right question to have asked.
It would seem to me (based on nothing more than the snippet of makefile posted) that those are more likely to be variables you can set than variables that are already set. That is they would be how you control the location used for locating libunwind.
So if the try-cc call is failing I'd assume that means you either don't have libunwind installed at all or that you have it installed in a non-standard system location and haven't set those variables to tell make about it.

Resources