--- Comment #7 from bangerth at dealii dot org 2009-01-23 19:31 ---
I see this as well. It triggers a lot when using boost::graph which
uses empty classes as tags all over the place. A simple case with
boost::graph would be this:
--
#include
using namespace
--- Comment #3 from bangerth at dealii dot org 2009-01-23 19:26 ---
I see this as well. It triggers a ton of time in boost::graph code.
I think it should have higher priority than P3.
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #7 from bangerth at dealii dot org 2009-01-18 03:58 ---
(In reply to comment #6)
> Maybe this issue isn't sufficiently clarified in the audit. Unless I'm badly
> mistaken (Jon, Chris will correct me), this is not a bug for a C++03 + TR1
> bind
>
--- Comment #5 from bangerth at dealii dot org 2009-01-17 01:41 ---
(In reply to comment #2)
> I'm seeing the same thing with Boost.Bind (boost 1.37, GCC 4.2.1).
boost.bind appears to work just fine for me, though!?
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35569
--- Comment #1 from bangerth at dealii dot org 2009-01-16 23:15 ---
Btw, the equivalent that uses boost::bind works just fine.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38889
Version: 4.4.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bangerth at dealii dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38889
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bangerth at dealii dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3
--- Comment #41 from bangerth at dealii dot org 2009-01-06 15:46 ---
(In reply to comment #40)
> I read all comments and saw a patch. But I don't know how I can fix my gcc
> with
> this patch.
The easiest way is to wait for gcc 4.4.
W.
--
http://gcc.gnu.org/bugzill
--- Comment #3 from bangerth at dealii dot org 2008-10-15 01:51 ---
(In reply to comment #2)
> bar the function shadows bar the variable. I think the warning is correct.
> The variable _bar is not being taken into account at all.
Ah, bummer, I didn't even look close en
--- Comment #1 from bangerth at dealii dot org 2008-10-15 01:38 ---
Note also that the documentation plainly states:
@item -Wshadow
@opindex Wshadow
@opindex Wno-shadow
Warn whenever a local variable shadows another local variable, parameter or
global variable or whenever a built-in
about variable names that aren't equal
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
Re
--- Comment #7 from bangerth at dealii dot org 2008-09-10 15:30 ---
Still the same with gcc version 4.4.0 20080801 (experimental) [trunk revision
138448]
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #12 from bangerth at dealii dot org 2008-09-10 15:26 ---
Still happens with gcc version 4.4.0 20080801 (experimental) [trunk revision
138448]
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #2 from bangerth at dealii dot org 2008-08-13 16:31 ---
(In reply to comment #1)
> I don't think this is a good warning really as static is used all over the
> place. In system headers and really in almost all C++ code in general.
The key is the phrase ".
--- Comment #5 from bangerth at dealii dot org 2008-08-13 16:27 ---
Confirmed. What I believe Andrew was pointing out are the internal reasons
why this warning happens. However, the warning is clearly bogus, the flag
-Wunreachable-code isn't useful if it warns on this sort of cod
--- Comment #4 from bangerth at dealii dot org 2008-08-13 16:24 ---
This also failed with 4.2.1, and the reporter's compiler was 4.0.
Paolo, do you want to apply your patch to 4.3.x as well? If not,
I vote for closing the PR: It's not a recent regression, it's an
ICE
--- Comment #2 from bangerth at dealii dot org 2008-08-13 16:21 ---
(In reply to comment #0)
> bool pred4(const char *, const char *, const char *x = "", const char *y =
> "");
The type of pred4 is still
bool (*) (const char *, const char *, const char *x,
--- Comment #1 from bangerth at dealii dot org 2008-08-13 16:17 ---
Confirmed.
--
bangerth at dealii dot org changed:
What|Removed |Added
CC
--- Comment #1 from bangerth at dealii dot org 2008-08-13 16:14 ---
(In reply to comment #0)
> By default, I suppose a -Wl,-rpath, would be useful...
No, since you can't override that and then you can't use another libstdc++
than the one that comes with the compiler you b
--- Comment #17 from bangerth at dealii dot org 2008-08-07 13:13 ---
(In reply to comment #16)
> The expression cannot be very complicated because it needs to be a
> INTEGER_CST.
Sure, but it can be of the form
~SOME_PREPROCESSOR_MACRO | (MACRO2 ^ MACRO3)
What I meant to
--- Comment #15 from bangerth at dealii dot org 2008-08-07 05:41 ---
Hi Manu,
just saw your patch for PR 12242 and have a comment: I believe the warning
message would be much better if it said *why* the result is unspecified (if the
expression being cast is a bit more complicated then
--- Comment #14 from bangerth at dealii dot org 2008-08-07 05:41 ---
Patch now here:
http://gcc.gnu.org/ml/gcc-patches/2008-08/msg00436.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12242
--- Comment #22 from bangerth at dealii dot org 2008-07-10 13:23 ---
(In reply to comment #21)
> > Two questions:
> > 1/ Is the text in the documentation that Dirk Mueller added in the last
> > commit
> >of PR 30601 now wrong/outdated?
>
> I don&#
--- Comment #20 from bangerth at dealii dot org 2008-07-10 03:40 ---
(In reply to comment #19)
> Fixed for 4.4.0.
Thanks a lot!
Two questions:
1/ Is the text in the documentation that Dirk Mueller added in the last commit
of PR 30601 now wrong/outdated?
2/ Does your patch also
--- Comment #15 from bangerth at dealii dot org 2008-07-10 03:38 ---
(In reply to comment #11)
> Subject: Re: [4.3 regression] -Wreturn-type warns about more
> than what the documentation says
>
>
> > I think this was done on purpose.
>
> It is contrary t
--- Comment #15 from bangerth at dealii dot org 2008-07-09 19:22 ---
(In reply to comment #14)
> Ah, I didn't consider this option! Seems also trivial to implement, just
> remove
> completely the pt.c version of the warning and keep the one in decl.c. Then,
> over the
--- Comment #10 from bangerth at dealii dot org 2008-07-09 17:04 ---
(In reply to comment #8)
> I was also trying to raise the issue of whether we think the warning is
> useful.
> If it's not practical to avoid the warning in the library, then I wonder if
> it's
--- Comment #5 from bangerth at dealii dot org 2008-07-07 23:36 ---
Zero-sized arrays are a GNU extension to the C++ standard. Since
the compiler can't know the size of the object, sizeof returns zero.
This behavior is documented in the "Extensions" part of the GCC
--- Comment #1 from bangerth at dealii dot org 2008-07-07 23:30 ---
Not a bug: type arguments to templates need to be *named* types with
external linkage. The declaration of 'x' uses an unnamed structure,
the declaration of 'z' a type of function-scope (and so i
--- Comment #2 from bangerth at dealii dot org 2008-07-07 23:17 ---
Yes, the code is indeed ambiguous. Both icc and pgCC also agree.
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #5 from bangerth at dealii dot org 2008-06-16 15:03 ---
This appears to work for me now with
gcc version 4.4.0 20080527 (experimental) [trunk revision 136055] (GCC)
Can you check whether it also works for you?
W.
--
bangerth at dealii dot org changed
--- Comment #11 from bangerth at dealii dot org 2008-05-11 03:32 ---
(In reply to comment #10)
> VC<6,7,8,9>
I suppose that's the compiler you should use then.
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36203
--- Comment #8 from bangerth at dealii dot org 2008-05-11 02:59 ---
(In reply to comment #7)
> That little bit of ambiguity bothers me a lot less that [...]
If that's your opinion, then you've never worked with large
software systems. Writing a few this-> here and t
--- Comment #6 from bangerth at dealii dot org 2008-05-11 02:17 ---
(In reply to comment #5)
> Yet Sun, IBM and Microsoft all somehow manage it.
But which function do they take in this case:
--
void f();
template struct B
{
void f();
};
template struct D
--- Comment #3 from bangerth at dealii dot org 2008-05-07 04:21 ---
How is the compiler supposed to know about what alignment malloc can
produce? How can it know that ::operator new doesn't increase the
alignment automatically?
W.
--
bangerth at dealii dot org ch
--- Comment #8 from bangerth at dealii dot org 2008-05-07 04:17 ---
The point is: without the complete source code nothing definitive can
be said whether it's the compiler's or the programmer's fault. Your chances
that someone will take the time to try to understand
--- Comment #3 from bangerth at dealii dot org 2008-04-26 00:25 ---
By the way, the return code of __cxa_demangle is
-2: mangled_name is not a valid name under the C++ ABI mangling rules.
as per
http://docs.mandragor.org/files/Programming_languages/Cpp
--- Comment #2 from bangerth at dealii dot org 2008-04-26 00:22 ---
Confirmed. The demangler gets a valid symbol it can't demangle.
W.
--
bangerth at dealii dot org changed:
What|Removed |
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bangerth at dealii dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36052
--- Comment #1 from bangerth at dealii dot org 2008-04-14 14:34 ---
You are asking for too much. The problem is that in your first example
the compiler knows that you want to call the grab() function and therefore
can give you an informative error message. But in the second example it
--- Comment #2 from bangerth at dealii dot org 2008-04-14 14:28 ---
(In reply to comment #1)
> I don't think this is a bug as you did not mark the operations on s
> as atomic.
Yes, exactly.
--
bangerth at dealii dot org changed:
What
--- Comment #1 from bangerth at dealii dot org 2008-04-14 14:21 ---
I too believe that z1.cc is valid. icc accepts it.
Not a regression, the code fails back to 2.95.
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #3 from bangerth at dealii dot org 2008-04-14 14:17 ---
Yes. Note that it requires an argument of *class* type, not *pointer to
class* type.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35929
--- Comment #2 from bangerth at dealii dot org 2008-04-01 14:54 ---
(In reply to comment #0)
> error_estimator.cc: In static member function 'static void
> KellyErrorEstimator::integrate_over_irregular_face(const
> DoFHandler&,
> const Quadrature<(dim - 1)&
--- Comment #1 from bangerth at dealii dot org 2008-03-31 20:07 ---
I tend to think that this should indeed work. Nice self-contained testcase!
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #5 from bangerth at dealii dot org 2008-03-31 19:54 ---
(In reply to comment #0)
> The following stripped down code shows pure virtual method definitions for
> both
> a normal base class and a templated base class. To my surprise, the templated
> class&
--- Comment #4 from bangerth at dealii dot org 2008-03-31 19:51 ---
(In reply to comment #3)
> I believe that the main problem here is that GCC allows defining pure virtual
> functions.
No, that's perfectly legal.
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33878
--- Comment #1 from bangerth at dealii dot org 2008-03-31 19:45 ---
Maybe so, but gcc only tries to implement what the C++ standard describes.
Please take your idea for this extension to the relevant standards committees.
--
bangerth at dealii dot org changed:
What
--- Comment #6 from bangerth at dealii dot org 2008-03-25 19:37 ---
It appears to work with "gcc version 4.4.0 20080317". Can you see if it
works for you as well with a more recent gcc version (either from top-of-tree
or the top of the 4.3 branch that you used in your experi
--- Comment #2 from bangerth at dealii dot org 2008-03-25 19:02 ---
Confirmed again. Funny enough, this works:
-
void f();
namespace N { using ::f; }
void h()
{
void (& b)() = N::f; // not ok
void (& c)() = *&N::f; // ok!?
}
-
W.
-
--- Comment #4 from bangerth at dealii dot org 2008-03-25 18:58 ---
I can't reproduce this with
tmp/g> /home/bangerth/bin/x86/gcc-mainline/bin/gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../mainline/configure
--prefix=/home/bangerth/bin/x86/gcc-
--- Comment #1 from bangerth at dealii dot org 2008-03-18 05:12 ---
What happens when you do this? And what are the header files you use?
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #2 from bangerth at dealii dot org 2008-03-05 02:55 ---
This is called two-stage name lookup: when parsing a template all occurrences
of "things" that do not depend on the template parameter are bound to their
global definitions. Thus, here...
> templat
--- Comment #21 from bangerth at dealii dot org 2008-02-27 16:52 ---
Can someone check which of the testcases now work and separate
those that don't into PRs of their own? This PR has become
a bit confusing.
W.
--
bangerth at dealii dot org changed:
What|Re
--- Comment #12 from bangerth at dealii dot org 2008-02-12 08:17 ---
The following variant of the testcase in comment #8 is definitely
valid but produces an ICE:
-
template struct policy {
typedef int unnecessary;
};
template struct A {
typedef
--- Comment #2 from bangerth at dealii dot org 2008-02-12 06:26 ---
Not a bug: The name of a member (static or not) without class qualification
can not be used in an address-of expression or decay to a pointer as
desired in the current context:
5.19/2:
Other expressions are
--- Comment #4 from bangerth at dealii dot org 2008-02-11 03:38 ---
(In reply to comment #3)
> While the original testcase works for me on trunk, the testcase in comment #2
> does
> not. Or am I missing sth?
I see the same behavior with yesterday's svn version. T
--- Comment #2 from bangerth at dealii dot org 2008-02-10 01:13 ---
Confirmed. This was introduced in 3.4.x, and worked before. As Andrew
already noted, this has been fixed in mainline.
The problem can be more succinctly shown by the following testcase:
template
--- Comment #4 from bangerth at dealii dot org 2008-02-08 21:59 ---
Can this be reproduced with gcc 4.2.x or current mainline?
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #4 from bangerth at dealii dot org 2008-02-08 21:51 ---
This should get higher priority than P3...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35138
--- Comment #13 from bangerth at dealii dot org 2008-02-06 01:19 ---
Re-confirmed here:
http://gcc.gnu.org/ml/gcc/2008-02/msg00066.html
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #10 from bangerth at dealii dot org 2008-02-02 04:07 ---
Sharad, what compiler version did you use for the new testcases?
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #3 from bangerth at dealii dot org 2008-01-31 14:53 ---
This way you make the compiler believe that all the functions
are in a namespace when the compiler that compiled these functions
into a .dll assumed that they are not. This can't work.
--
http://gcc.gn
--- Comment #8 from bangerth at dealii dot org 2008-01-30 20:26 ---
I agree. This is valid and common code and we need to be able to compile it.
I would rate this as a blocker.
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
NFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bangerth at dealii dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34927
--- Comment #10 from bangerth at dealii dot org 2008-01-22 22:08 ---
The patch was withdrawn.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17729
--- Comment #9 from bangerth at dealii dot org 2008-01-22 22:06 ---
Apparently fixed.
--
bangerth at dealii dot org changed:
What|Removed |Added
Status|NEW
--- Comment #4 from bangerth at dealii dot org 2008-01-21 22:01 ---
I don't know. What namespace are the parallel containers in, and
what namespace are the parallel algorithms in?
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33486
--- Comment #3 from bangerth at dealii dot org 2008-01-13 16:31 ---
(In reply to comment #2)
> i'd ask why the first code is invalid?
> class Y looks pretty complete so why typedef expression throws an error?
A class is complete at the closing brace. You use it befo
--- Comment #2 from bangerth at dealii dot org 2008-01-13 03:12 ---
So fixed. This is the error message one would expect.
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #1 from bangerth at dealii dot org 2008-01-13 03:10 ---
Confirmed. Here's a slightly simplified testcase:
---bar.h
typedef struct {
unsigned : 16;
unsigned : 16;
} foo;
---bar.c
#include
#include
foo bar(unsig
--- Comment #1 from bangerth at dealii dot org 2008-01-13 02:49 ---
Confirmed.
--
bangerth at dealii dot org changed:
What|Removed |Added
CC
--- Comment #3 from bangerth at dealii dot org 2008-01-13 02:45 ---
Indeed invalid.
--
bangerth at dealii dot org changed:
What|Removed |Added
CC
--- Comment #4 from bangerth at dealii dot org 2008-01-13 02:43 ---
Confirmed, but fixed in 4.2.x.
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #1 from bangerth at dealii dot org 2008-01-13 02:33 ---
What is the question you want to ask? The first code you show is invalid,
the second valid...
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #4 from bangerth at dealii dot org 2008-01-13 02:31 ---
(In reply to comment #0)
> template class X {};
>
> class Y {
> typedef X X;
> };
>
>
> produces the following error:
> redef.cpp:4: error: declaration of 'typedef class X Y::
--- Comment #3 from bangerth at dealii dot org 2008-01-13 02:29 ---
As per Andrew's comment, this is invalid.
--
bangerth at dealii dot org changed:
What|Removed |
--- Comment #1 from bangerth at dealii dot org 2008-01-13 02:25 ---
Confirmed.
--
bangerth at dealii dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #1 from bangerth at dealii dot org 2008-01-13 02:23 ---
Can you try to reduce this to something smaller that doesn't require
boost?
--
bangerth at dealii dot org changed:
What|Removed |
--- Comment #1 from bangerth at dealii dot org 2008-01-13 02:20 ---
Confirmed. The code should be rejected since the friend
declaration has only one template parameter, whereas
the template has two.
W.
--
bangerth at dealii dot org changed:
What|Removed
--- Comment #1 from bangerth at dealii dot org 2008-01-13 02:17 ---
Explicit specializations of member templates need to be declared
outside the declaration of the outer class, as per 14.7.3/2.
--
bangerth at dealii dot org changed:
What|Removed
--- Comment #1 from bangerth at dealii dot org 2008-01-13 02:12 ---
One could make the argument that the dllimport specifier is
a storage-class-specifier which, per 11.4/6 is not allowed on
the friend declaration. Since a friend function declaration
needs to be preceded by a declaration
--- Comment #2 from bangerth at dealii dot org 2008-01-13 02:02 ---
If the original warning is ever restored, please make it read
circular dependency in default argument
instead of the abbreviate language
circular dependency in default args
W.
--
bangerth at dealii dot org
--- Comment #1 from bangerth at dealii dot org 2008-01-07 17:34 ---
(In reply to comment #0)
> o << arg;
This line calls the global operator
ostream operator<< (ostream, char*)
whereas this one
> std::ostringstream::operator<<
--- Comment #4 from bangerth at dealii dot org 2007-12-13 22:54 ---
By the way, the size of the vector affects whether the testcase fails or
not. Apparently the algorithms decide that if the vector is too small
then it's not worth subdividing the work. On my 2-processor machine, 2
--- Comment #3 from bangerth at dealii dot org 2007-12-12 22:44 ---
(In reply to comment #2)
> Let's just close it if you can't reproduce now. I'll just try to run
> everything
> again some time from now and if I have the same problem again I'll re-open.
--- Comment #2 from bangerth at dealii dot org 2007-12-11 20:55 ---
(In reply to comment #1)
> Hey Wolfgang, I cannot reproduce this:
>
> g++ -g -O2 -march=native -fopenmp -D_GLIBCXX_PARALLEL 34059.cc
>
> Seems to run fine for me. I'm using
>
>
--- Comment #1 from bangerth at dealii dot org 2007-11-15 04:35 ---
Confirmed with gcc 2.95 and 4.2.1.
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #2 from bangerth at dealii dot org 2007-11-15 04:40 ---
It may also be that the compiler sees that the store is dead and
removes it. Did you check whether the store appears in the assembler
output?
W.
--
bangerth at dealii dot org changed:
What|Removed
--- Comment #1 from bangerth at dealii dot org 2007-11-15 04:38 ---
Confirmed, a regression introduced in 4.0.x.
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #2 from bangerth at dealii dot org 2007-11-15 04:33 ---
Confirmed with 2.95 and 4.2.1.
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #5 from bangerth at dealii dot org 2007-11-15 04:26 ---
So done.
--
bangerth at dealii dot org changed:
What|Removed |Added
Status|WAITING
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bangerth at dealii dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34095
--- Comment #1 from bangerth at dealii dot org 2007-10-20 23:36 ---
The code should be invalid precisely because this is also invalid:
---
template struct A;
void foo()
{
A<0>;
}
---
g/x> c++ -c x.cc
x.cc: In function 'void foo()&#
--- Comment #4 from bangerth at dealii dot org 2007-10-19 23:54 ---
This is the shortest I can come up with:
--
template
struct __attribute__((visibility("default"))) List {};
int bar(List args);
bool test(const List &);
int i = bar(List());
bool t
--- Comment #12 from bangerth at dealii dot org 2007-10-18 18:46 ---
Yes, sorry. I meant to report of course that I believe that it works now.
Thanks for your work!
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33489
--- Comment #4 from bangerth at dealii dot org 2007-10-12 15:21 ---
(In reply to comment #3)
> (I'm told that) these two function-style casts compile fine on 4.2.1:
>
> template
> struct A {
> };
>
> A y;
> A z;
Uh, indeed, I see. This is weird indeed. S
--- Comment #7 from bangerth at dealii dot org 2007-10-12 15:16 ---
This used to be a GCC extension in the old days, which may explain
why it isn't rejected by default. I believe it was deprecated several
releases ago, you may find something to that effect in release notes.
--- Comment #2 from bangerth at dealii dot org 2007-10-12 13:04 ---
The rule for template non-type arguments of integral type is 14.3.2/1:
1 A template-argument for a non-type, non-template template-parameter
shall be one of:
-- an integral constant-expression of integral or
--- Comment #1 from bangerth at dealii dot org 2007-10-12 12:52 ---
It's not the parentheses or the greater-than sign, but the cast
that triggers the error. I will have to look up whether a cast
is allowed here. For reference, icc accepts the code.
W.
--
bangerth at dealii do
1 - 100 of 972 matches
Mail list logo
