gcc-4.4-20101019 is now available

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

Re: Plug-in Licensing

Justin Seyster writes: > Thanks for this advice. The link to the GCC Exception was especially helpful. > > The trick here is that I'm actually releasing a library designed to be > linked into plug-ins. I want the library itself to be copyleft but > for plug-in authors to retain any licensing fl

Re: how to initialize a pointer using data page mode

Phung Nguyen writes: >> It seems that you want to generate two .int statements.  My question is >> whether you can load those in a single load instruction, or whether you >> also need to generate multiple load instructions. > I need to generate multiple load instructions In that case, you need

Hooks, macros and target configuration

My ongoing work to implement the multilib selection changes described at will in due course require option-related hooks to be shared between the driver and the compilers proper (cc1 etc.). As we do not currently have a hooks system in the driver,

Re: Questions about selective scheduler and PowerPC

> [quote] > Target Hook: int TARGET_SCHED_ISSUE_RATE (void) > [snip] > Although the insn scheduler can define itself the possibility of issue > an insn on the same cycle, the value can serve as an additional > constraint to issue insns on the same simulated processor cycle > [snip] > [/quote] > >

Re: Plug-in Licensing

Thanks for this advice. The link to the GCC Exception was especially helpful. The trick here is that I'm actually releasing a library designed to be linked into plug-ins. I want the library itself to be copyleft but for plug-in authors to retain any licensing flexibility that they would have whe

Re: *_ALIGN_MAX_SKIP macros

> This is OK if you add LABEL_ALIGN_MAX_SKIP, LOOP_ALIGN_MAX_SKIP, > LABEL_ALIGN_AFTER_BARRIER_MAX_SKIP, and JUMP_ALIGN_MAX_SKIP to the > > /* Old target macros that have moved to the target hooks structure. */ > > #pragma GCC poison list in system.h. Thanks, committed with that change.

Re: how to initialize a pointer using data page mode

> It seems that you want to generate two .int statements.  My question is > whether you can load those in a single load instruction, or whether you > also need to generate multiple load instructions. I need to generate multiple load instructions

Re: Plug-in Licensing

Justin Seyster writes: > I'm getting ready to release plug-in code, and I want to have a very > clear idea about licensing before I release. I'm leaning towards > releasing everything as GPLv3, but I do want to know exactly what is > and isn't allowed. GPLv3 is fine. > I know this issue was de

Re: Problem with equivalent memory handling

Jeff Law writes: > Reload has the ability to replace a pseudo with its equivalent memory > location. This is fine and good. > > Imagine: > > 1. We have a pseudo (call is pseudo A) with a read-only memory > equivalent. Pseudo A does not get a hard reg > > 2. Pseudo A crosses a call (because

Re: GCC RTX generation question

"Radu Hobincu" writes: > 1. I have the following code: > > --- > extern void doSmth(); > > void bugTest(){ > doSmth(); > } > --- > > It compiles fine with -O0, but when I try to use -O3, I get the following > compiler error: > > --

Re: Plug-in Licensing

On Tue, 19 Oct 2010 16:05:51 -0400 Justin Seyster wrote: > I'm getting ready to release plug-in code, and I want to have a very > clear idea about licensing before I release. I'm leaning towards > releasing everything as GPLv3, but I do want to know exactly what is > and isn't allowed. A defini

Plug-in Licensing

I'm getting ready to release plug-in code, and I want to have a very clear idea about licensing before I release. I'm leaning towards releasing everything as GPLv3, but I do want to know exactly what is and isn't allowed. I know this issue was debated quite intensely before plug-in support got ad

Problem with equivalent memory handling

Looking for advice here -- while I haven't seen this bug trigger in the mainline, it triggers with the range splitting code I've been working on. Reload has the ability to replace a pseudo with its equivalent memory location. This is fine and good. Imagine: 1. We have a pseudo (call is

Re: 4-15% speed-up in std::sort special case - is it worth the effort?

On Wed, Aug 25, 2010 at 2:44 AM, Jaroslav Hajek wrote: > Hi all, > > I've been experimenting with sorting recently and I have noticed a > possibility to slightly optimize the sorting of std::pair values using > the default < operator. This is, I believe, a common usage case to > retrieve sorting i

GCC RTX generation question

Hello, I wrote here before a few months ago, I'm trying to port GCC to a simple RISC machine and I have two problems I don't seem to be able to fix. I'm using gcc 4.4.3 for both compiling and as source code. 1. I have the following code: --- extern void doSmth(); voi

Re: Questions about selective scheduler and PowerPC

On 10/19/2010 10:16 PM, Andrey Belevantsev wrote: On 19.10.2010 17:57, Jie Zhang wrote: Removing the failing assert fixes the test case. But I wonder why not just get max_issue correct. I'm testing the attached patch. IMHO, max_issue looks confusing. * The concept of ISSUE POINT has never been

Re: Questions about selective scheduler and PowerPC

On 10/19/10 6:16 PM, Andrey Belevantsev wrote: ... I agree that ISSUE_POINTS can be removed, as it was not used (maybe Maxim can comment more on this). I too agree with removing ISSUE_POINTS, it never found any use. Regards, -- Maxim Kuvyrkov CodeSourcery ma...@codesourcery.com (650) 331-3385

Re: Questions about selective scheduler and PowerPC

On 19.10.2010 17:57, Jie Zhang wrote: Removing the failing assert fixes the test case. But I wonder why not just get max_issue correct. I'm testing the attached patch. IMHO, max_issue looks confusing. * The concept of ISSUE POINT has never been used since the code landed in repository. * In the

Re: Questions about selective scheduler and PowerPC

On 10/18/2010 03:41 PM, Andrey Belevantsev wrote: On 18.10.2010 11:31, Jie Zhang wrote: Hi Andrey, On 10/18/2010 03:13 PM, Andrey Belevantsev wrote: Hi Jie, On 18.10.2010 10:49, Jie Zhang wrote: When this error happens, FENCE_ISSUED_INSNS (fence) is 2 and issue_rate is 1. PowerPC 8540 is ca

Re: Bug in expand_builtin_setjmp_receiver ?

Frederic Riss writes: > in builtins.c:expand_builtin_setjmp_receiver I see the following code: > > 827  /* Now put in the code to restore the frame pointer, and argument > 828     pointer, if needed.  */ > 829 #ifdef HAVE_nonlocal_goto > 830  if (! HAVE_nonlocal_goto) > 831 #endif > 832    { > 83

Re: atomicity of x86 bt/bts/btr/btc?

Jay K writes: > It might be nice if optimizing for size would use them with code like e.g.: I encourage you to file a missed-optimization bug at http://gcc.gnu.org/bugzilla , so that this is not forgotten. Ian

Re: secondary reload via 2 intermediary registers

Hi Jeff, Thanks for answer. I managed to make use of an architecture trick which allows me to get the secondary reload via only one intermediary register, but still have some comments to what you wrote me. > > 1.Is it possible to do the secondary reload via 2 > intermediary registers? > > As far

Bug in expand_builtin_setjmp_receiver ?

Hi, in builtins.c:expand_builtin_setjmp_receiver I see the following code: 827  /* Now put in the code to restore the frame pointer, and argument 828     pointer, if needed.  */ 829 #ifdef HAVE_nonlocal_goto 830  if (! HAVE_nonlocal_goto) 831 #endif 832    { 833      emit_move_insn (virtual_stack_

RE: atomicity of x86 bt/bts/btr/btc?

> Subject: RE: atomicity of x86 bt/bts/btr/btc? > From: foxmuldrster > To: jay > CC: gcc > Date: Tue, 19 Oct 2010 03:05:26 -0500 > > > > They do not automatically lock the bus. They will lock the bus with the > > > explicit LOCK prefix, and BTS is typically

RE: atomicity of x86 bt/bts/btr/btc?

> > They do not automatically lock the bus. They will lock the bus with the > > explicit LOCK prefix, and BTS is typically used for an atomic read/write > > operation. > Thanks Rick. > I'll go back to using them. > I'm optimizing mainly for size. > The comment should perhaps be amended. > The "sin

RE: atomicity of x86 bt/bts/btr/btc?

> Subject: Re: atomicity of x86 bt/bts/btr/btc? > From: foxmuldrsterm > To: jay.krell > CC: gcc@gcc.gnu.org > Date: Tue, 19 Oct 2010 02:52:34 -0500 > > > ;; %%% bts, btr, btc, bt. > > ;; In general these instructions are *slow* when applied to memory, > > ;

Re: atomicity of x86 bt/bts/btr/btc?

> ;; %%% bts, btr, btc, bt. > ;; In general these instructions are *slow* when applied to memory, > ;; since they enforce atomic operation. When applied to registers, > > I haven't found documented confirmation that these instructions are atomic > without a lock prefix, > having checked Intel and

atomicity of x86 bt/bts/btr/btc?

gcc-4.5/gcc/config/i386/i386.md: ;; %%% bts, btr, btc, bt. ;; In general these instructions are *slow* when applied to memory, ;; since they enforce atomic operation. When applied to registers, I haven't found documented confirmation that these instructions are atomic without a lock prefix, ha