[Bug target/78007] Important loop from 482.sphinx3 is not vectorized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78007
--- Comment #6 from Richard Biener ---
Author: rguenth
Date: Wed Nov 9 08:19:05 2016
New Revision: 241992
URL: https://gcc.gnu.org/viewcvs?rev=241992&root=gcc&view=rev
Log:
2016-11-09 Richard Biener
PR tree-optimization/78007
* tree-vect-stmts.c (vectorizable_bswap): New function.
(vectorizable_call): Call vectorizable_bswap for
BUILT_IN_BSWAP{16,32,64} if arguments are not promoted.
* gcc.dg/vect/vect-bswap32.c: Adjust.
* gcc.dg/vect/vect-bswap64.c: Likewise.
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/vect/vect-bswap32.c
trunk/gcc/testsuite/gcc.dg/vect/vect-bswap64.c
trunk/gcc/tree-vect-stmts.c
[Bug ipa/78268] New: [7 Regression] internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78268 Bug ID: 78268 Summary: [7 Regression] internal compiler error: Segmentation fault Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: trippels at gcc dot gnu.org CC: kugan at gcc dot gnu.org Target Milestone: --- Either r241990 or r241989 causes a new ICE during Firefox build: /home/trippels/gecko-dev/rdf/base/rdfutil.cpp:111:1: internal compiler error: Segmentation fault } ^ 0x10b6b1d3 crash_signal ../../gcc/gcc/toplev.c:338 0x108308dc unshare_expr_without_location(tree_node*) ../../gcc/gcc/gimplify.c:978 0x10903163 ipa_set_jf_arith_pass_through ../../gcc/gcc/ipa-prop.c:468 0x10903163 update_jump_functions_after_inlining ../../gcc/gcc/ipa-prop.c:2645 0x10915f8b propagate_info_to_inlined_callees ../../gcc/gcc/ipa-prop.c:3409 0x10917c1f ipa_propagate_indirect_call_infos(cgraph_edge*, vec*) ../../gcc/gcc/ipa-prop.c:3561 0x113c401b inline_call(cgraph_edge*, bool, vec*, int*, bool, bool*) ../../gcc/gcc/ipa-inline-transform.c:447 0x113b973b inline_small_functions ../../gcc/gcc/ipa-inline.c:2029 0x113b973b ipa_inline ../../gcc/gcc/ipa-inline.c:2439 0x113b973b execute ../../gcc/gcc/ipa-inline.c:2850 Reducing.
[Bug target/78253] [5/6/7 Regression] [ARM] call weak function instead of strong when called through pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78253 Richard Biener changed: What|Removed |Added Keywords||wrong-code CC||rth at gcc dot gnu.org Known to work||4.9.4 Version|unknown |5.4.0 Target Milestone|--- |5.5 Summary|[ARM] call weak function|[5/6/7 Regression] [ARM] |instead of strong when |call weak function instead |called through pointer |of strong when called ||through pointer Known to fail||5.4.0
[Bug target/78254] FAIL: g++.dg/torture/pr77822.C -O3 -g (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78254 --- Comment #1 from Richard Biener --- The question is whether this is invalid RTL, in which case we should guard against this in the RTL verifier (if we had one). Maybe the pattern should constrain the operand properly?
[Bug ipa/78268] [7 Regression] internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78268 --- Comment #1 from kugan at gcc dot gnu.org --- (In reply to Markus Trippelsdorf from comment #0) > Either r241990 or r241989 causes a new ICE during Firefox build: > > /home/trippels/gecko-dev/rdf/base/rdfutil.cpp:111:1: internal compiler > error: Segmentation fault > } > ^ > 0x10b6b1d3 crash_signal > ../../gcc/gcc/toplev.c:338 > 0x108308dc unshare_expr_without_location(tree_node*) > ../../gcc/gcc/gimplify.c:978 > 0x10903163 ipa_set_jf_arith_pass_through > ../../gcc/gcc/ipa-prop.c:468 > 0x10903163 update_jump_functions_after_inlining > ../../gcc/gcc/ipa-prop.c:2645 > 0x10915f8b propagate_info_to_inlined_callees > ../../gcc/gcc/ipa-prop.c:3409 > 0x10917c1f ipa_propagate_indirect_call_infos(cgraph_edge*, vec va_heap, vl_ptr>*) > ../../gcc/gcc/ipa-prop.c:3561 > 0x113c401b inline_call(cgraph_edge*, bool, vec vl_ptr>*, int*, bool, bool*) > ../../gcc/gcc/ipa-inline-transform.c:447 > 0x113b973b inline_small_functions > ../../gcc/gcc/ipa-inline.c:2029 > 0x113b973b ipa_inline > ../../gcc/gcc/ipa-inline.c:2439 > 0x113b973b execute > ../../gcc/gcc/ipa-inline.c:2850 > > > Reducing. Sorry about the breakage. can you please attach the preprocessed source file to reproduce this.
[Bug target/78255] [5/6/7 regression] Indirect sibling call causing wrong code generation for ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78255 Richard Biener changed: What|Removed |Added Keywords||wrong-code Target Milestone|--- |5.5
[Bug testsuite/78256] [7 Regression] test case gcc.dg/pr35691-1.c fails starting with its introduction in r241915
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78256 Richard Biener changed: What|Removed |Added Component|middle-end |testsuite Target Milestone|--- |7.0 Summary|test case |[7 Regression] test case |gcc.dg/pr35691-1.c fails|gcc.dg/pr35691-1.c fails |starting with its |starting with its |introduction in r241915 |introduction in r241915 --- Comment #1 from Richard Biener --- Input does not match expectation (LOGICAL_OP_NON_SHORT_CIRCUIT)
[Bug tree-optimization/78257] missing memcmp optimization with constant arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78257
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
Status|UNCONFIRMED |NEW
Last reconfirmed||2016-11-09
CC||mliska at suse dot cz
Ever confirmed|0 |1
--- Comment #1 from Richard Biener ---
Confirmed. Note handling the terminating nul is likely some off-by-one error
somewhere.
Handling arrays of integers (arrays in general) is harder as we do not store
the constructors in target representation (same for strings written as
{ 'a', 'b', '\0' } btw.). One can't use the host library routines to perform
the folding but has to compare two CONSTRUCTORs elementwise (they are at least
sorted).
[Bug ipa/78268] [7 Regression] internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78268
Markus Trippelsdorf changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2016-11-09
Ever confirmed|0 |1
--- Comment #2 from Markus Trippelsdorf ---
trippels@gcc2-power8 base % cat Unified_cpp_rdf_base0.ii
typedef enum {} nsresult;
struct A {
virtual nsresult m_fn1(bool);
};
struct B {
A *operator[](int);
};
struct C {
nsresult m_fn2(bool);
bool m_fn3(bool);
B mDataSources;
};
nsresult C::m_fn2(bool p1) { m_fn3(!p1); }
bool C::m_fn3(bool p1) { mDataSources[0]->m_fn1(p1); }
trippels@gcc2-power8 base % c++ -c -O3 Unified_cpp_rdf_base0.ii
Unified_cpp_rdf_base0.ii:14:54: internal compiler error: Segmentation fault
[Bug ipa/78258] [7 Regression] ICE in compare_values_warnv, at tree-vrp.c:1218
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78258
Richard Biener changed:
What|Removed |Added
Keywords||accepts-invalid
CC||kugan at gcc dot gnu.org
Component|fortran |ipa
Target Milestone|--- |7.0
Summary|ICE in |[7 Regression] ICE in
|compare_values_warnv, at|compare_values_warnv, at
|tree-vrp.c:1218 |tree-vrp.c:1218
--- Comment #3 from Richard Biener ---
1215 /* Below we rely on the fact that VAL1 and VAL2 are both pointers or
1216 both integers. */
1217 gcc_assert (POINTER_TYPE_P (TREE_TYPE (val1))
1218 == POINTER_TYPE_P (TREE_TYPE (val2)));
(gdb) p debug_tree (val1)
constant 0>
$1 = void
(gdb) p debug_tree (val2)
constant 7>
vrp_meet gets called from IPA-CP with one pointer and one
integer range. Oops.
#7 0x01947890 in ipcp_vr_lattice::meet_with_1 (this=0x28e8b78,
other_vr=0x2c201a88) at /space/rguenther/src/gcc-git/gcc/ipa-cp.c:909
909 vrp_meet (&m_vr, other_vr);
(gdb) p debug_value_range (other_vr)
[0B, 0B]
(gdb) p debug_value_range ( &this->m_vr)
[7, 7]
The FE ends up emitting / accepting mismatched param / call arg types:
sub (integer(kind=4) & restrict x1, character(kind=1)[1:4] * x2,
character(kind=1)[1:8] * x3, integer(kind=4) * x4, integer(kind=4) _x2,
integer(kind=4) _x3)
{
...
}
...
{
static integer(kind=4) C.3445 = 1;
sub (&C.3445, &"abcd"[1]{lb: 1 sz: 1}, 0B, 0B, 4, 0);
}
{
static integer(kind=4) C.3446 = 2;
static integer(kind=4) C.3447 = 4;
sub (&C.3446, &C.3447, &"1234567"[1]{lb: 1 sz: 1}, 7);
here 7 is passed in place of a pointer arg.
IPA-CP needs to be hardened against such mismatches (I believe the -CP part
simply converts, the IPA-CP part needs to, too).
Of course this looks like an invalid testcase that should have been rejected?
[Bug fortran/78259] [7 Regression] ICE in gfc_trans_subcomponent_assign, at fortran/trans-expr.c:7330
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78259 Richard Biener changed: What|Removed |Added Target Milestone|--- |7.0
[Bug sanitizer/78267] [7 Regression] libsanitizer breaks bootstrap on x86_64-apple-darwin16 at r241977
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78267 Richard Biener changed: What|Removed |Added Target Milestone|--- |7.0
[Bug target/78262] [7 Regression] wrong code with -fschedule-insns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78262 Uroš Bizjak changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-11-09 Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com Target Milestone|--- |5.5 Ever confirmed|0 |1 --- Comment #1 from Uroš Bizjak --- Ouch. Patch in testing: --cut here-- diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md index 6e0348d..a5650a1 100644 --- a/gcc/config/i386/i386.md +++ b/gcc/config/i386/i386.md @@ -10339,7 +10339,7 @@ "operands[2] = gen_lowpart (QImode, operands[2]);") (define_insn_and_split "*3_doubleword" - [(set (match_operand:DWI 0 "register_operand" "=r") + [(set (match_operand:DWI 0 "register_operand" "=&r") (any_shiftrt:DWI (match_operand:DWI 1 "register_operand" "0") (match_operand:QI 2 "nonmemory_operand" "c"))) (clobber (reg:CC FLAGS_REG))] --cut here--
[Bug ipa/78268] [7 Regression] internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78268 --- Comment #3 from Markus Trippelsdorf --- This happens on ppc64le. Doesn't seem to reproduce on X86.
[Bug debug/78265] Excess emission of debug info for ODR used global variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78265 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-11-09 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed. We are indeed erring more and more on the side of emit-debug-info for whatever is referenced in the source. In this case debug info for 'i' is requested via #0 dwarf2out_early_global_decl (decl=) at /space/rguenther/src/gcc-git/gcc/dwarf2out.c:25232 #1 0x00ffa9e5 in rest_of_decl_compilation ( decl=, top_level=1, at_end=0) at /space/rguenther/src/gcc-git/gcc/passes.c:320 #2 0x007ee13e in make_rtl_for_nonlocal_decl ( decl=, init=, asmspec=0x0) at /space/rguenther/src/gcc-git/gcc/cp/decl.c:6433 #3 0x007f0d73 in cp_finish_decl (decl=, init=, init_const_expr_p=false, asmspec_tree=, flags=1) at /space/rguenther/src/gcc-git/gcc/cp/decl.c:7067 and we never prune debug info for decls (only for "unused" types). OTOH I'm not a strong believer in first generating something and later pruning it again. Same happens with the C frontend.
[Bug c++/78263] Compile failure with AltiVec library on PPC64le and -std=c++11 flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78263 Richard Biener changed: What|Removed |Added Target||powerpc64le-*-* --- Comment #3 from Richard Biener --- Maybe altivec.h should contain a #warning if compiled without GNU extensions? (it looks like __STRICT_ANSI__ is defined for non-GNU modes).
[Bug tree-optimization/78248] [7 Regression] wrong code at -Os and above on x86_64-linux-gnu (in both 32-bit and 64-bit modes)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78248 --- Comment #6 from Martin Liška --- Still can't reproduce. Can you please paste output of gcc-trunk -Os small.c --verbose and it would be usefull to paste output of -S. Thanks
[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 Bug 53947 depends on bug 78007, which changed state. Bug 78007 Summary: Important loop from 482.sphinx3 is not vectorized https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78007 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug target/78007] Important loop from 482.sphinx3 is not vectorized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78007 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Richard Biener --- Fixed.
[Bug c++/78193] [7 regression] g++.dg/concepts/inherit-ctor3.C etc. FAIL at r241765
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78193
--- Comment #4 from Eric Botcazou ---
> This looks related to the ABI and was introduced by:
>
> r241765 | jason | 2016-11-02 02:50:29 +0100 (Wed, 02 Nov 2016) | 53 lines
>
> Implement P0136R1, Rewording inheriting constructors.
The problem comes from build_over_call:
if (current_function_decl
&& flag_new_inheriting_ctors
&& DECL_INHERITED_CTOR (current_function_decl)
&& cand->num_convs)
/* Don't introduce copies when passing arguments along to the inherited
constructor. */
CALL_FROM_THUNK_P (call) = true;
For the inherited constructor:
B::B(moveonly) [inherited from A] (struct B * const this, struct moveonly
D.1999)
{
struct moveonly D.2080;
struct moveonly D.2053;
:
A::A (this_2(D), D.2080);
return;
}
D.2080 is passed indirectly in the call but was not initially TREE_ADDRESSABLE
so its RTL was already set to a REG before mark_addressable is invoked on it.
On the contrary, when CALL_FROM_THUNK_P is not set, a stack temporary is built
and passed in the call instead, which is naturally addressable.
[Bug c++/78269] New: FAIL: FAIL: g++.dg/cpp1z/noexcept-type11.C and FAIL: g++.dg/cpp1z/noexcept-type9.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78269 Bug ID: 78269 Summary: FAIL: FAIL: g++.dg/cpp1z/noexcept-type11.C and FAIL: g++.dg/cpp1z/noexcept-type9.C Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: amker at gcc dot gnu.org Target Milestone: --- Tests added by revision 241944 failed on arm target: Test noexcept-typ11.C failed on arm targets with: /.../src/gcc/gcc/testsuite/g++.dg/cpp1z/noexcept-type11.C:3:6: warning: mangled name for 'void f(int (*)() noexcept)' will change in C++17 because the exception specification is part of a function type [-Wc++1z-compat] In function 'void f(int (*)() noexcept)': cc1plus: warning: mangled name for '' will change in C++17 because the exception specification is part of a function type [-Wc++1z-compat] cc1plus: warning: mangled name for '' will change in C++17 because the exception specification is part of a function type [-Wc++1z-compat] PASS: g++.dg/cpp1z/noexcept-type11.C(test for warnings, line 3) FAIL: g++.dg/cpp1z/noexcept-type11.C (test for excess errors) Test noexcept-type9.C failed on both arm and aarch64(linux and elf) targets with: output is: /.../src/gcc/gcc/testsuite/g++.dg/cpp1z/noexcept-type9.C:18:8: error: could not convert template argument '&A::g' from 'void (A::*)()' to 'void (A::*)() noexcept' PASS: g++.dg/cpp1z/noexcept-type9.C(test for errors, line 18) PASS: g++.dg/cpp1z/noexcept-type9.C (test for excess errors) UNRESOLVED: g++.dg/cpp1z/noexcept-type9.C compilation failed to produce executable
[Bug middle-end/78261] vect pass only vectorizes half of the array in gcc.c-torture/execute/pr68532.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78261 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Richard Biener --- Well, the testcase sums in[0] + in[8] + in[16] + ... and is vectorized using interleaving which means the last vector iteration would load from outside of the array. So we apply peeling for gaps. Now the question is why IPA-CP doesn't propagate alignment here (it doesn't even for -O3): callsite main/2 -> test/1 : param 0: CONST: 0 value: 0x0, mask: 0x0 Unknown VR param 1: CONST: &in value: 0x0, mask: 0x0fff0 VR ~[0, 0] param 2: CONST: 1 value: 0x1, mask: 0x0 Unknown VR Not considering test for cloning; no hot calls. Marking all lattices of test/1 as BOTTOM ah. Because it's called from main. Well, so everything works as intended. You likely see unaligned loads being performed as well.
[Bug c++/78269] FAIL: FAIL: g++.dg/cpp1z/noexcept-type11.C and FAIL: g++.dg/cpp1z/noexcept-type9.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78269 Richard Biener changed: What|Removed |Added Target|arm, aarch64|arm, aarch64, x86_64-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2016-11-09 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed.
[Bug ipa/78268] [7 Regression] internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78268 Richard Biener changed: What|Removed |Added Target Milestone|--- |7.0
[Bug tree-optimization/78257] missing memcmp optimization with constant arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78257
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot
gnu.org
--- Comment #2 from Martin Liška ---
(In reply to Richard Biener from comment #1)
> Confirmed. Note handling the terminating nul is likely some off-by-one
> error somewhere.
Yes, I'm having patch for that, that was trivial to fix.
>
> Handling arrays of integers (arrays in general) is harder as we do not store
> the constructors in target representation (same for strings written as
> { 'a', 'b', '\0' } btw.). One can't use the host library routines to perform
> the folding but has to compare two CONSTRUCTORs elementwise (they are at
> least
> sorted).
That would be harder, I'm wondering Richi how would it be difficult to
transform a ctor data to a binary blob we can use for memcmp, memchr, etc. ?
Element wise comparison may be doable, however I'm wondering how usefull the
job would be?
[Bug fortran/71894] [OOP] ICE in gfc_add_component_ref, at fortran/class.c:227
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71894 --- Comment #3 from janus at gcc dot gnu.org --- Author: janus Date: Wed Nov 9 09:22:52 2016 New Revision: 241993 URL: https://gcc.gnu.org/viewcvs?rev=241993&root=gcc&view=rev Log: 2016-11-09 Janus Weil PR fortran/71894 * class.c (gfc_add_component_ref): Add safety checks to avoid ICE. 2016-11-09 Janus Weil PR fortran/71894 * gfortran.dg/class_59.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/class_59.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/class.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/78248] [7 Regression] wrong code at -Os and above on x86_64-linux-gnu (in both 32-bit and 64-bit modes)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78248 --- Comment #7 from Uroš Bizjak --- (In reply to Martin Liška from comment #6) > Still can't reproduce. Can you please paste output of > gcc-trunk -Os small.c --verbose It fails for me: Program received signal SIGSEGV, Segmentation fault. main () at pr78248.c:16 16 d = b[e]; (gdb) valgrind says: ==18918== Invalid read of size 4 ==18918==at 0x40046C: main (pr78248.c:16) ==18918== Address 0x601000 is not stack'd, malloc'd or (recently) free'd ==18918== ==18918== ==18918== Process terminating with default action of signal 11 (SIGSEGV) ==18918== Access not within mapped region at address 0x601000 ==18918==at 0x40046C: main (pr78248.c:16) ==18918== If you believe this happened as a result of a stack ==18918== overflow in your program's main thread (unlikely but ==18918== possible), you can try to increase the size of the ==18918== main thread stack using the --main-stacksize= flag. ==18918== The main thread stack size used in this run was 10485760.
[Bug fortran/71894] [OOP] ICE in gfc_add_component_ref, at fortran/class.c:227
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71894 janus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |janus at gcc dot gnu.org Target Milestone|--- |7.0 --- Comment #4 from janus at gcc dot gnu.org --- Fixed with r241993. Closing.
[Bug tree-optimization/78248] [7 Regression] wrong code at -Os and above on x86_64-linux-gnu (in both 32-bit and 64-bit modes)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78248 --- Comment #8 from Martin Liška --- (In reply to Uroš Bizjak from comment #7) > (In reply to Martin Liška from comment #6) > > Still can't reproduce. Can you please paste output of > > gcc-trunk -Os small.c --verbose > > It fails for me: > > Program received signal SIGSEGV, Segmentation fault. > main () at pr78248.c:16 > 16 d = b[e]; > (gdb) > > valgrind says: > > ==18918== Invalid read of size 4 > ==18918==at 0x40046C: main (pr78248.c:16) > ==18918== Address 0x601000 is not stack'd, malloc'd or (recently) free'd > ==18918== > ==18918== > ==18918== Process terminating with default action of signal 11 (SIGSEGV) > ==18918== Access not within mapped region at address 0x601000 > ==18918==at 0x40046C: main (pr78248.c:16) > ==18918== If you believe this happened as a result of a stack > ==18918== overflow in your program's main thread (unlikely but > ==18918== possible), you can try to increase the size of the > ==18918== main thread stack using the --main-stacksize= flag. > ==18918== The main thread stack size used in this run was 10485760. I've already tried running the test-case in valgrind. But I can't see the problem :) May you please paste -S file and --verbose output?
[Bug tree-optimization/78248] [7 Regression] wrong code at -Os and above on x86_64-linux-gnu (in both 32-bit and 64-bit modes)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78248 --- Comment #9 from Uroš Bizjak --- Created attachment 4 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=4&action=edit --verbose-asm assembly
[Bug tree-optimization/78248] [7 Regression] wrong code at -Os and above on x86_64-linux-gnu (in both 32-bit and 64-bit modes)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78248 --- Comment #10 from Uroš Bizjak --- (In reply to Martin Liška from comment #8) > I've already tried running the test-case in valgrind. But I can't see the > problem :) May you please paste -S file and --verbose output? Done. What I find iteresting at the segfault is the index e: Program received signal SIGSEGV, Segmentation fault. main () at pr78248.c:16 16 d = b[e]; (gdb) p e $1 = 492 although we declare: int b[1], c = 2, d, e, f, g;
[Bug testsuite/78256] [7 Regression] test case gcc.dg/pr35691-1.c fails starting with its introduction in r241915
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78256 --- Comment #2 from prathamesh3492 at gcc dot gnu.org --- Author: prathamesh3492 Date: Wed Nov 9 09:46:13 2016 New Revision: 241994 URL: https://gcc.gnu.org/viewcvs?rev=241994&root=gcc&view=rev Log: 2016-11-09 Prathamesh Kulkarni PR middle-end/78256 testsuite/ * gcc.dg/pr35691-1.c (foo): Use & instead of &&. * gcc.dg/pr35691-2.c (foo): Use | instead of ||. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/pr35691-1.c trunk/gcc/testsuite/gcc.dg/pr35691-2.c
[Bug testsuite/78256] [7 Regression] test case gcc.dg/pr35691-1.c fails starting with its introduction in r241915
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78256 --- Comment #3 from prathamesh3492 at gcc dot gnu.org --- Bill, could you please confirm if r241994 fixes the test-cases for you ? Thanks, Prathamesh
[Bug middle-end/35691] Missed (a == 0) && (b == 0) into (a|(typeof(a)(b)) == 0 when the types don't match
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35691 prathamesh3492 at gcc dot gnu.org changed: What|Removed |Added CC||prathamesh3492 at gcc dot gnu.org --- Comment #2 from prathamesh3492 at gcc dot gnu.org --- Fixed on targets when LOGICAL_OP_NON_SHORT_CIRCUIT is true. When LOGICAL_OP_NON_SHORT_CIRCUIT is false, the conversion of truth_andif_expr to bit_and_expr doesn't happen and the pattern added in r241915 doesn't get matched.
[Bug target/78254] FAIL: g++.dg/torture/pr77822.C -O3 -g (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78254 --- Comment #2 from Andreas Schwab --- The expression would be undefined at runtime, so it doesn't matter if we generate an unspecified result.
[Bug tree-optimization/78248] [7 Regression] wrong code at -Os and above on x86_64-linux-gnu (in both 32-bit and 64-bit modes)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78248 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-11-09 Ever confirmed|0 |1 --- Comment #11 from Martin Liška --- (In reply to Uroš Bizjak from comment #10) > (In reply to Martin Liška from comment #8) > > > I've already tried running the test-case in valgrind. But I can't see the > > problem :) May you please paste -S file and --verbose output? > > Done. > > What I find iteresting at the segfault is the index e: > > Program received signal SIGSEGV, Segmentation fault. > main () at pr78248.c:16 > 16 d = b[e]; > (gdb) p e > $1 = 492 > > although we declare: > > int b[1], c = 2, d, e, f, g; I'm having the same binary, but it works. However this catches the problem: gcc pr78248.c -Os --verbose-asm -fsanitize=undefined && ./a.out pr78248.c:17:18: runtime error: index 1 out of bounds for type 'int [1]' pr78248.c:17:18: runtime error: load of address 0x006010f8 with insufficient space for an object of type 'int' 0x006010f8: note: pointer points here 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ^ I'm going to investigate which revision introduced the problem.
[Bug sanitizer/78267] [7 Regression] libsanitizer breaks bootstrap on x86_64-apple-darwin16 at r241977
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78267 --- Comment #2 from Dominique d'Humieres --- Unfortunately I don’t know the answers to the questions. I am under OS X 10.12.1 (aka darwin16.1) and Xcode 8.1. /usr/lib/libc.dylib points to libSystem.B.dylib. Dominique > Le 9 nov. 2016 à 08:54, m.ostapenko at samsung dot com > a écrit : > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78267 > > Maxim Ostapenko changed: > > What|Removed |Added > > CC||m.ostapenko at samsung dot com > > --- Comment #1 from Maxim Ostapenko --- > Eh, mine. > > typedef void (^os_trace_payload_t)(xpc_object_t xdict) looks very strange, it > seems that it's an Objective-C declaration, right? > > Could you check: > > 1) Libc version on your system. > 2) Contents of /usr/include/os/trace.h. Is that a valid C header? > > -- > You are receiving this mail because: > You reported the bug.
[Bug c/78270] New: ice in gimplify_switch_expr, at gimplify.c:2272
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78270 Bug ID: 78270 Summary: ice in gimplify_switch_expr, at gimplify.c:2272 Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- Created attachment 40001 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40001&action=edit gzipped C source code The attached code, when compiled by gcc trunk dated 20161109 and the compiler flags -fsanitize=kernel-address --param asan-stack=1 does this net/bluetooth/mgmt.c:5847:2: internal compiler error: in gimplify_switch_expr, at gimplify.c:2272 0x99f9bb gimplify_switch_expr ../../trunk/gcc/gimplify.c:2272 0x99840d gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) ../../trunk/gcc/gimplify.c:11402 0x99bea6 gimplify_stmt(tree_node**, gimple**) ../../trunk/gcc/gimplify.c:6449 0x99758b gimplify_statement_list ../../trunk/gcc/gimplify.c:1703 The source code is from the Linux kernel, so I assume it is quite important to have it working. I'll have a go at reducing the test case code.
[Bug c/78270] ice in gimplify_switch_expr, at gimplify.c:2272
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78270
--- Comment #1 from David Binderman ---
Reduced code
typedef struct {
} bdaddr_t;
struct mgmt_cp_read_local_oob_ext_data {
__u8 type
} fn1() {
struct mgmt_cp_read_local_oob_ext_data *cp;
switch (cp->type)
&(bdaddr_t) {}
[Bug debug/78271] New: Fortran, additional pointer type for deferred length strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78271 Bug ID: 78271 Summary: Fortran, additional pointer type for deferred length strings Product: gcc Version: 6.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: bernhard.heckel at intel dot com Target Milestone: --- Created attachment 40002 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40002&action=edit Debug info Gfortran Debug info for deferred length strings have additional pointer type, which is wrong in my opinion. Assumed length strings seems to be ok. See attached debug info for variable "vara" and "varb". "varb" has additional pointer attribute. Same to "vare" Fortran reproducer is from here: PR78212 Attached also debug info generated by ICC
[Bug debug/78271] Fortran, additional pointer type for deferred length strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78271 --- Comment #1 from Bernhard Heckel --- Created attachment 40003 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40003&action=edit Debug info Icc
[Bug testsuite/78256] [7 Regression] test case gcc.dg/pr35691-1.c fails starting with its introduction in r241915
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78256 Thomas Preud'homme changed: What|Removed |Added CC||thopre01 at gcc dot gnu.org --- Comment #4 from Thomas Preud'homme --- (In reply to prathamesh3492 from comment #3) > Bill, could you please confirm if r241994 fixes the test-cases for you ? > > Thanks, > Prathamesh It fixed the problem for arm-none-eabi (which I was about to report when I saw this) at least. Thanks.
[Bug fortran/46459] ICE (segfault): Invalid read in compare_actual_formal [error recovery]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46459 janus at gcc dot gnu.org changed: What|Removed |Added CC||janus at gcc dot gnu.org --- Comment #8 from janus at gcc dot gnu.org --- As mentioned by Harald, the patch in comment 1 works well and is close to obvious. Mikael, are you going to commit this, or do you want me to do it?
[Bug tree-optimization/78248] [7 Regression] wrong code at -Os and above on x86_64-linux-gnu (in both 32-bit and 64-bit modes)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78248 Martin Liška changed: What|Removed |Added CC||segher at gcc dot gnu.org --- Comment #12 from Martin Liška --- Started with r241824. I'm going to attach pr78248.c.256r.combine dump files, that differ.
[Bug target/78254] FAIL: g++.dg/torture/pr77822.C -O3 -g (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78254 --- Comment #3 from Andreas Schwab --- Author: schwab Date: Wed Nov 9 10:40:00 2016 New Revision: 241996 URL: https://gcc.gnu.org/viewcvs?rev=241996&root=gcc&view=rev Log: PR target/78254 * config/m68k/m68k.md: Reject out-of-range bit pos in bit-fields insns operating on a register. Modified: trunk/gcc/ChangeLog trunk/gcc/config/m68k/m68k.md
[Bug tree-optimization/78248] [7 Regression] wrong code at -Os and above on x86_64-linux-gnu (in both 32-bit and 64-bit modes)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78248 --- Comment #14 from Martin Liška --- Created attachment 40005 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40005&action=edit good combine dump
[Bug target/78254] FAIL: g++.dg/torture/pr77822.C -O3 -g (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78254 Andreas Schwab changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |7.0 --- Comment #4 from Andreas Schwab --- Fixed.
[Bug tree-optimization/78248] [7 Regression] wrong code at -Os and above on x86_64-linux-gnu (in both 32-bit and 64-bit modes)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78248 --- Comment #13 from Martin Liška --- Created attachment 40004 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40004&action=edit bad combine dump
[Bug libstdc++/64735] std::future broken on armel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64735 --- Comment #9 from Pauli --- atomicity.h uses exactly same builtins if _GLIBCXX_ATOMIC_BUILTINS is set 1. Difference include check for __gthread_active_p check and annotations for race detector. Annotations are empty macros in default build. Same code is uses for all other atomic operations in libstdc++. I'm finally having an working armv5te build from gcc-6-branch. I'm currently waiting the second unit test run to complete. If there is no unexpected failures from futures or exceptions I fill submit the complete patch later today.
[Bug sanitizer/78270] [7 Regression] ICE in gimplify_switch_expr, at gimplify.c:2272
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78270 Martin Liška changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2016-11-09 CC||dodji at gcc dot gnu.org, ||dvyukov at gcc dot gnu.org, ||jakub at gcc dot gnu.org, ||kcc at gcc dot gnu.org, ||marxin at gcc dot gnu.org Component|c |sanitizer Summary|ice in |[7 Regression] ICE in |gimplify_switch_expr, at|gimplify_switch_expr, at |gimplify.c:2272 |gimplify.c:2272 Ever confirmed|0 |1 --- Comment #2 from Martin Liška --- Mine, I've just isolated exactly the same test-case. I'm going to test patch for that.
[Bug sanitizer/78270] [7 Regression] ICE in gimplify_switch_expr, at gimplify.c:2272
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78270 Martin Liška changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Target Milestone|--- |7.0
[Bug c++/78269] FAIL: FAIL: g++.dg/cpp1z/noexcept-type11.C and FAIL: g++.dg/cpp1z/noexcept-type9.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78269 Thomas Preud'homme changed: What|Removed |Added Status|NEW |ASSIGNED CC||thopre01 at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |thopre01 at gcc dot gnu.org
[Bug c++/78269] FAIL: FAIL: g++.dg/cpp1z/noexcept-type11.C and FAIL: g++.dg/cpp1z/noexcept-type9.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78269 --- Comment #2 from Thomas Preud'homme --- Author: thopre01 Date: Wed Nov 9 10:50:21 2016 New Revision: 241997 URL: https://gcc.gnu.org/viewcvs?rev=241997&root=gcc&view=rev Log: 2016-11-09 Thomas Preud'homme gcc/testsuite/ PR testsuite/78269 * g++.dg/cpp1z/noexcept-type9.C: Make it a compile test. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/cpp1z/noexcept-type9.C
[Bug c++/78269] FAIL: FAIL: g++.dg/cpp1z/noexcept-type11.C and FAIL: g++.dg/cpp1z/noexcept-type9.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78269 Thomas Preud'homme changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|thopre01 at gcc dot gnu.org|unassigned at gcc dot gnu.org
[Bug c++/78269] FAIL: FAIL: g++.dg/cpp1z/noexcept-type11.C and FAIL: g++.dg/cpp1z/noexcept-type9.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78269 --- Comment #3 from Thomas Preud'homme --- Marking the bug as NEW again because g++.dg/cpp1z/noexcept-type11.C still needs fixing
[Bug fortran/46459] ICE (segfault): Invalid read in compare_actual_formal [error recovery]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46459 --- Comment #9 from janus at gcc dot gnu.org --- (In reply to janus from comment #8) > As mentioned by Harald, the patch in comment 1 works well and is close to > obvious. I verified that it regtests cleanly. Adapted to current trunk it looks like this: Index: gcc/fortran/interface.c === --- gcc/fortran/interface.c (Revision 241993) +++ gcc/fortran/interface.c (Arbeitskopie) @@ -3190,6 +3190,7 @@ compare_actual_formal (gfc_actual_arglist **ap, gf shape array, if the dummy argument has the VOLATILE attribute. */ if (f->sym->attr.volatile_ + && a->expr->expr_type == EXPR_VARIABLE && a->expr->symtree->n.sym->as && a->expr->symtree->n.sym->as->type == AS_ASSUMED_SHAPE && !(f->sym->as && f->sym->as->type == AS_ASSUMED_SHAPE)) @@ -3219,6 +3220,7 @@ compare_actual_formal (gfc_actual_arglist **ap, gf dummy argument has the VOLATILE attribute. */ if (f->sym->attr.volatile_ + && a->expr->expr_type == EXPR_VARIABLE && a->expr->symtree->n.sym->attr.pointer && a->expr->symtree->n.sym->as && !(f->sym->as
[Bug fortran/60777] [F03] RECURSIVE function rejected in specification expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60777 janus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |janus at gcc dot gnu.org Target Milestone|--- |7.0 --- Comment #5 from janus at gcc dot gnu.org --- (In reply to kargl from comment #4) > If > you feel that the patch in comment #3 is correct, you are > more than welcomed to commit it. It does look good at first glance. I'll test it and commit if successful.
[Bug tree-optimization/78272] New: [7 Regression] ICE in unshare_expr_without_location while building 471.omnetpp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78272
Bug ID: 78272
Summary: [7 Regression] ICE in unshare_expr_without_location
while building 471.omnetpp
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: ktkachov at gcc dot gnu.org
Target Milestone: ---
I'm seeing a segfault in ipa-prop.c when building SPEC2006, omnetpp in
particular.
The reduced testcase is:
class A
{
public:
A ();
};
int a;
int
fn1 (double, int)
{
new A;
}
int
fn2 (int rng)
{
if (a)
return fn1 (2.0, rng);
}
int
fn3 (double rng)
{
fn2 (rng);
}
Compiling with -Ofast on aarch64-none-linux-gnu gives the ICE:
distrib.cpp:24:1: internal compiler error: Segmentation fault
}
^
0xd4aabf crash_signal
$SRC/gcc/toplev.c:338
0xad6f24 unshare_expr_without_location(tree_node*)
$SRC/gcc/gimplify.c:978
0xb8057a ipa_set_jf_arith_pass_through
$SRC/gcc/ipa-prop.c:468
0xb8057a update_jump_functions_after_inlining
$SRC/gcc/ipa-prop.c:2645
0xb8618d propagate_info_to_inlined_callees
$SRC/gcc/ipa-prop.c:3407
0xb86f8f ipa_propagate_indirect_call_infos(cgraph_edge*, vec*)
$SRC/gcc/ipa-prop.c:3561
0x132ff94 inline_call(cgraph_edge*, bool, vec*,
int*, bool, bool*)
$SRC/gcc/ipa-inline-transform.c:447
0x13285a6 inline_small_functions
$SRC/gcc/ipa-inline.c:2029
0x13285a6 ipa_inline
$SRC/gcc/ipa-inline.c:2439
0x13285a6 execute
$SRC/gcc/ipa-inline.c:2850
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
[Bug tree-optimization/78272] [7 Regression] ICE in unshare_expr_without_location while building 471.omnetpp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78272 ktkachov at gcc dot gnu.org changed: What|Removed |Added Known to work||6.2.1 Target Milestone|--- |7.0 Known to fail||7.0
[Bug tree-optimization/78272] [7 Regression] ICE in unshare_expr_without_location while building 471.omnetpp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78272 --- Comment #1 from ktkachov at gcc dot gnu.org --- Started with r241990
[Bug libstdc++/78273] New: The transparent version of {map,set}::count should call _M_count_tr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78273
Bug ID: 78273
Summary: The transparent version of {map,set}::count should
call _M_count_tr
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: rs2740 at gmail dot com
Target Milestone: ---
They are currently
> template
> auto
> count(const _Kt& __x) const
> -> decltype(_M_t._M_count_tr(__x))
> { return _M_t._M_find_tr(__x) == _M_t.end() ? 0 : 1; }
but there is no requirement that at most one key in the container compare
equivalent to the heterogeneous key; the only requirement is that the keys of
the elements in the container be suitably partitioned with respect to the
heterogeneous key. Thus, they should simply return _M_t._M_count_tr(__x);.
[Bug c++/78274] New: Rejected specialization in different namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78274
Bug ID: 78274
Summary: Rejected specialization in different namespace
Product: gcc
Version: 6.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
I've noticed that clang++ accepts, but g++ rejects:
namespace std { template struct tuple_size; }
struct A { int x, y, z; };
template<> struct std::tuple_size { static const int value = 3; };
constexpr int a = std::tuple_size::value;
test.C:3:24: error: specialization of ‘template struct
std::tuple_size’ in different namespace [-fpermissive]
template<> struct std::tuple_size { static const int value = 3; };
^
test.C:1:45: error: from definition of ‘template struct
std::tuple_size’ [-fpermissive]
namespace std { template struct tuple_size; }
^~
Is that a g++ or clang++ bug?
[Bug sanitizer/61978] implement blacklist for sanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61978 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #11 from Martin Liška --- (In reply to Manuel López-Ibáñez from comment #10) > (In reply to Stewart Martin-Haugh from comment #9) > > Hi, > > I see this marked as WONTFIX - still, the use-cases that Kostya identifies > > are valid, I think. Would anyone be able to implement a patch, or suggest > > roughly how this might work? > > Although existing GCC devs may not find this feature interesting enough to > implement it themselves, a nice, small patch properly submitted together > with a convincingly argued rationale may get accepted. It seems this feature > is being used not only by Chromium but also by LibreOffice, and many GCC > users would still like to keep using GCC for building those programs. > > Many features that were initially rejected have been later accepted (e.g., > color diagnostics). It just needs someone to get behind the idea and push > for it in the right way. I welcome the idea of blacklist support and I can probably come up with a patch for that. I'm also thinking about supression of a repeated error. Running instrumented firefox binary produces >60K errors just during start up.
[Bug rtl-optimization/78200] [7 Regression] 429.mcf of cpu2006 regresses in GCC trunk for avx2 target.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78200
--- Comment #9 from Richard Biener ---
So RTL expansion ends up in
/* If jumps are cheap and the target does not support conditional
compare, turn some more codes into jumpy sequences. */
else if (BRANCH_COST (optimize_insn_for_speed_p (), false) < 4
&& targetm.gen_ccmp_first == NULL)
{
if ((code2 == BIT_AND_EXPR
&& TYPE_PRECISION (TREE_TYPE (op0)) == 1
&& TREE_CODE (gimple_assign_rhs2 (second)) != INTEGER_CST)
|| code2 == TRUTH_AND_EXPR)
{
code = TRUTH_ANDIF_EXPR;
op0 = gimple_assign_rhs1 (second);
op1 = gimple_assign_rhs2 (second);
where we could adjust operand order based on the immediately dominating
condition.
Unfortunately sth as simple as
/* We'll expand RTL for op0 first, see if we'd better
expand RTL for op1 first. */
if (TREE_CODE (op1) == SSA_NAME
&& single_pred_p (bb))
{
gimple *def1 = SSA_NAME_DEF_STMT (op1);
if (is_gimple_assign (def1)
&& TREE_CODE_CLASS (gimple_assign_rhs_code (def1)) ==
tcc_comparison)
{
basic_block pred = single_pred (bb);
gimple *last = last_stmt (pred);
if (last
&& gimple_code (last) == GIMPLE_COND
&& gimple_assign_rhs1 (def1) == gimple_cond_lhs
(last))
std::swap (op0, op1);
}
}
doesn't work as the predecessor is no longer in GIMPLE (we dropped the seq
for the GIMPLE stmts and GIMPLE_CONDs have no DEFs...). Also I'm not sure
the half-way RTL CFG will still point to the original block.
Of course the above heuristic is really only applicable if there's not much
code expanded between this jump and the one in the predecessor.
OTOH if we have the BRANCH_COST check during RTL expansion (similar to
what we have for LOGICAL_OP_NON_SHORT_CIRCUIT in fold-const.c) then maybe
if-combining shouldn't combine the conditionals. There's a slight disconnect
here, the above is BRANCH_COST < 4 while the other is BRANCH_COST >= 2 ...
The cfgexpand code could also be done as a pre-pass on the IL turning
the straight-line code back to CFG (I guess that's a good idea anyway).
[Bug ipa/78268] [7 Regression] internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78268 Markus Trippelsdorf changed: What|Removed |Added CC||ktkachov at gcc dot gnu.org --- Comment #4 from Markus Trippelsdorf --- *** Bug 78272 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/78272] [7 Regression] ICE in unshare_expr_without_location while building 471.omnetpp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78272 Markus Trippelsdorf changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||trippels at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #2 from Markus Trippelsdorf --- dup. *** This bug has been marked as a duplicate of bug 78268 ***
[Bug rtl-optimization/78200] [7 Regression] 429.mcf of cpu2006 regresses in GCC trunk for avx2 target.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78200
--- Comment #10 from Richard Biener ---
OTOH we _do_ have initial RTL
(insn 167 166 168 20 (set (reg:CCGOC 17 flags)
(compare:CCGOC (reg/v:DI 217 [ red_cost ])
(const_int 0 [0]))) "pbeampp.c":42 -1
(nil))
(jump_insn 168 167 169 20 (set (pc)
(if_then_else (ge (reg:CCGOC 17 flags)
(const_int 0 [0]))
(label_ref 175)
(pc))) "pbeampp.c":42 -1
(int_list:REG_BR_PROB 6400 (nil))
-> 175)
;; succ: 21 [36.0%] (FALLTHRU)
;; 23 [64.0%]
;; basic block 23, loop depth 2, count 0, freq 1067, maybe hot
;; Invalid sum of incoming frequencies 1216, should be 1067
;; prev block 22, next block 24, flags: (NEW, REACHABLE, RTL, MODIFIED,
VISITED)
;; pred: 20 [64.0%]
(code_label 175 173 176 23 98 "" [1 uses])
(note 176 175 177 23 [bb 23] NOTE_INSN_BASIC_BLOCK)
(insn 177 176 178 23 (set (reg:CCNO 17 flags)
(compare:CCNO (reg/v:DI 217 [ red_cost ])
(const_int 0 [0]))) "pbeampp.c":42 -1
(nil))
(insn 178 177 179 23 (set (reg:QI 273)
(gt:QI (reg:CCNO 17 flags)
(const_int 0 [0]))) "pbeampp.c":42 -1
(nil))
(insn 179 178 180 23 (set (reg:CCZ 17 flags)
(compare:CCZ (reg:QI 273)
(const_int 0 [0]))) "pbeampp.c":42 -1
(nil))
(jump_insn 180 179 587 23 (set (pc)
(if_then_else (eq (reg:CCZ 17 flags)
(const_int 0 [0]))
(label_ref 196)
(pc))) "pbeampp.c":42 -1
(int_list:REG_BR_PROB 3300 (nil))
-> 196)
that is, it compares in a sensible order allowing for combining (which
appearantly is what causes the code to run slower for not yet explored
reasons).
Expanding the other way around does not have any justification IMHO
and thus the "fix" would be to the later stage where we combine
the compare with the one on the backedge.
The issue is CSE2 which does
(insn 167 166 168 21 (set (reg:CC 17 flags)
(compare:CC (reg/v:DI 217 [ red_cost ])
(const_int 0 [0]))) "pbeampp.c":42 8 {*cmpdi_1}
(nil))
(jump_insn 168 167 169 21 (set (pc)
(if_then_else (ge (reg:CC 17 flags)
(const_int 0 [0]))
(label_ref 175)
(pc))) "pbeampp.c":42 635 {*jcc_1}
(expr_list:REG_DEAD (reg:CC 17 flags)
(int_list:REG_BR_PROB 6400 (nil)))
-> 175)
...
(insn 178 176 179 24 (set (reg:QI 273)
(gt:QI (reg:CC 17 flags)
(const_int 0 [0]))) "pbeampp.c":42 631 {*setcc_qi}
(expr_list:REG_DEAD (reg:CC 17 flags)
(nil)))
thus changes the earlier compare to CC and re-uses that CCmode. Note it's
still a mystery to me why this is slower (and I did not reproduce that myself
yet).
Then we combine it to
(insn 167 166 168 18 (set (reg:CC 17 flags)
(compare:CC (reg/v:DI 217 [ red_cost ])
(const_int 0 [0]))) "pbeampp.c":42 8 {*cmpdi_1}
(nil))
(jump_insn 168 167 169 18 (set (pc)
(if_then_else (ge (reg:CC 17 flags)
(const_int 0 [0]))
(label_ref 175)
(pc))) "pbeampp.c":42 635 {*jcc_1}
(int_list:REG_BR_PROB 6400 (nil))
-> 175)
;; succ: 19 [36.0%] (FALLTHRU)
;; 20 [64.0%]
;; basic block 20, loop depth 0, count 0, freq 1067, maybe hot
;; Invalid sum of incoming frequencies 1216, should be 1067
(jump_insn 180 179 587 20 (set (pc)
(if_then_else (le (reg:CC 17 flags)
(const_int 0 [0]))
(label_ref:DI 196)
(pc))) "pbeampp.c":42 635 {*jcc_1}
(int_list:REG_BR_PROB 3300 (expr_list:REG_DEAD (reg:CCZ 17 flags)
(nil)))
[Bug rtl-optimization/78200] [7 Regression] 429.mcf of cpu2006 regresses in GCC trunk for avx2 target.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78200
--- Comment #11 from Venkataramanan ---
Hi Richard
On haswell machine original run time for -O3 -max2 -mprefer-avx2
real2m35.325s
user2m35.257s
sys 0m0.070s
Changing the assembly from
.L98:
jle .L97
cmpl$2, %r9d
jne .L97
.L99:
To
.L98:
cmpl$2, %r9d
jne .L97
cmpq$0, %rdi
jle .L97
.L99:
real2m27.224s
user2m27.138s
sys 0m0.087s
improves run time.
> -Original Message-
> From: rguenth at gcc dot gnu.org [mailto:gcc-bugzi...@gcc.gnu.org]
> Sent: Wednesday, November 9, 2016 6:02 PM
> To: Kumar, Venkataramanan
> Subject: [Bug rtl-optimization/78200] [7 Regression] 429.mcf of cpu2006
> regresses in GCC trunk for avx2 target.
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78200
>
> --- Comment #10 from Richard Biener --- OTOH we
> _do_ have initial RTL
>
> (insn 167 166 168 20 (set (reg:CCGOC 17 flags)
> (compare:CCGOC (reg/v:DI 217 [ red_cost ])
> (const_int 0 [0]))) "pbeampp.c":42 -1
> (nil))
> (jump_insn 168 167 169 20 (set (pc)
> (if_then_else (ge (reg:CCGOC 17 flags)
> (const_int 0 [0]))
> (label_ref 175)
> (pc))) "pbeampp.c":42 -1
> (int_list:REG_BR_PROB 6400 (nil))
> -> 175)
> ;; succ: 21 [36.0%] (FALLTHRU)
> ;; 23 [64.0%]
>
> ;; basic block 23, loop depth 2, count 0, freq 1067, maybe hot ;; Invalid sum
> of
> incoming frequencies 1216, should be 1067 ;; prev block 22, next block 24,
> flags: (NEW, REACHABLE, RTL, MODIFIED,
> VISITED)
> ;; pred: 20 [64.0%]
> (code_label 175 173 176 23 98 "" [1 uses]) (note 176 175 177 23 [bb 23]
> NOTE_INSN_BASIC_BLOCK) (insn 177 176 178 23 (set (reg:CCNO 17 flags)
> (compare:CCNO (reg/v:DI 217 [ red_cost ])
> (const_int 0 [0]))) "pbeampp.c":42 -1
> (nil))
> (insn 178 177 179 23 (set (reg:QI 273)
> (gt:QI (reg:CCNO 17 flags)
> (const_int 0 [0]))) "pbeampp.c":42 -1
> (nil))
> (insn 179 178 180 23 (set (reg:CCZ 17 flags)
> (compare:CCZ (reg:QI 273)
> (const_int 0 [0]))) "pbeampp.c":42 -1
> (nil))
> (jump_insn 180 179 587 23 (set (pc)
> (if_then_else (eq (reg:CCZ 17 flags)
> (const_int 0 [0]))
> (label_ref 196)
> (pc))) "pbeampp.c":42 -1
> (int_list:REG_BR_PROB 3300 (nil))
> -> 196)
>
> that is, it compares in a sensible order allowing for combining (which
> appearantly is what causes the code to run slower for not yet explored
> reasons).
>
> Expanding the other way around does not have any justification IMHO and thus
> the "fix" would be to the later stage where we combine the compare with the
> one on the backedge.
>
> The issue is CSE2 which does
>
> (insn 167 166 168 21 (set (reg:CC 17 flags)
> (compare:CC (reg/v:DI 217 [ red_cost ])
> (const_int 0 [0]))) "pbeampp.c":42 8 {*cmpdi_1}
> (nil))
> (jump_insn 168 167 169 21 (set (pc)
> (if_then_else (ge (reg:CC 17 flags)
> (const_int 0 [0]))
> (label_ref 175)
> (pc))) "pbeampp.c":42 635 {*jcc_1}
> (expr_list:REG_DEAD (reg:CC 17 flags)
> (int_list:REG_BR_PROB 6400 (nil))) -> 175) ...
> (insn 178 176 179 24 (set (reg:QI 273)
> (gt:QI (reg:CC 17 flags)
> (const_int 0 [0]))) "pbeampp.c":42 631 {*setcc_qi}
> (expr_list:REG_DEAD (reg:CC 17 flags)
> (nil)))
>
> thus changes the earlier compare to CC and re-uses that CCmode. Note it's
> still
> a mystery to me why this is slower (and I did not reproduce that myself yet).
>
> Then we combine it to
>
> (insn 167 166 168 18 (set (reg:CC 17 flags)
> (compare:CC (reg/v:DI 217 [ red_cost ])
> (const_int 0 [0]))) "pbeampp.c":42 8 {*cmpdi_1}
> (nil))
> (jump_insn 168 167 169 18 (set (pc)
> (if_then_else (ge (reg:CC 17 flags)
> (const_int 0 [0]))
> (label_ref 175)
> (pc))) "pbeampp.c":42 635 {*jcc_1}
> (int_list:REG_BR_PROB 6400 (nil))
> -> 175)
> ;; succ: 19 [36.0%] (FALLTHRU)
> ;; 20 [64.0%]
>
>
> ;; basic block 20, loop depth 0, count 0, freq 1067, maybe hot ;; Invalid sum
> of
> incoming frequencies 1216, should be 1067 (jump_insn 180 179 587 20 (set (pc)
> (if_then_else (le (reg:CC 17 flags)
> (const_int 0 [0]))
> (label_ref:DI 196)
> (pc))) "pbeampp.c":42 635 {*jcc_1}
> (int_list:REG_BR_PROB 3300 (expr_list:REG_DEAD (reg:CCZ 17 flags)
> (nil)))
>
> --
> You are receiving this mail because:
> You reported the bug.
[Bug c++/78263] Compile failure with AltiVec library on PPC64le and -std=c++11 flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78263 Bill Schmidt changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-11-09 Ever confirmed|0 |1 --- Comment #4 from Bill Schmidt --- I agree, Richard -- leaving this bug open for that purpose. We will try to get to this in stage 3.
[Bug target/78275] New: [avr] at43usb320 in wrong multilib set.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78275 Bug ID: 78275 Summary: [avr] at43usb320 in wrong multilib set. Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: gjl at gcc dot gnu.org Target Milestone: --- avr-mcus.def currenly lists at43usb320 as belonging to avr31. This is not correct because the device can only handle 64 KiB of (external) program memory but avr31 is for devices with 128 KiB (supports ELPM which is not supported by at43usb320). As the data sheet does not mention the exact instruction set supported, it's unclear if avr3 is the correct multilib (likely) or avr35 (if MOVW) or even avr5 (of MUL).
[Bug target/78275] [avr] at43usb320 in wrong multilib set.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78275 Georg-Johann Lay changed: What|Removed |Added Target||avr Priority|P3 |P4
[Bug rtl-optimization/78200] [7 Regression] 429.mcf of cpu2006 regresses in GCC trunk for avx2 target.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78200 --- Comment #12 from Richard Biener --- Btw, I see with -mavx2 addq(%r9), %rax jns .L90 .L90: je .L92 cmpl$2, 24(%rdx) je .L91 thus there is no extra cmpq $0, %rdi in the predecessor. Note when I profile avx (base) vs. avx2 (peak) I see 18.17%451662 mcf_base.amd64- mcf_base.amd64-m64-gcc42-nn [.] refresh_potential 18.12%424592 mcf_base.amd64- mcf_base.amd64-m64-gcc42-nn [.] primal_bea_mpp 17.96%465325 mcf_peak.amd64- mcf_peak.amd64-m64-gcc42-nn [.] primal_bea_mpp 14.93%373309 mcf_peak.amd64- mcf_peak.amd64-m64-gcc42-nn [.] refresh_potential plus a 3-run of avx (base) vs. avx2 (peak) gives me 429.mcf 9120252 36.1 *9120264 34.6 S 429.mcf 9120257 35.5 S9120253 36.0 S 429.mcf 9120232 39.3 S9120258 35.4 * which isn't really conclusive. If you are trying to narrow down a regression GCC 6 vs. GCC 7 I wouldn't look at flags but at profiling and what changed.
[Bug fortran/78259] [7 Regression] ICE in gfc_trans_subcomponent_assign, at fortran/trans-expr.c:7330
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78259 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P4 CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Indeed, started with r241626.
[Bug ipa/78258] [7 Regression] ICE in compare_values_warnv, at tree-vrp.c:1218
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78258 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Started with r240292.
[Bug rtl-optimization/78200] [7 Regression] 429.mcf of cpu2006 regresses in GCC trunk for avx2 target.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78200 --- Comment #13 from Richard Biener --- When I compare GCC 6 (r241818) against trunk (r241997) with -Ofast -march=native (on Haswell) I get 429.mcf 9120230 39.7 S9120240 38.0 * 429.mcf 9120227 40.1 S9120244 37.4 S 429.mcf 9120230 39.7 *9120237 38.6 S thats ~5% regression. Profiling that shows 20.89%398295 mcf_peak.amd64- mcf_peak.amd64-m64-gcc42-nn [.] primal_bea_mpp 18.34%349619 mcf_base.amd64- mcf_base.amd64-m64-gcc42-nn [.] primal_bea_mpp 15.45%294258 mcf_peak.amd64- mcf_peak.amd64-m64-gcc42-nn [.] refresh_potential 13.53%257796 mcf_base.amd64- mcf_base.amd64-m64-gcc42-nn [.] refresh_potential
[Bug tree-optimization/78257] missing memcmp optimization with constant arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78257 --- Comment #3 from Martin Liška --- 'f0' function is optimized out as of r242000
[Bug c/77750] [7 Regression] gcc build not working with -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77750
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #7 from Jakub Jelinek ---
I don't see why the #c6 patch should be necessary, nor can reproduce this.
Are you using some older trunk version as bootstrap compiler, or something
similar?
E.g. the first case is:
case LT:
/* < C is equivalent to <= (C - 1) */
if (const_op > 0)
{
const_op -= 1;
code = LE;
/* ... fall through to LE case below. */
gcc_fallthrough ();
}
else
break;
case LE:
and there really is no need for any fallthrough comment, gcc_fallthrough ();
already represents that and works even at -O0.
[Bug tree-optimization/77719] [7 Regression] ICE in pp_string, at pretty-print.c:955
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77719 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |FIXED --- Comment #8 from Jakub Jelinek --- Assuming fixed.
[Bug fortran/60777] [F03] RECURSIVE function rejected in specification expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60777
--- Comment #6 from janus at gcc dot gnu.org ---
I think the patch in comment 1 actually does not work as expected (due to a
spurious semicolon).
However, this variant seems to work well and regtests cleanly:
Index: gcc/fortran/expr.c
===
--- gcc/fortran/expr.c (revision 241997)
+++ gcc/fortran/expr.c (working copy)
@@ -2794,12 +2794,12 @@
return false;
}
- if (f->attr.recursive)
-{
- gfc_error ("Specification function %qs at %L cannot be RECURSIVE",
-f->name, &e->where);
+ /* F08:7.1.11.6. */
+ if (f->attr.recursive
+ && !gfc_notify_std (GFC_STD_F2003,
+ "Specification function '%s' "
+ "at %L cannot be RECURSIVE", f->name, &e->where))
return false;
-}
function_allowed:
return restricted_args (e->value.function.actual);
I will commit this soon.
[Bug middle-end/71762] [5/6/7 Regression] ~X & Y to X < Y doesn't work for uninitialized values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71762 Richard Biener changed: What|Removed |Added CC||law at gcc dot gnu.org --- Comment #6 from Richard Biener --- The easiest "fix" might be to expand X < Y of 1-bit entities back to and-not... Or to remove these patterns from match.pd again, because if expansion needs to insert truncations for them to be valid that's never going to be a win. Jeff, you added those initially: 2013-06-19 Jeff Law * tree-ssa-forwprop.c (simplify_bitwise_binary_boolean): Fix typo in comment. * tree-ssa-forwprop.c (simplify_bitwise_binary_boolean): New function. (simplify_bitwise_binary): Use it to simpify certain binary ops on booleans. any preference? I'd rip them out and maybe teach the transform to combine/simplify-rtx which could check known-zero-bits to make sure the upper bits are not undefined.
[Bug libstdc++/78276] New: regex_search is slow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78276 Bug ID: 78276 Summary: regex_search is slow Product: gcc Version: 6.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: idrazil at fit dot vutbr.cz Target Milestone: --- Created attachment 40006 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40006&action=edit Example with bug I tried match this string "\r\n" with regexp "(?:[^\r\n]*)*?". GCC 4.9 can solve it almost instantly but at 6.2 (I've also tried 6.1) it takes on my computer more than 5 seconds. I've discovered increasing count of letter "a" also increase (probably exponentially) solving time of regexp. The problem goes away when I've alternated regexp to "[^\r\n]*?". (In this case the change is possible but my original code contains more complex regexp with the same problem) Full example is at the attachment.
[Bug testsuite/78256] [7 Regression] test case gcc.dg/pr35691-1.c fails starting with its introduction in r241915
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78256 --- Comment #5 from Bill Seurer --- Looks good on power, too. Thanks!
[Bug tree-optimization/78248] [7 Regression] wrong code at -Os and above on x86_64-linux-gnu (in both 32-bit and 64-bit modes)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78248 --- Comment #15 from Segher Boessenkool --- Hi, could you try https://gcc.gnu.org/ml/gcc-patches/2016-11/msg00775.html ? And sorry for the breakage.
[Bug testsuite/78256] [7 Regression] test case gcc.dg/pr35691-1.c fails starting with its introduction in r241915
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78256 prathamesh3492 at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #6 from prathamesh3492 at gcc dot gnu.org --- Thanks Thomas and Bill for confirming, I will mark it as fixed.
[Bug ipa/78268] [7 Regression] internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78268 Yuri Rumyantsev changed: What|Removed |Added CC||ysrumyan at gmail dot com --- Comment #5 from Yuri Rumyantsev --- We just got ICE for 471.omnetpp on x86 with guilty revision r241990
[Bug middle-end/71762] [5/6/7 Regression] ~X & Y to X < Y doesn't work for uninitialized values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71762 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com --- Comment #7 from Jeffrey A. Law --- ISTM the transformation is valid on gimple, but that at RTL expansion time we don't guarantee the range of the uninitialized object is [01]. And yes, if we have to insert truncations this transformation becomes a lose. One approach would be something similar to the unswitching on an uninitialized value fix that I need to get back to -- ensure the values are initialized and if they aren't, don't allow the transformation. I wouldn't be surprised if there are other places where using type/vrp information on a sub-word sized object that is uninitialized is going to cause problems. I don't think losing the transformations would be that big of a deal either. My recollection is they definitely triggered in GCC itself, but I don't have a sense of how often.
[Bug middle-end/77718] [7 Regression] expand_builtin_memcmp swaps args
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77718 --- Comment #7 from Jakub Jelinek --- Author: jakub Date: Wed Nov 9 16:21:45 2016 New Revision: 242007 URL: https://gcc.gnu.org/viewcvs?rev=242007&root=gcc&view=rev Log: PR target/77718 * builtins.c (expand_builtin_memcmp): Formatting fix. * gcc.c-torture/execute/pr77718.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr77718.c Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/77718] [7 Regression] expand_builtin_memcmp swaps args
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77718 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |FIXED --- Comment #8 from Jakub Jelinek --- Author: acsawdey Date: Thu Sep 29 16:21:20 2016 New Revision: 240625 URL: https://gcc.gnu.org/viewcvs?rev=240625&root=gcc&view=rev Log: 2016-09-29 Bernd Schmidt * builtins.c (expand_builtin_memcmp): don't swap args unless result is only being compared with zero. Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c
[Bug debug/78265] Excess emission of debug info for ODR used global variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78265
--- Comment #2 from David Blaikie ---
A side note/commentary:
Producing debug info for global variable declarations at all is an interesting
choice. If the whole program is built with debug info*, the global variable's
definition will have debug info and that should suffice, I think.
(* other optimizations in debug info that are the default for GCC make this
assumption (the vtable based class debug info optimization: struct foo {
virtual void f(); }; foo f; /* 'foo' emitted as a declaration here, a
definition wherever 'foo::f' is defined), so it would seem consistent to never
emit debug info for global variable declarations - with a flag to turn off this
assumption/optimization)
I mention this as it may make it easier to address this bug that way (though,
understandably, supporting the old behavior under a flag would be good and thus
this bug would still be an issue whenever that flag was used)
[Bug fortran/65173] ICE while compiling wrong code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65173 --- Comment #7 from Dominique d'Humieres --- Compiling the test in comment 0 with and instrumented gfortran I get pr65173.f90:7:45: real*8, dimension(256), allocatable :: x 1 Error: Allocatable component of structure at (1) must have a deferred shape pr65173.f90:8:52: real*8, dimension(2,256), allocatable :: bounds 1 Error: Allocatable component of structure at (1) must have a deferred shape pr65173.f90:9:67: character(string_length), dimension(256), allocatable :: names 1 Error: Allocatable component of structure at (1) must have a deferred shape pr65173.f90:13:28: character(*), dimension(), parameter :: char_params = ['element','parametrization'] 1 Error: Expected expression in array specification at (1) = ==23996==ERROR: AddressSanitizer: heap-use-after-free on address 0x6040bf10 at pc 0x0001002a2d95 bp 0x7fff5fbfe830 sp 0x7fff5fbfe828 READ of size 8 at 0x6040bf10 thread T0 #0 0x1002a2d94 in resolve_component(gfc_component*, gfc_symbol*) (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/f951+0x1002a2d94) #1 0x1002a5440 in resolve_fl_derived0(gfc_symbol*) (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/f951+0x1002a5440) #2 0x1002a61bd in resolve_fl_derived(gfc_symbol*) (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/f951+0x1002a61bd) #3 0x1002966c8 in resolve_symbol(gfc_symbol*) (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/f951+0x1002966c8) #4 0x10032dacc in do_traverse_symtree(gfc_symtree*, void (*)(gfc_symtree*), void (*)(gfc_symbol*)) (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/f951+0x10032dacc) #5 0x100345881 in gfc_traverse_ns(gfc_namespace*, void (*)(gfc_symbol*)) (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/f951+0x100345881) #6 0x1002d51ed in resolve_types(gfc_namespace*) (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/f951+0x1002d51ed) #7 0x100293315 in gfc_resolve(gfc_namespace*) (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/f951+0x100293315) #8 0x100223cdc in resolve_all_program_units(gfc_namespace*) (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/f951+0x100223cdc) #9 0x10023e38e in gfc_parse_file() (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/f951+0x10023e38e) #10 0x10038020a in gfc_be_parse_file() (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/f951+0x10038020a) #11 0x103bf0124 in compile_file() (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/f951+0x103bf0124) #12 0x103bf92ee in do_compile() (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/f951+0x103bf92ee) #13 0x10568dc2f in toplev::main(int, char**) (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/f951+0x10568dc2f) #14 0x105692be5 in main (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/f951+0x105692be5) #15 0x7fffe8d83254 in start (/usr/lib/system/libdyld.dylib+0x5254) #16 0xd (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/f951+0xd) 0x6040bf10 is located 0 bytes inside of 48-byte region [0x6040bf10,0x6040bf40) freed by thread T0 here: #0 0x15078e690 in wrap_free.part.0 (/opt/gcc/gcc7a/lib/libasan.3.dylib+0x53690) #1 0x1003446ba in gfc_free_charlen(gfc_charlen*, gfc_charlen*) (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/f951+0x1003446ba) #2 0x10022400d in reject_statement() (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/f951+0x10022400d) #3 0x100224373 in match_word(char const*, match (*)(), locus*) (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/f951+0x100224373) #4 0x1002322bd in decode_statement() (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/f951+0x1002322bd) #5 0x10023427b in next_free() (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/f951+0x10023427b) #6 0x100234af9 in next_statement() (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/f951+0x100234af9) #7 0x10023679d in parse_derived() (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/f951+0x10023679d) #8 0x100238b9b in parse_spec(gfc_statement) (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/f951+0x100238b9b) #9 0x10023c78b in parse_progunit(gfc_statement) (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/f951+0x10023c78b) #10 0x10023e350 in gfc_parse_file() (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/f951+0x10023e350) #11 0x10038020a in gfc_be_parse_file() (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/f951+0x10038020a) #12 0x103bf0124 in compile_file() (/opt/gcc/gcc7g/libexec/gc
[Bug sanitizer/78267] [7 Regression] libsanitizer breaks bootstrap on x86_64-apple-darwin16 at r241977
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78267 --- Comment #3 from Iain Sandoe --- (In reply to Maxim Ostapenko from comment #1) > Eh, mine. > > typedef void (^os_trace_payload_t)(xpc_object_t xdict) looks very strange, > it seems that it's an Objective-C declaration, right? It's declaring os_trace_payload_t to of type "Apple block" (like a lambda that can be used over the whole of c-family); Apple blocks are currently not supported by GCC. There is no realistic work-around, any interface using blocks will fail, and thus either those interfaces need to be excluded from tests, or the tests skipped/xfailed. > > Could you check: > > 1) Libc version on your system. > 2) Contents of /usr/include/os/trace.h. Is that a valid C header?
[Bug fortran/65173] ICE while compiling wrong code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65173 --- Comment #8 from Dominique d'Humieres --- Note that the tests z1.f90 and z8.f90 fail in a different way: pr65173_3.f90:3:39: character(:), allocatable :: x(n) 1 Error: Allocatable component of structure at (1) must have a deferred shape = ==24015==ERROR: AddressSanitizer: heap-use-after-free on address 0x6040cbf8 at pc 0x0001002b5734 bp 0x7fff5fbfe660 sp 0x7fff5fbfe658 READ of size 8 at 0x6040cbf8 thread T0 #0 0x1002b5733 in check_host_association(gfc_expr*) (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/f951+0x1002b5733) #1 0x1002ae1d7 in gfc_resolve_expr(gfc_expr*) (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/f951+0x1002ae1d7) #2 0x1e80a (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/f951+0x1e80a) #3 0x100014067 in gfc_resolve_array_spec(gfc_array_spec*, int) (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/f951+0x100014067) #4 0x1002a2754 in resolve_component(gfc_component*, gfc_symbol*) (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/f951+0x1002a2754) #5 0x1002a5440 in resolve_fl_derived0(gfc_symbol*) (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/f951+0x1002a5440) #6 0x1002a61bd in resolve_fl_derived(gfc_symbol*) (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/f951+0x1002a61bd) #7 0x1002966c8 in resolve_symbol(gfc_symbol*) (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/f951+0x1002966c8) #8 0x10032dacc in do_traverse_symtree(gfc_symtree*, void (*)(gfc_symtree*), void (*)(gfc_symbol*)) (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/f951+0x10032dacc) #9 0x100345881 in gfc_traverse_ns(gfc_namespace*, void (*)(gfc_symbol*)) (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/f951+0x100345881) #10 0x1002d51ed in resolve_types(gfc_namespace*) (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/f951+0x1002d51ed) #11 0x100293315 in gfc_resolve(gfc_namespace*) (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/f951+0x100293315) #12 0x100223cdc in resolve_all_program_units(gfc_namespace*) (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/f951+0x100223cdc) #13 0x10023e38e in gfc_parse_file() (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/f951+0x10023e38e) #14 0x10038020a in gfc_be_parse_file() (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/f951+0x10038020a) #15 0x103bf0124 in compile_file() (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/f951+0x103bf0124) #16 0x103bf92ee in do_compile() (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/f951+0x103bf92ee) #17 0x10568dc2f in toplev::main(int, char**) (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/f951+0x10568dc2f) #18 0x105692be5 in main (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/f951+0x105692be5) #19 0x7fffe8d83254 in start (/usr/lib/system/libdyld.dylib+0x5254) #20 0xd (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/f951+0xd) 0x6040cbf8 is located 40 bytes inside of 48-byte region [0x6040cbd0,0x6040cc00) freed by thread T0 here: #0 0x15078e690 in wrap_free.part.0 (/opt/gcc/gcc7a/lib/libasan.3.dylib+0x53690) #1 0x10033ce36 in gfc_delete_symtree(gfc_symtree**, char const*) (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/f951+0x10033ce36) #2 0x1003511bf in gfc_restore_last_undo_checkpoint() (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/f951+0x1003511bf) #3 0x1003515bd in gfc_undo_symbols() (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/f951+0x1003515bd) #4 0x1002241ee in reject_statement() (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/f951+0x1002241ee) #5 0x100224373 in match_word(char const*, match (*)(), locus*) (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/f951+0x100224373) #6 0x1002322bd in decode_statement() (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/f951+0x1002322bd) #7 0x10023427b in next_free() (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/f951+0x10023427b) #8 0x100234af9 in next_statement() (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/f951+0x100234af9) #9 0x10023679d in parse_derived() (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/f951+0x10023679d) #10 0x100238b9b in parse_spec(gfc_statement) (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/f951+0x100238b9b) #11 0x10023c78b in parse_progunit(gfc_statement) (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/f951+0x10023c78b) #12 0x10023e350 in gfc_parse_file() (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/f951+0x10023e350) #13 0x10038020a in gfc_be_parse_file() (/opt/gcc/gcc7g/libexe
[Bug sanitizer/78267] [7 Regression] libsanitizer breaks bootstrap on x86_64-apple-darwin16 at r241977
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78267 --- Comment #4 from Maxim Ostapenko --- (In reply to Iain Sandoe from comment #3) > (In reply to Maxim Ostapenko from comment #1) > > Eh, mine. > > > > typedef void (^os_trace_payload_t)(xpc_object_t xdict) looks very strange, > > it seems that it's an Objective-C declaration, right? > > It's declaring os_trace_payload_t to of type "Apple block" (like a lambda > that can be used over the whole of c-family); Apple blocks are currently > not supported by GCC. There is no realistic work-around, any interface > using blocks will fail, and thus either those interfaces need to be excluded > from tests, or the tests skipped/xfailed. > > > > > Could you check: > > > > 1) Libc version on your system. > > 2) Contents of /usr/include/os/trace.h. Is that a valid C header? Thank you for clarification. We'll probably need GCC local patch here (say, define SANITIZER_OS_TRACE to 0).
[Bug fortran/77680] [5/6/7 Regression] [F03] ICE in ctor_for_folding, at varpool.c:419
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77680
Jakub Jelinek changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org,
||jakub at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek ---
Indeed. Not sure what bind(c) should mean on automatic variables. Shall it
force them to be non-automatic (SAVEd), or not?
If not, I bet we want something like the following. Plus the question is
if DECL_COMMON should be added for initialized variables, in C it is just
uninitialized non-automatic variables that are common. Plus, shouldn't it
also depend on -fcommon switch?
--- gcc/fortran/trans-decl.c.jj 2016-10-31 13:28:11.0 +0100
+++ gcc/fortran/trans-decl.c2016-11-09 17:50:33.695988616 +0100
@@ -588,26 +588,6 @@ gfc_finish_var_decl (tree decl, gfc_symb
if (sym->attr.cray_pointee)
return;
- if(sym->attr.is_bind_c == 1 && sym->binding_label)
-{
- /* We need to put variables that are bind(c) into the common
-segment of the object file, because this is what C would do.
-gfortran would typically put them in either the BSS or
-initialized data segments, and only mark them as common if
-they were part of common blocks. However, if they are not put
-into common space, then C cannot initialize global Fortran
-variables that it interoperates with and the draft says that
-either Fortran or C should be able to initialize it (but not
-both, of course.) (J3/04-007, section 15.3). */
- TREE_PUBLIC(decl) = 1;
- DECL_COMMON(decl) = 1;
- if (sym->attr.access == ACCESS_PRIVATE && !sym->attr.public_used)
- {
- DECL_VISIBILITY (decl) = VISIBILITY_HIDDEN;
- DECL_VISIBILITY_SPECIFIED (decl) = true;
- }
-}
-
/* If a variable is USE associated, it's always external. */
if (sym->attr.use_assoc || sym->attr.used_in_submodule)
{
@@ -635,10 +615,10 @@ gfc_finish_var_decl (tree decl, gfc_symb
initialized variables are SAVE_IMPLICIT and explicitly saved are
SAVE_EXPLICIT. */
if (!sym->attr.use_assoc
- && (sym->attr.save != SAVE_NONE || sym->attr.data
- || (sym->value && sym->ns->proc_name->attr.is_main_program)
- || (flag_coarray == GFC_FCOARRAY_LIB
- && sym->attr.codimension && !sym->attr.allocatable)))
+ && (sym->attr.save != SAVE_NONE || sym->attr.data
+ || (sym->value && sym->ns->proc_name->attr.is_main_program)
+ || (flag_coarray == GFC_FCOARRAY_LIB
+ && sym->attr.codimension && !sym->attr.allocatable)))
TREE_STATIC (decl) = 1;
/* If derived-type variables with DTIO procedures are not made static
@@ -708,6 +688,27 @@ gfc_finish_var_decl (tree decl, gfc_symb
}
}
+ if ((sym->attr.is_bind_c == 1 && sym->binding_label)
+ && (TREE_STATIC (decl) || DECL_EXTERNAL (decl)))
+{
+ /* We need to put variables that are bind(c) into the common
+segment of the object file, because this is what C would do.
+gfortran would typically put them in either the BSS or
+initialized data segments, and only mark them as common if
+they were part of common blocks. However, if they are not put
+into common space, then C cannot initialize global Fortran
+variables that it interoperates with and the draft says that
+either Fortran or C should be able to initialize it (but not
+both, of course.) (J3/04-007, section 15.3). */
+ TREE_PUBLIC (decl) = 1;
+ DECL_COMMON (decl) = 1;
+ if (sym->attr.access == ACCESS_PRIVATE && !sym->attr.public_used)
+ {
+ DECL_VISIBILITY (decl) = VISIBILITY_HIDDEN;
+ DECL_VISIBILITY_SPECIFIED (decl) = true;
+ }
+}
+
/* Handle threadprivate variables. */
if (sym->attr.threadprivate
&& (TREE_STATIC (decl) || DECL_EXTERNAL (decl)))
[Bug sanitizer/78267] [7 Regression] libsanitizer breaks bootstrap on x86_64-apple-darwin16 at r241977
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78267 --- Comment #5 from Jakub Jelinek --- extern char **environ; #endif -#if defined(__has_include) && __has_include() +#if defined(__has_include) && __has_include() && defined(__clang__) #define SANITIZER_OS_TRACE 1 #include #else is preapproved if it works.
[Bug sanitizer/78267] [7 Regression] libsanitizer breaks bootstrap on x86_64-apple-darwin16 at r241977
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78267 --- Comment #6 from Maxim Ostapenko --- Created attachment 40007 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40007&action=edit Untested fix. Attaching untested fix. Dominique, could you try it?
[Bug libstdc++/78273] The transparent version of {map,set}::count should call _M_count_tr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78273 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-11-09 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- Oh, good point.
[Bug sanitizer/78267] [7 Regression] libsanitizer breaks bootstrap on x86_64-apple-darwin16 at r241977
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78267 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-11-09 Ever confirmed|0 |1 --- Comment #7 from Dominique d'Humieres --- > Attaching untested fix. > Dominique, could you try it? Allow for ~2 hours.
[Bug fortran/60500] [5/6/7 Regression] Spurious warning on derived type initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60500 --- Comment #12 from vehre at gcc dot gnu.org --- Well, the change introduced by r241885 is quite complicated. It may cause major regressions. I don't recommend backporting it.
[Bug c++/78274] Rejected specialization in different namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78274 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-11-09 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- It's invalid in C++98 but valid in C++11, so we should accept it. The change was done by http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3064.pdf to fix http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#374
