--- Comment #17 from bangerth at dealii dot org 2006-08-22 20:36 ---
I agree that we should allow this behavior. Clearly the standard has nothing
to say about whether -fno-rtti should allow this or not, but the standard
has an explicit provision for the case of dynamic_castvoid
--- Comment #1 from bangerth at dealii dot org 2006-08-23 15:01 ---
(In reply to comment #0)
int size1 = sizeof(A); // == 0, should be nonzero
int size2 = sizeof(a); // == 0, should be nonzero
What makes you think so?
Since: ISO 14882-2003, 9 [Classes].3
I don't quite know
--- Comment #1 from bangerth at dealii dot org 2006-08-23 15:08 ---
I can confirm that it takes
g++ 3.3: 1.5 seconds
gcc 3.4: 18.6 seconds
gcc 4.0: 13.2 seconds
However, gcc4.1 is back down to 0.5 seconds to compile this and presumably
takes a lot less memory as well. So
--- Comment #4 from bangerth at dealii dot org 2006-08-24 01:52 ---
Paolo has already confirmed this one.
--
bangerth at dealii dot org changed:
What|Removed |Added
--
bangerth at dealii dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #2 from bangerth at dealii dot org 2006-08-24 01:57 ---
It doesn't seem to matter for me whether the function is a template or
not. Which version did you use to get to that statement?
W.
--
bangerth at dealii dot org changed:
What|Removed
--- Comment #1 from bangerth at dealii dot org 2006-08-24 01:59 ---
Um, why? The value 1.234 is an rvalue of type double. You cast it to
an rvalue of type const int, which can clearly be assigned to an
int right away without another cast. In fact, const-volatile qualifications
do
namespaces
don't mix
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bangerth at dealii dot
--- Comment #1 from bangerth at dealii dot org 2006-09-04 16:04 ---
I forgot to say that this comes from trying to use -fprofile-use on 447.dealII
from SPEC 2006...
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28948
--- Comment #1 from bangerth at dealii dot org 2006-09-12 03:58 ---
At first I thought that the warning is not useful since the variable may
in fact not be unused at all -- the using declaration simply makes the
name available in the present scope.
However, then I realized
--- Comment #5 from bangerth at dealii dot org 2006-09-12 04:00 ---
(In reply to comment #4)
I suppose this is the same basic problem?
No, that code is definitely legal and unobjectionable. Just as having two
extern declarations of the same variable in the same scope (or two forward
--- Comment #4 from bangerth at dealii dot org 2006-09-13 03:32 ---
With today's 4.1.x snapshot and on x86_64, I get this at -O2:
.L4:
mov %edx, %eax
incl%edx
cmpl%edx, %ecx
movl%esi, (%rdi,%rax,4)
jne .L4
--- Comment #3 from bangerth at dealii dot org 2006-09-13 03:34 ---
This appears to be working now on x86_64 with last night's gcc 4.1.x
subversion.
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #1 from bangerth at dealii dot org 2006-09-13 03:39 ---
Confirmed. I see the same behavior on x86_64-linux-unknown-gnu. This
is a regression from 3.4.x that is present in at least the 4.0.x and 4.1.x
release branches (don't know about mainline).
W.
--
bangerth at dealii
--- Comment #6 from bangerth at dealii dot org 2006-09-13 04:02 ---
Isn't this a duplicate of PR 28173 now?
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #3 from bangerth at dealii dot org 2006-09-13 16:10 ---
Confirmed with the testcase from attachment #2.
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #3 from bangerth at dealii dot org 2006-09-15 13:49 ---
Confirmed. This is the valid testcase:
struct Base {
templateclass C void method() { }
};
struct Left : public Base { };
struct Right : public Base { };
struct Join : public Left, public Right
--- Comment #4 from bangerth at dealii dot org 2006-09-27 04:30 ---
This is definitely firmly in the class of extension to the language that
requires a thorough proposal to be presented to the standards committee
things. I don't think anyone is even remotely interested in implementing
--- Comment #4 from bangerth at dealii dot org 2006-09-27 04:50 ---
This code can't work. The check() function is not a virtual function,
so calling
((broken)-*func) ();
is translated to
( ((Base*)(broken))-*func) ();
because func is of type
void (Base::*) (...)
Then, when you
--- Comment #6 from bangerth at dealii dot org 2006-09-27 04:57 ---
Filing bug reports is certainly a good think no matter what happens:
a) If code is finally merged from the branch, we will have to go back to
these bug reports to make sure they're really fixed
b) If code is never
--- Comment #1 from bangerth at dealii dot org 2006-09-27 15:46 ---
You didn't show us the code that generated the problem. We can't do anything
without that. Please read
http://gcc.gnu.org/bugs.html
for more information.
Best
W.
--
bangerth at dealii dot org changed
--- Comment #1 from bangerth at dealii dot org 2006-09-27 15:48 ---
-q64 is not a flag that gcc recognizes. It is a flag that xlC recognizes,
however. Why would you want to pass it to gcc?
W.
--
bangerth at dealii dot org changed:
What|Removed
--- Comment #2 from bangerth at dealii dot org 2006-09-28 05:59 ---
Confirmed. This actually worked in gcc2.95 to my surprise:
g/x /home/bangerth/bin/gcc-2.95.3/bin/c++ -c x.cc
x.cc: In function `void foo()':
x.cc:1: variable-sized object of type `const char *[((c - 1) + 1)]' may
--- Comment #4 from bangerth at dealii dot org 2006-09-28 06:06 ---
I think the error message is perfectly clear: it says that there is no
function
foo (X)
but that there is a function that provides
foo (X)
We've gone through this many times that there is no way to say see, you
--- Comment #7 from bangerth at dealii dot org 2006-09-28 06:09 ---
Daniel, would you prefer if we marked this as WONTFIX? I think this thing
is so contentious that we're not going to do anything about it until there's
some sort of resolutions from the ISO committees.
I just don't see
--- Comment #1 from bangerth at dealii dot org 2006-09-28 06:10 ---
Can you post preprocessed sources as requested in
http://gcc.gnu.org/bugs.html
Thanks
Wolfgang
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #1 from bangerth at dealii dot org 2006-09-28 06:15 ---
This is what is listed in the release notes of gcc 3.4:
http://gcc.gnu.org/gcc-3.4/changes.html
They say this:
-
When binding an rvalue of class type to a reference, the copy constructor of
the class must
--- Comment #9 from bangerth at dealii dot org 2006-10-10 03:26 ---
(In reply to comment #8)
(In reply to comment #7)
3.4.4 (or 3.4.6) are the system compilers on FreeBSD-5.x and FreeBSD-6.x
So what, we are talking about the FSF GCC and not freebsd and 3.4.x is no
longer maintained
--- Comment #2 from bangerth at dealii dot org 2006-10-10 03:36 ---
This is in fact a duplicate of PR 20039.
*** This bug has been marked as a duplicate of 20039 ***
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #2 from bangerth at dealii dot org 2006-10-10 03:36 ---
*** Bug 28990 has been marked as a duplicate of this bug. ***
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #3 from bangerth at dealii dot org 2006-10-10 03:44 ---
Confirmed. Not a useful extension because confusing:
-
struct A;
struct B {
B (const A);
};
struct A {
operator B() const;
};
A a;
B b1 = a;// xpass
---
g/x /home
--- Comment #1 from bangerth at dealii dot org 2006-10-10 03:51 ---
Confirmed:
--
struct S { void operator () (); };
void foo ()
{
( S()() );
}
--
g/x /home/bangerth/bin/gcc-4.2-pre/bin/c++ -c x.cc
x.cc: In function #8216;void foo()#8217;:
x.cc:5
--- Comment #6 from bangerth at dealii dot org 2006-10-10 03:54 ---
Confirmed. The code makes sense and we shouldn't unconditionally warn.
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #1 from bangerth at dealii dot org 2006-10-10 03:56 ---
Indeed can't reproduce on x86.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29297
--- Comment #3 from bangerth at dealii dot org 2006-10-10 04:00 ---
The standard does not provide to explicitly specify the template
arguments of a constructor invocation. The syntax
nametype
refers to a template class 'name' with template argument 'type', not
to a template
--- Comment #3 from bangerth at dealii dot org 2006-10-10 04:11 ---
Confirmed:
--
template typename T struct A {};
template template typename class P
struct B {
template template typename class Q
friend bool foo (const BQ a);
};
template template typename class Q
--- Comment #4 from bangerth at dealii dot org 2006-10-10 04:13 ---
btw, this only happens if Q is really a template template argument. As noted
by the original reporter, the problem goes away if Q is simply a template
argument.
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #4 from bangerth at dealii dot org 2006-10-10 04:24 ---
Your expectations are wrong. You probably believe that here
-
void f3()
{
D d3;
printf(3) getValue() - %d,, d3.getValue());
{
D d3 = d3;
printf(getValue() - %d\n, d3.getValue
--- Comment #5 from bangerth at dealii dot org 2006-10-10 04:27 ---
Here's the right combination of flags that warns (for f3() only):
g/x /home/bangerth/bin/gcc-4.2-pre/bin/c++ -Winit-self -Wuninitialized -O2 -c
x.cc
x.cc: In function #8216;void f3()#8217;:
x.cc:42: warning: #8216;d3$c
--- Comment #6 from bangerth at dealii dot org 2006-10-10 14:25 ---
(In reply to comment #5)
foo should not have been injected by the friend.
True, but that's irrelevant here. We get a tentative declaration that we
simply have to unify with the later real declaration.
Note
--- Comment #11 from bangerth at dealii dot org 2006-10-10 14:56 ---
(In reply to comment #10)
For you, the developers, it is, probably, indeed faster, than writing another
explanation, why you have no resources to do it...
No, it will actually take significant time, since one has
--- Comment #13 from bangerth at dealii dot org 2006-10-10 15:18 ---
(In reply to comment #12)
In comment #9: shouldn't be too hard.
In comment #11: No, it will actually take significant time
It's a long and boring process. It's not complicated, it just takes time
--- Comment #5 from bangerth at dealii dot org 2006-10-11 03:35 ---
Um, the error message says
`foo' is not a template
which is about as accurate as can be.
That said, the request for a warning for constructors that can't be called
is ok. Would you mind opening a new report only
--- Comment #4 from bangerth at dealii dot org 2006-10-11 03:43 ---
Confirmed. 12.5/4 reads to me as if myclass::operator delete[] should be
called. Indeed icc doesn't call either user defined operator in the
array case. I think that's just a convergence of bugs, though.
This appears
--- Comment #1 from bangerth at dealii dot org 2006-10-12 00:39 ---
int array3[(const unsigned short) (20.5 * 3)];
error message from compiler is:
error: array bound is not an integer constant
to me this is wrong because the expression (const unsigned short) (20.5 * 3
--- Comment #3 from bangerth at dealii dot org 2006-10-12 00:41 ---
Confirmed.
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
CC
--- Comment #2 from bangerth at dealii dot org 2006-10-12 00:56 ---
Why exactly do you think that the empty base should not be located at
the same address as the simple_base base object?
W.
--
bangerth at dealii dot org changed:
What|Removed
--- Comment #4 from bangerth at dealii dot org 2006-10-12 01:03 ---
The operator== you want to call is used in a context in which the
template argument cannot be deduced (a non-deduceable context).
If you want to use this construct, you will have to write something like
--- Comment #19 from bangerth at dealii dot org 2006-10-12 01:06 ---
Since this is solved on mainline and nobody seems to have been able to
ever reproduce it anyway, there doesn't seem to be a chance of this
being actively worked on on older release branches. I'll therefore close
it. We
--
bangerth at dealii dot org changed:
What|Removed |Added
Known to work||4.2.0
Target Milestone|4.1.2 |4.2.0
http
--- Comment #2 from bangerth at dealii dot org 2006-10-12 01:08 ---
What exactly is the problem here? I get this as an error message:
g/x /home/bangerth/bin/gcc-4.2-pre/bin/c++ -c x.cc
x.cc: In function #8216;void f()#8217;:
x.cc:3: error: break statement not within loop or switch
gnu dot org
ReportedBy: bangerth at dealii dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29437
--- Comment #1 from bangerth at dealii dot org 2006-10-12 01:39 ---
Confirmed.
--
bangerth at dealii dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #4 from bangerth at dealii dot org 2006-10-12 01:41 ---
Are there any plans to backport the fix to 4.0.x, or should this bug be
closed as a WONTFIX on that branch?
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #1 from bangerth at dealii dot org 2006-10-12 01:43 ---
Confirmed. To make things more interesting, gcc presently gives me
the warning twice:
g/x /home/bangerth/bin/gcc-4.2-pre/bin/c++ -c x.cc -Wall
x.cc: In function #8216;int main()#8217;:
x.cc:5: warning: null argument
--- Comment #4 from bangerth at dealii dot org 2006-10-12 01:45 ---
Confirmed. The template version doesn't compile, whereas the non-template
version does.
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #4 from bangerth at dealii dot org 2006-10-12 01:47 ---
I can confirm that this is apparently fixed now.
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #3 from bangerth at dealii dot org 2006-10-12 01:49 ---
Confirmed.
--
bangerth at dealii dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #5 from bangerth at dealii dot org 2006-10-12 01:50 ---
gcc is correct. It is true that the result of the ?: operator is
a reference to the Base object of the Derived object created in the
second arm. However, the result is an rvalue, and a constant reference
is initialized
--- Comment #2 from bangerth at dealii dot org 2006-10-12 01:52 ---
It is infact: this is a cleaned up version of that PR, but actually handles
the thing that is wrong, whereas PR 28169 was talking about something that
wasn't a bug at all.
W.
--
http://gcc.gnu.org/bugzilla
--- Comment #3 from bangerth at dealii dot org 2006-10-12 02:06 ---
Forget this, the type of the rhs is of course an rvalue of type Base,
there is no need to copy the entire Derived object.
W.
--
bangerth at dealii dot org changed:
What|Removed
--- Comment #8 from bangerth at dealii dot org 2006-10-12 04:27 ---
I don't believe the code is valid.
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29408
--- Comment #8 from bangerth at dealii dot org 2006-10-12 19:55 ---
(In reply to comment #6)
Thank you for your answer, this is very interesting (but where is it
documented?).
In the gcc manual.
But still *very* dangerous, because the destructor of this unitialized object
--- Comment #2 from bangerth at dealii dot org 2006-10-17 05:45 ---
I can't either. The typical failure mode would have been an infinite
growth of memory usage, but I can't see this with any version I have.
It must be a RH specific problem...
--
bangerth at dealii dot org changed
--- Comment #9 from bangerth at dealii dot org 2006-10-21 04:28 ---
Mark,
is there any way for a backport of your patch to the 4.1 branch? This
appears to be a regression involving boost, and I got word from
people whose codes break with 4.1.x because of this...
Thanks
W
--- Comment #2 from bangerth at dealii dot org 2006-10-24 02:21 ---
I'm not completely sure who's right and wrong, but here's what's happening:
the second argument in the X case is an integer (the number zero), not
an int*. Consequently, the first template is not an exact match
--- Comment #6 from bangerth at dealii dot org 2006-10-26 06:34 ---
*** Bug 29593 has been marked as a duplicate of this bug. ***
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #2 from bangerth at dealii dot org 2006-10-26 06:34 ---
This is in fact a duplicate of PR 968.
*** This bug has been marked as a duplicate of 968 ***
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #3 from bangerth at dealii dot org 2006-10-26 06:34 ---
Ah shoot...
--
bangerth at dealii dot org changed:
What|Removed |Added
Status|RESOLVED
--- Comment #4 from bangerth at dealii dot org 2006-10-26 06:35 ---
I meant PR 986 :(
*** This bug has been marked as a duplicate of 986 ***
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #9 from bangerth at dealii dot org 2006-10-26 06:35 ---
*** Bug 29593 has been marked as a duplicate of this bug. ***
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #2 from bangerth at dealii dot org 2006-10-26 06:39 ---
To be more concrete: (int)(expression) rounds down. So if your quotient
of logarithms happens to be computed to 5.999, then you
will get a result of 5 after casting to int. You should round results,
not just
--- Comment #2 from bangerth at dealii dot org 2006-10-27 22:47 ---
Built-in types are not associated with any namespace. ADL therefore doesn't
apply to them -- name lookup proceeds from the present scope outward and
stops once a suitable name is found. This results in you getting all
--- Comment #1 from bangerth at dealii dot org 2006-10-27 22:57 ---
Confirmed.
--
bangerth at dealii dot org changed:
What|Removed |Added
CC
--- Comment #5 from bangerth at dealii dot org 2006-10-31 00:01 ---
(In reply to comment #0)
COtherClass(5, m_szSzField, NULL, 0,
ImmString1).Method1().Method2(m_ullProblemField)(ImmString2,
m_pvPointerField)(ImmString3, m_ullProblemField);
[...]
The problem
--- Comment #4 from bangerth at dealii dot org 2006-11-01 22:57 ---
You don't need a cast when converting to pointer, but the data
type of 0 is still int. When determining the type of a template
parameter, it therefore tries to to make the template parameter 'int'.
--
http
--- Comment #1 from bangerth at dealii dot org 2006-11-07 01:04 ---
Why exactly is this invalid again?
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #3 from bangerth at dealii dot org 2006-11-07 04:38 ---
(In reply to comment #2)
(In reply to comment #1)
Why exactly is this invalid again?
Because local types cannot be templates.
I don't think that's true. A local type cannot be a template
argument (14.3.1/2) but I
--- Comment #4 from bangerth at dealii dot org 2006-11-08 22:57 ---
This is a duplicate of another PR where we forget to substitute an
outer template argument in the specialization of an inner template.
I think it concerned a boolean value in that case, rather than a type.
W
--- Comment #6 from bangerth at dealii dot org 2006-11-09 05:25 ---
Indeed. They are duplicates.
*** This bug has been marked as a duplicate of 14032 ***
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #8 from bangerth at dealii dot org 2006-11-09 05:25 ---
*** Bug 29767 has been marked as a duplicate of this bug. ***
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #9 from bangerth at dealii dot org 2006-11-09 05:33 ---
PR29767 made me try whether we can achieve the same wrong effect for
template type parameters, and indeed we can:
template typename T struct outer {
template typename T2, typename U
struct
--- Comment #7 from bangerth at dealii dot org 2006-11-09 05:35 ---
(In reply to comment #0)
gcc and msvc accept such code but produces different results.
is this code (in)valid? i'm not sure what behaviour is correct.
The code is valid because it is a *partial* specialization
--- Comment #6 from bangerth at dealii dot org 2006-11-14 02:29 ---
(In reply to comment #5)
We can make a deal: I obfuscate and publish the code, you guys fix the
bug preserving, if possible, performance.
The code is really complex, and it's not realistic for me to make it smaller
--- Comment #2 from bangerth at dealii dot org 2006-11-14 03:45 ---
I believe the code is in fact invalid, based on 14.3.2/1 and this wording
in 14.3.2/5:
-- For a non-type template-parameter of type pointer to member
function, no conversions apply.
The latter
--- Comment #1 from bangerth at dealii dot org 2006-11-15 01:53 ---
There's two problems here: first, you are missing a template
in front of your definition. Second, you can't initialize
static variables with
type class::variable();
since this is ambiguous to declaring a function
--- Comment #2 from bangerth at dealii dot org 2006-11-15 01:59 ---
Confirmed.
(Note that in the actual code, Doh was boost::mutex::scoped_lock.
And I fear that using boost::mutex::scoped_lock like this is becoming
a widespread idiom.)
Ugh, this isn't an easy to read idiom...
W
--- Comment #4 from bangerth at dealii dot org 2006-11-15 02:09 ---
(In reply to comment #3)
14.3.2/1 says that a constant expression that evaluates to a null member
pointer value is allowed as a non-type template argument, with an explicit
reference to 4.11, which explains how
--- Comment #11 from bangerth at dealii dot org 2006-11-17 02:09 ---
I'm only a bug master and don't do any work on the compiler anyway, so my
say isn't worth much, but here's my take:
You propose that you can give us 15,000 lines of obfuscated code through which
we will have to dig
--- Comment #12 from bangerth at dealii dot org 2006-11-17 02:12 ---
(In reply to comment #11)
down, or to make the code significantly slower. Typically, the bug reports
^^ smaller, sorry W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
--- Additional Comments From bangerth at dealii dot org 2005-02-28 15:35
---
This seems to work with the latest version I have, which is from 20050130.
I don't know what's going on...
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20241
--- Additional Comments From bangerth at dealii dot org 2005-02-28 15:37
---
It also seems to be working with a snapshot from yesterday that I had on
another machine. Andrew, can you double-check with something newer?
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20241
--- Additional Comments From bangerth at dealii dot org 2005-02-28 15:47
---
Kriang is our resident expert on this. A shorter testcase is this:
---
class C;
namespace NS {
class A {
friend class C;
};
}
using namespace NS;
class C {};
C c
--
What|Removed |Added
Summary|incorrect error: class has |ambiguity with friend name
|not been declared |injection and using
--- Additional Comments From bangerth at dealii dot org 2005-02-28 15:53
---
I believe the code is invalid: you try to do a partial specialization of
a member function, but there is no such thing -- you need to use an overload
instead. To me this looks like an accept-invalid. Here's
--- 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
1 - 100 of 968 matches
Mail list logo
