[1/3] Change 'v1' float and int code to fall back to v0

  While working on another patch, I discovered that the libcc1 plugin
code never did version negotiation correctly.  So, the patches to
introduce v1 never did anything -- the new code, as far as I know, has
never been run.

Making version negotiation work shows that the existing code causes
crashes.  For example, safe_lookup_builtin_type might return
error_mark_node in some cases, which the callers aren't prepared to
accept.

Looking into it some more, I couldn't find any justification for this
v1 code for the C compiler plugin.  Since it's not run at all, it's
also clear that removing it doesn't cause any regressions in gdb.

However, rather than remove it, this patch changes it to handle
ERROR_MARK better, and then to fall back to the v0 code if the new
code fails to find the type it's looking for.

2024-02-26  Tom Tromey  <tom@tromey.com>

	* libcc1plugin.cc (safe_lookup_builtin_type): Handle ERROR_MARK.
	(plugin_int_type): Fall back to plugin_int_type_v0.
	(plugin_float_type): Fall back to plugin_float_type_v0.
---
 libcc1/ChangeLog       |  6 ++++++
 libcc1/libcc1plugin.cc | 19 ++++++++++---------
 2 files changed, 16 insertions(+), 9 deletions(-)
  

On 2/26/24 20:12, Tom Tromey wrote:
> While working on another patch, I discovered that the libcc1 plugin
> code never did version negotiation correctly.  So, the patches to
> introduce v1 never did anything -- the new code, as far as I know, has
> never been run.
> 
> Making version negotiation work shows that the existing code causes
> crashes.  For example, safe_lookup_builtin_type might return
> error_mark_node in some cases, which the callers aren't prepared to
> accept.
> 
> Looking into it some more, I couldn't find any justification for this
> v1 code for the C compiler plugin.  Since it's not run at all, it's
> also clear that removing it doesn't cause any regressions in gdb.
> 
> However, rather than remove it, this patch changes it to handle
> ERROR_MARK better, and then to fall back to the v0 code if the new
> code fails to find the type it's looking for.
> 
> 2024-02-26  Tom Tromey  <tom@tromey.com>
> 
> 	* libcc1plugin.cc (safe_lookup_builtin_type): Handle ERROR_MARK.
> 	(plugin_int_type): Fall back to plugin_int_type_v0.
> 	(plugin_float_type): Fall back to plugin_float_type_v0.
Given this is all libcc1 related and thus primarily of interest to gdb, 
if you're happy with it, then it's OK for the trunk.

jeff
  

>>>>> "Jeff" == Jeff Law <jeffreyalaw@gmail.com> writes:

Jeff> Given this is all libcc1 related and thus primarily of interest to
Jeff> gdb, if you're happy with it, then it's OK for the trunk.

Thank you.

I could not push this because:

remote: *** ChangeLog format failed:
remote: *** ERR: invalid PR component in subject: "Fix PR libcc1/113977"

I guess this script isn't in sync with the components in bugzilla.

I don't know how to fix this.

Tom
  

On 2/28/24 15:57, Tom Tromey wrote:
>>>>>> "Jeff" == Jeff Law <jeffreyalaw@gmail.com> writes:

> I could not push this because:
> 
> remote: *** ChangeLog format failed:
> remote: *** ERR: invalid PR component in subject: "Fix PR libcc1/113977"
> 
> I guess this script isn't in sync with the components in bugzilla.
> 
> I don't know how to fix this.
Me neither, but I can suggest a hacky workaround.  Change the component 
in bugzilla to something the pre-commit hooks understand, push the fix, 
then change the component back a little while later and adjust the 
ChangeLog after it gets generated overnight.  Ugly as sin.

jeff
  

On Wed, Feb 28, 2024 at 3:26 PM Jeff Law <jeffreyalaw@gmail.com> wrote:
>
>
>
> On 2/28/24 15:57, Tom Tromey wrote:
> >>>>>> "Jeff" == Jeff Law <jeffreyalaw@gmail.com> writes:
>
> > I could not push this because:
> >
> > remote: *** ChangeLog format failed:
> > remote: *** ERR: invalid PR component in subject: "Fix PR libcc1/113977"
> >
> > I guess this script isn't in sync with the components in bugzilla.
> >
> > I don't know how to fix this.
> Me neither, but I can suggest a hacky workaround.  Change the component
> in bugzilla to something the pre-commit hooks understand, push the fix,
> then change the component back a little while later and adjust the
> ChangeLog after it gets generated overnight.  Ugly as sin.

I don't know how to update the script server side after it is
committed in git. the checker script is located in git though:
```
[apinski@xeond2 contrib]$ git diff gcc-changelog/git_commit.py
diff --git a/contrib/gcc-changelog/git_commit.py
b/contrib/gcc-changelog/git_commit.py
index 87bec4e00f5..4a3720de7fb 100755
--- a/contrib/gcc-changelog/git_commit.py
+++ b/contrib/gcc-changelog/git_commit.py
@@ -109,6 +109,7 @@ bug_components = {
     'libffi',
     'libfortran',
     'libgcc',
+    'libcc1',
     'libgcj',
     'libgomp',
     'libitm',
```

Thanks,
Andrew Pinski

>
> jeff
  

>>>>> "Andrew" == Andrew Pinski <pinskia@gmail.com> writes:

Andrew> I don't know how to update the script server side after it is
Andrew> committed in git. the checker script is located in git though:

Thanks, I didn't realize it was there.

Could you check in your patch?
IMO it seems obvious.

Tom
  

On Wed, Feb 28, 2024 at 5:35 PM Tom Tromey <tom@tromey.com> wrote:
>
> >>>>> "Andrew" == Andrew Pinski <pinskia@gmail.com> writes:
>
> Andrew> I don't know how to update the script server side after it is
> Andrew> committed in git. the checker script is located in git though:
>
> Thanks, I didn't realize it was there.
>
> Could you check in your patch?
> IMO it seems obvious.

Pushed as r14-9230-g5ff49272bf4eb6
(https://gcc.gnu.org/pipermail/gcc-patches/2024-February/646819.html).
I noticed there should be other cleanup of the bug components there
too but I will leave that for another time.

Thanks,
Andrew Pinski

>
> Tom
  

>>>>> "Jeff" == Jeff Law <jeffreyalaw@gmail.com> writes:

>> I don't know how to fix this.

Jeff> Me neither, but I can suggest a hacky workaround.

FTR, I asked Jakub on irc and he fixed it, so thankfully I didn't have
to resort to the hack :-)

thanks,
Tom