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 Comp
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 someth
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 th
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://li
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&view=log)
That's just not very nice IM
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 DL
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).
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]
Hi,
r47600 and r47580 seem to have empty log messages (when viewed with
ViewVC: https://svn.freepascal.org/cgi-bin/viewvc.cgi/?root=fpc&view=log)
That's just not very nice IMHO.
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https:/
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
unde
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 attac
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 f
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 t
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:
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\
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\B
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
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 ex
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
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-dev
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\ora
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
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 "mak
23 matches
Mail list logo
