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
> -Original Message-
> From: Andrew Pinski [mailto:pins...@gcc.gnu.org]
> Sent: Saturday, November 5, 2022 2:34 PM
> To: Zhongyunde
> Cc: hongtao@intel.com; gcc-patches@gcc.gnu.org; Zhangwen(Esan)
> ; Weiwei (weiwei, Compiler)
> ; zhong_1985...@163.com
> Subj
hi,
This patch is try to fix the issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107190,
would you like to give me some suggestion, thanks.
~/source/gccUpstreamDir/gcc/testsuite(cfg) » git format-patch -1
--start-number=00 HEAD -o ~/patch
/home/zhongyunde/patch/-PHIOPT-Add-A-B-CST-B
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=edit
has different operand order base on different commit node
hi @Andrew Pinski
* Showed as the figure swap_order.jpg
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
>
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
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=edit
the huge bb sligtly change after match ResLo
Thanks for your suggestion, and I think both ctz_table_index and
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
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
: 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/G77nKnf8W
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
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96031
--- Comment #4 from zhongyunde at tom dot com ---
> As for ivopt, I can see a minor improvement by replacing != exit condition
> with <=, thus saving add 2 instruction computing _22, which happens to
> "disable" the wr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96427
--- Comment #6 from zhongyunde at tom dot com ---
Created attachment 49087
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49087=edit
adjust the alignment according the attibute
If user don't specify the alignment, so we can do s
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zhongyunde at tom dot com
Target Milestone: ---
For the following case, we can easy known the while loop will execute once, but
with newest gcc 10.2, it still generated suboptimal code with condition
expression.
void
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=93102
--- Comment #4 from zhongyunde at tom dot com ---
case from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96427 generates *.LC0,
but don't emit an aggregate copy a_1 = *.LC0, i.e. it is legal even for
non-const local array.
typedef int v4si
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96427
--- Comment #2 from zhongyunde at tom dot com ---
should the data alignment honor the user specified ?
Now, it seems compiler _do_ align the initializer according align load.
so even if the local array doesn't specify the __attribute__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95696
--- Comment #6 from zhongyunde at tom dot com ---
Thanks for you notes and I thinks this issue can be closed now.
It doesn't need to handle of non-SMS cases as they'll reschedule in general,
which is good for performance under my test.
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zhongyunde at tom dot com
Target Milestone: ---
For the following code, we can known the local array a_1 is aligned 64 bytes,
but now gcc only aligned to default 32 bytes for related anchor
> -Original Message-
> From: Richard Sandiford [mailto:richard.sandif...@arm.com]
> Sent: Tuesday, July 28, 2020 1:33 AM
> To: Zhongyunde
> Cc: gcc-patches@gcc.gnu.org; Yangfei (Felix)
> Subject: Re: [PATCH PR95696] regrename creates overlapping register
>
I reconsider the issue and update patch attached.
Yes, If the kernel loop bb's information doesn't use in regrename, it also need
not be collected to save compile time.
> -Original Message-
> From: Zhongyunde
> Sent: Sunday, July 26, 2020 3:29 PM
> To: 'Richard Sandiford
> >> It's interesting that this is for a testcase using SMS. One of the
> >> traditional problems with the GCC implementation of SMS has been
> >> ensuring that later passes don't mess up the scheduled loop. So in
> >> your testcase, does register allocation succeed for the SMS loop
> >>
> -Original Message-
> From: Richard Sandiford [mailto:richard.sandif...@arm.com]
> Sent: Wednesday, July 22, 2020 12:12 AM
> To: Zhongyunde
> Cc: gcc-patches@gcc.gnu.org; Yangfei (A)
> Subject: Re: 答复: [PATCH PR95696] regrename creates overlapping
> register
送时间: 2020年7月21日 0:05
收件人: Zhongyunde
抄送: gcc-patches@gcc.gnu.org; Yangfei (A)
主题: Re: [PATCH PR95696] regrename creates overlapping register allocations for
vliw
Hi,
Zhongyunde writes:
> Hi，
>
> In most target, it is limited to issue two insns with change the same
> register. S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96031
--- Comment #3 from zhongyunde at tom dot com ---
I find there is some different between the two cases during in ivopts.
For the 2nd case, a UINT32 type iv sum is choosed
[local count: 955630224]:
# sum_15 = PHI <0(5), sum_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95696
--- Comment #3 from zhongyunde at tom dot com ---
(In reply to Richard Biener from comment #2)
> Please send patches to gcc-patc...@gcc.gnu.org
I have send this patch by email according your suggestion, please give me some
advice, thanks!
Hi，
In most target, it is limited to issue two insns with change the same register.
So a register is not realy unused if there is another insn, which set the
register in the save VLIW.
For example, The insn 73 start with insn:TI, so it will be issued together with
others insns until a new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96031
--- Comment #1 from zhongyunde at tom dot com ---
this may can be enhance by ivopts.
If the case adjusted as following, then the 'and w2, w2, 65535 ' will
disappear.
typedef unsigned int UINT32;
typedef unsigned short UINT16;
UINT16
: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zhongyunde at tom dot com
Target Milestone: ---
For the following code, as instruction strh only store the low 16-bits value,
so the 'and w2, w2, 65535 ' is redundant.
test base on the ARM64 gcc 8.2 on https
In some target, it is limited to issue two insns with change the same
register.(The insn 73 start with insn:TI, so it will be issued together with
others insns until a new insn start with insn:TI, such as insn 71)
The regrename can known the mode V2VF in insn 73 need two successive registers,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95696
zhongyunde at tom dot com changed:
What|Removed |Added
CC||zhongyunde at tom dot com
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zhongyunde at tom dot com
Target Milestone: ---
In some target, it is limited to issue two insns with change the same
register.(The insn 73 start with insn:TI, so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95267
zhongyunde at tom dot com changed:
What|Removed |Added
CC||zhongyunde at tom dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95210
zhongyunde at tom dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95210
--- Comment #1 from zhongyunde at tom dot com ---
patch for this issue.
@ linux-9z2e in ~/software/gcc/gcc on git:master o [23:02:26]
$ git diff
diff --git a/gcc/gcse.c b/gcc/gcse.c
index 8b9518e..65982ec 100644
--- a/gcc/gcse.c
+++ b/gcc
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zhongyunde at tom dot com
Target Milestone: ---
rtx_insn *
prepare_copy_insn (rtx reg, rtx exp)
{
...
else
{
rtx_insn *insn = emit_insn (gen_rtx_SET (reg, exp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95019
--- Comment #2 from zhongyunde at tom dot com ---
It is a generic issue for all targets, such as x86, it also don't enpand IVOPTs
as index is not used for DEST and Src directly. we may need expand IVOPTs, then
different targets can select
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zhongyunde at tom dot com
Target Milestone: ---
For the following code, we can known the variable C05A1 is only used for
the offset of array Dest and Src, and the unit size
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=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 effect.
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zhongyunde at tom dot com
Target Milestone: ---
For the following code, we can known init the array C16DD is always
consecutive, so we can use the more bigger mode size.
test base
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=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
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;
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
: 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
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=edit
a simplified test case
compile loop.c with follow command on x86 tar
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
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
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=edit
a simple testcase
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
1 - 100 of 121 matches
Mail list logo
