[fpc-devel] error target i386 -Cp80486

[J. Gareth Moreton]

I've gotten back as far as here, and it's still bad:

commit 7fbda0e0e8b1d071e72ccbc5e487dbb1c2173c63 (HEAD)
Author: Jonas Maebe <jonas at freepascal.org>
Date:   Wed Mar 24 14:33:09 2021 +0000

       * support building with FPC 3.2.2

     git-svn-id: trunk at 49045 -

I can't check earlier without difficulty because 3.2.2 doesn't work.  
However the hang (and also an eventual out of memory error) doesn't 
occur if -OoNOPEEPHOLE is specified, meaning the problem is located in 
the peephole optimizer.  So it looks like I'll have to try to debug this 
the hard way!

Kit

On 23/04/2024 17:27, J. Gareth Moreton via fpc-devel wrote:
> I've reproduced the hang doing "make clean all CPU_TARGET=i386 
> OS_TARGET=win32 OPT="-Cp80486 -Op80486"" on my x86_64-win64 machine.
>
> So far I haven't found the bad commit - this problem has been here a 
> while.
>
> Kit
>
> I still haven't found the bad commit!
>
> On 23/04/2024 12:46, J. Gareth Moreton via fpc-devel wrote:
>> Absolutely I can.  I'll see what I can find.
>>
>> Gareth aka. Kit
>>
>> On 23/04/2024 12:09, Tomas Hajny via fpc-devel wrote:
>>> On 2024-04-23 11:50, Marģers . via fpc-devel wrote:
>>>> 1) does not work
>>>> make clean singlezipinstall OS_TARGET=win32 CPU_TARGET=i386
>>>> ALLOW_WARNINGS=1 OPT="  -O2 -vxitl -Cp80486 -Op80486"
>>>>
>>>> hangs on
>>>> system.inc(421,2) Start reading includefile
>>>> C:\Users\Lietotajs\Downloads\fora\a\486\gh\rtl\inc\generic.inc
>>>  .
>>>  .
>>>
>>> Indeed. This is clearly an issue related to optimizations. The 
>>> important point missing here is that it happens when compiling with 
>>> ppc1.exe. I just tried building a trunk compiler (make rtl_all 
>>> compiler_all) with "OPT=-O- -Cp80486 -Op80486" and then started 
>>> another compilation round with compiler built this way, but using 
>>> -O2 this time, in order to make sure that it wasn't an optimization 
>>> bug in the released 3.2.2 compiler. The new compilation round (using 
>>> a non-optimized compiler) hangs at an exactly the same place, i.e. 
>>> it's a bug (probably endless loop?) in the optimization code 
>>> specific to the trunk compiler. @Gareth, could you please have a 
>>> look at it?
>>>
>>> Tomas
>>> _______________________________________________
>>> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
>>> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
>>>
>> _______________________________________________
>> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
>> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
>>
> _______________________________________________
> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
>