- constexpr all the things! - 1 Update
- strange issue ... - 16 Updates
- alloca in 32 bit pc assembly language - 2 Updates
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Oct 11 10:42PM +0100 https://leighjohnston.wordpress.com/2019/10/11/constexpr-all-the-things/ The C++20 constexpr changes do look very interesting: it will be the death knell of ivory tower C++ template meta-programmers which is a good thing. 😏 Just don't let the idea of using std::vector at compile time as well as at runtime make your coder's mind go ping! 🤣 http://open-std.org/JTC1/SC22/WG21/docs/papers/2019/p1004r2.pdf /Flibble -- "Snakes didn't evolve, instead talking snakes with legs changed into snakes." - Rick C. Hodgin "You won't burn in hell. But be nice anyway." – Ricky Gervais "I see Atheists are fighting and killing each other again, over who doesn't believe in any God the most. Oh, no..wait.. that never happens." – Ricky Gervais "Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Bryne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?" "I'd say, bone cancer in children? What's that about?" Fry replied. "How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil." "Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say." |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Oct 10 07:41PM -0400 On 10/9/19 5:26 PM, Scott Lurndal wrote: > the external reference to the symbol. It becomes surprising, > then, to many programmers when their program won't link when compiled > without optimization. I'm curious - what is your explanation for the fact that my simplified program (posted on October 3rd) matches Bonita's description of her program, yet compiles without a link error? |
| Melzzzzz <Melzzzzz@zzzzz.com>: Oct 10 10:10PM > I'm taking the value of a static const integral member without > taking its address or a reference on that. The behaviour of that > is defined and there's no code that should affect that behaviour. How compiler can know that? Only way compiler can know that is to enforce rule that address can't be taken... -- press any key to continue or any other to quit... U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi bili naoruzani. -- Mladen Gogala |
| Paavo Helde <myfirstname@osa.pri.ee>: Oct 11 09:01AM +0300 On 11.10.2019 2:41, James Kuyper wrote: > I'm curious - what is your explanation for the fact that my simplified > program (posted on October 3rd) matches Bonita's description of her > program, yet compiles without a link error? You mean the one without any odr-access? This is easy, the standard says the definition of the const static member is not required if there is no odr-access. Even if it had odr-access and no definition of the static member (and is therefore an invalid program), it still can compile and link because some optimizations are applied even without any -O flag, and because the standard says the compiler is not obliged to detect and report this kind of errors (presumably because it would be hard for a linker to detect a problem if it has already been optimized away by the compiler). |
| David Brown <david.brown@hesbynett.no>: Oct 11 09:14AM +0200 On 11/10/2019 01:41, James Kuyper wrote: > I'm curious - what is your explanation for the fact that my simplified > program (posted on October 3rd) matches Bonita's description of her > program, yet compiles without a link error? My explanation would be that Bonita's description of her code is not accurate. She won't show the code, she won't try to get a simplified case that shows the problem - instead, she repeatedly asserts that she knows best and the compiler has a bug. I think that until /proven/ otherwise by real code, we must assume her code is in error and is not what she thinks it is or how she described it, with the error manifesting in different ways with different compilers. |
| Ian Collins <ian-news@hotmail.com>: Oct 11 08:16PM +1300 On 11/10/2019 20:14, David Brown wrote: > otherwise by real code, we must assume her code is in error and is not > what she thinks it is or how she described it, with the error > manifesting in different ways with different compilers. There be trolls... -- Ian. |
| Bonita Montero <Bonita.Montero@gmail.com>: Oct 11 03:06PM +0200 > the reason what is wrong with excuse that you have voodoo > that fixes it therefore "knowledge" is even less understandable > to me than outright lying about something of it. The compiler simply changes a non-odr-access into an odr access although the value is simply assigned to a member of the same type of class Node. The compiler isn't simply allowed to do that. And with the extra-cast I've proven that there's a bug in the compiler. This is how class Node is defined: struct node_links { Node *lruPrev; Node *lruNext; }; struct bucket_links { Node *prevInBucket, *nextInBucket; }; struct Node : public node_links, public bucket_links { bool postInsertion; Node *nextFree; std::uint32_t pinCounter; // Key and value are template-types od the outer // class Key k; Value v; }; This is the definition of FREE_NODE inside the same class. static std::uint32_t const UNPINNED_NODE = 0, FREE_NODE = 0xFFFFFFFFu; Inside this class there is a constructor as well as different methods doing the same "nd->pinCounter = FREE_NODE;". In the case where the compiler makes a non-odr-access to an odr-access it's this code: Node *prev, *nd, *prevFree; ... nd = &m_nodes[0]; ... for( ; ; prev = nd, prevFree = nd, ++nd, ++iPrev ) { ... nd->pinCounter = FREE_NODE; } Bút the other code simply doesn't matter. It is just for your stupidity. |
| Bonita Montero <Bonita.Montero@gmail.com>: Oct 11 03:07PM +0200 >> is defined and there's no code that should affect that behaviour. > How compiler can know that? Only way compiler can know that is to > enforce rule that address can't be taken... It is specified what a non-odr- and an odr-access is. The standard even gives examples, the same given in cppreference. |
| Paavo Helde <myfirstname@osa.pri.ee>: Oct 11 04:30PM +0300 On 11.10.2019 16:06, Bonita Montero wrote: > static > std::uint32_t const UNPINNED_NODE = 0, > FREE_NODE = 0xFFFFFFFFu; This is not the definition, but declaration. And which "same class"? Node? Why is it not visible inside the Node definition above? Anyway, the Node class has nothing to do with the errors. From the error messages you posted some time ago, it is clearly seen that the linker complains about LruCache::FREE_NODE in some class template LruCache, not Node. The error messages you posted, for reference: In function `LruCache<unsigned long, unsigned long, std::hash<unsigned long>, std::equal_to<unsigned long>, std::allocator<char> >::LruCache(unsigned long, unsigned long, unsigned long, unsigned long, std::hash<unsigned long> const&, std::equal_to<unsigned long> const&, std::allocator<char> const&)': xxxxx.cpp:(.text._ZN8LruCacheImmSt4hashImESt8equal_toImESaIcEEC2EmmmmRKS1_RKS3_RKS4_[_ZN8LruCacheImmSt4hashImESt8equal_toImESaIcEEC5EmmmmRKS1_RKS3_RKS4_]+0x20d): undefined reference to `LruCache<unsigned long, unsigned long, std::hash<unsigned long>, std::equal_to<unsigned long>, std::allocator<char> >::FREE_NODE' |
| Bonita Montero <Bonita.Montero@gmail.com>: Oct 11 04:02PM +0200 > This is not the definition, but declaration. Doesn't change the issue. > And which "same class"? Everything I showed declared in an outer class. > messages you posted some time ago, it is clearly seen that the linker > complains about LruCache::FREE_NODE in some class template LruCache, not > Node. Someone else here wanted to see code and he insisted that this might change the behaviour of the compiler regarding the problem. I'm not of this opinion, it's just to satify stupid demands. |
| Paavo Helde <myfirstname@osa.pri.ee>: Oct 11 05:21PM +0300 On 11.10.2019 17:02, Bonita Montero wrote: > Someone else here wanted to see code and he insisted that this might > change the behaviour of the compiler regarding the problem. I'm not > of this opinion, it's just to satify stupid demands. Translation: I had some problems with my stomach and the doctor wanted to see my poop. I sent the poop of my dog. Stupid doctor, he thinks that looking at some dog poop will somehow fix my stomach. I drank a lot of vodka instead and feel great now! |
| Bonita Montero <Bonita.Montero@gmail.com>: Oct 11 04:22PM +0200 > to see my poop. I sent the poop of my dog. Stupid doctor, he thinks that > looking at some dog poop will somehow fix my stomach. I drank a lot of > vodka instead and feel great now! You're just talking stupid stuff. |
| "Öö Tiib" <ootiib@hot.ee>: Oct 11 08:09AM -0700 On Friday, 11 October 2019 17:23:04 UTC+3, Bonita Montero wrote: > > looking at some dog poop will somehow fix my stomach. I drank a lot of > > vodka instead and feel great now! > You're just talking stupid stuff. But you post random dog poop that does not compile and when I edit it to compile then it has no linker errors. |
| Bonita Montero <Bonita.Montero@gmail.com>: Oct 11 05:17PM +0200 >> You're just talking stupid stuff. > But you post random dog poop that does not compile and when I edit it > to compile then it has no linker errors. With my g++ 6.3.0 it gives a linker-error. |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Oct 11 11:37AM -0400 On 10/11/19 3:14 AM, David Brown wrote: >> program, yet compiles without a link error? > My explanation would be that Bonita's description of her code is not > accurate. But in that case, why bring this up at all? Bonita has made it abundantly clear that the validity of her code depends upon the absence of an odr-use. Other people seemed to believe it's invalid even with no odr-uses, and I assumed that you were still arguing that point. I think it's safe to assume that she already understands why it depends upon that absence. There's no need to go into details about it, as if she'd suggested that the absence wasn't necessary. I think it's entirely plausible that she could be wrong about the absence of an odr-use in some other part of her code. Whether or not something is an odr-use can sometimes be a tricky thing to figure out, and she's not particularly careful about such things. However, I find it less plausible that she has incorrectly described the voodoo code she used to "work around" the problem. She seems quite proud of her voodoo code, so I'd expect that to be described accurately. She used a cast of an expression to the same type it always had, converting something that wasn't an odr-use into something that was still not an odr-use. Why would such a cast solve a linker problem caused by an odr-use in some other part of her program? That's why I'm still clinging to the possibility of undefined behavior in the part of her code that she refuses to show us, as the most plausible explanation - with an actual compiler bug as a distant second-place possibility. > otherwise by real code, we must assume her code is in error and is not > what she thinks it is or how she described it, with the error > manifesting in different ways with different compilers. That I can fully agree with. Note: "different ways with different compilers" is entirely consistent with her assumption that it's a compiler bug. |
| David Brown <david.brown@hesbynett.no>: Oct 11 05:51PM +0200 On 11/10/2019 17:37, James Kuyper wrote: >> My explanation would be that Bonita's description of her code is not >> accurate. > But in that case, why bring this up at all? I think you may be mixing up posters here - it was Scott that brought it up, not me. I merely said why I agree with him. This can, of course, be blamed fully on Bonita's refusal to use standard Usenet attributions. > abundantly clear that the validity of her code depends upon the absence > of an odr-use. Other people seemed to believe it's invalid even with no > odr-uses, and I assumed that you were still arguing that point. No, not necessarily. It could just as easily be that there is an odr-use somewhere, but that some compilers (perhaps dependent on flags) have removed the particular use by optimisation, or otherwise generated code with the same effect but no linking error. Since we don't have a complete example demonstrating the effect, it is unlikely that we will ever know for sure. (I can't say what point Scott might have been arguing.) > suggested that the absence wasn't necessary. > I think it's entirely plausible that she could be wrong about the > absence of an odr-use in some other part of her code. Yes, exactly. > Whether or not > something is an odr-use can sometimes be a tricky thing to figure out, > and she's not particularly careful about such things. Agreed. > less plausible that she has incorrectly described the voodoo code she > used to "work around" the problem. She seems quite proud of her voodoo > code, so I'd expect that to be described accurately. Agreed - it is likely that that bit is described accurately. It is the rest of the code that is missing. > converting something that wasn't an odr-use into something that was > still not an odr-use. Why would such a cast solve a linker problem > caused by an odr-use in some other part of her program? I don't know. > in the part of her code that she refuses to show us, as the most > plausible explanation - with an actual compiler bug as a distant > second-place possibility. Agreed. > That I can fully agree with. Note: "different ways with different > compilers" is entirely consistent with her assumption that it's a > compiler bug. Also true. (It is consistent with there being a bug in gcc for leading to the linking error - it is also consistent with there being a bug in other compilers that don't give a linking error.) |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Oct 11 12:19PM -0700 On 10/11/2019 6:06 AM, Bonita Montero wrote: [...] Humm... Fwiw, FREE_NODE reminds me of a stub pointer value. Akin to my use of CT_WAIT in: https://pastebin.com/raw/j41cPT9S #define CT_WAIT ((ct_work*)(0xDEADBEEFU)) |
| matth <matthewcoan1976@gmail.com>: Oct 10 05:17PM -0500 [BITS 32] [SEGMENT .text] global _alloca extern __chkstk _alloca: pop ecx pop eax ;sub esp,eax call __chkstk mov eax,esp sub esp,4 jmp ecx |
| Frederick Gotham <cauldwell.thomas@gmail.com>: Oct 10 11:50PM -0700 On Thursday, October 10, 2019 at 11:17:36 PM UTC+1, matth wrote: > mov eax,esp > sub esp,4 > jmp ecx Be careful, you'll get an email from Keith Thompson if you post stuff like that here |
| 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