--- Comment #4 from bangerth at dealii dot org 2006-02-13 17:13 ---
May be related to PR26261.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25868
--
bangerth at dealii dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26261
unassigned at gcc dot gnu dot org
ReportedBy: bangerth at dealii dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26261
--- Comment #6 from bangerth at dealii dot org 2006-01-24 05:48 ---
(In reply to comment #5)
> Well, the actual argument type is wholely resolved at point of call. And the
> formal parameter type is valid at the point where sort is defined. It will
> recognize A as an A
--- 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
--- Comment #4 from bangerth at dealii dot org 2005-12-20 16:14 ---
Yes, you were wrong. This certainly can't be equivalent to the enum snippet
you posted since once can take the address of this static member, but can't
take the address of an enum member.
W.
--
http://g
--- Comment #2 from bangerth at dealii dot org 2005-12-20 16:03 ---
Confirmed. The typedef is only rejected if it is actually used to define
a variable.
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #2 from bangerth at dealii dot org 2005-12-09 05:20 ---
Confirmed. We should at least complain about cases 1, 3, 5. As does,
incidentally, icc with -Xc -ansi.
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #3 from bangerth at dealii dot org 2005-11-23 17:12 ---
Here's a much shorter testcase:
-
#include
struct Point {
Point (const Point &);
Point (const double x);
double values[3];
};
Point::Point (const double x) {
this->v
--- Comment #1 from bangerth at dealii dot org 2005-11-23 16:53 ---
Created an attachment (id=10328)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10328&action=view)
Failing file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25005
ponent: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bangerth at dealii dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25005
--- Comment #4 from bangerth at dealii dot org 2005-11-23 05:31 ---
I don't have chapter and verse to justify this, but icc and gcc agree
that they should reject this code
--
namespace N {
class C {};
void foo(C) {};
}
using namespace N;
void foo(long) {};
voi
--- Comment #6 from bangerth at dealii dot org 2005-11-23 05:25 ---
Given the literal meaning of the word "void", it is amusing to think
about what one might want to mean when one says "const void"...
--
bangerth at dealii dot org changed:
--- Comment #2 from bangerth at dealii dot org 2005-11-23 05:22 ---
Confirmed.
--
bangerth at dealii dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #3 from bangerth at dealii dot org 2005-11-23 05:21 ---
The second constructor is definitely bogus, but its mere existence
does no harm. We should only perform the check for sensibility when
we actually instantiate the second constructor.
W.
--
bangerth at dealii dot
--- Comment #25 from bangerth at dealii dot org 2005-11-08 05:23 ---
*** Bug 24657 has been marked as a duplicate of this bug. ***
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #6 from bangerth at dealii dot org 2005-11-08 05:23 ---
This is PR 13967. See in particular comment #11 in the audit trail there.
Not that that PR would be particularly enlightening, but the situation is
at least discussed at length there.
W.
*** This bug has been marked
--- Comment #5 from bangerth at dealii dot org 2005-11-08 05:14 ---
This can of course be made even simpler:
struct A {
template A(int (*)[i]) : j(i) {}
int * i;
int j;
};
int i[3];
A a(&i);
g/x> /home/bangerth/bin/gcc-3.4.5-pr
--- Comment #11 from bangerth at dealii dot org 2005-10-31 16:10 ---
(In reply to comment #8)
> > How do you generate all these snippets?
>
> By sheer determination. I pick some topic like pointers-to-members or
> destructors for example and try to find some bugs. Over t
--- Comment #2 from bangerth at dealii dot org 2005-10-28 16:26 ---
And here's the minimal testcase:
-
template
struct S
{
static const int u = 2 * dim;
static const int p[u];
static int f();
};
template <>
inline int S<3>
--- Comment #1 from bangerth at dealii dot org 2005-10-28 16:19 ---
Created an attachment (id=10076)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10076&action=view)
Preprocessed sources
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24569
itical
Priority: P2
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bangerth at dealii dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24569
--- Comment #1 from bangerth at dealii dot org 2005-10-14 22:21 ---
Confirmed. The problem goes back to at least 2.95.
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #2 from bangerth at dealii dot org 2005-10-12 14:57 ---
To be clear about what the original bug was: despite the existence of the
explicit instantiation (after an implicit instantiation of f<1>), the generated
symbol had private linkage. Such symbols aren't ex
--- Comment #6 from bangerth at dealii dot org 2005-10-04 02:03 ---
Confirmed. A redux is here:
--
template
struct O {
struct I;
};
template<>
struct O::I
{
I();
};
O::I::I() {}
--
g/x> /home/bangerth/bin/gcc-3.4.5-pre/b
--- Additional Comments From bangerth at dealii dot org 2005-09-29 16:29
---
Confirmed. Seems as if this never worked.
W.
--
What|Removed |Added
Status
--- Additional Comments From bangerth at dealii dot org 2005-09-29 00:25
---
How about the other branches?
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24102
--- Additional Comments From bangerth at dealii dot org 2005-09-27 14:01
---
Then the issue you are seeing is a separate one, and we would need to
have a smaller testcase to figure out what is going on. Please try to
work on finding one so that we can look at it.
Thanks
Wolfgang
--- Additional Comments From bangerth at dealii dot org 2005-09-27 00:44
---
Kevin,
can you try out the various testcases from this report and see whether your
compiler fails any of them?
W.
--
What|Removed |Added
--- Additional Comments From bangerth at dealii dot org 2005-09-26 19:00
---
The testcase in comment #3 shows an ice-on-invalid. The testcase in
comment #7 is valid, and ices anyway.
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22172
--- Additional Comments From bangerth at dealii dot org 2005-09-20 20:07
---
A constructor is a special function the name of which is that of the type
to which it belongs. The type's name is that that includes template arguments.
You could also say that the constructor is a fun
--- Additional Comments From bangerth at dealii dot org 2005-09-20 18:31
---
This looks like a duplicate of PR 23896 -- does the patch there help you?
I.e. if you update the compiler to the latest version, does the problem
go away?
W.
--
What|Removed
--- Additional Comments From bangerth at dealii dot org 2005-09-20 18:28
---
In particular, template arguments are _never_ deduced for types, only for
functions.
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23977
--- Additional Comments From bangerth at dealii dot org 2005-09-16 13:25
---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
--- Additional Comments From bangerth at dealii dot org 2005-09-16 13:21
---
I am pretty sure this is a duplicate of PR 23896, which was fixed last
night. Can you try with an updated compiler?
Thanks
Wolfgang
--
What|Removed |Added
--- Additional Comments From bangerth at dealii dot org 2005-09-15 17:56
---
This is what I come up with:
---
template struct X {};
template struct length {
static const int value = 2;
};
template void foo () {
sizeof(X::value>);
}
template v
--- Additional Comments From bangerth at dealii dot org 2005-09-14 23:05
---
I think that's a particularly bad idea: if we use assert(), then we get
an immediate backtrace when run in the debugger. If an exception is
thrown, it is a pain to set a breakpoint in the correct li
--- Additional Comments From bangerth at dealii dot org 2005-09-14 22:57
---
Well, we've been tightening the compiler in many places. I consider this
a particularly useless extension -- it's true that it doesn't hurt anyone,
but it adds nothing whatsoever of value to
--- Additional Comments From bangerth at dealii dot org 2005-09-14 21:10
---
Fair enough. And to get more to the point of only using user-defined
conversion sequences (instead of the standard conversion from double
to int):
struct A;
struct B { B(const double
--- Additional Comments From bangerth at dealii dot org 2005-09-14 18:07
---
I'm not sure it is a duplicate, since the error messages are very
different. But be that as it may, this is a regression and should
be fixed. If it is, someone may want to take a look at that other
--- Additional Comments From bangerth at dealii dot org 2005-09-14 15:36
---
*** Bug 23510 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From bangerth at dealii dot org 2005-09-14 15:36
---
Indeed a duplicate.
*** This bug has been marked as a duplicate of 9335 ***
--
What|Removed |Added
--- Additional Comments From bangerth at dealii dot org 2005-09-14 15:35
---
I believe the compiler is correct. In order to check whether there
is a conversion sequence from float to A, it needs to instantiate the
type, parts of which are declared by incomplete. This should be an
--- Additional Comments From bangerth at dealii dot org 2005-09-14 15:28
---
Confirmed. This is a regression against 3.3 which compiled the code
just fine.
W.
--
What|Removed |Added
--- Additional Comments From bangerth at dealii dot org 2005-09-14 15:25
---
I don't see the problem either. You should simply mark the argument to
the constructor as const so that temporaries can be bound to it.
W.
--
What|Removed |
--- Additional Comments From bangerth at dealii dot org 2005-09-14 15:23
---
This has been complained about in other PRs before. The problem is that
the following syntax is allowed:
struct S {} typedef A;
i.e., the infix-form of typedef. Since there are other PRs about this
--- Additional Comments From bangerth at dealii dot org 2005-09-13 14:04
---
Here's a slightly smaller version:
-
struct A {};
struct B : private A {};
B *p = static_cast((A*)0);
-
g/x> /home/bangerth/bin/gcc-3.2.3/bin/c++ -c x.cc
g/
--- Additional Comments From bangerth at dealii dot org 2005-09-12 14:54
---
(In reply to comment #9)
> Of course, if the target audience for gcc is the developers that work on it,
> then the present message is just fine...
Well, it certainly isn't. We are just stru
--- Additional Comments From bangerth at dealii dot org 2005-09-12 01:55
---
Well, but then tell me what you expect for the case you have:
template
voidfoo::g() {}
How many template parameters do you give? I count one (in the
'template <...>' angle br
--- Additional Comments From bangerth at dealii dot org 2005-09-12 01:18
---
Folks,
I find that this bug is now present on the 3.4.x branch. I don't know
for how long, but believe that it broke somewhere between 5 and 15 days
ago. It would be good if we could fix this b
--- Additional Comments From bangerth at dealii dot org 2005-09-11 23:38
---
The code is illegal (you can only partially specialize class templates,
not function templates). I think the error message is clear: you only
give one template parameter (and try, illegally, to fix the other
--
Bug 20293 depends on bug 100, which changed state.
Bug 100 Summary: confusing name lookup diagnostic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=100
What|Old Value |New Value
--
Bug 12272 depends on bug 100, which changed state.
Bug 100 Summary: confusing name lookup diagnostic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=100
What|Old Value |New Value
--- Additional Comments From bangerth at dealii dot org 2005-09-11 01:50
---
This is good enough. The fact that the compiler says that a name is
not declared when it is in fact ambiguous is treated in a number of
other PRs.
W.
--
What|Removed
--- Additional Comments From bangerth at dealii dot org 2005-09-09 14:06
---
This is weird indeed. Here's the shortest I can come up with:
---
template struct X {
template
X< (W+(W&&W) > 1 ? W+(W&&W) : 1)+1>
operator + (const X&
--- Additional Comments From bangerth at dealii dot org 2005-09-09 00:09
---
(In reply to comment #4)
> A regression hunt on powerpc-linux shows the reduced testcase from comment
#4
How wonderful, a recursive reference -- Janis's comment shows up as comment
#4 :-)
--
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |mmitchel at gcc dot gnu dot
|dot org |org
Status|REOPENED
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |mmitchel at gcc dot gnu dot
|dot org |org
Status|NEW
--
What|Removed |Added
Summary|[3.3/3.4 regression] [arm] |[3.4 regression] [arm] ICE
|ICE in change_address_1, at |in change_address_1, at
--- Additional Comments From bangerth at dealii dot org 2005-09-07 22:40
---
Yea, but I guess I'll leave this to you guys, that sounds too complicated
for me. I'll just stick my head out every once in a while and try to find
a loophope in your reasoning and to invent ways to
--- Additional Comments From bangerth at dealii dot org 2005-09-07 21:27
---
I guess then there is no danger involved.
BTW, I'm not one of the corporate folks, so I have few problems with
breaking ABI compatibility :-) I was just too fast raising a point that
in the end didn&#
--- Additional Comments From bangerth at dealii dot org 2005-09-07 20:55
---
What I had meant was liba.so containing an explicit specialization of
std::vector and libb.so using it while being compiled with
-fno-implicit-instantiations (or whatever the correct name for that
flag was
--- Additional Comments From bangerth at dealii dot org 2005-09-07 20:19
---
If you add a third argument to the constructor, don't you somehow have to
add the old constructor with its two-argument signature to the library to
allow old programs to link against the new library?
--
What|Removed |Added
CC||bangerth at dealii dot org
Last reconfirmed|2005-09-06 18:49:14 |2005-09-07 20:12:20
--- Additional Comments From bangerth at dealii dot org 2005-09-07 20:03
---
*** Bug 23691 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From bangerth at dealii dot org 2005-09-07 20:03
---
This is actually a duplicate of PR 23771. It compiles fine with 4.0.1pre
but doesn't anymore with today's 4.0.2pre.
W.
*** This bug has been marked as a duplicate of 23771 ***
--
mponent: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bangerth at dealii dot org
CC: gcc-bugs at gcc dot gnu dot org,mmitchel at gcc dot gnu
dot org,nathan at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23771
--- Additional Comments From bangerth at dealii dot org 2005-09-07 00:38
---
gcc is correct. Ambiguation of base class members does not happen based
on assigning to different types.
W.
--
What|Removed |Added
--- Additional Comments From bangerth at dealii dot org 2005-09-02 16:33
---
I think it can be considered arguable whether the code is valid or not.
Here it is again:
template struct X {
static const T value = false;
};
template struct W
--- Additional Comments From bangerth at dealii dot org 2005-08-31 20:34
---
In the discussion on the duplicate PR 23660, rth explained part of this here:
http://gcc.gnu.org/ml/gcc/2005-08/msg00934.html
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22076
--- Additional Comments From bangerth at dealii dot org 2005-08-29 23:10
---
What Andrew is trying to say is that in C, even variables that are marked
'const' can be modified. Thus, the compiler can't (naively, i.e. without
using flow analysis) determine that '
--- Additional Comments From bangerth at dealii dot org 2005-08-12 04:05
---
We're already at comment 85 in this PR, so this is definitely going to be my
last message.
While I sympathize with your desire to have a better error message, you seem
not to understand the implicatio
--- Additional Comments From bangerth at dealii dot org 2005-08-09 17:05
---
You realize that your results differ only in the 8th digit -- which just
so happens to be the precision you get from floats, right?
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23298
--- Additional Comments From bangerth at dealii dot org 2005-08-09 17:01
---
(In reply to comment #11)
> I was also able to pin down the patch that triggered/exposed this problem:
>
> 2005-07-09 Diego Novillo <[EMAIL PROTECTED]>
I'm not sure what relationshi
--- Additional Comments From bangerth at dealii dot org 2005-08-09 14:11
---
I think we should all recuse ourselves from this discussion, since we just
keep iterating our same old positions:
Yongwei believes that this is a defect in the standard and that gcc should
not follow the
--- Additional Comments From bangerth at dealii dot org 2005-08-08 18:01
---
This seems already fixed in 4.0 and mainline:
g/x> /home/bangerth/bin/gcc-4.0*/bin/c++ -c x.cc
x.cc:2: error: ‘A’ is not a template
x.cc:2: error: expected id-expression before ‘~’ token
g/x>
--- Additional Comments From bangerth at dealii dot org 2005-08-08 17:59
---
Confirmed, a regression from before the new parser went in.
Smaller testcase:
---
template struct A {};
template void f() {
(new A)->
--- Additional Comments From bangerth at dealii dot org 2005-08-08 13:20
---
It serves its users by providing a reliable translator for the language
defined by the standard. Think about the portability implications of
compilers that willy-nilly implement some parts of the standard but
--- Additional Comments From bangerth at dealii dot org 2005-08-06 22:56
---
If you know what's going on, the error message is actually clear:
foo.cc:7: error: invalid use of undefined type `struct bar'
This just means that the partially specialized class bar has not
--- Additional Comments From bangerth at dealii dot org 2005-08-06 20:29
---
No, you try to partially specialize a member. That isn't allowed.
You either have to completely specialize all template parameters, or
none. Long standing annoyance in C++...
W.
--
--- Additional Comments From bangerth at dealii dot org 2005-08-06 17:18
---
I agree with Gaby: the standard pretty unambiguously lists the signature of
std::distance, and the name lookup rules say that it needs to be found. What
leeway do we have in rejecting it anyway and picking
--- Additional Comments From bangerth at dealii dot org 2005-08-05 13:10
---
I fail to see how James' quote has any significance for this PR at all. It
talks about overload resolution, which is not the question here at all.
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Keywords||diagnost
--- Additional Comments From bangerth at dealii dot org 2005-07-28 23:42
---
Confirmed. These are all regressions.
W.
--
What|Removed |Added
Status|RESOLVED
--- Additional Comments From bangerth at dealii dot org 2005-07-28 19:43
---
I believe you can't.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17445
--- Additional Comments From bangerth at dealii dot org 2005-07-25 15:21
---
This basically boils down to this question:
-
template struct S { typedef int type; };
template
int foo(T, typename S::type * ret);
int j = foo(1, 0);
--
icc
--- Additional Comments From bangerth at dealii dot org 2005-07-25 14:25
---
As for the initial testcase (Andrew's testcase in comment #1),
- gcc3.3 rejects it with and without the template declaration
- icc rejects it with and without the template declaration
- gcc3.4
--- Additional Comments From bangerth at dealii dot org 2005-07-24 04:59
---
I would imagine that in real world, there are either a rather small number
of overloads of a name (less than five) or very many (more than 20 or 30).
Most code I've seen don't use many overloads (fa
--- Additional Comments From bangerth at dealii dot org 2005-07-24 04:55
---
So yes, what's the problem? That you don't have these header files installed
on your system?
W.
--
What|Removed
--- Additional Comments From bangerth at dealii dot org 2005-07-24 04:51
---
Don't worry, I'm just trying to tighten the net of PRs somehow -- if someone
comes around to fix this PR, she might take a little more time than I have
right now to find that duplicate PR...
--- Additional Comments From bangerth at dealii dot org 2005-07-24 04:50
---
Certainly yes :-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20118
--- Additional Comments From bangerth at dealii dot org 2005-07-24 00:14
---
Well, let's have the libstdc++ people comment then :-)
W.
--
What|Removed |
--- Additional Comments From bangerth at dealii dot org 2005-07-23 22:32
---
Benjamin, what's the status on this now?
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14500
--- Additional Comments From bangerth at dealii dot org 2005-07-23 21:36
---
This works in 4.0.1 and mainline. It ICEd since at least 2.95, so is not a
regression and won't be fixed on the 3.4 branch.
W.
--
What|Removed |
--- Additional Comments From bangerth at dealii dot org 2005-07-23 21:33
---
Here's what we get with present mainline and icc:
g/x> /home/bangerth/bin/gcc-4.1-pre/bin/c++ -c x.cc
x.cc:4: error: too few template-parameter-lists
g/x> icc -Xc -ansi -c x.cc
x.cc(4):
--- Additional Comments From bangerth at dealii dot org 2005-07-23 21:29
---
There is another PR about exactly this problem somewhere.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20308
--- Additional Comments From bangerth at dealii dot org 2005-07-23 21:27
---
gcc is actually correct. Per the using declaration in main(), you
introduce N::foo into the scope of foo(), and when foo(enum1) is called
we find the name foo inside namespace N and then stop to search, so
--- Additional Comments From bangerth at dealii dot org 2005-07-23 21:15
---
No, the standard says that the result for an iterator 'i' in the output
range is
((...(*first + *(first + 1)) + ...) + *(first + (i - result)))
So arithmetic is done with the data type of
--- Additional Comments From bangerth at dealii dot org 2005-07-23 21:11
---
This is related to PR 22149.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22618
--- Additional Comments From bangerth at dealii dot org 2005-07-23 21:10
---
This is related to PR 22618.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22149
501 - 600 of 972 matches
Mail list logo
