Timeline for Creating the mythical XAND Gate
Current License: CC BY-SA 4.0
12 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 27 at 15:29 | comment | added | Deadcode | @test_account I think you are misreading my statement; it refers to the time at which I posted my answer. After I posted it, three Python answers were posted that use a similar concept. | |
| Oct 25 at 18:05 | comment | added | test_account | I've been thinking a bit about the claim "this is the only solution so far that doesn't use ... operator precedence tricks". There is a good point here, but the description is a little narrow. What about something like "this is the only solution that executes at runtime as the standard logical && of two expressions". This way, you don't have to worry about other compiler fudges turning up later. | |
| Oct 21 at 20:25 | comment | added | Peter Cordes | noipa = no Inter-Procedural Analysis. | |
| Oct 21 at 20:25 | comment | added | Peter Cordes | Without the noipa attribute, GCC can see that a unconditionally returns true, which has a similar effect to [[likely]] on that block (or __builtin_expect(!!a(), 1) like Linux likely(a()) macros), but without even doing a conditional branch on the return value, just calling it (because noinline) and then printing. And in the short-circuit code, call a is directly followed by call b. With noipa like I used, or with the definition in a different file and no LTO, it assumes that printing is unlikely and puts that block out of line at the bottom of the function after the ret. | |
| Oct 21 at 20:00 | comment | added | Deadcode | @PeterCordes Nicely done! I didn't know about the [[likely]] annotation. But it seems to work even without that. | |
| Oct 21 at 19:39 | comment | added | Peter Cordes | I tried to make this more robust so it could be compiled with optimization enabled. __attribute__((noinline,noipa)) on both a and b gets it to print a is true a && b is true. godbolt.org/z/G8ebdf5Mz shows the asm from g++ -O2 for x86-64. The first two if statements compile with jumps to blocks at the bottom of the function which then jump back, so the callsites are very close. a() && b() compiles with the two callsites far apart. godbolt.org/z/nnGsGrc5G shows using [[likely]] to override the branch layout, and bumps up the threshold to 16 bytes to "fix" it. | |
| Oct 21 at 2:17 | comment | added | Deadcode | @ChrisBouchard As long as you don't call a() or b() bare (as a lone statement without using its value), it should be hard or impossible to get b() to return a different value when called from the same point in the program. I invite you to try. | |
| Oct 21 at 0:43 | comment | added | Chris Bouchard | Does this meet the requirement that the condition "must continue to hold true throughout the duration of your program"? In particular, the explanation that "you can not just have a value that simply changes after it's read the first time so that the second time you make the comparison it is no longer truthy." | |
| Oct 20 at 1:57 | history | edited | Deadcode | CC BY-SA 4.0 | return to the original description, and include -O0 in the language spec |
| Oct 20 at 1:55 | history | rollback | Deadcode | Rollback to Revision 1 | |
| Oct 19 at 23:56 | history | edited | Deadcode | CC BY-SA 4.0 | I no longer want to frame the description as a comparison against previous submissions. |
| Oct 19 at 20:56 | history | answered | Deadcode | CC BY-SA 4.0 |