[Bug c++/104343] New: Too many arguments error reported for a variadic-argument function if std::endl is passed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104343
Bug ID: 104343
Summary: Too many arguments error reported for a
variadic-argument function if std::endl is passed
Product: gcc
Version: 7.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ethouris at gmail dot com
Target Milestone: ---
I have the following definition (requires `` and ``):
```
template
inline Stream& Print(Stream& in) { return in;}
template
inline Stream& Print(Stream& sout, Arg1&& arg1, Args&&... args)
{
sout << arg1;
return Print(sout, args...);
}
template
inline std::string Sprint(Args&&... args)
{
std::ostringstream sout;
Print(sout, args...);
return sout.str();
}
```
The call
```
sinfo.bufferinfo = Sprint("B: off=", buffer.offset(), " now=",
FormatTime(timeinfo), endl);
```
Reports this error:
```
(5 of 13): error: too many arguments to function 'std::__cxx11::string
Sprint(Args&& ...) [with Args = {}; std::__cxx11::string =
std::__cxx11::basic_string]'
```
Replacing `endl` with `"\n"` fixes the problem.
Might be that I cannot bind `std::endl` to the argument as given here, but the
error report is at least misleading. How can there be "too many arguments"
passed to a function that gets a variable number of arguments?
[Bug c++/96266] New: Macro defined as enum in parens resolves to 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96266 Bug ID: 96266 Summary: Macro defined as enum in parens resolves to 1 Product: gcc Version: 7.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ethouris at gmail dot com Target Milestone: --- Created attachment 48906 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48906=edit Preprocessed C++ file with example. I'm attaching a quite long preprocessed file, but all "simplified examples" didn't reproduce it. I'm not even sure if this is a bug or a feature (maybe something related to resolving into `defined()` pp function), but it definitely works not according to the intention. This can also be my mistake, but if so, I'm completely unable to find it despite best efforts. In short: 1. There's an enum defined, one value is, say, `UPDATE = 0x10` 2. There's a macro defined: `#define ETONLY (UPDATE)` 3. The variable is passed as `int x = 0x11`. 4. The expression `x & ETONLY` resolves to... 1 (not 0x10). Workaround: 1. Define `ETONLY` as `(0 | UPDATE)` 2. Expression `x & int(ETONLY)` resolves correctly to 0x10. Tested on gcc 7.5 and some older, including 4.4.
[Bug c/66658] missing -Wunused-value negating a function result in a comma expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66658
Michal Malecki changed:
What|Removed |Added
CC||ethouris at gmail dot com
--- Comment #3 from Michal Malecki ---
Just caught this one, too, something like:
if (x(a, b), c)
{ ... }
Where x is declared as
int x(int a, int b, int c = -1);
There should be at least a warning that "suggested parentheses around the
expression", not necessarily with every case where the "comma operator" is
used.
[Bug c++/70163] New: C++ DR 257 constructor forward to virtual base class's constructor in an abstract class required
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70163 Bug ID: 70163 Summary: C++ DR 257 constructor forward to virtual base class's constructor in an abstract class required Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ethouris at gmail dot com Target Milestone: --- Sorry if this already passed through somehow, but there was no trace of this problem so far in gcc bugzilla and I found it in version 4.9.0. The problem can be described in short as: The constructor forwarder to the base class's constructor shouldn't be required, if the current class is abstract and the base class is virtual. This is completely described as C++ DR 257: http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#257 So, it's still working with this defect in gcc 4.9.0, also when compiling in C++11 mode. May happen that this is already fixed in some later version of gcc, then please leave appropriate information here.The clang++ compiler has this problem fixed.
[Bug c++/65448] Allow for cascade includes in error messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65448 --- Comment #2 from Michal Malecki ethouris at gmail dot com --- (In reply to Manuel López-Ibáñez from comment #1) Which tools? Shouldn't those tools be fixed instead? The problem is that it's very easy to interpret the format that every line matches: filename:line[:column]: error message This is generally understood by all tools, and it's a format that can be also easily generated. This is a simple and general rule that can be claimed across the tools and it has been used as an informal standard since always. Anything that doesn't match this format is generally treated as to be ignored or simply not a compiler error message (for example, an echoed command line from make). These lines starting with In file included from do not undergo any stable format definition and are not easy parseable, especially if we regard that the message isn't necessarily in English. Perhaps this would have been a better way to do it (although I would prefer the notes after the error, and it could just not say note:, to be consistent with what we do for template instantiations), Whatever. I just gave this as an example - at least be it something that matches the above format. if we could start over again, but now GCC has always behaved like this, So you can imagine how sick and tired some are :D Actually I'm using gcc since about 2.6 version and I cannot recall any tool that understands these In file included from messages. if we change it, it may break other tools. Should there be any - but even if, I think I spoke about having an option to change the format. I meant command-line option to change the behavior, while leaving the default behavior as is, should that not be clear enough. Just like there's for example a -fmessage-length option. BTW. If I'm not mistaken, there are more cases, when error messages from the compiler may be interesting, but they don't match the error message format and are therefore skipped by the tools.
[Bug c++/65448] New: Allow for cascade includes in error messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65448 Bug ID: 65448 Summary: Allow for cascade includes in error messages Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ethouris at gmail dot com When gcc reports a compile error that refers to a line in a file that is included by another include file, which is finally included by the *.cpp file being compiled, it reports the error more-less this way: In file included from file1.h:10:1, from file2.h:11:1, from file.cpp:9:0: file3.h:25:0: error: 'symbol' does not name a type Most tools that use these error reports simply skip the first three lines, as they do not look like standard compiler error format. It would be nice to have at least an option to change the format into something like this: file1.h:10:1: note: In file included from here, file2.h:11:1: note: from here, file.cpp:9:0: note: from here, file3.h:25:0: error: 'symbol' does not name a type Some programming mistakes are very tough to determine without the cascade include information (such as forgetting a semicolon in some declaration before an #include directive).
[Bug c++/31397] Useful compiler warning missing (virtual functions in derived classes used without 'virtual')
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31397 Michal Malecki ethouris at gmail dot com changed: What|Removed |Added CC||ethouris at gmail dot com --- Comment #15 from Michal Malecki ethouris at gmail dot com --- But it would be nice to add a warning, valid in C++11 mode only, when a method is overridden without 'override' keyword, or an overloaded method is defined, which does not override without explicit 'new'. For example, -Wimplicit-override. Additionally, if [[base_check]] has been withdrawn, the same idea can be additionally added as __attribute__((warn_implicit_override)) (or, in C++11, [[gnu::warn_implicit_override]]). I don't think forcing a 'virtual' keyword would do things any better - 'virtual' can always mean starting a new virtual method in this class, which does not override anything.
[Bug c++/52008] [Core/1495] ICE when adding partial specialization for variadic-templated structure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52008 --- Comment #14 from Michal Malecki ethouris at gmail dot com 2012-11-06 23:32:36 UTC --- (In reply to comment #13) if the DR makes it ill-formed and GCC rejects it is this FIXED? GCC rejects it by doing ICE. I don't think this is the right thing that GCC should do. My last proposal is: gcc should report error at the place where the wannabe specialization is defined (comment with line 18) with something like: 18: This template specialization does not match the template parameters\n12: of this class template. I cannot check whether gcc currently fixed to do this, so I'm sorry if this is behind the current state.
[Bug c++/52008] [Core/1495] ICE when adding partial specialization for variadic-templated structure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52008 --- Comment #16 from Michal Malecki ethouris at gmail dot com 2012-11-07 07:17:46 UTC --- (In reply to comment #15) (In reply to comment #14) GCC rejects it by doing ICE. I don't think this is the right thing that GCC should do. No it doesn't it gives an error, see comment 4. ... I'm sorry if this is behind the current state. In this below, just add #include tuple to get rid of undefined symbol errors :) t.cc:1:11: error: 'size_t' has not been declared template size_t B, typename Type1, typename... Types ^ t.cc:8:8: error: partial specialization is not more specialized than the primary template because it replaces multiple parameters with a pack expansion struct tuple_sliced0, Types... // -- line 18 ^ And that's what it should be, thanks. (Would be nice of course, if the part of the message starting from the primary template is another message assigned to the line where the primary template is defined, but this is just cosmetic :).
[Bug c++/53528] Support C++11 generalized attributes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53528
--- Comment #5 from Michal Malecki ethouris at gmail dot com 2012-07-26
20:18:36 UTC ---
Looks nice. Is that a big deal if you also make a standard [[noreturn]]
attribute simply an alias to [[gnu::noreturn]]? As far as I know the standard,
they should behave exactly the same way.
Another thing is that I think this should work, according to the standard:
void quit [[gnu::noreturn]] () { throw 0; }
And it doesn't with this patch. Of course, [[gnu::noreturn]] void quit()...
works and is more intuitive, but both are required by the standard. I guess the
difference is when you'd do this:
int quit [[noreturn]](), pass(); // pass does return!
while here both are noreturn:
[[noreturn]] int quit(), pass();
[Bug c++/53528] Support C++11 generalized attributes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53528 Michal Malecki ethouris at gmail dot com changed: What|Removed |Added CC||ethouris at gmail dot com --- Comment #2 from Michal Malecki ethouris at gmail dot com 2012-06-25 08:11:16 UTC --- If this feature is going to be used also for extended GNU attributes, it can be done via a special extension: [[gnu init_priority(200)]] [[gnu format(printf, 2, 3)]] would be same as: __attribute__ ((init_priority (200))) __attribute__ ((format(printf, 2, 3))) Some standard attributes can be also implemented as alias to existing gnu attributes, for example [[gnu noreturn]] would be the same as [[noreturn]]. Currently the only standard attributes are noreturn and carries_dependency. They don't get any arguments, so I don't think the difference to current attribute syntax matters.
[Bug c++/52008] [C++0x] ICE when adding partial specialization for variadic-templated structure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52008
--- Comment #10 from Michal Malecki ethouris at gmail dot com 2012-04-23
12:38:47 UTC ---
(In reply to comment #9)
(In reply to comment #8)
2. The code is rejected the following way: the template specialization
definition is itself rejected because due to not covered explicitly all
explicit parameters (that is, all but parameter pack) this is not considered
template specialization.
Right, because the partial specialization doesn't specialize the Type1
parameter, it is not more specialized than the primary template.
It's not the problem that it's not more specialized (because it is, as long
as we state it's correct), but rather that it's not correctly defined partial
specialization.
I have tried to find some confirmation in the C++ standard; I think the
14.5.5/4 should make things clear:
(...)
Specifically, the order of the template arguments is the sequence in which they
appear in the template parameter list.
(...)
There are no specific statements for template specializations in case of
variadic parameters. It's important because there are two theoretical
possibilities:
1. First there happens the parameter pack expansion, and then the potential
specialization is verified against the primary template. This way the
specialization can only be rejected if the resulting parameter list does not
match the primary template.
2. First the potential specialization is verified against the primary template,
and then the parameter pack is expanded. In this case the mentioned code is
invalid because the second definition cannot be considered partial
specialization of the tuple_sliced class.
By literally adhering to this rule in the standard, the #2 solution should be
taken. It would be also hard to apply #1 for templates that are also variadic
(to expand the parameter pack, it must be instantiated, and after
instantiation, specializations can no longer be considered).
So, this code should be rejected already at the place of definition of the
specialization, with the explanation, that the arguments passed to the
specialization must exactly match arguments defined in the primary template
(even if it's a parameter pack).
The only thing I have doubts of is whether this is then correct:
template class A, typename... V class X;
template class B, class C, typename... V class Xint, B, C, V...;
According to the cited rule in the standard, it's not - the only allowed would
be int, V... or C, V
You should rewrite your code the way I did, and then do something to address
the ambiguity; possibly a third partial specialization.
It's not a problem to rewrite the above code so that it works as expected:
templatebool cond, typename TypeIfSo, typename TypeIfNot
struct TypeIf { typedef TypeIfNot type; };
templatetypename TypeIfSo, typename TypeIfNot
struct TypeIftrue, TypeIfSo, TypeIfNot { typedef TypeIfSo type; };
template size_t B, typename Type1, typename... Types
struct tuple_sliced
{
typedef typename
TypeIfB==0,
tupleTypes...,
tuple_slicedB-1, Types...
::type type;
};
Important thing is that the initial code, even though incorrect, should result
in correct rejection and error report.
[Bug c++/52008] [C++0x] ICE when adding partial specialization for variadic-templated structure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52008 --- Comment #8 from Michal Malecki ethouris at gmail dot com 2012-04-21 12:06:36 UTC --- Jason, There is no better or worse specialization - the first one is a primary template, not a specialization. The example of tuple_slice1, int, int, int will just not match the specialization with first argument 0 because, simply, here the first argument is 1. I have stated that the parameter pack is itself not a type specification, just a higher level construct that will be first resolved to the actual list of arguments and only then checked for anything else. But I'm not exactly sure of that, so maybe the argument pack specification should undergo specialization rules by itself. There are, for me, only two logical methods to solve this problem: 1. The code is accepted, even though it violates the standard a bit; pedantic flags may turn it off. In particular, the specialization is treated as really a specialization because it matches the name and all tries to instantiate the primary template can be redirected to the specialization, as long as it matches the specialized argument. Both the specialization and the primary template are considered only after the argument pack is expanded, in which case both will expand to exactly the same list of arguments - so the expanded versions will have the primary-specialization relationship. 2. The code is rejected the following way: the template specialization definition is itself rejected because due to not covered explicitly all explicit parameters (that is, all but parameter pack) this is not considered template specialization. But the template specialization can only be considered invalidly defined specialization, if template parameters that are passed to the template are incorrect according to the template parameter definition in the primary template.
[Bug c++/52008] [C++0x] ICE when adding partial specialization for variadic-templated structure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52008
Michal Malecki ethouris at gmail dot com changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED |
--- Comment #5 from Michal Malecki ethouris at gmail dot com 2012-04-20
13:33:35 UTC ---
Hey, guys, not too fast.
Why do you say it's not more specialized?
The primary template contains size_t B as the first template parameter, and
the specialization puts explicit 0 in this place. According to the standard,
this IS a specialization.
Of course, it works now if you change the terminal definition into:
templatetypename Type1, typename... Types
struct tuple_sliced0, Type1, Types...
{
typedef tupleType1, Types... type;
};
But it's roughly the same - the only difference is that it doesn't manage an
interesting case of slicing to 0 (actually I should change it to 1). Whether
the specialization really matches the primary template, it should be decided
when the variadic parameters are expanded, so if this is correct, the cited one
should be correct, too.
[Bug c++/52008] New: [C++0x] ICE when adding partial specialization for variadic-templated structure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52008
Bug #: 52008
Summary: [C++0x] ICE when adding partial specialization for
variadic-templated structure
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ethou...@gmail.com
I found this with the following code:
template size_t B, typename Type1, typename... Types
struct tuple_sliced
{
typedef typename tuple_slicedB-1, Types...::type type;
};
templatetypename... Types
struct tuple_sliced0, Types... // -- line 18
{
typedef tupleTypes... type;
};
gcc 4.6 says that it's not implemented to expand Types... in the first
structure. With gcc 4.7 I got a message:
tuple.cc:18:8: internal compiler error: in process_partial_specialization, at
cp/pt.c:4398
The master declaration of tuple_sliced passes correctly - however any use of it
will result in infinite recursion when there's no terminal version.
[Bug c++/50998] [C++0x] ICE partial specialization error at cp/pt.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50998
Michal Malecki ethouris at gmail dot com changed:
What|Removed |Added
CC||ethouris at gmail dot com
--- Comment #3 from Michal Malecki ethouris at gmail dot com 2012-01-04
14:52:56 UTC ---
I found a case of similar case - different line number, so maybe it's something
else:
template size_t B, typename Type1, typename... Types
struct tuple_sliced
{
typedef typename tuple_slicedB-1, Types...::type type;
};
templatetypename... Types
struct tuple_sliced0, Types... // -- line 18
{
typedef tupleTypes... type;
};
gcc 4.6 says that it's not implemented to expand Types... in the first
structure. I got a message:
tuple.cc:18:8: internal compiler error: in process_partial_specialization, at
cp/pt.c:4398
The master declaration of tuple_sliced passes correctly - however any use of it
will result in infinite recursion when there's no terminal version.
[Bug c++/50563] New: Weird syntax acceptance rules for non-static data members initialized in place (C++0x)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50563
Bug #: 50563
Summary: Weird syntax acceptance rules for non-static data
members initialized in place (C++0x)
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ethou...@gmail.com
In the latest version it's possible to initialize data in place.
According to the standard, non-static data members can be initialized with:
int a = 0;
or
int a {0};
and not with the constructor syntax:
int a (0);
However there are probably no strict rules how the list of variables can be
initialized. I state that it should be normally allowed. Actually gcc accepts
the following syntax:
int a {10}, b {20};
as well as:
int a, b = 20;
but this one:
int a = 10, b = 20;
ends up with the following error message:
error: expected ‘;’ before ‘,’ token
I'm not completely sure, but it should be just strict rule: either the list of
variables syntax is not allowed when the variables are also initialized (so int
a,b=20; should fail too), or the list of variables syntax should be supported
as usual.
[Bug c++/48489] New: Invalid error message 'has no member named' when referring directly to the base class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48489
Summary: Invalid error message 'has no member named' when
referring directly to the base class
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ethou...@gmail.com
Created attachment 23908
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23908
Short C++ code that reproduces the problem.
There is one case, having that:
struct Base { };
struct Concrete: Base { void setValue( string, string ); };
and using:
v-BaseType::setValue( this-name, this-value );
[with template parameter BaseType = Base]
generates the following error:
newmpl.cc:37:35: error: ‘struct Concrete’ has no member named ‘setValue’
which is a lie, because Concrete::setValue exists. The mistaken here is the
name of the class that does not have given member, which should be ‘struct
Base’ here, because this call refers directly to the given class (not to the
'v' pointer's class).
Please find the reproduction example in attachment (no dependencies but C++
standard library). You can see that the 'Base' class has 'setValue' commented
out in order to make this error occur.
The same behavior is with the latest version, gcc 4.7.0.
[Bug c/31367] Should not warn about use of deprecated type in deprecated struct
--- Comment #4 from ethouris at gmail dot com 2010-05-18 07:14 ---
No matter which entity is actually affected in the example above, 'foo' is a
type of field used inside the entity. In all these cases, deprecation warning
should not be reported for the field of type 'foo'. It should be reported only
when no part of the structure definition is deprecated.
The difference between deprecating only a typedef for a structure or the
structure itself, but not its typedef, should not be seen when it concerns one
integrated declaration (that is, when you deprecate any of these two, both
the typedef and the struct are deprecated). To only deprecate the typedef or
the struct, they should be declared separately - for example, bop4/bar4 should
be declared this way:
struct bar4
{
foo baz;
};
typedef struct bar4 bop4 __attribute__((deprecated));
So, in the examples for bop1-bop4, all of barN/bopN symbols should be
deprecation-attributed (and, simultaneously, in all these declarations the
deprecation warning should not be reported for 'baz' field declaration). For
this above declaration, the compiler should issue a warning about 'baz' field,
as the structure isn't deprecated and is using a deprecated type 'foo'; so
should be reported a warning about using struct bar4 (this structure is this
way implicitly deprecated) and bop4 (which is explicitly deprecated).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31367
[Bug c++/37737] [c++0x] ICE in get_innermost_template_args at cp/pt.c:516 during variadic function overload deduction
--- Comment #7 from ethouris at gmail dot com 2009-01-27 18:33 --- Created an attachment (id=17194) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17194action=view) Preprocessed source that caused the problem The problem is reported for line 40 in msigslot.h, where a 'friend' declaration is provided (with a variadic-templated function). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37737
[Bug c++/37737] [c++0x] ICE in get_innermost_template_args at cp/pt.c:516 during variadic function overload deduction
--- Comment #8 from ethouris at gmail dot com 2009-01-27 18:35 --- I added as attachment the code that causes the same error message. Please note that this code was compiling and working correctly with the old Doug Gregor's patch, which was the first version of 'variadic template' feature. I'd suggest you check why it was working there. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37737
