RE: STDCXX examples fails and reasons [MSVC]
-Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor Sent: Monday, July 09, 2007 7:47 AM To: stdcxx-dev@incubator.apache.org Subject: Re: STDCXX examples fails and reasons [MSVC] Because in windows infrastructure the TZ environment variable is set for all examples only, but my patch in unix infrastructure sets TZ variable for tests also. Hmm. I don't suppose it should matter (our tests shouldn't be relying on the variable being set to any specific value), but I see what you mean. Is there a way to set the variable just for examples? I don't know another way, but I'm not a makefile guru :) Commited thus: http://svn.apache.org/viewvc?view=revrev=554682 Farid.
Re: list of available cross-build result views
Mark Brown wrote: -Original Message- From: [EMAIL PROTECTED] Sent: Sat, 16 Jun 2007 15:59:11 -0600 To: stdcxx-dev@incubator.apache.org Subject: list of available cross-build result views ...is on the page below. This page and the cross-build views are all set up to get generated from the all-platform build result data at 8AM PDT every day. http://people.apache.org/~sebor/stdcxx/results/builds.html Martin, This looks interesting. I have a question though. There are a number of black cells in the test tables on most of the pages. For instance, the 22.locale.num.put.mt test on the redhat_as-5.0-em64t-gcc-4.1.1.html page. Does it mean the test did not run? I looked for the test on the redhat_as-5.0-em64t-gcc-64b-4.1.1-12d-log.gz.txt page referenced from column 12 (the closest I could find to 15D). The status of the test is SEGV but when I looked in the log I couldn't find the test there. I completely missed this post, sorry about that. There shouldn't be any black cells. Wherever there are, it's because of a bug in the script that parses the logs and creates the HTML matrices. I haven't had time to fix them yet but the script is in Subversion in case someone feels like some shell or awk hacking ;-) (The script also needs to be enhanced to parse Windows logs.) http://svn.apache.org/viewvc?view=revrevision=552891 Martin
Windows build failures reported as DATA
Most of our Windows buils failed due to a change I committed over the weekend (http://svn.apache.org/viewvc?view=revrevision=554281). I'm working on fixing the regression but the breakage highlighted another problem that I'm hoping you might be able to quickly fix, Andrew. Even though the builds failed due to a compilation error in the library they are reported in the status of DATA instead of LIB. Thanks Martin
RE: 23.deque.special
-Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor Sent: Monday, July 09, 2007 7:40 AM To: stdcxx-dev@incubator.apache.org Subject: Re: 23.deque.special Farid Zaripov wrote: Below is a part of the 23.deque.special test. These rw_assert's fails because of deque::end() internal representation is dependent on object and cannot be swapped. I'm not sure I understand. The std::deque::iterator type has two members: pointer to the current element and pointer to the array containing the element (include/deque, line 188): // `cur' points at the curent element or is null (for the end iterator) // `node' points to the array containing the element or cur (for end) pointer _C_cur; _C_node_pointer _C_node; }; For the end iterator _C_node == _C_cur. In case swapping two empty deque, two end iterators being swapped. Let's iter1 is the iterator of some deque1 and iter2 is the iterator of another deque2 before swap. And let's iter3 is the iterator of deque1 and iter4 is the iterator of deque2 after swap. Before swap: iter1._C_cur == 0; iter1._C_node == deque1._C_end._C_cur; iter2._C_cur == 0; iter2._C_node == deque2._C_end._C_cur; After swap still: iter3._C_cur == 0; iter3._C_node == deque1._C_end._C_cur; iter4._C_cur == 0; iter4._C_node == deque2._C_end._C_cur; The iterators mebmer values aren't swapped, because if they would swapped these iterators wouldn't be end iterators in terms of our deque implementation. iter3 != iter2 and iter4 != iter1 So in our deque implementation we shouldn't compare end iterators after swap operation. Swapping two deques is required not to invalidate any iterators, isn't that right? If iter3 should == iter2 and iter4 should == iter1, then we need to change the deque implementation. Are you suggesting to loosen the test so as not to exercise this requirement? I suggest only not to exercise iterators if one deque is empty. Farid.
[jira] Commented: (STDCXX-109) [Mac OS X 10.2.8] Unable to build rwstderr.cat (no gencat utility)
[ https://issues.apache.org/jira/browse/STDCXX-109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511175 ] Martin Sebor commented on STDCXX-109: - We should be able to successfully build the library even when gencat isn't installed. The fix is simple: make the makefile rule succeed even if the invocation of the utility fails. One way to do it is to put a dash in front of it: # create a catalog from text message files - see gencat(1) $(CATFILE): $(MSGFILES) -gencat $@ $^ [Mac OS X 10.2.8] Unable to build rwstderr.cat (no gencat utility) -- Key: STDCXX-109 URL: https://issues.apache.org/jira/browse/STDCXX-109 Project: C++ Standard Library Issue Type: Bug Components: Build Environment: Mac OS X 10.2.8/Darwin 6.8 with GCC 3.1 Reporter: Andrew Black Assignee: Andrew Black Fix For: 4.2 When the make process gets to the point where it tries to build the rwstderr.cat file, the make process fails with gencat rwstderr.cat /Volumes/Orion/Work/stdcxx/src/rwstderr.msg /bin/sh: gencat: command not found make[2]: *** [rwstderr.cat] Error 127 make[1]: *** [lib] Error 2 make: *** [libstd] Error 2 The most obvious cause is that there is no gencat utility installed on the system in the $PATH hierarchy. I have not searched for the gencat utility outside of the $PATH hierarchy at this point in time, though it would make sense to do so. As this utility is referenced as a part of the makefile rules, it would be difficult at best to control logic through the characterization tests. A possible way to detect if there is an accessable copy of gencat would be to use the which command, redirecting the output to /dev/null, and using the return code to detect the location. Another possible tactic would be to make the failed execution of gencat a non fatal problem (which likely would result in other problems if it failed in other circumstances), then to touch the output file when done so that a file is present (if empty) to be used in building the library. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: 23.deque.special
Farid Zaripov wrote: -Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor Sent: Monday, July 09, 2007 7:40 AM To: stdcxx-dev@incubator.apache.org Subject: Re: 23.deque.special Farid Zaripov wrote: Below is a part of the 23.deque.special test. These rw_assert's fails because of deque::end() internal representation is dependent on object and cannot be swapped. I'm not sure I understand. The std::deque::iterator type has two members: pointer to the current element and pointer to the array containing the element (include/deque, line 188): // `cur' points at the curent element or is null (for the end iterator) // `node' points to the array containing the element or cur (for end) pointer _C_cur; _C_node_pointer _C_node; }; For the end iterator _C_node == _C_cur. In case swapping two empty deque, two end iterators being swapped. Let's iter1 is the iterator of some deque1 and iter2 is the iterator of another deque2 before swap. And let's iter3 is the iterator of deque1 and iter4 is the iterator of deque2 after swap. Before swap: iter1._C_cur == 0; iter1._C_node == deque1._C_end._C_cur; iter2._C_cur == 0; iter2._C_node == deque2._C_end._C_cur; After swap still: iter3._C_cur == 0; iter3._C_node == deque1._C_end._C_cur; iter4._C_cur == 0; iter4._C_node == deque2._C_end._C_cur; The iterators mebmer values aren't swapped, because if they would swapped these iterators wouldn't be end iterators in terms of our deque implementation. iter3 != iter2 and iter4 != iter1 So in our deque implementation we shouldn't compare end iterators after swap operation. Swapping two deques is required not to invalidate any iterators, isn't that right? If iter3 should == iter2 and iter4 should == iter1, then we need to change the deque implementation. Right, I think that will be necessary. I was under the impression that you already did that in the change below but now that I've re-read it I think that issue might be about something else. http://svn.apache.org/viewvc?view=revrevision=507940 Are you suggesting to loosen the test so as not to exercise this requirement? I suggest only not to exercise iterators if one deque is empty. But that would only hide the bug. swapping empty deques needs to work (and not invalidate iterators) just as well as swapping ones with elements. Martin
[jira] Created: (STDCXX-479) [Sun C++ 5.9] many warnings on -xarch=v9
[Sun C++ 5.9] many warnings on -xarch=v9 Key: STDCXX-479 URL: https://issues.apache.org/jira/browse/STDCXX-479 Project: C++ Standard Library Issue Type: Bug Components: Configuration Affects Versions: 4.1.3 Environment: Sun C++ 5.9, Solaris 10, SPARC Reporter: Martin Sebor Assignee: Martin Sebor Priority: Critical According to http://developers.sun.com/sunstudio/documentation/ss12/whatsnew.html, the -xarch=v9 option has been deprecated in favor of -xarch=sparc -m64 on SPARC. The compiler issues warnings for each use of the deprecated option See below). See also the following thread: http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg03874.html $ nice gmake BUILDTYPE=15D BUILDDIR=/build/sebor/stdcxx-sunpro-5.9-15D/ GNUmakefile:289: CONFIG not specified, using sunpro.config creating BUILDDIR=/build/sebor/stdcxx-sunpro-5.9-15D/ generating /build/sebor/stdcxx-sunpro-5.9-15D//makefile.in from /amd/devco/sebor/stdcxx/etc/config/sunpro.config gmake[1]: Entering directory `/build/sebor/stdcxx-sunpro-5.9-15D' gmake[2]: Entering directory `/build/sebor/stdcxx-sunpro-5.9-15D/include' gmake config gmake[3]: Entering directory `/build/sebor/stdcxx-sunpro-5.9-15D/include' configuring stdcxx 4.2.0 for CC-5.9 on sunos-5.10-sparc checking if the compiler is sane ok (invoked with CC) checking if the linker is sane ok (invoked with CC) checking system architecture LP64 big endian ... gmake[3]: Leaving directory `/build/sebor/stdcxx-sunpro-5.9-15D/include' touch config.h gmake[2]: Leaving directory `/build/sebor/stdcxx-sunpro-5.9-15D/include' gmake[2]: Entering directory `/build/sebor/stdcxx-sunpro-5.9-15D/lib' generating dependencies for $(TOPDIR)/src/atomic-cxx.S CC: Warning: -xarch=v9 is deprecated, use -m64 to create 64-bit programs -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
RE: 23.deque.special
-Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] Sent: Monday, July 09, 2007 8:05 PM To: stdcxx-dev@incubator.apache.org Subject: Re: 23.deque.special Right, I think that will be necessary. I was under the impression that you already did that in the change below but now that I've re-read it I think that issue might be about something else. http://svn.apache.org/viewvc?view=revrevision=507940 In this change I just corrected _C_begin and _C_end members of empty deque after swap operaton. Are you suggesting to loosen the test so as not to exercise this requirement? I suggest only not to exercise iterators if one deque is empty. But that would only hide the bug. swapping empty deques needs to work (and not invalidate iterators) just as well as swapping ones with elements. But in current implementation iterator not invalidated. Yes, it's mebmers has changed, but it's still valid end iterator. If we decide to set deque._C_end._C_node = 0 for end iterator of empty deque It would be a big change (we should change the all places where _C_end._C_node member dereferenced). Farid.
RE: Intel C++ build issues on Windows
-Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor Sent: Monday, July 09, 2007 7:44 AM To: stdcxx-dev@incubator.apache.org Subject: Re: Intel C++ build issues on Windows We'll also need a solution for those executables (but we can worry about that once we're done enhancing the test driver). We can install the similar handlers in each example, but I don't see any 2) of 3) popups in examples at the moment. But that could change. I'd like to come up with a reliable mechanism that would let us prevent these popups in both tests and examples, just in case. Perhaps a good place for it would be the examples.h header, although preferably without relying on the coupling between the header and the example sources: https://issues.apache.org/jira/browse/STDCXX-425 I can make the function i.e. init_example() in which all needed hooks are installed, but this function should be invoked from main() in all examples. Farid.
Re: config with wide has no effect on Solaris/Intel + patch
Michael van der Westhuizen wrote: Hi Martin, On 7/7/07, Martin Sebor [EMAIL PROTECTED] wrote: [snip] I recall reading somewhere that Sun C++ 5.9 supports the gcc -m64 option but I can't find the reference. Do you happen to have a link? The x86 equivalent I was able to find in the online documentation is still -xarch=amd64 (I couldn't find -m64 in the manual): http://docs.sun.com/source/819-3690/Comp_Options_App.html#pgfId-999544 I picked the flags up here - http://developers.sun.com/sunstudio/documentation/ss12/whatsnew.html Ah, that's the page I read! Thanks! The xarch flags used result in compile-time warnings with C++ 5.9, so the -mXX options are really necessary. Agreed. I created a separate issue for this: https://issues.apache.org/jira/browse/STDCXX-479 It's possible to further tune the generated code using non-deprecated -xarch options - there are details in the links above. We're only just getting around to setting up the compiler but once it's up and running we'll test your patch with it. I've found quite a few issues with C++ 5.9, so we'll probably stick to 5.8+patches for now - at least until the obvious optimiser bugs are worked out. I've logged a compile-time showstopper (a ube assertion that crops up in both 4.1.3 and 4.2.0) with bugs.sun.com, but I haven't logged a runtime problem with the numeric limits configuration test which makes it impossible to compile with any optimisation on sparcv8/sparcv9 (I haven't had time to look into the problem). Ugh. Sounds like we have some work to do... I'm also seeing the support/atomic* tests timing out on the i386 and amd64 - this is unexpected, but I haven't had time to look into this yet. Check the list and Jira in case we figure out before you do (otherwise keep us posted -- thanks!) Martin Some of the tests are also hitting backend corner cases - I've never seen the UBE take as much memory as it does now, and I've never seen it use a whole CPU before: 7723 michael 315M 312M cpu0 00 0:05:43 50% ube/1 Michael
[jira] Created: (STDCXX-480) [Sun C++ 5.9] -xM outputs full preprocessed output for .S files
[Sun C++ 5.9] -xM outputs full preprocessed output for .S files --- Key: STDCXX-480 URL: https://issues.apache.org/jira/browse/STDCXX-480 Project: C++ Standard Library Issue Type: Bug Components: External Reporter: Martin Sebor Compiling a .S file with Sun C++ 5.8 produces a listing of dependencies suitable for inclusion in makefiles. Sun C++ 5.9 unexpectedly produces the full preprocessed output instead: $ CC -V -xM t.S CC: Sun C++ 5.8 Patch 121017-08 2006/12/06 cpp: Software Generation Utilities (SGU) SunOS/SVR4 t.o: t.S t.o: /usr/include/assert.h $ CC -V -xM t.S | sed /^ *$/d CC: Sun C++ 5.9 SunOS_sparc 2007/05/03 cpp: Software Generation Utilities (SGU) SunOS/SVR4 # 1 t.S # 1 /usr/include/assert.h 1 #ident @(#)assert.h 1.1004/05/18 SMI # 20 /usr/include/assert.h # 22 /usr/include/assert.h # 28 /usr/include/assert.h extern void _assert(); # 34 /usr/include/assert.h # 51 /usr/include/assert.h # 53 /usr/include/assert.h # 60 /usr/include/assert.h # 2 t.S 2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Intel C++ build issues on Windows
Farid Zaripov wrote: -Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor Sent: Monday, July 09, 2007 7:44 AM To: stdcxx-dev@incubator.apache.org Subject: Re: Intel C++ build issues on Windows We'll also need a solution for those executables (but we can worry about that once we're done enhancing the test driver). We can install the similar handlers in each example, but I don't see any 2) of 3) popups in examples at the moment. But that could change. I'd like to come up with a reliable mechanism that would let us prevent these popups in both tests and examples, just in case. Perhaps a good place for it would be the examples.h header, although preferably without relying on the coupling between the header and the example sources: https://issues.apache.org/jira/browse/STDCXX-425 I can make the function i.e. init_example() in which all needed hooks are installed, but this function should be invoked from main() in all examples. I was hoping to do it in a non-intrusive way. For instance, on UNIX we could link with (or preload) a shared library that would in its startup code run the function. Or we could use a command line option to the preprocessor (such as gcc -include file) to include a header containing the definition of such a function: http://gcc.gnu.org/onlinedocs/gcc-4.2.0/gcc/Preprocessor-Options.html#index-include-634 Does MSVC have something similar? Martin
Re: 23.deque.special
Farid Zaripov wrote:
[...]
Are you suggesting to loosen the test so as not to exercise this
requirement?
I suggest only not to exercise iterators if one deque is empty.
But that would only hide the bug. swapping empty deques needs
to work (and not invalidate iterators) just as well as
swapping ones with elements.
But in current implementation iterator not invalidated. Yes, it's
mebmers
has changed, but it's still valid end iterator.
But it doesn't point to the right container. Unless I'm still
missing something this needs to pass:
#include assert.h
#include deque
int main ()
{
std::dequeint x, y;
std::dequeint::iterator i = x.begin (), j = x.end ();
std::dequeint::iterator k = y.begin (), l = y.end ();
std::swap (x, y);
assert (i == y.begin () j == y.end ());
assert (k == y.begin () l == y.end ());
}
If we decide to set deque._C_end._C_node = 0 for end iterator of
empty
deque It would be a big change (we should change the all places where
_C_end._C_node member dereferenced).
Couldn't we just repoint _C_end._C_node in swap()? I thought
that's what we were doing anyway so I guess I still don't fully
understand the problem.
Martin
Re: config with wide has no effect on Solaris/Intel + patch
Hi Martin, On 7/9/07, Martin Sebor [EMAIL PROTECTED] wrote: Check the list and Jira in case we figure out before you do (otherwise keep us posted -- thanks!) Thanks - I'll definitely keep an eye on the lists. Michael
RE: 23.deque.special
-Original Message-
From: Martin Sebor [mailto:[EMAIL PROTECTED]
Sent: Monday, July 09, 2007 10:05 PM
To: stdcxx-dev@incubator.apache.org
Subject: Re: 23.deque.special
But in current implementation iterator not invalidated. Yes, it's
mebmers has changed, but it's still valid end iterator.
But it doesn't point to the right container. Unless I'm still
missing something this needs to pass:
No. It point to the right container.
std::dequeint x, y;
x._C_end._C_node always == x._C_end._C_cur for empty container x
This condition is required by current design (include/deque, line 663)
void _C_init () {
// clear both `beg.cur' and `end.cur' and set both `beg.node'
// and `end.node' to point to `end.cur' (instead of 0) to avoid
// having to check before dereferencing the pointers
_C_beg =
_C_end = _C_deque_iter (pointer (), _C_end._C_cur);
_C_nodes = _C_node_pointer ();
_C_node_size = 0;
}
After x.swap (y) operation x._C_end._C_node still should point to
x._C_end._C_cur,
but not to y._C_end._C_cur to be a valid end iterator of the
container x.
If we decide to set deque._C_end._C_node = 0 for end
iterator of
empty deque It would be a big change (we should change the
all places
where _C_end._C_node member dereferenced).
Couldn't we just repoint _C_end._C_node in swap()?
http://svn.apache.org/viewvc?view=revrevision=507940
Here I repoint _C_end._C_node to the value required by current design
after binary _STD::swap (_C_end, __rhs._C_end);
Farid.
[jira] Commented: (STDCXX-480) [Sun C++ 5.9] -xM outputs full preprocessed output for .S files
[ https://issues.apache.org/jira/browse/STDCXX-480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511241 ] Martin Sebor commented on STDCXX-480: - Original Message Subject: Re: (Incident Review ID: 1009625) Sun C++ 5.9 -xM outputs full preprocessed output for .S files Date: Mon, 09 Jul 2007 12:57:49 -0700 (MST) From: Steve Clamage [EMAIL PROTECTED] To: [EMAIL PROTECTED] Hi Martin Sebor, Thank you for reporting this issue. We have determined that this report is a new bug and entered the bug into our internal bug tracking system under Bug Id: 6578364. You can monitor this bug on the Java Bug Database at http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6578364. It may take a day or two before your bug shows up in this external database. If you are a member of the Sun Developer Network (SDN), there are two additional options once the bug is visible. 1. Voting for the bug Click http://bugs.sun.com/bugdatabase/addVote.do?bug_id=6578364. 2. Adding the report to your Bug Watch list. You will receive an email notification when this bug is updated. Click http://bugs.sun.com/bugdatabase/addBugWatch.do?bug_id=6578364. The Sun Developer Network (http://developers.sun.com) is a free service that Sun offers. To join, visit https://softwarereg.sun.com/registration/developer/en_US/new_user. For a limited time, SDN members can obtain fully licensed Java IDEs for web and enterprise development. More information is at http://developers.sun.com/prodtech/javatools/free/. Regards, Steve NOTICE: This message, including any attachments, is for the intended recipient(s) only. If you are not the intended recipient(s), please reply to the sender, delete this message, and refrain from disclosing, copying, or distributing this message. --- Previous Messages - Report - category : c++ subcategory : preproc release : studio12 type : bug synopsis : Sun C++ 5.9 -xM outputs full preprocessed output for .S files customer name : Martin Sebor customer mail : [EMAIL PROTECTED] sdn id : language : en company : Rogue Wave Software hardware : sun4 os : solaris_10 bug id : 6578364 date created : Mon Jul 09 13:49:09 MST 2007 date evaluated : Mon Jul 09 12:54:14 MST 2007 description : FULL PRODUCT VERSION : Sun C+ 5.9 ADDITIONAL OS VERSION INFORMATION : Solaris 10 A DESCRIPTION OF THE PROBLEM : From https://issues.apache.org/jira/browse/STDCXX-480 Compiling a .S file with Sun C++ 5.8 produces a listing of dependencies suitable for inclusion in makefiles. Sun C++ 5.9 unexpectedly produces the full preprocessed output instead: $ cat t.S #include assert.h $ CC -V -xM t.S CC: Sun C++ 5.8 Patch 121017-08 2006/12/06 cpp: Software Generation Utilities (SGU) SunOS/SVR4 t.o: t.S t.o: /usr/include/assert.h $ CC -V -xM t.S | sed /^ *$/d CC: Sun C++ 5.9 SunOS_sparc 2007/05/03 cpp: Software Generation Utilities (SGU) SunOS/SVR4 # 1 t.S # 1 /usr/include/assert.h 1 #ident @(#)assert.h 1.10 04/05/18 SMI # 20 /usr/include/assert.h # 22 /usr/include/assert.h # 28 /usr/include/assert.h extern void _assert(); # 34 /usr/include/assert.h # 51 /usr/include/assert.h # 53 /usr/include/assert.h # 60 /usr/include/assert.h # 2 t.S 2 REGRESSION. Last worked in version studio11 STEPS TO FOLLOW TO REPRODUCE THE PROBLEM : Compile any .S file. EXPECTED VERSUS ACTUAL BEHAVIOR : EXPECTED - Same as with Sun C++ 5.8 and prior: t.o: t.S t.o: /usr/include/assert.h ACTUAL - Full preprocessed output: # 1 t.S # 1 /usr/include/assert.h 1 #ident @(#)assert.h 1.10 04/05/18 SMI # 20 /usr/include/assert.h # 22 /usr/include/assert.h # 28 /usr/include/assert.h extern void _assert(); # 34 /usr/include/assert.h # 51 /usr/include/assert.h # 53 /usr/include/assert.h # 60 /usr/include/assert.h # 2 t.S 2 REPRODUCIBILITY : This bug can be reproduced always. -- BEGIN SOURCE -- #include assert.h -- END SOURCE -- Release Regression From : studio11 The above release value was the last known release where this bug was not reproducible. Since then there has been a regression. [Sun C++ 5.9] -xM outputs full preprocessed output for .S files --- Key: STDCXX-480 URL: https://issues.apache.org/jira/browse/STDCXX-480 Project: C++ Standard Library Issue Type: Bug Components: External Reporter: Martin Sebor Compiling a .S file with Sun C++ 5.8 produces a listing of dependencies suitable for inclusion in makefiles. Sun C++ 5.9 unexpectedly produces the full preprocessed output instead: $
[jira] Commented: (STDCXX-476) [Intel Thread Checker 3.1] calls std::terminate() after throwing exception of class type
[
https://issues.apache.org/jira/browse/STDCXX-476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511250
]
Martin Sebor commented on STDCXX-476:
-
Filed the following issue with Intel:
https://premier.intel.com/premier/IssueDetail.aspx?IssueID=441117
[Intel Thread Checker 3.1] calls std::terminate() after throwing exception of
class type
Key: STDCXX-476
URL: https://issues.apache.org/jira/browse/STDCXX-476
Project: C++ Standard Library
Issue Type: Bug
Components: External
Environment: Intel Thread Checker 3.1
Reporter: Martin Sebor
Running a program that throws and catches an exception of user-defined type
in a thread function through the thread checker causes a call to terminate():
cat t.cpp make t icc -v tcheck_cl t
#include pthread.h
#include stdio.h
struct S { };
int loop;
extern C void* thread_proc (void*)
{
for (loop = 0; loop != 2; ++loop) {
printf (%d\n, loop);
try { throw S (); }
catch (...) { }
}
return 0;
}
int main ()
{
pthread_t tid;
if (pthread_create (tid, 0, thread_proc, 0))
return 1;
pthread_join (tid, 0);
}
icc -c -I/home/sebor/stdcxx/include/ansi -D_RWSTDDEBUG -D_REENTRANT
-I/home/sebor/stdcxx/include -I/build/sebor/stdcxx-icc-10.0.025-15S/include
-I/home/sebor/stdcxx/examples/include -cxxlib-nostd -g -w1 t.cpp
icc t.o -o t -cxxlib-nostd -lpthread
-L/build/sebor/stdcxx-icc-10.0.025-15S/lib -lstd15S -lcxaguard -lsupc++ -lm
Version 10.0
Intel(R) Thread Checker 3.1 command line instrumentation driver (24400)
Copyright (c) 2007 Intel Corporation. All rights reserved.
Building project
Instrumenting
11% t ( All Functions ):..
Running: /build/sebor/stdcxx-icc-10.0.025-15S/examples/t
0
terminate called after throwing an instance of 'S'
Application finished
___
|ID|Short Des|Severit|Co|Context|Description |1st Ac|2nd
Acc|
| |cription |y Name |un|[Best] |
|cess[B|ess[Bes|
| | | |t | | |est] |t]
|
___
|1 |Thread te|Informa|1 |Whole |Thread termination at
|t.cpp|t.cpp|
| |rmination|tion | |Program|t.cpp:24 - includes stack |:24 |:24
|
| | | | |1 |allocation of 10.004 MB and | |
|
| | | | | |use of 7.281 KB | |
|
___
|2 |Thread te|Informa|1 |Whole |Thread termination at
|t.cpp|t.cpp|
| |rmination|tion | |Program|t.cpp:21 - includes stack |:21 |:21
|
| | | | |2 |allocation of 10 MB and use of| |
|
| | | | | |4.938 KB | |
|
___
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-476) [Intel Thread Checker 3.1] calls std::terminate() on an exception in a thread function
[
https://issues.apache.org/jira/browse/STDCXX-476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Sebor updated STDCXX-476:
Summary: [Intel Thread Checker 3.1] calls std::terminate() on an exception
in a thread function (was: [Intel Thread Checker 3.1] calls std::terminate()
after throwing exception of class type)
[Intel Thread Checker 3.1] calls std::terminate() on an exception in a thread
function
--
Key: STDCXX-476
URL: https://issues.apache.org/jira/browse/STDCXX-476
Project: C++ Standard Library
Issue Type: Bug
Components: External
Environment: Intel Thread Checker 3.1
Reporter: Martin Sebor
Running a program that throws and catches an exception of user-defined type
in a thread function through the thread checker causes a call to terminate():
cat t.cpp make t icc -v tcheck_cl t
#include pthread.h
#include stdio.h
struct S { };
int loop;
extern C void* thread_proc (void*)
{
for (loop = 0; loop != 2; ++loop) {
printf (%d\n, loop);
try { throw S (); }
catch (...) { }
}
return 0;
}
int main ()
{
pthread_t tid;
if (pthread_create (tid, 0, thread_proc, 0))
return 1;
pthread_join (tid, 0);
}
icc -c -I/home/sebor/stdcxx/include/ansi -D_RWSTDDEBUG -D_REENTRANT
-I/home/sebor/stdcxx/include -I/build/sebor/stdcxx-icc-10.0.025-15S/include
-I/home/sebor/stdcxx/examples/include -cxxlib-nostd -g -w1 t.cpp
icc t.o -o t -cxxlib-nostd -lpthread
-L/build/sebor/stdcxx-icc-10.0.025-15S/lib -lstd15S -lcxaguard -lsupc++ -lm
Version 10.0
Intel(R) Thread Checker 3.1 command line instrumentation driver (24400)
Copyright (c) 2007 Intel Corporation. All rights reserved.
Building project
Instrumenting
11% t ( All Functions ):..
Running: /build/sebor/stdcxx-icc-10.0.025-15S/examples/t
0
terminate called after throwing an instance of 'S'
Application finished
___
|ID|Short Des|Severit|Co|Context|Description |1st Ac|2nd
Acc|
| |cription |y Name |un|[Best] |
|cess[B|ess[Bes|
| | | |t | | |est] |t]
|
___
|1 |Thread te|Informa|1 |Whole |Thread termination at
|t.cpp|t.cpp|
| |rmination|tion | |Program|t.cpp:24 - includes stack |:24 |:24
|
| | | | |1 |allocation of 10.004 MB and | |
|
| | | | | |use of 7.281 KB | |
|
___
|2 |Thread te|Informa|1 |Whole |Thread termination at
|t.cpp|t.cpp|
| |rmination|tion | |Program|t.cpp:21 - includes stack |:21 |:21
|
| | | | |2 |allocation of 10 MB and use of| |
|
| | | | | |4.938 KB | |
|
___
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: STDCXX examples fails and reasons [MSVC]
Farid Zaripov wrote: -Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor Sent: Monday, July 09, 2007 7:47 AM To: stdcxx-dev@incubator.apache.org Subject: Re: STDCXX examples fails and reasons [MSVC] Because in windows infrastructure the TZ environment variable is set for all examples only, but my patch in unix infrastructure sets TZ variable for tests also. Hmm. I don't suppose it should matter (our tests shouldn't be relying on the variable being set to any specific value), but I see what you mean. Is there a way to set the variable just for examples? I don't know another way, but I'm not a makefile guru :) In GNU make there is such a thing as Target-Specific Variables. I thought maybe we could use it to set TZ in GNUmakefile.exm: http://www.gnu.org/software/make/manual/make.html#Target_002dspecific Martin
Re: Windows build failures reported as DATA
Greetings Martin. I've done a little digging, and the problem appears to originate in the glue scripts used for nightly testing. In particular, the post-run parser for windows incorrectly interprets a failure to build the library as a hard (state C) failure, rather than a library (state F) failure. I will be checking in a fix shortly. --Andrew Black Martin Sebor wrote: Most of our Windows buils failed due to a change I committed over the weekend (http://svn.apache.org/viewvc?view=revrevision=554281). I'm working on fixing the regression but the breakage highlighted another problem that I'm hoping you might be able to quickly fix, Andrew. Even though the builds failed due to a compilation error in the library they are reported in the status of DATA instead of LIB. Thanks Martin
