View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0001474||OpenFOAM||[All Projects] Bug||public||2015-01-03 20:39||2016-10-04 08:35|
|Fixed in Version|
|Summary||0001474: Feedback on the 64-bit labels recently implemented|
|Description||Not sure if this is going to be the only issue, but so far the first one I found, at least with GCC 4.6.3, is that this was missing:|
in the build options. Without it, tons of the following happen during building:
/home/ofuser/OpenFOAM/OpenFOAM-dev/src/OpenFOAM/lnInclude/label.H:61:1: error: ‘INT64_MIN’ was not declared in this scope
/home/ofuser/OpenFOAM/OpenFOAM-dev/src/OpenFOAM/lnInclude/label.H:62:1: error: ‘INT64_MAX’ was not declared in this scope
similar happens with the 32-bit labels.
|Additional Information||Quick fix/patch:|
diff --git a/wmake/rules/linux64Gcc/c++ b/wmake/rules/linux64Gcc/c++
index a23dd82..2e88664 100644
@@ -9,7 +9,7 @@ CC = g++ -m64
-ptFLAGS = -DNoRepository -ftemplate-depth-100
+ptFLAGS = -DNoRepository -ftemplate-depth-100 -D__STDC_LIMIT_MACROS
c++FLAGS = $(GFLAGS) $(c++WARN) $(c++OPT) $(c++DBUG) $(ptFLAGS) $(LIB_HEADER_DIRS) -fPIC
|Tags||No tags attached.|
Maintaning backward compatibility with old gcc versions is becoming increasingly problematic and at the moment I only test back to gcc-4.7.2 for releases. I have tested the latest OpenFOAM-dev with gcc-4.8.1, 4.9.2 and Clang-3.5.0.
I will add the -D__STDC_LIMIT_MACROS to the gcc rules for 4.5 and 4.6 and with check if it is needed for 4.7.
||I am building with gcc-4.7.2 and -D__STDC_LIMIT_MACROS is not needed|
||I am now building with gcc-4.6.4 and -D__STDC_LIMIT_MACROS is not needed|
||Is this an issue with the gcc version or your system header files?|
I haven't managed yet to test on more systems other than on my main machine, which is using Ubuntu 12.04 x86_64. The header it's using is the default one at "/usr/include/stdint.h".
Tomorrow (er, today) I'll test on a few more virtual machines with other Linux Distributions/versions, to assess what's going on. I do have a tendency to manage some crazy building conditions sometimes... even if I'm mostly using standard installations with standard options...
OK, I've isolated the source of this issue. This was a fix that was implemented in libc:
- Bug report: https://sourceware.org/bugzilla/show_bug.cgi?id=15366
- The commit that fixed this: https://sourceware.org/git/?p=glibc.git;a=commit;h=1ef74943ce2f114c78b215af57c2ccc72ccdb0b7
- Was made part of libc as of version 2.18: https://sourceware.org/git/?p=glibc.git;a=tag;h=f470138ba1124af9cffb839912538bbab2d0ca07
Therefore, if the libc library in use is 2.18 or newer (10 Aug 2013), then this definition "__STDC_LIMIT_MACROS" is not necessary.
OK, this is certainly annoying... CentOS/RHEL 7.0 is using libc 2.17, which doesn't have this fix yet.
I'll test if "std::numeric_limits<int32_t>::max()" is more generic than "INT32_MAX".
Source for this idea: http://stackoverflow.com/questions/3233054/error-int32-max-was-not-declared-in-this-scope
> I'll test if "std::numeric_limits<int32_t>::max()" is more generic than "INT32_MAX".
This requires C++11 support which we don't yet rely on in order to maintain support for gcc-4.5 and gcc-4.6. Initially I used cstdint rather than stdint.h but this would have limited gcc versions to 4.7 or higher and required the use of the C++11 support option. At some point I would like to use much of the C++11 functionality in OpenFOAM but we have to wait until support for Ubuntu 12.04 and other old GNU/Linux releases is no longer needed.
I have successfully completed testing of OpenFOAM-dev with gcc-4.[5-8].4, gcc-4.9.2 and clang-3.5.0: no problems.
> I have successfully completed testing of OpenFOAM-dev with gcc-4.[5-8].4, gcc-4.9.2 and clang-3.5.0: no problems.
My guess is that you did not have any problems because your system has got "libc" 2.18, 2.19 or newer. You might not have as much success with a system with "libc" 2.17 or older.
While testing with "numeric_limits", I spotted a few stray "INT_MAX" (and UINT_MAX) macros that can be harmful sometime in the future. Perhaps it's best to either switch them to "INT32_MAX" or something more explicitly generic. You can find them by running:
find src -name *.[CH] -type f | xargs grep INT_MAX
In the mean time I'll continue testing with "numeric_limits".
As far as I can figure out, there was a fix made on "numeric_limits::min/max" in C++11 to have it return as "constexpr" or something like that. But otherwise, this is something that has existed for far longer than C++11.
I'll test "numeric_limits::min/max" on my current system, on a much older and on a much newer system, to assess if using "numeric_limits" is bullet-proof or not to "libc" versions and C++ standards.
I will check the use of INT_MAX as you suggest. If "numeric_limits::min/max" proves problematic on old systems as an interim solution I am OK adding
just before the inclusion of stdint.h as suggested in the bug-reports you dug-up.
Now I understand it better... this is why you had stated that "numeric_limits::min/max" was C++11 only:
static const label labelMin = INT_SIZE(INT, _MIN);
static const label labelMax = INT_SIZE(INT, _MAX);
precisely due to the new feature "constexpr" in C++11.
edit: Mainly because of this:
Then I'll test with:
before all "#include <stdint.h>" in OpenFOAM's own source code.
> find src -name *.[CH] -type f | xargs grep INT_MAX
Most of these occurrences relate specifically to type int and hence using INT_MAX is correct. The only exceptions are in ptscotchDecomp.C and
scotchDecomp.C which should now use labelMax. I will push this change.
||I am testing using numeric_limits at the moment and so far I have not had any problems. I will test build with gcc-4.[5-9] and clang-3.5.0 before pushing the change.|
I have hit the same problem you hit, back to
Resolved by commit 097f23e11a3ee5c4e93ffc68b89614265459e6d5
When we stop supporting old GNU/Linux versions and upgrade to C++11 this nonsense will be replaced with cstdint and numeric_limits.
Sorry, gotta reopen this report with some more information. This happened both with the hacks I had tried before your commit, as well with a fresh "git pull":
In file included from /home/ofuser/OpenFOAM/OpenFOAM-dev/src/OpenFOAM/lnInclude/doubleFloat.H:29:0,
/home/ofuser/OpenFOAM/OpenFOAM-dev/src/OpenFOAM/lnInclude/label.H:61:1: error: ‘INT32_MIN’ was not declared in this scope
/home/ofuser/OpenFOAM/OpenFOAM-dev/src/OpenFOAM/lnInclude/label.H:62:1: error: ‘INT32_MAX’ was not declared in this scope
Attached is a patch file "foamyIncludeOrder.patch" with the changes that seemed to fix this issue.
I haven't taken the time to further debug this, but something in the "CGALTriangulation3Ddefs.H" and "CGALTriangulation2Ddefs.H" is interfering with the "#define __STDC_LIMIT_MACROS".
I think I deduced it now... CGAL's headers also include the "stdint.h" before OpenFOAM's own headers.
foamyIncludeOrder.patch (2,559 bytes)
diff --git a/applications/utilities/mesh/generation/foamyHexMesh/conformalVoronoiMesh/conformalVoronoiMesh/conformalVoronoiMesh.H b/applications/utilities/mesh/generation/foamyHexMesh/conformalVoronoiMesh/conformalVoronoiMesh/conformalVoronoiMesh.H index eb1cf68..b85fb37 100644 --- a/applications/utilities/mesh/generation/foamyHexMesh/conformalVoronoiMesh/conformalVoronoiMesh/conformalVoronoiMesh.H +++ b/applications/utilities/mesh/generation/foamyHexMesh/conformalVoronoiMesh/conformalVoronoiMesh/conformalVoronoiMesh.H @@ -41,8 +41,8 @@ SourceFiles #ifndef conformalVoronoiMesh_H #define conformalVoronoiMesh_H -#include "CGALTriangulation3Ddefs.H" #include "uint.H" +#include "CGALTriangulation3Ddefs.H" #include "searchableSurfaces.H" #include "conformationSurfaces.H" #include "cellShapeControl.H" diff --git a/applications/utilities/mesh/generation/foamyHexMesh/conformalVoronoiMesh/conformalVoronoiMesh/featurePointConformer/featurePointConformer.H b/applications/utilities/mesh/generation/foamyHexMesh/conformalVoronoiMesh/conformalVoronoiMesh/featurePointConformer/featurePointConformer.H index e3c415b..e832b29 100644 --- a/applications/utilities/mesh/generation/foamyHexMesh/conformalVoronoiMesh/conformalVoronoiMesh/featurePointConformer/featurePointConformer.H +++ b/applications/utilities/mesh/generation/foamyHexMesh/conformalVoronoiMesh/conformalVoronoiMesh/featurePointConformer/featurePointConformer.H @@ -39,12 +39,12 @@ SourceFiles #ifndef featurePointConformer_H #define featurePointConformer_H -#include "CGALTriangulation3Ddefs.H" #include "vector.H" #include "DynamicList.H" #include "List.H" #include "extendedFeatureEdgeMesh.H" #include "pointPairs.H" +#include "CGALTriangulation3Ddefs.H" // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * // diff --git a/applications/utilities/mesh/generation/foamyQuadMesh/CV2D.H b/applications/utilities/mesh/generation/foamyQuadMesh/CV2D.H index 4948196..e3e316a 100644 --- a/applications/utilities/mesh/generation/foamyQuadMesh/CV2D.H +++ b/applications/utilities/mesh/generation/foamyQuadMesh/CV2D.H @@ -117,8 +117,6 @@ SourceFiles #define CGAL_INEXACT #define CGAL_HIERARCHY -#include "CGALTriangulation2Ddefs.H" - #include "Time.H" #include "point2DFieldFwd.H" #include "dictionary.H" @@ -134,6 +132,8 @@ SourceFiles #include "relaxationModel.H" #include "cellSizeAndAlignmentControls.H" +#include "CGALTriangulation2Ddefs.H" + // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * // namespace Foam
foamyIncludeOrder.patch (2,559 bytes)
I applied the patch but re-ordered a bit and added a comment. Maybe it would be more obvious if we simply define __STDC_LIMIT_MACROS before the CGAL headers are included.
Please re-open if there are any remaining issues with this.
There is a problem with
- compiling Pstream
- with IntelMPI
- with g++ (clang++ is ok)
What seems to be happening:
- Intel mpi.h pulls in /usr/include/stdint.h
but without setting __STDC_LIMIT_MACROS
- so then when it comes to uint32.H it does not include stdin.h anymore.
||I want to avoid the proliferation of __STDC_LIMIT_MACROS which is a temporary work-around for old C++ compilers. Why not move the include of mpi.h after the OpenFOAM headers?|
|Sounds good. Is what we're doing already in e.g. ptscotchDecomp.C and zoltanRenumber.C|
#define __STDC_LIMIT_MACROS removed from OpenFOAM-dev:
|2015-01-03 20:39||wyldckat||New Issue|
|2015-01-03 21:14||henry||Note Added: 0003484|
|2015-01-03 21:23||henry||Note Added: 0003485|
|2015-01-03 23:34||henry||Note Added: 0003493|
|2015-01-03 23:35||henry||Note Added: 0003494|
|2015-01-04 01:25||wyldckat||Note Added: 0003495|
|2015-01-04 11:13||wyldckat||Note Added: 0003496|
|2015-01-04 12:06||henry||Note Added: 0003497|
|2015-01-04 13:31||wyldckat||Note Added: 0003498|
|2015-01-04 13:46||henry||Note Added: 0003499|
|2015-01-04 15:20||wyldckat||Note Added: 0003501|
|2015-01-04 15:21||wyldckat||Note Edited: 0003501||View Revisions|
|2015-01-04 15:45||henry||Note Added: 0003503|
|2015-01-04 18:22||henry||Note Added: 0003504|
|2015-01-04 18:51||henry||Note Added: 0003505|
|2015-01-04 20:18||henry||Note Added: 0003506|
|2015-01-04 20:18||henry||Status||new => resolved|
|2015-01-04 20:18||henry||Resolution||open => fixed|
|2015-01-04 20:18||henry||Assigned To||=> henry|
|2015-01-04 22:05||wyldckat||Note Added: 0003507|
|2015-01-04 22:05||wyldckat||Status||resolved => feedback|
|2015-01-04 22:05||wyldckat||Resolution||fixed => reopened|
|2015-01-04 22:06||wyldckat||File Added: foamyIncludeOrder.patch|
|2015-01-04 23:46||henry||Note Added: 0003508|
|2015-01-04 23:46||henry||Status||feedback => resolved|
|2015-01-04 23:46||henry||Resolution||reopened => fixed|
||Note Added: 0005004|
|2015-06-26 12:11||henry||Note Added: 0005005|
||Note Added: 0005006|
|2016-10-04 08:35||henry||Note Added: 0006956|