View Issue Details

IDProjectCategoryView StatusLast Update
0036287FPCCompilerpublic2019-12-10 20:17
ReporterJ. Gareth MoretonAssigned ToFlorian 
PriorityhighSeverityblockReproducibilitysometimes
Status resolvedResolutionfixed 
Platformx86_64-win64OSMicrosoft WindowsOS Version10 Professional
Product Version3.3.1Product Buildr43434 
Target VersionFixed in Version 
Summary0036287: Internal Error 200109092 when manually compiling Lazarus
DescriptionAfter updating FPC to the latest trunk, Manually compiling Lazarus using FPC under Win64 via the command prompt raises Internal Error 200109092, which indicates an invalid loc parameter in "tcg.a_load_loc_reg" in "unit /compiler/cgobj.pas". i.e:

lazsyntextarea.pp(1106,27) Fatal: Internal error 200109092
Fatal: Compilation aborted
Steps To ReproduceBuild the x86_64-win64 build of FPC ("svn info" identifies the current revision as 43434) using "make clean all install", then from your Lazarus source directory (tested with a fresh pull of its own trunk), run the following command from the Windows command prompt (Replace "C:\pp" with wherever FPC has been installed after it is built):

C:\pp\bin\x86_64-win64\ppcx64 -Mobjfpc -FE -g- -Xs -FuC:\pp\units\x86_64-win64\fcl-db\src\sqldb -FuC:\pp\units\x86_64-win64\libtar\src -FuC:\pp\units\x86_64-win64\fpmkunit\src -Fupackager -FuC:\pp\units\x86_64-win64\fppkg\src -FlC:\pp\units\x86_64-win64\rtl -FuC:\pp\units\x86_64-win64\rtl -FiC:\pp\units\x86_64-win64\rtl\inc -FiC:\pp\units\x86_64-win64\rtl\win -FiC:\pp\units\x86_64-win64\rtl\win64 -FiC:\pp\units\x86_64-win64\rtl\x86_64 -FiC:\pp\units\x86_64-win64\rtl\win\wininc -FuC:\pp\units\x86_64-win64\rtl\win -FiC:\pp\units\x86_64-win64\rtl\objpas\sysutils -Fiide\include -FuC:\pp\units\x86_64-win64\rtl\inc -FuC:\pp\units\x86_64-win64\rtl\objpas -Fulcl\interfaces\win32 -Fucomponents\lazutils -FiC:\pp\units\x86_64-win64\rtl\objpas\classes -FuC:\pp\units\x86_64-win64\rtl-objpas\src\inc -FuC:\pp\units\x86_64-win64\fcl-base\src -Fulcl -FuC:\pp\units\x86_64-win64\fcl-image\src -Filcl\include -FuC:\pp\units\x86_64-win64\winunits-base\src -FuC:\pp\units\x86_64-win64\rtl-objpas\src\win -FiC:\pp\units\x86_64-win64\rtl-objpas\src\inc -FuC:\pp\units\x86_64-win64\paszlib\src -FuC:\pp\units\x86_64-win64\hash\src -FuC:\pp\units\x86_64-win64\pasjpeg\src -Fulcl\widgetset -Fucomponents\lazutils -FuC:\pp\units\x86_64-win64\fcl-process\src -FiC:\pp\units\x86_64-win64\fcl-process\src\win -FuC:\pp\units\x86_64-win64\chm\src -FuC:\pp\units\x86_64-win64\fcl-json\src -Fulcl\forms -Fucomponents\codetools -Fiide\include\win64 -Fucomponents\ideintf -Fucomponents\lazcontrols -Fucomponents\debuggerintf -Fudebugger -Fucomponents\synedit -FuC:\pp\units\x86_64-win64\fcl-registry\src -FuC:\pp\units\x86_64-win64\regexpr\src -Fupackager\registration -FuC:\pp\units\x86_64-win64\fcl-db\src\base -Fucomponents\ideintf -FuC:\pp\units\x86_64-win64\fcl-res\src -Fupackager -Fudesigner -Fuide\frames -FuC:\pp\units\x86_64-win64\fcl-xml\src -FuC:\pp\units\x86_64-win64\fcl-extra\src\win -FuC:\pp\units\x86_64-win64\winunits-jedi\src -FuC:\pp\units\x86_64-win64\fcl-db\src\dbase -FiC:\pp\units\x86_64-win64\fcl-process\src\winall -FiC:\pp\units\x86_64-win64\fcl-base\src\win -Fucomponents\lazdebuggergdbmi -Fudebugger\frames -Fuconverter -Fupackager\frames -O3 ide\lazarus.pp -B
Additional InformationUsing the "make" command on Lazarus does not raise the error.

I'm willing to accept that I might have gotten something wrong with the directories or the configuration, but an Internal Error is in the same category as assertions and is a bug no matter how incorrect one's configuration is.

Currently it is blocking my work on the jump optimisations (I updated my local FPC copy to the most recent trunk revision in order to test my patches).
Tagscompiler, internal error, lazarus, x86_64-win64
Fixed in Revision
FPCOldBugId
FPCTarget-
Attached Files

Activities

J. Gareth Moreton

2019-11-10 06:08

developer   ~0119182

The line in question in the reported source file is the end of a multi-line statement (line 1106, column 27 points to the minus sign before "TextArea.TopLine"):

  if (FirstTextLine >= 0) then
    rcInval.Top := Max(TextArea.TextBounds.Top,
                       TextArea.TextBounds.Top
                       + (DisplayView.TextToViewIndex(FirstTextLine).Top
                          - TextArea.TopLine + 1) * TextArea.LineHeight);

Anton Kavalenka

2019-11-10 13:44

reporter   ~0119185

Never even tried -O3 - it is dangerous. Always -O2

Florian

2019-11-10 13:55

administrator   ~0119186

@Anton: -O3 does not contain any optimizations which are "dangerous". -O3 is only slower and (as any other part of the compiler) it might be buggy.

J. Gareth Moreton

2019-11-10 14:35

developer   ~0119189

-O4 is the 'dangerous' one, but even then it shouldn't raise an internal error. Also, the side-effects only occur in very particular circumstances.

The main difference with -O3 over -O2 is that the first stage of the peephole optimizer is run repeatedly until nothing is changed, whereas with -O1 and -O2 it's only run twice.

J. Gareth Moreton

2019-11-10 19:22

developer   ~0119198

I just confirmed that it occurs for me under -O2 as well (using the above command), so I'm not sure what 'make' is doing differently that suppresses the error.

J. Gareth Moreton

2019-11-10 20:58

developer   ~0119200

Running it in the debugger, loc is set to "LOC_SUBSETREG", which isn't covered by the case block.

Florian

2019-11-10 21:02

administrator   ~0119201

Please post a stackdump where it comes from.

J. Gareth Moreton

2019-11-10 21:29

developer   ~0119203

Here is the stack dump (I placed the call temporarily inside the Internal Error routine):

  $0000000100032986 INTERNALERROR, line 572 of verbose.pas
  $000000010009BA0A A_LOAD_LOC_REG, line 1667 of cgobj.pas
  $00000001001FB1A4 SECOND_ADDORDINAL, line 1529 of x86/nx86add.pas
  $00000001001F39E5 SECOND_ADDORDINAL, line 63 of x86_64/nx64add.pas
  $00000001001FCB54 SECOND_OPORDINAL, line 653 of ncgadd.pas
  $00000001001FD0D8 PASS_GENERATE_CODE, line 793 of ncgadd.pas
  $000000010015F9F2 SECONDPASS, line 208 of pass_2.pas
  $00000001001FB6E0 PASS_LEFT_RIGHT, line 104 of ncgadd.pas

Adding the following to line 1523 of x86\nx86add.pas fixes the problem:

           if (left.location.loc in [LOC_CSUBSETREG,LOC_SUBSETREG,LOC_SUBSETREF,LOC_CSUBSETREF]) then
             hlcg.location_force_reg(current_asmdata.CurrAsmList,left.location,left.resultdef,left.resultdef,true);

I don't want to blindly do that though in case it causes a subtle break elsewhere and it shouldn't be set to LOC_SUBSETREG in the first place, since I'm fairly sure this internal error didn't start happening until recently.

Florian

2019-11-10 22:46

administrator   ~0119205

Please check if r43449 helps, I solved it slightly different.

J. Gareth Moreton

2019-11-11 00:46

developer   ~0119206

Confirmed that Lazarus now compiles successfully. Thanks Florian. I wonder what started all of that trouble with the internal error.

Issue History

Date Modified Username Field Change
2019-11-10 05:59 J. Gareth Moreton New Issue
2019-11-10 06:00 J. Gareth Moreton Tag Attached: x86_64-win64
2019-11-10 06:00 J. Gareth Moreton Tag Attached: compiler
2019-11-10 06:00 J. Gareth Moreton Tag Attached: lazarus
2019-11-10 06:00 J. Gareth Moreton Tag Attached: internal error
2019-11-10 06:01 J. Gareth Moreton Priority normal => high
2019-11-10 06:01 J. Gareth Moreton Severity minor => block
2019-11-10 06:01 J. Gareth Moreton Steps to Reproduce Updated View Revisions
2019-11-10 06:01 J. Gareth Moreton FPCTarget => -
2019-11-10 06:08 J. Gareth Moreton Note Added: 0119182
2019-11-10 13:44 Anton Kavalenka Note Added: 0119185
2019-11-10 13:55 Florian Note Added: 0119186
2019-11-10 14:35 J. Gareth Moreton Note Added: 0119189
2019-11-10 19:22 J. Gareth Moreton Note Added: 0119198
2019-11-10 20:58 J. Gareth Moreton Note Added: 0119200
2019-11-10 21:02 Florian Note Added: 0119201
2019-11-10 21:29 J. Gareth Moreton Note Added: 0119203
2019-11-10 22:46 Florian Note Added: 0119205
2019-11-11 00:46 J. Gareth Moreton Note Added: 0119206
2019-11-11 00:49 J. Gareth Moreton Status new => resolved
2019-11-11 00:49 J. Gareth Moreton Resolution open => fixed
2019-12-10 20:17 Florian Assigned To => Florian