gollvm: unable to build etcd #33020
Labels
NeedsInvestigation
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
Comments
|
Change https://golang.org/cl/185977 mentions this issue: |
|
CL 185977 resolves the problem listed above, bit it looks like there is another problem hiding behind that one (I am investigating). Failure mode:
|
|
Change https://golang.org/cl/186697 mentions this issue: |
gopherbot
pushed a commit
to golang/gofrontend
that referenced
this issue
Jul 18, 2019
In CL 183850 a change was made to combine tracking/discovery of exported types and imported packages during export data generation. As a result of this refactoring a bug was introduced: the new code can potentially insert items into the exports set (an unordered_set) while iterating through the same set, which is illegal according to the spec for std::unordered_set. This patch fixes the problem by changing the type discovery phase to iterate through a separate list of sorted exports, as opposed to iterating through the main unordered set. Also included is a change to fix the code that looks for variables that are referenced from inlined routine bodies (this code wasn't scanning all of the function that it needed to scan). New test case for this problem in CL 186697. Updates golang/go#33020. Change-Id: Id9ae5af462bc0819e8c9a8dd038ce9746297ad5d Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/185977 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Red-Portal
pushed a commit
to Red-Portal/gcc
that referenced
this issue
Jul 18, 2019
In CL 183850 a change was made to combine tracking/discovery of
exported types and imported packages during export data generation. As
a result of this refactoring a bug was introduced: the new code can
potentially insert items into the exports set (an unordered_set) while
iterating through the same set, which is illegal according to the spec
for std::unordered_set.
This patch fixes the problem by changing the type discovery phase to
iterate through a separate list of sorted exports, as opposed to
iterating through the main unordered set. Also included is a change
to fix the code that looks for variables that are referenced from
inlined routine bodies (this code wasn't scanning all of the function
that it needed to scan).
New test case for this problem in CL 186697.
Updates golang/go#33020.
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/185977
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@273564 138bc75d-0d04-0410-961f-82ee72b054a4
gopherbot
pushed a commit
that referenced
this issue
Jul 18, 2019
Updates #33020 Change-Id: I82554ef20ea35e0087fd9ecd9548c2dfeacdc617 Reviewed-on: https://go-review.googlesource.com/c/go/+/186697 Run-TryBot: Than McIntosh <thanm@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com> Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
Enclose a reduced case which could reproduce the issue of Llvm_backend::materializeComposite. Given a struct type: The named base of FArg is set to "func(args []string)error" which happens to be the type of field 'Arg2', converting the backend representation of the type of Arg1 has a side-effect which sets the btype of Arg2's type, such side-effect result in the post-processing of 'Arg2' being bypassed and remaining 'Command' in 'unresolved placeholder' status, so its opaque llvm type fails to be concretized. So far the issue could be reproduced via 'importing' type definitions only as the exporter seems to do type definitions sharing, perhaps there are other scenarios undiscovered Tried a fix locally which adds place-holder pointer types created for function type to a list (similar to Type::placeholder_pointers, or they can share the same list) then lets finish_pointer_types takes care the concretizing, it could fix the crash of building etcd (a few errors of undefined symbol observed), wonder there might be a better solution from the perspective of type sharing. |
|
Seems that neither .go nor .txt is supported, enclosing the code here. |
|
Thanks @shawn-xdji for the analysis and the reduced test case. I agree with your analysis, the problem is that the FE is manufacturing a placeholder but then never finalizing it. There was a similar problem a while back fixed in https://go-review.googlesource.com/c/gofrontend/+/51131, I think the fix for this bug is to generalize/extend that change. I will send a CL. |
|
Change https://golang.org/cl/191743 mentions this issue: |
|
Change https://golang.org/cl/191744 mentions this issue: |
gopherbot
pushed a commit
to golang/gofrontend
that referenced
this issue
Aug 26, 2019
This change extends the work in https://golang.org/cl/51131 to include placeholder pointer types created for Go function types, which can also be left dangling/unresolved in some instances. This fixes an assert in Llvm_backend::materializeComposite. Test case can be found in https://golang.org/cl/191743. Updates golang/go#33020. Change-Id: I66094131916a2a7175f32654a7376d7db568f741 Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/191744 Reviewed-by: Ian Lance Taylor <iant@golang.org>
kraj
pushed a commit
to kraj/gcc
that referenced
this issue
Aug 26, 2019
This change extends the work in https://golang.org/cl/51131 to include
placeholder pointer types created for Go function types, which can
also be left dangling/unresolved in some instances. This fixes an
assert in Llvm_backend::materializeComposite.
Test case can be found in https://golang.org/cl/191743.
Updates golang/go#33020.
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/191744
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@274935 138bc75d-0d04-0410-961f-82ee72b054a4
gopherbot
pushed a commit
that referenced
this issue
Aug 29, 2019
Testcase for a gollvm bug (assert in Llvm_backend::materializeComposite). Updates #33020. Change-Id: Icdf5b4b2b6eb55a5b48a31a61c41215b1ae4cf01 Reviewed-on: https://go-review.googlesource.com/c/go/+/191743 Reviewed-by: Ian Lance Taylor <iant@golang.org>
tomocy
pushed a commit
to tomocy/go
that referenced
this issue
Sep 1, 2019
Testcase for a gollvm bug (assert in Llvm_backend::materializeComposite). Updates golang#33020. Change-Id: Icdf5b4b2b6eb55a5b48a31a61c41215b1ae4cf01 Reviewed-on: https://go-review.googlesource.com/c/go/+/191743 Reviewed-by: Ian Lance Taylor <iant@golang.org>
t4n6a1ka
pushed a commit
to t4n6a1ka/go
that referenced
this issue
Sep 5, 2019
Testcase for a gollvm bug (assert in Llvm_backend::materializeComposite). Updates golang#33020. Change-Id: Icdf5b4b2b6eb55a5b48a31a61c41215b1ae4cf01 Reviewed-on: https://go-review.googlesource.com/c/go/+/191743 Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
Hi. Ivan |
asiekierka
pushed a commit
to WonderfulToolchain/gcc-ia16
that referenced
this issue
May 16, 2022
In CL 183850 a change was made to combine tracking/discovery of
exported types and imported packages during export data generation. As
a result of this refactoring a bug was introduced: the new code can
potentially insert items into the exports set (an unordered_set) while
iterating through the same set, which is illegal according to the spec
for std::unordered_set.
This patch fixes the problem by changing the type discovery phase to
iterate through a separate list of sorted exports, as opposed to
iterating through the main unordered set. Also included is a change
to fix the code that looks for variables that are referenced from
inlined routine bodies (this code wasn't scanning all of the function
that it needed to scan).
New test case for this problem in CL 186697.
Updates golang/go#33020.
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/185977
From-SVN: r273564
cagedmantis
added
the
NeedsInvestigation
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What version of Go are you using (
go version)?Does this issue reproduce with the latest release?
yes
What operating system and processor architecture are you using (
go env)?linux/amd64
What did you do?
As reported by yuanting@ict.ac.cn
What did you expect to see?
Successful compilation
What did you see instead?
Needs investigation. There have been several changes and bugs in import/export lately; this looks like a new one.
The text was updated successfully, but these errors were encountered: