[Bug target/36722] ICE with inline asm in 64bit mode because of type size
--- Comment #3 from ubizjak at gmail dot com 2008-08-23 07:21 ---
(In reply to comment #2)
looks like a PR37191
No.
Register constraints in the testcase are just not what they look like.
=rax in fact specifies multiple constraints, and that includes:
r for general integer reg
a for rax
x for SSE reg
Similar for =rcx, but with rcx instead of rax.
So the correct asm would look like this:
void x(void)
{
unsigned long a, b;
asm volatile ( : =a (a), =c (b) : 0 ((unsigned long) 0x0));
}
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36722
[Bug target/36722] ICE with inline asm in 64bit mode because of type size
--- Comment #4 from schwab at suse dot de 2008-08-23 07:58 --- It's still an ice-on-invalid, and as such a valid bug. -- schwab at suse dot de changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36722
[Bug fortran/36534] Bogus: '__convert_s1_s4' at (1) is obsolescent in fortran 95
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|fxcoudert at gcc dot gnu dot|unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36534
[Bug fortran/35937] Wrong type for charlength of function
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|fxcoudert at gcc dot gnu dot|unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35937
[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c
--- Comment #31 from andreast at gcc dot gnu dot org 2008-08-23 08:17 --- /Volumes/development/gcc/head/objdir-x86_64/./gcc/cc1plus -fpreprocessed prims.ii -fPIC -feliminate-unused-debug-symbols -quiet -dumpbase prims.cc -mmacosx-version-min=10.5.4 -mtune=generic -auxbase-strip .libs/prims.o -g -O2 -Wswitch-enum -Wextra -Wall -version -fno-rtti -fnon-call-exceptions -fdollars-in-identifiers -fomit-frame-pointer -fno-common -o prims.s GNU C++ (GCC) version 4.4.0 20080822 (experimental) [trunk revision 139497] (x86_64-apple-darwin9) compiled by GNU C version 4.4.0 20080822 (experimental) [trunk revision 139497], GMP version 4.2.2, MPFR version 2.3.1. GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: d33cfb8d3b429a09faa5a0175497a6bb COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.5.4' '-shared-libgcc' '-B/Volumes/development/gcc/head/objdir-x86_64/./gcc' '-nostdinc++' '-L/Volumes/development/gcc/head/objdir-x86_64/x86_64-apple-darwin9/libstdc++-v3/src' '-L/Volumes/development/gcc/head/objdir-x86_64/x86_64-apple-darwin9/libstdc++-v3/src/.libs' '-B/Volumes/development/gcc/head/testbin-x86_64/x86_64-apple-darwin9/bin/' '-B/Volumes/development/gcc/head/testbin-x86_64/x86_64-apple-darwin9/lib/' '-isystem' '/Volumes/development/gcc/head/testbin-x86_64/x86_64-apple-darwin9/include' '-isystem' '/Volumes/development/gcc/head/testbin-x86_64/x86_64-apple-darwin9/sys-include' '-DHAVE_CONFIG_H' '-I.' '-I/Volumes/development/gcc/head/gcc/libjava' '-I./include' '-I./gcj' '-I/Volumes/development/gcc/head/gcc/libjava' '-Iinclude' '-I/Volumes/development/gcc/head/gcc/libjava/include' '-I/Volumes/development/gcc/head/gcc/libjava/classpath/include' '-Iclasspath/include' '-I/Volumes/development/gcc/head/gcc/libjava/classpath/native/fdlibm' '-I/Volumes/development/gcc/head/gcc/libjava/../boehm-gc/include' '-I../boehm-gc/include' '-I/Volumes/development/gcc/head/gcc/libjava/libltdl' '-I/Volumes/development/gcc/head/gcc/libjava/libltdl' '-I/Volumes/development/gcc/head/gcc/libjava/.././libjava/../gcc' '-I/Volumes/development/gcc/head/gcc/libjava/../zlib' '-I/Volumes/development/gcc/head/gcc/libjava/../libffi/include' '-I../libffi/include' '-fno-rtti' '-fnon-call-exceptions' '-fdollars-in-identifiers' '-Wswitch-enum' '-D_FILE_OFFSET_BITS=64' '-fomit-frame-pointer' '-Wextra' '-Wall' '-D_GNU_SOURCE' '-DPREFIX=/Volumes/development/gcc/head/testbin-x86_64' '-DTOOLEXECLIBDIR=/Volumes/development/gcc/head/testbin-x86_64/lib' '-DJAVA_HOME=/Volumes/development/gcc/head/testbin-x86_64' '-DBOOT_CLASS_PATH=/Volumes/development/gcc/head/testbin-x86_64/share/java/libgcj-4.4.0.jar' '-DJAVA_EXT_DIRS=/Volumes/development/gcc/head/testbin-x86_64/share/java/ext' '-DGCJ_ENDORSED_DIRS=/Volumes/development/gcc/head/testbin-x86_64/share/java/gcj-endorsed' '-DGCJ_VERSIONED_LIBDIR=/Volumes/development/gcc/head/testbin-x86_64/lib/gcj-4.4.0-10' '-DPATH_SEPARATOR=:' '-DECJ_JAR_FILE=/Volumes/development/gcc/head/testbin-x86_64/share/java/ecj.jar' '-DLIBGCJ_DEFAULT_DATABASE=/Volumes/development/gcc/head/testbin-x86_64/lib/gcj-4.4.0-10/classmap.db' '-DLIBGCJ_DEFAULT_DATABASE_PATH_TAIL=gcj-4.4.0-10/classmap.db' '-g' '-O2' '-MT' 'prims.lo' '-MD' '-MP' '-MF' '.deps/prims.Tpo' '-c' '-fno-common' '-DPIC' '-v' '-save-temps' '-o' '.libs/prims.o' '-mtune=generic' /Volumes/development/gcc/head/objdir-x86_64/./gcc/as -arch x86_64 -force_cpusubtype_ALL -o .libs/prims.o prims.s prims.s:unknown:Undefined symbol: __Z19_Jv_AllocPtrFreeObjiPN4java4lang5ClassE can't be a weak_definition prims.s:unknown:Undefined symbol: __Z12_Jv_AllocObjiPN4java4lang5ClassE can't be a weak_definition -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37170
[Bug c++/37208] C++0x deleted functions and SFINAE
--- Comment #2 from paolo dot carlini at oracle dot com 2008-08-23 09:31 --- Let's CC Jason... -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||jason at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37208
[Bug middle-end/37174] [4.4 Regression] ICE: in vinfo_for_stmt, at tree-vectorizer.h:546
--- Comment #7 from irar at gcc dot gnu dot org 2008-08-23 10:43 --- Subject: Bug 37174 Author: irar Date: Sat Aug 23 10:42:34 2008 New Revision: 139508 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=139508 Log: PR tree-optimization/37174 * tree-vect-analyze.c (vect_get_and_check_slp_defs): Check that the def stmt is a part of the loop before accessing its stmt_vec_info. Added: trunk/gcc/testsuite/g++.dg/vect/pr37174.cc Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-analyze.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37174
[Bug middle-end/37151] [4.4 Regression] ICE with -fprofile-use and -ftree-loop-linear
--- Comment #3 from burnus at gcc dot gnu dot org 2008-08-23 11:16 --- Platform: x86-64-linux (openSUSE Factory on AMD Athlon64). However, I cannot reproduce it anymore with the current trunk - Close as WORKSFORME. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37151
[Bug middle-end/37209] New: [4.4 Regression] ICE in vinfo_for_stmt, at tree-vectorizer.h:546
Works here with: 2008-08-19-r139224 fails here with: 2008-08-20-r139252 (Note both had some patches applied, but looking at the diffs to the trunk at that time, they should not affect the failure.) $ gfortran -O3 test.f90 test.f90: In function 'euler': test.f90:1: internal compiler error: in vinfo_for_stmt, at tree-vectorizer.h:546 SUBROUTINE euler(mrot,amat,alpha,beta,gamma) IMPLICIT NONE INTEGER, INTENT(IN) :: mrot(3,3) REAL, INTENT(IN) :: amat(3,3) REAL, INTENT(OUT) :: alpha,beta,gamma INTEGER :: det,a1,a2,n REAL :: mprop(3,3),amatinv(3,3),detr REAL :: pi,sina,sinb,sinc,cosa,cosb,cosc pi = atan(1.0)*4.0 det= mrot(1,1)*mrot(2,2)*mrot(3,3) + mrot(1,2)*mrot(2,3)*mrot(3,1) + mrot(2,1)*mrot(3,2)*mrot(1,3) - mrot(1,3)*mrot(2,2)*mrot(3,1) - mrot(2,3)*mrot(3,2)*mrot(1,1) - mrot(2,1)*mrot(1,2)*mrot(3,3) mprop=REAL(det)*MATMUL(amat,MATMUL(REAL(mrot),amatinv)) cosb = mprop(3,3) sinb = 1.00 - cosb*cosb sinb = max(sinb,0.00) sinb = sqrt(sinb) IF ( abs(sinb).LT.1.0e-5 ) gamma = 0.0 END SUBROUTINE -- Summary: [4.4 Regression] ICE in vinfo_for_stmt, at tree- vectorizer.h:546 Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: ice-on-invalid-code Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37209
[Bug middle-end/37209] [4.4 Regression] ICE in vinfo_for_stmt, at tree-vectorizer.h:546
--- Comment #1 from irar at il dot ibm dot com 2008-08-23 11:31 --- I think it's a duplicate of pr37174. I've just committed the fix. Ira -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37209
[Bug c++/13358] long long and C++ do not mix well
--- Comment #18 from manu at gcc dot gnu dot org 2008-08-23 11:31 --- I cannot reproduce the warning in C or C++. It seems this got fixed silently. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13358
[Bug middle-end/37174] [4.4 Regression] ICE: in vinfo_for_stmt, at tree-vectorizer.h:546
--- Comment #8 from irar at il dot ibm dot com 2008-08-23 11:32 --- Fixed. -- irar at il dot ibm dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37174
[Bug middle-end/37209] [4.4 Regression] ICE in vinfo_for_stmt, at tree-vectorizer.h:546
--- Comment #2 from burnus at gcc dot gnu dot org 2008-08-23 11:41 --- Solved by the patch for PR 37174. *** This bug has been marked as a duplicate of 37174 *** -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37209
[Bug middle-end/37174] [4.4 Regression] ICE: in vinfo_for_stmt, at tree-vectorizer.h:546
--- Comment #9 from burnus at gcc dot gnu dot org 2008-08-23 11:41 --- *** Bug 37209 has been marked as a duplicate of this bug. *** -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37174
[Bug other/37210] New: Prohibit Default Builds in the GCC Source Tree
The gcc configuration instructions *highly* recommend building outside the gcc source tree, and often, following the gcc-help list, I see that doing so causes problems. I propose that the build process be modified so as to default to *failing* to build under those circumstances. Add a configuration variable, if necessary, to allow such a build. In the meantime, I recommend that the highly recommendation be changed to some more mandatory language unless the user is a gcc developer. -- Summary: Prohibit Default Builds in the GCC Source Tree Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tom dot browder at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37210
[Bug c++/13358] long long and C++ do not mix well
--- Comment #19 from manu at gcc dot gnu dot org 2008-08-23 12:26 --- OK, sorry, I needed -m32 in the command line to reproduce it. Is there a consensus here? It seems too pedantic to warn for something that GCC can handle perfectly well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13358
[Bug c++/33736] error: integer constant is too large for �long� type incorrect for C++0x
--- Comment #2 from manu at gcc dot gnu dot org 2008-08-23 12:37 --- I think this is a duplicate of 13358. The warning should be conditional on Wlong-long and Wlong-long should be disabled in -std=c++0x (in fact it is already). I am testing a patch btw. *** This bug has been marked as a duplicate of 13358 *** -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33736
[Bug c++/13358] long long and C++ do not mix well
--- Comment #20 from manu at gcc dot gnu dot org 2008-08-23 12:37 --- *** Bug 33736 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13358
[Bug c/36299] spurious and undocumented warning with -Waddress for a == 0 when a is an array
--- Comment #2 from manu at gcc dot gnu dot org 2008-08-23 12:53 --- Andrew, how could we detect that it is a decayed array? I think we would like to warn for if (a == (void *) 0) but not for if ((void *)a == 0) or even if possible not for if (a[0] == 0) Vincent, this warning was added on purpose, because probably someone requested it. I don't see that it is very different from the documented case of using the address of a function in a conditional. You should be able to work-around the macro case by casting the array to (char *) or perhaps casting to (void *) ? That said, we would like to not warn within macros for a wide range of warnings but we don't have the infrastructure to do that yet. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36299
[Bug fortran/37201] ICE
--- Comment #1 from tkoenig at gcc dot gnu dot org 2008-08-23 13:07 --- Confirmed. Reduced test case: program test INTERFACE FUNCTION cdir() BIND(C,name=cdir) RESULT(r) CHARACTER(kind=1) :: r END FUNCTION END INTERFACE WRITE(*,*) ICHAR(cdir()) END PROGRAM -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||32630 nThis|| Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC host triplet|i686 GNU/Linux, kernel | |2.6.22.1| Last reconfirmed|-00-00 00:00:00 |2008-08-23 13:07:50 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37201
[Bug fortran/37131] inline matmul for small matrix sizes
--- Comment #4 from tkoenig at gcc dot gnu dot org 2008-08-23 13:18 --- Created an attachment (id=16134) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16134action=view) test case Actually, the test cases were a bit unfair, because the middle-end decided not to calculate the values of c that were never used. Attached is a better test case. Timings on x86_64-unknown-linux-gnu: matmul =12.840802 s subroutine without explicit interface: 0.88805580 s subroutine with explicit interface: 0.87605572 s inline with sum 2.0721283 s While inlining is still much better than matmul, a hand-rolled 3*3 subroutine is much faster overall, which I find a bit surprising. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37131
[Bug c/7543] no warning for always-false if (!a 0x4) bitwise and on boolean value
--- Comment #13 from manu at gcc dot gnu dot org 2008-08-23 13:49 --- (In reply to comment #8) Thanks. (By the way, if there a gcc person interested in such a list, please contact me.) I am interested in such a list. Thanks in advance. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7543
[Bug fortran/37203] Check ORDER= of RESHAPE
--- Comment #1 from tkoenig at gcc dot gnu dot org 2008-08-23 14:11 --- Confirmed. We should also have a run-time check for this: [EMAIL PROTECTED]:/tmp$ gfortran -fbounds-check foo.f90 [EMAIL PROTECTED]:/tmp$ ./a.out 1 6 2 0 3 0 4 0 5 0 *** glibc detected *** free(): invalid next size (fast): 0x00508950 *** Aborted [EMAIL PROTECTED]:/tmp$ -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added CC||tkoenig at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-08-23 14:11:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37203
[Bug other/35648] -Wall includes -Wwrite-strings
--- Comment #3 from manu at gcc dot gnu dot org 2008-08-23 15:37 --- Subject: Bug 35648 Author: manu Date: Sat Aug 23 15:36:32 2008 New Revision: 139517 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=139517 Log: 2008-08-23 Manuel Lopez-Ibanez [EMAIL PROTECTED] PR 35648 * doc/invoke.texi (Wwrite-strings): Clarify description. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/invoke.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35648
[Bug other/35648] -Wall includes -Wwrite-strings
--- Comment #4 from manu at gcc dot gnu dot org 2008-08-23 15:40 --- Fixed in GCC 4.4. Thanks for the report. -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35648
[Bug c++/31246] Strange -Wunreachable-code warning with _GLIBCXX_DEBUG
--- Comment #18 from manu at gcc dot gnu dot org 2008-08-23 15:59 ---
(In reply to comment #0)
Compiling the following with -Wunreachable-code -D_GLIBCXX_DEBUG
--
#include vector
int main()
{
std::vectorint::iterator a;
}
--
produces the warning :
I cannot reproduce this in GCC 4.4.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31246
[Bug c++/31246] Strange -Wunreachable-code warning with _GLIBCXX_DEBUG
--- Comment #19 from manu at gcc dot gnu dot org 2008-08-23 16:01 ---
(In reply to comment #4)
Here is a minimal code example:
#include new
int* get_ptr(void* ptr)
{
return new(ptr) int();
}
I can reproduce this, though.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31246
[Bug c++/31246] Strange -Wunreachable-code warning with _GLIBCXX_DEBUG
--- Comment #20 from manu at gcc dot gnu dot org 2008-08-23 16:13 --- For testcase in comment #4 I get 2 warnings now: home/manuel/test2/src/gcc/testsuite/g++.dg/warn/pr31246-2.C: In function int* get_ptr(void*): /home/manuel/test2/src/gcc/testsuite/g++.dg/warn/pr31246-2.C:8: warning: will never be executed /home/manuel/test2/src/libstdc++-v3/libsupc++/new: In function void* operator new(size_t, void*): /home/manuel/test2/src/libstdc++-v3/libsupc++/new:105: warning: will never be executed libsupc++/new does not contain #pragma GCC system_headers, so even using warning_at doesn't suppress the warning. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31246
[Bug c++/31246] Strange -Wunreachable-code warning with _GLIBCXX_DEBUG
--- Comment #21 from manu at gcc dot gnu dot org 2008-08-23 16:21 --- If gimple stmts do not have the equivalent of DECL_ARTIFICIAL, then the C++ front-end should use gimple_set_no_warning(stmt) when generating such constructs. So, anyone knows where this comes from? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31246
[Bug fortran/37201] ICE in in gfc_conv_string_parameter
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2008-08-23 16:54 --- Needed a little better summary -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Summary|ICE |ICE in in ||gfc_conv_string_parameter http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37201
[Bug fortran/37211] New: TRANSFER to characters: Size checking
For the following gfortran should print: Intrinsic TRANSFER at %L has partly undefined result: source size %ld result size %ld but this does not work. character(len=20) :: str str = transfer(10,str) end Ditto for character( KIND=4 ,len=20) -- Summary: TRANSFER to characters: Size checking Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37211
[Bug fortran/37212] New: TRANSFER: Simplify array argument
In the following program, transfer could be simplified at compile time, however, this does not happen. Additionally is the following is not needed: - Call to _gfortran_internal_pack. There is no way the array could be noncontiguous. - Call to _gfortran_internal_unpack. There is no need to unpack the temporary array, especially not if it is only there as src argument of memmove. character(len=4,kind=4) :: str str = transfer([int(z'039f'),int(z'03cd'),int(z'03c7'), int(z'30b8') ], str) end -- Summary: TRANSFER: Simplify array argument Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37212
[Bug middle-end/37161] [4.4 Regression]: Revision 139225 caused gfortran.dg/vect/pr33301.f -O
--- Comment #2 from irar at gcc dot gnu dot org 2008-08-23 17:05 --- Subject: Bug 37161 Author: irar Date: Sat Aug 23 17:04:12 2008 New Revision: 139518 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=139518 Log: PR tree-optimization/37161 * tree-vectorizer.h (vect_get_smallest_scalar_type): Declare. * tree-vect-analyze.c (vect_get_smallest_scalar_type): New function. (vect_determine_vectorization_factor): Move the scalar type retrieval to vect_get_smallest_scalar_type. (vect_build_slp_tree): Call vect_get_smallest_scalar_type to get scalar type. Remove redundant computation. * tree-vect-transform.c (vect_get_constant_vectors): Add argument. (vect_get_slp_defs): Take the type of RHS into account if necessary by calling vect_get_smallest_scalar_type. Call vect_get_constant_vectors with additional argument. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-vect-analyze.c trunk/gcc/tree-vect-transform.c trunk/gcc/tree-vectorizer.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37161
[Bug c++/31246] Strange -Wunreachable-code warning with _GLIBCXX_DEBUG
--- Comment #22 from manu at gcc dot gnu dot org 2008-08-23 17:24 --- In addition, __cxa_call_unexpected should probably have both TREE_NO_WARNING and DECL_ARTIFICIAL set but this is orthogonal because at the point of the warning we should not be testing that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31246
[Bug tree-optimization/36218] [4.2/4.3/4.4 regression] VRP causes stack overflow while building libgcj
--- Comment #16 from aaronavay62 at aaronwl dot com 2008-08-23 18:06 --- (In reply to comment #15) This should be fixed on the trunk by 2008-08-20 Richard Guenther [EMAIL PROTECTED] can someone verify this? Thanks. Yes and no. On revision 139510 (2008-08-23), the compilation of cipher.lo is successful in a normal build, so I presume that the VRP problem has been fixed. Yay! However, there is a new (since April 2008) stack overflow now in HTML_401F.lo. This one does not seem to be VRP-related, as -fno-tree-vrp does not seem to help. It does, however, compile with -O0. Here is the backtrace: #0 0x00a61805 in htab_find_slot_with_hash (htab=0x5745038, element=0x83060, hash=13718576, insert=INSERT) at ../../svn/libiberty/hashtab.c:610 #1 0x00a61a82 in htab_find_slot (htab=0x5745038, element=0x83060, insert=INSERT) at ../../svn/libiberty/hashtab.c:678 #2 0x0076562a in set_livein_block (var=0x68aa180, bb=0x54c3dc0) at ../../svn/gcc/tree-into-ssa.c:503 #3 0x00766ae1 in prepare_block_for_update (bb=0x54c3dc0, insert_phi_p=1 '\001') at ../../svn/gcc/tree-into-ssa.c:2364 #4 0x00766cf0 in prepare_block_for_update (bb=0x54c3d00, insert_phi_p=1 '\001') at ../../svn/gcc/tree-into-ssa.c:2450 #5 0x00766cf0 in prepare_block_for_update (bb=0x54c3c00, insert_phi_p=1 '\001') at ../../svn/gcc/tree-into-ssa.c:2450 ... #10851 0x00766cf0 in prepare_block_for_update (bb=0x4f63600, insert_phi_p=1 '\001') at ../../svn/gcc/tree-into-ssa.c:2450 #10852 0x00766cf0 in prepare_block_for_update (bb=0x4f63580, insert_phi_p=1 '\001') at ../../svn/gcc/tree-into-ssa.c:2450 #10853 0x00766cf0 in prepare_block_for_update (bb=0x4f63500, insert_phi_p=1 '\001') at ../../svn/gcc/tree-into-ssa.c:2450 #10854 0x00769e62 in update_ssa (update_flags=2048) at ../../svn/gcc/tree-into-ssa.c:3230 #10855 0x00762164 in compute_may_aliases () at ../../svn/gcc/tree-ssa-alias.c:1842 #10856 0x0052644d in execute_function_todo (data=0x11) at ../../svn/gcc/passes.c:943 #10857 0x005265a0 in do_per_function ( callback=0x52629c execute_function_todo, data=0x11) at ../../svn/gcc/passes.c:837 #10858 0x00526670 in execute_todo (flags=1048577) at ../../svn/gcc/passes.c:1021 #10859 0x00526954 in execute_one_pass (pass=0xb05150) at ../../svn/gcc/passes.c:1297 #10860 0x00526b48 in execute_pass_list (pass=0xb05150) at ../../svn/gcc/passes.c:1323 #10861 0x00526b5b in execute_pass_list (pass=0xb04f10) at ../../svn/gcc/passes.c:1324 #10862 0x00759fb0 in tree_rest_of_compilation (fndecl=0x28c6c80) at ../../svn/gcc/tree-optimize.c:418 #10863 0x0058796f in cgraph_expand_function (node=0x47acc80) at ../../svn/gcc/cgraphunit.c:1039 #10864 0x0058968a in cgraph_optimize () at ../../svn/gcc/cgraphunit.c:1101 #10865 0x00443615 in java_parse_file (set_yydebug=0) at ../../svn/gcc/java/jcf-parse.c:1961 #10866 0x0047907d in toplev_main (argc=32, argv=0x31934e8) at ../../svn/gcc/toplev.c:959 #10867 0x0040124b in __mingw_CRTStartup () #10868 0x00401298 in mainCRTStartup () Should I open a new PR for this different stack overflow, and close this one? I still have not had a chance to see why Joseph's change to LDFLAGS to make MinGW use the same stack allocation as Linux when building GCC does not propagate into libjava. Once that is fixed, this entire catagory of MinGW-specific problems should go away. So alternately we could close this one, and open a new one just for the LDFLAGS issue. -- aaronavay62 at aaronwl dot com changed: What|Removed |Added Last reconfirmed|2008-07-14 08:03:23 |2008-08-23 18:06:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36218
[Bug c++/37004] [C++ only] Wconversion warns for short y = 0x7fff; short z = (short) x y;
--- Comment #3 from manu at gcc dot gnu dot org 2008-08-23 18:06 --- In C: /* Wrapper around c_common_type that is used by c-common.c and other front end optimizations that remove promotions. ENUMERAL_TYPEs are allowed here and are converted to their compatible integer types. BOOLEAN_TYPEs are allowed here and return either boolean_type_node or preferably a non-Boolean type as the common type. */ tree common_type (tree t1, tree t2) In C++: /* Return the common type of two types. We assume that comptypes has already been done and returned 1; if that isn't so, this may crash. This is the type for the result of most arithmetic operations if the operands have the given two types. */ tree common_type (tree t1, tree t2) They are not the same. C++ performs integral promotion, C doesn't. Which is a waste of time in C++ because everywhere common_type is called, integral promotions have been performed already. Duplicationg type_after_usual_arithmetic_conversions with a variant that does not perform promotions fixes the problem. But there should be a more elegant way to handle this than just duplicating the whole function... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37004
[Bug fortran/37025] ICE with TRANSFER to non-default-kind character: transfer(int(z'bde4'),4_'a')
--- Comment #1 from burnus at gcc dot gnu dot org 2008-08-23 18:13 --- Subject: Bug 37025 Author: burnus Date: Sat Aug 23 18:12:30 2008 New Revision: 139520 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=139520 Log: 2008-08-23 Tobias Burnus [EMAIL PROTECTED] PR fortran/37025 * target-memory.c (gfc_interpret_character): Support kind=4 characters. 2008-08-23 Tobias Burnus [EMAIL PROTECTED] PR fortran/37025 * gfortran.dg/widechar_8.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/widechar_8.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/target-memory.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37025
[Bug c/30260] Enumeration types and enumeration constants erroneously given unsigned types
--- Comment #6 from manu at gcc dot gnu dot org 2008-08-23 18:20 ---
In GCC 4.4 we produce the same output independently of -pedantic:
(a 0) = 1, (A2 0) = 1, A{1,2} = +0, -1
(b 0) = 0, (B2 0) = 0, B{1,2} = +0, -1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30260
[Bug fortran/37025] ICE with TRANSFER to non-default-kind character: transfer(int(z'bde4'),4_'a')
--- Comment #2 from burnus at gcc dot gnu dot org 2008-08-23 18:21 --- FIXED on the trunk (4.4). -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37025
[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c
--- Comment #32 from hp at gcc dot gnu dot org 2008-08-23 18:38 --- Thanks, I got everything I need. The problem seen for the Darwin bootstrap is caused not by the output_operand call to assemble_external, but by another call, in cp/decl2.c:mark_used. Plainly treating that (as now) the same as the assemble_external call from output_operand, causes lots of actually not used (perhaps inlined, but not referenced) functions to be marked as weak. You can see this diffing e.g. prims.s for unpatched 139232 and 139233 for x86_64-linux but you don't see it for unpatched darwin because of the assemble_external call being masked by the #ifdef. For GNU/Linux, having random .weak annotations for unreferenced and undefined symbols apparently has no visible effect. The reason that the Darwin assembler complains when it sees some of these, is that they're coupled with annotations specifically for weak *definitions* for one reason or another (without a matching symbol definition), while with more common targets the weak annotations for references and definitions look the same, the absence/presence of the actual definition defines what weakness type it is. I'm not sure why there are assemble_external calls all over and from language front-ends; there should be only one in output_operand (for code) and one where data is output. Come to think of it, they shouldn't be there either, but in expand, so we don't have to play target-specific tricks. Not sure whether that change would fit in this PR, or if I should go with just remove or gate the bogus and redundant assemble_external calls. Bah, I guess I should just have asked for revert of 139233; that and related earlier changes obviously weren't fit for trunk. Ok, one more try. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37170
[Bug c++/31246] Strange -Wunreachable-code warning with _GLIBCXX_DEBUG
--- Comment #23 from paolo dot carlini at oracle dot com 2008-08-23 18:43 --- To be clear, there are no #pragma GCC system_header at all in the entire libsupc++ directory. I hope we don't have to begin... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31246
[Bug c++/31246] Strange -Wunreachable-code warnings
--- Comment #24 from paolo dot carlini at oracle dot com 2008-08-23 18:45 --- I'm going to tweak a bit the Summary, seems misleading now. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Summary|Strange -Wunreachable-code |Strange -Wunreachable-code |warning with _GLIBCXX_DEBUG |warnings http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31246
[Bug c++/31246] -Wunreachable-code warnings for compiler-generated code
--- Comment #25 from manu at gcc dot gnu dot org 2008-08-23 18:50 --- This looks clearer to me. Maybe Jason or Mark have some idea where this code is generated. It should be clear that it is compiler-generated and we can set DECL_ARTIFICIAL or TREE_NO_WARNING. Then we just have to make sure to propagate that. And finally, check it before warning. -- manu at gcc dot gnu dot org changed: What|Removed |Added Summary|Strange -Wunreachable-code |-Wunreachable-code warnings |warnings|for compiler-generated code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31246
[Bug fortran/37076] Concatenation of KIND=4 strings with KIND=4 parameters fails
--- Comment #1 from burnus at gcc dot gnu dot org 2008-08-23 18:51 --- FIXED on the trunk (4.4). -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37076
[Bug fortran/37076] Concatenation of KIND=4 strings with KIND=4 parameters fails
--- Comment #2 from burnus at gcc dot gnu dot org 2008-08-23 18:51 --- Subject: Bug 37076 Author: burnus Date: Sat Aug 23 18:49:43 2008 New Revision: 139521 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=139521 Log: 2008-08-23 Tobias Burnus [EMAIL PROTECTED] PR fortran/37076 * arith.c (gfc_arith_concat): Fix concat of kind=4 strings. 2008-08-23 Tobias Burnus [EMAIL PROTECTED] PR fortran/37076 * gfortran.dg/widechar_9.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/widechar_9.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/arith.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37076
[Bug fortran/37201] ICE in in gfc_conv_string_parameter
--- Comment #3 from burnus at gcc dot gnu dot org 2008-08-23 19:13 --- *** Bug 37205 has been marked as a duplicate of this bug. *** -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37201
[Bug fortran/37205] BIND(C): Character FUNCTION foo() - ICE
--- Comment #1 from burnus at gcc dot gnu dot org 2008-08-23 19:13 --- Actually, this PR was first ... *** This bug has been marked as a duplicate of 37201 *** -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37205
[Bug fortran/37201] ICE in in gfc_conv_string_parameter
--- Comment #4 from burnus at gcc dot gnu dot org 2008-08-23 19:45 ---
Actually, removing the assert
--- /home/tob/projects/gcc/gcc/fortran/trans-expr.c (Revision 139520)
+++ /home/tob/projects/gcc/gcc/fortran/trans-expr.c
@@ -4008,2 +4008,0 @@ gfc_conv_string_parameter (gfc_se * se)
- gcc_assert (se-string_length
- TREE_CODE (TREE_TYPE (se-string_length)) == INTEGER_TYPE);
is enough for assignments. Proof:
str[1]{lb: 1 sz: 1} = cdir (); ! str = cdir()
i = (integer(kind=4)) cdir (); ! i = ichar(cdir())
TODO: Come up with a better assert which works also in this case.
* * *
For I/O one also needs the following:
--- trans-io.c (Revision 139521)
+++ trans-io.c
@@ -2071,2 +2071,6 @@ transfer_expr (gfc_se * se, gfc_typespec
- gcc_assert (TREE_CODE (TREE_TYPE (tmp)) == ARRAY_TYPE);
- arg2 = TYPE_MAX_VALUE (TYPE_DOMAIN (TREE_TYPE (tmp)));
+
+ /* BIND(C) function return value. */
+ if (TREE_CODE (TREE_TYPE (tmp)) != ARRAY_TYPE)
+ arg2 = build_int_cst (gfc_charlen_type_node, 1);
+ else
+ arg2 = TYPE_MAX_VALUE (TYPE_DOMAIN (TREE_TYPE (tmp)));
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37201
[Bug c/36299] spurious and undocumented warning with -Waddress for a == 0 when a is an array
--- Comment #3 from vincent at vinc17 dot org 2008-08-23 20:00 ---
(In reply to comment #2)
this warning was added on purpose, because probably someone requested it. I
don't see that it is very different from the documented case of using the
address of a function in a conditional.
The documentation should be improved anyway (the word suspicious is very
subjective).
You should be able to work-around the macro case by casting the array to (char
*) or perhaps casting to (void *) ?
Yes, this makes sense. Perhaps this should be documented.
That said, we would like to not warn within
macros for a wide range of warnings but we don't have the infrastructure to do
that yet.
How about something like __extension__, e.g. __no_warnings__ would disable the
warnings for the following statement or expression? If expression, one could
still use __no_warnings__ with ({ ... }). Keywords for individual warnings or
warning groups would even be better. At the same time, it would be nice to have
some macro defined, declaring that such a keyword is available (that would be
much better than testing the GCC version).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36299
[Bug target/37094] [4.4 Regression] Ada build broken for i586
--- Comment #6 from hubicka at gcc dot gnu dot org 2008-08-23 20:03 --- Subject: Bug 37094 Author: hubicka Date: Sat Aug 23 20:02:08 2008 New Revision: 139522 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=139522 Log: PR target/37094 * i386.c (standard_80387_constant_p): Use optimize_size. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37094
[Bug target/31897] [4.3 Regression] 30% speed regression with -m32 on Opteron with rnflow
--- Comment #14 from ubizjak at gmail dot com 2008-08-23 20:07 --- Looking at http://users.physik.fu-berlin.de/~tburnus/gcc-trunk/benchmark/, it looks that the problem was mysteriously fixed in recent mainline. -- ubizjak at gmail dot com changed: What|Removed |Added Summary|[4.3/4.4 Regression] 30%|[4.3 Regression] 30% speed |speed regression with -m32 |regression with -m32 on |on Opteron with rnflow |Opteron with rnflow http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31897
[Bug c++/37213] New: Declaration/expression ambiguity resolution does not extend beyond initializer
When compiling the following program:
struct S {int z;};
typedef S* (*FuncType)(int,int);
int x,y;
S* a() {
FuncType(a)(x,y)-z = 0; // treated as declaration
return 0;
}
This is the result:
t.cpp: In function 'S* a()':
t.cpp:5: error: initializer expression list treated as compound expression
t.cpp:5: error: invalid conversion from 'int' to 'S* (*)(int, int)'
t.cpp:5: error: expected ',' or ';' before '-' token
Shouldn't GCC examine '-' after 'FuncType(a)(x,y)' and conclude that the
statement is an expression instead of a declaration ?
--
Summary: Declaration/expression ambiguity resolution does not
extend beyond initializer
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: akyrtzi at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37213
[Bug target/37094] [4.4 Regression] Ada build broken for i586
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2008-08-23 21:08 --- The Ada compiler builds again. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37094
[Bug c/37214] New: Weird operation reordering when compiling with -O3/O2 leading to errornous result
2 instruction are inverted in the compiled code so the result is wrong.
The compilation is ok when using no optimization, but the problem happen with
-O3 and -O2.
Here is the function to compile:
void test2(uint32_t* source, uint32_t* dest)
{
*dest=*source;
*(uint16_t*)dest = (*(uint16_t*)dest)1;
}
You could guess that the shift should happen after the copy.
Here is what you get when dissassembling:
00400500 test2:
400500: 66 d1 26shlw (%rsi)
400503: 8b 07 mov(%rdi),%eax
400505: 89 06 mov%eax,(%rsi)
400507: c3 retq
400508: 0f 1f 84 00 00 00 00nopl 0x0(%rax,%rax,1)
40050f: 00
Here is the information on my configuration:
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)
/usr/lib/gcc/x86_64-linux-gnu/4.2.3/cc1 -E -quiet -v test.c -mtune=generic
-Wall -O2 -fpch-preprocess -o test.i
ignoring nonexistent directory /usr/local/include/x86_64-linux-gnu
ignoring nonexistent directory
/usr/lib/gcc/x86_64-linux-gnu/4.2.3/../../../../x86_64-linux-gnu/include
ignoring nonexistent directory /usr/include/x86_64-linux-gnu
#include ... search starts here:
#include ... search starts here:
/usr/local/include
/usr/lib/gcc/x86_64-linux-gnu/4.2.3/include
/usr/include
End of search list.
/usr/lib/gcc/x86_64-linux-gnu/4.2.3/cc1 -fpreprocessed test.i -quiet -dumpbase
test.c -mtune=generic -auxbase test -O2 -Wall -version -fstack-protector
-fstack-protector -o test.s
GNU C version 4.2.3 (Ubuntu 4.2.3-2ubuntu7) (x86_64-linux-gnu)
compiled by GNU C version 4.2.3 (Ubuntu 4.2.3-2ubuntu7).
GGC heuristics: --param ggc-min-expand=98 --param ggc-min-heapsize=128576
Compiler executable checksum: 04286fa30e0b1c736cc2bb914c15518c
test.c: In function #8216;main#8217;:
test.c:67: warning: implicit declaration of function #8216;srand#8217;
as --traditional-format -V -Qy -o test.o test.s
GNU assembler version 2.18.0 (x86_64-linux-gnu) using BFD version (GNU Binutils
for Ubuntu) 2.18.0.20080103
/usr/lib/gcc/x86_64-linux-gnu/4.2.3/collect2 --eh-frame-hdr -m elf_x86_64
--hash-style=both -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o test
/usr/lib/gcc/x86_64-linux-gnu/4.2.3/../../../../lib/crt1.o
/usr/lib/gcc/x86_64-linux-gnu/4.2.3/../../../../lib/crti.o
/usr/lib/gcc/x86_64-linux-gnu/4.2.3/crtbegin.o
-L/usr/lib/gcc/x86_64-linux-gnu/4.2.3 -L/usr/lib/gcc/x86_64-linux-gnu/4.2.3
-L/usr/lib/gcc/x86_64-linux-gnu/4.2.3/../../../../lib -L/lib/../lib
-L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/4.2.3/../../.. test.o -lgcc
--as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed
/usr/lib/gcc/x86_64-linux-gnu/4.2.3/crtend.o
/usr/lib/gcc/x86_64-linux-gnu/4.2.3/../../../../lib/crtn.o
--
Summary: Weird operation reordering when compiling with -O3/O2
leading to errornous result
Product: gcc
Version: 4.2.3
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: cuerob at free dot fr
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37214
[Bug preprocessor/37215] New: ICE on 'gcc -E -dM -fpreprocessed - /dev/null'
Executing 'gcc -E -dM -fpreprocessed - /dev/null' gives: stdin:1: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Environment: System: Linux alpha2 2.6.26 #1 Sun Jul 20 12:35:52 CEST 2008 x86_64 AMD Athlon(tm) 64 Processor 2800+ AuthenticAMD GNU/Linux Architecture: x86_64 host: x86_64-unknown-linux-gnu build: x86_64-unknown-linux-gnu target: x86_64-unknown-linux-gnu configured with: ../configure --prefix=/usr --enable-shared --enable-languages=c,c++,fortran,objc,obj-c++,treelang --enable-threads=posix --mandir=/usr/share/man --enable-__cxa_atexit --disable-multilib --libdir=/usr/lib --libexecdir=/usr/lib --enable-clocale=gnu --disable-libstdcxx-pch --with-tune=generic How-To-Repeat: Just run 'gcc -E -dM -fpreprocessed - /dev/null'. -- Summary: ICE on 'gcc -E -dM -fpreprocessed - /dev/null' Product: gcc Version: 3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ivan dot stankovic at fer dot hr GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37215
[Bug c/37216] New: Invalid XMM instructions generated with -O3
GCC generates an XMM instruction with a memory operand not 16-byte aligned as
it should be (i think), this generates a segmentation fault when run.
Input file: (test.c)
-
int iarr[64];
int iint = 0;
int main() {
int i;
for(i=0;i64;i++) {
iarr[i] = -2;
}
return 0;
}
-
Output of gcc -v:
Using built-in specs.
Target: i686-pc-cygwin
Configured with: ../source-4.3.1/configure --prefix=/usr/src/gcc/prefix-4.3.1
--enable-languages=c,c++ --disable-nls --without-included-gettext
--enable-version-specific-runtime-libs --enable-threads=posix
--disable-win32-registry
Thread model: posix
gcc version 4.3.1 (GCC)
Command used to compile:
/usr/src/gcc/prefix-4.3.1/bin/gcc test.c -o test.exe -march=core2 -O3
CPU: Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz
Offending instruction: 'movdqa %xmm0,0x403024'
--
Summary: Invalid XMM instructions generated with -O3
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: simon dot sasburg at gmail dot com
GCC build triplet: i686-pc-cygwin
GCC host triplet: i686-pc-cygwin
GCC target triplet: i686-pc-cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216
[Bug c/37214] Weird operation reordering when compiling with -O3/O2 leading to errornous result
--- Comment #1 from schwab at suse dot de 2008-08-23 23:07 --- You are violating the C/C++ aliasing rules. *** This bug has been marked as a duplicate of 21920 *** -- schwab at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37214
[Bug c/21920] aliasing violations
--- Comment #129 from schwab at suse dot de 2008-08-23 23:07 --- *** Bug 37214 has been marked as a duplicate of this bug. *** -- schwab at suse dot de changed: What|Removed |Added CC||cuerob at free dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21920
[Bug bootstrap/25502] I64d format Werror problem in build
--- Comment #19 from aaronavay62 at aaronwl dot com 2008-08-24 01:17 --- Kai, I'm assigning this to you because you said on IRC a month or two ago that you were working on a patch for this. I've been working around this with a local patch that adds __extension__ everywhere that needs it. -- aaronavay62 at aaronwl dot com changed: What|Removed |Added AssignedTo|aaronavay62 at aaronwl dot |ktietz at gcc dot gnu dot |com |org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25502
[Bug c++/37217] New: ICE on Valid Code
This code has been working forever: $ g++ -v Using built-in specs. Target: i686-pc-cygwin Configured with: /cygdrive/f/Home/cvsroot/gcc/configure --verbose --enable-threads --disable-nls --disable-win32-registry --enable-languages=c,c++ Thread model: posix gcc version 4.4.0 20080823 (experimental) (GCC) [EMAIL PROTECTED] ~/PD $ uname -a CYGWIN_NT-5.1 MCKELVEY-XP 1.5.25(0.156/4/2) 2008-06-12 19:34 i686 Cygwin $ g++ -c -g -fno-elide-constructors -DUSE_MUTEX=1 -pedantic-errors -Werror -ansi -fno-common -Wall -Wold-style-cast -Wsign-promo -Wpointer-arith -Wundef -Wwrite-strings -Winvalid-pch -Woverloaded-virtual -Wcast-qual -Wextra -Wredundant-decls -Wshadow -Wcast-align -Wcomment -fstrict-aliasing -Winit-self -Wmissing-include-dirs -Wswitch-default -Wswitch-enum -Wlogical-op -Wconversion -Wmissing-declarations -Wunused -MMD --save-temp -fimplicit-templates -o Types.o Types.cc In file included from /usr/local/lib/gcc/i686-pc-cygwin/4.4.0/../../../../include/c++/4.4.0/bits/localefwd.h:48, from /usr/local/lib/gcc/i686-pc-cygwin/4.4.0/../../../../include/c++/4.4.0/locale:46, from Types.h:37, from Types.cc:29: /usr/local/lib/gcc/i686-pc-cygwin/4.4.0/../../../../include/c++/4.4.0/i686-pc-cygwin/bits/c++locale.h: In function 'int std::__convert_from_v(int* const, char*, int, const char*, ...)': /usr/local/lib/gcc/i686-pc-cygwin/4.4.0/../../../../include/c++/4.4.0/i686-pc-cygwin/bits/c++locale.h:67: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. $ alias CONFIGURECVS alias CONFIGURECVS='/cygdrive/f/Home/cvsroot/gcc/configure --verbose --enable-threads --disable-nls --disable-win32-registry --enable-languages=c,c++' [EMAIL PROTECTED] ~/PD $ alias BUILD alias BUILD='nice make CFLAGS='\'''\'' BOOT_CFLAGS='\'''\'' LIBCFLAGS='\''-g -O'\'' CXXFLAGS='\''-O'\'' LIBCXXFLAGS='\''-g -O'\'' bootstrap' -- Summary: ICE on Valid Code Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mckelvey at maskull dot com GCC build triplet: i686-pc-cygwin GCC host triplet: i686-pc-cygwin GCC target triplet: i686-pc-cygwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37217
[Bug c++/37217] ICE on Valid Code
--- Comment #1 from mckelvey at maskull dot com 2008-08-24 01:41 --- Created an attachment (id=16135) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16135action=view) Compressed preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37217
[Bug middle-end/37218] New: [4.4 Regression] Revision 139525 caused many SLP regressions
On Linux/ia32, Revision 139525 caused FAIL: gcc.dg/vect/slp-14.c scan-tree-dump-times vect vectorized 1 loops 1 FAIL: gcc.dg/vect/slp-14.c scan-tree-dump-times vect vectorizing stmts using SLP 2 FAIL: gcc.dg/vect/slp-15.c scan-tree-dump-times vect vectorized 1 loops 1 FAIL: gcc.dg/vect/slp-15.c scan-tree-dump-times vect vectorizing stmts using SLP 2 FAIL: gcc.dg/vect/slp-2.c scan-tree-dump-times vect vectorized 4 loops 1 FAIL: gcc.dg/vect/slp-2.c scan-tree-dump-times vect vectorizing stmts using SLP 4 FAIL: gcc.dg/vect/slp-20.c scan-tree-dump-times vect vectorized 2 loops 1 FAIL: gcc.dg/vect/slp-20.c scan-tree-dump-times vect vectorizing stmts using SLP 4 FAIL: gcc.dg/vect/slp-22.c scan-tree-dump-times vect vectorized 2 loops 1 FAIL: gcc.dg/vect/slp-22.c scan-tree-dump-times vect vectorizing stmts using SLP 6 FAIL: gcc.dg/vect/slp-25.c scan-tree-dump-times vect vectorized 2 loops 1 FAIL: gcc.dg/vect/slp-25.c scan-tree-dump-times vect Alignment of access forced using peeling 2 FAIL: gcc.dg/vect/slp-9.c scan-tree-dump-times vect vectorized 1 loops 1 FAIL: gcc.dg/vect/slp-9.c scan-tree-dump-times vect vectorizing stmts using SLP 1 -- Summary: [4.4 Regression] Revision 139525 caused many SLP regressions 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=37218
[Bug rtl-optimization/37219] New: [4.3/4.4 Regression] fwprop1 is broken for addresses
When looking into a regression for the PS3 toolchain (when I merged from 4.1.1 to 4.3.0), I noticed fwprop1 does not prop addresses at all since loop_father will always be non NULL as the outer loop always exists. The outer loop includes the whole function. I have a patch which fixes the issue and I just need to test it. I am going to put this as a regression as cse1 used to prop these addresses but we no longer do. -- Summary: [4.3/4.4 Regression] fwprop1 is broken for addresses Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pinskia at gcc dot gnu dot org GCC target triplet: spu-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37219
[Bug rtl-optimization/37219] [4.3/4.4 Regression] fwprop1 is broken for addresses
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-08-24 03:55 --- Here is the patch which I am testing: Index: fwprop.c === --- fwprop.c(revision 139496) +++ fwprop.c(working copy) @@ -1056,7 +1056,9 @@ fwprop (void) struct df_ref *use = DF_USES_GET (i); if (use) if (DF_REF_TYPE (use) == DF_REF_REG_USE - || DF_REF_BB (use)-loop_father == NULL) + || DF_REF_BB (use)-loop_father == NULL + /* The outer most loop is not really a loop. */ + || loop_outer (DF_REF_BB (use)-loop_father) == NULL) forward_propagate_into (use); } @@ -1099,7 +1101,9 @@ fwprop_addr (void) struct df_ref *use = DF_USES_GET (i); if (use) if (DF_REF_TYPE (use) != DF_REF_REG_USE -DF_REF_BB (use)-loop_father != NULL) +DF_REF_BB (use)-loop_father != NULL + /* The outer most loop is not really a loop. */ +loop_outer (DF_REF_BB (use)-loop_father) != NULL) forward_propagate_into (use); } --- CUT --- -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-08-24 03:55:43 date|| Target Milestone|--- |4.3.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37219
