Re: Deprecating basic asm in a function - What now?

On Mon, Jul 4, 2016 at 12:09 PM, Frank Ch. Eigler wrote: > jwakely.gcc wrote: > >> [...] (When we switched Fedora to using GCC 6, with C++14 enabled by >> default, dozens and dozens of C++ packages failed to compile, >> because even in 2016 nobody had ever tried to compile them

Re: Deprecating basic asm in a function - What now?

On 07/04/2016 03:43 PM, Jonathan Wakely wrote: On 22 June 2016 at 10:28, David Wohlferd wrote: And I *get* that it takes time to re-write this, and people have schedules, lives, a need for sleep. But even under the most insanely aggressive schedule I can imagine (if gcc continue to release

Re: Deprecating basic asm in a function - What now?

jwakely.gcc wrote: > [...] (When we switched Fedora to using GCC 6, with C++14 enabled by > default, dozens and dozens of C++ packages failed to compile, > because even in 2016 nobody had ever tried to compile them with > C++11 features enabled.) And one shouldn't blame those that choose to

Re: Deprecating basic asm in a function - What now?

On 04/07/16 14:43, Jonathan Wakely wrote: > It doesn't matter how much warning people have to fix such things, > most of them won't do it. Then at the last minute some poor person has > to spend days or weeks going through other people's code fixing all > the problems... ...and breaking

Re: Deprecating basic asm in a function - What now?

On 22 June 2016 at 10:28, David Wohlferd wrote: > And I *get* that it takes time to re-write this, and people have schedules, > lives, a need for sleep. But even under the most insanely aggressive > schedule I can imagine (if gcc continue to release ~1/year), it will be at > least a year before

Re: Deprecating basic asm in a function - What now?

On 22 June 2016 at 20:28, Andrew Pinski wrote: > On Wed, Jun 22, 2016 at 12:26 PM, Manuel López-Ibáñez > wrote: >> On 22 June 2016 at 19:05, Andrew Pinski wrote: >>> Note each target in gas has its own way of parsing assembly code

Re: Deprecating basic asm in a function - What now?

On Wed, Jun 22, 2016 at 12:26 PM, Manuel López-Ibáñez wrote: > On 22 June 2016 at 19:05, Andrew Pinski wrote: >> On Wed, Jun 22, 2016 at 10:59 AM, Manuel López-Ibáñez >> wrote: >>> On 22/06/16 10:02, Florian Weimer wrote: GCC

Re: Deprecating basic asm in a function - What now?

On 22 June 2016 at 19:05, Andrew Pinski wrote: > On Wed, Jun 22, 2016 at 10:59 AM, Manuel López-Ibáñez > wrote: >> On 22/06/16 10:02, Florian Weimer wrote: >>> GCC could parse the assembly instructions and figure out the clobbers. >> >> >> Which is also

Re: Deprecating basic asm in a function - What now?

On Wed, Jun 22, 2016 at 10:59 AM, Manuel López-Ibáñez wrote: > On 22/06/16 10:02, Florian Weimer wrote: >> >> On 06/21/2016 06:53 PM, Andrew Haley wrote: >>> >>> Me too. I wonder if there's anything else we can do to make basic asm >>> in a function a bit less of a time

Re: Deprecating basic asm in a function - What now?

On 22/06/16 10:02, Florian Weimer wrote: On 06/21/2016 06:53 PM, Andrew Haley wrote: Me too. I wonder if there's anything else we can do to make basic asm in a function a bit less of a time bomb. GCC could parse the assembly instructions and figure out the clobbers. Which is also needed

Re: Deprecating basic asm in a function - What now?

On 06/22/2016 09:23 AM, James Greenhalgh wrote: On the other hand, some of the the x86_64 examples in lib/raid6/sse2.c are super scary and have back-to-back instructions with hard-coded registers... asm volatile("pcmpgtb %xmm4,%xmm5"); asm volatile("paddb %xmm4,%xmm4");

Re: Deprecating basic asm in a function - What now?

On Mon, Jun 20, 2016 at 08:01:24PM +0200, Michael Matz wrote: > You see, the experiment shows that there's a gazillion uses of basic asms > out there. I applied the proposed patch and built myself an allyesconfig AArch64 linux kernel, the results were not pretty... make | grep "warning:

Re: Deprecating basic asm in a function - What now?

On 22/06/16 09:59, Florian Weimer wrote: > On 06/20/2016 07:40 PM, Andrew Haley wrote: >> On 20/06/16 18:36, Michael Matz wrote: >>> I see zero gain by deprecating them and only churn. What would be the >>> advantage again? >> >> Correctness. It is very likely that many of these basic asms are

Re: Deprecating basic asm in a function - What now?

On Wed, Jun 22, 2016 at 02:23:46AM -0700, David Wohlferd wrote: > I don't have a sample of people accessing local variables, but I do have one > where someone was using 'scratch' registers in BAIF assuming the compiler > would just "handle it." And before you call that guy a dummy, let me point >

Re: Deprecating basic asm in a function - What now?

On 6/21/2016 9:43 AM, Jeff Law wrote: > I think there's enough resistance to deprecating basic asms within a function that we should probably punt that idea. I don't disagree that there has been pushback. I just wish less of it was of the form "Because I don't wanna." A few examples of

Re: Deprecating basic asm in a function - What now?

In the end, my problems with basic-asm-in-functions (BAIF) come down to reliably generating correct code. Optimizations are based on the idea of "you can safely modify x if you can prove y." But given that basic asm are opaque blocks, there is no way to prove, well, much of anything. Adding

Re: Deprecating basic asm in a function - What now?

On 06/21/2016 06:53 PM, Andrew Haley wrote: > Me too. I wonder if there's anything else we can do to make basic asm > in a function a bit less of a time bomb. GCC could parse the assembly instructions and figure out the clobbers. Florian

Re: Deprecating basic asm in a function - What now?

On 06/20/2016 07:40 PM, Andrew Haley wrote: > On 20/06/16 18:36, Michael Matz wrote: >> I see zero gain by deprecating them and only churn. What would be the >> advantage again? > > Correctness. It is very likely that many of these basic asms are not > robust in the face of compiler changes

Re: Deprecating basic asm in a function - What now?

On Tue, Jun 21, 2016 at 06:29:45PM +, Bernd Edlinger wrote: > I do not like the idea to deprecate the basic asm at all, I must admit, > but I think if we added a warning, that just contains a positive information, > like > "warning: basic asm semantic has been changed to implicitly clobber

Re: Deprecating basic asm in a function - What now?

On 21/06/2016 17:53, Andrew Haley wrote: > On 21/06/16 17:43, Jeff Law wrote: > > I think there's enough resistance to deprecating basic asms within a > > function that we should probably punt that idea. > > > > I do think we should look to stomp out our own uses of basic asms > > within

Re: Deprecating basic asm in a function - What now?

On 21/06/16 17:43, Jeff Law wrote: > I think there's enough resistance to deprecating basic asms within a > function that we should probably punt that idea. > > I do think we should look to stomp out our own uses of basic asms > within functions just from a long term maintenance standpoint. > >

Re: Deprecating basic asm in a function - What now?

On 06/21/2016 10:33 AM, Andrew Haley wrote: Hi, On 21/06/16 13:08, Michael Matz wrote: On Tue, 21 Jun 2016, Andrew Haley wrote: As said in the various threads about basic asms, all correctness problems can be solved by making GCC more conservative in handling them (or better said: not

Re: Deprecating basic asm in a function - What now?

Hi, On 21/06/16 13:08, Michael Matz wrote: > On Tue, 21 Jun 2016, Andrew Haley wrote: > >>> As said in the various threads about basic asms, all correctness >>> problems can be solved by making GCC more conservative in handling >>> them (or better said: not making it less conservative). >> >>

Re: Deprecating basic asm in a function - What now?

Hi, On Tue, 21 Jun 2016, Andrew Haley wrote: > > As said in the various threads about basic asms, all correctness > > problems can be solved by making GCC more conservative in handling > > them (or better said: not making it less conservative). > > Well, yes. That's exactly why we've agreed

Re: Deprecating basic asm in a function - What now?

Hi, On 20/06/16 19:01, Michael Matz wrote: > On Mon, 20 Jun 2016, Andrew Haley wrote: > >> On 20/06/16 18:36, Michael Matz wrote: >>> I see zero gain by deprecating them and only churn. What would be the >>> advantage again? >> >> Correctness. > > As said in the various threads about basic

Re: Deprecating basic asm in a function - What now?

Hi, On Mon, 20 Jun 2016, Andrew Haley wrote: > On 20/06/16 18:36, Michael Matz wrote: > > I see zero gain by deprecating them and only churn. What would be the > > advantage again? > > Correctness. As said in the various threads about basic asms, all correctness problems can be solved by

Re: Deprecating basic asm in a function - What now?

On 20/06/16 18:36, Michael Matz wrote: > I see zero gain by deprecating them and only churn. What would be the > advantage again? Correctness. It is very likely that many of these basic asms are not robust in the face of compiler changes because they don't declare their dependencies and

Re: Deprecating basic asm in a function - What now?

Hi, On Sun, 19 Jun 2016, David Wohlferd wrote: > All basic asm in trunk: 1,105 instances. > - Exclude 273 instances with empty strings leaving 832. > - Exclude 271 instances for boehm-gc project leaving 561. > - Exclude 202 instances for testsuite project leaving 359. > - Exclude 282 instances

Re: Deprecating basic asm in a function - What now?

Given how many embedded ports have #defines in external packages for basic asms for instructions such as nop, enable/disable interrupts, other system-level opcodes, etc... I think this is a bad idea. Even glibc would break. #define enable() asm("eint") __asm__ __volatile__ ("fwait");

Re: Deprecating basic asm in a function - What now?

On 20/06/16 15:52, Segher Boessenkool wrote: > On Mon, Jun 20, 2016 at 03:49:19PM +0100, Andrew Haley wrote: >> On 20/06/16 15:42, Segher Boessenkool wrote: >>> On Mon, Jun 20, 2016 at 02:55:58PM +0100, Andrew Haley wrote: On 20/06/16 14:50, Segher Boessenkool wrote: > If basic asm is

Re: Deprecating basic asm in a function - What now?

On Mon, Jun 20, 2016 at 03:49:19PM +0100, Andrew Haley wrote: > On 20/06/16 15:42, Segher Boessenkool wrote: > > On Mon, Jun 20, 2016 at 02:55:58PM +0100, Andrew Haley wrote: > >> On 20/06/16 14:50, Segher Boessenkool wrote: > >>> If basic asm is deprecated, that means some time later it will be >

Re: Deprecating basic asm in a function - What now?

On 20/06/16 15:42, Segher Boessenkool wrote: > On Mon, Jun 20, 2016 at 02:55:58PM +0100, Andrew Haley wrote: >> On 20/06/16 14:50, Segher Boessenkool wrote: >>> If basic asm is deprecated, that means some time later it will be >>> removed, at which time an asm without : can be used as extended asm

Re: Deprecating basic asm in a function - What now?

On Mon, Jun 20, 2016 at 02:55:58PM +0100, Andrew Haley wrote: > On 20/06/16 14:50, Segher Boessenkool wrote: > > If basic asm is deprecated, that means some time later it will be > > removed, at which time an asm without : can be used as extended asm > > Not exactly: it'd be an asm with no

Re: Deprecating basic asm in a function - What now?

On 20/06/16 14:50, Segher Boessenkool wrote: > If basic asm is deprecated, that means some time later it will be > removed, at which time an asm without : can be used as extended asm Not exactly: it'd be an asm with no inputs, no outputs, and no clobbers i.e. no effects. Andrew.

Re: Deprecating basic asm in a function - What now?

On Mon, Jun 20, 2016 at 12:00:16AM -0700, Andrew Pinski wrote: > Also I think the other place where we should accept basic asm is for > "nop" instructions. I have seen people use that heavily. And anything else that means the same as basic asm and as extended asm. > Note really I don't like the

Re: Deprecating basic asm in a function - What now?

On Mon, 20 Jun 2016, Andrew Haley wrote: > On 20/06/16 08:00, Andrew Pinski wrote: > > + /* Acceptable. */ > > + asm (" "); /* { dg-warning "Deprecated: asm in function without > > extended syntax" } */ > > This is incorrect English. It should be > > "Deprecated: asm without extended

Re: Deprecating basic asm in a function - What now?

On 20/06/16 08:00, Andrew Pinski wrote: > + /* Acceptable. */ > + asm (" "); /* { dg-warning "Deprecated: asm in function without > extended syntax" } */ This is incorrect English. It should be "Deprecated: asm without extended syntax in function" because it's the asm that is missing the

Re: Deprecating basic asm in a function - What now?

On Sun, Jun 19, 2016 at 11:43 PM, David Wohlferd wrote: > Perhaps this post should be directed toward port maintainers? > > Since several global maintainers have now suggested it, I have created a > patch that deprecates basic asm when used in a function (attached). It

Deprecating basic asm in a function - What now?

Perhaps this post should be directed toward port maintainers? Since several global maintainers have now suggested it, I have created a patch that deprecates basic asm when used in a function (attached). It excludes (ie does not deprecate) top level asm, asm in "naked" functions, asm with