On Wednesday 27 February 2008 03:06, J.C. Pizarro wrote:
> Compiling and executing the code of Nick Piggin at
> http://gcc.gnu.org/ml/gcc/2008-02/msg00601.html
>
> in my old Athlon64 Venice 3200+ 2.0 GHz,
> 3 GiB DDR400, 32-bit kernel, gcc 3.4.6, i got
>
> $ gcc -O3 -falign-functions=64 -falign-loo
Ross Ridge wrote:
Ross Ridge writes:
On Unix-like systems you can catch SIGABRT, but even there how do you
tell that it didn't come from CTRL-\...
Oops, I forgot that CTRL-\ had it own signal SIGQUIT.
Ross Ridge
In fact I suspect that once you stop si
Ross Ridge writes:
> On Unix-like systems you can catch SIGABRT, but even there how do you
> tell that it didn't come from CTRL-\...
Oops, I forgot that CTRL-\ had it own signal SIGQUIT.
Ross Ridge
Andi Kleen wrote:
[EMAIL PROTECTED] (Ross Ridge) writes:
Easy: The signal frame that is passed as an argument to the signal handler
has a trapno member than will contain 4 for INTO. The only other case where
it would contain 4 would be a explicit int 4
OK, so that's exactly what is needed i
[EMAIL PROTECTED] (Ross Ridge) writes:
> Robert Dewar writes:
> >Yes, and that is what we would want for Ada, so I am puzzled by your
> >sigh. All Ada needs to do is to issue a constraint_error exception,
> >it does not need to know where the exception came from or why except
> >in very broad deta
On Mon, Mar 03, 2008 at 09:29:18AM +1100, Greg Schafer wrote:
> The following patch restores the old behaviour and fixes my build.
I for one would not like to see us go back to the old broken
behaviour. One rather nice result of Carlos' fix is that you can now
build a sysrooted compiler on a nati
I gave up with DF and instead went through function tree argument to
rediscover argument registers.
It was then simple matter to exclude these from epilog/prolog registers
saves/restores.
The patches is posted - and seem quite portable to other targets.
http://gcc.gnu.org/ml/gcc-patches/200
Ross Ridge wrote:
Robert Dewar writes:
Yes, and that is what we would want for Ada, so I am puzzled by your
sigh. All Ada needs to do is to issue a constraint_error exception,
it does not need to know where the exception came from or why except
in very broad detail.
Unless printing "This appli
On Sun, Mar 02, 2008 at 01:17:02PM -0500, Carlos O'Donell wrote:
> Greg Schafer wrote:
> >Hi Carlos and Mark,
> >
> >Your "Relocated compiler should not look in $prefix" patch here:
> >
> >http://gcc.gnu.org/ml/gcc/2006-10/msg00280.html
> >
> >appears to have caused a regression in my GCC 4.3 testi
Robert Dewar writes:
>Yes, and that is what we would want for Ada, so I am puzzled by your
>sigh. All Ada needs to do is to issue a constraint_error exception,
>it does not need to know where the exception came from or why except
>in very broad detail.
Unless printing "This application has request
Robert Dewar write:
But, once again, using the processor specific JO instruction will be
much better for Ada than double length arithmetic, using JO does not
involve a "program crash with a vague exception".
*sigh* The possibility of using GCC's -ftrapv support to implement
overlow exception
Robert Dewar write:
>Usually there are ways of telling what is going on at a sufficiently
>low level, but in any case, code using the conditional jump instruction
>(jo/jno) is hugely better than what we do now (and it is often faster
>to usea jo than into).
Ross Ridge wrote:
>My point is that us
Dear all,
Here is a patch that give us caret diagnostics in C/C++. There a lot
of things that can be improved but because I wanted to get some
feedback with my current approach.
Basically, I store a pointer linebuf in the line_map structure to a
character in the input file buffer. The character c
Ross Ridge wrote:
Robert Dewar write:
Usually there are ways of telling what is going on at a sufficiently
low level, but in any case, code using the conditional jump instruction
(jo/jno) is hugely better than what we do now (and it is often faster
to usea jo than into).
My point is that using
Robert Dewar write:
>Usually there are ways of telling what is going on at a sufficiently
>low level, but in any case, code using the conditional jump instruction
>(jo/jno) is hugely better than what we do now (and it is often faster
>to usea jo than into).
My point is that using INTO or some othe
Ross Ridge wrote:
Actually, that's a different issue than catching 100% of overflows,
which apparently Ada doesn't require.
Well basically Ada does require catching all overflows, the only issue
is the optimization issue that we already discussed, it would be
acceptable to not catch this. How
Mark Mitchell writes:
> However, I don't think doing all of that work is required to make this
> feature useful to people. You seem to be focusing on making -ftrapv
> capture 100% of overflows, so that people could depend on their programs
> crashing if they had an overflow. That might be usef
Steven Bosscher wrote:
There has been at least one incident of a software bug in certified
code, but it is very rare, and the record is impressive (no life
has been lost because of a software bug in the history of commercial
aviation).
I agree with all you've said so far, but this statement abo
Greg Schafer wrote:
Hi Carlos and Mark,
Your "Relocated compiler should not look in $prefix" patch here:
http://gcc.gnu.org/ml/gcc/2006-10/msg00280.html
appears to have caused a regression in my GCC 4.3 testing.
In summary, there is a small window *during the GCC build itself* where GCC
does
> There has been at least one incident of a software bug in certified
> code, but it is very rare, and the record is impressive (no life
> has been lost because of a software bug in the history of commercial
> aviation).
I agree with all you've said so far, but this statement above is a bit
too op
Frank Ch. Eigler wrote:
Hi -
On Sun, Mar 02, 2008 at 10:20:30AM -0500, Robert Dewar wrote:
[...]
(Off topic, but I'd expect that avionics software is engineered with
enough layers of protection, including catching traps, so that a
-ftrapv hit would not cause a deep impact.)
As I say, it is mo
Hi -
On Sun, Mar 02, 2008 at 10:20:30AM -0500, Robert Dewar wrote:
> [...]
> >(Off topic, but I'd expect that avionics software is engineered with
> >enough layers of protection, including catching traps, so that a
> >-ftrapv hit would not cause a deep impact.)
>
> As I say, it is more usual in a
(Off topic, but I'd expect that avionics software is engineered with
enough layers of protection, including catching traps, so that a
-ftrapv hit would not cause a deep impact.)
Actually this discussion is not *so* off-topic.
if you regard -ftrapv as something that would be enabled in critica
Frank Ch. Eigler wrote:
Hi -
On Sun, Mar 02, 2008 at 09:30:25AM -0500, Robert Dewar wrote:
[...] Safety-critical and security-critical software are two
totally different concepts. Be careful not to confuse them. In
safety-critical software, e.g. avionics system, it is not acceptable
for the s
Hi -
On Sun, Mar 02, 2008 at 09:30:25AM -0500, Robert Dewar wrote:
> [...] Safety-critical and security-critical software are two
> totally different concepts. Be careful not to confuse them. In
> safety-critical software, e.g. avionics system, it is not acceptable
> for the system to crash. In
Frank Ch. Eigler wrote:
Mark Mitchell <[EMAIL PROTECTED]> writes:
[...] You seem to be focusing on making -ftrapv capture 100% of
overflows, so that people could depend on their programs crashing if
they had an overflow. That might be useful in two circumstances:
(a) getting bugs out (though
Mark Mitchell <[EMAIL PROTECTED]> writes:
> [...] You seem to be focusing on making -ftrapv capture 100% of
> overflows, so that people could depend on their programs crashing if
> they had an overflow. That might be useful in two circumstances:
> (a) getting bugs out (though for an example lik
On Sun, Mar 2, 2008 at 2:00 PM, Joseph S. Myers <[EMAIL PROTECTED]> wrote:
> On Sat, 1 Mar 2008, Richard Guenther wrote:
>
> > I missed once point noticed by Joseph also, that the libgcc implementation
> > uses signed types in the implementation of the trapping arithmetics.
> > Where we of cours
On Sat, 1 Mar 2008, Richard Guenther wrote:
> I missed once point noticed by Joseph also, that the libgcc implementation
> uses signed types in the implementation of the trapping arithmetics.
> Where we of course optimize away the overflow check, so the libgcc
> routines will never trap. (if it d
Richard Guenther wrote:
Nice plan. Though I doubt that even this simple one will be carried out,
as even the simple bugs in the current implementation stay around for at
least 5 years.
Well let's see .. we (AdaCore) will try to focus more attention on this
to evaluate whether it is feasible t
> I agree with everything you've written, including, in particular, that
> making this explicit in the IL (via special tree codes for, e.g.,
> trapping-add) would be best.
I'd be in favor of flags rather than new codes. For the most part, all
processing of non-trapping operations and trapping o
Mark Mitchell wrote:
However, I don't think doing all of that work is required to make this
feature useful to people. You seem to be focusing on making -ftrapv
capture 100% of overflows, so that people could depend on their programs
crashing if they had an overflow. That might be useful in t
On Sun, 2 Mar 2008, Mark Mitchell wrote:
> Joseph S. Myers wrote:
>
> > > > int f(int a, int b) { return 0 * (a + b); }
>
> > They are the natural interpretation of -ftrapv that's simplest to describe
> > in terms of the abstract machine of the C standard: any signed integer
> > arithmetic overf
Joseph S. Myers wrote:
int f(int a, int b) { return 0 * (a + b); }
They are the natural interpretation of -ftrapv that's simplest to describe
in terms of the abstract machine of the C standard: any signed integer
arithmetic overflow in the abstract machine (and maybe integer division by
0,
Jack Howarth wrote:
Do we have any other targets that link gcc (and xgcc)
with the shared libgcc? I see that i386 and x86_64 linux
creates a gcc (and xgcc) linked to the static libgcc.
If any other targets use a shared libgcc for gcc (and xgcc)
they may be broken as well.
That's a good hint
35 matches
Mail list logo
