Re: Adding to G++: Adding a warning on throwing unspecified exceptions.
Brendon Costa wrote:
> You as an author of a new template class "could" define it the other way.
>
> The issue here is that doing so restricts usage of the generic
> component. In specific cases this may be desirable, but not for generic
> components like STL containers or those in boost. For generic components
> you want to make them as useful as possible. Even if at the time of
> writing the container you do not foresee that throwing any type of
> exception is a good idea, users may come up with some way of using it
> that you just never thought about.
>
> I.e. I think the general philosophy is to define only what restrictions
> are necessary to implement the template, not necessarily what we think
> constitute good uses of the template at the time we created it.
I definately agree with your comments here (generic components should
often allow their types to throw what they like), I'm just not sure
how to achieve it any other way.
Here's some ideas:
1) In many cases, templates can make a pretty good case for requiring
no-throw for member functions of their type, such as destructors and
move constructors.
Currently, templates can't restrict exceptions when they should and
when they shouldn't.
With the warning, templates need to restrict exceptions when they
should and when they shouldn't, (or be throw all, which requires an
ugly downstream catch(...) ).
Both aren't optimal, although preventing a legitimate thing is worse
than allowing a wrong thing.
2) As in my last post, use template parameters to specify additional
exception types.
===
#include
class foo {
public:
void bar() throw(float) { throw float(5); }
};
template // or use concepts.
class zug {
public:
template void call_bar() throw(int, E) { f.bar();
throw int(3); }
F f;
};
int main() {
zug zf;
try {
zf.call_bar(); // here float is passed as an additional
exception.
}
catch(int& caught) {
std::cout << "caught an int" << std::endl;
}
catch(float& caught) {
std::cout << "caught a float" << std::endl;
}
return 0;
}
===
output:
caught a float
===
The above works on code::blocks, which uses some form of GCC, and
looks OK to me.
Of course this only works for exactly one exception type.
You'd have to wait for C++0X variadic templates (and hope you can
throw them) if you need zero or more than one.
It's also very verbose, a little cryptic, and nested templates could
make variadic versions horrifically long.
However it's a start.
Brendon Costa wrote:
> I had to go to lengths to provide
> a "suppressions" system for EDoc++, simply because almost all code can
> throw all sorts of exceptions i had never heard of before. A developer
> "generally" is not interested in exceptions like:
> __gnu_cxx::recursive_init. But after writing EDoc++ i found exceptions
> like this turn up all over the place, though they should not occur in
> normal operation...
As for implicit exceptions that aren't manually thrown with a throw
statement, eg:
__gnu_cxx::recursive_init
(http://www.cygwin.com/ml/cygwin-developers/2005-05/msg00019.html)
or arithmetic exceptions (perhaps 1/0 etc)
I would just suggest ignoring these. Eventually the compiler _may_
declare these exceptions per implicit op or remove the exceptions, but
either way it's too difficult to manage manually.
You could still specify those exceptions if you're really masochistic.
There is something else to consider.
If this project works reasonably well and perhaps becomes popular,
it's not unreasonable to suggest some minor extensions to the C++
standard to help people code using it.
For example:
1) allowing typedef'd function pointers and concept functions to have
a throw specifier.
2) allowing: "void bar() throw(type_a, type_b, foo::throw);" or "...,
foo())" or something whereby bar inherits foo's throw specifiers,
which would mainly solve the above template problem.
3) extending 2 by giving the option of removing specific types, "void
bar() throw(foo::throw, not int);" so that you can reduce the types
thrown by catching them. I can think of some circumstances where this
could be useful but I'm not sure if they're common enough to justify
it.
Which would then make rigid exception specifying easy enough to use
everywhere. Ok I know I'm trying to fly before I can crawl here :)
Just something to think on.
Re: Apple, iPhone, and GPLv3 troubles
>> This means that you couldn't use *GCC* if you >> did something the FSF found objectionable, closing an easy >> work-around. > > This doesn't work, because it breaks out of the basic framework of > copyright law. Nobody signs anything or accepts any terms in order to > use gcc. The FSF wants to stop people from distributing proprietary > binary plugins to gcc. The copyright on gcc does not apply to those > plugins. Also, even if you could develop a license similar to the GPL but with an additional restriction to this end, this would not be the GPL anymore, because GPLv3 limits the "non-permissive additional terms" to the ones listed in Section 7: a) [disclaiming warranty] b) [requiring preservation of legal notices] c) [requiring that modified versions of such material be marked] d) [limiting the use for publicity purposes of names] e) [declining to grant rights for use of some trademarks] f) [the Apache License's patent indemnification clause] All other non-permissive additional terms are considered "further restrictions" within the meaning of section 10. If the Program as you received it, or any part of it, contains a notice stating that it is governed by this License along with a term that is a further restriction, you may remove that term. Even without considering the feasibility of adding such a bullet, it would not be a good PR move for the FSF to add a bullet "g" to the above list for the sake of GCC. The possibility of modifying the permissive terms of the runtime libraries (which are distributed with every binary produced by the compiler) does seem like a good way to control the *usage* of the compiler as opposed to its distribution. Paolo
Re: Apple, iPhone, and GPLv3 troubles
On Sep 25, 2008, at 3:11 AM, Paolo Bonzini wrote: This means that you couldn't use *GCC* if you did something the FSF found objectionable, closing an easy work-around. This doesn't work, because it breaks out of the basic framework of copyright law. Nobody signs anything or accepts any terms in order to use gcc. The FSF wants to stop people from distributing proprietary binary plugins to gcc. The copyright on gcc does not apply to those plugins. Also, even if you could develop a license similar to the GPL but with an additional restriction to this end, this would not be the GPL anymore, because GPLv3 limits the "non-permissive additional terms" to the ones listed in Section 7: The FSF could certainly define a new "GPL4" or "GPL3.1" or whatever, that contained any wording they want. However, this whole discussion is off topic for this list, I'm sorry I've propagated it this far! -Chris
ACATS Target Requirement Question
Hi, RTEMS has BSPs for a couple of simulators that do not have a source for clock tick interrupts. We simulate the passage of time by having a special IDLE task advance time. This works well enough when all tasks block but if a test depends on something like timeslice expiration, that won't happen. My questions are... + Is this sufficient to pass a reasonable subset of the ACATS? + Is it known which, if any, tests would be expected to fail in this environment? Thanks. -- Joel Sherrill, Ph.D. Director of Research & Development [EMAIL PROTECTED]On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985
[graphite] Graphite Workshop in Austin (before SC'08)
Hi, For those interested in participating in a two days graphite development, please consider updating the wiki page adding your name in the attendees list http://gcc.gnu.org/wiki/Graphite_Workshop_Nov08 We need to know how many developers will attend the workshop for logistics purposes: the meeting will be hosted on the AMD campus in Austin. The workshop is organized before the SuperComputing'08 conference in November, and it is not affiliated with this conference. Sebastian Pop -- AMD - GNU Tools
Re: ACATS Target Requirement Question
Well I guess running the ACATS gives a big hint. There were not many failures on sh-rtems4.10 and some of those were illegal memory accesses. So only the c4* and cxa* are likely to be related to not having a real clock tick. sh-rtems4.10-gcc (GCC) 4.4.0 20080918 (experimental) [trunk revision 140475] === acats Summary === # of expected passes2299 # of unexpected failures13 # of unsupported tests3 ce2108f - simulator does not have persistent files ce2108h - simulator does not have persistent files ce3112d - simulator does not have persistent files a22006b - unknown reason for failure c380004 - Memory exception at 44000 (illegal address) c45532m - raised CONSTRAINT_ERROR : c45532m.adb:143 range check failed c45532o - raised CONSTRAINT_ERROR : c45532o.adb:147 range check failed c45532p - raised CONSTRAINT_ERROR : c45532p.adb:141 range check failed c953002 - ran too long, may eventually finish simsh7032:c953002: Memory exception at 44000 (illegal address) c974013 - Memory exception at 44000 (illegal address) cd1c04e - explicit fail THE VALUES OF DERIVED_TYPE COMPONENTS WERE INCORRECT. cxa4009 - explicit fail Incorrect results cxa4020 - explicit fail Incorrect results cxg2018 - Memory exception at 44000 (illegal address) cxg2019 - Memory exception at 44000 (illegal address) cxg2021 - Memory exception at 44000 (illegal address) Joel Sherrill wrote: Hi, RTEMS has BSPs for a couple of simulators that do not have a source for clock tick interrupts. We simulate the passage of time by having a special IDLE task advance time. This works well enough when all tasks block but if a test depends on something like timeslice expiration, that won't happen. My questions are... + Is this sufficient to pass a reasonable subset of the ACATS? + Is it known which, if any, tests would be expected to fail in this environment? Thanks. -- Joel Sherrill, Ph.D. Director of Research & Development [EMAIL PROTECTED]On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985 -- Joel Sherrill, Ph.D. Director of Research & Development [EMAIL PROTECTED]On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985
Продажа и монтаж сайдинга
ПР0ДАЖА И М0НТАЖ САЙДИНГА И В0Д0СТ0К0В...
- - -
Наша компания продает высококачественный виниловый и цокольный сайдинг
производства Канады, США и России...
ЦЕНЫ на материалы - значительно НИЖЕ рыночных, за счет прямых закупок
у экспортеров и специальных скидок предоставленных для нашей компании...
Выполняем доставку и монтаж любого вида сайдинга в кратчайшие сроки...
Выезжаем на замеры без выходных и задержек...
Наши менеджеры принимают звонки круглосуточно...
Цены на услуги монтажа Вас приятно удивят...
Работаем по схеме: Замер - Расчет - Доставка - Монтаж ...
_ _ _
Для более подробной информации, позвоните нашим менеджерам...
Телефоны менеджеров:
8 |926| 566 90 00
8 {926} 02-08-470
h8300 on testsuite and -wrap
Hi, I am trying to run the gcc test suite on h8300-rtems and getting lots of failures which look like this: /home/joel/work-gnat/svn/b-gcc1-h8300/gcc/xgcc -B/home/joel/work-gnat/svn/b-gcc1-h8300/gcc/ /home/joel/work-gnat/svn/gcc/gcc/testsuite/gcc.c-torture/execute/20001031-1.c gcc_tg.o -w -O1 -DSTACK_SIZE=2048 -mh -mint32 -B/home/joel/work-gnat/svn/bsp-install/h8300-rtems4.10/h8sim/lib/ -specs bsp_specs -qrtems /home/joel/work-gnat/svn/b-gcc1-h8300/rtems_gcc_main.o -Wl,-wrap,exit -Wl,-wrap,_exit -Wl,-wrap,main -Wl,-wrap,abort -lm -o /home/joel/work-gnat/svn/b-gcc1-h8300/gcc/testsuite/gcc/20001031-1.x1 -L /home/joel/work-gnat/svn/install/h8300-rtems4.10/lib/h8300h/ -lm /tmp/ccKBizhg.o: In function `.L20': 20001031-1.c:(.text+0x99): undefined reference to `__wrap__exit' gcc_tg.o: In function `___wrap_exit': testglue.c:(.text+0x173): undefined reference to `___real_exit' gcc_tg.o: In function `.L9': testglue.c:(.text+0x23d): undefined reference to `___real__exit' gcc_tg.o: In function `___wrap_abort': testglue.c:(.text+0x271): undefined reference to `___real_abort' gcc_tg.o: In function `___wrap_main': testglue.c:(.text+0x2b9): undefined reference to `___real_main' testglue.c:(.text+0x2c1): undefined reference to `__wrap__exit' /home/joel/work-gnat/svn/bsp-install/h8300-rtems4.10/h8sim/lib/librtemscpu.a(libposix_a-psignal.o): In function `_POSIX_signals_Abnormal_termination_handler': /home/joel/work-gnat/svn//rtems/c/src/../../cpukit/posix/src/psignal.c:41: undefined reference to `__wrap__exit' The arguments passed to ld look correct but looking into this with a simple h8300-elf-gcc build, I noticed that since gcc puts a leading _ on the symbols, you have to pass "-Wl,-wrap,_malloc" NOT -Wl,-wrap,malloc". Where is the leading underscore not getting dealt with so the wrap functions get invoked. FWIW I didn't see any h8300-elf results since last year and wonder if this is a known issue. -- Joel Sherrill, Ph.D. Director of Research & Development [EMAIL PROTECTED]On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985
Re: h8300 on testsuite and -wrap
Joel Sherrill wrote: Hi, I am trying to run the gcc test suite on h8300-rtems and getting lots of failures which look like this: /home/joel/work-gnat/svn/b-gcc1-h8300/gcc/xgcc -B/home/joel/work-gnat/svn/b-gcc1-h8300/gcc/ /home/joel/work-gnat/svn/gcc/gcc/testsuite/gcc.c-torture/execute/20001031-1.c gcc_tg.o -w -O1 -DSTACK_SIZE=2048 -mh -mint32 -B/home/joel/work-gnat/svn/bsp-install/h8300-rtems4.10/h8sim/lib/ -specs bsp_specs -qrtems /home/joel/work-gnat/svn/b-gcc1-h8300/rtems_gcc_main.o -Wl,-wrap,exit -Wl,-wrap,_exit -Wl,-wrap,main -Wl,-wrap,abort -lm -o /home/joel/work-gnat/svn/b-gcc1-h8300/gcc/testsuite/gcc/20001031-1.x1 -L /home/joel/work-gnat/svn/install/h8300-rtems4.10/lib/h8300h/ -lm /tmp/ccKBizhg.o: In function `.L20': 20001031-1.c:(.text+0x99): undefined reference to `__wrap__exit' gcc_tg.o: In function `___wrap_exit': testglue.c:(.text+0x173): undefined reference to `___real_exit' gcc_tg.o: In function `.L9': testglue.c:(.text+0x23d): undefined reference to `___real__exit' gcc_tg.o: In function `___wrap_abort': testglue.c:(.text+0x271): undefined reference to `___real_abort' gcc_tg.o: In function `___wrap_main': testglue.c:(.text+0x2b9): undefined reference to `___real_main' testglue.c:(.text+0x2c1): undefined reference to `__wrap__exit' /home/joel/work-gnat/svn/bsp-install/h8300-rtems4.10/h8sim/lib/librtemscpu.a(libposix_a-psignal.o): In function `_POSIX_signals_Abnormal_termination_handler': /home/joel/work-gnat/svn//rtems/c/src/../../cpukit/posix/src/psignal.c:41: undefined reference to `__wrap__exit' The arguments passed to ld look correct but looking into this with a simple h8300-elf-gcc build, I noticed that since gcc puts a leading _ on the symbols, you have to pass "-Wl,-wrap,_malloc" NOT -Wl,-wrap,malloc". Where is the leading underscore not getting dealt with so the wrap functions get invoked. FWIW I didn't see any h8300-elf results since last year and wonder if this is a known issue. I ran into it as well when testing IRA. Hell if I can remember what I did to fix it though jeff
Re: Adding to G++: Adding a warning on throwing unspecified exceptions.
2008/9/24 Simon Hill: > Brain Dessent wrote: >> You're essentially trusting that all >> exception specifiers for every function in the program and *all* library >> code are always present and always correct which is a huge leap of faith >> that I don't think is supported by reality. > > I agree that it won't be very useful initially due to lots of third > party code like boost neither defining nor adhering exception > restrictions 100% of the time (STL may be guilty also). However, this > is a catch 22. Why not provide the mechanism for verifying exception > specifications so that these libraries can, in future, become fully > compliant? That won't happen. Boost and the standard library are not "guilty" of anything. The standard library components *are* fully compliant to the ISO standard by definition, and the omission of exception specifications is (in almost all cases) completely intentional. Some people might find the warning useful, but please don't assume that code without exception specifications is incomplete, or would necessarily benefit from having them. Jonathan
Re: ACATS Target Requirement Question
On Thu, 2008-09-25 at 14:49 -0500, Joel Sherrill wrote: > Well I guess running the ACATS gives a big hint. There were not many > failures on sh-rtems4.10 and some of those were illegal memory accesses. > So only the c4* and cxa* are likely to be related to not having a real > clock tick. The c4 fails are likely real codegen bug. As for tasking tests, most of them have very long delays (sleep) since Ada semantics does not guarantee anything, so it's not surprising that most test will pass RTEMS idle task trick. Laurent > sh-rtems4.10-gcc (GCC) 4.4.0 20080918 (experimental) [trunk revision 140475] > > === acats Summary === > # of expected passes2299 > # of unexpected failures13 > # of unsupported tests3 > > ce2108f - simulator does not have persistent files > ce2108h - simulator does not have persistent files > ce3112d - simulator does not have persistent files > a22006b - unknown reason for failure > c380004 - Memory exception at 44000 (illegal address) > c45532m - raised CONSTRAINT_ERROR : c45532m.adb:143 range check failed > c45532o - raised CONSTRAINT_ERROR : c45532o.adb:147 range check failed > c45532p - raised CONSTRAINT_ERROR : c45532p.adb:141 range check failed > c953002 - ran too long, may eventually finish simsh7032:c953002: Memory > exception at 44000 (illegal address) > c974013 - Memory exception at 44000 (illegal address) > cd1c04e - explicit fail THE VALUES OF DERIVED_TYPE COMPONENTS WERE > INCORRECT. > cxa4009 - explicit fail Incorrect results > cxa4020 - explicit fail Incorrect results > cxg2018 - Memory exception at 44000 (illegal address) > cxg2019 - Memory exception at 44000 (illegal address) > cxg2021 - Memory exception at 44000 (illegal address) > > > Joel Sherrill wrote: > > Hi, > > > > RTEMS has BSPs for a couple of simulators that > > do not have a source for clock tick interrupts. > > We simulate the passage of time by having a special > > IDLE task advance time. This works well enough > > when all tasks block but if a test depends on > > something like timeslice expiration, that won't > > happen. > > > > My questions are... > > > > + Is this sufficient to pass a reasonable subset > > of the ACATS? > > > > + Is it known which, if any, tests would be expected > > to fail in this environment? > > > > Thanks. > > > > -- > > Joel Sherrill, Ph.D. Director of Research & Development > > [EMAIL PROTECTED]On-Line Applications Research > > Ask me about RTEMS: a free RTOS Huntsville AL 35805 > >Support Available (256) 722-9985 > > > > > > > >
gcc-4.3-20080925 is now available
Snapshot gcc-4.3-20080925 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20080925/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.3 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_3-branch revision 140670 You'll find: gcc-4.3-20080925.tar.bz2 Complete GCC (includes all of below) gcc-core-4.3-20080925.tar.bz2 C front end and core compiler gcc-ada-4.3-20080925.tar.bz2 Ada front end and runtime gcc-fortran-4.3-20080925.tar.bz2 Fortran front end and runtime gcc-g++-4.3-20080925.tar.bz2 C++ front end and runtime gcc-java-4.3-20080925.tar.bz2 Java front end and runtime gcc-objc-4.3-20080925.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.3-20080925.tar.bz2The GCC testsuite Diffs from 4.3-20080918 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.3 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Adding to G++: Adding a warning on throwing unspecified exceptions.
> The above works on code::blocks, which uses some form of GCC, and > looks OK to me. > Of course this only works for exactly one exception type. > You'd have to wait for C++0X variadic templates (and hope you can > throw them) if you need zero or more than one. > It's also very verbose, a little cryptic, and nested templates could > make variadic versions horrifically long. > However it's a start. > All these are reasons why such a feature will not be used. Trying to write code with C++ exception specifications has a LOT of problems in addition to things you mentioned above i can think of a few: * It is VERY difficult to get correct (compounded across platforms and versions of libraries/compilers, or with different compile time options etc that may cause different exceptions to be thrown) * It has the great feature, where if you do get it wrong it likes to call that lovely terminate function (Dripping with sarcasm...) * Maintaining code with such specifications is cumbersome and a LOT of work (I tried it). * A lot of difficulties arise in the presence of templates in determining what exceptions may be thrown (And solutions described are cumbersome) * There is no compile time assertion of compliance (This is solved by EDoc++, but may also be solved in part by the warning feature being proposed). This is where Java differs, it has a compile time compliance that "non-runtime" exceptions are specified/handled. But as i understand it no runtime assertion (it is not needed). Where as C++ is the exact opposite. This brings across the important point about "runtime" exceptions. In Java they do not need to be specified in an exception specifier, they will just propagate out the function and may be handled somewhere (or crash out the main entry point). In C++ if you add some exceptions to the specifier, but forget/omit the runtime ones, then your program will be terminated early, there is no option for other code to actually handle that exception (std::bad_exception in my opinion is a bad substitute in this situation). What is the benefit of exception specifiers that can not be provided with documentation (I am sure there are some or they wouldn't have been added to the standard, but i have become dis-enchanted with exception specifiers)? The only thing i can think of is optimization, and that is discussed by the boost page on exception specifiers mentioned earlier. It has been a while since i have looked in detail on this topic. Initially EDoc++ was written so that i could then go and write all my C++ code with exception specifiers and then use EDoc++ to enforce them (I wanted to reproduce what Java had for C++). But even though EDoc++ can enforce such usage, to actually write code that lists all its exception specifiers is just WAY too much work and there is no or little gain that i can see from doing so. As a result, EDoc++ has evolved to cover different aspects of exception usage analysis and the initial purposes of it i rarely use. What i mentioned in an earlier post is that rather than a function specify what it can throw, i propose that for the C++ community a more useful compile time assertion is to allow code that uses a function to define what exceptions it can deal with that function throwing. I.e. moving the contract from the used to the user. I noticed when i started to become aware of writing exception safe code, that i would be acutely aware that certain portions of code i was using needed to have particular exception requirements (Such as the nothrow destructor, or i use certain members of the std::list or pointers as they have a number of no-throw operations). I can not enforce that say some client code include exception specifiers, but i can modify my code to define the contract that i require of them. Then i could use EDoc++ or some other similar tool to tell me if those contracts have not been met. If they are not, then i either request change in the client code or change the way i use them. With all this in mind, i think that the proposed warning will not be used by many and will not shape the future of C++ due primarily with the issues inherent in the C++ language definition of how exception specifiers work. I do however think as i mentioned before that it would make a great project to learn more about GCC internals and would encourage giving it a try on those grounds. Brendon.
Re: ACATS Target Requirement Question
> RTEMS has BSPs for a couple of simulators that > do not have a source for clock tick interrupts. > We simulate the passage of time by having a special > IDLE task advance time. This works well enough > when all tasks block but if a test depends on > something like timeslice expiration, that won't > happen. > > My questions are... > > + Is this sufficient to pass a reasonable subset > of the ACATS? It should be, since standard Ada semantics assume no timeslicing, and run-until-blocked semantics, which is basically what you described above. Arno
