[opensuse-factory] rpmlint: warn if -ansi is used to build packages
Hi: Will be cool if rpmlint could warn when upstream packages attempt to use the -ansi gcc option because it inhibits usage of gcc builtin functions while optimizing (list here --> http://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html#Other-Builtins) most recently it caught my attention that it also disables the new "optimize-strlen" pass in gcc 4.7, in particular this: "for hosted compilations where stpcpy is available in the runtime and headers provide its prototype, e.g. void foo (char *a, const char *b, const char *c, const char *d) { strcpy (a, b); strcat (a, c); strcat (a, d); } can be optimized into: void foo (char *a, const char *b, const char *c, const char *d) { strcpy (stpcpy (stpcpy (a, b), c), d); } " when -ansi is used and (defined(_GNU_SOURCE) || (_XOPEN_SOURCE >= 700 || _POSIX_C_SOURCE >= 200809L)) is false, there is no stpcpy prototype and hence no optimization. Thoughts ? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 09.05.2012 23:19, schrieb Cristian Rodríguez:
when -ansi is used and (defined(_GNU_SOURCE) || (_XOPEN_SOURCE >= 700 || _POSIX_C_SOURCE >= 200809L)) is false, there is no stpcpy prototype and hence no optimization.
Thoughts ?
My usual question would apply: Can you measure the difference? If not, I wouldn't want to waste my energy discussing this. -ansi is a _very_ popular flag - e.g. all of KDE (3 and 4) uses it. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, 10 May 2012, Stephan Kulow wrote:
Am 09.05.2012 23:19, schrieb Cristian Rodríguez:
when -ansi is used and (defined(_GNU_SOURCE) || (_XOPEN_SOURCE >= 700 || _POSIX_C_SOURCE >= 200809L)) is false, there is no stpcpy prototype and hence no optimization.
Thoughts ?
My usual question would apply: Can you measure the difference? If not, I wouldn't want to waste my energy discussing this.
-ansi is a _very_ popular flag - e.g. all of KDE (3 and 4) uses it.
Using this flag (or what it aliases to - -std=c++98/c90 as opposed to the defaults which are gnu++98/gnu90) makes sense to avoid GCC features creep into a codebase and thus make sure the source will also build using compilers that are not GCC (or implement all of its extensions). Using the flag to produce binaries for a GNU/Linux system makes less sense though. I'm not sure what we should do here, but if we do something we need to handle -std=c90, -std=c99, etc. the same way (thus, recommend the gnu variants). Richard. -- Richard Guenther <rguenther@suse.de> SUSE / SUSE Labs SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer
Am 10.05.2012 12:45, schrieb Richard Guenther:
On Thu, 10 May 2012, Stephan Kulow wrote:
Am 09.05.2012 23:19, schrieb Cristian Rodríguez:
when -ansi is used and (defined(_GNU_SOURCE) || (_XOPEN_SOURCE >= 700 || _POSIX_C_SOURCE >= 200809L)) is false, there is no stpcpy prototype and hence no optimization.
Thoughts ?
My usual question would apply: Can you measure the difference? If not, I wouldn't want to waste my energy discussing this.
-ansi is a _very_ popular flag - e.g. all of KDE (3 and 4) uses it.
Using this flag (or what it aliases to - -std=c++98/c90 as opposed to the defaults which are gnu++98/gnu90) makes sense to avoid GCC features creep into a codebase and thus make sure the source will also build using compilers that are not GCC (or implement all of its extensions). Using the flag to produce binaries for a GNU/Linux system makes less sense though.
I'm not sure what we should do here, but if we do something we need to handle -std=c90, -std=c99, etc. the same way (thus, recommend the gnu variants).
Of course you can hack gcc to make -ansi void if SUSE_IGNORE_ANSI is set :) Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
El 10/05/12 06:45, Richard Guenther escribió:
On Thu, 10 May 2012, Stephan Kulow wrote:
Am 09.05.2012 23:19, schrieb Cristian Rodríguez:
when -ansi is used and (defined(_GNU_SOURCE) || (_XOPEN_SOURCE>= 700 || _POSIX_C_SOURCE>= 200809L)) is false, there is no stpcpy prototype and hence no optimization.
Thoughts ?
My usual question would apply: Can you measure the difference? If not, I wouldn't want to waste my energy discussing this.
-ansi is a _very_ popular flag - e.g. all of KDE (3 and 4) uses it.
Using this flag (or what it aliases to - -std=c++98/c90 as opposed to the defaults which are gnu++98/gnu90) makes sense to avoid GCC features creep into a codebase and thus make sure the source will also build using compilers that are not GCC (or implement all of its extensions). Using the flag to produce binaries for a GNU/Linux system makes less sense though.
I'm not sure what we should do here, but if we do something we need to handle -std=c90, -std=c99, etc. the same way (thus, recommend the gnu variants).
Richard.
While ugly, I believe we could use an enviroment variable, SUSE_CC_PREFER_GNU where all this flags are equivalent to -std=gnu99 Packages can then unset that variable in the rare case it causes a problem. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Quoting Cristian Rodríguez <crrodriguez@opensuse.org>:
Hi:
Will be cool if rpmlint could warn when upstream packages attempt to use the -ansi gcc option because it inhibits usage of gcc builtin functions while optimizing (list here --> http://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html#Other-Builtins) most recently it caught my attention that it also disables the new "optimize-strlen" pass in gcc 4.7, in particular this:
"for hosted compilations where stpcpy is available in the runtime and headers provide its prototype, e.g.
void foo (char *a, const char *b, const char *c, const char *d) { strcpy (a, b); strcat (a, c); strcat (a, d); }
can be optimized into:
void foo (char *a, const char *b, const char *c, const char *d) { strcpy (stpcpy (stpcpy (a, b), c), d); } "
when -ansi is used and (defined(_GNU_SOURCE) || (_XOPEN_SOURCE >= 700 || _POSIX_C_SOURCE >= 200809L)) is false, there is no stpcpy prototype and hence no optimization.
Thoughts ?
Christian, before you send all kind of SRs (as you already started): Maybe we can finalize the discussion here and get consensus that this is wishful and helpful? What do we gain (not hypothetical, but real), what do we risk? IMHO: diverting from what an upstream provides / proposes in such cases should be well understood and not 'just done'. Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Le jeudi 10 mai 2012, à 05:55 -0400, Dominique Leuenberger a écrit :
before you send all kind of SRs (as you already started): Maybe we can finalize the discussion here and get consensus that this is wishful and helpful?
What do we gain (not hypothetical, but real), what do we risk?
IMHO: diverting from what an upstream provides / proposes in such cases should be well understood and not 'just done'.
And also: why not just do it upstream first and wait for the next upstream tarball? Is this really urgent? Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 10.05.2012 12:02, schrieb Vincent Untz:
Le jeudi 10 mai 2012, à 05:55 -0400, Dominique Leuenberger a écrit :
before you send all kind of SRs (as you already started): Maybe we can finalize the discussion here and get consensus that this is wishful and helpful?
What do we gain (not hypothetical, but real), what do we risk?
IMHO: diverting from what an upstream provides / proposes in such cases should be well understood and not 'just done'.
And also: why not just do it upstream first and wait for the next upstream tarball? Is this really urgent?
Like Richard said: it makes sense to use it for upstream developers and it's a valid distribution optimization (if it really matters) to remove it. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 10.05.2012 13:32, schrieb Stephan Kulow:
Like Richard said: it makes sense to use it for upstream developers and it's a valid distribution optimization (if it really matters) to remove it.
Then a "--disable-ansi" configure option should be pushed upstream IMVHO. -- Stefan Seyfried "Dispatch war rocket Ajax to bring back his body!" -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, May 10, 2012 at 10:35 AM, Stefan Seyfried <stefan.seyfried@googlemail.com> wrote:
Like Richard said: it makes sense to use it for upstream developers and it's a valid distribution optimization (if it really matters) to remove it.
Then a "--disable-ansi" configure option should be pushed upstream IMVHO.
I don't think that's the best way to go about the issue. Can't CXXFLAGS be manipulated somehow in the build environment to override the -ansi options upstream appends? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Le jeudi 10 mai 2012, à 13:32 +0200, Stephan Kulow a écrit :
Am 10.05.2012 12:02, schrieb Vincent Untz:
Le jeudi 10 mai 2012, à 05:55 -0400, Dominique Leuenberger a écrit :
before you send all kind of SRs (as you already started): Maybe we can finalize the discussion here and get consensus that this is wishful and helpful?
What do we gain (not hypothetical, but real), what do we risk?
IMHO: diverting from what an upstream provides / proposes in such cases should be well understood and not 'just done'.
And also: why not just do it upstream first and wait for the next upstream tarball? Is this really urgent?
Like Richard said: it makes sense to use it for upstream developers and it's a valid distribution optimization (if it really matters) to remove it.
Sure, but it makes no sense for a distribution to carry a patch forever for this. It just makes our life more difficult in the long term. 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, it should be of interest to other distros too and so should be upstreamable in some way anyway. Cheers, Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, May 10, 2012 at 12:53 PM, Vincent Untz <vuntz@opensuse.org> wrote:
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, it should be of interest to other distros too and so should be upstreamable in some way anyway.
Cheers,
With that train of thought, -ansi shouldn't be used in --enable-release (if there's such an enable, which there usually is). But that means you have to create and upstream lots of patches. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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 ? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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 :-) Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
El 17/03/13 09:17, Cristian Morales Vega escribió:
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?
OK, we probably want something like this.. the idea of an environment variable still raises a flag here but I dont see any other workable way. Other than what the GCC manual says.. when -ansi is used glibc disables all optimized inline math functions ..(yay!) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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. 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). Richard. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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
El 18/03/13 12:38, Richard Biener escribió:
Yes, the existing rpmlint check. Note that -grecord-gcc-switches is the default starting with GCC 4.8.
Is there any way to make it record the preprocessor defines that were used in the command line? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, 18 Mar 2013, Cristian Rodr?guez wrote:
El 18/03/13 12:38, Richard Biener escribi?:
Yes, the existing rpmlint check. Note that -grecord-gcc-switches is the default starting with GCC 4.8.
Is there any way to make it record the preprocessor defines that were used in the command line?
They are only recorded with -frecord-gcc-switches, not -grecord-gcc-switches. With -grecord-gcc-switches you get <0><b>: Abbrev Number: 1 (DW_TAG_compile_unit) <c> DW_AT_producer : (indirect string, offset: 0x1e): GNU C 4.9.0 20130318 (experimental) -mtune=generic -march=x86-64 -g -frecord-gcc-switches while with -frecord-gcc-switches
readelf -x 4 t.o
Hex dump of section '.GCC.command.line': 0x00000000 2d697072 65666978 202f686f 6d652f61 -iprefix /home/a 0x00000010 6275696c 642f7267 75656e74 6865722f build/rguenther/ 0x00000020 7472756e 6b2d672f 6763632f 2e2e2f6c trunk-g/gcc/../l 0x00000030 69623634 2f676363 2f783836 5f36342d ib64/gcc/x86_64- 0x00000040 756e6b6e 6f776e2d 6c696e75 782d676e unknown-linux-gn 0x00000050 752f342e 382e302f 002d6973 79737465 u/4.8.0/.-isyste 0x00000060 6d202e2f 696e636c 75646500 2d697379 m ./include.-isy 0x00000070 7374656d 202e2f69 6e636c75 64652d66 stem ./include-f 0x00000080 69786564 002d4420 5f464f4f 3d330074 ixed.-D _FOO=3.t 0x00000090 2e63002d 6d74756e 653d6765 6e657269 .c.-mtune=generi 0x000000a0 63002d6d 61726368 3d783836 2d363400 c.-march=x86-64. 0x000000b0 2d67002d 66726563 6f72642d 6763632d -g.-frecord-gcc- 0x000000c0 73776974 63686573 00 switches. I suppose -frecord-gcc-switches output might be easier to replace the existing .comment.SUSE.OPTs section handling in OBS post-processing. Richard. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 03/18/2013 09:47 AM, Richard Biener wrote:
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).
That will certainly be helpful, unfortunately it does not fix anything. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, 18 Mar 2013, Cristian Rodr?guez wrote:
On 03/18/2013 09:47 AM, Richard Biener wrote:
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).
That will certainly be helpful, unfortunately it does not fix anything.
Well, if you want to "fix" things then fix them explicitely. By for example appending -std=gnu99 to RPM_OPT_FLAGS. Ok I know that will not work, but consider adding a switch like -fgnu that just switches the dialect flavor (which might even be upstreamable). Richard. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
El 10/05/12 05:55, Dominique Leuenberger a.k.a DimStar escribió:
Christian,
before you send all kind of SRs (as you already started):
I wrote this email _after_ the SRs..
What do we gain (not hypothetical, but real), what do we risk?
Did you read the link I placed at the start of the thread ? http://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html#Other-Builtins using -ansi disables usage of most if not all of the functions listed there, which are optimized according to the platform. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Quoting Cristian Rodríguez <crrodriguez@opensuse.org>:
Hi:
when -ansi is used and (defined(_GNU_SOURCE) || (_XOPEN_SOURCE >= 700 || _POSIX_C_SOURCE >= 200809L)) is false, there is no stpcpy prototype and hence no optimization.
Christian, First: I appreciate the way you initially brought this topic up for discussion... BUT: Then you went ahead and 'implemented' the change, even though concerns and questions were raised. This in itself I don't consider 'bad' yet, but the fact that you went over other maintainers of projects which you are also maintainer of and ignoring their questions is considered hostile (at least by me). At least wait out the discussion and see what's coming out of it. Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 10.05.2012 13:34, schrieb Dominique Leuenberger a.k.a DimStar:
Quoting Cristian Rodríguez <crrodriguez@opensuse.org>:
Hi:
when -ansi is used and (defined(_GNU_SOURCE) || (_XOPEN_SOURCE >= 700 || _POSIX_C_SOURCE >= 200809L)) is false, there is no stpcpy prototype and hence no optimization.
Christian,
Hi Dominik,
First: I appreciate the way you initially brought this topic up for discussion...
BUT: Then you went ahead and 'implemented' the change, even though concerns and questions were raised. This in itself I don't consider 'bad' yet, but the fact that you went over other maintainers of projects which you are also maintainer of and ignoring their questions is considered hostile (at least by me).
This is something that I don't hear for the first time - especially about Cristian I have to say. I don't think we should add such rules into our software, but if there are several people maintainer in the project, we should give them a chance to review instead of stepping on each other's shoes. Unless it's 100% clear it's 100% safe - I don't think there is any need to review other people's typo fixes. And while there is certainly a timeout associated with other people stepping up, this timeout is not generic, but may depend on the project. E.g. Stefan clearly said he's on vacation, so X11:Xorg did not see the reaction time Stefan is famous for (especially at 4am his time :) And yes, I had my share of critism on the topic of stepping on other's shoes too :) Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 9 May 2012 22:19, Cristian Rodríguez <crrodriguez@opensuse.org> wrote:
Hi:
Will be cool if rpmlint could warn when upstream packages attempt to use the -ansi gcc option because it inhibits usage of gcc builtin functions while optimizing (list here --> http://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html#Other-Builtins) most recently it caught my attention that it also disables the new "optimize-strlen" pass in gcc 4.7, in particular this:
"for hosted compilations where stpcpy is available in the runtime and headers provide its prototype, e.g.
void foo (char *a, const char *b, const char *c, const char *d) { strcpy (a, b); strcat (a, c); strcat (a, d); }
can be optimized into:
void foo (char *a, const char *b, const char *c, const char *d) { strcpy (stpcpy (stpcpy (a, b), c), d); } "
when -ansi is used and (defined(_GNU_SOURCE) || (_XOPEN_SOURCE >= 700 || _POSIX_C_SOURCE >= 200809L)) is false, there is no stpcpy prototype and hence no optimization.
Thoughts ?
Can you explain to me why in https://build.opensuse.org/package/rdiff?linkrev=base&package=libebml&project=multimedia%3Alibs&rev=29 you added "-D_GNU_SOURCE" to the CFLAGS? I would have thought it was enough removing the use of "-ansi -fno-gnu-keywords". -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
El 19/03/13 19:10, Cristian Morales Vega escribió:
I would have thought it was enough removing the use of "-ansi -fno-gnu-keywords".
No, it is not.. removing -ansi or -fno-gnu-keywords do not mean GNU implementations are always prefered at compile time.. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
El 19/03/13 19:10, Cristian Morales Vega escribió:
Can you explain to me why in https://build.opensuse.org/package/rdiff?linkrev=base&package=libebml&project=multimedia%3Alibs&rev=29 you added "-D_GNU_SOURCE" to the CFLAGS? I would have thought it was enough removing the use of "-ansi -fno-gnu-keywords".
In this particular example it does not matter either, the code is compiled with g++ where _GNU_SOURCE is always unconditionally defined anyway. cat test.cpp #define _GNU_SOURCE int main(void) { return 0; } g++ test.cpp g++ test.cpp test.cpp:1:0: warning: "_GNU_SOURCE" redefined [enabled by default] #define _GNU_SOURCE ^ <command-line>:0:0: note: this is the location of the previous definition -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (9)
-
Claudio Freire -
Cristian Morales Vega -
Cristian Rodríguez -
Dominique Leuenberger a.k.a DimStar -
Richard Biener -
Richard Guenther
-
Stefan Seyfried -
Stephan Kulow -
Vincent Untz