https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43745
--- Comment #13 from Georg-Johann Lay <gjl at gcc dot gnu.org> --- (In reply to Matthijs Kooijman from comment #12) > Apologies if this is an obvious question, but I'm not familiar with gcc/g++ > internals. Georg-Johann, you say this requires address space support in c++, > but I'm not sure I follow you there. Two things: > You say WG21 will never add AS support to C++, but also say that language > support for AS is not needed, only internal support in gcc/g++. So that > means what WG21 does is not relevant for vtable handling in particular? Front-end maintainers usually follow the WGs in what they implement and are willing to approve. When you propose some non-standard extensions — even as a working patch with testcases, documentation, etc. — the maintainers will reject it. They fear it might be inconsistent with existing features or the code "just being dropped" and maintenance burden is up to them. Adding AS in the c++ front-end without exposing them to the language (i.e. you still can't use __flash in c++) will be rejected by the maintainers as "too specific", see below for similar case. > Even if AS would not be used, what prevents g++ from emitting the vtables > in the `progmem.data` section and generating vtable-invocation code using > LPM instructions? vtables are generated by the c++ front-end. Some hacking in the avr back-end might be enough to but these tables in flash, but you cannot access it correctly without qualifying all accesses. These qualifiers must be added by the c++ FE so that any pointers / accesses / (internal) variables derived from it use the correct AS. We just saw the maintainers rejecting PR49857 (which is about putting tree-switch-converted lookup-tables into flash / named AS) as "too specific". The avr part was approved. The only change to the middle-end was a well documented hook (statically) invoked only once in tree-switch-conversion module. The maintainers proposed "more generic" solution; none of proposals would work and none of them would be more generic because the only object that's opt to such optimization is CSWTCH from tree-switch-conversion. I got the impression it wasn't even understood why one cannot just patch sections. And patching ASes won't work if any pass might copy a pointer. The tables must be read-only, in static storage, not public, not weak, not linkonce, not comdat, and must be artificial, i.e. cooked up by the compiler (otherwise inline asm will break). So the only use case was CSWTCH anyway... For details see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49857#c17 vtables are even more restrictive because it would be an ABI change: all modules accessing the vtable must agree upon it's AS, i.e. you cannot specify the AS per command option. > or some gcc-specific attribute on a class? Attributes won't work — due to the same reason for why progmem does not work with c / c++: with progmem: you'd need inline asm. And because vtables are artificial, you'll never gat a hand on them. And to be honest: My current impression is that avr-gcc is a dead horse. http://gcc.gnu.org/ml/gcc/2017-07/msg00224.html Maintainers are proposing to deprecate bunch of backends as a side effect of deprecating two essential features that are "old code" and not used by the targets they get their bucks for. Sooner or later they will succeed, effectively throwing bunch of targets into the dust bin. With that perspective and my recent impressions, I think working on avr-gcc has become a waste of time.