ld.exe:linker_script.ld:138 cannot move location counter backwards | ArduinoFFT Error
Short Version
The short answer is that you've exhausted RAM.
These two arrays alone:
const uint16_t samples = 16128;
double vImag[samples] = {0};
double double_buffer[16384] = {};

...are occupying (16128 + 16384) * 8 == 260096 bytes of memory.  There's only 262144 bytes of RAM in entirety.
The way the linker script is set up at least 1024 bytes are reserved for the stack, and there is no doubt at least another kByte in use somewhere.  In the Mbed OS and Arduino core files if nothing else.
As for why it fails only when you call Compute, that comes down to the compiler optimizer discovering that one (perhaps both) of your arrays are not actually used and so not entering into the mix when the linker is run.
Details
In theory, you should have gotten a somewhat nicer and easier to understand message from an ASSERT in the linker script:
ASSERT(. &lt;= (ORIGIN(RAM) + LENGTH(RAM) - 1024), &quot;heap region overflowed into stack&quot;);

So, you should have seen an error &quot;heap region overflowed into stack&quot; on your screen instead, which is maybe not the easiest thing for an Arduino user to decipher, but heap and stack are terms likely to be recognizable as memory-related sooner or later.
However, the linker executable shipped with the current version 1.3.2 of the Arduino core for Mbed ignores ASSERT statements completely; I have tested this (and tested my understanding of my test using an amd64 linker).  Presumably, there's a build option for the linker or a command-line or configuration file option that controls that, but I haven't found it yet.  In any case, it ignores a helpful ASSERT and instead proceeds to fail on line 138 mentioned in the error message:
 . = ORIGIN(RAM) + LENGTH(RAM) - 1024;

You can see it involves the same expression, just without a useful message if something goes wrong.  The &quot;location counter&quot; in the message is a linker related term that roughly means &quot;where the next thing will be placed in memory&quot; as it cobbles together your final executable from separately compiled chunks.  You've used so much RAM in your program that the location counter has been pushed past where the linker script wants to place the __HeapLimit symbol, 1K from the end of the MCU's RAM.  The location counter is supposed to increase monotonically.  So, evaluating this expression results in an erroneous attempt to &quot;move location counter backwards&quot;.