[SOLVED] {$push} and {$pop} on trunk [2024/02/13] doen't work

[Fibonacci]

There is other issue, watch the video.

Uncommenting a comment affects how the compiler works. A COMMENT. WTF?

FPC trunk x64 Windows. Can someone confirm commenting/uncommenting A COMMENT changes structure size? Is it just me? Its really weird.

[rvk]

Ha, now I get it too. (Your code was the correct version)

pi@raspberrypi:~ $ fpc a.pas
Free Pascal Compiler version 3.3.1 [2024/02/13] for aarch64
Copyright (c) 1993-2024 by Florian Klaempfl and others
Target OS: Linux for AArch64
Compiling a.pas
Assembling program
Linking a
18 lines compiled, 0.2 sec, 166500 bytes code, 62954 bytes data
pi@raspberrypi:~ $ ./a
sizeof midi = 268
sizeof list = 280 <---- WATCH THIS

pi@raspberrypi:~ $

It only happens if there is nothing (no code) above or below the comment.

BTW there are more problems with the latest trunk as Lazarus won't compile anymore (apparently due to a problem in both fpc and lazarus code. Probably not connected).

[TRon]

I am able to confirm at Debian x86-64, old trunk:

Without comment:

Code: [Select]

$ fpc -V3.3.1 test.pas
Free Pascal Compiler version 3.3.1 [2022/03/31] for x86_64
Copyright (c) 1993-2022 by Florian Klaempfl and others
Target OS: Linux for x86-64
Compiling test.pas
Linking test
28 lines compiled, 0.1 sec, 142016 bytes code, 54232 bytes data
$ ./test
sizeof midi = 268
sizeof list = 280 <---- WATCH THIS

With comment:

Code: [Select]

$ fpc -V3.3.1 test.pas
Free Pascal Compiler version 3.3.1 [2022/03/31] for x86_64
Copyright (c) 1993-2022 by Florian Klaempfl and others
Target OS: Linux for x86-64
Compiling test.pas
Linking test
31 lines compiled, 0.1 sec, 142016 bytes code, 54232 bytes data</pre>
$ ./test
sizeof midi = 268
sizeof list = 272 <---- WATCH THIS

April 1st seem to have come early this year 

[Fibonacci]

I made a minimal reproducible.

Code: Pascal  [Select][+][-]

1. type
2.   {$push}
3.   {$packrecords 4}
4.   test1 = record
5.     q: qword; // 8
6.     b: byte;  // 1
7.   end;        // 12 aligned
8.   {$pop}
9.   // this comment fixes it, without this comment test2 is not aligned to 4 bytes
10.   {$push}
11.   {$packrecords 4}
12.   test2 = record
13.     t1: test1; // 12
14.   end;         // 12 aligned
15.   {$pop}
16.  
17. begin
18.   writeln('sizeof test1 = ', sizeof(test1));
19.   writeln('sizeof test2 = ', sizeof(test2), ' <---- WATCH THIS');
20.  
21.   readln;
22. end.

It doesnt work with block comment {}, must be line comment //.

Remove this comment, or replace it with block comment and it messes up the push & pack & pop sequence. Parsing error or something. @PascalDragon needed here.

@Key-Real: SOLUTION TO YOUR PROBLEM: Put a line comment between your push-pop blocks and its fixed No kidding.

[Key-Real]

Did you try what happens if you put both record definitions in the same {$packrecords 4} block?
( so don't {$pop} and {$push} until the last (MIDIPacketList) is declared )

this works


btw. the solution with a comment inbetween  is inacceptable,
I don't wanna change the FPC Sources, this should work as it is(and has worked a half a year ago).

I subscrubed to the Dev-List and send a main, but my Mail doesn't shows up in the February thread I don't knew why?

If a Dev reads this pls put this on the list!    , thx

[rvk]

btw. the solution with a comment inbetween  is inacceptable,
I don't wanna change the FPC Sources, this should work as it is(and has worked a half a year ago).

Any code will work in between those pop and push.

O wow, I didn't realize this snippet was in FPC itself (and indeed with the bracket-comment in between).

Line 580 of .\fpc\packages\univint\src\MIDIServices.pas

If a Dev reads this pls put this on the list!    , thx

I think the way it works is that you open a bug report for this.

(you can hope for someone else to do it, or a reaction on the mailing list, but no telling how long that would take )

BTW. The following issue might be related (it mentions the 280 on cocoa but 272 on carbon).
(although it's a slightly different problem)

MidiPacket and MidiPacketList Size if differnece between carbon and cocoa.
https://gitlab.com/freepascal.org/fpc/source/-/issues/35750

https://forum.lazarus.freepascal.org/index.php/topic,45782.0.html

[Key-Real]

BTW. The following issue might be related (it mentions the 280 on cocoa but 272 on carbon).
(although it's a slightly different problem)

MidiPacket and MidiPacketList Size if differnece between carbon and cocoa.
https://gitlab.com/freepascal.org/fpc/source/-/issues/35750

https://forum.lazarus.freepascal.org/index.php/topic,45782.0.html

Yes, thats why I fixed the FPC Source! half a year ago

[Josh]

Hi

This is extremely worrying, unfotunately I cannot check/help until earliest weekend.

But my concern is this can effect any fix sized data structure (not just midiservices) , that is defined for working with nearly anything.

And putting a superfluous // comment in ( that should be ignored in its entireaty by the compiler) is effected the size of the structure.

This needs to be fixed urgently, as it will break countless things, that the programmer will find hard to locate, and if they do how to fix a structure that is larger than it should be.

Can someone do a test of other structures with calculateable size with 4 byte alignment , and see what the results are?

Hopefully this gets to the fpc dev team urgently.

Fixing midiservices is pointless as there is no reason why its now reporting wrong size, fixing the cause is paramount.

[Key-Real]

I mailed yesterday to the devML but my mail don't apear on the list

someone pls, send a mail to the DevML

[Bart]

I would suggest to just report on the bugtracker.
Add your example code to the bugreport.
Clearly state which architecture.
And you may also say that aother architectures were tested (here on the forum) and were fine.

Bart

[Josh]

Hi

Unfortunately i did not get a chance to do any tests over the weekend.

Any updates on this?

[Fibonacci]

I've seen it on mailing lists, without much interest, now it's on gitlab: https://gitlab.com/freepascal.org/fpc/source/-/issues/40655

I'm curious what the devs have to say that "inline comment" between structures is a fix

[Key-Real]

This Issue was fixed.

[TRon]

Thank you for reporting Key-Real, that was a nasty one. And of course thank you PD for the fix.