[Bug c++/54430] [C++11] For-Loop: Scope of iterating variable begins too early
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54430 Akim Demaille changed: What|Removed |Added CC||akim.demaille at gmail dot com --- Comment #4 from Akim Demaille --- I hit that one too with 5.2.
[Bug c++/54430] [C++11] For-Loop: Scope of iterating variable begins too early
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54430 --- Comment #5 from Akim Demaille --- FWIW, it's on StackOverflow since May 2013. http://stackoverflow.com/questions/16407212/identifier-with-the-same-name-in-both-expression-and-declaration-of-range-based
[Bug bootstrap/67158] ICE dwarf2out.c:19910/gen_inlined_subroutine_die, at : Compiling gcc6.0 with gcc6.0 -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67158 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #1 from Richard Biener --- Possibly also happens with bootstrap-lto and BOOT_CFLAGS=-g, that is, during stage2/3 when not optimizing (?)
[Bug libfortran/66936] io/unix.c gratuitously uses S_IRWXG and S_IRWXO on the basis that umask() is available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66936 Francois-Xavier Coudert changed: What|Removed |Added CC||ktietz at gcc dot gnu.org --- Comment #14 from Francois-Xavier Coudert --- Kai, as mingw maintainer, can you comment? Why did this issue appear recently? And does the patch seem OK to you?
[Bug c++/67164] New: [6 Regression] ICE: tree check: expected class ‘expression’, have ‘exceptional’ (argument_pack_select) in tree_operand_check, at tree.h:3356
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67164
Bug ID: 67164
Summary: [6 Regression] ICE: tree check: expected class
‘expression’, have ‘exceptional’
(argument_pack_select) in tree_operand_check, at
tree.h:3356
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: trippels at gcc dot gnu.org
Target Milestone: ---
% cat github_113.ii
namespace std {
template struct integral_constant {
static constexpr _Tp value = 0;
};
template struct conditional;
template struct __or_;
template
struct __or_<_B1, _B2> : conditional<1, _B1, _B2> {};
template struct __and_;
template
struct __and_<_B1, _B2> : conditional<1, _B2, _B1> {};
template struct is_rvalue_reference;
template
struct is_reference
: __or_, is_rvalue_reference<_Tp>>::type {};
template _Tp declval();
struct __do_is_direct_constructible_impl {
template ()))>
static integral_constant __test(int);
};
template
struct __is_direct_constructible_impl : __do_is_direct_constructible_impl {
decltype(__test<_Tp, _Arg>(0)) type;
};
template
struct __is_direct_constructible_new_safe
: __and_> {};
template
struct __is_direct_constructible_new
: conditional::value, int,
__is_direct_constructible_new_safe<_Tp, _Arg>> {};
template
struct __is_direct_constructible
: __is_direct_constructible_new<_Tp, _Arg>::type {};
template struct __is_nary_constructible;
template
struct __is_nary_constructible<_Tp, _Arg>
: __is_direct_constructible<_Tp, _Arg> {};
template
struct is_constructible : __is_nary_constructible<_Tp, _Args...>::type {};
template struct enable_if;
template struct conditional {
typedef _Iftrue type;
};
template
struct conditional {
typedef _Iffalse type;
};
}
namespace boost {
namespace hana {
template struct fast_and;
template struct closure {
template ::value...>::value>>
closure(Yn...);
template ::value...>::value>::type>
closure(closure);
};
template struct make_impl;
template struct make_t {
template decltype(auto) operator()(X... x) {
return make_impl::apply(x...);
}
};
template make_t make;
struct Pair;
auto make_pair = make;
struct Tuple;
auto make_tuple = make;
template <> struct make_impl {
template static closure apply(Xs &&...);
};
struct pair : closure<> {
using closure::closure;
};
template <> struct make_impl {
template static pair apply(F, S);
};
namespace struct_detail {
template struct member_ptr {};
template auto prepare_member_name_impl() {}
template auto prepare_member_name() {
return prepare_member_name_impl;
}
}
}
}
struct Person {
int Person;
auto apply() {
struct member_names;
boost::hana::make_tuple(boost::hana::make_pair(
boost::hana::struct_detail::prepare_member_name<0, member_names>(),
boost::hana::struct_detail::member_ptr{}));
}
};
% clang++ -std=c++14 -c github_113.ii
%
(gcc-5 rejects the testcase)
% g++ -std=c++14 -c github_113.ii
github_113.ii: In instantiation of ‘struct
std::__is_direct_constructible_impl&&>’:
github_113.ii:41:8: required from ‘struct
std::is_constructible&&>’
github_113.ii:56:13: required by substitution of ‘template boost::hana::closure::closure(Yn ...) [with Yn =
boost::hana::closure; = ]’
github_113.ii:67:43: required from ‘decltype(auto)
boost::hana::make_t::operator()(X ...) [with X = {boost::hana::pair};
Datatype = boost::hana::Tuple]’
github_113.ii:100:67: required from here
github_113.ii:24:29: error: no matching function for call to
‘std::__is_direct_constructible_impl&&>::__test(int)
’
decltype(__test<_Tp, _Arg>(0)) type;
^
github_113.ii:20:34: note: candidate: template
static std::integral_constant
std::__do_is_direct_constructible_impl::__test(int)
static integral_constant __test(int);
^
github_113.ii:20:34: note: template argument deduction/substitution failed:
github_113.ii:19:13: error: invalid cast of an rvalue expression of type
‘boost::hana::closure’ to type ‘boost::hana::pair&’
typename = decltype(_Tp(declval<_Arg>()))>
^
(trunk ICEs since r214396)
% g++ -c github_113.ii
github_113.ii: In substitution of ‘template::value
...>::value>::type >
boost::hana::pair::pair(boost::hana::closure) [with Yn = ;
typename std::enable_if::value
...>::value>::type = ]’:
github_113.ii:19:13: required by substitution of ‘template static std::integral_constant
std::__do_is_direct_constructible_impl::__test(int) [with _Tp =
boost::hana::pair&; _Arg = boost::hana::closure&&;
= ]’
github_113.ii:24:29: required from ‘struct
std::__is_direct_constructible_impl&&>’
github_113.ii:41:8: required from ‘struct
std::is_constructible&&>’
github_113.ii:56:13: required by substitution of ‘template boost::hana::closur
[Bug c++/67164] ICE: tree check: expected class ‘expression’, have ‘exceptional’ (argument_pack_select) in tree_operand_check, at tree.h:3356
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67164 Markus Trippelsdorf changed: What|Removed |Added Summary|[6 Regression] ICE: tree|ICE: tree check: expected |check: expected class |class ‘expression’, have |‘expression’, have |‘exceptional’ |‘exceptional’ |(argument_pack_select) in |(argument_pack_select) in |tree_operand_check, at |tree_operand_check, at |tree.h:3356 |tree.h:3356 | Known to fail||5.1.0, 6.0 --- Comment #1 from Markus Trippelsdorf --- With --enable-checking gcc-5 also ICEs. gcc-4.9 rejects the testcase: github_113.ii:70:47: error: template declaration of ‘boost::hana::make_t boost::hana::make’ template make_t make; ^ github_113.ii:72:18: error: ‘make’ was not declared in this scope auto make_pair = make; ^ github_113.ii:72:27: error: expected primary-expression before ‘>’ token auto make_pair = make; ^ github_113.ii:72:28: error: expected primary-expression before ‘;’ token auto make_pair = make; ^ github_113.ii:74:19: error: ‘make’ was not declared in this scope auto make_tuple = make; ^ github_113.ii:74:29: error: expected primary-expression before ‘>’ token auto make_tuple = make; ^ github_113.ii:74:30: error: expected primary-expression before ‘;’ token auto make_tuple = make; ^
[Bug c++/67164] ICE: tree check: expected class ‘expression’, have ‘exceptional’ (argument_pack_select) in tree_operand_check, at tree.h:3356
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67164 Markus Trippelsdorf changed: What|Removed |Added CC||ldionne.2 at gmail dot com --- Comment #2 from Markus Trippelsdorf --- (Louis, this ICE was introduced by commit 8a0ddb0fa7b6f7a of https://github.com/ldionne/hana)
[Bug c++/67159] [c++concepts] Segfault while diagnosing constraint violation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67159 --- Comment #4 from Jason Merrill --- (In reply to Casey Carter from comment #3) > Thanks once again, Jason. Procedural question: now that c++-concepts has > landed on trunk, should I be tagging bug reports differently? i.e., > Version=6.0 and maybe "[concepts]" in the title? Sounds good.
[Bug other/67165] New: please enable libbacktrace to work with compressed debug sections
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67165 Bug ID: 67165 Summary: please enable libbacktrace to work with compressed debug sections Product: gcc Version: 5.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: doko at gcc dot gnu.org Target Milestone: --- please enable libbacktrace to work with compressed debug sections. libbacktrace doesn't work with stripped binaries. The unstripped binaries built with compressed debug sections would save some space on disk.
[Bug c++/67166] New: Inconsistency between static data members and static functions when using multiple inheritance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67166
Bug ID: 67166
Summary: Inconsistency between static data members and static
functions when using multiple inheritance
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: anders.granlund.0 at gmail dot com
Target Milestone: ---
Consider the following two programs:
struct A { static const int x = 0; };
struct B : A { using A::x; };
struct C : B, A {};
int main() { C::x; }
struct A { static void x() {} };
struct B : A { using A::x; };
struct C : B, A {};
int main() { C::x; }
Compile them with the following command line:
g++ prog.cc -std=c++14 -pedantic-errors
GCC inconsistently accepts the first program, but rejects the second program
with the following error:
prog.cc: In function 'int main()':
prog.cc:4:16: error: reference to 'x' is ambiguous
int main() { C::x; }
^
prog.cc:1:26: note: candidates are: static void A::x()
struct A { static void x() {} };
^
prog.cc:1:26: note: static void A::x()
I think GCC should consistently accept both programs just like clang does.
This is because we have no ambiguity here in the name-lookup. There is only one
entity with name x, the static member of A.
I have tried this with gcc HEAD 6.0.0 20150808 here:
http://melpon.org/wandbox/permlink/mbr1XEKQp7bF71iS
http://melpon.org/wandbox/permlink/E5iKa6GfLG2q1m0o
[Bug other/67165] please enable libbacktrace to work with compressed debug sections
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67165 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-08-09 CC||hjl.tools at gmail dot com Ever confirmed|0 |1 --- Comment #1 from H.J. Lu --- Both ld and gold on binutils master branch support --compress-debug-sections=[none|zlib|zlib-gnu|zlib-gabi] to compress debug sections. --compress-debug-sections=zlib-gnu is for legacy .zdebug* compressed debug section support. Support for the gABI SHF_COMPRESSED debug sections should be sufficient. bfd, readelf and gold can decompress the SHF_COMPRESSED debug sections.
[Bug debug/67163] g2 generates incorrect decl_line
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67163 --- Comment #4 from dehao at gcc dot gnu.org --- Right, in -g2 binary debug info, the decl_file is pointing to the header file in which the function is declared. However, if the definition is available, it makes more sense to point decl_file and decl_line where it's actually defined, right? Additionally, it's better to keep g1 and g2 debug info consistent.
[Bug libfortran/66936] io/unix.c gratuitously uses S_IRWXG and S_IRWXO on the basis that umask() is available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66936 --- Comment #15 from Steve Kargl --- On Sun, Aug 09, 2015 at 08:53:36AM +, fxcoudert at gcc dot gnu.org wrote: > Kai, as mingw maintainer, can you comment? Why did this issue appear recently? > And does the patch seem OK to you? > See comment #6.
[Bug libfortran/66936] io/unix.c gratuitously uses S_IRWXG and S_IRWXO on the basis that umask() is available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66936 --- Comment #16 from Francois-Xavier Coudert --- Author: fxcoudert Date: Sun Aug 9 16:43:42 2015 New Revision: 226750 URL: https://gcc.gnu.org/viewcvs?rev=226750&root=gcc&view=rev Log: PR libfortran/66936 * io/unix.c (__MINGW32__): Undefine HAVE_UMASK. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/unix.c
[Bug libfortran/66936] io/unix.c gratuitously uses S_IRWXG and S_IRWXO on the basis that umask() is available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66936 Francois-Xavier Coudert changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #17 from Francois-Xavier Coudert --- (In reply to Steve Kargl from comment #15) > See comment #6. Thanks Steve, I had missed that. Given the history and reasons, I've committed the patch to restore build on mingw32. Marking as fixed on trunk.
[Bug rtl-optimization/67145] [6 Regression] associativity from psuedo-reg ordering
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67145 Alan Modra changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-08-10 Summary|[6 Regression] Innefective |[6 Regression] |plus-minus simplification |associativity from ||psuedo-reg ordering Ever confirmed|0 |1 --- Comment #1 from Alan Modra --- This is what is really going on. Shown below are the first two differences at expand, shorn of irrelevant insn numbering, clobbers etc. r224767 r224768 (set (reg:SI 143) (set (reg:SI 143) (plus:SI (reg/v/f:SI 134 [ in ])(plus:SI (reg/v/f:SI 134 [ in ]) (reg/v:SI 139 [ x ]))) (reg:SI 142))) (set (reg/f:SI 144) (set (reg/f:SI 144) (plus:SI (reg:SI 143) (plus:SI (reg:SI 143) (reg:SI 142))) (reg/v:SI 139 [ x ]))) ... (set (reg:SI 151) (set (reg:SI 151) (plus:SI (reg/v/f:SI 134 [ in ])(plus:SI (reg/v/f:SI 134 [ in ]) (reg/v:SI 139 [ x ]))) (reg:SI 150))) (set (reg/f:SI 152) (set (reg/f:SI 152) (plus:SI (reg:SI 151) (plus:SI (reg:SI 151) (reg:SI 150))) (reg/v:SI 139 [ x ]))) It isn't too hard to see why fwprop sees an optimisation opportunity for one but not the other. The questions I have are: 1) Why isn't "in + x" hoisted out of the loop? 2) If we care about associativity, isn't the r224768 ordering correct in that it follows the gimple association? See gimple below. 3) If we want reverse associativity at the rtl level, isn't relying on sorting done according to pseudo reg numbering deep inside a function simplifying additive expressions, just a little bit fragile? # ivtmp.7_47 = PHI _11 = *pretmp_53; _13 = _11 + x_12(D); _14 = (sizetype) _13; _16 = in_15(D) + _14; _17 = *_16; MEM[base: out_4(D), index: ivtmp.7_47, offset: 0B] = _17; _21 = *pretmp_54; _22 = x_12(D) + _21; _28 = *pretmp_57; _29 = _22 + _28; _30 = (sizetype) _29; _31 = in_15(D) + _30; _32 = *_31; MEM[base: out_4(D), index: ivtmp.7_47, offset: 1B] = _32;
[Bug rtl-optimization/67145] [6 Regression] associativity from psuedo-reg ordering
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67145 --- Comment #2 from Alan Modra --- Note that r224768 was specifically about keeping register order (association and commutation) when simplify_plus_minus does not simplify an expression, because ordering matters for machine insn matching when an expression contains fixed regs. It would be possible to modify the r224768 change so that expressions not containing fixed regs are sorted, but I think that would be the wrong fix due to points (2) and (3) above.
[Bug tree-optimization/67153] [5/6 Regression] integer optimizations 53% slower than std::bitset<>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67153 --- Comment #3 from ncm at cantrip dot org --- Created attachment 36159 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36159&action=edit bitset, but using an inlined container adapter, not lambdas, and slow This version compiles just as badly as the integer version, even by gcc-4.9.
[Bug c/39121] strange behavior in chained operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39121 frankhb1989 at gmail dot com changed: What|Removed |Added CC||frankhb1989 at gmail dot com --- Comment #9 from frankhb1989 at gmail dot com --- This should work since C++11 because the rules of builtin assignment were modified (CWG 222; see also CWG 637). However, it is still undefined in C11, even if the new "sequenced before" wording has been copied from C++11 (WG21/N1944). Not sure if any diagnostics should be changed.
[Bug fortran/64022] [F2003][IEEE] ieee_support_flag does not handle kind=10 and kind=16 REAL variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64022 --- Comment #12 from uros at gcc dot gnu.org --- Author: uros Date: Mon Aug 10 05:13:01 2015 New Revision: 226755 URL: https://gcc.gnu.org/viewcvs?rev=226755&root=gcc&view=rev Log: PR fortran/64022 * gfortran.dg/ieee/large_4.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/ieee/large_4.f90 Modified: trunk/gcc/testsuite/ChangeLog
