Re: RFC: Improving support for known testsuite failures

On Thu, 8 Sep 2011, Diego Novillo wrote: > On Thu, Sep 8, 2011 at 04:31, Richard Guenther > wrote: > > > I think it would be more useful to have a script parse gcc-testresults@ > > postings from the various autotesters and produce a nice webpage > > with revisions and known FAIL/XPASSes for the t

Re: Use of FLAGS_REGNUM clashes with generates insn

On Fri, 23 Sep 2011, Joern Rennecke wrote: > Quoting "Paulo J. Matos" : > > > My addition instruction sets all the flags. So I have: > > This is annoying, but can be handled. Been there, done that. > dse.c needs a small patch, which I intend to submit sometime in the future. Could you be persuad

Re: Target-libiberty being built -- gcc-4.6.1 & gcc-4.6.2

On Sun, 30 Oct 2011, Michael Eager wrote: > On 10/29/2011 11:55 PM, Michael Eager wrote: > > On 10/29/2011 08:44 PM, Ian Lance Taylor wrote: > > > Michael Eager writes: > > > > > > > I'm seeing a build failure when building a bootstrap gcc > > > > because it is attempting to build target-libiberty.

Re: approaches to carry-flag modelling in RTL

On Sat, 29 Oct 2011, Peter Bigot wrote: > On Fri, Oct 28, 2011 at 11:59 AM, Richard Henderson wrote: > Based on what I've encountered so far, between having to duplicate many > insns (one with CC_REG, one without), adding splits to convert between them, > and making a hash of the templates for the

Re: approaches to carry-flag modelling in RTL

On Mon, 31 Oct 2011, Paulo J. Matos wrote: > On 31/10/11 05:36, Hans-Peter Nilsson wrote: > > BTW, I > > don't think it helps that someone decided the canonical form of > > a parallel that includes a CC-setter must have the CC-setting > > *first* (contrasti

Re: approaches to carry-flag modelling in RTL

Please, when replying, also send to me, not just the list. On Tue, 1 Nov 2011, Paulo J. Matos wrote: > On 01/11/11 02:43, Hans-Peter Nilsson wrote: > > > > Not obvious or maybe I was unclear as to what I alluded? > > In the below insn-bodies, "sub" is the insn tha

Re: Dependent Labels Question

On Thu, 3 Nov 2011, Iyer, Balaji V wrote: > Is it possible to make sure that the "LABELX" occurs right > after the "Call some_function" instruction (and the instruction > scheduler moves the label with the call INSN)? I insert the > label right after the call is expanded and LABELX is being moved >

Re: [C++11] Reclaiming fixed-point suffixes for user-defined literals.

On Sun, 6 Nov 2011, Joern Rennecke wrote: > Quoting David Brown : > > > Take an example using a processor I know well, the AVR (it is an 8-bit > > device, which is a little unusual for gcc). It has an instruction will > > multiply two "1.7" signed 8-bit integers to get a single 1.15 signed > > 16

Re: [C++11] Reclaiming fixed-point suffixes for user-defined literals.

(Not CC:ing the quoted newsgroup, sorry.) On Tue, 8 Nov 2011, David Brown wrote: > If the compiler can generate fractional arithmetic code directly from such > expressions, then it is indeed a good step towards implementing such types as > a pure C++ class without needing to use compiler extension

Re: [C++11] Reclaiming fixed-point suffixes for user-defined literals.

On Tue, 8 Nov 2011, Joseph S. Myers wrote: > On Tue, 8 Nov 2011, Hans-Peter Nilsson wrote: > > > (yes, that's you cue. :) For acceptance, IMHO better get it > > working universally by open-coding the implementation without > > requiring --enable-* options. > > M

Re: bootstrap regression on sparc

On Fri, 11 Nov 2011, David Miller wrote: > > While building libstdc++ I get an assertion failure in haifa-sched.c, > specifically the assertion on line 3437 is failing: > I haven't looked more deeply at it, but the first recent suspicious change > are the basic block handling changes Alan made two

libgcc: why emutls.c in LIB2ADDEH instead of LIB2ADD?

As subject says, in libgcc, why is $(srcdir)/emutls.c in LIB2ADDEH (and LIB2ADDEHSTATIC and LIB2ADDEHSHARED) instead of LIB2ADD? Emulating TLS has nothing to do with exception-handling, nor is there something that might throw while calling one of its functions. Ok to fix that? brgds, H-P

Re: Profiling gcc itself

On Sun, 20 Nov 2011, Jeff Evarts wrote: > On Sun, 20 Nov 2011 11:34:27 -0500, Tim Prince wrote: > > On 11/20/2011 11:10 AM, Basile Starynkevitch wrote: > >> On Sun, 20 Nov 2011 03:43:20 -0800 Jeff Evarts wrote: > >>> I posted this question at irc://irc.oftc.net/#gcc and they suggested > >>> tha

Re: Ad: Fix PR middle-end/45416, missing opt for (a&(1<

On Sun, 11 Dec 2011, Andrew Pinski wrote: > On Sun, Dec 11, 2011 at 3:13 PM, Georg-Johann Lay wrote: > > If there was a canonical representation of these operations, a backend > > wouldn't even notice if the tree passes chose a different, more convenient > > canonicalization. > > The problem is no

Re: building unwind-sjlj.o with / without -fexceptions

On Mon, 5 Dec 2011, Joern Rennecke wrote: > I find that exception handling doesn't work properly for the epiphany with > recent gcc sources (it worked in the pre-merged port with sources from July). > I suppose that is related to the change mentioned in: > http://gcc.gnu.org/ml/gcc-patches/2011-11/

Re: Which Binutils should I use for performing daily regression test on trunk?

> From: Terry Guo > Date: Wed, 21 Dec 2011 04:25:46 +0100 > I plan to set up daily regression test on trunk for target > ARM-NONE-EABI and post results to gcc-testresults mailing > list. Nice. I see others do it for that target, but apparently not for a pristine tree (the results having many fa

Re: trouble emilinating redundant compares

On Mon, 16 Jan 2012, Paul S wrote: > In the port I'm working on I have used the newer CC tracking technique (i.e. > not cc0). I have followed the directions at the top of compare-elim.c and have > the following pattern for addhi3 > I'm clearly missing something... can anyone provide a hint ? You'

Re: RTL AND Instruction

On Sun, 22 Jan 2012, Matt Davis wrote: > Once I emit my rtx into the list of insns, GCC gives me an "unrecognized insn" > error. I can trace the code through the first part of the condition, > specified > in i386.md, "ix86_binary_operator_ok," and that passes fine from the > "anddi_1" define_insn

RE: readonly register

On Thu, 19 Jan 2012, BELBACHIR Selim wrote: > In fact my final purpose is to replace $INP by a register bank > in order to be able to read several inputs using pipelined > instructions (and instruction scheduler). The fixed reg solution > will prevent me from doing this. Is there another way to pr

RE: readonly register

On Sun, 22 Jan 2012, Hans-Peter Nilsson wrote: > On Thu, 19 Jan 2012, BELBACHIR Selim wrote: > > > In fact my final purpose is to replace $INP by a register bank > > in order to be able to read several inputs using pipelined > > instructions (and instruction scheduler)

Re: trouble emilinating redundant compares

On Mon, 23 Jan 2012, Paul S wrote: > Thanks Dave, > > I would never have guessed from gccinternals.pdf that it is possible to use > mode iterators to select predicates & constraints ... Really? If you but if you have suggestions for improving the documentation, that'd be welcome. > I think I hav

Re: help: standard name of vector mode

On Thu, 15 Oct 2009, Åí½¨Õ wrote: > I'm porting gcc , and use its autovectorization. > How can I know wether a standard name support a vector mode ? I might misunderstand your question, but the vector modes that are supported are enumerated by the port. See e.g. gcc/config/i386/i386-modes.def,

Re: -use-linker-plugin passed to ld

On Fri, 23 Oct 2009, Ian Lance Taylor wrote: > Steven Bosscher writes: > > I was just wondering why this is not a -f* flag, e.g. -fuse-linker-plugin? > Any opinions on the best user interface for this? The color that spells -fuse-linker-plugin seems better, in line with other options. How it's i

Re: Build broken in libstdc++ on x86_64-linux

On Thu, 12 Nov 2009, Paolo Carlini wrote: > the build is currently, ie 154122, broken in libstdc++-v3: > > ./src/system_error.cc:95:1: internal compiler error: > Segmentation fault > > Version 154120 works fine for me. FWIW, seen for cris-elf too. (Worked: r154119, failed from: r154122.)

Re: How to support 40bit GP register - Take two

On Fri, 20 Nov 2009, Mohamed Shafi wrote: > I tried implementing the suggestion given by Richard, but got into > issues. The GCC frame work is written assuming that there are no modes > with HOST_BITS_PER_WIDE_INT < GET_MODE_BITSIZE (mode) < 2 * > HOST_BITS_PER_WIDE_INT. (Not seeing a reply regard

Re: How to support 40bit GP register - Take two

Sorry if I misunderstood, but... On Fri, 18 Dec 2009, Mohamed Shafi wrote: > 2009/12/18 Hans-Peter Nilsson : > > On Fri, 20 Nov 2009, Mohamed Shafi wrote: > >> I tried implementing the suggestion given by Richard, but got into > >> issues. The GCC frame work is written

Re: RFC: machine specific alternative cost modifier

On Fri, 17 Oct 2008, Joern Rennecke wrote: > On Fri, Oct 17, 2008 at 10:46:41AM -0700, Ian Lance Taylor wrote: > > > > I think you could achieve the same result by writing multiple > > define_insn patterns and using the instruction predicate. > > Yes, I could. But that would quadruple my machine

Re: RFC: machine specific alternative cost modifier

On Sat, 25 Oct 2008, Joern Rennecke wrote: > Moreover, the .md file also doesn't get more readable if I replace > a three character constraint string with a multiword iterator invocation... > for something like eight out of 14 alternatives for some instructions. Um yeah, there is that... > FWIW,

Re: -fno-ira removal

On Thu, 23 Oct 2008, Paolo Bonzini wrote: > > The following ports haven't been converted yet: > > > > arc m32c m68hc11 mmix pdp11 score vax > > DJ has reported problems on the list for m32c. > > Regarding ARC and MMIX we might expect some action from Joern and H-P > respectively, Problems for MMIX

Re: [PATCH]: bump minimum MPFR version, (includes some fortran bits)

On Sun, 26 Oct 2008, Geoff Keating wrote: > Does everyone really type --with-mpfr= on every build? While we're listing practices, and since nobody's listed it, lest people think that method isn't used, mine is to *always build with in-tree gmp and mpfr*: whether at the compile farm, in a packa

Re: [EMAIL PROTECTED]: Results for 4.4.0 20081106 (experimental) [trunk revision 141636] (GCC) testsuite on m32c-unknown-elf]

On Fri, 7 Nov 2008, Martin Jambor wrote: > >From the logs I see that the testsuite probably uses a cross-compiled > gcc? How do you configure gcc to get such a beats? See . (Don't ever change anything in the hardlinked /combined tree, though and don't tr

Re: GCC 4.4.0 Status Report (2008-11-27)

On Tue, 9 Dec 2008, Vladimir Makarov wrote: > Today Jeff Law (many thanks to him!) approved a big patch I wanted to commit > before submitting patch removing the old register allocator. So nothing > prevents to remove the old RA. > > I am going to submit the patch removing the old RA for review to

Re: GCC 4.4.0 Status Report (2008-11-27)

On Tue, 9 Dec 2008, Vladimir Makarov wrote: > Hans-Peter Nilsson wrote: > > Vladimir, have you had chance to look at supporting > > LOAD_EXTEND_OP (implicit sign-extension) in IRA? > > <http://gcc.gnu.org/ml/gcc/2008-10/msg00458.html> > > I'm guessing no, but

Re: GCC 4.4.0 Status Report (2008-11-27)

On Tue, 9 Dec 2008, Jeff Law wrote: > Hans-Peter Nilsson wrote: > > Vladimir, have you had chance to look at supporting > > LOAD_EXTEND_OP (implicit sign-extension) in IRA? > > > > <http://gcc.gnu.org/ml/gcc/2008-10/msg00458.html> > > > > I'm g

Re: Inline limits

On Thu, 5 Feb 2009, Paul Brook wrote: > > For -Os it should be enough to set PARAM_STACK_FRAME_GROWTH > > to zero. Inlining at -Os should already only happen if it decreases > > (overall!) code-size. Thus, inlining a function that is called once and > > that does not need to be emitted will alway

Re: bitfields: types vs modes?

On Tue, 10 Mar 2009, DJ Delorie wrote: > One of our customers has a chip with memory-mapped peripheral > registers that need to be accessed in a specific mode. The registers > represent bitfields within the hardware, so a volatile struct is an > obvious choice to represent them in C. Thank you fo

Re: bitfields: types vs modes?

On Wed, 11 Mar 2009, Paul Brook wrote: > PR23623 (I suspect the status on that bug is incorrect, it's nt actually > fixed). The ARM EABI defines semantics for volatile bitfields, and gcc gets > this wrong. If the ARM EABI really documents the semantics for that, implement-c.texi:Qualifiers does ne

Re: help for arm avr bfin cris frv h8300 m68k mcore mmix pdp11 rs6000 sh vax

> Date: Fri, 13 Mar 2009 12:34:49 +0100 > From: Paolo Bonzini > I would like to know whether for avr,bfin,cris,frv,h8300,pdp11,rs6000 > (which define SHIFT_COUNT_TRUNCATED as 0) and for mcore,sh,vax (which > do not define it at all) it is right that shift counts are never > truncated. The answer

Re: help for arm avr bfin cris frv h8300 m68k mcore mmix pdp11 rs6000 sh vax

On Fri, 13 Mar 2009, Paolo Bonzini wrote: > These are all the !SHIFT_COUNT_TRUNCATED targets. > > For 4.5 I would like to improve our RTL canonicalization so that no > out-of-range shifts are ever in the RTL representation. > > This in turn means that the description given by SHIFT_COUNT_TRUNCATED

Re: help for arm avr bfin cris frv h8300 m68k mcore mmix pdp11 rs6000 sh vax

> Date: Sat, 14 Mar 2009 13:07:04 +0100 > From: Paolo Bonzini > Hans-Peter Nilsson wrote: > >> Date: Fri, 13 Mar 2009 12:34:49 +0100 > >> From: Paolo Bonzini > > > >> I would like to know whether for avr,bfin,cris,frv,h8300,pdp11,rs6000 > >>

Re: any recent changes to gcc test builds

> Date: Mon, 23 Mar 2009 09:37:02 -0500 > From: Joel Sherrill > I am confused at the gcc test results for RTEMS > over the weekend. I have 1000s of failures > across all the targets which look like this: > Any ideas? I fixed a bug in Janis' GCC_EXEC_PREFIX testsuite cleanup:

Re: any recent changes to gcc test builds

> Date: Mon, 23 Mar 2009 10:19:37 -0500 > From: Joel Sherrill > I don't have those in my board.exp: > > set_board_info cflags "-B${RTEMS_MAKEFILE_PATH}/lib/ -specs bsp_specs > -qrtems -mcpu=603e" > set_board_info ldflags "${RTEMS_CONFIG_OBJ}" Those should find ${RTEMS_MAKEFILE_PATH}/lib/libm.

Re: Invalid reload inheritance with paradoxical subregs

On Thu, 2 Apr 2009, Uros Bizjak wrote: > Combine simplifies lshiftrt/shift/and combined instruction under the > assumption, that for ZERO_EXTEND LOAD_EXTEND_OP targets it can prove > that certain bits are zero, so AND operation can be omitted. The > resulting instruction is valid only for memory op

Re: generating functions and eh region

On Fri, 3 Apr 2009, Ian Lance Taylor wrote: > gcc's -fasynchronous-unwind-tables option is > intended to support unwinding the stack at any precise instruction > boundary, which might be adequate for this purpose if the OS can handle > the adjustment from an exception in the middle of an instructio

Re: Invalid reload inheritance with paradoxical subregs

On Mon, 6 Apr 2009, Uros Bizjak wrote: > Hans-Peter Nilsson wrote: > > And again, I'd be perfectly fine with removing this weird > > LOAD_EXTEND_OP-specific "feature". I'm of half a mind to remove > > the #define from the MMIX port. > Please note, t

Re: question on 16 bit registers with 32 bit pointers

On Mon, 13 Apr 2009, Dave Korn wrote: > Michael Meissner wrote: > > On Sat, Apr 11, 2009 at 01:40:57AM +0100, Dave Korn wrote: > >> Stelian Pop wrote: > >> > > Do I need to define movsi3(), addsi3() etc. patterns manually or > > should GCC figure those by itself ? ... > > Though if you use

Slush, please?

I don't see a request, yet more than two people seem to agree, so: can we have a slush (no new merges or features) while the tree is stabilized? I'll let other people answer the "why" wrt. priority platforms; the double breakages for cris-elf (PR39927, PR39938) don't count. :/ brgds, H-P

Re: GCC porting tutorials

> From: "Jonas Paulsson" > Date: Mon, 26 Apr 2010 11:07:04 +0200 > I recently completed my degree project on LTH on retargeting GCC. See > http://sam.cs.lth.se/ExjobGetFile?id=224 for my report (it will be moved to > http://cs.lth.se/examensarbete/rapporter/rapporter_2010/ soon). Interesting o

Widening multiplications (was: Re: GCC porting tutorials)

> Date: Tue, 27 Apr 2010 20:41:47 +0200 (CEST) > From: "Jonas Paulsson" > I've been following the discussion a bit about contributing, and find > myself here now even directly pointed at :-) As I mentioned, I am not very > experienced with GCC, for one thing I have not studied other ports very >

Parallelized loads and widening mults cont:ed (was: Re: GCC porting tutorials)

> Date: Thu, 29 Apr 2010 08:55:56 +0200 (CEST) > From: "Jonas Paulsson" > It feels good to know that the widening mults issue has been > resolved Yes, nice, and as late as last week too, though the patch was from February. > as > it was a bit of a disapointment I noted the erratic behaviour wit

Re: GFDL/GPL issues

> Date: Tue, 25 May 2010 17:44:32 -0700 > From: Mark Mitchell > In a biweekly call with the other GCC Release Managers, I was asked > today on the status of the SC/FSF discussions re. GFDL/GPL issues. In > particular, the question of whether or not we can use "literate > programming" techniques

Re: Illegal schedule

On Mon, 21 Jun 2010, Boris Boesler wrote: > The four instructions before the jump are placed into the > delay slots, such that the delay slots are completely filled; > but there is still the pipeline hazard, which can't be resolved > by inserting NOPs now, because there are no free slots. GCC por

Re: patch: honor volatile bitfield types

> From: DJ Delorie > Date: Wed, 16 Jun 2010 18:53:54 -0400 A bit of thread hijacking (moving it to gcc@) I'm afraid, but it's too related to pass up on the opportunity... > Index: gcc/doc/invoke.texi > === > --- gcc/doc/invoke.texi

Re: patch: honor volatile bitfield types

> Date: Wed, 23 Jun 2010 11:53:31 -0400 > From: Daniel Jacobowitz > On Wed, Jun 23, 2010 at 11:34:04AM -0400, DJ Delorie wrote: > > > Can we similarly promise or say something for accesses of the > > > containing struct as a whole? > > I hadn't considered those cases (when would you want to copy a

Re: patch: honor volatile bitfield types

(I wrote:) > > Can we similarly promise or say something for accesses of the > > containing struct as a whole? No takers? > Date: Wed, 23 Jun 2010 11:34:04 -0400 > From: DJ Delorie > Should be the same as before, I would think. Primarily I want them similarly defined. I wasn't expecting thos

Re: textual prologue/epilogue

On Mon, 15 Nov 2010, Paolo Bonzini wrote: > The only targets that are using textual prologues and epilogues are now arc, > cris, pdp11 and vax. ARC should probably have been deprecated long ago, any > plans to convert the others or (for cris) to flip the default? What code are you loking at; wher

Re: Status and rationale for toplevel bootstrap (was Re: Example of debugging GCC with toplevel bootstrap)

On Mon, 16 Jan 2006, DJ Delorie wrote: > Two copies of gcc, both configured for the same target and built from > the same sources, should produce identical objects regardless of how > they are built or what they run on. For the record, this unfortunately isn't so, at least wasn't weeks ago, compar

Re: cannot find -lm

On Tue, 24 Jan 2006, Eric Fisher wrote: > ld: cannot find -lm > collect2: ld returned 1 exit status > How can I get it? Port newlib. It's simple enough. brgds, H-P

Re: Since r110852: Mainline broken for VAX (cc0 target)

On Sun, 12 Feb 2006, David Fang wrote: > > > And now: How do you actually find the PRs? I seem to wrongly use > > > Bugzilla's search engine. I submitted "int_mode_for_mode" into the > > > "Enter a bug # or some search terms" box of > > > http://gcc.gnu.org/bugzilla/ , which didn't find anything.

Re: Design a microcontroller for gcc

On Wed, 15 Feb 2006, Sylvain Munaut wrote: > * 2 flags Carry & Zero for testing. I think most of your questions have been answered, so let me just add that if nothing else, the port will be much simplified if you make sure that only specific compare instructions set condition codes, i.e. not

Re: Design a microcontroller for gcc

On Thu, 16 Feb 2006, Sylvain Munaut wrote: > What I was thinking for the moment was to have : > - sign is always the msb of the last ALU output > - add/sub to modify all flags > - move/xor/and/not/or only affect zero (and sign) > - shift operations always affect carry and zero > - Have some sp

Re: Design a microcontroller for gcc

On Wed, 15 Feb 2006, DJ Delorie wrote: > > BTW, carry-out from shifts is very rarely used in compiled code.) > Unless you've expanded SI shifts into a pair of HI shifts. > > > Besides what DJ said about performance (both pros and cons > > there), the problem is as I said with port complexity, becau

Re: Design a microcontroller for gcc

On Wed, 15 Feb 2006, Hans-Peter Nilsson wrote: > FWIW, I use > peephole2s and condition code modes in CRIS w.i.p. ...and cbranch (cc setter + user in one combined insn) which are split after reload. brgds, H-P

Re: Design a microcontroller for gcc

On Wed, 15 Feb 2006, DJ Delorie wrote: > I hope I can stick with my cmp/jmp model and manage them myself still, > though, because there's a LOT of patterns in m32c where the set of > flags affected depends on which alternative you select, and most > patterns affect the flags in some (usually nonort

Re: Design a microcontroller for gcc

On Wed, 15 Feb 2006, Hans-Peter Nilsson wrote: > Unless I'm delirious (it's way past bedtime) I see a m32c port > and it's cc0-free. Is there a problem? I see, in the code in svn trunk the compares aren't optimized away yet. You must be having a lot of fun right now. ;-) brgds, H-P

Re: Design a microcontroller for gcc

On Wed, 15 Feb 2006, DJ Delorie wrote: I wrote: > > Anyway, at least keep a way to add reg+reg and reg+integer, load and > > store of memory and load of integer and address without condition > > code effects and your port has a chance to avoid the related bloat. > > At least, move/load/store shou

Re: Design a microcontroller for gcc

On Thu, 16 Feb 2006, Sylvain Munaut wrote: > Move/Load/Store without flag is no problem. But for add, to allow > multiword add, carry is needed and I can't make it optionnal. As I hinted, perhaps you can have the multiword carry a separate one from the flags carry, perhaps moved over with a separa

Re: RFC: Message-ID to mailing list URL match

On Fri, 17 Feb 2006, Grigory Zagorodnev wrote: > For example cgi-bin/mesg.cgi script of mhonarc mail-to-html converter, > the one used by gcc.gnu.org, can "extract a message from an archive > based upon message-id" so having interface to this script would be > useful. Further the mail client may be

Re: REG_OK_STRICT and EXTRA_CONSTRAINT

On Thu, 24 Aug 2006, Paolo Bonzini wrote: > Some ports, notably MMIX, are using different definitions of > EXTRA_CONSTRAINT depending on REG_OK_STRICT. This can be a bug, because > the same instruction may be considered invalid in reload.c and valid by > recog.c. When I wrote that code, accounti

Re: REG_OK_STRICT and EXTRA_CONSTRAINT

On Thu, 24 Aug 2006, Paolo Bonzini wrote: > Anyway, I was not meaning to *not* account for anything, but just to > replace REG_OK_STRICT with checks on reload_in_progress and > reload_completed. I understand the semantics that you wanted for 'U'. > > The bug may be that in some cases, 'U' is check

Re: REG_OK_STRICT and EXTRA_CONSTRAINT

On Fri, 25 Aug 2006, Paolo Bonzini wrote: > After I'm done with the base_reg_class changes, I will try > modifying address_operand to be something along the lines of your U > constraint: Yeah, that does sound like the real bug; nothing should be using non-strict checking after reload as address_op

Re: Meaning of (set (reg:CC condition_codes_reg) (ge (op0) (op1)))

On Sat, 2 Sep 2006, Rask Ingemann Lambertsen wrote: >What does this instruction mean? > > (set (reg:CC 13 cc) > (ge (mem/c/i:HI (plus:HI (reg/f:HI 15 argp) > (const_int 2 [0x2])) [2 x+0 S2 A16]) > (const_int 0 [0x0]))) >... >The (reg:CC 13 cc) part is the condit

Re: Missing elements in VECTOR_CST

On Mon, 18 Sep 2006, Mark Mitchell wrote: > Andrew Pinski wrote: > > The documention on VECTOR_CST is not clear if we can have missing > > elements in that the remaining elements are zero. Right we produce such > > VECTOR_CST for things like: > > #define vector __attribute__((vector_size(16) )) >

Re: Missing elements in VECTOR_CST

On Thu, 28 Sep 2006, Mark Mitchell wrote: > Hans-Peter Nilsson wrote: > > On Mon, 18 Sep 2006, Mark Mitchell wrote: > > > >> Andrew Pinski wrote: > >>> The documention on VECTOR_CST is not clear if we can have missing > >>> elements in that the rem

Re: git gcc-commit-mklog doesn't extract PR number to ChangeLog

On Fri, 11 Jun 2021, Martin Sebor via Gcc wrote: > On 6/11/21 11:32 AM, Jonathan Wakely wrote: > > On Fri, 11 Jun 2021 at 18:02, Martin Sebor wrote: > > > My objection is to making our policies and tools more restrictive > > > than they need to be. We shouldn't expect everyone to study whole > >

Re: git gcc-commit-mklog doesn't extract PR number to ChangeLog

On Tue, 15 Jun 2021, Martin Sebor wrote: > On 6/15/21 6:56 PM, Hans-Peter Nilsson wrote: > > On Fri, 11 Jun 2021, Martin Sebor via Gcc wrote: > > > > > On 6/11/21 11:32 AM, Jonathan Wakely wrote: > > > > On Fri, 11 Jun 2021 at 18:02, Martin Sebor wrote: >

Re: [PATCH] Port GCC documentation to Sphinx

On Wed, 30 Jun 2021, Eli Zaretskii via Gcc-patches wrote: > > Cc: jos...@codesourcery.com, gcc@gcc.gnu.org, gcc-patc...@gcc.gnu.org > > From: Martin Li?ka > > Date: Wed, 30 Jun 2021 12:11:03 +0200 > > > 4. Menus lost the short descriptions of the sub-sections. Example: > > > > > >* Designated

Re: GCC LM32 bug: reordering instructions in stack

On Fri, 1 Oct 2021, Nelson Ribeiro via Gcc wrote: > Hello. > > Firstly I want to apologize for this long post, but in a way this post also > is meant for documenting the work that I have done hunting down this issue. > Secondly I must say that I do not have much insights on the GCC internals, > onl

Re: Many analyzer failures on non-Linux system (x86_64-apple-darwin)

Not seeing anyone doing the obvious one-up, so JFTR: On Mon, 10 Jan 2022, David Malcolm via Gcc wrote: > On Mon, 2022-01-10 at 17:13 +0100, FX wrote: > > > FAIL: gcc.dg/analyzer/asm-x86-lp64-1.c > > The purpose of these asm tests is to verify that the analyzer doesn't > get confused by various in

Re: Benchmark recommendations needed

On Mon, 14 Feb 2022, Andras Tantos wrote: > Hello all! > > I'm working on porting GCC to a new processor architecture. I think > I've finally got to a fairly stable stage, so the next logical step > would be to test and optimize. For that, I would need some benchmarks, > and this is where I'm seeki

Re: lambda coding style

On Wed, 10 Jan 2024, Jason Merrill via Gcc wrote: > On 1/10/24 15:59, Marek Polacek wrote: > > On Wed, Jan 10, 2024 at 02:58:03PM -0500, Jason Merrill via Gcc wrote: > > > What formatting style do we want for non-trivial lambdas in GCC sources? > > > I'm thinking the most consistent choice would be

Re: RFC: Formalization of the Intel assembly syntax (PR53929)

On Fri, 19 Jan 2024, LIU Hao wrote: > ? 2024-01-18 20:54, Jan Beulich ??: > > I'm sorry, but most of your proposal may even be considered for being > > acceptable only if you would gain buy-off from the MASM guys. Anything > > MASM treats as valid ought to be permitted by gas as well (within the >

Re: Stack Checking implementation problems

On Wed, 9 Feb 2005, James E Wilson wrote: > A workaround would be to add a special unspec RTL pattern that emits the > bgeu/break/label. Then you would no longer have control-flow inside the > prologue. You can use the gas local label feature to avoid needing to > create a label rtx. Or (for the

Re: [RFA:] change back name of initial rtl dump suffix to ".rtl".

> Date: Mon, 21 Feb 2005 11:19:59 +0100 > From: Paolo Bonzini <[EMAIL PROTECTED]> > > Do you know of a reason why that isn't on by default? > > Because -fdump-rtl-expand-detailed includes *two* copies of the RTL: one > lacks the prologue and epilogue but is interleaved with trees, the other > i

Re: Confusion about delay slots and using condition-code register

On Wed, 6 Mar 2013, Alan Lehotsky wrote: > So, am I constructing my RTL incorrectly? No. > Do I need to be > making the clobbers inside a parallel instead of just emitting > them sequentially? Exactly. > (define_insn "*addsi" > [(set (match_operand:SI 0 "nonimmediate_operand" "=rm,r

RE: Modeling predicate registers with more than one bit

On Tue, 26 Mar 2013, Paulo Matos wrote: > > -Original Message- > > From: Hans-Peter Nilsson [mailto:h...@bitrange.com] > > Sent: 05 March 2013 01:45 > > To: Paulo Matos > > Cc: gcc@gcc.gnu.org > > Subject: Re: Modeling predicate registers with more tha

Re: Delay slot filling - what still matters, and what doesn't matter so much anymore?

(People, please don't use my @gcc.gnu.org address if you need to ping me; not sure why Steven used that. I also changed the other CC'ed addresses to the corresponding relevant one from MAINTAINERS. Looks like I'm month+ behind on reading the lists again... On the plus side, maybe a reply-bump rek

Re: Where does the gcc_tg.o linked in tests come from?

On Fri, 11 Oct 2013, Brooks Moses wrote: > I'm trying to reproduce a test failure outside the Dejagnu testsuite, > and I noticed that the file I'm trying to recompile is linked with a > gcc_tg.o file. Based on the missing-symbol errors I get when I don't > include it, it seems to provide things l

Re: linux says it is a bug

On Tue, 4 Mar 2014, Yury Gribov wrote: > Richard wrote: > > volatile __asm__("":::"memory") > > > > is a memory barrier and a barrier for other volatile instructions. > > AFAIK asm without output arguments is implicitly marked as volatile. So it may > not be needed in barrier() at all. Yes, exactl

Re: approaches to carry-flag modelling in RTL

s seem to make the most sense. > We shan't do that until we tackle... > > On 11/01/2011 02:59 PM, Hans-Peter Nilsson wrote: > > I'm still thinking of a generic md iterator mechanism (one that > > doesn't restrict the form of the expansion in ways getting in > >

Re: C++: Letting compiler know asm block can call function that can throw?

On Mon, 2 Apr 2012, Michael Matz wrote: > On Mon, 2 Apr 2012, Jakub Jelinek wrote: > > > > inline int syscall1(int number, long arg1) { > > > register int ax __asm__("eax"); > > > register long di __asm__("rdi"); > > > ax = number; > > > di = arg1; > > > __asm__ volatile ("syscall"); > >

What to do about pattern recognition not in .md order when the mode of a pattern operand is unspecified

Other target-patches exposed this for me. I have on the 4.7-branch an insn: (jump_insn 245 277 246 (set (pc) (label_ref:SI 312)) whatever.c:511 -1 (nil) -> 187) and two (or more) pattern candidates in the following .md file order: (define_insn "jump" [(set (pc) (label_ref

Re: What to do about pattern recognition not in .md order when the mode of a pattern operand is unspecified

> From: Richard Sandiford > Date: Sun, 22 Apr 2012 10:47:24 +0200 > With some trepidation, because I suspect I'm missing the point :-) Maybe but maybe not. Below it seems my observation was misdiagnosed, and this is just a minor bug. > Hans-Peter Nilsson writes: > &g

How do I set SIG_ATOMIC_TYPE to a variant of a C-type?

I'm considering changing SIG_ATOMIC_TYPE for CRIS (*-elf and *-linux-gnu) to the effect of #define SIG_ATOMIC_TYPE "int __attribute__((__aligned__(4)))" but that by itself doesn't work. It causes a SEGV on the 4.7 branch and no doubt also on trunk; the code is the same. From a gdb session it app

Re: How do I set SIG_ATOMIC_TYPE to a variant of a C-type?

> From: "Joseph S. Myers" > Date: Tue, 15 May 2012 22:06:03 +0200 > Unless your signal.h does > > typedef __SIG_ATOMIC_TYPE__ sig_atomic_t; I just assumed that was the case, what with other ___xxx_TYPE__ being used throughout the test-suite. My bad. > this should only affect the testcases gcc

Re: Maybe expand MAX_RECOG_ALTERNATIVES ?

On Fri, 11 May 2012, Greg McGary wrote: > On 05/11/12 16:00, Greg McGary wrote: > > > My question is this: does it make sense to double MAX_RECOG_ALTERNATIVES so > > that I can use insn attributes to identify operand signatures, or should I > > use > > another approach? > > After some exploration,

Re: Option -pthread in test suite with cross compilers

On Fri, 18 May 2012, Ralf Corsepius wrote: > On 05/18/2012 09:24 AM, Sebastian Huber wrote: > > Hi, > > > > if I run the ARM GCC test suite for C and C++ with the arm-rtemseabi4.11 > > target, then I get several unexpected errors due to: > > > > gcc/testsuite/gcc/gcc.log:xgcc: error: unrecognized c

Re: Option -pthread in test suite with cross compilers

On Fri, 18 May 2012, Joel Sherrill wrote: > I don't mind having -pthread be a noop but the leap > from a having a header file to having a specific gcc > option is a stretch IMO. Unless EVERY gcc target with > pthread support is required by gcc to have that option. > Is that the undocumented(?) inte

Re: Option -pthread in test suite with cross compilers

On Fri, 18 May 2012, Ian Lance Taylor wrote: > Joel Sherrill writes: > > > On 05/18/2012 08:27 AM, Ian Lance Taylor wrote: > >> Ralf Corsepius writes: > >> > >>> I am not sure, but AFAICT, -pthread is Linux-specific. > >> It's not properly documented, but -pthread works on a number of hosts, > >>

Re: array bounds violation in caller-save.c : duplicate hard regs check added

On Fri, 25 May 2012, DJ Delorie wrote: > If I apply this patch, which checks for duplicate hard registers within > -fira-share-save-slots, the following *-elf targets fail due to the assert: > > bfin cris m32c rl78 rx sh sh64 v850 Oop. An no clue as to what's wrong. Can you pretty please m

<    1   2   3   >