Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: zhongyunde at huawei dot com
Target Milestone: ---
* test: https://gcc.godbolt.org/z/5YbezdW89
```
float foo (float num[], float r2inv, int n) {
float sum = 0.0;
for (int i=0; i
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zhongyunde at huawei dot com
Target Milestone: ---
* test: https://gcc.godbolt.org/z/sr6Mevf9G
```
float32x4_t test2_float_vec (float32x4_t a, float32x4_t b
Assignee: unassigned at gcc dot gnu.org
Reporter: zhongyunde at huawei dot com
Target Milestone: ---
* test: https://gcc.godbolt.org/z/E6Eez81jh
```
#include
typedef svfloat32_t fvec32 __attribute__((arm_sve_vector_bits(256)));
typedef svfloat32_t __m256_;
__m256_
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zhongyunde at huawei dot com
Target Milestone: ---
* test:https://gcc.godbolt.org/z/39KddjbE4
```
void va(struct args_t * func_args)
{
for (int nl = 0; nl < iterations; nl++) {
for (int i = 0; i <
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zhongyunde at huawei dot com
Target Milestone: ---
test:https://gcc.godbolt.org/z/j74z1qaT9
```
int check_pointer (void)
{
int *pa = (int *) malloc (sizeof (int) * NUM);
int *pb = (int *) malloc (sizeof (int) * NUM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109269
--- Comment #3 from vfdff ---
* test: https://gcc.godbolt.org/z/5s4Wbs466
```
void mset (int *a, int num) {
for (int i=0; i< num; i++)
a[i] = 2;
}
```
* the issue is still exist with int type as we use 32-bits register? . see
detail on
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zhongyunde at huawei dot com
Target Milestone: ---
* test case:https://gcc.godbolt.org/z/jde11xv53
```
void mset (int *a, long long num) {
for (long long i=0; i< num; i++)
a[i] = 2;
}
```
* Base on above c
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zhongyunde at huawei dot com
Target Milestone: ---
* test:https://gcc.godbolt.org/z/res6aTYqP
```
unsigned sel(unsigned X) {
return X == 6 ? 6 : 8;
}
```
* gcc:
```
sel:
cmp w0, 6
mov w1, 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106323
--- Comment #4 from vfdff ---
Now, llvm use 4 loads and CMP+CCMP, https://gcc.godbolt.org/z/PM3jxEM9M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104611
--- Comment #3 from vfdff ---
As the load instructions usually have long latency, so do it need some extra
restrict when we try this transformation?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107090
--- Comment #11 from vfdff ---
Created attachment 53787
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53787&action=edit
has different operand order base on different commit node
hi @Andrew Pinski
* Showed as the figure swap_order.jpg at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107316
--- Comment #2 from vfdff ---
(In reply to Andrew Pinski from comment #1)
> I suspect this is just a dup of bug 106583 and will be fixed by the patch
> which was submitted recently
> (https://gcc.gnu.org/pipermail/gcc-patches/2022-October/603905
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zhongyunde at huawei dot com
Target Milestone: ---
* case, https://godbolt.org/z/38bcszxdo
```
int check (char *mask, double *result, int n) {
int count = 0;
for (int i=0; i
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zhongyunde at huawei dot com
Target Milestone: ---
test case: https://godbolt.org/z/ahreYnahE
```
int main (int argc, char** argv)
{
if (lshift_1 (0xull) != 0ll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104611
vfdff changed:
What|Removed |Added
CC||zhongyunde at huawei dot com
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107208
--- Comment #3 from vfdff ---
it seems releted to targetm.calls.function_value called by assign_parms, who
return different behaviour for MODE_COMPLEX_FLOAT and MODE_COMPLEX_INT. With
the following changes, then choose a pair of DI for the int c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107090
--- Comment #10 from vfdff ---
Created attachment 53698
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53698&action=edit
the huge bb sligtly change after match ResLo
Thanks for your suggestion, and I think both ctz_table_index and
nop_ato
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107090
--- Comment #8 from vfdff ---
hi @Andrew Pinski
For the 2nd issue, I also matched the huge pattern, but it need return two
value, it seems don't work with current framework? so should I have to split it
into two simples to match the high and l
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: zhongyunde at huawei dot com
Target Milestone: ---
* gcc now generate 2 redundant mov instrunction compared to llvm
```
mul64(unsigned long _Complex, unsigned long _Complex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107090
vfdff changed:
What|Removed |Added
Attachment #53684|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107090
vfdff changed:
What|Removed |Added
CC||zhongyunde at huawei dot com
--- Comment #5
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: zhongyunde at huawei dot com
Target Milestone: ---
This case is simplify from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107090,
and we can see that the codegen of function `test_m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107090
--- Comment #4 from vfdff ---
(In reply to Andrew Pinski from comment #1)
> A few issues.
> First is:
>
> if (_26 != 0)
> goto ; [50.00%]
> else
> goto ; [50.00%]
>
>[local count: 536870913]:
> ht_15 = ht_13 + 4294967296;
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107090
--- Comment #2 from vfdff ---
Thanks for your suggestion.
As the combine pass can't address more than 4 sequence insns, which pass may be
more suitable to match the huge pattern after fixing the 1st issue.
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zhongyunde at huawei dot com
Target Milestone: ---
* test case: https://godbolt.org/z/x5jMhqW8s
```
# define BN_BITS432
# define BN_MASK2(0xL)
# define
: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: zhongyunde at huawei dot com
Target Milestone: ---
hi
base on https://gcc.godbolt.org/z/9bonaW4eh, we can see that `aarch64
gfortran` 12 has some regression.
* x86-x64 gfortran 12 -- pass
* aarch64 gfortran 12
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: zhongyunde at huawei dot com
Target Milestone: ---
We can see that, the icc use a two-layer loop to initialize a 3D array, and the
inner loop initialize the low 2D of the
: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zhongyunde at huawei dot com
Target Milestone: ---
test case, see detail https://gcc.godbolt.org/z/PM3jxEM9M
```
#include
int src(char* s1, char* s2) {
return memcmp(s1, s2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106268
--- Comment #2 from vfdff ---
it seems different for the C version, see detail
https://godbolt.org/z/vc1edYKhf
in your above case, the icc also doesn't elide the outer loop.
: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: zhongyunde at huawei dot com
Target Milestone: ---
For the kernel inner loop body, gcc generate an loop, while icc doesn't, see
detail in https://godbolt.org/z/G77n
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zhongyunde at huawei dot com
Target Milestone: ---
llvm uses memory access instructions with larger access bit width base on
following case, both on x86 and arm, see detail
https
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zhongyunde at huawei dot com
Target Milestone: ---
llvm uses memory access instructions with larger access bit width base on
following case, both on x86 and arm, see detail
https
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zhongyunde at huawei dot com
Target Milestone: ---
case:https://godbolt.org/z/sc5rTzaeb
```
double advance(double dt, double dx, double dy, double dz)
{
double dSquared = dx * dx + dy * dy + dz * dz;
double mag
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zhongyunde at huawei dot com
Target Milestone: ---
* test case, gcc has a redundant movprfx insn in the kernel loop body, see
detail https://gcc.godbolt.org/z/8vG4PzM18.
```
#include
#define ARRAY_ALIGNMENT 64
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zhongyunde at huawei dot com
Target Milestone: ---
test case:
void loop(int N, double *a, double *b) {
// #pragma clang loop vectorize_width(4, scalable)
for (int i = 0; i < N
Assignee: unassigned at gcc dot gnu.org
Reporter: zhongyunde at huawei dot com
Target Milestone: ---
test case, see detail https://gcc.godbolt.org/z/95osxxjx5
float foo(float a)
{
float x = 1.0f;
float y = 0.0f;
float z = x / y;
return fmax (a, z);
}
as the z is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94084
vfdff changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: zhongyunde at huawei dot com
Target Milestone: ---
As __attribute__((const)) function should have no side effect, so it won't
modify any global variable. but
Assignee: unassigned at gcc dot gnu.org
Reporter: zhongyunde at huawei dot com
Target Milestone: ---
cat test.c
extern double top[100];
int foo (long long j, double a) {
top[j] += a;
return 0;
}
gcc10.3 -g0 -O3 -march=armv8.2-a test.c -save-temps -S, can also be test base
on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96427
vfdff changed:
What|Removed |Added
CC||zhongyunde at huawei dot com
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94573
--- Comment #6 from vfdff ---
Created attachment 48267
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48267&action=edit
only get the adjust_bit_pos change
base on the adjust_bit_pos change only, I test it on the gcc 9, and find it
take eff
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zhongyunde at huawei dot com
Target Milestone: ---
After we enable the schedule DO_PREDICATION, then spec_dependency_cache will be
alloc in function extend_dependency_caches, and it is obvious
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93781
--- Comment #5 from vfdff ---
Created attachment 48008
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48008&action=edit
patch base on gcc 7.3, additional for 1st testcases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93781
--- Comment #4 from vfdff ---
according your prompt, I test it base on gcc 7.3, and the second testcase
works.
--- a/gcc/tree-vrp.c
+++ b/gcc/tree-vrp.c
@@ -3301,6 +3301,18 @@ extract_range_from_binary_expr (value_range *vr,
else
set_val
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93781
--- Comment #2 from vfdff ---
I test a more simple testcase, and find the arg_5(D) already get the expected
range, but the _2 = 1 << arg_9 is unexpected.
unsigned int foo (unsigned int arg)
{
unsigned int C03FE = 4;
if (arg + 1 < 4) //
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93781
--- Comment #2 from vfdff ---
For more test, I find the following case2 can get the expect result, while the
case1 can't.
== [case1] ==
unsigned int foo (unsigned int arg)
{
unsigned int C03FE = 4;
if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94084
--- Comment #2 from vfdff ---
thanks very much, you are right.
I try the case2 with global pointer and it get similar result with case1.
extern int base;
extern int *dest, *src;
void foo (int n)
{
int i;
// #pragma no_swp
for (i=0; i
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zhongyunde at huawei dot com
Target Milestone: ---
For the following case1 and case2, we can known the global value base is a loop
invariant value, so the load insn can be lifted out of the
: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zhongyunde at huawei dot com
Target Milestone: ---
for example, if the following oril insns need two register for operand0 and
operand1 have an implication constraint, i.e
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zhongyunde at huawei dot com
Target Milestone: ---
For the following code, we can known the value C03FE is always less then 5,
so the return value should be true.
test base on the x86-64 gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90354
--- Comment #8 from vfdff ---
I have a method to fix this issue:
check the egde with bb_has_eh_pred, and avoid bundling the jump insn when it
is true.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93561
--- Comment #3 from vfdff ---
thanks very much!
: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zhongyunde at huawei dot com
Target Milestone: ---
In funcion spill_for, there is following code:
mode = PSEUDO_REGNO_MODE (regno);
...
for (i = 0; i < rclass_size; i++)
{
hard_regno = ira_class_hard_r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93102
--- Comment #2 from vfdff ---
do you mean the optimization memtioned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47980
Yes, it can be with optimized option '-fmerge-all-constants', but it doesn't
active in default.
: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zhongyunde at huawei dot com
Target Milestone: ---
test code:
int foo (int m, int n)
{
const int C2029[10] = {0,1,2,3,2,3,0,1,2,3};
int index, sum = 0;
for (index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90354
--- Comment #6 from vfdff ---
(In reply to Richard Biener from comment #5)
> (In reply to Richard Biener from comment #2)
> > Which target? Which GCC version did work for you?
>
> Which target are you working on? Since you mark this as regress
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90837
--- Comment #4 from vfdff ---
this is an invalid issue, thanks
: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zhongyunde at huawei dot com
Target Milestone: ---
Created attachment 46481
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46481&action=edit
a simplified test case
compile loop.c with follow command
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90354
--- Comment #4 from vfdff ---
Another issue, it is not suiteable for some target supported more than 2 insns
issued together ? But the following code already exist very long without
problem.
/* ??? Hopefully multiple delay slots are not annul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90354
--- Comment #3 from vfdff ---
I work on GCC 7.3, in function scan_trace, control = pat->insn (0), so it only
check whether or not a jump_insn for the first insn of sequence.
for (prev = insn, insn = NEXT_INSN (insn);
insn;
prev =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90354
vfdff changed:
What|Removed |Added
CC||zhongyunde at huawei dot com
--- Comment #1
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: zhongyunde at huawei dot com
Target Milestone: ---
simplified testcase base on g++.eh/ia64-1.C:
~/ICE ยป cat exp1.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90267
--- Comment #3 from vfdff ---
but it doesn't warning anything, even with -Wstrict-aliasing -Wall.
Accord to http://blog.sina.com.cn/s/blog_74caf0ce010173up.html, We expect an
warning similar the following infomation.
warning: dereferencing typ
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zhongyunde at huawei dot com
Target Milestone: ---
Created attachment 46254
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46254&action=edit
a simple t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56069
vfdff changed:
What|Removed |Added
CC||zhongyunde at huawei dot com
--- Comment #20
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zhongyunde at huawei dot com
Target Milestone: ---
the preprocessed file base gcc 7.3
# 1570
"/usr1/bmtest/zhongyunde/SAC_C11/SAC/UT/linux_hcc_SD6186/../../CODE/SRS/SAC_SRSMEAS_EQSINR3I.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90027
--- Comment #2 from vfdff ---
for deja testcase: gcc.c-torture/execute/20010518-2.c
as the struct a_struct define with __attribute__ ((packed)), so the member
variable b also not aligned with 4 bytes, is this case undefined behavior ?
typedef
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zhongyunde at huawei dot com
Target Milestone: ---
base gcc 7.3.0, in function expand_expr_real_1 we can see the follow code:
else if (SLOW_UNALIGNED_ACCESS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89887
--- Comment #8 from vfdff ---
an static variable out put in assemble is decided by an special option
flag_toplevel_reorder ?
/* Traditionally we do not eliminate static variables when not
optimizing and when not doing toplevel reo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89886
--- Comment #4 from vfdff ---
Created attachment 46067
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46067&action=edit
the history of patch merged
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89886
--- Comment #3 from vfdff ---
A further thing, I think a 'static variables' will be put out in assemble, it
does not mean it is referenced ?
8dfbf71d (hubicka 2010-05-14 23:39:39 + 1286) /* Return true when all
references to VNODE must be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89886
--- Comment #2 from vfdff ---
it was worked in function varpool_node::finalize_decl (tree decl)
/* Set definition first before calling notice_global_symbol so that
it is available to notice_global_symbol. */
node->definition = true;
n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89887
--- Comment #6 from vfdff ---
Yes, I agree with your point, it is not a bug.
I doubt there is something prevent us finding the array not be touched with the
option -fno-toplevel-reorder -O2 (based on gcc 7.3), and we may get better
performance i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89887
--- Comment #4 from vfdff ---
I check that base on gcc-431, and find the local array will be placed in read
only section, i.e. gcc-431 can found the array not be touched with the option
-fno-toplevel-reorder. so is it a regression ?
~/GCC/gcc-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89887
--- Comment #2 from vfdff ---
Add option -fno-toplevel-reorder for O2, then aucSubFrmType.1820 will also be
placed in section data.
/opt/buildtools/gcc-7.3.0/bin/gcc dd.c -O2 -S -fno-toplevel-reorder
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89887
vfdff changed:
What|Removed |Added
CC||zhongyunde at huawei dot com
--- Comment #1
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zhongyunde at huawei dot com
Target Milestone: ---
file the simple testcase dd.c, compiled with the following command:
pekpcsi2:~ # /opt/buildtools/gcc-7.3.0/bin
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zhongyunde at huawei dot com
Target Milestone: ---
Created attachment 46057
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46057&action=edit
simple t
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zhongyunde at huawei dot com
Target Milestone: ---
Created attachment 43132
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43132&action=edit
patch
Now, as we define match
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zhongyunde at huawei dot com
Target Milestone: ---
Now, as we define match_dup in target insn in *.md, so when the cse only try to
replace the SRC and DEST of memory in function cse_insn
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zhongyunde at huawei dot com
Target Milestone: ---
testcase:
__attribute__ ((vector_size (16))) g_73 = {0x15FE687EL, 0x5827DF98L,
0xF8411272L, 0x235E695EL};
__attribute__ ((vector_size (16))) g_1124;
int func_1
Priority: P3
Component: regression
Assignee: unassigned at gcc dot gnu.org
Reporter: zhongyunde at huawei dot com
Target Milestone: ---
as we known , some target with vliw, then some insns can be issued at the same
cycle.
in file sched-deps.c, the following code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66335
--- Comment #3 from vfdff ---
(In reply to Richard Biener from comment #2)
> No, it's working as intended - we just print where we _could_ hoist it to
> (together with the cost).
you mean function `determine_max_movement` will check the cost, so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66335
--- Comment #1 from vfdff ---
I suggest using the code following code similar to fix the issue.
for (bsi = gsi_start_phis (bb); !gsi_end_p (bsi); gsi_next (&bsi))
{
stmt = gsi_stmt (bsi);
... ...
... ...
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zhongyunde at huawei dot com
Target Milestone: ---
in function invariantness_dom_walker::before_dom_children based on gcc 4.9.2 ,
we can see the following code:
if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66084
--- Comment #4 from vfdff ---
ok, it is ok based on gcc 4.9.2, thanks.
$GCC492/gcc ticket_1634.c -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66084
--- Comment #1 from vfdff ---
the following try can fix the issue, but need consider the reason why the
gcc_assert is added original ?
[zhongyunde@linux-root ~/6183_hcc/gcc/gcc-4.7.0/gcc]$svn diff fold-const.c
Index: fold-const.c
==
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zhongyunde at huawei dot com
Target Milestone: ---
Created attachment 35509
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35509&action=edit
a small case compile with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65842
--- Comment #1 from vfdff ---
(gdb) p debug_rtx (newpat)
(set (reg:SI 191 [ g_123$6+4 ])
(and:SI (mem/c:SI (pre_modify:SI (reg/f:SI 164)
(plus:SI (reg/f:SI 164)
(const_int -12 [0xfff4]))) [4 g_123+4 S4
: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zhongyunde at huawei dot com
Created attachment 35382
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35382&action=edit
float32 is a custom define type, so default gc
90 matches
Mail list logo
