https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116030
--- Comment #11 from Jiu Fu Guo ---
(In reply to Peter Bergner from comment #10)
> Testing was clean with the patch updated with Kewen and Sam's suggestions,
> so I pushed the commit given Kewen's approval in the patch thread.
Hi Peter, thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117007
--- Comment #8 from Jiu Fu Guo ---
(In reply to Peter Bergner from comment #1)
> Jeff, did any of your recent constant patches help with this or is this
> something different?
Vector constant runs into different paths as DImode. Those patches a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116030
--- Comment #6 from Jiu Fu Guo ---
(In reply to Jiu Fu Guo from comment #5)
> And the new version:
> https://gcc.gnu.org/pipermail/gcc-patches/2024-August/66.html
Sorry, -save-temps is still there.
As Kewen's comments:
https://gcc.gnu.org/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116030
--- Comment #5 from Jiu Fu Guo ---
And the new version:
https://gcc.gnu.org/pipermail/gcc-patches/2024-August/66.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116030
--- Comment #4 from Jiu Fu Guo ---
Submitted a patch as:
https://gcc.gnu.org/pipermail/gcc-patches/2024-August/660983.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96866
Jiu Fu Guo changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97448
Jiu Fu Guo changed:
What|Removed |Added
CC||guojiufu at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107757
--- Comment #2 from Jiu Fu Guo ---
For the scenario of this PR, the 2insn sequence would be faster than
non-prefixed loading.
One finding may be useful: when building 64bit constants, I notice that loading
may be faster sometimes if the constan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95782
Jiu Fu Guo changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98140
--- Comment #3 from Jiu Fu Guo ---
(In reply to Jiu Fu Guo from comment #2)
> (In reply to Alexander Grund from comment #1)
> > It looks like this was fixed in 10.1 by this commit
> > https://github.com/gcc-mirror/gcc/commit/
> > 37e0df8a9be5a823
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96866
--- Comment #3 from Jiu Fu Guo ---
While, I'm wondering if we could accept this code, and handle it as something
like:
(insn 5 4 6 (set (reg/f:DI 118)
(mem/u/c:DI (unspec:DI [
(symbol_ref/u:DI ("*.LC0") [flags 0x2])
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96866
Jiu Fu Guo changed:
What|Removed |Added
CC||guojiufu at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98140
Jiu Fu Guo changed:
What|Removed |Added
CC||guojiufu at gcc dot gnu.org
--- Comment #2
|RESOLVED
CC||guojiufu at gcc dot gnu.org
--- Comment #1 from Jiu Fu Guo ---
This seems a duplicate of PR100736.
*** This bug has been marked as a duplicate of bug 100736 ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100736
Jiu Fu Guo changed:
What|Removed |Added
CC||pheeck at gcc dot gnu.org
--- Comment #7 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95782
Jiu Fu Guo changed:
What|Removed |Added
CC||guojiufu at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106879
Jiu Fu Guo changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29215
Bug 29215 depends on bug 30271, which changed state.
Bug 30271 Summary: -mstrict-align can add an store extra for struct argument
passing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30271
What|Removed |Added
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16996
Bug 16996 depends on bug 30271, which changed state.
Bug 30271 Summary: -mstrict-align can add an store extra for struct argument
passing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30271
What|Removed |Added
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101926
Bug 101926 depends on bug 30271, which changed state.
Bug 30271 Summary: -mstrict-align can add an store extra for struct argument
passing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30271
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30271
Jiu Fu Guo changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101926
Bug 101926 depends on bug 112525, which changed state.
Bug 112525 Summary: fail to eliminate unused store
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112525
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112525
Jiu Fu Guo changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113109
--- Comment #13 from Jiu Fu Guo ---
(In reply to GCC Commits from comment #9)
> The master branch has been updated by Hans-Peter Nilsson :
>
> https://gcc.gnu.org/g:3d03630b123411340e52d05124cb0cacfa1fc8b0
>
> commit r14-6817-g3d03630b12341134
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113109
--- Comment #8 from Jiu Fu Guo ---
(In reply to Andrew Pinski from comment #6)
> So I did a quick audit of the EH_RETURN_HANDLER_RTX and most are registers
> rather than a memory location . And the ones which were memory locations
> used either
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113109
--- Comment #7 from Jiu Fu Guo ---
(In reply to Hans-Peter Nilsson from comment #3)
>
> I'm "guessing" that the problem with the patch, is that anything any port
> stores through a pointer based on virtual_incoming_args_rtx before
> returning,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30271
Jiu Fu Guo changed:
What|Removed |Added
CC||guojiufu at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111971
Jiu Fu Guo changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112525
--- Comment #6 from Jiu Fu Guo ---
(In reply to Jiu Fu Guo from comment #3)
> One possible method is fixing DSE to let is able to remove those 'store's.
> (but need to take care of the case that is using 'arg_pointer' to pass
> parameters.)
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112525
--- Comment #3 from Jiu Fu Guo ---
One possible method is fixing DSE to let is able to remove those 'store's.
(but need to take care of the case that is using 'arg_pointer' to pass
parameters.)
Another method: there is a patch
https://gcc.gnu.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112525
--- Comment #1 from Jiu Fu Guo ---
(In reply to Jiu Fu Guo from comment #0)
> For below code:
> ```
> typedef struct teststruct
> {
> double d;
> int arr[15]; /* for ppc64le example foo1, 14: foo is just blr. 15: foo has
> 8 'std's */
> } te
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: guojiufu at gcc dot gnu.org
Target Milestone: ---
For below code:
```
typedef struct teststruct
{
double d;
int arr[15]; /* for ppc64le example foo1, 14: foo is just blr. 15: foo has 8
'std's */
} teststruct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112340
Jiu Fu Guo changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111971
--- Comment #5 from Jiu Fu Guo ---
With a bisect, the result shows "85419ac59724b7ce710ebb4acf03dbd747edeea3 is
the first bad commit".
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108220
Jiu Fu Guo changed:
What|Removed |Added
CC||guojiufu at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111971
--- Comment #2 from Jiu Fu Guo ---
It seems gcc11 is ok.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111971
--- Comment #1 from Jiu Fu Guo ---
This issue can be reproduced on 'ppc64' BE machine with -m32.
: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: guojiufu at gcc dot gnu.org
Target Milestone: ---
For the below code, an ICE occurs when built with "-m32 -O2".
```
void
foo (unsigned long long *a)
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111778
--- Comment #2 from Jiu Fu Guo ---
Thanks so much for reporting this issue, and thanks for tracing down it!
For the code, if 'lz' is 0, it is correct to return false.
|RESOLVED
CC||guojiufu at gcc dot gnu.org
--- Comment #3 from Jiu Fu Guo ---
After r14-4470, the trunk could generate a better code for this case.
||guojiufu at gcc dot gnu.org
Status|NEW |RESOLVED
--- Comment #9 from Jiu Fu Guo ---
After r14-4470, trunk generates better code for this case.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93176
Jiu Fu Guo changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106708
Jiu Fu Guo changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108338
Jiu Fu Guo changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111597
--- Comment #3 from Jiu Fu Guo ---
(In reply to Jiu Fu Guo from comment #0)
> In match.pd there is a pattern:
> /* ((T)(A)) + CST -> (T)(A + CST) */
> #if GIMPLE
> (simplify
>(plus (convert:s SSA_NAME@0) INTEGER_CST@1)
> (if (TREE_COD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111597
--- Comment #1 from Jiu Fu Guo ---
While, even without this pattern in match.pd, the generated the sign
extend(extsw) is still there.
So, just wondering if this sub-optimal asm code would be fixed in another way.
erity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: guojiufu at gcc dot gnu.org
Target Milestone: ---
In match.pd there is a pattern:
/* ((T)(A)) + CST -> (T)(A + CST) */
#if GIMPLE
(simplify
(plus (conv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111495
--- Comment #5 from Jiu Fu Guo ---
(In reply to Andrew Pinski from comment #3)
> I suspect r14-4192-g4d80863d7f93c0a839d1fe5 fixed this ...
Yes, I reproduced this issue on ppc64le, and the fix r14-4192 seems to work
fine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111482
Jiu Fu Guo changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111482
--- Comment #7 from Jiu Fu Guo ---
This is caused by missing to check a vr's "undefine_p".
In the pattern "(X + C) / N",
(if (exact_mod (c)
...
&& range_op_handler (PLUS_EXPR).overflow_free_p (vr0, vr1)
...)
(plus (op @0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111482
--- Comment #6 from Jiu Fu Guo ---
I reproduced these issue PR11148 and PR111355 on ppc64le too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111482
--- Comment #5 from Jiu Fu Guo ---
Thanks a lot for reporting this!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111303
--- Comment #9 from Jiu Fu Guo ---
(In reply to CVS Commits from comment #7) this comment should be linked to
PR111324.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111324
--- Comment #7 from Jiu Fu Guo ---
A comment https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111303#c7
should be attached here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111303
Jiu Fu Guo changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111324
Jiu Fu Guo changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111324
--- Comment #5 from Jiu Fu Guo ---
(In reply to Andrew Pinski from comment #2)
> Confirmed.
>
> So using the local range in this case is ok. There might be only a few times
> we don't want to use it though in match.
Agree, "get_range_query" w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111324
--- Comment #4 from Jiu Fu Guo ---
(In reply to Jiu Fu Guo from comment #3)
> A patch is posted:
> https://gcc.gnu.org/pipermail/gcc-patches/2023-September/629534.html
It is not for this PR. Sorry for typo.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111324
--- Comment #3 from Jiu Fu Guo ---
A patch is posted:
https://gcc.gnu.org/pipermail/gcc-patches/2023-September/629534.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111324
--- Comment #1 from Jiu Fu Guo ---
In match.pd, there is a pattern:
/* Simplify (t * 2) / 2) -> t. */
(for div (trunc_div ceil_div floor_div round_div exact_div)
(simplify
(div (mult:c @0 @1) @1)
(if (ANY_INTEGRAL_TYPE_P (type))
(if (T
nt: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: guojiufu at gcc dot gnu.org
Target Milestone: ---
For case:
-- t.c
typedef unsigned int INT;
INT
foo (INT x, INT y)
{
if (x > 100 || y > 100)
return 0;
return (x * y) / y;
}
-
gcc -O2 t.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111303
--- Comment #4 from Jiu Fu Guo ---
For the pattern: "(X + C) / N", "op (plus@3 @0 INTEGER_CST@1) INTEGER_CST@2)"
where "X" has value-range, and "X + C" does not overflow:
&& get_range_query (cfun)->range_of_expr (vr0, @0))
&& get_range_query (c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111303
--- Comment #3 from Jiu Fu Guo ---
In the pattern of match.pd, there is:
&& range_op_handler (PLUS_EXPR).overflow_free_p (vr0, vr1)
&& get_range_query (cfun)->range_of_expr (vr3, @3)
/* "X+C" and "X" are not of opp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111303
Jiu Fu Guo changed:
What|Removed |Added
Last reconfirmed||2023-09-06
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111303
Jiu Fu Guo changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |guojiufu at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108757
Jiu Fu Guo changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93176
--- Comment #12 from Jiu Fu Guo ---
Thanks a lot for asking!
The patch which handles this is submitted at:
https://gcc.gnu.org/pipermail/gcc-patches/2023-July/623519.html
I would ping this patch again. If ok, I will commit to trunk.
(And the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106460
Jiu Fu Guo changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101853
--- Comment #17 from Jiu Fu Guo ---
> But "nobody" counts that close, so better say "no xtreme-header-* failures
> since r13-5702-g72058eea9d407e".
:) Since these failures occur erratically, so maybe reopen this or open a new
one if the failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100052
--- Comment #15 from Jiu Fu Guo ---
(In reply to seurer from comment #14)
> The failures occur erratically so one clean run doesn't mean much. Scanning
> the test results mailing list I see failures for this just today in trunk.
Yeap, thanks f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101853
--- Comment #14 from Jiu Fu Guo ---
Pass on trunk, gcc-12, gcc-11 for xtreme-header-* cases:
make check-gcc-c++ RUNTESTFLAGS="--target_board=unix'{-m64}'
modules.exp=xtreme-header-*"
=== g++ Summary ===
# of expected passes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100052
--- Comment #13 from Jiu Fu Guo ---
Pass on trunk, gcc-12, gcc-11 for xtreme-header-* cases:
make check-gcc-c++ RUNTESTFLAGS="--target_board=unix'{-m64}'
modules.exp=xtreme-header-*"
=== g++ Summary ===
# of expected passes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108757
--- Comment #24 from Jiu Fu Guo ---
(In reply to Jiu Fu Guo from comment #23)
> /* Simplify ((t + -N*M) / N + M) -> t / N: (t + -C) >> N + (C>>N) ==> t >> N
> */
> (for div (trunc_div exact_div)
div was not used in this matcher, yet. Here rshif
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108757
--- Comment #23 from Jiu Fu Guo ---
/* Simplify ((t + -N*M) / N + M) -> t / N: (t + -C) >> N + (C>>N) ==> t >> N */
(for div (trunc_div exact_div)
(simplify
(plus (rshift (plus @0 INTEGER_CST@1) INTEGER_CST@2) INTEGER_CST@3)
(if (INTEGRAL_T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108757
--- Comment #22 from Jiu Fu Guo ---
(In reply to Andrew Pinski from comment #21)
> (In reply to Jiu Fu Guo from comment #20)
> > Interesting thing:
> > the VR is always VR_VARYING, even for the below simple case:
> >
> > typedef unsigned long I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108757
Jiu Fu Guo changed:
What|Removed |Added
CC||guojiufu at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106708
--- Comment #3 from Jiu Fu Guo ---
With the trunk, for
*arg++ = 0x98765432ULL;
*arg++ = 0x7cdeab55ULL;
are expected.
For *arg++ = 0x6543ULL; lis+xoris are not committed to the trunk
yet.
|--- |FIXED
CC||guojiufu at gcc dot gnu.org
--- Comment #4 from Jiu Fu Guo ---
On the trunk, the output is expected:
li 3,17185
oris 3,3,0x8765
blr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108809
Jiu Fu Guo changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106879
Jiu Fu Guo changed:
What|Removed |Added
CC||guojiufu at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108809
--- Comment #3 from Jiu Fu Guo ---
A similar different view between BE and LE on the vector for vec_xst_len_r.
For:
store_data_uc = (vector unsigned char){ 1, 2, 3, 4, 5, 6, 7, 8,
9, 10, 11, 12, 13,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108809
Jiu Fu Guo changed:
What|Removed |Added
CC||guojiufu at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108722
Jiu Fu Guo changed:
What|Removed |Added
CC||guojiufu at gcc dot gnu.org
--- Comment
ent: target
Assignee: unassigned at gcc dot gnu.org
Reporter: guojiufu at gcc dot gnu.org
Target Milestone: ---
In a mail-list discussion,
https://gcc.gnu.org/pipermail/gcc-patches/2022-December/609054.html, as Segher
points out, we could use 'mtvsrws' for the co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103743
Jiu Fu Guo changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108073
--- Comment #2 from Jiu Fu Guo ---
(In reply to Surya Kumari Jangala from comment #1)
> Hi Jiu Fu Guo, are you working on this bug? If not, I would like to take
> this up.
Thanks for your asking!
I drafted an experimental patch. Welcome for any
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: guojiufu at gcc dot gnu.org
Target Milestone: ---
For the below code:
typedef struct DF {double a[4]; long l; } DF;
double __attribute__ ((noipa)) foo_df (DF arg){return arg.a[3];}
At
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106708
--- Comment #1 from Jiu Fu Guo ---
PR93178 also mentioned the "li,oris" case.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107692
--- Comment #7 from Jiu Fu Guo ---
(In reply to Hongyu Wang from comment #6)
> (In reply to Jiu Fu Guo from comment #4)
> cut...
>
> Yes, I've already posted the patch at
> https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606478.html
On
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107692
--- Comment #5 from Jiu Fu Guo ---
> -munroll-only-small-loops does not turn on or off -funroll-loops, and it
> should not, so that it does what it says, if nothing else.
Yes, and -funroll-loops would win over -munroll-only-small-loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107692
Jiu Fu Guo changed:
What|Removed |Added
CC||guojiufu at gcc dot gnu.org
--- Comment
: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: guojiufu at gcc dot gnu.org
Target Milestone: ---
When building 541.leela_r from spec2017, I encounter one error:
include/c++/13.0.0/bitset: In instantiation of 'void
std::_Base_bitset<_Nw>::_M_do_reset()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106550
Jiu Fu Guo changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106928
--- Comment #3 from Jiu Fu Guo ---
(In reply to Martin Liška from comment #2)
> I think you missed -fno-finite-math-only option as documented here:
> https://www.spec.org/cpu2017/Docs/benchmarks/500.perlbench_r.html#portability
Thanks! It pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106928
--- Comment #1 from Jiu Fu Guo ---
The out.mis file:
3258: # of abstol errors: 0
Minimum abstol: nan
^
3259: Maximum reltol: 0.0e+00
# of abstol errors: 0
^
3260: # of reltol errors: 0
Maximum reltol: 0.
-end
Assignee: unassigned at gcc dot gnu.org
Reporter: guojiufu at gcc dot gnu.org
Target Milestone: ---
With the latest trunk, the 500.perlbench_r (-Ofast) from spec2017 encounter VE
on power9 and power10 on no matter with or without
-fno-unsafe-math-optimizations.
With
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: guojiufu at gcc dot gnu.org
Target Milestone: ---
For code: t.c
void foo (long *arg)
{
*arg++ = 0x98765432ULL;
*arg++ = 0x7cdeab55ULL;
*arg++ = 0x6543ULL;
}
gcc -O2 -S t.c
lis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106550
--- Comment #2 from Jiu Fu Guo ---
(In reply to Kewen Lin from comment #1)
> Confirmed.
>
> Clang supports it as:
>
> https://godbolt.org/z/Kxj584sfd
Thanks Kewen!
Or another example code could be:
pli 9,101736451 (0x6106003)
sldi 9,9,32
pa
Assignee: unassigned at gcc dot gnu.org
Reporter: guojiufu at gcc dot gnu.org
Target Milestone: ---
There is 'pli' which supports a 34bits immediate, so to generate a 64bits
constant we just need 3 instructions at most.
void
foo (unsigned long long
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106460
--- Comment #1 from Jiu Fu Guo ---
The ice occur when output rtx "(high:DI (symbol_ref:DI ("var_48")..))) to
constant pool.
This rtx is generated at function "recog_for_combine"(in combine.cc) after
invoking "force_const_mem".
This kind of rtx
1 - 100 of 275 matches
Mail list logo
