On 06/05/2017 06:28 AM, Jakub Jelinek wrote:
So unless cxx_dup_lang_specific_decl or copy_decl or tsubst_decl
clears the DECL_DECOMP_BASE for the short time before cp_finish_decomp
is called, DECL_DECOMP_BASE will be "wrong" for a short time, but it
shouldn't matter, nothing should be querying i
On Wed, May 31, 2017 at 01:16:36PM -0400, Nathan Sidwell wrote:
> On 05/31/2017 01:05 PM, Jakub Jelinek wrote:
>
> > That is weird, that sounds like a bug somewhere? Which testcase is it on?
>
> I think decomp25 & decomp7 & 8 (sorry, can't recall full name).
> I discovered them because my first
On Wed, May 31, 2017 at 01:16:36PM -0400, Nathan Sidwell wrote:
> On 05/31/2017 01:05 PM, Jakub Jelinek wrote:
>
> > That is weird, that sounds like a bug somewhere? Which testcase is it on?
>
> I think decomp25 & decomp7 & 8 (sorry, can't recall full name).
> I discovered them because my first
On 05/31/2017 01:05 PM, Jakub Jelinek wrote:
That is weird, that sounds like a bug somewhere? Which testcase is it on?
I think decomp25 & decomp7 & 8 (sorry, can't recall full name).
I discovered them because my first attempt had an assert that the
incoming base was the same as the stored on
On Wed, May 31, 2017 at 12:54:24PM -0400, Nathan Sidwell wrote:
> This patch reworks how decl_decomposition is marked. With the new
> lang_decl_decomp struct, the selector grew another used but -- which
> affected me on the modules branch. however, we can use that use selector
> value in place of
This patch reworks how decl_decomposition is marked. With the new
lang_decl_decomp struct, the selector grew another used but -- which
affected me on the modules branch. however, we can use that use
selector value in place of the decompostion_p bitfield.
This patch makes that change, but it
