On Tue, 2005-08-23 at 22:10 -0500, Peter Bergner wrote:
> On Tue, 2005-08-23 at 21:26 +0200, Bernd Schmidt wrote:
> > As Jim points out, we may have to do that for IA64 anyway, so we could
> > consider doing it on all targets. Dan is correct that this can
> > introduce new code that won't be eli
On Tue, 2005-08-23 at 21:26 +0200, Bernd Schmidt wrote:
> As Jim points out, we may have to do that for IA64 anyway, so we could
> consider doing it on all targets. Dan is correct that this can
> introduce new code that won't be eliminated. One question is how often
> this is going to occur in
Snapshot gcc-3.4-20050823 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/3.4-20050823/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 3.4 CVS branch
with the following options: -rgcc-ss-3_4-20050823
You'll
On Tue, Aug 23, 2005 at 04:32:42PM -0400, Paul Koning wrote:
> 1. Why do _builtin_ia32_paddusb and similar functions take signed
>vector arguments, when the hardware primitive is defined to operate
>on unsigned vectors?
Because the interface you're actually supposed to be using
is _mm_adds
Benjamin Kosnik <[EMAIL PROTECTED]> writes:
> > Could we modify the CVS commit filters to *require* the right
> > versions? If it detects a commit with the wrong version (at least,
> > assuming the old rev had the right version), it can just reject it.
>
> Dunno if this is possible, but this wou
Steven Bosscher wrote:
On Monday 22 August 2005 14:46, Leehod Baruch wrote:
Hello,
I would like to know if someone knows a suitable branch for the sign
extension optimization pass.
Why not just maintain it in a local tree and post refined
versions every now and then, until stage 1 for GCC 4
DJ Delorie wrote:
This certainly wasn't my intention, please change it to 79L.
How's this? It passes both m32c and x86-64.
2005-08-23 DJ Delorie <[EMAIL PROTECTED]>
* gcc.c-torture/execute/stdarg-2.c (main): Make sure long
constants have the L suffix.
OK.
--
Mark Mitche
Two things I'm wondering about:
1. Why do _builtin_ia32_paddusb and similar functions take signed
vector arguments, when the hardware primitive is defined to operate
on unsigned vectors?
2. Why are there no sse equivalents of those functions, ones that
operate on 128 bit values (i.e., pa
> "KC" == Kelley Cook <[EMAIL PROTECTED]> writes:
KC> Unfortunately, we have automake 1.9.3, 1.9.4 and 1.9.5 floating
KC> throughout the tree. I propose standardizing the entire tree on 1.9.6,
KC> as it is the current release; moreover the 1.9 branch has only had a
KC> few minor patches since
Dan,
> Is there a performance difference between the movl + movl and
> pushl code sequences?
Not in this example, but movl is faster in some circumstances than pushl. A
sequence of pushl has an implicit dependency chain on %esp, as it changes after
each pushl, whereas a sequence of movl cou
On Tue, Aug 23, 2005 at 11:40:16AM -0700, Dan Nicolaescu wrote:
> Is there a performance difference between the movl + movl and pushl
> code sequences?
In this case, no.
> If not maybe then gcc should generate pushl for -O2
> too because it is smaller code.
It's not quite as simple as you make o
Paolo Bonzini <[EMAIL PROTECTED]> wrote:
> While researching who is really using flow's computed LOG_LINKS, I
> found
> a define_split in the rs6000 back-end that uses them through
> find_single_use. It turns out the only users are combine, this split,
> and a function in regmove.
See also:
ht
Steven Bosscher wrote:
On Tuesday 23 August 2005 17:06, Bernd Schmidt wrote:
The idea is to put the initialization insns only on the paths where the
register will be uninitialized.
int foo (int n)
{
int a;
while (--n)
a = n;
return a;
}
Not knowing n, how can you be sure whether
> Could we modify the CVS commit filters to *require* the right
> versions? If it detects a commit with the wrong version (at least,
> assuming the old rev had the right version), it can just reject it.
Dunno if this is possible, but this would be great. It would be nice if
there was a way to se
For this code (from PR23525):
extern int waiting_for_initial_map;
extern int cp_pipe[2];
extern int pc_pipe[2];
extern int close (int __fd);
void
first_map_occurred(void)
{
close(cp_pipe[0]);
close(pc_pipe[1]);
waiting_for_initial_map = 0;
}
gcc -march=i686 -O2 generates:
> Thanks Tom for pointing this out. We have to all keep these
> autotools versions synced: it bugs everybody to have extraneous
> differences in trees due to version mis-match.
Could we modify the CVS commit filters to *require* the right
versions? If it detects a commit with the wrong version (
> This certainly wasn't my intention, please change it to 79L.
How's this? It passes both m32c and x86-64.
2005-08-23 DJ Delorie <[EMAIL PROTECTED]>
* gcc.c-torture/execute/stdarg-2.c (main): Make sure long
constants have the L suffix.
Index: gcc.c-torture/execute/stdarg-2.c
Thanks Tom for pointing this out. We have to all keep these autotools
versions synced: it bugs everybody to have extraneous differences in
trees due to version mis-match.
>Unfortunately, we have automake 1.9.3, 1.9.4 and 1.9.5 floating
>throughout the tree.
How did this happen?
>I propose sta
--- Tom Tromey <[EMAIL PROTECTED]> wrote:
> > "KC" == Kelley Cook <[EMAIL PROTECTED]> writes:
>
> KC> 2005-08-19 Kelley Cook <[EMAIL PROTECTED]>
> KC> * Makefile.am (ACLOCAL_AMFLAGS): Also include "..".
> KC> * acinclude.m4: Delete. Extract CHECK_FOR_BROKEN_MINGW_LD to
> ...
> KC> * m
On Tue, 2005-08-23 at 07:44, Bernd Schmidt wrote:
> Jim Wilson once suggested we should just emit insns to make sure every
> register is initialized and be done with it - problem solved. I had
> started to work on that, if people think it's a good idea I can dig that
> stuff out again.
I'd lik
On Aug 23, 2005, at 9:53 AM, Richard Henderson wrote:
On Tue, Aug 23, 2005 at 09:28:50AM -0600, Roger Sayle wrote:
Good catch. This is indeed a -ffast-math (or more precisely a
flag_unsafe_math_optimizations) transformation. I'd prefer to
keep these transformations with -ffast-math, as Jan d
>
> Hi Guys,
>
> There is a problem with unit-at-a-time compilation and DWARF debug
> info generation. Consider this small test case which has been
> derived from GDB's observer.c source file:
There was even more issues with uninitialized variables a month ago.
This was all caused by Mark
Hi Guys,
There is a problem with unit-at-a-time compilation and DWARF debug
info generation. Consider this small test case which has been
derived from GDB's observer.c source file:
int observer_test_first_observer = 0;
int observer_test_second_observer = 0;
int observer_test_th
On Tue, Aug 23, 2005 at 09:28:50AM -0600, Roger Sayle wrote:
> Good catch. This is indeed a -ffast-math (or more precisely a
> flag_unsafe_math_optimizations) transformation. I'd prefer to
> keep these transformations with -ffast-math, as Jan described them
> as significantly helping SPEC's mesa
--- Florian Weimer <[EMAIL PROTECTED]> wrote:
> * Gerald Pfeifer:
>
> > On Sun, 31 Jul 2005, Daniel Berlin wrote:
> >> For code.
> >> I have never seen such claims made for documentation, since it's much
> >> easier to remove and deal with infringing docs than code.
> >
> > I have seen such stat
Leehod Baruch <[EMAIL PROTECTED]> writes:
> Is it true that in a SET, a search for a _use_ of a register
> in the LHS should be done only inside a memory address?
See refers_to_regno_p for an example of a function which looks for
all uses of a register.
Ian
On Mon, 22 Aug 2005, Dale Johannesen wrote:
> There is some clever code in convert_to_real that converts
>
> double d;
> (float)floor(d)
>
> to
>
> floorf((float)d)
> ...
>
> Comments? Should I preserve the buggy behavior with -ffast-math?
Good catch. This is indeed a -ffast-math (or more precis
On Tue, 2005-08-23 at 17:06 +0200, Bernd Schmidt wrote:
> Daniel Berlin wrote:
>
> > If you make them all defined, then it's going to be live where it wasn't
> > before, even though it's not really *used* over those paths.
>
> The idea is to put the initialization insns only on the paths where th
On Tuesday 23 August 2005 17:06, Bernd Schmidt wrote:
> The idea is to put the initialization insns only on the paths where the
> register will be uninitialized.
int foo (int n)
{
int a;
while (--n)
a = n;
return a;
}
Not knowing n, how can you be sure whether "a" is uninitialized for
Daniel Berlin wrote:
If you make them all defined, then it's going to be live where it wasn't
before, even though it's not really *used* over those paths.
The idea is to put the initialization insns only on the paths where the
register will be uninitialized.
Bernd
On Tue, 2005-08-23 at 16:44 +0200, Bernd Schmidt wrote:
> Andreas Krebbel wrote:
>
> > Ok I understand that implementing the special lifeness analyzers in global
> > alloc
> > using the df.c framework would ease reusing it somewhere else. But my
> > question
> > was more basic.
> > So do you agr
Andreas Krebbel wrote:
Ok I understand that implementing the special lifeness analyzers in global alloc
using the df.c framework would ease reusing it somewhere else. But my question
was more basic.
So do you agree that using one lifeness analyzer for checking what
an optimizer step has done bas
Hello,
sorry for the late answer.
> Vlad promised to update it to use df.c once it wasn't "1% slower", which
> would make it easily reusable elsewhere, but never did.
> Of course, you could reuse it without that, but then someone will
> invariably come along and mess with it.
Ok I understand tha
David Edelsohn wrote:
Paolo Bonzini writes:
Paolo> I'm testing a patch that does this replacement, and I can post it
Paolo> tomorrow morning. It has triggered only a dozen times so far (half in
Paolo> libgcc, half in the compiler), but it may be worth keeping it.
It w
* Matteo Emanuele:
> Is it possible to find the register save area and the
> overflowing arguments within the called function
> without using %ebp (that means with
> -fomit-frame-pointer set) and knowing nothing of the
> caller?
You mean, if the caller called the function as it were a non-variad
Andreas Schwab wrote:
> Try -Wextra.
Ah thanks! I have already lost time several times due to this
almost invisible mistake and I didn't know -Wextra would catch it.
However, it seems to only work for the C compiler, not for C++.
(Using GCC 3.4.4)
(Oops, sorry Andreas, I actually meant to only
Hello,
can anyone tell me how to use option -m64 in
g++ (GCC) 3.4.3 20050227 (Red Hat 3.4.3-22.1)?
when I input the command line:
>g++ -m64 -o test test.cc
error message was output:
/tmp/ccyjpGIh.o(.text+0x900): In function `main':
: relocation truncated to fit: R_X86_64_32
.
.
.
best regards
Hi to everyone,
I cannot figure out how variadic function are
practically implemented. In the called (variadic)
function after few 'push's %rsp is suddenly
decremented by N bytes: the red area starts 128 bytes
below the NEW rsp or %rsp-N above?
Is it possible to find the register save area and th
Leehod Baruch wrote:
Hello,
Is it true that in a SET, a search for a _use_ of a register
in the LHS should be done only inside a memory address?
Also within the second and third arguments of a ZERO_EXTRACT. And its
first argument may be a MEM, in which case you should look into it.
Look at
Hello,
Is it true that in a SET, a search for a _use_ of a register
in the LHS should be done only inside a memory address?
Like in this SET:
(set (mem:SI (plus:DI (reg:DI 159)
(reg/v/f:DI 150 )))
(subreg/s:SI (reg/v:DI 142 [ j ]) 4)) -1 (nil)
Registers 142, 159 and 150 are
Not that it come as a big surprise, but I successfully compiled
gcc-3.4.4 on darwin 6.8 (as specified by uname -a)
config.guess reports
powerpc-apple-darwin.6.8
gcc -v reports
Configured with ../gcc-3.4.4/configure --program-suffix=-3.4.4
--enable-languages=c,c++,f77,java,objc
Thread model: p
Christophe Jaillet <[EMAIL PROTECTED]> wrote:
> I think that the structure 'struct loop_info' in loop.c could be
> shrinked a bit if all the 'int has_XXX' fields where turned into a
> bitfield just as in 'struct iv_class' or 'struct induction' in the
> same file.
>
> I don't know if it worse it (i
* Gerald Pfeifer:
> On Sun, 31 Jul 2005, Daniel Berlin wrote:
>> For code.
>> I have never seen such claims made for documentation, since it's much
>> easier to remove and deal with infringing docs than code.
>
> I have seen such statements, by RMS himself.
The official position might have change
Ivan Novick <[EMAIL PROTECTED]> writes:
> How come the following code would not be considered a Warning?
Try -Wextra.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D
On Mon, Aug 22, 2005 at 08:38:01PM -0400, DJ Delorie wrote:
>
> This test assumes that integer constants passed as varargs are
> promoted to a type at least as big as "long", which is not valid on 16
> bit hosts. For example:
>
> void
> f1 (int i, ...)
> {
> va_start (gap, i);
> x = va_arg (
45 matches
Mail list logo
