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

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

Open
tzmfreedom opened this issue Dec 1, 2018 · 9 comments
Open

Comments

@tzmfreedom
Copy link

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)

@ziflex
Copy link

ziflex commented Dec 24, 2018

Same here

@r3code
Copy link

r3code commented Aug 27, 2019

@ziflex Is there any fixes? Have the same issue here expr-lang/expr#64

@antonmedv
Copy link

Any news on this issue?

@hoshsadiq
Copy link

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

@antonmedv
Copy link

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

ncarlier added a commit to ncarlier/feedpushr that referenced this issue Jan 3, 2020
Pending resolution of these issues:

- expr-lang/expr#64
- antlr/antlr4#2433
@allain
Copy link

allain commented Feb 3, 2020

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.

@cubewise-tryan
Copy link

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.

@exander77
Copy link

Can this be fixed in master?

@vladaionescu
Copy link

Thanks @cubewise-tryan! Works like a charm!

Here's the sed version of the workaround:

sed -i.bak 's/(1<</(int64(1)<</g' ./file.go
diff ./file.go.bak ./file.go

shenxn pushed a commit to shenxn/protonmail-bridge-docker that referenced this issue Jan 1, 2022
* Workaround to compile for 32bit

This is a workaround based on [this
comment](antlr/antlr4#2433 (comment)).
It is not a pretty solution but it worked well on my test file.

It runs once to compile, if make fails, then it apply the fix and try
again, this is done so builds that don't need workaround don't use it
and also because the workaround is done on top of downloaded files
during ethe first compilation.

* Update README to remove ARMv7 error comment
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

9 participants