Re: Understanding bogus? gcc.dg/signbit-6.c

Am 02.10.24 um 15:55 schrieb Georg-Johann Lay: I am having problems understanding test case gcc.dg/signbit-6.c which fails on a 16-bit platform (avr). https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/testsuite/gcc.dg/signbit-6.c;h=da186624cfa057dfc3780c8af4f6b1335ba07e7e;hb=HEAD The relevant

Understanding bogus? gcc.dg/signbit-6.c

I am having problems understanding test case gcc.dg/signbit-6.c which fails on a 16-bit platform (avr). https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/testsuite/gcc.dg/signbit-6.c;h=da186624cfa057dfc3780c8af4f6b1335ba07e7e;hb=HEAD The relevant part of the code is: int main () { TYPE a[N];

Re: x86_64 regression tests arbitrary failing?

Am 17.09.24 um 19:03 schrieb Arsen Arsenović: Hi, Georg-Johann Lay writes: For a trivial change that I'd like to bootstrap + regtest, I am am getting FAILs like: $ diff xxx/gcc/testsuite/gcc/gcc.sum yyy/gcc/testsuite/gcc/gcc.sum 164656c164656 < PASS: c-c++-common/tsan/atomic_stack

x86_64 regression tests arbitrary failing?

For a trivial change that I'd like to bootstrap + regtest, I am am getting FAILs like: $ diff xxx/gcc/testsuite/gcc/gcc.sum yyy/gcc/testsuite/gcc/gcc.sum 164656c164656 < PASS: c-c++-common/tsan/atomic_stack.c -O0 output pattern test --- > FAIL: c-c++-common/tsan/atomic_stack.c -O0 output p

Re: value-range.cc:2165: ICE in invert

Am 03.09.24 um 18:12 schrieb Andrew MacLeod: On 8/25/24 03:48, Richard Biener wrote: On Sat, Aug 24, 2024 at 6:19 PM Georg-Johann Lay wrote: Trying to use the value-range interface and functions I am running into that ICE when using invert().   From what the sources suggest, invert

value-range.cc:2165: ICE in invert

Trying to use the value-range interface and functions I am running into that ICE when using invert(). From what the sources suggest, invert() computes the complement of the current set (the union of finitely many intervals). For example, when I have a range of [-128, -1] for int8_t, invert() run

Re: Changing control flow in an RTL pass

Am 21.08.24 um 11:31 schrieb Richard Biener: On Wed, Aug 21, 2024 at 11:19 AM Georg-Johann Lay wrote: Hi, in an RTL optimization pass I would like to perform a transformation like from old code: [bb 1] if (condA);; insn1 goto label_1; [bb 2] if (cond_B) ;; insn2

Changing control flow in an RTL pass

Hi, in an RTL optimization pass I would like to perform a transformation like from old code: [bb 1] if (condA);; insn1 goto label_1; [bb 2] if (cond_B) ;; insn2 goto label_2; to new code: [bb 1] if (cond1) ;; branch1 goto label_2; [bb 2] if (cond2) ;;

Re: Commit missing from gcc-cvs and bugzilla

Am 12.08.24 um 19:45 schrieb Mark Wielaard: Hi Johann, On Sat, Aug 10, 2024 at 07:34:09PM +0200, Georg-Johann Lay wrote: I just noticed that one of my commits, https://gcc.gnu.org/r15-2865 is missing from https://gcc.gnu.org/pipermail/gcc-cvs/2024-August/date.html Even though it has the

Commit missing from gcc-cvs and bugzilla

I just noticed that one of my commits, https://gcc.gnu.org/r15-2865 is missing from https://gcc.gnu.org/pipermail/gcc-cvs/2024-August/date.html Even though it has the tag "PR target/113934" the respective PR didn't get a pointer to the commit: https://gcc.gnu.org/PR113934 Did I do something

Re: Custom Float Instructions

Am 08.08.24 um 10:08 schrieb Amit Hiremath: I know, I am looking for a solution without using __asm macro I explained that, too. Did you even read my answer? Johann On Thu, Aug 8, 2024 at 1:20 PM Georg-Johann Lay You have already asked that question (and got an answer) in gcc-help

Re: Custom Float Instructions

You have already asked that question (and got an answer) in gcc-help@: https://gcc.gnu.org/pipermail/gcc-help/2024-August/thread.html#143628 Johann Am 08.08.24 um 03:54 schrieb Amit Hiremath: Hello, I want to add custom single precision floating point sine, cosine, exp instructions to risc-v

Re: insn attributes: Support blocks of C-code?

Am 17.07.24 um 20:49 schrieb Richard Sandiford: Georg-Johann Lay writes: [...] Am 13.07.24 um 13:44 schrieb Richard Sandiford: It shouldn't be necessary to emit the enum tag these days. If removing Hi Richard, I am not familiar with the gensupport policies, which is the reason wh

Re: insn attributes: Support blocks of C-code?

Am 13.07.24 um 13:44 schrieb Richard Sandiford: Georg-Johann Lay writes: So I had that situation where in an insn attribute, providing a block of code (rather than just an expression) would be useful. Expressions can provided by means of symbol_ref, like in (set (attr "l

Re: Insn combine trying (ior:HI (clobber:HI (const_int 0)))

Am 15.07.24 um 19:53 schrieb Richard Sandiford: Georg-Johann Lay writes: In a test case I see insn combine trying to match such expressions, which do not make any sense to me, like: Trying 2 -> 7: 2: r45:HI=r48:HI REG_DEAD r48:HI 7: {r47:HI=r45:HI|r46:PSI#0;clob

insn attributes: Support blocks of C-code?

So I had that situation where in an insn attribute, providing a block of code (rather than just an expression) would be useful. Expressions can provided by means of symbol_ref, like in (set (attr "length") (symbol_ref ("1 + GET_MODE_SIZE (mode)"))) However providing a block of code gives a

md: define_code_attr / define_mode_attr: Default value?

Is it possible to specify a default value in define_code_attr resp. define_mode_attr ? I had a quick look at read-rtl, and it seem to be not the case. Or am I missing something? Johann

Re: Setting insn mnemonic partly automagically

Am 22.06.24 um 10:46 schrieb Stefan Schulze Frielinghaus: On Fri, Jun 21, 2024 at 09:50:43PM +0200, Georg-Johann Lay wrote: Am 17.06.24 um 21:13 schrieb Stefan Schulze Frielinghaus via Gcc: Hi all, I'm trying to add an alternative to an existing insn foobar: (define_insn "foobar&

Re: Setting insn mnemonic partly automagically

Am 17.06.24 um 21:13 schrieb Stefan Schulze Frielinghaus via Gcc: Hi all, I'm trying to add an alternative to an existing insn foobar: (define_insn "foobar" [(set (match_operand ...) (match_operand ...))] "" "@ foo bar #") Since the asm output depends on the op

Re: How to target a processor with very primitive addressing modes?

Am 10.06.24 um 18:35 schrieb Paul Koning: On Jun 10, 2024, at 11:48 AM, Georg-Johann Lay wrote: Am 08.06.24 um 11:32 schrieb Mikael Pettersson via Gcc: On Thu, Jun 6, 2024 at 8:59 PM Dimitar Dimitrov wrote: Have you tried defining TARGET_LEGITIMIZE_ADDRESS for your target? From a quick

Re: How to target a processor with very primitive addressing modes?

Am 08.06.24 um 11:32 schrieb Mikael Pettersson via Gcc: On Thu, Jun 6, 2024 at 8:59 PM Dimitar Dimitrov wrote: Have you tried defining TARGET_LEGITIMIZE_ADDRESS for your target? From a quick search I see that the iq2000 and rx backends are rewriting some PLUS expression addresses with insn s

Re: How to avoid some built-in expansions in gcc?

Am 31.05.24 um 22:12 schrieb Richard Biener: Am 31.05.2024 um 20:56 schrieb Georg-Johann Lay :  Am 31.05.24 um 19:32 schrieb Richard Biener: Am 31.05.2024 um 17:25 schrieb Paul Koning via Gcc :  On May 31, 2024, at 11:06 AM, Georg-Johann Lay wrote: Am 31.05.24 um 17:00 schrieb

Re: How to avoid some built-in expansions in gcc?

Am 31.05.24 um 19:32 schrieb Richard Biener: Am 31.05.2024 um 17:25 schrieb Paul Koning via Gcc :  On May 31, 2024, at 11:06 AM, Georg-Johann Lay wrote: Am 31.05.24 um 17:00 schrieb Paul Koning: On May 31, 2024, at 9:52 AM, Georg-Johann Lay wrote: What's the recommended w

Re: How to avoid some built-in expansions in gcc?

Am 31.05.24 um 17:00 schrieb Paul Koning: On May 31, 2024, at 9:52 AM, Georg-Johann Lay wrote: What's the recommended way to stop built-in expansions in gcc? For example, avr-gcc expands isinff() to a bloated version of an isinff() implementation that's written in asm

Re: How to avoid some built-in expansions in gcc?

Am 31.05.24 um 15:56 schrieb Jonathan Wakely: On Fri, 31 May 2024 at 14:52, Georg-Johann Lay wrote: What's the recommended way to stop built-in expansions in gcc? For example, avr-gcc expands isinff() to a bloated version of an isinff() implementation that's written in asm

How to avoid some built-in expansions in gcc?

What's the recommended way to stop built-in expansions in gcc? For example, avr-gcc expands isinff() to a bloated version of an isinff() implementation that's written in asm (PR115307). Johann

Will PR rtl-optimization/101188 be back-ported to v13 ?

We have this (rare?) wrong code bug https://gcc.gnu.org/PR101188 which Jeff fixed for v14: https://gcc.gnu.org/r14-1738 The fix doesn't fit 100% for v13 but the PR has a backport for v13 in comment #16. Would be great if this could be part of v13.3, but I don't have the resources to reg-test

Re: Why is -ffold-mem-offsets a target option?

Am 15.01.24 um 13:20 schrieb Richard Biener: On Mon, Jan 15, 2024 at 11:22 AM Georg-Johann Lay wrote: Just noticed that -ffold-mem-offsets is a target option, i.e. it is shown with --help=target > grep -A3 mem-off common.opt ffold-mem-offsets Target Bool Var(flag_fold_mem_offsets) I

Why is -ffold-mem-offsets a target option?

Just noticed that -ffold-mem-offsets is a target option, i.e. it is shown with --help=target > grep -A3 mem-off common.opt ffold-mem-offsets Target Bool Var(flag_fold_mem_offsets) Init(1) Fold instructions calculating memory offsets to the memory access instruction if possible. Is that "Target

varasm.cc: how to hook in assemble_variable ?

The avr backend supports variable attributes like the following that allow to define symbols: __attribute__((address(1234)) char a_symbol; would produce assembly .global a_symbol a_symbol = 1234 This works except for -fdata-sections -fno-common (PR112952), and I am struggling to find a fix. C

Re: LRA for avr: Maintain live range info for pseudos assigned to FP?

Am 20.11.23 um 08:14 schrieb SenthilKumar.Selvaraj--- via Gcc: On Thu, 2023-10-05 at 15:33 -0400, Vladimir Makarov wrote: EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe On 9/7/23 07:21, senthilkumar.selva...@microchip.com wrote: Hi, One more

Re: Porting to a custom ISA

Am 15.08.23 um 14:06 schrieb Richard Biener via Gcc: On Tue, Aug 15, 2023 at 1:38 PM MegaIng via Gcc wrote: Also, on another backend I saw comments relating to libgcc (or newlib?) not working that well on systems where int is 16bit. Is that still true, and what is the best workaround? You

Re: LRA for avr: Arithmetic on stack pointer

Am 09.08.23 um 13:15 schrieb SenthilKumar.Selvaraj--- via Gcc: [...] I guess the condition exists to ensure sp_off is always correct? Considering LRA already handles post_dec of SP just fine, perhaps it can allow RTX like (set (reg/f:HI 32 __SP_L__) (plus:HI (reg/f:HI 32 __SP_L__

Re: LRA for avr: Handling hard regs set directly at expand

Am 28.07.23 um 07:04 schrieb senthilkumar.selva...@microchip.com: On Thu, 2023-07-27 at 15:11 +0200, Georg-Johann Lay wrote: EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe Am 17.07.23 um 13:33 schrieb SenthilKumar.Selvaraj--- via Gcc: Hi

Re: LRA for avr: Handling hard regs set directly at expand

Am 17.07.23 um 13:33 schrieb SenthilKumar.Selvaraj--- via Gcc: Hi, The avr target has a bunch of patterns that directly set hard regs at expand time, like so The correct approach would be to use usual predicates together with constraints that describe the register instead of hard regs,

Re: Wrong cost computation / conclusion ins insn combine?

Am 24.05.23 um 14:31 schrieb Richard Earnshaw (lists): On 23/05/2023 19:41, Georg-Johann Lay wrote: For some time now I am staring at the following test case and what combine does with it: typedef struct { unsigned b0 : 1; unsigned b1 : 1; unsigned b2 : 1; unsigned b3

Re: [patch]: Implement PR104327 for avr

Am 25.05.23 um 08:35 schrieb Richard Biener: On Wed, May 24, 2023 at 5:44 PM Georg-Johann Lay wrote: Am 24.05.23 um 11:38 schrieb Richard Biener: On Tue, May 23, 2023 at 2:56 PM Georg-Johann Lay wrote: PR target/104327 not only affects s390 but also avr: The avr backend pre-sets some

Re: inlining failed in call to 'always_inline': target specific option mismatch

Am 24.05.23 um 11:28 schrieb Richard Biener: On Tue, May 23, 2023 at 1:25 PM Georg-Johann Lay wrote: This error pops up in the testsuite for avr. As far as I understand, this is due to target-specific optimization like in avr-common.cc: { OPT_LEVELS_1_PLUS_NOT_DEBUG

Re: [patch]: Implement PR104327 for avr

Am 24.05.23 um 11:38 schrieb Richard Biener: On Tue, May 23, 2023 at 2:56 PM Georg-Johann Lay wrote: PR target/104327 not only affects s390 but also avr: The avr backend pre-sets some options depending on optimization level. The inliner then thinks that always_inline functions are not

Wrong cost computation / conclusion ins insn combine?

For some time now I am staring at the following test case and what combine does with it: typedef struct { unsigned b0 : 1; unsigned b1 : 1; unsigned b2 : 1; unsigned b3 : 1; unsigned b4 : 1; unsigned b5 : 1; unsigned b6 : 1; unsigned b7 : 1; } b_t; Prior to combin

[patch]: Implement PR104327 for avr

PR target/104327 not only affects s390 but also avr: The avr backend pre-sets some options depending on optimization level. The inliner then thinks that always_inline functions are not eligible for inlining and terminates with an error. Proposing the following patch that implements TARGET_CAN_INL

inlining failed in call to 'always_inline': target specific option mismatch

This error pops up in the testsuite for avr. As far as I understand, this is due to target-specific optimization like in avr-common.cc: { OPT_LEVELS_1_PLUS_NOT_DEBUG, OPT_mgas_isr_prologues, NULL, 1 }, { OPT_LEVELS_1_PLUS, OPT_mmain_is_OS_task, NULL, 1 }, // Stick to the "old" plac

Re: [IRA] Code bloat due to register spills in v9, v10, v11, v12 and master

Am 09.12.22 um 22:14 schrieb Vladimir Makarov: On 2022-12-09 14:23, Georg-Johann Lay wrote: There is the following code size regression, filed as https://gcc.gnu.org/PR90706 I am sorry, I feel your frustration. I was not aware of this PR. Unfortunately, the PR was marked as P4 and I

[IRA] Code bloat due to register spills in v9, v10, v11, v12 and master

There is the following code size regression, filed as https://gcc.gnu.org/PR90706 Simple test cases are, for example #define PORT (*((unsigned char volatile*) 0x24)) unsigned short var16; void func (void) { if (2048000ul * var16 > 120ul) PORT |= 1; } When I compile it with $

Re: -Warray-bounds interprets int *var as int var[0] ?

Am 23.11.22 um 18:18 schrieb Andrew Pinski: On Wed, Nov 23, 2022 at 9:15 AM Georg-Johann Lay wrote: The following code throws a warning which I do not understand. Purpose is to save and restore SREG, which is a special function register (SFR) defined by its hardware address as: #define

-Warray-bounds interprets int *var as int var[0] ?

The following code throws a warning which I do not understand. Purpose is to save and restore SREG, which is a special function register (SFR) defined by its hardware address as: #define SREG (*(volatile uint8_t*) (0x3F + __AVR_SFR_OFFSET__)) which is the common C idiom to define such an SFR.

Re: Links to web pages are broken.

Am 11.11.22 um 09:48 schrieb Martin Liška: On 11/10/22 18:01, Jonathan Wakely wrote: Maybe just "docs" or "trunkdocs" or "latestdocs" instead of "onlinedocs-new", since that is (1) very long, and (2) will look silly in ten years when it's not new and we need to add onlinedocs-even-newer 😉 I

Re: Links to web pages are broken.

Am 10.11.22 um 16:25 schrieb Jonathan Wakely: On Thu, 10 Nov 2022 at 15:23, Jonathan Wakely wrote: On Thu, 10 Nov 2022 at 15:17, Georg-Johann Lay wrote: Am 10.11.22 um 16:05 schrieb Martin Liška: On 11/10/22 15:45, Georg-Johann Lay wrote: Hi, I just observed that links like https

Re: Links to web pages are broken.

Am 10.11.22 um 16:05 schrieb Martin Liška: On 11/10/22 15:45, Georg-Johann Lay wrote: Hi, I just observed that links like https://gcc.gnu.org/install/configure.html ceased to work.  Presumably this is to sphinx stuff, but it would be great if not hundreds of links across the web to GCC

Links to web pages are broken.

Hi, I just observed that links like https://gcc.gnu.org/install/configure.html ceased to work. Presumably this is to sphinx stuff, but it would be great if not hundreds of links across the web to GCC pages like the above would be 404. I know that the new link is https://gcc.gnu.org/install

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: 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: 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: 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 ( 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: 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: 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?

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: 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: 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

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: 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

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: 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?

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: $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

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: 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: 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: 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

[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: 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

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: 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

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: 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

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: 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

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: [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

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

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: 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

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: [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

[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: 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

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: 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

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: 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

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

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: 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

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: [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

  1   2   3   4   >