Hi! Now, that was another quirky debug session: in 'gcc/omp-low.cc:create_omp_child_function' we clearly do set 'TREE_USED (t) = 1;' for '.omp_data_i', which ends up as formal parameter for outlined '[...]._omp_fn.[...]' functions, pointing to the "OMP blob". Yet, in offloading compilation, I only ever got '!TREE_USED' for the formal parameter '.omp_data_i'. This greatly disturbs a nvptx back end expand-time transformation that I have implemented, that's active 'if (!TREE_USED ([formal parameter]))'. After checking along all the host-side OMP handling, eventually (in hindsight: "obvious"...) I found that, "simply", we're not streaming 'TREE_USED'! With that changed (see attached "Re-introduce 'TREE_USED' in tree streaming"; no visible changes in x86_64-pc-linux-gnu and powerpc64le-unknown-linux-gnu 'make check'), my issue was quickly addressed -- if not for the question *why* 'TREE_USED' isn't streamed (..., and apparently, that's a problem only for my case..?), and then I found that it's *intentionally been removed* in one-decade-old commit ee03e71d472a3f73cbc1a132a284309f36565972 (Subversion r200151) "Re-write LTO type merging again, do tree merging". At this point, I need help: is this OK to re-introduce unconditionally, or in some conditionalized form (but, "ugh..."), or be done differently altogether in the nvptx back end (is 'TREE_USED' considered "stale" at some point in the compilation pipeline?), or do we need some logic in tree stream read-in (?) to achieve the same thing that removing 'TREE_USED' streaming apparently did achieve, or yet something else? Indeed, from a quick look, most use of 'TREE_USED' seems to be "early", but I saw no reason that it couldn't be used "late", either? Original discussion "not streaming and comparing TREE_USED": "[RFC] Re-write LTO type merging again, do tree merging", continued "Re-write LTO type merging again, do tree merging". In 2013, offloading compilation was just around the corner -- "Summary of the Accelerator BOF at Cauldron" -- and you easily could've foreseen this issue, no? ;-P Grüße Thomas ----------------- Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955