[Bug fortran/50525] gfortran should not allow early reference to entry dummy argument (r178939)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50525 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Keywords||accepts-invalid CC||burnus at gcc dot gnu.org --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2011-09-27 07:56:20 UTC --- NAG has: Error: test.f90, line 2: Dummy arg X used before first occurrence in an argument list And ifort has: h4j.f90(2): error #6482: An ENTRY dummy argument is referenced in an executable statement before it appears in any ENTRY statement. [X] f(y)=x ! this is wrong ---^ The easiest fix is probably to check whether the symbol is already defined when parsing entry e(x) (or adding attr.dummy).
[Bug libstdc++/49559] [C++0x] stable_sort calls self-move-assignment operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49559 --- Comment #24 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2011-09-27 08:22:22 UTC --- Author: paolo Date: Tue Sep 27 08:22:07 2011 New Revision: 179242 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=179242 Log: 2011-09-27 Paolo Carlini paolo.carl...@oracle.com PR libstdc++/49559 * include/bits/stl_algo.h (__move_merge_backward): Remove. (__move_merge_adaptive, __move_merge_adaptive_backward): New. (__merge_adaptive): Use the latter two. (__rotate_adaptive): Avoid self move-assignment. * include/bits/stl_algobase.h (move_backward): Fix comment. * testsuite/25_algorithms/stable_sort/49559.cc: New. * testsuite/25_algorithms/inplace_merge/49559.cc: Likewise. * testsuite/25_algorithms/inplace_merge/moveable.cc: Extend. * testsuite/25_algorithms/inplace_merge/moveable2.cc: Likewise. * testsuite/util/testsuite_rvalref.h (rvalstruct::operator= (rvalstruct)): Check for self move-assignment. Added: branches/gcc-4_6-branch/libstdc++-v3/testsuite/25_algorithms/inplace_merge/49559.cc branches/gcc-4_6-branch/libstdc++-v3/testsuite/25_algorithms/stable_sort/49559.cc Modified: branches/gcc-4_6-branch/libstdc++-v3/ChangeLog branches/gcc-4_6-branch/libstdc++-v3/include/bits/stl_algo.h branches/gcc-4_6-branch/libstdc++-v3/include/bits/stl_algobase.h branches/gcc-4_6-branch/libstdc++-v3/testsuite/25_algorithms/inplace_merge/moveable.cc branches/gcc-4_6-branch/libstdc++-v3/testsuite/25_algorithms/inplace_merge/moveable2.cc branches/gcc-4_6-branch/libstdc++-v3/testsuite/util/testsuite_rvalref.h
[Bug libstdc++/49559] [C++0x] stable_sort calls self-move-assignment operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49559 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Target Milestone|4.7.0 |4.6.2 --- Comment #25 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-27 08:23:53 UTC --- Fixed for 4.6.2 too.
[Bug c++/16057] Error message omits overload candidate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16057 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED CC|gcc-bugs at gcc dot gnu.org | Resolution||FIXED --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-27 08:31:02 UTC --- Fixed in 4.6.0.
[Bug tree-optimization/50480] 10% performance regression on Spec2006 410.bwaves
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50480 --- Comment #4 from Yukhin Kirill kirill.yukhin at intel dot com 2011-09-27 08:31:35 UTC --- (In reply to comment #3) For 32bit only it seems. Supposedly a cost model issue, the register pressure will be higher and we have only half the number of SSE regs. Richard, what's wrong maybe with cost model? If you're increasing liverange and you have not as much registers (32-bit case), obviously register pressure will increase and degrade performance. But again, how it is connected with cost model?
[Bug c++/18101] invalid declaration in struct not rejected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18101 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED CC|gcc-bugs at gcc dot gnu.org | Resolution||INVALID --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-27 08:37:52 UTC --- We produce a warning, exactly like ICC.
[Bug c++/25015] [gomp] Function names cannot be demangled due to .omp_fn suffix
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25015 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC|gcc-bugs at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-27 08:49:04 UTC --- Now it says In function ‘built-in’. Jakub, could we do better here?
[Bug c++/50363] internal compiler error: verify_gimple failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50363 --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-09-27 08:53:15 UTC --- Author: rguenth Date: Tue Sep 27 08:53:08 2011 New Revision: 179247 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=179247 Log: 2011-09-27 Richard Guenther rguent...@suse.de PR tree-optimization/50363 * tree-ssa-pre.c (create_expression_by_pieces): Handle pointer conversions in POINTER_PLUS_EXPRs properly. * gcc.dg/torture/pr50363.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr50363.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-pre.c
[Bug c/50444] -ftree-isa ignores alignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50444 --- Comment #5 from rguenther at suse dot de rguenther at suse dot de 2011-09-27 08:52:06 UTC --- On Mon, 26 Sep 2011, hjl.tools at gmail dot com wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50444 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added CC||jamborm at gcc dot gnu.org Summary|unaligned movdqa|-ftree-isa ignores |instruction after inlining |alignment --- Comment #3 from H.J. Lu hjl.tools at gmail dot com 2011-09-26 17:39:41 UTC --- -ftree-isa ignores alignment and generates: SR.11_17 = SR.10_18; MEM[(struct Engine *)e_1(D) + 40B].m = SR.11_17; ^^^ This is wrong. Ah, so we now have the SSE testcase ;)
[Bug tree-optimization/50480] 10% performance regression on Spec2006 410.bwaves
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50480 --- Comment #5 from rguenther at suse dot de rguenther at suse dot de 2011-09-27 08:57:33 UTC --- On Tue, 27 Sep 2011, kirill.yukhin at intel dot com wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50480 --- Comment #4 from Yukhin Kirill kirill.yukhin at intel dot com 2011-09-27 08:31:35 UTC --- (In reply to comment #3) For 32bit only it seems. Supposedly a cost model issue, the register pressure will be higher and we have only half the number of SSE regs. Richard, what's wrong maybe with cost model? If you're increasing liverange and you have not as much registers (32-bit case), obviously register pressure will increase and degrade performance. But again, how it is connected with cost model? It's connected to the cost model not modeling the whole vectorized loop but only vectorized statements. So it can't possibly catch this case. I thought of moving more of the cost model details to the target by allowing the target to track the complete loop, like with void * targetm.vectorizer.cost_model_start_loop (struct loop *); targetm.vectorizer.cost_model_stmt (void *, gimple); unsigned targetm.vectorizer.cost_model_finish_loop (void *); where the latter would return a cost for the vectorized loop. We'd need that to model things like PPC having imbalanced resources for some kind of vectorizations as well (shift takes up much resources, so you need other stmts to compensate for it). Richard.
[Bug tree-optimization/50363] internal compiler error: verify_gimple failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50363 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Component|c++ |tree-optimization Resolution||FIXED --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2011-09-27 08:58:37 UTC --- Fixed.
[Bug middle-end/50528] [4.7 Regression] SPEC CPU 2006 failed to build with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50528 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-09-27 Ever Confirmed|0 |1 --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-09-27 08:59:52 UTC --- Confirmed.
[Bug c++/30066] option to make inline functions hidden
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30066 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-09-27 CC|gcc-bugs at gcc dot gnu.org |vincenzo.innocente at cern ||dot ch Ever Confirmed|0 |1 --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-27 09:08:09 UTC --- 2006 ;)
[Bug middle-end/50527] inconsistent vla align
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50527 --- Comment #3 from vries at gcc dot gnu.org 2011-09-27 09:21:12 UTC --- Or alternatively (given we re-compute alignment together with folding alloca), assign the same alignment as folding would. At the point that we determine the alloca alignment during propagation in visit_stmt, we cannot predict whether that alloca will be folded (during the same or later ccp phase). So the only way to achieve other alignment is to be conservative a bit longer for vla-allocas with respect to alignment: - keep align at 1 byte during ccp. - if we fold during ccp, assign align calculated at folding - after we are sure there is no more folding (at expand, or f.i. at the end of the second ccp phase if we limit folding to the first 2 ccp phases, to take advantage of the larger alignment in the middle-end), we assign BIGGEST_ALIGNMENT. The question is of course what standards say about the alignment of alloca (4) I think alloca is non-standard. But in the context of fold_builtin_alloca_for_var, alloca is the implementation vehicle of vlas, so the question is what the standard says about alignment of vlas.
[Bug middle-end/50527] inconsistent vla align
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50527 --- Comment #4 from vries at gcc dot gnu.org 2011-09-27 09:23:21 UTC --- Created attachment 25368 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25368 proposed patch Hm, I suppose we should then make all replacement decls have BIGGEST_ALIGNMENT rather than min (BIGGEST_ALIGNMENT, object-size) Currently testing this patch on x86_64. 2011-09-27 Tom de Vries t...@codesourcery.com * tree-ssa-ccp.c (fold_builtin_alloca_for_var): Use align from ptr_info. * gcc.dg/pr50527.c: New test.
[Bug middle-end/50527] inconsistent vla align
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50527 --- Comment #5 from rguenther at suse dot de rguenther at suse dot de 2011-09-27 09:28:42 UTC --- On Tue, 27 Sep 2011, vries at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50527 --- Comment #3 from vries at gcc dot gnu.org 2011-09-27 09:21:12 UTC --- Or alternatively (given we re-compute alignment together with folding alloca), assign the same alignment as folding would. At the point that we determine the alloca alignment during propagation in visit_stmt, we cannot predict whether that alloca will be folded (during the same or later ccp phase). So the only way to achieve other alignment is to be conservative a bit longer for vla-allocas with respect to alignment: - keep align at 1 byte during ccp. - if we fold during ccp, assign align calculated at folding - after we are sure there is no more folding (at expand, or f.i. at the end of the second ccp phase if we limit folding to the first 2 ccp phases, to take advantage of the larger alignment in the middle-end), we assign BIGGEST_ALIGNMENT. I think we can check if the size is constant in evaluate_stmt and compute alignment according to that. It should only change from non-constant to constant, thus properly go down the lattice during propagation. We don't want to force excessive alignment on the replacement decls as that might require re-aligning the stack which is expensive. The question is of course what standards say about the alignment of alloca (4) I think alloca is non-standard. But in the context of fold_builtin_alloca_for_var, alloca is the implementation vehicle of vlas, so the question is what the standard says about alignment of vlas. Indeed.
[Bug c++/31489] error says struct when it should say class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31489
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
Status|NEW |ASSIGNED
AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot
|gnu.org |com
--- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-27
10:06:09 UTC ---
I just discovered that actually we *do* have machinery to do this, in general
terms (see CLASSTYPE_DECLARED_CLASS, used by eg, class_key_or_enum_as_string).
But cp_parser_elaborated_type_specifier doesn't use it, ie doesn't set
CLASSTYPE_DECLARED_CLASS (at variance with cp_parser_class_head). Thus
something like the following patchlet should do the trick. That said, Andrew
has a point of course, for its second example we would say struct or class,
whichever comes last in the redeclaration. All in all, seems an improvement to
me, if the below works pretty well I'm going to submit it.
/
Index: parser.c
===
--- parser.c(revision 179242)
+++ parser.c(working copy)
@@ -13423,8 +13423,15 @@ cp_parser_elaborated_type_specifier (cp_parser* pa
}
if (tag_type != enum_type)
-cp_parser_check_class_key (tag_type, type);
+{
+ /* Indicate whether this class was declared as a `class' or as a
+`struct'. */
+ if (TREE_CODE (type) == RECORD_TYPE)
+ CLASSTYPE_DECLARED_CLASS (type) = (tag_type == class_type);
+ cp_parser_check_class_key (tag_type, type);
+}
+
/* A cannot follow an elaborated type specifier. If that
happens, the user was probably trying to form a template-id. */
cp_parser_check_for_invalid_template_id (parser, type, token-location);
[Bug middle-end/50530] New: [4.7 Regression] ICE in inline_read_section, at ipa-inline-analysis.c:2895
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50530 Bug #: 50530 Summary: [4.7 Regression] ICE in inline_read_section, at ipa-inline-analysis.c:2895 Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: mar...@trippelsdorf.de I've hit the following ICE while building the latest Gold linker (with CXXFLAGS='-march=native -O2 -pipe -flto'): g++ -W -Wall -Werror -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -frandom-seed=ld-new -march=native -O2 -pipe -flto -o ld-new main.o i386.o x86_64.o sparc.o powerpc.o arm.o arm-reloc-property.o libgold.a ../libiberty/libiberty.a -ldl -lz lto1: internal compiler error: in inline_read_section, at ipa-inline-analysis.c:2885 Please submit a full bug report, I've used delta to reduce it to: /usr/libexec/gcc/x86_64-pc-linux-gnu/4.7.0/lto1 libgold.a@0x3da2600 ../libiberty/libiberty.a@0x99f76 -O1 Reading command line options: libgold.a@0x3da2600 ../libiberty/libiberty.a@0x99f76 Reading object files: libgold.a@0x3da2600 ../libiberty/libiberty.a@0x99f76 Reading the callgraph Merging declarations Reading summaries lto1: internal compiler error: in inline_read_section, at ipa-inline-analysis.c:2895 But I don't know how to reduce it further.
[Bug target/50038] redundant zero extensions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50038 --- Comment #2 from tocarip.intel at gmail dot com 2011-09-27 10:15:15 UTC --- Created attachment 25369 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25369 Possible solution Here is an experimental patch which solves this problem. I modified implicit-zee pass to also eliminate useless zero-extensions from QImode to SImode. With this patch rgbyiqv test from EEMBC 2.0 benchmark showed 6% improvement. However after this patch implicit-zee may became useful for additional targets. For example it became beneficial to 32-bit x86 (+4% on rgbyiqv). Here is a Changelog: 2011-09-27 Ilya Tocar ilya.to...@intel.com * implicit-zee.c: Added 2011 to copyright. (combine_set_zero_extend): Add QImode. (merge_def_and_ze): Likewise. (add_removable_zero_extend): Likewise. (not_qi_to_si): New. (make_defs_and_copies_lists): Add check for QImode.
[Bug middle-end/50527] inconsistent vla align
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50527 --- Comment #6 from vries at gcc dot gnu.org 2011-09-27 10:49:23 UTC --- I think we can check if the size is constant in evaluate_stmt and compute alignment according to that. We can only do that in the last ccp phase that does folding of vla-alllocas. If the argument is not constant, it will not be folded in this phase, but it might be folded during the next ccp phase, when the argument does turn constant. If the argument is constant, it might not be folded in this phase, but it still might be folded during the next ccp phase. Therefore, in evaluate_stmt, we cannot predict whether the alloca will be folded, unless we're in the last ccp phase. And the propagation of alignment of alloca starts in the first ccp phase. It should only change from non-constant to constant, thus properly go down the lattice during propagation. Currently, the result of an alloca is always constant, to be precise, constant 0 with only lower bits valid. This is independent of whether the argument is constant.
[Bug middle-end/50527] inconsistent vla align
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50527 --- Comment #7 from rguenther at suse dot de rguenther at suse dot de 2011-09-27 11:08:01 UTC --- On Tue, 27 Sep 2011, vries at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50527 --- Comment #6 from vries at gcc dot gnu.org 2011-09-27 10:49:23 UTC --- I think we can check if the size is constant in evaluate_stmt and compute alignment according to that. We can only do that in the last ccp phase that does folding of vla-alllocas. If the argument is not constant, it will not be folded in this phase, but it might be folded during the next ccp phase, when the argument does turn constant. If the argument is constant, it might not be folded in this phase, but it still might be folded during the next ccp phase. Therefore, in evaluate_stmt, we cannot predict whether the alloca will be folded, unless we're in the last ccp phase. And the propagation of alignment of alloca starts in the first ccp phase. It should only change from non-constant to constant, thus properly go down the lattice during propagation. Currently, the result of an alloca is always constant, to be precise, constant 0 with only lower bits valid. This is independent of whether the argument is constant. The parameter I meant. But yes if we don't fold alloca in ccp1 we might fold away alignment tests based on BIGGEST_ALIGNMENT while later ccp might fold it and use less alignment. Maybe don't assume any particular alignment for allocas for vlas then. Richard.
[Bug c++/30066] option to make inline functions hidden
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30066 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||jakub at redhat dot com, ||rguenth at gcc dot gnu.org --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-27 11:10:56 UTC --- This remained un-triaged for quite a bit of time, does it make any sense at all to the compiler people? I'm hearing the idea mentioned quite a few times...
[Bug middle-end/50530] [4.7 Regression] ICE in inline_read_section, at ipa-inline-analysis.c:2895
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50530 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug c++/50531] New: ICE on defaulted template destructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50531
Bug #: 50531
Summary: ICE on defaulted template destructor
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bepa...@yahoo.com
Created attachment 25370
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25370
Preprocessed source that triggers ICE
In a program I'm writing I encoutered dozens of ICEs due to bug 49507. After
upgrading to 4.6.1, all but one disappeared. The following code shows an
example.
//-- datafilter.h --
#ifndef DATAFILTER_H_
#define DATAFILTER_H_
template typename T
class DataFilter
{
public:
inline virtual ~DataFilter();
virtual void dataUpdate(int, int) = 0;
virtual void dataStart(int, int);
};
templatetypename T
inline DataFilterT::~DataFilter() = default;
#endif
//-- arcalculator.h --
#ifndef ARCALCULATOR_H_
#define ARCALCULATOR_H_
#include datafilter.h
class ARCalculator : public DataFilterARCalculator
{
public:
ARCalculator() = default;
// the function declared first will generate an ICE
virtual void dataStart(int, int);
virtual void dataUpdate(int, int);
};
#endif
//-- datastart.cc --
#include arcalculator.h
void ARCalculator::dataStart(int, int)
{}
//-- dataupdate.cc --
#include arcalculator.h
void ARCalculator::dataUpdate(int, int)
{}
Strangely, even though the two functions (dataStart and dataUpdate) are
identical, one will compile fine while the other generates an ICE:
$ g++ -c -std=c++0x -Wall -Wextra -save-temps dataupdate.cc # compiles fine
$ g++ -c -std=c++0x -Wall -Wextra -save-temps datastart.cc # generates ICE
In file included from arcalculator.h:4:0,
from datastart.cc:1:
datafilter.h: In destructor 'DataFilterT::~DataFilter() [with T =
ARCalculator]':
arcalculator.h:5:7: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://bugzilla.redhat.com/bugzilla for instructions.
Preprocessed source stored into /tmp/cccoDyUu.out file, please attach this to
your bugreport.
$
By switching the declarations of dataStart() and dataUpdate() in
arcalculator.h, the source which gives the error is also switched: whichever
function is declared first in the header, will generate the ICE when compiled.
g++ version info:
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/i686-redhat-linux/4.6.1/lto-wrapper
Target: i686-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin
--enable-java-awt=gtk --disable-dssi
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--with-ppl --with-cloog --with-tune=generic --with-arch=i686
--build=i686-redhat-linux
Thread model: posix
gcc version 4.6.1 20110908 (Red Hat 4.6.1-9) (GCC)
Preprocessed source is attached.
[Bug libffi/50532] New: [patch] libffi needs FFI_MMAP_EXEC_WRIT on kfreebsd-amd64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50532 Bug #: 50532 Summary: [patch] libffi needs FFI_MMAP_EXEC_WRIT on kfreebsd-amd64 Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: libffi AssignedTo: unassig...@gcc.gnu.org ReportedBy: petr.salin...@seznam.cz libffi crashes under kfreebsd-amd64 in trampoline. As the GNU/kFreeBSD uses the same kernel as plain FreeBSD, it suffices --- src/libffi/configure.ac +++ src/libffi/configure.ac @@ -313,7 +313,7 @@ fi case $target in - *-apple-darwin10* | *-*-freebsd* | *-*-openbsd* | *-pc-solaris*) + *-apple-darwin10* | *-*-freebsd* | *-*-kfreebsd* | *-*-openbsd* | *-pc-solaris*) AC_DEFINE(FFI_MMAP_EXEC_WRIT, 1, [Cannot use malloc on this target, so, we revert to alternative means]) See also original Debian bug http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=642928 Many thanks Petr
[Bug libffi/50532] [patch] libffi needs FFI_MMAP_EXEC_WRIT on kfreebsd-amd64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50532 Petr.Salinger at seznam dot cz changed: What|Removed |Added Target||x86_64-pc-kfreebsd-gnu Host||x86_64-pc-kfreebsd-gnu Build||x86_64-pc-kfreebsd-gnu Severity|blocker |normal
[Bug c++/50531] ICE on defaulted template destructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50531
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Keywords||ice-on-valid-code
Status|UNCONFIRMED |NEW
Last reconfirmed||2011-09-27
Ever Confirmed|0 |1
--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2011-09-27
11:55:48 UTC ---
reduced:
template typename T
class DataFilter
{
public:
inline virtual ~DataFilter();
};
templatetypename T
inline DataFilterT::~DataFilter() = default;
class ARCalculator : public DataFilterARCalculator
{
public:
virtual void dataStart(int, int);
};
void ARCalculator::dataStart(int, int)
{}
[Bug fortran/50525] gfortran should not allow early reference to entry dummy argument (r178939)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50525
--- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2011-09-27
12:12:03 UTC ---
I meant something like the following. Though, the wording could be improved.
--- a/gcc/fortran/decl.c
+++ b/gcc/fortran/decl.c
@@ -4296,6 +4296,14 @@ gfc_match_formal_arglist (gfc_symbol *progname, int
st_flag, int null_flag)
if (gfc_get_symbol (name, NULL, sym))
goto cleanup;
+
+ if (sym-attr.referenced !sym-attr.dummy)
+ {
+ gfc_error (Argument '%s' at %C has been already used at %L,
+sym-name, sym-declared_at);
+ m = MATCH_ERROR;
+ goto cleanup;
+ }
}
p = gfc_get_formal_arglist ();
[Bug translation/50533] New: Creating object by calling constructor explicitly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50533 Bug #: 50533 Summary: Creating object by calling constructor explicitly Classification: Unclassified Product: gcc Version: 4.4.5 Status: UNCONFIRMED Severity: major Priority: P3 Component: translation AssignedTo: unassig...@gcc.gnu.org ReportedBy: malvi...@gmail.com Please, look at this debate: http://stackoverflow.com/questions/7565776/construct-object-by-calling-constructor-method-explicitly. I'm not expert in C++ and can't say is this bug or not. If it's bug I will add all needed environments, versions of gcc and so on. In general: I can create object by calling constructor explicitly: throw impress_errors::Error::Error(err_code); - this is compiled and work correct on version g++ (Ubuntu/Linaro 4.4.4-14ubuntu5) 4.4.5 (Ubuntu Maverick - 10.04). And this code failed on version g++ (Ubuntu/Linaro 4.5.2-8ubuntu4) 4.5.2 (Ubuntu Narwhal - 11.04) and g++ (Debian 4.6.1-13) 4.6.1 with following error: posix_lib.cpp: In function ‘int pos_close(int)’: posix_lib.cpp:363:46: error: cannot call constructor ‘impress_errors::Error::Error’ directly posix_lib.cpp:363:46: error: for a function-style cast, remove the redundant ‘::Error’
[Bug c++/50533] Creating object by calling constructor explicitly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50533 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC|malvikus at gmail dot com | Component|translation |c++ Severity|major |normal
[Bug middle-end/50530] [4.7 Regression] ICE in inline_read_section, at ipa-inline-analysis.c:2895
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50530 Markus Trippelsdorf markus at trippelsdorf dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Markus Trippelsdorf markus at trippelsdorf dot de 2011-09-27 12:51:57 UTC --- I cannot reproduce the ICE anymore. Must have been a stale object file (maybe I forgot to run make clean). Sorry for the noise.
[Bug c++/50533] Creating object by calling constructor explicitly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50533
--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2011-09-27
12:59:41 UTC ---
(In reply to comment #0)
Please, look at this debate:
No, please follow the bug reporting instructions at http://gcc.gnu.org/bugs/
and post a testcase, not a link to somewhere else.
Your case can be reduced to:
struct E {
E(int) { }
};
int main()
{
throw E::E(1);
}
The C++11 standard says that in this case the name E::E names the constructor
(not the class) and that
Such a constructor name shall be used only in the declarator-id of
a declaration that names a constructor or in a using-declaration.
So I believe your code is invalid.
[Bug middle-end/50527] inconsistent vla align
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50527 vries at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011-09-27 AssignedTo|unassigned at gcc dot |vries at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #8 from vries at gcc dot gnu.org 2011-09-27 13:03:55 UTC --- Created attachment 25371 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25371 updated proposed patch Maybe don't assume any particular alignment for allocas for vlas then. Updated patch accordingly, now testing on x86_64. 2011-09-27 Tom de Vries t...@codesourcery.com * tree-ssa-ccp.c (evaluate_stmt): Don't assume alignment for vla-related allocas. * gcc.dg/pr50527.c: New test.
[Bug bootstrap/50513] cross configurations fail to build ipa-inline-analysis.o with -Werror
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50513 --- Comment #2 from Mikael Pettersson mikpe at it dot uu.se 2011-09-27 13:34:56 UTC --- Probably fixed by Richard Sandiford in r179268.
[Bug middle-end/50534] New: sincos not supported for svlm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50534 Bug #: 50534 Summary: sincos not supported for svlm Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: vincenzo.innoce...@cern.ch Is there any reason why BUILT_IN_SINCOS is not supported in gcc/config/i386/i386.c? This bug may be considered a duplicate of PR40770 even if it is more specific.
[Bug libgomp/50386] [4.7 Regression] libgomp.h:87:5: error: unnamed struct/union that defines no instances
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50386 rsand...@gcc.gnu.org rsandifo at gcc dot gnu.org changed: What|Removed |Added CC||rsandifo at gcc dot gnu.org --- Comment #6 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org 2011-09-27 13:54:14 UTC --- Seems to be the same PR50326. Testing a fix.
[Bug middle-end/50534] sincos not supported for svlm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50534 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-09-27 13:59:57 UTC --- Because of the implementation detail on how to represent the two return values. Thus, this isn't a svml issue but a general issue. *** This bug has been marked as a duplicate of bug 40770 ***
[Bug tree-optimization/40770] Vectorization of complex types, vectorization of sincos missing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40770 --- Comment #11 from Richard Guenther rguenth at gcc dot gnu.org 2011-09-27 13:59:57 UTC --- *** Bug 50534 has been marked as a duplicate of this bug. ***
[Bug fortran/50535] New: transformational intrinsic functions not allowed in statement functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50535 Bug #: 50535 Summary: transformational intrinsic functions not allowed in statement functions Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com ! transformational intrinsic functions not allowed in statement functions ! (r178939) logical g,l(2) ! gfortran should complain because all() is transformational g(x)=all(l) end
[Bug fortran/50536] New: an input item shall not appear as the do-variable of any io-implied-do
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50536 Bug #: 50536 Summary: an input item shall not appear as the do-variable of any io-implied-do Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com ! an input item shall not appear as the do-variable of any io-implied-do ! gfortran should reject this one ! (r178939) read *,(l,l=1,2) end
[Bug fortran/50537] New: explicit interface required (r178939)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50537 Bug #: 50537 Summary: explicit interface required (r178939) Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com ! explicit interface required (r178939) ! this program violates Fortran 95 12.3.1.1 number (2) letter (e) ! this program violates Fortran 2003 12.3.1.1 number (3) letter (c) ! this program violates Fortran 2008 12.4.2.2 number (3) letter (c) character(2) f print *,f(1) ! erroneous end character(n) function f(n) f='az' end
[Bug fortran/50538] New: formal argument cannot be same as procedure name (r178939)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50538 Bug #: 50538 Summary: formal argument cannot be same as procedure name (r178939) Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com ! formal argument cannot be same as procedure name(r178939) subroutine sub entry e(sub) end
[Bug fortran/50539] New: Internal error gfc_match_entry(): Bad state (r178939)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50539 Bug #: 50539 Summary: Internal error gfc_match_entry(): Bad state (r178939) Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com ! Internal error gfc_match_entry(): Bad state (r178939) function f entry e(f) end
[Bug fortran/50540] New: Internal Error: Can't convert UNKNOWN to INTEGER(4) (r178939)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50540 Bug #: 50540 Summary: Internal Error: Can't convert UNKNOWN to INTEGER(4) (r178939) Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com ! Internal Error: Can't convert UNKNOWN to INTEGER(4) (r178939) implicit none integer i,dest(10) forall (i=2:ix) dest(i)=i end
[Bug fortran/50541] New: gfortran should not accept a pointer as a generic-name (r178939)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50541 Bug #: 50541 Summary: gfortran should not accept a pointer as a generic-name (r178939) Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com ! gfortran should not accept a pointer as a generic-name (r178939) pointer s! gfortran should complain here interface s ! or here function f() ! this is the right place to specify the pointer attribute pointer f end function end interface end
[Bug fortran/50542] New: gfortran should detect violation of Fortran 95 R536 (r178939)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50542 Bug #: 50542 Summary: gfortran should detect violation of Fortran 95 R536 (r178939) Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com ! gfortran should detect violation of Fortran 95 R536 (r178939) ! Fortran 2003 R528 ! Fortran 2008 R538 type t integer g end type type(t) u data (u%g,j=1,1) /1/! violates R536: data-i-do-object cannot be a scalar data (ii,j=1,1) /1/ ! ditto end
[Bug fortran/50525] gfortran should not allow early reference to entry dummy argument (r178939)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50525 --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2011-09-27 14:27:39 UTC --- The patch causes regressions as it comes before the check in resolve_variable (search for before the ENTRY, which covers a similar issue (cf PR 25090). Namely: gfortran.dg/entry_dummy_ref_1.f90 gfortran.dg/entry_dummy_ref_2.f90 False positive - (n used in a specification expression): gfortran.dg/entry_array_specs_2.f * * * From the F2008 standard (12.6.2.6 ENTRY statement, para 7): In a subprogram, a name that appears as a dummy argument in an ENTRY statement shall not appear in an executable statement preceding that ENTRY statement, unless it also appears in a FUNCTION, SUBROUTINE, or ENTRY statement that precedes the executable statement. * * * Regarding resolve_variable: As cs_base == NULL, the existing check 5086 /* Deal with forward references to entries during resolve_code, to 5087 satisfy, at least partially, 12.5.2.5. */ 5088 if (gfc_current_ns-entries 5089 current_entry_id == sym-entry_id 5090 cs_base fails and, hence, there is no error. * * * Side remarks: a) before the ENTRY statement in which it is a parameter - Misuse of the term parameter b) warning: ‘master.0.sub’ defined but not used - Declare as DECL_ARTIFICIAL to avoid warning - or to handle it better if the warning itself makes sense.
[Bug bootstrap/50543] New: Bootstrap fails to build for latest 4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50543 Bug #: 50543 Summary: Bootstrap fails to build for latest 4.6.0 Classification: Unclassified Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: kirill.yuk...@intel.com Hi, I am not sure, but possibly this will duplicate some other bug. Bootstrap miscompares on latest 4.6.0 sources: $ ../gcc/configure i686-linux --with-arch=corei7 --with-cpu=corei7 --enable-clocale=gnu --with-system-zlib --enable-shared --with-demangler-in-ld --enable-cloog-backend=isl --with-fpmath=sse --prefix=$PREFIX --enable-languages=c,c++,fortran $ make -j24 ... make[2]: Entering directory `/export/users/kyukhin/ws_ref/4.6_build' make[3]: Entering directory `/export/users/kyukhin/ws_ref/4.6_build' rm -f stage_current make[3]: Leaving directory `/export/users/kyukhin/ws_ref/4.6_build' Comparing stages 2 and 3 warning: gcc/cc1plus-checksum.o differs warning: gcc/cc1-checksum.o differs Bootstrap comparison failure! gcc/tree-ssa-loop-im.o differs gcc/loop-iv.o differs gcc/ira-build.o differs gcc/reload.o differs gcc/gcov.o differs gcc/tree-vect-stmts.o differs gcc/tree-vrp.o differs gcc/reload1.o differs gcc/bb-reorder.o differs gcc/real.o differs gcc/ira.o differs gcc/dwarf2out.o differs gcc/tree-ssa-loop-prefetch.o differs gcc/fold-const.o differs gcc/ira-emit.o differs gcc/cfgexpand.o differs gcc/build/genautomata.o differs gcc/omega.o differs gcc/ira-conflicts.o differs gcc/gcc.o differs gcc/store-motion.o differs gcc/ipa-split.o differs gcc/sel-sched.o differs gcc/plugin.o differs gcc/tree-predcom.o differs gcc/driver-i386.o differs gcc/tree.o differs libcpp/directives.o differs libcpp/charset.o differs libcpp/traditional.o differs libcpp/expr.o differs libdecnumber/bid2dpd_dpd2bid.o differs libiberty/sha1.o differs libiberty/pic/sha1.o differs lto-plugin/.libs/lto-plugin.o differs make[2]: *** [compare] Error 1 make[2]: Leaving directory `/export/users/kyukhin/ws_ref/4.6_build' make[1]: *** [stage3-bubble] Error 2 make[1]: Leaving directory `/export/users/kyukhin/ws_ref/4.6_build' make: *** [all] Error 2
[Bug bootstrap/50543] Bootstrap fails to build for latest 4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50543 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2011-09-27 14:39:05 UTC --- what do you mean latest 4.6.0? the 4.6.0 release, or the latest sources on the 4.6 branch? (which will become 4.6.2)
[Bug target/48108] lto should be containerized in a single mach-o section on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48108 Jack Howarth howarth at nitro dot med.uc.edu changed: What|Removed |Added Severity|enhancement |normal
[Bug c++/35722] [C++0x] Variadic templates expansion into non-variadic class template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35722 Dodji Seketeli dodji at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|NEW AssignedTo|dodji at gcc dot gnu.org|unassigned at gcc dot ||gnu.org --- Comment #15 from Dodji Seketeli dodji at gcc dot gnu.org 2011-09-27 14:46:22 UTC --- Unassigning myself as I am not working on this right now.
[Bug rtl-optimization/50249] ira marks wrong value for inheriting
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50249 --- Comment #7 from Bernd Schmidt bernds at gcc dot gnu.org 2011-09-27 14:55:16 UTC --- Author: bernds Date: Tue Sep 27 14:55:11 2011 New Revision: 179272 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=179272 Log: PR rtl-optimization/50249 * reload1.c (reload_reg_reaches_end_p): Accept a reloadnum argument instead of opnum and type. All callers changed. Remove useless declaration. Search forward for other reloads of the same type for the same operand using the same register; if any are found, return false. (reload_regs_reach_end_p): Same argument changes; all callers changed. Modified: trunk/gcc/ChangeLog trunk/gcc/reload1.c
[Bug rtl-optimization/50249] ira marks wrong value for inheriting
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50249 vries at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED AssignedTo|unassigned at gcc dot |bernds at gcc dot gnu.org |gnu.org | --- Comment #8 from vries at gcc dot gnu.org 2011-09-27 15:34:44 UTC --- Bernd committed patch, marking fixed.
[Bug c++/14283] Diagnostic for invalid template-id could be improved
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14283
Manuel López-Ibáñez manu at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|NEW
CC||manu at gcc dot gnu.org
Known to fail||
--- Comment #13 from Manuel López-Ibáñez manu at gcc dot gnu.org 2011-09-27
15:44:31 UTC ---
In GCC 4.5.3:
test.cc:5:13: error: ‘INVALID’ in class ‘A’ does not name a type
It should say: 5:25: error: ‘INVALID’ in class ‘A’ does not name a template
Notice that the location of the error is also wrong.
Clang gives a better diagnostic, but an extra superfluous one:
/tmp/webcompile/_14799_0.cc:5:25: error: 'INVALID' following the 'template'
keyword does not refer to a template
typedef A::template INVALIDvoid X;
^~~
/tmp/webcompile/_14799_0.cc:5:32: error: expected member name or ';' after
declaration specifiers
typedef A::template INVALIDvoid X;
~~~^
2 errors generated.
[Bug middle-end/43864] Same basic blocks should be merged
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43864 --- Comment #3 from vries at gcc dot gnu.org 2011-09-27 16:10:53 UTC --- Author: vries Date: Tue Sep 27 16:10:42 2011 New Revision: 179275 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=179275 Log: 2011-09-27 Tom de Vries t...@codesourcery.com PR middle-end/43864 * tree-ssa-tail-merge.c: New file. (struct same_succ_def): Define. (same_succ, const_same_succ): New typedef. (struct bb_cluster_def): Define. (bb_cluster, const_bb_cluster): New typedef. (struct aux_bb_info): Define. (BB_SIZE, BB_SAME_SUCC, BB_CLUSTER, BB_VOP_AT_EXIT): Define. (gvn_uses_equal): New function. (same_succ_print, same_succ_print_traverse, update_dep_bb) (stmt_update_dep_bb, local_def, same_succ_hash) (inverse_flags, same_succ_equal, same_succ_alloc, same_succ_delete) (same_succ_reset): New function. (same_succ_htab, same_succ_edge_flags) (deleted_bbs, deleted_bb_preds): New var. (debug_same_succ): New function. (worklist): New var. (print_worklist, add_to_worklist, find_same_succ_bb, find_same_succ) (init_worklist, delete_worklist, delete_basic_block_same_succ) (same_succ_flush_bbs, purge_bbs, update_worklist): New function. (print_cluster, debug_cluster, update_rep_bb) (add_bb_to_cluster, new_cluster, delete_cluster): New function. (all_clusters): New var. (alloc_cluster_vectors, reset_cluster_vectors, delete_cluster_vectors) (merge_clusters, set_cluster): New function. (gimple_equal_p, gsi_advance_bw_nondebug_nonlocal, find_duplicate) (same_phi_alternatives_1, same_phi_alternatives, bb_has_non_vop_phi) (deps_ok_for_redirect_from_bb_to_bb, deps_ok_for_redirect) (find_clusters_1, find_clusters): New function. (update_vuses, vop_phi, vop_at_entry, replace_block_by): New function. (update_bbs): New var. (apply_clusters): New function. (update_debug_stmt, update_debug_stmts): New function. (tail_merge_optimize): New function. tree-pass.h (tail_merge_optimize): Declare. * tree-ssa-pre.c (execute_pre): Use tail_merge_optimize. * Makefile.in (OBJS-common): Add tree-ssa-tail-merge.o. (tree-ssa-tail-merge.o): New rule. * opts.c (default_options_table): Set OPT_ftree_tail_merge by default at OPT_LEVELS_2_PLUS. * tree-ssa-sccvn.c (vn_valueize): Move to ... * tree-ssa-sccvn.h (vn_valueize): Here. * timevar.def (TV_TREE_TAIL_MERGE): New timevar. * common.opt (ftree-tail-merge): New switch. * params.def (PARAM_MAX_TAIL_MERGE_COMPARISONS) (PARAM_MAX_TAIL_MERGE_ITERATIONS): New parameter. * doc/invoke.texi (Optimization Options, -O2): Add -ftree-tail-merge. (-ftree-tail-merge, max-tail-merge-comparisons) (max-tail-merge-iterations): New item. Added: trunk/gcc/tree-ssa-tail-merge.c Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in trunk/gcc/common.opt trunk/gcc/doc/invoke.texi trunk/gcc/opts.c trunk/gcc/params.def trunk/gcc/timevar.def trunk/gcc/tree-pass.h trunk/gcc/tree-ssa-pre.c trunk/gcc/tree-ssa-sccvn.c trunk/gcc/tree-ssa-sccvn.h
[Bug middle-end/43864] Same basic blocks should be merged
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43864 --- Comment #4 from vries at gcc dot gnu.org 2011-09-27 16:12:48 UTC --- Author: vries Date: Tue Sep 27 16:12:35 2011 New Revision: 179276 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=179276 Log: 2011-09-27 Tom de Vries t...@codesourcery.com PR middle-end/43864 * gcc.dg/fold-compare-2.c (dg-options): Add -fno-tree-tail-merge. * gcc/testsuite/gcc.dg/uninit-pred-2_c.c: Same. * gcc.dg/pr43864.c: New test. * gcc.dg/pr43864-2.c: Same. * gcc.dg/pr43864-3.c: Same. * gcc.dg/pr43864-4.c: Same. Added: trunk/gcc/testsuite/gcc.dg/pr43864-2.c trunk/gcc/testsuite/gcc.dg/pr43864-3.c trunk/gcc/testsuite/gcc.dg/pr43864-4.c trunk/gcc/testsuite/gcc.dg/pr43864.c Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/fold-compare-2.c trunk/gcc/testsuite/gcc.dg/uninit-pred-2_c.c
[Bug bootstrap/50543] Bootstrap fails to build for latest 4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50543 --- Comment #2 from Yukhin Kirill kirill.yukhin at intel dot com 2011-09-27 16:17:15 UTC --- (In reply to comment #1) what do you mean latest 4.6.0? the 4.6.0 release, or the latest sources on the 4.6 branch? (which will become 4.6.2) Latest sources. Sorry for misunderstanding
[Bug middle-end/49463] [4.7 Regression] LTO doesn't work symbol renamed via asm statement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49463 --- Comment #13 from Jan Hubicka hubicka at gcc dot gnu.org 2011-09-27 16:28:37 UTC --- Author: hubicka Date: Tue Sep 27 16:28:24 2011 New Revision: 179280 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=179280 Log: PR middle-end/49463 * gcc.c-torture/execute/builtins/strstr-asm-lib.c (my_strstr): Mark used. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.c-torture/execute/builtins/strstr-asm-lib.c
[Bug debug/50544] New: Wrong esp offset in debug infos for functions that call stdcall functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50544 Bug #: 50544 Summary: Wrong esp offset in debug infos for functions that call stdcall functions Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassig...@gcc.gnu.org ReportedBy: bernhardl...@googlemail.com Created attachment 25372 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25372 compile with -g -O2 In the attached program, f2 disassambles to this: 0x08048400 +0: sub$0x1c,%esp 0x08048403 +3: mov0x8049708,%eax 0x08048408 +8: mov%eax,(%esp) 0x0804840b +11:call 0x80483e0 f 0x08048410 +16:sub$0x4,%esp 0x08048413 +19:add$0x1c,%esp 0x08048416 +22:ret If one places a breakpoint at 0x08048410 the stack looks like this: Breakpoint 1, 0x08048410 in f2 () at asdf.c:20 20 f(x); (gdb) bt #0 0x08048410 in f2 () at asdf.c:20 #1 0x08048420 in ?? () #2 0x4dedd413 in __libc_start_main (main=0x8048310 main, argc=1, ubp_av=0xb724, init=0x8048420 __libc_csu_init, fini=0x8048490 __libc_csu_fini, rtld_fini=0x4deb1dd0 _dl_fini, stack_end=0xb71c) at libc-start.c:226 #3 0x08048341 in _start () For 0x08048413, it looks as it should: #0 f2 () at asdf.c:22 #1 0x0804831b in main (argc=1, argv=0xb724) at asdf.c:27 I would guess that the frame adjustment DWARF op is not emitted for the instruction at 0x08048410. Normally this wouldn't be much of a problem, but wine hits this sometimes with the way it sets up windows exceptions, which makes this very annoying. gcc version is Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/i686-redhat-linux/4.6.1/lto-wrapper Target: i686-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-ppl --with-cloog --with-tune=generic --with-arch=i686 --build=i686-redhat-linux Thread model: posix gcc version 4.6.1 20110804 (Red Hat 4.6.1-7) (GCC)
[Bug middle-end/49463] [4.7 Regression] LTO doesn't work symbol renamed via asm statement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49463 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #14 from Jan Hubicka hubicka at gcc dot gnu.org 2011-09-27 16:42:57 UTC --- It turns out that I forgot to commit the libstrstr patch and in meantime configure script was modified so it no longer enabled -fuse-linker-plugin by default. Since I tend to always specify it by hand I did not noticed for quite a while. I suppose the problem is that I have plugin enabled LD in my install directory while configure script is incorrectly querying the system wide LD? Anyway testsuite should be clean with plugin now. Sorry for taking so long.
[Bug libstdc++/9635] time_get::date_order unimplemented
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9635 Steve Ellcey sje at cup dot hp.com changed: What|Removed |Added CC||sje at cup dot hp.com --- Comment #6 from Steve Ellcey sje at cup dot hp.com 2011-09-27 16:43:11 UTC --- I am curious if we think anything will be done with this bug. I see someone proposed a patch to the C++ library a while back (https://issues.apache.org/jira/browse/STDCXX-459) but it was not accepted. Do the comments from C++ library issue 461 (http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#461) affect this bug and our ability to fix it?
[Bug libgomp/50386] [4.7 Regression] libgomp.h:87:5: error: unnamed struct/union that defines no instances
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50386 --- Comment #7 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org 2011-09-27 17:18:29 UTC --- Author: rsandifo Date: Tue Sep 27 17:18:22 2011 New Revision: 179285 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=179285 Log: gcc/ PR middle-end/50386 PR middle-end/50326 * tree-sra.c (build_ref_for_model): Use the type of the field as the type of the COMPONENT_REF. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-sra.c
[Bug bootstrap/50326] [4.7 regression] ICE in set_lattice_value, at tree-ssa-ccp.c:456
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50326 --- Comment #9 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org 2011-09-27 17:18:32 UTC --- Author: rsandifo Date: Tue Sep 27 17:18:22 2011 New Revision: 179285 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=179285 Log: gcc/ PR middle-end/50386 PR middle-end/50326 * tree-sra.c (build_ref_for_model): Use the type of the field as the type of the COMPONENT_REF. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-sra.c
[Bug bootstrap/50543] Bootstrap fails to build for latest 4.6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50543 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Version|4.6.2 |4.6.0 --- Comment #3 from H.J. Lu hjl.tools at gmail dot com 2011-09-27 17:18:56 UTC --- What are the last known working revision and non-working revision?
[Bug fortran/50541] gfortran should not accept a pointer as a generic-name (r178939)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50541 janus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011-09-27 CC||janus at gcc dot gnu.org AssignedTo|unassigned at gcc dot |janus at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #1 from janus at gcc dot gnu.org 2011-09-27 17:36:10 UTC --- This one is trivial: Index: gcc/fortran/symbol.c === --- gcc/fortran/symbol.c(revision 179255) +++ gcc/fortran/symbol.c(working copy) @@ -504,6 +504,7 @@ check_conflict (symbol_attribute *attr, const char conf (dummy, result); conf (entry, result); conf (generic, result); + conf (generic, pointer); conf (function, subroutine);
[Bug libstdc++/9635] time_get::date_order unimplemented
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9635 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC|paolo.carlini at oracle dot | |com | --- Comment #7 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-27 17:38:37 UTC --- Sorry, I'm not interested in working on these issues any time soon. By the way, you say 'a patch was rejected' or something similar, but I haven't seen any patch submitted to *this* project in any form.
[Bug libstdc++/9635] time_get::date_order unimplemented
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9635 --- Comment #8 from Steve Ellcey sje at cup dot hp.com 2011-09-27 18:23:56 UTC --- No, the patch I mentioned was not sent to this project. If I am reading the web site correctly (the first link in comment #6), I think the patch was sent to the apache version of the C++ library. I am not sure what relationship that has to the GCC libstdc++.
[Bug libstdc++/9635] time_get::date_order unimplemented
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9635 --- Comment #9 from Jonathan Wakely redi at gcc dot gnu.org 2011-09-27 19:00:44 UTC --- None whatsoever, the Apache stdcxx project is the open source version of Rogue Wave's C++ library
[Bug middle-end/43864] Same basic blocks should be merged
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43864 vries at gcc dot gnu.org changed: What|Removed |Added CC||vries at gcc dot gnu.org Resolution|DUPLICATE |FIXED AssignedTo|unassigned at gcc dot |vries at gcc dot gnu.org |gnu.org | --- Comment #5 from vries at gcc dot gnu.org 2011-09-27 19:26:44 UTC --- Patch and test-cases checked in, marking fixed.
[Bug bootstrap/50543] Bootstrap fails to build for latest 4.6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50543 --- Comment #4 from H.J. Lu hjl.tools at gmail dot com 2011-09-27 20:29:55 UTC --- I have no problem with /export/gnu/import/git/gcc-release/configure --enable-clocale=gnu --with-system-zlib --with-demangler-in-ld --enable-languages=c,c++ i686-linux --prefix=/usr/gcc-4.6.2-corei7 --with-local-prefix=/usr/local --enable-gnu-indirect-function --with-arch=corei7 --with-cpu=corei7 --with-fpmath=sse on gcc-4_6-branch at revision 179242.
[Bug c++/50545] New: [C++0x] SFINAE does not handle an explicit type conversion (functional notation) with a braced-init-list well if target type is not dependent
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50545
Bug #: 50545
Summary: [C++0x] SFINAE does not handle an explicit type
conversion (functional notation) with a
braced-init-list well if target type is not dependent
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: gintensub...@gmail.com
// tested on gcc-4.7-20110924 (experimental)
template class T
T declval();
// #1
template class T
auto f( int )
- decltype( int{ declvalT() } );
// #2
template class
void f( ... );
#define STATIC_ASSERT( ... ) static_assert( __VA_ARGS__, #__VA_ARGS__ )
template class T, class U
struct is_same {
static constexpr bool value = false;
};
template class T
struct is_sameT, T {
static constexpr bool value = true;
};
STATIC_ASSERT( is_same decltype( fint(0) ), int ::value ); // OK;
fint(0) calls #1.
STATIC_ASSERT( is_same decltype( fint*(0) ), void ::value ); // static
assertion fails; fint*(0) should call #2, because int{ (int*)0 } is
ill-formed, but calls #1.
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #111 from Jan Hubicka hubicka at gcc dot gnu.org 2011-09-27 20:48:19 UTC --- Mozilla now builds for me with slim LTO objects. I.e. with -flto=24 -fuse-linker-plugin -fno-fat-lto-objects One needs ar/nm/ranlib that works with slim LTO. I simply set PATH to directory with following scripts: jh@evans:/abuild/jh/trunk-install/bin cat nm #!/bin/sh /usr/bin/nm --plugin /abuild/jh/trunk-install/libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/liblto_plugin.so $* jh@evans:/abuild/jh/trunk-install/bin cat ar #!/bin/sh cmd=$1 shift /abuild/jh/trunk-install/bin/ar-with-plugin $cmd --plugin /abuild/jh/trunk-install/libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/liblto_plugin.so $* jh@evans:/abuild/jh/trunk-install/bin cat ranlib #!/bin/sh jh@evans:/abuild/jh/trunk-install/bin If I was not lazy to rebuild ranlib, I think it exists with plugin support now, too. Just disabling it was however equally easy. I will do some benchmarks about build time/disk usage. Resulting binary works too, BTW :)
[Bug c++/31489] error says struct when it should say class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31489 --- Comment #4 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2011-09-27 21:52:23 UTC --- Author: paolo Date: Tue Sep 27 21:52:19 2011 New Revision: 179293 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=179293 Log: /cp 2011-09-27 Paolo Carlini paolo.carl...@oracle.com PR c++/31489 * parser.c (cp_parser_elaborated_type_specifier): For RECORD_TYPE, set CLASSTYPE_DECLARED_CLASS. /testsuite 2011-09-27 Paolo Carlini paolo.carl...@oracle.com PR c++/31489 * g++.dg/parse/error40.C: New. * g++.dg/warn/incomplete1.C: Adjust. Added: trunk/gcc/testsuite/g++.dg/parse/error40.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/warn/incomplete1.C
[Bug c++/31489] error says struct when it should say class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31489 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC|gcc-bugs at gcc dot gnu.org | Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-27 21:54:26 UTC --- Fixed for 4.7.0.
[Bug c++/50533] Creating object by calling constructor explicitly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50533 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-27 21:57:07 UTC --- Let's close this.
[Bug c++/27527] invalid types produced out of argument deduction (SFINAE bug)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27527 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC|gcc-bugs at gcc dot gnu.org |jason at gcc dot gnu.org --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-27 22:05:34 UTC --- Jason, can you help analyzing a bit the complete testcase attached in Comment #3? To date, I still see the EDG-based compilers I have at hand rejecting most of the -DCASE, like GCC, and, on the other hand, does not look like matter of passing down complain values...
[Bug c++/49855] internal compiler error: in fold_convert_const_int_from_real
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49855 Navin Kumar navin.kumar at gmail dot com changed: What|Removed |Added CC||navin.kumar at gmail dot ||com --- Comment #1 from Navin Kumar navin.kumar at gmail dot com 2011-09-27 22:12:50 UTC --- I have the same problem with gcc 4.6.1; works fine on gcc 4.5.3
[Bug c++/49855] [4.6/4.7 Regression] internal compiler error: in fold_convert_const_int_from_real
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49855 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-09-27 CC||jason at gcc dot gnu.org Known to work||4.6.0 Summary|internal compiler error: in |[4.6/4.7 Regression] |fold_convert_const_int_from |internal compiler error: in |_real |fold_convert_const_int_from ||_real Ever Confirmed|0 |1 Known to fail||4.6.1, 4.7.0 --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-27 22:19:52 UTC --- Oops, apparently this regressed in 4.6.1, 4.6.0 and 4.5.x were fine.
[Bug c++/49152] Unhelpful diagnostic for iterator dereference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152
--- Comment #8 from Christopher Yeleighton giecrilj at stegny dot 2a.pl
2011-09-27 22:23:34 UTC ---
I agree that this would be an improvement, even without clang's selective
typedef unwrapping. But I have some doubts such a patch will be accepted. I
was
told in a couple of occasions that I cannot just remove the expression from
the
diagnostic and rely on the user to look up the source code location.
What follows is an expression regurgitated by g++ for your convenient perusal.
You might want to show it to the person who expresses such strong opinions.
Ask him gently to tell you what it means.
doit.cpp:290:129: error: no match for ‘operator’ in ‘std::cout
boost::range::equal_range [with ForwardRange =
boost::range_detail::transform_rangeboost::value_factoryls::file_recchar::as_char0,
std::vectorls::file_recchar , Value = int, typename
boost::range_iteratorconst ForwardRange::type =
boost::transform_iteratorboost::value_factoryls::file_recchar::as_char0,
__gnu_cxx::__normal_iteratorls::file_recchar*,
std::vectorls::file_recchar , boost::use_default,
boost::use_default]((*(const
boost::range_detail::transform_rangeboost::value_factoryls::file_recchar::as_char0,
std::vectorls::file_recchar *)( boost::range_detail::operator| [with
InputRng = std::vectorls::file_recchar , UnaryFunction =
boost::value_factoryls::file_recchar::as_char0]((* lv_fr), (*(const
boost::range_detail::transform_holderboost::value_factoryls::file_recchar::as_char0
*)(
boost::adaptors::{anonymous}::transformed.boost::range_detail::forwarderHolder::operator()
[with T = boost::value_factoryls::file_recchar::as_char0, Holder =
boost::range_detail::transform_holder]((boost::value_factoryls::file_recchar::as_char0(),
boost::value_factoryls::file_recchar::as_char0(, (*
((int)a_n.std::basic_string_CharT, _Traits, _Alloc::operator[] [with _CharT
= char, _Traits = std::char_traitschar, _Alloc = std::allocatorchar,
std::basic_string_CharT, _Traits, _Alloc::reference = char,
std::basic_string_CharT, _Traits, _Alloc::size_type = long unsigned
int](0ul’
[Bug debug/50279] [4.7 Regression] ICE while building the go front-end with LTO enabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50279 --- Comment #3 from Jack Howarth howarth at nitro dot med.uc.edu 2011-09-27 22:52:58 UTC --- (In reply to comment #2) The same error occurs while building xplor-nih on x86_64-apple-darwin11... The failures building xplor-nih with -flto using gcc trunk are gone at r179288.
[Bug testsuite/50485] gcc.target/i386/sse4_1-blendps.c fails spuriously on i686
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50485 Maxim Kuvyrkov mkuvyrkov at gcc dot gnu.org changed: What|Removed |Added CC||mkuvyrkov at gcc dot ||gnu.org --- Comment #6 from Maxim Kuvyrkov mkuvyrkov at gcc dot gnu.org 2011-09-28 00:10:25 UTC --- I'm also getting this failure with yesterday mainline. Isn't the problem here that SRC3 is used uninitialized in _mm_blend_ps? The test case is buggy, and Tom's patch initializes SRC3 to a value that triggers the bug reliably. I really want to fix this to avoid someone else (beyond Tom, Andrew and myself) wasting their time on debugging a non-deterministic test case. H.J., as you the author of the test case, would you please look into what changes are need to fix it? Is it intended that SRC3.X is used uninitialized? Thank you.
