http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47855
Summary: missed cbnz optimization
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47855
--- Comment #1 from Carrot 2011-02-25 07:18:07 UTC
---
I printed out the address of each instruction from function arm_reorg()
id=173 addr=0
id=2 addr=4
id=3 addr=8
id=15 addr=12
id=18 addr=16
id=199 addr=24
id=21 addr=26
id=23 addr=30
id=26 add
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47920
Summary: strange code generated for expression (a+7)/8
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: una
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47920
--- Comment #3 from Carrot 2011-03-01 06:44:47 UTC
---
(In reply to comment #1)
> Presumably because arithmetic right-shift by 3 isn't the same as a division by
> 8 when (a+7) is negative. Changing the types to unsigned gives the code you
> want
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50150
Bug #: 50150
Summary: misc vect.exp failures for target arm
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50150
--- Comment #2 from Carrot 2011-08-23 01:14:46 UTC
---
(In reply to comment #1)
> So how was this toolchain configured by default ?
>
> Ramana
My configuration is:
configured by /usr/local/google/home/carrot/trunk4/configure, generated by GN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50194
Bug #: 50194
Summary: wrong tail call optimization for mixed arm/thumb mode
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50194
--- Comment #3 from Carrot 2011-08-30 01:16:34 UTC
---
Yes, it's a problem of the linker in my testing environment. I've tried to
manually link it with a different linker, it can run successfully. And the
correct stub is generated
2472 a9c8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49452
Carrot changed:
What|Removed |Added
CC||carrot at google dot com
--- Comment #19 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49452
--- Comment #20 from Carrot 2011-09-14 03:02:03 UTC
---
> Instruction 2 and 24 refer to the same location, but have different offset
> relative to FP because the call to y changes FP. DSE doesn't (and can not, if
> it is intra-procedural) know th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49452
--- Comment #23 from Carrot 2011-09-16 06:57:15 UTC
---
(In reply to comment #21)
> > All callee saved registers should never changed after function call. Here fp
> > has been changed is not because it is after a function call, it is because
> >
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50150
--- Comment #4 from Carrot 2011-09-26 02:16:15 UTC
---
After adding '--with-fpu=neon' '--with-float=softfp' to my configuration, most
of the failure disappeared, but there are still several
gcc
FAIL: gcc.dg/vect/vect-120.c scan-tree-dump-times v
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53241
Bug #: 53241
Summary: Bad pre increment insn for ARM vfp store instructions
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53447
Bug #: 53447
Summary: missed optimization of 64bit ALU operation with small
constant
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53447
--- Comment #2 from Carrot 2012-05-23 06:54:55 UTC
---
A question about related pattern
626 (define_insn_and_split "*arm_adddi3"
627 [(set (match_operand:DI 0 "s_register_operand" "=&r,&r")
628 (plus:DI (match_operand:DI
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53447
Carrot changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52129
Bug #: 52129
Summary: wrong code to pass parameters to tail call function
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: major
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52256
Bug #: 52256
Summary: CSE the memory load from both branches of if statement
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52338
Bug #: 52338
Summary: shorter abs thumb2 code sequences
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52396
Bug #: 52396
Summary: Gcc failed to hoist loop invariant expression out of
loop
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52412
Bug #: 52412
Summary: another unnecessary register move on arm
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56993
--- Comment #1 from Carrot ---
I did some more experimentation on this benchmark.
O0/O1 generates correct result, but O2/Os generates wrong result. So the
problem should be in some optimization pass that is enabled in O2/Os while
disabled in O1.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56993
--- Comment #3 from Carrot ---
I don't have a reduced test case. But I have a reduced config file.
###
ext = Linux64
backup_config = 0
makeflags = -j64
default=default=defau
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51372
Bug #: 51372
Summary: internal compiler error: in write_builtin_type, at
cp/mangle.c:2204
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51372
Carrot changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51509
Bug #: 51509
Summary: Inefficient neon intrinsic code sequence
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51659
Bug #: 51659
Summary: ICE in function output_move_double
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51659
--- Comment #1 from Carrot 2011-12-23 02:29:49 UTC
---
(gdb) cont
Continuing.
Breakpoint 2, output_move_double (operands=0x19be680, emit=1 '\001', count=0x0)
at ../../../trunk/gcc/config/arm/arm.c:13933
13933 gcc_assert (!emit);
(gdb) p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51659
--- Comment #2 from Carrot 2012-01-05 07:06:22 UTC
---
It can be reproduced with following simple code
struct function
{
int pops_args;
long long x_frame_offset;
};
long long get_func_frame_size (struct function *f)
{
return -f->x_frame
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51797
Bug #: 51797
Summary: Arm backend missed the mls related optimization
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Pr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55666
Bug #: 55666
Summary: Use scratch register to avoid save/restore of callee
saved register
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: U
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55666
--- Comment #1 from Carrot 2012-12-12 19:48:30 UTC
---
Created attachment 28938
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28938
testcase
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55769
Bug #: 55769
Summary: unnecessary spill/reload to compose register pair
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: enhance
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: carrot at google dot com
This is actually a regression caused by r175916.
Compile the following code with options -O2 -fno-strict-aliasing
-fprofile-generate
struct thread_param
{
long* buf;
long iterations;
long
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: carrot at google dot com
Target: powerpc64le-grtev4-linux-gnu
Source code:
extern int* foo1 ( long* );
extern int *foo2 ( long *, long *);
extern void foo3 (long, long);
void bar()
{
long d, f, x, s
Assignee: unassigned at gcc dot gnu.org
Reporter: carrot at google dot com
Target: aarch64
Created attachment 32808
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32808&action=edit
testcase
Attached is reduced preprocessed source code. Compile it with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61202
--- Comment #1 from Carrot ---
In arm_neon.h, we have
__extension__ static __inline int16x8_t __attribute__ ((__always_inline__))
vqdmulhq_n_s16 (int16x8_t a, int16_t b)
{
int16x8_t result;
__asm__ ("sqdmulh %0.8h,%1.8h,%2.h[0]"
:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61202
--- Comment #3 from Carrot ---
4.8 branch also has the same problem.
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: carrot at google dot com
Target: powerpc64le
Compile the following source code with options -m64 -mvsx -mcpu=power8 -O2
typedef unsigned char Bool;
typedef unsigned char UChar;
typedef unsigned int UInt32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61202
Carrot changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
ONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: carrot at google dot com
GCC build triplet: i686-linux
GCC host triplet: i686-linux
GCC target triplet: arm-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43129
4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: carrot at google dot com
GCC build triplet: i686-linux
GCC host triplet: i686-linux
GCC target triplet: arm-
Summary: unnecessary register spill
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: carrot at google dot com
GCC build
c
Version: 4.5.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: carrot at google dot com
GCC build triplet: i686-linux
GCC host triplet: i686-linu
--- Comment #1 from carrot at google dot com 2010-03-01 08:11 ---
Created an attachment (id=19994)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19994&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43216
t org
ReportedBy: carrot at google dot com
GCC build triplet: i686-linux
GCC host triplet: i686-linux
GCC target triplet: arm-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43286
--- Comment #1 from carrot at google dot com 2010-03-08 08:28 ---
Created an attachment (id=20040)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20040&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43286
--- Comment #2 from carrot at google dot com 2010-03-08 08:32 ---
The command line options are: -march=armv7-a -O2 -fpic
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43286
--- Comment #1 from carrot at google dot com 2010-03-16 06:23 ---
This optimization uses one less register (the register hold the GOT base), to
get this beneficial the ideal place for it should be before register
allocation.
Usually expand pass generates instructions to load global
--- Comment #5 from carrot at google dot com 2010-03-18 03:52 ---
In this case arm_arm_address_cost does the right thing. The problem is in
function should_replace_address.
When two addresses have same address cost, we choose the one with higher rtx
cost. The reason is "That ha
--- Comment #4 from carrot at google dot com 2010-03-21 09:18 ---
It is for thumb1, there should be another parameter that I missed
-march=armv5te. It still exists in today's trunk.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42495
t gnu dot org
ReportedBy: carrot at google dot com
GCC build triplet: i686-linux
GCC host triplet: i686-linux
GCC target triplet: arm-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43513
--- Comment #1 from carrot at google dot com 2010-03-25 09:20 ---
Created an attachment (id=20195)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20195&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43513
--- Comment #3 from carrot at google dot com 2010-03-26 06:42 ---
There are 2 problems with csa for arm:
1. In function rest_of_handle_stack_adjustments:
if (!ACCUMULATE_OUTGOING_ARGS)
{
...
}
ACCUMULATE_OUTGOING_ARGS is defined to 1 in arm.h, so this pass is not
d compare with 0 can be combined
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: carrot at google dot com
GCC build
--- Comment #1 from carrot at google dot com 2010-03-31 07:50 ---
Created an attachment (id=20262)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20262&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43597
--- Comment #3 from carrot at google dot com 2010-03-31 08:01 ---
(In reply to comment #2)
> Doesn't this belong in the linker as a relaxation? This would solve the reloc
> problem in the process.
>
Gnu linker has already support R_ARM_GOT_PREL. And the new relocation
unassigned at gcc dot gnu dot org
ReportedBy: carrot at google dot com
GCC build triplet: i686-linux
GCC host triplet: i686-linux
GCC target triplet: arm-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43616
--- Comment #10 from carrot at google dot com 2010-04-08 09:29 ---
Fixed by the above patch.
--
carrot at google dot com changed:
What|Removed |Added
Status
--- Comment #5 from carrot at google dot com 2010-04-08 13:31 ---
(In reply to comment #4)
> I guess you'll have to experiment with your implementation to
> see what gives the best results on a large body of code.
>
I will experiment on CSiBE.
--
http://gcc.gn
--- Comment #3 from carrot at google dot com 2010-04-10 13:17 ---
Fixed by patch http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158189.
--
carrot at google dot com changed:
What|Removed
--- Comment #6 from carrot at google dot com 2010-04-11 12:09 ---
Some experiment results:
Compile CSiBE with options -Os -fpic -mthumb -fno-short-enums
without this optimization: 2830665
simplify-got before ra:2825737
simplify-got after ra: 2826853
So this optimization
--- Comment #7 from carrot at google dot com 2010-04-11 12:12 ---
(In reply to comment #6)
> Some experiment results:
>
> Compile CSiBE with options -Os -fpic -mthumb -fno-short-enums
>
> without this optimization: 2830665
> simplify-got before ra:2825737
>
: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: carrot at google dot com
GCC build triplet: i686-linux
GCC host triplet: i686-linux
GCC target triplet: arm-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43814
--- Comment #1 from carrot at google dot com 2010-04-20 09:03 ---
Created an attachment (id=20435)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20435&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43814
--- Comment #7 from carrot at google dot com 2010-04-22 12:26 ---
(In reply to comment #6)
> I can't see how it would hurt to allow combine to always merge insns that are
> known to be consecutive (ie to ignore CLASS_LIKELY_SPILLED_P if
> prev_nonenote_insn(consumer) == pr
ReportedBy: carrot at google dot com
GCC build triplet: i686-linux
GCC host triplet: i686-linux
GCC target triplet: arm-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43864
--- Comment #1 from carrot at google dot com 2010-04-23 07:28 ---
Created an attachment (id=20469)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20469&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43864
--- Comment #3 from carrot at google dot com 2010-04-24 11:53 ---
lsls r2,r3, #1 can be assembled to 16 bit.
lsl r2,r3, #1 is 32 bit because only 32 bit encoding can ignore condition
code.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42879
--- Comment #5 from carrot at google dot com 2010-04-26 08:30 ---
Yes, it looks much better for this case. The number of instructions is reduced
from 49 to 39. All problems described have gone.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43216
Version: 4.6.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: carrot at google dot com
GCC build triplet: i686-linux
GCC host triplet: i686-linux
GCC targ
--- Comment #1 from carrot at google dot com 2010-04-28 08:18 ---
Created an attachment (id=20504)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20504&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43920
--- Comment #2 from carrot at google dot com 2010-04-28 09:01 ---
The expected sequence should be:
...
cmp r4, #-1
beq .L4
cmp r0, #-1
beq .L4
...
When changes the options to -march=armv5te -mthumb -Os, gcc can generate the
expected codes
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: carrot at google dot com
Target: powerpc64le
I use ppc gcc to compile following code with option -O2
unsigned long c2l(unsigned char* p)
{
unsigned long res = *p + *(p+1);
return res;
}
long c2sl(signed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63530
Carrot changed:
What|Removed |Added
CC||carrot at google dot com
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63530
--- Comment #3 from Carrot ---
It turns out that when function vect_create_addr_base_for_vector_ref create a
new pointer, it doesn't set the correct alignment of pointer value, so the
default alignment of the point_to type is used. We should use
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: carrot at google dot com
Target: powerpc64le
Currently ppc gcc generates two instructions to compute the address of non
local data. If the data layout is known to compiler, we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63530
--- Comment #7 from Carrot ---
(In reply to Ramana Radhakrishnan from comment #6)
> Fixed then ?
Yes, thanks for closing it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47764
--- Comment #6 from Carrot ---
Another example for ppc.
Following code is disassembled from sha1dgst.o in openssl which is compiled by
gcc
:
...
80: 82 5a 52 3f addis r26,r18,23170
84: 78 9a
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: carrot at google dot com
Host: x86_64-unknown-linux-gnu
Target: powerpc64le
Compile following code with trunk compiler and options -O2 -m64 -mcpu=power8
void foo(int *p1, char *p2, int s)
{
int
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: carrot at google dot com
Target: powerpc64le
Compile following code with options -m64 -mcpu=power8 -O2
extern void free (void *__ptr);
void my_free ( void* p, void* addr )
{
if (addr != ((void *)0)) free
Assignee: unassigned at gcc dot gnu.org
Reporter: carrot at google dot com
Target: arm-unknown-linux-gnueabi
Compile following source code with options -march=armv7-a -mfpu=vfpv3
-mfloat-abi=softfp -O2 -std=gnu++11
#include
#include
const int kFixedPointDenominator
Assignee: unassigned at gcc dot gnu.org
Reporter: carrot at google dot com
Target: powerpc64le
Compile following source code with options -m64 -mcpu=power8 -O2
typedef struct {
int l;
int b[258];
} S;
void clear (S* s )
{
int i;
int len = s->l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62040
Carrot changed:
What|Removed |Added
CC||carrot at google dot com
--- Comment #5 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62040
--- Comment #6 from Carrot ---
Even more simplified test case for gcc4.9, but it doesn't trigger the error for
trunk.
typedef __builtin_aarch64_simd_udi uint64x1
__attribute__ ((__vector_size__ (8)));
typedef __builtin_aarch64_simd_udi uint64
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: carrot at google dot com
Target: powerpc64le
Compile following source code with options -m64 -mcpu=power8 -O2
typedef struct {
int l;
int b[258];
} S;
void clear (S* s )
{
int i;
int
Assignee: unassigned at gcc dot gnu.org
Reporter: carrot at google dot com
Target: aarch64
Compile following source code with options -fprofile-use -O2
static inline int CLZ(int mask) {
return mask ? __builtin_clz(mask) : 32;
}
int foo(int value)
{
if (value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62262
--- Comment #5 from Carrot ---
(In reply to amker from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > (insn 27 26 40 5 (set (reg:SI 73 [ D.2590 ])
> > (and:SI (ashift:SI (reg/v:SI 74 [ value ])
> > (const_in
: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: carrot at google dot com
Check out the latest trunk, apply the following patch to move web before IRA
Index: passes.def
===
--- passes.def(revision 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63156
--- Comment #3 from Carrot ---
../trunk3/configure '--build=x86_64-build_unknown-linux-gnu'
'--host=x86_64-build_unknown-linux-gnu' '--target=arm-unknown-linux-gnueabi'
'--prefix=/usr/local/google/home/carrot/x-tools/arm-unknown-linux-gnueabi'
'-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63156
--- Comment #4 from Carrot ---
In function df_uses_record, we have:
...
case PRE_DEC:
case POST_DEC:
case PRE_INC:
case POST_INC:
case PRE_MODIFY:
case POST_MODIFY:
gcc_assert (!DEBUG_INSN_P (insn_info->insn));
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63156
--- Comment #6 from Carrot ---
(In reply to Steven Bosscher from comment #5)
> (In reply to Carrot from comment #4)
> > For a AUTOINC rtl expression, we create two refs, one def and one use, but
> > only the def gets the flag DF_REF_READ_WRITE, t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63156
--- Comment #8 from Carrot ---
(In reply to Steven Bosscher from comment #7)
> (In reply to Carrot from comment #6)
> > Since it is intentionally to remove flag DF_REF_READ_WRITE on use,
>
> Ah, but I don't think that was the correct fix. The DE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63156
--- Comment #9 from Carrot ---
The original flag setting code is neither correct. Consider following
pre_modify expression:
(pre_modify (r1)// def1, use1
(plus (r1) // use2
(r2)))//
Assignee: unassigned at gcc dot gnu.org
Reporter: carrot at google dot com
Target: powerpc64le
In bzip2 there are code segment like:
if (s->state == BZ_X_MAGIC_1) {
/*initialise the save area*/
s->save_i = 0;
s->save_j = 0;
--- Comment #9 from carrot at google dot com 2009-11-23 08:51 ---
Fixed by Richard. Close it.
--
carrot at google dot com changed:
What|Removed |Added
Status
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: carrot at google dot com
GCC build triplet: i686-linux
GCC host triplet: i686-linux
GCC
--- Comment #1 from carrot at google dot com 2009-11-24 08:52 ---
Created an attachment (id=19108)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19108&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42161
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: carrot at google dot com
GCC build triplet: i686-linux
GCC host triplet: i686-linux
GCC target triplet: arm-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #1 from carrot at google dot com 2009-11-25 09:16 ---
Created an attachment (id=19147)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19147&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42172
101 - 200 of 272 matches
Mail list logo
