Yes, I would be highly interested. I think Interix should
get more attention in general, esp. since its performance
seems to be _much_ better than Cygwin.
Regards
Harri
Bernd Schmidt wrote:
Mark Shinwell wrote:
Do you think it should be the case that, at the point below, _any_ reload
with reg_rtx corresponding to a hard register should have the relevant
bit set in reload_spill_index?
I think so. I'm attaching a patch below. It appears to have no effect
on a
On Jul 5, 2007, Richard Sandiford <[EMAIL PROTECTED]> wrote:
> Ian Lance Taylor <[EMAIL PROTECTED]> writes:
>> I think the best option is for somebody to go through the uses of
>> no_new_pseudos and fix them. Incomplete transitions are bad.
> I admit I'm still not sure on this point, and seein
Hello
On i686-pc-mingw32 I can build a libbid-enabled libgcc by adding
--enable-decimal-float=bid to configure and
setting ENABLE_DFP=1 in environment when running make bootstrap.
make -k check-gcc RUNSTESTFLAGS='dfp.exp" sets
check_effective_target_dfprt as true abd gives:
===
On Fri, 6 Jul 2007, Roman Zippel wrote:
> Hi,
>
> On Thu, 5 Jul 2007, Richard Guenther wrote:
>
> > For me both canonicalizations generate
> >
> > movl8(%ecx,%edx,4), %eax
> > addl4(%ecx,%edx,4), %eax
>
> Hmm, there seem to be other problems in this area as well.
> Eith
>
> > Or
> > am I missing a more fundamental reason for the limited
> range of targets
> > supporting DFP?
>
>
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1176.pdf
Thanks.
Danny
Danny Smith wrote:
> Or
> am I missing a more fundamental reason for the limited range of targets
> supporting DFP?
Enabling it in gcc would just enable the compiler parts, but the decimal
float C extension proposed standard includes a lot more than that,
there's a whole checklist of stuff requir
> Alexandre Oliva writes:
Alexandre> Collapsing no_new_pseudos with anything else that doesn't carry the
Alexandre> semantics it currently expresses is a transformation that loses
Alexandre> information. Pretty please don't do this just because the current
Alexandre> code doesn't care about t
I am seeing an odd behavior and was wondering if it was a bug. In
X86_64, Gcc is sign extending a bit shift operation when assigned to an
unsigned long. Specifically:
#include
int main(){
unsigned long val;
val = (1 << 31);
printf("Val = %lx\n", val);
return 0;
}
This resu
David Edelsohn <[EMAIL PROTECTED]> writes:
> So far all I read is complaints from you and Richard, but no
> offers to implement your more extensive proposal in the next few weeks.
> You simply are making demands that volunteers implement more extensive
> transformation. This is a giant Bike
On Fri, Jul 06, 2007 at 06:06:43AM -0600, Wachdorf, Daniel R wrote:
> val = (1 << 31);
Try 1UL << 31 instead.
> Should the result be 0x8000? I understand that the bit shift is a
> 32 bit operation, but shouldn't the compiler then up convert that to a
> 64 bit unsigned long?
No, a signed
Mark Shinwell wrote:
Bernd Schmidt wrote:
Mark Shinwell wrote:
Do you think it should be the case that, at the point below, _any_
reload
with reg_rtx corresponding to a hard register should have the relevant
bit set in reload_spill_index?
I think so. I'm attaching a patch below. It appears
On Fri, Jul 06, 2007 at 06:06:43AM -0600, Wachdorf, Daniel R wrote:
> I am seeing an odd behavior and was wondering if it was a bug. In
> X86_64, Gcc is sign extending a bit shift operation when assigned to an
> unsigned long. Specifically:
>
> #include
>
> int main(){
>
> unsigned long v
> Passes ought to distinguish GIMPLE values from GIMPLE invariants
> according to context.
Looks like someone already ran into the problem. In tree-ssa-ccp.c:
/* The regular is_gimple_min_invariant does a shallow test of the object.
It assumes that full gimplification has happened, or will ha
Starting 2007-07-02 my daily ppc64 tester has failed bootstrap with a SEGV in
libgfortran:
libtool: compile: /home/dnovillo/perf/sbox/gcc/local.ppc64/bld/./gcc/gfortran
-B/home/dnovillo/perf/sbox/gcc/local.ppc64/bld/./gcc/
-B/home/dnovillo/perf/sbox/gcc/local.ppc64/inst/powerpc64-unknown-linu
"Zack Weinberg" <[EMAIL PROTECTED]> writes:
> On 05 Jul 2007 18:22:50 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> > "Zack Weinberg" <[EMAIL PROTECTED]> writes:
> >
> > [std_expand_builtin_va_start]
> >
> > > rtx va_r = expand_normal (valist);
> > > emit_move_insn (va_r, nextarg);
> >
Starting 2007-07-02 my daily ppc64 tester has failed bootstrap with
a SEGV in libgfortran:
libtool: compile: /home/dnovillo/perf/sbox/gcc/local.ppc64/bld/./
gcc/gfortran -B/home/dnovillo/perf/sbox/gcc/local.ppc64/bld/./gcc/ -
B/home/dnovillo/perf/sbox/gcc/local.ppc64/inst/powerpc64-unknown-
On 7/5/07, Paolo Bonzini <[EMAIL PROTECTED]> wrote:
> libstdc++'s bitmap_allocator.cc, because for some reason reload wants
> a MODE_PARTIAL_INT mode with 64 bits. There is no such mode, so
> get_smallest_mode_for_size aborts. I am attaching the .lreg and .greg
> dumps to this message (compress
On 05 Jul 2007 18:22:50 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
"Zack Weinberg" <[EMAIL PROTECTED]> writes:
[std_expand_builtin_va_start]
> rtx va_r = expand_normal (valist);
> emit_move_insn (va_r, nextarg);
>
> but this is a part of the compiler I am not at all familiar with...
ll -version -fno-repack-arrays
-fno-underscoring -fallow-leading-underscore -fPIC -I .
-fintrinsic-modules-path finclude -o selected_int_kind.s
GNU F95 version 4.3.0 20070706 (experimental) (powerpc64-unknown-linux-gnu)
compiled by GNU C version 4.3.0 20070706 (experimental), GMP
version 4.1.4, MP
+++ Ian Lance Taylor [05/07/07 17:48 -0700]:
> "Gregory B. Prokopski" <[EMAIL PROTECTED]> writes:
>
> > One of the operations I need to perform is to reorder basic blocks in a
> > particular manner. This works fine for example on i386 and other that have
> > HAS_LONG_COND_BRANCH, HAS_LONG_UNCOND_
"Gregory B. Prokopski" <[EMAIL PROTECTED]> writes:
> > But you seem to be within a single function, so I don't understand why
> > you have any trouble at all. Why doesn't the shorten_branches pass
> > work for you?
>
> I reorder the basic blocks in passes.c, right after compute_alignmnets ().
>
On Fri, 2007-07-06 at 20:50 +1200, Danny Smith wrote:
> On i686-pc-mingw32 I can build a libbid-enabled libgcc by adding
> --enable-decimal-float=bid to configure and
> setting ENABLE_DFP=1 in environment when running make bootstrap.
> Can somebody please advise of further test harness(es) for l
+++ Ian Lance Taylor [06/07/07 09:16 -0700]:
> shorten_branches should work correctly--you shouldn't need to do
> anything special. My only guess is that there is something wrong with
> the way you are reordering the blocks. For example, perhaps you are
> simply reordering the CFG without reorder
On Fri, Jul 06, 2007 at 12:07:43PM -0400, Diego Novillo wrote:
> On 7/6/07 11:48 AM, FX Coudert wrote:
>
> > Depends what is your current version,
>
> $ rpm -q gmp
> gmp-4.1.4-12
>
>
> > I guess. Can you get us a backtrace?
>
> Well, it seems to be a mis-compilation of f951. The stage3 f951 b
On Fri, Jul 06, 2007 at 10:08:44AM -0700, Steve Kargl wrote:
>
> Dorit has isolated the problem to the ISO C Binding import. See
> for example
>
> http://gcc.gnu.org/ml/gcc/2007-07/msg00133.html
>
> AFAIK, ppc64 is the only target that is failing. I'll send you
> my public key later today (I
On 7/6/07 1:14 PM, Steve Kargl wrote:
> perf/sbox/gcc/local.ppc64/src/libgfortran/intrinsics/selected_int_kind.f90
>
> This is file is autogenerated. If it's mangled you'll get the
> failure.
Sure, but I've lost the file. I'm trying to bootstrap from scratch with
the latest version of GMP/MPFR
On Jul 6, 2007, David Edelsohn <[EMAIL PROTECTED]> wrote:
>> Alexandre Oliva writes:
Alexandre> Collapsing no_new_pseudos with anything else that doesn't carry the
Alexandre> semantics it currently expresses is a transformation that loses
Alexandre> information. Pretty please don't do this j
"Gregory B. Prokopski" <[EMAIL PROTECTED]> writes:
> +++ Ian Lance Taylor [06/07/07 09:16 -0700]:
> > shorten_branches should work correctly--you shouldn't need to do
> > anything special. My only guess is that there is something wrong with
> > the way you are reordering the blocks. For example,
On 7/3/07, Bernardo Innocenti <[EMAIL PROTECTED]> wrote:
Ollie Wild wrote:
> As an aside to the ongoing git repository discussion, I'm curious if
> anyone has experimented with committing changes to the GCC repository
> via git-svn's dcommit command. I'm curious to know if it plays nicely
> with
Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> Richard Sandiford <[EMAIL PROTECTED]> writes:
>
>> That's why it seems so odd to me to want to get rid of the port uses
>> and not replace it with something directly equivalent. I just don't
>> see how it qualifies as a clean-up. I think tying the po
On 7/6/07 1:14 PM, Steve Kargl wrote:
> One other thing. Can you post the contents of
>
> perf/sbox/gcc/local.ppc64/src/libgfortran/intrinsics/selected_int_kind.f90
>
> This is file is autogenerated. If it's mangled you'll get the
> failure.
Attached. The failure still exists with the latest
Diego Novillo wrote:
On 7/6/07 1:14 PM, Steve Kargl wrote:
One other thing. Can you post the contents of
perf/sbox/gcc/local.ppc64/src/libgfortran/intrinsics/selected_int_kind.f90
This is file is autogenerated. If it's mangled you'll get the
failure.
Attached. The failure still exists wit
On 7/6/07 3:31 PM, Brooks Moses wrote:
> Hmm. Looking at that, I suspect that the relevant file is actually the
> "selected_int_kind.inc" one that it includes. Can you post that as well?
Attached.
integer, parameter :: c = 5
type (int_info), parameter :: int_infos(c) = (/ &
int_info (1,
Ollie Wild wrote:
It should. git-svn is bidirectional.
My main concern is with whether or not git-svn preserves proper
formatting of change descriptions. For instance, all the imported
changes have the tabs removed.
I still see the tabs in my git tree, but git-log prepends four
spaces to a
I have a question relating to variadic builtins and floating point
arguments. I'm trying to implement "isnormal" like so:
http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01292.html
Basically, I change __builtin_isnormal(x) ->
isgreaterequal(fabs(x),FP_MIN) & islessequal(fabs(x),FP_MAX)
(where FP_M
On Fri, 6 Jul 2007, Kaveh R. GHAZI wrote:
> So how do we detect or work around this promotion issue and discriminate
> between the case where a float is promoted because of the variadic
> prototype vs a user supplied cast or other user code?
I think we may need to tag these builtins in some way t
Snapshot gcc-4.3-20070706 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20070706/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.3 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
38 matches
Mail list logo
