[Bug c++/86177] Wnull-dereference warning for object file compile missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86177
--- Comment #6 from Jonny Grant ---
Jonathan, This is a good point. Where is best to document it?
It's very useful to have these warnings, and I was unaware that -Wall would not
turn on such a necessary feature, or -O2
Could there be overall documentation on some default warning options that give
most useful warnings for safe code development?
BTW, I do feel the function could be warned when compiled as an object.
void f(int *i)
{
*i = 1;
}
There is an implied requirement that the pointer is never null.
[Bug c/86178] No warning when missing return from function main()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86178 --- Comment #3 from Jonny Grant --- oops, my bad
[Bug c/84195] newlines in deprecated diagnostics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84195 Andreas Schwab changed: What|Removed |Added Status|RESOLVED|REOPENED Last reconfirmed||2018-06-17 Resolution|FIXED |--- Ever confirmed|0 |1 --- Comment #6 from Andreas Schwab --- FAIL: gcc.c-torture/compile/pr84195.c -O0 (test for warnings, line 15) FAIL: gcc.c-torture/compile/pr84195.c -O0 (test for excess errors) Excess errors: /opt/gcc/gcc-20180616/gcc/testsuite/gcc.c-torture/compile/pr84195.c:15:3: warning: 'i' is deprecated: foo bar [-Wdeprecated-declarations]
[Bug c++/86147] [8/9 Regression] Lambda is capturing a non-ODR-used constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86147 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Jason Merrill --- Fixed.
[Bug c++/86171] [6/7/8/9 Regression] g++ ICE on valid code: tree check: expected var_decl or function_decl, have type_decl in duplicate_decls, at cp/decl.c:2291
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86171 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug libstdc++/86189] New: not equal allocators not behaving as expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86189
Bug ID: 86189
Summary: not equal allocators not behaving as expected
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: rianquinn at gmail dot com
Target Milestone: ---
I think this is a bug, but I am dealing with allocators so I am not 100% sure
here. I have created a really simple allocator for testing. The allocators are
NOT equal, and I have instructed the containers to propagate the allocator
using the propagate_on_container_copy_assignment alias set to true. Propagation
occurs, but during the destruction of the containers, the old allocator is
somehow being used. Whats worse is the newly allocated memory that was created
using one allocator, is deallocated using another, even though they are not
equal. Seems like a bug.
Here is the allocator I have created:
template
class myallocator4
{
public:
using value_type = T;
using pointer = T *;
using size_type = std::size_t;
using propagate_on_container_copy_assignment = std::true_type;
using is_always_equal = std::false_type;
public:
myallocator4() = default;
template
myallocator4(const myallocator4 &other) noexcept
{ (void) other; }
pointer allocate(size_type n)
{
if (auto ptr = static_cast(malloc(sizeof(T) * n))) {
std::cout << "A: " << this << " ptr: " << ptr << '\n';
return ptr;
}
throw std::bad_alloc();
}
void deallocate(pointer p, size_type n)
{
(void) n;
std::cout << "D: " << this << " ptr: " << p << '\n';
free(p);
}
};
template
bool operator==(const myallocator4 &, const myallocator4 &)
{ return false; }
template
bool operator!=(const myallocator4 &, const myallocator4 &)
{ return true; }
Here is the test case:
TEST_CASE("copy container, propogate")
{
std::cout << "copy container, propogate\n";
std::list> mylist1;
std::list> mylist2;
mylist1.push_back(1);
mylist1.push_back(2);
mylist1.push_back(3);
mylist2.push_back(4);
mylist2.push_back(5);
mylist2.push_back(6);
std::cout << "--" << '\n';
mylist2 = mylist1;
std::cout << "--" << '\n';
}
And here is the result:
copy container, propogate
A: 0x7ffce414af40 ptr: 0x562e4822ca30
A: 0x7ffce414af40 ptr: 0x562e4822cbf0
A: 0x7ffce414af40 ptr: 0x562e4822cc40
A: 0x7ffce414af60 ptr: 0x562e48237880
A: 0x7ffce414af60 ptr: 0x562e48233fe0
A: 0x7ffce414af60 ptr: 0x562e4822cc60
--
D: 0x7ffce414af60 ptr: 0x562e48237880
D: 0x7ffce414af60 ptr: 0x562e48233fe0
D: 0x7ffce414af60 ptr: 0x562e4822cc60
A: 0x7ffce414ae40 ptr: 0x562e4822cc60
A: 0x7ffce414ae40 ptr: 0x562e48233fe0
A: 0x7ffce414ae40 ptr: 0x562e48237880
--
D: 0x7ffce414af60 ptr: 0x562e4822cc60
D: 0x7ffce414af60 ptr: 0x562e48233fe0
D: 0x7ffce414af60 ptr: 0x562e48237880
D: 0x7ffce414af40 ptr: 0x562e4822ca30
D: 0x7ffce414af40 ptr: 0x562e4822cbf0
D: 0x7ffce414af40 ptr: 0x562e4822cc40
As can be seen, the allocator at 0x7ffce414af60 (which is the original
allocator for the second list) is used to deallocate memory from
0x7ffce414ae40, even though the allocators are not equal.
[Bug c/84888] C/C++: Improve wording of unclosed paren/brace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84888 Eric Gallager changed: What|Removed |Added Status|NEW |ASSIGNED See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=84887 --- Comment #3 from Eric Gallager --- (In reply to Eric Gallager from comment #2) > (In reply to Eric Gallager from comment #1) > > > > As in bug 84887, I'd like a link to the reddit thread mentioned here, too > > Thread is here: > https://www.reddit.com/r/programming/comments/84oizv/usability_improvements_in_gcc_8/dvr93d4/ > Confirming on the basis that your original bug was actually a confirmation > of the linked comment. Also ASSIGNED since you're the assignee.
[Bug c++/84897] Better handling of unqualified "string"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84897 Eric Gallager changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #5 from Eric Gallager --- Changing status to ASSIGNED since there's an assignee.
[Bug c++/84898] Fix-it hints for '.' vs '->'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84898 Eric Gallager changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #3 from Eric Gallager --- assignee = ASSIGNED
[Bug c++/84916] Tweaks to template type elision
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84916 Eric Gallager changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-06-17 Ever confirmed|0 |1 --- Comment #3 from Eric Gallager --- (In reply to David Malcolm from comment #0) > In > https://www.reddit.com/r/programming/comments/84oizv/usability_improvements_in_gcc_8/dvrdyhv/ > Reddit user "Liorithiel" pointed out: > > > Have you considered performing elision conditionally on the length on the > > elided part? I see the benefits of changing, let say, > >std::map>, std::string> > > > into > >std::map<[...], std::string>, > > > but for me, > > std::map > > > is clearer than > > std::map<[...], int>. > > (see the other comments downthread from thread). > > I'm filing this reminder to take a look at tweaking this for gcc 9. Trunk is on gcc 9 now. Confirming since this originally came from someone else, and changing status to ASSIGNED since you're the assignee. > > Maybe only elide common items if there's "more than one thing" e.g. if it's > a template itself, or is multiple args?
[Bug c++/84360] unnecessary aka in error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84360
Eric Gallager changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2018-06-17
CC||egallager at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #5 from Eric Gallager ---
(In reply to Jonathan Wakely from comment #4)
> (In reply to David Malcolm from comment #3)
> > So should this ideally read:
> > return type ‘T’ {aka ‘class std::tuple’} is incomplete
> > to express both the name the code used, and the underlying type?
>
> Yes.
Confirming and changing status to ASSIGNED since David put himself as the
assignee.
[Bug c++/84917] Verbosity when dealing with nested template data structures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84917
Eric Gallager changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2018-06-17
Ever confirmed|0 |1
--- Comment #1 from Eric Gallager ---
(In reply to David Malcolm from comment #0)
> In
> https://www.reddit.com/r/programming/comments/84oizv/usability_improvements_in_gcc_8/dvsa8dw/
> Reddit user "rifeid" reports excess verbosity...
>
> > [...] when dealing with nested template data structures. For example,
>
> #include
> #include
> using vec = std::vector;
> void blah() {
> vec x;
> x.foo();
> }
>
> > results in
>
> test.cpp: In function ‘void blah()’:
> test.cpp:6:4: error: ‘using vec = class
> std::vector > {aka class
> std::vector >}’ has no member named ‘foo’
> x.foo();
> ^~~
>
> > My issues with this:
> >
> > It may look better if the error: line just uses vec, and
> > have the full expansion relegated to a note: line. Not sure.
> >
> > The expansion is printed twice.
> >
> > As std::string is part of the C++ standard, I'd prefer it unexpanded.
>
> Confirmed on godbolt.org.
So, confirmed then. And ASSIGNED as with other bugs.
>
> I think parts of these are a dup (maybe of PR c++/84360) but it seems worth
> capturing here and fixing.
[Bug other/26061] error and warning count
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26061 Eric Gallager changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #22 from Eric Gallager --- Changing status to ASSIGNED since David Malcolm put himself as the assignee.
[Bug c++/86190] New: -Wsign-conversion ignores explicit conversion in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86190
Bug ID: 86190
Summary: -Wsign-conversion ignores explicit conversion in some
cases
Product: gcc
Version: 8.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: woodroof at gmail dot com
Target Milestone: ---
Created attachment 44289
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44289&action=edit
Preprocessed source file
Affected versions:
g++ (Ubuntu 8-20180414-1ubuntu2) 8.0.1 20180414 (experimental) [trunk revision
259383]
g++-7 (Ubuntu 7.3.0-16ubuntu3) 7.3.0
Command line:
g++ -Wsign-conversion -c 1.cpp
Output:
1.cpp: In member function ‘bool A::func()’:
1.cpp:10:23: warning: conversion to ‘std::vector::size_type’ {aka ‘long
unsigned int’} from ‘int’ may change the sign of the result [-Wsign-conversion]
return vec.size() < static_cast(var);
^~~~
