--- 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/bug
--- 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 #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 #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 #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 #1 from bangerth at dealii dot org 2008-08-13 16:17 ---
Confirmed.
--
bangerth at dealii dot org changed:
What|Removed |Added
CC
--- 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 #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 #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 #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 #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 #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
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 #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
--- 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 #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 #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 #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
I get a duplicate error message for this code:
--
class A {};
struct C : A
{
virtual ~C () = 0;
} c;
-
bangerth/tmp> c++ -c x.cc
x.cc:6: error: cannot declare variable 'c' to be of abstract type 'C'
x.cc:4: note: because the following vir
--- 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
--- 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 #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 #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 #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 #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-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-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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #4 from bangerth at gmail dot com 2009-02-01 05:07 ---
Confirmed indeed, with this (linker) error message:
g/x> c++ x.cc
/tmp/ccjPvb3J.o: In function `main':
x.cc:(.text+0x12): undefined reference to `Function()'
collect2: ld returned 1 exit status
This alrea
--- Comment #1 from bangerth at gmail dot com 2009-02-01 05:18 ---
Confirmed.
--
bangerth at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #1 from bangerth at gmail dot com 2009-02-12 23:17 ---
Confirmed:
g/x> /home/bangerth/bin/x86/gcc-mainline/bin/c++ -c x.cc
x.cc: In function 'int main()':
x.cc:3: internal compiler error: in write_builtin_type, at cp/mangle.c:1855
Please submit a full bug
--- Comment #2 from bangerth at gmail dot com 2009-02-12 23:21 ---
I do get an ICE:
g/x> /home/bangerth/bin/x86/gcc-mainline/bin/c++ -c x.cc
x.cc: In instantiation of 'const int junk::value':
x.cc:6: instantiated from here
x.cc:4: internal compiler error: Segmentation
--- Comment #2 from bangerth at gmail dot com 2009-02-12 23:23 ---
I think the code is invalid. The name 'i' is non-dependent, so shouldn't
it be bound to the member variable at the point of definition?
W.
--
bangerth at gmail dot com changed:
W
--- Comment #4 from bangerth at gmail dot com 2009-02-12 23:21 ---
Confirmed.
--
bangerth at gmail dot com changed:
What|Removed |Added
CC
--- Comment #4 from bangerth at gmail dot com 2009-02-13 00:12 ---
Confirmed, it also ICEs on mainline.
That's a much more serious case. I'm not entirely sure whether the code
is valid: you do
template static Z& y();
template static char test(typeof(y())*);
with Y
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bangerth at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39269
--- Comment #3 from bangerth at gmail dot com 2009-04-02 22:05 ---
Andrew is right:
> static inline bool Read( const char* Str, int& v )
> { v = 0; return true; }
>
> template< class T >
> static inline bool Read( const char* Str, std::vector<
--- Comment #2 from bangerth at gmail dot com 2009-04-08 13:11 ---
The testcase is indeed invalid. We should reject it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39684
--- Comment #8 from bangerth at gmail dot com 2009-04-08 23:10 ---
We're about 8 generations of gcc later now. Is this still true? Still
20,000 cycles?
W.
--
bangerth at gmail dot com changed:
What|Removed |
Wrong "value computed is not used"
warning
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
--- Comment #1 from bangerth at gmail dot com 2009-04-26 17:10 ---
Jakub,
does your patch also fix PR 39875?
Thanks
W.
--
bangerth at gmail dot com changed:
What|Removed |Added
--- Comment #1 from bangerth at gmail dot com 2009-04-26 17:10 ---
May be related to PR 39889.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39875
--- Comment #10 from bangerth at gmail dot com 2009-04-29 12:51 ---
There is really nothing much that can be done within the current C++
standard. In C, NULL is defined as
(void*)0
which can be converted to any other pointer and so is clearly marked
as a pointer. The compiler can
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56257
Bug #: 56257
Summary: std::vector allows access to the elements of
_Vector_base
Classification: Unclassified
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56257
--- Comment #3 from Wolfgang Bangerth 2013-02-09
21:37:55 UTC ---
:-) Sure, and of course I did tell him "don't do that". In essence it's a
question of how easy it is to shoot yourself in the foot by exposing inte
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33415
--- Comment #9 from Wolfgang Bangerth 2013-03-25
13:50:00 UTC ---
Vikas: This was fixed in GCC in 2008. The version of GCC you are using (3.4.6)
was released in 2006 and the entire 3.4.x tree is in fact from 2004. It is time
for you to
;
subdomain_indices.insert(subdomain_indices.end(),
local_dof_indices.begin(),
local_dof_indices.end());
}
..
>>>> /home/bangerth/bin/gcc-mainline/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/home/bang
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54575
--- Comment #4 from Wolfgang Bangerth 2012-09-14
11:48:56 UTC ---
Would this do? ;-)
..
template
struct is_convertible { static const bool value = true; };
template struct enable_if { };
template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54575
--- Comment #13 from Wolfgang Bangerth 2012-09-18
15:32:17 UTC ---
Thanks, all, for the quick turnaround. This works again, not just on the
testcase but on the entire code base.
Best
W.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54994
Bug #: 54994
Summary: [4.8 regression] New ICE in tsubst_copy
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54844
Wolfgang Bangerth changed:
What|Removed |Added
CC||bangerth at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54844
--- Comment #10 from Wolfgang Bangerth 2012-10-22
11:58:58 UTC ---
Given that this bug has been found 3 times already (and I extracted my testcase
from the widely used BOOST library), is there an ETA for a fix?
W.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54844
--- Comment #12 from Wolfgang Bangerth 2012-10-22
13:05:36 UTC ---
Thanks, Jakub!
rmal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bangerth at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41109
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bangerth at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41110
--- Comment #1 from bangerth at gmail dot com 2009-08-20 20:40 ---
Jason, might this be a result of your changes to used/unused variables?
W.
--
bangerth at gmail dot com changed:
What|Removed |Added
--- Comment #1 from bangerth at gmail dot com 2009-08-20 20:41 ---
Jason, might this be a result of your changes to used/unused variables?
W.
--
bangerth at gmail dot com changed:
What|Removed |Added
cc dot gnu dot org
ReportedBy: bangerth at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41134
--- Comment #2 from bangerth at gmail dot com 2009-08-20 20:47 ---
(In reply to comment #1)
> Well this is invalid code that is accepted by GCC anyways
How so??
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41134
--- Comment #4 from bangerth at gmail dot com 2009-08-20 20:54 ---
(In reply to comment #3)
> You cannot use a static variable in a template :).
I would be unaware of that restriction. It's true that you can't use objects
with internal linkage (such as static variables)
--- Comment #6 from bangerth at gmail dot com 2009-08-20 21:20 ---
(In reply to comment #5)
> Why is this a regression? Which compiler version didn't warn here?
4.3.2. Current mainline warns.
> The question is really whether we want unused variables just in the case
>
--- Comment #5 from bangerth at gmail dot com 2009-08-24 22:37 ---
Thanks a lot for the quick turnaround, Jason!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41109
--- Comment #1 from bangerth at gmail dot com 2009-08-25 04:12 ---
It looks like your terminating double quote is not the same as the
opening one. How are they encoded on your system?
--
bangerth at gmail dot com changed:
What|Removed |Added
--- Comment #1 from bangerth at gmail dot com 2009-08-25 04:21 ---
This is the way C++ works. The copy constructor must be available.
(The compiler doesn't have to actually call it, but it must be
available.)
--
bangerth at gmail dot com changed:
What|Re
--- Comment #1 from bangerth at gmail dot com 2009-08-25 04:23 ---
Yes.
--
bangerth at gmail dot com changed:
What|Removed |Added
CC
--
bangerth at gmail dot com changed:
What|Removed |Added
CC||bangerth at gmail dot com
Status|UNCONFIRMED
--- Comment #2 from bangerth at gmail dot com 2009-08-25 13:24 ---
Why would this be ambiguous? A string literal has type "array of n const char"
(see 2.13.4/1), so it should go with the array constructor. Do you disagree?
W.
--
bangerth at gmail dot com changed:
--- Comment #8 from bangerth at gmail dot com 2009-08-25 13:27 ---
Already confirmed.
--
bangerth at gmail dot com changed:
What|Removed |Added
CC
--- Comment #7 from bangerth at gmail dot com 2009-08-25 13:29 ---
I would think so.
--
bangerth at gmail dot com changed:
What|Removed |Added
Status
--- Comment #4 from bangerth at gmail dot com 2009-08-25 13:31 ---
*** Bug 41104 has been marked as a duplicate of this bug. ***
--
bangerth at gmail dot com changed:
What|Removed |Added
--- Comment #1 from bangerth at gmail dot com 2009-08-25 13:31 ---
Yes, I think this is an exact duplicate.
*** This bug has been marked as a duplicate of 23055 ***
--
bangerth at gmail dot com changed:
What|Removed |Added
--- Comment #10 from bangerth at gmail dot com 2009-08-25 13:39 ---
Was already confirmed.
--
bangerth at gmail dot com changed:
What|Removed |Added
CC
--- Comment #1 from bangerth at gmail dot com 2009-08-25 13:43 ---
This is an interesting one:
enum EE {ee};
struct D {
enum EE : 8;
};
In C++98, this looks like an unnamed bit field as part of struct D, but
with C++0x we
--- Comment #3 from bangerth at gmail dot com 2009-08-25 13:45 ---
Agreed -- I do get the warning from current mainline as well.
--
bangerth at gmail dot com changed:
What|Removed |Added
--- Comment #1 from bangerth at gmail dot com 2009-08-25 13:46 ---
Please follow the instructions listed in <http://gcc.gnu.org/bugs.html> as
mentioned by the error message. In particular, we need a preprocessed
testcase.
--
bangerth at gmail dot com changed:
--- Comment #6 from bangerth at gmail dot com 2009-08-25 13:58 ---
Confirmed.
Nathan, is this the bug you had worked on? If so, it may be of interest to
add a link to your patch to this PR for reference.
W.
--
bangerth at gmail dot com changed:
What|Removed
--- Comment #4 from bangerth at gmail dot com 2009-08-25 13:59 ---
gcc 3.3 has not been maintained for a long time. Since you say that gcc 4.0
fixes the bug, I think we can close the bug.
W.
--
bangerth at gmail dot com changed:
What|Removed
--
bangerth at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41161
--- Comment #3 from bangerth at gmail dot com 2009-08-25 13:54 ---
Hm, can you try to come up with a smaller testcase for which it may be a bit
simpler to see what is going on?
Thanks
W.
--
bangerth at gmail dot com changed:
What|Removed |Added
--- Comment #2 from bangerth at gmail dot com 2009-08-25 14:04 ---
Confirmed:
-
class A {
template struct s {
enum { value };
};
};
int i = A::s<10>::value;
-
This should produce an error but doesn
--- Comment #1 from bangerth at gmail dot com 2009-08-25 14:10 ---
Confirmed.
--
bangerth at gmail dot com changed:
What|Removed |Added
CC
--- Comment #1 from bangerth at gmail dot com 2009-08-25 14:13 ---
With current mainline, I just get these errors:
g/x> /home/bangerth/bin/x86/gcc-mainline/bin/c++ x.cc -std=c++0x
x.cc:4:36: error: '__int128_t' was not declared in this scope
x.cc:5:36: error: '__
--- Comment #1 from bangerth at gmail dot com 2009-08-25 14:15 ---
Confirmed. Very odd.
--
bangerth at gmail dot com changed:
What|Removed |Added
CC
--- Comment #1 from bangerth at gmail dot com 2009-08-25 14:16 ---
Confirmed. An ICE. I haven't checked the accepts-invalid part.
--
bangerth at gmail dot com changed:
What|Removed |
--- Comment #5 from bangerth at gmail dot com 2009-08-25 14:25 ---
Jonathan, the point everyone is trying to make is this: since no function
or function template matches the call, all the compiler could possibly
do is list all declarations of the name staticPrint() or none, but of
--- Comment #2 from bangerth at gmail dot com 2009-08-25 14:39 ---
Hm, confusing:
-
enum E {e};
struct A {
A(int);
explicit A(E) {};
};
int main () { A a = e; }
-
This compiles but not links becase A::A(int) is called. If
--- Comment #1 from bangerth at gmail dot com 2009-08-25 15:24 ---
Confirmed:
-
template struct Base {
template class I
--- Comment #3 from bangerth at gmail dot com 2009-08-25 15:26 ---
Confirmed with gcc4.2.1.
W.
--
bangerth at gmail dot com changed:
What|Removed |Added
Last
401 - 500 of 1203 matches
Mail list logo
