--- Comment #5 from bangerth at gmail dot com 2009-01-27 16:00 ---
Richard,
this isn't a duplicate of PR 38851: while the testcase there indeed now
passes, the one in the current PR still fails.
Best
Wolfgang
--
bangerth at gmail dot com changed:
What|Re
--
bangerth at gmail dot com changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38908
--- Comment #9 from bangerth at gmail dot com 2009-01-28 17:27 ---
Created an attachment (id=17203)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17203&action=view)
Failing testcase
Richard,
I hate to break the news to you but there are even more cases. Attached
is a fi
--- Comment #10 from bangerth at gmail dot com 2009-01-28 17:28 ---
Re-open
--
bangerth at gmail dot com changed:
What|Removed |Added
Status|RESOLVED
--- Comment #5 from bangerth at gmail dot com 2009-01-30 15:00 ---
(In reply to comment #4)
> However, I'm still analyzing whether we really want to reject. As data points,
> ICC doesn't, even in strict mode; on the other hand Comeau rejects the
> identifier "
--- Comment #3 from bangerth at gmail dot com 2009-01-30 15:03 ---
This is probably related to PR 2288.
--
bangerth at gmail dot com changed:
What|Removed |Added
--- Comment #5 from bangerth at gmail dot com 2009-01-30 15:05 ---
*** Bug 39038 has been marked as a duplicate of this bug. ***
--
bangerth at gmail dot com changed:
What|Removed |Added
--- Comment #4 from bangerth at gmail dot com 2009-01-30 15:05 ---
*** This bug has been marked as a duplicate of 18770 ***
--
bangerth at gmail dot com changed:
What|Removed |Added
--- Comment #1 from bangerth at gmail dot com 2009-01-30 15:13 ---
Yes, I think this would be an optimizing compiler could potentially perform.
At the same time I think you are expecting too much from the compiler: it
would have to have a semantic understanding of what the strlen
--- Comment #1 from bangerth at gmail dot com 2009-01-30 15:20 ---
Confirmed. The original testcase had a function argument of type
pointer-to-pointer-to-array-of-unknown-size, but this testcase
also fails:
template
bool f (T_ p);
bool g ()
{ return f(0
--
bangerth at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed
--- Comment #1 from bangerth at gmail dot com 2009-01-30 15:23 ---
Confirmed.
--
bangerth at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #1 from bangerth at gmail dot com 2009-01-30 15:27 ---
Confirmed. This used to work in 4.1 where we got the following error
(which does not earn the prize for the prettiest error message ever):
g/x> /home/bangerth/bin/gcc-4.1.1/bin/c++ -c x.cc
x.cc: In function '
--- Comment #2 from bangerth at gmail dot com 2009-01-30 15:28 ---
Thinking some more about it, I believe that the code is actually valid.
icc accepts it, for comparison.
W.
--
bangerth at gmail dot com changed:
What|Removed |Added
--- Comment #5 from bangerth at gmail dot com 2009-01-30 15:29 ---
I think Jason confirmed this already...
--
bangerth at gmail dot com changed:
What|Removed |Added
--- Comment #10 from bangerth at gmail dot com 2009-01-30 15:37 ---
(In reply to comment #9)
> Following the twisted maze that is BOOST_CLASS_EXPORT() leads me to think that
> it is (very) roughly equivalent to this:
>
> void dummy(boost::archive::xml_iarchive &
--- Comment #3 from bangerth at gmail dot com 2009-01-30 15:45 ---
Confirmed. There is no need to convolve error messages like that.
W.
--
bangerth at gmail dot com changed:
What|Removed |Added
--- Comment #16 from bangerth at gmail dot com 2009-01-30 15:49 ---
(In reply to comment #5)
> Excuse me, but I do not understand what makes this code invalid. Could anybody
> explain? If so, does this apply to all the test cases given (also for bugs
> that
> are marked a
--- Comment #17 from bangerth at gmail dot com 2009-01-30 15:51 ---
*** Bug 38681 has been marked as a duplicate of this bug. ***
--
bangerth at gmail dot com changed:
What|Removed |Added
--- Comment #7 from bangerth at gmail dot com 2009-01-30 15:51 ---
(In reply to comment #5)
> Did I understand this wrong ? Does the correct interpretation of the standard
> not allow for member-function-pointers as non-type arguments ?
It does, but it requires them to be in a co
--- Comment #2 from bangerth at gmail dot com 2009-01-30 15:58 ---
The standard details certain side effects of throwing exceptions such
as allocating and freeing memory as well as setting expressions that
std::uncaught_exception can evaluate. These side effects can not
always be
--- Comment #2 from bangerth at gmail dot com 2009-01-30 16:02 ---
Confirmed. Gcc would have to keep track of the actual types of variables.
W.
--
bangerth at gmail dot com changed:
What|Removed |Added
gcc dot gnu dot org
ReportedBy: bangerth at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40155
--- Comment #1 from bangerth at gmail dot com 2009-05-15 02:56 ---
Oh, should've said:
g/x> /home/bangerth/bin/x86/gcc-mainline/bin/c++ -std=c++0x -c x.cc
x.cc:9: error: invalid conversion from 'int (*)(double)' to 'int (*)()'
x.cc:5: error: too man
tus: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bangerth at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40642
--- Comment #6 from bangerth at gmail dot com 2009-07-06 20:56 ---
(In reply to comment #3)
I had to stare at the testcase in comment #3 for a little while and thought
others may have to as well: it fails because the inheritance from Base is
*private*, not because the dynamically
--- Comment #4 from bangerth at gmail dot com 2009-08-05 17:54 ---
(In reply to comment #3)
> &c.f isn't even valid, it should be &C::f
>
> I didn't check the code, but that message isn't used for member variables or
> nested types, so if it does on
--- Comment #5 from bangerth at gmail dot com 2009-08-05 17:57 ---
However, one of my gripes with the previous error message is that it's
just too obscure: where did I forget the '&', and why would I have wanted
to write them in the first place? It could have said
--- Comment #7 from bangerth at gmail dot com 2009-08-05 18:47 ---
(In reply to comment #6)
> Examples where the ampersand probably makes more sense are:
>
> g++.dg/rtti/typeid8.C
> g++.dg/conversion/memfn2.C
> g++.old-deja/g++.other/asm2.C
Possibly, but in all thos
--- 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 internal
details of the implem
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 upg
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54575
Bug #: 54575
Summary: ICE with std::vector::insert and -std=c++11
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priori
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<> s
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
--- Comment #3 from bangerth at gmail dot com 2009-08-25 15:30 ---
Can you try to come up with a smaller, possibly self-contained testcase
that would make it simpler for us to determine what's going on? Take a
look here regarding what would help us:
http://gcc.gnu.org/bugs.ht
--- Comment #2 from bangerth at gmail dot com 2009-08-25 15:31 ---
Confirmed. A regression.
--
bangerth at gmail dot com changed:
What|Removed |Added
CC
--- Comment #1 from bangerth at gmail dot com 2009-08-25 15:33 ---
That would require that the ABI specifies such a mangling. I'm not sure
anyone wants to go that route.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40527
--- Comment #1 from bangerth at gmail dot com 2009-08-25 15:34 ---
Confirmed.
--
bangerth at gmail dot com changed:
What|Removed |Added
CC
--- Comment #2 from bangerth at gmail dot com 2009-08-25 15:35 ---
Confirmed.
--
bangerth at gmail dot com changed:
What|Removed |Added
CC
--- Comment #1 from bangerth at gmail dot com 2009-08-25 15:35 ---
Confirmed.
--
bangerth at gmail dot com changed:
What|Removed |Added
CC
--- Comment #1 from bangerth at gmail dot com 2009-08-25 15:39 ---
Hm, interesting. I would have thought as well that the code should compile.
On the other hand, icc also produces the same error message, so I am now
officially confused...
--
bangerth at gmail dot com changed
--- Comment #3 from bangerth at gmail dot com 2009-08-25 15:40 ---
Also works on gcc4.3.2, so apparently fixed everywhere.
--
bangerth at gmail dot com changed:
What|Removed |Added
--- Comment #1 from bangerth at gmail dot com 2009-08-25 15:42 ---
Yes, this is confusing.
--
bangerth at gmail dot com changed:
What|Removed |Added
CC
--- Comment #1 from bangerth at gmail dot com 2009-08-25 15:44 ---
Confirmed. Not a regression.
--
bangerth at gmail dot com changed:
What|Removed |Added
--- Comment #1 from bangerth at gmail dot com 2009-08-25 15:49 ---
Confirmed.
--
bangerth at gmail dot com changed:
What|Removed |Added
CC
1 - 100 of 189 matches
Mail list logo
