Dear list,
# gcc -v
Using built-in specs.
Target: alphaev56-dec-osf5.1b
Configured with:
../configure
--enable-threads=posix
--enable-languages=c,c++,treelang
--prefix=/usr/local
--enable-version-specific-runtime-libs
--enable-shared
--enable-nls
--enable-interpreter
Thread model: posix
g
On Mon, Oct 03, 2005 at 09:32:53PM +0100, Ivan Novick wrote:
>I would subscribe to the MinGW list as this is a key technology to
>making cygwin/windows cross compiling work
>
>http://www.mingw.org/
If you're using Cygwin, then the *cygwin* list (see
http://cygwin.com/lists.html) is where you'd d
Snapshot gcc-3.4-20051004 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/3.4-20051004/
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-20051004
You'll
On 10/4/05, Janis Johnson <[EMAIL PROTECTED]> wrote:
> I forgot to mention that I'll fix this.
Great! :)
--
Cheers,
/ChJ
Peter Lupton NCH Swift Sound wrote:
> But I have been going through other reports from the 'bug book' which I ask
> my programmers to log. Another case which explicit bools would solve would
> be (in Win32)...
>
> HANDLE hFile = CreateFile(...);
> if (!hFile) return;
>
> If t
On Tue, Oct 04, 2005 at 01:16:58PM -0700, Janis Johnson wrote:
> On Tue, Oct 04, 2005 at 12:43:35PM +0200, FX Coudert wrote:
> > >is there anything I can provide you with to have a better guess? I'm
> > >definately willing to debug if you direct me...
> >
> > Unfortunately, I think we need a dejag
On Tue, Oct 04, 2005 at 12:43:35PM +0200, FX Coudert wrote:
> >is there anything I can provide you with to have a better guess? I'm
> >definately willing to debug if you direct me...
>
> Unfortunately, I think we need a dejagnu expert here, I have no idea how
> to debug these things...
>
> If no
- Original Message -
Sent: Monday, October 03, 2005 3:02 AM
Subject: Re: problems with writing a new pass
In file included from /usr/include/stdio.h:831,
from ../../gcc/gcc/tsystem.h:90,
from ../../gcc/gcc/crtstuff.c:62:
/usr/include/bits/stdio.h: In fun
On Tue, Oct 04, 2005 at 10:07:31AM -0700, Dale Johannesen wrote:
> >http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23809
The patch in the PR looks reasonable.
r~
On Oct 1, 2005, at 8:41 PM, Andrew Pinski wrote:
On Oct 1, 2005, at 11:10 PM, Dale Johannesen wrote:
But better fix would be not call split_nonconstant_init_1 for
local decls and have the front-end produce a CONSTRUCTOR which is
just like what the C front-end produces.
I'll try it.
This pat
On Oct 3, 2005, at 3:49 PM, Andrew Pinski wrote:
On Oct 3, 2005, at 6:41 PM, Evan Cheng wrote:
But according to the manual -msse3 does not turn on generation of
SSE3 instructions:
The manual is semi-confusing I had forgot about that.
There is a bug about the issue recorded as PR 23809:
http://
On Tuesday 04 October 2005 15:39, Peter Lupton NCH Swift Sound wrote:
> Richard: based on your argument all type checking is for nought :).
>
> But I have been going through other reports from the 'bug book' which I ask
> my programmers to log. Another case which explicit bools would solve would
>
Richard: based on your argument all type checking is for nought :).
But I have been going through other reports from the 'bug book' which I ask
my programmers to log. Another case which explicit bools would solve would
be (in Win32)...
HANDLE hFile = CreateFile(...);
if (!hF
On Tue, Oct 04, 2005 at 10:07:07AM +0200, Uros Bizjak wrote:
> * config/i386/i386.h (TARGET_FISTTP): Enable also for
> TARGET_SSE3 and only for TARGET_80387.
> * config/i386/i386.md (fix_trunc_fisttp_i387_1,
> (fix_trunc_i387_fisttp, fix_trunc_i387_fisttp_with_temp):
>
On Tue, Oct 04, 2005 at 01:00:53PM +0100, Joern RENNECKE wrote:
> I could make it there, but I'd have to leave shortly after 11 p.m.,
> since the last
> train from paddington to bristol goes at half past eleven.
That would be fine.
I've spoken to the organisers and have had you added to the lis
All of the usual suspects (Berlin, Bosscher, Henderson, Hubicka,
Mitchell, Novillo, etc.) have bugs with our names on them. I think we
can knock quite a few these down relatively easily.
I've fixed (or am about to commit patches for) the 4.1 regressions
assigned to me.
Diego, if you have any
On 10/4/05, Peter Lupton NCH Swift Sound <[EMAIL PROTECTED]> wrote:
> Maybe I gave a too simple example on my first post. Another example common
> error which would be prevented by blocking implicit bool conversion might be:
>
> if (strcmp(szMyName, "Peter")) printf("Hello Peter");
>
> This ba
Joe Buck wrote at http://gcc.gnu.org/ml/gcc/2005-10/msg00075.html :
> My suggestion: anyone who is listed in the MAINTAINERS file, and who can
> make it to the dinner, could volunteer to accept the award. If more than
> one want to go, and the dinner hosts are willing, you can all go up on
> sta
Maybe I gave a too simple example on my first post. Another example common
error which would be prevented by blocking implicit bool conversion might be:
if (strcmp(szMyName, "Peter")) printf("Hello Peter");
This bad error currently just slips through. If we gave an option to only
accept ex
I have two separate questions to ask:
1. what is the status on 21766 (a 4.1 regression)? bootstrap has been
broken on Windows (cygwin and mingw) for more that 4 months now, is it
expected to be fixed before branch?
2. what's the status for fortran wrt the quality push? can we still
check
is there anything I can provide you with to have a better guess? I'm
definately willing to debug if you direct me...
Unfortunately, I think we need a dejagnu expert here, I have no idea how
to debug these things...
If nobody can provide help in the next few days, please file a bug-report.
Th
On 10/4/05, FX Coudert <[EMAIL PROTECTED]> wrote:
> This testcase should only be run if there is a 128-bit integer kind
> available. This looks like it's not the case here, but then why is
> check_effective_target_fortran_large_int returning true?
>
> I can't really understand that. What are you tc
This testcase should only be run if there is a 128-bit integer kind
available. This looks like it's not the case here, but then why is
check_effective_target_fortran_large_int returning true?
I can't really understand that. What are you tcl/expect/dejagnu versions?
i686-pc-linux-gnu
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.0.2/configure --program-suffix=-4.0.2
--enable-languages=c,c++
Thread model: posix
gcc version 4.0.2
Red Hat Linux release 9 (Shrike)
Linux gkremos.mikroskosmos.com 2.4.20-20.9 #1 Mon Aug 18 11:45:58
This one also works for -mno-80387 and simplifies insn pattern constraints a
bit:
2005-10-05 Uros Bizjak <[EMAIL PROTECTED]>
* config/i386/i386.h (TARGET_FISTTP): Enable also for
TARGET_SSE3 and only for TARGET_80387.
* config/i386/i386.md (fix_trunc_fisttp_i387_1,
In http://gcc.gnu.org/ml/gcc-testresults/2005-10/msg00130.html, and a
few previous postings of testsuite results on sparc/sparc64 linux, I
get this gfortran failure:
Executing on host:
/usr/local/src/trunk/objdir/gcc/testsuite/../gfortran
-B/usr/local/src/trunk/objdir/gcc/testsuite/../
/usr/local
Quoting Uros Bizjak <[EMAIL PROTECTED]>:
> Following simple patch should implement your suggested approach:
>
> -march=prescott enables fisttp
> -msse3enables fisttp
> -march=prescott -mno-sse3 enables fisttp
>
> Otherwise fisttp is disabled.
This one also works
Quoting Evan Cheng <[EMAIL PROTECTED]>:
> Let me know what you think. I kind of agree with your argument. But
> for practical reasons I thinkg -msse3 should enable fisttp. Certainly
> here in Apple, a few folks have been surprised by this.
Following simple patch should implement your sugges
28 matches
Mail list logo
