Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: bule1 at huawei dot com
CC: richard.sandiford at arm dot com
Target Milestone: ---
Target: AARCH64
This report suggest to use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94154
Bu Le changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: bule1 at huawei dot com
CC: mjambor at suse dot cz
Target Milestone: ---
Target: aarch64
Created attachment 48154
--> ht
Assignee: unassigned at gcc dot gnu.org
Reporter: bule1 at huawei dot com
Target Milestone: ---
Created attachment 48584
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48584=edit
proposed patch
I would like to propose an implementation of the medium code mo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95285
--- Comment #1 from Bu Le ---
Created attachment 48585
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48585=edit
patch for binutils
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95285
--- Comment #14 from Bu Le ---
> > Anyway, my point is that the size of single data does't affact the fact that
> > medium code model is missing in aarch64 and aarch64 is lack of PIC large
> > code model.
>
> What is missing is efficient
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95285
--- Comment #10 from Bu Le ---
> Fortran already has -fstack-arrays to decide between allocating arrays on
> the heap or on the stack.
I tried the flag with my example. The fstack-array seems cannot move the array
in the bss to the heap. The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95285
--- Comment #11 from Bu Le ---
> You're right, we need an extra add, so it's like this:
>
> adrpx0, bar1.2782
> movk x1, :high32_47:bar1.2782
> add x0, x0, x1
> add x0, x0, :lo12:bar1.2782
>
> > (By the way, the high32_47
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95285
--- Comment #3 from Bu Le ---
(In reply to Wilco from comment #2)
> Is the main usage scenario huge arrays? If so, these could easily be
> allocated via malloc at startup rather than using bss. It means an extra
> indirection in some cases (to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95285
--- Comment #6 from Bu Le ---
(In reply to Wilco from comment #4)
> (In reply to Bu Le from comment #3)
> > (In reply to Wilco from comment #2)
> Well the question is whether we're talking about more than 4GB of code or
> more than 4GB of data.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95285
--- Comment #7 from Bu Le ---
(In reply to Wilco from comment #5)
> (In reply to Bu Le from comment #0)
>
> Also it would be much more efficient to have a relocation like this if you
> wanted a 48-bit PC-relative offset:
>
> adrpx0,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96366
--- Comment #5 from Bu Le ---
(In reply to rsand...@gcc.gnu.org from comment #3)
> (In reply to Bu Le from comment #2)
> > (In reply to rsand...@gcc.gnu.org from comment #1)
> > > (In reply to Bu Le from comment #0)
> Generating a subtraction
: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: bule1 at huawei dot com
Target Milestone: ---
Target: AARCH64
Created attachment 48824
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48824=e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96030
--- Comment #3 from Bu Le ---
(In reply to Jakub Jelinek from comment #1)
> The directive should be doing what
> #pragma omp declare simd
> does on the target and it is an ABI decision what exactly it does.
Hi,I am still confused about your
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96030
--- Comment #2 from Bu Le ---
(In reply to Jakub Jelinek from comment #1)
> The directive should be doing what
> #pragma omp declare simd
> does on the target and it is an ABI decision what exactly it does.
I tried this test case. But I haven't
Assignee: unassigned at gcc dot gnu.org
Reporter: bule1 at huawei dot com
Target Milestone: ---
Target: AARCH64
Created attachment 48815
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48815=edit
patch for enable libquadmath in aarch64
Hi
I would like to prop
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: bule1 at huawei dot com
CC: richard.sandiford at arm dot com
Target Milestone: ---
Created attachment 48950
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96366
--- Comment #2 from Bu Le ---
(In reply to rsand...@gcc.gnu.org from comment #1)
> (In reply to Bu Le from comment #0)
> Hmm. In general, the lack of a vector pattern shouldn't case ICEs,
> but I suppose the add/sub pairing is somewhat special
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96016
--- Comment #2 from Bu Le ---
(In reply to Andrew Pinski from comment #1)
> If long double is 128bit fp already, then glibc has full support of it. So
> you dont need libquadmath at all. It is only there if long double is not
> 128bit long
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96016
--- Comment #4 from Bu Le ---
(In reply to Andreas Schwab from comment #3)
> You are computing the sine of (double)ld. If you want the sine of a long
> double value, you need to use the sinl function, also use acosl(-1) to
> compute pi in long
20 matches
Mail list logo
