Artificial front-end variables?

[Tobias Schlüter <tobias dot schlueter at physik dot uni-muenchen dot de>]

I've been looking at PR12366, which looks something like this:
   b = a( (/ 1, 2, 3, 4 /) )
where b and a are arrays. The problem seemingly is that the code 
generators expect a variable for a vector subscript. It seemed to me 
that the easiest cure would be to introduce an artificial variable, and 
change the code to
   t = (/ 1, 2, 3, 4 /)
   b = a(t)
with t the artificial variable, of course. I verified that this compiles 
correctly when generated manually.

I thought about adding this feature to the compiler, it seems easy 
enough. All that is necessary appears to be
1) a new attribute "artificial" for gfc_symbol's & functions to generate 
them with unique names
2) a modification to trans-decl which marks declarations as artificial, 
if attr.artificial is set

I was wondering if you think that something like this would be useful.

Other applications that I can think of are in the scalarizer (I don't 
understand at all how our scalarizer works, but I'm wondering if it 
couldn't be modified to create gfc_code structures once artificial 
symbols were available), and nested array operations like c = 
matmul(a,matmul(a,b)) -> t = matmul(a,b); c = matmul(a,t) which should 
cure our issues with being "unable to find scalarization loop", and 
maybe others.

Thoughts?

- Tobi