On Mon, 18 Mar 2013, Cristian Morales Vega wrote:
On 18 March 2013 12:47, Richard Biener <rguenther@suse.de> wrote:
On Sun, 17 Mar 2013, Cristian Morales Vega wrote:
On 10 May 2012 17:09, Vincent Untz <vuntz@opensuse.org> wrote:
Le jeudi 10 mai 2012, ? 11:56 -0400, Cristian Rodr?guez a ?crit :
El 10/05/12 11:53, Vincent Untz escribi?:
In general, I'm pretty much against non-upstream patches changing the build system unless there's a really good reason for them. Optimization is not a good enough reason for me: if the optimization matters.
The example optimization I mentioned first in the thread , also catches some extra buffer overflows.. is better security a good enough reason for you ?
Sounds like something we'd want to share with the world to me. So good reason, but reason to push upstream too :-)
Given Richard Guenther explanation I can't see a good way of upstreaming this. I mean, it's actually already upstreamed! The upstream patch is the -ansi/-std option that projects could use when developing, but that apparently nobody should be adding to the makefiles they release. Additionally gcc is a project with 19 patches already. So while I always try to avoid patches in my packages in this case I don't think a one line patch more or less is going to make any difference. In any case this is for gcc maintainers to decide.
So I went forward and created the patch in home:RedDwarf:branches:devel:gcc. Any advice before creating a submit request? Should we run the testsuite with "SUSE_ALWAYS_GNU" defined or not?
No, running the testsuite with SUSE_ALWAYS_GNU will result in failures.
Note the patch,
Index: gcc/c-family/c-opts.c =================================================================== --- gcc/c-family/c-opts.c.orig +++ gcc/c-family/c-opts.c @@ -822,6 +822,9 @@ c_common_handle_option (size_t scode, co break; }
+ if (getenv ("SUSE_ALWAYS_GNU") && atoi(getenv ("SUSE_ALWAYS_GNU")) > 0) + flag_iso = 0; + return result; }
is bogus and will even created wrong code. Which means it is not acceptable anyway.
Ups. I modified it but it still goes for the "iso" thing since I don't know if "flag_no_nonansi_builtin" would be enough and if a bad combination can break the generated code.
I suggest you arrange for -grecord-gcc-switches to be enabled in RPM_OPT_FLAGS and implement a rpmlint check to search for -std=non-gnu-XXX or -ansi. We can then also drop the suse-record-gcc-opts.diff switch (there is also -frecord-gcc-switches).
Any preference between "-frecord-gcc-switches" and "-grecord-gcc-switches"? In the former "the exact format of the recording is target and binary file format dependent". And the later requires DWARF. I am not into debugging formats. There is any relevant architecture which can't use DWARF? Notice that the info will be lost in the cases where RPM_OPT_FLAGS is not used. Somebody is actually depending on suse-record-gcc-opts.diff?
Yes, the existing rpmlint check. Note that -grecord-gcc-switches is the default starting with GCC 4.8. All archs use DWARF, the info should be accessible via readelf for example. Richard. -- Richard Biener <rguenther@suse.de> SUSE / SUSE Labs SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 GF: Jeff Hawn, Jennifer Guild, Felix Imend -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org