--- 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 class T = int struct policy {
typedef int unnecessary;
};
template class
--
bangerth at dealii dot org changed:
What|Removed |Added
CC||bangerth at dealii dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #10 from bangerth at dealii dot org 2007-02-16 18:39 ---
This is a duplicate of PR14032, which has more information on the matter
than the present one.
W.
*** This bug has been marked as a duplicate of 14032 ***
--
bangerth at dealii dot org changed:
What
--- Comment #1 from bangerth at dealii dot org 2007-01-21 05:34 ---
Confirmed.
--
bangerth at dealii dot org changed:
What|Removed |Added
CC
--- 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 #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
--- You are receiving this mail because: ---
You reported the bug, or are watching the reporter
--
Bug 10891 depends on bug 28687, which changed state.
Bug 28687 Summary: [4.2 regression] dynamic_castvoid* disallowed too
rigorously with -fno-rtti
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28687
What|Old Value |New Value
--- Comment #3 from bangerth at dealii dot org 2006-01-10 22:40 ---
Confirmed, but this is already fixed as of 3.4.6 20060102 (prerelease)
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25744
--- You are receiving this mail because: ---
You are on the CC list
--- Additional Comments From bangerth at dealii dot org 2005-09-15 17:56
---
This is what I come up with:
---
template int struct X {};
template typename T struct length {
static const int value = 2;
};
template typename T void foo () {
sizeof(XlengthT
--- Additional Comments From bangerth at dealii dot org 2004-12-15 14:10
---
I can't reproduce this. Can you post the exact output of gcc -v?
Thanks
Wolfgang
--
What|Removed |Added
--- Additional Comments From bangerth at dealii dot org 2004-10-15 14:50
---
This is a duplicate of PR 4882.
W.
*** This bug has been marked as a duplicate of 4882 ***
--
What|Removed |Added
--- Additional Comments From bangerth at dealii dot org 2004-10-15 14:50
---
*** Bug 18007 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From bangerth at dealii dot org 2004-10-15 14:53
---
Likely related to PR 10574.
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4882
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.
--- Additional Comments From bangerth at dealii dot org 2004-10-15 14:56
---
There quite some discussion on this matter in PR 13088.
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4882
--- You are receiving this mail because: ---
You are on the CC list for the bug
--- Additional Comments From bangerth at dealii dot org 2004-08-27 13:27
---
*** Bug 17208 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From bangerth at dealii dot org 2004-08-18 12:58
---
PR 17071 has this very nice and clean testcase.
--
int foo (int);
template class T T foo (T, T);
template class T, class U int bar (T, U);
int main ()
{
bar (0, foo
--- Additional Comments From bangerth at dealii dot org 2004-07-29 14:50
---
Andrew: I get an ICE in exactly the same position for both Volker's
and my testcase. Are you sure they started at different times? Or
did you mean that you compared one of our testcases with the original
one
--
What|Removed |Added
Known to fail||3.4.0 3.5.0
Known to work||3.2.3 3.3.4
Summary|[3.4/3.5
--- Additional Comments From bangerth at dealii dot org 2004-06-16 20:20
---
Confirmed with 3.3.4 and 3.4:
g/x /home/bangerth/bin/gcc-3.3.4-pre/bin/c++ -c x.cc -Wall
x.cc: En function `int foo(char*)':
x.cc:6: aviso: se ignora
Error interno del compilador: Error al reportar
--- Additional Comments From bangerth at dealii dot org 2004-06-01 14:37
---
I also find the message overly terse. The abbreviated form arg for
argument sounds too much like an unquoted reference to a variable.
Why can't we speak English as in most other messages, for example
--- Additional Comments From bangerth at dealii dot org 2004-06-01 15:52
---
Sounds pretty good to me :-)
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1027
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.
--- Additional Comments From bangerth at dealii dot org 2004-05-14 22:57
---
(As noted in PR 15426)
Actually, this bug isn't fixed. With the testcase in comment #10,
I still get an ICE when using -g:
g/x /home/bangerth/bin/gcc-3.5-pre/bin/c++ -c x.cc -g
x.cc: In function
--- Additional Comments From bangerth at dealii dot org 2004-05-11 18:38
---
A patch was submitted here:
http://gcc.gnu.org/ml/gcc-patches/2004-05/msg00599.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15214
--- You are receiving this mail because: ---
You
--- Additional Comments From bangerth at dealii dot org 2004-05-11 18:53
---
I don't quite understand the usefulness of the construct you want the
compiler to accept: if the destructor can't be called from a derived
class, then you can derive from this class. Why would you want
--- Additional Comments From bangerth at dealii dot org 2004-05-11 19:23
---
Ah, ok. Basically what you do is to mark the class final, i.e. no
other class can derive from it. I think your claim then makes sense.
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15214
--- Additional Comments From bangerth at dealii dot org 2004-03-29 16:33
---
Gaby: are you aware of this regression on the 3.3 branch due to a
backported patch? We could avoid this is we undo the regression
by reverting the backport and simply stick with the breakage
of PR 10776
--- Additional Comments From bangerth at dealii dot org 2004-03-29 22:33
---
Uncomfirmed here only means that we have no small testcase, which is one
of our requirements to put something into confirmed mode. It is
certainly on our radar!
W.
--
http://gcc.gnu.org/bugzilla
--- Additional Comments From bangerth at dealii dot org 2004-03-24 15:34
---
This section might even benefit from some of the words we have on our
web pages about the effects of excess precision.
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14708
--- You are receiving
--- Additional Comments From bangerth at dealii dot org 2004-03-24 15:42
---
Ugh, I've reduced bug reports with close to 100k lines, but this one has more
than 500k, and it takes forever to compile even without optimization.
However, it seems like a very good candidate for delta
--- Additional Comments From bangerth at dealii dot org 2004-03-24 17:06
---
That's very impressive you find it so quickly, guys!
BTW: we get PRs with testcases in the range of 80k lines not infrequently.
If 500k is getting us into trouble, this is not a huge margin, and we should
--- Additional Comments From bangerth at dealii dot org 2004-03-24 17:47
---
So given my own comment #9, do we have to expect testcases with 4e9
lines anytime soon? I hate to think about the implications on my
private life reducing such testcases might have...
--
http
--- Additional Comments From bangerth at dealii dot org 2004-03-19 19:56
---
I don't consider this as a bug. I'd just close it.
Note that there is not much we can do about it: we can't say that there is an
attempt
to bind an rvalue to a non-const reference, because this would imply
--- Additional Comments From bangerth at dealii dot org 2004-03-11 15:51
---
The let's reopen the bug. I keep wondering why there is such resistance
to really small patches like the one needed for this PR...
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14493
--- You
--- Additional Comments From bangerth at dealii dot org 2004-03-11 15:52
---
.
--
What|Removed |Added
Status|RESOLVED|REOPENED
--- Additional Comments From bangerth at dealii dot org 2004-02-19 00:26
---
Confirmed. Here's something a little smaller:
---
int* foo();
const bool b = false;
int main() {
int i;
if (b)
if (int* p = foo())
{
int bla
--- Additional Comments From bangerth at dealii dot org 2004-02-02 23:16
---
This is a duplicate of PR 13924.
W.
*** This bug has been marked as a duplicate of 13924 ***
--
What|Removed |Added
--- Additional Comments From bangerth at dealii dot org 2004-02-02 23:16
---
*** Bug 13943 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From bangerth at dealii dot org 2004-02-02 23:18
---
I think I remember that there is a duplicate of this and that it
was stated that it is up to the implementation what it does in
this case: the problem is throwing while generating the argument
to a throw
--- Additional Comments From bangerth at dealii dot org 2004-01-12 17:05
---
This is silly. Richard is the maintainer of this target. He should have
the right to set the severity of this PR.
W.
--
What|Removed |Added
PLEASE REPLY TO [EMAIL PROTECTED] ONLY, *NOT* [EMAIL PROTECTED]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12421
--- Additional Comments From bangerth at dealii dot org 2003-09-26 17:46
---
Confirmed also on x86-linux, but I don't presently have the time to
reduce the testcase so I
PLEASE REPLY TO [EMAIL PROTECTED] ONLY, *NOT* [EMAIL PROTECTED]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11984
bangerth at dealii dot org changed:
What|Removed |Added
PLEASE REPLY TO [EMAIL PROTECTED] ONLY, *NOT* [EMAIL PROTECTED]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11437
bangerth at dealii dot org changed:
What|Removed |Added
PLEASE REPLY TO [EMAIL PROTECTED] ONLY, *NOT* [EMAIL PROTECTED]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11437
--- Additional Comments From bangerth at dealii dot org 2003-07-12 23:54
---
OK, the new report is now PR 11510.
W.
--- You are receiving this mail because
)
(and a host of other errors later on, but this one is for T=CWord1). So change
the order of declarations of your classes (and the use of CPtrCWord1) and
it should work just fine.
W.
-
Wolfgang Bangerth email
PLEASE REPLY TO [EMAIL PROTECTED] ONLY, *NOT* [EMAIL PROTECTED]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11444
bangerth at dealii dot org changed:
What|Removed |Added
PLEASE REPLY TO [EMAIL PROTECTED] ONLY, *NOT* [EMAIL PROTECTED]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11437
bangerth at dealii dot org changed:
What|Removed |Added
PLEASE REPLY TO [EMAIL PROTECTED] ONLY, *NOT* [EMAIL PROTECTED]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11437
--- Additional Comments From bangerth at dealii dot org 2003-07-04 21:54
---
I forgot to say: I don't know whether the code is legal, but
it shouldn't ICE anyway
if you could submit a patch! Thanks!
-
Wolfgang Bangerth email:[EMAIL PROTECTED]
www: http://www.ticam.utexas.edu/~bangerth/
Synopsis: -Wconversion should be split into two distinct flags
State-Changed-From-To: open-analyzed
State-Changed-By: bangerth
State-Changed-When: Sun Feb 2 22:54:20 2003
State-Changed-Why:
Has been analyzed. Patch is even in the audit trail, but
seems to have become stuck in gcc's patch
Synopsis: warn about asserts with side effects
State-Changed-From-To: open-feedback
State-Changed-By: bangerth
State-Changed-When: Tue Jan 7 17:40:58 2003
State-Changed-Why:
As much as I sympathize with the goal of such a warning, I
doubt it will be possible to implement it. The reason
Synopsis: cc allows dollars in identifiers by default on i386 but fails
State-Changed-From-To: open-analyzed
State-Changed-By: bangerth
State-Changed-When: Mon Jan 6 16:43:21 2003
State-Changed-Why:
Confirmed.
There are several things that are wrong:
- The warning has no effect
Synopsis: xmmintrin.h broken for c++
Responsible-Changed-From-To: unassigned-hubicka
Responsible-Changed-By: bangerth
Responsible-Changed-When: Tue Nov 26 19:23:17 2002
Responsible-Changed-Why:
Jan, you probably have the best knowledge of
this code, so I enter your name here; let me know
remove the noreturn attribute line, I cannot make gcc
complain about the code:
tmp/g cat x.c
#include stdlib.h
int main (void)
{
exit(1);
}
tmp/g /home/bangerth/bin/gcc-3.3x-pre/bin/gcc -Wmissing-noreturn -std=gnu99 -c
x.c
tmp/g
What do you do differently?
Regards
Wolfgang
53 matches
Mail list logo
