Re: [fpc-pascal] Barriers semantics
Jonas Maebe via fpc-pascal schrieb am Mo., 14. Aug. 2023, 21:02: > On 14/08/2023 18:19, denisgolovan via fpc-pascal wrote: > > Now we have "volatile" intrinsic for assignments in place, I'd like to > ask for another clarification. > > Just to make sure given your questions below: using volatile in the > context of multithreaded code is completely wrong in 99.9% of the cases, > and when it's not in the best case it's usually just highly inefficient. > volatile in FPC/C++ is unrelated to volatile in Java or C# in that respect. > > > Documentation states we have following barriers - ReadBarrier, > WriteBarrier, ReadDependencyBarrier, ReadWriteBarrier. > > > > I'd like to get an idea how those related to more common / standard > terms - Acquire/Release & their combinations? > > Read/Write barriers are terms used in cpu architecture manuals. > Acquire/Release are high level parallel programming terms. > Doesn't Aarch64 use acquire/release instructions for locking? đŸ¤” > > Is it safe to assume that: > > > > ReadBarrier - Acquire > > WriteBarrier - Release > > ReadWriteBarrier - Acquire+Release > > ReadDependencyBarrier - which one is that? > > You cannot express a ReadDependencyBarrier in terms of acquire/release. > See e.g. the explanation of "data dependency barrier" at > https://www.sobyte.net/post/2022-08/cpu-cache-and-memory-barriers/ . In > practice, I don't think any currently used cpu architectures still > require such barriers though. > It depends on the use case. When working with external hardware onm Aarch64 (e.g. with DMA) they are very much a necessity. Regards, Sven > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] encodeURLElement in latest FPC source build
Hi all,
Not sure if this is a bug, but I'm seeing some strange behaviour with
encodeURLElement on the latest build from source.
See attached file url.pas.
I'm using Debian 12.
Regards,
David Connolly
{$mode delphi}
{$H+}
{$codepage utf8}
program url;
uses
cwstring,
fphttpclient;
var
ansi : ansiString = 'Hello ANSI World!';
uni : unicodeString = 'Hello UNICODE World!';
utf8 : UTF8String = 'Hello UTF8 World!';
raw : RawByteString = 'Hello RAW World!';
begin
writeln( 'lit = ', 'Hello LITERAL World!' );
writeln( 'lit = ', encodeURLElement( 'Hello LITERAL World!' ) );
writeln( '' );
writeln( 'ansi= ', ansi );
writeln( 'ansi= ', encodeURLElement( ansi ) );
writeln( '' );
writeln( 'unicode = ', uni );
writeln( 'unicode = ', encodeURLElement( uni ) );
writeln( '' );
writeln( 'uft8= ', utf8 );
writeln( 'uft8= ', encodeURLElement( utf8 ) );
writeln( '' );
writeln( 'raw = ', raw );
writeln( 'raw = ', encodeURLElement( raw ) );
writeln( '' );
end.___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Barriers semantics
Jonas Maebe via fpc-pascal wrote: See e.g. the explanation of "data dependency barrier" at https://www.sobyte.net/post/2022-08/cpu-cache-and-memory-barriers/ . In Interesting stuff to read. Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] LLVM LTO
Hi -Clflto -Clflto-no-system -k-fuse-ld=gold -k-plugin=/path/to/LLVMgold.so that helped, but I have to do it without -Clflto-no-system, or it gives an error Then I could run my unit tests: FPC alone: 25 seconds LLVM: 21 seconds LLVM LTO: 20 seconds does not seem to matter much Cheers, Benito On 11.08.23 12:46, Jonas Maebe via fpc-pascal wrote: On 10/08/2023 17:06, Benito van der Zander via fpc-pascal wrote: I tried to use the LLVM Link-Time-Optimization, -Clflto I should update the wiki page. Under Debian 11, I can tell FPC to use gold with lto by specifying the following command line parameters: -Clflto -Clflto-no-system -k-fuse-ld=gold -k-plugin=/path/to/LLVMgold.so Note that compiling the FPC RTL with LTO currently doesn't work under Linux, because LLVM does not rename local labels in pure assembler procedures when doing so, resulting in duplicate labels. It works fine when compiling FPC and its units normally, and then only using LTO for your program. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] LLVM LTO
On 15/08/2023 17:24, Benito van der Zander via fpc-pascal wrote: Hi -Clflto -Clflto-no-system -k-fuse-ld=gold -k-plugin=/path/to/LLVMgold.so that helped, but I have to do it without -Clflto-no-system, or it gives an error That was a typo, it's -Clfltonosystem. But it doesn't matter if the RTL is not compiled with LTO. Then I could run my unit tests: FPC alone: 25 seconds LLVM: 21 seconds LLVM LTO: 20 seconds does not seem to matter much It depends on the program. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] LLVM crash
Hi On which platform? When I compile the attached tt.pp file with -gw4 -Clfsanitize=address (LLVM 13, Debian 11, x86-64) and then run it, I get the output in tt.txt. It includes line information. You could try lldb instead of gdb, although gdb should also be able to handle debug information generated by LLVM. Ubuntu 22.04, LLVM 13 Nothing helps. only some units are affected Actually, now I see the warnings during compilation Assembling xquery mismatched subprogram between llvm.dbg.addr variable and !dbg attachment inlinable function call in a function with debug info must have a !dbg location  invoke void @"\01XQUERY$_$IXQVALUE_$__$$_$finalize$IXQVALUE"(%typ.XQUERY.IXQValue* %reg.1_200)  to label %.Lj9768 unwind label %.Lj9743 .  call void @llvm.dbg.addr(metadata %typ.SYSTEM.TRTLCriticalSection* %tmp.1, metadata !48637, metadata !DIExpression()), !dbg !48773 label %0 void ()* @"\01XQUERY_$$_finalize$" !48637 = !DILocalVariable(name: "_zero_$SYSTEM_$$_TRTLCRITICALSECTION", scope: !48635, file: !3, line: 10567, type: !1260) !48635 = distinct !DISubprogram(name: "XQUERY_$$_init$", scope: !3, file: !3, line: 3506, type: !7606, scopeLine: 10504, spFlags: DISPFlagDefinition, unit: !2) !48773 = !DILocation(line: 10570, column: 1, scope: !48772) !48772 = distinct !DISubprogram(name: "XQUERY_$$_finalize$", scope: !3, file: !3, line: 10570, type: !7606, scopeLine: 10570, spFlags: DISPFlagDefinition, unit: !2) warning: ignoring invalid debug info in /home/theo/lib/fpc/x86_64-linux/xquery.ll The first appears to be caused by my managed operator patch Then there is the default issue https://gitlab.com/freepascal.org/fpc/source/-/issues/40395 (and you have fixed it while I was still writing this mail) Then this: https://gitlab.com/freepascal.org/fpc/source/-/issues/40280 is causing a stack corruption https://gitlab.com/freepascal.org/fpc/source/-/issues/40392 is causing a heap corruption Cheers, Benito On 11.08.23 12:57, Jonas Maebe via fpc-pascal wrote: On 10/08/2023 23:27, Benito van der Zander via fpc-pascal wrote: i tried to run my program under LLVM (from july fpc) and it crashes? Program received signal SIGSEGV, Segmentation fault. 0x0042e5f1in SYSTEM_$$_SYSGETMEM_FIXED$QWORD$$POINTER() (gdb) bt #0 0x0042e5f1in SYSTEM_$$_SYSGETMEM_FIXED$QWORD$$POINTER() #1 0x0041b92ain fpc_ansistr_setlength() #2 0x00558d52in RESETBUFFER(ABUFFER=0x7fffd560, BASECAPACITY=130) at bbutils.pas:1650 #3 INIT(ABUFFER=0x7fffd560, BASECAPACITY=130, AENCODING=65001) at bbutils.pas:1639 #4 STRDECODEHTMLENTITIES(result=0x0, P=, L=130, ENCODING=65001, FLAGS=...) at bbutils.pas:5527 anyone has seen sysgetmem crash before? It suggests heap corruption. Perhaps that is exactly the kind of things ASAN was supposed to detect. Possibly, yes. But with ASAN, I get an error somewhere entirely else. And I do not understand it, because the function is shown as ~ 5000 lines of assembly. How can I see the mixed code with disassemble /rm in gdb? I tried to call fpc -gl, -gs and -gw, and nothing helps On which platform? When I compile the attached tt.pp file with -gw4 -Clfsanitize=address (LLVM 13, Debian 11, x86-64) and then run it, I get the output in tt.txt. It includes line information. You could try lldb instead of gdb, although gdb should also be able to handle debug information generated by LLVM. And there are a lot of weird ASAN calls for trivial movs. Like: 0x006f577c<+22204>: 48 8b bb c8 00 00 00 movrdi,QWORDPTR[rbx+0xc8] 0x006f5783<+22211>: e8 18 cc d0 ff call0x4023a0<__asan_report_load8@plt> 0x006f5788<+22216>: e8 13 cc d0 ff call0x4023a0<__asan_report_load8@plt> 0x006f578d<+1>: e8 0e cc d0 ff call0x4023a0<__asan_report_load8@plt> 0x006f5792<+6>: e8 09 cc d0 ff call0x4023a0<__asan_report_load8@plt> 0x006f5797<+22231>: 48 89 c7 movrdi,rax 0x006f579a<+22234>: e8 01 cc d0 ff call0x4023a0<__asan_report_load8@plt> 0x006f579f<+22239>: 48 89 cf movrdi,rcx 0x006f57a2<+22242>: e8 09 ca d0 ff call0x4021b0<__asan_report_store8@plt> Are they supposed to be there? These are generated by LLVM's own code generator, so yes. Jonas ___ fpc-pascal maillist -fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
