[vta, trunk] don't leak uninitialized stack state into output

When building certain initializers, the Fortran front-end allocates a
buffer on the stack, sets up some elements of it from the source of the
initialization, and then proceeds to use the entire buffer to initialize
a larger destination.  The result is that the uninitialized portion of
the buffer leaks into the program output.

I figured zero-initializing the entire buffer would often be pointless,
so I decided to initialize only the portion that wasn't covered by the
source.

I'm pretty sure this was caught in a testsuite run with -fcompare-debug,
but I don't recall the exact testcase 

I'm installing this in the branch.  Ok for trunk?

for  gcc/ChangeLog.vta
from  Alexandre Oliva <aoliva <at> redhat.com>

	* fortran/simplify.c (gfc_simplify_transfer): Zero-initialize
	unused portions of the buffer.

Index: gcc/fortran/simplify.c
===================================================================
--- gcc/fortran/simplify.c.orig	2008-12-10 03:13:26.000000000 -0200
+++ gcc/fortran/simplify.c	2008-12-15 03:54:04.000000000 -0200
@@ -4432,6 +4432,7 @@ gfc_simplify_transfer (gfc_expr *source,
   size_t result_size;
   size_t result_elt_size;

[PATCH, java, fortran] Merge help texts for duplicate options.

Hello,

Currently, some switches are documented more than once.  The opt*.awk
machinery currently picks one arbitrarily, for -v --help output (see
the other patch on gcc-patches that ensures that at least one of them
is picked).

This patch attempts to sort out the duplicates manually.  I found this
a bit nontrivial to do, as for other languages, the help may sound
confusing or may not even be true, so please read carefully.

Changes address Fortran, C, and Java front-ends.

These are the current duplicates found on i686-pc-linux-gnu:

I:
c:       -I <dir>        Add <dir> to the end of the main include path
fortran: -I<directory>   Add a directory for INCLUDE and MODULE searching

Wconversion:
c:       Warn for implicit type conversions that may change a value
fortran: Warn about implicit conversion

Wdeprecated:
c:       Warn about deprecated compiler features
java:    Warn if a deprecated compiler feature, class, method, or field is used

Wsystem-headers:
common:  Do not suppress warnings from system headers
c:       Do not suppress warnings from system headers

Re: [vta, trunk] don't leak uninitialized stack state into output

On Sun, Mar 1, 2009 at 7:17 AM, Alexandre Oliva <aoliva <at> redhat.com> wrote:
> When building certain initializers, the Fortran front-end allocates a
> buffer on the stack, sets up some elements of it from the source of the
> initialization, and then proceeds to use the entire buffer to initialize
> a larger destination.  The result is that the uninitialized portion of
> the buffer leaks into the program output.
>
> I figured zero-initializing the entire buffer would often be pointless,
> so I decided to initialize only the portion that wasn't covered by the
> source.
>
> I'm pretty sure this was caught in a testsuite run with -fcompare-debug,
> but I don't recall the exact testcase 
>
> I'm installing this in the branch.  Ok for trunk?

I think zeroing the buffer completely before using it would match
general programming style more appropriately (there's no
XCALLOCA, but maybe using xcalloc/free would be more appropriate
anyway in case that buffer can get large).

Of course I cannot approve the patch anyway.

Richard.

>
> --
> Alexandre Oliva           http://www.lsd.ic.unicamp.br/~oliva/
> You must be the change you wish to see in the world. -- Gandhi
> Be Free! -- http://FSFLA.org/   FSF Latin America board member

Re: [vta, trunk] don't leak uninitialized stack state into output

Alexandre,

That's verging on obvious.  OK by me.

Thanks for the patch.

Paul

On Sun, Mar 1, 2009 at 11:42 AM, Richard Guenther
<richard.guenther <at> gmail.com> wrote:
> On Sun, Mar 1, 2009 at 7:17 AM, Alexandre Oliva <aoliva <at> redhat.com> wrote:
>> When building certain initializers, the Fortran front-end allocates a
>> buffer on the stack, sets up some elements of it from the source of the
>> initialization, and then proceeds to use the entire buffer to initialize
>> a larger destination.  The result is that the uninitialized portion of
>> the buffer leaks into the program output.
>>
>> I figured zero-initializing the entire buffer would often be pointless,
>> so I decided to initialize only the portion that wasn't covered by the
>> source.
>>
>> I'm pretty sure this was caught in a testsuite run with -fcompare-debug,
>> but I don't recall the exact testcase 
>>
>> I'm installing this in the branch.  Ok for trunk?
>
> I think zeroing the buffer completely before using it would match
> general programming style more appropriately (there's no
> XCALLOCA, but maybe using xcalloc/free would be more appropriate
> anyway in case that buffer can get large).

[Patch, fortran] PR39334 - recursive parameter declaration

This is a simple fix for something of a corner case.  The error
message is not the best but it should more than suffice.

Bootstrapped and regtested on FC9/x86_64 - OK for 4.5?

Paul

2009-03-01  Paul Thomas  <pault <at> gcc.gnu.org>

	PR fortran/39334
	* primary.c (match_kind_param): Return MATCH_NO if the symbol
	has no value.

2009-03-01  Paul Thomas  <pault <at> gcc.gnu.org>

	PR fortran/39334
	* gfortran.dg/recursive_parameter_1.f90: New test.

Index: gcc/testsuite/gfortran.dg/recursive_parameter_1.f90
===================================================================
--- gcc/testsuite/gfortran.dg/recursive_parameter_1.f90	(revision 0)
+++ gcc/testsuite/gfortran.dg/recursive_parameter_1.f90	(revision 0)
@@ -0,0 +1,11 @@
+! { dg-do compile }
+! Tests the fix for PR39334 in which the recursive parameter declaration
+! caused a sgfault.
+!
+! Reported by James van Buskirk on comp.lang.fortran
+!

Re: [Patch, fortran] PR39334 - recursive parameter declaration

Paul Richard Thomas wrote:
> This is a simple fix for something of a corner case.  The error
> message is not the best but it should more than suffice.
> 
> Bootstrapped and regtested on FC9/x86_64 - OK for 4.5?

Ok.  Thanks for the quick fix!

Daniel

> Paul
> 
> 2009-03-01  Paul Thomas  <pault <at> gcc.gnu.org>
> 
> 	PR fortran/39334
> 	* primary.c (match_kind_param): Return MATCH_NO if the symbol
> 	has no value.
> 
> 2009-03-01  Paul Thomas  <pault <at> gcc.gnu.org>
> 
> 	PR fortran/39334
> 	* gfortran.dg/recursive_parameter_1.f90: New test.
> 

--

-- 
Done:  Arc-Bar-Cav-Ran-Rog-Sam-Tou-Val-Wiz
To go: Hea-Kni-Mon-Pri

Re: FORTRAN GCC 4.3.X library

On Wed, 2009-03-04 at 09:05 -0800, Takis Psarogiannakopoulos wrote:

Hi Takis,

a general point: It is probably better to mail fortran <at> gcc.gnu.org
directly, instead of individual developers.  This is more likely to
generate a useful response, or a useful discussion   I've CC:'d my
reply there.

> I am dealing with the gcc 4.3.x sources in a new port and I have a small
> issue with libgfortan :
> 
> In gcc-4.3.x/libgfrotran/generated all fuction arguments seem to have a
> 
> const restrict
> 
> prefix. My compilation fails due to that no defined. What it should be and
> where it should be defined?

This is standard C99.  Libgfortran is supposed to be compiled with
-std=gnu99, and it is also supposed to be built by the recently built
gcc/gfortran.  You can check for -std=gnu99 in the generated Makefile.
If this isn't happening, there is an error in the build machinery for
your system.  Could you maybe supply us with some more details?

	Thomas

Re: FORTRAN GCC 4.3.X library

Thomas,

Thank you for your answer. I didnt email the fortran list cause I thought
its not worth it. I was under the impression I was missing something
something very obvious.
You are right its the -std=c99 that is needed and the const restrict seems
to be the old __restrict right? I must confess thats a very peculiar
name... I have never use it really but i kind rememebr a regression about
that name.
I am using a gcc-4.3.x/config/mh-os file that picks up all the flags and
as this file by default in GCC is being copied "as is" to the main
Makefile can it override all the flags.
-std=gnu99 is defined on libgfortran/Makefile.in/am AM_CFLAGS with other
warnings. As have switched the warnings off from the main config/mh-*
config file the flag -std=gnu99 is not passed to the compile flags.
However the main Makefile has a -D_GNU_SOURCE clearly defined and its
there really it should also have included the -std=gnu99 flag.
Maybe someone can do that change?
If a system doesnt need a -std=gnu99 there is not harm, but if its needed
and its not there the whole compilation fail!

Kind Regards,

On Wed, 4 Mar 2009, Thomas Koenig wrote:

> On Wed, 2009-03-04 at 09:05 -0800, Takis Psarogiannakopoulos wrote:
>
> Hi Takis,
>

Re: FORTRAN GCC 4.3.X library

Takis Psarogiannakopoulos wrote:
> Thomas,
> 
> Thank you for your answer. I didnt email the fortran list cause I thought
> its not worth it. I was under the impression I was missing something
> something very obvious.

The obvious thing, as Thomas mentioned, is that due to the way the GCC 
bootstrap works, libgfortran is designed to be built with the same 
version of the gcc compiler as the library itself.

> You are right its the -std=c99 that is needed and the const restrict seems
> to be the old __restrict right?

restrict is the C99 standardized version of the GNU extension 
__restrict, yes (some other compilers have the same extension with some 
other name such as #pragma noalias and whatnot). const is another 
specifier that is not related to restrict. They are use together in 
libgfortran since the combination implements more or less the Fortran 
argument passing semantics, allowing the compiler to optimize more 
aggressively. And yes, in some cases the performance difference has been 
measured to be significant (search the list archives for details).

> I must confess thats a very peculiar
> name...

It is what it is, I'm pretty sure the gfortran maintainers are not 
interested in trying to convince the ISO C committee to change the name. 
If you wish to tilt at windmills yourself, feel free.

Re: FORTRAN GCC 4.3.X library

On Thu, 5 Mar 2009, Janne Blomqvist wrote:

>
> > I have never use it really but i kind rememebr a regression about
> > that name.
>
> Uh-uh, well that's pretty vague. Is this supposed to convince us to
> remove our usage of restrict, or?

??? The only reason I mention that was that I kind recall some discussions
with Torvalds about the peculiar naming.

>
> Indeed, libgfortran requires the -std=gnu99 flag in order to compile, so
> removing that in one way or another will not allow the library to build.
> But to be honest, I have no idea what you're asking us to actually do
> here, or what your problem really is. You're apparently using gcc 4.3,
> which should handle -std=gnu99 including using 'restrict' just fine.
>
The way that gcc is building at the moment is:
If there is a gcc-x.x.x/config/mh-* file that describes the OS is being
copied as is to the main Makefile aka gcc-x.x.x/Makefile
The idea being long time ago to override flags set by configure scripts
here and there. We of course agree that -std=gnu99 or -std=c99 is needed
to build libgfortran.
The flag at the moment is passed to the build by libgfortran/configure in
which case with the above mechanism it could be overriden, Result you can
never build libgfortran if this happens.
Now I am looking libgfortran/Makefile.in (or am) and see a clearly defined