Re: typeof and operands in named address spaces

On Wed, Nov 4, 2020 at 7:33 PM Uros Bizjak via Gcc wrote: > > Hello! > > I was looking at the recent linux patch series [1] where segment > qualifiers (named address spaces) were introduced to handle percpu > variables. In the patch [2], the author mentions that: > > --q-- > Unfortunately, gcc doe

Re: Wrong insn scheduled by Sched1 pass

Jojo 在 2020年11月5日 +0800 AM2:25，Jim Wilson ，写道： > On Mon, Nov 2, 2020 at 11:45 PM Jojo R wrote: > > From origin insn seqs, I think the insn 'r500=unspec[r100] 300’ is in > > Good place because of the bypass of my pipeline description, it is not > > needed to schedule. > > ... > > Is there any wa

答复: Disassemble the .lib file compiled with gcc-arm-8.3-2019.03-x86_64-arm-eabi compilation tool chain, and found that malloc is optimized to calloc.

Thanks. 发件人: Richard Earnshaw 发送时间: 2020年11月4日 23:45:39 收件人: YaRu Wei(魏亚茹); gcc@gcc.gnu.org 主题: Re: Disassemble the .lib file compiled with gcc-arm-8.3-2019.03-x86_64-arm-eabi compilation tool chain, and found that malloc is optimized to calloc. On 30/10/2020 0

typeof and operands in named address spaces

Hello! I was looking at the recent linux patch series [1] where segment qualifiers (named address spaces) were introduced to handle percpu variables. In the patch [2], the author mentions that: --q-- Unfortunately, gcc does not provide a way to remove segment qualifiers, which is needed to use ty

Re: Wrong insn scheduled by Sched1 pass

On Mon, Nov 2, 2020 at 11:45 PM Jojo R wrote: > From origin insn seqs, I think the insn 'r500=unspec[r100] 300’ is in > Good place because of the bypass of my pipeline description, it is not > needed to schedule. > ... > Is there any way to control my case ? > Or my description of pipeline is not

Re: Disassemble the .lib file compiled with gcc-arm-8.3-2019.03-x86_64-arm-eabi compilation tool chain, and found that malloc is optimized to calloc.

On 30/10/2020 08:53, YaRu Wei(魏亚茹) wrote: > Dear gcc: > I find that disassemble the .lib file compiled with > gcc-arm-8.3-2019.03-x86_64-arm-eabi compilation tool chain, and found that > malloc is optimized to calloc. I want to know under what circumstances malloc > will be optimized to calloc?

Re: Symbol + Constant output.

Hi. Hongyu Wang wrote: 3. are you intending to update the tests? Yes, so could you tell me what does missing “_” means? I have some trouble building darwin target for now. Darwin uses a USER_LABEL_PREFIX of ‘_’ (there are a small number of targets that do this). So public symbols begin wi

Re: Symbol + Constant output.

Hi, > 1. might I suggest using the {} form of quoting these regexes - it makes > them much more readable. Sure. > 2. I think there are some syntax errors in the regexes for these tests > (because it’s very hard to check them when using the “” quotes). > > "(?:movdqu|movups)\[ \\t\]+\[^\n\]

Re: git tag creation for misc/first-auto-changelog

On 11/3/20 7:43 PM, Jonathan Wakely wrote: On Tue, 3 Nov 2020 at 17:40, Martin Liška wrote: Hello. I would like to create a git tag for a point when we started using automatically-generated ChangeLog files. It's: cfdff3eeb902958d3eefe60d5712d64e2367843f and I would name it something like: mi

Re: Symbol + Constant output.

Hi, Hongyu Wang via Gcc wrote: Maybe those scan-asm regexp are too strict and should be relaxed a bit. I agree with this, since with -fPIC the code produced would be different, just use symbol + constant may be too strict. I think the scan-assembler could be reduced to /* { dg-final { scan-

Re: Symbol + Constant output.

> Maybe those scan-asm regexp are too strict and should be relaxed a > bit. I agree with this, since with -fPIC the code produced would be different, just use symbol + constant may be too strict. I think the scan-assembler could be reduced to /* { dg-final { scan-assembler "(?:movdqu|movups)\[ \\