Ad:

C++ Discussion Thread
Unsolved
Views: 7587

Page 1
2
3
Next

You are currently viewing page 1 of this multi-page discussion thread

May 13th, 2006

what's with gcc?

Expand Post »

The following code finds the square root of a number, it runs fine unless you compile with MinGW gcc:

C++ Syntax (Toggle Plain Text)
#include<stdio.h>
#include<stdlib.h>
 
int main(void)
{
	double x0,x1,a;
	int i;	
	x1 = 1;
	x0  = 0;
	printf("\nFind square root of: ");
	scanf("%lf",&a);
	for(i = 0; x0 != x1; ++i)
	{
		x0 = x1;
		x1 = .5 * (x1 + a / x1);
//		printf("\nIteration %d - converging to %lf - prev value %lf",i,x1,x0);
 
	}
 
	printf("Finished");
 
	return 0;
}
#include<stdio.h>
#include<stdlib.h>

int main(void)
{
	double x0,x1,a;
	int i;	
	x1 = 1;
	x0  = 0;
	printf("\nFind square root of: ");
	scanf("%lf",&a);
	for(i = 0; x0 != x1; ++i)
	{
		x0 = x1;
		x1 = .5 * (x1 + a / x1);
//		printf("\nIteration %d - converging to %lf - prev value %lf",i,x1,x0);
		
	}
	
	printf("Finished");
			
	return 0;
}

The problem is if compiled with compilers other than gcc (I have tested it with lcc, visual C++ and borland C++) it reaches "finished" but for gcc it never gets out of the loop. Try to find sqrt of 5, 7 and you will see what I mean. I know about the issues involving comparison of double datatypes, but in this particular case it is guaranteed that x1 will stop changing after certain iterations.

Now for the most interesting part. Uncomment the printf statement within the loop. And you will see everything works fine. I got no clue what's happening inside gcc.

I want to know if anyone's gcc(MinGW) compiler is also behaving the same or not.

Similar Threads

win32 gcc cross compiling for linux target in C
Problem with basic templates on GCC in C++
from gcc to VC++.Net in C++
error when compiling murphy's law with gcc in C
installing vmware tools on mandrake 10 in Linux Applications and Software

Asif_NSU

Reputation Points: 113

Solved Threads: 3

Posting Whiz

Offline

353 posts
since Apr 2004

Permalink

May 13th, 2006

Re: what's with gcc?

works ok with Dev-C++ (version 4.9.9.2 which uses gcc), just had to add getchar() after the scanf() to flush the '\n' out of the keyboard so that I could see the results before the program terminated.

Ancient Dragon

Sponsor

Team Colleague

Featured Poster

Reputation Points: 5608

Solved Threads: 2282

Retired and Enjoying Life

Offline

21,947 posts
since Aug 2005

Permalink

May 13th, 2006

Re: what's with gcc?

> I know about the issues involving comparison of double datatypes
"This is a hole, and I know I'm lying at the bottom of it."
What exactly were you expecting to happen?
If you know about the issues, why didn't you code around them and test on each compiler?

> The problem is if compiled with compilers other than gcc (I have tested it with lcc, visual C++ and borland C++
Proving that your code has undefined behaviour.

> but in this particular case it is guaranteed that x1 will stop changing after certain iterations.
Just because the printf outputs "1.234" and "1.234" does not mean the equivalent numeric test for inequality will fail. Printing things to only 6 digits of precision when doubles have 15 digits of precision is going to entail a certain amount of rounding.

> Uncomment the printf statement within the loop. And you will see everything works fine.
Try printing out the value of i at the end of the loop.
Without printf slowing it down, it's probably executing many 1000's more iterations. Which might mean it eventually stumbles upon convergence.

Adding a final "\n" to your printf would be a good idea as well.

Salem

Team Colleague

Reputation Points: 5862

Solved Threads: 950

Posting Sage

Offline

7,164 posts
since Dec 2005

Permalink

May 13th, 2006

-1

Re: what's with gcc?

C++ Syntax (Toggle Plain Text)
#include <stdio.h>
#include <stdlib.h>
 
int main(void)
{
	float x0,x1,a;
 
	printf("\nFind square root of: ");
	scanf("%f",&a);
 
 
	float t = 10;
	int i;
 
    for(i = 0; i<100; i++)
	{
        t = t - ((t*t - a)/(2*t));
 
		printf("\nIteration %f ",t);
 
	}
 
	printf("Finished\n");
	getchar();
	getchar();
 
	//return 0;
}
#include <stdio.h>
#include <stdlib.h>

int main(void)
{
	float x0,x1,a;

	printf("\nFind square root of: ");
	scanf("%f",&a);
	
	
	float t = 10;
	int i;
	
    for(i = 0; i<100; i++)
	{
        t = t - ((t*t - a)/(2*t));
		
		printf("\nIteration %f ",t);
		
	}
	
	printf("Finished\n");
	getchar();
	getchar();

	//return 0;
}

One more thing, I would use newton's formula for rapid convergence as shown above. It also eliminates the comparison stumbling block.

iamthwee

Featured Poster

Reputation Points: 1536

Solved Threads: 431

Posting Expert

Offline

5,865 posts
since Aug 2005

Permalink

May 13th, 2006

Re: what's with gcc?

Quote ...

"This is a hole, and I know I'm lying at the bottom of it."
What exactly were you expecting to happen?
If you know about the issues, why didn't you code around them and test on each compiler?

There is no hole in my code. I said I am aware of the comparison issue with double/float datatypes. I said so because some of you might jump into the conclusion that checking for inequality between two double datatypes is what's wrong with my code.

Quote ...

Proving that your code has undefined behaviour.

Not necessarily; it could very well be for a bug with the version of gcc I have.

Quote ...

Just because the printf outputs "1.234" and "1.234" does not mean the equivalent numeric test for inequality will fail. Printing things to only 6 digits of precision when doubles have 15 digits of precision is going to entail a certain amount of rounding.

Why did you presume I am relying on the output of printf? Newton raphson method has quadratic convergence which does not require much iteration to get to 15 digits of precision. It is also guranteed that x1 stop changing after certain no of iterations, and when it does that the loop will exit. So I don't see anything wrong with the loop condition.

Quote ...

Try printing out the value of i at the end of the loop.

If I print something within the loop, the program executes just fine. If I don't print anything inside the loop, it seems to go on for ever. THIS weird behaviour is what's bugging me. Do you have the 3.4.2 version of MinGW? Did you try my code with it? If you did, did you see the weird behaviour I mentioned above? That is all I was asking of you.

Quote ...

Adding a final "\n" to your printf would be a good idea as well.

Adding a '\n' to my printf doesn't make the weird behaviour go away, This advice of yours is not only childish but also completely irrelevant to the issue at hand.

Quote ...

works ok with Dev-C++ (version 4.9.9.2 which uses gcc),

The version I am using is 3.4.2 of gcc, I thing DevC++ uses a version greater than 3.4.2. I checked sourcedforge for the latest 'current' version, but it was still 3.4.2. Only the 'candidate' has a newer version.

I still can't explain the way my program is behaving. Why printing inside the loop makes the program work and not printing inside the loop takes it into an infinite loop(when compiled using MinGW gcc version 3.4.2).

Asif_NSU

Reputation Points: 113

Solved Threads: 3

Posting Whiz

Offline

353 posts
since Apr 2004

Permalink

May 13th, 2006

Re: what's with gcc?

>>The version I am using is 3.4.2 of gcc

Then upgrade to the newest version. Why use a buggy compiler (as if VC++ 6.0 is bug-free!:mrgreen: )

Ancient Dragon

Sponsor

Team Colleague

Featured Poster

Reputation Points: 5608

Solved Threads: 2282

Retired and Enjoying Life

Offline

21,947 posts
since Aug 2005

Permalink

May 13th, 2006

Re: what's with gcc?

> I said so because some of you might jump into the conclusion that checking for
> inequality between two double datatypes is what's wrong with my code.
http://docs.sun.com/source/806-3568/ncg_goldberg.html
http://c-faq.com/fp/fpequal.html
Just because you believe that it "isn't a problem for me" doesn't mean that it isn't a problem. The fact that it works for you sometimes, with some compilers doesn't mean that there isn't a problem.

> it could very well be for a bug with the version of gcc I have.
Statements like this require huge amounts of proof - you don't have that.
Did you disassemble all the generated code to find out what the compiler really did?
Besides, if you did, you should have visited
http://www.mingw.org/bugs.shtml

Not to mention

C++ Syntax (Toggle Plain Text)
$ gcc -W -Wall -ansi -pedantic -O2 foo.c
foo.c: In function ‘main’:
foo.c:16: warning: ISO C90 does not support the ‘%lf’ printf format
foo.c:16: warning: ISO C90 does not support the ‘%lf’ printf format
$ gcc -W -Wall -ansi -pedantic -O2 foo.c
foo.c: In function ‘main’:
foo.c:16: warning: ISO C90 does not support the ‘%lf’ printf format
foo.c:16: warning: ISO C90 does not support the ‘%lf’ printf format

Read
http://www.mingw.org/mingwfaq.shtml
"MinGW uses the Microsoft runtime libraries, distributed with the Windows operating system"
It does not use the standard GNU LibC implementation, but inherits all the bugs and features of the host libraries.
Maybe by feeding printf() bogus format sequences it's corrupting the stack and the rest of your local variables into the bargain.
Do you still see a problem when you use correct printf format controls?

> Do you have the 3.4.2 version of MinGW? Did you try my code with it? If you did, did you see the weird behaviour I mentioned above?
No, No and No.
Generally speaking, I try and sort out the obvious deficiencies (such as undefined or suspicious behavior) before actually bothering to try and run code myself.

> Adding a '\n' to my printf doesn't make the weird behaviour go away, This advice of
> yours is not only childish but also completely irrelevant to the issue at hand.
Here's chapter and verse from the C89 standard.

Quote ...

4.9.2 Streams

Input and output, whether to or from physical devices such as terminals and tape drives, or whether to or from files supported on structured storage devices, are mapped into logical data streams, whose properties are more uniform than their various inputs and outputs. Two forms of mapping are supported, for text streams and for binary streams .99

A text stream is an ordered sequence of characters composed into lines , each line consisting of zero or more characters plus a terminating new-line character. Whether the last line requires a terminating new-line character is implementation-defined. Characters may have to be added, altered, or deleted on input and output to conform to differing conventions for representing text in the host environment. Thus, there need not be a one-to-one correspondence between the characters in a stream and those in the external representation. Data read in from a text stream will necessarily compare equal to the data that were earlier written out to that stream only if: the data consist only of printable characters and the control characters horizontal tab and new-line; no new-line character is immediately preceded by space characters; and the last character is a new-line character. Whether space characters that are written out immediately before a new-line character appear when read in is implementation-defined.

Again, all this "works for me with the foo and bar compilers" doesn't make your code bug free, or free from different implementation specific behaviours.
And how would you know whether it was an issue or not, since you have yet to figure out the answer to the question?

Salem

Team Colleague

Reputation Points: 5862

Solved Threads: 950

Posting Sage

Offline

7,164 posts
since Dec 2005

Permalink

May 13th, 2006

Re: what's with gcc?

Quote ...

http://docs.sun.com/source/806-3568/ncg_goldberg.html
http://c-faq.com/fp/fpequal.html
Just because you believe that it "isn't a problem for me" doesn't mean that it isn't a problem. The fact that it works for you sometimes, with some compilers doesn't mean that there isn't a problem.

I read the first article back in my "Computer organisation and design" class regarding how to represent real numbers inside computers. And I have already told you I am completely aware that the following code is wrong:

C++ Syntax (Toggle Plain Text)
double x;
for(x = 0; x != 9.9; x += .1)
      //do something
double x;
for(x = 0; x != 9.9; x += .1)
      //do something

However the following block from my code is perfectly alright:

C++ Syntax (Toggle Plain Text)
for(i = 0; x0 != x1; ++i)
{ 
     x0 = x1;
     x1 = .5 * (x1 + a / x1);
     //printf("\nIteration %d - converging to %lf - prev value %lf",i,x1,x0);
 
 
}
for(i = 0; x0 != x1; ++i)
{ 
     x0 = x1;
     x1 = .5 * (x1 + a / x1);
     //printf("\nIteration %d - converging to %lf - prev value %lf",i,x1,x0);


}

if you can't see the difference, that's very unfortunate.

Quote ...

Statements like this require huge amounts of proof - you don't have that.
Did you disassemble all the generated code to find out what the compiler really did?

LOL, when did statements like "this could very well be a bug with gcc" requires "huge amount of proof". In fact, I posted my code here just TO VERIFY if it was indeed a bug with the version of gcc I have or not. I wanted to see if anyone else gets the same output as I am getting.

As for the format specifier %lf for printf() i don't think it's an issue with MinGW gcc which has implemented a great deal of C99 standard. ABOVE ALL the code works fine when I uncomment the printf() statement not the other way.

Quote ...

No, No and No.

And that's why I am prolly wasting my time here.

Instead of putting up a whole bunch of "this might be the problem"s you could have been more specific. That might have been more useful.

As for printing a final '\n' - that's more of an issue with input streams. Printing a newline to the console is the least of the worries here.

Asif_NSU

Reputation Points: 113

Solved Threads: 3

Posting Whiz

Offline

353 posts
since Apr 2004

Permalink

May 13th, 2006

Re: what's with gcc?

Quote originally posted by Asif_NSU ...

LOL, when did statements like "this could very well be a bug with gcc" requires "huge amount of proof".

For quite a long time, actually.
http://www.catb.org/~esr/faqs/smart-....html#id264997

Quote originally posted by Asif_NSU ...

As for the format specifier %lf for printf() i don't think it's an issue with MinGW gcc

The general rule of thumb is this: once you do undefined behavior, the rest of the program is undefined.

Dave Sinkula

Team Colleague

Reputation Points: 2780

Solved Threads: 312

long time no c

Offline

4,790 posts
since Apr 2004

Permalink

May 14th, 2006

Re: what's with gcc?

Quote ...

For quite a long time, actually.
http://www.catb.org/~esr/faqs/smart-....html#id264997

I never claimed to have found a bug in gcc. I merely suggested that it could be a possibility. If you look at my first post I was here to clarify if it was due to a bug with the gcc or due to something wrong with my code.

Quote ...

The general rule of thumb is this: once you do undefined behavior, the rest of the program is undefined.

So using %lf with printf is undefined behaviour? That is certainly news to me. If that's true there are three possible actions that should be taken:

1. The ones who specified this to be an undefind behaviour in the C standard should be shot dead for creating this confusion in the first place. If %lu is okay why should %lf be not. It sounds so natural.

2. The authors who wrote books on C and said %lf is a valid printf format specifier should be shot dead for misleading/misinforming us.

3. Dave Sinkula, Narue, Ancient Dragon, Rashakifol and everyone else possesing a much better knowledge on C should be shot dead since they did not point this one out to me before;I believe I have used %lf with printf many a times before in this forum.

With all that said my gcc still acts weird even if I use %f instead of %lf with printf (specially when the printf statement was inside a comment after all ). But I guess you can't see it for yourself. So I will take the pain of video recording my desktop activity and posting it here. I am currently posting from elsewhere. I will do so as soon as I get home. I must see it to its end.

Asif_NSU

Reputation Points: 113

Solved Threads: 3

Posting Whiz

Offline

353 posts
since Apr 2004

Page 1
2
3
Next

This thread is more than three months old

No one has posted to this discussion for at least three months. Please let old threads die and do not reply to them unless you feel you have something new and valuable to contribute that absolutely must be added to make the discussion complete. Otherwise, please start a new thread in this forum instead.

Previous Thread in C++ Forum Timeline: finding max value of 10 integers

Next Thread in C++ Forum Timeline: New to C++

DaniWeb Message

Cancel Changes

User Name
Password