>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. 😉
>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??? 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.
