https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106635
--- Comment #12 from Xiaoguang <xgchenshy at 126 dot com> --- (In reply to Richard Earnshaw from comment #11) > (In reply to Xiaoguang from comment #9) > > Yeah, I also find such description, my memory type is uncachable normal > > memory, but not device memory > > I use mmap to get the virtual address with an O_SYNC in fd > > Yes, I think you're correct: you can have non-cacheable normal memory and > that supports unaligned accesses. > > However, I don't know how you are supposed to set that up with Linux mmap > calls. It's beyond my knowledge of how the kernel works with the system. > You'd be best asking about that in a different forum where some kernel > experts hang out. > > I don't know what other constraints you might have on your system, but have > you considered using cacheable memory and then inserting cache > synchronization calls at the points where you really need to synchronize > data? That may well have significantly better performance than trying to > map the data as non-cacheable. Note that if you have simultaneous readers > of the data, you'll need to mark the pointers to it as volatile anyway, > because otherwise the compiler might re-order the stores to separate > locations. Thanks very much for the help, I'll continue to investigate this failure, but it is not related with gcc anymore.
