[Bug c++/17314] Error message wrongly shows declared rather than inherited access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17314 --- Comment #24 from Ivan Godard --- OP here. Yes, no one would *intentionally* try to derive from a virtual private. But one could - and I did - derive a class with. It took no little wild geese chasing from the diagnostic to find that a virtual private was the real, and unreported, problem. So I filed a *UI* and *QOI* ticket. Compilers exist not only to translate correct code, but also to help with the inevitable incorrect code. After all, more of the latter gets submitted for compilation. To say that a code is nonsense and so can be ignored is a disservice to the community that gcc purports to serve. In fairness, gcc and its maintainers are much less arrogant these days than when this ticket was filed. But I notice that bugzilla shows *twenty seven* tickets filed by me and still open. Every one of those is a dozen years old or more, because around then I got fed up with the gcc attitude, switched to clang, and have never been back. Except for the occasional rant like this.
[Bug c/70779] New: -trapv does not generate trapping vode for integer conversions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70779
Bug ID: 70779
Summary: -trapv does not generate trapping vode for integer
conversions
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: igodard at pacbell dot net
Target Milestone: ---
This source:
extern int si; extern unsigned ui;
int main(int argc, char** argv) {
return argc==0?si:ui; }
compiled with this command line:
gcc -S -O3 -ftrapv src/test2.c
gets this code:
main:
.LFB0:
.cfi_startproc
testl %edi, %edi
movlui(%rip), %eax
cmove si(%rip), %eax
ret
.cfi_endproc
Note that there is no check for overflow.
[Bug c++/12672] Evals template defaults args that it should not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12672 --- Comment #11 from Ivan Godard --- OP here; better late than never :-) IANALL, but the portions of the standard cited by Jonathan all refer to argument evaluation, while the problem here is in the result type. Why is the result even being considered before argument evaluation and identification is completed?
[Bug c++/12672] Evals template defaults args that it should not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12672 --- Comment #6 from Ivan Godard --- Twelve years and counting? :-)
[Bug c++/62057] New: __builtin_offsetof works but std::offsetof doesn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62057
Bug ID: 62057
Summary: __builtin_offsetof works but std::offsetof doesn't
Product: gcc
Version: 4.6.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: igodard at pacbell dot net
This code:
#includecstddef
class A {
public:
int i;
};
int main() {
int x = __builtin_offsetof(A, i);
int j = std::offsetof(A, i);
}
gets you this:
s6:~/ootbc/genAsm$ gcc foo.cc
foo.cc: In function âint main()â:
foo.cc:10:16: error: expected unqualified-id before â__builtin_offsetofâ
foo.cc:10:16: error: expected â,â or â;â before â__builtin_offsetofâ
Version:
s6:~/ootbc/genAsm$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/gcc/4.6.4/libexec/gcc/x86_64-unknown-linux-gnu/4.6.4/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.6.4/configure --prefix=/usr/local/gcc/4.6.4
--libdir=/usr/local/gcc/4.6.4/lib64 --enable-languages=c,c++
Thread model: posix
gcc version 4.6.4 (GCC)
[Bug c++/54545] New: diagnostic overflow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54545 Bug #: 54545 Summary: diagnostic overflow Classification: Unclassified Product: gcc Version: 4.6.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: igod...@pacbell.net This code: enum class d(a,b,c}; gets you this: s3:~/ootbc/personal/ivan$ g++ -std=c++0x foo.cc foo.cc:1:1: warning: elaborated-type-specifier for a scoped enum must not use the âclassâ keyword [enabled by default] foo.cc:1:12: error: use of enum âdâ without previous declaration foo.cc:1:15: error: expected â)â before â,â token foo.cc:1:17: error: invalid type in declaration before â,â token foo.cc:1:19: error: expected initializer before â}â token foo.cc:1:19: error: expected declaration before â}â token
[Bug c++/53068] collect2 breaks link order control
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53068 --- Comment #4 from Ivan Godard igodard at pacbell dot net 2012-04-22 06:08:28 UTC --- Looking a little further at this, I don't think we can use init_array at all, even if it ran in reverse order. Consider TUs in a .a library, where some of the TUs have an order dependency with other TUs in the same library. If I understand the way init_array works (doubtful), the init_array will be populated with TUs in command line order; the assumption is that libraries at the end of the list are more primitive, and so will need to be initialized first. Or maybe the order is reversed; either way, it is determined by the command line. However, if several TUs are picked up from a single library then they will be ordered w/r/t files from a different library, but will be in random order w/r/t files from the same library. This breaks the asserted intra-library dependency. As far as I can tell from the discussion there is no way to control the init_array populating process other than priority, which as previously mentioned is unusable in a large environment with third-party binaries. Hence we need some way to force gcc to continue to use ctors instead of init_array. I find no documented option to do that - have I overlooked it, or does it not exist? Or have I misunderstood init_array (all to likely)?
[Bug c++/53068] collect2 breaks link order control
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53068 --- Comment #6 from Ivan Godard igodard at pacbell dot net 2012-04-22 07:46:20 UTC --- Yes, but. Order is not defined, but order dependencies are inescapable in C++ which has a tendency to invoke constructors where you least expect them - when you #include a file for example. The naive sometimes advocate lazy init, doing dynamic initialization in each accessor; they have never had to deal with thread convoying behind the lock in the accessor. Others advocate having an init phase where explicit calls spread out from main() and allocate (and initialize) whatever each module needs; they have never dealt with objects that must be static because new() is unavailable for hardware reasons. I'm not asking for the behavior to be defined; you are right that the language does not demand that. But we mere users need to control the undefined behavior, and so we need hooks to use for that control. Apparently a usable set of hooks just gratuitously went away. That sucks.
[Bug other/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770 Ivan Godard igodard at pacbell dot net changed: What|Removed |Added CC||igodard at pacbell dot net --- Comment #96 from Ivan Godard igodard at pacbell dot net 2012-04-22 08:01:55 UTC --- I'm a user that the switch to init_array just broke. Details are in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53068, but to summarize: Large production environment Must use other compilers too Third party binaries as well as our code. Each project represented as a .a library. Static initialization dependencies between TUs in a project (and hence within .o's in a library). Static initialization dependencies among projects. Executables link some explicit .o's with libraries from other projects, and must provide semantically correct ordering. Hence: Can't use priorities (not supported on other compilers; can't add pragmas to 3rd party code; maintaining a global absolute order over hundreds of files that change dependencies each release is a headache) Can't use init_array (no way to control ordering among files extracted from a single library) So for a decade we have manually maintained a dependency graph (relative, not absolute like priorities) and used that to put explicit commands to position .ctor sections into a linker script. That broke in 4.7. Yes, the language leaves inter-TU order unspecified. But we the users have to control that particular unspecified to get our job done. There used to be a way to exercise that control, through hooks in the linker script. You have now gratuitously taken away that control *and left nothing else to use instead*. At this point our choices appear to be to stay at 4.6 forever (or at least until the roar of complaint makes you do something), or to do our own collect2. Pretty poor.
[Bug other/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770 --- Comment #98 from Ivan Godard igodard at pacbell dot net 2012-04-22 17:44:24 UTC --- It's OK if you reverse the default order - make it sideways if it gets a faster Firefox. We can cope. It's OK is you dump ctors for init_array if it simplifies your maintenance. We don't want you to be stuck with maintaining both systems. But give us some (documented!) way to control how the init_array gets populated, for when there's something you didn't think of in your planning. Like using command line order breaks when there are intra-library order dependencies. Please. OK to re-open this ticket?
[Bug other/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770 --- Comment #101 from Ivan Godard igodard at pacbell dot net 2012-04-22 19:35:08 UTC --- Well, it's easy to say that it's the other guy's problem, but it isn't. You are assuming that the linker is always gnu ld; for big shops with multi-platform targets that's not necessarily true. We can't expect vendors of other linkers to deal with gcc decisions. Instead, may I suggest that the problem is in collect2, which is where gcc generates an init_array; the linker just includes the table in the load module, unchanged from what collect2 gives it. I there's another bug list separately for collect2 then please give me the URL and I'll go away and bother them instead. You used to produce a section for each init; the linker knows about sections, so we can use the linker to enforce order. You are no longer producing a section for each init, but are instead jamming them together into an anonymous opaque object that a linker cannot change (hacks in your own linker notwithstanding). So long as you are going to do the jamming yourself, we mere users need some scripting mechanism to control it. Yes, there are options to preserve the legacy behavior. Until you get tired of supporting two mechanisms, or bitrot creeps into the legacy. I have enough trouble preserving C++ as a language of choice here in this shop, without gratuitous breakage of things that in truth are not part of the standard but nevertheless are needed for a working tool.
[Bug other/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770 --- Comment #103 from Ivan Godard igodard at pacbell dot net 2012-04-22 21:52:40 UTC --- I may be just displaying my ignorance, but my understanding is that order under init_array is governed by order of pointers within the array itself, and where the pointed-to sections are in the file is irrelevant. After all, a reason for the switch was so Firefox could get the inits with fewer disk reads. So even if I can rearrange the init_array. sections nothing will change, because the order is set by the pointers and you have left me with no control over that. Not so?
[Bug c++/53068] New: collect2 breaks link order control
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53068 Bug #: 53068 Summary: collect2 breaks link order control Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: igod...@pacbell.net Created attachment 27214 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27214 generated linker script Not sure which heading collect2 goes under; placed in c++ heading by default. We use a linker script to control static initialization order. We manually maintain files that give intra- and inter-project dependencies from which a tool produces a partial ordering file that is added to each project library. Before linking, another tool collects the partial order files of all libraries referenced on the link command line to produce a global partial order for the program being linked. It then takes the default linker script that gcc uses and textually modifies it with linker commands that reflect the partial order. We then pass the modified script to gcc on the gcc linker command line, which invokes collect2 and the system linker in the normal way. For this to work we depend on the collect2 priority sort defaulting to the file order that the system gives it on the first link pass. That is, we depend on the sort being stable in the absence of program-specified priorities, which we do not use (priority is impractical for large developments that incorporate third-party binaries; our system uses local relative dependency rather than trying to maintain global absolute priority). This has worked for a decade, but breaks in 4.7. Because we are using the same linker I conclude that there have been changes in collect2, most likely the introduction of an unstable sort. I will attach a representative script generated by our system.
[Bug c++/53068] collect2 breaks link order control
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53068 --- Comment #3 from Ivan Godard igodard at pacbell dot net 2012-04-22 04:49:46 UTC --- Wow - this will break a lot of big users - we are far from the only ones who find priorities unusable. BTAIM, it appears that our choice is to use an option (there is one? what?) to force 4.7 to continue to use ctors, or to use some other option (there is one? what?) to force 4.7 to process init_array in reverse order from what it does by default. Of these two, which do you recommend as a workaround? Are there any other choices?
[Bug c++/52321] poor diagnostic of invalid cast
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52321 --- Comment #2 from Ivan Godard igodard at pacbell dot net 2012-02-21 15:30:42 UTC --- Somewhere there's an attept to coerce a to b that sees the source is a class and the target is a class and tries to see if the source is derived from target. That check fails because source is undefined, and the failure propagates out as other possible casts are tried. If you save the reason for failure your can't cast message can look at the reason. The message could expand on other possible reasons too. Just a suggestion - that's how we did it in the Mary compilers, and gave a list of the plausible reasons for failure.
[Bug c++/52321] poor diagnostic of invalid cast
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52321 --- Comment #4 from Ivan Godard igodard at pacbell dot net 2012-02-21 17:38:30 UTC --- Define an enum of reasons with success first, flop the sense of the test so that false means coercion was OK (grep to find all calls and put a ! in front of each), and return the reason enum instead of bool. The code that is reason-aware saves the enum and builds a good message; the legacy code that is not reason-aware treats the enum as a bool and works as before except for the inverted sense of the test. Maybe half an hour of work. Plausible?
[Bug c++/52321] New: poor diagnostic of invalid cast
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52321
Bug #: 52321
Summary: poor diagnostic of invalid cast
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: igod...@pacbell.net
This code:
class foo;
class bar {};
int main() {
foo* f;
bar* b = static_castbar*(f);
return 0;
}
gets you this:
s3:~/ootbc/sim$ g++ foo.cc
foo.cc: In function âint main()â:
foo.cc:5:30: error: invalid static_cast from type âfoo*â to type âbar*â
The issued diagnostic is correct but not very helpful. The real bug is that
class foo is defined (somewhere else) as class foo : public bar {...}, but the
definitions wasn't imported. A diagnostic like:
foo.cc: In function âint main()â:
foo.cc:6:3: error: invalid use of incomplete type âstruct fooâ
foo.cc:1:7: error: forward declaration of âstruct fooâ
(which is what you put out for - on an undefined) would be *much* better.
[Bug c++/52288] New: Trouble with operator?: and lambdas
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52288
Bug #: 52288
Summary: Trouble with operator?: and lambdas
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: igod...@pacbell.net
This code:
int main(int argc, char** argv) {
bool b;
void* p = b ? [argc](int i){ return i; } :
[argc](int i){ return i; };
return 0; }
gets you this:
s3:~/ootbc/personal/ivan$ g++ --std=c++0x foo.cc
foo.cc: In function âint main(int, char**)â:
foo.cc:5:28: error: no match for ternary âoperator?:â in âb ? {argc} : {argc}â
which is a poor. Meanwhile this code:
int main(int argc, char** argv) {
bool b;
void* p = b ? [argc](int i){ return i; } :
[argc](int i){ return i; };
return 0; }
gets you this:
s3:~/ootbc/personal/ivan$ g++ --std=c++0x foo.cc
foo.cc: In function âint main(int, char**)â:
foo.cc:4:42: error: taking address of temporary [-fpermissive]
foo.cc:5:29: error: taking address of temporary [-fpermissive]
foo.cc:5:29: error: conditional expression between distinct pointer types
âmain(int, char**)::lambda(int)*â and âmain(int, char**)::lambda(int)*â
lacks a cast
which is even worse.
[Bug c++/52288] Trouble with operator?: and lambdas
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52288 --- Comment #3 from Ivan Godard igodard at pacbell dot net 2012-02-17 00:00:48 UTC --- As lambdas get used more you will get this kind of report a lot. I suggest you head off a lot of nuisance by having any lambda/lambda type comparisons emit a Note: each lambda is it own unique type.
[Bug c++/52212] friend declaration doesn't see previous friend of same function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52212 --- Comment #6 from Ivan Godard igodard at pacbell dot net 2012-02-12 17:14:34 UTC --- I'll put in a report to clang. One of you guys is right- are you well enough connected to jointly figure out who it is?
[Bug c++/52212] New: friend declaration doesn't see previous friend of same function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52212
Bug #: 52212
Summary: friend declaration doesn't see previous friend of same
function
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: igod...@pacbell.net
This code:
class D {
class E{
class F{};
friend void foo1(D::E::F q);
};
friend void foo1(D::E::F q);
};
void foo1(D::E::F q) {}
int main(int argc, char** argv) { return 0; }
gets you:
foo.cc:3:9: error: âclass D::E::Fâ is private
foo.cc:6:26: error: within this context
Note that the same function was earlier made a friend of class E, and so can
see F. If you leave out the second friending, you get:
foo.cc: In function âvoid foo1(D::E::F)â:
foo.cc:2:8: error: âclass D::Eâ is private
foo.cc:9:21: error: within this context
which is correct; foo1 cannot see E without the second friend. But with both
friends foo1 should see everybody.
[Bug c++/52212] friend declaration doesn't see previous friend of same function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52212 --- Comment #1 from Ivan Godard igodard at pacbell dot net 2012-02-12 07:46:10 UTC --- p.s. FWIW, clang accepts this and Comeau does not.
[Bug c++/42356] improve list of candidates and error recovery for ambiguous call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42356 --- Comment #12 from Ivan Godard igodard at pacbell dot net 2011-10-22 15:52:54 UTC --- Manual said: g++ could also specify which ones are viable candidates, and which ones are not even viable, and for the ones not viable, explain why.
[Bug c++/42356] improve list of candidates and error recovery for ambiguous call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42356 --- Comment #16 from Ivan Godard igodard at pacbell dot net 2011-10-23 01:28:48 UTC --- (In reply to comment #15) (In reply to comment #12) Manual said: g++ could also specify which ones are viable candidates, and which ones are not even viable, and for the ones not viable, explain why. http://en.wikipedia.org/wiki/Manual http://en.wikipedia.org/wiki/Manuel Whoever said it, they were right :-)
[Bug c++/49729] New: diagnostic cascade
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49729
Summary: diagnostic cascade
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: igod...@pacbell.net
This code:
int main() {
for(int i = 0; i 10; ++i)
continue);
return 0;
}
got me:
s3:~/ootbc/sim$ g++ foo.cc
foo.cc: In function ‘int main()’:
foo.cc:3: error: expected ‘;’ before ‘)’ token
foo.cc:3: error: expected primary-expression before ‘)’ token
foo.cc:3: error: expected ‘;’ before ‘)’ token
I got the idea the first time :-)
[Bug libstdc++/36231] ostream includes unistd.h outside namespace std, polluting
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36231 --- Comment #16 from Ivan Godard igodard at pacbell dot net 2011-04-20 21:06:39 UTC --- Would it be possible to wrap each #include of a C file in a namespace, adjusting the references from the C++ library accordingly? The namespace to be used could be shared by all such #includes. Of course, there would have to be some cleverness to finesse the guard macros on the .h files so the user could have both the namespaced indirect inclusion and also an explicit direct inclusion if desired. As far as I've checked, the inclusions appear to be for typedefs and sizes and not for actual functions or data, for which the double inclusion approach might cause trouble.
[Bug libstdc++/36231] ostream includes unistd.h outside namespace std, polluting
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36231 --- Comment #19 from Ivan Godard igodard at pacbell dot net 2011-04-21 00:22:08 UTC --- I notice that Bugzilla is carrying this as enhancement and unconfirmed. Seems odd :-)
[Bug c++/45963] New: inconsistent and poor array initialization diagnostic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45963
Summary: inconsistent and poor array initialization diagnostic
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: igod...@pacbell.net
This code:
class foo {
public:
foo(int i): i(i) {}
foo() : i(0) {}
int i;
};
class bar {
public:
bar() : a(1) {}
bar(bool) : b(1) {}
bar(int) : b() {}
int a[5];
foo b[5];
};
int main() {
return 0;
}
gets you this:
s3:~/ootbc/members$ g++ foo.cc
foo.cc: In constructor ‘bar::bar()’:
foo.cc:9: error: incompatible types in assignment of ‘int’ to ‘int [5]’
foo.cc: In constructor ‘bar::bar(bool)’:
foo.cc:10: error: bad array initializer
In contrast, Comeau gives:
ComeauTest.c, line 9: error: only () is allowed as initializer for array
member
bar::a
bar() : a(0) {}
^
ComeauTest.c, line 10: error: only () is allowed as initializer for array
member
bar::b
bar(bool) : b(0) {}
^
[Bug c++/45437] Loses reference during update
--- Comment #14 from igodard at pacbell dot net 2010-08-31 02:20 --- Reopened, based on following communication from Clark Nelson + In one interpretation, it means the rvalue evaluation of b and f(); in this interpretation the ordering of the operand evaluations is undefined and hence the value of b at and after the assignment is also undefined. It is unclear how the assignment receives an lvalue to assign to in this interpretation. I don't see how this interpretation is viable. As you point out, if you evaluate the LHS as an rvalue, there's no way to do the assignment. In the second interpretation, it means the lvalue evaluation of b and the rvalue evaluation of f(); in this interpretation the lvalue-to-rvalue conversion of b takes place within the assignment, so consequently f() must be evaluated before the conversion takes place. Hence, the assignment receives the (lvalue) b with a well-defined rvalue of true, and the value after the assignment is also well-defined and true. I agree with this. (Except the part where you describe lvalue-to-rvalue conversion of b happening within the assignment. That conversion doesn't actually happen at all. Not that that matters to the conclusion.) I looked at the discussion in the bug. The issue has nothing to do with whether the evaluation of |= acts like a function call (which of course it doesn't). Instead, it has to do with whether the evaluation of |= is allowed to overlap with the execution of f. Even before the turn of the century, function calls were described as having sequence points at their beginning and end, and that was always intended to be interpreted as disallowing overlapping execution between caller and callee. But under the new formulation, the non-overlapping requirement is stated even more clearly. In C++, see 5.17p1: With respect to an indeterminately-sequenced function call, the operation of a compound assignment is a single evaluation. In other words, it is not allowed to implement |= by fetching b, then calling f, evaluating the result of |, and storing that result. The evaluation of |= has to happen either entirely before or entirely after the execution of the called function, and in this case it clearly can't happen before. So this code has perfectly well-defined behavior, and it's what Ivan expects. Now, all that being said, the new rules were intended primarily just to be a clearer formulation of what the old rules always were. It could be argued that this is just a substantive clarification of the old rules. But, for example, I didn't put it in of my own initiative; I was specifically asked to make things work this way. Clark -- igodard at pacbell dot net changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45437
[Bug c++/45437] Loses reference during update
--- Comment #10 from igodard at pacbell dot net 2010-08-29 18:00 --- I agree that Nelson's proposal (in particular 5.17p1 -assignment and compound assignment operators) defines the ordering as: - evaluation of operands - assignment - evaluation of assignment expression i.e. evaluating result of (a|=b) for use in another expression However you beg the question because you assume that evaluation of operands means evaluation of rvalues derived from the operands. It does not; it means evaluation of an lvalue (i.e. a reference) and an rvalue respectively, because otherwise the assignment would not have an lvalue to assign to. Hence the function f() must be called before |= (the assignment) is performed. I have left the report as Resolved Invalid because I'm sure that you are sick of me reopening it. However, that there is such a disagreement on the language semantics suggests that Nelson's wording is unclear at best and ambiguous at worse, and I have sent him a note to that effect. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45437
[Bug c++/45437] Loses reference during update
--- Comment #11 from igodard at pacbell dot net 2010-08-29 18:24 ---
Note to Nelson, for the record here:
There is a disagreement about C++ sequence semantics happening in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45437
The gist is the following code:
bool b = false;
bool f() { b = true; return false; }
b |= f();
The question is whether this is well defined (with b having the value true
after the assignment) or undefined. Your proposal states:
5.17p1 (assignment and compound assignment operators):
The assignment operator (=) and the compound assignment operators all group
right-to-left. All require a modifiable lvalue as their left operand and return
an lvalue with the type and value of the left operand after the assignment has
taken place an lvalue referring to the left operand. The result in all cases is
a bit-field if the left operand is a bit-field. In all cases, the assignment is
sequenced after the value computation of the right and left operands, and
before the value computation of the assignment expression. With respect to an
indeterminately-sequenced function call, the operation of a compound assignment
is a single evaluation. [ Note: Therefore, a function call shall not intervene
between the lvalue-to-rvalue conversion and the side effect associated with any
single compound assignment operator. end note ]
All agree that this governs; the question is what the value computation of the
right and left operands of the |= assignment means.
In one interpretation, it means the rvalue evaluation of b and f(); in this
interpretation the ordering of the operand evaluations is undefined and hence
the value of b at and after the assignment is also undefined. It is unclear how
the assignment receives an lvalue to assign to in this interpretation.
In the second interpretation, it means the lvalue evaluation of b and the
rvalue evaluation of f(); in this interpretation the lvalue-to-rvalue
conversion of b takes place within the assignment, so consequently f() must be
evaluated before the conversion takes place. Hence, the assignment receives the
(lvalue) b with a well-defined rvalue of true, and the value after the
assignment is also well-defined and true.
Whichever of these interpretations you had intended, the extent of the
disagreement suggests that the proposed wording, while fine for simple
assignment, might be clarified for the compound assignment operators.
Respectfully,
Ivan Godard
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45437
[Bug c++/45437] Loses reference during update
--- Comment #6 from igodard at pacbell dot net 2010-08-28 17:49 --- Thank you. Don't know about C, but this is C++ in which operators are function. BTW, even in C the standard goes to some lengths in places to make things that look like functions but have odd semantics be defined as macros so as to avoid the semantic guarantees. If the standard says that C++ argument evaluation semantics is different for the arguments of a pre-defined function vs the arguments of a user-declared overload of the same function then this report is invalid. And I would be very surprised :-) Is Gabe still with you guys? I'd guess he'd know. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45437
[Bug c++/45437] New: Loses reference during update
This code:
#include iostream
struct s{
s(bool bb) : i(0), b(bb), j(0) {}
int i;
bool b;
int j;
};
boolf(s s1, s s2, s s3, int k) {
s3.b = true;
return false;
}
int main() {
bool bz = false;
s sz(bz);
sz.b |= f(sz, sz, sz, 3);
std::cerr sz.b \n;;
return 0;
}
prints this:
s3:~/ootbc$ g++ foo.cc
s3:~/ootbc$ a.out
0
It appears that a |= f() is being compiled as if it were the same as a = a |
F, with the compiler free to order the evaluation of a and f() in a | f() in
any way it pleases. The order is exposed when f() has a side effect on a.
However, my understanding of a |= f() is that it must be evaluated as if it
were:
bool c = a;
bool d = f();
operator|=(c, d)
That is, the first argument to |= is a reference, not a value. Thus, both
arguments (the reference and the function call) must be evaluated *before* |=
is called and the reference will have already seen the side effect before |=.
--
Summary: Loses reference during update
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45437
[Bug c++/45437] Loses reference during update
--- Comment #2 from igodard at pacbell dot net 2010-08-28 04:11 --- No it must be evaluated as if it was: operator|=(a, f()) Exactly. The arguments (a and f()) must be evaluated to their parameter types (bool and bool) before the call to |=. There *is* a sequence point; it's the call of |=, and the compiler is not permitted to move the side effect of f() into the body of |=, nor is it permitted to dereference a before the call. To quote Wikipedia: A sequence point in C or C++ is ... Before a function is entered in a function call. The order in which the arguments are evaluated is not specified, but this sequence point means that all of their side effects are complete before the function is entered. citing 1998 standard section 1.9, paragraphs 1618. Please consult your colleagues on this. -- igodard at pacbell dot net changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45437
[Bug c++/45437] Loses reference during update
--- Comment #4 from igodard at pacbell dot net 2010-08-28 04:32 ---
Yes, I understand that the comma is not a sequence point, and a may be
evaluated (to a) in any order w/r/t f() (to bool). But it is not legal to
evaluate a to bool before the call of |=, because |= takes empbool/emp,
not empbool/emp.
If you still don't get my point here please check with someone else. This isn't
the usual side-effect idiocy that you usually get. :-)
Suppose we have:
void g(bool bref, bool b) { std::cerr bref \n; }
bool val = false;
bool f(bool bf) { bf = true; return false; }
g(val, f(val));
you would agree that the language requires that f be called before g and it
prints true because val is never dereferenced as an argument, yes?
--
igodard at pacbell dot net changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45437
[Bug c++/45064] New: friends of nested classes don't see outer classes
This code:
class f1 {
class f2 {
class f3;
friend
void bar(f1::f2::f3 arg);
class f3 {};
};
};
voidbar(f1::f2::f3 arg) {}
gets you:
foo.cc: In function void bar(f1::f2::f3):
foo.cc:2: error: class f1::f2 is private
foo.cc:9: error: within this context
If I change it to:
class f1 {
friend
void bar(f1::f2::f3 arg);
class f2 {
class f3;
class f3 {};
};
};
voidbar(f1::f2::f3 arg) {}
I of course get:
foo.cc:4: error: f1::f2::f3 has not been declared
foo.cc: In function void bar(f1::f2::f3):
foo.cc:5: error: class f1::f2 is private
foo.cc:10: error: within this context
foo.cc:7: error: class f1::f2::f3 is private
foo.cc:10: error: within this context
Changing the friend to:
friend
void ::bar(f1::f2::f3 arg);
doesn't change anything.
Seems to me that a friend of an inner class should see anything that class can
see, including outer classes. The friend declaration might be expecting that
bar is a member function of f1, but explicit ::bar to tell the compiler that
it's global doesn't work either.
Is this a bug or have I found another language feature?
--
Summary: friends of nested classes don't see outer classes
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45064
[Bug c++/44579] New: Extern doesn work for const arrays
Given file foo.cc:
const
int arr[] = {0};
compiled to foo.o, and file bar.cc:
extern
const
int arr[];
int main() {
return arr[0];
}
compiled and linked with foo.o, you get:
s3:~/ootbc/personal/ivan$ g++ bar.cc foo.o
/tmp/ccsMPoJa.o: In function `main':
bar.cc:(.text+0x6): undefined reference to `arr'
collect2: ld returned 1 exit status
It works if the array isn't const.
--
Summary: Extern doesn work for const arrays
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44579
[Bug c++/20313] poor diagnostic
--- Comment #4 from igodard at pacbell dot net 2010-06-06 00:50 --- Wow - a blast from the past! FWIW, I still think that the anonymous is confusing. That 4.6 drops one of the messages is an improvement though... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20313
[Bug libstdc++/36231] ostream includes unistd.h outside namespace std, polluting
--- Comment #9 from igodard at pacbell dot net 2010-04-30 14:24 --- This is not a fault of POSIX, because I'm *not* using POSIX. I'm using C++ ostream. Because I'm not using POSIX I expect to be able to declare (for example) int open = 0; without a problem - open is not a reserved key word and I'm not #including anything that is *defined* to transitively include a POSIX header. According to my reading of the standard, all standard libraries must export only the names defined by the standard, and any other names they need must be guarded by leading underscores or be within a similarly guarded namespace that has not been opened by using. My report says that gcc violates that standard, because it gratuitously dumps POSIX names into my global space. Of course, I may be wrong in my interpretation of the standard - I have been many times before :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36231
[Bug libstdc++/36231] ostream includes unistd.h outside namespace std, polluting
--- Comment #3 from igodard at pacbell dot net 2010-04-29 23:35 --- Reopened, because comment#2 mistakes the problem. I don't want to get anything included into namespace std. However, I also do not want tyo get C header names imported into my application's global space merely because I included a C++ header. The correct solution to this is for the C++ library to not transitively include any C headers. If the C++ facility requires access to a C library function then the access can be hidden behind an adapter function in the C++ library. It is commonly assumed that applications will mix-and-match both C and C++ in one program, but some of us are trying to write only in C++ and don't want to be polluted. -- igodard at pacbell dot net changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|WONTFIX | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36231
[Bug libstdc++/36231] ostream includes unistd.h outside namespace std, polluting
--- Comment #6 from igodard at pacbell dot net 2010-04-30 05:28 --- I guess I'm still not being clear. I'm not using *any* of those names; I'm not using C; I'm not using POSIX. I'm only using ostream, which is a plain old C++ library, but when I include ostream I'm getting C library functions like open() - not C++ open, C open() - added to my global space, where they conflict with application identifiers. Including a C++ include file should not cause any identifiers from the C or POSIX to be gratuitously added to the the user's global space. This is a bug. Please check with your colleagues if you still do not understand the problem. Andrew says 4.3 has fixed this; if so it can be closed FIXED, if verified. But closing it WONTFIX is wrong. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36231
[Bug c++/43285] typeof doesn't act like a type in ::
--- Comment #3 from igodard at pacbell dot net 2010-03-08 15:37 --- You sure that you want to ban this? Looks like you'll just have to unban it again. From http://en.wikipedia.org/wiki/Decltype: In December 2008, a concern was raised to the committee by Jaakko Järvi over the inability to use decltype to form a qualified-id,[13] which is inconsistent with the intent that decltype(e) should be treated as if it were a typedef-name.[14] While commenting on the formal Committee Draft for C++0x, the Japanese ISO member body noted that a scope operator(::) cannot be applied to decltype, but it should be. It would be useful in the case to obtain member type(nested-type) from an instance as follows:[15] vectorint v; decltype(v)::value_type i = 0; // int i = 0; In September 2009, Daveed Vandevoorde proposed a wording change to correct the issue.[16] The solution involved adding a decltype-specifier to the list of allowed nested-name-specifiers, and changing the wording to emphasize that a nested-name-specifier denotes a class rather than naming it.[16] -- igodard at pacbell dot net changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43285
[Bug c++/43285] New: typeof doesn't act like a type in ::
This code:
struct foo { typedef int f; };
int main() {
foo g;
typeof(g)::f bar;
typedef
typeof(g) h;
h::f baz;
return 0;
}
gets:
s3:~/ootbc/personal/ivan$ g++ foo.cc
foo.cc: In function int main():
foo.cc:4: error: expected initializer before bar
--
Summary: typeof doesn't act like a type in ::
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43285
[Bug c++/41970] use of a type with no linkage to declare a variable with linkage
--- Comment #15 from igodard at pacbell dot net 2010-01-12 01:12 --- Should I submit a second report so there is one for accepts invalid and a different one for diagnostic quality? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41970
[Bug c++/41970] Unjustified anonymous type warning
--- Comment #9 from igodard at pacbell dot net 2010-01-10 22:23 ---
Comeau gives this diagnostic:
ComeauTest.c, line 1: error: use of a type with no linkage to declare a
variable
with linkage
enum {a, b, c} A = a;
^
This message give the true nature of the problem, whereas the gcc message:
foo.cc:1: warning: non-local variable anonymous enum A uses anonymous
type
requires six posts from experts to explain.
Please recategorize this report as diagnostic quality, confirm, and assign
it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41970
[Bug c++/42356] confused compiler
--- Comment #5 from igodard at pacbell dot net 2009-12-14 14:58 --- There's no question that there was an error here. The report is on the diagnostic. I'm sorry if I hadn't made that clear. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42356
[Bug c++/42356] confused compiler
--- Comment #2 from igodard at pacbell dot net 2009-12-14 04:51 --- Well, I see several issues with the diagnostics. 1) The call is not ambiguous, because if it were (only) ambiguous then removing the base baz would disambiguate. Instead the case without baz gets you: s3:~/ootbc/memspec$ g++ foo.cc foo.cc: In function int main(): foo.cc:27: error: no matching function for call to foo::newNode() That is, a call cannot be both ambiguous and have no matching function. 2) The reported list of overloads include those which have the wrong number of arguments. 3) The diagnostic contains freeList::newNode(U, V) [with U = U, V = V, T = bar] as the call citation, which makes it look like the local U matches a (non-existent in this case) global U and local V matches a global V, the way that local T matches global bar. Perhaps it could say something like freeList::newNode(U, V) [with U = ?, V = ?, T = bar] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42356
[Bug c++/42356] New: confused compiler
This code:
templatetypename T
class freeList {
public:
T* newNode() { return 0; }
templatetypename U
T* newNode(U u) { return newNode()-init(u); }
templatetypename U, typename V
T* newNode(U u, V v) { return newNode()-init(u, v); }
};
class bar {};
class baz {};
class foo : public freeListbar, public freeListbaz { };
int main() {
foo f;
bar*b = f.newNodebar();
}
gets you:
s3:~/ootbc/memspec$ g++ foo.cc
foo.cc: In function int main():
foo.cc:17: error: request for member newNode is ambiguous
foo.cc:8: error: candidates are: templateclass U, class V T*
freeList::newNode(U, V) [with U = U, V = V, T = baz]
foo.cc:6: error: candidates are: templateclass U T* freeList::newNode(U)
[with U = U, T = baz]
foo.cc:4: error: candidates are: T* freeListT::newNode() [with T = baz]
foo.cc:8: error: templateclass U, class V T*
freeList::newNode(U, V) [with U = U, V = V, T = bar]
foo.cc:6: error: templateclass U T* freeList::newNode(U)
[with U = U, T = bar]
foo.cc:4: error: T* freeListT::newNode() [with T = bar]
foo.cc:17: error: expected primary-expression before token
foo.cc:17: error: expected primary-expression before ) token
--
Summary: confused compiler
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42356
[Bug c++/42328] rejects valid friend
--- Comment #5 from igodard at pacbell dot net 2009-12-08 15:20 ---
Both proposals befriend more than the minimum actually needed by program
semantics. The former befriends any member of freeListbar, baz, not just foo;
the latter any member of any freeList at all. In addition, the former requires
that bar be a resolved type. Bar is resolved in the simplified example I
submitted, but in the original baz is itself a template and bar is a class
argument, and you get a diagnostic on a friend of the form of the first
suggestion. That's why the friend is a template, not just freeListbar, baz -
the original code was more like:
templatetypename U
class baz : protected freeListU, baz,
protected freeListaType, baz,
protected freeListbType, baz,
more, where all but U were resolved types
{
templatetypename T
friend
voidfreeListT, baz::foo();
body of baz
};
but was simplified for the report.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42328
[Bug c++/42328] New: rejects valid friend
This code:
templatetypename T, typename U
class freeList {
public:
void foo() {};
};
class bar {};
class baz : protected freeListbar, baz {
templatetypename T
friend
voidfreeListT, baz::foo();
};
int main() {
baz b;
return 0;
}
gets you:
s3:~/ootbc/personal/ivan$ g++ foo.cc
foo.cc:12: error: member void freeListT, baz::foo() declared as friend
before type freeListT, baz defined
FWIW, Comeau accepts it.
--
Summary: rejects valid friend
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42328
[Bug c++/42328] rejects valid friend
--- Comment #3 from igodard at pacbell dot net 2009-12-08 02:16 ---
I stand corrected about Comeau - I missed the error and only noticed the
warning. Regardless, there must be some way to solve this problem:
templatetypename T, typename U
class freeList {
public:
void foo();
};
class bar {};
class baz : protected freeListbar, baz {
voidfrob() {}
};
template
voidfreeListbar, baz::foo() { static_castbaz*(this)-frob(); }
int main() {
baz b;
return 0;
}
gets you:
s3:~/ootbc/personal/ivan$ g++ foo.cc
foo.cc: In member function void freeListT, U::foo() [with T = bar, U =
baz]:
foo.cc:14: error: freeListbar, baz is an inaccessible base of baz
I believe this diagnostic is legitimate. If I recall, in earlier versions of
the compiler (4.0.X? Don't remember) the template friend declaration in the
original report exposed the base class to the friend function and the code
(with the friend) compiled without error. Then we upgraded the compiler and it
stopped working. I thought this reflected a new bug and reported it. If in fact
the friend is invalid (just not previously caught) then fine - but then how do
you get the original cast to the base to work?
In short, if the friend declaration I wrote is illegal, how otherwise do you
turn a member function of a base class into a friend of a derived class of that
base?
I realize that helping me in my code is not your job, but any help would be
greatly appreciated. And if it is not in fact possible perhaps some of the
language mavens among you might raise the issue with the standards group,
because what I was trying is certainly a reasonable thing to want to do.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42328
[Bug libstdc++/42242] New: vector::resize unnecessarily calls null constructor
This code shows that the resize member function is calling the null constructor
even when the size does not need to be changed.
#includevector
#includeiostream
class c {
public:
c() { std::cerr c null constructor called\n; }
c(int i) : i(i) {}
int i;
};
int main() {
std::vectorcf;
f.push_back(c(0));
f.resize(1);
return 0;
}
--
Summary: vector::resize unnecessarily calls null constructor
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42242
[Bug libstdc++/42242] vector::resize could be split up into two different functions
--- Comment #9 from igodard at pacbell dot net 2009-12-01 19:02 --- FWIW, I think it is a design error in the standard. The resize function seems to be designed from an assumption that the vector type T is POD. The second argument should not be a T, it should be a constructor, so any added cells (if the resize extends the vector) are constructed in place rather than the construct-a-temp/copy-construct/destruct sequence. Or there should be no second argument and the null constructor used implicitly iff actually needed. The actual usecase (that prompted the report) used the vector as a state holder in a recursive tree walk; the resize was used to cut back the state when returning from a leaf. The null constructor is seriously non-trivial for the node type, involving considerable file activity that could fail (a file system search). The workaround was simple when the problem was discovered: have a do-nothing null constructor for the vector, with the real null constructor turned into a constructor taking a dummy argument. Of course, that wound up getting exposed into the exported interface, and required macros to hide. :-( -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42242
[Bug libstdc++/42242] vector::resize could be split up into two different functions
--- Comment #11 from igodard at pacbell dot net 2009-12-01 19:26 --- Subject: Re: vector::resize could be split up into two different functions We await r-value references with baited breath :-) chris at bubblescope dot net wrote: --- Comment #10 from chris at bubblescope dot net 2009-12-01 19:07 --- Anyway, the result of this bug is that the fix to resize() given in the latest draft of C++0x should be applied. The resulting code would only be invoked if you ask the compiler to use C++0x mode, but if care about performance you should be doing this anyway, I suspect your types may well benefit from rvalue references. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42242
[Bug c++/41050] New: Placement new not seeing base class protected functions
This code:
#includememory
class foo {
protected:
foo() {}
foo(int) {}
public:
};
class bar : public foo {
public:
bar() : foo() {
new (this) foo(5);
}
};
bar b;
gets you:
~/ootbc/sim$ g++ foo.cc
foo.cc: In constructor bar::bar():
foo.cc:5: error: foo::foo(int) is protected
foo.cc:12: error: within this context
--
Summary: Placement new not seeing base class protected functions
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41050
[Bug c++/41050] Placement new not seeing base class protected functions
--- Comment #2 from igodard at pacbell dot net 2009-08-13 02:47 --- Well, if the call is on foo then surely a foo can call; its own methods, whereas if the call is on bar then a bar should see the protected methods of its base class foo. Either way it should be visible. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41050
[Bug c++/40538] Compiler crashes while using decimal float point in a function argument
--- Comment #2 from igodard at pacbell dot net 2009-06-24 16:34 --- Probably not the same as 39131, because this ices only if the function is declared. Both the typedef and the data declaration compile OK without the function, whereas 39131 seems to ice without any use at all. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40538
[Bug c++/40127] New: Fails to identify template function with default args
This code:
templatetypename T
voidfoo(int i, void(*f)(T*) = 0, T* a = 0) {}
int main() {
foo(5);
return 0;
}
gets you:
foo.cc: In function int main():
foo.cc:5: error: no matching function for call to foo(int)
So I figured that binding required an actual type, so I tried making it
explicit in the default values:
templatetypename T
voidfoo(int i, void(*f)(T*) = static_castvoid(*)(void*)(0),
T* a = static_castvoid*(0)) {}
int main() {
foo(5);
return 0;
}
But that gets me the same error.
I'm not sure whether argument types can be bound from default arguments in the
standard, but if they can't then I should get a diagnostic at the declaration
of the template. The actual message is cryptic and unhelpful.
--
Summary: Fails to identify template function with default args
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40127
[Bug c++/12672] Evals template defaults args that it should not
--- Comment #5 from igodard at pacbell dot net 2009-04-16 17:02 --- Wow! Six years and counting! This might be my oldest outstanding bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12672
[Bug libstdc++/37811] bind1st fails on mem_fun with reference argument
--- Comment #2 from igodard at pacbell dot net 2008-10-13 15:18 --- Deprecated or not, shouldn't it work up until when it is actually removed? And forgive me, but I don't understand the relevance of DR 109 here. Perhaps you meant some other number? Lastly, if this is not a compiler issue should I file it against c++lib instead? Ivan -- igodard at pacbell dot net changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37811
[Bug libstdc++/37811] bind1st fails on mem_fun with reference argument
--- Comment #4 from igodard at pacbell dot net 2008-10-13 16:06 --- Ah - I was looking at language DR109, not library DR109. However, the correct DR says the committee approved the example reported here (and adds the fix) so gcc appears to be in error to fail it. However, there is the curious remark: Howard believes there is a flaw in this resolution. See c++std-lib-9127. We may need to reopen this issue. Unfortunately Google turns up nothing for c++std-lib-9127 except this cryptic message, and just 9127 and other variations aren't productive either. Can you tell me where to find it? -- igodard at pacbell dot net changed: What|Removed |Added CC||igodard at pacbell dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37811
[Bug libstdc++/37811] bind1st fails on mem_fun with reference argument
--- Comment #6 from igodard at pacbell dot net 2008-10-13 17:01 --- Then I'm hopelessly confused. It's clear that my report and the example in DR109 are the same problem. You say: The example in DR 109 does *not* compile if the additional operator() are not added and does when the resolution of DR 109 is implemented. That makes sense - with the addition of the overload my example will compile too. So it appears that gcc (at least 4.3.1) does *not* implement DR109. You then say, in essence, So what, it's deprecated in C++0X and there's a better solution therein, get over it. Would that I could! Unfortunately, out here in the real world some of us have legal, business, and practical mandates that *require* us to use only *officially issued* language standards, and explicitly prohibit us from using extensions, next-release features and so on. On pain of being fired, if not worse. I realize that keeping up with soon-to-be-obviated DRs is not the most professionally satisfying activity. But the fix here seems so well known and trivial that I don't understand a reluctance to put it in. However, gcc is a volunteer project and if nobody will put it in then nobody will put it in. May I suggest that the proper resolution of my report is VERIFIED - WONT FIX? Or perhaps I've again misunderstood? -- igodard at pacbell dot net changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37811
[Bug libstdc++/37811] bind1st fails on mem_fun with reference argument
--- Comment #8 from igodard at pacbell dot net 2008-10-13 17:55 --- OK, thanks for your time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37811
[Bug c++/37811] New: bind1st fails on mem_fun with reference argument
This code:
#includefunctional
class Foo {
public:
voidF(int i) {}
voidG(int i) {}
voidH(int* i) {}
};
voidbar () {
Foo f;
Foo* fs;
std::mem_fun(Foo::F);
std::mem_fun(Foo::G);
std::mem_fun(Foo::H);
std::bind1st(std::mem_fun(Foo::F), fs);
std::bind1st(std::mem_fun(Foo::G), fs);
std::bind1st(std::mem_fun(Foo::H), fs);
std::bind1st(std::mem_fun_ref(Foo::F), f);
std::bind1st(std::mem_fun_ref(Foo::G), f);
std::bind1st(std::mem_fun_ref(Foo::H), f);
}
compiles on Comeau. On gcc it gets you:
/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.3.1/../../../../include/c++/4.3.1/backward/binders.h:
In instantiation of std::binder1ststd::mem_fun1_tvoid, Foo, int :
foo.cc:16: instantiated from here
/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.3.1/../../../../include/c++/4.3.1/backward/binders.h:120:
error: typename _Operation::result_type
std::binder1st_Operation::operator()(typename
_Operation::second_argument_type) const [with _Operation =
std::mem_fun1_tvoid, Foo, int] cannot be overloaded
/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.3.1/../../../../include/c++/4.3.1/backward/binders.h:114:
error: with typename _Operation::result_type
std::binder1st_Operation::operator()(const typename
_Operation::second_argument_type) const [with _Operation =
std::mem_fun1_tvoid, Foo, int]
/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.3.1/../../../../include/c++/4.3.1/backward/binders.h:
In instantiation of std::binder1ststd::mem_fun1_ref_tvoid, Foo, int :
foo.cc:19: instantiated from here
/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.3.1/../../../../include/c++/4.3.1/backward/binders.h:120:
error: typename _Operation::result_type
std::binder1st_Operation::operator()(typename
_Operation::second_argument_type) const [with _Operation =
std::mem_fun1_ref_tvoid, Foo, int] cannot be overloaded
/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.3.1/../../../../include/c++/4.3.1/backward/binders.h:114:
error: with typename _Operation::result_type
std::binder1st_Operation::operator()(const typename
_Operation::second_argument_type) const [with _Operation =
std::mem_fun1_ref_tvoid, Foo, int]
Note that only the member functions with a reference parameter fail; pass by
value and pass by pointer are accepted.
--
Summary: bind1st fails on mem_fun with reference argument
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37811
[Bug c++/37108] New: bogus ambiguity reported
this code:
class bar {
public:
operator int() { return f; }
operator const int() const { return f; }
int f;
};
int main() {
const bar* cb;
const int cx = *cb;
bar* b;
int x = *b;
switch(*cb) {}
switch(*b) {}
return 0;
}
gets you:
~/ootbc/personal/ivan$ g++ foo.cc
foo.cc: In function int main():
foo.cc:13: error: ambiguous default type conversion from const bar
foo.cc:13: error: candidate conversions include bar::operator int() and
bar::operator const int() const
foo.cc:14: error: ambiguous default type conversion from bar
foo.cc:14: error: candidate conversions include bar::operator int() and
bar::operator const int() const
Note that it reports ambiguity both when the source is const and only one
conversion (the const int() const one) is possible, and also when the source
is not const even though a conversion not involving constifying is preferred to
one that does constify. Not sure whether this counts as one or two bugs.
Here's what Comeau says:
Comeau C/C++ 4.3.10.1 (May 29 2008 09:37:15) for ONLINE_EVALUATION_BETA1
Copyright 1988-2008 Comeau Computing. All rights reserved.
MODE:strict errors C++ C++0x_extensions
ComeauTest.c, line 10: warning: variable cb is used before its value is set
const int cx = *cb;
^
ComeauTest.c, line 12: warning: variable b is used before its value is set
int x = *b;
^
--
Summary: bogus ambiguity reported
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37108
[Bug c++/36961] New: fails to identify template
enum A{a};
enum B{b};
class bottom {};
templatetypename E class attr {
public: E v;
operator E() { return v;}
};
templatetemplatetypename class node, typename attr, typename next
class attrNode : public nodeattr, public next {};
templatetemplatetypename class node
class list1 : public
attrNodenode, A,
attrNodenode, B,
bottom {};
class foo : public list1attr {};
list1attr v1;
foo v2;
templatetypename E, templatetypenameclass node,
templatetemplatetypename class class nodeList
nodeEatt(nodeListnode v) { return v; }
int main() {
A x1 = attA(v1);
B x2 = attB(v1);
A x3 = attA(foo);
}
gets you:
~/ootbc/personal/ivan$ g++ foo.cc
foo.cc: In function int main():
foo.cc:31: error: expected primary-expression before ) token
--
Summary: fails to identify template
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36961
[Bug c++/36961] fails to identify template
--- Comment #1 from igodard at pacbell dot net 2008-07-29 00:52 ---
Oops - sorry, posted wrong test case:
enum A{a};
enum B{b};
enum C{c};
enum D{d};
class bottom {};
templatetypename E class attr {
public: E v;
operator E() { return v;}
};
templatetemplatetypename class node, typename attr, typename next
class attrNode : public nodeattr, public next {};
templatetemplatetypename class node
class list1 : public
attrNodenode, A,
attrNodenode, B,
bottom {};
class foo : public list1attr {};
list1attr v1;
foo v2;
templatetypename E, templatetypenameclass node,
templatetemplatetypename class class nodeList
nodeEatt(nodeListnode v) { return v; }
int main() {
A x1 = attA(v1);
B x2 = attB(v1);
A x3 = attA(v2);
}
gets you:
~/ootbc/personal/ivan$ g++ foo.cc
foo.cc: In function int main():
foo.cc:33: error: no matching function for call to att(foo)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36961
[Bug c++/36961] fails to identify template
--- Comment #3 from igodard at pacbell dot net 2008-07-29 00:54 --- p.s. Comeau likes the (correct, second) test case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36961
[Bug c++/36961] fails to identify template
--- Comment #5 from igodard at pacbell dot net 2008-07-29 01:07 --- Please confirm that it is an error with your associates. First, Comeau likes it. Second, other template functions have no trouble identifying a template base class given a derived class. What is different about this case is that the base class is one that takes a template rather than a class or constant. Templates taking templates are unusual, and I'd be not surprised that g++ was insufficiently tested in this area. -- igodard at pacbell dot net changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36961
[Bug c++/36961] fails to identify template
--- Comment #6 from igodard at pacbell dot net 2008-07-29 02:32 --- FWIW, Visual Studio has been reported to me as accepting the test case too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36961
[Bug c/33877] Request for __VA_ARGC__
--- Comment #1 from igodard at pacbell dot net 2008-07-23 06:59 --- Second the motion - I too have had to tie myself in knots (generating source code that is then compiled...) to get the effect of this extension. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33877
[Bug c++/36626] New: traditional cast not recognized
This:
class a{
public:
static const signed long long int b = 1;
static const unsigned long long int c = unsigned long long int(b);
};
gets you this:
~/ootbc/asm$ g++ foo.cc
foo.cc:4: error: expected primary-expression before unsigned
foo.cc:4: error: expected ; before unsigned
--
Summary: traditional cast not recognized
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36626
[Bug c++/36601] New: Can't be friended by template class argument
This:
templatetypename F class Foo { friend class F; };
gets you this:
~/ootbc/asm$ g++ foo.cc
foo.cc:2: error: using template type parameter F after class
foo.cc:2: error: friend declaration does not name a class or function
--
Summary: Can't be friended by template class argument
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36601
[Bug libstdc++/36231] New: ostream includes unistd.h outside namespace std, polluting
Include chain is ostream - ios - iosfwd - bits/c++io.h - bits/gthr.h - bits/gthr-default.h - unistd.h. The same chain also includes pthread.h. These are imported at file scope, not in namespace std, which pollutes the application name space. I tried to report this to libstdc++ project, but their reporting instructions seem to lead here although strictly there's no problem with the compiler itself. -- Summary: ostream includes unistd.h outside namespace std, polluting Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: igodard at pacbell dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36231
[Bug c++/36163] New: Friend declaration confused by namespace/using
This code:
namespace name {
class foo {
public:
templateclass T
voidbaz(T t) { int i = t.dat; }
};
}
using namespace name;
class bar {
friend class foo;
int dat;
};
int main() {
bar b;
foo f;
f.baz(b);
}
gets you:
~/ootbc/members$ g++ foo.cc
foo.cc: In member function 'void name::foo::baz(T) [with T = bar]':
foo.cc:16: instantiated from here
foo.cc:11: error: 'int bar::dat' is private
foo.cc:5: error: within this context
--
Summary: Friend declaration confused by namespace/using
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36163
[Bug c++/36163] Friend declaration confused by namespace/using
--- Comment #2 from igodard at pacbell dot net 2008-05-06 21:39 --- Isn't ::foo the using'd class from name? If not, how does one befriend a class that comes from a using? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36163
[Bug c++/35228] New: template accepting numeric fails with sizeof
This code:
templateint i
class foo {
public:
typedef
unsigned int unsigned_t;
typedef
signed int signed_t;
};
templatetypename T
class bar {
public:
typedef
foo8::unsigned_t baz1;
typedef
foosizeof(T)::unsigned_t baz2;
};
barint var;
gets you this:
~/ootbc/personal/ivan$ c++ foo.cc
foo.cc:16: error: type 'foosizeof (T)' is not derived from type 'barT'
foo.cc:16: error: expected ';' before 'baz2'
--
Summary: template accepting numeric fails with sizeof
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35228
[Bug c++/20478] poor parse error diagnostic
--- Comment #7 from igodard at pacbell dot net 2008-01-25 22:35 --- Yes, it has always been understood that this code is invalid. The report is about the quality of the diagnostic that was given, not whether a diagnostic should be given. The diagnostics (three of them for one error) refer to a location a *long* way from the actual error, and with no obvious (to me anyway) syntactic relationship to the actual problem. -- igodard at pacbell dot net changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20478
[Bug c++/11756] ICE's when using typeof in template function parameter type declarations
--- Comment #9 from igodard at pacbell dot net 2007-10-04 08:58 --- My apologies, perhaps I'm misunderstanding the jargon. I took the fix comment to mean that typeof in the context reported would produce a diagnostic saying that gcc could not compile the construct, and that this was acceptable because typeof would be acceptable in a typedef and the typedef'd name could be used instead of a literal typeof. Under that understanding, I called it a kludge. There are any number of contexts in which a type is accepted but a declaration is not, and especially in macro expansions it may be quite inconvenient to force the writer to manually declare the type. It tends to expose the internals of an abstraction when one wants a clean abstract interface that looks and acts like an expression or primary, and could be implemented as such if typeof were accepted in all contexts. If that is not a correct interpretation of sorry and decltype then I regret pulling your chain, and would like to know what these do mean if you would take the time to explain. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11756
[Bug c++/11756] ICE's when using typeof in template function parameter type declarations
--- Comment #10 from igodard at pacbell dot net 2007-10-04 09:02 --- Sorry, I don't understand As you can see in the comment threads for some of the other bug reports about typeof in templates. The only other report cited as a duplicate to this one is 11757, and that has no real comments at all. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11756
[Bug c++/11756] ICE's when using typeof in template function parameter type declarations
--- Comment #12 from igodard at pacbell dot net 2007-10-04 14:23 --- Pays to show your ignorance; then you learn something :-) I thank you. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11756
[Bug c++/11756] ICE's when using typeof in template function parameter type declarations
--- Comment #6 from igodard at pacbell dot net 2007-10-04 01:15 --- Can you spell kludge? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11756
[Bug c++/33176] strange diagnostic with if (a) b
--- Comment #2 from igodard at pacbell dot net 2007-08-29 01:02 --- Why does it think a template is a label? I would understand if the code were: lab: if (i == 0) lab) ... but it knows that confirm is a function template at this point, and can't be a future label. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33176
[Bug c++/33176] strange diagnostic with if (a) b
--- Comment #4 from igodard at pacbell dot net 2007-08-29 02:27 --- OK, I see. I doubt I'm the only one who is confused by the report of a mis-used obscure gcc-only feature instead of an all-too-common parenthesis error :-) However, if you are emitting diagnostics on the fly then you have little choice but accept the last valid parse, which exposes you to trouble when the user has excess closers. In the compilers I've done we didn't do the diagnostics on the fly, but the diagnostic emitter backed up the parse to previous levels of the bracket tree and reparsed omitting either the opener or the last preceding closer at each level. We took the parse that got farthest, reporting a probably excess or missing bracket at the point where it did (or did not) appear. This avoided nearly all of the cascaded errors that gcc produces. Of course, that was in the days when a recompile was half an hour not 20 seconds, and getting the compiler as far as you could was a big help to the programmer :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33176
[Bug c++/33176] New: strange diagnostic
The code:
templatetypename T
bool confirm(T t, int i) { return t == i; }
int main() {
int i = 0, j = 1, k = 2;
if (i == j) confirm(j, k) ) { i = 2; }
return 0;
}
gets you:
~/ootbc/sim/src$ g++ foo.cc
foo.cc: In function 'int main()':
foo.cc:5: error: expected `;' before '(' token
foo.cc:5: error: label 'confirm' used but not defined
The actual problem is an extra ) after i == j, with nary a label anywhere.
--
Summary: strange diagnostic
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33176
[Bug c++/33156] preprocessor precedence of string concatenation backwards?
--- Comment #2 from igodard at pacbell dot net 2007-08-23 17:50 --- Whether # is before or after string concatenation, string concatenation should happen *sometime* and doesn't. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33156
[Bug c++/33156] preprocessor precedence of string concatenation backwards?
--- Comment #4 from igodard at pacbell dot net 2007-08-23 19:30 --- Ah! I see. So if string cat is after there's only one string, which does contain embedded quotes as printed. And if string cat were before you couldn't compose a string out of a sequence of macro calls and literals. Makes sense, sorry to bother you. -- igodard at pacbell dot net changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33156
[Bug c++/33150] New: frend functions of template get new diagnostic
The following code received no diagnostic in 4.0.1, but on 4.2.1 gets:
~/ootbc/personal/ivan$ g++ foo.cc
foo.cc: In instantiation of 'foo2int':
foo.cc:16: instantiated from here
foo.cc:12: error: redefinition of 'void bar(int)'
foo.cc:5: error: 'void bar(int)' previously defined here
Test case:
templatetypename T
class foo1 {
public:
friend
voidbar(T t) {};
};
templatetypename T
class foo2 {
public:
friend
voidbar(T t) {};
};
foo1int f1;
foo2int f2;
int main() {}
This may just be a result of tightening up gcc to the standard and the code
always was wrong, but I submit the report in case it is actually a regression
in a rarely-used part of the language.
As I understand it, every function defined in a template is considered to
itself be a template, and hence having a template function that is also a
definition does not count as a duplicate definition no matter how many times
the template is instantiated. However, that seems to no longer apply for
friends declared and defined in templates. Note that both friends refer to the
same function, which is textually declared identically.
Incidentally, declaring the friends inline makes no difference to the
diagnostic, whereas it would for a plain function. Possibly the construction
does in fact reflect the standard, but the inline keyword is mishandled? I
leave to the language lawyers whether this is valid or a regression, but in any
case you might want to add this code to your regression suite.
--
Summary: frend functions of template get new diagnostic
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33150
[Bug c++/33156] New: preprocessor precedence of string concatenation backwards?
The code:
#includeiostream
#define foo(b) #b
int main() {
std::cerr foo( this is a long string
broken across lines
but constiuting one argument to the macro ) \n;
}
produces:
~/ootbc/personal/ivan$ a.out
this is a long string broken across lines but constiuting one argument
to the macro
Shouldn't the embedded quotes be elided?
--
Summary: preprocessor precedence of string concatenation
backwards?
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33156
[Bug c++/32190] wrong error recovery on parsing template arguments
--- Comment #9 from igodard at pacbell dot net 2007-08-17 10:37 --- Subject: Re: wrong error recovery on parsing template arguments Begging your pardon, but what's wrong with the one I put in already? Ivan manu at gcc dot gnu dot org wrote: --- Comment #8 from manu at gcc dot gnu dot org 2007-08-17 10:28 --- Ivan, would you like to write, test and post the testcase? Once it is approved I can commit it for you (with your name of course!). A starting point will be http://gcc.gnu.org/wiki/HowToPrepareATestcase, if you need further help, please contact me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32190
[Bug c++/32190] wrong error recovery on parsing template arguments
--- Comment #11 from igodard at pacbell dot net 2007-08-17 17:25 ---
Subject: Re: wrong error recovery on parsing template arguments
Seems impractical. I don't have access to the old versions or mainline,
and don't know what magic to put in the source for your system to use.
I'm sure all that could be fixed, but it's more likely to take more of
someone's time holding my hand than it would be to do it themselves. If
I were doing a hundred of them it would be worth the investment, but for
a one-off it seems hardly useful.
Ivan
manu at gcc dot gnu dot org wrote:
--- Comment #10 from manu at gcc dot gnu dot org 2007-08-17 10:50 ---
(In reply to comment #9)
Subject: Re: wrong error recovery on parsing template arguments
Begging your pardon, but what's wrong with the one I put in already?
Nothing is wrong, but to be useful for GCC testsuite, we need to add some
markers (for example, // { dg-error template argument 1 is invalid }) and
then run an old version and check that the test fails and run it for mainline
and check that the test passes. Then the patch adding the testcase is
submitted
to gcc-patches for review with an appropriate changelog, approved and
committed. I think it would be a feasible contribution from you, letting more
advance developers like Paolo to focus on more complex stuff.
But if you don't want to do it just say so, no problem at all.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32190
[Bug c++/32966] New: bad diagnostic
This:
#includecstdlib
class system { system() {} };
int foo(system* p) {}
gets you:
~/ootbc/systemspec/build$ g++ foo.cc
foo.cc:4: error: 'p' was not declared in this scope
foo.cc:4: error: expected ',' or ';' before '{' token
The problem is that the function int system(...) is in scope so system on
line 4 is not recognized as a type and I guess the compiler is trying to parse
it as an expression (with * as the multiply operator). However, there's no
language construction type identifier (expression) that I know of.
--
Summary: bad diagnostic
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32966
[Bug c++/32966] bad diagnostic
--- Comment #1 from igodard at pacbell dot net 2007-08-02 05:32 --- Doh! a constructor. Sorry to trouble you. -- igodard at pacbell dot net changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32966
[Bug c++/32888] New: Declared long long double has wrong type
The code:
int main() {
long long double x;
long long double v = 0.0;
}
gets you:
~/ootbc/common$ g++ foo.cc
foo.cc: In function 'int main()':
foo.cc:3: warning: converting to 'long long int' from 'double'
Either long long double is illegal and should be flagged on both
declarations, or it is legal and should give you a floating point type not
long long int.
--
Summary: Declared long long double has wrong type
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32888
[Bug c++/32190] wrong error recovery on parsing template arguments
--- Comment #4 from igodard at pacbell dot net 2007-06-04 14:27 --- Well, in my ignorance, I'd say that the symptoms are consistent with scanning forward to the next , regardless of what gets scanned over, such an unmatched or statement-lists. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32190
[Bug c++/32190] New: bad diagnostic
This code:
templatetypename T class foo{ };
int main() {
fooint i;
foofooint j;
int k;
int l;
fooint m;
return 0;
}
gets you:
~/ootbc/sim/sandbox$ g++ foo.cc
foo.cc: In function 'int main()':
foo.cc:8: error: template argument 1 is invalid
foo.cc:8: error: invalid type in declaration before ';' token
~/ootbc/sim/sandbox$ fg
The real problem is a missing three lines earlier.
--
Summary: bad diagnostic
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32190
[Bug c++/32190] bad diagnostic
--- Comment #2 from igodard at pacbell dot net 2007-06-02 23:40 --- Either way, it is reporting on the first line after the point of actual error that contains a use of a template. The space between error and report is thus arbitrarily large and may cross files, and the flagged line has nothing wrong on it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32190
[Bug c++/20682] lost parser
--- Comment #12 from igodard at pacbell dot net 2007-04-10 02:45 --- Funny indeed - that's a scream :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20682
[Bug c++/31454] New: protected protects againt derived class
The code:
struct base {
protected:
virtual void foo() {}
};
struct der : public base {
virtual void foo() { p-foo(); }
base* p;
};
gets you:
~/ootbc/sim/test$ g++ foo.cc
foo.cc: In member function 'virtual void der::foo()':
foo.cc:3: error: 'virtual void base::foo()' is protected
foo.cc:7: error: within this context
--
Summary: protected protects againt derived class
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31454
[Bug c++/30891] New: poor diagnostic
The code:
int main() {
int i = 0;
namespace foo {
int j = 0;
}
return 0;
}
gets you:
~/ootbc/sim$ g++ foo.cc
foo.cc: In function 'int main()':
foo.cc:3: error: expected primary-expression before 'namespace'
foo.cc:3: error: expected `;' before 'namespace'
In contrast, Comeau gives:
Comeau C/C++ 4.3.8 (Aug 19 2006 13:36:48) for ONLINE_EVALUATION_Alpha1
Copyright 1988-2006 Comeau Computing. All rights reserved.
MODE:strict errors C++
ComeauTest.c, line 3: error: namespace definition is not allowed
namespace foo {
^
ComeauTest.c, line 2: warning: variable i was declared but never referenced
int i = 0;
^
1 error detected in the compilation of ComeauTest.c.
--
Summary: poor diagnostic
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30891
