[PATCH] doc: discourage use of __attribute__((optimize())) in production code

[PATCH] doc: discourage use of __attribute__((optimize())) in production code

[Markus Trippelsdorf]

Many developers are still using __attribute__((optimize())) in
production code, although it quite broken. 

	* doc/extend.texi (Common Function Attributes) [optimize]:
	Discourage use of the optimize attribute.

diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 883d9b334ab5..a1359f5579ce 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -3021,10 +3021,8 @@ that affect more than one function.
 @xref{Function Specific Option Pragmas}, for details about the
 @samp{#pragma GCC optimize} pragma.
 
-This can be used for instance to have frequently-executed functions
-compiled with more aggressive optimization options that produce faster
-and larger code, while other functions can be compiled with less
-aggressive options.
+This attribute should only be used for debugging purposes.  It is not
+suitable for production code.
 
 @item pure
 @cindex @code{pure} function attribute
-- 
Markus

Re: [PATCH] doc: discourage use of __attribute__((optimize())) in production code

[Andi Kleen]

Markus Trippelsdorf <markus@trippelsdorf.de> writes:

> Many developers are still using __attribute__((optimize())) in
> production code, although it quite broken. 

Wo reads documentation? @) If you want to discourage it better warn once
at runtime.

-Andi

Re: [PATCH] doc: discourage use of __attribute__((optimize())) in production code

[Richard Biener]

On Sun, Dec 13, 2015 at 9:03 PM, Andi Kleen <andi@firstfloor.org> wrote:
> Markus Trippelsdorf <markus@trippelsdorf.de> writes:
>
>> Many developers are still using __attribute__((optimize())) in
>> production code, although it quite broken.
>
> Wo reads documentation? @) If you want to discourage it better warn once
> at runtime.

We're also quite heavily using it in LTO internally now.

Richard.

> -Andi

Re: [PATCH] doc: discourage use of __attribute__((optimize())) in production code

[Trevor Saunders]

On Mon, Dec 14, 2015 at 10:01:27AM +0100, Richard Biener wrote:
> On Sun, Dec 13, 2015 at 9:03 PM, Andi Kleen <andi@firstfloor.org> wrote:
> > Markus Trippelsdorf <markus@trippelsdorf.de> writes:
> >
> >> Many developers are still using __attribute__((optimize())) in
> >> production code, although it quite broken.
> >
> > Wo reads documentation? @) If you want to discourage it better warn once
> > at runtime.
> 
> We're also quite heavily using it in LTO internally now.

besides that does this really make sense?  I suspect very few people are
using this for the fun of it.  I'd guess most usage is to disable
optimizations to work around bugs, or maybe trying to get a very hot
function optimized more.  Either way I suspect its only used by people
with good reason and this would just really iritate them.

Trev

> 
> Richard.
> 
> > -Andi

Re: [PATCH] doc: discourage use of __attribute__((optimize())) in production code

[Markus Trippelsdorf]

On 2015.12.14 at 11:20 -0500, Trevor Saunders wrote:
> On Mon, Dec 14, 2015 at 10:01:27AM +0100, Richard Biener wrote:
> > On Sun, Dec 13, 2015 at 9:03 PM, Andi Kleen <andi@firstfloor.org> wrote:
> > > Markus Trippelsdorf <markus@trippelsdorf.de> writes:
> > >
> > >> Many developers are still using __attribute__((optimize())) in
> > >> production code, although it quite broken.
> > >
> > > Wo reads documentation? @) If you want to discourage it better warn once
> > > at runtime.
> > 
> > We're also quite heavily using it in LTO internally now.
> 
> besides that does this really make sense?  I suspect very few people are
> using this for the fun of it.  I'd guess most usage is to disable
> optimizations to work around bugs, or maybe trying to get a very hot
> function optimized more.  Either way I suspect its only used by people
> with good reason and this would just really iritate them.

Well, if you look at bugzilla you'll find several wrong code bugs caused
by this attribute, e.g.: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59262

Also Richi stated in the past (I quote):
»I consider the optimize attribute code seriously broken and
unmaintained (but sometimes useful for debugging - and only that).«

https://gcc.gnu.org/ml/gcc/2012-07/msg00201.html

-- 
Markus

Re: [PATCH] doc: discourage use of __attribute__((optimize())) in production code

[Manuel López-Ibáñez]

On 14/12/15 16:40, Markus Trippelsdorf wrote:
> On 2015.12.14@11:20 -0500, Trevor Saunders wrote:
>> On Mon, Dec 14, 2015@10:01:27AM +0100, Richard Biener wrote:
>>> On Sun, Dec 13, 2015@9:03 PM, Andi Kleen <andi@firstfloor.org> wrote:
>>>> Markus Trippelsdorf <markus@trippelsdorf.de> writes:
>>>>
>>>>> Many developers are still using __attribute__((optimize())) in
>>>>> production code, although it quite broken.
>>>>
>>>> Wo reads documentation? @) If you want to discourage it better warn once
>>>> @runtime.
>>>
>>> We're also quite heavily using it in LTO internally now.
>>
>> besides that does this really make sense?  I suspect very few people are
>> using this for the fun of it.  I'd guess most usage is to disable
>> optimizations to work around bugs, or maybe trying to get a very hot
>> function optimized more.  Either way I suspect its only used by people
>> with good reason and this would just really iritate them.
>
> Well, if you look@bugzilla you'll find several wrong code bugs caused
> by this attribute, e.g.: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59262
>
> Also Richi stated in the past (I quote):
> »I consider the optimize attribute code seriously broken and
> unmaintained (but sometimes useful for debugging - and only that).«
>
> https://gcc.gnu.org/ml/gcc/2012-07/msg00201.html

It is even a FAQ: https://gcc.gnu.org/wiki/FAQ#optimize_attribute_broken

Cheers,

Manuel.

Re: [PATCH] doc: discourage use of __attribute__((optimize())) in production code

[Trevor Saunders]

On Mon, Dec 14, 2015 at 05:40:57PM +0100, Markus Trippelsdorf wrote:
> On 2015.12.14 at 11:20 -0500, Trevor Saunders wrote:
> > On Mon, Dec 14, 2015 at 10:01:27AM +0100, Richard Biener wrote:
> > > On Sun, Dec 13, 2015 at 9:03 PM, Andi Kleen <andi@firstfloor.org> wrote:
> > > > Markus Trippelsdorf <markus@trippelsdorf.de> writes:
> > > >
> > > >> Many developers are still using __attribute__((optimize())) in
> > > >> production code, although it quite broken.
> > > >
> > > > Wo reads documentation? @) If you want to discourage it better warn once
> > > > at runtime.
> > > 
> > > We're also quite heavily using it in LTO internally now.
> > 
> > besides that does this really make sense?  I suspect very few people are
> > using this for the fun of it.  I'd guess most usage is to disable
> > optimizations to work around bugs, or maybe trying to get a very hot
> > function optimized more.  Either way I suspect its only used by people
> > with good reason and this would just really iritate them.
> 
> Well, if you look at bugzilla you'll find several wrong code bugs caused
> by this attribute, e.g.: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59262

is that wrong code? it looks to me like somebody thinks its missed
optimization, and personally I'd say its not a bug just not fully
expected behavior.

> Also Richi stated in the past (I quote):
> »I consider the optimize attribute code seriously broken and
> unmaintained (but sometimes useful for debugging - and only that).«
> 
> https://gcc.gnu.org/ml/gcc/2012-07/msg00201.html

I'm certainly not recommending its use, and noting in docs that its
results can be suprising seems reasonable, but runtime warnings seems
likely to annoy users.

Trev

> 
> -- 
> Markus

Re: [PATCH] doc: discourage use of __attribute__((optimize())) in production code

[Jeff Law]

On 12/13/2015 01:19 AM, Markus Trippelsdorf wrote:
> Many developers are still using __attribute__((optimize())) in
> production code, although it quite broken.
>
> 	* doc/extend.texi (Common Function Attributes) [optimize]:
> 	Discourage use of the optimize attribute.
I went back and reviewed the discussion as well as the BZs.  I think 
this patch is fine for the trunk.  I don't think a runtime warning is 
likely to be looked upon favorably by most users.

jeff