With 4.9 this does not compile, since reinterpret_cast is not a const expression according to standard. So all I can do is use a static const member with out-of-class initialization (ie. runtime initialization etc.). Is there any extension in place in this compiler port that could make the old code work again? I basically only want to map registers to references in a C++-way. I am totally aware that this is platform dependent, but the addresses are anyways so I don't see why one shouldn't be able to do this.

Hello,
thank you for trying, I'm currently confused why this works for you. I'm currently thinking that because "value" is not referenced, the constexpr expression is not evaluated?
Can you give "reference<int, 0x1000000>::value = 5;" or "auto& ref = reference<int, 0x1000000000>::value;" a try? The standard really forbids reinterpret_cast in constexpr expressions (I learned it the hard way), but 4.8 allowed it and with 4.9 I didn't see any way anymore. I downloaded the latest stable version from the main page.

I admit I may be missing something. What is wrong with a templated function? I can see how the templated structure might be convenient if it could be statically initialized. I wasn't successful in doing so. The following templated function works OK for me. Also know that I'm doing the same thing you are in defining structures to access register files.

Hello Marc,
thank you for hopping in! What I'm trying to do is giving a named reference a compile time static target address. I'm trying to avoid macros where possible. The way you suggest is in my eyes pretty close to the reinterpret_cast/C-Cast-Macros from the vendors. The thing is we must do a (runtime-)call at the place of access and rely on the optimizer to figure it out, since we cannot do the cast at compile-time.

From then on I can use "some_register" as a short identifier that respects namespaces and everything (actually it will be more like a struct for multiple registers). So right now I have the option to stick with 4.8 or accomplish it with custom symbol tables for the linker (since I started to auto-generate the headers from a register meta-file, the latter will actually not be sooo super bad). But since this port of the compiler is targetted at a microcontroller and hardware access is bread&butter I thought there may be extensions in place that could make it possible to achieve this within the language.

I've been thinking more about this as well. I agree that the function template is more like the macro than we'd like. As a constexpr, it should avoid a runtime penalty. As I wrote before, I checked (some) of the assembler output and found that it was doing what we'd hope with a simple address load from the constant pool.

That said, I'd like what you are talking about and then some. I'd really like to be able to write:

using SATA = iostruct<SATA_STRUCT,0xa0010000>;
...
SATA::p.config = 10; // Of course, I'd like to be able to drop the ::p and use SATA.config
...
using UARTx = iostruct<UART_STRUCT>;
using UART1 = UARTx<0xa0020000>;
...

I'm currently using a macro to bridge the gap which satisfies the code readability, but isn't as C++ as I'd like.

The form you are using makes me think it may allocate RAM for each register to hold some_register. Have you verified that there is no RAM/ROM impact per instance?

A value of any integral or enumeration type can be converted to a pointer type. A pointer converted to an integer of sufficient size and back to the same pointer type is guaranteed to have its original value, otherwise the resulting pointer cannot be dereferenced safely. The null pointer constant NULL or integer zero is not guaranteed to yield the null pointer value of the target type; static_cast or implicit conversion should be used for this purpose.

So, I'm inclined to believe this is a bug.

FWIW, I spent some time attempting to coerce [sic] the behavior we're looking for without any luck.

Well, you're right, I'm still relying on the optimizer to optimize away the store for the reference (although that is not so improbable), but since I specify internal linkage, the compiler has all rights to eliminate it in my eyes, as it does with function-local alias-references.
I cannot quote from the standard, but the definition of constexpr actively and namely excludes reinterpret_cast in valid constexpr expressions.

The only solution that is supported by standard would be to declare the symbols "extern "C" register_type myregister;" and let the linker supply placement through symbol files "-Wl symbols.sym". symbols.sym then contains many "myregister = 0xFooFoo;".

The compiler output is identical for both p1 and p2 with the 4.8 compiler.

Unfortunately, the 4.9 compiler creates a static datum for the p2 form. Darn it. my hunch is that t would do the same for the p1 form if were willing to accept it. IMHO, the creating of a static datum makes the static object unusable.

Yes indeed, since the 4.9 compiler rejects thinking that a reinterpret_cast can be a constant expression (following the standard, which I think is too strict in this point) there seems to be no "constant propagation" or how one could call that... It's a shame really.