Re: [fpc-devel] Might need some help with this one

2020-11-26 Thread Tomas Hajny via fpc-devel

On 2020-11-26 20:17, Bart via fpc-devel wrote:

On Thu, Nov 26, 2020 at 6:52 PM Jonas Maebe via fpc-devel
 wrote:


"break" is probably a command that's recognised by the cmd shell.

Yes it is:
C:\Users\Bart>help break
Sets or Clears Extended CTRL+C checking on DOS system

This is present for Compatibility with DOS systems. It has no effect
under Windows.

If Command Extensions are enabled, and running on the Windows
platform, then the BREAK command will enter a hard coded breakpoint
if being debugged by a debugger.


Try to
execute the program as .\break or break.exe


Makes no difference whatsoever.
It does run, because you can set ExitCode and query errorlevel after 
execution.


Typing 'break.exe' in cmd.exe _does_ make a difference here (it executes 
as expected unlike when typing just 'break'). And obviously running 
break.exe using some other 'shell' (e.g. your preferred OFM ;-) ) works 
as well.


Tomas
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] Problems building on i386-win32

2020-11-26 Thread J. Gareth Moreton via fpc-devel
The fact that it doesn't seem to throw a warning if the library is 
missing is a bit weird.  Or if it does, I haven't noticed the message.


Gareth aka. Kit

On 26/11/2020 21:02, Sven Barth via fpc-devel wrote:

Am 26.11.2020 um 21:48 schrieb J. Gareth Moreton via fpc-devel:
I figured it was something like that.  I'm not sure which installer 
put it there, or if moving it to the System32 directory will cause 
something to catastrophically fail!


Given that it seems to just silently ignore the issue of the DLL 
doesn't exist, would a warning be better for an invalid DLL or should 
it remain an error?
Good question. I don't know why we have the DLL scanner anyway, 
considering that it also works without the DLL present...


Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel



--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] Problems building on i386-win32

2020-11-26 Thread Sven Barth via fpc-devel

Am 26.11.2020 um 21:48 schrieb J. Gareth Moreton via fpc-devel:
I figured it was something like that.  I'm not sure which installer 
put it there, or if moving it to the System32 directory will cause 
something to catastrophically fail!


Given that it seems to just silently ignore the issue of the DLL 
doesn't exist, would a warning be better for an invalid DLL or should 
it remain an error?
Good question. I don't know why we have the DLL scanner anyway, 
considering that it also works without the DLL present...


Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] Commits without log message

2020-11-26 Thread Sven Barth via fpc-devel

Am 26.11.2020 um 21:48 schrieb avx512 via fpc-devel:

Hi,

sorry, there were small changes in my private branch.


Editing log messages is enabled for the FPC repository.

Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] Commits without log message

2020-11-26 Thread avx512 via fpc-devel

Hi,

sorry, there were small changes in my private branch.

Torsten


Am 26.11.2020 um 20:29 schrieb Bart via fpc-devel:

Hi,

r47600 and r47580 seem to have empty log messages (when viewed with
ViewVC: https://svn.freepascal.org/cgi-bin/viewvc.cgi/?root=fpc=log)

That's just not very nice IMHO.



___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] Problems building on i386-win32

2020-11-26 Thread J. Gareth Moreton via fpc-devel
I figured it was something like that.  I'm not sure which installer put 
it there, or if moving it to the System32 directory will cause something 
to catastrophically fail!


Given that it seems to just silently ignore the issue of the DLL doesn't 
exist, would a warning be better for an invalid DLL or should it remain 
an error?


Gareth aka. Kit

On 26/11/2020 20:33, Sven Barth via fpc-devel wrote:

Am 25.11.2020 um 00:37 schrieb J. Gareth Moreton via fpc-devel:

Hi everyone,

This might be my own configuration, but can people check that 
i386-win32 works properly? I tried to build it to test one of my new 
optimisations, but got a failure when building the trunk (without my 
optimisations).


Building using "make all install OS_TARGET=win32 CPU_TARGET=i386 
FPC=C:\FPC\3.2.0\bin\i386-win32\fpc.exe" (since my machine is 64-bit 
Windows)


...
[ 20%] Compiled package odbc
Start compiling package oracle for target i386-win32.
   Compiling oracle\BuildUnit_oracle.pp
   Compiling .\oracle\src\oratypes.pp
   Compiling .\oracle\src\ocidyn.pp
   Compiling .\oracle\src\oci.pp
   Compiling .\oracle\src\oraoci.pp
External command 
"C:/Users/garet/Documents/programming/fpc/compiler/ppc386.exe -Twin32 
-FUoracle\units\i386-win32\ 
-FuC:\Users\garet\Documents\programming\fpc\rtl\units\i386-win32\ 
-Fuoracle\src -Fioracle\src -Ur -Xs -O2 -n -di386 -dRELEASE -XX -CX 
-Sc -viq oracle\BuildUnit_oracle.pp" failed with exit code 1. Console 
output:

Target OS: Win32 for i386
Compiling oracle\BuildUnit_oracle.pp
Compiling .\oracle\src\oratypes.pp
Compiling .\oracle\src\ocidyn.pp
Compiling .\oracle\src\oci.pp
Compiling .\oracle\src\oraoci.pp
oraoci.pp(1437) Error: Invalid DLL C:\windows\system32\common.dll, 
invalid header size

oraoci.pp(1437) Fatal: There were 1 errors compiling module, stopping
Fatal: Compilation aborted

The installer encountered the following error:
Compilation of "BuildUnit_oracle.pp" failed
make[2]: *** [smart] Error 1
make[2]: Leaving directory 
`C:/Users/garet/Documents/programming/fpc/packages'

make[1]: *** [packages_smart] Error 2
make[1]: Leaving directory `C:/Users/garet/Documents/programming/fpc'
make: *** [build-stamp.i386-win32] Error 2

It seems that the Oracle package is upset about one of my DLLs. 
Anyone got any ideas?  It's blocking more complete testing of my 
changes (and other things like Tomas' console colour patch).


Thank you for sending me the DLL. The problem is that the DLL is a 
64-bit one, but is for some reason located in the virtualized 32-bit 
System32 directory.


Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel



--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] Problems building on i386-win32

2020-11-26 Thread Sven Barth via fpc-devel

Am 25.11.2020 um 00:37 schrieb J. Gareth Moreton via fpc-devel:

Hi everyone,

This might be my own configuration, but can people check that 
i386-win32 works properly? I tried to build it to test one of my new 
optimisations, but got a failure when building the trunk (without my 
optimisations).


Building using "make all install OS_TARGET=win32 CPU_TARGET=i386 
FPC=C:\FPC\3.2.0\bin\i386-win32\fpc.exe" (since my machine is 64-bit 
Windows)


...
[ 20%] Compiled package odbc
Start compiling package oracle for target i386-win32.
   Compiling oracle\BuildUnit_oracle.pp
   Compiling .\oracle\src\oratypes.pp
   Compiling .\oracle\src\ocidyn.pp
   Compiling .\oracle\src\oci.pp
   Compiling .\oracle\src\oraoci.pp
External command 
"C:/Users/garet/Documents/programming/fpc/compiler/ppc386.exe -Twin32 
-FUoracle\units\i386-win32\ 
-FuC:\Users\garet\Documents\programming\fpc\rtl\units\i386-win32\ 
-Fuoracle\src -Fioracle\src -Ur -Xs -O2 -n -di386 -dRELEASE -XX -CX 
-Sc -viq oracle\BuildUnit_oracle.pp" failed with exit code 1. Console 
output:

Target OS: Win32 for i386
Compiling oracle\BuildUnit_oracle.pp
Compiling .\oracle\src\oratypes.pp
Compiling .\oracle\src\ocidyn.pp
Compiling .\oracle\src\oci.pp
Compiling .\oracle\src\oraoci.pp
oraoci.pp(1437) Error: Invalid DLL C:\windows\system32\common.dll, 
invalid header size

oraoci.pp(1437) Fatal: There were 1 errors compiling module, stopping
Fatal: Compilation aborted

The installer encountered the following error:
Compilation of "BuildUnit_oracle.pp" failed
make[2]: *** [smart] Error 1
make[2]: Leaving directory 
`C:/Users/garet/Documents/programming/fpc/packages'

make[1]: *** [packages_smart] Error 2
make[1]: Leaving directory `C:/Users/garet/Documents/programming/fpc'
make: *** [build-stamp.i386-win32] Error 2

It seems that the Oracle package is upset about one of my DLLs. Anyone 
got any ideas?  It's blocking more complete testing of my changes (and 
other things like Tomas' console colour patch).


Thank you for sending me the DLL. The problem is that the DLL is a 
64-bit one, but is for some reason located in the virtualized 32-bit 
System32 directory.


Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] Might need some help with this one

2020-11-26 Thread J. Gareth Moreton via fpc-devel
Okay, so I have to specify "-MObjfpc -Sh" to get it to compile due to 
what the code uses, and the bug still requires the use of -O2 to 
appear.  However... "fpc -MObjfpc -Sh -O2 -Ooregvar -alr -sr breakp.pp" 
produces a bad binary.


I removed the register comments so it's clearer:

    ...
# [11] pChar(result)[i] := BarSym[(progress >= (0.75 + i) / divs) or (i 
= int32(divs) - 1) and (progress >= 1)];

    cvtsi2ssl    %ireg16d,%mreg34ms
    movaps    %mreg34ms,%mreg35ms
    addss    _$BREAKP$_Ld1(%rip),%mreg35ms
    movl    %ireg18d,%ireg28d
    andl    $4294967295,%ireg28d
    cvtsi2ssq    %ireg28q,%mreg37ms
    movaps    %mreg35ms,%mreg38ms
    divss    %mreg37ms,%mreg38ms
    comiss    %mreg32ms,%mreg38ms
    jp    .Lj12
    jbe    .Lj10 < Register %ireg27q not initialised if this 
instruction branches to .Lj10

.Lj12:
    jmp    .Lj11
.Lj11:
    movl    %ireg18d,%ireg29d
    movslq    %ireg29d,%ireg30q
    subq    $1,%ireg30q
    movslq    %ireg16d,%ireg31q
    movq    %ireg31q,%ireg27q < Problem register: %ireg27q
    cmpq    %ireg27q,%ireg30q
    je    .Lj14
    jmp    .Lj15
.Lj14:
    comiss    _$BREAKP$_Ld2(%rip),%mreg32ms
    jp    .Lj17
    jae    .Lj16
.Lj17:
    jmp    .Lj15
.Lj16:
    jmp    .Lj10
.Lj15:
    jmp    .Lj13
.Lj10:
    movq    $1,%ireg32q
    jmp    .Lj18
.Lj13:
    movq    $0,%ireg32q
.Lj18:
    movq    (%ireg17q),%ireg33q
    cmpq    $0,%ireg33q
    jne    .Lj19
    leaq    FPC_EMPTYCHAR(%rip),%ireg33q
.Lj19:
    leaq 
TC_$P$BREAKP$_$BAR$SINGLE$LONGWORD$$ANSISTRING_$$_BARSYM(%rip),%ireg34q

    movb    (%ireg34q,%ireg32q,1),%ireg35l
    movb    %ireg35l,(%ireg33q,%ireg27q,1) < Problem register: %ireg27q
    cmpl    %ireg25d,%ireg16d
    jge    .Lj9
    jmp    .Lj7
.Lj9:
.Lj6:
    ...

The problem register is %ireg27q - it's not being initialised if "jbe 
.Lj10" branches.  By your explanation, it seems that the code generator 
is buggy on one of the nodes.  Thanks for the tips in isolating where it 
could be.  To help out, I've attached the node dump file for the test 
program.


Gareth aka. Kit

On 26/11/2020 19:04, Yuriy Sydorov via fpc-devel wrote:

Hi,

On 26.11.2020 17:34, J. Gareth Moreton via fpc-devel wrote:

Hi everyone,

So a couple of people have reported that -O2 sometimes produces bad 
code under x86_64.  So far it seems isolated to that CPU.


https://bugs.freepascal.org/view.php?id=38129

After my own investigations with the attached code, the problem still 
occurs even if the peephole optimizer is disabled, and the 
uninitialised register is being allocated within conditional code 
that is not always executed, rather than before or after it.


Anyone with any tips on where to dig next (register allocator, node 
converter etc.) would be most appreciated!


First compile with the "-Ooregvar -alr -sr" switches. You will get the 
assembler output with imaginary registers and notes about register 
allocations and de-allocations. Inspect if all is correct at this 
stage. If not then the a code generator of some node is buggy.


Then compile with "-Ooregvar -alr". If the issue is present only at 
this stage, then the bug is in the register allocator.


Yuriy.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel




--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


   
  AnsiString
  
 

   
  
 

   DIVS

 
  
  
 

   result

 
  
   


   
  
 
I
 
  
  
 
0
 
  
  
 

   
  DIVS
   


   1

 
  
  
 

   
  
 
result
 
  
   


   
  
 I
  
   

 
 

[fpc-devel] Commits without log message

2020-11-26 Thread Bart via fpc-devel
Hi,

r47600 and r47580 seem to have empty log messages (when viewed with
ViewVC: https://svn.freepascal.org/cgi-bin/viewvc.cgi/?root=fpc=log)

That's just not very nice IMHO.

-- 
Bart
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] Might need some help with this one

2020-11-26 Thread Bart via fpc-devel
On Thu, Nov 26, 2020 at 6:52 PM Jonas Maebe via fpc-devel
 wrote:

> "break" is probably a command that's recognised by the cmd shell.
Yes it is:
C:\Users\Bart>help break
Sets or Clears Extended CTRL+C checking on DOS system

This is present for Compatibility with DOS systems. It has no effect
under Windows.

If Command Extensions are enabled, and running on the Windows
platform, then the BREAK command will enter a hard coded breakpoint
if being debugged by a debugger.

> Try to
> execute the program as .\break or break.exe

Makes no difference whatsoever.
It does run, because you can set ExitCode and query errorlevel after execution.

-- 
Bart
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] Might need some help with this one

2020-11-26 Thread Yuriy Sydorov via fpc-devel

Hi,

On 26.11.2020 17:34, J. Gareth Moreton via fpc-devel wrote:

Hi everyone,

So a couple of people have reported that -O2 sometimes produces bad code under x86_64.  So far it seems isolated to that 
CPU.


https://bugs.freepascal.org/view.php?id=38129

After my own investigations with the attached code, the problem still occurs even if the peephole optimizer is disabled, 
and the uninitialised register is being allocated within conditional code that is not always executed, rather than 
before or after it.


Anyone with any tips on where to dig next (register allocator, node converter 
etc.) would be most appreciated!


First compile with the "-Ooregvar -alr -sr" switches. You will get the assembler output with imaginary registers and 
notes about register allocations and de-allocations. Inspect if all is correct at this stage. If not then the a code 
generator of some node is buggy.


Then compile with "-Ooregvar -alr". If the issue is present only at this stage, 
then the bug is in the register allocator.

Yuriy.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] Might need some help with this one

2020-11-26 Thread J. Gareth Moreton via fpc-devel

Hah, that's the reason! Thanks Jonas.  Crisis averted.

Now for the original problem...

Gareth aka. Kit

On 26/11/2020 17:52, Jonas Maebe via fpc-devel wrote:

On 26/11/2020 16:34, J. Gareth Moreton via fpc-devel wrote:

P.S. Also, there seems to be a strange, unrelated glitch.  If I rename
the file to "break.pp" and change the program name to "break" (from
breakp), the compiled binary doesn't seem to write output (or it
immediately exits - can't tell yet).  I'm not sure if this is because of
the program name being the same as an instruction or what.

"break" is probably a command that's recognised by the cmd shell. Try to
execute the program as .\break or break.exe


Jonas
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel



--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] Might need some help with this one

2020-11-26 Thread Jonas Maebe via fpc-devel
On 26/11/2020 16:34, J. Gareth Moreton via fpc-devel wrote:
> P.S. Also, there seems to be a strange, unrelated glitch.  If I rename
> the file to "break.pp" and change the program name to "break" (from
> breakp), the compiled binary doesn't seem to write output (or it
> immediately exits - can't tell yet).  I'm not sure if this is because of
> the program name being the same as an instruction or what.

"break" is probably a command that's recognised by the cmd shell. Try to
execute the program as .\break or break.exe


Jonas
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] Might need some help with this one

2020-11-26 Thread J. Gareth Moreton via fpc-devel
That is very peculiar, especially given that Delphi has the same 
problem!  I wonder what's causing that.


Going back to the problem at hand though... seems we have bad code being 
generated in places on x86_64, but it's not in the peephole optimizer 
for once!


Gareth aka. Kit

On 26/11/2020 17:25, Bart via fpc-devel wrote:

On Thu, Nov 26, 2020 at 5:00 PM J. Gareth Moreton via fpc-devel
 wrote:

program break;
{$apptype console}

begin
   writeln('I am Break');
end.

Compiles with fpc 3.2.0 and Delphi 7.
Outputs nothing at all with both compilers

If I run it inside GDB
Delphi 7 of fpc:
Starting program: C:\Users\Bart\LazarusProjecten\bugs\breakprog/break.exe
[New Thread 6888.0x26fc]
[New Thread 6888.0x1ea0]
[New Thread 6888.0x6bc]
[New Thread 6888.0x25b0]
I am Break

Program exited normally.




--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] Might need some help with this one

2020-11-26 Thread Bart via fpc-devel
On Thu, Nov 26, 2020 at 6:25 PM Bart  wrote:

> program break;
> {$apptype console}
>
> begin
>   writeln('I am Break');
> end.
>
> Compiles with fpc 3.2.0 and Delphi 7.
> Outputs nothing at all with both compilers
>
> If I run it inside GDB
> Delphi 7 of fpc:
> Starting program: C:\Users\Bart\LazarusProjecten\bugs\breakprog/break.exe
> [New Thread 6888.0x26fc]
> [New Thread 6888.0x1ea0]
> [New Thread 6888.0x6bc]
> [New Thread 6888.0x25b0]
> I am Break
>
> Program exited normally.
>
>
> --
> Bart

  assign(F, 'break.txt');
  rewrite(F);
  writeln(F,'Writing to file...');
  close(F);

Does not create a file (if the program is called break).
Unless you run it in GDB, then it does.

Curious...

If you rename the executable (so after compilation/building) it runs
as expected.
So it is Windows that does this .


-- 
Bart
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] Might need some help with this one

2020-11-26 Thread Bart via fpc-devel
On Thu, Nov 26, 2020 at 5:00 PM J. Gareth Moreton via fpc-devel
 wrote:

program break;
{$apptype console}

begin
  writeln('I am Break');
end.

Compiles with fpc 3.2.0 and Delphi 7.
Outputs nothing at all with both compilers

If I run it inside GDB
Delphi 7 of fpc:
Starting program: C:\Users\Bart\LazarusProjecten\bugs\breakprog/break.exe
[New Thread 6888.0x26fc]
[New Thread 6888.0x1ea0]
[New Thread 6888.0x6bc]
[New Thread 6888.0x25b0]
I am Break

Program exited normally.


-- 
Bart
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] Might need some help with this one

2020-11-26 Thread J. Gareth Moreton via fpc-devel
Technically it isn't a reserved word, or at least not a keyword. Either 
way the compiler allows it, but the result is peculiar.  It probably 
shouldn't be allowed in that case.


Gareth aka. Kit

On 26/11/2020 15:58, Bart via fpc-devel wrote:

On Thu, Nov 26, 2020 at 4:34 PM J. Gareth Moreton via fpc-devel
 wrote:


P.S. Also, there seems to be a strange, unrelated glitch.  If I rename
the file to "break.pp" and change the program name to "break" (from
breakp), the compiled binary doesn't seem to write output (or it
immediately exits - can't tell yet).  I'm not sure if this is because of
the program name being the same as an instruction or what.

Isn't break a reserved word?



--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] Might need some help with this one

2020-11-26 Thread Bart via fpc-devel
On Thu, Nov 26, 2020 at 4:34 PM J. Gareth Moreton via fpc-devel
 wrote:

> P.S. Also, there seems to be a strange, unrelated glitch.  If I rename
> the file to "break.pp" and change the program name to "break" (from
> breakp), the compiled binary doesn't seem to write output (or it
> immediately exits - can't tell yet).  I'm not sure if this is because of
> the program name being the same as an instruction or what.

Isn't break a reserved word?

-- 
Bart
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


[fpc-devel] Might need some help with this one

2020-11-26 Thread J. Gareth Moreton via fpc-devel

Hi everyone,

So a couple of people have reported that -O2 sometimes produces bad code 
under x86_64.  So far it seems isolated to that CPU.


https://bugs.freepascal.org/view.php?id=38129

After my own investigations with the attached code, the problem still 
occurs even if the peephole optimizer is disabled, and the uninitialised 
register is being allocated within conditional code that is not always 
executed, rather than before or after it.


Anyone with any tips on where to dig next (register allocator, node 
converter etc.) would be most appreciated!


Gareth aka. Kit

P.S. Also, there seems to be a strange, unrelated glitch.  If I rename 
the file to "break.pp" and change the program name to "break" (from 
breakp), the compiled binary doesn't seem to write output (or it 
immediately exits - can't tell yet).  I'm not sure if this is because of 
the program name being the same as an instruction or what.




--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
program breakp;

function Bar(const progress: single; divs: uint32): string;
const
BarSym: array[boolean] of char = ('.', '#');
var
i: int32;
begin
SetLength(result, divs);
for i := 0 to int32(divs) - 1 do
pChar(result)[i] := BarSym[(progress >= (0.75 + i) / divs) or (i = 
int32(divs) - 1) and (progress >= 1)];
end;

var
s: string;

begin
s := Bar(0.7, 10) + ' 70%';
writeln(s);
WriteLn('Odd');
end.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


[fpc-devel] thread safe random

2020-11-26 Thread thaddy via fpc-devel

I think that the just committed threadsafe random is overly complex.
I provided a working version some time ago that is less intrusive.
https://forum.lazarus.freepascal.org/index.php/topic,35050.msg242571.html#msg242571
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] Problems building on i386-win32

2020-11-26 Thread Alexander Bunakov via fpc-devel

On 25.11.2020 4:37, J. Gareth Moreton via fpc-devel wrote:

Compiling .\oracle\src\oraoci.pp
oraoci.pp(1437) Error: Invalid DLL C:\windows\system32\common.dll, 
invalid header size

oraoci.pp(1437) Fatal: There were 1 errors compiling module, stopping
Fatal: Compilation aborted


From packages\oracle\README.txt:

"For the older 'oraoci' unit to compile you need oracle
server installed, these units was tested and performed
on Oracle 8.0.1.5 Standard server. One developer license
of Oracle server is free of charge..."

Looks like the common.dll is not the right one that is needed to compile.

--
Regards,
Alexander
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] Problems building on i386-win32

2020-11-26 Thread Virgo Pärna via fpc-devel
On Wed, 25 Nov 2020 08:51:19 +, J. Gareth Moreton via fpc-devel 
 wrote:
> Aah, typical!  C:\Windows\System32 is supposed to be for 32-bit DLLs, 
> while C:\Windows\System is 64-bit.  Question is, what can I do to 
> resolve it?  I'm not even sure what Common.dll is for.

 SYSTEM32 has 64 bit files on 64 bit Windowsi, 32 bit files go to
 SysWOW64. I'm not sure, what SYSTEM was for. And Windows Virtualises
 access to SYSTEM32 to SysWOW64 for 32 bit programs. I specifically
 tested with 32 and 64 bit Total Commander - they show different content
 for C:\WINDOWS\SYSTEM32 directory.
So if the compiler is 32 bit fpc, then actual dll should be
C:\Windows\SysWOW64. And if that is 64 bit dll for some reason, then
that could cause problems. 

-- 
Virgo Pärna 
virgo.pa...@mail.ee

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] Problems building on i386-win32

2020-11-26 Thread Alexander Bunakov via fpc-devel

On 25.11.2020 4:37, J. Gareth Moreton via fpc-devel wrote:
This might be my own configuration, but can people check that i386-win32 
works properly? I tried to build it to test one of my new optimisations, 
but got a failure when building the trunk (without my optimisations).


Building using "make all install OS_TARGET=win32 CPU_TARGET=i386 
FPC=C:\FPC\3.2.0\bin\i386-win32\fpc.exe" (since my machine is 64-bit 
Windows)


Just now successfully compiled both i386-win32 and x86_64-win64 from 
trunk r47572 with release FPC 3.2.0.


--
Regards,
Alexander
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel