rolandschulz
rolandschulz
See https://wandbox.org/permlink/XHwzxHs2lzbi3J3k here (credit to arthur-odwyer for example). What's observable is the difference between the pointer during construction and anytime after the emplace.
I agree it is an obvious stupid type. I asked about that on cpplang.slack (Feb 24 on #general). The conversation (answer by Arthur): >> Does that mean the libstdc++ optimization...
This might be a bug in terminal instead. I created an issue there too: https://github.com/microsoft/terminal/issues/13595
Sorry didn't notice your reply. I would throw an exception. Out of range values should be exceptional so that wouldn't turn into misusing exception for control flow. I would consider...
Would Codeplay's extension proposal https://github.com/codeplaysoftware/standards-proposals/pull/132 address your use-case?
All 3 failures are incorrect results not TSAN errors. They also all 3 still occur with OMP_NUM_THREADS=1. Thus it seems that the LLVM pass added by archer causes incorrect results....
I provided the git, cmake, and ninja commands in my first message. That should let you be able to reproduce the error. If you have difficulty reproducing I'm happy to...
What's the use case for storing them in containers? Why is that solution better than alternatives and therefore important to support?
> It's not clear how to return sub group size when backend implementation doesn't support it hence, I believe some other exception wording might suite here. I don't think that...
Note that the proposed solution doesn't link against OpenCL but ocloc (the igc offline compiler). This works even if the OpenCL runtime isn't available.