similar to: PROPOSAL: Extend inline asm syntax with size spec

On Sun, Dec 16, 2018 at 12:29 PM Nadav Amit <namit at vmware.com> wrote: > > > On Dec 15, 2018, at 6:50 PM, Masahiro Yamada <yamada.masahiro at socionext.com> wrote: > > > > Revert the following 9 commits: > > > > [1] 5bdcd510c2ac ("x86/jump-labels: Macrofy inline assembly code to > > work around GCC inlining bugs") > > >

* Segher Boessenkool <segher at kernel.crashing.org> wrote: > On Mon, Oct 08, 2018 at 11:07:46AM +0200, Richard Biener wrote: > > On Mon, 8 Oct 2018, Segher Boessenkool wrote: > > > On Sun, Oct 07, 2018 at 03:53:26PM +0000, Michael Matz wrote: > > > > On Sun, 7 Oct 2018, Segher Boessenkool wrote: > > > > > On Sun, Oct 07, 2018 at 11:18:06AM

Hi Segher, On Sun, Dec 2, 2018 at 3:48 PM Segher Boessenkool <segher at kernel.crashing.org> wrote: > > On Fri, Nov 30, 2018 at 10:06:02AM +0100, Boris Petkov wrote: > > On November 29, 2018 1:25:02 PM GMT+01:00, Segher Boessenkool <segher at kernel.crashing.org> wrote: > > >This will only be fixed from GCC 9 on, if the compiler adopts it. The > >

Revert the following commits: - 5bdcd510c2ac9efaf55c4cbd8d46421d8e2320cd ("x86/jump-labels: Macrofy inline assembly code to work around GCC inlining bugs") - d5a581d84ae6b8a4a740464b80d8d9cf1e7947b2 ("x86/cpufeature: Macrofy inline assembly code to work around GCC inlining bugs") - 0474d5d9d2f7f3b11262f7bf87d0e7314ead9200. ("x86/extable: Macrofy inline assembly

Revert the following commits: - 5bdcd510c2ac9efaf55c4cbd8d46421d8e2320cd ("x86/jump-labels: Macrofy inline assembly code to work around GCC inlining bugs") - d5a581d84ae6b8a4a740464b80d8d9cf1e7947b2 ("x86/cpufeature: Macrofy inline assembly code to work around GCC inlining bugs") - 0474d5d9d2f7f3b11262f7bf87d0e7314ead9200. ("x86/extable: Macrofy inline assembly

On Wed, Oct 10, 2018 at 01:54:33PM -0500, Segher Boessenkool wrote: > It would be great to hear from kernel people if it works adequately for > what you guys want it for :-) Sure, ping me when you have the final version and I'll try to build gcc with it and do some size comparisons. Thx. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the

On Wed, Oct 10, 2018 at 01:54:33PM -0500, Segher Boessenkool wrote: > It would be great to hear from kernel people if it works adequately for > what you guys want it for :-) Sure, ping me when you have the final version and I'll try to build gcc with it and do some size comparisons. Thx. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the

I couldn't resist: izeof(synth_buffs) = sizeof(float)*2*2*0x120 = 4 * 4 * 0x120 = 0x1200 = 4608 -Anish > -----Original Message----- > From: Segher Boessenkool [mailto:segher@chello.nl] > Sent: Monday, July 02, 2001 6:34 PM > To: vorbis-dev@xiph.org > Subject: Re: [vorbis-dev] ogg vorbis dynamic memory allocation. > > > > > Firelight Multimedia wrote: >

Thread-split from the vorbis-mailing list ("Vorbis determined to be as good as MPC at 128 kbps!") <p>On Sun, 30 May 2004, Segher Boessenkool wrote: [Steven So] SS>> If iTunes AAC can encode castanets with much less pre-echo at SS>> ABR 128 kbps, then hopefully there will be an imaginative SS>> (and non-patented) way of doing this in Vorbis without the SS>>

* Segher Boessenkool <segher at kernel.crashing.org> wrote: > > > More precise *size* estimates, yes. And if the user lies he should not > > > be surprised to get assembler errors, etc. > > > > Yes. > > > > Another option would be if gcc parses the inline asm directly and > > does a more precise size estimation. Which is a lot more involved

On November 29, 2018 1:25:02 PM GMT+01:00, Segher Boessenkool <segher at kernel.crashing.org> wrote: >This will only be fixed from GCC 9 on, if the compiler adopts it. The >kernel wants to support ancient GCC, so it will need to have a >workaround >for older GCC versions anyway. What about backporting it, like Richard says? -- Sent from a small device: formatting sux and

Revert the following 9 commits: [1] 5bdcd510c2ac ("x86/jump-labels: Macrofy inline assembly code to work around GCC inlining bugs") This was partially reverted because it made good cleanups irrespective of the inlining issue; the error message is still unneeded, and the conversion to STATIC_BRANCH_{NOP,JUMP} should be kept. [2] d5a581d84ae6 ("x86/cpufeature:

Quoting Segher Boessenkool <segher@kernel.crashing.org>: > > I wonder if there's a way to "weak-link" against libraries on > > Linux/GNU-ld-so? The idea is that a symbol lookup/relocation isn't > > performed until the call is actually MADE, rather than merely > > referenced. > > That's the default behaviour. No it's not. The

On Thu, Nov 29, 2018 at 02:09:25PM +0100, Richard Biener wrote: > I'd be not opposed to backporting the asm inline support. Even better! :-) > Of course we still have to be happy with it and install the patch ;) > > Are you (kernel folks) happy with asm inline ()? Yes, I think we are: https://lkml.kernel.org/r/20181031125526.GA13219 at hirez.programming.kicks-ass.net Thx. --

Me again, this time not about patents but about wavelets. I've been doing some work on an image compression method which uses Haar wavelets plus VQ and entropy coding, and Segher Boessenkool told me in a private message that you are also doing a video codec. So I searched the archives and read a bunch of posts, but I never did find out any web address. And it's not on xiph.org either. So

I would like to see the following information added to the FAQ at vorbis.com, appended to the "Audio Quality" section. "Uiver," "boa," and "jonI" from OPN's #Vorbis channel contributed and reviewed it. "What does the 'quality' setting mean?" Beginning with vorbislib 1.0-rc3, audio quality is no longer measured in kilobits per

Segher Boessenkool wrote: >> I noticed that you changed all constant floating point numbers >> from double notation (e.g. 3.0) to float notation (3.0f) in the latest >> version >> of Speex (in subversion). >> Did that give any performance increase (because of elimination of the >> float to double and double to float conversions)? > > > It does, with

Greetings, I thought this was supposed to be a list for educated people to discuss serious development of the ogg vorbis project. In light of that, it is amazing to see the level Mr. Segher Boessenkool drops down to in the last posts. More or less calling people insane and accusing them of being on crack and what not. I didn't want to post this on the list, for there is no reason to

Hi folks. My first post over here. While working on a music server optimzation (which ususally goes hand in hand with running pretty low buffers on realtime streams) I figured that certain HiRez flacs were causing XRUNS/hickups on my Linux server platform. The interesting thing is to run into XRUNS even though the stream gets send to a Squeezebox Touch which got a 20s buffer on its receiving

On Fri, 20 May 2005, Segher Boessenkool wrote: >> a new instruction selection framework, > > Hi Chris, > > Any documentation on that insn selection framework? Or just > point me to the source files ;-) There is not enough, but a high level overview is here: http://llvm.cs.uiuc.edu/docs/CodeGenerator.html#instselect The best way is to learn by example, e.g. take a look at