Compiler bug in lcc-win32

[James Kuyper]

I this case it would be an "extension" of the || operator.
The "extension" that would only be effective, when the
program was compiled with optimizing (option -O).

Here, you express unjustified certainty about the location of the
problem, even though you later admit that there are other possibilities.

....

There is NO file stdio.h at the place searched with "".

That's good to know - but it's not a good reason for not fixing the
problematic code. The right response would have been "thanks for
pointing that out", rather than complaining about it being irrelevant to
the problem at hand. It probably is - but it's still a good idea to get
in the habit of using the correct form. I'm surprised, given the
extensive programming experience you allude to farther down, that you
have not yet already acquired that habit.

I am aware of this possibility.

You sure don't talk as if you were. See farther above, where you just
summarily dismiss the possibility that anything other than the
implementation of || could be relevant.

....

This is possible but improbable, since this is not the
first program I wrote.

I agree that it's improbable. However, given that it's trivial to rule
out that possibility, it's rather odd that you didn't bother to do so,
and even more odd that you complain so bitterly against the suggestion
that you should.

You should fix up the char signedness problem, the use of "" rather than
<> in the #include, and if you're compiling for C90, return a valid
value from main(). Compile with whichever options lcc requires for
maximum conformance with whichever version of the C standard you prefer.
If the problem still occurs, only then will you have collected enough
evidence to justify the certainty you already feel about the irrelevance
of all of those other issues. They probably are irrelevant, but it's
inexcusable to avoid doing the trivial things that you need to do to
convert "probably" into "certainly".

It looks like BartC has already done at least part of this work for you;
but you should have done it yourself.

 

[Ben Bacarisse]

It looks like BartC has already done at least part of this work for you;
but you should have done it yourself.

If you are interested in the bug, I posted a short version (of about a
dozen lines) to comp.lang.lcc that, as far as I know, does not have any
undefined behaviour.

 

[tm]

Here, you express unjustified certainty about the location of the
problem, even though you later admit that there are other possibilities.

I posted the test program after two days examining this
bug. I have a dozen other versions which trigger it
also. This is just the demo version which allows to show
the bug without using big parts of my software.

That's good to know - but it's not a good reason for not fixing the
problematic code. The right response would have been "thanks for
pointing that out",

[snip]

Interestingly I expected other people to sent me this
response.

You sure don't talk as if you were. See farther above, where you just
summarily dismiss the possibility that anything other than the
implementation of || could be relevant.

As I already said, I examined this bug for two days.
I used programs, which included <stdio.h>, which
returned a value for the main function, which used
unsigned char * as actual parameter, etc. I have also
versions with and without libraries (For a short time
I had the linker and/or the library creation program
under suspicion). BTW.: My own program was under
suspicion for the whole time. But it turned out to
be "not guilty".

I agree that it's improbable. However, given that it's trivial to rule
out that possibility, it's rather odd that you didn't bother to do so,
and even more odd that you complain so bitterly against the suggestion
that you should.

You should fix up the char signedness problem, the use of "" rather than
<> in the #include, and if you're compiling for C90, return a valid
value from main(). Compile with whichever options lcc requires for
maximum conformance with whichever version of the C standard you prefer.
If the problem still occurs, only then will you have collected enough
evidence to justify the certainty you already feel about the irrelevance
of all of those other issues. They probably are irrelevant, but it's
inexcusable to avoid doing the trivial things that you need to do to
convert "probably" into "certainly".

I am certain. See above.

BTW.: I port my software to other compilers and operating
systems to discover bugs and weaknesses in MY software.
It is not my prime intention to test compilers and runtime
libraries. I want to improve my stuff. From time to time I
find problems outside of my software.
Then I can do two things:

1. Dismiss this product. In companies this is done in
90% of the cases, when there is a problem in an open
source product. I have heard very often: We use open
source software, but we don't report bugs.
2. Write some testcase which allows a maintainer to fix
the problem. This is unpayed work and people usually
don't react friendly when you point out, that they
did something wrong.

It looks like BartC has already done at least part of this work for you;
but you should have done it yourself.

I posted a program that can be used as start for the
people who maintain the lcc compiler. It was my work and
my decision to do it this way. I did 99% of the work
to demonstrate that something is going wrong. And you
attack me because of 1% missing.

You should be polite and stop to argue this way
(and discover a compiler bug yourself).


Greetings Thomas Mertes

--
Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.

 

[Keith Thompson]

If you are interested in the bug, I posted a short version (of about a
dozen lines) to comp.lang.lcc that, as far as I know, does not have any
undefined behaviour.

Correction: comp.compilers.lcc.

 

[jacob navia]

Hi Thomas

I was prompted by this discussion to go to la Roche sur Yon
and close myself inside the cyber cafe for several hours.

I would like (again) to thank you for your bug report. Contrary
to the anonymous "bug" trolls before I know you are real and
also that the bug is real.

I have a corrected version of the software now. It is a very difficult
to reprodue bug, and thanks to your test program I have been able
to identify the culprit and correct the optimization bug.

I am sending you a corrected version.

Jacob

 

[Eric Sosman]

[...]

No matter: Neither is your program. Once you invoke undefined
behavior, the implementation is not obliged to live up to anything
the C Standard promises.

With -Wall gcc complains a little bit:
Control reaches the end of the non-void function 'main'
and the function 'get_ident' expects ‘unsigned char *’
but the argument is of type ‘char *’.

This two things have no influence on the compiler bug.

By my count, that makes two issues you've dismissed as "has no
influence" and "does not make any difference." You may be right (I
will even go so far as to say you are probably right), but one has
to ask: What evidence supports your claims? Would it not have been
simpler to write a Simon-pure demonstration in the first place?

Or was the scent of your prey just too strong in your nostrils?

I was busy to prepare my new Seed7 release. [...]
If you are interested, you can download Seed7
and check it.

Ah, so this is Yet Another Seed Spam. What a surprise.

 

[tm]

[...]

No matter: Neither is your program.  Once you invoke undefined
behavior, the implementation is not obliged to live up to anything
the C Standard promises.

With -Wall gcc complains a little bit:
Control reaches the end of the non-void function 'main'
and the function 'get_ident' expects ‘unsigned char *’
but the argument is of type ‘char *’.

This two things have no influence on the compiler bug.

     By my count, that makes two issues you've dismissed as "has no
influence" and "does not make any difference."  You may be right (I
will even go so far as to say you are probably right), but one has
to ask: What evidence supports your claims?

Jacob Navia seems to support my claims (see this thread):
----- cite -----
I would like (again) to thank you for your bug report. Contrary
to the anonymous "bug" trolls before I know you are real and
also that the bug is real.

I have a corrected version of the software now. It is a very difficult
to reprodue bug, and thanks to your test program I have been able
to identify the culprit and correct the optimization bug.
----- end cite -----

 Would it not have been
simpler to write a Simon-pure demonstration in the first place?

I discovered the bug in an approx. 100000 line program.
In two days of work I distilled this size down to the
program I posted.

[snip]


Greetings Thomas Mertes

--
Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.

 

[James Kuyper]

As I already said, I examined this bug for two days.
I used programs, which included <stdio.h>, which
returned a value for the main function, which used
unsigned char * as actual parameter, etc.

So, let me get this straight: you
1. test at least one version of the program where all of those things
were handled correctly.
2. For unspecified reasons, also tested at least one version where all
of those things were handled incorrectly.
3. When you became certain that it was a compiler bug, you posted your
message using the version where they were all handled incorrectly.

I have to admit that it never occurred to me that someone would do
something like that. I'm sure that this represents a failure of my
imagination. In general, I tend to assume that badly written code is due
to a failure to understand what's wrong with it, rather than being due
to a deliberate decision to publish bad code. I will have to keep in
mind that this is not always the case. I don't understand it, but I will
keep it in mind.

....

You should be polite and stop to argue this way
(and discover a compiler bug yourself).

I have. Not very often, but occasionally.

 

[Kenny McCormack]

You should be polite and stop to argue this way

I have. Not very often, but occasionally.[/QUOTE]

OK, but I've yet to see any evidence of it.

--
Religion is regarded by the common people as true,
by the wise as foolish,
and by the rulers as useful.

(Seneca the Younger, 65 AD)

 

[Keith Thompson]

[...]
Eric Sosman wrote:
No matter: Neither is your program.  Once you invoke undefined
behavior, the implementation is not obliged to live up to anything
the C Standard promises.

With -Wall gcc complains a little bit:
Control reaches the end of the non-void function 'main'
and the function 'get_ident' expects ‘unsigned char *’
but the argument is of type ‘char *’.

This two things have no influence on the compiler bug.

     By my count, that makes two issues you've dismissed as "has no
influence" and "does not make any difference."  You may be right (I
will even go so far as to say you are probably right), but one has
to ask: What evidence supports your claims?

Jacob Navia seems to support my claims (see this thread):
----- cite -----
I would like (again) to thank you for your bug report. Contrary
to the anonymous "bug" trolls before I know you are real and
also that the bug is real.

I have a corrected version of the software now. It is a very difficult
to reprodue bug, and thanks to your test program I have been able
to identify the culprit and correct the optimization bug.
----- end cite -----

 Would it not have been
simpler to write a Simon-pure demonstration in the first place?

I discovered the bug in an approx. 100000 line program.
In two days of work I distilled this size down to the
program I posted.

I applaud the work you did to help track down this bug, and I'm
glad that it led to a solution.

I'm just a bit confused about why you didn't (a) take another 5
minutes to correct some obvious remaining errors in your test case,
and (b) send the bug report to a more appropriate place (probably
jacob's e-mail) rather than to a language discussion group.

You've spent more time defending
#include "stdio.h"
than you would have spent changing it to
#include <stdio.h>

Nobody is claiming that the use of "" rather than <> was actually
relevant to the problem.

 

[James Kuyper]

On 07/18/2011 10:42 AM, tm wrote: ....

While I've been saying things you didn't want to hear, I did so with all
appropriate politeness. The closest I've came to being impolite was when
I suggested that you might be one of those people who post spurious bug
reports against lcc-win32. Even then, I was careful to merely point out
that very real possibility, and not to actually accuse you.

I have. Not very often, but occasionally.

Most recently, <http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46926>.

 

[Noob]

I have [discovered compiler bugs]. Not very often, but occasionally.
Most recently, <http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46926>

Thank you for helping improve gcc.

Considering GCC's licence (GPL) and its large user base,
making gcc better has much much (much!!) more value to
society overall than improving random proprietary software.