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/
> >
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114786
Jiu Fu Guo changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRMED
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
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
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
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
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.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 */
> }
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112525
Bug ID: 112525
Summary: fail to eliminate unused store
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111971
Bug ID: 111971
Summary: ICE: maximum number of generated reload insns per insn
achieved (90)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity:
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94395
Jiu Fu Guo changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94393
Jiu Fu Guo changed:
What|Removed |Added
Resolution|--- |FIXED
CC|
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
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111597
Bug ID: 111597
Summary: pattern "(T)(A)+cst -->(T)(A+cst)" cause suboptimal
for ppc64
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
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
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"
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111324
Bug ID: 111324
Summary: More optimization about "(X * Y) / Y"
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
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
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
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
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
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
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
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
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93178
Jiu Fu Guo changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108338
Bug ID: 108338
Summary: use mtvsrws for lowpart DI->SF conversion on P9
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108073
Bug ID: 108073
Summary: [rs6000] sub-optimal float member accessing on struct
parameter
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107037
Bug ID: 107037
Summary: 541.leela_r compiling fail since r13-2779
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
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:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106928
Bug ID: 106928
Summary: 500.perlbench_r fail(VE) since r13-1933
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106708
Bug ID: 106708
Summary: [rs6000] 64bit constant generation with oris xoris
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106550
Bug ID: 106550
Summary: [rs6000] sub-optimal constant generation
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106460
Bug ID: 106460
Summary: internal compiler error: output_operand: invalid
expression as operand on -O1
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103743
--- Comment #6 from Jiu Fu Guo ---
Drafted a patch:
https://gcc.gnu.org/pipermail/gcc-patches/2022-May/594702.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101168
Jiu Fu Guo changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105418
Jiu Fu Guo changed:
What|Removed |Added
Resolution|--- |INVALID
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105418
--- Comment #6 from Jiu Fu Guo ---
(In reply to Jiu Fu Guo from comment #5)
...
> This issue happens when calling debug_tree/decl_as_string manually inside
> FE. At where overloaded functions (::new) are not resolved yet, and then
> cause
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105418
--- Comment #5 from Jiu Fu Guo ---
0x1089f887 dump_substitution
/home/guojiufu/gcc/gcc-mainline-base/gcc/cp/error.cc:1654
0x108a1c2f dump_function_decl
/home/guojiufu/gcc/gcc-mainline-base/gcc/cp/error.cc:1817
0x1089e187
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105418
Jiu Fu Guo changed:
What|Removed |Added
Priority|P3 |P5
--- Comment #1 from Jiu Fu Guo ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105418
Bug ID: 105418
Summary: debug_tree does not support well for std::construct_at
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105322
Jiu Fu Guo changed:
What|Removed |Added
CC||guojiufu at gcc dot gnu.org
--- Comment
1 - 100 of 210 matches
Mail list logo