Re: subreg vs vec_select

Hi! On Thu, Sep 10, 2020 at 12:21:47PM +0200, Ilya Leoshkevich wrote: > On Wed, 2020-09-09 at 16:09 -0500, Segher Boessenkool wrote: > > On Wed, Sep 09, 2020 at 11:50:56AM +0200, Ilya Leoshkevich via Gcc > > wrote: > > > I have a vector pseudo containing a single

Re: A problem with one instruction multiple latencies and pipelines

On Thu, Sep 10, 2020 at 11:04:26AM +0100, Richard Sandiford wrote: > Segher Boessenkool writes: > > You can also use some other attributes to classify instructions, you > > don't have to put it all in one "type" attribute. This can of course be > > done later,

Re: A problem with one instruction multiple latencies and pipelines

Hi! On Fri, Sep 11, 2020 at 08:44:54AM +0100, Richard Sandiford wrote: > Segher Boessenkool writes: > > Consider cores that do not care about the "subtype" at all: when using > > just "type", all cores have to test for "foo,foo_subtype", while with &g

Re: A problem with one instruction multiple latencies and pipelines

Hi! On Mon, Sep 14, 2020 at 10:55:35AM +0100, Richard Sandiford wrote: > "Qian, Jianhua" writes: > > - If we cannot resolve it, the existing CPUs' descriptions need > > to be changed. This is not what I expected. > > - If we want to add new attribute to resolve this probl

Re: A problem with one instruction multiple latencies and pipelines

On Mon, Sep 14, 2020 at 08:35:44PM +0100, Richard Sandiford wrote: > Segher Boessenkool writes: > >> Although this looks/sounds complicated, the advantage is that everything > >> remains up-to-date. If we instead added a second attribute and only > >> defined i

Re: Wrong optimization from ‘fwprop’ pass

Hi! On Wed, Sep 23, 2020 at 10:50:52AM +0800, Jojo R wrote: > insn seqs: > > s1: > > __builtin_set_float_convert_mode(0); > r1 = __builtin_load(a1, a2); > r2 = __builtin_float_convert(r1); > __builtin_store(a3, r2); > __builtin_set_float_convert_mode(0); > > s2: >

Re: First set of patches to allow changing the long double default were posted:

Hi! On Wed, Oct 07, 2020 at 08:00:49PM -0400, Michael Meissner wrote: > I looked into this a bit, and I think we want to keep the current behavior (as > modified by the patches). As Joseph says, the _Float types have their own > types, but may/may not use the same modes as other types. Obviously

Re: typeof and operands in named address spaces

On Mon, Nov 09, 2020 at 01:47:13PM +0100, Peter Zijlstra wrote: > > + lots of people and linux-toolchains > > On Wed, Nov 04, 2020 at 07:31:42PM +0100, Uros Bizjak wrote: > > Hello! > > > > I was looking at the recent linux patch series [1] where segment > > qualifiers (named address spaces) wer

Re: typeof and operands in named address spaces

On Tue, Nov 10, 2020 at 09:11:08PM +0100, Peter Zijlstra wrote: > On Tue, Nov 10, 2020 at 10:42:58AM -0800, Nick Desaulniers wrote: > > When I think of qualifiers, I think of const and volatile. I'm not > > sure why the first post I'm cc'ed on talks about "segment" qualifiers. > > Maybe it's in re

Re: typeof and operands in named address spaces

On Tue, Nov 10, 2020 at 08:57:42AM +0100, Peter Zijlstra wrote: > On Mon, Nov 09, 2020 at 11:50:15AM -0800, Nick Desaulniers wrote: > > On Mon, Nov 9, 2020 at 11:46 AM Segher Boessenkool > > wrote: > > > On Mon, Nov 09, 2020 at 01:47:13PM +0100, Peter Zijlstra wrote: >

Re: CSE deletes valid REG_EQUAL?

Hi guys, On Thu, Nov 12, 2020 at 09:10:14PM -0700, Jeff Law wrote: > On 11/12/20 7:02 PM, Xionghu Luo via Gcc wrote: > > The output shows "REQ_EQUAL r118:DI+0x66546b64" is deleted by > > df_remove_dead_eq_notes, > > but r120:DI is not REG_DEAD here, so is it correct here to check insn use > > an

Re: The conditions when convert from double to float is permitted?

On Fri, Dec 11, 2020 at 03:54:44PM +0800, Xionghu Luo wrote: > +cc. > > > On 2020/12/11 14:25, Xionghu Luo via Gcc wrote: > >Thanks, > > > >On 2020/12/10 17:12, Richard Biener wrote: > >>>2) From PR90070: > >>> > >>>double temp1 = (double)r->red; > >>>double temp2 = (double)aggregate.red;

Re: The conditions when convert from double to float is permitted?

On Fri, Dec 11, 2020 at 05:38:30PM +0800, Xionghu Luo wrote: > On 2020/12/11 15:47, Richard Biener wrote: > >> Note that the add/sub sequence is different for (3) and (4) since > >> -funsafe-math-optimizations is implicitly true. "fp-contract=fast" in > >> (1) and (2) could avoid Inf as fmads coul

CC0 removal branch

Hi! I have updated my CC0 removal branch I started in 2019: refs/users/segher/heads/cc0 (yes I know this needs some patch series work; this branch rebases). I have tested it all on powerpc*, and sill test it with cross-compilers to all Linux targets later today. I already know one problem that

Re: More consistency for Git log messages?

On Tue, Dec 29, 2020 at 12:54:53AM +0100, Gerald Pfeifer wrote: > Having spent a bit more time with GCC sources (as opposed to wwwdocs) > recently and looking for prior art to guide me, I noticed there's a > lot of options to specific the ChangeLog file(s) to use. > > And correspondingly a lot o

Re: Should GCC provide __builtin_memcpy_inline like clang does?

On Tue, Jan 19, 2021 at 11:33:56AM +, unlvsur unlvsur via Gcc-help wrote: > I think __builtin_memmove_inline, __builtin_memset_inline can also get > provided. > > That allows better performance for small size copies You normally will get better performance by letting the compiler figure out

Re: rtx_cost of insns

On Mon, Jun 29, 2015 at 05:16:39PM +0930, Alan Modra wrote: > Note that we already have insn_rtx_cost, and it returns a minimum cost > for a SET, so register move insns get a cost of 1 insn. However, > despite insn_rtx_cost starting life in combine.c, even combine doesn't > use it in all whole ins

Re: rtx_cost of insns

On Tue, Jun 30, 2015 at 02:16:19PM +0930, Alan Modra wrote: > On Mon, Jun 29, 2015 at 09:34:40AM -0500, Segher Boessenkool wrote: > > On Mon, Jun 29, 2015 at 05:16:39PM +0930, Alan Modra wrote: > > > Note that we already have insn_rtx_cost, and it returns a minimum cost &

Re: rl78 vs cse vs memory_address_addr_space

On Mon, Jul 06, 2015 at 04:45:35PM -0400, DJ Delorie wrote: > Combine gets as far as this: > > Trying 5 -> 9: > Failed to match this instruction: > (parallel [ > (set (mem/v/j:QI (const_int 240 [0xf0]) [0 MEM[(volatile union > un_per0 *)240B].BIT.no4+0 S1 A16]) > (ior:QI (mem/

Re: rl78 vs cse vs memory_address_addr_space

On Mon, Jul 06, 2015 at 04:58:36PM -0500, Segher Boessenkool wrote: > On Mon, Jul 06, 2015 at 04:45:35PM -0400, DJ Delorie wrote: > > Combine gets as far as this: > > > > Trying 5 -> 9: > > Failed to match this instruction: > > (parallel [ > >

Re: Can shrink-wrapping ever move prologue past an ASM statement?

On Tue, Jul 07, 2015 at 07:53:49PM +0200, Martin Jambor wrote: > I've been asked to look into the item one of > http://permalink.gmane.org/gmane.linux.kernel/1990397 and found out > that at least shrink-wrapping happily moves prologue past an asm > statement which can be bad if the asm statement co

Re: Can shrink-wrapping ever move prologue past an ASM statement?

On Wed, Jul 08, 2015 at 11:23:09AM +0200, Martin Jambor wrote: > > For other archs, e.g. x86-64, you can do > > > > register void *sp asm("%sp"); > > asm volatile("call func" : "+r"(sp)); > Well, I only have had a quick look at where things "go wrong" and have > not spent much time thin

Re: Can shrink-wrapping ever move prologue past an ASM statement?

On Wed, Jul 08, 2015 at 11:22:34AM -0500, Josh Poimboeuf wrote: > > Writing the asm with a clobber of the stack pointer causes all stack > > accesses to go via the frame pointer, which causes pretty horrible > > code. > > As far as I can tell, most (but not all) kernel stack accesses already > occ

Re: Can shrink-wrapping ever move prologue past an ASM statement?

On Wed, Jul 08, 2015 at 03:51:12PM -0500, Josh Poimboeuf wrote: > > > > > For other archs, e.g. x86-64, you can do > > > > > > > > > > register void *sp asm("%sp"); > > > > > asm volatile("call func" : "+r"(sp)); > > I've found that putting "sp" in the clobber list also seems to work:

Re: Can shrink-wrapping ever move prologue past an ASM statement?

On Wed, Jul 08, 2015 at 03:15:12PM -0600, Jeff Law wrote: > >For other archs, e.g. x86-64, you can do > > > > register void *sp asm("%sp"); > > asm volatile("call func" : "+r"(sp)); > > > >I've found that putting "sp" in the clobber list also seems to work: > > > > asm volatile("c

Re: Can shrink-wrapping ever move prologue past an ASM statement?

On Fri, Jul 10, 2015 at 10:02:06AM +0100, Richard Earnshaw wrote: > This isn't going to reliably work for ARM or AArch64. If the only call > within a leaf function is via the ASM the compiler doesn't guarantee to > ensure the stack is aligned to the ABI requirements. Those archs have a link regis

Re: Basic GCC testing question

On Fri, Jul 10, 2015 at 10:43:43AM -0700, Steve Ellcey wrote: > > I have a basic GCC testing question. I built a native GCC and ran: > > make RUNTESTFLAGS='dg.exp' check > > Everything passed and according to the log file it used the unix.exp > as the target-board. But if I try running:

Re: Basic GCC testing question

On Fri, Jul 10, 2015 at 02:14:09PM -0700, Steve Ellcey wrote: > > > make RUNTESTFLAGS='dg.exp --target-board=unix' check > > > > Does it work better if you spell --target_board ? > Arg, I hate it when I do something stupid like that. It would be ince > if runtest gave an error message when it

Re: Using the asm suffix

On Sun, Aug 16, 2015 at 06:33:40PM -0700, David Wohlferd wrote: > As a followup to my update to the inline asm docs, I'm cleaning up the > docs for 'Asm Labels.' The changes I want to make are pretty > straight-forward (attached; comments welcome). But then I came across > this line of code (f

Re: Using the asm suffix

On Sun, Aug 16, 2015 at 06:33:40PM -0700, David Wohlferd wrote: > On systems where an underscore is normally prepended to the name of a C > -function or variable, this feature allows you to define names for the > +variable, this feature allows you to define names for the > linker that do not star

Re: Using the asm suffix

On Mon, Aug 17, 2015 at 09:55:48PM -0700, David Wohlferd wrote: > >> On systems where an underscore is normally prepended to the name of a C > >>-function or variable, this feature allows you to define names for the > >>+variable, this feature allows you to define names for the > >> linker that d

Re: Using the asm suffix

On Wed, Aug 19, 2015 at 02:08:16PM -0700, David Wohlferd wrote: > >>My intent here is to break this clearly into two @subsubheadings: > >>'Assembler names for data' and 'Assembler names for functions'. Since > >>data is the first section, I removed the word 'function' here. > >I missed that, sorry.

Re: Moving to git

On Thu, Aug 20, 2015 at 03:31:52PM -0400, David Malcolm wrote: > If we're going to migrate to git (I hope so), can we also please > *slightly* revise the policy on commit messages, to add meaningful > titles to commits? > > Currently: > https://www.gnu.org/software/gcc/svnwrite.html#checkin says:

Re: Using the asm suffix

On Wed, Aug 19, 2015 at 11:02:14PM -0700, David Wohlferd wrote: > >>how about replacing the existing > >>text ("It does not make sense to use this feature with a non-static > >>local variable since such variables do not have assembler names.") with > >>"Do not use this feature with a non-static loc

Re: [PATCH][www] svnwrite.html: recommend giving checkin messages a title (was Re: Moving to git)

On Fri, Aug 21, 2015 at 07:54:11PM -0400, David Malcolm wrote: > > >> In the git world, the first line of the commit message has special > > >> meaning, being treated as the "title" of the commit. > > > > > > It would be nice if we could use a real commit message, not just a short > > > title line;

Re: [PATCH][www] svnwrite.html: recommend giving checkin messages a title (was Re: Moving to git)

On Sat, Aug 22, 2015 at 10:59:31AM -0400, David Malcolm wrote: > > > +The log message for a checkin should be a single line giving a > > > +descriptive title for the checkin, followed by a blank line, followed by > > > +the complete ChangeLog entry for the change. This is the git convention; > > >

Re: Offer of help with move to git

On Sun, Aug 23, 2015 at 12:26:25PM -0400, Eric S. Raymond wrote: > One way to do it would be to mine the list archives for not just names > but name-date pairs. With a little scripting work that could be processed > into a sequence of map files, each one valid for a known span of dates. The > only

Re: LRA reloads of subregs

On Thu, Sep 03, 2015 at 03:33:56PM -0700, David Miller wrote: > (insn 18631 1099 1100 14 (set (reg:SI 13423) > (subreg:SI (mem/c:QI (plus:SI (reg/f:SI 101 %sfp) > (const_int -14269 [0xc843])) [0 %sfp+-14269 > S1 A8]) 0)) x.c:104 63 {*movsi_insn} > (expr

Re: LRA reloads of subregs

On Thu, Sep 03, 2015 at 11:19:43PM -0700, David Miller wrote: > From: Segher Boessenkool > Date: Thu, 3 Sep 2015 20:26:51 -0500 > > > On Thu, Sep 03, 2015 at 03:33:56PM -0700, David Miller wrote: > >> (insn 18631 1099 1100 14 (set (reg:SI 13423) > >> (

Re: Combined top-down and bottom-up instruction scheduler

On Tue, Sep 08, 2015 at 06:39:19PM +, Aditya K wrote: > IIUC, in the haifa-sched.c, the default scheduling algorithm seems to be > top-down (before reload). > Is there a way to schedule the other way (bottom up), or both ways? > > As a use case for bottom-up or some other heuristic: > Current

Re: dejagnu version update?

On Wed, Sep 16, 2015 at 01:39:42PM -0400, David Malcolm wrote: > AIUI, we specifically need >= 1.5.3 (or a version with a backport) to > get support for multiple load_lib paths mentioned by Bernhard, which is > what motivated this thread (on gcc-patches, before it spread to the gcc > list): We als

Re: Support for targets with widths other than 2^x (Power of 2)

On Thu, Oct 15, 2015 at 02:34:06PM +0200, Ramon Wirsch wrote: > The SpartanMC architecture poses a few additional difficulties as it > is 18 Bits wide. > Our investigations have shown that GCC is on principle capable of that > (it is working right now, although with several limitations). The main >

Re: Proposed doc update for Explicit Reg Vars 1/3

On Mon, Oct 12, 2015 at 03:06:19PM -0700, David Wohlferd wrote: > But now it has annoyed someone who is willing to work on it. And thanks for that :-) > The current menu page has a couple of flaws: > > 1) It tries to condense the entire contents of the other 2 pages into a > single paragraph ea

Re: Proposed doc update for Explicit Reg Vars 2/3

On Mon, Oct 12, 2015 at 04:07:48PM -0700, David Wohlferd wrote: > Index: extend.texi > === > --- extend.texi (revision 228690) > +++ extend.texi (working copy) > @@ -8506,7 +8506,8 @@ > @cindex global register variables >

Re: Proposed doc update for Explicit Reg Vars 3/3

On Mon, Oct 12, 2015 at 04:09:34PM -0700, David Wohlferd wrote: > I was hoping to modify the text to say that local register variables can > "only" be used to call Extended asm. This would greatly simplify this > section. But it is not true: they can be used anywhere any variable can be used. O

Re: Proposed doc update for Explicit Reg Vars 2/3

On Mon, Oct 19, 2015 at 11:14:30PM -0600, Jeff Law wrote: > >>+All global register variable declarations must precede all function > >>+definitions. If such a declaration appears after function definitions, > >>+the declaration would be too late to prevent the register from being used > >>+for oth

Re: Proposed doc update for Explicit Reg Vars 3/3

On Mon, Oct 19, 2015 at 11:25:27PM -0600, Jeff Law wrote: > >>+Defining a register variable does not reserve the register; it > >>+remains available for other uses in places where flow control determines > >>+the variable's value is not live. For this reason, the following uses > > > >This is misl

Re: Proposed doc update for Explicit Reg Vars 3/3

On Mon, Oct 19, 2015 at 11:22:06PM -0600, Jeff Law wrote: > WRT your hope to limit this to only uses in extended asms. That'd be > nice, but that's never been an explicit limitation. I would strongly > hesitate to add that limitation at this point in time. r88265 (from 2004) made explicit that

Re: Proposed doc update for Explicit Reg Vars 3/3

On Tue, Oct 20, 2015 at 10:22:53AM -0600, Jeff Law wrote: > bz21182 has a testcase that's still helped by local register variables. I tried it out, and it now is much worse *with* the reg vars than without (and -O2 vs. -O3 makes no difference at all). It doesn't look to have used the pre-determin

Re: Proposed doc update for Explicit Reg Vars 3/3

On Tue, Oct 20, 2015 at 12:01:26PM -0600, Jeff Law wrote: > On 10/20/2015 11:11 AM, Segher Boessenkool wrote: > >On Tue, Oct 20, 2015 at 10:22:53AM -0600, Jeff Law wrote: > >>bz21182 has a testcase that's still helped by local register variables. > > > >I tri

Re: Proposed doc update for Explicit Reg Vars 2/3

On Tue, Oct 20, 2015 at 09:24:48PM -0700, David Wohlferd wrote: > >>+Registers can be a limited resource on some systems and allowing the > >They are a limited resource on almost all systems. "Scarce resource"? > > "Scarce" it is. I've left the rest alone for the moment, but how would > you fee

Re: Proposed doc update for Explicit Reg Vars 1/3

On Tue, Oct 20, 2015 at 09:14:51PM -0700, David Wohlferd wrote: > >Abot the patches themselves... Hard to review again, sigh... > > I know, and I'm sorry. > > I just can't see any way to completely re-org the text without the patch > becoming a nightmare. I was hoping the html links would make

Re: Proposed doc update for Explicit Reg Vars 3/3

On Thu, Oct 22, 2015 at 12:38:16AM -0700, David Wohlferd wrote: > An updated Local Register Variables patch is attached with the changes > discussed. It also includes removing the extra space after '.' that > Segher has been giving me grief about and Jeff's request re Globals: You must have und

Re: inline asm and multi-alternative constraints

On Fri, Nov 06, 2015 at 03:29:43PM -0700, Jeff Law wrote: > It's never easy to predict whether or not something like this will be > contentious. Worst case is you post, it's contentious, we iterate a bit > and reach some kind of resolution (ok, worst case is no resolution is > reached, but that

Re: inline asm and multi-alternative constraints

On Fri, Nov 06, 2015 at 11:50:40PM -0800, David Wohlferd wrote: > >The same goes for some constraints and almost all output modifiers. > > Are you suggesting more doc changes? Looking thru the pages you reference: > > - Starting with 'modifiers', "=+&" and (reluctantly) "%" seem reasonable > fo

Re: basic asm and memory clobbers

On Sun, Nov 08, 2015 at 04:10:01PM -0800, David Wohlferd wrote: > It seems like a doc update is what is needed to close PR24414 (Old-style > asms don't clobber memory). What is needed to close the bug is to make the compiler work properly. Whether that means clobbering memory or not, I don't muc

Re: basic asm and memory clobbers

On Tue, Nov 17, 2015 at 02:31:29PM -0700, Jeff Law wrote: > >- There is a plausible work-around with extended asm, which (mostly) has > >clear semantics regarding clobbers. > Converting an old-style asm to extended asm can be painful. ANd in the > case of legacy code the conversion process itself

Re: basic asm and memory clobbers

On Thu, Nov 19, 2015 at 05:23:55PM -0800, David Wohlferd wrote: > For that reason, I'd like to propose adding 2 new clobbers to extended > asm as part of this work: > > "clobberall" - This gives extended the same semantics as whatever the > new basic asm will be using. > "clobbernone" - This giv

Re: basic asm and memory clobbers

On Fri, Nov 20, 2015 at 02:45:05AM -0800, David Wohlferd wrote: > On 11/19/2015 7:14 PM, Segher Boessenkool wrote: > >On Thu, Nov 19, 2015 at 05:23:55PM -0800, David Wohlferd wrote: > >>For that reason, I'd like to propose adding 2 new clobbers to extended >

Re: basic asm and memory clobbers

On Fri, Nov 20, 2015 at 02:05:01PM +0100, Richard Henderson wrote: > I'd be perfectly happy to deprecate and later completely remove basic asm > within functions. > > Because IMO it's essentially useless. It has no inputs, no outputs, and no > way to tell the compiler what machine state has bee

Re: basic asm and memory clobbers

On Fri, Nov 20, 2015 at 04:29:50PM +0100, Richard Henderson wrote: > >>It seems to me that it would be better to remove the feature, forcing what > >>must be an extremely small number of users to audit and update to extended > >>asm. > > > >Should asm("bla"); then be an extended asm with no input

Re: basic asm and memory clobbers

On Mon, Nov 23, 2015 at 05:39:17PM -0800, David Wohlferd wrote: > On 11/23/2015 1:44 PM, paul_kon...@dell.com wrote: > >>On Nov 23, 2015, at 4:36 PM, David Wohlferd wrote: > >> > >>... > >>>The more I think about it, I'm just not keen on forcing all those > >>>old-style asms to change. > >>If you

Re: basic asm and memory clobbers

On Mon, Nov 23, 2015 at 09:48:42PM -0700, Jeff Law wrote: > On 11/23/2015 07:22 PM, Segher Boessenkool wrote: > > > >Here is a test that shows that on at least PowerPC the basic asm is > >identical to the extended asm without clobber (compile with -O2 -S and > >-fno-ipa

Re: basic asm and memory clobbers

On Thu, Nov 26, 2015 at 05:30:48AM -0500, Hans-Peter Nilsson wrote: > On Fri, 20 Nov 2015, Richard Henderson wrote: > > I'd be perfectly happy to deprecate and later completely remove basic asm > > within functions. > > We've explictly promised (directed to kernel people IIRC) that > the empty bas

Re: basic asm and memory clobbers

On Fri, Nov 20, 2015 at 04:29:50PM +0100, Richard Henderson wrote: > On 11/20/2015 04:20 PM, Segher Boessenkool wrote: > >Should asm("bla"); then be an extended asm with no input, no outputs, > >no (non-automatic) clobbers? That would be the most straightforward and

Re: basic asm and memory clobbers - Proposed solution

On Tue, Dec 01, 2015 at 08:41:22PM -0700, Jeff Law wrote: > Isn't "asm" conditionally supported for ISO C++? In which case it's not > mandatory and semantics are implementation defined. Yes. > My strong preference is still to document the desired semantics for GCC > and treat anything that doe

Re: basic asm and memory clobbers - Proposed solution

On Sun, Dec 13, 2015 at 10:59:11PM -0800, David Wohlferd wrote: > Is there a decision maker still teetering on the edge of making a call > here? I think people are waiting for consensus, and we won't get consensus until there is a good solution, something that gives workable semantics (whatever t

Re: basic asm and memory clobbers - Proposed solution

On Sun, Dec 20, 2015 at 02:53:15PM -0800, David Wohlferd wrote: > >You do not have to escape the { and } for extended asm, on this target, > >using %{ produces even an error. > > I believe the only the only target that needs to escape {} is i386, > since it's the only one that supports dialects (

Re: RS6000/PowerPC -mpaired

On Tue, Jan 05, 2016 at 05:43:47PM +, Alan Lawrence wrote: > Can anyone give me any pointers on how to use the -mpaired option ("PowerPC > 750CL paired-single instructions") ? Configure your compiler with --target=powerpc-elf-paired, maybe add --with-cpu=750 ? > I'm trying to get it to use t

Re: Validity of SUBREG+AND-imm transformations

On Mon, Feb 29, 2016 at 10:51:24AM +, Kyrill Tkachov wrote: > So I'm trying to create a define_insn to match something like: > [(set (match_operand:SI 0 "register_operand" "=r") > (ashift:SI > (match_operand:SI 1 "register_operand" "r") > (and:QI > (match_operand:QI 2

Re: Compiler support for erasure of sensitive data

On Tue, Mar 01, 2016 at 10:27:00AM +0100, Richard Biener wrote: > > We were thinking on making a function attribute that ensures that non > > necessary registers, or stack frames used by the function will be correctly > > cleared before returning. > > We think in implementing for x86_64 as a firs

Re: Validity of SUBREG+AND-imm transformations

On Fri, Mar 04, 2016 at 02:48:21PM +, Kyrill Tkachov wrote: > Although there are case where we hit the same problem: > unsigned long > f3 (unsigned long bit_addr) > { > unsigned long bitnumb = bit_addr & 63; > return (1L << bitnumb); > } > > combine will try to match: > (set (reg:DI 78) >

Re: Compiler support for erasure of sensitive data

[ Please don't top-post. ] On Wed, Mar 09, 2016 at 11:23:22AM -0300, Andres Tiraboschi wrote: > We are developing this feature for x86_64 > I want to see which registers are being used by the current function > for returning a value or as arguments. > I traverse the rtl looking for clobbered regis

Re: Mysterious decision in combine

On Mon, Mar 21, 2016 at 02:31:51PM +0100, Dominik Vogt wrote: > On Thu, Mar 17, 2016 at 01:22:04PM -0700, Richard Henderson wrote: > > On 03/16/2016 11:35 PM, Dominik Vogt wrote: > Now combine tries to combine > > (parallel [ > (set (reg:SI 64) > (and:SI (mem:SI (reg:DI 2 %r2

Re: Should a disabled warning be allowed to be promoted to an error(Bugzilla PR 70275)?

On Mon, Mar 28, 2016 at 04:32:50PM -0600, Martin Sebor wrote: > On 03/28/2016 01:56 PM, Florian Weimer wrote: > >>In Bugzilla PR # 70275, Manuel López-Ibáñez reports that even though > >>he provides the "-Werror=return-type" option, the compiler doesn't > >>flag the warning/error about a control re

Re: Should a disabled warning be allowed to be promoted to an error(Bugzilla PR 70275)?

On Thu, Mar 31, 2016 at 06:34:12PM +0200, Florian Weimer wrote: > * Segher Boessenkool: > > > On Mon, Mar 28, 2016 at 04:32:50PM -0600, Martin Sebor wrote: > >> On 03/28/2016 01:56 PM, Florian Weimer wrote: > >> >>In Bugzilla PR # 70275, Manuel López-Ibáñe

Re: Segher Boessenkool appointed PowerPC maintainer

On Fri, Apr 22, 2016 at 04:41:04PM -0400, David Edelsohn wrote: > I am pleased to announce that the GCC Steering Committee has > appointed Segher Boessenkool as rs6000/powerpc port co-maintainer. > > Please join me in congratulating Segher on his new role. > Segher, ple

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, 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'

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 me

Re: ubsan and Dejagnu not having a big enough buffer in some cases

On Wed, Jul 20, 2016 at 12:48:09PM +0530, Senthil Kumar Selvaraj wrote: > > I see this for some of the larger C frontend tests with lots of expected > > errors/warnings as well. I also see this for tests with small output, but it happens more often for tests with big output. > Are you guys getti

Re: DejaGnu directive matching multiple messages on the same line

On Wed, Jul 20, 2016 at 02:57:22PM -0600, Martin Sebor wrote: > Btw., the above works fine when each directive is on its own line > but when the second follows the first on the same line (somehow > I thought it needed to be at first), the second one needs another > string argument. I haven't looke

Re: Need help with PR71976 combine.c::get_last_value returns a wrong result

On Mon, Jul 25, 2016 at 02:28:28PM +0200, Georg-Johann Lay wrote: > (insn 43 31 44 2 (set (reg:QI 18 r18) > (const_int 0 [0])) bug-combin.c:29 56 {movqi_insn} > (nil)) > (insn 51 50 52 2 (set (reg:QI 16 r16) > (const_int 40 [0x28])) bug-combin.c:29 56 {movqi_insn} > (nil)

Re: Need help with PR71976 combine.c::get_last_value returns a wrong result

On Tue, Jul 26, 2016 at 02:14:49PM +0200, Georg-Johann Lay wrote: > >>which returns const0_rtx because reg 18 is set in insn 43 to const0_rtx. > >>Total outcome is that the right shift of reg:DI 18 is transformed to a > >>no-op move and cancelled out in the remainder. > > > >Why does num_sign_bit_c

Re: Need help with PR71976 combine.c::get_last_value returns a wrong result

On Tue, Jul 26, 2016 at 03:38:18PM +0200, Georg-Johann Lay wrote: > >>@@ -13206,6 +13206,13 @@ get_last_value (const_rtx x) > >> && DF_INSN_LUID (rsp->last_set) >= subst_low_luid) > >> return 0; > >> > >>+ /* If the lookup is for a hard register make sure that value contains > >>at > >>

Re: Need help with PR71976 combine.c::get_last_value returns a wrong result

On Wed, Jul 27, 2016 at 09:14:27PM +0200, Georg-Johann Lay wrote: > >diff --git a/gcc/combine.c b/gcc/combine.c > >index 77e0d2b..dec6226 100644 > >--- a/gcc/combine.c > >+++ b/gcc/combine.c > >@@ -9977,6 +9977,9 @@ reg_num_sign_bit_copies_for_combine (const_rtx x, > >machine_mode mode, > >

Re: Need help with PR71976 combine.c::get_last_value returns a wrong result

Hi Johann, I tested a variant of your patch, building Linux for 32 different (sub-)architectures; surprisingly (to me) there are no regressions at all. Do you want to send it to gcc-patches? Segher diff --git a/gcc/combine.c b/gcc/combine.c index 77e0d2b..750bf83 100644 --- a/gcc/combine.c ++

Re: Need help with PR71976 combine.c::get_last_value returns a wrong result

On Fri, Jul 29, 2016 at 11:05:13AM +0200, Georg-Johann Lay wrote: > There might still problems linger around if hard-regs are used: > > Suppose we set the reg in DImode and then get_last_value is called for the > same reg in SImode. Using the DI value might be wrong, e.g. if it is used > to com

Re: fxsrintrin.h

On Fri, Aug 19, 2016 at 08:45:49AM +0200, Jakub Jelinek wrote: > On Fri, Aug 19, 2016 at 01:50:52PM +0800, lhmouse wrote: > > Given the `_fxsave()` function returning `void`, it is invalid C but valid > > C++: > > It is also a GNU C extension. And GCC warns with -Wpedantic (but not without). It

Re: How do you emit RTL for a jump to a mem/symbol instead of an asm label?

On Sun, Aug 21, 2016 at 02:04:49PM -0500, Daniel Santos wrote: > Thanks for the response! Perhaps an UNSPEC insn is needed here because I > have work to do on other passes too. For example, when the debug info is > created, it's giving the wrong location (on the stack) for where some > registers

Re: How do you emit RTL for a jump to a mem/symbol instead of an asm label?

On Wed, Aug 24, 2016 at 02:47:41AM -0500, Daniel Santos wrote: > On 08/21/2016 05:59 PM, Segher Boessenkool wrote: > >On Sun, Aug 21, 2016 at 02:04:49PM -0500, Daniel Santos wrote: > >>Thanks for the response! Perhaps an UNSPEC insn is needed here because I > >>have wor

Re: [PATCH 1/3] Put a TARGET_LRA_P into every target

On Wed, Sep 14, 2016 at 07:46:13AM -0500, Peter Bergner wrote: > On 9/14/16 5:35 AM, Segher Boessenkool wrote: > > (I hope the wording is strong enough). > Maybe s/New ports should use LRA/New ports must use LRA/ ? Yeah maybe. Does anyone else have an opinion on this? Cc:ing gcc@.

Converting to LRA (calling all maintainers)

Hi! Since a few days TARGET_LRA_P defaults to returning "true". I changed all in-tree ports to still behave the same as before, which for most ports means they use old reload always. All the primary platforms (see the release criteria, ) now default to LR

Re: Converting to LRA (calling all maintainers)

On Fri, Sep 16, 2016 at 02:53:16PM -0600, Jeff Law wrote: > Under traps for the unwary -- LRA requires the target to not use the old > cc0 condition code handling... I added this now, thanks Jeff. > ANd yes, I see this as a way to deprecating those cc0 targets like the > m68k :-) Would be a sh

Re: Converting to LRA (calling all maintainers)

On Fri, Sep 16, 2016 at 11:22:04PM +0200, Eric Botcazou wrote: > > Since a few days TARGET_LRA_P defaults to returning "true". I changed > > all in-tree ports to still behave the same as before, which for most > > ports means they use old reload always. All the primary platforms (see > > the rele

Re: gcc 3.4.6 asm charset error

On Thu, Sep 22, 2016 at 05:35:22PM +1000, Paul Edwards wrote: > GCC 3.4.6 natively handles different character > sets for source and target. It actually works > fine, writing source code in ASCII targeting > an EBCDIC destination. > > However, __asm() doesn't seem to be working. > As seen below, i

Re: Converting to LRA (calling all maintainers)

On Sun, Sep 25, 2016 at 04:28:04PM +0900, Oleg Endo wrote: > > > ANd yes, I see this as a way to deprecating those cc0 targets like > > > the  > > > m68k :-) > > Would be a shame to see m68k go.  There still is time... > > Indeed.  68K is a perfect candidate for addressing mode optimization > (AMS

Re: Converting to LRA (calling all maintainers)

On Sun, Sep 25, 2016 at 10:46:55AM +0200, Eric Botcazou wrote: > > There is no hurry to kill old reload. As you say, many targets will > > not be converted soon. But one day it will be removed. Not in GCC 7, > > not in GCC 8 almost certainly. But one day. > > Certainly not in GCC 8, the top pr

Re: style convention: /*foo_p=*/ to annotate bool arguments

On Tue, Oct 04, 2016 at 07:40:09AM -0400, Nathan Sidwell wrote: > On 10/03/16 19:48, Martin Sebor wrote: > >In a recent review Jason and I discussed the style convention > >commonly followed in the C++ front end to annotate arguments > >in calls to functions taking bool parameters with a comment >

Re: Question about sibling call epilogues & registers

Hi Daniel, On Sat, Oct 15, 2016 at 01:45:12AM -0500, Daniel Santos wrote: > The insn that's getting deleted is 75, where RCX is set. I'm starting > to think that maybe df_analyze() presumes that my call (to the stub) is > invalidating RCX, although it does not. It looks like you don't use add_

<    1   2   3   4   5   6   7   >