quick question about compiling Stockfish with icc

[Don]

Thanks for the clarification. It was my first attempt at compiling with something other than gcc, which never produced similar messages during my experience.

If you use gcc with the flags:

-Wwrite-strings -Wcast-qual -Wshadow -Wconversion -W -Wall -ansi -pedantic

as I do, you will see that it screams as loud and often as icc does. Incidentally, you should strive to understand what the warnings mean and then check each and every one of them to ensure that they are spurious. (I admit that I do not always check every warning on projects written by other people but I sometimes do. However, I always check every warning on my own code.).

The first type of warning up above is designed to show problems like this:

int int_value = 23456789;
char char_value = int_value; /* Compiler complains about losing significant bits. If you print char_value you will see it is not the same as int_value for obvious reasons. */

The above type of assignment is safe if and only if the contents of int_value are less than or equal to CHAR_MAX and greater than or equal to CHAR_MIN as defined in limits.h.

As an exercise, you might include <assert.h> and then put an assert on each assignment that gets a warning to see if there really is a problem. Then do a debug build and run some chess contests with the debug engine. Once in a while you will find a real bug by doing this.

I always use -Wall and make my programs compile without generating warning. Some warnings are actually bugs - it's an easy way to avoid a lot of bugs.

[michiguel]

Thanks for the clarification. It was my first attempt at compiling with something other than gcc, which never produced similar messages during my experience.

If you use gcc with the flags:

-Wwrite-strings -Wcast-qual -Wshadow -Wconversion -W -Wall -ansi -pedantic

as I do, you will see that it screams as loud and often as icc does. Incidentally, you should strive to understand what the warnings mean and then check each and every one of them to ensure that they are spurious. (I admit that I do not always check every warning on projects written by other people but I sometimes do. However, I always check every warning on my own code.).

The first type of warning up above is designed to show problems like this:

int int_value = 23456789;
char char_value = int_value; /* Compiler complains about losing significant bits. If you print char_value you will see it is not the same as int_value for obvious reasons. */

The above type of assignment is safe if and only if the contents of int_value are less than or equal to CHAR_MAX and greater than or equal to CHAR_MIN as defined in limits.h.

As an exercise, you might include <assert.h> and then put an assert on each assignment that gets a warning to see if there really is a problem. Then do a debug build and run some chess contests with the debug engine. Once in a while you will find a real bug by doing this.

I always use -Wall and make my programs compile without generating warning. Some warnings are actually bugs - it's an easy way to avoid a lot of bugs.

-Wall produce only a fraction of all available warnings. In fact, it produces too few. I really cannot understand why this name has been chosen to deceive. I have been using -Wall -Wextra, but now I see that with Dann's, some other warnings are turned on.

Be careful, some important warnings are off with -Wall!!!

Miguel

[michiguel]

Thanks for the clarification. It was my first attempt at compiling with something other than gcc, which never produced similar messages during my experience.

If you use gcc with the flags:

-Wwrite-strings -Wcast-qual -Wshadow -Wconversion -W -Wall -ansi -pedantic

as I do, you will see that it screams as loud and often as icc does. Incidentally, you should strive to understand what the warnings mean and then check each and every one of them to ensure that they are spurious. (I admit that I do not always check every warning on projects written by other people but I sometimes do. However, I always check every warning on my own code.).

The first type of warning up above is designed to show problems like this:

int int_value = 23456789;
char char_value = int_value; /* Compiler complains about losing significant bits. If you print char_value you will see it is not the same as int_value for obvious reasons. */

The above type of assignment is safe if and only if the contents of int_value are less than or equal to CHAR_MAX and greater than or equal to CHAR_MIN as defined in limits.h.

As an exercise, you might include <assert.h> and then put an assert on each assignment that gets a warning to see if there really is a problem. Then do a debug build and run some chess contests with the debug engine. Once in a while you will find a real bug by doing this.

I always use -Wall and make my programs compile without generating warning. Some warnings are actually bugs - it's an easy way to avoid a lot of bugs.

-Wall produce only a fraction of all available warnings. In fact, it produces too few. I really cannot understand why this name has been chosen to deceive. I have been using -Wall -Wextra, but now I see that with Dann's, some other warnings are turned on.

Be careful, some important warnings are off with -Wall!!!

Miguel

eng.c(656): warning #167: argument of type "const struct prmtrs **" is incompatible with parameter of type "const struct prmtrs *"
adjust_internal_clock (gr, &prm);

This was not detected by GCC with Dann's switches and was detected by intel.

I was chasing this bug for an hour.

Miguel

[Don]

Thanks for the clarification. It was my first attempt at compiling with something other than gcc, which never produced similar messages during my experience.

If you use gcc with the flags:

-Wwrite-strings -Wcast-qual -Wshadow -Wconversion -W -Wall -ansi -pedantic

as I do, you will see that it screams as loud and often as icc does. Incidentally, you should strive to understand what the warnings mean and then check each and every one of them to ensure that they are spurious. (I admit that I do not always check every warning on projects written by other people but I sometimes do. However, I always check every warning on my own code.).

The first type of warning up above is designed to show problems like this:

int int_value = 23456789;
char char_value = int_value; /* Compiler complains about losing significant bits. If you print char_value you will see it is not the same as int_value for obvious reasons. */

The above type of assignment is safe if and only if the contents of int_value are less than or equal to CHAR_MAX and greater than or equal to CHAR_MIN as defined in limits.h.

As an exercise, you might include <assert.h> and then put an assert on each assignment that gets a warning to see if there really is a problem. Then do a debug build and run some chess contests with the debug engine. Once in a while you will find a real bug by doing this.

I always use -Wall and make my programs compile without generating warning. Some warnings are actually bugs - it's an easy way to avoid a lot of bugs.

-Wall produce only a fraction of all available warnings. In fact, it produces too few. I really cannot understand why this name has been chosen to deceive. I have been using -Wall -Wextra, but now I see that with Dann's, some other warnings are turned on.

Be careful, some important warnings are off with -Wall!!!

Miguel

I will be turning on other warnings then.

[Don]

Dann or anyone,

I'm compiling with more warning enabled now. Now I get warning errors with bitfields in structures. It's really annoying because there seems to be no solution that I have found to prevent the warning generated going from a smaller fields to a 32 bit field.

I cannot find anything on the web except to AND the value you are assigned with a constant. That actually generates additional code and that is seriously broken in my opinion.

example:

tt.cpp:127: warning: conversion to ‘unsigned int:18’ from ‘uint32_t’ may alter its value

I'm using: gcc (Ubuntu 4.4.3-4ubuntu5) 4.4.3

Any ideas?

Don

Thanks for the clarification. It was my first attempt at compiling with something other than gcc, which never produced similar messages during my experience.

If you use gcc with the flags:

-Wwrite-strings -Wcast-qual -Wshadow -Wconversion -W -Wall -ansi -pedantic

as I do, you will see that it screams as loud and often as icc does. Incidentally, you should strive to understand what the warnings mean and then check each and every one of them to ensure that they are spurious. (I admit that I do not always check every warning on projects written by other people but I sometimes do. However, I always check every warning on my own code.).

The first type of warning up above is designed to show problems like this:

int int_value = 23456789;
char char_value = int_value; /* Compiler complains about losing significant bits. If you print char_value you will see it is not the same as int_value for obvious reasons. */

The above type of assignment is safe if and only if the contents of int_value are less than or equal to CHAR_MAX and greater than or equal to CHAR_MIN as defined in limits.h.

As an exercise, you might include <assert.h> and then put an assert on each assignment that gets a warning to see if there really is a problem. Then do a debug build and run some chess contests with the debug engine. Once in a while you will find a real bug by doing this.

[michiguel]

Dann or anyone,

I'm compiling with more warning enabled now. Now I get warning errors with bitfields in structures. It's really annoying because there seems to be no solution that I have found to prevent the warning generated going from a smaller fields to a 32 bit field.

I cannot find anything on the web except to AND the value you are assigned with a constant. That actually generates additional code and that is seriously broken in my opinion.

example:

tt.cpp:127: warning: conversion to ‘unsigned int:18’ from ‘uint32_t’ may alter its value

I'm using: gcc (Ubuntu 4.4.3-4ubuntu5) 4.4.3

Any ideas?

Don

Thanks for the clarification. It was my first attempt at compiling with something other than gcc, which never produced similar messages during my experience.

If you use gcc with the flags:

-Wwrite-strings -Wcast-qual -Wshadow -Wconversion -W -Wall -ansi -pedantic

as I do, you will see that it screams as loud and often as icc does. Incidentally, you should strive to understand what the warnings mean and then check each and every one of them to ensure that they are spurious. (I admit that I do not always check every warning on projects written by other people but I sometimes do. However, I always check every warning on my own code.).

The first type of warning up above is designed to show problems like this:

int int_value = 23456789;
char char_value = int_value; /* Compiler complains about losing significant bits. If you print char_value you will see it is not the same as int_value for obvious reasons. */

The above type of assignment is safe if and only if the contents of int_value are less than or equal to CHAR_MAX and greater than or equal to CHAR_MIN as defined in limits.h.

As an exercise, you might include <assert.h> and then put an assert on each assignment that gets a warning to see if there really is a problem. Then do a debug build and run some chess contests with the debug engine. Once in a while you will find a real bug by doing this.

If we know what warning is the culprit, it could be silenced in a fragment of the program like this
http://gcc.gnu.org/onlinedocs/gcc/Diagn ... ic-Pragmas

I guess that the responsible warning could be found here
http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html

I generally try to avoid pragmas, but sometimes it is impossible w/o turning off the warning. I prefer to use a localized pragma than turning off the warning for the whole program.

Miguel

[bob]

Dann or anyone,

I'm compiling with more warning enabled now. Now I get warning errors with bitfields in structures. It's really annoying because there seems to be no solution that I have found to prevent the warning generated going from a smaller fields to a 32 bit field.

Have you tried the obvious re-cast? I have been looking at these warnings as well (I do not use bit fields due to inefficiency, but there are a _ton_ of others, including my inline asm won't work with all the warnings enabled)...

I cannot find anything on the web except to AND the value you are assigned with a constant. That actually generates additional code and that is seriously broken in my opinion.

example:

tt.cpp:127: warning: conversion to ‘unsigned int:18’ from ‘uint32_t’ may alter its value

I'm using: gcc (Ubuntu 4.4.3-4ubuntu5) 4.4.3

Any ideas?

Don

Thanks for the clarification. It was my first attempt at compiling with something other than gcc, which never produced similar messages during my experience.

If you use gcc with the flags:

-Wwrite-strings -Wcast-qual -Wshadow -Wconversion -W -Wall -ansi -pedantic

as I do, you will see that it screams as loud and often as icc does. Incidentally, you should strive to understand what the warnings mean and then check each and every one of them to ensure that they are spurious. (I admit that I do not always check every warning on projects written by other people but I sometimes do. However, I always check every warning on my own code.).

The first type of warning up above is designed to show problems like this:

int int_value = 23456789;
char char_value = int_value; /* Compiler complains about losing significant bits. If you print char_value you will see it is not the same as int_value for obvious reasons. */

The above type of assignment is safe if and only if the contents of int_value are less than or equal to CHAR_MAX and greater than or equal to CHAR_MIN as defined in limits.h.

As an exercise, you might include <assert.h> and then put an assert on each assignment that gets a warning to see if there really is a problem. Then do a debug build and run some chess contests with the debug engine. Once in a while you will find a real bug by doing this.

[Don]

Dann or anyone,

I'm compiling with more warning enabled now. Now I get warning errors with bitfields in structures. It's really annoying because there seems to be no solution that I have found to prevent the warning generated going from a smaller fields to a 32 bit field.

Have you tried the obvious re-cast?

I stated the problem incorrectly, I'm trying to assign a smaller field from a larger integer type, otherwise I'm sure a cast would work fine.

How do you cast a 32 bit value to an 18 bit value so that the compiler will let it work? There is no syntax for doing that such as "(int:18) x"

I have been looking at these warnings as well (I do not use bit fields due to inefficiency, but there are a _ton_ of others, including my inline asm won't work with all the warnings enabled)...

I cannot find anything on the web except to AND the value you are assigned with a constant. That actually generates additional code and that is seriously broken in my opinion.

example:

tt.cpp:127: warning: conversion to ‘unsigned int:18’ from ‘uint32_t’ may alter its value

I'm using: gcc (Ubuntu 4.4.3-4ubuntu5) 4.4.3

Any ideas?

Don

Thanks for the clarification. It was my first attempt at compiling with something other than gcc, which never produced similar messages during my experience.

If you use gcc with the flags:

-Wwrite-strings -Wcast-qual -Wshadow -Wconversion -W -Wall -ansi -pedantic

as I do, you will see that it screams as loud and often as icc does. Incidentally, you should strive to understand what the warnings mean and then check each and every one of them to ensure that they are spurious. (I admit that I do not always check every warning on projects written by other people but I sometimes do. However, I always check every warning on my own code.).

The first type of warning up above is designed to show problems like this:

int int_value = 23456789;
char char_value = int_value; /* Compiler complains about losing significant bits. If you print char_value you will see it is not the same as int_value for obvious reasons. */

The above type of assignment is safe if and only if the contents of int_value are less than or equal to CHAR_MAX and greater than or equal to CHAR_MIN as defined in limits.h.

As an exercise, you might include <assert.h> and then put an assert on each assignment that gets a warning to see if there really is a problem. Then do a debug build and run some chess contests with the debug engine. Once in a while you will find a real bug by doing this.

[Dann Corbit]

Dann or anyone,

I'm compiling with more warning enabled now. Now I get warning errors with bitfields in structures. It's really annoying because there seems to be no solution that I have found to prevent the warning generated going from a smaller fields to a 32 bit field.

I cannot find anything on the web except to AND the value you are assigned with a constant. That actually generates additional code and that is seriously broken in my opinion.

example:

tt.cpp:127: warning: conversion to ‘unsigned int:18’ from ‘uint32_t’ may alter its value

I'm using: gcc (Ubuntu 4.4.3-4ubuntu5) 4.4.3

Any ideas?

Don

Thanks for the clarification. It was my first attempt at compiling with something other than gcc, which never produced similar messages during my experience.

If you use gcc with the flags:

-Wwrite-strings -Wcast-qual -Wshadow -Wconversion -W -Wall -ansi -pedantic

as I do, you will see that it screams as loud and often as icc does. Incidentally, you should strive to understand what the warnings mean and then check each and every one of them to ensure that they are spurious. (I admit that I do not always check every warning on projects written by other people but I sometimes do. However, I always check every warning on my own code.).

The first type of warning up above is designed to show problems like this:

int int_value = 23456789;
char char_value = int_value; /* Compiler complains about losing significant bits. If you print char_value you will see it is not the same as int_value for obvious reasons. */

The above type of assignment is safe if and only if the contents of int_value are less than or equal to CHAR_MAX and greater than or equal to CHAR_MIN as defined in limits.h.

As an exercise, you might include <assert.h> and then put an assert on each assignment that gets a warning to see if there really is a problem. Then do a debug build and run some chess contests with the debug engine. Once in a while you will find a real bug by doing this.

After you have determined that there is no possibility if harm for a particular assignment, turn off that warning with a pragma, and then restore it afterwards. You can also remove the warning with a cast.

I do suggest adding an assert() so that if it really is overlooked somehow, you can discover the problem in debug mode.

[mcostalba]

Dann or anyone,

I'm compiling with more warning enabled now. Now I get warning errors with bitfields in structures. It's really annoying because there seems to be no solution that I have found to prevent the warning generated going from a smaller fields to a 32 bit field.

Have you tried the obvious re-cast?

I stated the problem incorrectly, I'm trying to assign a smaller field from a larger integer type, otherwise I'm sure a cast would work fine.

How do you cast a 32 bit value to an 18 bit value so that the compiler will let it work? There is no syntax for doing that such as "(int:18) x"

Ok, sorry, but I have enabled the -pedantic flag also on myself now

Here we go, a little bit of annoying coding best practice lesson: shutting up a warning with a cast is normally the "The Wrong Thing To Do" (tm).

It means you have not clear what a warning is: It is not an error, it is something that the campiler wants "warn" you about. Look, this _could_ be dangerous. If you simply shut up the warning with a cast of course you do _not_ fix the source of danger that is to assign a 32 bit value to a smaller one, you simply say to the compiler: "no, I am not interested you warn me about this", but the source of warning is still alive and kicking. And if you change something in the behaviour of your code, that source of warning could _silently_ become a source of bugs.

So the bottom line is that using casts to shut up the compiler is generally a very bad idea and will lead to _real_ bugs.