Antlr4: Go runtime: Can not compile on 386 by constant overflows int error

Created on 1 Dec 2018  路  8Comments  路  Source: antlr/antlr4

Following error is occured when building to GOARCH=386 on Golang runtime.

$ GOOS=windows GOARCH=386 CGO_ENABLED=0 \
  go build -a -tags netgo -installsuffix netgo -ldflags="-s -w" -o dist/foo

parser/apex_parser.go:2769:220: constant 2954920112 overflows int
parser/apex_parser.go:2769: constant 4059596561 overflows int
parser/apex_parser.go:3256: constant 4029318396 overflows int
parser/apex_parser.go:3256: constant 2149454871 overflows int

Source file is here.
Because int value is overflowed, it may fix if changing from int type to int64 type.
(It looks like _la variable is overflowed)

Most helpful comment

This was also an issue for me, fix for me was to explicitly set the type to int64 int64(1)<< instead of 1<<. Code to update after running Antlr is:

pth := `..\yourfilepath.go`
data, err := ioutil.ReadFile(pth)
if err != nil {
    logger.Fatalf("Unable to read parser.go: %s", err)
}

str := string(data)
// Need to replace 1 with int64(1) to stop int overflows on 32 bit systems
fixed := strings.Replace(str, "(1<<", "(int64(1)<<", -1)

err = ioutil.WriteFile(pth, []byte(fixed), 0666)
if err != nil {
    logger.Fatalf("Unable to save parser.go: %s", err)
}

Hopefully that helps someone, it would be better of course to get it fixed in the source.

All 8 comments

Same here

@ziflex Is there any fixes? Have the same issue here https://github.com/antonmedv/expr/issues/64

Any news on this issue?

Worth noting that due to this it's impossible to build for armhf as well.

@pboyer any news? I'm don't want to rewrite parser because of this error :(

In the event that is helps the next person who reads this: I wrote a quick node script that changed the check from a bitwise check to a more naive one and just have it call it after building the parser code:

const fs = require('fs')
const parserPath = ".../path/parser_parser.go"
const parserCode = fs.readFileSync(parserPath, 'utf-8')

const patchedCode = parserCode.replace(/(\(\(1<<uint\(_la\)\)&\([^{]+)/g, match => {
    const parts = match.match(/<<([A-Z][^)]+)/g)
    return '(' + parts.map(p => `_la == ${p.substr(2)}`).join(' || ') + ')'
})

fs.writeFileSync(parserPath, patchedCode)

Seems this fixes the issue in my case. Hope it helps you out too.

This was also an issue for me, fix for me was to explicitly set the type to int64 int64(1)<< instead of 1<<. Code to update after running Antlr is:

pth := `..\yourfilepath.go`
data, err := ioutil.ReadFile(pth)
if err != nil {
    logger.Fatalf("Unable to read parser.go: %s", err)
}

str := string(data)
// Need to replace 1 with int64(1) to stop int overflows on 32 bit systems
fixed := strings.Replace(str, "(1<<", "(int64(1)<<", -1)

err = ioutil.WriteFile(pth, []byte(fixed), 0666)
if err != nil {
    logger.Fatalf("Unable to save parser.go: %s", err)
}

Hopefully that helps someone, it would be better of course to get it fixed in the source.

Can this be fixed in master?

Was this page helpful?
0 / 5 - 0 ratings