[Bug c++/54665] New: [C++11] template alias to template does not work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54665
Bug #: 54665
Summary: [C++11] template alias to template does not work
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mw_tr...@users.sourceforge.net
Template aliases, as described in N2258[1], are not fully implemented.
Specifically, they do not work if the type being aliased is itself a template.
Simple test case (taken from Wikipedia[2]):
template
class SomeType;
class OtherType;
template
using TypedefName = typename SomeType;
int main()
{
return 0;
}
This fails to compile with the error:
$ gcc -std=c++11 template-alias.cpp
template-alias.cpp:6:30: error: expected nested-name-specifier
[1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2258.pdf
[2] http://en.wikipedia.org/wiki/C++11#Alias_templates
[Bug c++/52718] -Wzero-as-null-pointer-constant: misleading location for 0 as default argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52718 Matthew Woehlke changed: What|Removed |Added CC||mw_triad at users dot ||sourceforge.net --- Comment #10 from Matthew Woehlke 2012-11-01 00:38:20 UTC --- This is not fixed (gcc 4.7.2) if the default parameter occurs in a system header. In such case, I would expect no warning at all. Instead, I get the old and confusing behavior of gcc warning at the point where the default parameter is used.
[Bug c++/52718] -Wzero-as-null-pointer-constant: misleading location for 0 as default argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52718
--- Comment #12 from Matthew Woehlke
2012-11-01 17:47:04 UTC ---
Requires qt-devel installed, but has the benefit of being the exact issue I'm
having in production (on the chance it's something screwy about Qt...):
$ cat zero-as-pointer.cpp
#include
int main()
{
QLabel label;
return 0;
}
$ g++ -std=c++11 -Werror=zero-as-null-pointer-constant zero-as-pointer.cpp
zero-as-pointer.cpp: In function ‘int main()’:
zero-as-pointer.cpp:5:10: error: zero as null pointer constant
[-Werror=zero-as-null-pointer-constant]
cc1plus: some warnings being treated as errors
Exit 1
$ g++ --version
g++ (GCC) 4.7.2 20120921 (Red Hat 4.7.2-2)
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
...maybe it got fixed in 4.7.3?
Note: the problem is this ctor:
explicit QLabel(QWidget *parent=0, Qt::WindowFlags f=0);
If I replace my declaration with:
QLabel label(nullptr, Qt::WindowFlags(nullptr));
...then I get no warning.
[Bug c++/52718] -Wzero-as-null-pointer-constant: misleading location for 0 as default argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52718
--- Comment #13 from Matthew Woehlke
2012-11-01 17:56:49 UTC ---
...and with your example I do indeed get no warning.
Simplified test case:
$ cat zero-as-pointer.h
#pragma GCC system_header
class Foo
{
public:
Foo(void** = 0);
};
class Bar
{
public:
Bar(Foo = 0);
};
$ cat zero-as-pointer.cpp
#include "zero-as-pointer.h"
int main()
{
Bar bar;
return 0;
}
$ g++ -std=c++11 -Werror=zero-as-null-pointer-constant zero-as-pointer.cpp
zero-as-pointer.cpp: In function ‘int main()’:
zero-as-pointer.cpp:5:7: error: zero as null pointer constant
[-Werror=zero-as-null-pointer-constant]
cc1plus: some warnings being treated as errors
Apparently it is something about the 'Foo = 0' part (replace Foo with
Qt::WindowFlags in my 'real' example).
[Bug c++/55173] New: GCC gives wrong location, and ignores -isystem, when warning about default arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55173
Bug #: 55173
Summary: GCC gives wrong location, and ignores -isystem, when
warning about default arguments
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mw_tr...@users.sourceforge.net
This came up originally related to bug 52718, but according to Paolo there, is
not actually related at all...
Consider the following header:
#pragma GCC system_header // or include via -isystem
class Foo
{
Foo(void* = 0);
};
class Bar
{
Bar(Foo = 0, void* = 0)
};
The following instantiation:
Bar bar;
...trips -Wzero-as-null-pointer-constant (also, the warning is reported in the
source file, not the header).
This appears to only happen when a default parameter implicitly invokes a
constructor, where the warning occurs in the constructor invocation. IOW, this:
Bar bar(nullptr);
...does not trigger a warning, as 'Foo(nullptr)' is okay.
Besides the less-helpful-than-desired diagnostic, this behavior is unfortunate,
as it prevents promoting warnings to errors in the face of such constructs, or
else forcing programmers to avoid use of default parameters.
[Bug c++/52718] -Wzero-as-null-pointer-constant: misleading location for 0 as default argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52718 --- Comment #19 from Matthew Woehlke 2012-11-01 23:04:42 UTC --- Reported as bug 55173. I'm not going to claim to understand bug 43486 sufficiently to know it is the same issue, but if you are sure, please feel free to close as duplicate.
[Bug c++/59624] New: bizarre warning about 'assigned but unused parameter' in ctor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59624
Bug ID: 59624
Summary: bizarre warning about 'assigned but unused parameter'
in ctor
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mw_triad at users dot sourceforge.net
Created attachment 31538
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31538&action=edit
SSCCE showing the bug
Consider the following code:
// foo is a class, rc is an enum class
foo::foo(rc c) : v{static_cast(c)} {}
g++ with -std=c++11 -Wall -Wextra warns:
foo.cpp:8:3: warning: parameter ‘c’ set but not used
[-Wunused-but-set-parameter]
...but there is no assignment occurring?!
I suspect under the covers this is due to C++ DR1288 (i.e. see bug #50025 of
which this is possibly either a duplicate or just goes away if that is fixed,
but will let someone else make that call), but for otherwise-warning-free code
it's quite obnoxious, as there does not appear to be anything wrong with the
code.
Goes away if ()'s are used instead of {}'s for the initialization.
(Full SSCCE is attached.)
[Bug c++/59653] New: warn when non-const parameter or local variable is not modified
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59653 Bug ID: 59653 Summary: warn when non-const parameter or local variable is not modified Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: mw_triad at users dot sourceforge.net Some coding styles specify that local variables that are not modified should be marked 'const' in order (in theory) to allow for compiler optimization. It would be great if gcc could omit a warning for violations of this rule. I imagine this would work by setting a flag on a non-const local variable instantiation that is cleared when the variable is used in a manner that requires that is not be 'const'. If the flag is not cleared when the variable goes out of scope (which presumably gcc knows, as it needs to invoke the dtor at this time if the type has one), a warning would be emitted. The same for function/method parameters, but likely as a separate warning, would also be desirable. Closely related to bug #59552; that one should probably be a different option, but the implementation is likely similar.
[Bug c++/59653] warn when non-const parameter or local variable is not modified
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59653 Matthew Woehlke changed: What|Removed |Added Severity|normal |enhancement
[Bug c++/55655] New: cannot export specialized template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55655 Bug #: 55655 Summary: cannot export specialized template Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: mw_tr...@users.sourceforge.net Let us say I have a generic template class, e.g. my_smart_ptr. Let us also say I have a class 'foo', 'clas foo : public my_smart_ptr' that is part of some library public API. And last, let us say that 'foo' needs to specialize 'my_smart_ptr'. As far as I can tell, it is impossible to export this instantiation with proper symbol visibility in this configuration. I do NOT want to make all possible instantiations of my_smart_ptr have default visibility (someone, somewhere may have an instantiation that should have hidden visibility). I need to do two things, but they are mutually contradictory: 1. I need to explicitly instantiate the template in order to give it default visibility. However, if I do this first, it prevents specialization. (I also get compiler errors for my specific use case, as generic instantiation is not possible.) 2. I need to declare specialization prior to instantiation. However, if I do this before instantiation, I cannot set default visibility on the instantiation and I get link errors. I think there should be a way to do this... Right now I am forced to not export the template, requiring each user to use their own instantiation, which creates a fragile ABI.
[Bug c++/55655] cannot export specialized template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55655 --- Comment #2 from Matthew Woehlke 2012-12-11 21:06:26 UTC --- Created attachment 28930 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28930 example code Here's a simplified concrete example. Since we are talking about correct visibility, -fvisibility=hidden or #pragma equivalent is implied; otherwise, compile flags do not (AFAIK) matter.
[Bug c++/55655] cannot export specialized template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55655 --- Comment #4 from Matthew Woehlke 2012-12-11 23:34:21 UTC --- (In reply to comment #3) > Which symbols are hidden which you don't want to be? ptr > What do you mean "instantiation failed"? You get a warning but it works. It fails if you haven't declared the specialization, which is necessary to get the correct visibility of ptr. With the specialization declare, instantiation "succeeds" but with the wrong visibility.
[Bug c/7652] -Wswitch-break : Warn if a switch case falls through
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7652
--- Comment #22 from Matthew Woehlke ---
Thanks for the patch. However, one thing I am not seeing is an easy way to
suppress the warning for a specific occurrence (a la [[clang:fallthrough]]).
Can that be added also? (Or is it there and I miss something?)
Ideally this would work like:
switch (expr)
{
case A:
// empty body, no warning
case B:
...
[[gcc:fallthrough]] // suppress warning for fall-through to 'case C'
case C:
...
break;
case D:
...
// will warn here
default:
...
break;
}
[Bug c/7652] -Wswitch-break : Warn if a switch case falls through
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7652 --- Comment #27 from Matthew Woehlke --- (In reply to Marek Polacek from comment #26) > Perhaps we could invent __builtin_fallthrough or some such. Yes, I was expecting there would be some alternate spelling for cases where C++11 attributes are not available, e.g. using __attribute__ or __builtin_fallthrough or some such. Please support [[gnu:fallthrough]] also, though, for consistency with clang (and it gives more weight to eventually making [[fallthrough]] standardized).
[Bug c/7652] -Wswitch-break : Warn if a switch case falls through
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7652 --- Comment #32 from Matthew Woehlke --- (In reply to Florian Weimer from comment #30) > Does this mean that you propose a GCC extension which allows to write this? > > goto 5; >case 5: While I personally detest this syntax :-), I feel that I should note that there is a proposal to add e.g. 'goto case 5' to C++17. (Note that I'm not sure if it's even an official proposal yet, though, just that it's been brought up on std-proposals.) (*I* much prefer __builting_fallthrough() or some such...)
[Bug c++/43486] Preserve variable-use locations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43486 --- Comment #8 from Matthew Woehlke --- Can this *please* get fixed? This really hurts the ability to use -Wzero-as-null-ptr in particular. See https://bugreports.qt.io/browse/QTBUG-45291 for an example of the pain this causes.
[Bug c++/60135] New: add option to warn if ctor/conversion declared implicit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60135 Bug ID: 60135 Summary: add option to warn if ctor/conversion declared implicit Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: mw_triad at users dot sourceforge.net "explicit" is a great tool for avoiding mistakes in the use of a class. Unfortunately, programmers must remember to use it, and there is not presently a mechanism to diagnose failure to do so. I would like to request that g++ add (1) a warning if a constructor or conversion operator is not declared "explicit", and (2) some mechanism (e.g. an attribute) to silence this warning for a particular declaration, i.e. to annotate that a constructor or conversion operator is intended to be implicit. This would help to prevent forgetting to make such "explicit" when implicit behavior is not desired.
[Bug libstdc++/64399] New: g++ does not diagnose when upcasting owning pointer (e.g. unique_ptr) with non-virtual destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64399
Bug ID: 64399
Summary: g++ does not diagnose when upcasting owning pointer
(e.g. unique_ptr) with non-virtual destructor
Product: gcc
Version: 4.8.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: mw_triad at users dot sourceforge.net
Consider the following code:
#include
struct X { ~X(); };
struct Y : X { ~Y(); };
std::unique_ptr f();
void g()
{
std::unique_ptr x = f();
}
This code is almost certainly broken; ownership of the constructed Y is
transferred to an owning unique_ptr in a way that will most likely (in general;
"always" in this specific example) result in Y's destructor never being called.
It seems pretty silly that there is no diagnostic for this. There ought to be a
warning in unique_ptr's conversion operator converting from Derived to Base if
~Base is not virtual. (Arranging at the library level to trip
-Wnon-virtual-dtor seems logical.)
[Bug libstdc++/64399] g++ does not diagnose when upcasting owning pointer (e.g. unique_ptr) with non-virtual destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64399 --- Comment #2 from Matthew Woehlke --- (In reply to Jonathan Wakely from comment #1) > PR 58876 *Almost*, except I am proposing that -Wnon-virtual-dtor should trip even if X does not otherwise have virtual methods. (Just why you'd be writing such code, I'm not sure, but...) Odd that didn't turn up in my search for existing bugs...
[Bug libstdc++/58876] No non-virtual-dtor warning in std::unique_ptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58876
Matthew Woehlke changed:
What|Removed |Added
CC||mw_triad at users dot
sourceforge.
||net
--- Comment #5 from Matthew Woehlke ---
See also bug 64399, which proposes that a) the conversion itself should
generate a warning, and b) the presence of other virtual methods in A should
not be required for the warning to trip. (This could be achieved by something
like static_assert except to emit a warning, combined with
std::has_virtual_destructor, without otherwise having to fiddle with pragmas.)
Actually, this may be required for 'make_unique(new B)' to warn, since the
conversion of a B* ('new B') to an A* (which is what is passed to make_unique /
unique_ptr::unique_ptr) should not warn. (IOW, unique_ptr / make_unique would
need overloads taking any pointer type and doing the conversion inside STL so
that std::has_virtual_destructor can be checked against the actual pointer
type.)
...or alternatively gcc would need to detect when a converted pointer is passed
to unique_ptr / make_unique, which seems like it would be harder.
[Bug libstdc++/64399] g++ does not diagnose when upcasting owning pointer (e.g. unique_ptr) with non-virtual destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64399 --- Comment #7 from Matthew Woehlke --- (In reply to Thiago Macieira from comment #3) > Because it's not a bug. > > This is a totally valid scenario. Valid in what way? I constructed a Y but arranged, probably by accident, that its dtor is never called. I fail to see how that's not likely a bug in my code that reasonably warrants a diagnostic. (Note that I'm talking about a *warning*, and possibly one that isn't even on by default, not an error.) (In reply to Marc Glisse from comment #6) > It might pedantically be illegal, but it is useful, and I believe some people > would like to avoid the warning when the two destructors are equivalent. However, the compiler doesn't know that here, because I didn't provided a definition thereof; Y's dtor, even in this example, could have important side effects. Even if the compiler *can* prove equivalence, I'd be suspicious whether this was intended, but I'd be okay with a different (i.e. more pedantic) warning in that case. (I'd also point out that it's not unreasonable to require the user to somehow annotate if this is intentional if they care about avoiding the warning when it's enabled.) Anyway, I still get no warning if Y has members that need to be destroyed, which definitely causes bad behavior when its dtor isn't called.
[Bug libstdc++/58876] No non-virtual-dtor warning in std::unique_ptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58876 --- Comment #7 from Matthew Woehlke --- (In reply to Jonathan Wakely from comment #6) > (In reply to Matthew Woehlke from comment #5) > > Actually, this may be required for 'make_unique(new B)' to warn, since > > That's not how make_unique works. ...and I'm suggesting it *should* be. (How else are you going to warn? After that executes, the pointer no longer knows that it really contains a B, unless you teach the compiler some fancy extra tricks, which seems overly complicated. Conversely, I feel that 'make_unique(new B)' should warn if it's going to result in failing to call B's dtor. I might even go so far as to say 'even if the compiler can prove that B's dtor is trivial', though I'd be willing to delegate that to a different and more pedantic warning.)
[Bug libstdc++/58876] No non-virtual-dtor warning in std::unique_ptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58876 --- Comment #9 from Matthew Woehlke --- (In reply to Jonathan Wakely from comment #8) > No, really, that's not how make_unique works. You do not use 'new' with > make_unique, that's the whole point [...] D'oh, sorry :-). Not sure what I was thinking. I think I meant 'unique_ptr(new B)', like to the original example. That said... > unique_ptr p = make_unique(); ...this is also a good example that I would like to see warn. (I think this has the same problems; the warning would need to trigger in the conversion operator, otherwise the knowledge of the true type is lost by the time the unique_ptr is destroyed.)
[Bug libquadmath/119397] New: missing license file for SunPro covered sources
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119397 Bug ID: 119397 Summary: missing license file for SunPro covered sources Product: gcc Version: 14.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libquadmath Assignee: unassigned at gcc dot gnu.org Reporter: mw_triad at users dot sourceforge.net Target Milestone: --- Many sources in libquadmath (and also libgo) contain the following notice: Copyright (C) 1993 by Sun Microsystems, Inc. All rights reserved. Developed at SunPro, a Sun Microsystems, Inc. business. Permission to use, copy, modify, and distribute this software is freely granted, provided that this notice is preserved. However, there is no corresponding COPYING.SunPro. This makes it difficult for distributions to comply with the license terms, and indeed makes it questionable whether any distributed binary build of GCC is in compliance without expending additional effort. While Debian does seem to expend this effort, at least packages of Red Hat apparently do not. There should be a COPYING.* for any and all license texts that are required to be included in binary distributions of any components that are part of the GCC repository.
[Bug libquadmath/119397] missing license file for SunPro covered sources
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119397 --- Comment #2 from Matthew Woehlke --- To be clear, you are arguing that distributions of the software can entirely omit the notice because the source code is not distributed? Has that been tested in court, or has Sun Microsystems affirmed this interpretation? Because that is NOT the usual understanding of what is meant by 'preserving this notice'. In fact, if that were the interpretation, the license would be practically irrelevant, which is not likely what Sun intended. Debian, at least, disagrees (see /usr/share/doc/libquadmath0/copyright). Moreover, most corporate lawyers, who typically err on the side of caution, will also disagree. Making it more difficult for users to copy the license notice into their own software which uses libquadmath is actively hostile to those same users (who happen to have said corporate lawyers looking over their shoulders). Please respect the needs of those users.
