Hi,

I got strange ppcx64 error: -139, which I found is caused by this:

type
  TNodeStack = specialize TVector<TNodeHash>;

where TNodeHash itself is a specialization:

type
  PNode = ^TNode; //TNode is a plain record
  TNodeHash = specialize TTreap<Integer, PNode>;

Is it true that specialization of a generic class using another specialized generic class is not allowed?

Thanks!

Xiangrong

No, that should work. Maybe some bug. Is there any error message? Could you present the full compiler output, please? You are using 2.7.1, right?

Regards,
Sven

Hi Sven,

I am using fpc 2.6.2. I am very sorry that I don't have time to compile and install 2.7.1 at this time.

It's good to know that it works, at least in 2.7.1. I will report the problem again while I start using 2.7.1 or when it is released as 2.8 :-)

For now, another suggestion regarding this error is the error message it gave out, which is not understandable (error -139), I only find out the cause of this by comparing my source code in git.

I hope this is also improved in 2.7 or later.

Thanks!
Shannon

2014-04-15 13:34 GMT+08:00 Sven Barth :

"Xiangrong Fang" wrote

It's good to know that it works, at least in 2.7.1. I will report the

problem again while I start using 2.7.1 or when it is released as 2.8 :-)

That's the point: I don't know wether it compiles in 2.7.1 as I did not test it. If you could provide a minimal sample (which fails in 2.6.2) and report that as a bug I could ensure that 2.7.1 works correctly there.

For now, another suggestion regarding this error is the error message it

gave out, which is not understandable (error -139), I only find out the cause of this by comparing my source code in git.

No other message? Did you check the -v options that errors are really printed? Do you compile using Lazarus or on command line? If the former then try the latter please or do a right click on the message window and select "copy all visible and hidden messages to clipboard" (or so) and paste that somewhere else to see wether Lazarus hid any messages.

I hope this is also improved in 2.7 or later.

Normally there should either be an error message (at least "compilation aborted") or if it's a crash a stackstrace...

Regards,
Sven

2014-04-15 17:21 GMT+08:00 Sven Barth :

​I cannot replicate the problem using a minimal program, because it gives out different error message. The following minimal program compiles OK:

program vectr;
type
  generic TGeneric1<T> = class
  end;
  generic TGeneric2<T> = class
  end;
  TSpec1 = specialize TGeneric1<Integer>;
  TSpec2 = specialize TGeneric2<TSpec1>;
begin
end.

While the following program generate different error:

program vectr;
uses
  treap, vector;
type
  TNodeHash = specialize TTreap<Integer, string>;
  TNodeVector = class(specialize TVector<TNodeHash>)
  protected
    function OnSort(v1, v2: T): Integer; override;
  end;
operator <(nh1, nh2: TNodeHash): Boolean;
begin
  Result := nh1.Count < nh2.Count;
end;
operator >(nh1, nh2: TNodeHash): Boolean;
begin
  Result := nh1.Count > nh2.Count;
end;
function TNodeVector.OnSort(v1, v2: T): Integer;
begin
  Result := 0;
end;
begin
end.    ​

gives error message:

vector.pas(149,9) Error: Operator is not overloaded: "TTreap$LongInt$AnsiString" < "TTreap$LongInt$AnsiString" vector.pas(151,14) Error: Operator is not overloaded: "TTreap$LongInt$AnsiString" > "TTreap$LongInt$AnsiString" vectr.lpr(28) Fatal: There were 2 errors compiling module, stopping

The two used units can be downloaded here:

https://github.com/xrfang/fpcollection/

While in my real program, I have this:

type
  TCmhWaves = specialize TVector<TCmhWave>;

The thing is, even if I do NOT use this definition at all, it still crashes the compiler. By "crash" I mean I get this from lazarus:

Compiling wmodel.lError: /usr/bin/ppcx64 can't be executed, error message: Failed to execute "/usr/bin/ppcx64", error code: -139

TCmhWave is a specialized subclass of My TTreap class (also on github), it does NOT overload the < and > operators either.

So my question is:

1) why my simplified example still require overloaded operator, although I have already done so?

2) If this is the cause of error (TCmhWave does not have these operators defined), why the compiler returns error code: -139 instead of more detailed errors?

BTW, on my first attempt to debug this problem in lazbuild (command line) I get some error related to VMA, but unfortunately I forgot what it is and cannot get it shown again. Is there any way to customize the lazbuild by some switches to let it output more messages?

Thanks.

"TTreap$LongInt$AnsiString" < "TTreap$LongInt$AnsiString"

vector.pas(151,14) Error: Operator is not overloaded:

"TTreap$LongInt$AnsiString" > "TTreap$LongInt$AnsiString"

vectr.lpr(28) Fatal: There were 2 errors compiling module, stopping

Operator overloads must be available in the scope the generic type was *declared* in, not the scope it is *specialized* in. Currently this is only possible by using records that contain operator overloads ("class operator") and using those to specialize the generic. So you'll need to create a container record that contains your TTreap specialization TNodeHash and the operator overloads for > and < and specialize TVector with that.

I have an idea to improve this situation for non-Delphi mode generics, but that wouldn't help you with 2.6.x ;)

crashes the compiler. By "crash" I mean I get this from lazarus:

Compiling wmodel.lError: /usr/bin/ppcx64 can't be executed, error

message: Failed to execute "/usr/bin/ppcx64", error code: -139

Is there really a "ppcx64" in /usr/bin? And is it really executable? (try "/usr/bin/ppcx64 -i" in a shell) Also check you Lazarus settings that you've setup the correct "fpc" binary and that you project's target settings are set to the correct platform (maybe you are trying to compile for x86_64 without having a x84_64 compiler installed).

Regards,
Sven

2014-04-15 20:26 GMT+08:00 Sven Barth :

​No problem with the executable. I run it from command line, which is ok. i.e. "ppcx64" is not corrupted, nor there is any authorization problem. Also, if I remove the unused declaration, the error is gone.​

Doesn't "-139" have any meaning to you?

Regards,
Xiangrong