Re: A smaller self contained test case. Was: Compiler Bug or what I'm doing wrong?

[M E Leypold <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de>]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On 24 Jun 2006 22:22:30 +0200, M E Leypold wrote:
> 
> > I followed Barnes' advice here: "wether it is appropriate to use a
> > variant or tagged type, the key consideration is mutability". 
> 
> True [mutability of class instances] Handles to tagged types is another way
> to have mutable class-wide.
>  
> >>   procedure Get_Record is
> >>      F : File_Type;
> >>      S : Stream_Access;
> >>   begin
> >>      Open (F, Mode => In_File, Name => "tmp-bug3" );
> >>      S := Stream (F);
> >>      for I in 1 .. 400 loop
> >>         declare
> >>            R : Customer_Description renames
> >>                   Customer_Description'Input (S);
> > 
> > Oops. My, that is a dirty trick -- but how do I return R? Hm, yes I
> > can see how that would work. Perhaps :-).  I'll see how I can fit that
> > into the database module.
> 
> Hey, it is not a trick, but a nice pattern! I am using it quite often, and
> count it for a good style.

I didn't know that one could rename function results :-). Never had
seen that. But now that I see it, it makes a lot of sense. My
experiments indicate that a lot less finalizers/initializers run with
that pattern. That is good and I'll keep that in mind.

Also, thinking about it, that should be solution to initializing
limited values, wich I have been looking for and never foudn it (AFAIK
Barnes is silent on that). I assume the following would work (with
B_Type being a limited type)?

   declare B : B_Type renames Make_a_B(...);

> Anyway, the following will work as well:


Unfortunately all that doesn't remove my original Bug. The original
program (not the simplified example) has a more complex data structure
and a kind of filesystem/database. If I replace Read/Write by
Input/Output there, the bug persists. 

In the really simple example I submitted, tha bug goes away, but I
consider this accidental (due to the Heisenbug nature of
initialization- and malloc()-related bugs). When trying to replace the
Unbounded_String(s) in the example by Controlled types A_Class and
B_Class which print when their finalizes/initializers/asjustment are
run, I get mixed, partially non reproducible results:

  - I had a case where it seemed, that one initializer too many is
    run. When trying to change the tracing that effect vanished and
    couldn't be restored.

  - I had a case where during Read no initializers/finalizers whatever
    where run, but the discriminant was changed. The finalizer for the
    non-visible variant part (non-visible with the changed
    dioscriminant) was run at block exit but on the data content of
    the visible variant part.

All that indicates that the problem in question is not simply a
problem ion the order of operations as a surmised before. It looks a
bit like a caching problem: When at block exit the runtime examines
the discriminant it seems to have retained the old value somewhere and
act on that. I hoped, that switching of optimization (-O0) would make
that kind of bug go away, but didn't change anything.

I'm stuck for the moment. Simple workarounds obviously don't cover the
more complex cases (variant parts in varaint parts in variant
parts). Either I will have to write IO-procedure manually, or I'll
have to change to another compiler. Well.

Regards -- Markus