[Bug target/36992] Very stange code for _mm_move_epi64
--- Comment #17 from ubizjak at gmail dot com 2008-08-03 06:49 --- Fixed. -- ubizjak at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED GCC target triplet||x86-pc-linux-gnu Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36992
[Bug bootstrap/37013] gcc-4.2.1 build breaks in fortran when using --with-mpfr=
--- Comment #3 from rob1weld at aol dot com 2008-08-03 06:29 --- Reopened - Broken in 4.2.2 and 4.2.3 also. -- rob1weld at aol dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Known to fail||4.2.1 4.2.2 4.2.3 Resolution|WONTFIX | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37013
[Bug target/36992] Very stange code for _mm_move_epi64
--- Comment #16 from uros at gcc dot gnu dot org 2008-08-03 06:14 --- Subject: Bug 36992 Author: uros Date: Sun Aug 3 06:13:04 2008 New Revision: 138564 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=138564 Log: PR target/36992 * config/i386/sse.md (vec_concatv2di): Add Y2 constraint to alternative 0 of operand 1. (*vec_concatv2di_rex64_sse): Ditto. (*vec_concatv2di_rex64_sse4_1): Add x constraint to alternative 0 of operand 1. (*sse2_storeq_rex64): Penalize allocation of "r" registers. * config/i386/mmx.md (*mov_internal_rex64): Penalize allocation of "Y2" registers to avoid SSE <-> MMX conversions for DImode moves. (*movv2sf_internal_rex64): Ditto. testsuite/ChangeLog: PR target/36992 * gcc.target/i386/pr36992-1.c: New test. * gcc.target/i386/pr36992-2.c: Ditto. Added: trunk/gcc/testsuite/gcc.target/i386/pr36992-1.c trunk/gcc/testsuite/gcc.target/i386/pr36992-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/mmx.md trunk/gcc/config/i386/sse.md trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36992
[Bug bootstrap/37013] gcc-4.2.1 build breaks in fortran when using --with-mpfr=
--- Comment #2 from rob1weld at aol dot com 2008-08-03 05:12 --- > 4.2.1 is history and is completely and utterly unsupported. OK. Directory ftp://ftp.gnu.org/gnu/gcc/ says the date is 07/20/07 so it is barely over one year old. I desire to build a 4.2.x series so I'll move up one minor. Thanks, I'm marking this as WONTFIX based on your reply. -- rob1weld at aol dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37013
[Bug bootstrap/37013] gcc-4.2.1 build breaks in fortran when using --with-mpfr=
--- Comment #1 from kargl at gcc dot gnu dot org 2008-08-03 04:58 --- what happens with gcc versions 4.2.2, 4.2.3, 4.2.4, 4.3.0, and 4.3.1? In other words, 4.2.1 is history and is completely and utterly unsupported. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37013
[Bug bootstrap/37013] New: gcc-4.2.1 build breaks in fortran when using --with-mpfr=
OpenSolaris is available free from: http://opensolaris.org/ I am building gcc-4.2.1 release from: ftp://ftp.gnu.org/gnu/gcc/gcc-4.2.1/gcc-4.2.1.tar.bz2 When building gcc on Solaris operating systems it is required (by Sun) that you use "--prefix=...", "--with-gmp=...", "--with-mpfr=...", (and --with-ld=/usr/ccs/bin/ld, --enable-shared, --disable-static, --enable-threads=solaris, --enable-multilib) in order to compile gcc correctly and, when installing, to avoid overwriting the system compiler and libraries. Overwriting the system compiler and libraries is not a supported configuration (of the Operating System). I used --with-mpfr=/opt/gnu/mpfr-2.3.1 so I could use my own copy of mpfr but while building gcc the build broke here (in gcc/fortran stage 1): ... build/genchecksum cc1plus-dummy > cc1plus-checksum.c gcc -c -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute-DHAVE_CONFIG_H -I. -I. -I/aux0/gcc-4.2.1/gcc -I/aux0/gcc-4.2.1/gcc/. -I/aux0/gcc-4.2.1/gcc/../include -I./../intl -I/aux0/gcc-4.2.1/gcc/../libcpp/include -I/aux0/gcc-4.2.1/gcc/../libdecnumber -I../libdecnumbercc1plus-checksum.c -o cc1plus-checksum.o gcc -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute-DHAVE_CONFIG_H -o cc1plus \ cp/cp-lang.o stub-objc.o cp/call.o cp/decl.o cp/expr.o cp/pt.o cp/typeck2.o cp/class.o cp/decl2.o cp/error.o cp/lex.o cp/parser.o cp/ptree.o cp/rtti.o cp/typeck.o cp/cvt.o cp/except.o cp/friend.o cp/init.o cp/method.o cp/search.o cp/semantics.o cp/tree.o cp/repo.o cp/dump.o cp/optimize.o cp/mangle.o cp/cp-objcp-common.o cp/name-lookup.o cp/cxx-pretty-print.o cp/cp-gimplify.o tree-mudflap.o attribs.o c-common.o c-format.o c-pragma.o c-semantics.o c-lex.o c-dump.o sol2-c.o c-pretty-print.o c-opts.o c-pch.o c-incpath.o cppdefault.o c-ppoutput.o c-cppbuiltin.o prefix.o c-gimplify.o c-omp.o tree-inline.o cc1plus-checksum.o main.o libbackend.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a ../libcpp/libcpp.a ./../intl/libintl.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a gcc -c -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute-DHAVE_CONFIG_H -I. -Ifortran -I/aux0/gcc-4.2.1/gcc -I/aux0/gcc-4.2.1/gcc/fortran -I/aux0/gcc-4.2.1/gcc/../include -I./../intl -I/aux0/gcc-4.2.1/gcc/../libcpp/include -I/aux0/gcc-4.2.1/gcc/../libdecnumber -I../libdecnumber/aux0/gcc-4.2.1/gcc/fortran/arith.c -o fortran/arith.o In file included from /aux0/gcc-4.2.1/gcc/fortran/arith.c:31: /aux0/gcc-4.2.1/gcc/fortran/gfortran.h:1229:18: error: mpfr.h: No such file or directory In file included from /aux0/gcc-4.2.1/gcc/fortran/arith.c:31: /aux0/gcc-4.2.1/gcc/fortran/gfortran.h:1263: error: syntax error before 'mpfr_t' /aux0/gcc-4.2.1/gcc/fortran/gfortran.h:1263: warning: no semicolon at end of struct or union /aux0/gcc-4.2.1/gcc/fortran/gfortran.h:1263: warning: no semicolon at end of struct or union /aux0/gcc-4.2.1/gcc/fortran/gfortran.h:1267: error: syntax error before 'mpfr_t' ... My mpfr.h file is present in directory /opt/gnu/mpfr-2.3.1/include but the ' gcc -o fortran/arith.o ... ' command does not "-I" that directory. -- Summary: gcc-4.2.1 build breaks in fortran when using --with- mpfr= Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rob1weld at aol dot com GCC build triplet: i386-pc-solaris2.11 GCC host triplet: i386-pc-solaris2.11 GCC target triplet: i386-pc-solaris2.11 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37013
[Bug c++/37012] numerous stackalign related testsuite failures on i686-apple-darwin9
--- Comment #3 from howarth at nitro dot med dot uc dot edu 2008-08-03 04:30 --- This testcase is compiled with... /sw/src/fink.build/gcc44-4.3.999-20080801/darwin_objdir/gcc/testsuite/g++/../../g++ -B/sw/src/fink.build/gcc44-4.3.999-20080801/darwin_objdir/gcc/testsuite/g++/../../ /sw/src/fink.build/gcc44-4.3.999-20080801/gcc-4.4-20080801/gcc/testsuite/g++.dg/torture/stackalign/eh-alloca-1.C -nostdinc++ -I/sw/src/fink.build/gcc44-4.3.999-20080801/darwin_objdir/i686-apple-darwin9/libstdc++-v3/include/i686-apple-darwin9 -I/sw/src/fink.build/gcc44-4.3.999-20080801/darwin_objdir/i686-apple-darwin9/libstdc++-v3/include -I/sw/src/fink.build/gcc44-4.3.999-20080801/gcc-4.4-20080801/libstdc++-v3/libsupc++ -I/sw/src/fink.build/gcc44-4.3.999-20080801/gcc-4.4-20080801/libstdc++-v3/include/backward -I/sw/src/fink.build/gcc44-4.3.999-20080801/gcc-4.4-20080801/libstdc++-v3/testsuite/util -fmessage-length=0 -O3 -g -mstackrealign -mpreferred-stack-boundary=5 -L/sw/src/fink.build/gcc44-4.3.999-20080801/darwin_objdir/i686-apple-darwin9/./libstdc++-v3/src/.libs -L/sw/src/fink.build/gcc44-4.3.999-20080801/darwin_objdir/i686-apple-darwin9/./libstdc++-v3/src/.libs -L/sw/src/fink.build/gcc44-4.3.999-20080801/darwin_objdir/i686-apple-darwin9/./libiberty -multiply_defined suppress --save-temps -lm -o ./eh-alloca-1.exe on i686-apple-darwin9. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37012
[Bug c++/37012] numerous stackalign related testsuite failures on i686-apple-darwin9
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2008-08-03 04:28 --- Created an attachment (id=16003) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16003&action=view) preprocessed source file for g++.dg/torture/stackalign/eh-alloca-1.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37012
[Bug c++/37012] numerous stackalign related testsuite failures on i686-apple-darwin9
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2008-08-03 04:27 --- Created an attachment (id=16002) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16002&action=view) assembly file for g++.dg/torture/stackalign/eh-alloca-1.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37012
[Bug c++/37012] New: numerous stackalign related testsuite failures on i686-apple-darwin9
Current gcc trunk exhibits a number of stackalign execution related testsuite failures on i686-apple-darwin9... http://gcc.gnu.org/ml/gcc-testresults/2008-08/msg00184.html One example is g++.dg/torture/stackalign/eh-alloca-1.C which fails in the execution tests at all optimization levels. In gdb, this segfault backtraces as... Starting program: /Users/howarth/stackalign/eh-alloca-1.exe Reading symbols for shared libraries +++. done terminate called after throwing an instance of 'A' Program received signal SIGABRT, Aborted. 0x92986b9e in __kill () (gdb) bt #0 0x92986b9e in __kill () #1 0x92986b91 in kill$UNIX2003 () #2 0x929fdec2 in raise () #3 0x92a0d47f in abort () #4 0x001bed0b in __gnu_cxx::__verbose_terminate_handler () #5 0x001bc83a in __cxxabiv1::__terminate () #6 0x001bc87c in std::terminate () #7 0x001bc974 in __cxa_throw () #8 0x1ea1 in foo (size=192) at /sw/src/fink.build/gcc44-4.3.999-20080801/gcc-4.4-20080801/gcc/testsuite/g++.dg/torture/stackalign/eh-alloca-1.C:47 #9 0x1ed5 in main () at /sw/src/fink.build/gcc44-4.3.999-20080801/gcc-4.4-20080801/gcc/testsuite/g++.dg/torture/stackalign/eh-alloca-1.C:53 -- Summary: numerous stackalign related testsuite failures on i686- apple-darwin9 Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: howarth at nitro dot med dot uc dot edu GCC build triplet: i686-apple-darwin9 GCC host triplet: i686-apple-darwin9 GCC target triplet: i686-apple-darwin9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37012
[Bug c++/36963] [4.4 Regression] Bogus narrowing conversion error in initializer list.
-- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-08-03 03:01:20 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36963
[Bug c++/36963] [4.4 Regression] Bogus narrowing conversion error in initializer list.
--- Comment #6 from jason at gcc dot gnu dot org 2008-08-03 03:01 --- There is an open issue about this problem which should be addressed at the next meeting. I'm quite sure this will not be invalid C++0x when the standard is finished. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36963
[Bug bootstrap/36948] cc1.exe: internal compiler error: Segmentation fault
--- Comment #14 from andry at inbox dot ru 2008-08-03 02:42 --- (In reply to comment #12) > MinGW apps like gcc have *no* way of interpreting anything but Win32 paths. It is, i found that Msys bash shell (not console) converts all this stuff with Msys paths. So xgcc already gothering paths in windows form. > And yes, using Win32 paths with colons also fails because the gcc build > system isn't expecting paths with colons. Fails not the build, fails call to cc1.exe, in "/gcc" in build directory. I try simply run it and it fails. Maybe problem in some library and in another thing... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36948
[Bug bootstrap/36948] cc1.exe: internal compiler error: Segmentation fault
--- Comment #13 from andry at inbox dot ru 2008-08-03 01:50 --- (In reply to comment #12) > You're not really testing what you think you are Ok, i found that Msys console converts all application arguments and environment variables before run any application. So, i missed out that in Windows console GCC compiler doesn't understand MSYS paths. > And yes, using Win32 paths with colons also fails because the gcc build > system isn't expecting paths with colons. So, have i any chances to pass in --prefix argument path in Windows form to not mingw directory? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36948
[Bug middle-end/37009] No need to align stack when incoming stack is aligned
--- Comment #1 from hjl dot tools at gmail dot com 2008-08-03 00:54 --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2008-08/msg00124.html -- hjl dot tools at gmail dot com changed: What|Removed |Added BugsThisDependsOn||37010 URL||http://gcc.gnu.org/ml/gcc- ||patches/2008- ||08/msg00124.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37009
[Bug target/37010] -Os passes __m128 on stack with wrong alignment
--- Comment #1 from hjl dot tools at gmail dot com 2008-08-03 00:37 --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2008-08/msg00123.html -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||Joey dot ye at intel dot ||com, xuepeng dot guo at ||intel dot com URL||http://gcc.gnu.org/ml/gcc- ||patches/2008- ||08/msg00123.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37010
[Bug fortran/37011] New: F2003, type extension: multiple inheritence not rejected
F2003, sec. 4.5.1 (derived type definition): EXTENDS is an attribute that can not be specified more than once. Currently (20080803), gfortran accepts: TYPE :: b INTEGER :: i END TYPE TYPE, EXTENDS(b), EXTENDS(b) :: d INTEGER :: j END TYPE -- Summary: F2003, type extension: multiple inheritence not rejected Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: accepts-invalid Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dfranke at gcc dot gnu dot org OtherBugsDependingO 20585 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37011
[Bug libfortran/36886] misaligment for cshift of character
--- Comment #3 from tkoenig at gcc dot gnu dot org 2008-08-02 23:49 --- Created an attachment (id=16001) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16001&action=view) better patch This one is better :-) -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Attachment #16000|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36886
[Bug libfortran/36886] misaligment for cshift of character
--- Comment #2 from tkoenig at gcc dot gnu dot org 2008-08-02 23:43 --- Created an attachment (id=16000) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16000&action=view) proposed patch for cshift0 Here's something that works for cshift0. cshift1 still to do... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36886
[Bug rtl-optimization/36998] [4.3/4.4 regression] Ada bootstrap broken on i586-*-*
--- Comment #10 from kkojima at gcc dot gnu dot org 2008-08-02 22:12
---
(In reply to comment #8)
> If a label is reachable from different args_size levels, that's a severe bug
> and should be fixed wherever that is created, likely expander.
It seems that arg_size is reset with (set (reg sp) (reg fp))
just after label 77 in #7:
(code_label 77 42 76 10 "" [2 uses])
(note 76 77 61 [bb 9] NOTE_INSN_BASIC_BLOCK)
(insn 61 76 100 bas.c:22 (use (reg/i:SI 0 r0)) -1 (nil))
(note 100 61 101 NOTE_INSN_EPILOGUE_BEG)
(insn 101 100 102 bas.c:22 (unspec_volatile [
(const_int 0 [0x0])
] 0) 284 {blockage} (nil))
(insn 102 101 127 bas.c:22 (set (reg/f:SI 15 r15)
(reg/f:SI 14 r14)) 175 {movsi_ie} (nil))
Does it look a target bug? If so, should I file a new
PR target to bugzilla?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36998
[Bug bootstrap/36948] cc1.exe: internal compiler error: Segmentation fault
--- Comment #12 from brian at dessent dot net 2008-08-02 21:02 --- Subject: Re: cc1.exe: internal compiler error: Segmentation fault You're not really testing what you think you are, because MSYS translates everything on the command line, so saying that "gcc -I/foo/bar" works just means that MSYS actually executed "gcc -Ic:/path/to/foo/bar". MinGW apps like gcc have *no* way of interpreting anything but Win32 paths. And yes, using Win32 paths with colons also fails because the gcc build system isn't expecting paths with colons. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36948
[Bug bootstrap/36948] cc1.exe: internal compiler error: Segmentation fault
--- Comment #11 from andry at inbox dot ru 2008-08-02 20:41 --- > /c/foo/bar is valid for *MSYS* apps. But we're talking about gcc which > is NOT a MSYS app, it is a MinGW app, i.e. native win32. /c/foo/bar is > *not* valid for such an app. Not true, for example, Mingw GCC 3.4.4 perfectly understands BOTH type of paths. You can simply test it putting paths in to environment variables like "CPATH" or in "-I" key on command line. > In fact the whole point of MSYS is to > rewrite these paths as c:/foo/bar when invoking MinGW apps, but that is > only possible if they are passed on a command line. The gcc build > system sometimes embeds them in filenames and they won't be translated. > Thus you have to be careful to avoid using them. If all this was true, then build should be crash on early stage then first "incorrect" path come on commend line, but it wouldn't happend. I test build with "c:\" and with "c:/" paths, the build crashes the same. I think this is not a point of the bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36948
[Bug bootstrap/36948] cc1.exe: internal compiler error: Segmentation fault
--- Comment #10 from brian at dessent dot net 2008-08-02 19:24 --- Subject: Re: cc1.exe: internal compiler error: Segmentation fault /c/foo/bar is valid for *MSYS* apps. But we're talking about gcc which is NOT a MSYS app, it is a MinGW app, i.e. native win32. /c/foo/bar is *not* valid for such an app. In fact the whole point of MSYS is to rewrite these paths as c:/foo/bar when invoking MinGW apps, but that is only possible if they are passed on a command line. The gcc build system sometimes embeds them in filenames and they won't be translated. Thus you have to be careful to avoid using them. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36948
[Bug c++/36963] [4.4 Regression] Bogus narrowing conversion error in initializer list.
--- Comment #5 from manu at gcc dot gnu dot org 2008-08-02 19:05 --- ... to close as INVALID. -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36963
[Bug c++/36963] [4.4 Regression] Bogus narrowing conversion error in initializer list.
--- Comment #4 from manu at gcc dot gnu dot org 2008-08-02 19:04 --- Reopened... -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36963
[Bug c++/37004] [C++ only] Wconversion warns for short y = 0x7fff; short z = (short) x & y;
--- Comment #2 from manu at gcc dot gnu dot org 2008-08-02 19:03 --- Wrong bug (argh!). -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37004
[Bug c++/37004] [C++ only] Wconversion warns for short y = 0x7fff; short z = (short) x & y;
--- Comment #1 from manu at gcc dot gnu dot org 2008-08-02 19:03 --- INVALID (not FIXED). -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37004
[Bug c++/36963] [4.4 Regression] Bogus narrowing conversion error in initializer list.
--- Comment #3 from manu at gcc dot gnu dot org 2008-08-02 19:02 --- OK. Invalid then. -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36963
[Bug target/36992] Very stange code for _mm_move_epi64
--- Comment #15 from ubizjak at gmail dot com 2008-08-02 18:43 --- Complete patch at http://gcc.gnu.org/ml/gcc-patches/2008-08/msg00116.html -- ubizjak at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2008- ||08/msg00116.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36992
[Bug c++/36963] [4.4 Regression] Bogus narrowing conversion error in initializer list.
--- Comment #2 from chris dot fairles at gmail dot com 2008-08-02 18:41 --- (In reply to comment #1) > AFAIK, the error is a request of the c++0x standard and it seems -0.02435L > does > not fit exactly in a float while -0.25L does, so the message is correct and I > thus I don't think there is a bug here. > > Perhaps it should be a permissive error, so users can compile legacy code in > c++0x mode. > > CCing Jason. > I think you are right. Section 8.5.4 - List-initialization, in the current WD (N2691) says that a narrowing conversion from double to float is only allowed if the conversion is of a literal value and the value can fit into the destination type such that it produces the exact same value when coverted back. Then from 8.5.4 paragraph 3, 3rd bullet, if any argument requires a narrowing conversion, the program is ill-formed. If you use the "f" post-fix in the test case, no narrowing conversion is required and the error is not issued as expected. This can be marked as invalid I believe. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36963
[Bug target/35659] [4.3/4.4 Regression] Miscompiled code with -O2 (but not with -O2 -funroll-loops) on ia64
--- Comment #23 from mkuvyrkov at gcc dot gnu dot org 2008-08-02 18:15 --- (In reply to comment #22) > Maxim, have you had time to look at this bug? Given that it is generating bad > code and is in 4.3.0 and 4.3.1 I was wondering if it will be fixed for 4.3.2. Sorry for the delay. I posted the fix at http://gcc.gnu.org/ml/gcc-patches/2008-08/msg00112.html. I would appreciate if someone could test the cumulative patch of three fixes for ia64 speculation support or provide a single-file executable testcase for this bug. Here are links to two other bugfixes for ia64 speculation support: http://gcc.gnu.org/ml/gcc-patches/2008-08/msg00110.html http://gcc.gnu.org/ml/gcc-patches/2008-08/msg00111.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35659
[Bug bootstrap/36948] cc1.exe: internal compiler error: Segmentation fault
--- Comment #9 from andry at inbox dot ru 2008-08-02 18:01 --- (In reply to comment #8) > It's a valid MinGW path only if you have created a physical directory > named "c" at the root of the current drive, i.e. X:\c\_GccBuilds\... > >From "/msys/1.0/doc/MSYS_VS_CYGWIN": /cygdrive: There is no such item. All devices and mapped shares are auto mounted with the device letter as the mount point. E.G.: the C:\ drive is referenced as /c. >From this, "/c" is automount point to "c:". -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36948
[Bug target/37010] New: -Os passes __m128 on stack with wrong alignment
-Os passes __m128 on stack with wrong alignment:
bash-3.2$ cat x.c
#include
extern void foo (__m128 x, __m128 y ,__m128 z ,__m128 a, int size);
void
bar (void)
{
__m128 x = { 1.0 };
foo (x, x, x, x, 5);
}
bash-3.2$ /export/build/gnu/gcc-work/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-work/build-x86_64-linux/gcc/-Os -msse2 -m32 x.c
-S
bash-3.2$ cat x.s
.file "x.c"
.text
.globl bar
.type bar, @function
bar:
pushl %ebp
movl%esp, %ebp
subl$20, %esp
movss .LC0, %xmm0
pushl $5
subl$16, %esp
movups %xmm0, (%esp)
This should be aligned at 16byte with movaps.
movaps %xmm0, %xmm2
movaps %xmm0, %xmm1
callfoo
addl$32, %esp
leave
ret
--
Summary: -Os passes __m128 on stack with wrong alignment
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37010
[Bug bootstrap/36948] cc1.exe: internal compiler error: Segmentation fault
--- Comment #8 from brian at dessent dot net 2008-08-02 16:56 --- Subject: Re: cc1.exe: internal compiler error: Segmentation fault It's a valid MinGW path only if you have created a physical directory named "c" at the root of the current drive, i.e. X:\c\_GccBuilds\... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36948
[Bug target/36992] Very stange code for _mm_move_epi64
--- Comment #14 from ubizjak at gmail dot com 2008-08-02 16:01 --- (In reply to comment #13) > We should also test -O0. Usage of MMX regs with -O0 is fixed by following patch: Index: config/i386/mmx.md === --- config/i386/mmx.md (revision 138553) +++ config/i386/mmx.md (working copy) @@ -65,9 +65,9 @@ (define_insn "*mov_internal_rex64" [(set (match_operand:MMXMODEI8 0 "nonimmediate_operand" - "=rm,r,!?y,!?y ,m ,!y,Y2,x,x ,m,r,x") + "=rm,r,!?y,!?y ,m ,!y,*Y2,x,x ,m,r,x") (match_operand:MMXMODEI8 1 "vector_move_operand" - "Cr ,m,C ,!?ym,!?y,Y2,!y,C,xm,x,x,r"))] + "Cr ,m,C ,!?ym,!?y,*Y2,!y,C,xm,x,x,r"))] "TARGET_64BIT && TARGET_MMX && !(MEM_P (operands[0]) && MEM_P (operands[1]))" "@ @@ -124,9 +124,9 @@ (define_insn "*movv2sf_internal_rex64" [(set (match_operand:V2SF 0 "nonimmediate_operand" - "=rm,r ,!?y,!?y ,m ,!y,Y2,x,x,x,m,r,x") + "=rm,r ,!?y,!?y ,m ,!y,*Y2,x,x,x,m,r,x") (match_operand:V2SF 1 "vector_move_operand" - "Cr ,m ,C ,!?ym,!y,Y2,!y,C,x,m,x,x,r"))] + "Cr ,m ,C ,!?ym,!y,*Y2,!y,C,x,m,x,x,r"))] "TARGET_64BIT && TARGET_MMX && !(MEM_P (operands[0]) && MEM_P (operands[1]))" "@ > Why do we use _mm_movepi64_pi64 at all? _mm_movepi64_pi64 is an MMX > intrinsic. It isn't necessary here. _mm_movepi64_pi64 extracts DImode element 0 from V2DI vector. It just generates sse2_storeq_* pattern that operates also on SSE regs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36992
[Bug rtl-optimization/36998] [4.3/4.4 regression] Ada bootstrap broken on i586-*-*
--- Comment #9 from ebotcazou at gcc dot gnu dot org 2008-08-02 15:49 --- > Untested patch to set args_size to 0 when encountering (set (reg sp) (reg di)) > etc. OK on i586-linux (C/C++/Ada) on both the mainline and the 4.3 branch. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-08-02 15:49:07 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36998
[Bug c++/36963] [4.4 Regression] Bogus narrowing conversion error in initializer list.
--- Comment #1 from manu at gcc dot gnu dot org 2008-08-02 15:28 --- AFAIK, the error is a request of the c++0x standard and it seems -0.02435L does not fit exactly in a float while -0.25L does, so the message is correct and I thus I don't think there is a bug here. Perhaps it should be a permissive error, so users can compile legacy code in c++0x mode. CCing Jason. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||jason at redhat dot com, ||manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36963
[Bug target/36992] Very stange code for _mm_move_epi64
--- Comment #13 from hjl dot tools at gmail dot com 2008-08-02 15:19
---
We should also test -O0. This code:
extern __inline __m128i __attribute__((__gnu_inline__, __always_inline__,
__artificial__))
_mm_movpi64_epi64 (__m64 __A)
{
return _mm_set_epi64 ((__m64)0LL, __A);
}
extern __inline __m128i __attribute__((__gnu_inline__, __always_inline__,
__artificial__))
_mm_move_epi64 (__m128i __A)
{
return _mm_set_epi64 ((__m64)0LL, _mm_movepi64_pi64 (__A));
}
Why do we use _mm_movepi64_pi64 at all? _mm_movepi64_pi64 is an MMX
intrinsic. It isn't necessary here.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36992
[Bug rtl-optimization/36998] [4.3/4.4 regression] Ada bootstrap broken on i586-*-*
--- Comment #8 from jakub at gcc dot gnu dot org 2008-08-02 15:17 --- If a label is reachable from different args_size levels, that's a severe bug and should be fixed wherever that is created, likely expander. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36998
[Bug target/36992] Very stange code for _mm_move_epi64
--- Comment #12 from ubizjak at gmail dot com 2008-08-02 15:07 ---
Patch in testing:
Index: testsuite/gcc.target/i386/pr36992.c
===
--- testsuite/gcc.target/i386/pr36992.c (revision 0)
+++ testsuite/gcc.target/i386/pr36992.c (revision 0)
@@ -0,0 +1,12 @@
+/* { dg-do compile }
+/* { dg-options "-msse2 -O2" } */
+
+#include
+
+__m128i
+test (__m128i b)
+{
+ return _mm_move_epi64 (b);
+}
+
+/* { dg-final { scan-assembler-times "mov\[qd\]\[ \\t\]+.*%xmm" 1 } } */
Index: config/i386/sse.md
===
--- config/i386/sse.md (revision 138553)
+++ config/i386/sse.md (working copy)
@@ -4777,7 +4777,7 @@
"")
(define_insn "*sse2_storeq_rex64"
- [(set (match_operand:DI 0 "nonimmediate_operand" "=mx,r,r")
+ [(set (match_operand:DI 0 "nonimmediate_operand" "=mx,*r,r")
(vec_select:DI
(match_operand:V2DI 1 "nonimmediate_operand" "x,Yi,o")
(parallel [(const_int 0)])))]
@@ -4940,10 +4940,10 @@
(set_attr "mode" "TI,V4SF,V2SF")])
(define_insn "vec_concatv2di"
- [(set (match_operand:V2DI 0 "register_operand" "=Y2,?Y2,Y2,x,x,x")
+ [(set (match_operand:V2DI 0 "register_operand" "=Y2 ,?Y2,Y2,x,x,x")
(vec_concat:V2DI
- (match_operand:DI 1 "nonimmediate_operand" " m,*y ,0 ,0,0,m")
- (match_operand:DI 2 "vector_move_operand" " C, C,Y2,x,m,0")))]
+ (match_operand:DI 1 "nonimmediate_operand" " mY2,*y ,0 ,0,0,m")
+ (match_operand:DI 2 "vector_move_operand" " C , C,Y2,x,m,0")))]
"!TARGET_64BIT && TARGET_SSE"
"@
movq\t{%1, %0|%0, %1}
@@ -4956,10 +4956,10 @@
(set_attr "mode" "TI,TI,TI,V4SF,V2SF,V2SF")])
(define_insn "*vec_concatv2di_rex64_sse4_1"
- [(set (match_operand:V2DI 0 "register_operand" "=x,x,Yi,!x,x,x,x,x")
+ [(set (match_operand:V2DI 0 "register_operand" "=x ,x ,Yi,!x,x,x,x,x")
(vec_concat:V2DI
- (match_operand:DI 1 "nonimmediate_operand" " 0,m,r ,*y,0,0,0,m")
- (match_operand:DI 2 "vector_move_operand" "rm,C,C ,C ,x,x,m,0")))]
+ (match_operand:DI 1 "nonimmediate_operand" " 0 ,mx,r ,*y,0,0,0,m")
+ (match_operand:DI 2 "vector_move_operand" " rm,C ,C ,C ,x,x,m,0")))]
"TARGET_64BIT && TARGET_SSE4_1"
"@
pinsrq\t{$0x1, %2, %0|%0, %2, 0x1}
@@ -4975,10 +4975,10 @@
(set_attr "mode" "TI,TI,TI,TI,TI,V4SF,V2SF,V2SF")])
(define_insn "*vec_concatv2di_rex64_sse"
- [(set (match_operand:V2DI 0 "register_operand" "=Y2,Yi,!Y2,Y2,x,x,x")
+ [(set (match_operand:V2DI 0 "register_operand" "=Y2 ,Yi,!Y2,Y2,x,x,x")
(vec_concat:V2DI
- (match_operand:DI 1 "nonimmediate_operand" " m,r ,*y ,0 ,0,0,m")
- (match_operand:DI 2 "vector_move_operand" " C,C ,C ,Y2,x,m,0")))]
+ (match_operand:DI 1 "nonimmediate_operand" " mY2,r ,*y ,0 ,0,0,m")
+ (match_operand:DI 2 "vector_move_operand" " C ,C ,C ,Y2,x,m,0")))]
"TARGET_64BIT && TARGET_SSE"
"@
movq\t{%1, %0|%0, %1}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36992
[Bug rtl-optimization/36998] [4.3/4.4 regression] Ada bootstrap broken on i586-*-*
--- Comment #7 from kkojima at gcc dot gnu dot org 2008-08-02 15:02 ---
I've tested the 2nd patch on sh4, but it doesn't fix the ICE
on sh4. Perhaps the problem is slightly different from that
for i586. Here is a reduced test case for the sh-elf compiler
with the option '-m4 -O -fasynchronous-unwind-tables':
union double_union
{
double d;
unsigned int i[2];
};
char *foo (double _d, char *s, char **rve)
{
union double_union d;
d.d = _d;
if ((d.i[1]) & 0x8000UL)
(d.i[1]) &= ~0x8000UL;
if (((d.i[1]) & 0x7ff0UL) == 0x7ff0UL)
return s;
if (!d.d)
{
s = "0";
if (rve) *rve = s + 1;
return s;
}
}
I've tried to see what is going on in the above test case
with stepping from the top of compute_barrier_args_size_1.
It seems that that function scans insns and updates
cur_args_size as follows:
(insn/f 95 ... (set (reg/f:SI 14 r14) (reg/f:SI 15 r15))...)
...
(insn 91 ... (set (mem/c:SF (pre_dec:SI (reg/f:SI 15 r15))) (reg:SF 68
fr4))...)
cur_args_size is updated to 4.
(insn 92 ... (set (mem/c:SF (pre_dec:SI (reg/f:SI 15 r15))) (reg:SF 69
fr5))...)
cur_args_size is updated to 8.
...
(jump_insn 22 ... (label_ref 77) ...)
...
(insn 86 ... (set (mem/c:DF (pre_dec:SI (reg/f:SI 15 r15))) (reg:DF 6 r6)))
cur_args_size is updated to 16.
...
(jump_insn 33 ... (label_ref 77) ...)
...
;; Exit block
(code_label 77 ...)
...
(insn 102 ... (set (reg/f:SI 15 r15) (reg/f:SI 14 r14)) ...)
Thus label 77 is reachable from (jump_insn 22 ...) where arg_size
is 8 and from (jump_insn 33 ...) where arg_size is 16.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36998
[Bug middle-end/37009] New: No need to align stack when incoming stack is aligned
If a parameter is passed on stack, caller is responsible to align
the stack frame to at least the alignment of the parameter. But gcc
will align the stack even when it has been aligned already by caller.
bash-3.2$ cat 1.i
typedef float __m128 __attribute__ ((__vector_size__ (16), __may_alias__));
int
__attribute__ ((noinline))
foo(__m128 x, int size, ...)
{
volatile char * ptr=__builtin_alloca(size);
volatile int __attribute((aligned(16))) xxx;
xxx = 2;
ptr [1]= 30;
return xxx;
}
int
bar ()
{
__m128 x = { 1.0 };
foo (x, 30);
return 0;
}
bash-3.2$ /export/build/gnu/gcc-avx/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-stack/build-x86_64-linux/gcc/ -msse2 -m32
-mpreferred-stack-boundary=2 -S -o 1.s 1.i
bash-3.2$ cat 1.s
.file "1.i"
.text
.globl foo
.type foo, @function
foo:
leal4(%esp), %ecx
andl$-16, %esp
pushl -4(%ecx)
pushl %ebp
movl%esp, %ebp
pushl %ecx
subl$36, %esp
movl16(%ecx), %eax
addl$15, %eax
addl$3, %eax
shrl$2, %eax
sall$2, %eax
subl%eax, %esp
movl%esp, -28(%ebp)
movl-28(%ebp), %eax
addl$15, %eax
shrl$4, %eax
sall$4, %eax
movl%eax, -28(%ebp)
movl-28(%ebp), %eax
movl%eax, -12(%ebp)
movl$2, -24(%ebp)
movl-12(%ebp), %eax
addl$1, %eax
movb$30, (%eax)
movl-24(%ebp), %eax
movl-4(%ebp), %ecx
leave
leal-4(%ecx), %esp
ret
.size foo, .-foo
.globl bar
.type bar, @function
bar:
pushl %ebp
movl%esp, %ebp
andl$-16, %esp
subl$48, %esp
movss .LC0, %xmm0
movlps %xmm0, 32(%esp)
movhps %xmm0, 40(%esp)
movl$30, 16(%esp)
xorps %xmm0, %xmm0
movlps 32(%esp), %xmm0
movhps 40(%esp), %xmm0
movlps %xmm0, (%esp)
movhps %xmm0, 8(%esp)
callfoo
movl$0, %eax
leave
ret
.size bar, .-bar
.section.rodata
.align 16
.LC0:
.long 1065353216
.long 0
.long 0
.long 0
.ident "GCC: (GNU) 4.4.0 20080802 (experimental) [stack revision
138551]"
.section.note.GNU-stack,"",@progbits
bash-3.2$
--
Summary: No need to align stack when incoming stack is aligned
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37009
[Bug target/36992] Very stange code for _mm_move_epi64
--- Comment #11 from ubizjak at gmail dot com 2008-08-02 13:22 --- Uh, clearing of top bits is explicitly stated in latest Software Developer's Manual for both movq and movd. I'll fix these patterns. -- ubizjak at gmail dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ubizjak at gmail dot com |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-08-02 13:22:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36992
[Bug rtl-optimization/31485] C complex numbers, amd64 SSE, missed optimization opportunity
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-08-02 13:18 --- Doh, this is indeed completely broken ;) I'll experiment with lowering complex operations to vectorized form a bit. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31485
[Bug target/36992] Very stange code for _mm_move_epi64
--- Comment #10 from ubizjak at gmail dot com 2008-08-02 13:10 --- "←" in my previous post represents left pointing arrow, <. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36992
[Bug target/36992] Very stange code for _mm_move_epi64
--- Comment #9 from ubizjak at gmail dot com 2008-08-02 13:08 --- Hm, IA-32 Intel® Architecture Software Developers Manual says about movq: Operation MOVQ instruction when operating on MMX technology registers and memory locations: DEST ← SRC; MOVQ instruction when source and destination operands are XMM registers: DEST[63:0] ← SRC[63:0]; MOVQ instruction when source operand is XMM register and destination operand is memory location: DEST ← SRC[63:0]; MOVQ instruction when source operand is memory location and destination operand is XMM register: DEST[63:0] ← SRC; DEST[127:64] ← H; Please note, that the documentation doesn't say anything about clearing destination bits [127:64] when both source and destination are in XMM register. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36992
[Bug rtl-optimization/31485] C complex numbers, amd64 SSE, missed optimization opportunity
--- Comment #4 from ubizjak at gmail dot com 2008-08-02 13:00 ---
(In reply to comment #3)
> Operations in loops should now be vectorized. The original testcase is
> probably not worth vectorizing due to calling convention problems (_Complex T
> is not passed as a vector).
Not really. For some unknown reason, _Complex float is passed as a two element
vector in SSE register. This introduces (double!) store forwarding penalty,
since we have to split the value into SSE pair before processing. This is wrong
ABI design, as shown by comparing generated code from following example:
--cut here--
_Complex float testf (_Complex float a, _Complex float b)
{
return a + b;
}
_Complex double testd (_Complex double a, _Complex double b)
{
return a + b;
}
--cut here--
testf:
movq%xmm0, -8(%rsp)
movq%xmm1, -16(%rsp)
movss -8(%rsp), %xmm0
movss -4(%rsp), %xmm2
addss -16(%rsp), %xmm0
addss -12(%rsp), %xmm2
movss %xmm0, -24(%rsp)
movss %xmm2, -20(%rsp)
movq-24(%rsp), %xmm0
ret
testd:
addsd %xmm3, %xmm1
addsd %xmm2, %xmm0
ret
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31485
[Bug rtl-optimization/31485] C complex numbers, amd64 SSE, missed optimization opportunity
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-08-02 12:21 --- Operations in loops should now be vectorized. The original testcase is probably not worth vectorizing due to calling convention problems (_Complex T is not passed as a vector). Complex lowering could generate vectorized code directly though for operations not in a loop. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-08-02 12:21:42 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31485
[Bug c++/37008] [4.2 Regression] OOM on a big c++ file
--- Comment #4 from livubuntu at lalescu dot ro 2008-08-02 12:21 --- (In reply to comment #2) > g++: Internal error: Killed (program cc1plus) > > this means your system ran out of memory and the operating system decided > to kill the compiler. Note that memory usage problems are unlikely to be > fixed in a further release of GCC 4.2, but you might want to try GCC 4.3.1 > or later which uses less memory than GCC 4.1 for your testcase. > I tried the GCC 4.3.1, of course, but I got very very many weird warnings for the Qt included files. I tried the binary GCC 4.3.1 from Debian. A collaborator reports that he compiled successfully FET for the same Qt as mine, with GCC 4.3.1, but for 32 bit version. He obtained only a few warnings. Thank you for fast reply. I'll do some more tests with GCC 4.3.1 and maybe report bugs to Trolltech for Qt or report bugs here for GCC 4.3.1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37008
[Bug tree-optimization/35252] No vectorization for complex arrays
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-08-02 12:06 --- Subject: Bug 35252 Author: rguenth Date: Sat Aug 2 12:05:47 2008 New Revision: 138553 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=138553 Log: 2008-08-02 Richard Guenther <[EMAIL PROTECTED]> PR target/35252 * config/i386/sse.md (SSEMODE4S, SSEMODE2D): New mode iterators. (ssedoublesizemode): New mode attribute. (sse_shufps): Call gen_sse_shufps_v4sf. (sse_shufps_1): Macroize. (sse2_shufpd): Call gen_Sse_shufpd_v2df. (sse2_shufpd_1): Macroize. (vec_extract_odd, vec_extract_even): New expanders. (vec_interleave_highv4sf, vec_interleave_lowv4sf, vec_interleave_highv2df, vec_interleave_lowv2df): Likewise. * i386.c (ix86_expand_vector_init_one_nonzero): Call gen_sse_shufps_v4sf instead of gen_sse_shufps_1. (ix86_expand_vector_set): Likewise. (ix86_expand_reduc_v4sf): Likewise. * lib/target-supports.exp (vect_extract_even_odd_wide) Add. (vect_strided_wide): Likewise. * gcc.dg/vect/fast-math-pr35982.c: Enable for vect_extract_even_odd_wide. * gcc.dg/vect/fast-math-vect-complex-3.c: Likewise. * gcc.dg/vect/vect-1.c: Likewise. * gcc.dg/vect/vect-107.c: Likewise. * gcc.dg/vect/vect-98.c: Likewise. * gcc.dg/vect/vect-strided-float.c: Likewise. * gcc.dg/vect/slp-11.c: Enable for vect_strided_wide. * gcc.dg/vect/slp-12a.c: Likewise. * gcc.dg/vect/slp-12b.c: Likewise. * gcc.dg/vect/slp-19.c: Likewise. * gcc.dg/vect/slp-23.c: Likewise. * gcc.dg/vect/slp-5.c: Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/config/i386/sse.md trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/vect/fast-math-pr35982.c trunk/gcc/testsuite/gcc.dg/vect/fast-math-vect-complex-3.c trunk/gcc/testsuite/gcc.dg/vect/slp-11.c trunk/gcc/testsuite/gcc.dg/vect/slp-12a.c trunk/gcc/testsuite/gcc.dg/vect/slp-12b.c trunk/gcc/testsuite/gcc.dg/vect/slp-19.c trunk/gcc/testsuite/gcc.dg/vect/slp-23.c trunk/gcc/testsuite/gcc.dg/vect/slp-5.c trunk/gcc/testsuite/gcc.dg/vect/vect-1.c trunk/gcc/testsuite/gcc.dg/vect/vect-107.c trunk/gcc/testsuite/gcc.dg/vect/vect-98.c trunk/gcc/testsuite/gcc.dg/vect/vect-strided-float.c trunk/gcc/testsuite/lib/target-supports.exp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35252
[Bug rtl-optimization/36998] [4.3/4.4 regression] Ada bootstrap broken on i586-*-*
--- Comment #6 from jakub at gcc dot gnu dot org 2008-08-02 11:57 --- Created an attachment (id=15999) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15999&action=view) sp=reg.patch Untested patch to set args_size to 0 when encountering (set (reg sp) (reg di)) etc. I'll be offline for a week, can somebody please test the latter patch (the former is just a short term hack to disable the ICEs and keeping the unwind info bogus)? What perhaps still should be asserted is that on CALL_INSNs current args_size is equal to INTVAL (XEXP (call, 1)) (probably just in the !after_p case). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36998
[Bug rtl-optimization/36998] [4.3/4.4 regression] Ada bootstrap broken on i586-*-*
--- Comment #5 from jakub at gcc dot gnu dot org 2008-08-02 11:53 --- Created an attachment (id=15998) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15998&action=view) disable-asserts.patch Quick hack to disable asserts. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36998
[Bug tree-optimization/36922] [4.4 Regression] ICE in tree-data-ref.c with -ftree-loop-linear
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-08-02 11:50 --- Confirmed by the dup. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code Priority|P3 |P2 Last reconfirmed|-00-00 00:00:00 |2008-08-02 11:50:13 date|| Summary|ICE in tree-data-ref.c with |[4.4 Regression] ICE in |-ftree-loop-linear |tree-data-ref.c with -ftree- ||loop-linear Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36922
[Bug c++/37008] [4.2 Regression] OOM on a big c++ file
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Summary|Crash bug on a big c++ file |[4.2 Regression] OOM on a ||big c++ file Target Milestone|--- |4.2.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37008
[Bug c++/37008] Crash bug on a big c++ file
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-08-02 11:48 --- Created an attachment (id=15997) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15997&action=view) unincluded testcase Testcase that works with either -m32/-m64 and all libstdc++ versions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37008
[Bug c++/37008] Crash bug on a big c++ file
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-08-02 11:47 --- g++: Internal error: Killed (program cc1plus) this means your system ran out of memory and the operating system decided to kill the compiler. Note that memory usage problems are unlikely to be fixed in a further release of GCC 4.2, but you might want to try GCC 4.3.1 or later which uses less memory than GCC 4.1 for your testcase. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||compile-time-hog, memory-hog Known to fail||4.2.4 Known to work||4.1.2 4.3.1 Last reconfirmed|-00-00 00:00:00 |2008-08-02 11:47:05 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37008
[Bug target/36851] [4.4 regression] cc1plus SEGV compiling strstream.cc on Tru64 UNIX
--- Comment #7 from jh at suse dot cz 2008-08-02 11:31 --- Subject: Re: [4.4 regression] cc1plus SEGV compiling strstream.cc on Tru64 UNIX Looks like Aplha is not tuplified yet? ../../gcc/config/alpha/alpha.c: In function 'va_list_skip_additions': ../../gcc/config/alpha/alpha.c:5815: warning: assignment from incompatible pointer type ../../gcc/config/alpha/alpha.c:5817: error: 'PHI_NODE' undeclared (first use in this function) ../../gcc/config/alpha/alpha.c:5817: error: (Each undeclared identifier is reported only once ../../gcc/config/alpha/alpha.c:5817: error: for each function it appears in.) Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36851
[Bug bootstrap/36948] cc1.exe: internal compiler error: Segmentation fault
--- Comment #7 from andry at inbox dot ru 2008-08-02 11:10 --- (In reply to comment #6) > This kind of path > '--prefix=/c/_GccBuilds/gcc-4.3.1-install/mingw-32-i686' may be understood by But this is Mingw compatible path, isn't it? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36948
[Bug target/36851] [4.4 regression] cc1plus SEGV compiling strstream.cc on Tru64 UNIX
--- Comment #6 from jh at suse dot cz 2008-08-02 10:49 --- Subject: Re: [4.4 regression] cc1plus SEGV compiling strstream.cc on Tru64 UNIX > > If you provide a preprocessed testcase maybe he can. Otherwise patches > > welcome > > I guess. > > Done. Unfortunately, I won't be available for testing until September 1st. > > If this cannot be resolved, I'll certainly need quite some guidance to fix > it myself. I was also at conference till 1st. I will try to look at it now. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36851
[Bug c++/37008] Crash bug on a big c++ file
--- Comment #1 from livubuntu at lalescu dot ro 2008-08-02 07:30 --- Created an attachment (id=15996) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15996&action=view) The .ii file (archived with zip) The .ii file obtained by -save-temps command to g++ (archived with zip) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37008
[Bug c++/37008] New: Crash bug on a big c++ file
My open source application FET compiles OK with g++ 4.1.3. But with 4.2.3 it crashes on a bigger file named rules.cpp. My FET program is available at http://lalescu.ro/liviu/fet/ I have 1 GB of RAM, AMD dual core 4000+ The g++ version: [EMAIL PROTECTED]:~/t/fet-5.6.1$ gcc -v Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.2.3 (Ubuntu 4.2.3-2ubuntu7) The command and output error: [EMAIL PROTECTED]:~/t/fet-5.6.1$ make cd src/ && make -f Makefile make[1]: Entering directory `/home/goghi/t/fet/src' cd interface/ && make -f Makefile make[2]: Entering directory `/home/goghi/t/fet/src/interface' g++ -save-temps -c -pipe -fpermissive -O2 -D_REENTRANT -Wall -W -DQT_SHARED -DQT_NO_DEBUG -DQT_QT3SUPPORT_LIB -DQT3_SUPPORT -DQT_XML_LIB -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -I/usr/share/qt4/mkspecs/linux-g++ -I. -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtNetwork -I/usr/include/qt4/QtNetwork -I/usr/include/qt4/QtGui -I/usr/include/qt4/QtGui -I/usr/include/qt4/QtXml -I/usr/include/qt4/QtXml -I/usr/include/qt4/Qt3Support -I/usr/include/qt4/Qt3Support -I/usr/include/qt4 -I../engine -I../../tmp -I../../tmp -o ../../tmp/rules.o ../engine/rules.cpp g++: warning: -pipe ignored because -save-temps specified g++: Internal error: Killed (program cc1plus) Please submit a full bug report. See http://gcc.gnu.org/bugs.html> for instructions. For Debian GNU/Linux specific bug reporting instructions, see . make[2]: *** [../../tmp/rules.o] Error 1 make[2]: Leaving directory `/home/goghi/t/fet/src/interface' make[1]: *** [sub-interface-make_default] Error 2 make[1]: Leaving directory `/home/goghi/t/fet/src' make: *** [sub-src-make_default] Error 2 [EMAIL PROTECTED]:~/t/fet-5.6.1$ I'll attach also the .ii file. -- Summary: Crash bug on a big c++ file Product: gcc Version: 4.2.3 Status: UNCONFIRMED Severity: major Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: livubuntu at lalescu dot ro http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37008
