Since commit r10-580-ge154242724b084 gcc no longer passes -many to the assembler for --enable-checking=yes builds. However, we still pass -many to the assembler for --enable-checking=release builds. This can hide wrong code bugs like in PR112707. This bugzilla is to discuss whether should we remove passing -many to the assembler under all conditions or should we leave things as they are? Let the bikeshedding begin! :-)
CCing interested parties for their input.
Narrowing the ISA dialect range accepted by the assembler is good in theory to catch problems. We need to ensure that this doesn't break a lot of existing code and make POWER more tedious. Most people want to download a pre-built package. If someone downloads source code, they want it to configure, build and run without problems. While this change will ensure that new packages are more strictly conformant and may not cause problems with new Linux distro releases, it could prevent older packages from building with newer releases of GCC.
The behavior shouldn't change dependent on --enable-checking. Can't we make sure to pass -mno-any (if that exists...) during bootstrap and testsuite instead?
I was quite surprised by this behaviour. It should really be documented if we're going to stick with it, but I don't think we should at all..
(In reply to Richard Biener from comment #3) > Can't we make sure to pass -mno-any (if that exists...) during bootstrap > and testsuite instead? -mno-any does not exist.
(In reply to Sam James from comment #4) > I was quite surprised by this behaviour. It should really be documented if > we're going to stick with it, but I don't think we should at all.. I have asked Jeevitha to prepare a patch to remove the -many assembler option usage on --enable-checking=release builds. It would be nice if we can get some distro help to do some practice distro builds using the patch to verify whether there it causes any fallout on distro builds to help decide whether we should push the patch or leave things as they are.
(In reply to Peter Bergner from comment #6) Thanks Peter. We're happy to help with that in Gentoo. If you remember, please CC me on the patch and we'll give it a spin.
Created attachment 57584 [details] Removed -many from the options passed by default to the assembler. Sam James, can you do a practice distro build using this patch?
(In reply to Jeevitha from comment #8) > Created attachment 57584 [details] > Removed -many from the options passed by default to the assembler. > > Sam James, can you do a practice distro build using this patch? Hi Jeevitha, I've added this to our patchset tonight and asked some people to give it a spin on top of that too.
No problems reported yet and we have several people testing on ppc w/ gcc 14.
(In reply to Sam James from comment #10) > No problems reported yet and we have several people testing on ppc w/ gcc 14. Thanks for the testing! This is clearly a stage1 patch, so we'll wait until then before submitting it.
*** Bug 114813 has been marked as a duplicate of this bug. ***
(In reply to Peter Bergner from comment #11) > This is clearly a stage1 patch, so we'll wait until > then before submitting it. I'm not that familiar with gcc development procedures. Do I understand you correctly, that a fix for this bug will not be included in gcc-14 (according to https://gcc.gnu.org/develop.html#timeline, gcc-14 stage1 ended several months ago), it will have to wait for gcc-15?
(In reply to Niels Möller from comment #13) > I'm not that familiar with gcc development procedures. Do I understand you > correctly, that a fix for this bug will not be included in gcc-14 (according > to https://gcc.gnu.org/develop.html#timeline, gcc-14 stage1 ended several > months ago), it will have to wait for gcc-15? Correct, I meant waiting for GCC 15 stage1. I want it to burn-in on trunk for a long while, because it had the potential to disrupt distro package builds. It seems clean so far with the practice Gentoo builds, but I'll feel more comfortable when other distros start using it too. That said, Jeevitha, now that we're in stage1, can you please post your patch?
On 07/05/24 1:53 am, bergner at gcc dot gnu.org wrote: > That said, Jeevitha, now that we're in stage1, can you please post your patch? > Sure Peter.
(In reply to Peter Bergner from comment #14) > (In reply to Niels Möller from comment #13) > > I'm not that familiar with gcc development procedures. Do I understand you > > correctly, that a fix for this bug will not be included in gcc-14 (according > > to https://gcc.gnu.org/develop.html#timeline, gcc-14 stage1 ended several > > months ago), it will have to wait for gcc-15? > > Correct, I meant waiting for GCC 15 stage1. I want it to burn-in on trunk > for a long while, because it had the potential to disrupt distro package > builds. It seems clean so far with the practice Gentoo builds, but I'll > feel more comfortable when other distros start using it too. FWIW, we're keeping it going forward (so it'll be in e.g. our GCC 14 patchset when we unleash that on the masses). Just keep in mind that very few distributions build with > release checking. We only do default-checking for the branch when it's in development still and also optionally via USE=debug. So, while testing by others is still valuable, I don't expect you'll get that much - at least without people specifically knowing to turn on checking and ensure stuff doesn't break. (Of course, making sure release checking works fine now too is important, but you get my point.)
PR113652 remains a problem and I guess it's more of a problem for landing this change in a release, as it means PR113652 will affect more people.