«

On 30 Aug, 02:27, lloyd <lloyd.hough...@gmail.com> wrote:

> My program enumerates arrangements of a specified combinatorial
> object, at different orders. It's recursive and has to go pretty deep.
> If I invoke it with the "quick" flag, then instead of telling me how
> many arrangements of the object there are at a particular order, it
> just tells me as soon as it finds *any*, and exits--this gives me a
> quick answer about existence, when I don't care how many solutions
> there are (which is sometimes lengthy to compute). The way I
> implemented this is by using the solution counter, which is a global
> variable: I run a comparison at the head of each loop and if
> num_solutions > 0 then I break, and the program surfaces from all the
> recursed inner function calls that way.

how doe sit do this? Does it use multiple returns or something? Can
you trace it in a debugger or put printf()s in? This might give you a
clue as to which bits "work" and which bits "fail".


> At least that's how it's supposed to work. And I spent hours trying to
> find why it didn't break out and end after finding a solution, as I
> was sure my code was sound. In the end I happened to remember a
> similar problem I'd had once, where compiling at a different
> optimisation changed some detail of how the program worked, and when I
> compiled it (with gcc) using -O2 it worked as it was supposed to. Very
> frustrating!
>
> I can't possibly paste the code here as it is too nasty, and it would
> take a lot of work to get it down to minimum size. But I thought I'd
> ask if anyone knows this issue, and whether it is likely to be a bug
> in my code, or something badly phrased that -O2 somehow accidentally
> fixes, or whether it's more likely to be a bug in gcc as invoked
> without optimisation.
>
> Thanks! *--Lloyd

Seebs said:

> Does anyone, ever, in any way, depend on the output of this program?
> If not, why does it exist? *If they do, is it okay if it lies to them?

Thanks to all for your righteous concern (no sarcasm intended,
honestly). My program does nothing mission-critical for anyone, it is
used to produce solutions to a mathematical problem with artistic
applications, so no buildings will fall down.

Once I get through the hell that is the beginning of a new academic
semester I will try stripping the program down to isolate the bug,
more out of sheer morbid curiosity than because the possibility of
wrong results is so awful. The program is a little convoluted in
structure but deliberately not too clever in how it does it, so I can
understand it.

To Eric: I actually have no doubt that it's Lloyd who's doing
something dodgy, and not gcc.

Thanks everyone.

On 2010-08-30, lloyd <> wrote:
> Seebs said:
>> Does anyone, ever, in any way, depend on the output of this program?
>> If not, why does it exist? *If they do, is it okay if it lies to them?

> Thanks to all for your righteous concern (no sarcasm intended,
> honestly). My program does nothing mission-critical for anyone, it is
> used to produce solutions to a mathematical problem with artistic
> applications, so no buildings will fall down.

That's encouraging.

> Once I get through the hell that is the beginning of a new academic
> semester I will try stripping the program down to isolate the bug,
> more out of sheer morbid curiosity than because the possibility of
> wrong results is so awful. The program is a little convoluted in
> structure but deliberately not too clever in how it does it, so I can
> understand it.

Cool. And yes, under the circumstances, waiting for a more opportune
time might be reasonable.

If the program is in modules, note that you can sometimes narrow things
down by compiling them at different optimization levels; this will often,
but not always, tell you where the problem is.

> To Eric: I actually have no doubt that it's Lloyd who's doing
> something dodgy, and not gcc.

Well, that tears it, you'll have found a compiler bug.

-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet-
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

Seebs wrote:
> > To Eric: I actually have no doubt that it's Lloyd who's doing
> > something dodgy, and not gcc.
>
> Well, that tears it, you'll have found a compiler bug. *

In case that wasn't clear, I meant I have no doubt (i.e. I believe it
to be true) that the dodginess is on my part, not on gcc's part.

Seeb wrote:
> > To Eric: I actually have no doubt that it's Lloyd who's doing
> > something dodgy, and not gcc.
>
> Well, that tears it, you'll have found a compiler bug. *

In case I wasn't clear, I meant that I do not doubt (i.e. I believe it
to be true) that the dodginess is on my part, not on the part of gcc.

lloyd <> writes:
> Seeb wrote:
>> > To Eric: I actually have no doubt that it's Lloyd who's doing
>> > something dodgy, and not gcc.
>>
>> Well, that tears it, you'll have found a compiler bug. Â*
>
> In case I wasn't clear, I meant that I do not doubt (i.e. I believe it
> to be true) that the dodginess is on my part, not on the part of gcc.

I think it was clear; the "" was a smiley.

(BTW, he's "Seebs", not "Seeb". Are you constructing attribution lines
manually?)

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

On Aug 30, 12:24*pm, lloyd <lloyd.hough...@gmail.com> wrote:
> Once I get through the hell that is the beginning of a new academic
> semester I will try stripping the program down to isolate the bug,
> more out of sheer morbid curiosity than because the possibility of
> wrong results is so awful. The program is a little convoluted in
> structure but deliberately not too clever in how it does it, so I can
> understand it.
>

Bravo. I join with all others on the point that an optimization-
dependent bug is a smoking gun; you need to go find the bullet. It
may be in your own foot.

After you've resolved the problem, you might want to replace the
global variable for computation-unwinding with setjmp() and a
longjmp() at the point where a complete solution is found. See your
favorite documentation.

Cheers.

On 2010-08-30, Jon Wild <> wrote:
> Seebs wrote:
>> > To Eric: I actually have no doubt that it's Lloyd who's doing
>> > something dodgy, and not gcc.

>> Well, that tears it, you'll have found a compiler bug. *

> In case that wasn't clear, I meant I have no doubt (i.e. I believe it
> to be true) that the dodginess is on my part, not on gcc's part.

Right. And the moment you are *sure* it's your bug, the compiler will
have a bug just to throw you off the scent.

Henry Spencer once said "Do not lie to the compiler, for it will have its
revenge." At this point, enough people have lied to compilers often enough
that they actively seek revenge on all humans as a matter of principle.

-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet-
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

Keith Thompson was all like:
> (BTW, he's "Seebs", not "Seeb". *Are you constructing attribution lines
> manually?)

Heavens no, I always use the computer keyboard to type them in

Gene wrote:
> After you've resolved the problem, you might want to replace the
> global variable for computation-unwinding with setjmp() and a
> longjmp() at the point where a complete solution is found. *See your
> favorite documentation.

Hey, I just looked into this longjmp thing. How long has this been
going on? Thanks for the hint.