Re: [Boost-users] [filesystem] Apparent non-compliant code in current operations.hpp, ...

From: Beman Dawes (bdawes_at_[hidden])
Date: 2007-10-19 14:22:17

Marty Fried wrote:
> Back on Fri, 19 Oct 2007 11:37:11 +0200, in gmane.comp.lib.boost.user,Markus
> Schöpflin <markus.schoepflin_at_[hidden]> wrote:
> 
 > ...
 >
>> No worry, I just remembered that we have regression test runs for xlC on 
>> the trunk. See 
>> http://beta.boost.org/development/tests/trunk/developer/summary.html for 
>> details on the state of xlC. Looks like xlC has its problems with boost code.
> 
> I seems to me that something strange is going on; I'm not able to even
> compile the filesystem library without errors. It seems like the regression
> tests succeeded with the compile and link, if I'm reading it correctly.
> Could it be that the test is done with an older version of xlC, that may not
> have checked for this condidtion?  We are using version 8; version 9
> recently came out.

You can tell what version of a compiler is being used by looking at the 
config library's conf_info output. For the current regression results, 
it's reporting:

IBM Visual Age version 900
     _CHAR_UNSIGNED                          =1
     _CPPUNWIND                              =1
     __cplusplus                             =199711L
     __STDC__                                =0
     _WCHAR_T                                =1
     __CHAR_UNSIGNED__                       =1
     __EXCEPTIONS                            =1
     __powerpc__                             =1
     _WCHAR_T                                =1
     __IBMCPP__                              =900

> I want to go back to aix and try the exact command line listed for the vacpp
> test output, to see what result I get.  I'll report back.

Another aspect is that our tests are running on the code as it currently 
stands, not on the 1.34.1 code.

>> Hmm, cxx has this to say:
>>
>> cxx: Error: foo.cxx, line 6: Cannot create variable "f" of incomplete type
>>           "foo<int>".
>>           detected during instantiation of
>>                     "void templatefunc<T>() [with T=int]" at line 11
>>    foo<int> f;
>> ------------^
>>
>> Now I'm left wondering why the tests on Tru64 don't show this error. Just 
>> to be sure, do you get the error while compiling the filesystem lib itself 
>> or while using the compiled filesystem lib?
>>
>> If you get the error during compilation of the library, are you sure that 
>> above code is a valid reproducer for the original problem? (I'm not 
>> implying that it isn't, I just want to make sure it is.)
> 
> I believe the test case is valid, but there is one difference that may
> matter here...  the test case has one less level of indirection than the
> actual code.  We didn't think it made a difference, and we wanted to
> simplify as much as possible; the test showed that the error is caught by
> xlC and Comeau, but not by gcc or msvc.  However, it could be that one more
> level of indirection is needed to hide the error from Tru64, too.  In other
> words, maybe Tru64 is better than gcc and MSVC at finding this test case
> error, but not as good as xlC/Comeau with one more level of indirection to
> mask it.  Would you like me to modify the test case?
> 
> I appreciate your looking into this - I was worried you might dismiss it as
> a problem with an unsupported compiler - not that I think it really is that
> simple. Assuming it's really an error, it will probably eventually become a
> problem with a supported compiler.

If the code isn't standard compliant, I'd like to fix it. But it looks 
like version 9 of vacpp is accepting it, or possible the code has 
changed enough that the problem no longer exists.

> Please let me know what I can do next to help out.

If you get some sample code that you think exactly reproduces the 
problem, and Comeau reports an error, please send it to me.

Thanks,

--Beman