[Bug c++/111067] g++.dg/opt/icf{1,2,3}.C tests fail on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111067 --- Comment #12 from Jason Merrill --- (In reply to Iain Sandoe from comment #11) > SO I suppose the question is do we want to figure out why the opt is failing > (knowing that if it succeeds that is a secondary issue) - or just > dg-xfail-run-if for Darwin? I think we can just disable icf1 on darwin, and not try to merge i and j. It would be nice for icf[23] to work, since those don't involve externally-visible symbols (or even names at all). It would be good to understand what is preventing the optimization in that case.
[Bug c++/111067] g++.dg/opt/icf{1,2,3}.C tests fail on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111067 --- Comment #11 from Iain Sandoe --- (In reply to Jason Merrill from comment #10) > (In reply to Jonathan Wakely from comment #8) > > (In reply to Iain Sandoe from comment #7) > > > So I am actually asking if the extension actually has any useful meaning? > > > > For non-darwin, yes, it requests the storage of two initializer lists to be > > merged (see the commit msg for r14-1500-g4d935f52b0d5c0). > > Though that doesn't involve the attribute, and promoting init-lists to > static should work fine on darwin. I think that is working we end up with two constant text arrays (no copy via automatic storage as mentioned in the paper) > (In reply to Jonathan Wakely from comment #6) > > The question then is whether the attribute is supposed to be a non-binding > > request or not. > > > > If it's a non-binding request then the test should be adjusted/unsupported > > for this target. > > It is a non-binding request. And yes, if this optimization is problematic on > darwin, we should adjust the test. Actually, the optimisation is failing on Darwin - we produce two distinct arrays. (although, if it succeeds then technically that's breaking the ABI since we then have two external symbols with the same addresss). SO I suppose the question is do we want to figure out why the opt is failing (knowing that if it succeeds that is a secondary issue) - or just dg-xfail-run-if for Darwin? This is what we generate now: .const .align 3 _i: .long 1 .long 2 .long 3 .globl _j .align 3 _j: .long 1 .long 2 .long 3 and we do access i and j directly (i.e. not via the GOT).
[Bug c++/111067] g++.dg/opt/icf{1,2,3}.C tests fail on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111067 --- Comment #10 from Jason Merrill --- (In reply to Jonathan Wakely from comment #8) > (In reply to Iain Sandoe from comment #7) > > So I am actually asking if the extension actually has any useful meaning? > > For non-darwin, yes, it requests the storage of two initializer lists to be > merged (see the commit msg for r14-1500-g4d935f52b0d5c0). Though that doesn't involve the attribute, and promoting init-lists to static should work fine on darwin. (In reply to Jonathan Wakely from comment #6) > The question then is whether the attribute is supposed to be a non-binding > request or not. > > If it's a non-binding request then the test should be adjusted/unsupported > for this target. It is a non-binding request. And yes, if this optimization is problematic on darwin, we should adjust the test.
[Bug c++/111067] g++.dg/opt/icf{1,2,3}.C tests fail on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111067 --- Comment #9 from Andrew Pinski --- (In reply to Iain Sandoe from comment #7) > So I am actually asking > - if the extension actually has any useful meaning? YES it does. Especially when it comes to the ability to reduce space used. https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2752r2.html is the link to the paper that is referenced as the notion for the extension. I think this is a minor issue from the point of view of the testcase can just be xfailed on darwin really. Though I suspect the backend will/should be fixed to mark the alias as being the same symbols really.
[Bug c++/111067] g++.dg/opt/icf{1,2,3}.C tests fail on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111067 --- Comment #8 from Jonathan Wakely --- (In reply to Iain Sandoe from comment #7) > So I am actually asking > - if the extension actually has any useful meaning? For non-darwin, yes, it requests the storage of two initializer lists to be merged (see the commit msg for r14-1500-g4d935f52b0d5c0). > - if it is an extension it probably should be only available in gnu:: ? It's a standard attribute. The extension is allowing it to be placed on variables that aren't non-static data members. If you spell it gnu::no_unique_address then it's a completely different attribute (and in that case I'd suggest an alternative name, because we don't want to recreate the msvc::no_unique_address debacle, or even give the impression of doing so!)
[Bug c++/111067] g++.dg/opt/icf{1,2,3}.C tests fail on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111067 --- Comment #7 from Iain Sandoe --- however: 1) it is not in the gnu:: namespace the tests just have it as [[ ]]. 2) I do not think that the standard has anything to say about how entities at file scope are ordered in memory (many/most impls. probably use the same order as the file - but I do not think they are obliged to). 3) it is an ABI break for Darwin (where two global entities are not allowed to have the same address - although it _is_ possible to tell the linker that one is an alias for another - that support is not (yet) available in the FE). So I am actually asking - if the extension actually has any useful meaning? - if it is an extension it probably should be only available in gnu:: ?
[Bug c++/111067] g++.dg/opt/icf{1,2,3}.C tests fail on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111067 --- Comment #6 from Jonathan Wakely --- Yes, I think it's an extension, added by r14-1500-g4d935f52b0d5c0 The question then is whether the attribute is supposed to be a non-binding request or not. If it's a non-binding request then the test should be adjusted/unsupported for this target. If the latter, then that use of the attribute should be ill-formed for this target and give an error.
[Bug c++/111067] g++.dg/opt/icf{1,2,3}.C tests fail on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111067 Iain Sandoe changed: What|Removed |Added Target|x86_64-apple-darwin20 |*-darwin* Component|testsuite |c++ Last reconfirmed|2023-08-18 00:00:00 |2024-3-7 Host|x86_64-apple-darwin20 |*-darwin* Build|x86_64-apple-darwin20 |*-darwin* --- Comment #5 from Iain Sandoe --- I am shifting this to component C++, because the answer to comment #4 is really what's important - if this is supposed to work for file scope entities, then it needs to be a GCC extension (ISTM, anyway).
[Bug c++/111067] g++.dg/opt/icf{1,2,3}.C tests fail on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111067 Francois-Xavier Coudert changed: What|Removed |Added Known to fail||14.0 Target||x86_64-apple-darwin20 CC||jason at gcc dot gnu.org Host||x86_64-apple-darwin20 Build||x86_64-apple-darwin20 Last reconfirmed||2023-08-18 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW
