Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: z.zhanghaijian at huawei dot com
Target Milestone: ---
For if/else structure,
Example 1:
int test(int cond, int a, int b, int c)
{
int result = 0;
if (cond)
result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94274
--- Comment #3 from z.zhanghaijian at huawei dot com ---
(In reply to Marc Glisse from comment #1)
> Detecting common beginnings / endings in branches is something gcc does very
> seldom. Even at -Os, for if(cond)f(b);else f(c); we need t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94274
--- Comment #4 from z.zhanghaijian at huawei dot com ---
(In reply to Richard Biener from comment #2)
> Note that with binary operations you are eventually increasing register
> pressure up to a point where we need to spill so IMHO this
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: z.zhanghaijian at huawei dot com
CC: rguenther at suse dot de
Target Milestone: ---
test case: gcc/testsuite/gcc.dg/pr94269.c
Command line: aarch64-linux-gnu-gcc -S -O2 -fopt-info -march
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94398
--- Comment #1 from z.zhanghaijian at huawei dot com ---
(gdb) bt
#0 aarch64_builtin_support_vector_misalignment (mode=E_VNx4SFmode,
type=0xb79ec2a0, misalignment=-1, is_packed=false)
at ../../gcc-git/gcc/config/aarch64/aarch64.c:17510
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: z.zhanghaijian at huawei dot com
Target Milestone: ---
Minmax optimization for fortran，
for example:
SUBROUTINE mydepart(vara,varb,varc,res)
REAL, INTENT(IN) :: vara,varb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94665
--- Comment #4 from z.zhanghaijian at huawei dot com ---
(In reply to Segher Boessenkool from comment #2)
> If vara is a NaN, this is not the same; it needs -ffinite-math-only.
> And in fact adding that option does the trick (on powerpc t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94665
--- Comment #6 from z.zhanghaijian at huawei dot com ---
(In reply to Segher Boessenkool from comment #5)
> Can you show the -fdump-rtl-combine-all dump where that insn is
> created?
>
> It is fine to generate min or max insns h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94665
--- Comment #8 from z.zhanghaijian at huawei dot com ---
(In reply to Segher Boessenkool from comment #7)
> Can r94 or r93 be NaN there?
>
> (I should build an aarch64 compiler... takes almost a day though :-) )
Yes, r94 and r93 are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94665
--- Comment #12 from z.zhanghaijian at huawei dot com ---
(In reply to Segher Boessenkool from comment #11)
> Confirmed the comment 4 problem, on all archs. This is a very old bug.
Ok to me, can this optimization cha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94665
--- Comment #13 from z.zhanghaijian at huawei dot com ---
When change to flag_finite_math_only, this fmaxnm can also be generated with
the patch above(swap the true_rtx/false_rtx).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94665
--- Comment #14 from z.zhanghaijian at huawei dot com ---
(In reply to Segher Boessenkool from comment #11)
> Confirmed the comment 4 problem, on all archs. This is a very old bug.
There are two ways to fix this bug:
1. Cha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94665
--- Comment #16 from z.zhanghaijian at huawei dot com ---
(In reply to Segher Boessenkool from comment #15)
> replacing flag_unsafe_math_operations by flag_finite_math_only isn't correct,
> but you can add it instead, i.e.
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: z.zhanghaijian at huawei dot com
Target Milestone: ---
Rtl combine should consider NaNs when generate fp min/max.
There is detailed discussion information here:
https://gcc.gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94665
--- Comment #18 from z.zhanghaijian at huawei dot com ---
(In reply to Segher Boessenkool from comment #17)
> [ Please don't add other email addresses for me; I get enough mail already,
> I don't need all bugzilla mail in dupl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94665
z.zhanghaijian at huawei dot com changed:
What|Removed |Added
Resolution|--- |FIXED
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: z.zhanghaijian at huawei dot com
Target Milestone: ---
The case gcc.dg/pr94780.c on aarch64:
_Atomic double x;
double
foo (void)
{
double bar () { return x; }
x /= 3;
return bar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94820
--- Comment #3 from z.zhanghaijian at huawei dot com ---
I have an initial fix for aarch64 that is under testing.
Will post to gcc-patches when finished.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94274
--- Comment #5 from z.zhanghaijian at huawei dot com ---
Created attachment 48659
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48659&action=edit
Fold phi whose incoming args are defined from binary operations
I tried to make a p
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: z.zhanghaijian at huawei dot com
Target Milestone: ---
ICE issue triggered under option -fpack-struct=n:
Example:
test.c：
#include "arm_sve.h"
gcc test.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95523
--- Comment #2 from z.zhanghaijian at huawei dot com ---
(In reply to rsand...@gcc.gnu.org from comment #1)
> The reason for the assert is that the alignment is part of the
> ABI of the types and is relied on when using LDR and STR for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95523
--- Comment #4 from z.zhanghaijian at huawei dot com ---
> Could you try setting DECL_USER_ALIGN on the FIELD_DECL?
> that should (hopefully) force the field to keep its
> natural alignment.
Do you mean to change the alignment t
: driver
Assignee: unassigned at gcc dot gnu.org
Reporter: z.zhanghaijian at huawei dot com
Target Milestone: ---
For the case：
cat foo.c
void foo (void)
{
return;
}
$gcc foo.c -S -dumpbase "" -dumpbase-ext .c -o foo.o
gcc: internal compiler error: in process_c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96230
--- Comment #2 from z.zhanghaijian at huawei dot com ---
(In reply to Richard Biener from comment #1)
> But then an empty dumpbase should be OK?
The case ic-misattribution-1.c in the gcc testsuite contains an empty string
-dumpb
Assignee: unassigned at gcc dot gnu.org
Reporter: z.zhanghaijian at huawei dot com
Target Milestone: ---
For aarch64 SVE,
The case:
typedef unsigned char v32u8 __attribute__ ((vector_size (32)));
unsigned __attribute__((noinline, noclone))
foo(unsigned u)
{
v32u8 v32u8_0
Assignee: unassigned at gcc dot gnu.org
Reporter: z.zhanghaijian at huawei dot com
Target Milestone: ---
For aarch64 SVE,
The case:
typedef unsigned char v32u8 __attribute__ ((vector_size (32)));
unsigned __attribute__((noinline, noclone))
foo(unsigned u)
{
v32u8 v32u8_0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96834
z.zhanghaijian at huawei dot com changed:
What|Removed |Added
CC||z.zhanghaijian at
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: z.zhanghaijian at huawei dot com
Target Milestone: ---
The case like:
test.c:
int f31() { }
void f30() { printf("30\n"); f31(); }
void f29() {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96834
--- Comment #7 from z.zhanghaijian at huawei dot com ---
(In reply to Richard Biener from comment #5)
> (In reply to z.zhanghaij...@huawei.com from comment #4)
> > The case like:
> > test.c:
> > int f31()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96893
--- Comment #2 from z.zhanghaijian at huawei dot com ---
(In reply to Richard Biener from comment #1)
> Please provide a script to generate the testcase. A backtrace would be nice
> as well, likely the stack blows up.
cat gen.sh
#!/bi
30 matches
Mail list logo
