https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90106
--- Comment #19 from JunMa ---
we can skip the target by adding
/* { dg-skip-if "need hardfp abi" { *-*-* } { "-mfloat-abi=soft" } { "" } } */
to testcase.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90106
--- Comment #17 from JunMa ---
(In reply to Christophe Lyon from comment #16)
> That's what I did... (use -fdump-tree-cdce-details).
>
> The assembler code is:
> .arm
> .fpu softvfp
> .type foo, %function
> foo:
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90106
--- Comment #15 from JunMa ---
(In reply to Christophe Lyon from comment #14)
> Sure, here is the contents of cdce3.c.105t.cdce:
>
> ;; Function foo (foo, funcdef_no=0, decl_uid=4197, cgraph_uid=1,
> symbol_order=0)
>
> foo (float x)
> {
> fl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90106
--- Comment #13 from JunMa ---
(In reply to Christophe Lyon from comment #12)
> This new test fails on arm:
> FAIL: gcc.dg/cdce3.c scan-tree-dump cdce "cdce3.c:9: [^\n\r]* function call
> is shrink-wrapped into error conditions."
I don't have ar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90514
--- Comment #4 from JunMa ---
(In reply to Andrew Pinski from comment #3)
> (In reply to JunMa from comment #2)
> > I had got confused by the comments in vrp pass. the condition
> > if ((kind != ENUM1) && (kind != ENUM2))
> > is not always fal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90517
JunMa changed:
What|Removed |Added
CC||JunMa at linux dot alibaba.com
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90514
--- Comment #2 from JunMa ---
(In reply to Andrew Pinski from comment #1)
> Are you saying the precision should be 1? If so then no, that would be
> invalid as in C, enum have the full range of the underlying type and is well
> defined to have v
Assignee: unassigned at gcc dot gnu.org
Reporter: JunMa at linux dot alibaba.com
Target Milestone: ---
For case pr23046.c:
enum eumtype { ENUM1, ENUM2 };
void g(const enum eumtype kind );
void f(long i);
void g(const enum eumtype kind)
{
if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90437
JunMa changed:
What|Removed |Added
CC||JunMa at linux dot alibaba.com
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90387
--- Comment #4 from JunMa ---
LGTM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90387
JunMa changed:
What|Removed |Added
CC||JunMa at linux dot alibaba.com
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90106
--- Comment #9 from JunMa ---
(In reply to JunMa from comment #7)
> yes, the transformation in CDEC prevent the tail call optimization. let's
> check the return stmt in CDEC pass.
Sorry for the confused comment.
As the discussion above, The cd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90106
--- Comment #8 from JunMa ---
(In reply to Alexander Monakov from comment #6)
> Reopening and confirming, GCC's code looks less efficient than possible for
> no good reason.
>
> CDCE does
>
> y = sqrt (x);
> ==>
> y = IFN_S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89774
JunMa changed:
What|Removed |Added
CC||JunMa at linux dot alibaba.com
--- Comment #10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90106
JunMa changed:
What|Removed |Added
CC||JunMa at linux dot alibaba.com
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89922
JunMa changed:
What|Removed |Added
CC||JunMa at linux dot alibaba.com
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89977
--- Comment #5 from JunMa ---
(In reply to Martin Sebor from comment #4)
> You're right that the conversion from int128_t to unsigned long can result
> in truncation, so the range of the result is that of unsigned long. Yet I
> suspect that rely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89977
--- Comment #3 from JunMa ---
(In reply to JunMa from comment #2)
> After a bit more thinking, the behavior of gcc trunk is right. the range of
> n_3 in truncation from int128 to long unsigned int equal to the range of
> long unsigned int. for ex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89977
--- Comment #2 from JunMa ---
After a bit more thinking, the behavior of gcc trunk is right. the range of n_3
in truncation from int128 to long unsigned int equal to the range of long
unsigned int. for example: if n_3 = 0x1, then _1 is 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89977
JunMa changed:
What|Removed |Added
CC||JunMa at linux dot alibaba.com
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89934
JunMa changed:
What|Removed |Added
CC||JunMa at linux dot alibaba.com
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89911
JunMa changed:
What|Removed |Added
CC||JunMa at linux dot alibaba.com
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89341
--- Comment #12 from JunMa ---
(In reply to Jan Hubicka from comment #11)
> Removing the alias check seems correct to me. The same body alias patch was
> long and needed special casing those aliases on quite few places. I am not
> at all sure wh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89809
--- Comment #3 from JunMa ---
the stmt generated by fe has some issue, in 004t.original dump file:
return = (uint16_t) ((signed short) *p | (signed short) ((int) *(p +
1) << 8));
However, the return stmt should be:
return = (uint16_t) (((int)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89809
JunMa changed:
What|Removed |Added
CC||JunMa at linux dot alibaba.com
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89341
JunMa changed:
What|Removed |Added
CC||JunMa at linux dot alibaba.com
--- Comment #10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89772
JunMa changed:
What|Removed |Added
CC||JunMa at linux dot alibaba.com
--- Comment #2
27 matches
Mail list logo
