Hi
I'm getting this failure on powerpc:
../../gcc/gcc/fortran/simplify.c: In function 'gfc_simplify_scale':
../../gcc/gcc/fortran/simplify.c: In function 'gfc_simplify_scale':
../../gcc/gcc/fortran/simplify.c:3345: error: type mismatch in binary
expression
long unsigned int
long unsigned int
i
On 9/18/07, Jim Wilson <[EMAIL PROTECTED]> wrote:
> Tomas Svensson wrote:
> There is no optimization at all without -O, no matter how many -f
> options you use. What you want to do is -O -fno-foo -fno-bar etc.
> However, we do not have -f options for every optimization, so there is
> no guarantee
Hi Mark,
there are 3 simple patches waiting for review which I hoped to get in
in stage 2. They should be a nop for targets not exploiting the new
insn attribute. So I hope they still qualify for early stage 3. I've
several patches on my harddisk relying on that feature to be present
so I would
David Daney wrote:
> Richard,
>
> There seems to be a small problem with the MIPS atomic memory operations
> patch I recently committed
> (http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01290.html), in that on a
> dual CPU machine it does not quite work.
>
> You can look at http://gcc.gnu.org/bugz
Andreas,
besides doing this act of bookkeeping, could you also point out a solution to
the problem at hand?
Thanks, Jan
>>> "schwab at suse dot de" <[EMAIL PROTECTED]> 19.09.07 11:47 >>>
--- Comment #4 from schwab at suse dot de 2007-09-19 09:47 ---
*** This bug has been marked as a
"Andreas Krebbel" <[EMAIL PROTECTED]> writes:
> there are 3 simple patches waiting for review which I hoped to get in
> in stage 2. They should be a nop for targets not exploiting the new
> insn attribute. So I hope they still qualify for early stage 3. I've
> several patches on my harddisk rel
"Andreas Krebbel" <[EMAIL PROTECTED]> writes:
> there are 3 simple patches waiting for review which I hoped to get in
> in stage 2. They should be a nop for targets not exploiting the new
> insn attribute. So I hope they still qualify for early stage 3. I've
> several patches on my harddisk rel
"Tomas Svensson" <[EMAIL PROTECTED]> writes:
> So I guess the problem is somehow caused by global common
> subexpression elimination. Could it be that gcse changes the insn in
> some way, making it unrecognizable by the usual define_insn's?
gcse will never convert a recognizable insn into an unre
Hi Ian,
> I'm sorry I haven't had time to reply to this patch, but I'm not
> entirely happy with it. Conceptually it seems reasonable, but I don't
> understand why your implementation has to work the way it does; it
> seems overly complicated. And I wonder whether it wouldn't be simpler
> to ach
On Tue, Sep 18, 2007 at 05:12:48PM -0700, David Daney wrote:
> There seems to be a small problem with the MIPS atomic memory operations
> patch I recently committed
> (http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01290.html), in that on a
> dual CPU machine it does not quite work.
>
> You can
On Wed, 19 Sep 2007, Ralf Baechle wrote:
> Please make this loop closure branch a branch-likely. This is necessary
> as a errata workaround for some processors.
Do we emulate them for MIPS I? We do emulate "ll" and "sc" and adding
"sync" is easy (as a no-op as support for R3000 SMP is unlikel
Maciej W. Rozycki wrote:
On Wed, 19 Sep 2007, Ralf Baechle wrote:
Please make this loop closure branch a branch-likely. This is necessary
as a errata workaround for some processors.
Do we emulate them for MIPS I? We do emulate "ll" and "sc" and adding
"sync" is easy
Currently, I (and th
On Wed, 19 Sep 2007, David Daney wrote:
> Currently, I (and thus GCC 4.3) am assuming that Linux emulates 'll', 'sc' and
> 'sync', If sync is not emulated, we would need to adjust the code generation
> so that it is not emitted on ISAs that don't support it.
While adding "sync" is trivial enough
David Daney wrote:
Maciej W. Rozycki wrote:
On Wed, 19 Sep 2007, Ralf Baechle wrote:
Please make this loop closure branch a branch-likely. This is necessary
as a errata workaround for some processors.
Do we emulate them for MIPS I? We do emulate "ll" and "sc" and
adding "sync" is easy
Maciej W. Rozycki wrote:
On Wed, 19 Sep 2007, David Daney wrote:
Currently, I (and thus GCC 4.3) am assuming that Linux emulates 'll', 'sc' and
'sync', If sync is not emulated, we would need to adjust the code generation
so that it is not emitted on ISAs that don't support it.
While adding "
On Wed, 19 Sep 2007, David Daney wrote:
> I just checked myself. 'sync' is not emulated. We will have to make a change
> so that it is not emitted on ISAs that do not support it.
The problem is if such software is run on a newer processor it may
silently break. Tough, I know... We should ha
David Daney wrote:
> Maciej W. Rozycki wrote:
>> On Wed, 19 Sep 2007, David Daney wrote:
>>> Currently, I (and thus GCC 4.3) am assuming that Linux emulates 'll',
>>> 'sc' and
>>> 'sync', If sync is not emulated, we would need to adjust the code
>>> generation
>>> so that it is not emitted on ISA
On Wed, Sep 19, 2007 at 07:12:33PM +0100, Thiemo Seufer wrote:
> >> Another option is to depend on the setting of -mbranch-likely. By
> >> default it is on only for the processors which implement it and do not
> >> discourage it, i.e. these of the MIPS II, MIPS III and MIPS IV ISAs.
All MIPS
We have performance results that show GCC now delivers outstanding performance
on AMD's Quad-core Barcelona processors. We've just posted our SPECint results
tests with GCC 4.1.2 on AMD's Quad-core Barcelona processors. We just want to
thank all of you for doing such a great job on the performanc
On Mon, 17 Sep 2007, Dave Korn wrote:
> Hyphenated. It's not a line option of a command, it's an option of a
> command-line.
On Mon, 17 Sep 2007, Joseph S. Myers wrote:
> As an adjective I think it should be "command-line"; I'm sure Sandra will
> correct me if I'm wrong here.
On Mon, 17 Sep 200
Christopher Key wrote:
The most concise form that I've found so far is:
const int d = 8; // 16, 32 etc
x = y / d - ((y % d < 0) ? 1 : 0)
although this still produces rather longer code (see example below).
Any integer divide by constant can be replaced by a sequence of
multiply, shift, and add
Michael Meissner wrote:
> We have performance results that show GCC now delivers outstanding performance
> on AMD's Quad-core Barcelona processors. We've just posted our SPECint
> results
> tests with GCC 4.1.2 on AMD's Quad-core Barcelona processors. We just want to
> thank all of you for doing
22 matches
Mail list logo
