headers
Vaibhav Kaushal | 1 Dec 2010 07:23
Picon

Wherer is the Segmentation fault?

I am trying to dump a list of simple structure of two fields (roll
number and name of student) into a file but it is failing. here is the
code:

====================================

#include <stdio.h>

//structure of entry
typedef struct {
	int rollno;
	char name[60];
} entry;

entry *newentry;

entry* randomidxval(int x){
	printf("\n Entering randomidxval");
	entry *newentry;
	newentry->rollno = x;
	int i=0;
	for (i=0; i<60; i++) {
		newentry->name[i]=x;
	}
	printf("\n Exiting randomidxval");
	return newentry;
	
}

void create () {
(Continue reading)

Permalink | Reply | 2 comments |
headers
Aubin LaBrosse | 1 Dec 2010 07:31
Picon

Re: Wherer is the Segmentation fault?

In randomidxval - you never malloc entry. 

Sent from my iPhone

On Nov 30, 2010, at 10:23 PM, Vaibhav Kaushal <vaibhavkaushal123 <at> gmail.com> wrote:

> I am trying to dump a list of simple structure of two fields (roll
> number and name of student) into a file but it is failing. here is the
> code:
> 
> ====================================
> 
> #include <stdio.h>
> 
> //structure of entry
> typedef struct {
>    int rollno;
>    char name[60];
> } entry;
> 
> entry *newentry;
> 
> entry* randomidxval(int x){
>    printf("\n Entering randomidxval");
>    entry *newentry;
>    newentry->rollno = x;
>    int i=0;
>    for (i=0; i<60; i++) {
>        newentry->name[i]=x;
>    }
(Continue reading)

Permalink | Reply | 1 comment |
headers
Vaibhav Kaushal | 1 Dec 2010 08:12
Picon

Re: Wherer is the Segmentation fault?

On Tue, 2010-11-30 at 22:31 -0800, Aubin LaBrosse wrote:
> In randomidxval - you never malloc entry. 

Thanks for that sentence. I banged my head 1 hour after this and never
really went looking there. Thanks a lot :)
Permalink | Reply | 0 comments |
headers
Y.Li | 1 Dec 2010 10:50
Picon
Picon
Favicon

about gfortran

Hi,

I installed gfortran in my computer. But when I try to use it in the cmd, it alway says: "gfortran: error:
CreateProcess: No such file or directory". Could you let me know how to solve it?

Thank you very much.

Yuan
Permalink | Reply | 1 comment |
headers
Vincent Lefevre | 1 Dec 2010 12:54

Re: Library search path problem on x86_64 machines (lib64 vs lib)

On 2010-11-30 17:21:35 +0000, Jonathan Wakely wrote:
> Vincent, rather than using LIBRARY_PATH (which doesn't do what you
> want when gcc-4.3.1 decides to look in $LIBRARY_PATH/../lib64) you
> could use -L to ensure it looks in the directories you want.

My example was just a simple test. In the reality, I use things like
configure/make and so on, so that -L is not possible. I also want
to avoid options that would need to be used potentially for any
compilation.

> Or you could add lib64 symlinks pointing to $HOME/gmp/athlon64/lib
> and $HOME/x86_64/lib, so that you get consistent behaviour from
> Debian's gcc and FSF gcc.

Yes, I thought about that. And perhaps add a cron script that would
check that I haven't forgotten anything (that would be useful if I
add a new lib directory in a few years).

Thanks for the answers.

--

-- 
Vincent Lefèvre <vincent <at> vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)
Permalink | Reply | 0 comments |
headers
Jorge PEREZ | 1 Dec 2010 14:44
Picon
Favicon

Re: inline bug (?)

For what is worth I did the test again but this time I separated the
main and f1 in two separate C files. I compiled them separately and then
linked them together. This time the function was never inlined (even if
there is just one or two calls, i.e. NC=1 or 2).

Weird huh?

PS: main and f1 were defined in
http://gcc.gnu.org/ml/gcc-help/2010-11/msg00201.html

jorge.perez <at> invia.fr wrote:
> Thans for your comments guys, I'll follow your suggestions and try other examples and test additional
options as well. 
>
> I forgot to precise however that I used the option -os (optimizing for size)
>
> Regards
>
>
> Jorge
>
> In addition to the comments from Eric:
> On Wed, Nov 17, 2010 at 06:53:28PM +0100, Eric Botcazou wrote:
>   
>>> I appreciate any feedback or suggestions you have about this, maybe I'm
>>> doing it all wrong from the begining, but the fact that inline increases
>>> the size of the code was weird to me.
>>>       
>> The inlining heuristics are complex and tuned for real programs, so it's 
>> probably easy to fool them with toy examples.  Modifying them generally
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eric Botcazou | 1 Dec 2010 14:45
Favicon

Re: inline bug (?)

>  For what is worth I did the test again but this time I separated the main
> and f1 in two separate C files. I compiled them separately and then linked
> them together. This time the function was never inlined (even if there is
> just one or two calls, i.e. NC=1 or 2).

You need LTO (-flto) to inline between different compilation units.

--

-- 
Eric Botcazou
Permalink | Reply | 4 comments |
headers
Mr Dash Four | 1 Dec 2010 14:52

Re: building gcc 4.4.5 from source on Fedora 13


> Why don't you just install the necessary (x86_64 and i686) packages on
> those other machines?
>   
If I am building from source (SRPMs) I expect everything to be built and 
not scramble around looking for additional RPMs which are part of the 
same package I am supposedly building 'from source'.

> Yep, but didn't we already establish you don't need to anyway, you're
> just ranting about a spec file which does what it's designed to do,
> but not what you want?
>   
Aye, if by above you mean that gcc.spec is designed to compile 
sixty-four-bit-only GCC, including support for such commonly-used 
programming languages like ada, GCC-Java (no Fedora distribution should 
be without it!), giving the grant total of zero flexibility to configure 
any part of the GCC built, than gcc.spec does an absolutely marvellous 
job - no question!

Oh, of course, I nearly forgot the tests - watching that mighty, 
freshly-compiled sixty-four-bit-only GCC perform number-crunching for 
two whole hours as part of that built and seeing those numbers roll on 
my screen is just a jot to watch - absolutely magnificent!

If, on the other hand, one wants to build GCC which truly 
cross-compiles, has the ability to exclude languages which are not 
needed during that built (and save some built time in the process), has 
the ability to exclude the tests (which take 2/3 of the build up, no 
less) and expect at the end of that built to have all the necessary GCC 
packages which enable it to function properly - as a cross-compiler,
(Continue reading)

Permalink | Reply | 2 comments |
headers
Jorge PEREZ | 1 Dec 2010 14:57
Picon
Favicon

Re: inline bug (?)

Eric Botcazou wrote:
>>  For what is worth I did the test again but this time I separated the main
>> and f1 in two separate C files. I compiled them separately and then linked
>> them together. This time the function was never inlined (even if there is
>> just one or two calls, i.e. NC=1 or 2).
>>     
>
> You need LTO (-flto) to inline between different compilation units.
>
>   
Not sure if I understood right, but I compiled with -flto in both cases.
Actually it's good that it didn't inline this time because I compiled
with -Os too and inlining would make the code size bigger. It's weird
though that when compiling main and f1 together, f1 is inlined up to 5
times increasing dramatically the code size.
Permalink | Reply | 3 comments |
headers
Jorge PEREZ | 1 Dec 2010 15:01
Picon
Favicon

Re: inline bug (?)

Jorge PEREZ wrote:
> Eric Botcazou wrote:
>   
>>>  For what is worth I did the test again but this time I separated the main
>>> and f1 in two separate C files. I compiled them separately and then linked
>>> them together. This time the function was never inlined (even if there is
>>> just one or two calls, i.e. NC=1 or 2).
>>>     
>>>       
>> You need LTO (-flto) to inline between different compilation units.
>>
>>   
>>     
> Not sure if I understood right, but I compiled with -flto in both cases.
> Actually it's good that it didn't inline this time because I compiled
> with -Os too and inlining would make the code size bigger. It's weird
> though that when compiling main and f1 together, f1 is inlined up to 5
> times increasing dramatically the code size.
>
>   
I replied too fast, sorry.

Just wanted to add that moreover, when main and f1 are compiled together
it has different behaviors if they are in separate files or in the same
file.

When in different files, no inline is done (this is good)
When in the same file, inline is done up to 5 times (weird and bad for
code size)
(Continue reading)

Permalink | Reply | 2 comments |

Gmane