--
bangerth at dealii dot org changed:
What|Removed |Added
Status|WAITING |NEW
Ever Confirmed|0 |1
Last
--- Comment #18 from bangerth at dealii dot org 2007-05-09 16:39 ---
(In reply to comment #17)
> Are comitee decisions (right or wrong) more important than consequences for
> people? So Borland protects people from undefined behaviours when they can,
> and
> I wonder, isn
--- Comment #5 from bangerth at dealii dot org 2007-05-09 16:34 ---
The code originally given is indeed ambiguous. It boils down to this:
---
namespace boo {
template void work(T n);
template struct R { };
template
void rfunc(const R& a) {
using boo::
--- Comment #1 from bangerth at dealii dot org 2007-05-09 16:16 ---
Uh, can you elaborate? We get the warning you want if we have
int d (void) { register int a[2]; return a; }
instead. In your case, i.e. "return a,1", we return 1, but we still
need evaluate the express
--- Comment #16 from bangerth at dealii dot org 2007-05-08 17:25 ---
(In reply to comment #14)
> Which was wrong, I reported the bug and a guy from MinGW kindly explained that
> if it worked then that would be purely by accident and added:
> " When you declare the ar
--- Comment #13 from bangerth at dealii dot org 2007-05-08 15:34 ---
(In reply to comment #12)
> The summary says "g++ misses warning for & on temporary". But something that
> is
> always an error can be called a warning?
The point is that the standard doesn&
--- Comment #39 from bangerth at dealii dot org 2007-05-04 04:54 ---
>From my perspective as a user, I wouldn't find a memory clobber
in front of every placement new all that terrible. People don't
do that in tight loops, and even if they did all that would happen
is tha
--- Comment #3 from bangerth at dealii dot org 2007-05-04 04:50 ---
(In reply to comment #0)
> $ perl -wle 'print "int", "*" x 99, "p;"' >try.c && gcc try.c
> gcc: Internal error: Segmentation fault (program cc1)
Yo, dude, th
--- Comment #10 from bangerth at dealii dot org 2007-05-02 22:56 ---
*** Bug 31788 has been marked as a duplicate of this bug. ***
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #1 from bangerth at dealii dot org 2007-05-02 22:56 ---
*** This bug has been marked as a duplicate of 986 ***
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #3 from bangerth at dealii dot org 2007-05-01 19:16 ---
(In reply to comment #2)
> Ok, thanks. The other compiler we use here at work uses the i suffix to mean
> integer, just like l/L for long.
This is definitely non-standard. The 'i' suffix is for the i
--- Comment #2 from bangerth at dealii dot org 2007-05-01 17:01 ---
> int x[4];
> for(n=0;n<5;n++)
> x[n]=10;
You're asking for trouble here.
That said, we shouldn't produce a compiler error. I can't seem to reproduce
this, what platform is this
--- Comment #7 from bangerth at dealii dot org 2007-04-30 20:45 ---
(In reply to comment #2)
> Can we PLEASE make this a fatal error instead of a warning?
I second that, again.
For the record, I am seeing this very same issue several times as well
on my sources. If we don't
--- Comment #7 from bangerth at dealii dot org 2007-04-30 20:43 ---
Or configure with --disable-multilib.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31766
--- Comment #12 from bangerth at dealii dot org 2007-04-30 15:42 ---
(In reply to comment #10)
> i can reproduce testcase4 on [EMAIL PROTECTED]
I still can't reproduce on i686, sorry. Someone else will
have to look at this and try to further reduce the sources...
W.
--
--- Comment #9 from bangerth at dealii dot org 2007-04-30 03:25 ---
I can't reproduce this with neither r124272 nor r124284. What flags exactly do
you use?
W.
--
bangerth at dealii dot org changed:
What|Removed |
--- Comment #1 from bangerth at dealii dot org 2007-04-30 00:01 ---
I believe the current approach is pretty much the only thing that
can be implemented reliably, because you could write code like this:
---
int f(int i, int j);
int f(int j, int i);
int g = f(1,2
--- Comment #5 from bangerth at dealii dot org 2007-04-27 05:04 ---
Can you post disassembled code from gdb around the location where it
crashes?
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #2 from bangerth at dealii dot org 2007-04-19 20:10 ---
Fixed since 4.0.x.
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
CC
--- Comment #2 from bangerth at dealii dot org 2007-04-19 20:08 ---
This appears fixed since gcc 3.4.x.
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #3 from bangerth at dealii dot org 2007-04-19 20:06 ---
Confirmed. This is a regression on at least mainline. I don't
have my set of compilers around here to verify if it is also a
regression on 4.1 and 4.2.x. It seems to work with 4.0.x.
W.
--
bangerth at deali
--- Comment #15 from bangerth at dealii dot org 2007-04-16 19:02 ---
True. This has been fixed since 4.0.x.
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #3 from bangerth at dealii dot org 2007-04-10 19:18 ---
(In reply to comment #2)
> Maybe you don't have checking enabled for the release versions?
That appears to be the case (I thought I had set --enable-checking).
In any case, I see the ICE on the currently ma
--- Comment #1 from bangerth at dealii dot org 2007-04-10 00:30 ---
Confirmed, though this appears to work up to and including the 4.1.2
release at least, in contrast to your assertion...
W.
--
bangerth at dealii dot org changed:
What|Removed
--- Comment #10 from bangerth at dealii dot org 2007-04-09 15:23 ---
Great, thanks. Hopefully someone approves the patch soon.
Talking about canonical types: I think the idea of only issuing a warning
in cases like the current one is a really bad idea. Warnings are meant for
things
--- Comment #8 from bangerth at dealii dot org 2007-04-09 14:56 ---
(In reply to comment #6)
> Does the following patch fix the problem?
>
> http://gcc.gnu.org/ml/gcc-patches/2007-04/msg00188.html
Yes. I think it would be good if you added Andrew's testcase to the
--- Comment #7 from bangerth at dealii dot org 2007-04-09 14:49 ---
(In reply to comment #6)
> This is clearly my bug, but I am not able to reproduce it on
> i686-pc-linux-gnu.
This was with r123617, on i686-pc-linux-gnu. I can reproduce with this
version and Andrew'
--- Comment #1 from bangerth at dealii dot org 2007-04-08 01:03 ---
Please follow the steps outlined at http://gcc.gnu.org/bugs.html . In
particular, we'll need a preprocessed source file. It would also be
of interest how much memory you see that this testcase actually consumes
b
--- Comment #1 from bangerth at dealii dot org 2007-04-08 01:01 ---
I also find this a bit weird:
bug.cc:4: error: parameter packs not expanded with `...':
bug.cc:4: note: 't'
If the error ends with a colon, then the variable name should also be
listed as pa
--- Comment #2 from bangerth at dealii dot org 2007-04-08 00:58 ---
(In reply to comment #1)
> Do you mean -Woverloaded-virtual? (see man page)
> The diagostic reports when a derived class's method 'hides' the base class's.
>
No, he simply wants to know
--- Comment #1 from bangerth at dealii dot org 2007-04-08 00:56 ---
An internal compiler error is always a bug on our side. Please follow
the guidelines at http://gcc.gnu.org/bugs.html and supply us with the
information listed there.
W.
--
bangerth at dealii dot org changed
--- Comment #5 from bangerth at dealii dot org 2007-04-08 00:54 ---
(In reply to comment #4)
> ive no idea which part of the standard should imply/allow this. if one
> replaces
> "typename T::privIC * priv" with "T * priv", its valid and it compiles. I
--- Comment #2 from bangerth at dealii dot org 2007-04-07 16:59 ---
For some reason, bugzilla gives me an internal error when I try to attach
the file. In any case, it is here:
http://www.math.tamu.edu/~bangerth/step-27.ii.gz
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31505
--- Comment #1 from bangerth at dealii dot org 2007-04-07 16:55 ---
*** Bug 31506 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31505
--- Comment #1 from bangerth at dealii dot org 2007-04-07 16:55 ---
Ack, using the "back" button over PR submissions is no good...
*** This bug has been marked as a duplicate of 31505 ***
--
bangerth at dealii dot org changed:
What|Removed
edTo: unassigned at gcc dot gnu dot org
ReportedBy: bangerth at dealii dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31506
edTo: unassigned at gcc dot gnu dot org
ReportedBy: bangerth at dealii dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31505
--- Comment #3 from bangerth at dealii dot org 2007-04-07 16:29 ---
(In reply to comment #2)
> I'm willing to accept this as an hardware/OS issue, but then am I really that
> unlikely to be the only person having this kind of problem? In other words,
> has
> this type
--- Comment #2 from bangerth at dealii dot org 2007-04-07 16:23 ---
Confirmed.
I think a patch would be of interest. Maybe one could just tweak
the error to read
x.cc:5: error: invalid use of undefined type 'foobar'
x.cc:1: error: forward declaration of struct or cla
--- Comment #1 from bangerth at dealii dot org 2007-04-02 17:09 ---
Confirmed.
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
CC
--- Comment #12 from bangerth at dealii dot org 2007-03-29 17:05 ---
(In reply to comment #11)
> This still happens with -fmessage-length=80, per comment #9.
Uh, but that's exactly what I tried and it wrapped just fine, with
the tick on the second line...
W.
--
bangerth a
--- Comment #14 from bangerth at dealii dot org 2007-03-29 16:28 ---
Still happens with a recent mainline snapshot.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=99
--- Comment #11 from bangerth at dealii dot org 2007-03-29 16:25 ---
Still happens with a recent mainline snapshot.
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #10 from bangerth at dealii dot org 2007-03-29 16:20 ---
This appears fixed with current mainline (at the very least, I don't know
how far back this reaches, but 3.3.5 is still broken).
--
bangerth at dealii dot org changed:
What|Re
--- Comment #11 from bangerth at dealii dot org 2007-03-29 16:13 ---
Still happens with 4.1.2
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #10 from bangerth at dealii dot org 2007-03-28 17:37 ---
(In reply to comment #6)
> Always stopping is the right thing. Once Per finishes his fileline
> conversion, it will be possible to send cpplib's errors through
> diagnostic.c, and we will then be able
--- Comment #5 from bangerth at dealii dot org 2007-03-26 20:48 ---
Yup, Andrew is right.
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #3 from bangerth at dealii dot org 2007-03-26 20:46 ---
(In reply to comment #2)
> well, priv is a pointer..
What I really meant was a typedef:
template struct Base {
typedef typename T::X X;
};
struct A : Base
{
typedef in
--- Comment #17 from bangerth at dealii dot org 2007-03-26 20:44 ---
*** Bug 31330 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 2007-03-26 20:44 ---
Yes, indeed.
*** This bug has been marked as a duplicate of 27102 ***
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #9 from bangerth at dealii dot org 2007-03-26 15:17 ---
(In reply to comment #8)
> but I guess it could be possible at link time, as it is already the case
> for C symbols.
We also don't do that in C: if you have two functions of the same name defined
in two d
--- Comment #5 from bangerth at dealii dot org 2007-03-26 03:13 ---
Manuel,
thanks for (re-)submitting the patch today. I don't have the infrastructure
to test patches any more these days, but I appreciate that someone takes
up the issue again.
I think the text duplication is no
--- Comment #3 from bangerth at dealii dot org 2007-03-23 14:09 ---
Confirmed, but this has already been fixed after release 3.4.4 and
before release 3.4.5. None of the newer releases are affected.
W.
--
bangerth at dealii dot org changed:
What|Removed
--- Comment #1 from bangerth at dealii dot org 2007-03-23 06:26 ---
Or smaller like this:
--
template struct Base {
typename T::X X;
};
struct A : Base
{
typedef int X;
};
--
sunCC also rejects it. I tend to believe that the code is invalid
--- Comment #6 from bangerth at dealii dot org 2007-03-23 03:03 ---
(In reply to comment #5)
> That's not the case here; the class is in the global namespace.
Oh, bummer, of course...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31187
--- Comment #4 from bangerth at dealii dot org 2007-03-23 02:37 ---
Without wanting to be a distractor, but can variables of a type that
was declared in an anonymous namespace really have external linkage?
Think of the type being declared in a header file and one .cc file
has the
--- Comment #2 from bangerth at dealii dot org 2007-03-23 02:29 ---
You need to use 'make bootstrap' instead of just 'make'.
W.
--
bangerth at dealii dot org changed:
What|Removed
--- Comment #1 from bangerth at dealii dot org 2007-03-23 02:28 ---
You need to post a complete testcase, including all include files etc.
I can't reproduce the problem with the snippet you posted.
W.
--
bangerth at dealii dot org changed:
What|Re
--- Comment #7 from bangerth at dealii dot org 2007-03-23 02:13 ---
(In reply to comment #4)
> I agree , sure it is invalid ,(no mine at the root) but a diagnostic
> would be nice
It is very hard for a compiler to detect this because it only sees that there
is a class &#
--- Comment #6 from bangerth at dealii dot org 2007-03-21 03:59 ---
(In reply to comment #4)
> so in other words you're saying the solution to this is
> "if you want it to work with GCC, make your code non-portable"
>
> afaik "__attribute__ (( weak ))&q
--- Comment #1 from bangerth at dealii dot org 2007-03-20 20:02 ---
Confirmed.
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
CC
--- Comment #4 from bangerth at dealii dot org 2007-03-19 14:03 ---
(In reply to comment #3)
> I suspect that parallelizing for SSE/Altivec might be more peneficial
> in most cases than for OpenMP -- OpenMP is a 1,000 pounds gorilla.
I certainly agree. The beauty is that one ma
--- Comment #2 from bangerth at dealii dot org 2007-03-16 18:18 ---
(In reply to comment #1)
> You forgot to declare it, you only defined it.
In fact the other way around: you declared (and initialized) the variable
but you forgot to give a definition (which asks the compiler
--- Comment #6 from bangerth at dealii dot org 2007-03-14 20:49 ---
(In reply to comment #5)
> I know our code is wrong, but my point is that gcc34 generated correct code
> and gcc4x is not.
No, it happened to produce code that happened to do what you thought it would.
There is
--- Comment #1 from bangerth at dealii dot org 2007-03-09 05:05 ---
This appears to work on x86 linux.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31092
--- Comment #1 from bangerth at dealii dot org 2007-03-09 05:01 ---
Confirmed, though I believe this is a duplicate of some other PR. This
is not a regression.
Somewhat smaller:
--
template class C {};
template
class X
{
static const unsigned int Value = 2
--- Comment #4 from bangerth at dealii dot org 2007-03-09 04:54 ---
Confirmed. This is a regression introduced in 4.0.x.
Somewhat shorter:
struct A {};
template
struct C: virtual A {
C() {};
template C(const C&) {};
C func(const class C&
--- Comment #2 from bangerth at dealii dot org 2007-03-09 04:46 ---
Confirmed. This is a regression introduced in gcc4.0.x. Since the
error message doesn't give any context except for the ICE, I rate this
as somewhat more than a nuisance.
W.
--
bangerth at dealii dot org ch
--- Comment #2 from bangerth at dealii dot org 2007-03-09 04:43 ---
Confirmed. The message is probably ok, except that the code that dumps
a tree can't deal with some of the codes in it.
W.
--
bangerth at dealii dot org changed:
What|Re
--- Comment #4 from bangerth at dealii dot org 2007-03-09 04:40 ---
What exactly are you trying to achieve here:
-
typedef void (B::*FPTR)(int);
...
struct C : public A , public B {
virtual void C_bad() { }
};
c.t((FPTR)&C::C_bad);
--
Clearl
--- Comment #3 from bangerth at dealii dot org 2007-03-09 04:34 ---
(In reply to comment #0)
Take a look at this again:
> struct A
> {
> operator short& () { return m_value; }
> operator short () const { return m_value; }
> };
>
--- Comment #1 from bangerth at dealii dot org 2007-03-09 04:22 ---
Confirmed.
--
bangerth at dealii dot org changed:
What|Removed |Added
CC
--- Comment #1 from bangerth at dealii dot org 2007-03-09 04:21 ---
Confirmed. Not a regression.
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #1 from bangerth at dealii dot org 2007-03-09 04:20 ---
We got a warning in gcc2.95, but it has apparently already disappeared in
gcc3.2.x.
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #1 from bangerth at dealii dot org 2007-03-09 04:16 ---
Confirmed.
--
bangerth at dealii dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #5 from bangerth at dealii dot org 2007-03-09 04:14 ---
Here's a reduced code:
-
struct cons_end {};
template struct cons {
U elem;
V tail;
};
template
void foo(U elem, V tail)
{
foo(tail.elem,tail.tail);
}
template
void foo(U elem, cons_end
--- Comment #1 from bangerth at dealii dot org 2007-03-09 03:47 ---
I oppose this change in existing behavior. People have all sorts of
testsuites where existing behavior is stored in output files and
compared against every night. A change in such behavior may lead
to lots of
--- Comment #5 from bangerth at dealii dot org 2007-03-09 03:43 ---
If you make it defined earlier than the standard says, then you
get into trouble for cases like this:
void f() {
struct X {
void g(const char * = __FUNCTION__) {}
};
}
According to the N1970, this
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=31000
--- Comment #8 from bangerth at dealii dot org 2007-02-26 19:10 ---
Mark,
I think you misunderstood: the value *should* be set to 'true' (==1), but is
set to '2'. Or do you mean that '2' is another valid representation of 'true'
and that ther
--
bangerth at dealii dot org changed:
What|Removed |Added
Keywords||wrong-code
Target Milestone|--- |4.2.0
http
--- Comment #3 from bangerth at dealii dot org 2007-02-17 23:33 ---
(In reply to comment #2)
> Not fixed for four years? How come?
No volunteers to fix it? Not an important bug that bothers many people?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30837
--- Comment #17 from bangerth at dealii dot org 2007-02-16 18:47 ---
If anyone ever fixes this, the various duplicates of this bug
have a number of interesting variants that may be worth adding
to the testsuite as well.
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14032
--- Comment #16 from bangerth at dealii dot org 2007-02-16 18:39 ---
*** Bug 4882 has been marked as a duplicate of this bug. ***
--
bangerth at dealii dot org changed:
What|Removed |Added
--- 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 #10 from bangerth at dealii dot org 2007-02-12 16:03 ---
Daniel, any idea?
--
bangerth at dealii dot org changed:
What|Removed |Added
CC
--- Comment #7 from bangerth at dealii dot org 2007-02-12 00:02 ---
(In reply to comment #6)
> I immediately believe that Andrew's and Wolfgang's findings are accurate, but
> I
> never claimed that the mainline has a problem. I never even tried it.
I didn't
--- Comment #3 from bangerth at dealii dot org 2007-02-11 04:16 ---
(In reply to comment #2)
> I thought (according to the ARM) that all functions of a template class were
> implicitly function templates.
No, you confuse class member templates with class template m
--- Comment #1 from bangerth at dealii dot org 2007-02-11 04:12 ---
Confirmed.
--
bangerth at dealii dot org changed:
What|Removed |Added
CC
--- Comment #2 from bangerth at dealii dot org 2007-02-11 04:11 ---
As Andrew said: this is a violation of the C++ standard. You can have
only one definition of a name and if you have more then your program is
in error. The fact that you mark your functions inline doesn't change
--- Comment #5 from bangerth at dealii dot org 2007-02-11 04:07 ---
I also can't reproduce this with
bangerth/x> /tmp/bangerth/bin/bin/c++ -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../svn/configure --enable-checking --enable-langu
--- Comment #1 from bangerth at dealii dot org 2007-02-11 03:57 ---
Confirmed.
--
bangerth at dealii dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #1 from bangerth at dealii dot org 2007-02-11 03:56 ---
Confirmed.
--
bangerth at dealii dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #3 from bangerth at dealii dot org 2007-02-11 03:55 ---
As one data point: if it indeed finds the local function foo, then one
could think that declaring the friend as
friend T ::foo<>(const CTest &test);
might work (note the explicit global scope on the fun
--- Comment #1 from bangerth at dealii dot org 2007-02-11 03:51 ---
Confirmed.
--
bangerth at dealii dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #2 from bangerth at dealii dot org 2007-01-29 01:15 ---
In fact, after minor code changes, I can no longer reproduce the exact
sources that triggered this. I'll close it for the moment, and try
again if the problem should re-appear at one point...
W.
--
banger
--- Comment #6 from bangerth at dealii dot org 2007-01-26 23:01 ---
Hm, I'm not sure if I like this situation. Consider this snippet,
typical of template games:
---
template class Array {
T& operator();
T operator() const;
};
---
This c
?
--
Summary: [4.3 regression] Error with canonical types
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
Report
org
ReportedBy: bangerth at dealii dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30601
cit specialization declaration
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ban
201 - 300 of 972 matches
Mail list logo
