[Bug libstdc++/80662] libstdc++ basic_string casting oddity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80662 David Edelsohn changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-05-08 CC||jwakely.gcc at gmail dot com Ever confirmed|0 |1 --- Comment #1 from David Edelsohn --- Confirmed.
[Bug libstdc++/80662] New: libstdc++ basic_string casting oddity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80662
Bug ID: 80662
Summary: libstdc++ basic_string casting oddity
Product: gcc
Version: 7.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: dje at gcc dot gnu.org
Target Milestone: ---
Target: x86-64
// https://twitter.com/zxovq/status/861377261827629057
#include
#include
class my_stream : public std::stringstream {
public:
operator std::string() const
{
return std::stringstream::str();
}
template
my_stream& operator<<(T&& value)
{
std::stringstream::operator<<(std::forward(value));
return *this;
}
};
int main(void)
{
// for an unknown reason gcc 7.1 implicitly casts (my_stream{} << "")
// to std::basic_ostream& instead of using my_stream&
// gcc 6.3 is fine; uncomment static_cast below to make gcc 7.1 work
std::string s{/*static_cast*/(my_stream{} << "hello world")};
}
: In function 'int main()':
:24:76: error: no matching function for call to
'std::__cxx11::basic_string::basic_string()'
std::string s{/*static_cast*/(my_stream{} << "hello world")};
^
In file included from
/opt/compiler-explorer/gcc-7.1.0/include/c++/7.1.0/string:52:0,
from
/opt/compiler-explorer/gcc-7.1.0/include/c++/7.1.0/bits/locale_classes.h:40,
from
/opt/compiler-explorer/gcc-7.1.0/include/c++/7.1.0/bits/ios_base.h:41,
from
/opt/compiler-explorer/gcc-7.1.0/include/c++/7.1.0/ios:42,
from
/opt/compiler-explorer/gcc-7.1.0/include/c++/7.1.0/istream:38,
from
/opt/compiler-explorer/gcc-7.1.0/include/c++/7.1.0/sstream:38,
from :1:
/opt/compiler-explorer/gcc-7.1.0/include/c++/7.1.0/bits/basic_string.h:588:9:
note: candidate: template
std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::basic_string(_InputIterator, _InputIterator, const _Alloc&)
basic_string(_InputIterator __beg, _InputIterator __end,
^~~~
/opt/compiler-explorer/gcc-7.1.0/include/c++/7.1.0/bits/basic_string.h:588:9:
note: template argument deduction/substitution failed:
:24:76: note: candidate expects 3 arguments, 1 provided
std::string s{/*static_cast*/(my_stream{} << "hello world")};
^
In file included from
/opt/compiler-explorer/gcc-7.1.0/include/c++/7.1.0/string:52:0,
from
/opt/compiler-explorer/gcc-7.1.0/include/c++/7.1.0/bits/locale_classes.h:40,
from
/opt/compiler-explorer/gcc-7.1.0/include/c++/7.1.0/bits/ios_base.h:41,
from
/opt/compiler-explorer/gcc-7.1.0/include/c++/7.1.0/ios:42,
from
/opt/compiler-explorer/gcc-7.1.0/include/c++/7.1.0/istream:38,
from
/opt/compiler-explorer/gcc-7.1.0/include/c++/7.1.0/sstream:38,
from :1:
/opt/compiler-explorer/gcc-7.1.0/include/c++/7.1.0/bits/basic_string.h:550:7:
note: candidate: std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::basic_string(std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&&,
const _Alloc&) [with _CharT = char; _Traits = std::char_traits; _Alloc =
std::allocator]
basic_string(basic_string&& __str, const _Alloc& __a)
^~~~
/opt/compiler-explorer/gcc-7.1.0/include/c++/7.1.0/bits/basic_string.h:550:7:
note: candidate expects 2 arguments, 1 provided
/opt/compiler-explorer/gcc-7.1.0/include/c++/7.1.0/bits/basic_string.h:546:7:
note: candidate: std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::basic_string(const std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>&, const _Alloc&) [with _CharT = char; _Traits = std::char_traits;
_Alloc = std::allocator]
basic_string(const basic_string& __str, const _Alloc& __a)
^~~~
/opt/compiler-explorer/gcc-7.1.0/include/c++/7.1.0/bits/basic_string.h:546:7:
note: candidate expects 2 arguments, 1 provided
/opt/compiler-explorer/gcc-7.1.0/include/c++/7.1.0/bits/basic_string.h:542:7:
note: candidate: std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::basic_string(std::initializer_list<_Tp>, const _Alloc&) [with _CharT =
char; _Traits = std::char_traits; _Alloc = std::allocator]
basic_string(initializer_list<_CharT> __l, const _Alloc& __a = _Alloc())
^~~~
/opt/compiler-explorer/gcc-7.1.0/include/c++/7.1.0/bits/basic_string.h:542:7:
note: no known conversion for argument 1 from 'std::basic_ostream' to
'std::initializer_list'
/opt/compiler-explorer/gcc-7.1.0/include/c++/7.1.0/bits/basic_string.h:515:7:
note: candidate: std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::basic_string(std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&&)
[with _CharT = char; _Traits = std::char_traits; _Alloc =
std::allocator]
[Bug tree-optimization/80655] -Werror=format-truncation inconsistency between x86_32 and x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80655 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|2017-05-06 00:00:00 |2017-05-07 CC||msebor at gcc dot gnu.org Component|c++ |tree-optimization Ever confirmed|0 |1 --- Comment #6 from Martin Sebor --- Confirmed. The warning can be suppressed by changing the invocation of the vector ctor to be passed an unsigned type, e.g., like so: std::vector longer_message(size + 1U); The gimple-ssa-sprintf pass sees this. It's almost as though size_14 was being considered to be unsigned. [100.00%]: ... size_14 = snprintf (&message, 256, format_12(D), _2); ... [50.00%]: if (size_14 >= 0) <<< given size_14 is int, goto ; [46.68%] else goto ; [53.32%] [23.34%]: _4 = size_14 + 1; <<< and given this, ... if (_4 != 0) <<< how could this not hold... goto ; [33.00%] else goto ; [67.00%] <<< ...and this branch be taken? ... [7.70%]: _61 = operator new (_5); __builtin_memset (_61, 0, _5); ... snprintf (_61, _5, format_12(D), _7); ... [15.64%]: __builtin_memset (0B, 0, _5); ... snprintf (0B, _5, format_12(D), _85);
[Bug c++/80648] [DR903] Valid C++11 null pointer constant (1-1) is rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80648 --- Comment #8 from Keith Thompson --- That's a surprising interpretation of the word "amendment". Searching isocpp.org and other sites, I haven't found any official reference to an "amendment" to the C++ standard. The nearest thing I've found, which is referenced in the gcc documentation, is the 1995 amendment to the 1990 ISO C standard, "ANSI/ISO/IEC 9899-1990/AM 1-1995". That's definitely not a DR. (The C and C++ standard committees use similar procedures.) Does g++ implement *all* DRs reported against C++11?
[Bug c++/80648] [DR903] Valid C++11 null pointer constant (1-1) is rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80648 --- Comment #7 from Andrew Pinski --- (In reply to Keith Thompson from comment #6) > Shall I submit a separate ticket against the documentation? > > "info gcc" for gcc-7.1.0 has the following description for -std=c=+98 and > std=++03: > > 'c++98' > 'c++03' > The 1998 ISO C++ standard plus the 2003 technical corrigendum > and some additional defect reports. Same as '-ansi' for C++ > code. > > and this for -std=c++11 and -std=c++0x: > > 'c++11' > 'c++0x' > The 2011 ISO C++ standard plus amendments. The name 'c++0x' > is deprecated. > > Both should mention DRs. amendments is listed there which includes DR as far as I can tell.
[Bug c++/80648] [DR903] Valid C++11 null pointer constant (1-1) is rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80648 --- Comment #6 from Keith Thompson --- Shall I submit a separate ticket against the documentation? "info gcc" for gcc-7.1.0 has the following description for -std=c=+98 and std=++03: 'c++98' 'c++03' The 1998 ISO C++ standard plus the 2003 technical corrigendum and some additional defect reports. Same as '-ansi' for C++ code. and this for -std=c++11 and -std=c++0x: 'c++11' 'c++0x' The 2011 ISO C++ standard plus amendments. The name 'c++0x' is deprecated. Both should mention DRs. (I question the policy of implementing DRs that have not been approved by the committee. As I understand it, the existence of a DR merely means that *someone* thinks there's a defect in the standard. Many DRs are eventually rejected.)
[Bug c++/80648] [DR903] Valid C++11 null pointer constant (1-1) is rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80648 --- Comment #5 from Jonathan Wakely --- Whether or not it's part of the standard has no bearing on whether it's a bug in GCC, because we don't claim to implement just the original published standard. GCC's policy is to implement the standard plus DRs. It's a DR, so the fact we implement it is not a GCC bug, it's policy.
[Bug translation/80280] Missing closing quote (%>) c/semantics.c and c/c-typeck.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80280 --- Comment #4 from Volker Reichelt --- Author: reichelt Date: Sun May 7 19:41:09 2017 New Revision: 247728 URL: https://gcc.gnu.org/viewcvs?rev=247728&root=gcc&view=rev Log: PR translation/80280 * call.c (print_z_candidate): Fix quoting. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c
[Bug fortran/79311] [OOP] ICE in generate_finalization_wrapper, at fortran/class.c:1992
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79311 --- Comment #7 from janus at gcc dot gnu.org --- (In reply to janus from comment #6) > The regtest went pretty well, although I'm seeing these three failures: > > FAIL: gfortran.dg/coarray_lock_7.f90 -O scan-tree-dump-times original > FAIL: gfortran.dg/coarray_lock_7.f90 -O scan-tree-dump-times original > FAIL: gfortran.dg/mvbits_7.f90 -O0 (test for warnings, line 28) > > But I think they are unrelated and also occur without my patch. Will check. Indeed I see those also on a clean trunk.
[Bug c++/79664] ICE with #pragma omp parallel in constexpr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79664 Volker Reichelt changed: What|Removed |Added Known to work||6.3.1, 7.1.0 Target Milestone|--- |6.4 Known to fail||5.1.0, 6.1.0, 6.3.0
[Bug c++/79681] [6 Regression] ICE with constexpr and bitfield
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79681 Volker Reichelt changed: What|Removed |Added Status|NEW |RESOLVED Known to work||6.3.1 Resolution|--- |FIXED Known to fail||5.1.0, 6.1.0, 6.3.0 --- Comment #10 from Volker Reichelt --- Fixed by Jakub's patch.
[Bug fortran/79311] [OOP] ICE in generate_finalization_wrapper, at fortran/class.c:1992
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79311 --- Comment #6 from janus at gcc dot gnu.org --- (In reply to janus from comment #5) > This draft patch fixes the ICE on comment 0 and comment 4: > > [..] > > Regtesting now ... The regtest went pretty well, although I'm seeing these three failures: FAIL: gfortran.dg/coarray_lock_7.f90 -O scan-tree-dump-times original FAIL: gfortran.dg/coarray_lock_7.f90 -O scan-tree-dump-times original FAIL: gfortran.dg/mvbits_7.f90 -O0 (test for warnings, line 28) But I think they are unrelated and also occur without my patch. Will check.
[Bug c++/79639] [6 Regression] ICE with -O and constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79639 Volker Reichelt changed: What|Removed |Added Status|NEW |RESOLVED Known to work||6.3.1 Resolution|--- |FIXED --- Comment #7 from Volker Reichelt --- Fixed by Jakub's patch.
[Bug fortran/79311] [OOP] ICE in generate_finalization_wrapper, at fortran/class.c:1992
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79311 janus at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |8.0
[Bug fortran/79311] [OOP] ICE in generate_finalization_wrapper, at fortran/class.c:1992
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79311
janus at gcc dot gnu.org changed:
What|Removed |Added
Keywords||ice-on-valid-code
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |janus at gcc dot gnu.org
Summary|[F03] ICE in|[OOP] ICE in
|generate_finalization_wrapp |generate_finalization_wrapp
|er, at fortran/class.c:1992 |er, at fortran/class.c:1992
--- Comment #5 from janus at gcc dot gnu.org ---
This draft patch fixes the ICE on comment 0 and comment 4:
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (revision 247264)
+++ gcc/fortran/resolve.c (working copy)
@@ -12385,26 +12385,23 @@ gfc_resolve_finalizers (gfc_symbol* derived, bool
if (parent)
gfc_resolve_finalizers (parent, finalizable);
- /* Return early when not finalizable. Additionally, ensure that derived-type
- components have a their finalizables resolved. */
- if (!derived->f2k_derived || !derived->f2k_derived->finalizers)
+ /* Ensure that derived-type components have a their finalizers resolved. */
+ bool has_final = derived->f2k_derived && derived->f2k_derived->finalizers;
+ for (c = derived->components; c; c = c->next)
+if (c->ts.type == BT_DERIVED
+ && !c->attr.pointer && !c->attr.proc_pointer && !c->attr.allocatable)
+ {
+ bool has_final2 = false;
+ if (!gfc_resolve_finalizers (c->ts.u.derived, &has_final2))
+ return false; /* Error. */
+ has_final = has_final || has_final2;
+ }
+ /* Return early if not finalizable. */
+ if (!has_final)
{
- bool has_final = false;
- for (c = derived->components; c; c = c->next)
- if (c->ts.type == BT_DERIVED
- && !c->attr.pointer && !c->attr.proc_pointer &&
!c->attr.allocatable)
- {
- bool has_final2 = false;
- if (!gfc_resolve_finalizers (c->ts.u.derived, &has_final))
- return false; /* Error. */
- has_final = has_final || has_final2;
- }
- if (!has_final)
- {
- if (finalizable)
- *finalizable = false;
- return true;
- }
+ if (finalizable)
+ *finalizable = false;
+ return true;
}
/* Walk over the list of finalizer-procedures, check them, and if any one
Regtesting now ...
[Bug c++/66153] Internal compiler error in nested template function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66153 --- Comment #7 from Peter Boyle --- Signature of fail in 8.0.0 (head) is: ^~~~ prog.cc: In substitution of 'template Container(arg.data[0]))> function(const Container&) [with int N = 1; obj = ]': prog.cc:43:101: recursively required by substitution of 'template Container(arg.data[0]))> function(const Container&) [with int N = 1; obj = ]' prog.cc:43:101: required by substitution of 'template Container(arg.data[0]))> function(const Container&) [with int N = 1; obj = ]' prog.cc:45:33: required from 'Container(arg.data[0]))> function(const Container&) [with int N = 1; obj = Recursive > >]' prog.cc:58:26: required from here prog.cc:43:101: fatal error: template instantiation depth exceeds maximum of 900 (use -ftemplate-depth= to increase the maximum) template auto function(const Container & arg)-> Container(arg.data[0]))> ~~~^ compilation terminated.
[Bug c++/66153] Internal compiler error in nested template function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66153 --- Comment #6 from Peter Boyle --- Just an update: Still fails in G++ 7.1.0 and in 8.0.0 (head) on Wandbox. Still passes in Clang 4.0.0 and 5.0.0(head).
[Bug fortran/80657] Loop in character function declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80657 --- Comment #2 from Vittorio Zecca --- You do not get line numbers but offset in f951. Need rebuild with -g option or addr2line usage?
[Bug fortran/80645] [8 regression] FAIL: gfortran.dg/elemental_subroutine_3.f90 -O1 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80645 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2017-05-07 CC||rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- I don't see this one on darwin, but (not darwin specific, between r247578 and r247584, likely r247578 and/or r247581) gfc /opt/gcc/_clean/gcc/testsuite/gfortran.dg/alloc_comp_auto_array_2.f90 -O3 -m32 /opt/gcc/_clean/gcc/testsuite/gfortran.dg/alloc_comp_auto_array_2.f90:33:0: iregion = grid_index_region (iarg) ! Warning: '__builtin_memcpy' specified size between 2147483648 and 4294967295 exceeds maximum object size 2147483647 [-Wstringop-overflow=]
[Bug tree-optimization/78496] [7/8 Regression] Missed opportunities for jump threading
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78496 --- Comment #11 from Jeffrey A. Law --- Author: law Date: Sun May 7 15:10:55 2017 New Revision: 247727 URL: https://gcc.gnu.org/viewcvs?rev=247727&root=gcc&view=rev Log: 2017-05-07 Jeff Law Revert: 2017-05-06 Jeff Law PR tree-optimization/78496 * tree-vrp.c (simplify_assert_expr_using_ranges): Remove debugging code. PR tree-optimization/78496 * tree-vrp.c (simplify_assert_expr_using_ranges): New function. (simplify_stmt_using_ranges): Call it. (vrp_dom_walker::before_dom_children): Extract equivalences from an ASSERT_EXPR with an equality comparison against a constant. Revert: 2017-05-06 Jeff Law PR tree-optimization/78496 * gcc.dg/tree-ssa/ssa-thread-16.c: New test. * gcc.dg/tree-ssa/ssa-thread-17.c: New test. Removed: trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-thread-16.c trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-thread-17.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vrp.c
[Bug fortran/80657] Loop in character function declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80657 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-05-07 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- With an instrumented gfortran I get ==71082==ERROR: AddressSanitizer: stack-overflow on address 0x7fff5bc00e30 (pc 0x0001000df430 bp 0x7fff5bc01030 sp 0x7fff5bc00e00 T0) #0 0x1000df42f in gfc_traverse_expr(gfc_expr*, gfc_symbol*, bool (*)(gfc_expr*, gfc_symbol*, int*), int) (/opt/gcc/gcc7gp/libexec/gcc/x86_64-apple-darwin16.4.0/7.0.1/f951+0x1000df42f) #1 0x1000df7b3 in gfc_traverse_expr(gfc_expr*, gfc_symbol*, bool (*)(gfc_expr*, gfc_symbol*, int*), int) (/opt/gcc/gcc7gp/libexec/gcc/x86_64-apple-darwin16.4.0/7.0.1/f951+0x1000df7b3) #2 0x1000df98b in gfc_traverse_expr(gfc_expr*, gfc_symbol*, bool (*)(gfc_expr*, gfc_symbol*, int*), int) (/opt/gcc/gcc7gp/libexec/gcc/x86_64-apple-darwin16.4.0/7.0.1/f951+0x1000df98b) #3 0x1000df7b3 in gfc_traverse_expr(gfc_expr*, gfc_symbol*, bool (*)(gfc_expr*, gfc_symbol*, int*), int) (/opt/gcc/gcc7gp/libexec/gcc/x86_64-apple-darwin16.4.0/7.0.1/f951+0x1000df7b3) ... with a repeated pattern #4 0x1000df98b in gfc_traverse_expr(gfc_expr*, gfc_symbol*, bool (*)(gfc_expr*, gfc_symbol*, int*), int) (/opt/gcc/gcc7gp/libexec/gcc/x86_64-apple-darwin16.4.0/7.0.1/f951+0x1000df98b) #5 0x1000df7b3 in gfc_traverse_expr(gfc_expr*, gfc_symbol*, bool (*)(gfc_expr*, gfc_symbol*, int*), int) (/opt/gcc/gcc7gp/libexec/gcc/x86_64-apple-darwin16.4.0/7.0.1/f951+0x1000df7b3)
[Bug fortran/79072] ICE with class(*) pointer function result and character value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79072 --- Comment #7 from Dominique d'Humieres --- > Comment 5 code example gives incorrect results with the 7.1.0 release, > but correct results with 6.3 and 5.2 -- a regression. Likely caused by revision r241439. AFAICT this could be two different PRs.
[Bug testsuite/80661] New: make check-gcc RUNTESTFLAGS="dg.exp=g*" runs all the tests in gcc.dg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80661 Bug ID: 80661 Summary: make check-gcc RUNTESTFLAGS="dg.exp=g*" runs all the tests in gcc.dg Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: dominiq at lps dot ens.fr Target Milestone: --- It is my understanding that the command make check-gcc RUNTESTFLAGS="dg.exp=a*" runs all the tests in gcc.dg starting with an 'a' (same thing for g++ and gfortran). AFAICT (on darwin) this is true except when 'a' is replaced with 'g', 'o', or 't' (all the letters tested with gfortran). Is anybody understanding what is special with these three letters?
[Bug c++/80660] New: Member function pointer optimization affected by incompatible virtual function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80660
Bug ID: 80660
Summary: Member function pointer optimization affected by
incompatible virtual function
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: drepper.fsp+rhbz at gmail dot com
Target Milestone: ---
Consider the following code:
struct foo final {
int a = 0;
int b = 0;
void set_a(int p) { a = p; }
void set_b(int p) { b = p; }
#ifdef VIRT
virtual int get_a() const { return a; }
#endif
};
void (foo::*set)(int);
foo fobj1;
void bar1(int a) {
(fobj1.*set)(a);
}
When compiling with optimization and VIRT not defined the code generated for
bar1 does correctly so elide the test for a virtual function and saves code and
time at execution time.
Adding any virtual function (such as by defining VIRT) changes this. All of
the sudden the entire member function pointer call sequence is emitted.
This is unnecessary, though, since the present virtual function is incompatible
with the member function pointer 'set'. Therefore the generated code should be
the same, with or without get_a defined.
[Bug c/79027] [8 Regression] fold-const.c:11104:1: internal compiler error: Floating point exception
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79027 --- Comment #8 from John David Anglin --- The error on the trunk is caused by the middle end trying to do a mode change between SImode and BLKmode. Tweaking pa_cannot_change_mode_class() to reject changes to/modes with zero size appears to fix this bug. Running a full build and check. The bug has been present for a long time but only recently exposed by a gcc-8 change and/or selecting the right configure options.
[Bug fortran/79072] ICE with class(*) pointer function result and character value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79072 neil.n.carlson at gmail dot com changed: What|Removed |Added Known to fail||7.1.0 --- Comment #6 from neil.n.carlson at gmail dot com --- Comment 1 code example segfaults with the 7.1.0 release (and earlier). Comment 5 code example gives incorrect results with the 7.1.0 release, but correct results with 6.3 and 5.2 -- a regression.
[Bug libfortran/78379] Processor-specific versions for matmul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78379 --- Comment #30 from Thomas Koenig --- I think there still is one thing to do. Apparently, AMD CPUs (which use only vanilla at the moment) are slightly faster with -mprefer-avx128, and they should be much faster if they have FMA3. Unless I missed something, it is not possible to specify something like -mprefer-avx128 as a target attribute. What would be the best way to go about this?
[Bug fortran/68600] Inlined MATMUL is too slow.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68600 Thomas Koenig changed: What|Removed |Added Status|NEW |WAITING --- Comment #15 from Thomas Koenig --- I think that with the current status, where we have -finline-matmul-limit=30 by default, we can close this bug. Agreed?
[Bug libstdc++/80658] Memory leak reported in libstdc++ (zerotier)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80658 --- Comment #1 from Marc Glisse --- I am not sure what you expect from this PR exactly. If you have issues about glibc's implementation of malloc, please see about it with glibc (here is for gcc only). They already know about the performance issue, have at least one guy (DJ Delorie) working on it, and he is looking for workloads to help him tune the implementation, search the libc-alpha archives for how to help him. Personal experience: last time I tried jemalloc, it was slower than glibc for my application... If there is still some issue with debugging and multi-threading, try asking them if they have a better idea now of how to implement it. The zerotier rant mixes malloc, new and C++ allocators, it mixes what comes from standard C++ and what is an extension in libstdc++, talks about an environment variable that was renamed in 2003. In the end, it is so far from a useful bug report that I can only ignore it (maybe someone with a lot more time...). Libstdc++ does not create its own allocator by default, it uses new (which maps to malloc) by default. To use something like __mt_alloc, you have to include a header and use something from namespace __gnu_cxx, that's pretty clearly an explicit use of an extension by the user, not the default.
