--- Additional Comments From bangerth at dealii dot org 2005-03-02 00:04
---
You can't access a floating point variable through a pointer to integer.
Read up on -fstrict-aliasing, or its negative -fno-strict-aliasing.
W.
--
What|Removed |Added
--- Additional Comments From bangerth at dealii dot org 2005-03-02 19:24
---
The problem with the compiler not warning about these cases is that it is
perfectly legal to cast a double* to an int* -- the problem is that it is
not legal to access a double through an int*, but to flag
--- Additional Comments From bangerth at dealii dot org 2005-03-02 21:54
---
Correct. The class without inheritance doesn't need a constructor
since objects of this type can be initialized using a brace-enclosed
list. The class with inheritance is not POD, so it can't be initialized
--- Additional Comments From bangerth at dealii dot org 2005-03-02 23:03
---
This is indeed a diagnostic problem: the access is ambiguous, but instead
of saying so gcc chooses to mention that there is no such name at all. This
happens in many places, and I believe that there must
--- Additional Comments From bangerth at dealii dot org 2005-03-03 14:39
---
I think gcc is right, and icc rejects the code with an almost exact same
error message.
W.
--
What|Removed |Added
--- Additional Comments From bangerth at dealii dot org 2005-03-03 17:00
---
That's correct, but that's a dup of PR 16859.
W.
--
What|Removed |Added
Status
--- Additional Comments From bangerth at dealii dot org 2005-03-04 15:05
---
Here's another very nice example from PR 20313:
-
templateint j struct s;
templateint i si::s(int j) {}
-
Note that the definition of the constructor
--- Additional Comments From bangerth at dealii dot org 2005-03-04 15:15
---
This seems to be more a problem of precompiled headers on solaris than
anything else...
W.
--
What|Removed |Added
--- Additional Comments From bangerth at dealii dot org 2005-03-06 21:37
---
I think the whole idea of second-guessing what a user might have meant when
he misspelled an option is debatable. I personally am of the opinion that
this should yield an error or a warning, but that we
--- Additional Comments From bangerth at dealii dot org 2005-03-10 19:55
---
This is a duplicate of a good number of other PRs. I don't have the time
right now to find them, though...
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20401
--- Additional Comments From bangerth at dealii dot org 2005-03-11 14:50
---
Confirmed, with all gcc versions I have on my system. Here's what icc says:
g/x icc -Xc -ansi -c x.cc
x.cc(15): error: E has already been declared in the current scope
enum E
--- Additional Comments From bangerth at dealii dot org 2005-03-14 16:25
---
The place to look at is 12.6.2/2:
2 Names in a mem-initializer-id are looked up in the scope of the
constructor's class and, if not found in that scope, are looked up in
the scope containing
--- Additional Comments From bangerth at dealii dot org 2005-03-15 18:15
---
Created an attachment (id=8393)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8393action=view)
Preprocessed sources, not reduced
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20485
--- Additional Comments From bangerth at dealii dot org 2005-03-20 22:46
---
IIRC, this was intentional because people had a habit of writing RCS
$ID: strings at the top of files and wanted to find them again in
the executable to identify which files exactly were linked together
--
What|Removed |Added
Summary|[4.1 Regression] werid error|[4.1 Regression] weird error
|message after a parse error |message after a parse error
--- Additional Comments From bangerth at dealii dot org 2005-03-21 22:05
---
I'm absolutely positive this is a duplicate of a fair number of other PRs,
though I can't find one with a 20 second search. PR 13979 may be one, but
doesn't have a really short testcase so I can't tell
--- Additional Comments From bangerth at dealii dot org 2005-03-21 22:17
---
Here's a small testcase:
struct B {};
struct D : B {};
struct S {
int foo(B* taskData);
};
int i = S().foo((D*)0);
-
We get these messages, the one for 2.95
--- Additional Comments From bangerth at dealii dot org 2005-03-23 18:53
---
Intuitively, C++ treats unnamed enums differently than named ones, because
in templates the function/class name has to be mangled, and will contain
the name of the template arguments. If the template argument
--- Additional Comments From bangerth at dealii dot org 2005-03-23 19:24
---
That has been subject to discussion (i.e. whether the attempt to use an
unnamed enum as a template argument should just silently fail as a
substitution failure). However, it has been decided
--- Additional Comments From bangerth at dealii dot org 2005-03-23 21:56
---
Related PRs are: PR 19404, and in particular PR 17413. The latter is the one
I was thinking of.
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20589
quite so obvious. What
I get is this:
g/x /home/bangerth/bin/gcc-4*/bin/c++ -c a.cc
a.cc:2: error: ?void B::f()? and ?void B::f()? cannot be overloaded
Note that it doesn't show where the attempt to overload happens, it only shows
the original place. That's bad diagnostics.
gcc2.95
--- Additional Comments From bangerth at dealii dot org 2005-03-25 20:12
---
I should add that it doesn't matter whether you use old- or new-style
using declarations:
B::f;
B::f;
and
using B::f;
using B::f;
yield the same results.
W.
--
http://gcc.gnu.org/bugzilla
--- Additional Comments From bangerth at dealii dot org 2005-03-26 22:53
---
Well, I wanted to give an inuitive reasoning.
On the other hand, how do you propose to make up a unique name if an
unnamed enum is used in two different translation units as a template
argument?
W
--- Additional Comments From bangerth at dealii dot org 2005-03-26 22:57
---
Giovanni, in your example in comment #27, you get this:
Patched:
test.cc: In member function 'void AT, N, X::foo() [with T = int]':
test.cc:14: instantiated from here
test.cc:9: error: 'class std
--- Additional Comments From bangerth at dealii dot org 2005-03-28 15:06
---
Yes, there are multiple PRs in the database about diagnostics when people
forget the semicolon at the end of a struct or class declaration. There are
also examples in these PRs that show why this case is so
--- Additional Comments From bangerth at dealii dot org 2005-04-08 19:38
---
This is duplicate of PR 99.
*** This bug has been marked as a duplicate of 99 ***
--
What|Removed |Added
--- Additional Comments From bangerth at dealii dot org 2005-04-08 19:38
---
*** Bug 20906 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=99
) ? mu : 0) +
((i==j) (k==l) ? 1 : 0));
}
template void test3 ();
-
ICEs with gcc3.4.4pre (and apparently all older versions of the 3.4.x branch I
have):
deal.II/tests /ices/bangerth/tmp/build-gcc-3.4/gcc-install/bin/c++ -c x.cc
x.cc: In function `void test()':
x.cc:11
--- Additional Comments From bangerth at dealii dot org 2005-04-13 15:29
---
Note that it isn't related to PR 19899, even though the failure seems similar.
I should also note that the ICE happened with a compiler that had checking
enabled.
If checking is disabled, we simply get
--- Additional Comments From bangerth at dealii dot org 2005-04-15 05:29
---
A::foo_ is not template-dependent, so it is looked up and bound at the time
of template definition, not at instantiation time. Because template-dependent
base classes are not visible at the time, the access
--- Additional Comments From bangerth at dealii dot org 2005-04-15 05:31
---
The unqualified name Foo is looked up within the class hierarchy, and finds
the name of the base class.
W.
--
What|Removed |Added
--- Additional Comments From bangerth at dealii dot org 2005-04-15 05:36
---
It may also very well be the case that the shown opening brace isn't the
one that is unmatched, but that you forgot to close a block somewhere in
the middle.
W.
--
http://gcc.gnu.org/bugzilla
--- Additional Comments From bangerth at dealii dot org 2005-04-18 20:16
---
This code has at least two bugs:
template class MyTypeSample;
template std::mapchar*,char* MyTypeSample::m_map;
First, the instantiation must come *after* the definition of the static
member.
Second
--- Additional Comments From bangerth at dealii dot org 2005-04-18 20:29
---
This sentence just says that you can't do this:
class A { private: struct I{}; };
class B { friend class A::I; };
because A::I isn't accessible in B.
W.
--
http://gcc.gnu.org/bugzilla
--- Additional Comments From bangerth at dealii dot org 2005-04-18 20:34
---
And the answer to the original question: even though gcc handled it as this
in the past (incorrectly), a friend declaration is not a declaration. In
other words, if a name is not declared before, but first
--- Additional Comments From bangerth at dealii dot org 2005-04-19 14:08
---
Why? This code as always wrong. It has nothing to do with gcc3.4.x.
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17445
--- Additional Comments From bangerth at dealii dot org 2005-04-19 18:25
---
Martin Mike,
I'm happy to reopen this PR. I understand your analysis, and in fact thought
about it when I wrote my comment. Independently of whether it may be strictly
mandated by the standard, I do have
--- Additional Comments From bangerth at dealii dot org 2005-04-20 21:33
---
Explicit instantiations can only instantiate things that have been seen
before. Nothing is seen in your case, so there is nothing to be done.
W.
--
What|Removed |Added
--- Additional Comments From bangerth at dealii dot org 2005-05-02 18:42
---
I would be very much surprised if this was allowed. But then I, too, can't
find any normative statements in the standard. Maybe looking at the wrong
places, though...
W.
--
http://gcc.gnu.org/bugzilla
--- Additional Comments From bangerth at dealii dot org 2005-05-02 18:46
---
The problem is in fact that 'S' is ambiguous: either N::S or M::S are
candidates. The fact that gcc says that it doesn't know names when in fact
it does but they are ambiguous is recorded in a number of other
--- Additional Comments From bangerth at dealii dot org 2005-05-02 18:47
---
Same problem as in PR 21205.
W.
--
What|Removed |Added
Status|UNCONFIRMED
--- Additional Comments From bangerth at dealii dot org 2005-05-02 18:48
---
Just like PR 21205.
W.
--
What|Removed |Added
Status|UNCONFIRMED
--- Additional Comments From bangerth at dealii dot org 2005-05-02 18:54
---
What is going wrong is this: the name 'S' may refer to both the local
typedef in the base class 'A' as well as to the global structure '::S'.
If I write either
friend class A A ::S::S;
or
friend class
--- Additional Comments From bangerth at dealii dot org 2005-05-02 18:56
---
Confirmed. Funny enough, icc accepts the code as well...
W.
--
What|Removed |Added
--- Additional Comments From bangerth at dealii dot org 2005-05-02 19:02
---
Confirmed. However, this has really low priority: the C++ standard is not
a superset of the C99 standard, so a number of things new to C99 are not
part of C++, and this is one of them. If you want to write
--- Additional Comments From bangerth at dealii dot org 2005-05-06 22:21
---
I think that's a good question. We've had this before in some other PR. The
problem is that because the template parameter is explicitly specialized,
rather than deduced, SFINAE doesn't apply and the compiler
--- Additional Comments From bangerth at dealii dot org 2005-05-06 22:33
---
That's an interesting case involving covariant return types:
-
class B1 {
public:
virtual void foo();
};
class B2 {
public:
virtual B2 bar() = 0;
};
class I
--
What|Removed |Added
Summary|problem with tempalte and |problem with template and
|tempalte function |template function
--- Additional Comments From bangerth at dealii dot org 2005-05-12 17:49
---
You can't do this:
templatetypename T
std::ostream std::operator (std::ostream , a::AT const );
If you want to overload something in namespace std, you have to open that
namespace, put the declaration
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bangerth at dealii dot org
CC: gcc-bugs at gcc dot gnu dot org
http
--- Additional Comments From bangerth at dealii dot org 2005-05-17 16:27
---
Discussing the exact wording is nitpicking. The problem is real so let's
confirm this PR.
W.
--
What|Removed |Added
--- Additional Comments From bangerth at dealii dot org 2005-05-17 16:37
---
All gcc versions I have take the template in namespace odd, and so does
icc in strict mode. I see nothing in 3.4.2 that should prevent this
from happening. What is relevant here is that the using declaration
--- Additional Comments From bangerth at dealii dot org 2005-05-17 16:39
---
Andrew's argument has been made a number of times, and is considered
irrelevant
until someone actually comes around and implements the 'export' keyword.
This request is therefore definitely valid, but I
--- Additional Comments From bangerth at dealii dot org 2005-05-17 16:41
---
This is already fixed in gcc4.0 which says
g/x /home/bangerth/bin/gcc-4*/bin/c++ -c x.cc
x.cc:5: error: ISO C++ forbids declaration of #8216;T#8217; with no type
x.cc: In instantiation of #8216;BA#8217
--- Additional Comments From bangerth at dealii dot org 2005-05-17 17:52
---
Confirmed. Here is a simpler case:
-
extern void findme();
struct Z *p;
void (Z::*m) ();
void rr () {
findme();
(p-*m)();
findme();
}
--
if one greps
--- Additional Comments From bangerth at dealii dot org 2005-05-24 20:33
---
This is a duplicate of a dozen other bugs where gcc reports that there is
no declaration even though there are ambiguous ones. Can someone please go
through the list of open PRs and find it? We get a similar
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bangerth at dealii dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21799
--
What|Removed |Added
Severity|normal |critical
Target Milestone|--- |4.1.0
--- Additional Comments From bangerth at dealii dot org 2005-05-31 13:49
---
The PR Andrew cites is essentially a duplicate of PR 8271, which has been
around for 2 1/2 years already. It is about the fact that gcc accepts a
pointer to a constant member function for an argument
--- Additional Comments From bangerth at dealii dot org 2005-05-31 13:49
---
This is a duplicate of one of my rather older bugs, PR 8271...
W.
*** This bug has been marked as a duplicate of 8271 ***
--
What|Removed |Added
--- Additional Comments From bangerth at dealii dot org 2005-05-31 13:50
---
*** Bug 21801 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8271
--
Bug 21799 depends on bug 21801, which changed state.
Bug 21801 Summary: Accepts invalid for const member pointer functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21801
What|Old Value |New Value
--- Additional Comments From bangerth at dealii dot org 2005-05-31 17:56
---
PR 21799 treats the same problem, but looks a little cleaner and has some
additional comments.
W.
*** This bug has been marked as a duplicate of 21799 ***
--
What|Removed
--- Additional Comments From bangerth at dealii dot org 2005-05-31 17:56
---
*** Bug 21066 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
Bug 21799
: normal
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bangerth at dealii dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21851
--- Additional Comments From bangerth at dealii dot org 2005-05-31 23:21
---
Created an attachment (id=9004)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9004action=view)
Preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21851
--- Additional Comments From bangerth at dealii dot org 2005-05-31 23:28
---
I can still reproduce this with today's mainline. The segfault still
happens in a movapd instruction:
0x08048389 _Z1fv+21: movapd %xmm0,(%eax)
(gdb) info registers eax
eax0xbfffe944
--- Additional Comments From bangerth at dealii dot org 2005-06-01 19:00
---
This is a dup of PR 15259, which is already fixed in 4.0.
*** This bug has been marked as a duplicate of 15259 ***
--
What|Removed |Added
--- Additional Comments From bangerth at dealii dot org 2005-06-01 19:00
---
*** Bug 21864 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From bangerth at dealii dot org 2005-06-02 14:20
---
There's no way we can tell you what's wrong if you don't show us the complete
code, preferrably cut down to a manageable size. It may be a compiler bug,
or it may be that you are accidentally overwriting some
ReportedBy: bangerth at dealii dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21884
--- Additional Comments From bangerth at dealii dot org 2005-06-02 19:24
---
Created an attachment (id=9017)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9017action=view)
Preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21884
--- Additional Comments From bangerth at dealii dot org 2005-06-02 19:36
---
I don't know -- the failure appears in a completely different place. I see
this particular ICE on at least half a dozen of my files, but I'll be happy
holding off finding a reduced testcase until the other PR
--- Additional Comments From bangerth at dealii dot org 2005-06-02 20:17
---
Created an attachment (id=9018)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9018action=view)
Much shorter testcase
I attach another testcase that I managed to get down to approximately 10kloc
--- Additional Comments From bangerth at dealii dot org 2005-06-03 17:46
---
Nested class, like all other members of a class, have access to private
and protected members. That's what the standard says.
W.
--
What|Removed |Added
--- Additional Comments From bangerth at dealii dot org 2005-06-03 21:51
---
Here's the same testcase again, but shorter:
---
struct O {
templatetypename T struct B {
void set (T, bool=true);
};
struct D : public Bint
--- Additional Comments From bangerth at dealii dot org 2005-06-03 22:27
---
In private mail, I got another testcase that is even weirder:
---
struct O {
templatetypename T struct B {
void set (T, bool=true);
};
struct D : public Bint
--
What|Removed |Added
CC||giovannibajo at gcc dot gnu
||dot org
--- Additional Comments From bangerth at dealii dot org 2005-06-04 04:37
---
I'm sorry, but I have no idea what you mean by that. If you want to say
that O::Bint is instantiated by O::D, which is still inside O, yes, of
course that's the case. And I'm happy if the default arguments
--- Additional Comments From bangerth at dealii dot org 2005-06-06 14:27
---
Sure it is a regression: gcc3.3.x compiles it just fine, and so does 3.2.x.
gcc2.95 ICES, and from 3.4 onward we have the present error.
W.
--
What|Removed |Added
--- Additional Comments From bangerth at dealii dot org 2005-06-06 14:28
---
My last message refers to the code snippet in comment #4.
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21903
--- Additional Comments From bangerth at dealii dot org 2005-06-07 23:28
---
I concur with the last post -- a dummy return at the end would solve
the problem and seems like an acceptable solution for a release
branch.
W.
--
What|Removed |Added
--- Additional Comments From bangerth at dealii dot org 2005-06-16 20:00
---
The typedef you use is still a specialization of a template, so you
have to write
template intsample::keytype * intsample::keyptr = 0;
With this, it works.
W.
--
What|Removed
--- Additional Comments From bangerth at dealii dot org 2005-06-16 22:04
---
b = (size_t)(p = (int []){0, 1, 2}[1]);
What a perverse line of code -- I guess you got what you deserved :-)
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22098
--- Additional Comments From bangerth at dealii dot org 2005-06-20 21:30
---
Since this PR prevents me from running my nightly tests for more than 2 months
now, could someone try to run the regression finder on the small testcase to
find out who broke this and when? The duplicate
--- Additional Comments From bangerth at dealii dot org 2005-06-21 15:55
---
I also see this problem on the 4.0 branch now, with
gcc version 4.0.1 20050531 (prerelease)
I am pretty sure that it wasn't there in 4.0.0, but don't know for sure any
more...
W.
--
http
--- Additional Comments From bangerth at dealii dot org 2005-06-21 16:00
---
Giovanni,
I can confirm that your patch for PR 8271 also fixes the problem in this PR.
I would be extremely grateful if it would move somewhere...
Cheers
Wolfgang
--
What|Removed
--- Additional Comments From bangerth at dealii dot org 2005-06-21 16:03
---
I just verified that Giovanni's patch linked to in comment #4 also fixes the
regression reported in PR 21799. Apparently some unrelated change exposed the
problem in 21799, but the underlying issue is the one
--- Additional Comments From bangerth at dealii dot org 2005-06-21 16:14
---
I don't have the time to check it today, but could try tomorrow. It certainly
sounds plausible. Nathan, could you comment on this problem?
Thanks
Wolfgang
--
What|Removed
This used to compile but doesn't any more on mainline (ok on 4.0.x branch):
---
struct B {
void foo();
};
template typename T class I : public B {};
template typename T class D : private IT {
IT::B::foo;
};
--
g/x /home/bangerth
--
What|Removed |Added
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22136
With attached file, I get the following segfault with mainline:
examples/step-18 /home/bangerth/bin/gcc-4.1-pre/bin/c++ -c step-18.ii
step-18.ii:7102: warning: #8216;__malloc__#8217; attribute ignored
step-18.ii: In constructor #8216;std::_Vector_base_Tp,
_Alloc::_Vector_base(size_t, const
--
What|Removed |Added
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22139
--- Additional Comments From bangerth at dealii dot org 2005-06-21 17:58
---
Created an attachment (id=9125)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9125action=view)
Preprocessed sources
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22139
--- Additional Comments From bangerth at dealii dot org 2005-06-21 18:00
---
This looks like a memory problem -- the backtrace is this:
(gdb) r -quiet step-18.ii -o /dev/null
Starting
program:
/home/bangerth/bin/gcc-4.1-pre/libexec/gcc/i686-pc-linux-gnu/4.1.0/cc1plus
-quiet step
--- Additional Comments From bangerth at dealii dot org 2005-06-21 18:03
---
I also get essentially the same backtrace (with the call to
ggc_set_mark (p=0x14)
at the top) from the 4.0.1pre CVS as of 2005-05-31, although this
happens at a different place in the source code. I'm
--
What|Removed |Added
Summary|[4.1 regression] Segfault |[4.0/4.1 regression]
||Segfault
--- Additional Comments From bangerth at dealii dot org 2005-06-21 18:48
---
Created an attachment (id=9126)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9126action=view)
Smaller testcase
Attached is another testcase that has only half as many lines (~40k) and
that may be simpler
--- Additional Comments From bangerth at dealii dot org 2005-06-21 20:58
---
Good idea. So I tried it, and indeed this patch
2005-05-10 Nathan Sidwell [EMAIL PROTECTED]
PR c++/20723
* pt.c (more_specialized_fn): Member functions are unordered wrt
non
--- Additional Comments From bangerth at dealii dot org 2005-06-21 20:58
---
Unfortunately, the patch to this PR has caused the regression reported in
PR 21799 :-(
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19203
101 - 200 of 1190 matches
Mail list logo
