Re: [fpc-devel] Adapting MakeFile to make subfolders for targets with sub architectures
Op 11-08-18 om 10:22 schreef Christo: In my mind it was easier to think of subarch/abi options as extending the target concept, so each valid combination of CPU-OS-SUBARCH-ABI results in a unique target, which ends up in a separate directory. This concept seems to fit in well with the current concept of target=CPU-OS and requires minimal changes on both the Makefile side and fpmake side. As said, i did not really look into your changes. I had Florian's directory layout in mind. Maybe this is also an idea. Florian, what do you think? This is a bit different to how Florian started his modifications, which was CPU-OS/SUBARCH-ABI. This created some bifurcation in directory & file name conventions, hence my suggested approach above. Note that I am not familiar with the details of fpmkunit. I've looked at lcl/interfaces and here it seems as if each variant has its own list of units required. In this case most/all of the required units stay the same, it is just the used compiled unit paths and unit/binary output path that would differ. I'm sure I'm missing something about the way PackageVariants are supposed to work. PackageVariants can do more than you need, that's true. You only have to define some additional compiler-parameters, and search-paths, the rest will be done automatically. Regards, Joost. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] debug info by FPC upsets GDB when step-over
I am not sure when this started. It is certainly happening with fpc 3.0.4 and trunk. I do not know if it worked with earlier versions, but afaik user complaints only started since Lazarus was released with 3.0.4 - It happens with all versions of GDB. (So it is not something that changed in GDB, but may still be an issue in GDB / dont know) - It only happens with 64 bit apps (I only tested on Windows). When stepping through code (Lazarus trunk / different code may be needed for other versions, but it happens fairly frequent, so any bigger project should do) procedure TForm1.FormCreate(Sender: TObject); var a: String; begin a := 'aa'; // breakpoint on this line Caption := a; Cascade; end; Pressing F8 (step over) on Cascade, GDB will actually enter the function. GDB seems to believe that some part of the Cascade function is part of FormCreate. The following appears to fix it:| objcopy.exe -R .debug_frame project1.exe project1n.exe So there is something in debug_frame that upsets gdb. That is all I know. Any idea? | ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] SizeOf( const typcasted as shortstring)
On Mon, Aug 13, 2018 at 5:24 AM Sven Barth via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > It's odd that such expression compiles w/o any warnings or notes. (i.e. >> "ignoring typecasting for constant value expressions") >> > > Support for typecasts in untyped constants is by design and sometimes > required, e.g. for unsigned 64-Bit values. > > Does it mean, that in case of ShortString casting the value of the constant string should be extended up to 255 (256?) characters? thanks, Dmitry ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Case code pattern
Il 13/08/2018 16:29, J. Gareth Moreton ha scritto: I haven't explored it too deeply myself, but from what I understand, a jump table is only generated if there are a large number of branches (over 50). If it's just a handful of branches, it simply subtracts values from the input corresponding to the differences between the case labels, and jumping to the next subtraction if there's a mismatch, or to the else block if it goes negative. I'm not sure what it does for strings though. Gareth aka. Kit I see, I suspected the existence of a threshold value. I am not interested in strings, thank you, Marco ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Case code pattern
I haven't explored it too deeply myself, but from what I understand, a jump table is only generated if there are a large number of branches (over 50). If it's just a handful of branches, it simply subtracts values from the input corresponding to the differences between the case labels, and jumping to the next subtraction if there's a mismatch, or to the else block if it goes negative. I'm not sure what it does for strings though. Gareth aka. Kit On Mon 13/08/18 16:20 , Marco Borsari via fpc-devel fpc-devel@lists.freepascal.org sent: Hello, I would need a clarification about the way the case statement is translated into assembler by FPC. When the list of alternatives is continous, does the compiler generate a jump table? And if yes, there is some conditions for which a fall-through is performed anyway? Thank you, Marco Borsari ___ fpc-devel maillist - fpc-devel@lists.freepascal.org [1] http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel [2]">http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel Links: -- [1] mailto:fpc-devel@lists.freepascal.org [2] http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Case code pattern
Hello, I would need a clarification about the way the case statement is translated into assembler by FPC. When the list of alternatives is continous, does the compiler generate a jump table? And if yes, there is some conditions for which a fall-through is performed anyway? Thank you, Marco Borsari ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] SizeOf( const typcasted as shortstring)
Dmitry Boyarintsev schrieb am Mo., 13. Aug.
2018, 00:12:
> On Sun, Aug 12, 2018 at 5:40 PM Bart wrote:
>
>> const
>> x = ShortString('abc');
>> begin
>> writeln(SizeOf(x));
>> end.
>>
>> Delphi (7) prints 256, fpc prints 3.
>>
>> Is that a bug or an implementation detail?
>>
>
> Implementation detail.
> And it seems to be wrong on Delphi size, because for reason it assigns a
> type to a (non-typed) constant.
> It would make sense to return 256, if the constant was declared like this:
> const
>x : ShortString = 'abc';
> and fpc does recognize such typed constant as 256 in size.
>
> It's odd that such expression compiles w/o any warnings or notes. (i.e.
> "ignoring typecasting for constant value expressions")
>
Support for typecasts in untyped constants is by design and sometimes
required, e.g. for unsigned 64-Bit values.
Regards,
Sven
>
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
