--- 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 #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 #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 #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 #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
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 #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
--- 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 #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 #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 #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 #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 #1 from bangerth at dealii dot org 2006-07-18 13:34 ---
Is this related to libstdc++ PR 20758? Or is this unrelated since it
apparently isn't in the implementation of libstdc++ but in the
optimizers?
W.
--
bangerth at dealii dot org changed:
What|Re
--- Comment #1 from bangerth at dealii dot org 2006-07-18 13:35 ---
Confirmed.
--
bangerth at dealii dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #1 from bangerth at dealii dot org 2006-07-18 13:38 ---
Confirmed, a regression introduced in 3.4.x.
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #1 from bangerth at dealii dot org 2006-07-18 13:40 ---
(In reply to comment #0)
> Everyone knows that in C, "&function_name" and "function_name" are generally
> equivalent-- you can write:
> func_ptr_type* f = &function_name;
>
--- Comment #2 from bangerth at dealii dot org 2006-07-18 13:51 ---
Independent of the previous question, I believe gcc is wrong.
There should be two calls to bar().
Confirmed.
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #2 from bangerth at dealii dot org 2006-07-18 14:03 ---
Confirmed, though the testcase is huge and the error message atrocious.
Someone will have to take the time to reduce something smaller out of
this whole boost mess...
W.
--
bangerth at dealii dot org changed
--- Comment #3 from bangerth at dealii dot org 2006-07-20 03:45 ---
That's an important contribution, and I want to encourage you not to get
discouraged by the lengthy process of getting a copyright assignment and
then patch review. Please hang tight, this is a patch that others
--- Comment #1 from bangerth at dealii dot org 2006-08-06 22:12 ---
For some reason, this also passes icc. Interestingly, it isn't even the
case that offsetof manages to look through operator[] -- removing the
body of operator[] doesn't affect the result.
W.
--
bangerth
--- Comment #5 from bangerth at dealii dot org 2006-08-06 22:16 ---
Confirmed. I'm sure this is a duplicate of some other PR, but I don't
know which one right now...
W.
--
bangerth at dealii dot org changed:
What|Removed
--- Comment #1 from bangerth at dealii dot org 2006-08-06 22:19 ---
Confirmed. To make things worse, the diagnostic is really longish
right now as well:
g/x> c++ -c x.cc
x.cc:10: error: reference to 'B' is ambiguous
x.cc:4: error: candidates are: struct A::B
--- Comment #4 from bangerth at dealii dot org 2006-08-10 21:25 ---
I may not be the only one wondering whether this dynamic_cast(p) is
valid code at all. To this end, it may be worth noting section 5.2.7/1
of the standard:
1 The result of the expression dynamic_cast(v) is the
--- Comment #2 from bangerth at dealii dot org 2006-08-13 00:26 ---
The code is invalid (because there is no constructor s::s(s*)), but
we can make the code valid and still ICE:
--
namespace N
{
struct A { A(A*); };
void foo(const A &);
}
template vo
--- Comment #17 from bangerth at dealii dot org 2006-08-22 20:36 ---
I agree that we should allow this behavior. Clearly the standard has nothing
to say about whether -fno-rtti should allow this or not, but the standard
has an explicit provision for the case of dynamic_cast
--- Comment #1 from bangerth at dealii dot org 2006-08-23 15:01 ---
(In reply to comment #0)
>int size1 = sizeof(A); // == 0, should be nonzero
>int size2 = sizeof(a); // == 0, should be nonzero
What makes you think so?
> Since: ISO 14882-2003, 9 [Classes].3
I do
--- Comment #1 from bangerth at dealii dot org 2006-08-23 15:08 ---
I can confirm that it takes
g++ 3.3: 1.5 seconds
gcc 3.4: 18.6 seconds
gcc 4.0: 13.2 seconds
However, gcc4.1 is back down to 0.5 seconds to compile this and presumably
takes a lot less memory as well. So this is
--- Comment #4 from bangerth at dealii dot org 2006-08-24 01:52 ---
Paolo has already confirmed this one.
--
bangerth at dealii dot org changed:
What|Removed |Added
--
bangerth at dealii dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #2 from bangerth at dealii dot org 2006-08-24 01:57 ---
It doesn't seem to matter for me whether the function is a template or
not. Which version did you use to get to that statement?
W.
--
bangerth at dealii dot org changed:
What|Re
--- Comment #1 from bangerth at dealii dot org 2006-08-24 01:59 ---
Um, why? The value "1.234" is an rvalue of type double. You cast it to
an rvalue of type "const int", which can clearly be assigned to an
int right away without another cast. In fact, const-volati
ate/use and C++ anonymous namespaces
don't mix
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
--- Comment #1 from bangerth at dealii dot org 2006-09-04 16:04 ---
I forgot to say that this comes from trying to use -fprofile-use on 447.dealII
from SPEC 2006...
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28948
--- Comment #1 from bangerth at dealii dot org 2006-09-12 03:58 ---
At first I thought that the warning is not useful since the variable may
in fact not be unused at all -- the using declaration simply makes the
name available in the present scope.
However, then I realized that this
--- Comment #5 from bangerth at dealii dot org 2006-09-12 04:00 ---
(In reply to comment #4)
> I suppose this is the same basic problem?
No, that code is definitely legal and unobjectionable. Just as having two
extern declarations of the same variable in the same scope (or two forw
--- Comment #4 from bangerth at dealii dot org 2006-09-13 03:32 ---
With today's 4.1.x snapshot and on x86_64, I get this at -O2:
.L4:
mov %edx, %eax
incl%edx
cmpl%edx, %ecx
movl%esi, (%rdi,%rax,4)
jne
--- Comment #3 from bangerth at dealii dot org 2006-09-13 03:34 ---
This appears to be working now on x86_64 with last night's gcc 4.1.x
subversion.
--
bangerth at dealii dot org changed:
What|Removed |
--- Comment #1 from bangerth at dealii dot org 2006-09-13 03:39 ---
Confirmed. I see the same behavior on x86_64-linux-unknown-gnu. This
is a regression from 3.4.x that is present in at least the 4.0.x and 4.1.x
release branches (don't know about mainline).
W.
--
bangerth at d
--- Comment #6 from bangerth at dealii dot org 2006-09-13 04:02 ---
Isn't this a duplicate of PR 28173 now?
--
bangerth at dealii dot org changed:
What|Removed |
--- Comment #3 from bangerth at dealii dot org 2006-09-13 16:10 ---
Confirmed with the testcase from attachment #2.
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #3 from bangerth at dealii dot org 2006-09-15 13:49 ---
Confirmed. This is the valid testcase:
struct Base {
template void method() { }
};
struct Left : public Base { };
struct Right : public Base { };
struct Join : public Left, public Right { };
void
--- Comment #4 from bangerth at dealii dot org 2006-09-27 04:30 ---
This is definitely firmly in the class of "extension to the language that
requires a thorough proposal to be presented to the standards committee"
things. I don't think anyone is even remotely interested
--- Comment #4 from bangerth at dealii dot org 2006-09-27 04:50 ---
This code can't work. The check() function is not a virtual function,
so calling
((&broken)->*func) ();
is translated to
( ((Base*)(&broken))->*func) ();
because func is of type
void (Base::
--- Comment #6 from bangerth at dealii dot org 2006-09-27 04:57 ---
Filing bug reports is certainly a good think no matter what happens:
a) If code is finally merged from the branch, we will have to go back to
these bug reports to make sure they're really fixed
b) If code is
--- Comment #1 from bangerth at dealii dot org 2006-09-27 15:46 ---
You didn't show us the code that generated the problem. We can't do anything
without that. Please read
http://gcc.gnu.org/bugs.html
for more information.
Best
W.
--
bangerth at dealii dot o
--- Comment #1 from bangerth at dealii dot org 2006-09-27 15:48 ---
-q64 is not a flag that gcc recognizes. It is a flag that xlC recognizes,
however. Why would you want to pass it to gcc?
W.
--
bangerth at dealii dot org changed:
What|Removed
--- Comment #2 from bangerth at dealii dot org 2006-09-28 05:59 ---
Confirmed. This actually worked in gcc2.95 to my surprise:
g/x> /home/bangerth/bin/gcc-2.95.3/bin/c++ -c x.cc
x.cc: In function `void foo()':
x.cc:1: variable-sized object of type `const char *[((c - 1) + 1)]&
--- Comment #4 from bangerth at dealii dot org 2006-09-28 06:06 ---
I think the error message is perfectly clear: it says that there is no
function
foo (X)
but that there is a function that provides
foo (X&)
We've gone through this many times that there is no way to say
--- Comment #7 from bangerth at dealii dot org 2006-09-28 06:09 ---
Daniel, would you prefer if we marked this as WONTFIX? I think this thing
is so contentious that we're not going to do anything about it until there's
some sort of resolutions from the ISO committees.
I just
--- Comment #1 from bangerth at dealii dot org 2006-09-28 06:10 ---
Can you post preprocessed sources as requested in
http://gcc.gnu.org/bugs.html
Thanks
Wolfgang
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #1 from bangerth at dealii dot org 2006-09-28 06:15 ---
This is what is listed in the release notes of gcc 3.4:
http://gcc.gnu.org/gcc-3.4/changes.html
They say this:
-
When binding an rvalue of class type to a reference, the copy constructor of
the class must
--- Comment #9 from bangerth at dealii dot org 2006-10-10 03:26 ---
(In reply to comment #8)
> (In reply to comment #7)
> > 3.4.4 (or 3.4.6) are the system compilers on FreeBSD-5.x and FreeBSD-6.x
> So what, we are talking about the FSF GCC and not freebsd and 3.4.x is
--- Comment #2 from bangerth at dealii dot org 2006-10-10 03:36 ---
This is in fact a duplicate of PR 20039.
*** This bug has been marked as a duplicate of 20039 ***
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #2 from bangerth at dealii dot org 2006-10-10 03:36 ---
*** Bug 28990 has been marked as a duplicate of this bug. ***
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #3 from bangerth at dealii dot org 2006-10-10 03:44 ---
Confirmed. Not a useful extension because confusing:
-
struct A;
struct B {
B (const A&);
};
struct A {
operator B() const;
};
A a;
B b1 = a;// xpass
---
g/x>
--- Comment #1 from bangerth at dealii dot org 2006-10-10 03:51 ---
Confirmed:
--
struct S { void operator () (); };
void foo ()
{
( S()() );
}
--
g/x> /home/bangerth/bin/gcc-4.2-pre/bin/c++ -c x.cc
x.cc: In function ‘void foo()’:
x.cc:5: error: ‘t
--- Comment #6 from bangerth at dealii dot org 2006-10-10 03:54 ---
Confirmed. The code makes sense and we shouldn't unconditionally warn.
W.
--
bangerth at dealii dot org changed:
What|Removed |
--- Comment #1 from bangerth at dealii dot org 2006-10-10 03:56 ---
Indeed can't reproduce on x86.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29297
--- Comment #3 from bangerth at dealii dot org 2006-10-10 04:00 ---
The standard does not provide to explicitly specify the template
arguments of a constructor invocation. The syntax
name
refers to a template class 'name' with template argument 'type', not
to a
--- Comment #3 from bangerth at dealii dot org 2006-10-10 04:11 ---
Confirmed:
--
template struct A {};
template class P>
struct B {
template class Q>
friend bool foo (const B& a);
};
template class Q>
bool foo (const B& a);
void bar ()
--- Comment #4 from bangerth at dealii dot org 2006-10-10 04:13 ---
btw, this only happens if Q is really a template template argument. As noted
by the original reporter, the problem goes away if Q is simply a template
argument.
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #4 from bangerth at dealii dot org 2006-10-10 04:24 ---
Your expectations are wrong. You probably believe that here
-
void f3()
{
D d3;
printf("3) getValue() -> %d,", d3.getValue());
{
D d3 = d3;
printf("getVa
--- Comment #5 from bangerth at dealii dot org 2006-10-10 04:27 ---
Here's the right combination of flags that warns (for f3() only):
g/x> /home/bangerth/bin/gcc-4.2-pre/bin/c++ -Winit-self -Wuninitialized -O2 -c
x.cc
x.cc: In function ‘void f3()’:
x.cc:42: warning: ‘d3$c$v’
--- Comment #6 from bangerth at dealii dot org 2006-10-10 14:25 ---
(In reply to comment #5)
> foo should not have been injected by the friend.
True, but that's irrelevant here. We get a tentative declaration that we
simply have to unify with the later real declaration.
&g
--- Comment #11 from bangerth at dealii dot org 2006-10-10 14:56 ---
(In reply to comment #10)
> For you, the developers, it is, probably, indeed faster, than writing another
> explanation, why you "have no resources" to do it...
No, it will actually take significant
--- Comment #13 from bangerth at dealii dot org 2006-10-10 15:18 ---
(In reply to comment #12)
> In comment #9: shouldn't be too hard.
> In comment #11: No, it will actually take significant time
It's a long and boring process. It's not complicated, it just t
--- Comment #5 from bangerth at dealii dot org 2006-10-11 03:35 ---
Um, the error message says
`foo' is not a template
which is about as accurate as can be.
That said, the request for a warning for constructors that can't be called
is ok. Would you mind opening a new r
--- Comment #4 from bangerth at dealii dot org 2006-10-11 03:43 ---
Confirmed. 12.5/4 reads to me as if myclass::operator delete[] should be
called. Indeed icc doesn't call either user defined operator in the
array case. I think that's just a convergence of bugs, though.
Th
--- Comment #1 from bangerth at dealii dot org 2006-10-12 00:39 ---
> int array3[(const unsigned short) (20.5 * 3)];
>
> error message from compiler is:
> "error: array bound is not an integer constant"
>
> to me this is wrong because the expression "
--- Comment #3 from bangerth at dealii dot org 2006-10-12 00:41 ---
Confirmed.
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
CC
--- Comment #2 from bangerth at dealii dot org 2006-10-12 00:56 ---
Why exactly do you think that the empty base should not be located at
the same address as the simple_base base object?
W.
--
bangerth at dealii dot org changed:
What|Removed
--- Comment #4 from bangerth at dealii dot org 2006-10-12 01:03 ---
The operator== you want to call is used in a context in which the
template argument cannot be deduced (a "non-deduceable context").
If you want to use this construct, you will have to write some
--- Comment #19 from bangerth at dealii dot org 2006-10-12 01:06 ---
Since this is solved on mainline and nobody seems to have been able to
ever reproduce it anyway, there doesn't seem to be a chance of this
being actively worked on on older release branches. I'll therefore cl
--
bangerth at dealii dot org changed:
What|Removed |Added
Known to work||4.2.0
Target Milestone|4.1.2 |4.2.0
http
--- Comment #2 from bangerth at dealii dot org 2006-10-12 01:08 ---
What exactly is the problem here? I get this as an error message:
g/x> /home/bangerth/bin/gcc-4.2-pre/bin/c++ -c x.cc
x.cc: In function ‘void f()’:
x.cc:3: error: break statement not within loop or switch
That se
< "Derived ctor\n"; }
~Derived() { std::cout << "~Derived called\n"; }
Derived(const Derived &) { std::cout << "Base copy ctor\n"; }
};
int main ()
{
bool b = false;
const Base& ref = b ? Base() : Derived();
}
---
--- Comment #1 from bangerth at dealii dot org 2006-10-12 01:39 ---
Confirmed.
--
bangerth at dealii dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #4 from bangerth at dealii dot org 2006-10-12 01:41 ---
Are there any plans to backport the fix to 4.0.x, or should this bug be
closed as a WONTFIX on that branch?
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #1 from bangerth at dealii dot org 2006-10-12 01:43 ---
Confirmed. To make things more interesting, gcc presently gives me
the warning twice:
g/x> /home/bangerth/bin/gcc-4.2-pre/bin/c++ -c x.cc -Wall
x.cc: In function ‘int main()’:
x.cc:5: warning: null argument where
--- Comment #4 from bangerth at dealii dot org 2006-10-12 01:45 ---
Confirmed. The template version doesn't compile, whereas the non-template
version does.
W.
--
bangerth at dealii dot org changed:
What|Removed |
--- Comment #4 from bangerth at dealii dot org 2006-10-12 01:47 ---
I can confirm that this is apparently fixed now.
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #3 from bangerth at dealii dot org 2006-10-12 01:49 ---
Confirmed.
--
bangerth at dealii dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #5 from bangerth at dealii dot org 2006-10-12 01:50 ---
gcc is correct. It is true that the result of the ?: operator is
a reference to the Base object of the Derived object created in the
second arm. However, the result is an rvalue, and a constant reference
is initialized
--- Comment #2 from bangerth at dealii dot org 2006-10-12 01:52 ---
It is infact: this is a cleaned up version of that PR, but actually handles
the thing that is wrong, whereas PR 28169 was talking about something that
wasn't a bug at all.
W.
--
http://gcc.gnu.org/bug
--- Comment #3 from bangerth at dealii dot org 2006-10-12 02:06 ---
Forget this, the type of the rhs is of course an rvalue of type Base,
there is no need to copy the entire Derived object.
W.
--
bangerth at dealii dot org changed:
What|Removed
--- 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
--- Comment #8 from bangerth at dealii dot org 2006-10-12 19:55 ---
(In reply to comment #6)
> Thank you for your answer, this is very interesting (but where is it
> documented?).
In the gcc manual.
> But still *very* dangerous, because the destructor of this unitialized ob
--- Comment #2 from bangerth at dealii dot org 2006-10-17 05:45 ---
I can't either. The typical failure mode would have been an infinite
growth of memory usage, but I can't see this with any version I have.
It must be a RH specific problem...
--
bangerth at dealii dot o
--- Comment #9 from bangerth at dealii dot org 2006-10-21 04:28 ---
Mark,
is there any way for a backport of your patch to the 4.1 branch? This
appears to be a regression involving boost, and I got word from
people whose codes break with 4.1.x because of this...
Thanks
W
This little code
---
const double foo() { return 1.; }
---
used to be fine in C++ even in the presence of -Wreturn-type but now
yields a warning with recent mainline:
deal.II/tests> /tmp/bangerth/bin/bin/c++ -Wreturn-type -c x.cc
x.cc:1: warning: type qualifiers ignored
I get a warning about canonical types like this from one of my codes:
tests/bits> /tmp/bangerth/bin/bin/g++ -DHAVE_CONFIG_H -DHAVE_ISNAN -ggdb
-DDEBUG -pedantic -Wall -Wpointer-arith -Wwrite-s
trings -Winline -Woverloaded-virtual -Wsynth -Wsign-compare -Wconversion
-Wswitch -ftemplate-depth-
--- 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
--- 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 #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 #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:56 ---
Confirmed.
--
bangerth at dealii dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- 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 #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 #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 #1 from bangerth at dealii dot org 2007-02-11 04:12 ---
Confirmed.
--
bangerth at dealii dot org changed:
What|Removed |Added
CC
101 - 200 of 1203 matches
Mail list logo
