[jira] Commented: (STDCXX-562) [Intel C++ 9.1/SuSE Linux/AMD64, shared] SIGSEGV in tests
[ https://issues.apache.org/jira/browse/STDCXX-562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12528359 ] Farid Zaripov commented on STDCXX-562: -- I have no access to this platform, but trying to check the 64-bit build with intel c++ 9.1 / Windows. [Intel C++ 9.1/SuSE Linux/AMD64, shared] SIGSEGV in tests - Key: STDCXX-562 URL: https://issues.apache.org/jira/browse/STDCXX-562 Project: C++ Standard Library Issue Type: Bug Components: Tests Affects Versions: trunk Environment: Intel C++ 9.1/SuSE Linux/AMD64, shared builds only Reporter: Martin Sebor Attachments: linux_suse-9.1-amd64-icc-9.1-12D-575978-log.gz.txt Many string and container tests, as well as some iostream are failing when compiled with Intel C++ 9.1 on SuSE Linux/AMD64. Examples don't seem to be affected. Could the problem be in the driver, or related to exceptions? Or TLS? Builds with Intel C++ 10.0 look good. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
RE: Intel C++/Windows XP build failures
-Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor Sent: Tuesday, September 18, 2007 8:33 AM To: stdcxx-dev@incubator.apache.org Subject: Intel C++/Windows XP build failures Unfortunately, we continue to be having problems in Intel C++ (both 9.1 and 10.0) builds on Windows XP. It might be important that the failures are isolated to the servers xp64build (XP/EM64T Service Pack 1) and stein (XP/X86 Service Pack 2). The servers xp64build2 (also XP/EM64T Service Pack 1), box or mug (also XP/X86 Service Pack 2), don't seem to exhibit the problem in the latest builds. Farid, please let us know where you stand on this, if you've made any progress since the last time we discussed it and what we can do to help. For reference, AFAIK, the last update on this is here: http://www.nabble.com/Windows-build-failures-tf4379160.html#a12638734 I still can't reproduce the problem and I think that problem somewhere in installation of the icc. Yesterday I've added some additional logging to get some more details when problem is happened: http://svn.apache.org/viewvc?rev=576498view=rev Travis, can you please try to determine the difference between the good and the bad servers to see if we're missing patches or what else could be causing the failures? If there is a problem with the environment (incorrectly set up compilers, etc.), please let Andrew know so he can start working on getting it corrected. I suggest to try re-intergare ICC into VisualStudio by invoking C:\Program Files (x86)\Intel\Compiler\VS Integration\C++\VS2005\integrate.bat C:\Program Files (x86)\Microsoft Visual Studio 8 Farid.
[jira] Commented: (STDCXX-440) 23_allocator test case can consume all system memory
[ https://issues.apache.org/jira/browse/STDCXX-440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12528441 ] Andrew Black commented on STDCXX-440: - I'm not certain I agree with your conclusion about a misbehavior in the limit_process logic Martin. The flow control operator used in limit_process is a 'continue', not a 'break'. Unless I'm seriously mistaken, this essentially skips over the remainder of the for loop, sending the flow back to the start of the loop and incrementing the counter. 23_allocator test case can consume all system memory Key: STDCXX-440 URL: https://issues.apache.org/jira/browse/STDCXX-440 Project: C++ Standard Library Issue Type: Bug Components: Tests Affects Versions: 4.2 Environment: RHAP 5 (possibly others) Reporter: Eric Lemings Assignee: Andrew Black Priority: Critical Fix For: 4.2 Attachments: sample-top.txt The 22_allocator test case has been observed to consume all primary and virtual memory bringing the unfortunate system to its knees. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (STDCXX-440) 23_allocator test case can consume all system memory
Andrew, I'm not asking for your off the cuff critique of my admittedly fuzzy analysis. I said I wasn't sure I completely understood the problem, so I can certainly be wrong. What I am asking for is an hour of your time to actually debug the problem and fix whatever is causing the test to exhaust all 4GB of memory on the system despite the 1GB limit we impose on it. Martin Andrew Black (JIRA) wrote: [ https://issues.apache.org/jira/browse/STDCXX-440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12528441 ] Andrew Black commented on STDCXX-440: - I'm not certain I agree with your conclusion about a misbehavior in the limit_process logic Martin. The flow control operator used in limit_process is a 'continue', not a 'break'. Unless I'm seriously mistaken, this essentially skips over the remainder of the for loop, sending the flow back to the start of the loop and incrementing the counter. 23_allocator test case can consume all system memory Key: STDCXX-440 URL: https://issues.apache.org/jira/browse/STDCXX-440 Project: C++ Standard Library Issue Type: Bug Components: Tests Affects Versions: 4.2 Environment: RHAP 5 (possibly others) Reporter: Eric Lemings Assignee: Andrew Black Priority: Critical Fix For: 4.2 Attachments: sample-top.txt The 22_allocator test case has been observed to consume all primary and virtual memory bringing the unfortunate system to its knees.
Re: [MSVC 9.0] 'Unknown' enumerator conflict
Farid Zaripov wrote:
The 27.istream.unformatted.get.cpp and 27.istream.fmat.arith.cpp tests
are failed to compile
on MSVC 9.0 due to enum member name conflict:
[...]
We need to rename it to something. I can't invent the suitable name,
unless adding the unredscores :)
BTW it seems that this member is not used for now. Maybe we should
just remove it?
If it's not used for anything I say get rid of it :)
Another option, at least until we have strongly typed enums in
the language (see N2347:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2347.pdf)
would be to make MemFun a struct around the enums:
struct MemFun {
enum {
...
Throw = 0x1000,
Failure = 0x2000,
Unknown = 0x4000
};
};
Martin
Re: svn commit: r577002 - /incubator/stdcxx/trunk/tests/utilities/20.temp.buffer.cpp
[EMAIL PROTECTED] wrote: Author: faridz Date: Tue Sep 18 11:01:47 2007 New Revision: 577002 URL: http://svn.apache.org/viewvc?rev=577002view=rev Log: 2007-09-18 Farid Zaripov [EMAIL PROTECTED] * 20.temp.buffer.cpp (run_test): Use _RWSTD_LONG_MAX instead of _RWSTD_PTRDIFF_MAX because BigStruct parametrized by unsigned long type and sizeof (_RWSTD_PTRDIFF_T) can be greater that sizeof (unsigned long). Shouldn't that be the other way around? I mean, wouldn't a more robust solution be to parametrize BigStruct on ptrdiff_t so that it can be instantiated with the largest possible value even on LLP64 like Windows? Martin Modified: incubator/stdcxx/trunk/tests/utilities/20.temp.buffer.cpp Modified: incubator/stdcxx/trunk/tests/utilities/20.temp.buffer.cpp URL: http://svn.apache.org/viewvc/incubator/stdcxx/trunk/tests/utilities/20.temp.buffer.cpp?rev=577002r1=577001r2=577002view=diff == --- incubator/stdcxx/trunk/tests/utilities/20.temp.buffer.cpp (original) +++ incubator/stdcxx/trunk/tests/utilities/20.temp.buffer.cpp Tue Sep 18 11:01:47 2007 @@ -443,9 +443,9 @@ // avoid instantiating test on very large structs // to prevent failures (at compile or run-time) due // to compiler bugs -test_failure ((BigStruct_RWSTD_PTRDIFF_MAX / 2*)0, 0); -test_failure ((BigStruct_RWSTD_PTRDIFF_MAX - 1*)0, 0); -test_failure ((BigStruct_RWSTD_PTRDIFF_MAX*)0, 0); +test_failure ((BigStruct_RWSTD_LONG_MAX / 2*)0, 0); +test_failure ((BigStruct_RWSTD_LONG_MAX - 1*)0, 0); +test_failure ((BigStruct_RWSTD_LONG_MAX*)0, 0); #else
[MSVC 9.0] 'Unknown' enumerator conflict
The 27.istream.unformatted.get.cpp and 27.istream.fmat.arith.cpp tests
are failed to compile
on MSVC 9.0 due to enum member name conflict:
tests\include\rw_streambuf.h(58) : error C2365: 'Unknown' :
redefinition; previous definition was 'enumerator'
C:\Program Files\Microsoft
SDKs\Windows\v6.0A\include\winioctl.h(1635) : see declaration of
'Unknown'
rw_streambuf.h:
-
enum MemFun {
// bitmask with a bit for each virtual member function
[...]
// bit OR-ed with MemFun bits
Throw = 0x1000,
Failure = 0x2000,
Unknown = 0x4000
};
-
winioctl.h:
-
typedef enum _MEDIA_TYPE {
Unknown,// Format is unknown
F5_1Pt2_512,// 5.25, 1.2MB, 512 bytes/sector
F3_1Pt44_512, // 3.5, 1.44MB, 512 bytes/sector
F3_2Pt88_512, // 3.5, 2.88MB, 512 bytes/sector
-
We need to rename it to something. I can't invent the suitable name,
unless adding the unredscores :)
BTW it seems that this member is not used for now. Maybe we should
just remove it?
Farid.
RE: svn commit: r577002 - /incubator/stdcxx/trunk/tests/utilities/20.temp.buffer.cpp
-Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 18, 2007 9:53 PM To: stdcxx-dev@incubator.apache.org Subject: Re: svn commit: r577002 - /incubator/stdcxx/trunk/tests/utilities/20.temp.buffer.cpp * 20.temp.buffer.cpp (run_test): Use _RWSTD_LONG_MAX instead of _RWSTD_PTRDIFF_MAX because BigStruct parametrized by unsigned long type and sizeof (_RWSTD_PTRDIFF_T) can be greater that sizeof (unsigned long). Shouldn't that be the other way around? I mean, wouldn't a more robust solution be to parametrize BigStruct on ptrdiff_t so that it can be instantiated with the largest possible value even on LLP64 like Windows? Are there any LLP64 platforms except Windows? Because on Windows the maximum size of the array is 0x7fff bytes. The following line of code: char buf [0x8000]; inducts the error on MSVC (32 bit and 64 bit): error C2148: total size of array must not exceed 0x7fff bytes on ICC 9.1 (32 bit and 64 bit), 10.0 (32 bit and 64 bit): error: array is too large char buf [0x8000]; ^ Farid.
RE: svn commit: r577000 - in /incubator/stdcxx/trunk: include/loc/_messages.h src/messages.cpp
-Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 18, 2007 10:24 PM To: stdcxx-dev@incubator.apache.org Subject: Re: svn commit: r577000 - in /incubator/stdcxx/trunk: include/loc/_messages.h src/messages.cpp [EMAIL PROTECTED] wrote: Author: faridz Date: Tue Sep 18 10:56:44 2007 New Revision: 577000 I'm curious about this change... I thought dllexport was only necessary with symbols (functions or objects) that could be referenced from user code (either directly, or indirectly via our own inline functions), and that references to our own symbols from with the stdcxx library itself, even from other translation units, didn't need the decoration. In this case, I note that __rw_cat_open() is being called from a function that's declared inline (messages::do_open() in the primary template), so at the first glance the change makes sense. But then I also note that we're explicitly instantiating the primary template on char and wchar_t (no other specializations are allowed), which should prevent the do_open() member function from being implicitly instantiated in code that uses it, and that the dllexport shouldn't be necessary. So, does this mean that I'm missing something or that something isn't working quite the way it should? Could it be that MSVC is actually inlining the virtual do_open()? (Most other compilers don't inline virtual function so I would tend to define it out of line to save the little bit of space and avoid code for it from being emitted in every object file that calls it). Without that patch the 22.locale.stdcxx-554.cpp regression test failed to link on ICC, but succeeded on MSVC. http://people.apache.org/~sebor/stdcxx/results/win_2003-1-em64t-icl-10.0 -12D-win32-576688-log.gz.txt http://people.apache.org/~sebor/stdcxx/results/win_2003-1-em64t-icl-10.0 -12d-win32-576688-log.gz.txt http://people.apache.org/~sebor/stdcxx/results/win_2003-1-x86-icl-9.1-12 d-win32-576688-log.gz.txt 22.locale.stdcxx-554.cpp Linking... (Intel C++ Environment) xilink: executing 'link' 22.locale.stdcxx-554.obj : error LNK2019: unresolved external symbol int __cdecl __rw::__rw_cat_open(class std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar const ,struct std::locale const ) ([EMAIL PROTECTED]@@[EMAIL PROTECTED]@[EMAIL PROTECTED]@@V?$all [EMAIL PROTECTED]@2@@std@@[EMAIL PROTECTED]@@Z) referenced in function protected: virtual int __thiscall std::messageschar::do_open(class std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar const ,struct std::locale const )const ([EMAIL PROTECTED]@[EMAIL PROTECTED]@@[EMAIL PROTECTED]@[EMAIL PROTECTED]@ @[EMAIL PROTECTED]@2@@[EMAIL PROTECTED]@2@@Z) 22.locale.stdcxx-554.obj : error LNK2019: unresolved external symbol void __cdecl __rw::__rw_cat_close(int) ([EMAIL PROTECTED]@@[EMAIL PROTECTED]) referenced in function protected: virtual void __thiscall std::messageschar::do_close(int)const ([EMAIL PROTECTED]@[EMAIL PROTECTED]@@[EMAIL PROTECTED]) $(BUILDDIR)\12d\tests\22.locale.stdcxx-554.exe : fatal error LNK1120: 2 unresolved externals I'm surprised, that ICC does that because that functions (messages::open() and messages::close()) are not invoked in that test, but ICC put them into .obj file even in optimized mode (12d). Farid.
Re: svn commit: r577002 - /incubator/stdcxx/trunk/tests/utilities/20.temp.buffer.cpp
Farid Zaripov wrote: -Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 18, 2007 9:53 PM To: stdcxx-dev@incubator.apache.org Subject: Re: svn commit: r577002 - /incubator/stdcxx/trunk/tests/utilities/20.temp.buffer.cpp * 20.temp.buffer.cpp (run_test): Use _RWSTD_LONG_MAX instead of _RWSTD_PTRDIFF_MAX because BigStruct parametrized by unsigned long type and sizeof (_RWSTD_PTRDIFF_T) can be greater that sizeof (unsigned long). Shouldn't that be the other way around? I mean, wouldn't a more robust solution be to parametrize BigStruct on ptrdiff_t so that it can be instantiated with the largest possible value even on LLP64 like Windows? Are there any LLP64 platforms except Windows? I don't know of any other platforms with this silly model, but that doesn't mean there isn't one. Because on Windows the maximum size of the array is 0x7fff bytes. AFAICT, they're within their right to impose a limit. The C++ standard says the maximum size of an object that a conforming implementation is required to support is 262,144. We need to avoid exceeding the limit (which doesn't necessarily mean that we need to use unsigned long, just that we shouldn't be trying to create bigger objects than what the implementation allows). It's your call but if I were to decide, I would change BigStruct to take ptrdiff_t, or better yet, size_t as a parameter, and instantiate it on a INT_MAX just for Windows, and leave it the way it was everywhere else. Martin The following line of code: char buf [0x8000]; inducts the error on MSVC (32 bit and 64 bit): error C2148: total size of array must not exceed 0x7fff bytes on ICC 9.1 (32 bit and 64 bit), 10.0 (32 bit and 64 bit): error: array is too large char buf [0x8000]; ^ Farid.
RE: Intel C++/Windows XP build failures
Farid Zaripov wrote: Travis, can you please try to determine the difference between the good and the bad servers to see if we're missing patches or what else could be causing the failures? If there is a problem with the environment (incorrectly set up compilers, etc.), please let Andrew know so he can start working on getting it corrected. I suggest to try re-intergare ICC into VisualStudio by invoking C:\Program Files (x86)\Intel\Compiler\VS Integration\C++\VS2005\integrate.bat C:\Program Files (x86)\Microsoft Visual Studio 8 Farid. I looked at the versions, and everything matched up as expected. As a test I tried to open the Visual Studio on 'stein'. I got an error message... [Intel(R) Vtune(TM) Performance Analyzer]--[X] || | One or more components did not load correctly. | | You may need to reinstall the product. | || ++ I do not get this error message on the machines that are known to work work [box, mug]. I went ahead and ran the integration script as suggested by Farid above, and after running it I had no problems running Visual Studio. I'm pretty sure that this is going to fix the problems. Travis
Re: svn commit: r577000 - in /incubator/stdcxx/trunk: include/loc/_messages.h src/messages.cpp
Farid Zaripov wrote: -Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 18, 2007 10:24 PM To: stdcxx-dev@incubator.apache.org Subject: Re: svn commit: r577000 - in /incubator/stdcxx/trunk: include/loc/_messages.h src/messages.cpp [EMAIL PROTECTED] wrote: Author: faridz Date: Tue Sep 18 10:56:44 2007 New Revision: 577000 I'm curious about this change... [...] Without that patch the 22.locale.stdcxx-554.cpp regression test failed to link on ICC, but succeeded on MSVC. [...] I'm surprised, that ICC does that because that functions (messages::open() and messages::close()) are not invoked in that test, but ICC put them into .obj file even in optimized mode (12d). How about this: I'd like us to outline the functions regardless of these errors because I believe it's an improvement (I've done it for most other facets and classes in the library so we have a good precedent :) I've outlined them here: http://svn.apache.org/viewvc?rev=577098view=rev Could you try, as an experiment, to revert the dllexport change to see if the linker errors go away? The reason for doing that is that the fewer symbols we export from the library the less of an ABI footprint we have to worry about maintaining, and the easier it will be to maintain and test binary compatibility. Martin
[jira] Commented: (STDCXX-275) [HP aCC 3.70] ICE on ctor initializer while generating dependencies with +Maked -E
[
https://issues.apache.org/jira/browse/STDCXX-275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12528611
]
Martin Sebor commented on STDCXX-275:
-
Grrr. aCC 3.74 spits out the option with the complaint below (and then asserts
on the code):
$ cat t.cpp aCC -hpxstd98 +Maked -E -V t.cpp
struct S
{
S (): a (b c ? 0 : new T [d]) { }
} ;
aCC: warning 901: unknown option: `-hpxstd98': use +help for online
documentation.
aCC: HP ANSI C++ B3910B A.03.74
Signal 11
...
[HP aCC 3.70] ICE on ctor initializer while generating dependencies with
+Maked -E
--
Key: STDCXX-275
URL: https://issues.apache.org/jira/browse/STDCXX-275
Project: C++ Standard Library
Issue Type: Bug
Components: External
Affects Versions: 4.1.3
Environment: HP aCC 3.70
Reporter: Martin Sebor
Assignee: Martin Sebor
Priority: Critical
Fix For: 4.2
$ cat t.cpp aCC +Maked -E -V t.cpp
struct S
{
S (): a (b c ? 0 : new T [d]) { }
};
aCC: HP ANSI C++ B3910B A.03.70
Signal 11
( 0) 0x00297f64 sighandler__FiT1 + 0x134
[/amd/packages/mdx/hpux/compilers/hp/aCC370_11.23/opt/aCC/lbin/ctcom.pa20]
( 1) 0xc0213308 _sigreturn [/usr/lib/libc.2]
( 2) 0x0025d900 synthesize__15LibraryRoutinesF19LibraryRoutinesEnum +
0x7c
[/amd/packages/mdx/hpux/compilers/hp/aCC370_11.23/opt/aCC/lbin/ctcom.pa20]
( 3) 0x000c1bac enter__15LibraryRoutinesF19LibraryRoutinesEnum + 0x10
[/amd/packages/mdx/hpux/compilers/hp/aCC370_11.23/opt/aCC/lbin/ctcom.pa20]
( 4) 0x001864d0
lookup__3MapF11StringTokenP11DeclarationRbQ2_3Map10LookupKindRC11DynamicListXTP4
+ 0x168
[/amd/packages/mdx/hpux/compilers/hp/aCC370_11.23/opt/aCC/lbin/ctcom.pa20]
( 5) 0x001865dc
find__3MapF11StringTokenP11DeclarationRbQ2_3Map10LookupKindRC11DynamicListXTP4No
+ 0x9c
[/amd/packages/mdx/hpux/compilers/hp/aCC370_11.23/opt/aCC/lbin/ctcom.pa20]
( 6) 0x0019cf38
hasPointerToMemberComing__12PreprocessorFQ2_12Preprocessor8PTMStateP11Declaratio
+ 0x844
[/amd/packages/mdx/hpux/compilers/hp/aCC370_11.23/opt/aCC/lbin/ctcom.pa20]
( 7) 0x002088b4 isProbablyAnIdentifier__12PreprocessorFb + 0x54
[/amd/packages/mdx/hpux/compilers/hp/aCC370_11.23/opt/aCC/lbin/ctcom.pa20]
( 8) 0x001883fc
resolveIdentifier__12PreprocessorFP12ScannerValue11StringToken + 0xbd4
[/amd/packages/mdx/hpux/compilers/hp/aCC370_11.23/opt/aCC/lbin/ctcom.pa20]
( 9) 0x001896f4 nextToken__12PreprocessorFP12ScannerValue + 0x210
[/amd/packages/mdx/hpux/compilers/hp/aCC370_11.23/opt/aCC/lbin/ctcom.pa20]
(10) 0x000c6ea8 DoCompile__8CompilerFv + 0xd44
[/amd/packages/mdx/hpux/compilers/hp/aCC370_11.23/opt/aCC/lbin/ctcom.pa20]
(11) 0x00280d00 DoCompile__8CompilerFP6Buffer + 0x34
[/amd/packages/mdx/hpux/compilers/hp/aCC370_11.23/opt/aCC/lbin/ctcom.pa20]
(12) 0x002747c8 DoCompileFile__8CompilerFPc + 0x110
[/amd/packages/mdx/hpux/compilers/hp/aCC370_11.23/opt/aCC/lbin/ctcom.pa20]
(13) 0x0026cc8c main + 0x404
[/amd/packages/mdx/hpux/compilers/hp/aCC370_11.23/opt/aCC/lbin/ctcom.pa20]
(14) 0xc01459a8 _start + 0xc0 [/usr/lib/libc.2]
(15) 0x001989d0 $START$ + 0x178
[/amd/packages/mdx/hpux/compilers/hp/aCC370_11.23/opt/aCC/lbin/ctcom.pa20]
Error (system problem) 689: # Compiler received signal 11
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-559) add ASL headers to all documentation files
[ https://issues.apache.org/jira/browse/STDCXX-559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Travis Vitek updated STDCXX-559: Attachment: stdlibref.patch changelog for stdlibref.patch 20070-09-18 Travis Vitek [EMAIL PROTECTED] STDCXX-559 --distance-type.html: Add ASL header --iterator-category.html: Same. 1-1.html: Same. 1-2.html: Same. 1-3.html: Same. 1.html: Same. 2-1.html: Same. 2-10.html: Same. 2-11.html: Same. 2-2.html: Same. 2-3.html: Same. 2-4.html: Same. 2-5.html: Same. 2-6.html: Same. 2-7.html: Same. 2-8.html: Same. 2-9.html: Same. 2.html: Same. A-1.html: Same. A-2.html: Same. A-3.html: Same. A.html: Same. accumulate.html: Same. acknow.html: Same. adjacent-difference.html: Same. adjacent-find.html: Same. advance.html: Same. algorithm-h.html: Same. algorithms.html: Same. allocator.html: Same. associativecontainers.html: Same. auto-ptr.html: Same. B.html: Same. back-insert-iterator.html: Same. bad-alloc.html: Same. bad-cast.html: Same. bad-exception.html: Same. bad-typeid.html: Same. basic-filebuf.html: Same. basic-fstream.html: Same. basic-ifstream.html: Same. basic-ios.html: Same. basic-iostream.html: Same. basic-istream.html: Same. basic-istringstream.html: Same. basic-ofstream.html: Same. basic-ostream.html: Same. basic-ostringstream.html: Same. basic-streambuf.html: Same. basic-string.html: Same. basic-stringbuf.html: Same. basic-stringstream.html: Same. bidirectionaliterators.html: Same. binary-function.html: Same. binary-negate.html: Same. binary-search.html: Same. bind1st.html: Same. bitmasktypes.html: Same. bitset.html: Same. booktoc.html: Same. cerr.html: Same. char-traits.html: Same. cin.html: Same. clog.html: Same. codecvt-byname.html: Same. codecvt.html: Same. collate.html: Same. compare.html: Same. complex-h.html: Same. complex.html: Same. contact.html: Same. containers.html: Same. copy.html: Same. copyright.html: Same. count.html: Same. cout.html: Same. ctype-byname.html: Same. ctype.html: Same. deque-h.html: Same. deque.html: Same. distance.html: Same. divides.html: Same. domain-error.html: Same. equal-range.html: Same. equal-to.html: Same. equal.html: Same. exception-h.html: Same. exception.html: Same. exceptions.html: Same. facets.html: Same. fill.html: Same. find-end.html: Same. find-first-of.html: Same. find-if.html: Same. find.html: Same. for-each.html: Same. forwarditerators.html: Same. fpos.html: Same. frames-banner.html: Same. frames-classes-alpha.html: Same. frames-classes-func.html: Same. frames-displayarea.html: Same. frames-intro-contents.html: Same. frames-intro-text.html: Same. frames-tindex-contents.html: Same. frames-tindex.html: Same. front-insert-iterator.html: Same. fstream-h.html: Same. functional-h.html: Same. functionobjects.html: Same. functoc.html: Same. generate.html: Same. get-temporary-buffer.html: Same. greater-equal.html: Same. greater.html: Same. gslice-array.html: Same. gslice.html: Same. has-facet.html: Same. heapoperations.html: Same. I.html: Same. II.html: Same. III.html: Same. includes.html: Same. index.html: Same. indirect-array.html: Same. inner-product.html: Same. inplace-merge.html: Same. inputiterators.html: Same. insert-iterator.html: Same. insertiterators.html: Same. invalid-argument.html: Same. iomanip-h.html: Same. ios-base--failure.html: Same. ios-base.html: Same. ios-h.html: Same. iosfwd-h.html: Same. iostream-h.html: Same. isalnum.html: Same. isalpha.html: Same. iscntrl.html: Same. isdigit.html: Same. isgraph.html: Same. islower.html: Same. isprint.html: Same. ispunct.html: Same. isspace.html: Same. istream-h.html: Same. istream-iterator.html: Same. istreambuf-iterator.html: Same. istrstream.html: Same. isupper.html: Same. isxdigit.html: Same.
[jira] Assigned: (STDCXX-561) add ASL headers to all etc/nls files
[ https://issues.apache.org/jira/browse/STDCXX-561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Travis Vitek reassigned STDCXX-561: --- Assignee: Travis Vitek add ASL headers to all etc/nls files Key: STDCXX-561 URL: https://issues.apache.org/jira/browse/STDCXX-561 Project: C++ Standard Library Issue Type: Sub-task Components: Release Affects Versions: trunk Reporter: Martin Sebor Assignee: Travis Vitek Priority: Blocker Fix For: 4.2 According to the ASF Source Header and Copyright Notice Policy (http://www.apache.org/legal/src-headers.html), all human-readable Apache-developed files that are included within a distribution must include ASL header text. None of our character set description files or locale definition files (the files under etc/nls/) currently does. These headers need to be added in time for the 4.2.0 release. Since the above mentioned policy applies to releases distributed after November 1, 2006, this task affects trunk only (and not any already published releases or snapshots). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-559) add ASL headers to all documentation files
[ https://issues.apache.org/jira/browse/STDCXX-559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Travis Vitek updated STDCXX-559: Attachment: stdlibug.patch changelog for the stdlibug.patch 20070-09-18 Travis Vitek [EMAIL PROTECTED] STDCXX-559 1-1.html: Add ASL header. 1-2.html: Same. 1-3.html: Same. 1-4.html: Same. 1-5.html: Same. 1-6.html: Same. 1-7.html: Same. 1.html: Same. 10-1.html: Same. 10-2.html: Same. 10-3.html: Same. 10.html: Same. 11-1.html: Same. 11-2.html: Same. 11-3.html: Same. 11.html: Same. 12-1.html: Same. 12-2.html: Same. 12-3.html: Same. 12.html: Same. 13-1.html: Same. 13-2.html: Same. 13-3.html: Same. 13-4.html: Same. 13-5.html: Same. 13-6.html: Same. 13-7.html: Same. 13-8.html: Same. 13.html: Same. 14-1.html: Same. 14-2.html: Same. 14-3.html: Same. 14-4.html: Same. 14-5.html: Same. 14-6.html: Same. 14-7.html: Same. 14.html: Same. 15-1.html: Same. 15-2.html: Same. 15-3.html: Same. 15.html: Same. 16-1.html: Same. 16-2.html: Same. 16-3.html: Same. 16-4.html: Same. 16.html: Same. 17-1.html: Same. 17-2.html: Same. 17.html: Same. 18-1.html: Same. 18-2.html: Same. 18-3.html: Same. 18-4.html: Same. 18.html: Same. 19-1.html: Same. 19-2.html: Same. 19.html: Same. 2-1.html: Same. 2-2.html: Same. 2-3.html: Same. 2-4.html: Same. 2-5.html: Same. 2.html: Same. 20-1.html: Same. 20-2.html: Same. 20-3.html: Same. 20.html: Same. 21-1.html: Same. 21-2.html: Same. 21-3.html: Same. 21.html: Same. 22-1.html: Same. 22-2.html: Same. 22-3.html: Same. 22-4.html: Same. 22-5.html: Same. 22-6.html: Same. 22-7.html: Same. 22.html: Same. 23-1.html: Same. 23-2.html: Same. 23-3.html: Same. 23-4.html: Same. 23.html: Same. 24-1.html: Same. 24-2.html: Same. 24-3.html: Same. 24-4.html: Same. 24.html: Same. 25-1.html: Same. 25-2.html: Same. 25-3.html: Same. 25-4.html: Same. 25-5.html: Same. 25-6.html: Same. 25.html: Same. 26-1.html: Same. 26-2.html: Same. 26-3.html: Same. 26-4.html: Same. 26-5.html: Same. 26-6.html: Same. 26-7.html: Same. 26-8.html: Same. 26-9.html: Same. 26.html: Same. 27-1.html: Same. 27-2.html: Same. 27-3.html: Same. 27-4.html: Same. 27.html: Same. 28-1.html: Same. 28-2.html: Same. 28-3.html: Same. 28-4.html: Same. 28-5.html: Same. 28.html: Same. 29-1.html: Same. 29-2.html: Same. 29-3.html: Same. 29.html: Same. 3-1.html: Same. 3-2.html: Same. 3-3.html: Same. 3-4.html: Same. 3-5.html: Same. 3.html: Same. 30-1.html: Same. 30-2.html: Same. 30-3.html: Same. 30-4.html: Same. 30-5.html: Same. 30.html: Same. 31-1.html: Same. 31-2.html: Same. 31-3.html: Same. 31.html: Same. 32-1.html: Same. 32-2.html: Same. 32-3.html: Same. 32-4.html: Same. 32-5.html: Same. 32-6.html: Same. 32.html: Same. 33-1.html: Same. 33-2.html: Same. 33-3.html: Same. 33.html: Same. 34-1.html: Same. 34-2.html: Same. 34-3.html: Same. 34-4.html: Same. 34.html: Same. 35-1.html: Same. 35-2.html: Same. 35-3.html: Same. 35-4.html: Same. 35-5.html: Same. 35-6.html: Same. 35.html: Same. 36-1.html: Same. 36-2.html: Same. 36-3.html: Same. 36-4.html: Same. 36.html: Same. 37-1.html: Same. 37-2.html: Same. 37.html: Same. 38-1.html: Same. 38-2.html: Same. 38-3.html: Same. 38-4.html: Same. 38-5.html: Same. 38.html: Same. 39-1.html: Same. 39-2.html: Same. 39-3.html: Same. 39.html: Same. 4-1.html: Same. 4-2.html: Same. 4-3.html: Same. 4-4.html: Same. 4.html: Same. 40-1.html: Same. 40-2.html: Same. 40-3.html: Same. 40-4.html: Same. 40-5.html: Same. 40.html: Same. 41-1.html: Same.
[jira] Commented: (STDCXX-559) add ASL headers to all documentation files
[ https://issues.apache.org/jira/browse/STDCXX-559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12528650 ] Martin Sebor commented on STDCXX-559: - Thanks a lot! The two big patches applied cleanly (after I converted them to a sane format w/o CR/LF newlines ;-) but for some strange reason common.patch gave me trouble (see below). It seemed simple enough to make the changes by hand so I did -- you might want to double-check them just to be sure. patching file index.html patching file rw.css Hunk #1 FAILED at 1. 1 out of 1 hunk FAILED -- saving rejects to file rw.css.rej patching file rwbanner.css Hunk #1 FAILED at 1. 1 out of 1 hunk FAILED -- saving rejects to file rwbanner.css.rej add ASL headers to all documentation files -- Key: STDCXX-559 URL: https://issues.apache.org/jira/browse/STDCXX-559 Project: C++ Standard Library Issue Type: Sub-task Components: Release Affects Versions: trunk Reporter: Martin Sebor Assignee: Travis Vitek Priority: Blocker Fix For: 4.2 Attachments: common.patch, stdlibref.patch, stdlibug.patch According to the ASF Source Header and Copyright Notice Policy (http://www.apache.org/legal/src-headers.html), every documentation file needs to contain a comment with the ASL header in it. None of ours currently does. They comments need to be added for the 4.2.0 release. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r577142 [1/6] - /incubator/stdcxx/trunk/doc/stdlibref/
[EMAIL PROTECTED] wrote: Author: sebor Date: Tue Sep 18 21:15:03 2007 New Revision: 577142 URL: http://svn.apache.org/viewvc?rev=577142view=rev Log: 20070-09-18 Travis Vitek [EMAIL PROTECTED] STDCXX-559 * --distance-type.html: Add ASL header * --iterator-category.html: Same. Boy, these are really unfortunate file names. We should rename them to lose the leading dashes. Anyone know of any reason why we might not want to do that? Martin
[jira] Resolved: (STDCXX-559) add ASL headers to all documentation files
[ https://issues.apache.org/jira/browse/STDCXX-559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Sebor resolved STDCXX-559. - Resolution: Fixed Resolved. Will close after the next RAT report confirms that the we haven't skipped any files. add ASL headers to all documentation files -- Key: STDCXX-559 URL: https://issues.apache.org/jira/browse/STDCXX-559 Project: C++ Standard Library Issue Type: Sub-task Components: Release Affects Versions: trunk Reporter: Martin Sebor Assignee: Travis Vitek Priority: Blocker Fix For: 4.2 Attachments: common.patch, stdlibref.patch, stdlibug.patch According to the ASF Source Header and Copyright Notice Policy (http://www.apache.org/legal/src-headers.html), every documentation file needs to contain a comment with the ASL header in it. None of ours currently does. They comments need to be added for the 4.2.0 release. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-457) update license statement
[ https://issues.apache.org/jira/browse/STDCXX-457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Sebor updated STDCXX-457: Component/s: Release Set Component to Release [Engineering]. update license statement Key: STDCXX-457 URL: https://issues.apache.org/jira/browse/STDCXX-457 Project: C++ Standard Library Issue Type: Task Components: Release Affects Versions: 4.1.2, 4.1.3 Reporter: Martin Sebor Assignee: Martin Sebor Priority: Critical Fix For: 4.2 From the stdcxx status page: Check and make sure that the files that have been donated have been updated to reflect the new ASF copyright. See also: http://www.mail-archive.com/[EMAIL PROTECTED]/msg14483.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
do we still need rwstderr.rc?
Hi Farid, Now that we have our own gencat utility do we still need rwstderr.rc? http://svn.apache.org/repos/asf/incubator/stdcxx/trunk/src/rwstderr.rc Martin
[jira] Closed: (STDCXX-457) update license statement
[ https://issues.apache.org/jira/browse/STDCXX-457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Sebor closed STDCXX-457. --- Resolution: Fixed This is resolved for headers and sources. The rest is subsumed by STDCXX-552. update license statement Key: STDCXX-457 URL: https://issues.apache.org/jira/browse/STDCXX-457 Project: C++ Standard Library Issue Type: Task Components: Release Affects Versions: 4.1.2, 4.1.3 Reporter: Martin Sebor Assignee: Martin Sebor Priority: Critical Fix For: 4.2 From the stdcxx status page: Check and make sure that the files that have been donated have been updated to reflect the new ASF copyright. See also: http://www.mail-archive.com/[EMAIL PROTECTED]/msg14483.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-484) [HP aCC 3.74] -E +Maked ICE on a conditional with new
[
https://issues.apache.org/jira/browse/STDCXX-484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12528659
]
Martin Sebor commented on STDCXX-484:
-
Original Message
Subject: RE: aCC 3.74 -E +Maked ICE on a conditional with new
Date: Wed, 19 Sep 2007 09:51:34 +0530
From: Vasanth, Shanthal (STSD) [EMAIL PROTECTED]
To: Martin Sebor [EMAIL PROTECTED], Dennis Handly [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]
References: [EMAIL PROTECTED] [EMAIL PROTECTED]
Martin,
Yes, it is the same. It is coming out with AR0709 which will be
officially released this month.
-Shanthal
-Original Message-
From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor
Sent: Wednesday, September 19, 2007 9:44 AM
To: Dennis Handly
Cc: [EMAIL PROTECTED]
Subject: Re: aCC 3.74 -E +Maked ICE on a conditional with new
Dennis Handly wrote:
From: Martin Sebor [EMAIL PROTECTED]
It doesn't seem to work with 3.74. Is this an IPF only option?
No, it is a A.03.80 only option. I thought you beta tested it?
The latest beta I tested was called 3.76 and was based on the EDG
front end. Is that the same? And when is it coming out?
Martin
[HP aCC 3.74] -E +Maked ICE on a conditional with new
-
Key: STDCXX-484
URL: https://issues.apache.org/jira/browse/STDCXX-484
Project: C++ Standard Library
Issue Type: Bug
Components: External
Environment: HP aCC 3.74, 3.73, but not 3.63
Reporter: Martin Sebor
aCC 3.73 and 3.74 crashes generating dependencies for the code below:
$ cat t.cpp aCC +Maked -E -V t.cpp
void foo (int i) {
char a [1];
char *p = i sizeof a ? a : new char [i + 1];
}
aCC: HP ANSI C++ B3910B A.03.74
Signal 11
( 0) 0x00298924 sighandler__FiT1 + 0x134
[/amd/packages/mdx/hpux/compilers/hp/aCC374_11.31/opt/aCC/lbin/ctcom.pa20]
( 1) 0xc022c328 _sigreturn [/usr/lib/libc.2]
( 2) 0x0026b76c synthesize__15LibraryRoutinesF19LibraryRoutinesEnum +
0x7c
[/amd/packages/mdx/hpux/compilers/hp/aCC374_11.31/opt/aCC/lbin/ctcom.pa20]
( 3) 0x0026f7dc enter__15LibraryRoutinesF19LibraryRoutinesEnum + 0x10
[/amd/packages/mdx/hpux/compilers/hp/aCC374_11.31/opt/aCC/lbin/ctcom.pa20]
( 4) 0x001ca0d8
lookup__3MapF11StringTokenP11DeclarationRbQ2_3Map10LookupKindRC11DynamicListXTP4
+ 0x168
[/amd/packages/mdx/hpux/compilers/hp/aCC374_11.31/opt/aCC/lbin/ctcom.pa20]
( 5) 0x001c9e84
find__3MapF11StringTokenP11DeclarationRbQ2_3Map10LookupKindRC11DynamicListXTP4No
+ 0x9c
[/amd/packages/mdx/hpux/compilers/hp/aCC374_11.31/opt/aCC/lbin/ctcom.pa20]
( 6) 0x001a1e64
hasPointerToMemberComing__12PreprocessorFQ2_12Preprocessor8PTMStateP11Declaratio
+ 0x844
[/amd/packages/mdx/hpux/compilers/hp/aCC374_11.31/opt/aCC/lbin/ctcom.pa20]
( 7) 0x002375f4 isProbablyAnIdentifier__12PreprocessorFb + 0x54
[/amd/packages/mdx/hpux/compilers/hp/aCC374_11.31/opt/aCC/lbin/ctcom.pa20]
( 8) 0x001c7b7c
resolveIdentifier__12PreprocessorFP12ScannerValue11StringToken + 0xbd4
[/amd/packages/mdx/hpux/compilers/hp/aCC374_11.31/opt/aCC/lbin/ctcom.pa20]
( 9) 0x001c5a30 nextToken__12PreprocessorFP12ScannerValue + 0x210
[/amd/packages/mdx/hpux/compilers/hp/aCC374_11.31/opt/aCC/lbin/ctcom.pa20]
(10) 0x0026adc4 DoCompile__8CompilerFv + 0xd44
[/amd/packages/mdx/hpux/compilers/hp/aCC374_11.31/opt/aCC/lbin/ctcom.pa20]
(11) 0x000b347c DoCompile__8CompilerFP6Buffer + 0x34
[/amd/packages/mdx/hpux/compilers/hp/aCC374_11.31/opt/aCC/lbin/ctcom.pa20]
(12) 0x000b9178 DoCompileFile__8CompilerFPc + 0x110
[/amd/packages/mdx/hpux/compilers/hp/aCC374_11.31/opt/aCC/lbin/ctcom.pa20]
(13) 0x000c1248 main + 0x404
[/amd/packages/mdx/hpux/compilers/hp/aCC374_11.31/opt/aCC/lbin/ctcom.pa20]
(14) 0xc017d964 _start + 0xb4 [/usr/lib/libc.2]
(15) 0x001a7d08 $START$ + 0x178
[/amd/packages/mdx/hpux/compilers/hp/aCC374_11.31/opt/aCC/lbin/ctcom.pa20]
Error (system problem) 689: # Compiler received signal 11
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
