Question: Why can't we declare an array of 10000000 integers (or say, large enough) inside the main function or inside any function locally while it is possible globally?

Answer: 
**tl;dr:** space for local variables is limited. That's how CPU's and Operating Systems work. 

---

This is an implementation detail that is shared by many languages and implementations, e.g. C, C++ on typical desktop OS.

Most platforms where the code runs on set aside some memory called the *Stack* to be used for return adresses and local storage. This is just a detail of how the CPU (Intel, AMD, etc.) execute machine code. 

Allocation from the stack is very fast, but the memory is valid only until the function call returns. This makes it ideal for C/C++ local variables. 

However, stack space is limited, so a large allocation will fail with a 
*Stack Overflow* - even if there's still enough memory "elsewhere". 

Memory for global variables is allocated when the program starts. E.g. the executable would indicate "I need so much space filled with zeroes, and I need so much space for data, and so much space for code." 

The "third" memory location is the *Heap*: it is used for memory allocated with `malloc` / `new` etc. Allocation on the heap are more expensive than on the stack (and have more problems to cope with), and they stay around until you free them, which is both good and a burden. 

---

Some side notes, intentionally left out because it's not directly relevant for the question: 

The Stack is just a range of (contiguos) memory, where you can allocate and free memory only from the top. This makes it limited, convenient and fast. 

On modern desktop systems, 32 bit processes usually don't run out of memory anymore, but out of address space: there's still physical memory available, but all available possible adresses in a 32 bit word are used up. 

Each thread of execution gets its own stack, whereas global variables and the heap are shared between all threads of a process. 

---

Why don't compilers move large allocations elsewhere? 

First, "it has always been this way". A lot of existing code may subtly depend on the old behavior, and "improving" the compiler might break this code. 

Second, for various reasons, the only generally suitable "elsewhere" is the heap. The performance difference between stack and heap allocations is significant: 

* heap allocation is more expensive
* heap is shared so access to the heap from multiple threads must be synchronized which can be very costly.
* the top of the stack is almost always in the CPU's cache (because that adress range is accessed very frequently). The heap is more likely not

Most of the time, these details don't matter, but for some operations, this difference is significant. If the compiler would decide to put some allocations on the heap, we would lose predictability.
(edit: global variables don't typically go in the heap)

It's likely due to the difference between available **stack** memory and total memory. Local variables get placed on the stack, whereas global variables get placed in a statically allocated section of memory. The following is a more general question that has a good answer that gives an overview of program memory allocation:

[Global memory management in C++ in stack or heap?](https://stackoverflow.com/questions/1169858/global-memory-management-in-c-in-stack-or-heap)