[Bug fortran/52968] Call to type-bound procedure produces wrongly rejected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52968 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2012-04-13 CC||burnus at gcc dot gnu.org, ||janus at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2012-04-13 07:14:46 UTC --- What happens is the following (cf. primary.c's gfc_match_varspec): In the first step, S % Equation is matched. One then has: component = gfc_find_component (sym, name, false, false); ... sym = component-ts.u.derived; where sym __class_solvermodule_Equationtemplate_p. Next, one tries to match % Evaluate as type-bound procedure: if (sym-f2k_derived) tbp = gfc_find_typebound_proc (sym, t, name, false, gfc_current_locus); However, the class container does not have f2k_derived - only the _data component has. Unsurprisingly, it works if one replaces in type :: SolverType the CLASS pointer by a TYPE pointer. I have no idea why changing the order of the two type declarations helps - but I didn't try hard.
[Bug tree-optimization/52969] New: ICE in in get_expr_operands, at tree-ssa-operands.c:1035 with -ftree-loop-if-convert-stores
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52969 Bug #: 52969 Summary: ICE in in get_expr_operands, at tree-ssa-operands.c:1035 with -ftree-loop-if-convert-stores Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: vincenzo.innoce...@cern.ch Created attachment 27147 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27147 source code (generated with -E) compiling the attached real-life code I get c++ -v -O3 -std=c++0x -ftree-loop-if-convert-stores -c buggy.i Using built-in specs. COLLECT_GCC=c++ COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-apple-darwin11.3.0/4.7.0/lto-wrapper Target: x86_64-apple-darwin11.3.0 Configured with: ./configure --enable-languages=c,c++,fortran --disable-multilib --disable-bootstrap --enable-lto -disable-libitm Thread model: posix gcc version 4.7.0 20120205 (experimental) (GCC) COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.7.3' '-v' '-O3' '-std=c++11' '-ftree-loop-if-convert-stores' '-c' '-shared-libgcc' '-mtune=core2' /usr/local/libexec/gcc/x86_64-apple-darwin11.3.0/4.7.0/cc1plus -fpreprocessed buggy.i -fPIC -quiet -dumpbase buggy.i -mmacosx-version-min=10.7.3 -mtune=core2 -auxbase buggy -O3 -std=c++11 -version -ftree-loop-if-convert-stores -o /var/folders/hd/vml6pgj48xjfkp006s6djxf8gq/T//ccT2Uqbf.s GNU C++ (GCC) version 4.7.0 20120205 (experimental) (x86_64-apple-darwin11.3.0) compiled by GNU C version 4.7.0 20111201 (experimental), GMP version 4.3.1, MPFR version 2.4.1, MPC version 0.8.1 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 GNU C++ (GCC) version 4.7.0 20120205 (experimental) (x86_64-apple-darwin11.3.0) compiled by GNU C version 4.7.0 20111201 (experimental), GMP version 4.3.1, MPFR version 2.4.1, MPC version 0.8.1 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 3c7081ac5da07d4d6f6ca789c3e35f66 unhandled expression in get_expr_operands(): truth_not_expr 0x1050e00a0 type boolean_type 0x141b1bb28 bool sizes-gimplified public unsigned type_6 QI size integer_cst 0x141b0cba0 constant 8 unit size integer_cst 0x141b0cbc0 constant 1 align 8 symtab 0 alias set 14 canonical type 0x141b1bb28 precision 1 min integer_cst 0x141b0cfa0 0 max integer_cst 0x141b0cfe0 1 pointer_to_this pointer_type 0x1013bfe70 reference_to_this reference_type 0x1013bff18 arg 0 lt_expr 0x104f9d900 type boolean_type 0x141b1bb28 bool arg 0 ssa_name 0x105523550 type real_type 0x141b1be70 float visited var var_decl 0x104fb0aa0 maxpixdef_stmt maxpix_135 = MEM[(struct SiStripTemplate *)templ_76(D) + 40B]; version 135 arg 1 ssa_name 0x105523820 type real_type 0x141b1be70 float visited var var_decl 0x105475b40 D.104278def_stmt D.104278_144 = qscale_123 * D.104277_143; version 144 SiStripTemplateReco.cc:160:5 SiStripTemplateReco.cc:160:5 SiStripTemplateReco.cc: In function ‘int SiStripTemplateReco::StripTempReco1D(int, float, float, float, std::vectorfloat, SiStripTemplate, float, float, float, int, int, float)’: SiStripTemplateReco.cc:79:5: internal compiler error: in get_expr_operands, at tree-ssa-operands.c:1035 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. pb-d-128-141-131-26:bugs48 innocent$ c++ -v -O3 -std=c++0x -c buggy.i Using built-in specs. COLLECT_GCC=c++ COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-apple-darwin11.3.0/4.7.0/lto-wrapper Target: x86_64-apple-darwin11.3.0 Configured with: ./configure --enable-languages=c,c++,fortran --disable-multilib --disable-bootstrap --enable-lto -disable-libitm Thread model: posix gcc version 4.7.0 20120205 (experimental) (GCC) COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.7.3' '-v' '-O3' '-std=c++11' '-c' '-shared-libgcc' '-mtune=core2' /usr/local/libexec/gcc/x86_64-apple-darwin11.3.0/4.7.0/cc1plus -fpreprocessed buggy.i -fPIC -quiet -dumpbase buggy.i -mmacosx-version-min=10.7.3 -mtune=core2 -auxbase buggy -O3 -std=c++11 -version -o /var/folders/hd/vml6pgj48xjfkp006s6djxf8gq/T//ccLlzfNR.s GNU C++ (GCC) version 4.7.0 20120205 (experimental) (x86_64-apple-darwin11.3.0) compiled by GNU C version 4.7.0 20111201 (experimental), GMP version 4.3.1, MPFR version 2.4.1, MPC version 0.8.1 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 GNU C++ (GCC) version 4.7.0 20120205 (experimental) (x86_64-apple-darwin11.3.0) compiled by GNU C version 4.7.0 20111201 (experimental), GMP version 4.3.1, MPFR version 2.4.1, MPC version 0.8.1 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 3c7081ac5da07d4d6f6ca789c3e35f66
[Bug c++/52967] Segmentation fault on std::vector destruction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52967 --- Comment #2 from Dmitry Gerasimov karlicoss at gmail dot com 2012-04-13 08:26:08 UTC --- (In reply to comment #1) I don't know if this is not undefined code. v[0].a = run(); Is this: double a = v[0].a; a = run(); Or: double tmp = run(); v[0].a = tmp; I think both are correct because of the way the C++ standard defines =. Hm, double a = v[0].a; a = run(); does result in segfault. Should it?
[Bug libstdc++/52938] std::string::reserve request is not maintained if object is used in other object copy ctor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52938 --- Comment #13 from Jonathan Wakely redi at gcc dot gnu.org 2012-04-13 08:31:13 UTC --- The user could care less if we use copy-on-write in the string implementation. The standard doesn't force that (21.3.6). But it does allow it. We are violating what the standard says about reserve (20.3.10/20.3.11). Here it is: Effects: after reserve(), capacity() is greater or equal to the argument of reserve. That is it. if I call reserve(1024) on a string, from that point on, capacity should return at least 1024. Immediately after you call reserve it returns at least 1024. But not necessarily from that point on for ever and ever. If you call swap() to exchange it with another string it's capacity could shrink, or in C++11 if you move assign another string to it its capacity could change. Or, in C++03 for reference-counted strings, it could change because the previously-shared string is no longer shared. This is a pointless discussion anyway, it's not going to change.
[Bug libstdc++/52950] --enable-symvers=gnu-versioned-namespace exports symbol twice.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52950 Pawel Sikora pluto at agmk dot net changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Pawel Sikora pluto at agmk dot net 2012-04-13 08:43:24 UTC --- not a gcc bug (problem was in custom new/delete tracing).
[Bug c++/52967] Segmentation fault on std::vector destruction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52967 --- Comment #3 from Dmitry Gerasimov karlicoss at gmail dot com 2012-04-13 08:44:10 UTC --- (In reply to comment #1) I don't know if this is not undefined code. v[0].a = run(); Is this: double a = v[0].a; a = run(); Or: double tmp = run(); v[0].a = tmp; I think both are correct because of the way the C++ standard defines =. Ok, I got this. If v[0].a = run(); is equivalent to double a = v[0].a; a = run();, we: 1. calculate the address of a; 2. recurse into run 3. push_back, causing vector to increase its capacity and reallocate its memory, which makes a to point to free memory. I guess I should mark bug as Invalid?
[Bug middle-end/52886] [4.8 Regression] FAIL: gcc.dg/torture/pr36978.c -On (internal compiler error), n=1 and above
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52886 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #6 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-04-13 09:00:51 UTC --- AFAICT this pr is fixed, so closing. Thanks for the fix.
[Bug c/52862] [4.5/4.6/4.7/4.8 Regression] ICE convert_to_pointer, at convert.c:50
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52862 --- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2012-04-13 09:22:37 UTC --- Author: rguenth Date: Fri Apr 13 09:22:33 2012 New Revision: 186407 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=186407 Log: 2012-04-13 Richard Guenther rguent...@suse.de PR c/52862 * convert.c (convert_to_pointer): Remove special-casing of zero. * gcc.dg/pr52862.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/pr52862.c Modified: trunk/gcc/ChangeLog trunk/gcc/convert.c trunk/gcc/testsuite/ChangeLog
[Bug c/52549] [4.8 Regression] ice in pointer_diff
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52549 --- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2012-04-13 09:24:34 UTC --- Author: rguenth Date: Fri Apr 13 09:24:28 2012 New Revision: 186408 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=186408 Log: 2012-04-13 Richard Guenther rguent...@suse.de PR c/52549 * c-typeck.c (pointer_diff): Remove bogus assert. * gcc.dg/pr52549.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/pr52549.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-typeck.c trunk/gcc/testsuite/ChangeLog
[Bug c/52862] [4.5/4.6/4.7/4.8 Regression] ICE convert_to_pointer, at convert.c:50
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52862 --- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2012-04-13 09:26:48 UTC --- Author: rguenth Date: Fri Apr 13 09:26:45 2012 New Revision: 186409 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=186409 Log: 2012-04-13 Richard Guenther rguent...@suse.de PR c/52862 * convert.c (convert_to_pointer): Remove special-casing of zero. * gcc.dg/pr52862.c: New testcase. Added: branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/pr52862.c Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/convert.c branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
[Bug c/52549] [4.8 Regression] ice in pointer_diff
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52549 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||4.7.0 Resolution||FIXED --- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2012-04-13 09:28:19 UTC --- Fixed.
[Bug c/52862] [4.5/4.6 Regression] ICE convert_to_pointer, at convert.c:50
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52862 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Known to work||4.7.1, 4.8.0 Summary|[4.5/4.6/4.7/4.8|[4.5/4.6 Regression] ICE |Regression] ICE |convert_to_pointer, at |convert_to_pointer, at |convert.c:50 |convert.c:50| Known to fail|4.7.1, 4.8.0| --- Comment #7 from Richard Guenther rguenth at gcc dot gnu.org 2012-04-13 09:28:59 UTC --- Fixed for 4.7 and trunk sofar.
[Bug other/52944] [4.5/4.6 Regression] __builtin_object_size(..., 1) no longer returns (size_t)-1 for consecutive flexible/zero-length array members
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52944 --- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2012-04-13 09:30:48 UTC --- (In reply to comment #4) (In reply to comment #3) wouldn't it though ? there's still a top level union there surrounding all the members. so flattening it, i'd get three choices: - th_block; th_data - th_code; th_data - th_stuff the problem before was that it was a union followed by th_data testing locally with gcc-4.6.2, i get the object sizes of: - -O0: th_data:-1 th_stuff:-1 - -O[s123]: th_data:96 th_stuff:98 Ah, yeah. That might work reliably indeed. Though I find my solutions nicer and more explicit ;)
[Bug fortran/52970] New: OpenMP Scoping Incorrect for Arrays of Parameters
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52970 Bug #: 52970 Summary: OpenMP Scoping Incorrect for Arrays of Parameters Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: ian.b...@nag.co.uk Created attachment 27148 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27148 Program showing the problem Hi, when using default( none ) for the scoping of variables in an OpenMP parallel region gfortran complains that arrays of Parameters need scoping when they don't as they are named constants, not variables. Interestingly scalar Parameters behave correctly (sorry for any line wrap issues): Wot now? cat test_par_open.f90 program test_par_opemp !$ use omp_lib implicit none integer :: kk, jx,jy,jz Integer, Parameter :: nsbcll = 27 Integer, Dimension( 1:nsbcll ), Parameter :: nix = (/ 0, -1,-1,-1, 0, 0, 0, 1, 1, 1, -1,-1,-1, 0, 0, 1, 1, 1, -1,-1,-1, 0, 0, 0, 1, 1, 1 /) , niy = (/ 0, -1, 0, 1,-1, 0, 1,-1, 0, 1, -1, 0, 1,-1, 1,-1, 0, 1, -1, 0, 1,-1, 0, 1,-1, 0, 1 /) , niz = (/ 0, -1,-1,-1,-1,-1,-1,-1,-1,-1, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1, 1, 1, 1, 1, 1, 1 /) !$omp parallel do default(none) private(kk,jx,jy,jz) do kk=1, nsbcll jx=nix(kk) jy= niy(kk) jz=niz(kk) end do !$omp end parallel do end program Wot now? ~/Downloads/gcc-4.8/bin/gfortran --version GNU Fortran (GCC) 4.8.0 20120408 (experimental) Copyright © 2012 Free Software Foundation, Inc. GNU Fortran comes with NO WARRANTY, to the extent permitted by law. You may redistribute copies of GNU Fortran under the terms of the GNU General Public License. For more information about these matters, see the file named COPYING Wot now? ~/Downloads/gcc-4.8/bin/gfortran -fopenmp -W -Wall -pedantic -std=f95 test_par_open.f90 test_par_open.f90: In function ‘test_par_opemp’: test_par_open.f90:18:0: error: ‘nix’ not specified in enclosing parallel test_par_open.f90:15:0: error: enclosing parallel test_par_open.f90:19:0: error: ‘niy’ not specified in enclosing parallel test_par_open.f90:15:0: error: enclosing parallel test_par_open.f90:20:0: error: ‘niz’ not specified in enclosing parallel test_par_open.f90:15:0: error: enclosing parallel Note no error is generated for the scalar parameter nsbcll. This happens in 4.8.0, 4.6.2 and 4.5.2. Portland group, intel and oracle are all happy with the above code. The above code is attached, Ian
[Bug rtl-optimization/52203] ICE: in reset_sched_cycles_in_current_ebb, at sel-sched.c:7136 with -fsel-sched-pipelining -fselective-scheduling2 and other custom flags
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52203 --- Comment #11 from Andrey Belevantsev abel at gcc dot gnu.org 2012-04-13 09:36:46 UTC --- Author: abel Date: Fri Apr 13 09:36:42 2012 New Revision: 186410 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=186410 Log: PR rtl-optimization/52203 PR rtl-optimization/52715 Revert the 2012-03-07 fix for PR 52203. * sel-sched.c (reset_sched_cycles_in_current_ebb): Check that the insn does not modify DFA right before issuing, adjust issue_rate accordingly. Modified: trunk/gcc/ChangeLog trunk/gcc/sel-sched.c
[Bug tree-optimization/52969] ICE in in get_expr_operands, at tree-ssa-operands.c:1035 with -ftree-loop-if-convert-stores
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52969
Markus Trippelsdorf markus at trippelsdorf dot de changed:
What|Removed |Added
CC||markus at trippelsdorf dot
||de
--- Comment #1 from Markus Trippelsdorf markus at trippelsdorf dot de
2012-04-13 09:37:05 UTC ---
markus@x4 tmp % cat test.cpp
#include vector
int a, b;
void foo (std::vectorfloat cluster) {
int j;
float xsum[0];
for (; a ; ++j) {
xsum[j] = cluster[j];
if (xsum[j] 0)
xsum[j] = 0;
}
if (xsum[0])
b = 0;
}
markus@x4 tmp % gcc test.cpp -std=c++0x -ftree-loop-if-convert-stores -O1
test.cpp: In function ‘void foo(std::vectorfloat)’:
test.cpp:3:6: internal compiler error: in get_expr_operands, at
tree-ssa-operands.c:1035
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
[Bug rtl-optimization/52715] [4.8 Regression] ICE: in reset_sched_cycles_in_current_ebb, at sel-sched.c:7140 with -fselective-scheduling2 -funroll-loops --param=max-average-unrolled-insns=406
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52715 --- Comment #2 from Andrey Belevantsev abel at gcc dot gnu.org 2012-04-13 09:36:47 UTC --- Author: abel Date: Fri Apr 13 09:36:42 2012 New Revision: 186410 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=186410 Log: PR rtl-optimization/52203 PR rtl-optimization/52715 Revert the 2012-03-07 fix for PR 52203. * sel-sched.c (reset_sched_cycles_in_current_ebb): Check that the insn does not modify DFA right before issuing, adjust issue_rate accordingly. Modified: trunk/gcc/ChangeLog trunk/gcc/sel-sched.c
[Bug libstdc++/52604] mt allocator crashes on multi-threaded
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52604
--- Comment #14 from Laurent Aflonsi laurent.alfonsi at st dot com 2012-04-13
09:46:24 UTC ---
Thanks very much Paolo.
Here it is. I'll commit the patch in the mainline if no objection.
Laurent
2012-04-13 Laurent Alfonsi laurent.alfo...@st.com
PR libstdc++/52604
* src/mt_allocator.cc: (~__freelist): Reset pointer.
Index: src/c++98/mt_allocator.cc
===
--- src/c++98/mt_allocator.cc(revision 186374)
+++ src/c++98/mt_allocator.cc(working copy)
@@ -48,6 +48,7 @@
{
__gthread_key_delete(_M_key);
::operator delete(static_castvoid*(_M_thread_freelist_array));
+ _M_thread_freelist = 0;
}
}
};
[Bug libstdc++/52604] mt allocator crashes on multi-threaded
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52604 --- Comment #15 from Jonathan Wakely redi at gcc dot gnu.org 2012-04-13 09:48:39 UTC --- (In reply to comment #14) PR libstdc++/52604 * src/mt_allocator.cc: (~__freelist): Reset pointer. ^ c++98/
[Bug c++/52964] No warning on negative array size in template instantatiation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52964 --- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2012-04-13 09:50:01 UTC --- It's at least somewhat making -fsyntax-only less useful for C++ ... I'd use -fsyntax-only to have all errors reported and thus all invalid CUs rejected ... We do report non-syntax errors with -fsyntax-only after all.
[Bug c++/52954] Missing bounds check warning without optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52954 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2012-04-13 Summary|Missing bounds check|Missing bounds check |warning |warning without ||optimization Ever Confirmed|0 |1 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-04-13 09:51:38 UTC --- We only perform array-bounds warnings when we optimize and the VRP pass is turned on. We completely miss this kind of warning in the frontend(s), though they for sure can only detect very simple cases.
[Bug c++/52967] Segmentation fault on std::vector destruction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52967 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2012-04-13 09:52:03 UTC --- Yes, this is invalid. If you want to do this then you need to call reserve on the vector so that push_back doesn't cause reallocation (or decide if the code shouldn't just be rewritten differently!)
[Bug c++/24985] caret diagnostics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24985
--- Comment #34 from Richard Guenther rguenth at gcc dot gnu.org 2012-04-13
09:56:48 UTC ---
(In reply to comment #32)
(In reply to comment #31)
The effect of this patch on overload resolution diagnostics is problematic:
wa2.C: In function ‘int main()’:
wa2.C:6:6: error: no matching function for call to ‘f(int)’
f(1);
^
wa2.C:6:6: note: candidates are:
f(1);
^
wa2.C:1:6: note: void f()
void f();
^
wa2.C:1:6: note: candidate expects 0 arguments, 1 provided
void f();
^
wa2.C:2:6: note: void f(int, int)
void f(int,int);
^
wa2.C:2:6: note: candidate expects 2 arguments, 1 provided
void f(int,int);
^
When there are multiple diagnostics at the same input location, we should
only
print the source/caret information once.
True. Actually, in this case, perhaps we should print:
wa2.C:6:6: error: no matching function for call to ‘f(int)’
f(1);
^
note: candidates are:
wa2.C:1:6: note: candidate expects 0 arguments, 1 provided
void f();
^
wa2.C:2:6: note: candidate expects 2 arguments, 1 provided
void f(int,int);
^
no? Any other suggestions?
We could also print the %qD in the same line as:
wa2.C:6:6: error: no matching function for call to ‘f(int)’
f(1);
^
note: candidates are:
wa2.C:1:6: note: candidate 'void f()' expects 0 arguments, 1 provided
void f();
^
wa2.C:2:6: note: candidate 'void f(int, int)' expects 2 arguments, 1
provided
void f(int,int);
^
What do you think?
I think we should simply omit carets for all 'note's for now and add a
way for the callers to suppress carets. Though if you consider the testcase
changed to
void f(); void f(int,int);
int main()
{
f(1);
}
then suddenly the carets get more useful and the situation less clear:
t.C: In function 'int main()':
t.C:5:6: error: no matching function for call to 'f(int)'
f(1);
^
t.C:5:6: note: candidates are:
f(1);
^
t.C:1:6: note: void f()
void f(); void f(int,int);
^
t.C:1:6: note: candidate expects 0 arguments, 1 provided
void f(); void f(int,int);
^
t.C:1:17: note: void f(int, int)
void f(); void f(int,int);
^
t.C:1:17: note: candidate expects 2 arguments, 1 provided
void f(); void f(int,int);
^
btw, why do we print a location info for
t.C:5:6: note: candidates are:
f(1);
^
at all?
t.C:1:6: note: candidate expects 0 arguments, 1 provided
void f(); void f(int,int);
^
t.C:1:17: note: void f(int, int)
void f(); void f(int,int);
^
and the 2nd note here looks wrong.
[Bug middle-end/52939] [4.7/4.8 Regression] ice in gimple_get_virt_method_for_binfo with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52939 --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2012-04-13 09:58:44 UTC --- (In reply to comment #3) Created attachment 27143 [details] Simple testcase This should be a simpler testcase. What happens is that we are attempting to devirtualize call to a virtual method introduced in a descendant but with an ancestor which does not have it. I suppose this is OK if the call is never executed in run-time. Dealing with this situation in gimple_get_virt_method_for_binfo would be easy, but perhaps we want fold_ctor_reference to return NULL is it is requested to fold an expression from beyond the provided constructor? Well, if we know what the size of the constructor target is, yes. Otherwise all non-initialized parts are implicitely initialized to zero. Thus, you need to handle this case in gimple_get_virt_method_for_binfo anyway (fails are always better than asserts ...)
[Bug tree-optimization/52969] [4.7/4.8 Regression] ICE in in get_expr_operands, at tree-ssa-operands.c:1035 with -ftree-loop-if-convert-stores
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52969 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-04-13 AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.7.1 Summary|ICE in in |[4.7/4.8 Regression] ICE in |get_expr_operands, at |in get_expr_operands, at |tree-ssa-operands.c:1035|tree-ssa-operands.c:1035 |with|with |-ftree-loop-if-convert-stor |-ftree-loop-if-convert-stor |es |es Ever Confirmed|0 |1 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-04-13 10:01:06 UTC --- Mine.
[Bug c/52971] New: gcc ICE with an sh64 cross-compilation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52971 Bug #: 52971 Summary: gcc ICE with an sh64 cross-compilation Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: dhowe...@redhat.com Created attachment 27149 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27149 ICE producer I have built a cross-compiler toolchain for sh64 that can also compile for 32-bit SH. All the 32-bit Linux kernel SH defconfigs that I've fed it have worked, but the primary 64-bit SH defconfig fails with a gcc SEGV/ICE on at least one of the files. I've distilled the C code that produced the ICE down to a few lines (see attachment). This is compiled with: sh64-linux-gnu-gcc -m5-32media-nofpu -ml -Wa,-isa=shmedia -O2 -c ice.c ice.c: In function ‘part_pack_uuid’: ice.c:8:3: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://bugzilla.redhat.com/bugzilla/ for instructions. The gcc build was configured with: AR_FOR_TARGET=/usr/bin/sh64-linux-gnu-ar \ AS_FOR_TARGET=/usr/bin/sh64-linux-gnu-as \ DLLTOOL_FOR_TARGET=/usr/bin/sh64-linux-gnu-dlltool \ LD_FOR_TARGET=/usr/bin/sh64-linux-gnu-ld \ NM_FOR_TARGET=/usr/bin/sh64-linux-gnu-nm \ OBJDUMP_FOR_TARGET=/usr/bin/sh64-linux-gnu-objdump \ RANLIB_FOR_TARGET=/usr/bin/sh64-linux-gnu-ranlib \ STRIP_FOR_TARGET=/usr/bin/sh64-linux-gnu-strip \ WINDRES_FOR_TARGET=/usr/bin/sh64-linux-gnu-windres \ WINDMC_FOR_TARGET=/usr/bin/sh64-linux-gnu-windmc \ LDFLAGS='-Wl,-z,relro ' \ ../gcc-4.7.0-RC-20120302/configure --disable-dependency-tracking --disable-silent-rules --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/info --build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu --target=sh64-linux --enable-targets=all --program-prefix=sh64-linux-gnu- --enable-languages=c --without-headers --enable-sjlj-exceptions --with-system-libunwind --disable-nls --disable-threads --disable-shared --disable-libmudflap --disable-libssp --disable-libgomp --disable-libquadmath --disable-gold --disable-decimal-float --enable-checking= --enable-gnu-unique-object --enable-linker-build-id --disable-plugin --enable-nls --with-system-zlib --with-bugurl=http://bugzilla.redhat.com/bugzilla/ --enable-obsolete --with-multilib-list=m1,m2,m2e,m4,m4-single,m4-single-only,m2a,m2a-single,m5-32media,m5-32media-nofpu,m5-compact,m5-compact-nofpu,m5-64media,m5-64media-nofpu From gcc-4.7.0-RC-20120302.tar.bz2 downloaded from the gcc website. The binutils used was binutils-2.22.52.0.1.tar.bz2 with the patches from the Fedora rawhide binutils srpm applied. This was configured thusly: LDFLAGS='-Wl,-z,relro ' \ ../binutils-2.22.52.0.1/configure --disable-dependency-tracking --disable-silent-rules --enable-checking --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/info --build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu --target=sh64-elf --program-prefix=sh64-linux-gnu- --disable-shared --enable-64-bit-bfd --enable-targets=sh64-linux,sh-elf,sh-linux,sh4-linux --with-bugurl=http://bugzilla.redhat.com/bugzilla/ And a symlink emplaced at /usr/sh64-linux to point to the /usr/sh64-elf/ directory so that the cross-compiler could find it. For reference, the cross-gcc and cross-binutils are built as RPMs for Fedora using spec files or SRPMs similar to those that can be found in http://people.redhat.com/~dhowells/cross/
[Bug libstdc++/52604] mt allocator crashes on multi-threaded
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52604 --- Comment #16 from Paolo Carlini paolo.carlini at oracle dot com 2012-04-13 10:29:02 UTC --- Yes, please go ahead, mainline only for now (PR remains open) with Jon's fix to the ChangeLog and also, between parentheses (__freelist::~__freelist).
[Bug libstdc++/52604] mt allocator crashes on multi-threaded
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52604 --- Comment #17 from Paolo Carlini paolo.carlini at oracle dot com 2012-04-13 10:31:01 UTC --- Ah, another minor nit, remember to add 2012 to the list of Copyright Years (mind to keep the comment within 80 columns)
[Bug tree-optimization/52969] [4.7/4.8 Regression] ICE in in get_expr_operands, at tree-ssa-operands.c:1035 with -ftree-loop-if-convert-stores
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52969
--- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2012-04-13
10:39:35 UTC ---
(gdb) call debug_gimple_stmt (stmt)
_ifc_.9_27 = !(D.11217_6 0.0) ? _ifc_.8_26 : _ifc_.7_20;
the negate is spurious. I have a patch. if-conversion is also incredibly
stupid, transforming
if (cond)
x = a;
else
x = b;
to
x = cond ? a : x;
x = !cond ? b : x;
and only DSE removes the first dead store. But we keep both conditionals
as nothing even tries to optimize them:
D.1966_8 = *D.1965_7;
_ifc_.3_12 = xsum[j_21];
_ifc_.5_19 = D.1966_8 0.0 ? 0.0 : _ifc_.3_12;
D.1983_25 = D.1966_8 0.0;
D.1984_26 = ~D.1983_25;
_ifc_.8_27 = D.1983_25 ? _ifc_.5_19 : D.1966_8;
xsum[j_21] = _ifc_.8_27;
Reduced testcase:
int a, b;
float xsum[100];
void foo (float *cluster)
{
int j;
for (; a ; ++j) {
xsum[j] = cluster[j];
if (xsum[j] 0)
xsum[j] = 0;
}
if (xsum[0])
b = 0;
}
I have a patch.
[Bug c++/24985] caret diagnostics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24985 --- Comment #35 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-04-13 10:59:17 UTC --- (In reply to comment #34) btw, why do we print a location info for t.C:5:6: note: candidates are: f(1); ^ at all? I am proposing to print just: note: candidates are:, with enough leading empty space to align with the previous error and no caret. Is that OK? Richard, Jason? t.C:1:6: note: candidate expects 0 arguments, 1 provided void f(); void f(int,int); ^ t.C:1:17: note: void f(int, int) void f(); void f(int,int); ^ and the 2nd note here looks wrong. Could you explain why?
[Bug tree-optimization/52969] [4.7/4.8 Regression] ICE in in get_expr_operands, at tree-ssa-operands.c:1035 with -ftree-loop-if-convert-stores
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52969 --- Comment #4 from vincenzo Innocente vincenzo.innocente at cern dot ch 2012-04-13 11:31:37 UTC --- Ready to test the patch. I've another code that produces the same ICE in stl_algo.h:3264 not easy to reproduce in a small example...
[Bug c++/52972] New: [4.6] Pure virtual method is called instead of child's method
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52972 Bug #: 52972 Summary: [4.6] Pure virtual method is called instead of child's method Classification: Unclassified Product: gcc Version: 4.6.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: dri...@gmail.com Created attachment 27150 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27150 Bug sample drino@netbook:~/src$ g++ test.cpp drino@netbook:~/src$ ./a.out pure virtual method called terminate called without an active exception Aborted
[Bug c++/24985] caret diagnostics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24985 --- Comment #36 from Richard Guenther rguenth at gcc dot gnu.org 2012-04-13 11:34:04 UTC --- (In reply to comment #35) (In reply to comment #34) btw, why do we print a location info for t.C:5:6: note: candidates are: f(1); ^ at all? I am proposing to print just: note: candidates are:, with enough leading empty space to align with the previous error and no caret. Is that OK? Richard, Jason? Sounds good to me. But I think GNU conventions require a location here? t.C:1:6: note: candidate expects 0 arguments, 1 provided void f(); void f(int,int); ^ t.C:1:17: note: void f(int, int) void f(); void f(int,int); ^ and the 2nd note here looks wrong. Could you explain why? Because void f(int, int) is not of type candidate expects 0 arguments but it is of expects two which is duplicate of the following t.C:1:17: note: candidate expects 2 arguments, 1 provided void f(); void f(int,int); ^ But that's of course a different bug.
[Bug tree-optimization/52969] [4.7/4.8 Regression] ICE in in get_expr_operands, at tree-ssa-operands.c:1035 with -ftree-loop-if-convert-stores
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52969 --- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2012-04-13 11:39:27 UTC --- Created attachment 27151 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27151 patch
[Bug c++/24985] caret diagnostics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24985 --- Comment #37 from Jonathan Wakely redi at gcc dot gnu.org 2012-04-13 11:50:33 UTC --- I think for Richard's example a nice compromise would be: t.C: In function 'int main()': t.C:5:6: error: no matching function for call to 'f(int)' f(1); ^ note: candidates are: t.C:1:6: note: void f() t.C:1:6: note: candidate expects 0 arguments, 1 provided void f(); void f(int,int); ^ t.C:1:17: note: void f(int, int) t.C:1:17: note: candidate expects 2 arguments, 1 provided void f(); void f(int,int); ^ That includes all the relevant information but removes the duplication caused by printing the same source code and caret after each pair of notes, and the whitespace on the candidates are line instead of location info does help make it look less cluttered. GCC diagnostics do tend to look more densely packed than some other compilers. Caret diagnostics change that, but it's not necessarily an improvement if they just space out every line with duplicated snippets of source and carets.
[Bug c++/24985] caret diagnostics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24985 --- Comment #38 from Jonathan Wakely redi at gcc dot gnu.org 2012-04-13 11:53:31 UTC --- (In reply to comment #36) t.C:1:6: note: candidate expects 0 arguments, 1 provided void f(); void f(int,int); ^ t.C:1:17: note: void f(int, int) void f(); void f(int,int); ^ and the 2nd note here looks wrong. Could you explain why? Because void f(int, int) is not of type candidate expects 0 arguments but it is of expects two which is duplicate of the following t.C:1:17: note: candidate expects 2 arguments, 1 provided void f(); void f(int,int); ^ You're confusing two separate notes. This bit refers to the first overload, which expects 0 args: t.C:1:6: note: candidate expects 0 arguments, 1 provided void f(); void f(int,int); ^ And this bit refers to the second overload: t.C:1:17: note: void f(int, int) void f(); void f(int,int); ^ The line following says expects 2 arguments This is why in my previous comment I suggested removing the caret diagnostic between the related notes, so the notes that refer to the same thing are adjacent.
[Bug c++/24985] caret diagnostics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24985 --- Comment #39 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-04-13 11:54:53 UTC --- (In reply to comment #36) Sounds good to me. But I think GNU conventions require a location here? Well, if that is a hard requirement, I can just suppress the caret. Or we can just not print the note: candidates are:. It seems superfluous info to me. t.C:1:6: note: candidate expects 0 arguments, 1 provided void f(); void f(int,int); ^ t.C:1:17: note: void f(int, int) void f(); void f(int,int); ^ and the 2nd note here looks wrong. Could you explain why? Because void f(int, int) is not of type candidate expects 0 arguments but it is of expects two which is duplicate of the following t.C:1:17: note: candidate expects 2 arguments, 1 provided void f(); void f(int,int); ^ But that's of course a different bug. I see. The problem is that the output is meant to be read as (locations and duplicated carets removed for clarity): note: candidates are: note: candidate #1 is void f() void f(); void f(int,int); ^ note: candidate #1 expects 0 arguments, 1 provided note: candidate #2 is void f(int, int) void f(); void f(int,int); ^ note: candidate #2 expects 2 arguments, 1 provided that is, first print the candidate, then the reason for failure. If you read again the original, the 2nd and 3rd notes go together, like the 4th and 5th, so the output is correct (although I agree that quite confusing). That is why I proposed: note: candidate 'void f()' expects 0 arguments, 1 provided void f(); void f(int,int); ^ note: candidate 'void f(int, int)' expects 2 arguments, 1 provided void f(); void f(int,int); ^ (that is, instead of two notes per candidate, just one). Or we could number the candidates like above.
[Bug c++/24985] caret diagnostics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24985 --- Comment #40 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-04-13 11:58:04 UTC --- I think what Jonathan proposed in comment #37 is also nice. If Jason approves, I will implement it.
[Bug tree-optimization/52969] [4.7/4.8 Regression] ICE in in get_expr_operands, at tree-ssa-operands.c:1035 with -ftree-loop-if-convert-stores
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52969 --- Comment #6 from vincenzo Innocente vincenzo.innocente at cern dot ch 2012-04-13 11:59:59 UTC --- patch applied to latest trunk. success on both cases. thanks. v. p.s. optimizing the if-conversion to produce a single comparison will be appreciated as well
[Bug libstdc++/52604] mt allocator crashes on multi-threaded
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52604 --- Comment #19 from Laurent Aflonsi laurent.alfonsi at st dot com 2012-04-13 12:00:44 UTC --- Author: chrbr Date: Fri Apr 13 11:58:15 2012 New Revision: 186415 Log Message: fix last entry Modified: trunk/libstdc++-v3/ChangeLog
[Bug libstdc++/52604] mt allocator crashes on multi-threaded
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52604 --- Comment #18 from Laurent Aflonsi laurent.alfonsi at st dot com 2012-04-13 12:00:21 UTC --- Author: chrbr Date: Fri Apr 13 11:44:13 2012 New Revision: 186414 Log Message: PR:52604: (~__freelist): Reset pointer Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/src/c++98/mt_allocator.cc
[Bug tree-optimization/52969] [4.7/4.8 Regression] ICE in in get_expr_operands, at tree-ssa-operands.c:1035 with -ftree-loop-if-convert-stores
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52969 --- Comment #7 from rguenther at suse dot de rguenther at suse dot de 2012-04-13 12:04:38 UTC --- On Fri, 13 Apr 2012, vincenzo.innocente at cern dot ch wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52969 --- Comment #6 from vincenzo Innocente vincenzo.innocente at cern dot ch 2012-04-13 11:59:59 UTC --- patch applied to latest trunk. success on both cases. thanks. v. p.s. optimizing the if-conversion to produce a single comparison will be appreciated as well It looks like RTL optimization is able to get rid of the redundant one for the testcase. Do you have a testcase where this obviously not happens? I do have a patch that should address this. Richard.
[Bug c++/24985] caret diagnostics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24985 --- Comment #41 from Jonathan Wakely redi at gcc dot gnu.org 2012-04-13 12:07:01 UTC --- (In reply to comment #39) just not print the note: candidates are:. It seems superfluous info to me. Personally I like the candidates are line, I don't find it superfluous. If there are two erroneous calls: f(1); f(2); the candidates are notes help break up the errors and help me parse them. In real code these lines might be very long and wrap on the screen: t.cc:1:6: note: void f() t.cc:1:6: note: candidate expects 0 arguments, 1 provided The short, concise candidates are line is easy for me to locate quickly and start scanning down the list from there, especially when there is more than one error in the code.
[Bug c++/24985] caret diagnostics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24985 --- Comment #42 from Richard Guenther rguenth at gcc dot gnu.org 2012-04-13 12:08:02 UTC --- (In reply to comment #40) I think what Jonathan proposed in comment #37 is also nice. If Jason approves, I will implement it. Yes, I like that, too. For reference, the following: note: candidate 'void f()' expects 0 arguments, 1 provided void f(); void f(int,int); ^ note: candidate 'void f(int, int)' expects 2 arguments, 1 provided void f(); void f(int,int); ^ I'll approve a patch that implements this.
[Bug c++/24985] caret diagnostics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24985 --- Comment #43 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-04-13 12:15:45 UTC --- (In reply to comment #42) (In reply to comment #40) I think what Jonathan proposed in comment #37 is also nice. If Jason approves, I will implement it. Yes, I like that, too. For reference, the following: note: candidate 'void f()' expects 0 arguments, 1 provided void f(); void f(int,int); ^ note: candidate 'void f(int, int)' expects 2 arguments, 1 provided void f(); void f(int,int); ^ To avoid confusion, that was not what Jonathan proposed in comment #37. I'll approve a patch that implements this. With all due respect, since this is a C++ FE issue, I'll still wait for Jason's opinion before implementing anything. I still appreciate yours (or anyone else) comments. Thanks.
[Bug c++/24985] caret diagnostics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24985 --- Comment #44 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-04-13 12:18:35 UTC --- (In reply to comment #41) (In reply to comment #39) just not print the note: candidates are:. It seems superfluous info to me. Personally I like the candidates are line, I don't find it superfluous. OK, I don't have a strong opinion on this. Let's Jason decide. You seem to agree with me on removing the duplicated location in front of it, per comment #37, am I right?
[Bug tree-optimization/52969] [4.7/4.8 Regression] ICE in in get_expr_operands, at tree-ssa-operands.c:1035 with -ftree-loop-if-convert-stores
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52969 --- Comment #8 from Richard Guenther rguenth at gcc dot gnu.org 2012-04-13 12:22:25 UTC --- Author: rguenth Date: Fri Apr 13 12:22:16 2012 New Revision: 186416 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=186416 Log: 2012-04-13 Richard Guenther rguent...@suse.de PR tree-optimization/52969 * tree-if-conv.c (predicate_mem_writes): Properly gimplify the condition for the COND_EXPR and handle predicate negation by swapping the COND_EXPR arms. * gcc.dg/torture/pr52969.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr52969.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-if-conv.c
[Bug c++/24985] caret diagnostics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24985 --- Comment #45 from Jonathan Wakely redi at gcc dot gnu.org 2012-04-13 12:24:30 UTC --- (In reply to comment #42) Yes, I like that, too. For reference, the following: note: candidate 'void f()' expects 0 arguments, 1 provided void f(); void f(int,int); ^ note: candidate 'void f(int, int)' expects 2 arguments, 1 provided void f(); void f(int,int); ^ I like this for this example, but does it work as well if the function name is very long, and the expects 2 arguments, 1 provided is no longer in a predictable position, but pushed off to the right of a very long line? t.cc: In function 'int main()': t.cc:10:25: error: no matching function for call to 'a_long_function_name(int)' t.cc:10:25: note: candidates are: t.cc:5:6: note: void a_long_function_name() t.cc:5:6: note: candidate expects 0 arguments, 1 provided t.cc:6:6: note: void a_long_function_name(something_verbose::my_very_long_type, something_verbose::my_very_long_type) t.cc:6:6: note: candidate expects 2 arguments, 1 provided would become t.cc: In function 'int main()': t.cc:10:25: error: no matching function for call to 'a_long_function_name(int)' a_long_function_name(1); ^ t.cc:10:25: note: candidates are: t.cc:5:6: note: candidate 'void a_long_function_name()' expects 0 arguments, 1 provided void a_long_function_name(); ^ t.cc:6:6: note: candidate 'void a_long_function_name(something_verbose::my_very_long_type, something_verbose::my_very_long_type)' expects 2 arguments, 1 provided void a_long_function_name(something_verbose::my_very_long_type, something_verbose::my_very_long_type); ^ (we do already have this problem when printing ridiculous paths for stdlib headers with superfluous lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../.. rubbish in them, is there an existing bug for that?)
[Bug tree-optimization/52969] [4.7/4.8 Regression] ICE in in get_expr_operands, at tree-ssa-operands.c:1035 with -ftree-loop-if-convert-stores
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52969 --- Comment #9 from Richard Guenther rguenth at gcc dot gnu.org 2012-04-13 12:27:11 UTC --- Author: rguenth Date: Fri Apr 13 12:27:02 2012 New Revision: 186417 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=186417 Log: 2012-04-13 Richard Guenther rguent...@suse.de PR tree-optimization/52969 * tree-if-conv.c (predicate_mem_writes): Properly gimplify the condition for the COND_EXPR and handle predicate negation by swapping the COND_EXPR arms. * gcc.dg/torture/pr52969.c: New testcase. Added: branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/torture/pr52969.c Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/testsuite/ChangeLog branches/gcc-4_7-branch/gcc/tree-if-conv.c
[Bug c++/24985] caret diagnostics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24985 --- Comment #46 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-04-13 12:31:41 UTC --- (In reply to comment #45) (In reply to comment #42) Yes, I like that, too. For reference, the following: note: candidate 'void f()' expects 0 arguments, 1 provided void f(); void f(int,int); ^ note: candidate 'void f(int, int)' expects 2 arguments, 1 provided void f(); void f(int,int); ^ I like this for this example, but does it work as well if the function name is very long, and the expects 2 arguments, 1 provided is no longer in a predictable position, but pushed off to the right of a very long line? I see your point, I am convinced. (we do already have this problem when printing ridiculous paths for stdlib headers with superfluous lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../.. rubbish in them, is there an existing bug for that?) Please open one with a reproducible testcase and I will take a look. This is very annoying to me as well, and there should be a way to make these paths shorter.
[Bug tree-optimization/52969] [4.7/4.8 Regression] ICE in in get_expr_operands, at tree-ssa-operands.c:1035 with -ftree-loop-if-convert-stores
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52969 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #10 from Richard Guenther rguenth at gcc dot gnu.org 2012-04-13 12:34:43 UTC --- Fixed.
[Bug regression/52973] New: visibility attribute for class is not passed to its members
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52973
Bug #: 52973
Summary: visibility attribute for class is not passed to its
members
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: regression
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: holger.h...@sap.com
In following code, gcc-4.7 does not accept the visibility attribute
defined in the class declaration:
template class T class __attribute__((visibility(default))) a
{
public:
/* A */ static int c;
};
class __attribute__((visibility(default))) b : a b {};
template /* B */ int ab::c = 0;
With g++-4.7, ab::c is hidden, with g++-4.6 (and before) it is not.
$ g++-4.7 -fvisibility=hidden -c def.cpp objdump -Ct def.o | grep ab
g O .bss0004 .hidden ab::c
$ g++-4.6 -fvisibility=hidden -c def.cpp objdump -Ct def.o | grep ab
g O .bss0004 ab::c
Setting the default visibility at /* A */ or /* B */ works with
g++-4.7, but I think that it still should work also with the code above.
[Bug c++/52973] [4.7/4.8 Regression] visibility attribute for class is not passed to its members
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52973 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Component|regression |c++ Known to work||4.6.3 Target Milestone|--- |4.7.1 Summary|visibility attribute for|[4.7/4.8 Regression] |class is not passed to its |visibility attribute for |members |class is not passed to its ||members
[Bug target/49069] [4.6/4.7/4.8 Regression] ICE in gen_cstoredi4, at config/arm/arm.md:7554
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49069 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2
[Bug ada/52123] [4.7/4.8 Regression] gcc bootstrap with ada fails on mingw target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52123 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4
[Bug c++/51214] [4.7/4.8 Regression] [C++11] name lookup issue with c++11 enums
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51214 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2
[Bug c++/52465] [4.7 Regression] g++ rejects valid code with in-class using declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52465 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2 Known to work||4.8.0 Summary|[4.7/4.8 regression] g++|[4.7 Regression] g++ |rejects valid code with |rejects valid code with |in-class using declaration |in-class using declaration --- Comment #7 from Richard Guenther rguenth at gcc dot gnu.org 2012-04-13 12:56:24 UTC --- Fixed on trunk sofar.
[Bug target/52555] [4.6/4.7/4.8 Regression] ICE unrecognizable insn with -ffast-math and __attribute__((optimize(xx)))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52555 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2
[Bug rtl-optimization/52573] [4.5/4.6/4.7/4.8 regression] regrename creates overlapping register allocations for output operands
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52573 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2
[Bug middle-end/52621] [4.6/4.7 Regression] ICE with -O3 -march=opteron in initialize_matrix_A, at tree-data-ref.c:1964
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52621 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2
[Bug rtl-optimization/52573] [4.5/4.6/4.7/4.8 regression] regrename creates overlapping register allocations for output operands
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52573 --- Comment #2 from Bernd Schmidt bernds at gcc dot gnu.org 2012-04-13 13:02:03 UTC --- (expr_list:REG_DEAD (reg:SI 3 %d3 [236]) (expr_list:REG_UNUSED (reg:SI 3 %d3 [236]) The REG_DEAD note is bogus and confuses the renamer. Only REG_UNUSED should be on this insn.
[Bug tree-optimization/52969] [4.7/4.8 Regression] ICE in in get_expr_operands, at tree-ssa-operands.c:1035 with -ftree-loop-if-convert-stores
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52969 --- Comment #11 from vincenzo Innocente vincenzo.innocente at cern dot ch 2012-04-13 13:03:48 UTC --- I do not have a clear case in hand with evidence of double compare I will have a closer look to real life code. btw I just noticed that your test case does not vectorize even if I rewrite as for (; a ; ++j) xsum[j] = (cluster[j] 0.) ? 0. : cluster[j]; any idea why? c++ -O3 -c ifconv.cc -ftree-loop-if-convert-stores -ftree-vectorizer-verbose=9 Analyzing loop at ifconv.cc:10 10: = analyze_loop_nest = 10: === vect_analyze_loop_form === 10: not vectorized: control flow in loop. 10: bad loop form. ifconv.cc:3: note: vectorized 0 loops in function. pb-d-128-141-131-26:bugs48 innocent$ c++ -O3 -c ifconv.cc -ftree-loop-if-convert-stores -ftree-vectorizer-verbose=9 Analyzing loop at ifconv.cc:10 10: = analyze_loop_nest = 10: === vect_analyze_loop_form === 10: not vectorized: control flow in loop. 10: bad loop form. ifconv.cc:3: note: vectorized 0 loops in function. pb-d-128-141-131-26:bugs48 innocent$ c++ -Ofast -c ifconv.cc -ftree-loop-if-convert-stores -ftree-vectorizer-verbose=9 Analyzing loop at ifconv.cc:10 10: = analyze_loop_nest = 10: === vect_analyze_loop_form === 10: not vectorized: multiple exits. 10: bad loop form. ifconv.cc:3: note: vectorized 0 loops in function. pb-d-128-141-131-26:bugs48 innocent$ c++ -Ofast -c ifconv.cc -ftree-vectorizer-verbose=9 Analyzing loop at ifconv.cc:10 10: = analyze_loop_nest = 10: === vect_analyze_loop_form === 10: not vectorized: multiple exits. 10: bad loop form. ifconv.cc:3: note: vectorized 0 loops in function.
[Bug tree-optimization/52631] [4.6/4.7/4.8 Regression] VN does not use simplified expression for lookup
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52631 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2 Known to work||4.3.6 --- Comment #7 from Richard Guenther rguenth at gcc dot gnu.org 2012-04-13 13:10:04 UTC --- That looks good apart from the use of valid_gimple_rhs_p which allows too much. I'd rather use get_gimple_rhs_class (TREE_CODE (simplified)) and allow GIMPLE_UNARY_RHS, GIMPLE_BINARY_RHS and GIMPLE_TERNARY_RHS here.
[Bug tree-optimization/52633] [4.7/4.8 Regression] Compiler ICE in vect_is_simple_use_1 (ARM)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52633 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2 Summary|[4.7 Regression] Compiler |[4.7/4.8 Regression] |ICE in vect_is_simple_use_1 |Compiler ICE in |(ARM) |vect_is_simple_use_1 (ARM) --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-04-13 13:10:40 UTC --- I suppose also broken on trunk.
[Bug debug/52727] [4.7 Regression] internal compiler error at dwarf2cfi.c2:685
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52727 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2 Known to work||4.8.0 Summary|[4.7/4.8 Regression]|[4.7 Regression] internal |internal compiler error at |compiler error at |dwarf2cfi.c2:685|dwarf2cfi.c2:685 --- Comment #16 from Richard Guenther rguenth at gcc dot gnu.org 2012-04-13 13:13:06 UTC --- Fixed on trunk sofar.
[Bug fortran/52864] [4.6/4.7/4.8 Regression] Assignment to pointer component for INTENT(IN) dummy argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52864 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4
[Bug c++/52841] [4.7/4.8 Regression] error: type 'Solvable' is not a base type for type 'Resolvable'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52841 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2
[Bug c++/52974] New: Canonicalize include paths in diagnostics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52974
Bug #: 52974
Summary: Canonicalize include paths in diagnostics
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
CC: m...@gcc.gnu.org
#include algorithm
void f() { std::sort(1); }
The diagnostics caused by misuse of the standard library are ridiculous:
t.cc: In function 'void f()':
t.cc:2:23: error: no matching function for call to 'sort(int)'
t.cc:2:23: note: candidates are:
In file included from
/home/redi/gcc/4.x/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../include/c++/4.8.0/algorithm:63:0,
from t.cc:1:
/home/redi/gcc/4.x/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../include/c++/4.8.0/bits/stl_algo.h:5420:5:
note: templateclass _RAIter void std::sort(_RAIter, _RAIter)
/home/redi/gcc/4.x/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../include/c++/4.8.0/bits/stl_algo.h:5420:5:
note: template argument deduction/substitution failed:
t.cc:2:23: note: candidate expects 2 arguments, 1 provided
In file included from
/home/redi/gcc/4.x/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../include/c++/4.8.0/algorithm:63:0,
from t.cc:1:
/home/redi/gcc/4.x/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../include/c++/4.8.0/bits/stl_algo.h:5456:5:
note: templateclass _RAIter, class _Compare void std::sort(_RAIter, _RAIter,
_Compare)
/home/redi/gcc/4.x/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../include/c++/4.8.0/bits/stl_algo.h:5456:5:
note: template argument deduction/substitution failed:
t.cc:2:23: note: candidate expects 3 arguments, 1 provided
Users don't care that the include path is
$PREFIX/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../include/c++/4.8.0
The paths should be canonicalized using realpath(3) to simply
/home/redi/gcc/4.x/include/c++/4.8.0/algorithm and
/home/redi/gcc/4.x/include/c++/4.8.0/bits/stl_algo.h
This probably isn't a good idea for user headers, as the include path they use
with -I should be preserved so they recognise it, but for GCC's own C++ headers
(and possibly all system headers?) it would be a huge improvement.
[Bug c++/52974] Canonicalize include paths in diagnostics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52974 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2012-04-13 13:16:01 UTC --- The canonicalized version of that error is a lot more readable t.cc: In function 'void f()': t.cc:2:23: error: no matching function for call to 'sort(int)' t.cc:2:23: note: candidates are: In file included from /home/redi/gcc/4.x/include/c++/4.8.0/algorithm:63:0, from t.cc:1: /home/redi/gcc/4.x/include/c++/4.8.0/bits/stl_algo.h:5420:5: note: templateclass _RAIter void std::sort(_RAIter, _RAIter) /home/redi/gcc/4.x/include/c++/4.8.0/bits/stl_algo.h:5420:5: note: template argument deduction/substitution failed: t.cc:2:23: note: candidate expects 2 arguments, 1 provided In file included from /home/redi/gcc/4.x/include/c++/4.8.0/algorithm:63:0, from t.cc:1: /home/redi/gcc/4.x/include/c++/4.8.0/bits/stl_algo.h:5456:5: note: templateclass _RAIter, class _Compare void std::sort(_RAIter, _RAIter, _Compare) /home/redi/gcc/4.x/include/c++/4.8.0/bits/stl_algo.h:5456:5: note: template argument deduction/substitution failed: t.cc:2:23: note: candidate expects 3 arguments, 1 provided
[Bug c++/52906] [4.7 Regression] ICE: SIGSEGV in check_tag_decl (decl.c:4230) with __attribute__ ((__deprecated__)); alone
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52906 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2 Known to work||4.8.0 Summary|[4.7/4.8 Regression] ICE: |[4.7 Regression] ICE: |SIGSEGV in check_tag_decl |SIGSEGV in check_tag_decl |(decl.c:4230) with |(decl.c:4230) with |__attribute__ |__attribute__ |((__deprecated__)); alone |((__deprecated__)); alone Known to fail|4.8.0 | --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-04-13 13:15:41 UTC --- Fixed on trunk sofar.
[Bug middle-end/52939] [4.7/4.8 Regression] ice in gimple_get_virt_method_for_binfo with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52939 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2
[Bug bootstrap/52947] [4.7/4.8 Regression] bootstrap fails due to wrong include search path composition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52947 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2
[Bug tree-optimization/52734] [4.7/4.8 Regression] Incorrect optimization of uClibc sbrk()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52734 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2
[Bug c++/52973] [4.7/4.8 Regression] visibility attribute for class is not passed to its members
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52973 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2
[Bug tree-optimization/52868] [4.7/4.8 Regression] 4.6 is faster on Atom
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52868 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2
[Bug tree-optimization/52969] [4.7/4.8 Regression] ICE in in get_expr_operands, at tree-ssa-operands.c:1035 with -ftree-loop-if-convert-stores
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52969 --- Comment #12 from Richard Guenther rguenth at gcc dot gnu.org 2012-04-13 13:26:59 UTC --- (In reply to comment #11) I do not have a clear case in hand with evidence of double compare I will have a closer look to real life code. btw I just noticed that your test case does not vectorize even if I rewrite as for (; a ; ++j) xsum[j] = (cluster[j] 0.) ? 0. : cluster[j]; any idea why? It's because of the loop exit condition which we realize makes the loop execute at most once. If you rewrite it to for (; j a; ++j) then it works.
[Bug rtl-optimization/52975] New: Ofast produces not optimized code for vectorized converted if
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52975
Bug #: 52975
Summary: Ofast produces not optimized code for vectorized
converted if
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vincenzo.innoce...@cern.ch
this is a modified version of
gcc/testsuite/gcc.dg/torture/pr52969.c
notice
cmpps$0x1,%xmm2,%xmm1
cmpps$0x2,%xmm3,%xmm0
in case of Ofast
similar with -march=corei7 when blendv is generated
cat ifconv2.cc
int b;
float xsum[100];
float clus[100];
void bar2 ()
{
int j=0;
for (; j100 ; ++j) {
xsum[j] = clus[j];
if (xsum[j] 0)
xsum[j] = 0;
// xsum[j] = (clus[j] 0.) ? 0. : clus[j];
}
if (xsum[0])
b = 0;
}
pb-d-128-141-131-26:bugs48 innocent$ c++ -O3 -c ifconv2.cc
-ftree-loop-if-convert-stores -ftree-vectorizer-verbose=2
Analyzing loop at ifconv2.cc:7
Vectorizing loop at ifconv2.cc:7
7: LOOP VECTORIZED.
ifconv2.cc:4: note: vectorized 1 loops in function.
pb-d-128-141-131-26:bugs48 innocent$ otool -t -X -v ifconv2.o
__Z4bar2v:
leaq0x(%rip),%rax
xorps%xmm2,%xmm2
leaq0x(%rip),%rdx
leaq0x0190(%rip),%rcx
nopl0x(%rax,%rax)
movaps(%rax),%xmm1
movaps%xmm2,%xmm0
addq$0x10,%rax
cmpps$0x1,%xmm1,%xmm0
andnps%xmm1,%xmm0
movaps%xmm0,(%rdx)
addq$0x10,%rdx
cmpq%rcx,%rax
jne0x0020
xorps%xmm0,%xmm0
ucomiss0x(%rip),%xmm0
jnp0x0054
movl$0x,0xfffc(%rip)
ret
jne0x0049
repz/ret
pb-d-128-141-131-26:bugs48 innocent$ c++ -Ofast -c ifconv2.cc
-ftree-loop-if-convert-stores -ftree-vectorizer-verbose=2
Analyzing loop at ifconv2.cc:7
Vectorizing loop at ifconv2.cc:7
7: LOOP VECTORIZED.
ifconv2.cc:4: note: vectorized 1 loops in function.
pb-d-128-141-131-26:bugs48 innocent$ otool -t -X -v ifconv2.o
__Z4bar2v:
leaq0x(%rip),%rdx
xorps%xmm3,%xmm3
leaq0x(%rip),%rax
leaq0x0190(%rip),%rcx
nopl0x(%rax,%rax)
movaps(%rdx),%xmm2
movaps%xmm3,%xmm1
addq$0x10,%rdx
movaps%xmm2,%xmm0
cmpps$0x1,%xmm2,%xmm1
cmpps$0x2,%xmm3,%xmm0
andnps(%rax),%xmm1
andps%xmm0,%xmm2
andnps%xmm1,%xmm0
orps%xmm2,%xmm0
movaps%xmm0,(%rax)
addq$0x10,%rax
cmpq%rcx,%rdx
jne0x0020
xorps%xmm0,%xmm0
comiss0x(%rip),%xmm0
je0x0063
movl$0x,0xfffc(%rip)
repz/ret
[Bug fortran/52968] [OOP] Call to type-bound procedure produces wrongly rejected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52968 janus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |janus at gcc dot gnu.org |gnu.org | Summary|Call to type-bound |[OOP] Call to type-bound |procedure produces wrongly |procedure produces wrongly |rejected|rejected --- Comment #2 from janus at gcc dot gnu.org 2012-04-13 13:32:00 UTC --- (In reply to comment #1) Next, one tries to match % Evaluate as type-bound procedure: if (sym-f2k_derived) tbp = gfc_find_typebound_proc (sym, t, name, false, gfc_current_locus); However, the class container does not have f2k_derived - only the _data component has. Right. The class container's f2k_derived should be set up in 'gfc_build_class_symbol'. However, this is called before the type 'EquationTemplate' is available, and setting up the f2k_derived fails for this reason. Patch: Index: gcc/fortran/class.c === --- gcc/fortran/class.c(revision 186413) +++ gcc/fortran/class.c(working copy) @@ -541,8 +541,7 @@ gfc_build_class_symbol (gfc_typespec *ts, symbol_a fclass-refs++; fclass-ts.type = BT_UNKNOWN; fclass-attr.abstract = ts-u.derived-attr.abstract; - if (ts-u.derived-f2k_derived) -fclass-f2k_derived = gfc_get_namespace (NULL, 0); + fclass-f2k_derived = gfc_get_namespace (NULL, 0); if (gfc_add_flavor (fclass-attr, FL_DERIVED, NULL, gfc_current_locus) == FAILURE) return FAILURE; This makes the test case compile correctly (and is free of testsuite regressions).
[Bug tree-optimization/52969] [4.7/4.8 Regression] ICE in in get_expr_operands, at tree-ssa-operands.c:1035 with -ftree-loop-if-convert-stores
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52969 --- Comment #13 from vincenzo Innocente vincenzo.innocente at cern dot ch 2012-04-13 13:35:19 UTC --- Richard, please, look at PR59275. I think your testcase CAN produce not optimized code.
[Bug libstdc++/52938] std::string::reserve request is not maintained if object is used in other object copy ctor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52938 --- Comment #14 from Abdul Tohmaz abdul.tohmaz at emc dot com 2012-04-13 13:37:47 UTC --- (In reply to comment #13) Immediately after you call reserve it returns at least 1024. But not necessarily from that point on for ever and ever. If you call swap() to exchange it with another string it's capacity could shrink, or in C++11 if you move assign another string to it its capacity could change. Or, in C++03 for reference-counted strings, it could change because the previously-shared string is no longer shared. This is a pointless discussion anyway, it's not going to change. I agree with you on this discussion being pointless. I am looking at this from the end user perspective and what the standards dictates while you are looking at from the way gcc implements string. Your point about C++11 doesn't apply here (completely different ball game). The standard doesn't say anything about capacity for swap (21.3.5.8). The user expects the standard to be followed and when it says that capacity to be = to the reserve argument, he certainly expects that. Unless you can show me somewhere in the standards where it says the requested capacity via reserve calls may be affected by copy constructor in the case an implementer chose to use copy-on-write. That is all I ask.
[Bug c++/52974] Canonicalize include paths in diagnostics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52974 --- Comment #2 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-04-13 13:42:51 UTC --- (In reply to comment #0) This probably isn't a good idea for user headers, as the include path they use with -I should be preserved so they recognise it, but for GCC's own C++ headers (and possibly all system headers?) it would be a huge improvement. System headers are easy to detect, but what is GCC's own C++ headers? How can one detect those?
[Bug c++/52974] Canonicalize include paths in diagnostics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52974 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2012-04-13 13:55:27 UTC --- I don't know where they're defined but they're built in and g++ -v shows them #include ... search starts here: #include ... search starts here: /home/redi/gcc/4.x/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../include/c++/4.8.0 /home/redi/gcc/4.x/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../include/c++/4.8.0/x86_64-unknown-linux-gnu /home/redi/gcc/4.x/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../include/c++/4.8.0/backward /home/redi/gcc/4.x/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/include /usr/local/include /home/redi/gcc/4.x/include /home/redi/gcc/4.x/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/include-fixed /usr/include End of search list. The C++ headers are the only ones that need canonicalizing.
[Bug middle-end/52939] [4.7/4.8 Regression] ice in gimple_get_virt_method_for_binfo with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52939 Martin Jambor jamborm at gcc dot gnu.org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc-p ||atches/2012-04/msg00835.htm ||l --- Comment #5 from Martin Jambor jamborm at gcc dot gnu.org 2012-04-13 13:55:31 UTC --- Bah, I posted the patch to fix this with a wrong subject but there it is: http://gcc.gnu.org/ml/gcc-patches/2012-04/msg00835.html
[Bug fortran/52968] [OOP] Call to type-bound procedure wrongly rejected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52968 --- Comment #3 from janus at gcc dot gnu.org 2012-04-13 14:02:05 UTC --- This bug is similar to PR51995, and in fact the patch from comment #2 above seems to supersede the solution given there (which could be removed as a consequence): Index: gcc/fortran/class.c === --- gcc/fortran/class.c(revision 186413) +++ gcc/fortran/class.c(working copy) @@ -541,8 +541,7 @@ gfc_build_class_symbol (gfc_typespec *ts, symbol_a fclass-refs++; fclass-ts.type = BT_UNKNOWN; fclass-attr.abstract = ts-u.derived-attr.abstract; - if (ts-u.derived-f2k_derived) -fclass-f2k_derived = gfc_get_namespace (NULL, 0); + fclass-f2k_derived = gfc_get_namespace (NULL, 0); if (gfc_add_flavor (fclass-attr, FL_DERIVED, NULL, gfc_current_locus) == FAILURE) return FAILURE; @@ -579,8 +578,6 @@ gfc_build_class_symbol (gfc_typespec *ts, symbol_a c-attr.access = ACCESS_PRIVATE; c-attr.pointer = 1; } - else if (!fclass-f2k_derived) -fclass-f2k_derived = gfc_get_namespace (NULL, 0); /* Since the extension field is 8 bit wide, we can only have up to 255 extension levels. */
[Bug tree-optimization/52975] Ofast produces not optimized code for vectorized converted if
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52975 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Keywords||missed-optimization Last reconfirmed||2012-04-13 Component|rtl-optimization|tree-optimization AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-04-13 14:05:12 UTC --- Yes, I noticed this. For scalar code we can handle the mess caused by if-conversion in RTL optimization, for vectorized code we cannot. I have a patch that fixes it for -O3 at least - for -Ofast we run foul of if-conversion changing the conditions from 0.0 to = 0.0 on the else branch. I'll think about the best way of dealing with that.
[Bug fortran/51082] [F03] Wrong result for a pointer to a proc-pointer component
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51082 --- Comment #3 from janus at gcc dot gnu.org 2012-04-13 14:23:25 UTC --- Note: The patch in comment #2 regtests cleanly.
[Bug libstdc++/52604] mt allocator crashes on multi-threaded
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52604 --- Comment #20 from Paolo Carlini paolo.carlini at oracle dot com 2012-04-13 14:45:29 UTC --- Remember to always send the patches you commit to gcc-patc...@gcc.gnu.org (and libstd...@gcc.gnu.org in CC), even if already approved on the fly in audit trail (which should not happen very frequently) PS: are you aware that your name family name in the email address and as email sender do not match? ;)
[Bug tree-optimization/52976] New: [4.8 Regression] Revision 186384 breaks the polyhedron tests aermod.f90 and doduc.f90 at -O3 -ffast-math
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52976 Bug #: 52976 Summary: [4.8 Regression] Revision 186384 breaks the polyhedron tests aermod.f90 and doduc.f90 at -O3 -ffast-math Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: domi...@lps.ens.fr CC: rgue...@gcc.gnu.org, tkoe...@gcc.gnu.org, wschm...@gcc.gnu.org On powerpc-apple-darwin9 and x86_64-apple-darwin10, the polyhedron tests aermod.f90 and doduc.f90 are broken after revision 186384 at -O3 -ffast-math: [macbook] lin/test% gfc -O3 -ffast-math -fno-tree-vectorize aermod.f90 aermod.f90: In function 'grdurban': aermod.f90:27214:0: error: definition in block 9 follows the use SUBROUTINE GRDURBAN ^ for SSA_NAME: reassocpow.22077_36 in statement: D.56565_32 = D.56564_31 * reassocpow.22077_36; aermod.f90:27214:0: internal compiler error: verify_ssa failed SUBROUTINE GRDURBAN ^ [macbook] lin/test% gfc -O3 -ffast-math -fno-tree-vectorize doduc.f90 doduc.f90: In function 's55199': doduc.f90:4384:0: internal compiler error: gimple check: expected gimple_assign(error_mark), have gimple_call() in gimple_assign_rhs1, at gimple.h:1850 SUBROUTINE S55199(H,P,T,Rho,Dvdhp,Dvdph,Dtdh,Dtdp) ^ The SUBROUTINE S55199 can be reduced to SUBROUTINE S55199(P,Dvdph) implicit none real(8) :: c1,c2,c3,P,Dvdph c1=0.1d0 c2=0.2d0 c3=0.3d0 Dvdph = c1 + 2.*P*c2 + 3.*P**2*c3 END which gives the following ICE at r186417 [macbook] test/doduc_tst% gfc -O3 -ffast-math -fno-tree-vectorize s55199_red.f90 -c s55199_red.f90: In function 's55199': s55199_red.f90:1:0: internal compiler error: gimple check: expected gimple_assign(error_mark), have gimple_call() in gimple_assign_rhs1, at gimple.h:1850 SUBROUTINE S55199(P,Dvdph) ^ or s55199_red.f90: In function 's55199': s55199_red.f90:1:0: internal compiler error: in zero_one_operation, at tree-ssa-reassoc.c:1041 SUBROUTINE S55199(P,Dvdph) ^ for gcc configured with --enable-checking=release.
[Bug debug/51570] [4.7/4.8 Regression] FAIL: gcc.dg/guality/pr45003-[23].c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51570 --- Comment #7 from Alexandre Oliva aoliva at gcc dot gnu.org 2012-04-13 15:56:00 UTC --- Author: aoliva Date: Fri Apr 13 15:55:52 2012 New Revision: 186420 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=186420 Log: PR debug/51570 * var-tracking.c (expand_depth): New type. (onepart_aux, expand_loc_callback_data): Change depth type to it. (loc_exp_dep_alloc): Adjust initializer. (update_depth): Use new type. Add entryvals. (vt_expand_var_loc_chain): Take note of expansions with ENTRY_VALUEs, but don't accept them right away. Run an optional second pass accepting the minimum ENTRY_VALUE count found in the first pass. (vt_expand_loc_callback, INIT_ELCD): Adjust. Modified: trunk/gcc/ChangeLog trunk/gcc/var-tracking.c
[Bug debug/48866] gcc hangs when -g is set
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48866 --- Comment #12 from Alexandre Oliva aoliva at gcc dot gnu.org 2012-04-13 15:56:29 UTC --- Author: aoliva Date: Fri Apr 13 15:56:21 2012 New Revision: 186422 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=186422 Log: PR debug/48866 * df.h (enum debug_temp_where): New. (dead_debug_init, dead_debug_finish) Declare. (dead_debug_add, dead_debug_insert_temp): Declare. (struct dead_debug_use, struct dead_debug): Moved from... * df-problems.c: ... here. (df_set_unused_notes_for_mw): Bind debug uses of unused regno to a debug temp. (df_create_unused_note): Likewise. (df_set_dead_notes_for_mw): Move comment where it belongs. (dead_debug_init): Export. (dead_debug_reset_uses): New, factored out of... (dead_debug_finish): ...this. Export. (dead_debug_reset): Remove. (dead_debug_add): Export. (dead_debug_insert_before): Rename to... (dead_debug_insert_temp): ... this. Add where argument. Export. Locate stored value for BEFORE_WITH_VALUE. Avoid repeat inserts. Return insertion count. (df_note_bb_compute): Adjust. * dce.c (word_dce_process_block): Adjust dead debug uses. (dce_process_block): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/dce.c trunk/gcc/df-problems.c trunk/gcc/df.h
[Bug c/52977] New: internal compiler error: Segmentation fault with `-x c-header' or `-x cxx-header' option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52977
Bug #: 52977
Summary: internal compiler error: Segmentation fault with `-x
c-header' or `-x cxx-header' option
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ai.az...@gmail.com
Created attachment 27152
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27152
Output of -v option and preprocessed file
The following code causes an ICE with GCC 4.8.0 20120408 (experimental) and `-x
c-header' or `-x cxx-header' option.
typedef int __m64 __attribute__ ((__vector_size__ (8), __may_alias__));
__inline __m64 __attribute__((__gnu_inline__, __always_inline__,
__artificial__))
_mm_setzero_si64() { return (__m64)0LL; }
N.B. As far as I can confirm, this ICE is not reproduced with GCC 4.6.3, GCC
4.7.0 and GCC 4.8.0 20120311. This reproducer originally comes from a
Boost.Math 1.49.0 source file.
[Bug c++/52951] internal compiler error with c++11 initializer lists and C arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52951 --- Comment #2 from D W drwowe at yahoo dot com 2012-04-13 16:22:28 UTC --- I built gcc from gcc-4_7-branch, svn186417. I can confirm it does not segfault on my example.
[Bug c++/52972] Pure virtual method is called instead of child's method
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52972 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-04-13 16:24:07 UTC --- I think you are getting the correct behavior as the vtable for the base class is the current vtable for this. And return static_cast Real* (this); Does not change the vtable of the return class.
[Bug c++/52972] Pure virtual method is called instead of child's method
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52972 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2012-04-13 16:27:44 UTC --- right, during the base constructor the derived class hasn't been constructed yet and you can't call its virtual functions
[Bug c++/52972] Pure virtual method is called instead of child's method
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52972 --- Comment #3 from drinob at gmail dot com 2012-04-13 16:28:36 UTC --- Yes, this is my mistake.
[Bug c++/52978] New: Inherit from Template with specified type and override virtual function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52978
Bug #: 52978
Summary: Inherit from Template with specified type and override
virtual function
Classification: Unclassified
Product: gcc
Version: 4.5.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: benedikt...@aon.at
Created attachment 27153
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27153
preprocessed file
I tried to inherit from an template, but with an specified type. In this
derived class a virtual function from the base (the template class) is
overriden. During compile gcc complains about a pure virtual function if I try
to instantiate an object from the derived type.
I compiled the code with the following statement:
gcc -Wall -Wextra -save-temps -lstdc++ main.cpp
The code looks like this:
#include stdio.h
templateclass T
class Foo
{
public:
virtual void blub(const T value) const = 0;
};
class Bar : public Fooint*
{
public:
virtual void blub(const int* value) const
{
printf(\n%i\n, *value);
}
};
int main(int argc, char **argv)
{
Bar bar;
const int *one = new int;
bar.blub(one);
return 0;
}
The output from the compiler was that:
main.cpp: In Funktion »int main(int, char**)«:
main.cpp:21:7: Fehler: Variable »bar« kann nicht als vom abstrakten Typ »Bar«
deklariert werden
main.cpp:11:1: Anmerkung: because the following virtual functions are pure
within »Bar«:
main.cpp:7:20: Anmerkung: void FooT::blub(const T) const [with T =
int*]
main.cpp: At global scope:
main.cpp:19:5: Warnung: unbenutzter Parameter »argc«
main.cpp:19:5: Warnung: unbenutzter Parameter »argv«
make: *** [all] Fehler 1
Im running gcc version 4.5.3-r2 on Gentoo.
[Bug c/52979] New: likely wrong code bug w/packed bitfields
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52979
Bug #: 52979
Summary: likely wrong code bug w/packed bitfields
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: reg...@cs.utah.edu
CC: cheny...@cs.utah.edu
[regehr@dyson r30]$ current-gcc -O2 small.c ; ./a.out
0
[regehr@dyson r30]$ current-gcc -O3 small.c ; ./a.out
1
[regehr@dyson r30]$ cat small.c
int printf (const char *, ...);
int c, d, e;
void fn1 ()
{
}
#pragma pack(1)
struct S1
{
int f0:31;
int f1:6;
}
a = { 1 };
static struct S1 b = { 1 };
void fn2 ()
{
for (;;)
{
a.f1 = 1;
struct S1 f = { };
b = f;
e = 0;
if (d)
c = a.f0;
break;
}
}
void fn3 ()
{
fn2 ();
a = b;
}
int main (void)
{
fn3 ();
printf (%d\n, a.f0);
return 0;
}
[regehr@dyson r30]$ current-gcc -v
Using built-in specs.
COLLECT_GCC=current-gcc
COLLECT_LTO_WRAPPER=/uusoc/exports/scratch/regehr/z/compiler-install/gcc-r186403-install/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --with-libelf=/usr/local --enable-lto
--prefix=/home/regehr/z/compiler-install/gcc-r186403-install
--program-prefix=r186403- --enable-languages=c,c++
Thread model: posix
gcc version 4.8.0 20120413 (experimental) (GCC)
[Bug c++/52972] Pure virtual method is called instead of child's method
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52972 --- Comment #4 from drinob at gmail dot com 2012-04-13 16:35:35 UTC --- But it seems to work in g++ 4.3 (which is used at ideone.com): http://ideone.com/zy5R4 Is that behavior uncorrect?
[Bug target/52932] AVX2 intrinsic _mm256_permutevar8x32_ps has wrong parameter type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52932 --- Comment #10 from Agner Fog agner at agner dot org 2012-04-13 16:50:33 UTC --- _mm256_permutevar8x32_epi32 has the operands in wrong order. They need to be swapped. Did you fix this too? On 12-04-2012 20:37, uros at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52932 --- Comment #9 from uros at gcc dot gnu.org 2012-04-12 18:37:47 UTC --- Author: uros Date: Thu Apr 12 18:37:42 2012 New Revision: 186388 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=186388 Log: PR target/52932 * config/i386/avx2intrin.h (_mm256_permutevar8x32_ps): Change second argument type to __m256i. Update call to __builtin_ia32_permvarsf256. * config/i386/sse.md (UNSPEC_VPERMVAR): New. (UNSPEC_VPERMSI, UNSPEC_VPERMSF): Remove. (avx2_permvarv8sf, avx2_permvarv8si): Switch operands 1 and 2. (avx2_permvarmode): Macroize insn from avx2_permvarv8sf and avx2_permvarv8si using VI4F_256 mode iterator. * config/i386/i386.c (bdesc_args)__builtin_ia32_permvarsf256: Update builtin type to V8SF_FTYPE_V8SF_V8SI. (ix86_expand_vec_perm): Update calls to gen_avx2_permvarv8si and gen_avx2_permvarv8sf. (expand_vec_perm_pshufb): Ditto. testsuite/ChangeLog: PR target/52932 * gcc.target/i386/avx2-vpermps-1.c (avx2_test): Use __m256i type for second function argument. * gcc.target/i386/avx2-vpermps-2.c (init_permps): Update declaration. (calc_permps): Update declaration. Calculate result correctly. (avx2_test): Change src2 type to union256i_d. * gcc.target/i386/avx2-vpermd-2.c (calc_permd): Calculate result correctly. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/avx2intrin.h trunk/gcc/config/i386/i386.c trunk/gcc/config/i386/sse.md trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/i386/avx2-vpermd-2.c trunk/gcc/testsuite/gcc.target/i386/avx2-vpermps-1.c trunk/gcc/testsuite/gcc.target/i386/avx2-vpermps-2.c
[Bug target/52932] AVX2 intrinsic _mm256_permutevar8x32_ps has wrong parameter type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52932 --- Comment #11 from Uros Bizjak ubizjak at gmail dot com 2012-04-13 16:57:09 UTC --- (In reply to comment #10) _mm256_permutevar8x32_epi32 has the operands in wrong order. They need to be swapped. Did you fix this too? Yes.
