Dear GCC Developers,
I have problems with a dlx backend, which I have ported to GCC 4.1.1.
During compilation of gcc I get warnings about missing mode definitions
in the machine description file. The following instruction template is
affected:
---snip---
;;
;; calls that return int in r1
;;
(defi
On Tue, Feb 20, 2007 at 03:53:55PM -0800, Mark Mitchell wrote:
> Richard Guenther wrote:
>
> >> This is 4.7% drop of SPECfp_base2006 ratio (geomean of individual FP
> >> ratios).
>
> Clearly, 4.7% is significant. Grigory, thanks for the measurements!
>
> >> Here is the full set of changes in cp
On Wed, Feb 21, 2007 at 08:49:38AM -0800, Mark Mitchell wrote:
> I don't know how to evaluate Danny B's claims that these things are
> rare. We don't have nearly as a big a customer base as Red Hat or SuSE,
> and our customer base compiles a different class of applications on
> different hardware,
Hi,
I was trying some inline assembly with gcc.
Running the assembly program on 64 bit system ( with 64bit gcc
version) gives errors of the form
/tmp/cc28kO9v.s: Assembler messages:
/tmp/cc28kO9v.s:57: Error: suffix or operands invalid for `push'
But the same thing on 32bit runs perfectly fin
On 2/22/07, Alok kataria <[EMAIL PROTECTED]> wrote:
Hi,
I was trying some inline assembly with gcc.
Running the assembly program on 64 bit system ( with 64bit gcc
version) gives errors of the form
/tmp/cc28kO9v.s: Assembler messages:
/tmp/cc28kO9v.s:57: Error: suffix or operands invalid for `
Mark Mitchell wrote:
Excellent question; I should have asked for that as well. If 4.2 has
gained on 4.1 in other respects, the 4.7% drop might represent a smaller
regression relative to 4.1.
There is the 4.2 (r120817) vs. 4.1.2 release FP performance comparison
numbers. SPECfp_base2006 of gcc
Hi i've been put into a project in which the GDB residing on the host machine
should control the programs running on the target(wic has its (own made)
specific processor); I am very much new into all this and as my first task
: i have been assigned the task for porting the configuration scripts-
Hello all,
I added a small optimization which does the following . It converts
a = a + 1
if ( a > 0 )
to
if ( a > -1)
a is a signed int.
However this is causing 920612-1.c to fail, which is reproduced below
for convenience.
f(j)int j;{return++j>0;}
main(){ if(f((~0U)>>1)) abort(); exit(0); }
T
My question is that, IMO the test is checking overflow behaviour. Is
it right to have such a test ?
Would you care to prepare a patch that moved it under gcc.dg, adding a {
dg-options "-O2 -fno-strict-overflow" } marker (or maybe "-O2
-fno-wrapv")? But your optimization should also be condi
On 2/22/07, Paolo Bonzini <[EMAIL PROTECTED]> wrote:
> My question is that, IMO the test is checking overflow behaviour. Is
> it right to have such a test ?
Would you care to prepare a patch that moved it under gcc.dg, adding a {
dg-options "-O2 -fno-strict-overflow" } marker (or maybe "-O2
-fn
On 2/20/07, Revital1 Eres <[EMAIL PROTECTED]> wrote:
Hello,
We saw that the reassociation pass does not operate on built-in functions,
for example:
vp3 = vec_madd (vp1, vp2, vp3);
In the RTL level the function is expanded to regular insn:
(insn 87 91 88 9 (set (reg/v:V4SF 217 [ vp3 ])
Markus Franke <[EMAIL PROTECTED]> writes:
> ---snip---
> ;;
> ;; calls that return int in r1
> ;;
> (define_insn "call_val_internal_return_r1"
> [(parallel [(set (reg:SI 1)
> (call (match_operand:QI 0 "sym_ref_mem_operand" "")
> (match_operand 1 "" "i")))
Mans <[EMAIL PROTECTED]> writes:
> Hi i've been put into a project in which the GDB residing on the host machine
> should control the programs running on the target(wic has its (own made)
> specific processor); I am very much new into all this and as my first task
> : i have been assigned the ta
Markus Franke <[EMAIL PROTECTED]> writes:
> thank you for your answer. Having changed the code in the way you
> suggested I get still the same warning message.
> Any further suggestions?
Oh, yeah, you probably want to say call:SI too.
Anyhow, the idea should be pretty obvious.
Ian
Markus Franke <[EMAIL PROTECTED]> writes:
> thank you for your answer. Having changed the code in the way you
> suggested I get still the same warning message.
> Any further suggestions?
Oh, yeah, you probably want to say call:SI too.
Anyhow, the idea should be pretty obvious.
Ian
Hello,
thank you for your answer. Having changed the code in the way you
suggested I get still the same warning message.
Any further suggestions?
Regards,
Markus
Ian Lance Taylor wrote:
> Markus Franke <[EMAIL PROTECTED]> writes:
>
>
>>---snip---
>>;;
>>;; calls that return int in r1
>>;;
>>(d
Richard Guenther wrote:
On 2/21/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
To be honest, my instinct for the FSF is to take the 4% hit and get rid
of this nasty class of bugs. Users measure compiler quality by more
than just floating-point benchmarks; FP code is a relatively small
(albeit
Ian Lance Taylor wrote:
> Oh, yeah, you probably want to say call:SI too.
Yes I can do this and the warning message disappears. But now I get an
internal error message about a non matching rtl expression when
compiling a test program. Without "call:SI" I get warnings during
compilation but the com
Markus Franke <[EMAIL PROTECTED]> writes:
> Ian Lance Taylor wrote:
> > Oh, yeah, you probably want to say call:SI too.
>
> Yes I can do this and the warning message disappears. But now I get an
> internal error message about a non matching rtl expression when
> compiling a test program. Without
Grigory Zagorodnev wrote:
> Mark Mitchell wrote:
>> Excellent question; I should have asked for that as well. If 4.2 has
>> gained on 4.1 in other respects, the 4.7% drop might represent a smaller
>> regression relative to 4.1.
>>
> There is the 4.2 (r120817) vs. 4.1.2 release FP performance compa
Ian Lance Taylor wrote:
> Presumably the insn which doesn't match uses call with some mode other
> than SI. What mode does it use? What generated that insn with some
> other mode?
Well, the internal compiler error message which is thrown looks like this:
---snip---
Processing file 2120-2.c
> Grigory Zagorodnev wrote:
> > Mark Mitchell wrote:
> >> Excellent question; I should have asked for that as well. If 4.2 has
> >> gained on 4.1 in other respects, the 4.7% drop might represent a smaller
> >> regression relative to 4.1.
> >>
> > There is the 4.2 (r120817) vs. 4.1.2 release FP per
Jan Hubicka wrote:
Grigory Zagorodnev wrote:
Mark Mitchell wrote:
Excellent question; I should have asked for that as well. If 4.2 has
gained on 4.1 in other respects, the 4.7% drop might represent a smaller
regression relative to 4.1.
There is the 4.2 (r120817) vs. 4.1
Vladimir Makarov wrote:
> I remember nocona tunning gave 30% improvement SPECFp2000 for Intel
> nocona in 64 bit mode in comparison with the default x86_64 gcc tuning
> (for k8). So such big improvement is definetly mostly from new
> -mtune=generic.
Well, then, lets get numbers for other targets
Mark Mitchell wrote:
Vladimir Makarov wrote:
I remember nocona tunning gave 30% improvement SPECFp2000 for Intel
nocona in 64 bit mode in comparison with the default x86_64 gcc tuning
(for k8). So such big improvement is definetly mostly from new
-mtune=generic.
Well, then, lets get
CodeSourcer's VxWorks toolchains support the following extension to
__attribute__((constructor)):
void f __attribute__((constructor (N)));
The number provided is a constructor priority. These are treated
exactly like the arguments to the C++ init_priority attribute, which
allows control over
>
>
> CodeSourcer's VxWorks toolchains support the following extension to
> __attribute__((constructor)):
>
> void f __attribute__((constructor (N)));
>
> I plan to merge this functionality to the GCC mainline. Does anyone
> object to this feature, in principle?
I think this is a great exte
Why do we use 256 instead of BIGGEST ALIGNMENT in ix86_data_alignment?
This is causing all sorts of build problems for djgpp, as I'm getting
lots of warnings about too-big alignments, and with -Werror...
Index: i386.c
===
--- i386.c
>
> Why do we use 256 instead of BIGGEST ALIGNMENT in ix86_data_alignment?
> This is causing all sorts of build problems for djgpp, as I'm getting
> lots of warnings about too-big alignments, and with -Werror...
It is to improve performance of string functions on larger chunks of
data. x86-64 sp
> It is to improve performance of string functions on larger chunks of
> data. x86-64 specify this, for x86 it is optional. I don't think we
> should end up warning here - it is done only for static variables where
> the alignment can be higher than what BIGGEST_ALIGNMENT promise.
Higher than B
DJ Delorie <[EMAIL PROTECTED]> writes:
> > It is to improve performance of string functions on larger chunks of
> > data. x86-64 specify this, for x86 it is optional. I don't think we
> > should end up warning here - it is done only for static variables where
> > the alignment can be higher than
> Yes, BIGGEST_ALIGNMENT is supposed to be the biggest alignment the
> compiler will ever use.
Will ever use, or can ever use? Based on the code, it looks like "can
ever use" - i.e. it's an edict to the compiler to not exceed that
value, thus varasm warns when you exceed it.
> So if ix86_data_a
DJ Delorie <[EMAIL PROTECTED]> writes:
> > Yes, BIGGEST_ALIGNMENT is supposed to be the biggest alignment the
> > compiler will ever use.
>
> Will ever use, or can ever use? Based on the code, it looks like "can
> ever use" - i.e. it's an edict to the compiler to not exceed that
> value, thus va
On Feb 22, 2007, at 5:20 PM, Ian Lance Taylor wrote:
So if ix86_data_alignment wants to return 256 for some variable,
then it seems to me that BIGGEST_ALIGNMENT should be 256.
What if the object format doesn't allow recording alignments that
high? For example, DJGPP's coff format can only reco
> For ELF, this would be 256, good. For pecoff, that would be smaller.
Actually, I think pecoff supports larger alignments. DJGPP is plain
COFF (similar to i386-coff).
Hi all,
I am adding floating point support to GCC 4.1.1 for a private target.
My machine can issue
(1) Two instructions, [one integer insns (16 bit) + one floating point
insn (16 bit) ]or
(2) one 32 bit integer insn.
For case (1) , Since both instructions are executed parallely, there
is no dep
36 matches
Mail list logo
