Re: git conversion in progress

Am 11.01.20 um 02:18 schrieb Joseph Myers: I encourage people to continue to work on improving the documentation for using git with GCC ( and list some of the things that it seems

Re: git conversion in progress

Am 11.01.20 um 02:18 schrieb Joseph Myers: I encourage people to continue to work on improving the documentation for using git with GCC ( and list some of the things that it seems

Re: git conversion in progress

Am 14.01.20 um 12:34 schrieb Andreas Schwab: On Jan 14 2020, Georg-Johann Lay wrote: git clone --reference original-gcc ... Don't use --reference. It is too easy to lose work if you don't know what you are doing. Andreas. Well, then it should not be proposed in git.html then?

Re: git conversion in progress

Am 11.01.20 um 02:18 schrieb Joseph Myers: I encourage people to continue to work on improving the documentation for using git with GCC Hi, the front page reads "Our sources are readily and freely available via SVN...", similar recommendation for SVN in https://gcc.gnu.org/snapshots.html Jo

Re: subversion status on gcc.gnu.org

Am 20.03.20 um 18:37 schrieb Frank Ch. Eigler via Gcc: Hi - Both svn: and ssh+svn: now work for your archeological needs. Further, URLs such as https://gcc.gnu.org/viewcvs?rev=279160&root=gcc&view=rev https://gcc.gnu.org/r123456 are mapped to gitweb searches that try to locate the matching Fro

Re: Support for named address spaces in C++

Andrew Pinski via Gcc schrieb: On Wed, Jun 3, 2020 at 2:32 PM Max Ruttenberg via Gcc wrote: Hi all, I’ve added a named address space to our backend and I noticed that it is only support in C. Has anyone had experience porting this feature to C++? Is there any technical reason why it’s not su

Re: GTY / gengtype question - adding a new header file

Steve Ellcey schrieb: I have a question about gengtype and GTY. I was looking at adding some code to mips.c and it occurred to me that that file was getting very large (19873 lines). So I wanted to add a new .c file instead but that file needed some types that were defined in mips.c and not in

Re: gcc-4.9.1 generating different code between two successive builds

Cole schrieb: Hi, I am busy trying to generate a package for gcc that is consistent between two successive builds, and I am now down to the final few files. I am stuck with the file: cilk-abi-cilk-for.o, which is obviously built with -O2, but between two successive builds, the assembly code gen

Re: avr-gcc doesn't know address space wraps?

Ralph Doncaster schrieb: avr-gcc 4.9.2 doesn't seem to know that the address space wraps, so that an rjmp in the last 2KB of the address space can reach code in the first 2KB. The following code works fine with a jmp, but if I change the jmp ResetVector to rjmp, I get: (.bootloader+0x4): relocat

Re: avr-gcc doesn't know address space wraps?

Ralph Doncaster schrieb: On Sun, Jan 3, 2016 at 1:22 PM, Georg-Johann Lay wrote: Ralph Doncaster schrieb: avr-gcc 4.9.2 doesn't seem to know that the address space wraps, so that an rjmp in the last 2KB of the address space can reach code in the first 2KB. The following code works fine

Re: avr-gcc doesn't know address space wraps?

Ralph Doncaster schrieb: On Sun, Jan 3, 2016 at 2:36 PM, Georg-Johann Lay wrote: Ralph Doncaster schrieb: On Sun, Jan 3, 2016 at 1:22 PM, Georg-Johann Lay wrote: Ralph Doncaster schrieb: avr-gcc 4.9.2 doesn't seem to know that the address space wraps, so that an rjmp in the last 2

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

Tracking this wrong-code bug, I ended up in combine.c::get_last_value() which returns a wrong result. gcc generates wrong code at least with: 4.9 head, 5.2, 6.1 and trunk from today. Before combine we have: (insn 43 31 44 2 (set (reg:QI 18 r18) (const_int 0 [0])) bug-combin.c:29 56 {m

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

On 25.07.2016 23:05, Segher Boessenkool wrote: 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

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

On 26.07.2016 14:51, Segher Boessenkool wrote: 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

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

Segher Boessenkool schrieb: 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

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

On 29.07.2016 09:47, Segher Boessenkool wrote: 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. I am not so surprised because most backends don't make such an intense use of hard-regs like t

Re: [avr] fno-caller-saves and regression tests

On 09.08.2016 07:33, Senthil Kumar Selvaraj wrote: Hi Johann, Turning off -fcaller-saves for AVR makes the testcase I had for PR 71873 pass unless I explicitly add -fcaller-saves to force the compiler to generate the triggering insn patterns. Wonder if we should modify the existing test

Re: How to avoid constant propagation into functions?

On 07.12.2016 14:47, Jakub Jelinek wrote: On Wed, Dec 07, 2016 at 04:12:48PM +0300, Alexander Monakov wrote: [adding gcc@ for the compiler-testsuite-related discussion, please drop either gcc@ or gcc-help@ from Cc: as appropriate in replies] On Wed, 7 Dec 2016, Segher Boessenkool wrote: For ex

Re: Change the calling conventions only for the intrinsic functions.

Am 05/07/2014 04:20 PM, schrieb Umesh Kalappa: Hi All , We are porting GCC 4.8.1 for the customized hardware, where the current calling convention used as arguments are passed by stack and return value by register. But we do have some intrinsic functions(that are supplied by hardware folks )

Re: RFC: Doc update for attribute

Am 05/16/2014 07:16 PM, schrieb Carlos O'Donell: On 05/12/2014 11:13 PM, David Wohlferd wrote: After updating gcc's docs about inline asm, I'm trying to improve some of the related sections. One that I feel has problems with clarity is __attribute__ naked. I have attached my proposed update. Co

Re: Roadmap for 4.9.1, 4.10.0 and onwards?

Am 05/20/2014 06:04 PM, schrieb Paulo Matos: From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of Basile Starynkevitch Sent: 20 May 2014 16:29 To: Bruce Adams Cc: gcc@gcc.gnu.org Subject: Re: Roadmap for 4.9.1, 4.10.0 and onwards? On Tue, 2014-05-20 at 11:09 +0100, Bruce Adams

Re: RFC: Doc update for attribute

Am 05/20/2014 03:31 PM, schrieb Carlos O'Donell: On 05/20/2014 03:59 AM, Georg-Johann Lay wrote: Am 05/16/2014 07:16 PM, schrieb Carlos O'Donell: On 05/12/2014 11:13 PM, David Wohlferd wrote: After updating gcc's docs about inline asm, I'm trying to improve some of the r

PR63633: May middle-end come up width hard regs for insn expanders?

Investigating PR63633 turned out that the middle-end calls insn expanders with hard registers, namely mulsi3 from avr back-end: (define_expand "mulsi3" [(parallel [(set (match_operand:SI 0 "register_operand" "") (mult:SI (match_operand:SI 1 "register_operand" "")

Re: PR63633: May middle-end come up width hard regs for insn expanders?

Jeff Law schrieb: On 10/24/14 10:29, Jakub Jelinek wrote: But I'd say, if you can't handle hard regs in the operands (either general, or some specific ones), you should force the hard regs into pseudos (all hard regs, or just the problematic ones) in the expander. So in this case, check if th

Re: PR63633: May middle-end come up width hard regs for insn expanders?

Am 10/24/2014 08:29 PM, schrieb Jakub Jelinek: On Fri, Oct 24, 2014 at 08:19:57PM +0200, Georg-Johann Lay wrote: Yes, that's the straight forward approach which works so far. Bit tedious, but well... In one case expmed generated different code, though: divmodhi instead of mulhi_highpar

Re: PR63633: May middle-end come up width hard regs for insn expanders?

Am 10/27/2014 08:43 PM, schrieb Jeff Law: On 10/27/14 13:33, Georg-Johann Lay wrote: Am 10/24/2014 08:29 PM, schrieb Jakub Jelinek: On Fri, Oct 24, 2014 at 08:19:57PM +0200, Georg-Johann Lay wrote: Yes, that's the straight forward approach which works so far. Bit tedious, but well... I

How to update reg_dead notes

Hi, in order to fix PR64331 I tried to implement new target-specific passes whose sole purpose is to recompute REG_DEAD notes. The avr BE relies on correct dead notes which are used in avr.c:reg_unused_after which uses dead_or_set_p. avr BE needs correct dead notes in ADJUST_INSN_LENGTH, get_

Re: How to update reg_dead notes

Am 02/24/2015 um 02:11 PM schrieb Kenneth Zadeck: On 02/24/2015 06:41 AM, Georg-Johann Lay wrote: Hi, in order to fix PR64331 I tried to implement new target-specific passes whose sole purpose is to recompute REG_DEAD notes. The avr BE relies on correct dead notes which are used in

Re: How to update reg_dead notes

Am 02/24/2015 um 06:06 PM schrieb Eric Botcazou: Could you give me some advice on correct usage of df or even more preferred point me to a comprehensible documentation of df which is more complete than in df-core.c? Take a look at the c6x and mep ports. Thanks for the hint. I changed the ex

Re: How to update reg_dead notes

Am 02/24/2015 um 07:33 PM schrieb Kenneth Zadeck: when i suggested that you do a build with all of the checking turned on, i wanted you to this without you new code in it.there is a good possibility that the problem is that your port is generating bad rtl. Ah, ok. This actually revealed an

Re: GCC 5 Status Report (2015-03-20)

Joel Sherrill a écrit: I thought I would pass along a couple of data points from the *-rtems targets. Fourteen *-rtems target build OK on the head. The following do not even complete building gcc+newlib. v850 - PR65501. New and must be relatively recent. I built a C/C++ toolset on January 15.

Re: PR63633: May middle-end come up width hard regs for insn expanders?

dedicated hard regs. Issue is about correctness and efficiency of generated code. Am 10/24/2014 um 08:29 PM schrieb Jakub Jelinek: On Fri, Oct 24, 2014 at 08:19:57PM +0200, Georg-Johann Lay wrote: Yes, that's the straight forward approach which works so far. Bit tedious, but well... I

How to get anchors to onlinedocs that can be used in external documents?

How to add an anchor to one of the onlinedocs texi documents? Suppose I'd like to add an HTML anchor to one of the onlinedocs, for example to link it from the gcc release notes. Currently the only anchors are either auto-generated and contain some hashes (hence not usable from external docume

Re: PR63633: May middle-end come up width hard regs for insn expanders?

Am 04/20/2015 um 10:11 PM schrieb Vladimir Makarov: On 17/04/15 05:58 AM, Georg-Johann Lay wrote: I allowed me to CC Vladimir; maybe he can propose how the backend can describe an efficient, constraint-based solution. The problem is about expanders producing insns with non-fixed hard-regs as

Re: avr-gcc generating really dumb code

Ralph Doncaster schrieb: I wrote a small function to convert u8 to hex: // converts 4-bit nibble to ascii hex uint8_t nibbletohex(uint8_t value) { if ( value > 9 ) value += 'A' - '0'; return value + '0'; } // returns value as 2 ascii characters in a 16-bit int uint16_t u8tohex(uint8_t va

Missing barrier in outof_cfglayout

When pass outof_cfglayout is adding barriers, it appears that it misses some situations and then runs into "ICE: missing barrier" in the remainder (or, with checking disabled, into some other assertion). cfgrtl.c:fixup_reorder_chain() reads: /* Now add jumps and labels as needed to match t

Re: Missing barrier in outof_cfglayout

Am 05/11/2015 um 06:58 PM schrieb Jeff Law: Wow, that was fast! On 05/11/2015 10:19 AM, Georg-Johann Lay wrote: When pass outof_cfglayout is adding barriers, it appears that it misses some situations and then runs into "ICE: missing barrier" in the remainder (or, with checking disa

Re: Missing barrier in outof_cfglayout

Am 05/11/2015 um 10:43 PM schrieb Steven Bosscher: On Mon, May 11, 2015 at 7:37 PM, Georg-Johann Lay wrote: BTW, what's the policy about unconditional jumps at that time? There are plenty of unconditional jumps around and all are legitimate; just this one generated by cse1 is wrong?

Re: Missing barrier in outof_cfglayout

Am 05/12/2015 um 05:13 PM schrieb Jeff Law: On 05/12/2015 08:58 AM, Georg-Johann Lay wrote: Ah, yes. The ICE is actually in verify_flow_info: "wrong number of branch edges after unconditional jump in bb 4". It starts with an almost trivial jump table: (jump_insn 82 81 83 19

Code bloat due to silly IRA cost model?

Hi, I am trying to track down a code bloat issue and am stuck becauce I do not understand IRA's cose model. The test case is as simple as it gets: float func (float); float call (float f) { return func (f); } IRA dump shows the following insns: (insn 14 4 2 2 (set (reg:SF 44)

Re: BountySource campaign for gcc PR/91851

John Paul Adrian Glaubitz schrieb: Hello! For anyone who isn't aware of it yet, there is an ongoing BountySource campaign for gcc PR/91851 [1] which seeks to convert the m68k backend to MODE_CC so that it can be kept in gcc versions beyond version 11. Hi, have the cc0 backends been deprecated?

Re: BountySource campaign for gcc PR/91851

Peter Bergner schrieb: On 10/30/19 2:31 PM, Georg-Johann Lay wrote: Hi, have the cc0 backends been deprecated? I didn't follow the lists for some time... At least neither v9 or v10 release notes caveats mention such deprecation, neither is there respective PRs for the cc0 targets.

Re: BountySource campaign for gcc PR/91851

John Paul Adrian Glaubitz schrieb: On 10/31/19 10:00 PM, Georg-Johann Lay wrote: I didn't follow the lists for some time... At least neither v9 or v10 release notes caveats mention such deprecation, neither is there respective PRs for the cc0 targets. https://gcc.gnu.org/ml/gcc-patches

cc0 -> CCmode questions

Segher Boessenkool schrieb: Btw, does GCC support clobbering registers in branches (or cbranch4 for that matter)? This requirement would come up when transitioning avr to cc_mode because cbranches would live post reload. Of course. You cannot have *reloads* on branches, that is all. Segher

Re: GCC wwwdocs move to git done

Am 09.10.19 um 02:27 schrieb Joseph Myers: I've done the move of GCC wwwdocs to git (using the previously posted and discussed scripts), including setting up the post-receive hook to do the same things previously covered by the old CVS hooks, and minimal updates to the web pages dealing with the

Re: GCC wwwdocs move to git done

Am 06.11.19 um 15:03 schrieb Georg-Johann Lay: Am 09.10.19 um 02:27 schrieb Joseph Myers: I've done the move of GCC wwwdocs to git (using the previously posted and discussed scripts), including setting up the post-receive hook to do the same things previously covered by the old CVS hooks

Re: Code bloat due to silly IRA cost model?

alues to stack slots instead of keeping them in registers. Test case (for avr) is as simple as it gets: float func (float); float call (float f) { return func (f); } What am I missing? Johann Georg-Johann Lay schrieb: Hi, I am trying to track down a code bloat issue and am stuck beca

Re: Code bloat due to silly IRA cost model?

Am 11.12.19 um 18:55 schrieb Richard Sandiford: Georg-Johann Lay writes: Hi, doesn't actually anybody know know to make memory more expensive than registers when it comes to allocating registers? Whatever I am trying for TARGET_MEMORY_MOVE_COST and TARGET_REGISTER_MOVE_COST, ira-co

Re: Code bloat due to silly IRA cost model?

Am 11.12.19 um 18:55 schrieb Richard Sandiford: Georg-Johann Lay writes: Hi, doesn't actually anybody know know to make memory more expensive than registers when it comes to allocating registers? Whatever I am trying for TARGET_MEMORY_MOVE_COST and TARGET_REGISTER_MOVE_COST, ira-co

Re: Code bloat due to silly IRA cost model?

Am 13.12.19 um 13:45 schrieb Richard Sandiford: Georg-Johann Lay writes: Am 11.12.19 um 18:55 schrieb Richard Sandiford: Georg-Johann Lay writes: Hi, doesn't actually anybody know know to make memory more expensive than registers when it comes to allocating registers? Whatever I am t

Re: Help math RTL patterns...

On 17.01.2017 21:41, Steve Silva via gcc wrote: Hi Nathan, Thanks for your advice. I retooled the addhi3 sequence to look like this: (define_expand "addhi3" [(set (match_operand:HI 0 "snap_mem_or_reg""+a,m") (plus:HI (match_operand:HI 1 "snap_mem_or_reg" "%0,0") (match_operand:HI 2 "genera

Getting spurious FAILS in testsuite?

Hi, when I am running the gcc testsuite in $builddir/gcc then $ make check-gcc RUNTESTFLAGS='ubsan.exp' comes up with spurious fails. Running target unix Using /usr/share/dejagnu/baseboards/unix.exp as board description file for target. Using /usr/share/dejagnu/config/unix.exp as generic inter

Re: Getting spurious FAILS in testsuite?

On 01.06.2017 14:59, Georg-Johann Lay wrote: Hi, when I am running the gcc testsuite in $builddir/gcc then FYI, I found the following thread which reports a similar problem, but without and solution :-( CC'ing Diego, maybe he remembers the solution from back then... https://gcc.gnu.o

Re: Getting spurious FAILS in testsuite?

On 01.06.2017 16:16, Marek Polacek wrote: On Thu, Jun 01, 2017 at 02:59:37PM +0200, Georg-Johann Lay wrote: Hi, when I am running the gcc testsuite in $builddir/gcc then $ make check-gcc RUNTESTFLAGS='ubsan.exp' comes up with spurious fails. Running target unix Using /usr/sha

Re: Getting spurious FAILS in testsuite?

On 05.06.2017 18:25, Jim Wilson wrote: On 06/01/2017 05:59 AM, Georg-Johann Lay wrote: Hi, when I am running the gcc testsuite in $builddir/gcc then $ make check-gcc RUNTESTFLAGS='ubsan.exp' comes up with spurious fails. This was discussed before, and the suspicion was that it w

Re: Getting spurious FAILS in testsuite?

On 08.06.2017 23:33, Andrew Pinski wrote: On Thu, Jun 8, 2017 at 2:25 PM, Jeff Law wrote: On 06/08/2017 04:24 AM, Christophe Lyon wrote: On 8 June 2017 at 11:57, Georg-Johann Lay wrote: On 05.06.2017 18:25, Jim Wilson wrote: On 06/01/2017 05:59 AM, Georg-Johann Lay wrote: Hi, when I am

combiner: how to compute cost for bit insertion?

Hi, I'd need some help with the following optimization issue: avr backend supports insns for bit insertion, and insn combiner tries to use them: unsigned char bset (unsigned char a, unsigned char n) { return (a & ~0x40) | (n & 0x40); } Trying 7 -> 14: Successfully matched this instruction:

Re: combiner: how to compute cost for bit insertion?

On 10.07.2017 23:40, Segher Boessenkool wrote: On Mon, Jul 10, 2017 at 05:10:03PM +0200, Georg-Johann Lay wrote: Any ideas for a sane approach? You could change insn_rtx_cost to actually calculate the cost of the insn, not just set_src_cost of a single set. This will need checking on a great

onlinedocs: How to link to external HTML documents?

Hi, in a recent change I added a pointer to some Binutils documentation in doc/extend.texi: see the GNU Binutils @w{@uref{https://sourceware.org/binutils/docs/as/AVR_002dDependent.html,AVR assembler manual}}. This worked well in my local build : gcc/HTML/gcc-8.0.0/gcc/AVR-Function-Attributes.

Re: onlinedocs: How to link to external HTML documents?

Joseph Myers schrieb: On Tue, 11 Jul 2017, Georg-Johann Lay wrote: Hi, in a recent change I added a pointer to some Binutils documentation in doc/extend.texi: see the GNU Binutils @w{@uref{https://sourceware.org/binutils/docs/as/AVR_002dDependent.html,AVR assembler manual}}. For other

[patch] RFC: Hook for insn costs?

Hi, the current cost computations in rtlanal.c and maybe other places suffer from the fact that they are hiding parts of the expressions from the back-end, like SET_DESTs of single_set or the anatomy of PARALELLs. Would it be in order to have a hook like the one attached? I am aware of that, in

Re: [patch] RFC: Hook for insn costs (v2)?

uch a change be in order in principle? Ideas to improve it? I would then round it up and propose it as a patch. Johann On 12.07.2017 15:15, Georg-Johann Lay wrote: Hi, the current cost computations in rtlanal.c and maybe other places suffer from the fact that they are hiding parts o

Re: Getting spurious FAILS in testsuite?

On 12.07.2017 15:40, Bernd Edlinger wrote: On 07/11/17 22:28, Bernd Edlinger wrote: On 07/11/17 21:42, Andrew Pinski wrote: On Tue, Jul 11, 2017 at 12:31 PM, Andrew Pinski wrote: On Tue, Jul 11, 2017 at 12:27 PM, Andrew Pinski wrote: On Tue, Jul 11, 2017 at 12:15 PM, Bernd Edlinger wrote:

Re: Getting spurious FAILS in testsuite?

On 13.07.2017 18:47, Bernd Edlinger wrote: On 07/13/17 16:31, Georg-Johann Lay wrote: On 12.07.2017 15:40, Bernd Edlinger wrote: On 07/11/17 22:28, Bernd Edlinger wrote: On 07/11/17 21:42, Andrew Pinski wrote: On Tue, Jul 11, 2017 at 12:31 PM, Andrew Pinski wrote: On Tue, Jul 11, 2017 at

expmed costs and i386.c cost for widening mul (PR81444)

Hi, while testing a patch to fix PR81444, I came across a new FAIL due to the patch in i386.c/pr71321.c PR81444 is about wrong modes used by expmed.c as it computes costs for widening operations like widening mul. It uses GET_MODE_WIDER_MODE for the wider mode where is should use GET_MODE_2XWID

Re: expmed costs and i386.c cost for widening mul (PR81444)

On 17.07.2017 10:53, Georg-Johann Lay wrote: Hi, while testing a patch to fix PR81444, I came across a new FAIL due to the patch in i386.c/pr71321.c PR81444 is about wrong modes used by expmed.c as it computes costs for widening operations like widening mul. It uses GET_MODE_WIDER_MODE for

Re: [patch] RFC: Hook for insn costs?

On 16.07.2017 00:51, Segher Boessenkool wrote: Hi! On Wed, Jul 12, 2017 at 03:15:09PM +0200, Georg-Johann Lay wrote: the current cost computations in rtlanal.c and maybe other places suffer from the fact that they are hiding parts of the expressions from the back-end, like SET_DESTs of

Bug in lto-plugin.c ?

Hi, I tried to build a canadian cross with Configured with --build=x86_64-linux-gnu --host=i686-w64-mingw32 --target=avr While the result appears to work under wine, I am getting the following error from ld in a non-LTO compile + link: e:/winavr/8.0_2017-07-18/bin/../lib/gcc/avr/8.0.0/../../../.

Re: Bug in lto-plugin.c ?

On 19.07.2017 12:46, Richard Biener wrote: On Tue, Jul 18, 2017 at 6:36 PM, Georg-Johann Lay wrote: Hi, I tried to build a canadian cross with Configured with --build=x86_64-linux-gnu --host=i686-w64-mingw32 --target=avr While the result appears to work under wine, I am getting the following

Re: Register allocation trouble

Andrew Stubbs schrieb: Hi all, I have an architecture that has two register files. Let's call them class A and class B. There are some differences between their capabilities, but for the purposes of this problem, they can be considered to be identical, both holding SImode values, and both abl

Re: GCC Runtime Library Exception in gcc/config/* files?

Sebastian Huber schrieb: Hello, there are some files in gcc/config/* that contain the GCC Runtime Library Exception grep -r --include='*.[ch]' 'GCC Runtime Library Exception' -l gcc/config | wc 186 1865361 and some files that don't include it grep -r --include='*.[ch]' 'GCC Ru

Re: Register allocation trouble

On 24.07.2017 13:38, Andrew Stubbs wrote: Thanks to all those who replied. :-) Here's what I've done to fix the problem: 1. Set the base rclass to A only. 2. Configured secondary reloads to B via A. 3. Disabled the Rb constraint. [*] That's enough to create correct code, but it's pretty horr

Re: Register allocation trouble

Andrew Stubbs schrieb: On 24/07/17 14:58, Georg-Johann Lay wrote: Dunno if that works in all situation. For example, when the register allocator is facing high register pressure and decides to spill the target register, it uses the constraints of the matched insn. That would be a memory to

Overwhelmed by GCC frustration

Around 2010, someone who used a code snipped that I published in a wiki, reported that the code didn't work and hang in an endless loop. Soon I found out that it was due to some GCC problem, and I got interested in fixing the compiler so that it worked with my code. 1 1/2 years later, in 2011, I

Re: Overwhelmed by GCC frustration

On 31.07.2017 19:54, Jeff Law wrote: On 07/31/2017 11:23 AM, Segher Boessenkool wrote: On Tue, Aug 01, 2017 at 01:12:41AM +0900, Oleg Endo wrote: I could probably write a similar rant. This is the life of a "minority target programmer". Most development efforts are being done with primary tar

[patch,avr,v5,packported] Apply avr back-ports to v5.

Backported the wollowing PRs to v5: PR81910, PR80462, PR81407, PR67353, PR79883, PR81305, PR75963, PR81487. gcc/ Backport from 2017-08-22 trunk r251256. PR target/81910 * config/avr/avr.c (avr_handle_addr_attribute): Early return if not VAR_P. Filter attribute wa

Re: gcc torture test pr52286.c

Paul S schrieb: I've ported gcc to a 16 bit CPU and have all torture tests passing bar one, pr52286.c The offending lines of code are long a, b = 0; asm ("" : "=r" (a) : "0" (0)); which should cause zero to be assigned to the "a" SI sized variable. Inspecting the generated code revealed t

Re: Status of m32c target?

On 13.01.2018 00:07, Joseph Myers wrote: On Fri, 12 Jan 2018, Jeff Law wrote: I was going to suggest deprecation for gcc-8 given how badly it was broken in gcc-7 and the lack of maintenance on the target. While we're considering deprecations, what happened to the idea of setting a timescale b

Re: extern const initialized warns in C

Jay K schrieb: extern const int foo = 123; Why does this warn? This is a valid portable form, with the same meaning across all compilers, and, importantly, portably to C and C++. I also wondered about this. In C99 §6.9.2 "External object definitions" there's actually the following example in

Re: extern const initialized warns in C

On 22.01.2018 16:20, Jonathan Wakely wrote: On 21 January 2018 at 12:08, Georg-Johann Lay wrote: Jay K schrieb: extern const int foo = 123; Why does this warn? This is a valid portable form, with the same meaning across all compilers, and, importantly, portably to C and C++. I also

Re: $target.h vs $target-protos.h

Sandra Loosemore schrieb: The internals manual says that a backend for $target should have $target.h and $target-protos.h files, but doesn't say what the difference between them is or what belongs in which file. Current practice seems to be a mix of (1) $target.h contains macro definitions a

TARGET_HELP: --target-help vs. --help=target

Hi, I noticed a difference between --target-help and --help=target Whilst --target-help also calls target hooh TARGET_HELP to display additional information, using --help=target does not. This is in sync with the documentation, but appears a bit odd. It this a desired behaviour and is there a spe

How working with bugzilla?

Hi, what is needed to work with bugzilla like: - assigning a bug to me - confirming a bug (changing status) - adding affected versions like "known to fail" My user name is avr at gjlay dot de. It there a connexion between gcc role like maintainer and bugzilla access rights? Thanks, Johann

gcc-4.5/4.4: Bug in .subreg1 pass?

Hi, I am trying to track down/fix PR target/45291. The problem is that pass .subreg1 generates invalid subregs. According to internals "10.8 Registers and Memory, Normal Subregs" a normal (non-paradoxical) subreg as Lvalue sets the specifyed subreg and leaves the remaining part of the target word

Re: gcc-4.5/4.4: Bug in .subreg1 pass?

Paul Koning schrieb: On Feb 24, 2011, at 12:46 PM, Eric Botcazou wrote: Maybe the misunderstanding occurs when the mode of the subreg is less than word_size? It would certainly make sense that a subreg write of less than word_size leaves the bits undefined. ie, if word_size is SImode and we

Re: gcc-4.5/4.4: Bug in .subreg1 pass?

Eric Botcazou schrieb: What does "word" mean here? Is it a 32-bit entity or is it according to word_mode which is QImode for avr? The latter, it is machine-dependent. So the same should be true for QI-subregs of scalar modes if UNITS_PER_WORT = 1. Right? Right. Thanks for that definite c

Re: gcc-4.5/4.4: Bug in .subreg1 pass?

Denis Chertykov schrieb: 2011/2/26 Georg Johann Lay Eric Botcazou schrieb: What does "word" mean here? Is it a 32-bit entity or is it according to word_mode which is QImode for avr? The latter, it is machine-dependent. So the same should be true for QI-subregs of scala

Re: gcc-4.5/4.4: Bug in .subreg1 pass?

Georg-Johann Lay schrieb: Denis Chertykov schrieb: 2011/2/26 Georg Johann Lay Eric Botcazou schrieb: What does "word" mean here? Is it a 32-bit entity or is it according to word_mode which is QImode for avr? The latter, it is machine-dependent. So the same should be t

Re: gcc-4.5/4.4: Bug in .subreg1 pass?

Georg-Johann Lay schrieb: Denis Chertykov schrieb: 2011/2/26 Georg Johann Lay Eric Botcazou schrieb: What does "word" mean here? Is it a 32-bit entity or is it according to word_mode which is QImode for avr? The latter, it is machine-dependent. So the same should be t

Re: gcc-4.5/4.4: Bug in .subreg1 pass?

Denis Chertykov schrieb: 2011/2/26 Georg-Johann Lay : Ok, this is the patch I meant: http://gcc.gnu.org/viewcvs?view=revision&revision=86842 it allows just Pmode in r29:r28 because of some spill failures in PR15417 and PR12017. It was a stupid workaround. I think that the problem ex

RFC: [4.7] Adding CUMULATIVE_ARGS to targetm.calls.function_ok_for_sibcall?

Is it ok to extend targetm.function_ok_for_sibcall so that it passes also a pointer to the callee's CUMULATIVE_ARGS structure? In some situation it is quite tedious to recompute information like which hard regs are used to pass arguments from the passed trees (call expression resp., decl). This in

Re: RFC: [4.7] Adding CUMULATIVE_ARGS to targetm.calls.function_ok_for_sibcall?

Joern Rennecke wrote: Quoting Georg-Johann Lay : Is it ok to extend targetm.function_ok_for_sibcall so that it passes also a pointer to the callee's CUMULATIVE_ARGS structure? CUMULATIVE_ARGS is a target-dependent type, and thus every use of it in the interface of target hooks shou

Why IRA stores in frame, not in callee-saved reg?

In current trunk (r170704), 4.4-branch and 4.5-branch I observe the following optimization issue in IRA: It saves regs in the frame instead of in callee-saved registers which would be much smarter. In the following C source, foo2 is compiled as desired (push/pop r17 to save r24). In foo1 and foo3

Re: Why IRA stores in frame, not in callee-saved reg?

Georg-Johann Lay schrieb: > In current trunk (r170704), 4.4-branch and 4.5-branch I observe the > following optimization issue in IRA: It saves regs in the frame > instead of in callee-saved registers which would be much smarter. > > In the following C source, foo2 is compiled a

Re: Why IRA stores in frame, not in callee-saved reg?

Vladimir Makarov schrieb: On 03/08/2011 06:36 AM, Georg-Johann Lay wrote: Georg-Johann Lay schrieb: In current trunk (r170704), 4.4-branch and 4.5-branch I observe the following optimization issue in IRA: It saves regs in the frame instead of in callee-saved registers which would be much

Re: Using cc (question from avr)

Paulo J. Matos schrieb: Hi, I am having some trouble really understanding the working of cc_status. In order to understand it better I was looking at the code for avr under gcc 4.3. My assumption is that set_zn, set_* means that an instructions _changes_ these flags. So an instruction that s

Re: avr compilation

Paulo J. Matos schrieb: > Hi all, > > I am looking at the avr backend in order to try to sort some things out > on my own backend. > > One of the tests I am doing is by compiling the following: > int x = 0x1010; > int y = 0x0101; > > int add(void) > { > return x+y; > } > > It compiles to (in

Using secondary reload to reload CONST_INT?

The AVR controller basically has two kinds of hard registers: * LD_REGS (constraint "d") that can move immediates * NO_LD_REGS (constraint "l") that cannot move immediates movsi insn of avr backend does not supply an "l,i" constraint alternative, so that reload takes care of that and allocates

Re: Using secondary reload to reload CONST_INT?

Denis Chertykov schrieb: > 2011/3/20 Georg-Johann Lay : >> The AVR controller basically has two kinds of hard registers: >> >> * LD_REGS (constraint "d") that can move immediates >> * NO_LD_REGS (constraint "l") that cannot move immediates >>

Re: Using secondary reload to reload CONST_INT?

Denis Chertykov schrieb: > Please, provide test results. Denis. Ok, will take some time. Johann

  1   2   3   4   >