[Bug tree-optimization/86141] C++ Related Optimization Problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86141 --- Comment #5 from Andrew Pinski --- Try renaming main first. Gcc knows that main is only called once ever so gcc's inling heuristics are different inside main.
[Bug tree-optimization/86141] C++ Related Optimization Problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86141 --- Comment #4 from ASA --- Comment on attachment 44270 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44270 Assembly output from g++ 7.3.0 g++ -O -S gccbug.cpp
[Bug c++/86142] New: hard error for bad delete-expression in SFINAE context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86142 Bug ID: 86142 Summary: hard error for bad delete-expression in SFINAE context Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ensadc at mailnesia dot com Target Milestone: --- https://wandbox.org/permlink/9gfZwtKZC9Tu92fs template void f(); template int f(...); int x = f(); int y = f(); int z = f(); prog.cc: In substitution of 'template void f() [with T = int; = ]': prog.cc:7:16: required from here prog.cc:1:19: error: type 'int' argument given to 'delete', expected pointer template ^ prog.cc: In substitution of 'template void f() [with T = int (*)(); = ]': prog.cc:8:21: required from here prog.cc:1:19: error: cannot delete a function. Only pointer-to-objects are valid arguments to 'delete' prog.cc: In substitution of 'template void f() [with T = void*; = ]': prog.cc:9:18: required from here prog.cc:1:19: warning: deleting 'void*' is undefined [-Wdelete-incomplete] prog.cc:9:18: error: call of overloaded 'f()' is ambiguous int z = f(); ^ prog.cc:2:6: note: candidate: 'void f() [with T = void*; = void]' void f(); ^ prog.cc:4:5: note: candidate: 'int f(...) [with T = void*]' int f(...); ^ These variable definitions should call the second overload of `f`. No warning or error should be triggered. The code is accepted by clang.
[Bug tree-optimization/86141] C++ Related Optimization Problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86141 --- Comment #3 from ASA --- Comment on attachment 44271 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44271 Assembly output from clang++ 5.0.0 clang++ -O -S gccbug.cpp
[Bug c++/86135] At run time, when the constructor tries to construct an objects element with a initializer-list (using c++11 style) is giving segmentation fault. The old style of initialize with pa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86135 --- Comment #12 from Sabetay Toros --- Created attachment 44272 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44272=edit Testi case for crashed initialiazer list
[Bug tree-optimization/86141] C++ Related Optimization Problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86141 --- Comment #2 from ASA --- Created attachment 44271 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44271=edit Assembly output from clang++ 5.0.0
[Bug tree-optimization/86141] C++ Related Optimization Problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86141 --- Comment #1 from ASA --- Created attachment 44270 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44270=edit Assembly output from GCC 7.3.0
[Bug tree-optimization/86141] New: C++ Related Optimization Problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86141 Bug ID: 86141 Summary: C++ Related Optimization Problem Product: gcc Version: 7.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: aaron_sami_abassi at hotmail dot com Target Milestone: --- Created attachment 44269 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44269=edit Source code which demonstrates the optimization problem GCC does not optimize this code correctly however LLVM, ELLCC, ZAPCC, Intel and Microsoft compilers do. I tried several optimization levels but none were able to expand the function invocation inline where as the other compiler vendors all did so with default optimization levels. This was strictly experimental code which incidentally revealed the optimization issue when I looked at the resulting Assembly on godbolt.org using the various compilers. I do not require support for the bug, thank you.
[Bug c++/86135] At run time, when the constructor tries to construct an objects element with a initializer-list (using c++11 style) is giving segmentation fault. The old style of initialize with pa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86135
--- Comment #11 from Sabetay Toros ---
Here is my test case. The issue is in line 30. Please change the line
commented with direct initilization.
It wont crash.
If you are right list initializers is not usable.
I hope you have an answer.
#include using namespace std;#include #include
#include #include #include
#include #include template void
Draw(ostream& os, const T& Entry) {
os << Entry << endl;}
struct TObject {
template
TObject(T e) : Self(make_shared>(move(e))) {}
friend void Draw(ostream& os, const TObject& Entry) {
Entry.Self->ModelDraw(os);
}
private :
struct TConcept {
virtual ~TConcept() = default;
virtual void ModelDraw(ostream& os) const = 0;
};
shared_ptr Self;
template
struct TModel final : TConcept {
TModel(T e) : Data { move(e) } { }
// It seems the issue is in this line, initiliazer list C++11
version does not work
//TModel(T e) : Data ( move(e) ) { }
// C++98 style is working.
void ModelDraw(ostream& os) const {
Draw(os, Data);
}
T Data;
};
};class TMyClass {public :
string s;
TMyClass(string e) : s(move(e)) {};
friend void Draw(ostream& os, const TMyClass& E) {
os << E.s << endl;
}};using TDocument = vector;void Draw(ostream& os, const
TDocument& vDoc) {
os << " Document Print --" << endl;
for(const auto& e: vDoc)
Draw(os,e);
os << endl;}using THistory = vector;TDocument&
GetCurrent(THistory& vHstry) {
return vHstry.back();}void SaveHistory(THistory& vHstry) {
vHstry.push_back(vHstry.back());}int main(int argc, char** argv) {
TDocument vDoc;
THistory vHstry(1);
GetCurrent(vHstry).emplace_back(1);
GetCurrent(vHstry).emplace_back(3.2);
GetCurrent(vHstry).emplace_back(" This is a try");
GetCurrent(vHstry).emplace_back(" My Class ");
GetCurrent(vHstry).emplace_back(GetCurrent(vHstry));
Draw(cout , GetCurrent(vHstry));
return 0;}
On Wed, Jun 13, 2018 at 11:04 PM, redi at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86135
>
> --- Comment #10 from Jonathan Wakely ---
> You didn't provide a proper testcase so nobody can possibly explain why
> your
> code crashes.
>
> If it's similar to the code in comment 3 then
> model_t>
> tries to construct a vector from a vector using
> list-init
> which chooses the initializer_list constructor because object_t can be
> constructed from vector. It's the same bug 85577.
>
> --
> You are receiving this mail because:
> You reported the bug.
>
[Bug middle-end/86140] New: constprop clones with identical bodies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86140
Bug ID: 86140
Summary: constprop clones with identical bodies
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: redbeard0531 at gmail dot com
Target Milestone: ---
This was tweaked example code to demonstrate something totally unrelated, but I
noticed it was doing the constprop clone thing for functions with identical
instructions, which seemed odd. While this exact case doesn't matter, it seemed
like it might be a sign of a deeper bug.
https://godbolt.org/g/Zwpi7J
[[gnu::noinline]] void f(const int*){
asm volatile("");
}
void good() {
constexpr static int arr[1000] = {};
f(arr);
}
void bad() {
constexpr int arr[1000] = {};
f(arr);
}
f(int const*) [clone .constprop.0]:
ret
f(int const*) [clone .constprop.1]:
ret
f(int const*):
ret
good():
jmp f(int const*) [clone .constprop.0]
bad():
jmp f(int const*) [clone .constprop.1]
[Bug other/77609] __attribute__((section(".note.foo"))) forces SHT_PROGBITS though the assembler would use SHT_NOTE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77609 --- Comment #5 from roland at gcc dot gnu.org --- Author: roland Date: Thu Jun 14 01:18:59 2018 New Revision: 261581 URL: https://gcc.gnu.org/viewcvs?rev=261581=gcc=rev Log: PR other/77609: Let the assembler choose ELF section types for miscellaneous named sections gcc/ PR other/77609 * varasm.c (default_section_type_flags): Set SECTION_NOTYPE for any section for which we don't know a specific type it should have, regardless of name. Previously this was done only for the exact names ".init_array", ".fini_array", and ".preinit_array". (default_elf_asm_named_section): Add comment about relationship with default_section_type_flags and SECTION_NOTYPE. (get_section): Don't consider it a type conflict if one side has SECTION_NOTYPE and the other doesn't, as long as neither has the SECTION_BSS et al used in the default_section_type_flags logic. (cherry picked from commit db7548a2771bbf34cf7430712af7ac670b429958) Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/varasm.c
[Bug target/86139] New: [7/8/9 Regression] ICE in in store_constructor, at expr.c:6849 on aarch64-linux-gnu and arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86139
Bug ID: 86139
Summary: [7/8/9 Regression] ICE in in store_constructor, at
expr.c:6849 on aarch64-linux-gnu and
arm-linux-gnueabihf
Product: gcc
Version: 8.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: doko at debian dot org
Target Milestone: ---
[forwarded from https://bugs.debian.org/901290]
seen when building a recent version of chromium-browser on aarch64-linux-gnu
and arm-linux-gnueabihf. The reduced test case was made with a gcc-8 cross
arm-linux-gnueabihf gcc.
according to the bug reporter it fails on armhf in 6, 7 and 8, on arm64 on 7
and 8.
$ cat preprocessed.i
typedef int a;
typedef int c;
typedef char d;
typedef unsigned short f;
typedef long long g;
typedef float __attribute__((vector_size(16))) aa;
typedef c bv;
typedef g __attribute__((vector_size(32))) bw;
typedef f __attribute__((vector_size(8))) bx;
bv h, i;
aa *l;
bx m, n, o;
char q;
f *s;
f u;
void *memcpy(void *v, void *w, a z) {
return __builtin___memcpy_chk(v, w, z, 0);
}
typedef struct {
} ac;
typedef struct {
} e;
typedef struct {
} agab(ac *);
typedef enum {
ao,
ad,
ab,
ar,
as,
ae,
af,
ag,
ak,
ah,
ai,
aj,
ba,
al,
am,
an,
be,
ap,
aq,
av,
aw,
at,
au,
az,
bm,
ax,
ay,
bp,
bq,
bb,
bc,
bd,
bi,
bf,
bg,
bh,
by,
bj,
bk,
bl,
ca,
bn,
bo,
bt,
bu,
br
} bs;
void bz(bx);
bx cc();
f cb();
bx cd(bv v) {
d *j = 0;
bx k = {cb(j, v)};
return k;
}
void ce() {
__attribute__((__vector_size__(4 * sizeof(short unsigned short p = n,
k = p;
m = k;
o = cd(h);
}
bs t;
void x() {
aa r, b;
while (1)
switch (t) {
case ao:
case ad:
case ab:
case ar:
case as:
case ae:
case af:
case ag:
case ak: {
bw a;
__builtin_memcpy(, s, 4);
bx y = {(a & 5)[3]};
bz(y);
}
case ah:
case ai:
case aj:
case ba:
case al:
case am:
case an:
case be:
case ap:
case aq:
case av:
case aw:
case at:
case au:
case az:
case bm:
case ax:
case ay:
case bp:
case bq:
case bb:
case bc:
case bd:
case bi:
case bf:
case bg:
break;
case bh:
case by: {
bx c = (bx){r[2]} | (bx){b[2]};
__builtin_memcpy( + i, , 2 * 4);
}
case bj:
case bk:
case bl:
case ca:
case bn:
case bo:
return;
case bt: {
bx y = cc();
bw d = u | (bw){y[2]};
__builtin_memcpy(s, , 4);
}
case bu:
case br:;
}
}
void cf() {}
$ arm-linux-gnueabihf-gcc-8 -c -std=gnu11 -O0 -Wall -Wextra preprocessed.i
during RTL pass: expand
preprocessed.i: In function 'x':
preprocessed.i:88:6: internal compiler error: in store_constructor, at
expr.c:6849
void x() {
^
Please submit a full bug report,
with preprocessed source if appropriate.
gcc configured with
-v --with-pkgversion='Debian 8.1.0-4'
--with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-8 --enable-shared
--enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/
--enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libitm
--disable-libquadmath --disable-libquadmath-support --enable-plugin
--enable-default-pie --with-system-zlib --with-target-system-zlib
--enable-multiarch --disable-sjlj-exceptions --with-arch=armv7-a
--with-fpu=vfpv3-d16 --with-float=hard --with-mode=thumb --disable-werror
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=arm-linux-gnueabihf --program-prefix=arm-linux-gnueabihf-
--includedir=/usr/arm-linux-gnueabihf/include
[Bug c++/86099] [9 Regression] internal compiler error: in cx_check_missing_mem_inits, at cp/constexpr.c:815
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86099 --- Comment #5 from Jason Merrill --- Author: jason Date: Thu Jun 14 00:02:42 2018 New Revision: 261576 URL: https://gcc.gnu.org/viewcvs?rev=261576=gcc=rev Log: PR c++/86099 - ICE with trivial copy and non-trivial default ctor. * constexpr.c (instantiate_cx_fn_r): Don't synthesize trivial constructors. Added: trunk/gcc/testsuite/g++.dg/cpp0x/nsdmi-template18.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/constexpr.c
[Bug c++/86099] [9 Regression] internal compiler error: in cx_check_missing_mem_inits, at cp/constexpr.c:815
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86099 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jason Merrill --- Fixed.
[Bug c++/86099] [9 Regression] internal compiler error: in cx_check_missing_mem_inits, at cp/constexpr.c:815
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86099 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug libstdc++/83982] [6/7/8/9 Regression] Exception guarantee of C++14 vector::resize(size_type) is not met
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83982
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |ASSIGNED
Known to work||5.5.0
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
Summary|Exception guarantee of |[6/7/8/9 Regression]
|C++14 |Exception guarantee of
|vector::resize(size_type) |C++14
|is not met |vector::resize(size_type)
||is not met
Known to fail||6.4.0, 7.3.0, 8.1.0, 9.0
--- Comment #6 from Jonathan Wakely ---
This testcase passes when compiled by GCC 5 with no option (because that means
-std=gnu++98 and so elements are copied not moved):
#include
#include
struct X
{
X() : data(1)
{
if (fail)
throw 1;
}
static bool fail;
std::vector data;
};
bool X::fail = false;
void
test01()
{
std::vector v(2);
X* const addr = [0];
bool caught = false;
try {
X::fail = true;
v.resize(v.capacity() + 1); // force reallocation
} catch (int) {
caught = true;
}
assert( caught );
assert( v.size() == 2 );
assert( [0] == addr );
// PR libstdc++/83982
assert( ! v[0].data.empty() );
assert( ! v[1].data.empty() );
}
int
main()
{
test01();
}
But it fails when compiled by GCC 6 or later (except in C++98 modes), because
the existing elements are moved from and left empty. That makes this a
regression.
[Bug fortran/86110] ICE in gfc_resolve_character_array_constructor, at fortran/array.c:2044
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86110 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |7.4 --- Comment #6 from kargl at gcc dot gnu.org --- Fixed on 7-branch, 8-branch, and trunk. Thanks for the bug report.
[Bug c/86134] earlier diagnostic causes followup diagnostic about unknown -Wno-* options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86134 --- Comment #3 from Martin Sebor --- As per the recent discussion: https://gcc.gnu.org/ml/gcc-patches/2018-06/msg00422.html
[Bug c/86134] earlier diagnostic causes followup diagnostic about unknown -Wno-* options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86134 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org --- Comment #2 from Martin Sebor --- I thought this was by design? I.e., that warnings about unknown -Wno- options were suppressed unless/until a different kind of a warning is emitted.
[Bug fortran/86110] ICE in gfc_resolve_character_array_constructor, at fortran/array.c:2044
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86110 --- Comment #5 from kargl at gcc dot gnu.org --- Author: kargl Date: Wed Jun 13 22:40:46 2018 New Revision: 261575 URL: https://gcc.gnu.org/viewcvs?rev=261575=gcc=rev Log: 2018-06-13 Steven G. Kargl PR fortran/86110 * array.c (gfc_resolve_character_array_constructor): Avoid NULL pointer dereference. 2018-06-13 Steven G. Kargl PR fortran/86110 * gfortran.dg/pr86110.f90: New test. Added: branches/gcc-7-branch/gcc/testsuite/gfortran.dg/pr86110.f90 Modified: branches/gcc-7-branch/gcc/fortran/ChangeLog branches/gcc-7-branch/gcc/fortran/array.c branches/gcc-7-branch/gcc/testsuite/ChangeLog
[Bug libstdc++/86130] Expect SIGSEGV but program just silently exits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86130 --- Comment #16 from Paul Sanders --- Interesting, I can see why you don't want to change the behaviour again. It's just a shame it ever did anything other than SEGFAULT in the first place but as you point out, it's been the way it is for a long time now and changing it would be foolhardy. Just to finish off (I see that the decision is made): > this code has been present since r53839 in 2002 ... [and] it's far too late > to just turn this into a segfault because somebody on stackoverflow found it > surprising and doesn't know how to check iostreams for errors. I'm sure myself and the OP aren't the only ones ever to have been 'surprised' by this, and more will follow. I will update my answer at SO to explain what is really happening and how to fix it (the original code wasn't my own). Thank you for taking the time to lay things out for me, I learnt a lot here, even if I still don't like the way ostream behaves under these circumstances. It seems to me that badbit's job is to reflect whether or not the stream is in a usable state, and not get set just because something strange has been passed to the stream which does it no actual harm. It (badbit) just got abused back in 2002, so to speak, and now we're stuck with it. And finally, I owe you an apology for ever thinking that ostream would silently terminate your program like that; I posted one on SO. I hope it does some good, I don't set out to aggravate you guys.
[Bug libstdc++/86138] C++17: getline(istream, string) crashes on Cygwin because incompatible C++14 function is called
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86138 --- Comment #2 from Jonathan Wakely --- Only the std::string and std::wstring instantiations are problematic for C++17. This should be a better fix, i.e. allow the getline instantiations to be used even in C++17 mode: --- a/libstdc++-v3/include/bits/basic_string.tcc +++ b/libstdc++-v3/include/bits/basic_string.tcc @@ -1597,8 +1597,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION // Inhibit implicit instantiations for required instantiations, // which are defined via explicit instantiations elsewhere. -#if _GLIBCXX_EXTERN_TEMPLATE > 0 && __cplusplus <= 201402L +#if _GLIBCXX_EXTERN_TEMPLATE > 0 +#if __cplusplus <= 201402L extern template class basic_string; +#endif extern template basic_istream& operator>>(basic_istream&, string&); @@ -1613,7 +1615,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION getline(basic_istream&, string&); #ifdef _GLIBCXX_USE_WCHAR_T +#if __cplusplus <= 201402L extern template class basic_string; +#endif extern template basic_istream& operator>>(basic_istream&, wstring&);
[Bug libstdc++/86138] C++17: getline(istream, string) crashes on Cygwin because incompatible C++14 function is called
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86138 --- Comment #1 from Jonathan Wakely --- (In reply to Christian Franke from comment #0) > As a consequence, no C++17 compatible code for this getline() is generated > and the old getline() from cygstdc++-6.dll is called instead. Why is the one in the DLL not compatible? The extern templates are disabled because std::basic_string has additional member functions in C++17 mode, and they're not instantiated in the library. By disabling the explicit instantiation declarations the compiler will emit definitions for the C++17-only member functions. But there's nothing wrong with the getline instantiation in the DLL, it's identical to what would be defined for C++17. > AFAICS the above still holds for current SVN trunk release 261563. > > For a testcase and a proposed patch see: > https://cygwin.com/ml/cygwin/2018-06/msg00125.html As requested at https://gcc.gnu.org/bugs testcases need to be provided here, not as URLs.
[Bug libstdc++/86130] Expect SIGSEGV but program just silently exits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86130 --- Comment #15 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #13) > This is not an accident, it's a supported feature (and arguably documented, > by the code and the test). See also Bug 6518 which changed the segfault to setting failbit (and introduced a regression) and Bug 6750 which introduced the current behaviour.
[Bug libstdc++/86130] Expect SIGSEGV but program just silently exits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86130 --- Comment #14 from Jonathan Wakely --- (In reply to Paul Sanders from comment #12) > Any interest? Good grief, no. That would generate even worse code than what we have now, and it's possible to test for badbit without enabling exceptions. You keep making assumptions about what everyone else's programs do, and we have no way of knowing what the majority of libstdc++ users expect from this code, or how much code relies on the current behaviour.
[Bug libstdc++/86130] Expect SIGSEGV but program just silently exits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86130
--- Comment #13 from Jonathan Wakely ---
(In reply to Martin Sebor from comment #10)
> As a data point, calling printf ("%s", p) does lead to a segfault in Glibc
> for a null p because GCC turns the call into puts(p)
Only when optimization is enabled.
I'm not suggesting we should print "(null)", that would be crazy, I'm just
demonstrating that expecting a segfault for this kind of error is not a safe or
valid assumption.
> which doesn't have the
> same feature (see https://sourceware.org/bugzilla/show_bug.cgi?id=5618 for
> the background).
>
> I think most users prefer invalid uses of pointers to fail loudly so they
> can be caught early. Few users expect output functions to fail, and even
> fewer bother to check for failures when writing to standard streams.
Agreed, but this code has been present since r53839 in 2002, and there's an
explicit test for that behaviour:
testsuite/27_io/basic_ostream/inserters_character/char/8.cc
This is not an accident, it's a supported feature (and arguably documented, by
the code and the test).
> Besides the inserter without the test resulting in more efficient code and
> GCC emitting a warning when a null pointer is passed to it (it doesn't now
> even though it should because of the strlen call), leaving it to the
> compiler to deal with can also lead to better code downstream thanks to
> -fdelete-null-pointer-checks.
I think there would need to be a period of deprecation and an optional
assertion enabled by _GLIBCXX_ASSERTIONS before we can do that (assuming we
want to).
If we were starting from scratch I wouldn't add the check (e.g. see the patch
at https://gcc.gnu.org/ml/gcc-patches/2018-06/msg00768.html that I proposed
today) but it's far too late to just turn this into a segfault because somebody
on stackoverflow found it surprising and doesn't know how to check iostreams
for errors.
[Bug libstdc++/86130] Expect SIGSEGV but program just silently exits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86130 --- Comment #12 from Paul Sanders --- Sorry, I posted that in a bit of a rush. I took a proper look and the null pointers that set badbit actually make excellent sense. So I'll suggest a way out of the backwards compatibility conundrum when `ostream::operator<<` is passed a null pointer (of any sort). The suggestion I have is to test for a null pointer _only_ if the stream is set up to throw badbit exceptions Otherwise, just blindly dereference the pointer and crash. The rationale for this is that people who have set up an exception handler for badbit _might_ just have done so to catch null pointers. I think it's unlikely but it's possible. Those who haven't are probably getting away with something they shouldn't. Any interest?
[Bug tree-optimization/86114] ICE in gimple_fold_builtin_strlen with a call to an invalid strlen declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86114 Martin Sebor changed: What|Removed |Added Summary|[8/9 Regression] ICE in |ICE in |gimple_fold_builtin_strlen |gimple_fold_builtin_strlen |with an invalid call to |with a call to an invalid |strnlen |strlen declaration Known to fail|9.0 | --- Comment #6 from Martin Sebor --- Backported to GCC 8 in r261569.
[Bug tree-optimization/86114] [8/9 Regression] ICE in gimple_fold_builtin_strlen with an invalid call to strnlen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86114 --- Comment #5 from Martin Sebor --- Author: msebor Date: Wed Jun 13 20:39:50 2018 New Revision: 261569 URL: https://gcc.gnu.org/viewcvs?rev=261569=gcc=rev Log: PR tree-optimization/86114 - ICE in gimple_fold_builtin_strlen with an invalid call to strnlen gcc/testsuite/ChangeLog: PR tree-optimization/86114 * gcc.dg/pr86114.c: New test. gcc/ChangeLog: PR tree-optimization/86114 * gimple-fold.c (gimple_fold_builtin_strlen): Only handle LHS of integer types. * tree-ssa-strlen.c (maybe_set_strlen_range): Same. Added: branches/gcc-8-branch/gcc/testsuite/gcc.dg/pr86114.c Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/gimple-fold.c branches/gcc-8-branch/gcc/testsuite/ChangeLog branches/gcc-8-branch/gcc/tree-ssa-strlen.c
[Bug libstdc++/86130] Expect SIGSEGV but program just silently exits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86130 --- Comment #11 from Paul Sanders --- > I think most users prefer invalid uses of pointers to fail loudly so they can > be caught early. Few users expect output functions to fail, and even fewer > bother to check for failures when writing to standard streams. Yes, that's very much my own personal preference, but as I dig into this more I can see there are problems with doing what I'm asking for. > Removing this longstanding behaviour now could break an unknown number of > programs which are (implicitly or explicitly) relying on this behaviour of > libstdc++. I think they'd have to be relying on it explicitly (i.e. they turn on badbit exceptions or check explicitly for badbit). Otherwise, they have a bug. Question is, how many are there out there? I doubt many are testing badbit. Not for this reason, anyway. There is however, some info at [cppreference](http://en.cppreference.com/w/cpp/io/ios_base/iostate) which supports your view. Passing in quite a few types as nullptr sets badbit (too many, IMO), but `char *` is not mentioned explicitly. So I suppose it's reasonable for people to expect that _all_ null pointers should be treated in the same way. It's a shame anyone on the standards committee ever thought that testing for null pointers in this way was useful but I suppose we're stuck with it now. Personally, I think it was a big mistake. > Failure to open a file sets failbit, not badbit. Noted, thank you, I'm not very familiar with iostreams. Forget that bit then. > The program did work fine though, and anybody can verify that it does so > intentionally, not by accident. Nice link, thank you, but that doesn't change the basic argument that many programs will not be working quite right because they accidentally passed in a null pointer and didn't expect the resulting behaviour of `ostream`. Still, I might in the end have to say here, sadly: c'est la vie.
[Bug tree-optimization/86114] [8/9 Regression] ICE in gimple_fold_builtin_strlen with an invalid call to strnlen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86114 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Martin Sebor --- Fixed by r261567.
[Bug tree-optimization/86114] [8/9 Regression] ICE in gimple_fold_builtin_strlen with an invalid call to strnlen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86114 --- Comment #3 from Martin Sebor --- Author: msebor Date: Wed Jun 13 20:29:04 2018 New Revision: 261567 URL: https://gcc.gnu.org/viewcvs?rev=261567=gcc=rev Log: PR tree-optimization/86114 - ICE in gimple_fold_builtin_strlen with an invalid call to strnlen gcc/testsuite/ChangeLog: PR tree-optimization/86114 * gcc.dg/pr86114.c: New test. gcc/ChangeLog: PR tree-optimization/86114 * gimple-fold.c (gimple_fold_builtin_strlen): Only handle LHS of integer types. * tree-ssa-strlen.c (maybe_set_strlen_range): Same. Added: trunk/gcc/testsuite/gcc.dg/pr86114.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimple-fold.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-strlen.c
[Bug fortran/86110] ICE in gfc_resolve_character_array_constructor, at fortran/array.c:2044
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86110 --- Comment #4 from kargl at gcc dot gnu.org --- Author: kargl Date: Wed Jun 13 20:17:58 2018 New Revision: 261565 URL: https://gcc.gnu.org/viewcvs?rev=261565=gcc=rev Log: 2018-06-13 Steven G. Kargl PR fortran/86110 * array.c (gfc_resolve_character_array_constructor): Avoid NULL pointer dereference. 2018-06-13 Steven G. Kargl PR fortran/86110 * gfortran.dg/pr86110.f90: New test. Added: branches/gcc-8-branch/gcc/testsuite/gfortran.dg/pr86110.f90 Modified: branches/gcc-8-branch/gcc/fortran/ChangeLog branches/gcc-8-branch/gcc/fortran/array.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug c++/86135] At run time, when the constructor tries to construct an objects element with a initializer-list (using c++11 style) is giving segmentation fault. The old style of initialize with pa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86135 --- Comment #10 from Jonathan Wakely --- You didn't provide a proper testcase so nobody can possibly explain why your code crashes. If it's similar to the code in comment 3 then model_t> tries to construct a vector from a vector using list-init which chooses the initializer_list constructor because object_t can be constructed from vector. It's the same bug 85577.
[Bug c++/86135] At run time, when the constructor tries to construct an objects element with a initializer-list (using c++11 style) is giving segmentation fault. The old style of initialize with pa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86135 --- Comment #9 from Sabetay Toros --- I´ve examined your link. This is not the same case as you are stating. I am not initializing a vector with an initializer list, rather I am trying to initialize only one object member with a universal initialiazer. And all modern C++ books suggest not to use C++98 style initiliazers, just because they are confusing. After constructing the object I am putting to a vector. This is very very simple case. And besides what is your solution to this issue. How the user will be able to find that kind of errors. In these cases gcc must not give a runtime error message but compiler error message. On Wed, Jun 13, 2018 at 9:00 PM, redi at gcc dot gnu.org < gcc-bugzi...@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86135 > > --- Comment #8 from Jonathan Wakely --- > http://en.cppreference.com/w/cpp/language/list_initialization#Notes shows > a > similar example, demonstrating the different behaviour for initializer_list > constructors. std::vector has an initializer-list constructor, so trying to > move-construct a vector when object_t can be constructed from > std::vector will result in infinite recursion. > > This special case only applies to list-initialization, because it's > related to > constructors taking a std::initializer_list. It's totally wrong to say that > list-init and direct-init must do the same thing in the presence of > initializer-list constructors. If they did the same thing there would have > been > no need to introduce list-initialization syntax in the first place. > > -- > You are receiving this mail because: > You reported the bug. >
[Bug libstdc++/86138] New: C++17: getline(istream, string) crashes on Cygwin because incompatible C++14 function is called
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86138 Bug ID: 86138 Summary: C++17: getline(istream, string) crashes on Cygwin because incompatible C++14 function is called Product: gcc Version: 7.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: franke at computer dot org Target Milestone: --- The function std::getline(istream &, string &, char) crashes if build with Cygwin gcc-g++-7.3.0-2 and -std=gnu++17 enabled. This is because there is a bogus prototype specialization in basic_string.h: template<> basic_istream& getline(basic_istream& __in, basic_string& __str, char __delim); There is no implementation for this specialization. This has apparently the same effect as the 'extern template' which is disabled for C++17 in basic_string.tcc: #if _GLIBCXX_EXTERN_TEMPLATE > 0 && __cplusplus <= 201402L ... extern template basic_istream& getline(basic_istream&, string&, char); ... #endif As a consequence, no C++17 compatible code for this getline() is generated and the old getline() from cygstdc++-6.dll is called instead. AFAICS the above still holds for current SVN trunk release 261563. For a testcase and a proposed patch see: https://cygwin.com/ml/cygwin/2018-06/msg00125.html
[Bug sanitizer/86090] [ASAN] ASAN does not properly configure libbacktrace.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86090 --- Comment #3 from chefmax at gcc dot gnu.org --- Author: chefmax Date: Wed Jun 13 19:51:42 2018 New Revision: 261564 URL: https://gcc.gnu.org/viewcvs?rev=261564=gcc=rev Log: 2018-06-13 Denis Khalikov libsanitizer/ PR sanitizer/86090 * configure.ac: Check for lstat and readlink. * configure, config.h.in: Rebuild. Modified: trunk/libsanitizer/ChangeLog trunk/libsanitizer/config.h.in trunk/libsanitizer/configure trunk/libsanitizer/configure.ac
[Bug libstdc++/86130] Expect SIGSEGV but program just silently exits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86130
--- Comment #10 from Martin Sebor ---
As a data point, calling printf ("%s", p) does lead to a segfault in Glibc for
a null p because GCC turns the call into puts(p) which doesn't have the same
feature (see https://sourceware.org/bugzilla/show_bug.cgi?id=5618 for the
background).
I think most users prefer invalid uses of pointers to fail loudly so they can
be caught early. Few users expect output functions to fail, and even fewer
bother to check for failures when writing to standard streams.
Besides the inserter without the test resulting in more efficient code and GCC
emitting a warning when a null pointer is passed to it (it doesn't now even
though it should because of the strlen call), leaving it to the compiler to
deal with can also lead to better code downstream thanks to
-fdelete-null-pointer-checks.
[Bug c++/86094] [8/9 Regression] Call ABI changed for small objects with defaulted ctor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86094 --- Comment #9 from Jason Merrill --- Author: jason Date: Wed Jun 13 19:39:36 2018 New Revision: 261562 URL: https://gcc.gnu.org/viewcvs?rev=261562=gcc=rev Log: PR c++/86094 - wrong code with defaulted move ctor. gcc/c-family/ * c-opts.c (c_common_post_options): Bump the current ABI version to 13. Set warn_abi_version and flag_abi_compat_version to the current version rather than 0. Fix defaulting flag_abi_compat_version from warn_abi_version. gcc/cp/ * class.c (classtype_has_non_deleted_move_ctor): New. * tree.c (maybe_warn_parm_abi, type_has_nontrivial_copy_init): Handle v12 breakage. Added: trunk/gcc/testsuite/g++.dg/abi/invisiref2a.C Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-opts.c trunk/gcc/common.opt trunk/gcc/cp/ChangeLog trunk/gcc/cp/class.c trunk/gcc/cp/cp-tree.h trunk/gcc/cp/tree.c trunk/gcc/doc/invoke.texi trunk/gcc/testsuite/g++.dg/abi/macro0.C
[Bug c++/86094] [8/9 Regression] Call ABI changed for small objects with defaulted ctor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86094 --- Comment #10 from Jason Merrill --- Author: jason Date: Wed Jun 13 19:39:53 2018 New Revision: 261563 URL: https://gcc.gnu.org/viewcvs?rev=261563=gcc=rev Log: PR c++/86094 - wrong code with defaulted move ctor. gcc/c-family/ * c-opts.c (c_common_post_options): Bump the current ABI version to 13. Set warn_abi_version and flag_abi_compat_version to the current version rather than 0. Fix defaulting flag_abi_compat_version from warn_abi_version. gcc/cp/ * class.c (classtype_has_non_deleted_move_ctor): New. * tree.c (maybe_warn_parm_abi, type_has_nontrivial_copy_init): Handle v12 breakage. Added: branches/gcc-8-branch/gcc/testsuite/g++.dg/abi/invisiref2a.C Modified: branches/gcc-8-branch/gcc/c-family/ChangeLog branches/gcc-8-branch/gcc/c-family/c-opts.c branches/gcc-8-branch/gcc/common.opt branches/gcc-8-branch/gcc/cp/ChangeLog branches/gcc-8-branch/gcc/cp/class.c branches/gcc-8-branch/gcc/cp/cp-tree.h branches/gcc-8-branch/gcc/cp/tree.c branches/gcc-8-branch/gcc/doc/invoke.texi branches/gcc-8-branch/gcc/testsuite/g++.dg/abi/macro0.C
[Bug c/86137] ubsan runtime error in c-format.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86137 --- Comment #1 from joseph at codesourcery dot com --- Yes, this code needs to be fixed to avoid undefined overflow (if argnum > INT_MAX / 10 || (argnum == INT_MAX / 10 && *fcp - '0' > INT_MAX % 10), record that overflow has occurred and don't do the arithmetic on argnum).
[Bug libstdc++/86130] Expect SIGSEGV but program just silently exits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86130 --- Comment #9 from Jonathan Wakely --- (In reply to Paul Sanders from comment #8) > Thanks for your comments. I can see there are two sides to this. > > I was in the middle of composing the tract below. I'll include that anyway > because it took me ages to type. There's a bit at the end about people who > might get bitten if you do make this change, but a plausible alternative to > crashing the program might be to (a) print "(null)", and (b) leave the > badbit alone. I think I'd settle for that, I actually quite like the way > the printf family behaves. That would be another valid outcome of undefined behaviour, but would make it much harder to detect the problem. Setting badbit makes it possible to detect and take action (including calling std::abort() or throwing an exception, if you want to). > My view of the badbit, BTW, is that it's not there to catch programming > errors - it's there to report adverse events that come up at runtime (e.g. > cannot open file). I expand on that below. Failure to open a file sets failbit, not badbit. > After all, ostream would likely crash if the pointer was invalid, so what's > so special about NULL? It's detectable. > [Additional note: I can see if you change the current behaviour you might > get a bit of flak from people whose programs "used to work fine". Well, > they didn't, and they should be grateful to you for alerting them to that > fact.] The program did work fine though, and anybody can verify that it does so intentionally, not by accident: https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libstdc%2B%2B-v3/include/bits/ostream.tcc;h=e02ba55a6262b96ead90595e1aad56119a965844;hb=HEAD#l323 As the standard says: Permissible undefined behavior ranges from ignoring the situation completely with unpredictable results, to behaving during translation or program execution in a documented manner characteristic of the environment (with or without the issuance of a diagnostic message), to terminating a translation or execution (with the issuance of a diagnostic message).
[Bug fortran/86110] ICE in gfc_resolve_character_array_constructor, at fortran/array.c:2044
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86110 --- Comment #3 from kargl at gcc dot gnu.org --- Author: kargl Date: Wed Jun 13 19:37:50 2018 New Revision: 261561 URL: https://gcc.gnu.org/viewcvs?rev=261561=gcc=rev Log: 2018-06-13 Steven G. Kargl PR fortran/86110 * array.c (gfc_resolve_character_array_constructor): Avoid NULL pointer dereference. 2018-06-13 Steven G. Kargl PR fortran/86110 * gfortran.dg/pr86110.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr86110.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/array.c trunk/gcc/testsuite/ChangeLog
[Bug libstdc++/86130] Expect SIGSEGV but program just silently exits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86130 --- Comment #8 from Paul Sanders --- Thanks for your comments. I can see there are two sides to this. I was in the middle of composing the tract below. I'll include that anyway because it took me ages to type. There's a bit at the end about people who might get bitten if you do make this change, but a plausible alternative to crashing the program might be to (a) print "(null)", and (b) leave the badbit alone. I think I'd settle for that, I actually quite like the way the printf family behaves. My view of the badbit, BTW, is that it's not there to catch programming errors - it's there to report adverse events that come up at runtime (e.g. cannot open file). I expand on that below. - The code I posted was by way of example. I didn't realise at the time what was causing the behaviour I was observing - this whole thing came up on StackOverflow and you can see the thread here (please excuse me calling gcc 'naughty', I didn't have the full picture then): https://stackoverflow.com/questions/50696746/c-template-class-instance-issue I guess my point is that the way things are implemented currently is likely to lead to subtle, undetected bugs. Not everyone checks for errors properly, and not everyone (and that included me until just now) knows that if you want an iostream to throw exceptions you have to tell it so. Result? People innocently write code like that shown on in that thread and think they have done all they need to. But they haven't. So I see the current behaviour as being the worst of all worlds. After all, ostream would likely crash if the pointer was invalid, so what's so special about NULL? They are both programming errors, and not the sort of situation you want to have to write extra code to handle explicitly. Throwing an exception should be reserved for some external influence on the stream (such as a remote file becoming inaccessible due to a network error, say), which you *do* need to handle in your code. To put it another way, what are you going to do in your exception handler if you get a nullptr exception (whatever that is - is there even one?). Display "nullptr encountered, operation aborted" to the user and bail out? That's not going to impress your customer base. The reason I like bringing the program down is that it provides an opportunity to generate a stack trace and post it home somehow. But hopefully, the coding error is discovered before the code even gets out into the field, if you do this. [Additional note: I can see if you change the current behaviour you might get a bit of flak from people whose programs "used to work fine". Well, they didn't, and they should be grateful to you for alerting them to that fact.]
[Bug c/86137] New: ubsan runtime error in c-format.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86137
Bug ID: 86137
Summary: ubsan runtime error in c-format.c
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
For this C code, derived from
gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-18.c
a() { __builtin_sprintf(a, "%9223372036854775808i"); }
and a recent ubsan version of gcc trunk, I get
$ ~/gcc/results.261388.ubsan/bin/gcc -Wall -c bug445.c
../../trunk/gcc/c-family/c-format.c:1252:20: runtime error: signed integer
overflow: 922337203 * 10 cannot be represented in type 'int'
Source code is
nargnum = 10 * argnum + (*fcp - '0');
[Bug tree-optimization/86085] I/O built-ins considered argument clobbers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86085 --- Comment #2 from Martin Sebor --- To make use of the Glibc printf hooks users have to disable the GCC built-ins. Otherwise the hooks might interfere with the sprintf optimization.
[Bug libstdc++/86130] Expect SIGSEGV but program just silently exits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86130 --- Comment #7 from Jonathan Wakely --- I don't know the original reason for handling null pointers here, but it's consistent with glibc's printf which prints "(null)" when a null pointer is provided for a %s specifier. Removing this longstanding behaviour now could break an unnknown number of programs which are (impicitly or explicitly) relying on this behaviour of libstdc++. It's not at all clear to me that crashing is preferable.
[Bug libstdc++/86127] STL containers do not satisfy container.requirements.general clause 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86127 --- Comment #10 from Jonathan Wakely --- As I said in comment 6, I've already removed the copies that forward_list does on destruction. As I said in comment 3, there are no copies in the default constructor, they're in the initializer-list constructors. The standard says the initializer-list constructors look like: vector(initializer_list, const Allocator& = Allocator()); That default argument needs to get copied into the vector's allocator member somehow. It could be avoided by defining: vector(initializer_list); vector(initializer_list, const Allocator&); But doing so just to avoid making copies of a cheap-to-copy object is not a good justification, and would make it impossible to explicitly instantiate the container with a non-default constructible allocator type. Node-based containers such as forward_list and map neede to convert the allocator from the value_type to the node type. That can either happen once on construction, or every time elements are inserted or erased. Doing it on construction is the obvious choice, and that's where you see the "template copy constructor" lines for forward_list and map. The standard allows those copies, and they should be cheap. There is no bug here.
[Bug libstdc++/86130] Expect SIGSEGV but program just silently exits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86130 --- Comment #6 from Jonathan Wakely --- And they don't test for iostream operations failing? The program has undefined behaviour, i.e. a bug. Whether it's better to identify that and treat it as a corrupt stream state (setting badbit, and optionally throwing an exception) or crash the program depends on the program. There's no single choice that's correct for all programs.
[Bug c++/86129] Expect SIGBUS but program just silently exits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86129 --- Comment #4 from Paul Sanders --- Sorry, that didn't happen on purpose. I edited the title, maybe that's what caused it, or maybe it's because someone (Martin?) changed the component from gcc to libstdc++. Anyway, I won't post anything further here (I probably shouldn't have posted that last one, but saying 'GIGO' is not a valid reason for ignoring this issue).
[Bug libstdc++/86127] STL containers do not satisfy container.requirements.general clause 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86127 --- Comment #9 from Scott Constable --- (In reply to Jonathan Wakely from comment #8) > (In reply to Scott Constable from comment #7) > > (In reply to Jonathan Wakely from comment #1) > > > The allocator requirements say that move construction must be equivalent > > > to > > > copy construction, and allocators should be cheap to copy anyway. I don't > > > consider this a bug. > > > > To be nitpicky, it looks like this equivalence requirement was introduced > > recently in the C++20 draft. I'm compiling using C++14. > > It's a defect report, so applies to previous standards. > > https://wg21.link/lwg2593 > > Applying that change selectively would be madness. Ah, I wasn't aware this was a defect correction. I should have figured that out myself. > > > I agree that allocators should be cheap to copy, but as a general principle > > I think that all objects should be copied only when necessary. This is the > > behavior I have observed in STL containers in libc++, as shown in my example > > above. It just makes sense to me that when an STL container is moved, its > > allocator should be moved, and no copying should be performed. > > And that's exactly what libstdc++ does. Your test fails to distinguish > between copies/moves performed during move construction and other operations. I misstated my argument here. The STL container move invokes one move from the allocator, and this is correct. What I don't understand is why the other copies, e.g. from the container default constructor and destructor, are necessary. Particularly when libc++ does not exhibit this behavior.
[Bug fortran/82207] ieee_class identifies signaling NaNs as quiet NaNs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82207 --- Comment #12 from Steve Kargl --- On Wed, Jun 13, 2018 at 03:55:02PM +, guez at lmd dot ens.fr wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82207 > > --- Comment #11 from Lionel GUEZ --- > And what about my suggestion that ieee_support_nan(0.) should return false for > the time being? > AFAIK, the original implementation for the IEEE support followed either the the F95 Floating-Point Exceptions Tecnical Report (ISO/EIC TR 15580:2001) or F2003. These refer to IEC 60599 (1989-01), aka IEEE 754-1985. Someone needs to review the entirety of the IEEE support with respect to the upcoming F2018 standard. F2018 refers to ISO/IEC/IEEE 60559:2011. I know that 60599:2011 is a significant revision to 60599 (1989-01). Unfortunately, there are not enough "someone"s to go around to fix gfortran. Given a very quick glance at F2003, I think that it may not be a good idea for ieee_support_nan(0.) to return .false. as this then means IEEE_IS_NAN(X) cannot be used to determine if X is a NaN.
[Bug libstdc++/86130] Expect SIGSEGV but program just silently exits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86130 --- Comment #5 from Jonathan Wakely --- *** Bug 86129 has been marked as a duplicate of this bug. ***
[Bug c++/86129] Expect SIGBUS but program just silently exits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86129 Jonathan Wakely changed: What|Removed |Added Resolution|INVALID |DUPLICATE --- Comment #3 from Jonathan Wakely --- You've created two copies of this bug report, it doesn't help to continue two discussions in separate places. *** This bug has been marked as a duplicate of bug 86130 ***
[Bug c++/86135] At run time, when the constructor tries to construct an objects element with a initializer-list (using c++11 style) is giving segmentation fault. The old style of initialize with pa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86135 --- Comment #8 from Jonathan Wakely --- http://en.cppreference.com/w/cpp/language/list_initialization#Notes shows a similar example, demonstrating the different behaviour for initializer_list constructors. std::vector has an initializer-list constructor, so trying to move-construct a vector when object_t can be constructed from std::vector will result in infinite recursion. This special case only applies to list-initialization, because it's related to constructors taking a std::initializer_list. It's totally wrong to say that list-init and direct-init must do the same thing in the presence of initializer-list constructors. If they did the same thing there would have been no need to introduce list-initialization syntax in the first place.
[Bug libstdc++/86130] Expect SIGSEGV but program just silently exits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86130 --- Comment #4 from Paul Sanders --- @Johnathon Crashing the program is the right thing to do, because it means that the developer (or the test department) will get to find out about the problem before the customer does. Does that help you see why I am pushing for it?
[Bug c++/86129] Expect SIGBUS but program just silently exits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86129 --- Comment #2 from Paul Sanders --- The program should crash. That way, the developer (or the test department) gets to find out about the problem before the customer. I would have thought this was obvious.
[Bug libstdc++/86127] STL containers do not satisfy container.requirements.general clause 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86127 --- Comment #8 from Jonathan Wakely --- (In reply to Scott Constable from comment #7) > (In reply to Jonathan Wakely from comment #1) > > The allocator requirements say that move construction must be equivalent to > > copy construction, and allocators should be cheap to copy anyway. I don't > > consider this a bug. > > To be nitpicky, it looks like this equivalence requirement was introduced > recently in the C++20 draft. I'm compiling using C++14. It's a defect report, so applies to previous standards. https://wg21.link/lwg2593 Applying that change selectively would be madness. > I agree that allocators should be cheap to copy, but as a general principle > I think that all objects should be copied only when necessary. This is the > behavior I have observed in STL containers in libc++, as shown in my example > above. It just makes sense to me that when an STL container is moved, its > allocator should be moved, and no copying should be performed. And that's exactly what libstdc++ does. Your test fails to distinguish between copies/moves performed during move construction and other operations.
[Bug c++/86135] At run time, when the constructor tries to construct an objects element with a initializer-list (using c++11 style) is giving segmentation fault. The old style of initialize with pa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86135 --- Comment #7 from Jonathan Wakely --- (In reply to Sabetay Toros from comment #6) > the rules may be different but results must be the same. No, that's not true. The point of the different rules is to do different things. > There is a flaw here. If gcc is right in *list-initialization * then direct > initialization is wrong and should give the same result, No.
[Bug libstdc++/86127] STL containers do not satisfy container.requirements.general clause 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86127 --- Comment #7 from Scott Constable --- (In reply to Jonathan Wakely from comment #1) > The allocator requirements say that move construction must be equivalent to > copy construction, and allocators should be cheap to copy anyway. I don't > consider this a bug. To be nitpicky, it looks like this equivalence requirement was introduced recently in the C++20 draft. I'm compiling using C++14. I agree that allocators should be cheap to copy, but as a general principle I think that all objects should be copied only when necessary. This is the behavior I have observed in STL containers in libc++, as shown in my example above. It just makes sense to me that when an STL container is moved, its allocator should be moved, and no copying should be performed.
[Bug c++/86135] At run time, when the constructor tries to construct an objects element with a initializer-list (using c++11 style) is giving segmentation fault. The old style of initialize with pa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86135 --- Comment #6 from Sabetay Toros --- Hi, *Because the rules for direct-initialization (with parentheses) andlist-initialization (with braces) are different. Different rules meansdifferent things happen. * the rules may be different but results must be the same. There is a flaw here. If gcc is right in *list-initialization * then direct initialization is wrong and should give the same result, the segmentation fault. But it is not giving an error and it is working as expected. If Clang is running both version without an error, sorry you can not defend this. It cant be a biased result for achieving the initialization of a member. On Wed, Jun 13, 2018 at 7:04 PM, redi at gcc dot gnu.org < gcc-bugzi...@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86135 > > --- Comment #5 from Jonathan Wakely --- > (In reply to Sabetay Toros from comment #4) > > If it is not a bug then why the parenthesis version is working. > > Because the rules for direct-initialization (with parentheses) and > list-initialization (with braces) are different. Different rules means > different things happen. > > > Moreover Strastroup advice is to use the initializer list version in > > constructing objects not the parenthesis. > > That's not always good advice. > > > Besides Clang does not suffer with that kind of error. Both styles are > > working. > > Clang does not follow the standard correctly in this respect. > > -- > You are receiving this mail because: > You reported the bug. >
[Bug rtl-optimization/86107] [9 Regression] ICE: in ix86_mitigate_rop, at config/i386/i386.c:42301 with -O -funroll-loops -mavx5124fmaps -mmitigate-rop --param=hot-bb-frequency-fraction=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86107 --- Comment #6 from rsandifo at gcc dot gnu.org --- (In reply to Uroš Bizjak from comment #5) > (In reply to rsand...@gcc.gnu.org from comment #4) > > > > but should not fail verification even for !TARGET_INTER_UNIT_MOVES_TO_VEC > > > targets. As a matter of fact, the compilation works with -mtune=intel. > > > > This is by design when the insn belongs to a block that is being > > optimised for speed rather than size. It isn't recog per se that > > fails, but the validate_change stuff, which is designed for doing > > optional optimisations rather than required changes. > > Please note that regrename_do_replace fails, since the mentioned instruction > does not validate, although the compiler just wants to rename %bx to %dx in > (insn 1264); a simple register rename should not make the new insn invalid. Yeah, but "validate" in the "validate_change" sense rather than "recog_memoized" sense. Like I say, that's by design: regrename shouldn't be changing a "preferred for speed" alternative into a "not preferred for speed" alternative if the block is being optimised for speed. The renaming is a pure optimisation when regrename does it, so returning false is the right thing to do.
[Bug target/86048] [8/9 Regression] .seh_savexmm offset is negative error when compiling libpng
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86048
--- Comment #7 from Eric Botcazou ---
To give a bit more information about the bug: it's a bad interaction between
SEH, -freorder-blocks-and-partition (default) and
__builtin_{frame,return}_address.
[Bug libstdc++/86130] Expect SIGSEGV but program just silently exits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86130 --- Comment #3 from Jonathan Wakely --- Arguably crashing the program is more unfriendly. We could add the nonnull attribute to the relevant ostream members, or add assertions that can be optionally enabled, but I'm not convinced that crashing is necessarily an improvement.
[Bug c++/86135] At run time, when the constructor tries to construct an objects element with a initializer-list (using c++11 style) is giving segmentation fault. The old style of initialize with pa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86135 --- Comment #5 from Jonathan Wakely --- (In reply to Sabetay Toros from comment #4) > If it is not a bug then why the parenthesis version is working. Because the rules for direct-initialization (with parentheses) and list-initialization (with braces) are different. Different rules means different things happen. > Moreover Strastroup advice is to use the initializer list version in > constructing objects not the parenthesis. That's not always good advice. > Besides Clang does not suffer with that kind of error. Both styles are > working. Clang does not follow the standard correctly in this respect.
[Bug libstdc++/86127] STL containers do not satisfy container.requirements.general clause 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86127 Jonathan Wakely changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |9.0 Severity|normal |enhancement --- Comment #6 from Jonathan Wakely --- I've removed the converting copies from forward_list.
[Bug c++/86129] New: Expect SIGBUS but program just silently exits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86129
Bug ID: 86129
Summary: Expect SIGBUS but program just silently exits
Product: gcc
Version: 8.1.0
Status: RESOLVED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: p.sanders at alpinesoft dot co.uk
Target Milestone: ---
Status: RESOLVED
Resolution: INVALID
Hi guys,
My first post here, hope I do things right.
The following code snippet just exits the program silently rather than
generating SIGBUS as you would expect it to. I don't think what doing that is
appropriate.
clang *does* generate SIGBUS, and although the code below is, strictly
speaking, UB, I don't think gcc should behave as it does, for obvious reasons.
OK, here's the code:
#include
int main()
{
char *p = (char *) nullptr;
std::cout << "Watch the " << p << "birdie" << std::endl;
return 0;
}
And here's the output (note: no SIGBUS):
Watch the
Live demo here (where you can also try running it with clang)
https://wandbox.org/permlink/M1S74HqjT1HvLtr0
Sounds like an easy fix. Thanks.
--- Comment #1 from Richard Biener ---
Probably some nonnull attribute somewhere. Anyway, GIGO.
[Bug ipa/86124] [9 Regression] ICE in create_variable_info_for, at tree-ssa-structalias.c:6123
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86124 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |ASSIGNED Keywords||ice-on-valid-code Last reconfirmed||2018-06-13 Component|c |ipa CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 Target Milestone|--- |9.0 --- Comment #1 from Richard Biener --- Confirmed with -O -fipa-pta. Mine.
[Bug fortran/82207] ieee_class identifies signaling NaNs as quiet NaNs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82207 --- Comment #11 from Lionel GUEZ --- And what about my suggestion that ieee_support_nan(0.) should return false for the time being?
[Bug middle-end/86123] [8/9 Regression] ICE in prepare_cmp_insn, at optabs.c:3967
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86123 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Status|UNCONFIRMED |NEW Known to work||7.3.1 Keywords||ice-on-valid-code, ||needs-bisection Last reconfirmed||2018-06-13 Component|c |middle-end Ever confirmed|0 |1 Target Milestone|--- |8.2 Known to fail||8.1.1 --- Comment #1 from Richard Biener --- Confirmed.
[Bug middle-end/86122] [8/9 Regression] ICE in useless_type_conversion_p, at gimple-expr.c:87
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86122
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-06-13
CC||glisse at gcc dot gnu.org,
||rguenth at gcc dot gnu.org
Component|c |middle-end
Target Milestone|--- |8.2
Ever confirmed|0 |1
--- Comment #1 from Richard Biener ---
Confirmed.
/* (A +- CST1) +- CST2 -> A + CST3
Use view_convert because it is safe for vectors and equivalent for
scalars. */
(for outer_op (plus minus)
...
/* Last resort, use some unsigned type. */
(with { tree utype = unsigned_type_for (type); }
(view_convert (inner_op
(view_convert:utype @0)
(view_convert:utype
{ drop_tree_overflow (cst); })
but utype is NULL_TREE here. type is
signed_or_unsigned_type_for doesn't handle COMPLEX_TYPE.
[Bug middle-end/86121] [9 Regression] missing -Wstringop-overflow on strcpy followed by strcat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86121 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-06-13 CC||rguenth at gcc dot gnu.org Version|8.0 |9.0 Target Milestone|--- |9.0 Ever confirmed|0 |1 --- Comment #3 from Richard Biener --- Confirmed. The change was desired and the outcome is desired as well. The warning code needs to deal with this. We only optimize this after the strlen pass which runs pretty late and transforms the two calls to memcpy_chk calls (w/o folding them it seems so it takes until VRP/forwprop to finally fold them). There's a missed optimization opportunity in merging the two aggregate copies.
[Bug tree-optimization/86114] [8/9 Regression] ICE in gimple_fold_builtin_strlen with an invalid call to strnlen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86114 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Target Milestone|--- |8.2
[Bug middle-end/86113] __builtin_nan has "const" attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86113 Richard Biener changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2018-06-13 Component|c |middle-end Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Hum, confirmed. I guess they need to be either PURE or ".R".
[Bug libstdc++/86130] Expect SIGSEGV but program just silently exits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86130 --- Comment #2 from Paul Sanders --- Hi Martin, Thanks very much for your prompt reply, and I completely agree with your viewpoint. I therefore hereby request that libstc++ stops behaving like that and just lets the SIGSEGV happen. The current behaviour is very unfriendly.
[Bug c++/86135] At run time, when the constructor tries to construct an objects element with a initializer-list (using c++11 style) is giving segmentation fault. The old style of initialize with pa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86135 --- Comment #4 from Sabetay Toros --- *" --- Comment #2 from Jonathan Wakely http://gnu.org/>> ---This is not a bug, GCC is correct. With list-initialization the compiler doesnot always select a copy/move constructor even when the argument is the sametype as the object being constructed. "* If it is not a bug then why the parenthesis version is working. Moreover Strastroup advice is to use the initializer list version in constructing objects not the parenthesis. Besides Clang does not suffer with that kind of error. Both styles are working. Sabetay On Wed, Jun 13, 2018 at 5:52 PM, redi at gcc dot gnu.org < gcc-bugzi...@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86135 > > Jonathan Wakely changed: > >What|Removed |Added > > > Status|WAITING |RESOLVED > Resolution|--- |DUPLICATE > > --- Comment #2 from Jonathan Wakely --- > This is not a bug, GCC is correct. With list-initialization the compiler > does > not always select a copy/move constructor even when the argument is the > same > type as the object being constructed. > > *** This bug has been marked as a duplicate of bug 85577 *** > > -- > You are receiving this mail because: > You reported the bug. >
[Bug rtl-optimization/86108] [8/9 Regression] crash during unwinding with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86108 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Status|UNCONFIRMED |NEW Known to work||7.3.0 Keywords||EH, needs-bisection, ||wrong-code Last reconfirmed||2018-06-13 Component|c++ |rtl-optimization CC||hubicka at gcc dot gnu.org Ever confirmed|0 |1 Summary|crash during unwinding with |[8/9 Regression] crash |-O2 |during unwinding with -O2 Target Milestone|--- |8.2 Known to fail||8.1.0 --- Comment #1 from Richard Biener --- Confirmed. Note it works for 7.3 with -freorder-blocks-and-partition
[Bug gcov-profile/86109] [8/9 Regression] gcov reports lines in lambdas as not executable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86109 Richard Biener changed: What|Removed |Added Target Milestone|--- |8.2
[Bug rtl-optimization/86104] gcc ICE at -O1 on x86_64-linux-gnu in "plus_constant", at explow.c:103
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86104 Richard Biener changed: What|Removed |Added Target||x86_64-*-*, i?86-*-* --- Comment #3 from Richard Biener --- Yeah, I think ICE-on-invalid RTL input isn't something we want to track... We might want to track it for the purpose of a not implemented RTL IL verifier.
[Bug tree-optimization/86097] [8/9 Regression] ICE: verify_gimple failed (error: mismatching comparison operand types)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86097 Richard Biener changed: What|Removed |Added Priority|P3 |P2 CC||rguenth at gcc dot gnu.org
[Bug tree-optimization/86089] [9 Regression] ICE in get_string_length, at tree-ssa-strlen.c:653
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86089 Martin Sebor changed: What|Removed |Added CC||dcb314 at hotmail dot com --- Comment #15 from Martin Sebor --- *** Bug 86128 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/86128] ice in get_string_length, at tree-ssa-strlen.c:653
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86128 Martin Sebor changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |RESOLVED CC||msebor at gcc dot gnu.org Component|c |tree-optimization Resolution|--- |DUPLICATE --- Comment #1 from Martin Sebor --- The test case is corrupted but I'm pretty sure the ICE has been fixed and this report is a duplicate of bug 86089. Please reopen if it persists (and include a valid test case). *** This bug has been marked as a duplicate of bug 86089 ***
[Bug c++/86094] [8/9 Regression] Call ABI changed for small objects with defaulted ctor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86094 --- Comment #8 from Richard Biener --- Note if there's any ABI change between 8.1 and 8.2 please adjust changes.html to note this as a caveat (even if the 7.3 -> 8.1 change was unintended).
[Bug c++/86094] [8/9 Regression] Call ABI changed for small objects with defaulted ctor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86094 --- Comment #7 from Richard Biener --- Fixed?
[Bug c/86093] [8/9 Regression] volatile ignored on pointer in C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86093 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Target Milestone|--- |8.2
[Bug c/86092] global constant pointer optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86092 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #6 from Richard Biener --- kern_buff_p could be allocated to .rodata as well and thus a write traps.
[Bug c++/86091] [fold expression] Slow compile time and high memory usage compared to initializer_list folds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86091 --- Comment #1 from Richard Biener --- I can't reproduce the slowness. > /usr/bin/time g++-8 t.C -std=gnu++1z -Wall -Wextra 0.23user 0.04system 0:00.27elapsed 99%CPU (0avgtext+0avgdata 44028maxresident)k 0inputs+1568outputs (0major+14354minor)pagefaults 0swaps > /usr/bin/time g++-8 t.C -std=gnu++1z -Wall -Wextra -DBUG 0.18user 0.03system 0:00.22elapsed 100%CPU (0avgtext+0avgdata 30476maxresident)k 0inputs+1408outputs (0major+10204minor)pagefaults 0swaps
[Bug libstdc++/86127] STL containers do not satisfy container.requirements.general clause 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86127 --- Comment #5 from Jonathan Wakely --- Author: redi Date: Wed Jun 13 15:14:48 2018 New Revision: 261554 URL: https://gcc.gnu.org/viewcvs?rev=261554=gcc=rev Log: PR libstdc++/86127 avoid unnecessary allocator conversions There is no need to use an allocator of the correct value_type when calling allocator_traits::construct and allocator_traits::destroy. The existing node allocator can be used, instead of constructing a new allocator object every time. There's also no benefit to using __gnu_cxx::__alloc_traits instead of std::allocator_traits to get the pointer and const_pointer types. std::forward_list is only available for C++11 and later, when std::allocator_traits is available too. PR libstdc++/86127 * include/bits/forward_list.h (_Fwd_list_base::_Tp_alloc_type): Remove unused typedef. (_Fwd_list_base::_Node_alloc_traits): Use allocator_traits instead of __gnu_cxx::__alloc_traits. (_Fwd_list_base::_M_create_node, _Fwd_list_base::_M_erase_after): Use node allocator to create and destroy elements. (forward_list::_Tp_alloc_type): Remove unused typedef. (forward_list::_Alloc_traits): Use allocator_traits instead of __gnu_cxx::__alloc_traits. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/forward_list.h trunk/libstdc++-v3/include/bits/forward_list.tcc
[Bug libstdc++/86130] Expect SIGBUS but program just silently exits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86130 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org Component|c++ |libstdc++ --- Comment #1 from Martin Sebor --- The iostream inserters for char* require the pointer be non-null (and valid), so their behavior is undefined otherwise. Libstdc++ detects the null pointer and sets badbit in response which has the effect of discarding all subsequent output sent to the stream. If Clang/libc++ fails with a SEGV that's most likely because libc++ doesn't have this feature. FWIW, I don't think think detecting null pointers like this in the library is a useful feature. They should be treated the same as any other invalid pointer: i.e., let GCC decide what to do, which may be to issue a warning when it can detect the pointer is null (and either let the code SEGV or drop the dereference).
[Bug sanitizer/86090] [ASAN] ASAN does not properly configure libbacktrace.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86090 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-06-13 CC||rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Richard Biener --- Confirmed.
[Bug tree-optimization/86085] I/O built-ins considered argument clobbers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86085 Richard Biener changed: What|Removed |Added Keywords||alias, missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2018-06-13 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed. Note that some conservatism is because of glibc allowing hooks into printf formatting.
[Bug fortran/85703] [openacc] ICE in resolve_fntype, at fortran/resolve.c:16313
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85703 cesar at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from cesar at gcc dot gnu.org --- Fixed in trunk.
[Bug fortran/85702] [openacc] ICE in gfc_format_decoder, at fortran/error.c:943
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85702 cesar at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from cesar at gcc dot gnu.org --- Fixed in trunk.
[Bug tree-optimization/86136] Modular multiplication optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86136 --- Comment #1 from MCCCS --- Note: It can notice (a * n) % k = 0 if n is a multiple of k. The bug happens only if n % k != 0.
[Bug c++/86135] At run time, when the constructor tries to construct an objects element with a initializer-list (using c++11 style) is giving segmentation fault. The old style of initialize with pa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86135
--- Comment #3 from Jonathan Wakely ---
Based on the names I'm assuming your code is the same as a case I analysed
recently, which reduces to:
#include
#include
struct object_t {
template
object_t(T object)
: obj{std::make_shared>(std::move(object))}
{ }
struct concept_t {
virtual ~concept_t() = default;
};
template
struct model_t : concept_t {
model_t(T value) : _data{std::move(value)} {}
T _data;
};
std::shared_ptr obj;
};
int main() {
std::vector d;
std::vector d2;
d.push_back(d2);
}
This crashes with a stack overflow, due to Core DR 2137. GCC appears to be
implementing the standard correctly.
[Bug tree-optimization/86136] New: Modular multiplication optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86136
Bug ID: 86136
Summary: Modular multiplication optimization
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: mcccs at gmx dot com
Target Milestone: ---
Optimization: Ofast
GCC can't see that
(a * n) % k = (a * (n % k)) % k
(even) when n is known at compile time.
As a result,
int k (int a) {
return (a * t) % 5;
}
always gives a different assembly for t = 1, 2, ...
you can also replace 5 with any number
Play with it here: https://godbolt.org/g/HkyHqg
Clang has this bug too.
[Bug c++/85577] list-initialization chooses initializer-list constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85577 Jonathan Wakely changed: What|Removed |Added CC||sabetaytoros at gmail dot com --- Comment #5 from Jonathan Wakely --- *** Bug 86135 has been marked as a duplicate of this bug. ***
[Bug c++/86135] At run time, when the constructor tries to construct an objects element with a initializer-list (using c++11 style) is giving segmentation fault. The old style of initialize with pa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86135 Jonathan Wakely changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Jonathan Wakely --- This is not a bug, GCC is correct. With list-initialization the compiler does not always select a copy/move constructor even when the argument is the same type as the object being constructed. *** This bug has been marked as a duplicate of bug 85577 ***
[Bug fortran/85703] [openacc] ICE in resolve_fntype, at fortran/resolve.c:16313
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85703 --- Comment #4 from cesar at gcc dot gnu.org --- Author: cesar Date: Wed Jun 13 14:31:17 2018 New Revision: 261551 URL: https://gcc.gnu.org/viewcvs?rev=261551=gcc=rev Log: PR fortran/85703 gcc/fortran/ * parse.c (decode_oacc_directive): Set gfc_matching_function to false. (decode_omp_directive): Likewise. gcc/testsuite/ * gfortran.dg/goacc/pr85703.f90: New test. * gfortran.dg/gomp/pr85703.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/goacc/pr85703.f90 trunk/gcc/testsuite/gfortran.dg/gomp/pr85703.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/parse.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/85702] [openacc] ICE in gfc_format_decoder, at fortran/error.c:943
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85702 --- Comment #2 from cesar at gcc dot gnu.org --- Author: cesar Date: Wed Jun 13 14:29:04 2018 New Revision: 261550 URL: https://gcc.gnu.org/viewcvs?rev=261550=gcc=rev Log: PR fortran/85702 gcc/fortran/ * openmp.c (gfc_match_oacc_wait): Use %C to report error location. gcc/testsuite/ * gfortran.dg/goacc/pr85702.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/goacc/pr85702.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/openmp.c trunk/gcc/testsuite/ChangeLog
