True "no-exceptions" mode?
Hi, I am needing a truly exceptions-clean (or exceptions-free) binary due to some embedding systems platform. -fno-exceptions is not enough of course. I am thinking about taking the concept to the backend through multilibs: add some general -mno-exceptions or alike so there can be a selectable multilib compiled without any kind of exceptions. Of course that there should be more things of both front-end and library addressed, such as: - dynamic_cast of references shall not be permitted in this mode (so no bad_cast is possible). - .at() of containers disabled (e.g. vector::at()) - operator new shall be always nothrow I am going to create a discussion in the C++ committee as well, but I also wanted to create a discussion here. My initial proposal here is: add a -mno-exceptions or alike so that different multilibs can be selected based on the presence/absence of this flag; then, it is implementation-specific what a mulitlib "without exceptions" actually is. I'm now concerned in the flag and providing the selection mechanism only. Comments? Of course once exceptions are addressed, RTTI will be the next feature. Thanks! Daniel. -- Daniel F. Gutson Chief Engineering Officer, SPD San Lorenzo 47, 3rd Floor, Office 5 Córdoba, Argentina Phone: +54 351 4217888 / +54 351 4218211 Skype: dgutson
Re: True "no-exceptions" mode?
On Sun, May 18, 2014 at 1:12 PM, Jonathan Wakely wrote: > >> Comments? > > Sounds like a coding standard not a compiler multilib target. > > If you don't want exceptions don't use them. If the STL is compiled with exceptions support, I can't get rid off its overhead. It's not just about not using them, but to not pay for its overhead (e.g. see newlib). The 0-overhead principle is violated in this case, I'm paying for something I don't use in terms of RAM and cost in HRT applications. That hurts when developing for small-featured RAM boards. However, there could be two builds of the STL, one with exceptions support and another much smaller without; a flag like the one I'm proposing would be useful to select which one to link with in the target fragment file. -- Daniel F. Gutson Chief Engineering Officer, SPD San Lorenzo 47, 3rd Floor, Office 5 Córdoba, Argentina Phone: +54 351 4217888 / +54 351 4218211 Skype: dgutson
Re: True "no-exceptions" mode?
On Sun, 2014-05-18 at 12:33 -0300, Daniel Gutson wrote:
> Hi,
>
>I am needing a truly exceptions-clean (or exceptions-free) binary due to
> some embedding systems platform.
> -fno-exceptions is not enough of course.
Did you think of making some extension (using MELT, see
http://gcc-melt.org/ for more) or some plugin (in C++) which would
at least check that no exception gimple is going thru.
This might be adding a pass which would detect and bark when
exception-related gimples are used.
Regards
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Re: True "no-exceptions" mode?
On Sun, May 18, 2014 at 4:42 PM, Basile Starynkevitch
wrote:
> On Sun, 2014-05-18 at 12:33 -0300, Daniel Gutson wrote:
>> Hi,
>>
>>I am needing a truly exceptions-clean (or exceptions-free) binary due to
>> some embedding systems platform.
>> -fno-exceptions is not enough of course.
>
>
> Did you think of making some extension (using MELT, see
> http://gcc-melt.org/ for more) or some plugin (in C++) which would
> at least check that no exception gimple is going thru.
Yes, but it doesn't help: the problem is NOT in the compiler only, but
in the STL it gets linked with. That's why multilib stuff is required.
>
> This might be adding a pass which would detect and bark when
> exception-related gimples are used.
Can that act as a multilib selector?
>
> Regards
> --
> Basile STARYNKEVITCH http://starynkevitch.net/Basile/
> email: basilestarynkevitchnet mobile: +33 6 8501 2359
> 8, rue de la Faiencerie, 92340 Bourg La Reine, France
> *** opinions {are only mine, sont seulement les miennes} ***
>
>
--
Daniel F. Gutson
Chief Engineering Officer, SPD
San Lorenzo 47, 3rd Floor, Office 5
Córdoba, Argentina
Phone: +54 351 4217888 / +54 351 4218211
Skype: dgutson
gcc-4.10-20140518 is now available
Snapshot gcc-4.10-20140518 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.10-20140518/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.10 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 210592 You'll find: gcc-4.10-20140518.tar.bz2Complete GCC MD5=5e9fe95e6e745e3f194fc1c802be3374 SHA1=8ee022d6f7c804ff025065f16020c1d4e9dee469 Diffs from 4.10-20140511 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.10 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: we are starting the wide int merge
On Sat, 17 May 2014, Richard Sandiford wrote: > To rule out one possibility: which GCC are you using for stage1? I think that may the smoking gun. When I use GCC 4.7 to bootstrap, FreeBSD 8, 9 and 10 all build fine on i386 (= i486) and amd64. When I use the system compiler, which is GCC 4.2 on FreeBSD 8 and 9 and clang on FreeBSD 10, things fail on FreeBSD 10... ...with a bootstrap comparison failure of stages 2 and 3 on i386: https://redports.org/~gerald/20140518230801-31619-208277/gcc410-4.10.0.s20140518.log ...and an interesting failure on amd64: https://redports.org/~gerald/20140518230801-31619-208275/gcc410-4.10.0.s20140518.log In file included from .././../gcc-4.10-20140518/gcc/xcoffout.c:29: .././../gcc-4.10-20140518/gcc/tree.h:4576:3: warning: extraneous template parameter list in template specialization template <> ^~~ .././../gcc-4.10-20140518/gcc/wide-int.cc:1274:23: error: invalid use of a cast in a inline asm context requiring an l-value: remove the cast or build with -fheinous-gnu-extensions umul_ppmm (val[1], val[0], op1.ulow (), op2.ulow ()); ~~~^ This means this clang-based system is not able to bootstrap GCC trunk on amd64. Perhaps looking into this first may affect the failure on i486? Gerald
negative latencies
Are there hooks in gcc to deal with negative latencies? In other words, an architecture that permits an instruction to use a result from an instruction that will be issued later. At first glance it seems that it will will break a few things. 1) The definition of dependencies cannot come from the simple ordering of rtl. 2) The scheduling problem starts to look like "get off the train 3 stops before me". 3) The definition of live ranges needs to use actual instruction timing information, not just instruction sequencing. The hooks in the scheduler seem to be enough to stop damage but not enough to take advantage of this "feature". Thanks
Re: negative latencies
On Sun, May 18, 2014 at 11:13 PM, shmeel gutl wrote: > Are there hooks in gcc to deal with negative latencies? In other words, an > architecture that permits an instruction to use a result from an instruction > that will be issued later. Do you mean bypasses? If so there is a bypass feature which you can use: https://gcc.gnu.org/onlinedocs/gccint/Processor-pipeline-description.html#index-data-bypass-3773 Thanks, Andrew Pinski > > At first glance it seems that it will will break a few things. > 1) The definition of dependencies cannot come from the simple ordering of > rtl. > 2) The scheduling problem starts to look like "get off the train 3 stops > before me". > 3) The definition of live ranges needs to use actual instruction timing > information, not just instruction sequencing. > > The hooks in the scheduler seem to be enough to stop damage but not enough > to take advantage of this "feature". > > Thanks >
Re: we are starting the wide int merge
Gerald Pfeifer writes:
> On Sat, 17 May 2014, Richard Sandiford wrote:
>> To rule out one possibility: which GCC are you using for stage1?
>
> I think that may the smoking gun. When I use GCC 4.7 to bootstrap,
> FreeBSD 8, 9 and 10 all build fine on i386 (= i486) and amd64.
>
> When I use the system compiler, which is GCC 4.2 on FreeBSD 8 and 9
> and clang on FreeBSD 10, things fail on FreeBSD 10...
>
> ...with a bootstrap comparison failure of stages 2 and 3 on i386:
> https://redports.org/~gerald/20140518230801-31619-208277/gcc410-4.10.0.s20140518.log
Do you get exactly the same comparison failures using clang and GCC 4.2
as the stage1 compiler? That would rule out the system compiler
miscompiling stage1.
> In file included from .././../gcc-4.10-20140518/gcc/xcoffout.c:29:
> .././../gcc-4.10-20140518/gcc/tree.h:4576:3: warning: extraneous template
> parameter list in template specialization
> template <>
> ^~~
Oops, fixed below, applied as obvious.
> .././../gcc-4.10-20140518/gcc/wide-int.cc:1274:23: error: invalid use of a
> cast in a inline asm context requiring an l-value: remove the cast or
> build with -fheinous-gnu-extensions
> umul_ppmm (val[1], val[0], op1.ulow (), op2.ulow ());
> ~~~^
This is PR 61146. You can get around it by adding -fheinous-gnu-extensions
to BOOT_CFLAGS.
> This means this clang-based system is not able to bootstrap GCC trunk
> on amd64.
>
> Perhaps looking into this first may affect the failure on i486?
'Fraid it won't help. We don't use umul_ppmm (or even include
longlong.h) for 486.
Thanks,
Richard
gcc/
* tree.h: Remove extraneous template <>.
Index: gcc/tree.h
===
--- gcc/tree.h 2014-05-19 07:45:30.378667987 +0100
+++ gcc/tree.h 2014-05-19 07:46:07.364991104 +0100
@@ -4573,7 +4573,6 @@ #define ANON_AGGRNAME_FORMAT "__anon_%d"
unsigned int get_len () const;
};
- template <>
template
struct int_traits >
{
Re: negative latencies
On 19-May-14 09:39 AM, Andrew Pinski wrote: On Sun, May 18, 2014 at 11:13 PM, shmeel gutl wrote: Are there hooks in gcc to deal with negative latencies? In other words, an architecture that permits an instruction to use a result from an instruction that will be issued later. Do you mean bypasses? If so there is a bypass feature which you can use: https://gcc.gnu.org/onlinedocs/gccint/Processor-pipeline-description.html#index-data-bypass-3773 Thanks, Andrew Pinski Unfortunately, bypasses in the pipeline description is not enough. They only allow you to calculate the latency of true dependencies. They are also forced to be zero or greater. The real question is how the scheduler and register allocator can deal with negative latencies. Thanks Shmeel At first glance it seems that it will will break a few things. 1) The definition of dependencies cannot come from the simple ordering of rtl. 2) The scheduling problem starts to look like "get off the train 3 stops before me". 3) The definition of live ranges needs to use actual instruction timing information, not just instruction sequencing. The hooks in the scheduler seem to be enough to stop damage but not enough to take advantage of this "feature". Thanks - No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4577 / Virus Database: 3950/7515 - Release Date: 05/18/14
