View Issue Details

IDProjectCategoryView StatusLast Update
0036587FPCCompilerpublic2020-02-13 21:33
ReporterBenito van der Zander Assigned ToYuriy Sydorov  
PrioritynormalSeverityminorReproducibilityhave not tried
Status resolvedResolutionfixed 
Product Version3.3.1 
Fixed in Version3.3.1 
Summary0036587: INVALID in arm instructions on build server
DescriptionAfter updating from the October trunk to today's trunk, my project does not compiler anymore for Android arm on the build server:

> xquery__functions.s: Assembler messages:
> xquery__functions.s:4898: Error: shift expression expected -- `sbc r0,r2,INVALID'
> xquery__functions.s:4966: Error: immediate expression requires a # prefix -- `adc r0,INVALID,r2'
Additional InformationThese are the lines it happens. MicroSecsPerSec and ai are int64, all other int types are integer:

# [211] if (adatevalue^.timezone = high(Integer)) and (cxt.staticContext.ImplicitTimezoneInMinutes <> high(Integer)) then ai -= cxt.staticContext.ImplicitTimezoneInMinutes * 60 * MicroSecsPerSec;
    ldr r0,[r11, #-68]
    ldr r0,[r0, 0000028]
    mvn r1,#-2147483648
    cmp r0,r1
    bne .Lj224
    ldr r0,[r11, #-48]
    ldr r0,[r0, 0000036]
    ldr r0,[r0, 0000008]
    cmp r0,#0
    beq .Lj227
    ldr r0,[r11, #-48]
    ldr r0,[r0, 0000036]
    ldr r0,[r0, 0000008]
    ldr r0,[r0, 0000016]
    b .Lj228
.Lj227:
    mvn r0,#-2147483648
.Lj228:
    mvn r1,#-2147483648
    cmp r0,r1
    beq .Lj224
    ldr r0,[r11, #-48]
    ldr r0,[r0, 0000036]
    ldr r0,[r0, 0000008]
    cmp r0,#0
    beq .Lj230
    ldr r0,[r11, #-48]
    ldr r0,[r0, 0000036]
    ldr r0,[r0, 0000008]
    ldr r1,[r0, 0000016]
    b .Lj231
.Lj230:
    mvn r1,#-2147483648
.Lj231:
    ldr r0,.Lj232
    mul r3,r1,r0
    ldr r0,[r11, #-80]
    ldr r2,[r11, #-76]
    subs r1,r0,r3
    sbc r0,r2,INVALID
    str r1,[r11, #-80]
    str r0,[r11, #-76]

....

# [214] if (bdatevalue^.timezone = high(Integer)) and (cxt.staticContext.ImplicitTimezoneInMinutes <> high(Integer)) then ai += cxt.staticContext.ImplicitTimezoneInMinutes * 60 * MicroSecsPerSec;
    ldr r0,[r11, #-72]
    ldr r1,[r0, 0000028]
    mvn r0,#-2147483648
    cmp r1,r0
    bne .Lj234
    ldr r0,[r11, #-48]
    ldr r0,[r0, 0000036]
    ldr r0,[r0, 0000008]
    cmp r0,#0
    beq .Lj237
    ldr r0,[r11, #-48]
    ldr r0,[r0, 0000036]
    ldr r0,[r0, 0000008]
    ldr r0,[r0, 0000016]
    b .Lj238
.Lj237:
    mvn r0,#-2147483648
.Lj238:
    mvn r1,#-2147483648
    cmp r0,r1
    beq .Lj234
    ldr r0,[r11, #-48]
    ldr r0,[r0, 0000036]
    ldr r0,[r0, 0000008]
    cmp r0,#0
    beq .Lj240
    ldr r0,[r11, #-48]
    ldr r0,[r0, 0000036]
    ldr r0,[r0, 0000008]
    ldr r1,[r0, 0000016]
    b .Lj241
.Lj240:
    mvn r1,#-2147483648
.Lj241:
    ldr r0,.Lj232
    mul r3,r1,r0
    ldr r0,[r11, #-80]
    ldr r2,[r11, #-76]
    adds r1,r3,r0
    adc r0,INVALID,r2
    str r1,[r11, #-80]
    str r0,[r11, #-76]



I do not have fpc trunk on my computer to make a smaller example, but here is the entire log of the build server: https://api.travis-ci.org/v3/job/637580697/log.txt
TagsNo tags attached.
Fixed in Revision44151
FPCOldBugId
FPCTarget-
Attached Files

Activities

Yuriy Sydorov

2020-01-19 21:52

manager   ~0120562

I can't reproduce the issue.
Please provide a test source code and needed compiler options.

Benito van der Zander

2020-02-07 17:32

reporter   ~0120921

Here:

program test;
{$mode objfpc}
const MicroSecsPerSec = int64(1000000);
procedure xqvalueSubtractDates(ImplicitTimezoneInMinutes: integer);
var
  ai: Int64;
begin
    ai := 0;
    ai -= ImplicitTimezoneInMinutes * 60 * MicroSecsPerSec;
end;

begin
    xqvalueSubtractDates(0);
end.

Thaddy de Koning

2020-02-08 10:45

reporter   ~0120938

I can reproduce the internal error on linux-armhf as well. (trunk r44120)
Note the compiler warns to expand to int64
Also note that if the parameter is changed from integer to int64 it works

Yuriy Sydorov

2020-02-11 13:50

manager   ~0121013

Should be fixed in r44151. Please test and close the issue.

Jonas Maebe

2020-02-11 19:34

manager   ~0121017

That is not a proper fix. Please add a typeconversion node instead.

Yuriy Sydorov

2020-02-11 23:03

manager   ~0121021

Last edited: 2020-02-11 23:03

View 2 revisions

Jonas, my initial intention has been to add a typeconversion node, but it would not solve the issue properly.

Let's have the expression:
i64:=i64 + i32*1234*int64(10000);

Here the outer multiplication node has the int64 result after pass1. Then the simplification converts two multiplication nodes to one multiplication node (i32*12340000) with the longint result. Thus the result of the multiplication is truncated when i32 is big enough. Adding a type conversion to int64 would not help since the result of multiplication would be placed to an longint location before typecasting.
The test I've committed checks this.

Jonas Maebe

2020-02-12 20:21

manager   ~0121055

Then you may have to insert a typeconversion node in the left and/or right node. It still needs done that way because (even though it generally does not happen) running typecheckpass twice should result in the same result both times. In this case, that won't happen, because the second time you won't know there were these extra nodes since the simplification won't happen a second time. Additionally, not all code generators support a 32x32->64 multiplication with a hacked resultdef like that (I think PowerPC doesn't, and LLVM probably doesn't either).

Yuriy Sydorov

2020-02-13 19:58

manager   ~0121087

When I insert a typeconversion to int64 for the left or right node, The result indeed becomes int64 as needed, but the multiplication is performed using the "fpc_mul_longint_to_int64" helper instead of single mul instruction on arm and i386. Thus this is not the optimal solution.

"Hacking" of the resultdef in my fix is performed only when the simplification is called after pass1 and the 32x32->64 multiplication has been already chosen during pass1. For CPUs that does not support this type of multiplication this code path should be never executed.

So what is the proper and optimal way to fix this?

Florian

2020-02-13 21:33

administrator   ~0121089

The constant folding might not be done. I have a fix for it.

Issue History

Date Modified Username Field Change
2020-01-15 21:19 Benito van der Zander New Issue
2020-01-19 21:52 Yuriy Sydorov Assigned To => Yuriy Sydorov
2020-01-19 21:52 Yuriy Sydorov Status new => feedback
2020-01-19 21:52 Yuriy Sydorov FPCTarget => -
2020-01-19 21:52 Yuriy Sydorov Note Added: 0120562
2020-02-07 17:32 Benito van der Zander Note Added: 0120921
2020-02-07 17:32 Benito van der Zander Status feedback => assigned
2020-02-08 10:45 Thaddy de Koning Note Added: 0120938
2020-02-11 13:50 Yuriy Sydorov Status assigned => resolved
2020-02-11 13:50 Yuriy Sydorov Resolution open => fixed
2020-02-11 13:50 Yuriy Sydorov Fixed in Version => 3.3.1
2020-02-11 13:50 Yuriy Sydorov Fixed in Revision => 44151
2020-02-11 13:50 Yuriy Sydorov Note Added: 0121013
2020-02-11 19:34 Jonas Maebe Note Added: 0121017
2020-02-11 23:03 Yuriy Sydorov Note Added: 0121021
2020-02-11 23:03 Yuriy Sydorov Note Edited: 0121021 View Revisions
2020-02-12 20:21 Jonas Maebe Note Added: 0121055
2020-02-13 19:58 Yuriy Sydorov Note Added: 0121087
2020-02-13 21:33 Florian Note Added: 0121089