From: Amitha P. <pe...@cs...> - 2004-08-11 14:26:33
|
Folks, contrib/prip is failing to build under VC 6, and has been so for a long time. I pinged Jocelyn at the sf.net address yesterday, but haven't had a response yet. (Maybe the forwarding there is old or incorrect?) Should we turn off prip until this issue is resolved? The problem is causing an error email every night to everyone who commits anything because of the broken build. It seems to me that the dashboard has been sending many broken build messages over the last few weeks. Too many emails, and they become worthless. I'm concerned that most people have already started ignoring the broken build emails. Amitha. |
From: Peter V. <Pet...@es...> - 2004-08-11 14:37:16
|
> contrib/prip is failing to build under VC 6, and has been so for a > long time. Simplest solution is to turn off (part of) the build for VC60 only. Or even just conditionally comment out the offending lines for VC60. -- Peter. |
From: Amitha P. <pe...@cs...> - 2004-08-11 14:43:26
|
On Wed 11 Aug 2004, Peter Vanroose wrote: > Simplest solution is to turn off (part of) the build for VC60 only. > Or even just conditionally comment out the offending lines for VC60. Indeed. But the problem is that the template instantiation causes inheritance by the same class three times. class Base { }; class Derived : public Base, public Base, public Base { }; I'm not sure that this is legal C++, for one. Even if it is, I'm not sure that the design intended for this to happen. In which case, the design is flawed, and should be corrected by redesign. My guess is that the inheritance is for inheritance of implementation, and not a "is-a" relationship. In which case the solution is to create appropriate member variables. But only Jocelyn can really answer that, I think. Amitha. |
From: Peter V. <Pet...@es...> - 2004-08-11 14:58:31
|
> class Base { }; > class Derived : public Base, public Base, public Base { }; Actually, it's more something like (but still somewhat more complex than) template <T> class Base { typedef T base_type; }; template <class V, class E> class Derived : public Base<typename V::base_type>, public Base<typename E::base_type> { }; where V::base_type and E::base_type are never identical. Apparently, VC60 (only!) decides on "being identical" before resolution of the template arguments in use, hence sees twice Base<undefined_type> -- Peter. |
From: Amitha P. <pe...@cs...> - 2004-08-11 16:53:26
|
On Wed 11 Aug 2004, Peter Vanroose wrote: > Actually, it's more something like (but still somewhat more complex than) > > template <T> class Base { typedef T base_type; }; > template <class V, class E> class Derived > : public Base<typename V::base_type>, > public Base<typename E::base_type> { }; > > where V::base_type and E::base_type are never identical. You're right. When I first glanced at it yesterday, I thought they all resolved to .._base_dart, but now I see that they all (should!) resolve to distinct classes. I guess VC 6 is broken here. I would guess that it is important that all three base classes exist for the correct functioning of the class, so the temporary solution you committed would only fix the compiler errors, not the correctness of the code. If we can't find a solution that makes it compile correctly under VC 6, we should disable vpyr for VC 6 (with a CMake error message). Of course, we may need to disable vpyr in general (!), depending on the response to your other observation about the failing tests. But presumably the code works correctly under some compiler/platform combination; otherwise Jocelyn wouldn't have contributed it. Amitha. |
From: Ian S. <ian...@st...> - 2004-08-12 10:02:00
|
Amitha Perera wrote: ... > You're right. When I first glanced at it yesterday, I thought they > all resolved to .._base_dart, but now I see that they all (should!) > resolve to distinct classes. I guess VC 6 is broken here. > > I would guess that it is important that all three base classes exist > for the correct functioning of the class, so the temporary solution > you committed would only fix the compiler errors, not the > correctness of the code. If we can't find a solution that makes it > compile correctly under VC 6, we should disable vpyr for VC 6 (with > a CMake error message). Since I still use VC 6 myself, I appreciate attempts to keep VXL's syntax "dumb enough" to use it. However, might it be worth stating that VXL intends to drop VC6 support at some fixed date in the future? I can't talk for other sites, but at Manchester the only thing keeping us on VC6 is laziness. Ian. |
From: Amitha P. <pe...@cs...> - 2004-08-12 13:43:04
|
I've just committed a workaround that gets it to compile cleanly under VC 6. The tests still core dump, but as Peter pointed out, it core dumps on more than one platform. Does anyone know how to contact Jocelyn? Amitha. |
From: Peter V. <Pet...@es...> - 2004-08-11 14:41:22
|
> contrib/prip is failing to build under VC 6 Apart from this, the 3 failing tests (segfaults on all platforms) indicate a serious flaw somewhere in the prip code; this should be fixed preferably by the author. I would add that this also applies to the other failing tests, especially gevd_test_noise, sdet_test_region_proc and vifa_test_region_proc. -- Peter. |
From: Bill H. <bil...@ki...> - 2004-08-16 19:37:04
|
The vnl part of ITK has a number of warnings that are being suppressed by Dart. I would like to suppress them from the code with pragmas. The problem is that new users building from source code 100's of warnings. HEre diff -r1.6 vcl_compiler.h 21a22,28 > // 1116 Non-void function "std::__malloc_alloc_template<0>::_S_oom_malloc" (declared > // at line 163) should return a value. > // 3505 setjmp not marked as unknown_control_flow because it is not declared as a > // 3438 ceil not marked as no_side_effects because it is not declared as a function > # pragma set woff 3438 > # pragma set woff 1116 > # pragma set woff 3505 |
From: Peter V. <Pet...@es...> - 2004-08-17 06:50:43
|
> The vnl part of ITK has a number of warnings that are being > suppressed by Dart. I would like to suppress them from > the code with pragmas. The problem is that new users building > from source code 100's of warnings. >> # pragma set woff 3438 >> # pragma set woff 1116 >> # pragma set woff 3505 Disabling these warnings goes perfectly through command line switches; I have the following in my CMakeCache.txt : CMAKE_CXX_FLAGS:STRING=-ptused -no_prelink -ptv -LANG:ansi-for-init-scope=ON -no_auto_include -fullwarn -woff 1116,1174,1209,1355,1375,1468,1506,1682 B.t.w., I would not switch off 3438 and 3505 since these give valuable indications of potential problems. And I've never encountered them in vxl. -- Peter. |
From: William A. H. <bil...@ny...> - 2004-08-17 13:43:25
|
Yes, you can do it on the command line, however, when a user goes to build the software if they do not know about the VERY long CXXFLAGS list of warnings to suppress, then they see 1000's of warnings and think the software has problems. People building the software out of the box should see the same thing as the dashboards. Can you tell me how 3438 and 3505 have been useful to you? http://www.itk.org/Testing/Sites/rapture.sci.utah.edu/IRIX64-CC-7.3/20040815-0500-Nightly/BuildWarning.html I get 3438 in building vnl: Building object file vnl_least_squares_function.o... Building object file vnl_least_squares_cost_function.o... cc-3438 CC: WARNING File = /usr/include/math.h, Line = 308 ceil not marked as no_side_effects because it is not declared as a function #pragma no side effects (ceil) ^ What does this mean, and how do I fix it? I get 3505 here: Building object file test_stlfwd.o... Building object file test_string.o... Building object file test_sstream.o... Building object file test_vector.o... Building object file test_cstdio.o... Building object file test_include.o... cc-3505 CC: WARNING File = /usr/include/internal/setjmp_core.h, Line = 74 setjmp not marked as unknown_control_flow because it is not declared as a function #pragma unknown_control_flow (setjmp) ^ Again, how do I fix this? -Bill At 02:47 AM 8/17/2004, Peter Vanroose wrote: >>The vnl part of ITK has a number of warnings that are being >>suppressed by Dart. I would like to suppress them from >>the code with pragmas. The problem is that new users building >>from source code 100's of warnings. >>># pragma set woff 3438 >>># pragma set woff 1116 >>># pragma set woff 3505 > >Disabling these warnings goes perfectly through command line switches; >I have the following in my CMakeCache.txt : >CMAKE_CXX_FLAGS:STRING=-ptused -no_prelink -ptv -LANG:ansi-for-init-scope=ON -no_auto_include -fullwarn -woff 1116,1174,1209,1355,1375,1468,1506,1682 > >B.t.w., I would not switch off 3438 and 3505 since these give valuable > indications of potential problems. And I've never encountered > them in vxl. > > >-- Peter. > > >------------------------------------------------------- >SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media >100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 >Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. >http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 >_______________________________________________ >Vxl-maintainers mailing list >Vxl...@li... >https://lists.sourceforge.net/lists/listinfo/vxl-maintainers |
From: Peter V. <Pet...@es...> - 2004-08-17 15:48:39
|
> Can you tell me how 3438 and 3505 have been useful to you? I have never encountered those two warnings. Maybe I have a different version of the compiler? (Mine is 721.) > cc-3438 CC: WARNING File = /usr/include/math.h, Line = 308 > ceil not marked as no_side_effects because it is not declared as a function > > #pragma no side effects (ceil) > ^ That looks like an incompatibility between the compiler and /usr/include/math.h Were the /usr/include files updated when a new compiler version was installed? Or maybe only /usr/include was upgraded and not the compiler? > cc-3505 CC: WARNING File = /usr/include/internal/setjmp_core.h, Line = 74 > setjmp not marked as unknown_control_flow because it is not declared as a function > > #pragma unknown_control_flow (setjmp) > ^ Same comment. It would be "ideal" to be able to ignore warnings in /usr/include/*.h I don't know whether this is possible. Well, of course, with a simple (perl) script it's easy to "remove" e.g. all 3505 warnings in files named /usr/include/*.h Maybe the following approach could work: 1. Make sure that all access to /usr/include/math.h goes through vcl/sgi/vcl_cmath.h 2. Place those #pragma's in that file. Or possibly in a generated file but only when "#pragma no_side_effects" is present in /usr/include/math.h etc. -- Peter. |
From: Amitha P. <pe...@cs...> - 2004-08-18 12:52:58
|
On Tue 17 Aug 2004, Peter Vanroose wrote: > Maybe the following approach could work: > 1. Make sure that all access to /usr/include/math.h goes through > vcl/sgi/vcl_cmath.h > 2. Place those #pragma's in that file. Or possibly in a generated file > but only when "#pragma no_side_effects" is present in > /usr/include/math.h etc. For what it's worth, I agree with Peter's recommendation, if it can be achieved. I'd much rather the warnings due to system libraries be selectively and locally supressed via vcl than globally switching off warnings. Is there a warning push and pop for the MIPSPro compiler like there is for the Visual Studio compiler? |
From: Peter V. <Pet...@es...> - 2004-08-18 13:02:40
|
> Is there a warning push and pop for the MIPSPro compiler like there > is for the Visual Studio compiler? No, most probably not. I've never encountered anything of that kind. I've just verified that the "#pragma no side effects (...)" are also present in my /usr/include/math.h but still I've never encountered any of those compiler warnings (with my compiler version 721). -- Peter. |
From: William A. H. <bil...@ny...> - 2004-08-18 13:44:59
|
There is a #pragma set woff 1111 and a #pragma reset woff 1111 I am not sure it is the same as push and pop, but it is what seems to be done in stl. stl_vector.h:#pragma set woff 1174 stl_vector.h:#pragma set woff 1375 stl_vector.h:#pragma reset woff 1174 stl_vector.h:#pragma reset woff 1375 -Bill At 08:52 AM 8/18/2004, Amitha Perera wrote: >On Tue 17 Aug 2004, Peter Vanroose wrote: >> Maybe the following approach could work: >> 1. Make sure that all access to /usr/include/math.h goes through >> vcl/sgi/vcl_cmath.h >> 2. Place those #pragma's in that file. Or possibly in a generated file >> but only when "#pragma no_side_effects" is present in >> /usr/include/math.h etc. > >For what it's worth, I agree with Peter's recommendation, if it can be >achieved. I'd much rather the warnings due to system libraries be >selectively and locally supressed via vcl than globally switching off >warnings. > >Is there a warning push and pop for the MIPSPro compiler like there >is for the Visual Studio compiler? > > >------------------------------------------------------- >SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media >100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 >Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. >http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 >_______________________________________________ >Vxl-maintainers mailing list >Vxl...@li... >https://lists.sourceforge.net/lists/listinfo/vxl-maintainers |
From: Peter V. <Pet...@es...> - 2004-08-18 15:49:24
|
> #pragma set woff 1111 > #pragma reset woff 1111 That's indeed interesting. If this works like push/pop, you could try placing those in vcl/sgi/vcl_cmath.h around the offending #include(s) and see if that helps. -- Peter. |
From: Bill H. <bil...@ki...> - 2004-08-20 15:59:13
|
The CMakeLists.txt file in vcl seems to always compile the emulation directory. Things like vcl_alloc.cxx are always compiled. I thought this stuff was not used by all compilers? Should the build of emulation files be conditional on if they are actually going to be used? -Bill |
From: Peter V. <Pet...@es...> - 2004-08-21 20:22:09
|
> The CMakeLists.txt file in vcl seems to always compile > the emulation directory. Things like vcl_alloc.cxx are always compiled. > I thought this stuff was not used by all compilers? Should the > build of emulation files be conditional on if they are actually going > to be used? Yes, you're probably right. I seem to remember though (but didn't find back the exact discussion about it in my mail achives) that there was some reason to do so. Note that, when VCL_USE_NATIVE_STL is set, all files vcl/emulation/*.cxx are effectively empty, so no code is generated. There is a comment # It is OK to compile these sources with native # STLs because they won't generate any code in the makefile on this; moreover, the emulation files are within an ifndef USE_NATIVE_STL in the makefile, which seems to have diappeared when switching to CMake. So we could indeed try to reset this conditional compile. Just one more remark: It would not work to just throw away the whole vcl/emulation directory since the following two files are needed under some conditions, even if VCL_USE_NATIVE_STL and VCL_USE_NATIVE_COMPLEX are set: vcl_ciso646.h vcl_limits.h -- Peter. |
From: William A. H. <bil...@ny...> - 2004-08-23 15:22:43
|
Here is the source of the problem. Some people go into Visual Studio and add .txx as a file type. This allows syntax highlighting and editing in c++ mode for .txx files. The problem is that .txx files are added to the project then it will try to compile them. Several of the .txx files for emulation are added, and they do not end up empty if VCL_USE_NATIVE_STL is not set. Since VCL_USE_NATIVE_STL is a CMake variable anyway, it would be easy to remove the emulation files from the CMakeLists.txt file with an IF(VCL_USE_NATIVE_STL). -Bill At 04:19 PM 8/21/2004, Peter Vanroose wrote: >>The CMakeLists.txt file in vcl seems to always compile >>the emulation directory. Things like vcl_alloc.cxx are always compiled. >>I thought this stuff was not used by all compilers? Should the >>build of emulation files be conditional on if they are actually going >>to be used? > >Yes, you're probably right. >I seem to remember though (but didn't find back the exact discussion about it in my mail achives) that there was some reason to do so. >Note that, when VCL_USE_NATIVE_STL is set, all files vcl/emulation/*.cxx >are effectively empty, so no code is generated. There is a comment > # It is OK to compile these sources with native > # STLs because they won't generate any code >in the makefile on this; moreover, the emulation files are within an > ifndef USE_NATIVE_STL in the makefile, which seems to have diappeared when switching to CMake. >So we could indeed try to reset this conditional compile. > >Just one more remark: >It would not work to just throw away the whole vcl/emulation directory >since the following two files are needed under some conditions, even if >VCL_USE_NATIVE_STL and VCL_USE_NATIVE_COMPLEX are set: >vcl_ciso646.h >vcl_limits.h > > >-- Peter. > > >------------------------------------------------------- >SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media >100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 >Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. >http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 >_______________________________________________ >Vxl-maintainers mailing list >Vxl...@li... >https://lists.sourceforge.net/lists/listinfo/vxl-maintainers |
From: Peter V. <Pet...@es...> - 2004-08-23 14:34:52
|
> The problem is that when .txx files are added to the project > then it will try to compile them. > Several of the .txx files for emulation are added, > and they do not end up empty if VCL_USE_NATIVE_STL is not set. Compiling .txx files is never a good idea :-) Wouldn't it be simpler and safer to make sure that CMake never places .txx files in the "Source Files" group but always in the "Header Files" group? > Since VCL_USE_NATIVE_STL is a CMake variable anyway, it would be easy to remove > the emulation files from the CMakeLists.txt file with an IF(VCL_USE_NATIVE_STL). Agreed (except for the two exceptions mentioned before). -- Peter; |
From: William A. H. <bil...@ny...> - 2004-08-23 15:18:40
|
Nice idea, but once you add .txx as a c++ source file the folder it is in does not matter, it will be compiled. I agree it is a bad thing to do, but I was a bit surprised to see the emulation stuff as part of the project. -Bill At 10:34 AM 8/23/2004, Peter Vanroose wrote: >>The problem is that when .txx files are added to the project >>then it will try to compile them. >>Several of the .txx files for emulation are added, >>and they do not end up empty if VCL_USE_NATIVE_STL is not set. > >Compiling .txx files is never a good idea :-) >Wouldn't it be simpler and safer to make sure that CMake never places .txx files in the "Source Files" group but always in the "Header Files" group? > >>Since VCL_USE_NATIVE_STL is a CMake variable anyway, it would be easy to remove >>the emulation files from the CMakeLists.txt file with an IF(VCL_USE_NATIVE_STL). > >Agreed (except for the two exceptions mentioned before). > > >-- Peter; |
From: Amitha P. <pe...@cs...> - 2004-08-23 15:31:39
|
On Mon 23 Aug 2004, William A. Hoffman wrote: > Nice idea, but once you add .txx as a c++ source file the folder it > is in does not matter, it will be compiled. This is going somewhat off the topic, but a .txx file is not compiled by default. (At least, it isn't with VC6 and VC7.) You have to explicitly make the compiler think that .txx are compilable. I think it may involve registry settings. > I agree it is a bad thing to do, but I was a bit surprised to see > the emulation stuff as part of the project. Given your statement, you are probably aware of all this, but I'll digress anyway... If you, or anyone else, has changed the compiler to treat .txx as a compilable file, you've probably done the wrong thing unless the compiler happens to support exported templates. To my knowledge, only the Comeau (sp?) compiler does this. Even then, your exported template implementation then should sit in a .cxx file. Besides, convention has .txx files containing the implementation of a template. It should not contain any code that causes the template to be instantiated. This is why is it okay to include your .txx file at the end of the corresponding .h file if you are going to use implicit instantiation. "Compiling" a .txx file should not cause any object code to be generated. Of course, it will cause symbols to be defined, and in the specific case of vcl, these symbols could conflict with the correct system symbols. So there, the correct solution is indeed to never "see" those files. Amitha. |