- using a special pointer value... - 1 Update
- Observable end padding in arrays - 3 Updates
- who's at fault, me or compiler? - 4 Updates
- Optimiser Repressing Linker Error - 2 Updates
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jun 30 03:34PM -0700 On 6/29/2020 1:19 AM, Chris M. Thomasson wrote: >> The original message for this can be found here: >> https://groups.google.com/forum/#!original/comp.arch/k1Qr520dcDk/4vl_jiVRBQAJ >> within the following thread: [...] > return m_head.exchange(nullptr, std::memory_order_acquire); > } > }; [...] fwiw, there is a way to get rid of the acquire barrier in the stack::flush function. The only difference is that some relaxed barriers would become consume. This is fine on most arch's because they are no-ops wrt memory barriers, except dec alpha. |
| Juha Nieminen <nospam@thanks.invalid>: Jun 30 06:20AM > I have seen lots of code which assumes contiguity over the whole of a > multi-dimensional array, and I am pretty certain this requirement > exists, but can anyone point me to where I can find it? Not an answer to your question, but it reminded me of a conversation I had recently about why there is no multidimensional version of std::array. Why should there be? Because, AFAIK, std::array<std::array<T, X>, Y> is not guaranteed to be contiguous. |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Jun 30 11:39AM +0100 On Mon, 29 Jun 2020 14:41:07 -0700 > wording seems to indicate that it's a consequence of some normative > requirement elsewhere in the standard. (Nevertheless, I accept > that it's required.) It is odd, which is maybe why I missed it. The first sentence of the text extracted by Alf ("When applied to an array, the result is the total number of bytes in the array") is a truism, arising from the specification for the sizeof operator itself in §8.3.3/1: "The sizeof operator yields the number of bytes in the object representation of its operand". So the "this implies ..." is not implied at all. It does however appear to be normative, which is good enough for me. (At least, until the C++ standard committee notice this infelicity in the standard and decide to resolve it by removing the requirement for no end padding. Removing that requirement would break some pre-existing code concerning the accessing of elements of multi-dimensional arrays, but that has not dissuaded the committee before with their changes to object lifetime rules.) |
| Vir Campestris <vir.campestris@invalid.invalid>: Jun 30 09:44PM +0100 On 29/06/2020 22:08, Alf P. Steinbach wrote: >> I think if there was such a requirement every compiler I've ever used >> would disobey it. > Surely you mean the opposite? The bit I meant you snipped "may not have observable end padding". Andy |
| Juha Nieminen <nospam@thanks.invalid>: Jun 30 06:02AM >>and then you say that it's never instantiated. > Instantiation implies an action at runtime, not binary load time which is > what happens in this case. Says who? Instantiation means that the object physically exists at runtime. If the object never exists, it has never been instantiated. |
| Ian Collins <ian-news@hotmail.com>: Jun 30 06:11PM +1200 On 30/06/2020 18:02, Juha Nieminen wrote: >> what happens in this case. > Says who? Instantiation means that the object physically exists at runtime. > If the object never exists, it has never been instantiated. Says the troll who can't count code changes or compile code! -- Ian. |
| boltar@nowhere.co.uk: Jun 30 11:02AM On Tue, 30 Jun 2020 06:02:23 +0000 (UTC) >> what happens in this case. >Says who? Instantiation means that the object physically exists at runtime. >If the object never exists, it has never been instantiated. So is the machine code in the binary instantiated as well then? Instantiation means run time creation, not simply what the loader copied into memory before a single CPU instruction of the program has been run. |
| Juha Nieminen <nospam@thanks.invalid>: Jun 30 04:16PM > So is the machine code in the binary instantiated as well then? In this sense, yes. As opposed to the compiler evaluating the program at compile time and simply using the end result of the calculations (which is quite common especially nowadays with constexpr functions). If a constexpr function is evaluated at compile time and only its end result ends up being used, then you could say that the function was never instantiated. If the function gets compiled into the binary and thus actually exists there at runtime, then it got instantiated. Data or code, it works very similary. > Instantiation > means run time creation, not simply what the loader copied into memory before > a single CPU instruction of the program has been run. And where are you getting this weird definition from? |
| Juha Nieminen <nospam@thanks.invalid>: Jun 30 06:15AM > It seems that an automated optimiser realises that "Func" will never be called and so it doesn't require its definition. I doubt that the standard guarantees linker errors for code that might or might not be optimized away by the linker. Btw, this is one of the reasons why one should *always* test compiling one's projects *with* and *without* optimizations. It has bitten me in the behind more than once that I have the habit of always compiling with optimizations and never trying what happens if I leave optimizations out. More than once when compiling without optimizations I have got linker errors because I didn't realize that something was not defined properly but the compiler was hiding the error with optimizations. (Of course even then you can really rely on finding this out by simply leaving optimizations options out, as there's no guarantee that the compiler will not keep optimizing some things out.) |
| Frederick Gotham <cauldwell.thomas@gmail.com>: Jun 30 01:08AM -0700 On Tuesday, June 30, 2020 at 7:15:52 AM UTC+1, Juha Nieminen wrote: > (Of course even then you can really rely on finding this out by > simply leaving optimizations options out, as there's no guarantee that > the compiler will not keep optimizing some things out.) I had one executable program that I decided to split into one executable program and two libraries. So I did the split, and then I tried to link everything together. Well the exectuable program linked successfully even when I didn't link it with one of the new libraries I had created. I spent maybe about an hour copy-pasting function declarations and moving ".cpp" files, before I decided to look at where the function is called in the code, and I saw that I had an if-statement with a compile-time-constant boolean. |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment