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.Dann Corbit wrote:If you use gcc with the flags:Justin Sherron wrote:Thanks for the clarification. It was my first attempt at compiling with something other than gcc, which never produced similar messages during my experience.
-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.
quick question about compiling Stockfish with icc
Moderators: hgm, Rebel, chrisw
-
- Posts: 5106
- Joined: Tue Apr 29, 2008 4:27 pm
Re: quick question about compiling Stockfish with icc
-
- Posts: 6401
- Joined: Thu Mar 09, 2006 8:30 pm
- Location: Chicago, Illinois, USA
Re: quick question about compiling Stockfish with icc
-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.Don wrote: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.Dann Corbit wrote:If you use gcc with the flags:Justin Sherron wrote:Thanks for the clarification. It was my first attempt at compiling with something other than gcc, which never produced similar messages during my experience.
-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.
Be careful, some important warnings are off with -Wall!!!
Miguel
-
- Posts: 6401
- Joined: Thu Mar 09, 2006 8:30 pm
- Location: Chicago, Illinois, USA
Re: quick question about compiling Stockfish with icc
eng.c(656): warning #167: argument of type "const struct prmtrs **" is incompatible with parameter of type "const struct prmtrs *"michiguel wrote:-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.Don wrote: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.Dann Corbit wrote:If you use gcc with the flags:Justin Sherron wrote:Thanks for the clarification. It was my first attempt at compiling with something other than gcc, which never produced similar messages during my experience.
-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.
Be careful, some important warnings are off with -Wall!!!
Miguel
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
-
- Posts: 5106
- Joined: Tue Apr 29, 2008 4:27 pm
Re: quick question about compiling Stockfish with icc
I will be turning on other warnings then.michiguel wrote:-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.Don wrote: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.Dann Corbit wrote:If you use gcc with the flags:Justin Sherron wrote:Thanks for the clarification. It was my first attempt at compiling with something other than gcc, which never produced similar messages during my experience.
-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.
Be careful, some important warnings are off with -Wall!!!
Miguel
-
- Posts: 5106
- Joined: Tue Apr 29, 2008 4:27 pm
Re: quick question about compiling Stockfish with icc
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
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
Dann Corbit wrote:If you use gcc with the flags:Justin Sherron wrote:Thanks for the clarification. It was my first attempt at compiling with something other than gcc, which never produced similar messages during my experience.
-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.
-
- Posts: 6401
- Joined: Thu Mar 09, 2006 8:30 pm
- Location: Chicago, Illinois, USA
Re: quick question about compiling Stockfish with icc
If we know what warning is the culprit, it could be silenced in a fragment of the program like thisDon wrote: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
Dann Corbit wrote:If you use gcc with the flags:Justin Sherron wrote:Thanks for the clarification. It was my first attempt at compiling with something other than gcc, which never produced similar messages during my experience.
-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.
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
-
- Posts: 20943
- Joined: Mon Feb 27, 2006 7:30 pm
- Location: Birmingham, AL
Re: quick question about compiling Stockfish with icc
Don wrote: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
Dann Corbit wrote:If you use gcc with the flags:Justin Sherron wrote:Thanks for the clarification. It was my first attempt at compiling with something other than gcc, which never produced similar messages during my experience.
-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.
-
- Posts: 5106
- Joined: Tue Apr 29, 2008 4:27 pm
Re: quick question about compiling Stockfish with icc
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.bob wrote:Don wrote: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?
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
Dann Corbit wrote:If you use gcc with the flags:Justin Sherron wrote:Thanks for the clarification. It was my first attempt at compiling with something other than gcc, which never produced similar messages during my experience.
-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.
-
- Posts: 12554
- Joined: Wed Mar 08, 2006 8:57 pm
- Location: Redmond, WA USA
Re: quick question about compiling Stockfish with icc
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.Don wrote: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
Dann Corbit wrote:If you use gcc with the flags:Justin Sherron wrote:Thanks for the clarification. It was my first attempt at compiling with something other than gcc, which never produced similar messages during my experience.
-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 do suggest adding an assert() so that if it really is overlooked somehow, you can discover the problem in debug mode.
-
- Posts: 2684
- Joined: Sat Jun 14, 2008 9:17 pm
Re: quick question about compiling Stockfish with icc
Ok, sorry, but I have enabled the -pedantic flag also on myself nowDon wrote: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.bob wrote:Don wrote: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?
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"
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.