Re: Stack checking in GNAT

[anon@anon.org (anon)]

If you compile using the option "-fstack-check", the statement

pragma Suppress ( Storage_Check ) ;

will NOT turn this feature off, the compile will still generate 
calls to check the stack. Once the "-fstack-check" is enable, it 
can only be disable by using a different compiler or recompiling 
the GNAT1 aka GNAT1DRV.

So, making this option mandatory default is wrong.

Reasons:
        In some college courses, some profs create an assignment 
        to test the performance of a number of languages using 
        the same algorithm.  If GNAT has stack checking and the 
        others languages do not, (C in Linux will never have this 
        default because it will kill rebuilding the Linux Kernel) 
        it will only demonstrate to the students and prof that 
        Ada is a inefficient language to use. Which will decrease 
        the number of new students wanting to using Ada after that 
        class. And that will be one thing that will insure the 
        death of Ada.

        Then there is Adacore reason for having some of the default 
        features the way they are, since the GNAT Ada is provided 
        as an academic compiler. First, Adacore states that the GPL 
        version of GNAT is for academic usage. Second, it helps 
        student by providing a Free complete Ada compiler, with a 
        few features that may need to be altered like "-gnato". Which 
        the student can either work around by writing better code or 
        modifying the compiler in an advance class. But if all of the 
        default features are fix then you basically have the GNAT PRO 
        compiler without the extra Run-Time Libraries. In this case,
        Adacore could just shutdown the free source version or go out 
        of business. Note: They own the copyright to the GNAT Ada 
        compiler, so they can have all version pulled from the net.

        Adjusting the stack check default option would destroy using 
        GNAT as the core compiler for Real-Time projects such as 
        RTEMS, or MaRTE which are primarily written in Ada. These 
        projects depends upon a number of factors to maximize the 
        execution speed of the code, as well as having full control of 
        the language checks. Forcing the stack check will slow the 
        code to the point, that users will just change to other free 
        real-time projects that are non Ada. Killing Ada for these 
        type of free projects.

        Also which GNAT will be altered.  The GNU GCC version only or 
        will this include the versions at sourceforge, and what about 
        the master copy at Adacore. If Adacore rejects these changes 
        what will happen on their next release.  Will these changes 
        work or have to be reworked or be removed.

This type changes should for a personal, school, or company choice only, 
never for implementation that is being used by many different group and 
needs.

And as for making a comment to "http://gcc.gnu.org/bugzilla", Why? 
This is not a BUG, but some people's desire to hurt the true nature of 
Ada and Adacore's GPL GNAT compiler.

What we should be doing is to strengthen the GCC/GPL GNAT compiler 
to be true "to the nature of Ada". And there are a number of fixes that 
are needed.



In <874pfm2vgb.fsf@ludovic-brenta.org>, Ludovic Brenta <ludovic@ludovic-brenta.org> writes:
>Samuel Tardieu writes:
>> Ludovic> Also I am curious to know what would be the effect of
>> Ludovic> changing these flags in Debian.
>>
>> The effect would be disastrous for people handling bug reports from
>> Debian users submitted to http://gcc.gnu.org/bugzilla/ :)
>>
>> If you want to change a flag, I would suggest that you try to get it
>> changed in the GCC distribution rather than doing Debian specific
>> changes.
>
>OK.  I have filed two new bug reports in GCC's bugzilla:
>
>http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34117
>http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34118
>
>If you support these requests, please post a comment in these bugs.
>The more supporters, the more likely it is that GCC maintainers will
>accept the change.  I anticipate some opposition, too, along the lines
>of "it breaks backward compatibility" and "it is too CPU-intensive".
>
>-- 
>Ludovic Brenta.