--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last recon
--- Comment #11 from manu at gcc dot gnu dot org 2007-11-21 13:45 ---
(In reply to comment #10)
> > Then I humbly think you should have clearly stated that in your email and
> > asked people interested in the patch to ping the relevant maintainers on
> > your behalf.
>
> That's what I'v
--- Comment #10 from ebotcazou at gcc dot gnu dot org 2007-11-21 13:34
---
> Then I humbly think you should have clearly stated that in your email and
> asked people interested in the patch to ping the relevant maintainers on
> your behalf.
That's what I've sort of done in the second s
--- Comment #9 from manu at gcc dot gnu dot org 2007-11-21 13:17 ---
(In reply to comment #8)
> > Why don't you ping directly the relevant maintainers?
>
> Probably because I have other things more interesting to do. :-)
>
Then I humbly think you should have clearly stated that in you
--- Comment #8 from ebotcazou at gcc dot gnu dot org 2007-11-21 12:40
---
> Why don't you ping directly the relevant maintainers?
Probably because I have other things more interesting to do. :-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34118
--- Comment #7 from manu at gcc dot gnu dot org 2007-11-21 12:34 ---
(In reply to comment #5)
>
> AdaCore has done it on 7 architectures and is ready to contribute this code,
> see http://gcc.gnu.org/ml/gcc-patches/2006-11/msg01846.html
Why don't you ping directly the relevant maintain
--- Comment #6 from ludovic at ludovic-brenta dot org 2007-11-21 10:44
---
I note that this (impressive) patch is not in mainline yet; it seems nobody has
reviewed it yet. In the patch, you say: "-fstack-check is broken in the 4.x
series of compilers in the sense that you cannot recove
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2007-11-20 15:37
---
> 1) If Targparm.Stack_Check_Probes_On_Target is False (i.e. the "GNAT
> Stack-limit checking" is in effect), what circumstances would cause the
> stack check to not detect an overflow (i.e. "unreliable stack chec
--- Comment #4 from ludovic at ludovic-brenta dot org 2007-11-20 12:31
---
Questions:
1) If Targparm.Stack_Check_Probes_On_Target is False (i.e. the "GNAT
Stack-limit checking" is in effect), what circumstances would cause the stack
check to not detect an overflow (i.e. "unreliable sta
--- Comment #3 from pinskia at gmail dot com 2007-11-16 20:26 ---
Subject: Re: Please enable stack checking (-fstack-check) by default
On 16 Nov 2007 18:35:15 -, ebotcazou at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
> That's not true of probes in general, only of the generic
On 16 Nov 2007 18:35:15 -, ebotcazou at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
> That's not true of probes in general, only of the generic implementation of
> the probing method in GCC. The implementation on Alpha/Tru64 doesn't suffer
> from this defect for example.
Or even the spu-el
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2007-11-16 18:35
---
> GCC supports two ways to implement stack overflow checks: using guard pages
> called "probes", and inserting stack checking code into every subprogram.
That's confused. Probes are not "guard pages" and you alw
--- Comment #1 from niklas dot holsti at tidorum dot fi 2007-11-16 18:19
---
It would certainly be in the Ada spirit to have stack-checking enabled by
default.
If GCC offers a selection of stack-checking methods, I think the default method
should be the most reliable and general one, e
13 matches
Mail list logo
