This is the mail archive of the
mailing list for the GCC project.
Re: [lto] set LANG_HOOKS_REDUCE_BIT_FIELD_OPERATIONS
- From: "Richard Guenther" <richard dot guenther at gmail dot com>
- To: "Paolo Bonzini" <bonzini at gnu dot org>
- Cc: "Mark Mitchell" <mark at codesourcery dot com>, gcc-patches at gcc dot gnu dot org, "Richard Guenther" <rguenther at suse dot de>, "Nathan Froyd" <froydnj at codesourcery dot com>
- Date: Fri, 14 Dec 2007 23:18:20 +0100
- Subject: Re: [lto] set LANG_HOOKS_REDUCE_BIT_FIELD_OPERATIONS
- References: <20071213183309.GO11065@codesourcery.com> <firstname.lastname@example.org> <4762B371.email@example.com>
On Dec 14, 2007 5:46 PM, Paolo Bonzini <firstname.lastname@example.org> wrote:
> Paolo Bonzini wrote:
> > Nathan Froyd wrote:
> >> Reason #4829 why langhooks should die. The comment is at Kenny's
> >> request and is somewhat milder than Kenny's suggestion.
> >> Fixes a number of bitfield-related tests in the testsuite.
> > I have a 4.4-pending patch which "the right way to do this": removing
> > the langhook. I'll update it and submit it so that you can include it
> > in LTO.
> Here is the patch (which was actually 4.3-pending too, but I had no time
> to submit it earlier than stage3 :-P). The way it work is simply by
> turning the langhook into a type flag, so that C creates types with the
> flag set to true and C++ creates types with the flag set to false.
> I modified every place which sets TYPE_PRECISION to set or copy over the
> new flag.
> The middle-end has one type with small TYPE_PRECISION, namely
> boolean_type_node. In this patch I was more conservative than necessary
Ha! This at least hints at ...
> (hopefully), so in C++ I mark it as !TYPE_REDUCE_BIT_FIELD_OPERATIONS.
> Since I don't know if it is a problem for LTO, I left it in; but if it
> *is* a problem, you might try removing it altogether since I think this
> special treatment is not necessary.
> Then there is also the problem of the PR that Richard pointed out. I
> don't know if this patch can ease solving that PR, but it cannot make it
> worse. :-)
... what maybe breaks libjava. The C++ boolean type indeed has a
precision of 1.
I guess for 4.4 we need to figure out if we need the distinction at all.