gcc-4.8-20120422 is now available

Snapshot gcc-4.8-20120422 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.8-20120422/ 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/trunk

Attempting changes to the GIMPLifier

Dear all, I have a few questions regarding how to augment the information dumped in "004t" GIMPLE dumps (prior any optimization). My main concerns are: 1. Printing global variables. 2. Preserving function arguments (what I call an "interface"). Both 1 and 2 are not currently addressed, at

Re: target specific builtin expansion (middle end and back end definition inconsistence problem?).

Feng LI writes: > Yes, you are right. But how could I reference to a backend defined builtin > function in the middle end (I need to generate the builtin function in the > middle end and expand it in x86 backend)? If the function doesn't have a machine-independent definition, then use a target h

Re: target specific builtin expansion (middle end and back end definition inconsistence problem?).

Hi Ian, 2012/4/22 Ian Lance Taylor : > Feng LI writes: > >> I generate builtin function directly in the middle end and and expand >> the builtin function in the x86 backend to certain set of >> instructions. >> >> I've defined x86 builtin functions in the gcc backend like this: >> >> { OPTION_MAS

Re: old archives from 1998

"Paul Edwards" writes: > During the GCC 2.7.2/2.8.1 timeframe I sent emails to this list (or > some similar list) with patches. I have found evidence of the > patches being applied: > > http://hg.sourceforge.jp/view/cbc/GCC/file/ec4cbc2ac877/gcc/FSFChangeLog > > 527 Sun Oct 4 08:37:36 1998 Paul

Re: target specific builtin expansion (middle end and back end definition inconsistence problem?).

Feng LI writes: > I generate builtin function directly in the middle end and and expand > the builtin function in the x86 backend to certain set of > instructions. > > I've defined x86 builtin functions in the gcc backend like this: > > { OPTION_MASK_ISA_TSTAR | OPTION_MASK_ISA_64BIT, > CODE_FOR_

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: > > Other target-patches expos

old archives from 1998

Hello. During the GCC 2.7.2/2.8.1 timeframe I sent emails to this list (or some similar list) with patches. I have found evidence of the patches being applied: http://hg.sourceforge.jp/view/cbc/GCC/file/ec4cbc2ac877/gcc/FSFChangeLog 527 Sun Oct 4 08:37:36 1998 Paul Edwards 528 529 * co

target specific builtin expansion (middle end and back end definition inconsistence problem?).

Hi, I generate builtin function directly in the middle end and and expand the builtin function in the x86 backend to certain set of instructions. I've defined x86 builtin functions in the gcc backend like this: { OPTION_MASK_ISA_TSTAR | OPTION_MASK_ISA_64BIT, CODE_FOR_tstar_create, "__builtin_ia

Re: Mirror

Installed now, after an exchange with Igor and monitoring the mirror for ten days. Thanks, Igor! Gerald On Mon, 9 Apr 2012, Gerald Pfeifer wrote: > I was just going to add your server by means of the patch below, > alas all attempts to rach the server time out. What's going on? > > Gerald > >

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

With some trepidation, because I suspect I'm missing the point :-) Hans-Peter Nilsson writes: > 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 (o