Bug 2213753
| Summary: | internal compler error: output_operand: '%&' used without any local dynamic TLS references | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Jan Horak <jhorak> | ||||
| Component: | gcc | Assignee: | Marek Polacek <mpolacek> | ||||
| gcc sub component: | system-version | QA Contact: | Václav Kadlčík <vkadlcik> | ||||
| Status: | CLOSED ERRATA | Docs Contact: | |||||
| Severity: | unspecified | ||||||
| Priority: | unspecified | CC: | ahajkova, fweimer, jakub, ohudlick, sipoyare, vkadlcik | ||||
| Version: | 8.8 | Keywords: | Bugfix, Triaged, ZStream | ||||
| Target Milestone: | rc | Flags: | pm-rhel:
mirror+
|
||||
| Target Release: | --- | ||||||
| Hardware: | ppc64le | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | gcc-8.5.0-20.el8 | Doc Type: | No Doc Update | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | |||||||
| : | 2233565 2233566 2233567 2233568 2233569 (view as bug list) | Environment: | |||||
| Last Closed: | 2023-11-14 15:48:38 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Bug Depends On: | |||||||
| Bug Blocks: | 2233565, 2233566, 2233567, 2233568, 2233569 | ||||||
| Attachments: |
|
||||||
|
Description
Jan Horak
2023-06-09 07:39:23 UTC
Reduced testcase -O2 -fpic:
struct A { ~A (); };
static thread_local int *t;
int a;
A::~A () { t = &a; }
long b;
void *
foo ()
{
void *c;
if (t)
{
c = operator new (b);
return c;
}
void *d = operator new (b);
return d;
}
The bug went away with https://gcc.gnu.org/r9-4463 , but guess that isn't easily backportable.
The problem is that for some strange reason we aren't able to figure out that the test of the TLS var is useless during GIMPLE passes
(but can't figure it out even when replacing static thread_local with nothing), so it is only RTL optimizations that find out
that it is the same thing. But the old PowerPC way of doing TLSLD is clearly unable to cope with all TLSLD references in a function
that during expansion had some disappearing.
If you want a workaround, I see in MemPool:
class MemoryPool {
public:
static std::unique_ptr<MemoryPool> Make(size_t, size_t) {
return std::make_unique<MemoryPool>();
}
void resetScratchSpace() {}
void reportLeaks() const {}
bool isEmpty() const { return true; }
void* allocate(size_t size) { return ::operator new(size); }
void release(void* p) { ::operator delete(p); }
};
and then
void* Pool::AllocMemory(size_t size) {
MemoryPool* memPool = get_thread_local_memory_pool();
if (memPool) {
void* ptr = memPool->allocate(size);
;
return ptr;
}
void* ptr = ::operator new(size);
;
return ptr;
}
in the preprocessed source. If memPool->allocate will always just do ::operator new,
what is the point of the messing up with get_thread_local_memory_pool?
So, you could in both Pool::AllocMemory and Pool::FreeMemory wrap around the memPool related stuff with
#if SK_SUPPORT_GPU
or whatever guards in SkSLMemoryPool.h the implementation that actually does something from the dummy
one that only uses the system allocator.
Perhaps a fix could be try harder in get_some_local_dynamic_name, if we don't find any TLSLD references in the current function, return any other TLSLD symbol in the current TU. get_some_local_dynamic_name is used only by a couple of targets, so add some global variable next to some_local_dynamic_name (say cu_local_dynamic_name) and set that variable when emitting TLSLD sequences in the backend. Or instead search the varpool for TLS vars with TLSLD model. Or yet another option would be in all the instructions which use %& in the rs6000 backend call get_some_local_dynamic_name () during output and use the template with %& only if it returned non-zero, otherwise use some dummy instruction with the same size - if we don't have any TLSLD instructions left, the value that the instruction sets doesn't really matter. Workaround only tested on the above reduced testcase (which should go into the testsuite too):
--- gcc/final.c.jj 2023-06-09 10:56:10.224167367 +0200
+++ gcc/final.c 2023-06-14 14:10:04.634242884 +0200
@@ -1620,6 +1620,22 @@ get_some_local_dynamic_name ()
}
}
+ /* If all the TLSLD references from current function were DCEd, try harder and pick
+ name of any TLSLD symbol in current TU. */
+ varpool_node *node;
+ FOR_EACH_VARIABLE (node)
+ if (DECL_THREAD_LOCAL_P (node->decl)
+ && TREE_STATIC (node->decl)
+ && decl_tls_model (node->decl) == TLS_MODEL_LOCAL_DYNAMIC
+ && DECL_RTL_SET_P (node->decl))
+ {
+ rtx rtl = DECL_RTL (node->decl);
+ if (MEM_P (rtl)
+ && GET_CODE (XEXP (rtl, 0)) == SYMBOL_REF
+ && SYMBOL_REF_TLS_MODEL (XEXP (rtl, 0)) == TLS_MODEL_LOCAL_DYNAMIC)
+ return some_local_dynamic_name = XSTR (XEXP (rtl, 0), 0);
+ }
+
return 0;
}
Or perhaps better
--- gcc/final.c.jj 2023-06-09 10:56:10.224167367 +0200
+++ gcc/final.c 2023-06-14 14:10:04.634242884 +0200
@@ -1620,6 +1620,23 @@ get_some_local_dynamic_name ()
}
}
+ /* If all the TLSLD references from current function were DCEd, try harder and pick
+ name of any TLSLD symbol in current TU. */
+ varpool_node *node;
+ if (!this_is_asm_operands)
+ FOR_EACH_VARIABLE (node)
+ if (DECL_THREAD_LOCAL_P (node->decl)
+ && TREE_STATIC (node->decl)
+ && decl_tls_model (node->decl) == TLS_MODEL_LOCAL_DYNAMIC
+ && DECL_RTL_SET_P (node->decl))
+ {
+ rtx rtl = DECL_RTL (node->decl);
+ if (MEM_P (rtl)
+ && GET_CODE (XEXP (rtl, 0)) == SYMBOL_REF
+ && SYMBOL_REF_TLS_MODEL (XEXP (rtl, 0)) == TLS_MODEL_LOCAL_DYNAMIC)
+ return XSTR (XEXP (rtl, 0), 0);
+ }
+
return 0;
}
i.e. don't cache these extra efforts and use them only outside of inline asm, so that we don't change behavior of inline asm.
# rpm -q gcc gcc-8.5.0-19.el8.ppc64le # g++ -c bz.C -O2 -fpic during RTL pass: final bz.C: In function ‘void* foo()’: bz.C:18:1: internal compiler error: output_operand: '%&' used without any local dynamic TLS references } ^ # rpm -q gcc gcc-8.5.0-20.el8.ppc64le # g++ -c bz.C -O2 -fpic # OK We also need this fix for the RHEL 8.1, 8.2, 8.4 - that's where we need to rebase the Firefox. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (gcc bug fix and enhancement update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2023:7099 |