[Bug libgcc/86213] New: -fsplit-stack runtime may clobber SSE input param reg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86213 Bug ID: 86213 Summary: -fsplit-stack runtime may clobber SSE input param reg Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: thanm at google dot com Target Milestone: --- Created attachment 44295 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44295&action=edit tar file with reproducer sources and makefile The runtime code in libgcc that supports the -fsplit-stack flag can in some cases clobber an SSE register that is being used for parameter passing. The scenario is as follows: - routine A calls routine B, passing a floating point argument (which does in xmm0) - the routine B (compiled with -fsplit-stack) invokes "__morestack", which in turn may wind up calling out to other system routines (mmap for example) - routine B then does something with its floating point argument (xmm0) The code as written in __morestack does not save incoming SSE registers, so if something gets calls that uses SSE, it can lose param values. At the moment the only way to trigger this problem is to insure that the very first call made to __morestack is from a routine with a live floating point input argument (since the SSE clobbering takes place during a call to "getenv", which typically only is invoked on the first pass through the code). So this qualifies as a pretty obscure bug. Reproducer case attached (written for linux/x86). Example of failing run: $ make clean ; make run rm -f *.o *.so main gcc -c -O -fPIC -o main.o main.c gcc -c -fsplit-stack -O -fPIC -o m1.o m1.c gcc -c -O -fPIC -o m2.o m2.c gcc -O -fuse-ld=gold -fPIC -shared m1.o m2.o -o m1.so gcc -O -fuse-ld=gold main.o -o main m1.so LD_LIBRARY_PATH=`pwd` ./main in main noframe(64.00) = 0.00 Last value should be 64.0, not 0.0. Example of passing run (here with -m32): $ make clean ; make run EXTRA=-m32 rm -f *.o *.so main gcc -c -O -m32 -fPIC -o main.o main.c gcc -c -fsplit-stack -O -m32 -fPIC -o m1.o m1.c gcc -c -O -m32 -fPIC -o m2.o m2.c gcc -O -m32 -fuse-ld=gold -fPIC -shared m1.o m2.o -o m1.so gcc -O -m32 -fuse-ld=gold main.o -o main m1.so LD_LIBRARY_PATH=`pwd` ./main in main noframe(64.00) = 64.00
[Bug tree-optimization/90316] New: large compile time increase in opt / alias stmt walking for Go example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90316 Bug ID: 90316 Summary: large compile time increase in opt / alias stmt walking for Go example Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: thanm at google dot com Target Milestone: --- Created attachment 46276 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46276&action=edit Go testcase The attached Go file when built with gccgo tip takes a very long time to compile; I think the test case may be exposing some sort of non-linear behavior in tree-pre. Original problem was discovered with an application internal to Google (in auto-generated code); the testcase I am submitting is hand-generated but has the same control flow characteristics. The function of interest has no loops, but there is if-then-else control flow, and there are about 9000 bbs. Compiling with GCC 7 takes about 11 seconds; compiling with tip takes about 7 minutes (original Google testcase is larger and takes about 45 minutes to compile). Compile with: gccgo -c -O2 -g generated.go -o /tmp/gen.o Profile from "pprof": (pprof) top15 Showing nodes accounting for 381.91s, 96.34% of 396.42s total Dropped 1064 nodes (cum <= 1.98s) Showing top 15 nodes out of 50 flat flat% sum%cum cum% 84.13s 21.22% 21.22%202.04s 50.97% et_splay 75.82s 19.13% 40.35% 80.73s 20.36% dominated_by_p 52.73s 13.30% 53.65% 52.73s 13.30% et_recomp_min (inline) 42.98s 10.84% 64.49%384.60s 97.02% get_continuation_for_phi 41.95s 10.58% 75.07% 41.95s 10.58% set_depth_add (inline) 29.52s 7.45% 82.52% 29.52s 7.45% tree_check (inline) 19.98s 5.04% 87.56%223.37s 56.35% et_below 10.32s 2.60% 90.16% 10.32s 2.60% set_depth (inline) 7.54s 1.90% 92.07% 7.54s 1.90% set_prev (inline) 6.73s 1.70% 93.76% 6.73s 1.70% set_next (inline) 4.93s 1.24% 95.01% 4.93s 1.24% dom_convert_dir_to_idx (inline) 3.06s 0.77% 95.78% 3.06s 0.77% bitmap_list_find_element (inline) 1.65s 0.42% 96.20% 3.20s 0.81% gimple_vuse (inline) 0.41s 0.1% 96.30% 4.32s 1.09% insert_updated_phi_nodes_for 0.16s 0.04% 96.34%384.15s 96.90% maybe_skip_until (inline) Top offenders include "maybe_skip_until" and "get_continuation_for_phi". Time report: Time variable usr sys wall GGC phase parsing : 0.15 ( 0%) 0.01 ( 3%) 0.15 ( 0%) 7482 kB ( 12%) phase opt and generate : 191.73 (100%) 0.37 ( 97%) 192.11 (100%) 52645 kB ( 87%) phase last asm : 0.01 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 116 kB ( 0%) garbage collection : 0.08 ( 0%) 0.00 ( 0%) 0.08 ( 0%) 0 kB ( 0%) callgraph construction : 0.01 ( 0%) 0.01 ( 3%) 0.01 ( 0%) 6204 kB ( 10%) callgraph optimization : 0.00 ( 0%) 0.00 ( 0%) 0.03 ( 0%) 0 kB ( 0%) ipa function summary : 0.01 ( 0%) 0.00 ( 0%) 0.00 ( 0%) 1 kB ( 0%) ipa dead code removal : 0.01 ( 0%) 0.01 ( 3%) 0.02 ( 0%) 0 kB ( 0%) ipa profile: 0.00 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 0 kB ( 0%) cfg construction : 0.00 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 412 kB ( 1%) cfg cleanup: 0.01 ( 0%) 0.01 ( 3%) 0.02 ( 0%) 56 kB ( 0%) CFG verifier : 0.22 ( 0%) 0.01 ( 3%) 0.26 ( 0%) 0 kB ( 0%) trivially dead code: 0.02 ( 0%) 0.00 ( 0%) 0.03 ( 0%) 0 kB ( 0%) df scan insns : 0.02 ( 0%) 0.01 ( 3%) 0.02 ( 0%) 0 kB ( 0%) df multiple defs : 0.25 ( 0%) 0.00 ( 0%) 0.25 ( 0%) 0 kB ( 0%) df reaching defs : 0.09 ( 0%) 0.01 ( 3%) 0.08 ( 0%) 0 kB ( 0%) df live regs : 0.12 ( 0%) 0.00 ( 0%) 0.13 ( 0%) 0 kB ( 0%) df live&initialized regs : 0.06 ( 0%) 0.00 ( 0%) 0.07 ( 0%) 0 kB ( 0%) df must-initialized regs : 0.03 ( 0%) 0.01 ( 3%) 0.03 ( 0%) 0 kB ( 0%) df use-def / def-use chains: 0.19 ( 0%) 0.04 ( 11%) 0.25 ( 0%) 0 kB ( 0%) df reg dead/unused notes : 0.07 ( 0%) 0.00 ( 0%) 0.09 ( 0%) 530 kB ( 1%) register information : 0.01 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 0 kB ( 0%) alias analysis : 0.01 ( 0%) 0.00 ( 0%) 0.02 ( 0%) 1408 kB ( 2%) alias stmt walking : 184.44 (
[Bug tree-optimization/90316] [8/9/10 Regression] large compile time increase in opt / alias stmt walking for Go example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90316 --- Comment #7 from Than McIntosh --- I patched in your change and reran the original testacse. Verified that this fixes the problem, compile time now down to ~8 seconds. Thank you for the very quick turnaround-- much appreciated.
[Bug tree-optimization/90316] [8/9 Regression] large compile time increase in opt / alias stmt walking for Go example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90316 --- Comment #10 from Than McIntosh --- Update: it looks like we are not out of the woods quite yet -- I am seeing some similar behavior farther into the build. I will try to produce another reduced test case (this one is proving more difficult replicate).
[Bug tree-optimization/90316] [8/9 Regression] large compile time increase in opt / alias stmt walking for Go example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90316 --- Comment #12 from Than McIntosh --- Created attachment 46304 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46304&action=edit modified test case (file 2 of 2)
[Bug tree-optimization/90316] [8/9 Regression] large compile time increase in opt / alias stmt walking for Go example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90316 --- Comment #11 from Than McIntosh --- Created attachment 46303 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46303&action=edit modified test case (file 1 of 2)
[Bug tree-optimization/90316] [8/9 Regression] large compile time increase in opt / alias stmt walking for Go example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90316 --- Comment #13 from Than McIntosh --- I've made a stab at revising the test case to try to trigger the long compile time that I'm still seeing the real application code. Still not quite there yet (revised testcase takes maybe a minute to compile, original 45 mins) -- I don't understand quite why. To compile the revised testcase: gccgo -g -c -O2 auxiliary.go gccgo -g -c -O2 -I . generated2.go Having more than one package seems to be part of the equation (changes aliasing in some way? hard to tell). Profile still seems to be pointing to the same routines as before: (pprof) top15 Showing nodes accounting for 41.67s, 83.29% of 50.03s total Dropped 986 nodes (cum <= 0.25s) Showing top 15 nodes out of 88 flat flat% sum%cum cum% 15.12s 30.22% 30.22% 17.43s 34.84% dominated_by_p 7.96s 15.91% 46.13% 33.78s 67.52% get_continuation_for_phi 4.05s 8.10% 54.23% 4.05s 8.10% canon_value_cmp (inline) 3.70s 7.40% 61.62% 8.35s 16.69% canonicalize_values_star 2.31s 4.62% 66.24% 2.31s 4.62% dom_convert_dir_to_idx (inline) 2.29s 4.58% 70.82% 2.29s 4.58% tree_check (inline) 1.34s 2.68% 73.50% 4.25s 8.49% set_slot_part 1.11s 2.22% 75.71% 1.15s 2.30% gimple_vuse (inline) 1.05s 2.10% 77.81% 1.05s 2.10% loc_cmp 0.64s 1.28% 79.09% 0.64s 1.28% bitmap_list_find_element (inline) 0.52s 1.04% 80.13% 0.88s 1.76% hash_table::find_slot_with_hash
[Bug tree-optimization/90316] [8/9 Regression] large compile time increase in opt / alias stmt walking for Go example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90316 --- Comment #18 from Than McIntosh --- I tested the most recent commit (270944). That cuts the compile time on the larger example in half, but still at around 1200 seconds. I took another profile (will attach an SVG image from 'pprof web').
[Bug tree-optimization/90316] [8/9 Regression] large compile time increase in opt / alias stmt walking for Go example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90316 --- Comment #19 from Than McIntosh --- Created attachment 46313 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46313&action=edit SVG graph from profiling run
[Bug tree-optimization/90316] [8/9 Regression] large compile time increase in opt / alias stmt walking for Go example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90316 --- Comment #22 from Than McIntosh --- Apologies for the delayed response (busy with other bugs yesterday). Testcase: hard to share the original... it has hundreds if not thousands of imported packages (it's an auto-generated Go file), and I'd have to figure out some way to sanitize all the identifiers, since there is a lot of Google-proprietary stuff there. I'm attaching the output of -fdump-statistics-stats. The insert iterations lines are: 135 pre "insert iterations == 1084" 1 135 pre "insert iterations == 1" 9 135 pre "insert iterations == 2" 1
[Bug tree-optimization/90316] [8/9 Regression] large compile time increase in opt / alias stmt walking for Go example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90316 --- Comment #23 from Than McIntosh --- Created attachment 46326 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46326&action=edit dump from -fdump-statistics-stats
[Bug tree-optimization/90316] [8/9 Regression] large compile time increase in opt / alias stmt walking for Go example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90316 --- Comment #24 from Than McIntosh --- Did another run with the patch from comment 21. For the offending routine I get: phi-translate cache statistics: size 2097143, 1171808 elements, 0.465610 collisions
[Bug tree-optimization/90316] [8/9 Regression] large compile time increase in opt / alias stmt walking for Go example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90316 --- Comment #29 from Than McIntosh --- Tested patch at https://gcc.gnu.org/bugzilla/attachment.cgi?id=46337 and that brings compile time now down to about 700 seconds. -ftime-report shows that tree-PRE is still the major culprit. Also tested second patch at https://gcc.gnu.org/bugzilla/attachment.cgi?id=46339 and that looks even better, reduces compile time to 137 seconds, which is well under the timeout enforced by our build system. Thanks--
[Bug tree-optimization/90316] [8/9 Regression] large compile time increase in opt / alias stmt walking for Go example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90316 --- Comment #32 from Than McIntosh --- Compile time for the larger example looks good for the most recent commit on trunk (271124), ~130 seconds. Thanks for all your help on this.
[Bug tree-optimization/90316] [8/9 Regression] large compile time increase in opt / alias stmt walking for Go example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90316 --- Comment #34 from Than McIntosh --- GCC 8 and 9 branches -- I'll do that experiment later this morning. It's worth noting that if the code in questing uses more modern Go constructs (things introduced in Go 1.11/1.12) it may not compile properly, but I will at least give it a shot.
[Bug tree-optimization/90316] [8/9 Regression] large compile time increase in opt / alias stmt walking for Go example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90316 --- Comment #35 from Than McIntosh --- I applied r271124 to the gcc-9 branch and re-ran the large testcase -- still has the long compile time (2127 seconds), FWIW.
[Bug tree-optimization/90316] [8/9 Regression] large compile time increase in opt / alias stmt walking for Go example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90316 --- Comment #37 from Than McIntosh --- (In reply to rguent...@suse.de from comment #36) > Thanks for the experiment. I guess I will limit backporting things > to the GCC 9 branch then. Am I correct that the 2127 seconds are > the same regardless of whether r271124 is applied to the branch or not? The patch makes things slightly better -- without it the time is 2540 seconds.
[Bug go/80226] New: ICE gimple-expr.c:474 on Go function returning multiple empty struct/array values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80226
Bug ID: 80226
Summary: ICE gimple-expr.c:474 on Go function returning
multiple empty struct/array values
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: go
Assignee: ian at airs dot com
Reporter: thanm at google dot com
CC: cmang at google dot com
Target Milestone: ---
Compiling the attached test case with gccgo results in an ICE. Example:
$ go build -compiler gccgo repro.go
# command-line-arguments
In function ‘repro.Test36’:
go1: internal compiler error: in create_tmp_var, at gimple-expr.c:474
0xc2ace4 create_tmp_var(tree_node*, char const*)
../../gcc-trunk/gcc/gimple-expr.c:474
0x8f5f37 Gcc_backend::return_statement(Bfunction*, std::vector > const&, Location)
../../gcc-trunk/gcc/go/go-gcc.cc:2135
0x96f3b9 Return_statement::do_get_backend(Translate_context*)
../../gcc-trunk/gcc/go/gofrontend/statements.cc:2838
0x968480 Statement::get_backend(Translate_context*)
../../gcc-trunk/gcc/go/gofrontend/statements.cc:142
0x91b0f2 Block::get_backend(Translate_context*)
../../gcc-trunk/gcc/go/gofrontend/gogo.cc:6026
0x96c772 Block_statement::do_get_backend(Translate_context*)
../../gcc-trunk/gcc/go/gofrontend/statements.cc:1850
0x968480 Statement::get_backend(Translate_context*)
../../gcc-trunk/gcc/go/gofrontend/statements.cc:142
0x91b0f2 Block::get_backend(Translate_context*)
../../gcc-trunk/gcc/go/gofrontend/gogo.cc:6026
0x96ff8e If_statement::do_get_backend(Translate_context*)
../../gcc-trunk/gcc/go/gofrontend/statements.cc:3178
0x968480 Statement::get_backend(Translate_context*)
../../gcc-trunk/gcc/go/gofrontend/statements.cc:142
0x91b0f2 Block::get_backend(Translate_context*)
../../gcc-trunk/gcc/go/gofrontend/gogo.cc:6026
0x96c772 Block_statement::do_get_backend(Translate_context*)
../../gcc-trunk/gcc/go/gofrontend/statements.cc:1850
0x968480 Statement::get_backend(Translate_context*)
../../gcc-trunk/gcc/go/gofrontend/statements.cc:142
0x91b0f2 Block::get_backend(Translate_context*)
../../gcc-trunk/gcc/go/gofrontend/gogo.cc:6026
0x9198ef Function::build(Gogo*, Named_object*)
../../gcc-trunk/gcc/go/gofrontend/gogo.cc:5629
0x91ebf0 Named_object::get_backend(Gogo*, std::vector >&, std::vector >&,
std::vector >&)
../../gcc-trunk/gcc/go/gofrontend/gogo.cc:7411
0x90cad1 Gogo::write_globals()
../../gcc-trunk/gcc/go/gofrontend/gogo.cc:1322
0x90679e go_write_globals()
../../gcc-trunk/gcc/go/gofrontend/go.cc:174
0x8fd2e1 go_langhook_parse_file
../../gcc-trunk/gcc/go/go-lang.c:318
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
This is with trunk gccgo:
$ gccgo --version
gccgo (GCC) 7.0.1 20170322 (experimental)
$
Excerpt from the function:
func Test36(p0 uint64, p1 StructF36S0, p2 uint8, p3 int32, p4 StructF36S1) (r0
StructF36S2, r1 ArrayF36S0E0, r2 ArrayF36S1E0) {
rc0 := StructF36S2{}
rc1 := ArrayF36S0E0{}
rc2 := ArrayF36S1E0{}
if p0 == 0 {
return rc0, rc1, rc2
}
where r0/r1/r2 are all zero-sized arrays or empty structures.
I spent a little while poking around -- from what I can tell there is code
already in Gcc_backend::return_statement designed to catch this case (returning
empty-sized stuff), however it doesn't appear to be working correctly. Line is
if (int_size_in_bytes(TREE_TYPE(result)) == 0)
however this call is returning -1 in this case (since TREE_TYPE(result) is the
void type).
I will work on a fix.
[Bug go/80226] ICE gimple-expr.c:474 on Go function returning multiple empty struct/array values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80226
--- Comment #1 from Than McIntosh ---
This seems to do the trick:
diff --git a/gcc/go/go-gcc.cc b/gcc/go/go-gcc.cc
index ed6fc2c6105..62baa91fab8 100644
--- a/gcc/go/go-gcc.cc
+++ b/gcc/go/go-gcc.cc
@@ -2081,7 +2081,8 @@ Gcc_backend::return_statement(Bfunction* bfunction,
// If the result size is zero bytes, we have set the function type
// to have a result type of void, so don't return anything.
// See the function_type method.
- if (int_size_in_bytes(TREE_TYPE(result)) == 0)
+ tree res_type = TREE_TYPE(result);
+ if (res_type == void_type_node || int_size_in_bytes(res_type) == 0)
{
tree stmt_list = NULL_TREE;
for (std::vector::const_iterator p = vals.begin();
[Bug middle-end/67718] New: [aarch64] long double incorrect code for copysign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67718
Bug ID: 67718
Summary: [aarch64] long double incorrect code for copysign
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: thanm at google dot com
Target Milestone: ---
Created attachment 36392
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36392&action=edit
reduced test case (C++)
Compiling the attached example with g++ at -O2 or -O1 results in incorrect code
(-O0 looks ok). This is with gcc trunk aarch64-linux-android target; problem is
also present in 4.9. Source being compiled looks like:
/// begin
union IEEEl2bits {
long double e;
struct {
unsigned long manl :64;
unsigned long manh :48;
unsigned int exp :15;
unsigned int sign :1;
} bits;
};
long double
copysignl(long double x, long double y)
{
union IEEEl2bits ux, uy;
ux.e = x;
uy.e = y;
ux.bits.sign = uy.bits.sign;
return (ux.e);
}
/// end
Here is -O2 assembly:
ushrd1, d1, 63
fmovx0, d0
fmovx1, v0.d[1]
fmovd0, x0
fmovx2, d1
bfi x1, x2, 63, 1
fmovv0.d[1], x1
ret
Note that the first instruction is sourcing d1 (incorrect) -- this needs to
read q0 in order for correct semantics.
I am not a gcc expert, but I'm guessing that the problem is happening in the
reload phase. Prior to reload the RTL looks ok:
(insn 10 9 7 2 (set (reg:DI 81 [ D.3189 ])
(lshiftrt:DI (subreg:DI (reg:TI 33 v1 [ y ]) 8)
(const_int 63 [0x3f])))
bionic/libm/upstream-freebsd/lib/msun/src/s_copysignl.c:40 512
{*aarch64_lshr_sisd_or_int_di3}
(expr_list:REG_DEAD (reg:TI 33 v1 [ y ])
(nil)))
and then after reload this gets turned into
(insn 10 9 7 2 (set (reg:DI 33 v1 [orig:81 D.3189 ] [81])
(lshiftrt:DI (reg:DI 33 v1 [ y+8 ])
(const_int 63 [0x3f])))
bionic/libm/upstream-freebsd/lib/msun/src/s_copysignl.c:40 512
{*aarch64_lshr_sisd_or_int_di3}
(nil))
which doesn't look right -- we seem to have lost the "TI", which I take to be
the bug.
[Bug target/67718] [aarch64] long double incorrect code for copysign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67718 --- Comment #2 from Than McIntosh --- >>using __builtin_copysignl should generate better code generation anyways. Tried replacing the guts of the function with a call to __builtin_copysignl -- the bug is still present. Any recommendations on someone in the extended GCC community who could help me triage/analyze the bug? I have worked with register allocators before, but not with gcc's; I could use some guidance.
[Bug target/67718] [aarch64] long double incorrect code for copysign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67718 Than McIntosh changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #4 from Than McIntosh --- Thanks for the response. You are right: the code generated by 4.9 and trunk gcc is correct -- after going back and rebuilding and retesting I am seeing the same code you posted. I'm not sure what I did wrong the first time; sorry for the spam / noise / false alarm. I will mark the bug as INVALID... The specific copy of gcc I'm working with (which as you pointed out I should have included in the original report) is the Android platform/NDK copy of gcc 4.9, which is a variant based on the svn://gcc.gnu.org/svn/gcc/branches/google/gcc-4_9 branch with the addition of some changes back-ported from trunk. I can reproduce the same problem by building directly from the gcc google/gcc-4_9 branch (no Android changes), so it looks as though that is where things went off the tracks.
[Bug go/71396] "use of undefined type" error in gccgo-6 when go (1.6.1) is perfectly happy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71396 Than McIntosh changed: What|Removed |Added CC||thanm at google dot com --- Comment #1 from Than McIntosh --- Hello, I was unable to access the attachment (just got a single line of text). Could you please repost? Thanks, Than
[Bug debug/101064] New: long compile time in var_tracking for Go package
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101064 Bug ID: 101064 Summary: long compile time in var_tracking for Go package Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: thanm at google dot com Target Milestone: --- Created attachment 51008 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51008&action=edit testcase to reproduce (Go files, some profile reports) Building the attached Go package with gccgo results in a very long compile time, apparently due to var_tracking. To reproduce, unpack the tar file and build with either: A) go clean -cache; go build . or B) gccgo -c -O2 -g -m64 -fgo-pkgpath=xyz ./aenum.go ./avx_optabs.go [Note: this issue is first posted on the main Go issue tracker at https://github.com/golang/go/issues/46600; more details there]. This is a fairly modest sized Go package; building it with the main (non-gcc) Go compiler takes about a third of a second (user + sys, reported by /bin/time). For gccgo, building with -O0 takes about a second, but the time taken at -O1 and -O2 are much longer: -O1: 450 seconds -O2: 257 seconds Along with the test case, I am attaching some profiles collected using 'pprof'. The pass consuming the extra compile time appears to be variable_tracking; from the profiles the problem looks to be related to alias analysis / memory disambiguation.
