On September 3, 2020 7:59:12 PM GMT+02:00, Gary Oblock <g...@amperecomputing.com> wrote: >>This is absolutely not enough information to guess at the >>issue ;) > >That's fair, I was hoping some mad genius out there would confess to a >fubar_adjustment phase that was probably at fault. 😉
Ah, well. It's probably your own code that is at fault ;) >>I suggest you break at the return stmt of make_ssa_name_fn >>looking for t->base.u.version == 101 to see where and with >>which type _101 is created, from there watch *&t->typed.type >>in case something adjusts the type. > >I did the former but I used ssa_name_nodes_created >instead. Which though harder to get at, is unique. >Regarding the later... I guess... But, at various times (on certain >OS versions of certain machines) watch points have been >at bit dubious. I assume on a recent Ubuntu release >on an Intel I7 core this wouldn't be the case??? I never had an issue with watch points. Richard. >Thanks, > >Gary >________________________________ >From: Richard Biener <richard.guent...@gmail.com> >Sent: Wednesday, September 2, 2020 11:31 PM >To: Gary Oblock <g...@amperecomputing.com> >Cc: gcc@gcc.gnu.org <gcc@gcc.gnu.org> >Subject: Re: Types are confused in inlining > >[EXTERNAL EMAIL NOTICE: This email originated from an external sender. >Please be mindful of safe email handling and proprietary information >protection practices.] > > >On Wed, Sep 2, 2020 at 10:19 PM Gary Oblock via Gcc <gcc@gcc.gnu.org> >wrote: >> >> I'm not accusing inlining of having problems but I really >> need to understand what's going on in this situation so I can >> fix my optimization. >> >> The error given is: >> main.c: In function ‘main’: >> main.c:5:1: error: non-trivial conversion in ‘ssa_name’ >> 5 | main(void) >> | ^ >> struct type_t * >> unsigned long >> _101 = dedangled_97; >> during GIMPLE pass: fixup_cfg >> etc. >> etc. >> >> I put a conditional breakpoint in gdb where both >> _101 and dedangled_97 were created and low >> and behold they were both set to "unsigned long". >> Does anybody have a clue as to how "_101" got >> changed from "unsigned long" to "struct type_t *"? >> Note, the later is a meaningful type in my program. >> I'm trying to replace all instances of the former as >> part of structure reorganization optimization.) I should >> mention that this GIMPLE stmt is the one that moves >> the value computed in an inlined function into the body >> of code where the inling took place. > >This is absolutely not enough information to guess at the >issue ;) > >I suggest you break at the return stmt of make_ssa_name_fn >looking for t->base.u.version == 101 to see where and with >which type _101 is created, from there watch *&t->typed.type >in case something adjusts the type. > >> Thanks, >> >> Gary Oblock >> >> >> >> >> >> CONFIDENTIALITY NOTICE: This e-mail message, including any >attachments, is for the sole use of the intended recipient(s) and >contains information that is confidential and proprietary to Ampere >Computing or its subsidiaries. It is to be used solely for the purpose >of furthering the parties' business relationship. Any unauthorized >review, copying, or distribution of this email (or any attachments >thereto) is strictly prohibited. If you are not the intended recipient, >please contact the sender immediately and permanently delete the >original and any copies of this email and any attachments thereto.
