From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by kanga.kvack.org (Postfix) with ESMTP id 3D5406B0032 for ; Fri, 20 Sep 2013 23:14:01 -0400 (EDT) Received: by mail-pa0-f44.google.com with SMTP id lf10so150038pab.31 for ; Fri, 20 Sep 2013 20:14:00 -0700 (PDT) References: <1379445730.79703.YahooMailNeo@web172205.mail.ir2.yahoo.com> <1379550301.48901.YahooMailNeo@web172202.mail.ir2.yahoo.com> <20130919041451.GA2082@hp530> Message-ID: <1379733236.53557.YahooMailNeo@web172201.mail.ir2.yahoo.com> Date: Sat, 21 Sep 2013 04:13:56 +0100 (BST) From: Max B Reply-To: Max B Subject: Re: shouldn't gcc use swap space as temp storage?? In-Reply-To: <20130919041451.GA2082@hp530> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="2036796846-1751807674-1379733236=:53557" Sender: owner-linux-mm@kvack.org List-ID: Cc: "linux-mm@kvack.org" --2036796846-1751807674-1379733236=:53557 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable =0A=0A=0AVladimir,=0A=0Amany thanks for pointing out that C99 is not my nat= ive tongue.=0A=0AI plan to submit another segment of code -- this time in g= uaranteed non-buggy gfortran -- which shows similar behaviour to the buggy = gcc code.=A0 In fact the code was originally conceived and written in gfort= ran, and I attempted (with evident failure as you so graciously point out) = to translate it into gcc (seen below) for this linux-mm audience.=0A=0A=0AI= hope to gain productive feedback on the causes of the observed behaviour ,= and its solution, at this listserv because 1) the gfortran code is not bug= gy and 2) I believe the linux-memory management listserv is the correct for= um.=0A=0AI gather that many on this newsgroup may not have installed gfortr= an by default, but quite possibly someone will be curious to see if s/he ca= n replicate the observed behaviour, and either suggest a workaround or flag= it as a feature.=0A=0A=0ACheers,=0AMax=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A______= __________________________=0A De=A0: Vladimir Murzin = =0A=C0=A0: Max B =0ACc=A0: "linux-mm@kvack.org" =0AEnvoy=E9 le : Jeudi 19 septembre 2013 6h14=0AObjet=A0: Re: sh= ouldn't gcc use swap space as temp storage??=0A =0A=0AOn Thu, Sep 19, 2013 = at 01:25:01AM +0100, Max B wrote:=0A> =0A> =0A> =0A> =0A> =0A> =0A> Hi All,= =0A> =0A> See below for executable program.=0A> =0A> =0A> Shouldn't gcc use= swap space as temp storage?=A0 Either my machine is set up improperly, or = gcc does not (cannot?) access this capability.=0A> =0A> =0A> It seems to me= that programs should be able to access swap memory in these cases, but the= behaviour has not been confirmed.=0A> =0A> Can someone please confirm or c= orrect me?=0A> =0A=0AIt is not because your machine settings or gcc. Your c= ode is buggy.=0A=0A> =0A> Apologies if this is not the correct listserv for= the present discussion.=0A> =0A=0AI think the proper list for C related qu= estions is linux-c-programming or similar.=0A=0AVladimir=0A=0A> =0A> Thanks= for any/all help.=0A> =0A> =0A> Cheers,=0A> Max=0A> =0A> =0A> /*=0A> =A0* = This program segfaults with the *bar array declaration.=0A> =A0*=0A> =A0* I= wonder why it does not write the *foo array to swap space=0A> =A0* then us= e the freed ram to allocate *bar.=0A> =A0*=0A> =A0* I have explored the she= ll ulimit parameters to no avail.=0A> =A0*=0A> =A0* I have run this as root= and in userland with the same outcome.=0A> =A0*=0A> =A0* It seems to be a = problem internal to gcc, but may also be a kernel issue.=0A> =A0*=0A> =A0*/= =0A> =0A> #include =0A> #include =0A> =0A> #define NMAX = 628757505=0A> =0A> int main(int argc,char **argv) {=0A> =A0 float *foo,*bar= ;=0A> =0A> =A0 foo=3Dcalloc(NMAX,sizeof(float));=0A> =A0 fprintf(stderr,"%9= .3f %9.3f\n",foo[0],foo[1]);=0A> #if 1=0A> =A0 bar=3Dcalloc(NMAX,sizeof(flo= at));=0A> =A0 fprintf(stderr,"%9.3f %9.3f\n",bar[0],bar[1]);=0A> #endif=0A>= =0A> =A0 return=0A>=A0 0;=0A> } --2036796846-1751807674-1379733236=:53557 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable


Vladimir,


I plan to submit another segment of code -- th= is time in guaranteed non-buggy gfortran -- which shows similar behaviour t= o the buggy gcc code.  In fact the code was originally conceived and w= ritten in gfortran, and I attempted (with evident failure as you so graciou= sly point out) to translate it into gcc (seen below) for this linux-mm audi= ence.

I hope to gain productive feed= back on the causes of the observed behaviour , and its solution, at this li= stserv because 1) the gfortran code is not buggy and 2) I believe the linux-memory management listserv is the correct forum.

=
I gather that many on this newsgroup may not have installed= gfortran by default, but quite possibly someone will be curious to see if = s/he can replicate the observed behaviour, and either suggest a workaround = or flag it as a feature.

Cheers,
Max




=


De : Vladimir Murzin <mu= rzin.v@gmail.com>
=C0 : Max B <txtmb@yahoo.fr>
Cc := "linux-mm@kvack.org" <linux-mm@kvack.org>
Envoy=E9 le : Jeudi 19 septembre 201= 3 6h14
Objet : Re= : shouldn't gcc use swap space as temp storage??

On Thu, Sep 19, 2013 at 01:25:01AM +0100, Max B= wrote:
>
>
>
>
>
>
> Hi Al= l,
>
> See below for executable program.
>
>
= > Shouldn't gcc use swap space as temp storage?  Either my machine = is set up improperly, or gcc does not (cannot?) access this capability.
= >
>
> It seems to me that programs should be able to acces= s swap memory in these cases, but the behaviour has not been confirmed.
= >
> Can someone please confirm or correct me?
>

It = is not because your machine settings or gcc. Your code is buggy.

> =
> Apologies if this is not the correct listserv for the present disc= ussion.
>

I think the proper list for C related questions is = linux-c-programming or similar.

Vladimir

>
> Thanks= for any/all help.
>
>
> Cheers,
> Max
> >
> /*
>  * This program segfaults with the *bar arr= ay declaration.
>  *
>  * I wonder why it does not wr= ite the *foo array to swap space
>  * then use the freed ram to = allocate *bar.
>  *
>  * I have explored the shell ul= imit parameters to no avail.
>  *
>  * I have run thi= s as root and in userland with the same outcome.
>  *
> &n= bsp;* It seems to be a problem internal to gcc, but may also be a kernel is= sue.
>  *
>  */
>
> #include <stdio.h>
> #include <stdlib.h>
>
> #define= NMAX 628757505
>
> int main(int argc,char **argv) {
> &= nbsp; float *foo,*bar;
>
>   foo=3Dcalloc(NMAX,sizeof(flo= at));
>   fprintf(stderr,"%9.3f %9.3f\n",foo[0],foo[1]);
>= #if 1
>   bar=3Dcalloc(NMAX,sizeof(float));
>   fpri= ntf(stderr,"%9.3f %9.3f\n",bar[0],bar[1]);
> #endif
>
> =   return
>  0;
> }


<= /div> --2036796846-1751807674-1379733236=:53557-- -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org