https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105297
--- Comment #15 from Jiu Fu Guo ---
(In reply to Patrick Palka from comment #13)
> (In reply to Jiu Fu Guo from comment #11)
> > (In reply to Patrick Palka from comment #10)
> > >
> > > Interestingly that doesn't seem to make a difference.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105297
Jiu Fu Guo changed:
What|Removed |Added
CC||guojiufu at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105315
--- Comment #4 from Jiu Fu Guo ---
(In reply to Ian Lance Taylor from comment #3)
> Thanks, should be fixed now, I hope.
As tested, 'go' build pass on that machine now. Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105315
--- Comment #1 from Jiu Fu Guo ---
The failure compiling command is about -m32:
/home/guojiufu/gcc/build/gcc-mainline-base/./gcc/xgcc
-B/home/guojiufu/gcc/build/gcc-mainline-base/./gcc/
: normal
Priority: P3
Component: go
Assignee: ian at airs dot com
Reporter: guojiufu at gcc dot gnu.org
CC: cmang at google dot com
Target Milestone: ---
On P8 BE machine, I encounter a build failure.
libgo/runtime/go-signal.c:236:59: error: 'union
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85409
Jiu Fu Guo changed:
What|Removed |Added
CC||guojiufu at gcc dot gnu.org
--- Comment #9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105023
Jiu Fu Guo changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105023
Jiu Fu Guo changed:
What|Removed |Added
CC||guojiufu at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100052
--- Comment #10 from Jiu Fu Guo ---
While would we keep this open for a while to see if this issue occurs again.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100052
Jiu Fu Guo changed:
What|Removed |Added
CC||guojiufu at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99910
Jiu Fu Guo changed:
What|Removed |Added
CC||guojiufu at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101853
Jiu Fu Guo changed:
What|Removed |Added
CC||guojiufu at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105091
--- Comment #14 from Jiu Fu Guo ---
(In reply to Richard Biener from comment #13)
...
> Does the following fix the runtime error? The RTL after DSE seems to be OK.
>
> diff --git a/gcc/gimple-expr.cc b/gcc/gimple-expr.cc
> index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105091
--- Comment #12 from Jiu Fu Guo ---
In dse.cc, "may_be_aliased" affects "can_escape" and then affects
"kill_on_calls".
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105091
--- Comment #11 from Jiu Fu Guo ---
Find one difference between trunk and r12-656:
On trunk:
tree expr = MEM_EXPR (mem);
where mem is
(mem/f/c:DI (plus:DI (reg/f:DI 110 sfp)
(const_int 32 [0x20])) [3 GOTMP.2[0].x.__values+0 S8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105091
--- Comment #10 from Jiu Fu Guo ---
Created attachment 52718
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52718=edit
m.go sub1.go
Based on Ian's code, the below code also reproduce this issue.
package sub1
func TestBits(callback
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105091
--- Comment #9 from Jiu Fu Guo ---
(In reply to Ian Lance Taylor from comment #8)
...
>
> package main
>
> func main() {
> for _, test := range []struct {
> x, y, want []int
> }{
> {[]int{}, []int{},
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105091
--- Comment #7 from Jiu Fu Guo ---
tried to remove 'fmt' from the narrowed code, but it is still in code :)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105091
--- Comment #6 from Jiu Fu Guo ---
---bits_test.go
package big
import (
"fmt"
"testing"
)
type Bits []int
func TestMulBits(t *testing.T) {
for _, test := range []struct {
x, y, want Bits
}{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105091
--- Comment #5 from Jiu Fu Guo ---
Created attachment 52709
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52709=edit
280r.dse1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105091
--- Comment #4 from Jiu Fu Guo ---
Created attachment 52708
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52708=edit
279r.cse2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105091
--- Comment #2 from Jiu Fu Guo ---
starting to process insn 14
v: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20,
21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40,
41, 42, 43, 44, 45, 46,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105091
--- Comment #1 from Jiu Fu Guo ---
Checking the dumps from dse1, some "stack memory store" are deleted
incorrectly.
12: %3:DI=call [`runtime.newobject'] argc:0
REG_CALL_DECL `runtime.newobject'
13: r117:DI=%3:DI
REG_DEAD
: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: guojiufu at gcc dot gnu.org
Target Milestone: ---
Code is narrowed from math/big which passes at the early of r12(r12-656).
With -fdisable-rtl-dse1, the case also passes.
_testmain.go
package main
import
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101168
Jiu Fu Guo changed:
What|Removed |Added
CC||guojiufu at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103743
--- Comment #5 from Jiu Fu Guo ---
It would be also ok for the constant that only has 16bits in the middle:
e.g. 0x09876000ULL, we can rotate the constant to 0x9876.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103743
Jiu Fu Guo changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |guojiufu at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103743
Jiu Fu Guo changed:
What|Removed |Added
CC||guojiufu at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104525
--- Comment #1 from Jiu Fu Guo ---
with "-fsigned-char", the case run ok.
When 'char' is treated as 'unsigned': "c != -4" would not be true is any value
of 'c'.
So, this PR would be invalid.
Assignee: unassigned at gcc dot gnu.org
Reporter: guojiufu at gcc dot gnu.org
Target Milestone: ---
When checking the case in PR104521, a timeout occurs on the case at ppc64le.
The timeout also occurs with -O0 -fwrapv (without -fwrapv, the signed overflow
which would be a UB
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104519
Jiu Fu Guo changed:
What|Removed |Added
CC||guojiufu at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68212
--- Comment #10 from Jiu Fu Guo ---
I had a try for GCC11,
https://gcc.gnu.org/pipermail/gcc-patches/2021-July/574421.html.
The patches could mitigate the BB-count mismatch issue for loops. In theory,
this patch would make sense. But it also
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102087
--- Comment #22 from Jiu Fu Guo ---
(In reply to Martin Liška from comment #21)
> > _12 = Gif_ClipImage_gfi_1.0_1 + -1;
> > during GIMPLE pass: aprefetch
> > bug760.c:3:1: internal compiler error: verify_gimple failed
> > 0xde2f5a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63281
--- Comment #22 from Jiu Fu Guo ---
On power10, loading constant only needs 1 instruction, like:
pld 9,.LC0@pcrel
And, as tests, it seems nearly as fast as using 1 instruction to build const.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63281
--- Comment #21 from Jiu Fu Guo ---
Also had a test on powerpc, -m32. As testing, it seems no significant benefit
loading from 'rodata' vs. building constants by instructions.
lis %r7,0x410
ori %r7,%r7,0x103c
lis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63281
--- Comment #20 from Jiu Fu Guo ---
Created attachment 52114
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52114=edit
testcases
With these test cases, invoke 'foo' in these cases 1000,000,000 times, to see
the runtime:
building
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63281
--- Comment #19 from Jiu Fu Guo ---
(In reply to Segher Boessenkool from comment #18)
Thanks for your clarify!
> Yes, it is slow. Five sequential dependent integer instructions instead of
> one load instruction. Depending on how you benchmark
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63281
--- Comment #17 from Jiu Fu Guo ---
One thing, I'm wondering, is if it is really 'slow' using instructions to build
the const (even with 5 insns).
For example, there seems no big difference in runtime between the below two
pieces of code on a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63281
--- Comment #16 from Jiu Fu Guo ---
Thanks, Alan!
I saw your patches in this PR. They would help us to get the sequence of what
we are thinking. And as you said in the comments: it is a big problem for
fixing insn and rtl cost.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63281
--- Comment #14 from Jiu Fu Guo ---
For constant like 0x0008411, which is using 5 insns, at 'expand' pass,
it is treated as preferred to save in memory, while at cse1 pass, it was
replaced back to constant.
expand:
7:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63281
--- Comment #11 from Jiu Fu Guo ---
While for the const which Bill said in comment9, 0x0008411
The code sequence still contains a few instructions:
e.g.
li %r11,0
ori %r11,%r11,0x8000
sldi %r11,%r11,32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63281
Jiu Fu Guo changed:
What|Removed |Added
CC||guojiufu at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102069
Jiu Fu Guo changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102946
Jiu Fu Guo changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102087
Jiu Fu Guo changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102131
--- Comment #8 from Jiu Fu Guo ---
(In reply to Jakub Jelinek from comment #7)
> Any further progress on this?
Thanks, Jabkub!
There is a patch that may cover more cases (PR102636/PR100740.. and other cases
where 'vi0.step - iv1.step > 0'),
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102946
--- Comment #6 from Jiu Fu Guo ---
Hi Rainer and Richard,
Thanks for working on this PR.
The intention of these test cases (pr101145*) is to test if the number
of iterations can be calculated for the loop with the 'until wrap'
condition.
So,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102087
--- Comment #16 from Jiu Fu Guo ---
Thanks David, Richard,
~/gcc/install/gcc-mainline-base-debug/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/home/guojiufu/gcc/install/gcc-mainline-base-debug/bin/gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102364
--- Comment #3 from Jiu Fu Guo ---
We may be able to mark this as a duplicate of PR100740/PR102131.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102364
--- Comment #2 from Jiu Fu Guo ---
This is also the case that two ivs are combined into inaccurate step:
"{3,+,1} < {11,+,2}" was transformed to "{3,+,-1} < {11,+,0}".
The new condition is not same with the original one.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102131
--- Comment #6 from Jiu Fu Guo ---
Drafted a patch as below. With this patch, those cases can pass.
diff --git a/gcc/tree-ssa-loop-niter.c b/gcc/tree-ssa-loop-niter.c
index 7af92d1c893..a400c42919b 100644
--- a/gcc/tree-ssa-loop-niter.c
+++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102131
--- Comment #5 from Jiu Fu Guo ---
(In reply to bin cheng from comment #4)
> (In reply to Jiu Fu Guo from comment #3)
> > The issue may come from 'iv0 cmp iv1' transform:
> >
> >if (c > -->if (c>=b) in-loop
> > -->if (b<=c) in-loop
> >
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102131
--- Comment #3 from Jiu Fu Guo ---
The issue may come from 'iv0 cmp iv1' transform:
if (cif (c>=b) in-loop
-->if (b<=c) in-loop
c: {4, +, 3}
b: {1, +, 1}
if ({1, +, 1} <= {4, +, 3})
==> if ({1,+,-2} <= {4,+,0}) here, error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102131
--- Comment #2 from Jiu Fu Guo ---
Thank you!
For this case, there are two exits, and through these two exits, different
niters(number of iterations) are calculated. It fails to handle this kind of
case well.
In ivcanon pass, the edge on the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102087
--- Comment #10 from Jiu Fu Guo ---
Drafted a patch:
diff --git a/gcc/tree-ssa-loop-niter.c b/gcc/tree-ssa-loop-niter.c
index 7af92d1c893..5c77c8b7d51 100644
--- a/gcc/tree-ssa-loop-niter.c
+++ b/gcc/tree-ssa-loop-niter.c
@@ -1482,7 +1482,7 @@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102087
--- Comment #7 from Jiu Fu Guo ---
If step is +-1, or if the 'iv base' is constant, the 'bound' would be
calculated as const.
Otherwise, the 'bound' maybe something like: "(max - base) / step * step +
base". For this case, then runtime cost
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102087
--- Comment #6 from Jiu Fu Guo ---
Drafting patch to calculate three items: control, bound and cmp.
diff --git a/gcc/tree-ssa-loop-niter.c b/gcc/tree-ssa-loop-niter.c
index 7af92d1c893..c6e4b24fd83 100644
--- a/gcc/tree-ssa-loop-niter.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102072
Jiu Fu Guo changed:
What|Removed |Added
CC||zhendong.su at inf dot ethz.ch
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102087
Jiu Fu Guo changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102072
--- Comment #7 from Jiu Fu Guo ---
For this case: it was generated as:
l_12 = l_25 + 1;
if (l_12 > n_13(D))
Here: cmp is ">", bound is "n_13", and "iv(base=l_xx, step=1)".
This hits the assert in determine_exit_conditions.
For members of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102072
--- Comment #6 from Jiu Fu Guo ---
(In reply to Richard Earnshaw from comment #5)
> (In reply to Jiu Fu Guo from comment #4)
>
> > I did not find arm big-endian yet, I'm trying to reproduce this issue on
> > other targets...
>
> For testing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102072
--- Comment #4 from Jiu Fu Guo ---
Code around tree-ssa-loop-manip.c:1049 (in determine_exit_conditions) is:
else if (cmp == GT_EXPR)
{
gcc_assert (tree_int_cst_sign_bit (step));
}
which seems checking: 'step' should be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102069
--- Comment #1 from Jiu Fu Guo ---
Thanks, Segher!
The test case could be updated. The patch supports calculating the number of
iterations for the special condition(step to min/max), so we may just update to
the case to check if the "number
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61837
Jiu Fu Guo changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101669
Jiu Fu Guo changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101669
--- Comment #5 from Jiu Fu Guo ---
(In reply to Andrew Pinski from comment #4)
> What version of gdb are you using?
Tried gdb8.1/8.3/9.2 on ppc64le.
In gdb, the msg "error reading variable: dwarf2_find_location_expression:"
occurs when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101669
--- Comment #2 from Jiu Fu Guo ---
Similar to what Richard said, tested with gdb, use -gdwarf-4 with trunk, the
msg also disappears.
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: guojiufu at gcc dot gnu.org
Target Milestone: ---
For below case:
--gdb.f90
integer :: a(10), b(12)
call sub (a, 10)
call sub (b, 12)
write (*,*) a, b
end
|--- |FIXED
CC||guojiufu at gcc dot gnu.org
--- Comment #22 from Jiu Fu Guo ---
(In reply to Segher Boessenkool from comment #4)
> It's not fixed. On trunk we get:
>
> ===
> flush_dcache_range:
> rlwinm 3,3,0,0,27
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101291
--- Comment #7 from Jiu Fu Guo ---
When generates doloop.xxx in ivopts, gimple looks like:
[local count: 21023864]:
_38 = val_4(D) - start_3(D);
_29 = _38 / 16;
doloop.15_35 = _29 + 1;
[local count: 191126041]:
# cnt_17 = PHI
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: guojiufu at gcc dot gnu.org
Target Milestone: ---
For the below code, it should run infinite, but it terminates quickly.
#include
__attribute__ ((noinline))
unsigned foo(unsigned val, unsigned start)
{
unsigned cnt = 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101145
--- Comment #8 from Jiu Fu Guo ---
Reference the code of adjust_cond_for_loop_until_wrap, add code for non-const
cases. Code was added in adjust_cond_for_loop_until_wrap at beginning, to set
may_be_zero and no_overflow, the code was moved to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101145
--- Comment #6 from Jiu Fu Guo ---
> As tests, for below loop, adjust_cond_for_loop_until_wrap return false:
>
> foo (int *__restrict__ a, int *__restrict__ b, unsigned i)
> {
> while (++i > 100)
> *a++ = *b++ + 1;
> }
For the above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101145
--- Comment #5 from Jiu Fu Guo ---
(In reply to bin cheng from comment #4)
> (In reply to Jiu Fu Guo from comment #3)
> > Yes, while the code in adjust_cond_for_loop_until_wrap seems somehow tricky:
> >
> > /* Only support simple cases for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101145
--- Comment #3 from Jiu Fu Guo ---
Yes, while the code in adjust_cond_for_loop_until_wrap seems somehow tricky:
/* Only support simple cases for the moment. */
if (TREE_CODE (iv0->base) != INTEGER_CST
|| TREE_CODE (iv1->base) !=
|RESOLVED
CC||guojiufu at gcc dot gnu.org
--- Comment #6 from Jiu Fu Guo ---
Had a test, this issue has been fixed on the trunk by r12-1202.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59371
--- Comment #28 from Jiu Fu Guo ---
If change code as below, 'i' is not starting from '0', and 'compare code' is
'!='
then wrap/overflow on 'i' may happen, and optimizations (e.g. vectorization)
are not applied.
The below patch is trying to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59371
Jiu Fu Guo changed:
What|Removed |Added
CC||guojiufu at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100537
--- Comment #15 from Jiu Fu Guo ---
(In reply to Jiu Fu Guo from comment #9)
> Yes,
>
> diff --git a/gcc/go/go-gcc.cc b/gcc/go/go-gcc.cc
> index 5d9dbb5d068..32637a44af1 100644
> --- a/gcc/go/go-gcc.cc
> +++ b/gcc/go/go-gcc.cc
> @@ -1680,6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100537
--- Comment #14 from Jiu Fu Guo ---
Update/correct info:
If bootstrap-O3, the message is "error: method 'foo' is ambiguous".
It is "error: type has no method 'foo'".
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100537
--- Comment #13 from Jiu Fu Guo ---
(In reply to Ian Lance Taylor from comment #12)
> A change to go-gcc.cc should not change any of the error messages emitted by
> the Go frontend. It should not change the way that issue4458.go is handled.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100537
--- Comment #11 from Jiu Fu Guo ---
Had a quick regression test on the patch:
issue4458.go which pass before, but fail on this patch.
Compiling message changed from "error: method expression requires named type or
pointer to named type" to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100537
--- Comment #9 from Jiu Fu Guo ---
Yes,
diff --git a/gcc/go/go-gcc.cc b/gcc/go/go-gcc.cc
index 5d9dbb5d068..32637a44af1 100644
--- a/gcc/go/go-gcc.cc
+++ b/gcc/go/go-gcc.cc
@@ -1680,6 +1680,7 @@ Gcc_backend::address_expression(Bexpression*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100537
--- Comment #6 from Jiu Fu Guo ---
As Richard mentioned: one does mark the object addressable.
Which is for 'label' (Gcc_backend::label_address).
I'm wondering if all others invoking on build_fold_addr_expr_loc need to mark
addressable?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100537
--- Comment #5 from Jiu Fu Guo ---
breakpoint at tree-ssa.c:1013 error ("address taken, but ADDRESSABLE bit not
set");
if ((VAR_P (base)
|| TREE_CODE (base) == PARM_DECL
|| TREE_CODE (base) ==
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100537
Jiu Fu Guo changed:
What|Removed |Added
CC||guojiufu at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100513
--- Comment #24 from Jiu Fu Guo ---
(In reply to rguent...@suse.de from comment #22)
> On Tue, 11 May 2021, guojiufu at gcc dot gnu.org wrote:
>
cut..
> > Makefile:3001: recipe for target 'syscall.lo' failed
>
> Yes,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100513
--- Comment #23 from Jiu Fu Guo ---
Created attachment 50791
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50791=edit
the command to build syscall.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100513
--- Comment #21 from Jiu Fu Guo ---
When build the go on trunk with the patch, an error occur:
In function 'syscall.forkExec':
go1: error: address taken, but ADDRESSABLE bit not set
PHI argument
for PHI node
err$__object_77 = PHI
during
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100513
--- Comment #20 from Jiu Fu Guo ---
Yes, with the patch, bootstrap-O3 pass on ppc64le too.
Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100513
--- Comment #7 from Jiu Fu Guo ---
A similar issue also reported on X86 before,
https://gcc.gnu.org/pipermail/gcc-testresults/2021-April/677996.html
While when I bootstrap -O3 on one x86, it passes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100513
--- Comment #6 from Jiu Fu Guo ---
cut..
> 0xa5a5a5a5a5a5a5a means the location has been GC'ed already; either from
> ggc_free or from a previous ggc_collect.
> What you can try is run with the following options:
> --param ggc-min-expand=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100513
--- Comment #5 from Jiu Fu Guo ---
build command is:
configure --enable-languages=c,c++,fortran,objc,obj-c++,go --with-cpu=native
--disable-multilib --with-long-double-128 --prefix=$HOME/xx
--with-build-config=bootstrap-O3
make -j
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100513
--- Comment #4 from Jiu Fu Guo ---
Created attachment 50787
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50787=edit
t.ii
/home/guojiufu/gcc/build/gcc-mainline-test/./prev-gcc/xg++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100513
--- Comment #2 from Jiu Fu Guo ---
There is a similar bug fixed for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99447. it may be a different
issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100513
--- Comment #1 from Jiu Fu Guo ---
The error is raised after ipa “inlining” pass, when doing ggc_collect at stage
2.
At code:
xlimit = ((*xlimit).next);
The value of xlimit becomes 0xa5a5a5a5a5a5a5a5 before crash. 0xa5 may comes
from
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: guojiufu at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
With --with-build-config=bootstrap-O3, I encounter an ICE in bootstrap on
ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98813
--- Comment #8 from Jiu Fu Guo ---
For code in comment 4, it is optimized since there are some range info for "_2
= l_m_34 + _54;" where _54 > 0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98813
--- Comment #7 from Jiu Fu Guo ---
(In reply to Richard Biener from comment #6)
> (In reply to Andrew Pinski from comment #5)
> > (In reply to Jiu Fu Guo from comment #0)
> > > For the below code:
> > > ---t.c
> > > void
> > > foo (const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98813
--- Comment #4 from Jiu Fu Guo ---
Thanks, Richard!
One interesting thing: below code is vectorized:
void
foo (const double *__restrict__ A, const double *__restrict__ B,
double *__restrict__ C, int n, int k, int m)
{
if (n > 0 && m > 0
101 - 200 of 266 matches
Mail list logo
