Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/5c: miscompiles *p++ = struct_literal #4643

Closed
remyoudompheng opened this issue Jan 10, 2013 · 5 comments
Closed

cmd/5c: miscompiles *p++ = struct_literal #4643

remyoudompheng opened this issue Jan 10, 2013 · 5 comments
Milestone

Comments

@remyoudompheng
Copy link
Contributor

1. What is a short input program that triggers the error?

typedef struct {
  int a, b, c, d, e;
} S;

S* main(S* p) {
  *p++ = (S){1, 2, 3, 4, 5};
  return p;
}

2. What is the full compiler output?

--- prog list main ---
(truc.c:6) TEXT     main+0(SB),R0,$0-4
(truc.c:6) MOVW     p+0(FP),R1
(truc.c:7) ADD      $20,R1,R3
(truc.c:7) MOVW     $1,R2
(truc.c:7) MOVW     R2,0(R1)
(truc.c:7) MOVW     R3,R1
(truc.c:7) ADD      $20,R3,R3
(truc.c:7) MOVW     $2,R2
(truc.c:7) MOVW     R2,4(R1)
(truc.c:7) MOVW     R3,R1
(truc.c:7) ADD      $20,R3,R3
(truc.c:7) MOVW     $3,R2
(truc.c:7) MOVW     R2,8(R1)
(truc.c:7) MOVW     R3,R1
(truc.c:7) ADD      $20,R3,R3
(truc.c:7) MOVW     $4,R2
(truc.c:7) MOVW     R2,12(R1)
(truc.c:7) ADD      $20,R3,R0
(truc.c:7) MOVW     $5,R2
(truc.c:7) MOVW     R2,16(R3)
(truc.c:8) RET      ,
(truc.c:8) RET      ,


3. What version of the compiler are you using?  (Run it with the -V flag.)

go version devel +84a2c61092a9 Wed Jan 02 14:40:27 2013 -0800 linux/amd64
@bradfitz
Copy link
Contributor

Comment 1:

When fixed, could revert workaround here:
https://code.google.com/p/go/source/detail?r=a5b96b602690

@gopherbot
Copy link

Comment 2:

Compiler errors are hard to identify. I am curious about how you found out that the
compiler was generating incorrect code.

@remyoudompheng
Copy link
Contributor Author

Comment 3:

The debugging was done like this:
 * add prints to the GC code
 * observe it prints:
append obj(0x2e9608 24792 0x1eb934)
scanblock 0x2e9608 24792
append obj(0x2ef6e0 36328 0x1f282c)
scanblock 0x2ef6e0 36328
generic@0xb6e72000 0x10833000 0x0
generic@0xb6e72010 0x10801000 0x0
generic@0xb6e72020 0x1083a000 0x0
generic@0xb6e72030 0x1083a120 0x0
generic@0xb6e72040 0x1083a120 0x0
[...]
flushptrbuf@0xb6e72000 0x10833000 0x0
flushptrbuf@0xb6e72008 0x0 0x0
(printing address PtrBuf* and the two fields)
 * observe that it's weird that the pointer advances by 16 on the enqueue side and by 8 on the flushptrbuf side
 * observe that sizeof(Ptrbuf) is actually 8
 * think WTF aloud
 * add prints before and after *ptrbufpos++
 * disassemble
[the actual sequence is more complicated and involves using gdb and adding breakpoints,
finding no clue, restarting gdb, still have no clue, disassemble, print regs, have no
clue, resort to printf-debugging]

@remyoudompheng
Copy link
Contributor Author

Comment 4:

https://golang.org/cl/7090043/

Labels changed: added priority-soon, removed priority-triage.

Status changed to Started.

@remyoudompheng
Copy link
Contributor Author

Comment 5:

This issue was closed by revision c13866d.

Status changed to Fixed.

@rsc rsc added this to the Go1.1 milestone Apr 14, 2015
@rsc rsc removed the go1.1 label Apr 14, 2015
@golang golang locked and limited conversation to collaborators Jun 24, 2016
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants