Recent

Author Topic: FPC 3.2.x series branched, trunk update to 3.3.1  (Read 14866 times)

marcov

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 6627
FPC 3.2.x series branched, trunk update to 3.3.1
« on: August 18, 2018, 05:49:18 pm »
l.s.

A branch was made for a future series of 3.2.x FPC releases. A first release
of this branch is still months away, but the moment to test the compatibility
of your codebases with the future FPC is _NOW_!, while there is still time
to do something about it.

The svn designation of this fixes branch is branches/fixes_3_2

As a consequence, trunk will be updated to version 3.3.1, some people might have to update their scripts.

Thaddy

  • Hero Member
  • *****
  • Posts: 7199
Re: FPC 3.2.x series branched, trunk update to 3.3.1
« Reply #1 on: August 18, 2018, 11:07:22 pm »
Ok. Tnx.
inline variables like in D10.3 are a bit like Brexit: if you are given the wrong information it sounds like a good idea. Every kid loves candy, but it makes you fat and your teeth will disappear.

Blaazen

  • Hero Member
  • *****
  • Posts: 2679
  • POKE 54296,15
    • Eye-Candy Controls
Re: FPC 3.2.x series branched, trunk update to 3.3.1
« Reply #2 on: August 19, 2018, 12:21:23 am »
Quote
the moment to test the compatibility of your codebases with the future FPC is _NOW_!
This code
Code: Pascal  [Select]
  1. procedure TForm1.Button1Click(Sender: TObject);
  2. var a: array of Integer;
  3.     i: Integer;
  4. begin
  5.   SetLength(a, 10);  //HERE
  6.   for i:=0 to length(a)-1 do
  7.     a[i]:=i;
  8. end;
gives no warning at 3.0.4 but with the latest trunk it gives
"unit1.pas(36,14) Warning: Local variable "a" of a managed type does not seem to be initialized" at line with SetLength, which is silly since SetLength itself is initialization. SetLength passes parameter by refrence (var) but it is same in 3.0.4 and 3.1.1.
Lazarus 2.1.0 r59757M FPC 3.3.1 r40507 x86_64-linux-qt Chakra, Qt 4.8.7/5.11.2, Plasma 5.14.2
Lazarus 1.8.2 r57369 FPC 3.0.4 i386-win32-win32/win64 Wine 3.21

Try Eye-Candy Controls: https://sourceforge.net/projects/eccontrols/files/

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 4952
    • wiki
Re: FPC 3.2.x series branched, trunk update to 3.3.1
« Reply #3 on: August 19, 2018, 01:36:59 am »
For Windows users: https://sourceforge.net/projects/lazarus-snapshots/files/

Those installers contain Lazarus trunk + fpc 3.2 fixes branch.

Ensure to set the checkbox "secondary installation", then they do not interfere with your stable install.

valdir.marcos

  • Hero Member
  • *****
  • Posts: 544
Re: FPC 3.2.x series branched, trunk update to 3.3.1
« Reply #4 on: September 17, 2018, 07:27:17 am »
l.s.

A branch was made for a future series of 3.2.x FPC releases. A first release
of this branch is still months away, but the moment to test the compatibility
of your codebases with the future FPC is _NOW_!, while there is still time
to do something about it.

The svn designation of this fixes branch is branches/fixes_3_2

As a consequence, trunk will be updated to version 3.3.1, some people might have to update their scripts.


2.0 RC1
ftp://ftp.freepascal.org/pub/lazarus/releases/Lazarus%20Windows%2032%20bits/Lazarus%202.0RC1/
ftp://ftp.freepascal.org/pub/lazarus/releases/Lazarus%20Windows%2064%20bits/Lazarus%202.0RC1/
I am confused.
Which one is most probably to be released: Lazarus 2.0.0 with FPC 3.0.4 or FPC 3.2.0?

https://sourceforge.net/projects/lazarus-snapshots/files/Window%2032/lazarus-1.9.0-58738-fpc-3.2.0-beta-39634-win32.exe/download
https://sourceforge.net/projects/lazarus-snapshots/files/Window%2064/lazarus-1.9.0-58738-fpc-3.2.0-beta-39634-win64.exe/download

ftp://ftp.freepascal.org/pub/lazarus/releases/Lazarus%20Windows%2032%20bits/Lazarus%202.0RC1/lazarus-2.0RC1-fpc-3.0.4-win32.exe
ftp://ftp.freepascal.org/pub/lazarus/releases/Lazarus%20Windows%2064%20bits/Lazarus%202.0RC1/lazarus-2.0RC1-fpc-3.0.4-win64.exe

https://sourceforge.net/projects/lazarus-snapshots/files/Window%2032/
https://sourceforge.net/projects/lazarus-snapshots/files/Window%2064/

ftp://ftp.freepascal.org/pub/lazarus/releases/Lazarus%20Windows%2032%20bits/Lazarus%202.0RC1/
ftp://ftp.freepascal.org/pub/lazarus/releases/Lazarus%20Windows%2064%20bits/Lazarus%202.0RC1/

JuhaManninen

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3554
  • I like bugs.
Re: FPC 3.2.x series branched, trunk update to 3.3.1
« Reply #5 on: September 17, 2018, 11:23:40 am »
I am confused.
Which one is most probably to be released: Lazarus 2.0.0 with FPC 3.0.4 or FPC 3.2.0?
You asked the same question in another thread. I don't know why you are confused.

valdir.marcos

  • Hero Member
  • *****
  • Posts: 544
Re: FPC 3.2.x series branched, trunk update to 3.3.1
« Reply #6 on: September 18, 2018, 03:52:17 pm »
I am confused.
Which one is most probably to be released: Lazarus 2.0.0 with FPC 3.0.4 or FPC 3.2.0?
With FPC 3.0.4 obviously. FPC 3.2.0 will not be released for a long time. There is even no RC1 yet.

That said, testing with 3.2 branch is still recommended too, since once 3.2 is out the next minor (Lazarus 2.0.x) will probably use it.

I am confused.
Which one is most probably to be released: Lazarus 2.0.0 with FPC 3.0.4 or FPC 3.2.0?
You asked the same question in another thread. I don't know why you are confused.
Sorry for duplicating my post.
Thanks.

zamtmn

  • Sr. Member
  • ****
  • Posts: 348
Re: FPC 3.2.x series branched, trunk update to 3.3.1
« Reply #7 on: September 23, 2018, 10:35:15 am »
Blaazen
Quote
gives no warning at 3.0.4 but with the latest trunk it gives
"unit1.pas(36,14) Warning: Local variable "a" of a managed type does not seem to be initialized" at line with SetLength, which is silly since SetLength itself is initialization. SetLength passes
Yes I am also interested, will it be fixed?

Thaddy

  • Hero Member
  • *****
  • Posts: 7199
Re: FPC 3.2.x series branched, trunk update to 3.3.1
« Reply #8 on: September 30, 2018, 11:56:56 am »
No. If you followed the bug report on Mantis.
Case in point is that setlength() does NOT guarantee its values are initialized to a default. It just reserves space for a given number of elements. Even if the compiler MAY internally do something more.
As explained in the bug report and the follow ups it is trivial to actually initialize. (different syntax for objfpc and delphi mode, beware)
And as far as I can see there is no need for a fix.
inline variables like in D10.3 are a bit like Brexit: if you are given the wrong information it sounds like a good idea. Every kid loves candy, but it makes you fat and your teeth will disappear.

mse

  • Sr. Member
  • ****
  • Posts: 286
Re: FPC 3.2.x series branched, trunk update to 3.3.1
« Reply #9 on: September 30, 2018, 02:46:05 pm »
Quote
the moment to test the compatibility of your codebases with the future FPC is _NOW_!
This code
Code: Pascal  [Select]
  1. procedure TForm1.Button1Click(Sender: TObject);
  2. var a: array of Integer;
  3.     i: Integer;
  4. begin
  5.   SetLength(a, 10);  //HERE
  6.   for i:=0 to length(a)-1 do
  7.     a[i]:=i;
  8. end;
gives no warning at 3.0.4 but with the latest trunk it gives
"unit1.pas(36,14) Warning: Local variable "a" of a managed type does not seem to be initialized" at line with SetLength, which is silly since SetLength itself is initialization. SetLength passes parameter by refrence (var) but it is same in 3.0.4 and 3.1.1.
In MSEgui I use
Code: Pascal  [Select]
  1. {$ifndef mse_allwarnings}
  2.  {$if fpc_fullversion >= 030100}
  3.   {$warn 5089 off}
  4.   {$warn 5090 off}
  5.   {$warn 5093 off}
  6.   {$warn 6058 off}
  7.  {$endif}
  8. {$endif}
  9.  
in oder to suppress the unwanted warnings. Problem is that it does not work with -B, see
https://bugs.freepascal.org/view.php?id=34349
I agree that the warnings are wrong or at least sub optimal. Initializing the managed variables in code produces quite heavy redundant instructions:
Code: Pascal  [Select]
  1. procedure test();
  2. var
  3.  s1: string;
  4.  ar1: integerarty; //=array of integer
  5. begin
  6.  setlength(s1,10);
  7.  setlength(ar1,11);
  8. end;
  9.  
  10. MAIN_$$_TEST:
  11. .Lc1:
  12. .Ll1:
  13.         leaq    -120(%rsp),%rsp
  14. .Lc3:
  15. .Ll2:
  16.         movq    $0,(%rsp)
  17.         movq    $0,8(%rsp)
  18.         leaq    16(%rsp),%rdx
  19.         leaq    40(%rsp),%rsi
  20.         movl    $1,%edi
  21.         call    fpc_pushexceptaddr
  22.         movq    %rax,%rdi
  23.         call    fpc_setjmp
  24.         movslq  %eax,%rdx
  25.         movq    %rdx,104(%rsp)
  26.         testl   %eax,%eax
  27.         jne     .Lj6
  28. .Ll3:
  29.         movq    %rsp,%rdi
  30.         xorl    %edx,%edx
  31.         movl    $10,%esi
  32.         call    fpc_ansistr_setlength
  33. .Ll4:
  34.         movq    $11,112(%rsp)
  35.         movq    $RTTI_$MSETYPES_$$_INTEGERARTY,%rsi
  36.         leaq    112(%rsp),%rcx
  37.         leaq    8(%rsp),%rdi
  38.         movl    $1,%edx
  39.         call    fpc_dynarray_setlength
  40.  
Code: Pascal  [Select]
  1. procedure test();
  2. var
  3.  s1: string = '';
  4.  ar1: integerarty = nil; //=array of integer
  5. begin
  6.  setlength(s1,10);
  7.  setlength(ar1,11);
  8. end;
  9.  
  10. MAIN_$$_TEST:
  11. .Lc1:
  12. .Ll1:
  13.         leaq    -120(%rsp),%rsp
  14. .Lc3:
  15. .Ll2:
  16.         movq    $0,(%rsp)
  17.         movq    $0,8(%rsp)
  18.         leaq    16(%rsp),%rdx
  19.         leaq    40(%rsp),%rsi
  20.         movl    $1,%edi
  21.         call    fpc_pushexceptaddr
  22.         movq    %rax,%rdi
  23.         call    fpc_setjmp
  24.         movslq  %eax,%rdx
  25.         movq    %rdx,104(%rsp)
  26.         testl   %eax,%eax
  27.         jne     .Lj6
  28. .Ll3:
  29.         movq    $RTTI_$MSETYPES_$$_INTEGERARTY,%rdx ----redundant
  30.         movq    TC_$MAIN$_$TEST_$$_defaultar1,%rsi
  31.         leaq    8(%rsp),%rdi
  32.         call    fpc_dynarray_assign
  33.         movq    TC_$MAIN$_$TEST_$$_defaults1,%rsi
  34.         movq    %rsp,%rdi
  35.         call    fpc_ansistr_assign                  ----redundant
  36. .Ll4:
  37.         movq    %rsp,%rdi
  38.         xorl    %edx,%edx
  39.         movl    $10,%esi
  40.         call    fpc_ansistr_setlength
  41. .Ll5:
  42.         movq    $11,112(%rsp)
  43.         movq    $RTTI_$MSETYPES_$$_INTEGERARTY,%rsi
  44.         leaq    112(%rsp),%rcx
  45.         leaq    8(%rsp),%rdi
  46.         movl    $1,%edx
  47.         call    fpc_dynarray_setlength
  48.  

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 4952
    • wiki
Re: FPC 3.2.x series branched, trunk update to 3.3.1
« Reply #10 on: October 22, 2018, 12:52:45 am »
For Windows users: https://sourceforge.net/projects/lazarus-snapshots/files/

Ensure to set the checkbox "secondary installation", then they do not interfere with your stable install.
I uploaded up to date 3.2.0-beta installers for windows, bundled with Lazarus 2.0RC1

Note: Lazarus 2.0RC1 will be released with 3.0.4, but some Lazarus 2.0.x will probably switch to 3.2. So better test both combinations.

Soner

  • Full Member
  • ***
  • Posts: 105
Re: FPC 3.2.x series branched, trunk update to 3.3.1
« Reply #11 on: November 09, 2018, 05:38:55 pm »
It seems that something with the IsMultiThread variable changed.

Look my comments in the example from lazarus/examples/multithreading (you must add this lines and one Tlabel).

Code: Pascal  [Select]
  1. procedure TForm1.FormCreate(Sender: TObject);
  2. begin
  3.  
  4.   // IsMultiThread is here with  with fpc 3.0.4 true and with fpc 3.2.0 false
  5.   if IsMultiThread then  Label1.Caption:=' Yes _ IsMultiThread='+Ord(IsMultiThread).ToString
  6.   else  Label1.Caption:=' No _ IsMultiThread='+Ord(IsMultiThread).ToString;
  7.  
  8.   // ...
  9. end;    
  10.  
  11.  
  12. procedure TMyThread.Execute;
  13. begin
  14.     // HERE IsMultiThread for both true
  15.     newStatus:='TMyThread Time: '+FormatDateTime('YYYY-MM-DD HH:NN:SS',Now)+' _ IsMultiThread='+Ord(IsMultiThread).ToString;
  16.    
  17. end;
  18.  

This is only information for fpc-developer.  I don't know if is it bug or new feature.
I never used multithreading on fpc, I detected it as I look some examples here:
http://forum.lazarus-ide.org/index.php/topic,43005.msg301598
Maybe you should put this on your changed list, so the developer can change their code.

This is my lazaurs and fpc version
Lazarus Svn 2.1.0 r59470 (from 6.11.2018)
Fpc 3.2.0  r40279 (from today https://svn.freepascal.org/svn/fpc/branches/fixes_3_2/)
All 32Bit on Windows 10 64Bit.

I compile fpc 3.2.0.r59470 with fpc 3.2.0.r39795 from 2018/9/23

marcov

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 6627
Re: FPC 3.2.x series branched, trunk update to 3.3.1
« Reply #12 on: November 09, 2018, 07:05:37 pm »
It seems that something with the IsMultiThread variable changed.

You mean different from the documented behaviour?



Soner

  • Full Member
  • ***
  • Posts: 105
Re: FPC 3.2.x series branched, trunk update to 3.3.1
« Reply #13 on: November 09, 2018, 07:47:57 pm »
@marco
I don't know anything about multithreading and IsMultiThread variable in fpc.
I wanted only inform the developers and users of fpc.
In example from above and in ibx-examples with fpc 3.0.2 IsMultiThread is in OnFormCreate true but with fpc 3.2.0. it is false.

When this normal is then it is okay.
According to documentation the behavior in version 3.2.0 is more correct.
Maybe you should write in fpc 3.2.0 release notes something like "IsMultiThreads value is more accurate now", to inform the developers.

Edit 1:
Maybe Toni (author of ibx) and others need a variable like IsMultiThreadSupported.
After reading the documentation and thinking about, I must say the behavior in 3.0.2 is wrong.
« Last Edit: November 09, 2018, 07:56:01 pm by Soner »

Thaddy

  • Hero Member
  • *****
  • Posts: 7199
Re: FPC 3.2.x series branched, trunk update to 3.3.1
« Reply #14 on: November 09, 2018, 08:29:12 pm »
Note the behavior on different platforms is slightly different (has always been the case).
- On unixes (Posix), IsMultiThread is set when you include cthreads in the uses clause, assuming that if you include a threadmanager it is your intention to have a multithreaded application..
- On Windows, IsMultiThread is set when a thread is actually used (except from the bare Windows API functions, you need to set IsMultiThread by hand). For Windows there is a minimal Threadmanager included in the system unit.
- On other platforms it may vary
These differences are wholly caused by the differences in the underlying OS.
The specific behavior is mainly documented in the sources but the above is also documented in the official documentation.
See https://www.freepascal.org/docs-html/current/prog/progch10.html#progse43.html

Note that currently some work is going on in trunk related to thread local storage and as always implementation details need not be documented if there are no side effects.

In general don't assume anything about threading internals and don't assume the behavior is equivalent to e.g. Delphi.
And more broadly speaking I am one of those people that believe that a programmer that uses threading requires a license. Relatively few people qualify.....in any language...
« Last Edit: November 09, 2018, 08:43:09 pm by Thaddy »
inline variables like in D10.3 are a bit like Brexit: if you are given the wrong information it sounds like a good idea. Every kid loves candy, but it makes you fat and your teeth will disappear.