[Bug tree-optimization/43771] [4.5/4.6 Regression] ICE on valid when compiling ParMetis with gcc 4.5.0 and -O3
--- Comment #5 from irar at gcc dot gnu dot org 2010-04-19 06:02 --- Subject: Bug 43771 Author: irar Date: Mon Apr 19 06:02:27 2010 New Revision: 158503 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158503 Log: PR tree-optimization/43771 * tree-vect-slp.c (vect_supported_load_permutation_p): Check that load permutation doesn't have gaps. Added: branches/gcc-4_5-branch/gcc/testsuite/g++.dg/vect/pr43771.cc Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/testsuite/ChangeLog branches/gcc-4_5-branch/gcc/tree-vect-slp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43771
[Bug tree-optimization/43771] [4.5/4.6 Regression] ICE on valid when compiling ParMetis with gcc 4.5.0 and -O3
--- Comment #6 from irar at gcc dot gnu dot org 2010-04-19 06:18 --- Subject: Bug 43771 Author: irar Date: Mon Apr 19 06:17:56 2010 New Revision: 158504 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158504 Log: PR tree-optimization/43771 * tree-vect-analyze.c (vect_supported_load_permutation_p): Check that load permutation doesn't have gaps. Added: branches/gcc-4_4-branch/gcc/testsuite/g++.dg/vect/pr43771.cc Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/testsuite/ChangeLog branches/gcc-4_4-branch/gcc/tree-vect-analyze.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43771
[Bug other/43791] New: kernel/rtmutex.c:1138:1: internal compiler error: in cgraph_decide_inlining_of_small_functions, at ipa-inline.c:1009
building the latest kernel(2.6.34-rc4-00082-g250541f) I'm hitting this: kernel/rtmutex.c: At top level: kernel/rtmutex.c:1138:1: internal compiler error: in cgraph_decide_inlining_of_small_functions, at ipa-inline.c:1009 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[1]: *** [kernel/rtmutex.o] Error 1 make: *** [kernel] Error 2 as for gcc etc.. the only patch that I applied was the pure64 patch from: http://patches.cross-lfs.org/dev/gcc-4.4.2-pure64-1.patch -- Summary: kernel/rtmutex.c:1138:1: internal compiler error: in cgraph_decide_inlining_of_small_functions, at ipa- inline.c:1009 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: justinmattock at gmail dot com GCC build triplet: x86_64 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43791
[Bug other/43562] GCC ICE on optimize attribute
--- Comment #11 from jakub at gcc dot gnu dot org 2010-04-19 07:02 ---
This change broke building wine on x86-64. Distilled testcase:
__attribute__ ((ms_abi)) fn2 (int, int);
struct S { int s; };
struct T { int t; struct S *u; };
void
foo (struct T *x, void *y)
{
int a, b, c, d;
fn1 (0, a, b, c, d);
x-u[x-t].s = fn2 (fn3 (), a);
fn1 (y, a, b, c, d);
}
__attribute__ ((ms_abi)) void
bar (int x)
{
}
void
baz (int x)
{
}
now ICEs at -O2 on x86_64-linux with:
wineice.i: In function 'foo':
wineice.i:12: internal compiler error: in insert_save, at caller-save.c:1171
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
Apparently setup_save_areas
saved_reg-slot
= assign_stack_local_1
(regno_save_mode[regno][1],
GET_MODE_SIZE (regno_save_mode[regno][1]), 0, true);
creates a slot where regno_save_mode[regno][1] for regno 4 is VOIDmode, and the
VOIDmode MEM which has MEM_ALIGN 0 then confuses everything.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|FIXED |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43562
[Bug other/43562] GCC ICE on optimize attribute
--- Comment #12 from jakub at gcc dot gnu dot org 2010-04-19 07:03 --- Forgot to say this is on the 4.4 branch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43562
[Bug other/43562] GCC ICE on optimize attribute
--- Comment #13 from jakub at gcc dot gnu dot org 2010-04-19 07:07 --- Ah, that is PR43662. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43562
[Bug target/43662] [4.4/4.5/4.6 Regression] ICE in insert_save with ms_abi attribute
--- Comment #10 from jakub at gcc dot gnu dot org 2010-04-19 07:10 --- I don't think llp64 there would be very much helpful, then all functions are ms_abi and thus no ABI changes in between functions and no ICE. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43662
[Bug other/43791] kernel/rtmutex.c:1138:1: internal compiler error: in cgraph_decide_inlining_of_small_functions, at ipa-inline.c:1009
--- Comment #1 from justinmattock at gmail dot com 2010-04-19 07:13 ---
Created an attachment (id=20414)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20414action=view)
kernel .config
here is my .config I used to hit this error,
and FWIW here is my compile flags that I used for gcc:
CFLAGS=-m64 -mtune=core2 -march=core2 -O2 -pipe -fomit-frame-pointer
CXXFLAGS=${CFLAGS} MAKEOPTS={-j3} ../gcc*/configure --prefix=/usr
--libexecdir=/usr/lib --enable-shared --enable-threads=posix
--enable-__cxa_atexit --enable-c99 --enable-long-long --enable-clocale=gnu
--enable-languages=c,c++ --disable-multilib --disable-libstdcxx-pch
is there a git repository for gcc?
right now I'm seeing: http://git.infradead.org/gcc.git
if this is then I can try a bisect on with gcc(but then again might be
tricky with the need for a pure64 patch).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43791
[Bug c++/43792] New: In lambda express, calling member function of non-captured class gives internal compiler error
The below at the bottom of this comment gives:
/usr/local/bin/g++ -v -save-temps -std=gnu++0x -o
CMakeFiles/gccError.dir/gccError.cpp.o -c
/home/darlingm/code.gccerror/testing/gccError/gccError.cpp
Using built-in specs.
COLLECT_GCC=/usr/local/bin/g++
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc/configure --disable-multilib --enable-language=c,c++
--disable-nls
Thread model: posix
gcc version 4.6.0 20100418 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=gnu++0x' '-o'
'CMakeFiles/gccError.dir/gccError.cpp.o' '-c' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/cc1plus -E -quiet -v
-D_GNU_SOURCE /home/mdarling/code.gccerror/testing/gccError/gccError.cpp
-mtune=generic -march=x86-64 -std=gnu++0x -fpch-preprocess -o gccError.ii
ignoring nonexistent directory
/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../x86_64-unknown-linux-gnu/include
#include ... search starts here:
#include ... search starts here:
/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../include/c++/4.6.0
/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../include/c++/4.6.0/x86_64-unknown-linux-gnu
/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../include/c++/4.6.0/backward
/usr/local/include
/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/include
/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/include-fixed
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=gnu++0x' '-o'
'CMakeFiles/gccError.dir/gccError.cpp.o' '-c' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/cc1plus -fpreprocessed
gccError.ii -quiet -dumpbase gccError.cpp -mtune=generic -march=x86-64
-auxbase-strip CMakeFiles/gccError.dir/gccError.cpp.o -std=gnu++0x -version -o
gccError.s
GNU C++ (GCC) version 4.6.0 20100418 (experimental) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.6.0 20100418 (experimental), GMP version
4.3.1, MPFR version 2.4.2, MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C++ (GCC) version 4.6.0 20100418 (experimental) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.6.0 20100418 (experimental), GMP version
4.3.1, MPFR version 2.4.2, MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 7af0c1b1da9d8e649a58d85fd58b2bfb
/home/mdarling/code.gccerror/testing/gccError/gccError.cpp: In lambda function:
/home/mdarling/code.gccerror/testing/gccError/gccError.cpp:25:14: error:
'classInstance' is not captured
/home/mdarling/code.gccerror/testing/gccError/gccError.cpp:26:4: internal
compiler error: tree check: expected class 'type', have 'exceptional'
(error_mark) in cv_unqualified, at cp/tree.c:937
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
The original internal compiler error was of course in a much larger project,
and had a bunch of other code errors on it being the first compile attempt. I
got tunnel visioned at the first sight of an internal compiler error and spent
hours re-checking out the svn gcc source and recompiling, in case my svn
version from a week ago had a fixed bug in it.
After removing irrelevant portions of the program to get down to a small test
case, it appears that calling a member function of a non-captured class gives
an internal compiler error. Properly changing the lambda expression line to
functionstring () lambdaExpression = [classInstance] () { prevents the
internal compiler error.
I know it's invalid c++0x code that's causing the internal compiler error, but
removing the internal compiler error and only showing the message error:
'classInstance' is not captured might save someone else a few hours who gets
tunnel visioned on the one error. :)
==
#include iostream
#include string
#include functional
using namespace std;
class theClass {
public:
theClass();
string getA();
private:
string a;
};
theClass::theClass()
: a(theData) {
}
string theClass::getA() {
return a;
}
int main() {
theClass classInstance;
functionstring () lambdaExpression = [] () {
return classInstance.getA();
};
cout lambdaExpression() endl;
}
--
Summary: In lambda express, calling member function of non-
captured class gives internal compiler error
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: darlingm at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43792
[Bug c++/43792] In lambda express, calling member function of non-captured class gives internal compiler error
--- Comment #1 from darlingm at gmail dot com 2010-04-19 07:23 --- (bad refresh) *** This bug has been marked as a duplicate of 43790 *** -- darlingm at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43792
[Bug c++/43790] In lambda express, calling member function of non-captured class gives internal compiler error
--- Comment #1 from darlingm at gmail dot com 2010-04-19 07:23 --- *** Bug 43792 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43790
[Bug other/43791] kernel/rtmutex.c:1138:1: internal compiler error: in cgraph_decide_inlining_of_small_functions, at ipa-inline.c:1009
--- Comment #2 from jiez at gcc dot gnu dot org 2010-04-19 07:24 --- Justin, You can add V=1 when make linux kernel. Then you can find the command line used to compile rtmutex.c. Change -c in the command line to -E and return the command line. Rename the resulted rtmutex.o to rtmutex.i and attach that file here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43791
[Bug target/43662] [4.4/4.5/4.6 Regression] ICE in insert_save with ms_abi attribute
--- Comment #11 from jiez at gcc dot gnu dot org 2010-04-19 07:24 --- Thanks all. This is the updated patch: http://gcc.gnu.org/ml/gcc-patches/2010-04/msg01157.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43662
[Bug target/43729] Mach-O LTO support needed for darwin
-- steven at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2010-04-12 15:55:01 |2010-04-19 07:40:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43729
[Bug tree-optimization/43771] [4.5/4.6 Regression] ICE on valid when compiling ParMetis with gcc 4.5.0 and -O3
--- Comment #7 from irar at il dot ibm dot com 2010-04-19 07:48 --- Fixed on 4.6, 4.5 and 4.4. -- 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=43771
[Bug middle-end/43793] New: [4.6 Regression] tree check: expected tree that contains �decl minimal� structure, have �indirect_ref� in gfc_trans_array_bound_check
A recent regression on CP2K for gcc version 4.6.0 20100419 (experimental) [trunk revision 158504] (GCC) with the attached testcase and 'gfortran -c -fbounds-check': 1075.f90: In function sparse_alltoall: 1075.f90:544:0: internal compiler error: tree check: expected tree that contains decl minimal structure, have indirect_ref in gfc_trans_array_bound_check, at fortran/trans-array.c:2339 Please submit a full bug report, reduced testcase to be attached. -- Summary: [4.6 Regression] tree check: expected tree that contains decl minimal structure, have indirect_ref in gfc_trans_array_bound_check Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43793
[Bug middle-end/43793] [4.6 Regression] tree check: expected tree that contains �decl minimal� structure, have �indirect_ref� in gfc_trans_array_bound_check
--- Comment #1 from jv244 at cam dot ac dot uk 2010-04-19 07:52 --- small enough for pasting: cat bug.f90 MODULE fft_tools INTEGER, PARAMETER :: sp=4, dp=8 INTEGER, PARAMETER :: lp = dp CONTAINS SUBROUTINE sparse_alltoall ( rs, scount, sreq, rq, rcount, rreq, group ) COMPLEX(KIND=lp), DIMENSION(:, :), POINTER:: rs COMPLEX(KIND=lp), DIMENSION(:, :), POINTER:: rq IF ( rcount(pos) /= 0 ) THEN rq(1:rcount(pos),pos) = rs(1:rcount(pos),pos) END IF END SUBROUTINE sparse_alltoall END MODULE fft_tools -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43793
[Bug c/43794] New: miscompile semantically equivalent C source files using -O2
Two semantically equivalent files output different results using gcc 4.5.0 release,while gcc 4.4.1 produced correct results. here is the command line option used to compile the files: gcc -O2 MTest-1.c -o MTest-1.exe gcc -O2 MTest-7.c -o MTest-7.exe #and the results ./MTest-1.exe # generate MTest-1.out ./MTest-7.exe # generate MTest-7.out diff MTest-1.out MTest-7.out use gcc -O2 -fno-strict-aliasing or gcc -O2 -fno-strict-pre can avoid this problem. I have read the Non-bugs section in http://gcc.gnu.org/bugs/ and I'm sure our files does not violate the aliasing rule. the gcc 4.4.1 works correctly using fstrict-aliasing: gcc-4.4 -O2 -fstrict-aliasing MTest-1.c -o MTest-1.exe Here is the gcc configurebuild options $../exec/gcc -v Using built-in specs. COLLECT_GCC=../exec/bin/gcc COLLECT_LTO_WRAPPER=/sda3/test-gcc-4.5.0/exec/bin/../libexec/gcc/i686-pc-linux-gnu/4.5.0/lto-wrapper Target: i686-pc-linux-gnu Configured with: ../src/configure --prefix=/sda3/test-gcc-4.5.0/obj/../exec --enable-languages=c Thread model: posix gcc version 4.5.0 (GCC) I compiled it with gcc 4.4.1: $gcc -v Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.4.1-4ubuntu9' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-targets=all --disable-werror --with-arch-32=i486 --with-tune=generic --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu Thread model: posix gcc version 4.4.1 (Ubuntu 4.4.1-4ubuntu9) -- Summary: miscompile semantically equivalent C source files using -O2 Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: wuwei08 at iscas dot ac dot cn GCC build triplet: x86_32-Ubuntu-Linux GCC host triplet: x86_32-Ubuntu-Linux GCC target triplet: x86_32-Ubuntu-Linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43794
[Bug c/43794] miscompile semantically equivalent C source files using -O2
--- Comment #1 from wuwei08 at iscas dot ac dot cn 2010-04-19 08:09 --- Created an attachment (id=20415) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20415action=view) source files to trigger this bug Source files to trigger this bug.it is a tar file,include MTest-1.c,MTest-1.i,MTest-7.c,and MTest-7.i. command steps: tar xf bug43794.tar gcc-4.5 -O2 MTest-1.c -o mt1 ./mt1 # generate MTest-1.out gcc-4.5 -O2 MTest-7.c -o mt7 ./mt7 # generate MTest-7.out diff MTest-1.out MTest-7.out -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43794
[Bug middle-end/43793] [4.6 Regression] tree check: expected tree that contains �decl minimal� structure, have �indirect_ref� in gfc_trans_array_bound_check
--- Comment #2 from dominiq at lps dot ens dot fr 2010-04-19 08:52 --- Confirmed, probably introduced/uncovered between revisions 158215 (no ICE) and 158486 (ICE). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43793
[Bug tree-optimization/43572] [4.5 Regression] FAIL: gfortran.dg/PR19872.f execution test; formatted read - wrong numbers
--- Comment #24 from ramana at gcc dot gnu dot org 2010-04-19 09:06 --- (In reply to comment #23) Fixed for 4.6, if you confirm the patch for the branch tested ok I'll apply that there. The patch works fine on the 4.5 branch with arm-linux-gnueabi. A bootstrap with --with-cpu=cortex-a9 --with-fpu=vfpv3-d16 --with-float=softfp succeeds and the number of fortran testfailures drops down nicely from 721 to just 1. No regressions in libstdc++ or g++. There are some extra guality failures but there have been quite a few for a while on this board and I need to check with a newer gdb on that board to see what's going on. Hence I'd say this is good to go. cheers Ramana -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43572
[Bug tree-optimization/37027] SLP loop vectorization missing support for reductions
--- Comment #4 from irar at gcc dot gnu dot org 2010-04-19 09:11 --- Subject: Bug 37027 Author: irar Date: Mon Apr 19 09:10:45 2010 New Revision: 158506 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158506 Log: PR tree-optimization/37027 * tree-vectorizer.h (struct _loop_vec_info): Add new field reductions and macro to access it. (vectorizable_reduction): Add argument. (vect_get_slp_defs): Likewise. * tree-vect-loop.c (vect_analyze_scalar_cycles_1): Collect reduction statements for possible use in SLP. (new_loop_vec_info): Initialize LOOP_VINFO_REDUCTIONS. (destroy_loop_vec_info): Free LOOP_VINFO_REDUCTIONS. (vect_create_epilog_for_reduction): Handle SLP. Modify documentation, add new argument. (vectorizable_reduction): Likewise. * tree-vect-stmts.c (vect_get_vec_defs): Update call to vect_get_slp_defs. (vectorizable_type_demotion, vectorizable_type_promotion, vectorizable_store): Likewise. (vect_analyze_stmt): Update call to vectorizable_reduction. (vect_transform_stmt): Likewise. * tree-vect-slp.c (vect_get_and_check_slp_defs): Handle reduction. (vect_build_slp_tree): Fix indentation. Check that there are no loads from different interleaving chains in same node. (vect_slp_rearrange_stmts): New function. (vect_supported_load_permutation_p): Allow load permutations for reductions. Call vect_slp_rearrange_stmts() to rearrange statements inside SLP nodes if necessary. (vect_analyze_slp_instance): Handle reductions. (vect_analyze_slp): Try to build SLP instances originating from groups of reductions. (vect_detect_hybrid_slp_stmts): Skip reduction statements. (vect_get_constant_vectors): Create initial vectors for reductions according to reduction code. Add new argument. (vect_get_slp_defs): Add new argument, pass it to vect_get_constant_vectors. (vect_schedule_slp_instance): Remove SLP tree root statements. Added: trunk/gcc/testsuite/gcc.dg/vect/pr37027.c trunk/gcc/testsuite/gcc.dg/vect/slp-reduc-1.c trunk/gcc/testsuite/gcc.dg/vect/slp-reduc-2.c trunk/gcc/testsuite/gcc.dg/vect/slp-reduc-3.c trunk/gcc/testsuite/gcc.dg/vect/slp-reduc-4.c trunk/gcc/testsuite/gcc.dg/vect/slp-reduc-5.c trunk/gcc/testsuite/gcc.dg/vect/slp-reduc-6.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/lib/target-supports.exp trunk/gcc/tree-vect-loop.c trunk/gcc/tree-vect-patterns.c trunk/gcc/tree-vect-slp.c trunk/gcc/tree-vect-stmts.c trunk/gcc/tree-vectorizer.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37027
[Bug tree-optimization/43572] [4.5 Regression] FAIL: gfortran.dg/PR19872.f execution test; formatted read - wrong numbers
--- Comment #25 from rguenth at gcc dot gnu dot org 2010-04-19 09:12 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work|4.6.0 |4.5.1 4.6.0 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43572
[Bug tree-optimization/43572] [4.5 Regression] FAIL: gfortran.dg/PR19872.f execution test; formatted read - wrong numbers
--- Comment #26 from rguenth at gcc dot gnu dot org 2010-04-19 09:13 --- Subject: Bug 43572 Author: rguenth Date: Mon Apr 19 09:12:13 2010 New Revision: 158507 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158507 Log: 2010-04-19 Richard Guenther rguent...@suse.de PR tree-optimization/43572 * tree-tailcall.c (find_tail_calls): Verify the tail call properly. * gcc.dg/tree-ssa/tailcall-5.c: New testcase. Added: branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/tree-ssa/tailcall-5.c Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/testsuite/ChangeLog branches/gcc-4_5-branch/gcc/tree-tailcall.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43572
[Bug testsuite/43758] [4.6 Regression] 19 new GCC h...@158360 regressions
--- Comment #2 from dominiq at lps dot ens dot fr 2010-04-19 09:17 --- Also seen on powerpc64-unknown-linux-gnu (see http://gcc.gnu.org/ml/gcc-testresults/2010-04/msg01669.html ). -- dominiq at lps dot ens dot fr changed: What|Removed |Added GCC build triplet|powerpc-apple-darwin9 |powerpc*-*-* GCC host triplet|powerpc-apple-darwin9 |powerpc*-*-* GCC target triplet|powerpc-apple-darwin9 |powerpc*-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43758
[Bug middle-end/43793] [4.6 Regression] tree check: expected tree that contains �decl minimal� structure, have �indirect_ref� in gfc_trans_array_bound_check
--- Comment #3 from jv244 at cam dot ac dot uk 2010-04-19 09:23 --- Dominique, you should ask for 'bugzilla confirmation rights' which will allow to touch the 'Confirm' fields etc... -- jv244 at cam dot ac dot uk changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||4.6.0 Known to work||4.5.0 Last reconfirmed|-00-00 00:00:00 |2010-04-19 09:23:45 date|| Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43793
[Bug middle-end/43793] [4.6 Regression] tree check: expected tree that contains �decl minimal� structure, have �indirect_ref� in gfc_trans_array_bound_check
--- Comment #4 from dominiq at lps dot ens dot fr 2010-04-19 09:30 --- Dominique, you should ask for 'bug zilla confirmation rights' which will allow to touch the 'Confirm' fields etc... Do you WHO I should ask for 'bug zilla confirmation rights'? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43793
[Bug c++/43704] [4.5/4.6 Regression] ICE: tree check: accessed elt 2 of tree_vec with 1 elts in tsubst, at cp/pt.c:10074
--- Comment #7 from dodji at gcc dot gnu dot org 2010-04-19 09:32 --- Subject: Bug 43704 Author: dodji Date: Mon Apr 19 09:32:16 2010 New Revision: 158508 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158508 Log: Fix PR c++/43704 gcc/cp/ChangeLog: PR c++/43704 * typeck.c (structural_comptypes): Test dependent typedefs incompatibility before testing for their main variant based equivalence. gcc/testsuite/ChangeLog: PR c++/43704 * g++.dg/template/typedef32.C: New test. Added: trunk/gcc/testsuite/g++.dg/template/typedef32.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/typeck.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43704
[Bug libstdc++/43785] [4.5/4.6 Regression] very basic regression in std::make_pair
--- Comment #8 from redi at gcc dot gnu dot org 2010-04-19 09:35 --- It works fine without -std=c++0x, so is only a regression in code using an experimental compiler mode which implements an incomplet and incorrekt standard. This is not the right place to open defect reports against the draft -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43785
[Bug tree-optimization/43794] [4.5/4.6 Regression] miscompile semantically equivalent C source files using -O2
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-04-19 09:36 --- I can confirm that the output of MTest-7.c differs with -O2 -fno-inline -m32 vs. -O2 -fno-inline -m32 -fno-tree-pre. The latter is equivalent to the -O0 -m32 output. As inlining seems to be not relevant to trigger this bug can you help a bit and isolate the miscompiled function? (just split out each funtion to a separate file and see which you need to compile with -fno-tree-pre to get the bug vanishing). Thx. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|c |tree-optimization Ever Confirmed|0 |1 Keywords||wrong-code Known to work||4.4.3 Last reconfirmed|-00-00 00:00:00 |2010-04-19 09:36:01 date|| Summary|miscompile semantically |[4.5/4.6 Regression] |equivalent C source files |miscompile semantically |using -O2 |equivalent C source files ||using -O2 Target Milestone|--- |4.5.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43794
[Bug c++/6709] [DR743] decltype cannot be used with the :: operator
--- Comment #16 from redi at gcc dot gnu dot org 2010-04-19 09:38 --- Unsuspending, DR743 was recently resolved -- redi at gcc dot gnu dot org changed: What|Removed |Added Status|SUSPENDED |NEW Last reconfirmed|2009-04-16 18:10:10 |2010-04-19 09:38:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6709
[Bug bootstrap/43795] New: gcc-4.5.0, pb installation
Dear All, I want to compile gcc-4.5.0 on a Quad-Core AMD Opteron(tm) Processor 8356 in my user repository. The compiler is gcc version 4.1.2 20070626 (Red Hat 4.1.2-14). I think that I correctly installed all(?) the needed lib to compile gcc-4.5.0. But I issue the following error to the $make install command /bin/sh: line 3: cd: host-x86_64-unknown-linux-gnu/fixincludes: No such file or directory Here's the output of configure made immediately before: --- $./configure --prefix=$HOME/gcc --with-gmp=$HOME/gmp --with-mpfr=$HOME/mpfr --with-mpc=$HOME/mpc --enable-lto --with-ppl=$HOME/ppl --with-libelf=$HOME/libelf --with-cloog=$HOME/cloog-ppl checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu checking target system type... x86_64-unknown-linux-gnu checking for a BSD-compatible install... /usr/bin/install -c checking whether ln works... yes checking whether ln -s works... yes checking for a sed that does not truncate output... /bin/sed checking for gawk... gawk checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking for gnatbind... gnatbind checking for gnatmake... gnatmake checking whether compiler driver understands Ada... yes checking how to compare bootstrapped objects... cmp --ignore-initial=16 $$f1 $$f2 checking for objdir... .libs checking for the correct version of gmp.h... yes checking for the correct version of mpfr.h... yes checking for the correct version of mpc.h... yes checking for the correct version of the gmp/mpfr/mpc libraries... yes checking for version 0.10 of PPL... yes checking for version 0.15.5 (or later revision) of CLooG... yes checking how to run the C preprocessor... gcc -E checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking libelf.h usability... yes checking libelf.h presence... yes checking for libelf.h... yes checking gelf.h usability... yes checking gelf.h presence... yes checking for gelf.h... yes checking libelf/libelf.h usability... yes checking libelf/libelf.h presence... yes checking for libelf/libelf.h... yes checking libelf/gelf.h usability... yes checking libelf/gelf.h presence... yes checking for libelf/gelf.h... yes checking for the correct version of libelf... yes The following languages will be built: c,c++,fortran,java,lto,objc *** This configuration is not supported in the following subdirectories: target-libada gnattools (Any other directories should still work fine.) checking for default BUILD_CONFIG... bootstrap-debug checking for bison... bison -y checking for bison... bison checking for gm4... no checking for gnum4... no checking for m4... m4 checking for flex... flex checking for flex... flex checking for makeinfo... makeinfo checking for expect... expect checking for runtest... runtest checking for ar... ar checking for as... as checking for dlltool... no checking for ld... ld checking for lipo... no checking for nm... nm checking for ranlib... ranlib checking for strip... strip checking for windres... no checking for windmc... no checking for objcopy... objcopy checking for objdump... objdump checking for cc... cc checking for c++... c++ checking for gcc... gcc checking for gcj... gcj checking for gfortran... gfortran checking for ar... no checking for ar... ar checking for as... no checking for as... as checking for dlltool... no checking for dlltool... no checking for ld... no checking for ld... ld checking for lipo... no checking for lipo... no checking for nm... no checking for nm... nm checking for objdump... no checking for objdump... objdump checking for ranlib... no checking for ranlib... ranlib checking for strip... no checking for strip... strip checking for windres... no checking for windres... no checking for windmc... no checking for windmc... no checking where to find the target ar... host tool checking where to find the target as... host tool checking where to find the target cc... just compiled checking where to find the target c++... just compiled checking where to find the target c++ for libstdc++... just compiled checking where to find the target dlltool... host tool checking where to find the target gcc... just compiled checking where to
[Bug tree-optimization/43794] [4.5/4.6 Regression] miscompile semantically equivalent C source files using -O2
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-04-19 09:49 --- The function seems to be MetamorphicTestFunc and the issue is that GCC thinks that D.3914_916 = D.3912_898 * 14400; D.3915_917 = D.3914_916 % 200; is zero because 14400 % 200 == 0. As signed overflow is undefined this is a valid assumption. -fwrapv fixes it, we do seem to overflow. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43794
[Bug middle-end/43793] [4.6 Regression] tree check: expected tree that contains �decl minimal� structure, have �indirect_ref� in gfc_trans_array_bound_check
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-04-19 09:50 --- (In reply to comment #4) Dominique, you should ask for 'bug zilla confirmation rights' which will allow to touch the 'Confirm' fields etc... Do you WHO I should ask for 'bug zilla confirmation rights'? If you have svn write access you have full bugzilla rights if you use a bugzilla account with your @gcc.gnu.org address. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43793
[Bug c++/43787] [4.5/4.6 Regression] memory copy of empty class (sizeof is one)
--- Comment #8 from redi at gcc dot gnu dot org 2010-04-19 09:54 --- (In reply to comment #3) At the very least, you'd agree that it's a performance bug to be copying bytes from memory when the class is empty. At the severe use-case, it breaks existing code. As far as I can see, this can only break invalid code. The original testcase is definitely invalid, there is no object of type empty_t at address 0, that is true whether it is an empty class or not. I agree it's a missed optimization, but not a correctness issue -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43787
[Bug tree-optimization/43783] [4.5/4.6 regression] -O -ftree-pre options compile libbid wrong
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-04-19 09:56 --- Confirmed (libbid result is incorrect, GCC constant-folded result is correct). -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |NEW Ever Confirmed|0 |1 Keywords||wrong-code Known to work||4.4.3 Last reconfirmed|-00-00 00:00:00 |2010-04-19 09:56:21 date|| Summary|[4.5 regression] -O -ftree- |[4.5/4.6 regression] -O - |pre options compile libbid |ftree-pre options compile |wrong |libbid wrong http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43783
[Bug middle-end/43793] [4.6 Regression] tree check: expected tree that contains �decl minimal� structure, have �indirect_ref� in gfc_trans_array_bound_check
--- Comment #6 from dominiq at lps dot ens dot fr 2010-04-19 09:56 --- If you have svn write access you have full bugzilla rights if you use a bugzilla account with your @gcc.gnu.org address. Indeed I don't have svn write access and I am not planning to ask for it in a near future. Is there other ways to 'bugzilla confirmation rights'? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43793
[Bug target/43662] [4.4/4.5/4.6 Regression] ICE in insert_save with ms_abi attribute
--- Comment #12 from jiez at gcc dot gnu dot org 2010-04-19 10:03 --- Subject: Bug 43662 Author: jiez Date: Mon Apr 19 10:02:52 2010 New Revision: 158509 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158509 Log: PR target/43662 * reginfo.c (reinit_regs): Set caller_save_initialized_p to false. testsuite/ PR target/43662 * gcc.target/i386/pr43662.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr43662.c Modified: trunk/gcc/ChangeLog trunk/gcc/reginfo.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43662
[Bug libstdc++/43785] [4.5/4.6 Regression] very basic regression in std::make_pair
--- Comment #9 from redi at gcc dot gnu dot org 2010-04-19 10:03 --- Also, make_pair's reason for existing is to deduce template arguments. If you don't want argument deduction why use make_pair? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43785
[Bug target/43662] [4.4/4.5/4.6 Regression] ICE in insert_save with ms_abi attribute
--- Comment #13 from jiez at gcc dot gnu dot org 2010-04-19 10:05 --- Subject: Bug 43662 Author: jiez Date: Mon Apr 19 10:04:43 2010 New Revision: 158510 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158510 Log: PR target/43662 * reginfo.c (reinit_regs): Set caller_save_initialized_p to false. testsuite/ PR target/43662 * gcc.target/i386/pr43662.c: New test. Added: branches/gcc-4_5-branch/gcc/testsuite/gcc.target/i386/pr43662.c Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/reginfo.c branches/gcc-4_5-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43662
[Bug target/43662] [4.4/4.5/4.6 Regression] ICE in insert_save with ms_abi attribute
--- Comment #14 from jiez at gcc dot gnu dot org 2010-04-19 10:06 --- Subject: Bug 43662 Author: jiez Date: Mon Apr 19 10:06:13 2010 New Revision: 158511 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158511 Log: PR target/43662 * reginfo.c (reinit_regs): Set caller_save_initialized_p to false. testsuite/ PR target/43662 * gcc.target/i386/pr43662.c: New test. Added: branches/gcc-4_4-branch/gcc/testsuite/gcc.target/i386/pr43662.c Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/reginfo.c branches/gcc-4_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43662
[Bug other/39979] [4.4/4.5/4.6 Regression] possible wrong code at all -0x levels.
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||wrong-code Summary|possible wrong code at all -|[4.4/4.5/4.6 Regression] |0x levels. |possible wrong code at all - ||0x levels. Target Milestone|--- |4.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39979
[Bug target/43662] [4.4/4.5/4.6 Regression] ICE in insert_save with ms_abi attribute
--- Comment #15 from jiez at gcc dot gnu dot org 2010-04-19 10:10 --- Should be fixed now on trunk, 4.5 and 4.4 branches. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43662
[Bug fortran/43796] New: ICE with -fcheck=all
uname -a Linux loanamd25 2.6.16.46-0.10-smp #1 SMP Mon May 7 13:37:05 UTC 2007 x86_64 x86_64 x86_64 GNU/Linux gfortran --version GNU Fortran (GCC) 4.5.0 cat f06fkfn.f90 FUNCTION F06FKFN(N,W,INCW,X,INCX) IMPLICIT NONE INTEGER, PARAMETER :: WP = KIND(0.0D0) REAL (KIND=WP) :: F06FKFN REAL (KIND=WP), PARAMETER :: ONE = 1.0E+0_WP REAL (KIND=WP), PARAMETER :: ZERO = 0.0E+0_WP INTEGER, INTENT (IN):: INCW, INCX, N REAL (KIND=WP), INTENT (IN) :: W(*), X(*) REAL (KIND=WP) :: ABSYI, NORM, SCALE, SSQ INTEGER :: I, IW, IX REAL (KIND=WP), EXTERNAL:: F06BMFN INTRINSIC ABS, SQRT IF (N1) THEN NORM = ZERO ELSE IF (N==1) THEN NORM = SQRT(W(1))*ABS(X(1)) ELSE IF (INCW0) THEN IW = 1 ELSE IW = 1 - (N-1)*INCW END IF IF (INCX0) THEN IX = 1 ELSE IX = 1 - (N-1)*INCX END IF SCALE = ZERO SSQ = ONE DO I = 1, N IF ((W(IW)/=ZERO) .AND. (X(IX)/=ZERO)) THEN ABSYI = SQRT(W(IW))*ABS(X(IX)) IF (SCALEABSYI) THEN SSQ = 1 + SSQ*(SCALE/ABSYI)**2 SCALE = ABSYI ELSE SSQ = SSQ + (ABSYI/SCALE)**2 END IF END IF IW = IW + INCW IX = IX + INCX END DO NORM = F06BMFN(SCALE,SSQ) END IF F06FKFN = NORM RETURN END FUNCTION F06FKFN gfortran -O3 -m32 -fcheck=all -c f06fkfn.f90 f06fkfn.f90: In function f06fkfn: f06fkfn.f90:1:0: internal compiler error: Segmentation fault -- Summary: ICE with -fcheck=all Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mathewc at nag dot co dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43796
[Bug tree-optimization/43794] [4.5/4.6 Regression] miscompile semantically equivalent C source files using -O2
--- Comment #4 from steven at gcc dot gnu dot org 2010-04-19 10:21 --- Do we have a warning option for this? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43794
[Bug tree-optimization/43794] [4.5/4.6 Regression] miscompile semantically equivalent C source files using -O2
--- Comment #5 from rguenther at suse dot de 2010-04-19 10:35 --- Subject: Re: [4.5/4.6 Regression] miscompile semantically equivalent C source files using -O2 On Mon, 19 Apr 2010, steven at gcc dot gnu dot org wrote: --- Comment #4 from steven at gcc dot gnu dot org 2010-04-19 10:21 --- Do we have a warning option for this? -Wstrict-overflow[=[123]], but I didn't check if it triggers. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43794
[Bug c/43797] New: __attribute__((deprecated(message))) produces unexpected messages in some cases.
typedef int INT1 __attribute__((deprecated(No INT1)));
INT1 f1 (void) __attribute__((deprecated(No f1)));
INT1 f2 (void) __attribute__((deprecated));
void func (void)
{
f1();
f2();
}
===
produces:
warning: 'f1' is deprecated (declared at...): No f1*** (correct)
warning: 'f2' is deprecated (declared at...): No INT1 *** (incorrect, f2 has
no deprecation message).
--
Summary: __attribute__((deprecated(message))) produces
unexpected messages in some cases.
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: iains at gcc dot gnu dot org
GCC target triplet: ia32-pc-linux, i686-apple-darwin9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43797
[Bug fortran/43796] ICE with -fcheck=all
--- Comment #1 from dominiq at lps dot ens dot fr 2010-04-19 10:56 --- Confirmed on trunk with '-O[23] -m32 -fcheck=bounds' (compiles with '-O[01s]'). Works for me with 4.5 revision 157991 and 4.4.2 (with '-fbounds-check' instead of '-fcheck=bounds'), hence at least a 4.6 regression. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43796
[Bug bootstrap/43795] gcc-4.5.0, pb installation
--- Comment #1 from mikpe at it dot uu dot se 2010-04-19 11:00 --- (In reply to comment #0) Dear All, I want to compile gcc-4.5.0 on a Quad-Core AMD Opteron(tm) Processor 8356 in my user repository. The compiler is gcc version 4.1.2 20070626 (Red Hat 4.1.2-14). I think that I correctly installed all(?) the needed lib to compile gcc-4.5.0. But I issue the following error to the $make install command /bin/sh: line 3: cd: host-x86_64-unknown-linux-gnu/fixincludes: No such file or directory Here's the output of configure made immediately before: --- $./configure --prefix=$HOME/gcc --with-gmp=$HOME/gmp --with-mpfr=$HOME/mpfr Builds in the source dir itself are not supported. Just mkdir a separate objdir somewhere and in the objdir do /path/to/gcc/configure ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43795
[Bug tree-optimization/43783] [4.5/4.6 regression] -O -ftree-pre options compile libbid wrong
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-04-19 11:02 --- It's not bid128_ext_fma that is miscompiled but bid_round.c, building that with -O1 [-ftree-pre] works [fails]. __bid_round192_39_57 is miscompiled by PRE. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2010-04-19 09:56:21 |2010-04-19 11:02:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43783
[Bug fortran/43492] [fortran-dev Regression] ICE in gfc_add_component_ref, at fortran/expr.c:352
--- Comment #3 from janus at gcc dot gnu dot org 2010-04-19 11:07 --- Confirmed. Backtrace: #0 gfc_add_component_ref (e=0x17cb5e0, name=0x77f2fe70 base_transp1) at /home/jweil/gcc46/fortran-dev/gcc/fortran/expr.c:703 #1 0x00528306 in resolve_class_typebound_call (code=0x17cb6a0) at /home/jweil/gcc46/fortran-dev/gcc/fortran/resolve.c:5454 #2 0x0052dd1e in resolve_code (code=0x17cb6a0, ns=0x17caa30) at /home/jweil/gcc46/fortran-dev/gcc/fortran/resolve.c:8345 #3 0x005378fd in resolve_codes (ns=0x17caa30) at /home/jweil/gcc46/fortran-dev/gcc/fortran/resolve.c:12686 #4 0x005377ee in resolve_codes (ns=0x17c4b50) at /home/jweil/gcc46/fortran-dev/gcc/fortran/resolve.c:12672 #5 0x005379f8 in gfc_resolve (ns=0x17c4b50) at /home/jweil/gcc46/fortran-dev/gcc/fortran/resolve.c:12713 #6 0x00516ec1 in gfc_parse_file () at /home/jweil/gcc46/fortran-dev/gcc/fortran/parse.c:4292 #7 0x005591e3 in gfc_be_parse_file (set_yydebug=0) at /home/jweil/gcc46/fortran-dev/gcc/fortran/f95-lang.c:239 #8 0x00a0d48f in compile_file () at /home/jweil/gcc46/fortran-dev/gcc/toplev.c:1053 #9 0x00a0f779 in do_compile () at /home/jweil/gcc46/fortran-dev/gcc/toplev.c:2423 #10 0x00a0f84f in toplev_main (argc=2, argv=0x7fffe308) at /home/jweil/gcc46/fortran-dev/gcc/toplev.c:2465 #11 0x005e0f68 in main (argc=2, argv=0x7fffe308) at /home/jweil/gcc46/fortran-dev/gcc/main.c:35 -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-04-19 11:07:19 date|| Summary|[fortran-dev] ICE in|[fortran-dev Regression] ICE |gfc_add_component_ref, at |in gfc_add_component_ref, at |fortran/expr.c:352 |fortran/expr.c:352 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43492
[Bug tree-optimization/43783] [4.5/4.6 regression] -O -ftree-pre options compile libbid wrong
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-04-19 11:20 ---
Testcase:
typedef __attribute__((aligned(16)))
struct {
unsigned long w[3];
} UINT192;
UINT192 __bid_Kx192[32];
extern void abort (void);
int main()
{
int i = 0;
unsigned long x = 0;
for (i = 0; i 32; ++i)
__bid_Kx192[i].w[1] = i == 1;
for (i = 0; i 32; ++i)
x += __bid_Kx192[1].w[1];
if (x != 32)
abort ();
return 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43783
[Bug fortran/42517] -fcheck=recursion does not work with -fopenmp
--- Comment #11 from dominiq at lps dot ens dot fr 2010-04-19 11:25 --- Should not this PR closed as fixed? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42517
[Bug middle-end/43796] [4.5/4.6 Regression] ICE in is_overflow_infinity (tree-vrp.c:184) with gfortran -fcheck=bounds -O2
--- Comment #2 from burnus at gcc dot gnu dot org 2010-04-19 11:39 --- Confirm. It fails with 4.5 and 4.6 using the option -fbounds-check (== -fcheck-bounds), but only with -O2 and higher and for some reasons only with -m32 and not with -m64 on x86_64-unknown-linux-gnu. It works with GCC 4.1/4.2/4.3/4.4. Valgrind shows: ==2634== Invalid read of size 2 ==2634==at 0x9643CA: is_overflow_infinity (tree-vrp.c:184) ==2634==by 0x96447D: usable_range_p (tree-vrp.c:797) ==2634==by 0x96A3DD: compare_ranges (tree-vrp.c:3388) ==2634==by 0x96B083: vrp_evaluate_conditional_warnv_with_ops (tree-vrp.c:5669) ==2634==by 0x96B91F: vrp_evaluate_conditional (tree-vrp.c:5710) ==2634==by 0x9309DE: thread_across_edge (tree-ssa-threadedge.c:537) ==2634==by 0x9765ED: execute_vrp (tree-vrp.c:7214) ==2634==by 0x785B9A: execute_one_pass (passes.c:1569) ==2634==by 0x785E24: execute_pass_list (passes.c:1624) ==2634==by 0x785E36: execute_pass_list (passes.c:1625) ==2634==by 0x87AB34: tree_rest_of_compilation (tree-optimize.c:413) ==2634==by 0x9FCA60: cgraph_expand_function (cgraphunit.c:1548) ==2634== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==2634== test.f90: In function 'f06fkfn': test.f90:1:0: internal compiler error: Segmentation fault Please submit a full bug report, -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org Component|fortran |middle-end GCC target triplet||i386-unknown-linux-gnu Keywords||ice-on-valid-code Known to fail||4.5.0 4.6.0 Known to work||4.4.4 Summary|ICE with -fcheck=all|[4.5/4.6 Regression] ICE in ||is_overflow_infinity (tree- ||vrp.c:184) with gfortran - ||fcheck=bounds -O2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43796
[Bug other/39979] [4.4/4.5/4.6 Regression] possible wrong code at all -0x levels.
--- Comment #11 from pluto at agmk dot net 2010-04-19 11:44 --- (In reply to comment #9) The testcase is btw a too twisted maze. Can you wrap up a simple main() so that it fails at runtime? i'll try to reduce it to something human readable... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39979
[Bug other/39979] [4.4/4.5/4.6 Regression] possible wrong code at all -0x levels.
--- Comment #12 from pluto at agmk dot net 2010-04-19 11:44 --- (In reply to comment #10) Oh, and does it fail with http://gcc.gnu.org/bugzilla/attachment.cgi?id=20394 applied? this patch didn't help. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39979
[Bug middle-end/43793] [4.6 Regression] tree check: expected tree that contains �decl minimal� structure, have �indirect_ref� in gfc_trans_array_bound_check
--- Comment #7 from jv244 at cam dot ac dot uk 2010-04-19 11:56 --- (In reply to comment #6) If you have svn write access you have full bugzilla rights if you use a bugzilla account with your @gcc.gnu.org address. Indeed I don't have svn write access and I am not planning to ask for it in a near future. Is there other ways to 'bugzilla confirmation rights'? Nor do I have svn write access (afaik), but I can confirm/close/etc bugs. I think this was something tobias burnus enabled? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43793
[Bug tree-optimization/43783] [4.5/4.6 regression] -O -ftree-pre options compile libbid wrong
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-04-19 11:57 --- The array element alignment is not properly visible, but instead loads of random crap alignments appear in trees. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43783
[Bug fortran/43227] [4.5/4.6 Regression] ICE: segmentation fault in mio_expr
--- Comment #9 from pault at gcc dot gnu dot org 2010-04-19 12:12 --- I decided to take a look at this during lunchtime today. The source that I had to hand is the 20091203 4.5.0 snapshot. To my astonishment, this does not show the problem. I have had a quick look at the intervening gcc-cvs postings but cannot identify the source of the regression yet. Janus's patch of 20091211 is NOT the cause. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43227
[Bug middle-end/43796] [4.5/4.6 Regression] ICE in is_overflow_infinity (tree-vrp.c:184) with gfortran -fcheck=bounds -O2
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-04-19 12:26 --- Program received signal SIGSEGV, Segmentation fault. 0x00bdb380 in needs_overflow_infinity (type=0x0) at /space/rguenther/src/svn/gcc-4_5-branch/gcc/tree-vrp.c:184 184 return INTEGRAL_TYPE_P (type) !TYPE_OVERFLOW_WRAPS (type); (gdb) up #1 0x00bdb434 in is_overflow_infinity (val=0x75adfe70) at /space/rguenther/src/svn/gcc-4_5-branch/gcc/tree-vrp.c:269 269 return (needs_overflow_infinity (TREE_TYPE (val)) (gdb) call debug_tree (val) ssa_name 0x75adfe70 nothrow var var_decl 0x77fbf0a0 idef_stmt version 56 in-free-list Confirmed. We free the SSA name in substitute_and_fold () but it is still used in symbolical ranges which we end up using by jump threading. If we do so we shouldn't DCE stmts in substitute_and_fold (). There's also a missed-optimization which if fixed fixes this PR as well. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-04-19 12:26:31 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43796
[Bug tree-optimization/43794] [4.5/4.6 Regression] miscompile semantically equivalent C source files using -O2
--- Comment #6 from wuwei08 at iscas dot ac dot cn 2010-04-19 12:32 --- Subject: Re: [4.5/4.6 Regression] miscompile semantically equivalent C source files using -O2 On Mon, 2010-04-19 at 10:21 +, steven at gcc dot gnu dot org wrote: --- Comment #4 from steven at gcc dot gnu dot org 2010-04-19 10:21 --- Do we have a warning option for this? Thank you for your attention. There is no warning for it with '-Wall' option. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43794
[Bug fortran/43227] [4.5/4.6 Regression] ICE: segmentation fault in mio_expr
--- Comment #10 from dominiq at lps dot ens dot fr 2010-04-19 12:33 --- I decided to take a look at this during lunchtime today. The source that I had to hand is the 20091203 4.5.0 snapshot. To my astonishment, this does not show the problem. I have had a quick look at the intervening gcc-cvs postings but cannot identify the source of the regression yet. Janus's patch of 20091211 is NOT the cause. AFAICR the problem is specific to the fortran-dev branch. From my logs and my habits, I suspect that it was introduced between revisions 156573 (Feb 7 2010) and 157148 (probably at or after r157133, i.e. on or after Mon Mar 1 09:23:35 2010). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43227
[Bug tree-optimization/43794] [4.5/4.6 Regression] miscompile semantically equivalent C source files using -O2
--- Comment #7 from wuwei08 at iscas dot ac dot cn 2010-04-19 12:36 --- Thank you for your attention. There is no warning for it with '-Wstrict-overflow[=[123]]' option. (In reply to comment #5) Subject: Re: [4.5/4.6 Regression] miscompile semantically equivalent C source files using -O2 On Mon, 19 Apr 2010, steven at gcc dot gnu dot org wrote: --- Comment #4 from steven at gcc dot gnu dot org 2010-04-19 10:21 --- Do we have a warning option for this? -Wstrict-overflow[=[123]], but I didn't check if it triggers. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43794
[Bug target/43766] x86 prefetch doesn't use complex memory addressing
--- Comment #5 from uros at gcc dot gnu dot org 2010-04-19 12:37 --- Subject: Bug 43766 Author: uros Date: Mon Apr 19 12:37:16 2010 New Revision: 158515 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158515 Log: PR target/43766 * config/i386/i386.c (ix86_decompose_address): Handle ASHIFT addends. testsuite/ChangeLog: PR target/43766 * gcc.target/i386/pr43766.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr43766.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43766
[Bug target/43766] x86 prefetch doesn't use complex memory addressing
--- Comment #6 from ubizjak at gmail dot com 2010-04-19 12:38 --- Fixed. -- ubizjak at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43766
[Bug fortran/43227] [4.5/4.6 Regression] ICE: segmentation fault in mio_expr
--- Comment #11 from janus at gcc dot gnu dot org 2010-04-19 12:51 --- (In reply to comment #10) AFAICR the problem is specific to the fortran-dev branch. No, this is definitely not the case! Only the failure of comment #0 is specific to the branch. However, this failure is caused by an underlying problem with procedure pointers, which is also present in the 4.5 release (see comment #3). When searching for the origin of the regression, one should use the test case in comment #3 and look at the 4.5 trunk. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43227
[Bug target/43743] Dumb use of SSE regs for MMX operation
--- Comment #2 from ubizjak at gmail dot com 2010-04-19 12:53 --- (In reply to comment #0) If I take off -msse2, I get this: movd(%eax), %mm0 movd4(%eax), %mm1 punpcklbw %mm1, %mm0 The code above is produced _without_ SSE (-mno-sse), since with -mno-sse2, you will get: movss (%eax), %xmm0 movlps %xmm0, -8(%ebp) movss 4(%eax), %xmm0 movq-8(%ebp), %mm0 movlps %xmm0, -16(%ebp) punpcklbw -16(%ebp), %mm0 So, effectively the same code as with SSE2. -- ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-04-19 12:53:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43743
[Bug c/43798] New: attribute((aligned(x))) not honored for array element types?
in libbid we have
typedef __attribute__((aligned(16)))
struct {
unsigned long long w[3];
} UINT192;
UINT192 bid_Kx192[32];
thus we request 16-byte alignment for UINT192 (whose elements add
up to a size of 24). Now the array ends up with elements of size 24
and thus the elements are _not_ aligned to a 16-byte boundary, still
the element type is not adjusted to reflect that leading to inconsistencies
when one for example tries to set operand 3 of an ARRAY_REF
(which is specified in units of the alignment of the element).
This causes PR43783.
This is also at least a documentation bug as I can't find anything
that documents the above behavior.
--
Summary: attribute((aligned(x))) not honored for array element
types?
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Keywords: wrong-code, documentation
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43798
[Bug c/43798] attribute((aligned(x))) not honored for array element types?
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-04-19 13:05 --- Namely the bid_Kx192 decl looks like var_decl 0x75af8000 bid_Kx192 type array_type 0x75add7e0 type record_type 0x75add690 UINT192 type_0 BLK size integer_cst 0x77ef70c8 constant 192 unit size integer_cst 0x77ef7078 constant 24 user align 128 symtab 0 alias set -1 canonical type 0x75add498 fields field_decl 0x77fb34c0 w context translation_unit_decl 0x75afe000 D.1631 pointer_to_this pointer_type 0x75add888 BLK size integer_cst 0x77ef7258 constant 6144 unit size integer_cst 0x77fcfaa0 constant 768 user align 128 symtab 0 alias set -1 canonical type 0x75add9d8 domain integer_type 0x75add738 pointer_to_this pointer_type 0x75afc000 addressable used public static common BLK file t.c line 6 col 9 size integer_cst 0x77ef7258 6144 unit size integer_cst 0x77fcfaa0 768 align 256 chain function_decl 0x75adcb00 main where the TYPE_ALIGN of the element type only applies to the first array element. If you look at expr.c:array_ref_element_size then you can see that there doesn't exist a valid TREE_OPERAND (array-ref, 3) for indexing the above array as its TYPE_ALIGN_UNIT is bigger than the aligned-size. IMHO the C frontend ought to generate a variant type for the element type that has its alignment adjusted (or it shall follow the users request and add padding between the elements?). The current situation is unfortunate for the middle-end. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||jsm28 at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43798
[Bug fortran/43227] [4.5/4.6 Regression] ICE: segmentation fault in mio_expr
--- Comment #12 from dominiq at lps dot ens dot fr 2010-04-19 13:06 --- When searching for the origin of the regression, one should use the test case in comment #3 and look at the 4.5 trunk. I keep forgetting this test!-(on i686-apple-darwin9, it compiles at revision 147438, 20090512, and fails at revision 150825, 20090817). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43227
[Bug fortran/43227] [4.5/4.6 Regression] ICE: segmentation fault in mio_expr
--- Comment #13 from janus at gcc dot gnu dot org 2010-04-19 13:21 --- I keep forgetting this test!-(on i686-apple-darwin9, it compiles at revision 147438, 20090512, and fails at revision 150825, 20090817). That's a start. I can see two (hypothetical) candidates in this range: * r150725 * r150823 Will try to find out if one of these is the culprit. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43227
[Bug c/43798] attribute((aligned(x))) not honored for array element types?
--- Comment #2 from schwab at linux-m68k dot org 2010-04-19 13:28 --- An array cannot have internal padding, so the padding needs to be added to the element type. The attempt to define such an array should probably be rejected. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43798
[Bug target/43743] Dumb use of SSE regs for MMX operation
--- Comment #3 from ubizjak at gmail dot com 2010-04-19 13:34 --- From sse.md: ;; ??? In theory we can match memory for the MMX alternative, but allowing ;; nonimmediate_operand for operand 2 and *not* allowing memory for the SSE ;; alternatives pretty much forces the MMX alternative to be chosen. (define_insn *vec_concatv2si_sse2 [(set (match_operand:V2SI 0 register_operand =x,x ,*y,*y) (vec_concat:V2SI (match_operand:SI 1 nonimmediate_operand 0,rm, 0,rm) (match_operand:SI 2 reg_or_0_operand x,C ,*y, C)))] TARGET_SSE2 Since this insn is part of expand_vector_init sequences, changing RA preferences will result in the usage of MMX registers in the construction of i.e. V4SI vector. When MMX registers are touched, x87 register stack switches to MMX mode, so gcc will go really far to avoid touching MMX registers. The problem you show is the result of this, and changing the delicate balance of MMX register allocation preferences will just result in Really Annoying Problems elsewhere. Just stay away of MMX registers as much as possible. -- ubizjak at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43743
[Bug tree-optimization/43783] [4.5/4.6 regression] -O -ftree-pre options compile libbid wrong
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-04-19 13:37 --- Subject: Bug 43783 Author: rguenth Date: Mon Apr 19 13:36:54 2010 New Revision: 158517 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158517 Log: 2010-04-19 Richard Guenther rguent...@suse.de PR tree-optimization/43783 * tree-ssa-pre.c (create_component_ref_by_pieces_1): Drop constant ARRAY_REF operands two and three if possible. * gcc.c-torture/execute/pr43783.c: New testcase. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr43783.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-pre.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43783
[Bug c/43798] attribute((aligned(x))) not honored for array element types?
--- Comment #3 from jakub at gcc dot gnu dot org 2010-04-19 13:44 --- At least with pointers alignment greater than size of the pointed to type (or not divisible by it) is often used to say that the start of the array is aligned some way. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43798
[Bug fortran/43227] [4.5/4.6 Regression] ICE: segmentation fault in mio_expr
--- Comment #14 from janus at gcc dot gnu dot org 2010-04-19 13:46 --- (In reply to comment #13) I keep forgetting this test!-(on i686-apple-darwin9, it compiles at revision 147438, 20090512, and fails at revision 150825, 20090817). That's a start. I can see two (hypothetical) candidates in this range: * r150725 * r150823 I just checked r150724, which also fails. This means that both my guesses were wrong. But at least it bring us down to the range 147438:150724 (which is still three months of development). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43227
[Bug fortran/43227] [4.5/4.6 Regression] ICE: segmentation fault in mio_expr
--- Comment #15 from dominiq at lps dot ens dot fr 2010-04-19 13:54 --- I just checked r150724, which also fails. This means that both my guesses were wrong. But at least it bring us down to the range 147438:150724 (which is still three months of development). I don't have access to IRC from my office desk. If you have access to it, you may ping Tobias and Jerry to ask them to look to their archives for something in between. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43227
[Bug c/43798] attribute((aligned(x))) not honored for array element types?
--- Comment #4 from rguenther at suse dot de 2010-04-19 13:57 --- Subject: Re: attribute((aligned(x))) not honored for array element types? On Mon, 19 Apr 2010, jakub at gcc dot gnu dot org wrote: --- Comment #3 from jakub at gcc dot gnu dot org 2010-04-19 13:44 --- At least with pointers alignment greater than size of the pointed to type (or not divisible by it) is often used to say that the start of the array is aligned some way. Yes, we correctly copy the (over-)alignment of the element type to the array type. But the element type alignment then stays wrong. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43798
[Bug target/43799] New: -fschedule-insns breaks vararg functions in recent builds
Command line: gcc -fschedule-insns testcase-1.c ./a.out gcc -O[123s] -fschedule-insns testcase-2.c ./a.out Tested revisions: r158486 - fail r158225 - OK 4.5 r158486 - OK Compiler output: $ /mnt/svn/gcc-trunk/binary-158486-lto-fortran/bin/gcc -O3 -fschedule-insns testcase.c ./a.out Aborted -- Summary: -fschedule-insns breaks vararg functions in recent builds Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zsojka at seznam dot cz GCC host triplet: x86_64-pc-linux-gnu GCC target triplet: x86_64-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43799
[Bug target/43799] -fschedule-insns breaks vararg functions in recent builds
--- Comment #1 from hjl dot tools at gmail dot com 2010-04-19 14:06 --- Testcase? -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43799
[Bug target/43799] -fschedule-insns breaks vararg functions in recent builds
--- Comment #2 from zsojka at seznam dot cz 2010-04-19 14:10 --- Created an attachment (id=20416) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20416action=view) reduced testcase (from gcc.c-torture/execute/stdarg-2.c) Command line: $ gcc -fschedule-insns pr43799.c ./a.out Aborted -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43799
[Bug target/43799] [4.6 Regression] -fschedule-insns breaks vararg functions in recent builds
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||hubicka at gcc dot gnu dot ||org Status|WAITING |NEW Ever Confirmed|0 |1 Keywords||wrong-code Last reconfirmed|-00-00 00:00:00 |2010-04-19 14:11:59 date|| Summary|-fschedule-insns breaks |[4.6 Regression] -fschedule- |vararg functions in recent |insns breaks vararg |builds |functions in recent builds Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43799
[Bug target/43799] [4.6 Regression] -fschedule-insns breaks vararg functions in recent builds
--- Comment #3 from zsojka at seznam dot cz 2010-04-19 14:14 --- Created an attachment (id=20417) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20417action=view) reduced testcase (from gcc.c-torture/execute/stdarg-4.c) Command line: $ gcc -O3 -fschedule-insns pr43799-2.c ./a.out Aborted Fails at all -O[123s] levels. At least with -O3 -fschedule-insns, this check: cmp edi, 5 # i, is missing in the generated code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43799
[Bug target/43799] [4.6 Regression] -fschedule-insns breaks vararg functions in recent builds
--- Comment #4 from zsojka at seznam dot cz 2010-04-19 14:23 --- Created an attachment (id=20418) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20418action=view) list of testsuite failures (gcc, g++, fortran) $ make check RUNTESTFLAGS=--target_board=unix/-fschedule-insns $ grep '^FAIL:' gcc/testsuite/*/*.log | grep ' exec' It's possible not all these failures are related to this PR. 4.5 r158486 passes the run without any execution failure. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43799
[Bug other/43791] kernel/rtmutex.c:1138:1: internal compiler error: in cgraph_decide_inlining_of_small_functions, at ipa-inline.c:1009
--- Comment #3 from justinmattock at gmail dot com 2010-04-19 14:26 --- Subject: Re: kernel/rtmutex.c:1138:1: internal compiler error: in cgraph_decide_inlining_of_small_functions, at ipa-inline.c:1009 On Mon, Apr 19, 2010 at 12:24 AM, jiez at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org wrote: --- Comment #2 from jiez at gcc dot gnu dot org 2010-04-19 07:24 --- Justin, You can add V=1 when make linux kernel. Then you can find the command line used to compile rtmutex.c. Change -c in the command line to -E and return the command line. Rename the resulted rtmutex.o to rtmutex.i and attach that file here. cool..(thanks for the mini tutorial) I never knew that's how you make a preprocess file, attached is rtmutex.i as you requested. --- Comment #4 from justinmattock at gmail dot com 2010-04-19 14:26 --- Created an attachment (id=20419) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20419action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43791
[Bug c/43782] Erroneous expansion of __asm__() directive
--- Comment #3 from beebe at math dot utah dot edu 2010-04-19 14:34 --- Subject: Re: Erroneous expansion of __asm__() directive Oh I forgot to mention, sqrt will use sqrtsd and will be inlined so you don't need to use inline-asm yourself. The test code that I sent is an extract of a larger system; its use of __asm__() is intentional. --- - Nelson H. F. BeebeTel: +1 801 581 5254 - - University of UtahFAX: +1 801 581 4148 - - Department of Mathematics, 110 LCBInternet e-mail: be...@math.utah.edu - - 155 S 1400 E RM 233 be...@acm.org be...@computer.org - - Salt Lake City, UT 84112-0090, USAURL: http://www.math.utah.edu/~beebe/ - --- -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43782
[Bug c/43782] Erroneous expansion of __asm__() directive
--- Comment #4 from beebe at math dot utah dot edu 2010-04-19 14:35 --- Subject: Re: Erroneous expansion of __asm__() directive That is wrong because with ATT style x86 asm, the src is first and the dest is second. That cannot be the case: you cannot change the operand order after three years of it working one way! --- - Nelson H. F. BeebeTel: +1 801 581 5254 - - University of UtahFAX: +1 801 581 4148 - - Department of Mathematics, 110 LCBInternet e-mail: be...@math.utah.edu - - 155 S 1400 E RM 233 be...@acm.org be...@computer.org - - Salt Lake City, UT 84112-0090, USAURL: http://www.math.utah.edu/~beebe/ - --- -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43782
[Bug tree-optimization/37027] SLP loop vectorization missing support for reductions
--- Comment #5 from irar at il dot ibm dot com 2010-04-19 14:35 --- Fixed. -- irar at il dot ibm dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37027
[Bug c++/43704] [4.5/4.6 Regression] ICE: tree check: accessed elt 2 of tree_vec with 1 elts in tsubst, at cp/pt.c:10074
--- Comment #8 from hjl dot tools at gmail dot com 2010-04-19 14:44 --- On Linux/ia32, I got Executing on host: /export/gnu/import/svn/gcc-test/bld/gcc/testsuite/g++2/../../g++ -B/export/gnu/import/svn/gcc-test/bld/gcc/testsuite/g++2/../../ /export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/g++.dg/template/typedef32.C -nostdinc++ -I/export/gnu/import/svn/gcc-test/bld/i686-pc-linux-gnu/libstdc++-v3/include/i686-pc-linux-gnu -I/export/gnu/import/svn/gcc-test/bld/i686-pc-linux-gnu/libstdc++-v3/include -I/export/gnu/import/svn/gcc-test/src-trunk/libstdc++-v3/libsupc++ -I/export/gnu/import/svn/gcc-test/src-trunk/libstdc++-v3/include/backward -I/export/gnu/import/svn/gcc-test/src-trunk/libstdc++-v3/testsuite/util -fmessage-length=0 -ansi -pedantic-errors -Wno-long-long -S -o typedef32.s (timeout = 300) /export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/g++.dg/template/typedef32.C: In instantiation of 'banded_adaptormatrixdouble ::iterator1':^M /export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/g++.dg/template/typedef32.C:43:46: instantiated from here^M /export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/g++.dg/template/typedef32.C:35:9: error: no type named 'ic' in 'class banded_adaptormatrixdouble ::ty1'^M -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43704
[Bug c++/43800] New: [4.6 regression] FAIL: libgomp.c++/for-4.C
On Linux/ia32, revision 158513 gave FAIL: libgomp.c++/for-3.C -O0 (test for excess errors) FAIL: libgomp.c++/for-3.C -O1 (test for excess errors) FAIL: libgomp.c++/for-3.C -O2 (test for excess errors) FAIL: libgomp.c++/for-3.C -O3 -fomit-frame-pointer (test for excess errors) FAIL: libgomp.c++/for-3.C -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (test for excess errors) FAIL: libgomp.c++/for-3.C -O3 -fomit-frame-pointer -funroll-loops (test for excess errors) FAIL: libgomp.c++/for-3.C -O3 -g (test for excess errors) FAIL: libgomp.c++/for-3.C -Os (test for excess errors) FAIL: libgomp.c++/for-4.C -O0 (test for excess errors) FAIL: libgomp.c++/for-4.C -O1 (test for excess errors) FAIL: libgomp.c++/for-4.C -O2 (test for excess errors) FAIL: libgomp.c++/for-4.C -O3 -fomit-frame-pointer (test for excess errors) FAIL: libgomp.c++/for-4.C -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (test for excess errors) FAIL: libgomp.c++/for-4.C -O3 -fomit-frame-pointer -funroll-loops (test for excess errors) FAIL: libgomp.c++/for-4.C -O3 -g (test for excess errors) FAIL: libgomp.c++/for-4.C -Os (test for excess errors) Revision 158505 is OK. It may be cause by revision 158508: http://gcc.gnu.org/ml/gcc-cvs/2010-04/msg00614.html -- Summary: [4.6 regression] FAIL: libgomp.c++/for-4.C Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ 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=43800
[Bug libstdc++/43785] [4.5/4.6 Regression] very basic regression in std::make_pair
--- Comment #10 from navin dot kumar at gmail dot com 2010-04-19 14:53 --- However, what would make_pair have deduced its T1 and T2 to be in this example? My impression was make_pair(x,y) would have deduced T1=uint32_t and T2=uint32_t. Therefore, make_pairuint32_t,uint32_t(x,y) should be synonymous. The part that is confusing is if I do a diff on bits/stl_pair.h between GCC4.4.2 and GCC4.5.0, the constructor has not changed. Yet it compiles with -std=c++0x on GCC4.4.2 but errors with -std=c++0x on GCC4.5.0 (which is why I opened it up as a bug report to c++ initially rather than libstdc++). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43785
[Bug libstdc++/43785] [4.5/4.6 Regression] very basic regression in std::make_pair
--- Comment #11 from navin dot kumar at gmail dot com 2010-04-19 14:54 --- typo: constructor has not changed in the above post should be function has not changed -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43785
[Bug c/43782] Erroneous expansion of __asm__() directive
--- Comment #5 from jakub at gcc dot gnu dot org 2010-04-19 14:56 ---
Nobody changed the order of arguments, in ATT syntax always the result is the
last, in Intel syntax (not the default on Linux unless -masm=intel) the result
is the first.
Perhaps you were lucky and both the input and output got the same register and
so it didn't matter (say sqrtsd %xmm0, %xmm0).
You can also write the asm using
sqrtsd {%1, %0|%0, %1}
and then it will work with both the default ATT syntax and -masm=intel.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43782
[Bug libstdc++/43785] [4.5/4.6 Regression] very basic regression in std::make_pair
--- Comment #12 from bangerth at gmail dot com 2010-04-19 14:57 --- (In reply to comment #9) Also, make_pair's reason for existing is to deduce template arguments. If you don't want argument deduction why use make_pair? True. I don't know why one would want to do this either, but several people happened to do so about half a dozen times in our 500,000 lines of code. W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43785
[Bug c/43782] Erroneous expansion of __asm__() directive
--- Comment #6 from pinskia at gmail dot com 2010-04-19 15:07 --- Subject: Re: Erroneous expansion of __asm__() directive Sent from my iPhone On Apr 19, 2010, at 7:35 AM, Nelson H. F. Beebe be...@math.utah.edu wrote: That is wrong because with ATT style x86 asm, the src is first and the dest is second. That cannot be the case: you cannot change the operand order after three years of it working one way! It did not change. Just what happened was gcc is now inlining the function. Before it was not inlining the function which allowed the inline-asm's two operands to be the same (the argument to the function and the return value are done in the same register). Which means you were just getting lucky that it worked. In fact ATT asm has always been that way; while intel style asm is the opposite. Gcc outputs ATT by default, though you can change it via an option. --- --- --- -- - Nelson H. F. BeebeTel: +1 801 581 5254 - - University of UtahFAX: +1 801 581 4148 - - Department of Mathematics, 110 LCBInternet e-mail: be...@math.utah.edu - - 155 S 1400 E RM 233 be...@acm.org be...@computer.org - - Salt Lake City, UT 84112-0090, USAURL: http://www.math.utah.edu/~beebe/ - --- --- --- -- -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43782
[Bug fortran/43227] [4.5/4.6 Regression] ICE: segmentation fault in mio_expr
--- Comment #16 from burnus at gcc dot gnu dot org 2010-04-19 15:13 --- Works: 2009-07-24-r150035 Fails: 2009-07-29-r150196 (Both trees were _not_ clean, but the first has the same patches as the second one, plus one more - thus, it is rather likely that the regression range is still correct.) I think the culprit is: Date: Sat Jul 25 11:56:35 2009 New Revision: 150078 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=150078 2009-07-25 Janus Weil ja...@gcc.gnu.org PR fortran/39630 * decl.c (match_ppc_decl): Implement the PASS attribute for procedure pointer components. [...] * module.c (MOD_VERSION): Bump module version. (binding_ppc): New string constants. (mio_component): Only use formal args if component is a procedure pointer and add 'tb' member. (mio_typebound_proc): Include pass_arg and take care of procedure pointer components. [...] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43227
[Bug middle-end/43796] [4.5/4.6 Regression] ICE in is_overflow_infinity (tree-vrp.c:184) with gfortran -fcheck=bounds -O2
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-04-19 15:17 --- Subject: Bug 43796 Author: rguenth Date: Mon Apr 19 15:17:26 2010 New Revision: 158520 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158520 Log: 2010-04-19 Richard Guenther rguent...@suse.de PR tree-optimization/43796 * tree-vrp.c (adjust_range_with_scev): Lookup init and step from SCEV in the lattice. (vrp_visit_phi_node): Dump change. * gfortran.dg/pr43796.f90: New testcase. Added: trunk/gcc/testsuite/gfortran.dg/pr43796.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vrp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43796
[Bug middle-end/43796] [4.5 Regression] ICE in is_overflow_infinity (tree-vrp.c:184) with gfortran -fcheck=bounds -O2
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to fail|4.5.0 4.6.0 |4.5.0 Known to work|4.4.4 |4.4.4 4.6.0 Summary|[4.5/4.6 Regression] ICE in |[4.5 Regression] ICE in |is_overflow_infinity (tree- |is_overflow_infinity (tree- |vrp.c:184) with gfortran - |vrp.c:184) with gfortran - |fcheck=bounds -O2 |fcheck=bounds -O2 Target Milestone|--- |4.5.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43796
[Bug libstdc++/43785] [4.5/4.6 Regression] very basic regression in std::make_pair
--- Comment #13 from redi at gcc dot gnu dot org 2010-04-19 15:26 --- (In reply to comment #10) However, what would make_pair have deduced its T1 and T2 to be in this example? My impression was make_pair(x,y) would have deduced T1=uint32_t and T2=uint32_t. Therefore, make_pairuint32_t,uint32_t(x,y) should be synonymous. No, it would have deduced them as uint32_t so make_pairuint32_t,uint32_t is synonymous. Otherwise it tries to bind uint32_t to an lvalue, which is not allowed. The part that is confusing is if I do a diff on bits/stl_pair.h between GCC4.4.2 and GCC4.5.0, the constructor has not changed. Yet it compiles with -std=c++0x on GCC4.4.2 but errors with -std=c++0x on GCC4.5.0 (which is why I opened it up as a bug report to c++ initially rather than libstdc++). GCC 4.4 does not implement the updated rvalue reference semantics that prevent lvalues binding to rvalues. (In reply to comment #12) (In reply to comment #9) Also, make_pair's reason for existing is to deduce template arguments. If you don't want argument deduction why use make_pair? True. I don't know why one would want to do this either, but several people happened to do so about half a dozen times in our 500,000 lines of code. Well it's about time someone put a stop to it ;-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43785
[Bug libstdc++/43785] [4.5/4.6 Regression] very basic regression in std::make_pair
--- Comment #14 from redi at gcc dot gnu dot org 2010-04-19 15:37 --- (In reply to comment #13) Well it's about time someone put a stop to it ;-) Seriously though, it's quicker to write e.g. return std::pairuint32_t, uint32_t(x, y) than return std::make_pairuint32_t, uint32_t(x, y); I can't see why anyone would use the latter if they know both the arguments in advance. There is a valid use case for make_pairuint32_t(x, y), which suppresses deduction for the first argument but not the second. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43785
