Re: Should -msse3 enable fisttp?
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 suggested approach: -march=prescott enables fisttp -msse3enables fisttp -march=prescott -mno-sse3 enables fisttp Otherwise fisttp is disabled. 2005-10-05 Uros Bizjak <[EMAIL PROTECTED]> * config/i386/i386.h (TARGET_FISTTP): Enable for TARGET_SSE3. Uros.
Re: Should -msse3 enable fisttp?
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 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, (fix_trunc_i387_fisttp, fix_trunc_i387_fisttp_with_temp): Do not depend on TARGET_80387. Uros. fisttp_2.diff Description: Binary data
gcc 4.1 FAIL: gfortran.dg/large_integer_kind_1.f90 on sparc/sparc64 linux...
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/src/trunk/gcc/gcc/testsuite/gfortran.dg/large_integer_kind_1.f90 -O0 -pedantic-errors -L/usr/local/src/trunk/objdir/sparc64-unknown-linux-gnu/./libgfortran/.libs -L/usr/local/src/trunk/objdir/sparc64-unknown-linux-gnu/./libiberty -lm -o ./large_integer_kind_1.exe(timeout = 1200) In file /usr/local/src/trunk/gcc/gcc/testsuite/gfortran.dg/large_integer_kind_1.f90:8 integer(kind=k),intent(in) :: a 1 Error: Kind -1 not supported for type INTEGER at (1) In file /usr/local/src/trunk/gcc/gcc/testsuite/gfortran.dg/large_integer_kind_1.f90:25 use testmod 1 Fatal Error: Can't open module file 'testmod.mod' for reading at (1): No such file or directory compiler exited with status 1 output is: In file /usr/local/src/trunk/gcc/gcc/testsuite/gfortran.dg/large_integer_kind_1.f90:8 integer(kind=k),intent(in) :: a 1 Error: Kind -1 not supported for type INTEGER at (1) In file /usr/local/src/trunk/gcc/gcc/testsuite/gfortran.dg/large_integer_kind_1.f90:25 use testmod 1 Fatal Error: Can't open module file 'testmod.mod' for reading at (1): No such file or directory FAIL: gfortran.dg/large_integer_kind_1.f90 -O0 (test for excess errors) There are, also, more of the same type of error. Now, is this what I should expect? Is it perhaps even addressed by the recently commited patch to libgfortran? If none of the above, may a kernel/glibc/binutils problem lurk here? Would you like me to file this with bugzilla? -- Cheers, /ChJ
Re: Should -msse3 enable fisttp?
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, (fix_trunc_i387_fisttp, fix_trunc_i387_fisttp_with_temp): Do not depend on TARGET_80387. You forgot to attach either patch ;-) Paolo
success: gcc @ RH9.0 Shrike
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 EDT 2003 i686 i686 i386 GNU/Linux glibc-2.3.2-11.9 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 EDT 2003 i686 i686 i386 GNU/Linux glibc-2.3.2-11.9
Re: gcc 4.1 FAIL: gfortran.dg/large_integer_kind_1.f90 on sparc/sparc64 linux...
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?
Re: gcc 4.1 FAIL: gfortran.dg/large_integer_kind_1.f90 on sparc/sparc64 linux...
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 tcl/expect/dejagnu versions? well, looking at the testresult posting, http://gcc.gnu.org/ml/gcc-testresults/2005-10/msg00130.html, you see tcl-8.4.7-2 expect-5.42.1-1 dejagnu-1.4.4-2 and they're from FC3 compiled for sparc (the corona tree, aurora linux's development tree, see http://auroralinux.org) however, there still may very well be issues with these variants of the tools... is there anything I can provide you with to have a better guess? I'm definately willing to debug if you direct me... -- Cheers, /ChJ
Re: gcc 4.1 FAIL: gfortran.dg/large_integer_kind_1.f90 on sparc/sparc64 linux...
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. Thanks for your help, FX
Re: GCC 4.1 Status Report (2005-10-02)
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-in small patches that add support for things g77 supported but gfortran does not yet? Thanks, FX
Re: Wishlish: GCC option for explicit booleans
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 explicit bools then the error would be caught (because strcmp
returns int not bool).
At 10:27 AM 3/10/2005, Nicholas Nethercote wrote:
C++ would be a better language if the boolean type did not implicitly
convert from int. For example, many novice programmers make the
mistake.
if (i = j) dosomething(); // Should be i == j
If conversion to boolean required explicit this would all be solved. It
would mean all the old code with expressions like "while (p) ... "
would need to be changed to "while (p != NULL) ...". But I think the
change would be well justified.
What about a GCC option to turn off implicit conversion to boolean?
[~] more a.cpp
int main(void)
{
int i = 0, j = 0;
if (i = j)
return 0;
else
return 1;
}
[~] g++ -Wall a.cpp
a.cpp: In function `int main()':
a.cpp:4: warning: suggest parentheses around assignment used as truth value
Nick
Peter Lupton
[EMAIL PROTECTED]
NCH Swift Sound
Unit 13, Level 3
28 University Avenue
GPO Box 1169
Canberra ACT 2601
Australia
www.nch.com.au
Re: [URGENT] GCC 4.0 Nomination
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 > stage together, like they do at the Oscars. If more want to go than > can be accomodated, then we have something to work out, but even in that > case the people involved can discuss it among themselves and pick a > representative. 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.
Re: Wishlish: GCC option for explicit booleans
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 bad error currently just slips through. If we gave an option to only
> accept explicit bools then the error would be caught (because strcmp
> returns int not bool).
If you're that lazy programmer you're going to stick (bool) in front of it
to silence the warning.
Duh.
Richard.
Re: GCC 4.1 Status Report (2005-10-02)
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 alias regressions you need help with, lemme know.
Re: [URGENT] GCC 4.0 Nomination
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 list of people attending the dinner. They suggest that you go to the stand of our magazine - Linux User & Developer - during the afternoon and pick up your pass or just turn up at 19:00 for the ceremony. It's a black tie event and apparently that means we have to wear a suit or something (I've got to go and dig one out myself tonight). Jon.
Re: Should -msse3 enable fisttp?
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): > Do not depend on TARGET_80387. Ok. r~
Re: Wishlish: GCC option for explicit booleans
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 (!hFile) return;
If the compiler had forced the writer to make a real comparison, I am sure
the bug would never have made it into release. The problem here is
INVALID_HANDLE_VALUE is -1 not 0.
At 10:10 PM 4/10/2005, Richard Guenther wrote:
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 bad error currently just slips through. If we gave an option to only
> accept explicit bools then the error would be caught (because strcmp
> returns int not bool).
If you're that lazy programmer you're going to stick (bool) in front of it
to silence the warning.
Duh.
Richard.
Peter Lupton
[EMAIL PROTECTED]
NCH Swift Sound
Unit 13, Level 3
28 University Avenue
GPO Box 1169
Canberra ACT 2601
Australia
www.nch.com.au
Re: Wishlish: GCC option for explicit booleans
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 > be (in Win32)... > > HANDLE hFile = CreateFile(...); >if (!hFile) return; > > If the compiler had forced the writer to make a real comparison, I am sure > the bug would never have made it into release. The problem here is > INVALID_HANDLE_VALUE is -1 not 0. I would say this case is a problem of microsoft's api, sometimes 0 means not good, and sometimes -1. (and it's always a macro). Besides HANDLE is integer. (as far as I recall) I would give my own example of warning that should be an error, and it is not. This is not bool, but.. Recently in 2.6 kernels one of kmalloc's arguments has change its type. gcc only gives warning on that, while it should give an error. -- Vercetti
Re: Should -msse3 enable fisttp
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://gcc.gnu.org/bugzilla/show_bug.cgi?id=23809 I'm a little disappointed the behavior of the compiler was changed without addressing this. Maybe somebody could review the patch in that radar?
Re: RFC: redundant stores in C++
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 patch should fix the problem and also fixes FSF PR 8045 at the same time. FSF PR 8045 is about an missing unused variable causes by this code. This patch causes us to be more similar with the C front-end. It should also cause us save us some compile time issue when gimplifing and memory too. Note I have not tested this yet by either looking at the code gen or even compiling it. I will be doing a bootstrap/test of this right now. -- Pinski Index: typeck2.c === RCS file: /cvs/gcc/gcc/gcc/cp/typeck2.c,v retrieving revision 1.192 diff -u -p -r1.192 typeck2.c --- typeck2.c 1 Aug 2005 04:02:26 - 1.192 +++ typeck2.c 2 Oct 2005 03:36:41 - @@ -613,10 +613,13 @@ store_init_value (tree decl, tree init) value = digest_init (type, init); /* If the initializer is not a constant, fill in DECL_INITIAL with the bits that are constant, and then return an expression that - will perform the dynamic initialization. */ + will perform the dynamic initialization. We don't have to do this + for local variables either. */ if (value != error_mark_node && (TREE_SIDE_EFFECTS (value) - || ! initializer_constant_valid_p (value, TREE_TYPE (value + || ! initializer_constant_valid_p (value, TREE_TYPE (value))) + && (TREE_CODE (decl) != VAR_DECL + || TREE_STATIC (dest))) return split_nonconstant_init (decl, value); /* If the value is a constant, just put it in DECL_INITIAL. If DECL is an automatic variable, the middle end will turn this into a Thanks. The last line of this patch should use "decl", not "dest". With that obvious change it tests OK in apple's branch. (I cannot build mainline on darwin x86 at the moment for unrelated reasons - nothing that means there is a problem in mainline, I don't think.)
Re: Should -msse3 enable fisttp
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~
Re: problems with writing a new pass
- 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 function 'vprintf': /usr/include/bits/stdio.h:37: internal compiler error: Segmentation fault You are getting an error *compiling* vprintf, not *using* it. Paolo Thanks for the remind. After debugging for a while, I think it is an error caused by using *and* compiling: I put my pass as the first pass using NEXT_PASS in passes.c and use FOR_EACH_BB and etc, which are constructed after the pass of building CFGs. Then, during stage2 and 3, the new compiler will incorrectly *use* uninitialized data structures to *compile* vprintf and cause segfault. Then my question is: can the pass manager automatically rearrange the order of passes based on required and provided properties of all passes? It can help avoid certain misuses, like the one I made. Skyhover
Re: gcc 4.1 FAIL: gfortran.dg/large_integer_kind_1.f90 on sparc/sparc64 linux...
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 nobody can provide help in the next few days, please file a bug-report. > > Thanks for your help, > FX The result of check_effective_target_fortran_large_int is cached after it is first used for running tests for 64-bit code, and that result is still used for running the tests for 32-bit code when the result would be different. There's a similar problem in my tests for powerpc64-linux where the 32-bit result is used for 64-bit testing and all of those tests are maked unsupported. Janis
Re: gcc 4.1 FAIL: gfortran.dg/large_integer_kind_1.f90 on sparc/sparc64 linux...
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 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. > > > > Thanks for your help, > > FX > > The result of check_effective_target_fortran_large_int is cached after > it is first used for running tests for 64-bit code, and that result is > still used for running the tests for 32-bit code when the result would > be different. There's a similar problem in my tests for powerpc64-linux > where the 32-bit result is used for 64-bit testing and all of those > tests are maked unsupported. I forgot to mention that I'll fix this. Janis
Re: Wishlish: GCC option for explicit booleans
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 the compiler had forced the writer to make a real comparison, I am sure > the bug would never have made it into release. The problem here is > INVALID_HANDLE_VALUE is -1 not 0. It wouldn't help if the test was "corrected" to this: if (hFile==0) return; or if (!bool(hFile)) return; which I can imagine happening very easily if someone is modifying a whole code base to conform to the new rules. Once they've "corrected" it like that, it compiles again and the bug remains unfixed. If someone has made the mistake of thinking the invalid value is 0, I think that's unrelated to whether ints convert to bool. Code review seems like the best place for this bug to be caught IMHO. The difficulty of verifying the correct handling of magic numbers returned as error codes is an argument for using exceptions. If you need to use functions like CreateFile that don't throw, then wrap them in another function that does and then you only have to verify that the right value is checked in that one place. C++ provides better ways to avoid this error than disabling int -> bool conversions (again, IMHO.) As for your strcmp() example, that would break all code that says: if (!strcmp(s,t)) Unless you make operator!(int) return bool (which would seem sensible to me,) but then your HANDLE example wouldn't be caught. Personally I don't think the pros outweigh the cons of this idea. Regards, jon
Re: gcc 4.1 FAIL: gfortran.dg/large_integer_kind_1.f90 on sparc/sparc64 linux...
On 10/4/05, Janis Johnson <[EMAIL PROTECTED]> wrote: > I forgot to mention that I'll fix this. Great! :) -- Cheers, /ChJ
gcc-3.4-20051004 is now available
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 find: gcc-3.4-20051004.tar.bz2 Complete GCC (includes all of below) gcc-core-3.4-20051004.tar.bz2 C front end and core compiler gcc-ada-3.4-20051004.tar.bz2 Ada front end and runtime gcc-g++-3.4-20051004.tar.bz2 C++ front end and runtime gcc-g77-3.4-20051004.tar.bz2 Fortran 77 front end and runtime gcc-java-3.4-20051004.tar.bz2 Java front end and runtime gcc-objc-3.4-20051004.tar.bz2 Objective-C front end and runtime gcc-testsuite-3.4-20051004.tar.bz2The GCC testsuite Diffs from 3.4-20050927 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-3.4 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Cross GCC on Cygwin
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 discuss things. MinGW is a different kettle of fish. >>On Oct 1, 2005, at 4:41 AM, Brian Rose wrote: >> >>>I am an embedded software developer and I am interested in using >>>GCC as a >>>cross-compiler on the Cygwin/Windows platform. I would like to >>>know which lists I should subscribe to in order to discuss this >>>effort. -- Christopher Faylor spammer? -> [EMAIL PROTECTED] Cygwin Co-Project Leader[EMAIL PROTECTED] TimeSys, Inc.
Successful build of gcc 4.0.2 on alphaev56-dec-osf5.1b (c, c++, treelang)
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 gcc version 4.0.2 # sizer -v Compaq Tru64 UNIX V5.1B (Rev. 2650); Wed Sep 21 14:24:10 MEST 2005 Notes: It seems that Tru64 version of yacc, m4 and make are not compatible with gcc Makefile. The solution was to download and compile sources of bison (instead of yacc), GNU m4 and GNU make.
