Modifying generic tree with a plugin

Sombody knows if it is possible modifing the generic during compilation with a plugin?

Re: Compare Elimination problems

Correction, ...compare:CC_N... (R1:HI, 0) On 05/09/14 09:31, Paul Shortis wrote: Thanks Richard, I found the bug. try_eliminate_compare follows register definitions between the flags use and the clobbering compare by register number only, i.e. the register width isn't considered. if (D

Re: Compare Elimination problems

Thanks Richard, I found the bug. try_eliminate_compare follows register definitions between the flags use and the clobbering compare by register number only, i.e. the register width isn't considered. if (DF_REF_REGNO (def) == REGNO (in_a)) break; This caused R1:HI to follow R0:SI c

gcc-4.8-20140904 is now available

Snapshot gcc-4.8-20140904 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.8-20140904/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.8 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches

RE: Register allocation: caller-save vs spilling

Hi Vlad, I added you directly in case you hadn't spotted my original post. A simple example for AArch64 trunk is as follows: // Compile with: -O2 -fomit-frame-pointer -ffixed-d8 -ffixed-d9 -ffixed-d10 -ffixed-d11 -ffixed-d12 -ffixed-d13 -ffixed-d14 -ffixed-d15 -f(no-)caller-saves void g(void);

ICE in bitmap routines with LRA and inline assembly language

I was wondering if anyone has seen this bug involving LRA and inline assembly code. On MIPS, I am getting the attached ICE. Somehow the 'first' pointer in the live_reload_and_inheritance_pseudos bitmap structure is either getting clobbered or is not being correctly initialized to begin with. I

Re: Compare Elimination problems

On 09/03/2014 03:14 PM, Paul Shortis wrote: > (insn 33 84 85 6 (parallel [ > (set (reg:HI 1 r1) > (ashift:HI (reg:HI 1 r1) > (const_int 1 [0x1]))) > (clobber (reg:CC_NOOV 7 flags)) > ]) ../gcc/testsuite/gcc.c-torture/execute/960311

Re: [BUILDROBOT] rs6000-ibm-aix4.3 / rs6000-ibm-aix5.3.0: error: 'ASM_WEAKEN_DECL' was not declared in this scope

Hi, Jan This probably is expected for AIX 4.3. I am surprised that this occurs for AIX 5.3 because I thought that weak support was available after AIX 5.1 or AIX 5.2. I think that the weak support and MAKE_DECL_ONE_ONLY are required for proper operation now. Maybe I should formally deprecate AI

Re: non-reproducible g++.dg/ubsan/align-2.C -Os execution failure

Hello! > I ran into this non-reproducible failure while testing a non-bootstrap build > on x86_64: > > ... > PASS: g++.dg/ubsan/align-2.C -Os (test for excess errors) I found the same problem on x86_64 CentOS 5.10 when testing with -m32: gcc unix/-m32: FAIL: c-c++-common/ubsan/align-2.c -

[BUILDROBOT] rs6000-ibm-aix4.3 / rs6000-ibm-aix5.3.0: error: ‘ASM_WEAKEN_DECL’ was not declared in this scope

Hi! I should have sent this earlier, but maybe you're still interested: [...] g++ -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedant

non-reproducible g++.dg/ubsan/align-2.C -Os execution failure

Hi, I ran into this non-reproducible failure while testing a non-bootstrap build on x86_64: ... PASS: g++.dg/ubsan/align-2.C -Os (test for excess errors) Setting LD_LIBRARY_PATH to .:/data/vries/test-fix-fuse-caller-save-s390/with/nobootstrap/build/x86_64-unknown-linux-gnu/./libstdc++-v3/sr