http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60363
--- Comment #6 from bin.cheng ---
After investigation, I think the root cause is:
For given mergephi2 dump (before vrp), there are latch(bb13) and header(bb14)
of a loop:
:
# changed_18 = PHI
:
# changed_1 = PHI
# kill_elt_4 = PHI
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60363
--- Comment #7 from bin.cheng ---
The problem has nothing to do with VRP, and might be a missed opportunity of
jump threading.
The dump after VRP but before jump threading at the end of VRP is like:
...
:
goto ;
...
:
# kill_elt_3 = P
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58424
--- Comment #2 from bin.cheng ---
Yes, It works for below combination of options:
-mthumb -mcpu=cortex-m4
-mthumb/-marm -march=armv7-a/-mcpu=cortex-a7
But still happens for:
-mthumb -mcpu=cortex-m3
-mthumb/-marm
-mcpu=cortex-a7/-mcpu=corte
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67921
bin.cheng changed:
What|Removed |Added
CC||amker.cheng at gmail dot com
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67921
--- Comment #6 from bin.cheng ---
The fact is GCC calls function:
chrec_fold_minus (type, chrec1, chrec2)
// type == sizetype
// chrec1 == 4 - (sizetype) &c
// chrec2 == (sizetype) ((int *) p1_8(D) + ((sizetype) a_23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67921
--- Comment #7 from bin.cheng ---
Hmm, this issue could be simply because chrec_fold_multiply doesn't use
sizetype as CHREC_RIGHT's type to build pointer type CHREC:
return build_polynomial_chrec
(CHREC_VARIABLE (op0),
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68529
--- Comment #5 from bin.cheng ---
The dump before ldist is as below:
foo1 ()
{
unsigned int nchar;
char c[1];
:
c = {};
:
# nchar_14 = PHI
c[nchar_14] = 65;
nchar_5 = nchar_14 + 4294967295;
if (nchar_14 != 0)
goto ;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62173
bin.cheng changed:
What|Removed |Added
CC||amker.cheng at gmail dot com
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58623
bin.cheng changed:
What|Removed |Added
CC||amker.cheng at gmail dot com
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62178
--- Comment #5 from bin.cheng ---
Now I think the patch proposed isn't good enough. I am revisiting the
implementation to see if I can improve the existing algorithm, rather than just
adding another heuristic pass.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62151
bin.cheng changed:
What|Removed |Added
CC||amker.cheng at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62151
--- Comment #13 from bin.cheng ---
The check itself is suspicious too. Why do we want to check elim_i2/elim_i1
when distributing REG_DEAD note from i1?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62151
--- Comment #15 from bin.cheng ---
Hmm, words on tem_insn issue at the end of comment #12 isn't mature. It's more
complicated than that.
Turns out live range of register which is noted as DEAD in i1/i2 can be
extended because we propagate its u
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: amker.cheng at gmail dot com
Created attachment 33256
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33256&action=edit
tarball of dump fi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62032
--- Comment #1 from bin.cheng ---
Only fail with lto options.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62032
--- Comment #3 from bin.cheng ---
I did some investigation and think it's a latent bug of lto which reveaded by
r213585.
Before the revision, pass_fold_builtins::execute calls gimple_fold_builtins
directly to fold __builtin___vsnprintf_chk (_26,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61659
bin.cheng changed:
What|Removed |Added
CC||amker.cheng at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62025
bin.cheng changed:
What|Removed |Added
CC||amker.cheng at gmail dot com
--- Comment
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: amker.cheng at gmail dot com
Hi,
Revision 213779 causes lots cases under libstdc++-v3/testsuite/ext/ failed on
aarch64-none-elf and arm-none-eabi.
The log message is like
In file
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: amker.cheng at gmail dot com
Hi,
The test case is like below.
/* { dg-do compile { target arm*-*-* } } */
/* { dg-options "-mfp16-format=ieee" } */
/* Test mangling */
/* { dg-fi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62178
bin.cheng changed:
What|Removed |Added
CC||amker.cheng at gmail dot com
--- Comment #3
onent: driver
Assignee: unassigned at gcc dot gnu.org
Reporter: amker.cheng at gmail dot com
At least with revision@214413, gcc configured with below options on x86_64.
$ ../gcc/configure --prefix=../target/
--enable-languages=c,c++,ada,fortran,java,objc,obj-c++,go
O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62631
--- Comment #4 from bin.cheng ---
Hi Rainer,
This is caused by abnormal huge cost of function call `shiftadd_cost (true,
DImode, 2)'. It returns 100+ cost, resulting in huge cost when representing
use 1 with cand 4:
use 1
compare
in stateme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49444
bin.cheng changed:
What|Removed |Added
CC||amker.cheng at gmail dot com
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63411
--- Comment #2 from bin.cheng ---
(In reply to Oleg Endo from comment #0)
> Compiling the following as C or C++:
>
> typedef struct
> {
> unsigned char sprindex;
> unsigned char y;
> unsigned char index;
> unsigned char attr;
> unsigne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68576
bin.cheng changed:
What|Removed |Added
CC||amker.cheng at gmail dot com
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68576
--- Comment #5 from bin.cheng ---
The type conversion comses from lim, below code:
/* In case this is a stmt that is not unconditionally executed
when the target loop header is executed and the stmt may
invoke undefined in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68576
--- Comment #6 from bin.cheng ---
Hmm, at least for this case, lim should be aware that lim candidate doesn't
invoke undefined overflow when it is not executed after entering target loop.
Thus we don't need to rewrite it in unsigned arithmetic.
101 - 128 of 128 matches
Mail list logo
