The only problematic one seems to be standard_libexec_prefix, because that is used in line 3654 of gcc/gcc.c in a real assignment.
It is also used in line 64 of gcc/gcc-ar.c.
Other uses of all these other symbols could be calculated as compile time realitve paths, and if we can live with these paths staying in the same store directory, then it would be ok.
This problematic use pattern is in the from:
x=make_relative_prefix(y,standard_exec_prefix,standard_libexec_prefix);
if(!x) x=standard_libexec_prefix;
Code of make_relative_prefix is in libiberty/make-relative-prefix.c.
Assuming sane values (not nulls, existing program name, valid GCC_EXEC_PREFIX) we get null in the following cases:
1. GCC_EXEC_PREFIX(or the program name directory component)==standard_exec_prefix
2. if the path present in standard_exec_prefix and standard_libexec_prefix has no common directories(starting from the beginning)
3. in case of allocation failure.
We can safely assume that case 2 does not happen, as we at least have /gnu/store there, I think.
Nothing can be done about case 3, I don't think we get too far in that case anyway...
So, when this happens we simply have case 1: we are not relocated.
In gcc/gcc.c this pattern is guarded by if(gcc_exec_prefix) basically.(it is in an else block)
It is not so in gcc/gcc-ar.c.
This is how far I could get with it by now.