https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88932
bin.cheng changed:
What|Removed |Added
CC||amker.cheng at gmail dot com
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28364
bin.cheng changed:
What|Removed |Added
CC||amker.cheng at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82965
bin.cheng changed:
What|Removed |Added
CC||amker.cheng at gmail dot com
--- Comment
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.
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
bin.cheng changed:
What|Removed |Added
CC||amker.cheng at gmail dot com
--- Comment #4
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=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=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
bin.cheng changed:
What|Removed |Added
CC||amker.cheng at gmail dot com
--- Comment #5
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
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
bin.cheng changed:
What|Removed |Added
CC||amker.cheng at gmail dot com
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=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=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=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=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=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
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=62178
bin.cheng changed:
What|Removed |Added
CC||amker.cheng at gmail dot com
--- Comment #3
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62025
bin.cheng changed:
What|Removed |Added
CC||amker.cheng at gmail dot com
--- Comment
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=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=62032
--- Comment #1 from bin.cheng ---
Only fail with lto options.
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=61411
--- Comment #3 from bin.cheng ---
Then I think it's a latent bug in LRA. It should consult back-end about
legitimized address expressions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61411
bin.cheng changed:
What|Removed |Added
CC||amker.cheng at gmail dot com
: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: amker.cheng at gmail dot com
Created attachment 32877
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32877&action=edit
zipped dump files.
Given a simple progr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60363
--- Comment #15 from bin.cheng ---
Should be fixed now.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60363
--- Comment #10 from bin.cheng ---
Patch sent at http://gcc.gnu.org/ml/gcc-patches/2014-03/msg00857.html , but it
need to wait for stage 1.
I will xfail it for now.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53090
bin.cheng changed:
What|Removed |Added
CC||amker.cheng at gmail dot com
--- Comment #2
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
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=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 #5 from bin.cheng ---
Vrp1 generates below code:
:
if (b_elt_11(D) != 0B)
goto ;
else
goto ;
:
# kill_elt_10 = PHI
goto ;
:
kill_elt_14 = kill_elt_2->next;
:
# kill_elt_2 = PHI
if (kill_elt_2 != 0B)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60363
--- Comment #4 from bin.cheng ---
Although may be irrelavant. I found loop's latch doesn't get updated after
removing the forwarder latch basic block. Previous patch only catches function
remove_forwarder_block, but remove_forwarder_block_with_p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60363
--- Comment #3 from bin.cheng ---
After patching 208165, there are two more jump threading opportunities for dom1
pass. Jump threading is doing alright, the interesting thing is why there is
no such opportunities before patching.
I attatched rel
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60363
bin.cheng changed:
What|Removed |Added
CC||amker.cheng at gmail dot com
--- Comment #2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60280
bin.cheng changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60280
--- Comment #3 from bin.cheng ---
I think 4_8 is ok for this case. At least it doesn't have
http://gcc.gnu.org/ml/gcc-patches/2013-04/msg01530.html committed if I was
right.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60280
--- Comment #1 from bin.cheng ---
It's caused by patch at (revision r198333):
http://gcc.gnu.org/ml/gcc-patches/2013-04/msg01530.html
After patching, forwarder basic block 6 in below dump didn't get removed:
tr4 (short int * array, int n)
{
int
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: amker.cheng at gmail dot com
gcc.target/arm/ivopts-2.c is like:
/* { dg-do assemble } */
/* { dg-options "-Os -fdump-tree-ivopts -save-
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59519
--- Comment #10 from bin.cheng ---
(In reply to Jakub Jelinek from comment #9)
> BTW, the patch can hardly regress anything, it only affects cases that ICEd
> before the patch.
Em, I am worried if vectorization can handle peeled phi correctly for
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59519
--- Comment #7 from bin.cheng ---
(In reply to Jakub Jelinek from comment #6)
> Created attachment 31562 [details]
> gcc49-pr59519.patch
>
> I wonder if this isn't just a checking issue, the two PHI nodes created in
> *new_exit_bb have the same a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59519
--- Comment #5 from bin.cheng ---
For the offending loop:
:
:
# b.4_30 = PHI
# prephitmp_28 = PHI
# b_lsm.11_13 = PHI
# ivtmp_46 = PHI
c.1_9 = prephitmp_28 | 1;
b.4_12 = b.4_30 + 1;
ivtmp_45 = ivtmp_46 - 1;
if (ivtmp_45 !
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59519
--- Comment #4 from bin.cheng ---
First clue.
b_lsm.11_13 is recognized as chrec {1, +, 1}_2 with the patch, thus the loop
can be vectorized now.
:
:
# b.4_30 = PHI
# prephitmp_28 = PHI
# b_lsm.11_13 = PHI
# ivtmp_46 = PHI
c.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59519
bin.cheng changed:
What|Removed |Added
CC||amker.cheng at gmail dot com
--- Comment #3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52306
bin.cheng changed:
What|Removed |Added
CC||amker.cheng at gmail dot com
--- Comment #27
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: amker.cheng at gmail dot com
Created attachment 31478
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31478&action=edit
preprocessed c++ file
For attached preprocessed file, a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59536
--- Comment #13 from bin.cheng ---
(In reply to Andreas Schwab from comment #12)
> -fno-auto-inc-dec avoids the crash. Dup of #52306?
It looks like, AFAICT. Only this time it's blocking bootstrap :(
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59536
bin.cheng changed:
What|Removed |Added
CC||bernds at codesourcery dot com,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59536
--- Comment #10 from bin.cheng ---
The offending loop before IVOPT is like:
:
# var_index_1889 = PHI <1(924), var_index_983(923)>
# var_index.250_1269 = PHI <1(924), var_index.250_1959(923)>
if (var_index.250_1269 < _1237)
goto ;
el
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59536
--- Comment #9 from bin.cheng ---
Turns out my crossed bare-metal tool works after deleting all preprocessed "#
xxx file" lines, but why these lines matter?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59536
--- Comment #8 from bin.cheng ---
(In reply to Andreas Schwab from comment #1)
> Between r205951 and r205984.
(In reply to H.J. Lu from comment #7)
> (In reply to bin.cheng from comment #6)
> > Hi,
> > Sorry I don't have m68k environment to do th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59536
--- Comment #6 from bin.cheng ---
Hi,
Sorry I don't have m68k environment to do the bootstrap, could anyone help dump
"-fdump-tree-all-details -fdump-rtl-all-slim" with and without the patch for
me? Otherwise I have to revert the patch and hold i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59536
bin.cheng changed:
What|Removed |Added
CC||amker.cheng at gmail dot com
--- Comment #5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50955
--- Comment #19 from bin.cheng ---
>
> >not about an iv use appearing in memory reference while not marked as
> >address_p, and can be fixed by revise the existing check condition, is
> >it true?
>
> No, even expressing an address this way is br
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50955
bin.cheng changed:
What|Removed |Added
CC||amker.cheng at gmail dot com
--- Comment #17
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52272
bin.cheng changed:
What|Removed |Added
CC||amker.cheng at gmail dot com
--- Comment #21
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59479
--- Comment #2 from bin.cheng ---
I will investigate it later. Just clarifying, the function is called three
times by the caller, it would increase code size usually.
BTW, could you explain a little about "2nd-order effect"? I am not familiar
w
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39838
--- Comment #16 from bin.cheng ---
For optimization level O2, the dump before IVOPT is like:
:
_21 = p_6(D)->count;
if (_21 > 0)
goto ;
else
goto ;
:
:
# i_26 = PHI
if (count_8(D) > 0)
goto ;
else
goto ;
:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39838
bin.cheng changed:
What|Removed |Added
CC||amker.cheng at gmail dot com
--- Comment #15
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59445
--- Comment #18 from bin.cheng ---
Hi Dominique d'Humieres,
Thanks for verifying it.
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: amker.cheng at gmail dot com
Created attachment 31424
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31424&action=edit
The preprocessed file for newlib/libc/stdio/findfp.c
Hi, for attached prepr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59445
--- Comment #16 from bin.cheng ---
I fixed the reported problem and posted new patch at
http://gcc.gnu.org/ml/gcc-patches/2013-12/msg01159.html
Apology that I missed java in bootstrap for previous patch. This version
passes bootstrap and test for
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59445
--- Comment #15 from bin.cheng ---
Created attachment 31414
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31414&action=edit
The generated assembly with/without patch for code in comment #9 on cortex-m3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59445
--- Comment #14 from bin.cheng ---
I found out the root cause of this ICE and will use the simplified code given
by comment#9 as an example.
The gimple dump before IVOPT is like:
:
:
# c_2 = PHI
__val_comp_iter (D.4949);
p2 = D.4950;
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59445
--- Comment #13 from bin.cheng ---
Sorry for bothering, I have reverted the patch. Will investigate it.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39200
bin.cheng changed:
What|Removed |Added
CC||amker.cheng at gmail dot com
--- Comment #1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50749
bin.cheng changed:
What|Removed |Added
CC||amker.cheng at gmail dot com
--- Comment #15
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55190
bin.cheng changed:
What|Removed |Added
CC||amker.cheng at gmail dot com
--- Comment #3
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: amker.cheng at gmail dot com
gcc is at revision r202599 and is configured as:
../gcc/configure
build=i686-linux-gnu
host=i686-linux-gnu
target=arm-none-eabi
prefix=.../trunk-orig/target/
disable-decimal-float
disable-libffi
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: amker.cheng at gmail dot com
GCC ICEed with shrink-wrap-sibcall.c on a15 with below command line:
./arm-none-eabi-gcc -O2 -marm -mcpu=cortex-a15 -mfpu=neon -mfloat-abi=hard
shrink-wrap-sibcall.c -S -o shrink-wrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57540
bin.cheng changed:
What|Removed |Added
Component|middle-end |target
--- Comment #4 from bin.cheng ---
Sor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56102
bin.cheng changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57540
--- Comment #3 from bin.cheng ---
I think this should be handled in expand. During expanding, GCC tries "base +
scaled_offset + offset" pattern, which is invalid for targets like arm. At this
point we still have a chance to refactor "base + offse
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57540
bin.cheng changed:
What|Removed |Added
Component|rtl-optimization|target
--- Comment #2 from bin.cheng ---
Thi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57540
--- Comment #1 from bin.cheng ---
The dump of loop_init is like,
72: r178:SI=0
106: L106:
90: NOTE_INSN_BASIC_BLOCK 6
91: r178:SI=r178:SI+0x1
94: r190:SI=r177:SI<<0x2
REG_DEAD r177:SI
95: r191:SI=sfp:SI+r190:SI
REG_DEA
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: amker.cheng at gmail dot com
For below program,
void foo ( unsigned char *len,
int alphaSize,
int maxLen )
{
int i, j, k;
unsigned char tooLong
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56124
bin.cheng changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56139
Bug #: 56139
Summary: unmodified static data could go in .rodata, not .data
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: enh
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56124
--- Comment #1 from bin.cheng 2013-01-28
02:43:10 UTC ---
The root cause is in ira:scan_one_insn function.
It decrease cost of memory for pseudo which are target of loading from memory:
if (set != 0 && REG_P (SET_DEST (set)) && MEM_P
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56124
Bug #: 56124
Summary: Redundant reload for loading from memory
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56102
--- Comment #2 from bin.cheng 2013-01-25
07:25:34 UTC ---
Created attachment 29270
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29270
correct test case
The previous test case is not appropriate, because gcc won't split even with
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56102
--- Comment #1 from bin.cheng 2013-01-25
03:46:59 UTC ---
I have investigated this issue.
GCC uses function init_lower_subreg to initialize costs of MOVE insn with
different mode, then uses this information to decompose multi-word pseudo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56102
Bug #: 56102
Summary: Wrong rtx cost calculated for Thumb1
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Pr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56058
Bug #: 56058
Summary: GCC arm-none-eabi build failure
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: major
Priority
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55906
Bug #: 55906
Summary: suboptimal code generated for post-inc on Thumb1
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54910
bin.cheng changed:
What|Removed |Added
CC||amker.cheng at gmail dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49498
--- Comment #19 from bin.cheng 2012-11-21
13:24:02 UTC ---
(In reply to comment #18)
> *** Bug 55424 has been marked as a duplicate of this bug. ***
Just for the record.
If the analysis I gave in Comment #17 is right, this PR reveals an
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55424
Bug #: 55424
Summary: [4.8 Regression]gcc.dg/uninit-pred-8_b.c bogus warning
line 23 on ARM/Cortex-M0/-Os
Classification: Unclassified
Product: gcc
Version: 4.8.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49498
bin.cheng changed:
What|Removed |Added
CC||amker.cheng at gmail dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54989
--- Comment #7 from bin.cheng 2012-10-31
08:45:37 UTC ---
I think this is fixed and it's a bug in 4.8.0.
Hi Jack, could you verify that it is fixed? Thanks very much.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55031
Bug #: 55031
Summary: Documentation on RTL GCSE pass is outdated
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priori
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54989
bin.cheng changed:
What|Removed |Added
CC||amker.cheng at gmail dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54133
--- Comment #8 from amker.cheng 2012-09-25
07:45:02 UTC ---
I have spent some time investigating this bug and now I think I understand the
issue.
The problematic instruction patterns which save/restore argument/return
registers is gener
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54414
--- Comment #1 from amker.cheng 2012-08-30
10:17:15 UTC ---
I suspect that the call of arm_size_return_regs in function
thumb1_extra_regs_pushed should also be covered as in
http://gcc.gnu.org/ml/gcc-patches/2010-08/msg00830.html
1 - 100 of 128 matches
Mail list logo
