Re: __attribute__((optimize)) and fast-math related oddities
On Tue, Oct 20, 2009 at 1:54 AM, tbp tbp...@gmail.com wrote: On Mon, Oct 19, 2009 at 7:34 PM, Ian Lance Taylor i...@google.com wrote: Please file a bug report. __attribute__((optimize())) is definitely only half-baked. Apparently the code i've posted is just a variation around that 1 year old PR 37565 and if that doesn't work, worrying about the rest is entirely futile. Half baked you say? It's comforting to see that much optimism but couldn't the doc be adjusted a bit to reflect the fact that the baker got hit by a bus or something? I would rather suggest to rip out the half-baked code again. Richard.
Re: __attribute__((optimize)) and fast-math related oddities
On Tue, Oct 20, 2009 at 11:13:48AM -0700, H.J. Lu wrote: On Tue, Oct 20, 2009 at 2:19 AM, Richard Guenther richard.guent...@gmail.com wrote: On Tue, Oct 20, 2009 at 1:54 AM, tbp tbp...@gmail.com wrote: On Mon, Oct 19, 2009 at 7:34 PM, Ian Lance Taylor i...@google.com wrote: Please file a bug report. __attribute__((optimize())) is definitely only half-baked. Apparently the code i've posted is just a variation around that 1 year old PR 37565 and if that doesn't work, worrying about the rest is entirely futile. Half baked you say? It's comforting to see that much optimism but couldn't the doc be adjusted a bit to reflect the fact that the baker got hit by a bus or something? I would rather suggest to rip out the half-baked code again. I agree. The idea is good. But the design and implementation are incomplete. As the original author I do tend to agree, we've been finding all of these places, particularly as we go to more and more tree optimizations. However, the question is what do we do at this particular point given it has been in the compiler for 2 years now. There were a number of people that did ask me for it when I presented the initial thoughts a few years ago. -- Michael Meissner, IBM 4 Technology Place Drive, MS 2203A, Westford, MA, 01886, USA meiss...@linux.vnet.ibm.com
Re: __attribute__((optimize)) and fast-math related oddities
tbp tbp...@gmail.com writes: Merrily trying to make a test-case showing how unmanageable it is to try to override *math* flags per function, i soon had to stop because... Please file a bug report. __attribute__((optimize())) is definitely only half-baked. Ian
Re: __attribute__((optimize)) and fast-math related oddities
On Mon, Oct 19, 2009 at 10:34 AM, Ian Lance Taylor i...@google.com wrote: tbp tbp...@gmail.com writes: Merrily trying to make a test-case showing how unmanageable it is to try to override *math* flags per function, i soon had to stop because... Please file a bug report. __attribute__((optimize())) is definitely only half-baked. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37565 -- H.J.
Re: __attribute__((optimize)) and fast-math related oddities
On Mon, Oct 19, 2009 at 7:34 PM, Ian Lance Taylor i...@google.com wrote: Please file a bug report. __attribute__((optimize())) is definitely only half-baked. Apparently the code i've posted is just a variation around that 1 year old PR 37565 and if that doesn't work, worrying about the rest is entirely futile. Half baked you say? It's comforting to see that much optimism but couldn't the doc be adjusted a bit to reflect the fact that the baker got hit by a bus or something? PS: i'm sorry that i've missed that PR in my search, but i presumed the issue was much more specific.
