FAQ
Reviewers: golang-dev_googlegroups.com,

Message:
Hello golang-dev@googlegroups.com (cc: golang-dev@googlegroups.com),

I'd like you to review this change to
https://go.googlecode.com/hg/


Description:
cmd/5g, cmd/6g, cmd/8g: fix out of registers with array indexing.

Compiling expressions like:
s[s[s[s[s[s[s[s[s[s[s[s[i]]]]]]]]]]]]
make 5g and 6g run out of registers. Such expressions can arise
if a slice is used to represent a permutation and the user wants
to iterate it.

This is due to the usual problem of allocating registers before
going down the expression tree, instead of allocating them in a
postfix way.

The functions cgenr and agenr (that generate a value to a newly
allocated register instead of an existing location), are either
introduced or modified when they already existed to allocate
the new register as late as possible, and sudoaddable is disabled
for OINDEX nodes so that igen/agenr is used instead.

The problem does not appear in 8g because it generates
temporaries for almost every intermediate result, but some
of them could be eliminated once the allocation pattern is saner.

Update issue 4207.

Please review this at http://codereview.appspot.com/6733055/

Affected files:
M src/cmd/5g/cgen.c
M src/cmd/5g/gsubr.c
M src/cmd/6g/cgen.c
M src/cmd/6g/gg.h
M src/cmd/6g/gsubr.c
M src/cmd/8g/cgen.c
M src/cmd/8g/gg.h
M src/cmd/gc/fmt.c
M test/torture.go

Search Discussions

  • Dave at Oct 21, 2012 at 10:21 am
    ./all.bash does not pass nilptr.go

    # ../test
    run nilptr.go : incorrect output

    panic: memory reference did not panic

    goroutine 1 [running]:
    main.func·001(0x1c0e8, 0x10d84)
    /home/dfc/go/test/nilptr.go:46 +0x78
    main.shouldPanic(0x10d84, 0x2)
    /home/dfc/go/test/nilptr.go:49 +0x50
    main.main()
    /home/dfc/go/test/nilptr.go:31 +0x7c

    goroutine 2 [syscall]:
    created by runtime.main
    /home/dfc/go/src/pkg/runtime/proc.c:224
    exit status 2

    run recover3.go : incorrect output
    unexpected fault address 0x4e20
    throw: fault
    [signal 0xb code=0x1 addr=0x4e20 pc=0x11550]

    goroutine 1 [running]:
    main.func·006(0xb6f49fb4, 0x10e74)
    /home/dfc/go/test/recover3.go:63 +0x2c
    main.check(0x2cc44, 0xd, 0x10519900, 0x2d1c0, 0x17, ...)
    /home/dfc/go/test/recover3.go:48 +0x60
    main.main()
    /home/dfc/go/test/recover3.go:63 +0x204

    goroutine 2 [syscall]:
    created by runtime.main
    /home/dfc/go/src/pkg/runtime/proc.c:224
    exit status 2

    http://codereview.appspot.com/6733055/
  • Remyoudompheng at Oct 29, 2012 at 7:50 am

    On 2012/10/21 10:15:31, dfc wrote:
    ./all.bash does not pass nilptr.go
    The old code in agen never checked for explicit nils for large arrays. I
    have added the check.

    Rémy.

    http://codereview.appspot.com/6733055/
  • Dave Cheney at Oct 29, 2012 at 7:51 am
    Thank you.
    On Mon, Oct 29, 2012 at 6:50 PM, wrote:
    On 2012/10/21 10:15:31, dfc wrote:

    ./all.bash does not pass nilptr.go

    The old code in agen never checked for explicit nils for large arrays. I
    have added the check.

    Rémy.

    http://codereview.appspot.com/6733055/

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-dev @
categoriesgo
postedOct 20, '12 at 7:24p
activeOct 29, '12 at 7:51a
posts4
users2
websitegolang.org

2 users in discussion

Dave Cheney: 2 posts Remyoudompheng: 2 posts

People

Translate

site design / logo © 2022 Grokbase