[Bug other/61979] Why float variable loading twice into the FPU Stack during condition checking ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61979 --- Comment #5 from Andrew Pinski --- Where is the testcase, this is only the assembly output.
[Bug other/61979] Why float variable loading twice into the FPU Stack during condition checking ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61979 --- Comment #4 from Srikanth --- In the Above comment-3 assembly code with black color letter are the repeated code i.e storing the float variable twice in FPU stack during conditional checking for parity flag and zero flag. I just patch that one by removing repeated code ,after checking the parity flag i just check the zero flag with out loading it again into the FPU Stack and again compare with zero .
[Bug c++/61993] constexpr static member function "is not constant"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61993 --- Comment #2 from steveren --- Ah, it is a dupe; sorry, I missed that one.
[Bug other/61979] Why float variable loading twice into the FTU Stack during condition checking ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61979 --- Comment #3 from Srikanth --- Comment on attachment 33225 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33225 In this assemble code line number at 22-25 and after 27-30 both are same instructions repeated for conditional checking. > file"testcondition.c" > .section.rodata >.LC2: > .string "true" >.LC3: > .string "false" > .text > .globl main > .type main, @function >main: >.LFB0: > .cfi_startproc > pushl %ebp > .cfi_def_cfa_offset 8 > .cfi_offset 5, -8 > movl%esp, %ebp > .cfi_def_cfa_register 5 > andl$-16, %esp > subl$32, %esp > movl.LC0, %eax > movl%eax, 28(%esp) > flds28(%esp) > fldz > fucomip %st(1), %st > fstp%st(0) > jp .L6 flds28(%esp) fldz fucomip%st(1), %st fstp%st(0) > je .L7 >.L6: > movl$.LC2, (%esp) > callprintf > jmp .L4 >.L7: > movl$.LC3, (%esp) > callprintf >.L4: > movl$0, %eax > leave > .cfi_restore 5 > .cfi_def_cfa 4, 4 > ret > .cfi_endproc >.LFE0: > .size main, .-main > .section.rodata > .align 4 >.LC0: > .long 1094713344 > .ident "GCC: (Ubuntu/Linaro 4.8.1-10ubuntu9) 4.8.1" > .section.note.GNU-stack,"",@progbits
[Bug other/61979] Why float variable loading twice into the FTU Stack during condition checking ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61979 --- Comment #2 from Srikanth --- Created attachment 33225 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33225&action=edit In this assemble code line number at 22-25 and after 27-30 both are same instructions repeated for conditional checking. In this assemble code line number at 22-25 and after 27-30 both are same instructions repeated for conditional checking. Architecture Intel® Core™ i3-2350M CPU @ 2.30GHz × 4 Sorry its my mistype *not FTU*,its actually FPU Stack means Floating point unit stack I just patch the above code by removing the repeated code file"testcondition.c" .section.rodata .LC2: .string"true" .LC3: .string"false" .text .globlmain .typemain, @function main: .LFB0: .cfi_startproc pushl%ebp .cfi_def_cfa_offset 8 .cfi_offset 5, -8 movl%esp, %ebp .cfi_def_cfa_register 5 andl$-16, %esp subl$32, %esp movl.LC0, %eax movl%eax, 28(%esp) flds28(%esp) fldz fucomip%st(1), %st fstp%st(0) jp.L6 je.L7 .L6: movl$.LC2, (%esp) callprintf jmp.L4 .L7: movl$.LC3, (%esp) callprintf .L4: movl$0, %eax leave .cfi_restore 5 .cfi_def_cfa 4, 4 ret .cfi_endproc .LFE0: .sizemain, .-main .section.rodata .align 4 .LC0: .long1094713344 .ident"GCC: (Ubuntu/Linaro 4.8.1-10ubuntu9) 4.8.1" .section.note.GNU-stack,"",@progbits
[Bug c/59855] Support sparse-style __attribute__((designated_init)) on structures, requiring designated initializers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59855 --- Comment #7 from Marek Polacek --- Author: mpolacek Date: Sat Aug 2 05:52:30 2014 New Revision: 213515 URL: https://gcc.gnu.org/viewcvs?rev=213515&root=gcc&view=rev Log: PR c/59855 * gcc.dg/Wdesignated-init-2.c: New test. Added: trunk/gcc/testsuite/gcc.dg/Wdesignated-init-2.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug c++/52366] [c++11] static constexpr function cant initialize static constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52366 Andrew Pinski changed: What|Removed |Added CC||q@rsn-tech.co.uk --- Comment #5 from Andrew Pinski --- *** Bug 61993 has been marked as a duplicate of this bug. ***
[Bug c++/61993] constexpr static member function "is not constant"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61993 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Dup of bug 52366. test::idem can't be used as a constexpr until test is completed. *** This bug has been marked as a duplicate of bug 52366 ***
[Bug other/61895] libbacktrace crashes with bus error with empty file argv[0]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61895 Ian Lance Taylor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Version|4.10.0 |4.9.2 Resolution|--- |FIXED --- Comment #5 from Ian Lance Taylor --- Fixed.
[Bug other/61895] libbacktrace crashes with bus error with empty file argv[0]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61895 --- Comment #4 from ian at gcc dot gnu.org --- Author: ian Date: Sat Aug 2 00:54:15 2014 New Revision: 213513 URL: https://gcc.gnu.org/viewcvs?rev=213513&root=gcc&view=rev Log: PR other/61895 runtime: Ignore small argv[0] file for backtrace. Reportedly in some cases Docker starts processes with argv[0] pointing to an empty file. That would cause libgo to pass that empty file to libbacktrace, which would then fail to do any backtraces. Everything should work fine if libbacktrace falls back to /proc/self/exe. This patch to libgo works around the problem by ignoring argv[0] if it is a small file, or if stat fails. This is not a perfect fix but it's an unusual problem. Modified: trunk/libgo/runtime/go-caller.c
[Bug other/61895] libbacktrace crashes with bus error with empty file argv[0]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61895 --- Comment #3 from ian at gcc dot gnu.org --- Author: ian Date: Sat Aug 2 00:53:58 2014 New Revision: 213512 URL: https://gcc.gnu.org/viewcvs?rev=213512&root=gcc&view=rev Log: PR other/61895 runtime: Ignore small argv[0] file for backtrace. Reportedly in some cases Docker starts processes with argv[0] pointing to an empty file. That would cause libgo to pass that empty file to libbacktrace, which would then fail to do any backtraces. Everything should work fine if libbacktrace falls back to /proc/self/exe. This patch to libgo works around the problem by ignoring argv[0] if it is a small file, or if stat fails. This is not a perfect fix but it's an unusual problem. Modified: branches/gcc-4_9-branch/libgo/runtime/go-caller.c
[Bug c++/60417] [DR 1518] Bogus error on C++03 aggregate initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60417 --- Comment #7 from Jason Merrill --- Author: jason Date: Sat Aug 2 00:52:09 2014 New Revision: 213511 URL: https://gcc.gnu.org/viewcvs?rev=213511&root=gcc&view=rev Log: PR c++/60417 * init.c (build_vec_init): Set CONSTRUCTOR_IS_DIRECT_INIT on init-list for trailing elements. * typeck2.c (process_init_constructor_array): Likewise. Added: trunk/gcc/testsuite/g++.dg/init/explicit2.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/init.c trunk/gcc/cp/typeck2.c
[Bug other/61895] libbacktrace crashes with bus error with empty file argv[0]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61895 Ian Lance Taylor changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-08-02 Ever confirmed|0 |1 --- Comment #2 from Ian Lance Taylor --- I don't think changing libbacktrace is the right approach here. I don't think libbacktrace should ignore an existing file passed into it. I'll fix this in libgo.
[Bug c++/61994] constexpr vector array ICE [4.9.1 regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61994
--- Comment #1 from Jeremy Maitin-Shepard ---
With gcc 4.9.1:
The following test program produces an ICE:
typedef unsigned long limb_t __attribute__ ((__vector_size__ (16),
__may_alias__));
struct X {
limb_t limb = {1,1};
};
const X table[1][1] = {{ {} }};
g++ -std=c++11 -c test.cpp
test.cpp:7:31: internal compiler error: output_operand: invalid expression as
operand
const X table[1][1] = {{ {} }};
^
With gcc 4.9.0, the program compiles correctly.
[Bug c++/61994] New: constexpr vector array ICE [4.9.1 regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61994 Bug ID: 61994 Summary: constexpr vector array ICE [4.9.1 regression] Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jeremy at jeremyms dot com
[Bug c++/61993] New: constexpr static member function "is not constant"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61993
Bug ID: 61993
Summary: constexpr static member function "is not constant"
Product: gcc
Version: 4.8.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: q@rsn-tech.co.uk
This works:
static constexpr int idem (int x){ return x; }
struct test
{
static constexpr int a = idem (0);
};
This doesn't:
struct test
{
static constexpr int idem (int x){ return x; }
static constexpr int a = idem (0);
};
The error in the latter case is,
test.cpp:5:39: error: field initializer is not constant
static constexpr int a = idem (0);
^
I don't think this is a duplicate of any of the similar bugs posted; it seems
simpler and not dependent on any context that might not be fully available at
point of compilation.
[Bug c++/51253] [C++11][DR 1030] Evaluation order (sequenced-before relation) among initializer-clauses in braced-init-list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51253 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|4.10.0 |4.9.1 --- Comment #21 from Jason Merrill --- Fixed in 4.9.1.
[Bug c++/59707] [4.8 Regression] Crash when using std::map with template class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59707 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|4.8.4 |4.9.0 --- Comment #5 from Jason Merrill --- Fixed in 4.9. I'm reluctant to backport fixes for invalid-code bugs.
[Bug c++/59645] [4.8 Regression] ICE with covariant return and volatile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59645 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|4.8.4 |4.9.0 --- Comment #5 from Jason Merrill --- Closing. If anyone cares about fixing this in 4.8, we can backport it.
[Bug c++/59633] [4.8 Regression] ICE with __attribute((vector_size(...))) for enum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59633 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|4.8.4 |4.9.0 --- Comment #7 from Jason Merrill --- Apparently no one cares about fixing this in 4.8.
[Bug c++/57138] [4.8 Regression][DR 1430] ICE with pack expansion and alias template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57138 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |DUPLICATE --- Comment #9 from Jason Merrill --- Duplicate. *** This bug has been marked as a duplicate of bug 51239 ***
[Bug c++/51239] [DR 1430] ICE with variadic template alias
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51239 Jason Merrill changed: What|Removed |Added CC||jmetcalfe at acm dot org --- Comment #8 from Jason Merrill --- *** Bug 57138 has been marked as a duplicate of this bug. ***
[Bug c++/53492] [4.8 Regression] ICE in retrieve_specialization, at cp/pt.c:985
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53492 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Jason Merrill --- Not backporting fixes for invalid code bugs.
[Bug c++/61987] Name Resolution within a Template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61987 Daniel Krügler changed: What|Removed |Added CC||daniel.kruegler@googlemail. ||com --- Comment #9 from Daniel Krügler --- (In reply to Yuanming Gao from comment #7) > Please read the book: <>. The code comes from > <<7.1 Templates>>. The author thought the function int foo(int) must be > selected. > > Visual C++ can select the int foo(int) correctly. I don't know whether it is > an implementation issue, or it is by design. "Can select" is irrelevant in the context of correctness. As others have already said: The standard requires to consider *only* the overload foo(double), because for fundamental types the associated set of namespaces is empty (see [basic.lookup.argdep] p2 b1). In this case, argument-depending lookup doesn't happen, and only the overloads that can be found lexically before the call location as part of the (reduced) unqualified lookup are considered.
[Bug c++/59823] [4.8 Regression] conversion operator to const X& causes copy-construction of temporary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59823 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|4.9.0 |4.8.4 --- Comment #7 from Jason Merrill --- Fixed for 4.8.4.
[Bug c++/59956] [4.8 regression] internal compiler error: unexpected expression ‘P_S’ of kind template_parm_index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59956 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Jason Merrill --- Fixed for 4.8.4.
[Bug c++/60241] [4.8 Regression] internal compiler error: in finish_member_declaration, at cp/semantics.c:2617
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60241 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Jason Merrill --- Fixed.
[Bug c++/60361] [4.8 Regression] unexpected 'use of parameter outside function body' error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60361 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Jason Merrill --- Fixed for 4.8.4.
[Bug c++/59956] [4.8 regression] internal compiler error: unexpected expression ‘P_S’ of kind template_parm_index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59956 --- Comment #8 from Jason Merrill --- Author: jason Date: Fri Aug 1 18:33:47 2014 New Revision: 213501 URL: https://gcc.gnu.org/viewcvs?rev=213501&root=gcc&view=rev Log: PR c++/59956 * friend.c (do_friend): Pass the TEMPLATE_DECL to add_friend if we have a friend template in a class template. * pt.c (tsubst_friend_function): Look through it. (push_template_decl_real): A friend member template is primary. Added: branches/gcc-4_8-branch/gcc/testsuite/g++.dg/template/friend55.C Modified: branches/gcc-4_8-branch/gcc/cp/ChangeLog branches/gcc-4_8-branch/gcc/cp/friend.c branches/gcc-4_8-branch/gcc/cp/pt.c
[Bug c++/60241] [4.8 Regression] internal compiler error: in finish_member_declaration, at cp/semantics.c:2617
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60241 --- Comment #7 from Jason Merrill --- Author: jason Date: Fri Aug 1 18:33:41 2014 New Revision: 213500 URL: https://gcc.gnu.org/viewcvs?rev=213500&root=gcc&view=rev Log: PR c++/60241 * pt.c (lookup_template_class_1): Update DECL_TEMPLATE_INSTANTIATIONS of the partial instantiation, not the most general template. (maybe_process_partial_specialization): Reassign everything on that list. Added: branches/gcc-4_8-branch/gcc/testsuite/g++.dg/template/memclass5.C Modified: branches/gcc-4_8-branch/gcc/cp/ChangeLog branches/gcc-4_8-branch/gcc/cp/pt.c
[Bug c++/59823] [4.8 Regression] conversion operator to const X& causes copy-construction of temporary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59823 --- Comment #6 from Jason Merrill --- Author: jason Date: Fri Aug 1 18:33:54 2014 New Revision: 213502 URL: https://gcc.gnu.org/viewcvs?rev=213502&root=gcc&view=rev Log: PR c++/59823 Core DR 1138 * call.c (reference_binding): Pass LOOKUP_NO_TEMP_BIND for list-initialization. A conversion to rvalue ref that involves an lvalue-rvalue conversion is bad. (convert_like_real): Give helpful error message. Added: branches/gcc-4_8-branch/gcc/testsuite/g++.dg/cpp0x/overload3.C Modified: branches/gcc-4_8-branch/gcc/cp/ChangeLog branches/gcc-4_8-branch/gcc/cp/call.c
[Bug c++/60361] [4.8 Regression] unexpected 'use of parameter outside function body' error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60361 --- Comment #5 from Jason Merrill --- Author: jason Date: Fri Aug 1 18:33:35 2014 New Revision: 213499 URL: https://gcc.gnu.org/viewcvs?rev=213499&root=gcc&view=rev Log: PR c++/60361 * parser.c (cp_parser_template_id): Don't set up a CPP_TEMPLATE_ID if re-parsing might succeed. * semantics.c (finish_id_expression): Use of a parameter outside the function body is a parse error. Added: branches/gcc-4_8-branch/gcc/testsuite/g++.dg/parse/ambig7.C Modified: branches/gcc-4_8-branch/gcc/cp/ChangeLog branches/gcc-4_8-branch/gcc/cp/parser.c branches/gcc-4_8-branch/gcc/cp/semantics.c branches/gcc-4_8-branch/gcc/testsuite/g++.dg/parse/parameter-declaration-2.C branches/gcc-4_8-branch/gcc/testsuite/g++.dg/parse/typename7.C
[Bug web/61992] git web interface handles some paths badly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61992 --- Comment #1 from Rafał Mużyło --- ...if there's any confusion, aclocal.m4 is just a random pick
[Bug web/61992] New: git web interface handles some paths badly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61992 Bug ID: 61992 Summary: git web interface handles some paths badly Product: gcc Version: unknown Status: UNCONFIRMED Severity: minor Priority: P3 Component: web Assignee: unassigned at gcc dot gnu.org Reporter: galtgendo at o2 dot pl I don't know, if this is a misconfiguration on your part or a bug in the web frontend, but if I browse from gcc.gnu.org/git to https://gcc.gnu.org/git/?p=gcc.git;a=tree;f=libstdc%2B%2B-v3;h=ba19769f319ff21297cf78bd31aeca0e0d2d25e0;hb=refs/heads/gcc-4_9-branch then click on 'blob' for any file, the file is displayed as empty with https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libstdc%2B%2B-v3/aclocal.m4;h=60b7ccb59124ea9bdd7736b4c244e5a697edbd76;hb=refs/heads/gcc-4_9-branch path. If I change the path to https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libstdc++-v3/aclocal.m4;h=60b7ccb59124ea9bdd7736b4c244e5a697edbd76;hb=refs/heads/gcc-4_9-branch, the file content gets displayed correctly.
[Bug c++/61982] Optimizer does not eliminate stores to destroyed objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61982 --- Comment #7 from Jakub Jelinek --- (In reply to Daniel Krügler from comment #6) > (In reply to Avi Kivity from comment #5) > > Ah, I see that non-trivial destructors were fixed in gcc 4.9. > > I'm not sure whether I can agree with "fixed" here. A related (yet > unresolved) core-language issue is > > http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#640 Ugh, what a terrible proposal.
[Bug c++/61982] Optimizer does not eliminate stores to destroyed objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61982 --- Comment #6 from Daniel Krügler --- (In reply to Avi Kivity from comment #5) > Ah, I see that non-trivial destructors were fixed in gcc 4.9. I'm not sure whether I can agree with "fixed" here. A related (yet unresolved) core-language issue is http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#640
[Bug target/61988] compiler error when misplascing "memcpy(" instead of "memset("
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61988 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #2 from Jakub Jelinek --- Dup. *** This bug has been marked as a duplicate of bug 60693 ***
[Bug target/60693] [4.8 Regression] ICE on funny memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60693 Jakub Jelinek changed: What|Removed |Added CC||filip.svoboda at netajo dot cz --- Comment #8 from Jakub Jelinek --- *** Bug 61988 has been marked as a duplicate of this bug. ***
[Bug other/61963] CilkPlus Array Notation ICE in build_array_notation_ref on malformed function arguments.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61963 --- Comment #2 from Kirill Yukhin --- Author: kyukhin Date: Fri Aug 1 17:20:02 2014 New Revision: 213494 URL: https://gcc.gnu.org/viewcvs?rev=213494&root=gcc&view=rev Log: PR other/61963 gcc/cp/ * parser.c (cp_parser_array_notation): Added check for array_type. gcc/testsuite/ * c-c++-common/cilk-plus/AN/pr61963.c: New test. Added: trunk/gcc/testsuite/c-c++-common/cilk-plus/AN/pr61963.c Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/60953] configure: error: GNU Fortran is not working
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60953 kargl at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #6 from kargl at gcc dot gnu.org --- (In reply to multya from comment #5) > I update system to 8.4 and no mo errors. Thanks for updating the status. Closing as invalid.
[Bug c++/61991] New: Destructors not always called for statically initialized thread_local objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61991
Bug ID: 61991
Summary: Destructors not always called for statically
initialized thread_local objects
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: scovich at gmail dot com
If a thread_local object is statically initialized---trivial or constexpr
constructor---but has a non-trivial destructor, the destructor will only run if
some *other* thread_local object needs dynamic initialization *and* if at least
one such object is accessed by the thread during its lifetime. Accessing
members of the object itself does nothing, because it is statically
initialized.
Example:
#include
static thread_local struct X {
~X() {
printf("bye!\n");
}
} x;
static thread_local int y = printf("initialized y\n");
int main() {
//printf("%d\n", y);
}
Compiling the above with `g++ -std=gnu++11 bug.cpp' gives an executable that
produces no output when run.
Uncomment the printf in main() and recompile, and the resulting executable
prints:
initialized y
14
bye!
The only hint of trouble at compile time is that the compiler may warn about an
unused variable. However, that warning only comes if the offending object is
never accessed otherwise (perhaps because it is an exit guard of some type),
has static storage class, *and* no other dynamic thread_local storage exists...
an unlikely combination.
Looking at the assembly code output, the problem is obvious: X::~X is only
registered with __cxa_thread_exit if __tls_init is called, and the latter is
only called if the thread accesses a TLS object that needs dynamic
initialization.
Under Cygwin, I hit the further problem that __tls_init doesn't even contain
the any calls to __cxa_thread_exit. That's probably a separate bug, though, and
I don't know whose problem it might be.
If there's no easy fix, might I suggest a loud warning somewhere in the docs
might be appropriate so people have a way to know about the limitation? I tried
searching for this online, but Google didn't turn anything up.
(Discovered in 4.8.3, still there in 4.9.0, and given the nature of the bug I
suspect it's in more recent versions, too).
[Bug c++/61982] Optimizer does not eliminate stores to destroyed objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61982 --- Comment #5 from Avi Kivity --- Ah, I see that non-trivial destructors were fixed in gcc 4.9.
[Bug other/61963] CilkPlus Array Notation ICE in build_array_notation_ref on malformed function arguments.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61963 --- Comment #1 from Kirill Yukhin --- Author: kyukhin Date: Fri Aug 1 17:06:00 2014 New Revision: 213493 URL: https://gcc.gnu.org/viewcvs?rev=213493&root=gcc&view=rev Log: PR other/61963 gcc/cp/ * parser.c (cp_parser_array_notation): Added check for array_type. gcc/testsuite/ * c-c++-common/cilk-plus/AN/pr61963.c: New test. Added: branches/gcc-4_9-branch/gcc/testsuite/c-c++-common/cilk-plus/AN/pr61963.c Modified: branches/gcc-4_9-branch/gcc/cp/ChangeLog branches/gcc-4_9-branch/gcc/cp/parser.c branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
[Bug c++/61455] Internal compiler error, and other confused errors, when using array notation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61455 --- Comment #4 from Kirill Yukhin --- Author: kyukhin Date: Fri Aug 1 17:00:51 2014 New Revision: 213492 URL: https://gcc.gnu.org/viewcvs?rev=213492&root=gcc&view=rev Log: PR middle-end/61455 gcc/c-family/ * array-notation-common.c (extract_array_notation_exprs): Handling of DECL_EXPR added. gcc/c/ * c-array-notation.c (expand_array_notations): Handling of DECL_EXPR added. gcc/cp/ * cp-array-notation.c (expand_array_notation_exprs): Handling of DECL_EXPR improved. Changed handling for INIT_EXPR. gcc/testsuite/ * c-c++-common/cilk-plus/AN/pr61455.c: New test. * c-c++-common/cilk-plus/AN/pr61455-2.c: Likewise. Added: branches/gcc-4_9-branch/gcc/testsuite/c-c++-common/cilk-plus/AN/pr61455-2.c branches/gcc-4_9-branch/gcc/testsuite/c-c++-common/cilk-plus/AN/pr61455.c Modified: branches/gcc-4_9-branch/gcc/c-family/ChangeLog branches/gcc-4_9-branch/gcc/c-family/array-notation-common.c branches/gcc-4_9-branch/gcc/c/ChangeLog branches/gcc-4_9-branch/gcc/c/c-array-notation.c branches/gcc-4_9-branch/gcc/cp/ChangeLog branches/gcc-4_9-branch/gcc/cp/cp-array-notation.c branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
[Bug c++/61455] Internal compiler error, and other confused errors, when using array notation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61455 --- Comment #3 from Kirill Yukhin --- Author: kyukhin Date: Fri Aug 1 16:54:27 2014 New Revision: 213491 URL: https://gcc.gnu.org/viewcvs?rev=213491&root=gcc&view=rev Log: PR middle-end/61455 gcc/c-family/ * array-notation-common.c (extract_array_notation_exprs): Handling of DECL_EXPR added. gcc/c/ * c-array-notation.c (expand_array_notations): Handling of DECL_EXPR added. gcc/cp/ * cp-array-notation.c (expand_array_notation_exprs): Handling of DECL_EXPR improved. Changed handling for INIT_EXPR. gcc/testsuite/ * c-c++-common/cilk-plus/AN/pr61455.c: New test. * c-c++-common/cilk-plus/AN/pr61455-2.c: Likewise. Added: trunk/gcc/testsuite/c-c++-common/cilk-plus/AN/pr61455-2.c trunk/gcc/testsuite/c-c++-common/cilk-plus/AN/pr61455.c Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/array-notation-common.c trunk/gcc/c/ChangeLog trunk/gcc/c/c-array-notation.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-array-notation.c trunk/gcc/testsuite/ChangeLog
[Bug c++/61982] Optimizer does not eliminate stores to destroyed objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61982
--- Comment #4 from Marc Glisse ---
(In reply to Avi Kivity from comment #3)
> I observed this with non-trivial destructors as well.
>
> In fact, something like:
>
> X::~X() { i = 3; }
>
> also emits a store.
Not for me, at least at -O2.
[Bug libstdc++/61909] Small function optimization not applied to small objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61909
--- Comment #3 from Jonathan Wakely ---
(In reply to lukeocamden from comment #2)
> (In reply to Jonathan Wakely from comment #1)
> > This is by design.
>
> I don't really follow - do you mean a consequence of the design, or does the
> standard mandate copying/moving the object into the heap, or does using the
> heap have some other benefit?
None of the above.
I mean the author of our std::function intentionally chose to only avoid the
heap for function pointers
/**
* Trait identifying "location-invariant" types, meaning that the
* address of the object (or any of its members) will not escape.
* Also implies a trivial copy constructor and assignment operator.
*/
template
struct __is_location_invariant
: __or_, is_member_pointer<_Tp>>::type
{ };
...
static const bool __stored_locally =
(__is_location_invariant<_Functor>::value
&& sizeof(_Functor) <= _M_max_size
&& __alignof__(_Functor) <= _M_max_align
&& (_M_max_align % __alignof__(_Functor) == 0));
[Bug c++/61982] Optimizer does not eliminate stores to destroyed objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61982
--- Comment #3 from Avi Kivity ---
I observed this with non-trivial destructors as well.
In fact, something like:
X::~X() { i = 3; }
also emits a store.
[Bug libstdc++/61909] Small function optimization not applied to small objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61909 --- Comment #2 from lukeocamden at gmail dot com --- (In reply to Jonathan Wakely from comment #1) > This is by design. I don't really follow - do you mean a consequence of the design, or does the standard mandate copying/moving the object into the heap, or does using the heap have some other benefit? > I have a patch to do the optimization a bit more aggressively, but still > only for trivially copyable types and others known to be location invariant > (which should include lambdas) That would be a great start - thanks very much!
[Bug c++/61982] Optimizer does not eliminate stores to destroyed objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61982 --- Comment #2 from Jakub Jelinek --- The CLOBBER for non-decl expressions is added in the destructors, here we have trivial destructor, so it is "inlined" already by the frontend and thus not emitted. Perhaps we could emit it in the places where we'd normally insert a call to destructor if the object being destructed is not a decl (in that case I believe adding the CLOBBER for it should be handled during gimplification).
[Bug sanitizer/61978] implement blacklist for sanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61978 --- Comment #8 from Kostya Serebryany --- (In reply to Daniel Pinol from comment #7) > thank you everybody for your great feedback! > > @kostya: I provide here the full log. Even removing the #if's, it still > aborts. strict_memcmp=0 worked like a charm. Thanks! Good. Formally this is a bug, but in most cases not a very harmful one. So, just continue using strict_memcmp=0 > > I guess there's no way to just report the errors but not abort execution, > right? Right, asan exits on first error. (First entry in FAQ: https://code.google.com/p/address-sanitizer/wiki/AddressSanitizer#FAQ) > > > 0x09de51cc is located 52 bytes to the left of global variable '*.LC2' from > '/home/dani/svn/robot/sources/src/interaction/gui/touchscreen/ReemH/ > videoWindow/VideoWindow.cpp' (0x9de5200) of size 1 > '*.LC2' is ascii string '' > 0x09de51cc is located 0 bytes to the right of global variable '*.LC1' from > '/home/dani/svn/robot/sources/src/interaction/gui/touchscreen/ReemH/ > videoWindow/VideoWindow.cpp' (0x9de51c0) of size 12 > '*.LC1' is ascii string 'VideoWindow' > SUMMARY: AddressSanitizer: global-buffer-overflow > ../../.././libsanitizer/asan/asan_interceptors.cc:325 __interceptor_memcmp > Shadow bytes around the buggy address: > 0x213bc9e0: 04 f9 f9 f9 f9 f9 f9 f9 00 00 00 00 00 00 00 00 > 0x213bc9f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x213bca00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x213bca10: 01 f9 f9 f9 f9 f9 f9 f9 01 f9 f9 f9 f9 f9 f9 f9 > 0x213bca20: 01 f9 f9 f9 f9 f9 f9 f9 00 00 00 00 00 00 00 00 > =>0x213bca30: 00 00 00 00 00 00 00 00 00[04]f9 f9 f9 f9 f9 f9 > 0x213bca40: 01 f9 f9 f9 f9 f9 f9 f9 00 00 01 f9 f9 f9 f9 f9 > 0x213bca50: 00 00 01 f9 f9 f9 f9 f9 00 07 f9 f9 f9 f9 f9 f9 > 0x213bca60: 00 05 f9 f9 f9 f9 f9 f9 00 00 00 00 00 00 00 00 > 0x213bca70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x213bca80: 00 01 f9 f9 f9 f9 f9 f9 00 00 03 f9 f9 f9 f9 f9 > Shadow byte legend (one shadow byte represents 8 application bytes): > Addressable: 00 > Partially addressable: 01 02 03 04 05 06 07 > Heap left redzone: fa > Heap right redzone: fb > Freed heap region: fd > Stack left redzone: f1 > Stack mid redzone: f2 > Stack right redzone: f3 > Stack partial redzone: f4 > Stack after return: f5 > Stack use after scope: f8 > Global redzone: f9 > Global init order: f6 > Poisoned by user:f7 > Contiguous container OOB:fc > ASan internal: fe > ==19590==ABORTING
[Bug c++/61990] Incorrect caret location for type mismatches in function calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61990 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-08-01 CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Target Milestone|--- |4.10.0 Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Mine.
[Bug c++/61990] New: Incorrect caret location for type mismatches in function calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61990
Bug ID: 61990
Summary: Incorrect caret location for type mismatches in
function calls
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dmalcolm at redhat dot com
Given the following test.cc:
---
class foo {};
class bar {};
extern void some_fn (foo *, foo *, bar *, foo *, foo *);
void test(foo *f)
{
some_fn (f, f, f, f, f);
}
---
GCC trunk as of 2014-05-29 r211061 reports:
/tmp/test.cc:9:25: error: cannot convert ‘foo*’ to ‘bar*’ for argument ‘3’ to
‘void some_fn(foo*, foo*, bar*, foo*, foo*)’
some_fn (f, f, f, f, f);
^
It manages to report the arg num, but the caret is in the wrong place, on the
end paren; the caret should indicate the location of the bogus arg instead:
some_fn (f, f, f, f, f);
^
(Ideally, the whole of the bogus subexpression should be underlined, though I
appreciate that's a more involved fix architecturally).
[Bug sanitizer/61978] implement blacklist for sanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61978 --- Comment #7 from Daniel Pinol --- thank you everybody for your great feedback! @kostya: I provide here the full log. Even removing the #if's, it still aborts. strict_memcmp=0 worked like a charm. Thanks! I guess there's no way to just report the errors but not abort execution, right? 0x09de51cc is located 52 bytes to the left of global variable '*.LC2' from '/home/dani/svn/robot/sources/src/interaction/gui/touchscreen/ReemH/videoWindow/VideoWindow.cpp' (0x9de5200) of size 1 '*.LC2' is ascii string '' 0x09de51cc is located 0 bytes to the right of global variable '*.LC1' from '/home/dani/svn/robot/sources/src/interaction/gui/touchscreen/ReemH/videoWindow/VideoWindow.cpp' (0x9de51c0) of size 12 '*.LC1' is ascii string 'VideoWindow' SUMMARY: AddressSanitizer: global-buffer-overflow ../../.././libsanitizer/asan/asan_interceptors.cc:325 __interceptor_memcmp Shadow bytes around the buggy address: 0x213bc9e0: 04 f9 f9 f9 f9 f9 f9 f9 00 00 00 00 00 00 00 00 0x213bc9f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x213bca00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x213bca10: 01 f9 f9 f9 f9 f9 f9 f9 01 f9 f9 f9 f9 f9 f9 f9 0x213bca20: 01 f9 f9 f9 f9 f9 f9 f9 00 00 00 00 00 00 00 00 =>0x213bca30: 00 00 00 00 00 00 00 00 00[04]f9 f9 f9 f9 f9 f9 0x213bca40: 01 f9 f9 f9 f9 f9 f9 f9 00 00 01 f9 f9 f9 f9 f9 0x213bca50: 00 00 01 f9 f9 f9 f9 f9 00 07 f9 f9 f9 f9 f9 f9 0x213bca60: 00 05 f9 f9 f9 f9 f9 f9 00 00 00 00 00 00 00 00 0x213bca70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x213bca80: 00 01 f9 f9 f9 f9 f9 f9 00 00 03 f9 f9 f9 f9 f9 Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Heap right redzone: fb Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack partial redzone: f4 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user:f7 Contiguous container OOB:fc ASan internal: fe ==19590==ABORTING
[Bug middle-end/61762] failure to optimize memcpy from constant string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61762 --- Comment #18 from rguenther at suse dot de --- On Fri, 1 Aug 2014, froydnj at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61762 > > --- Comment #17 from Nathan Froyd --- > (In reply to Richard Biener from comment #15) > > Instead aligned the string. > > This is kind of unfortunate, as the motivating testcase was something more > like: > > ... > static const char string[] = "Private"; > unsigned int priv, riva, ivat, vate; > memcpy(&priv, &string[0], sizeof(priv)); > memcpy(&riva, &string[1], sizeof(riva)) > memcpy(&ivat, &string[2], sizeof(ivat)); > memcpy(&vate, &string[3], sizeof(vate)); > /* proceed to use priv, riva, ivate, vate for comparisons */ > > So on strict-align targets, even if the source string was aligned (and that > has > to be by user-declaration?) we wouldn't catch the latter three? Yes - or "maybe". I will still implement the optimization (see the patch) but it only triggers very late due to the c_strlen wart. OTOH on strict-align targets you get the memcpy expanded which means it's expanded inline if the target likes it to.
[Bug middle-end/61762] failure to optimize memcpy from constant string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61762 --- Comment #17 from Nathan Froyd --- (In reply to Richard Biener from comment #15) > Instead aligned the string. This is kind of unfortunate, as the motivating testcase was something more like: ... static const char string[] = "Private"; unsigned int priv, riva, ivat, vate; memcpy(&priv, &string[0], sizeof(priv)); memcpy(&riva, &string[1], sizeof(riva)) memcpy(&ivat, &string[2], sizeof(ivat)); memcpy(&vate, &string[3], sizeof(vate)); /* proceed to use priv, riva, ivate, vate for comparisons */ So on strict-align targets, even if the source string was aligned (and that has to be by user-declaration?) we wouldn't catch the latter three?
[Bug middle-end/61762] failure to optimize memcpy from constant string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61762 --- Comment #16 from Richard Biener --- Author: rguenth Date: Fri Aug 1 12:40:37 2014 New Revision: 213454 URL: https://gcc.gnu.org/viewcvs?rev=213454&root=gcc&view=rev Log: 2014-08-01 Richard Biener PR middle-end/61762 * gcc.dg/pr61762.c: Align the string to make the testcase work on strict-align targets. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/pr61762.c
[Bug middle-end/61762] failure to optimize memcpy from constant string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61762 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #15 from Richard Biener --- Instead aligned the string.
[Bug middle-end/61762] failure to optimize memcpy from constant string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61762 --- Comment #14 from Richard Biener --- Argh. Then we fall into the c_strlen wart to not break strlenopt... which means the fancy folding never triggers. Oh well. I guess simply XFAIL for strict-align targets.
[Bug middle-end/61762] failure to optimize memcpy from constant string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61762 --- Comment #13 from Richard Biener --- Does the following additional patch fix the existing testcase? Index: varpool.c === --- varpool.c (revision 213342) +++ varpool.c (working copy) @@ -413,8 +413,11 @@ ctor_for_folding (tree decl) } } - if ((!DECL_VIRTUAL_P (real_decl) - || DECL_INITIAL (real_decl) == error_mark_node + if (DECL_VIRTUAL_P (real_decl) + && DECL_INITIAL (real_decl) != error_mark_node) +return DECL_INITIAL (real_decl); + + if ((DECL_INITIAL (real_decl) == error_mark_node || !DECL_INITIAL (real_decl)) && (!node || !node->ctor_useable_for_folding_p ())) return error_mark_node;
[Bug middle-end/61762] failure to optimize memcpy from constant string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61762 Richard Biener changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #12 from Richard Biener --- (In reply to r...@cebitec.uni-bielefeld.de from comment #11) > > --- Comment #10 from Richard Biener --- > [...] > > Patch attached, it may still help SPARC passing the testcase. > > The patch doesn't make a difference, unfortunately. It does, but only during the "fab" pass. The issue is that when nothing changes the IL we don't try re-folding and during gimplification (where we unconditionally fold) we can't seem to get at the CTOR. Honza agrees this is a bug in ctor_for_folding. Richard. > Rainer
[Bug spam/61989] gregr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61989 Jonathan Wakely changed: What|Removed |Added Component|web |spam Resolution|MOVED |INVALID
[Bug web/61989] gregr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61989 --- Comment #2 from Iwona --- (In reply to Iwona from comment #1) > comments there is no comment
[Bug web/61989] gregr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61989 Iwona changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|translation |web Resolution|--- |MOVED --- Comment #1 from Iwona --- comments
[Bug web/61989] gregr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61989 --- Comment #3 from Iwona --- (In reply to Iwona from comment #1) > comments there is no comment
[Bug translation/61989] New: gregr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61989 Bug ID: 61989 Summary: gregr Product: gcc Version: trans-mem Status: UNCONFIRMED Severity: normal Priority: P3 Component: translation Assignee: unassigned at gcc dot gnu.org Reporter: iwona.lesik at gmail dot com grege
[Bug debug/61923] [4.8/4.9/4.10 Regression] -fcompare-debug errors while building Linux kernel.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61923 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-08-01 CC||aoliva at gcc dot gnu.org, ||bernds at gcc dot gnu.org, ||jakub at gcc dot gnu.org, ||vmakarov at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #4 from Jakub Jelinek --- Both the short #c0 and large #c3 testcases broke with r192203, the http://gcc.gnu.org/ml/gcc-patches/2012-08/msg00752.html patch to remember DFA state in between basic blocks. In the short testcase I see that in bb3 with -g there is an extra tick at the end of the bb added for the debug insn, which in itself is not a bug IMHO, it is preceeded by asm which probably doesn't want to coexist in the same cycle with anything else. Normally, if the debug insn was followed by any normal insns, those would be scheduled in the same tick as the debug insn, but now with this DFA state save/restore it apparently is an issue (I see the first insn in the bb4 is scheduled in the first tick for that bb, but the second insn differs between -g and -g0 - for -g it is scheduled in tick 1, for -g0 still in tick 0, due to DFA state differences. Not familiar with the scheduler enough to propose a fix, either it could be to change handling of debug insns so that they never themselves start a new scheduling tick, even if it would mean putting them after insns that want to be last in the cycle, or do some changes in the DFA state saving/restoring.
[Bug c++/61987] Name Resolution within a Template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61987 --- Comment #8 from Jonathan Wakely --- VC++ and the book are both wrong.
[Bug tree-optimization/61980] ICE: in compute_affine_dependence, at tree-data-ref.c:4233 with -fcheck-data-deps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61980 --- Comment #6 from Sabrina Souto --- OK, Thank you. (In reply to Richard Biener from comment #5) > (In reply to Sabrina Souto from comment #4) > > I don't have much experience with GCC, so I'm a bit confused with your 2 > > answers, please help me understanding what is happening: Based both on the > > documentation and the results, I understood that the result from the > > dependency analysis (Banerjee dist vectors: 0 1 , Omega dist vectors: 0) is > > wrong or not expected, but this is due to the "unreliably" work of > > -fcheck-data-deps or, since -fcheck-data-deps is used for debug, it is > > working well and this result must be investigated? > > Clearly either Omega or Banerjee is wrong. Banerjee is used by GCC for > code-generation and Omega is used to produce a comparison result only. > > If Omega is wrong we don't have to worry (it only makes -fcheck-data-deps > less useful), if Banerjee is wrong then we have to worry. > > I can't tell nor didn't investigate who is wrong (but from past experience > it's usually Omega).
[Bug c++/61987] Name Resolution within a Template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61987 --- Comment #7 from Yuanming Gao --- Please read the book: <>. The code comes from <<7.1 Templates>>. The author thought the function int foo(int) must be selected. Visual C++ can select the int foo(int) correctly. I don't know whether it is an implementation issue, or it is by design. Best regards, Yuanming > From: gcc-bugzi...@gcc.gnu.org > To: gaoyuanm...@hotmail.com > Subject: [Bug c++/61987] Name Resolution within a Template > Date: Fri, 1 Aug 2014 10:28:36 + > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61987 > > --- Comment #5 from Jonathan Wakely --- > G++ and clang++ call f(double) four times, because that is the only function > visible in the template definition. foo(int) is only visible at the point of > instantiation, so could only be found by ADL, but int has no associated > namespaces. > > EDG does call foo(int) twice, and fails to compile because the call with > unsigned long argument could call foo(double) or foo(int) and so is ambiguous. > > So either the code never calls foo(int) or the code doesn't compile! > > -- > You are receiving this mail because: > You reported the bug.
[Bug tree-optimization/61980] ICE: in compute_affine_dependence, at tree-data-ref.c:4233 with -fcheck-data-deps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61980 --- Comment #5 from Richard Biener --- (In reply to Sabrina Souto from comment #4) > I don't have much experience with GCC, so I'm a bit confused with your 2 > answers, please help me understanding what is happening: Based both on the > documentation and the results, I understood that the result from the > dependency analysis (Banerjee dist vectors: 0 1 , Omega dist vectors: 0) is > wrong or not expected, but this is due to the "unreliably" work of > -fcheck-data-deps or, since -fcheck-data-deps is used for debug, it is > working well and this result must be investigated? Clearly either Omega or Banerjee is wrong. Banerjee is used by GCC for code-generation and Omega is used to produce a comparison result only. If Omega is wrong we don't have to worry (it only makes -fcheck-data-deps less useful), if Banerjee is wrong then we have to worry. I can't tell nor didn't investigate who is wrong (but from past experience it's usually Omega).
[Bug c++/61987] Name Resolution within a Template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61987 --- Comment #6 from Yuanming Gao --- Visual C++ can select the int foo(int) correctly. I don't know whether it is an implementation issue, or it is by design. Best regards, Yuanming > From: gcc-bugzi...@gcc.gnu.org > To: gaoyuanm...@hotmail.com > Subject: [Bug c++/61987] Name Resolution within a Template > Date: Fri, 1 Aug 2014 10:06:00 + > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61987 > > --- Comment #4 from Andrew Pinski --- > (In reply to Yuanming Gao from comment #3) > > Please read the book: <>. The code comes from > > <<7.1 Templates>>. The author thought the function int foo(int) must be > > selected. > > Well I disagree with that book based on what the c++ standard says about > foundmental types and how argument dependent lookup works. > > > > > > > > Best regards, > > Yuanming Gao > > > > > From: gcc-bugzi...@gcc.gnu.org > > > To: gaoyuanm...@hotmail.com > > > Subject: [Bug c++/61987] Name Resolution within a Template > > > Date: Fri, 1 Aug 2014 09:46:21 + > > > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61987 > > > > > > --- Comment #2 from Andrew Pinski --- > > > I don't think this is a bug as foundmental types does not have an > > > associated > > > namespace associated with it. So the overload set is only what is declared > > > before the template. > > > > > > -- > > > You are receiving this mail because: > > > You reported the bug. > > -- > You are receiving this mail because: > You reported the bug.
[Bug tree-optimization/61980] ICE: in compute_affine_dependence, at tree-data-ref.c:4233 with -fcheck-data-deps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61980 --- Comment #4 from Sabrina Souto --- I don't have much experience with GCC, so I'm a bit confused with your 2 answers, please help me understanding what is happening: Based both on the documentation and the results, I understood that the result from the dependency analysis (Banerjee dist vectors: 0 1 , Omega dist vectors: 0) is wrong or not expected, but this is due to the "unreliably" work of -fcheck-data-deps or, since -fcheck-data-deps is used for debug, it is working well and this result must be investigated? (In reply to Richard Biener from comment #3) > It's intended for debugging only: > > @item -fcheck-data-deps > @opindex fcheck-data-deps > Compare the results of several data dependence analyzers. This option > is used for debugging the data dependence analyzers.
[Bug sanitizer/61978] implement blacklist for sanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61978 --- Comment #6 from Jakub Jelinek --- (In reply to Daniel Pinol from comment #3) > #if defined(__has_feature) > # if __has_feature(address_sanitizer) > __attribute__((no_sanitize_address)) > # endif > #endif > void triggerLang(ReemWindow &win, config::Language const &lang) is not adding the attribute at all. GCC doesn't support the clangism __has_feature. Just add the attribute unconditionally, uknown attributes just cause a warning, and 4.8+ supports that attribute.
[Bug sanitizer/61978] implement blacklist for sanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61978 --- Comment #5 from Kostya Serebryany --- Also check if strict_memcmp=0 helps you. https://code.google.com/p/address-sanitizer/wiki/Flags
[Bug tree-optimization/61980] ICE: in compute_affine_dependence, at tree-data-ref.c:4233 with -fcheck-data-deps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61980 --- Comment #3 from Richard Biener --- It's intended for debugging only: @item -fcheck-data-deps @opindex fcheck-data-deps Compare the results of several data dependence analyzers. This option is used for debugging the data dependence analyzers.
[Bug tree-optimization/61980] ICE: in compute_affine_dependence, at tree-data-ref.c:4233 with -fcheck-data-deps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61980 --- Comment #2 from Sabrina Souto --- Thank you for the confirmation Richard. Just a suggestion: if the option -fcheck-data-deps does not work well, maybe this option should be removed from the code or at least have a comment in the documentation related to this. (In reply to Richard Biener from comment #1) > Note that -fcheck-data-deps never worked very reliably for me (why do you > use it?) > > Confirmed on trunk.
[Bug sanitizer/61978] implement blacklist for sanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61978 --- Comment #4 from Kostya Serebryany --- Note that the blacklist can not disable the checking inside the memcmp interceptor. But it will disable instrumenting globals in QT, so if this is a global from QT (you did not post the full log) you will not see the error.
[Bug sanitizer/61978] implement blacklist for sanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61978 --- Comment #3 from Daniel Pinol --- I agree with Kostya. I get an error within Qt, and I cannot modify its source code. Another option would be having a flag for not aborting execution when an error is detected (as in valgrind) I tried adding the no_sanitize_address attribute to the method which eventually calls the problematic function, but it did not work. Is it possible to reopen a ticket until a solution for these kind of problems is addressed? thanks #if defined(__has_feature) # if __has_feature(address_sanitizer) __attribute__((no_sanitize_address)) # endif #endif void triggerLang(ReemWindow &win, config::Language const &lang) ==15711==ERROR: AddressSanitizer: global-buffer-overflow on address 0x09de51cc at pc 0xb7263661 bp 0xbfd89638 sp 0xbfd8961c READ of size 21 at 0x09de51cc thread T0 #0 0xb7263660 in __interceptor_memcmp ../../.././libsanitizer/asan/asan_interceptors.cc:325 #1 0xb513b25b (/opt/qtsdk-4.85/lib/libQtCore.so.4+0x1a925b) #2 0xb513bffa (/opt/qtsdk-4.85/lib/libQtCore.so.4+0x1a9ffa) #3 0xb513cc7a in QTranslator::translate(char const*, char const*, char const*) const (/opt/qtsdk-4.85/lib/libQtCore.so.4+0x1aac7a) #4 0xb513cd13 in QTranslator::translate(char const*, char const*, char const*, int) const (/opt/qtsdk-4.85/lib/libQtCore.so.4+0x1aad13) #5 0xb511bc16 in QCoreApplication::translate(char const*, char const*, char const*, QCoreApplication::Encoding, int) (/opt/qtsdk-4.85/lib/libQtCore.so.4+0x189c16) #6 0xb511c0a9 in QCoreApplication::translate(char const*, char const*, char const*, QCoreApplication::Encoding) (/opt/qtsdk-4.85/lib/libQtCore.so.4+0x18a0a9) #7 0x950803f in Ui_VideoWindow::retranslateUi(QWidget*) /home/dani/svn/robot/gcc491-sanitizer/src/interaction/gui/touchscreen/ReemH/videoWindow/ui_VideoWindow.h:267 #8 0x94f9cea in pal::gui::VideoWindow::TriggerLanguageChanged(pal::config::Language const&) /home/dani/svn/robot/sources/src/interaction/gui/touchscreen/ReemH/videoWindow/VideoWindow.cpp:146 #9 0x982afe4 in pal::gui::ReemWidget::triggerLanguageChanged(pal::config::Language const&) /home/dani/svn/robot/sources/src/interaction/gui/touchscreen/ReemWidget.cpp:476 #10 0x982b18a in pal::gui::ReemWidget::triggerLanguageChanged(pal::config::Language const&) /home/dani/svn/robot/sources/src/interaction/gui/touchscreen/ReemWidget.cpp:511 #11 0x92daab5 in pal::gui::triggerLang(pal::gui::ReemWindow&, pal::config::Language const&) /home/dani/svn/robot/sources/src/interaction/gui/touchscreen/ReemH/ReemWindow.cpp:315
[Bug c++/61987] Name Resolution within a Template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61987 --- Comment #5 from Jonathan Wakely --- G++ and clang++ call f(double) four times, because that is the only function visible in the template definition. foo(int) is only visible at the point of instantiation, so could only be found by ADL, but int has no associated namespaces. EDG does call foo(int) twice, and fails to compile because the call with unsigned long argument could call foo(double) or foo(int) and so is ambiguous. So either the code never calls foo(int) or the code doesn't compile!
[Bug c++/61988] compiler error when misplascing "memcpy(" instead of "memset("
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61988 --- Comment #1 from Filip Svoboda --- Created attachment 33224 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33224&action=edit failing source code
[Bug c++/61988] New: compiler error when misplascing "memcpy(" instead of "memset("
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61988
Bug ID: 61988
Summary: compiler error when misplascing "memcpy(" instead of
"memset("
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: filip.svoboda at netajo dot cz
Please see attached source.
When i wrongly called memcpy() function instead of memset() with argument for
memset(), the following error was generated:
filip@toshiba:~$ g++ err.cc
err.cc: In function ‘int main(int, char**)’:
err.cc:10:28: internal compiler error: in ix86_copy_addr_to_reg, at
config/i386/i386.c:21722
memcpy(foo, 0x00, MAX_LEN);
^
[Bug c++/61987] Name Resolution within a Template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61987 --- Comment #4 from Andrew Pinski --- (In reply to Yuanming Gao from comment #3) > Please read the book: <>. The code comes from > <<7.1 Templates>>. The author thought the function int foo(int) must be > selected. Well I disagree with that book based on what the c++ standard says about foundmental types and how argument dependent lookup works. > > > Best regards, > Yuanming Gao > > > From: gcc-bugzi...@gcc.gnu.org > > To: gaoyuanm...@hotmail.com > > Subject: [Bug c++/61987] Name Resolution within a Template > > Date: Fri, 1 Aug 2014 09:46:21 + > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61987 > > > > --- Comment #2 from Andrew Pinski --- > > I don't think this is a bug as foundmental types does not have an associated > > namespace associated with it. So the overload set is only what is declared > > before the template. > > > > -- > > You are receiving this mail because: > > You reported the bug.
[Bug c++/61987] Name Resolution within a Template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61987 --- Comment #3 from Yuanming Gao --- Please read the book: <>. The code comes from <<7.1 Templates>>. The author thought the function int foo(int) must be selected. Best regards, Yuanming Gao > From: gcc-bugzi...@gcc.gnu.org > To: gaoyuanm...@hotmail.com > Subject: [Bug c++/61987] Name Resolution within a Template > Date: Fri, 1 Aug 2014 09:46:21 + > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61987 > > --- Comment #2 from Andrew Pinski --- > I don't think this is a bug as foundmental types does not have an associated > namespace associated with it. So the overload set is only what is declared > before the template. > > -- > You are receiving this mail because: > You reported the bug.
[Bug tree-optimization/61375] [4.10 Regression] ICE in int_cst_value at -O3 in tree-ssa pass when compiling a reference to an __int128 value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61375 --- Comment #3 from thopre01 at gcc dot gnu.org --- Author: thopre01 Date: Fri Aug 1 09:46:47 2014 New Revision: 213436 URL: https://gcc.gnu.org/viewcvs?rev=213436&root=gcc&view=rev Log: 2014-08-01 Thomas Preud'homme Backport from mainline 2014-06-13 Thomas Preud'homme gcc/ PR tree-optimization/61375 * tree-ssa-math-opts.c (find_bswap_or_nop_1): Cancel optimization if symbolic number cannot be represented in an unsigned HOST_WIDE_INT. (execute_optimize_bswap): Cancel optimization if CHAR_BIT != 8. gcc/testsuite/ PR tree-optimization/61375 * gcc.c-torture/execute/pr61375-1.c: New test. Added: branches/gcc-4_9-branch/gcc/testsuite/gcc.c-torture/execute/pr61375.c Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/testsuite/ChangeLog branches/gcc-4_9-branch/gcc/tree-ssa-math-opts.c
[Bug c++/61987] Name Resolution within a Template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61987 --- Comment #2 from Andrew Pinski --- I don't think this is a bug as foundmental types does not have an associated namespace associated with it. So the overload set is only what is declared before the template.
[Bug tree-optimization/53991] _mm_popcnt_u64 fails with -O3 -fgnu-tm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53991 --- Comment #8 from andysem at mail dot ru --- We have a similar problem in Boost.Atomic: https://svn.boost.org/trac/boost/ticket/10204 There we mark all boost::atomic<> functions as always_inline to make sure the compiler sees the memory order arguments as constants as opposed to runtime values (otherwise the compiler just ignores memory order arguments and acts as if seq_cst was specified). As I understand, atomic intrinsics are transaction_unsafe, so should be Boost.Atomic functions as well, yet we still want them always_inline. Given this I don't quite understand the reason why a transaction_unsafe function can't be inlined into the caller; the caller is unsafe anyway, isn't it? Is there a solution for this problem on the source code level, except removing always_inline?
[Bug c++/61987] Name Resolution within a Template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61987 --- Comment #1 from Yuanming Gao --- Created attachment 33223 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33223&action=edit source code
[Bug c++/61987] New: Name Resolution within a Template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61987
Bug ID: 61987
Summary: Name Resolution within a Template
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gaoyuanming at hotmail dot com
Created attachment 33222
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33222&action=edit
Assembly code
I compiled the piece of code:
#include
int foo(double d) { return static_cast(d); }
template
class Test
{
public:
Test(int id, T const & value) : m_id(id), m_value(value) {}
void change()
{
m_value = foo(m_id);
}
void change(int seed)
{
m_id = foo(m_value) * seed;
}
T value() const { return m_value; }
private:
int m_id;
T m_value;
};
int foo(int n) { return n; }
int main()
{
Test t(10, 20);
t.change();
t.change(2);
Test tul(10, 30);
tul.change();
tul.change(3);
return 0;
}
and found that the function void Test::change(int) calls int foo(double)
to implement it. It is a bug.
[Bug tree-optimization/61375] [4.10 Regression] ICE in int_cst_value at -O3 in tree-ssa pass when compiling a reference to an __int128 value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61375 --- Comment #2 from thopre01 at gcc dot gnu.org --- Author: thopre01 Date: Fri Aug 1 08:56:17 2014 New Revision: 213426 URL: https://gcc.gnu.org/viewcvs?rev=213426&root=gcc&view=rev Log: 2014-08-01 Thomas Preud'homme Backport from mainline 2014-06-13 Thomas Preud'homme gcc/ PR tree-optimization/61375 * tree-ssa-math-opts.c (find_bswap_or_nop_1): Cancel optimization if symbolic number cannot be represented in an unsigned HOST_WIDE_INT. (execute_optimize_bswap): Cancel optimization if CHAR_BIT != 8. gcc/testsuite/ PR tree-optimization/61375 * gcc.c-torture/execute/pr61375-1.c: New test. Added: branches/gcc-4_8-branch/gcc/testsuite/gcc.c-torture/execute/pr61375.c Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/testsuite/ChangeLog branches/gcc-4_8-branch/gcc/tree-ssa-math-opts.c
[Bug regression/61510] [4.10 Regression]: 20_util/scoped_allocator/requirements/explicit_instantiation.cc and tr1/6_containers/tuple/requirements/explicit_instantiation.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61510 --- Comment #6 from jgreenhalgh at gcc dot gnu.org --- Author: jgreenhalgh Date: Fri Aug 1 08:56:05 2014 New Revision: 213425 URL: https://gcc.gnu.org/viewcvs?rev=213425&root=gcc&view=rev Log: [Patch] Not very subtle fix for pr61510 gcc/ PR regression/61510 * cgraphunit.c (analyze_functions): Use get_create rather than get for decls which are clones of abstract functions. Modified: trunk/gcc/ChangeLog trunk/gcc/cgraphunit.c
[Bug sanitizer/61978] implement blacklist for sanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61978 --- Comment #2 from Kostya Serebryany --- Yea. This has been discussed a couple of times before. using an attribute in the source is clearly the preferable way. Unfortunately, it is not always technically possible, so we *have* to use the blacklists. The major use cases: a) third_party code that can not be easily modified b) needs to blacklist an entire source directory c) blacklist should be applied to a type, not a function In Chromium we have these: http://src.chromium.org/viewvc/chrome/trunk/src/tools/memory/tsan_v2/ignores.txt?revision=279695 http://src.chromium.org/viewvc/chrome/trunk/src/tools/msan/blacklist.txt?revision=284946 http://src.chromium.org/viewvc/chrome/trunk/src/tools/ubsan_vptr/blacklist.txt?revision=285951 http://src.chromium.org/viewvc/chrome/trunk/src/third_party/instrumented_libraries/blacklists/asan/libglib2.0-0.txt?revision=282959 http://src.chromium.org/viewvc/chrome/trunk/src/third_party/instrumented_libraries/blacklists/msan/libx11-6.txt?revision=282959
[Bug other/61979] Why float variable loading twice into the FTU Stack during condition checking ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61979 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-08-01 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Testcase that shows the problem? On what architecture? What's a FTU stack?
[Bug tree-optimization/61980] ICE: in compute_affine_dependence, at tree-data-ref.c:4233 with -fcheck-data-deps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61980 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-08-01 Summary|[GCC-4.9.1] ICE: in |ICE: in |compute_affine_dependence, |compute_affine_dependence, |at tree-data-ref.c:4233 |at tree-data-ref.c:4233 ||with -fcheck-data-deps Ever confirmed|0 |1 Known to fail||4.10.0 --- Comment #1 from Richard Biener --- Note that -fcheck-data-deps never worked very reliably for me (why do you use it?) Confirmed on trunk.
[Bug fortran/60953] configure: error: GNU Fortran is not working
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60953 --- Comment #5 from multya --- I update system to 8.4 and no mo errors.
[Bug c++/61982] Optimizer does not eliminate stores to destroyed objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61982 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2014-08-01 CC||jakub at gcc dot gnu.org, ||jason at redhat dot com Version|unknown |4.9.1 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- We are missing CLOBBERs here - Jakub, ISTR you added indirect clobbers for this kind of stuff from the C++ frontend in some cases, but why not here? Seems this was for TARGET_EXPRs only? That is, here the frontend would be responsible for adding them? Confirmed.
[Bug tree-optimization/61964] [4.8/4.9 regression] krb5 database propagation enters infinite loop; reduced test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61964 --- Comment #17 from Anders Kaseorg --- Thanks. I verified that GCC 4.8 r213405 fixes my test case and the original Kerberos problem.
[Bug tree-optimization/61964] [4.8/4.9 regression] krb5 database propagation enters infinite loop; reduced test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61964 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||4.8.4, 4.9.2 Resolution|--- |FIXED Known to fail||4.8.3 --- Comment #16 from Richard Biener --- Fixed.
[Bug tree-optimization/61964] [4.8/4.9 regression] krb5 database propagation enters infinite loop; reduced test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61964 --- Comment #15 from Richard Biener --- Author: rguenth Date: Fri Aug 1 07:40:01 2014 New Revision: 213405 URL: https://gcc.gnu.org/viewcvs?rev=213405&root=gcc&view=rev Log: 2014-08-01 Richard Biener PR tree-optimization/61964 * tree-ssa-tail-merge.c (gimple_operand_equal_value_p): New function merged from trunk. (gimple_equal_p): Handle non-SSA LHS solely by structural equality. * gcc.dg/torture/pr61964.c: New testcase. * gcc.dg/pr51879-18.c: XFAIL. Added: branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/torture/pr61964.c Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/testsuite/ChangeLog branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/pr51879-18.c branches/gcc-4_8-branch/gcc/tree-ssa-tail-merge.c
[Bug tree-optimization/61964] [4.8/4.9 regression] krb5 database propagation enters infinite loop; reduced test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61964 --- Comment #14 from Richard Biener --- Author: rguenth Date: Fri Aug 1 07:36:16 2014 New Revision: 213404 URL: https://gcc.gnu.org/viewcvs?rev=213404&root=gcc&view=rev Log: 2014-08-01 Richard Biener PR tree-optimization/61964 * tree-ssa-tail-merge.c (gimple_equal_p): Handle non-SSA LHS solely by structural equality. * gcc.dg/torture/pr61964.c: New testcase. * gcc.dg/pr51879-18.c: XFAIL. Added: branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/torture/pr61964.c Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/testsuite/ChangeLog branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/pr51879-18.c branches/gcc-4_9-branch/gcc/tree-ssa-tail-merge.c
