--- 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-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-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-29 16:29
---
Confirmed. Seems as if this never worked.
W.
--
What|Removed |Added
Status
--- 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
--- 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 #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
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-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
--- 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 #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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47043
Wolfgang Bangerth changed:
What|Removed |Added
CC||joseph.h.garvin at gmail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45168
Wolfgang Bangerth changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47043
Wolfgang Bangerth changed:
What|Removed |Added
CC||bangerth at gmail dot com
--- Comment #8 from bangerth at gmail dot com 2010-02-16 23:42 ---
(In reply to comment #6)
> Clarified summary. Since this isn't a regression and there is a workaround,
> it
> doesn't seem like a high priority for 4.5.
But if I understand comment #3 correctly,
--- Comment #10 from bangerth at gmail dot com 2010-02-17 01:45 ---
(In reply to comment #9)
> The workaround in Comment #5 does work in mainline.
Right, but that wasn't the question. Does my program in comment #8 work? If
not, then that would be a regression.
As for the worka
To: unassigned at gcc dot gnu dot org
ReportedBy: bangerth at gmail dot com
OtherBugsDependingO 26261
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43101
--- Comment #12 from bangerth at gmail dot com 2010-02-17 02:00 ---
(In reply to comment #11)
> Only if the transitive property doesn't hold for workarounds. I think it does
> ;)
But you keep dodging the question whether we have regressed on the
workaround.
Anyway, thi
--- Comment #9 from bangerth at gmail dot com 2010-02-18 20:29 ---
(In reply to comment #8)
> For the record, all the compilers I have at hand, EDG based too, accept this
> in
> the most strict mode. I seriously doubt there is really something to fix here.
That said: if it i
--- Comment #11 from bangerth at gmail dot com 2010-02-18 20:53 ---
(In reply to comment #10)
> I'm not sure to fully understand, Wolfgang: you mean, we should change that
> line in the library instead of dealing with a possible C++ issue here? That
> would be easy to do
onent: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bangerth at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43117
--- Comment #1 from bangerth at gmail dot com 2010-02-19 00:56 ---
*** Bug 9990 has been marked as a duplicate of this bug. ***
--
bangerth at gmail dot com changed:
What|Removed |Added
--- Comment #14 from bangerth at gmail dot com 2010-02-19 00:56 ---
(In reply to comment #13)
> The library issue doesn't exist anymore ;) Thus, let's not be distracted by
> the
> trivial library case, ok?
I see, that's convenient :-)
In any case, in orde
--- Comment #2 from bangerth at gmail dot com 2010-02-19 00:59 ---
Darn, I did not pay attention at all. Scrap the text starting with
"The issue is confusing..." above which is entirely pointless because
the code I pasted is wrong in at least two ways (as the error messages
--- Comment #10 from bangerth at gmail dot com 2010-02-21 01:25 ---
(In reply to comment #7)
> (In reply to comment #3)
> > As another data-point,
> >
> > if ( (a=10) ) ;
> >
> > also doesn't warn. I'm not sure what the standard says on th
--- Comment #2 from bangerth at gmail dot com 2010-02-21 01:27 ---
I don't see what should be warned about. The 'const' in the signature of
'f' has no effect here, but it also doesn't hurt -- its presence or
absence simply doesn't make a difference.
--- Comment #2 from bangerth at gmail dot com 2010-02-22 03:56 ---
This is not a bug. Because the base class of Node::OpNode does not
depend on template arguments, the members of the base class are
visible in Node::OpNode::f(). On the other hand, since the base
class of Node::FooOpNode
--- Comment #4 from bangerth at gmail dot com 2010-02-22 04:29 ---
(In reply to comment #3)
> But doesn't this error happens during instantiation as the error message
> indicates? If definition of Node::FooNode is commented out, the templates
> themselves are accepted.
W
--- Comment #1 from bangerth at gmail dot com 2010-02-23 15:13 ---
This feature already exists. See the discussion of the "optimize" attribute
in
http://gcc.gnu.org/onlinedocs/gcc-4.4.3/gcc/Function-Attributes.html#Function-Attributes
W.
--
bangerth at gmail dot c
--- Comment #3 from bangerth at gmail dot com 2010-02-23 15:53 ---
So the attribute would have to be attached to the namespace, I guess.
We can keep the PR open, but my best guess is that this is going to be
one of those PRs that stay open forever as there is so little demand
for this
--
bangerth at gmail dot com changed:
What|Removed |Added
CC||mmitchel at gcc dot gnu dot
--- Comment #10 from bangerth at gmail dot com 2010-02-23 20:40 ---
(In reply to comment #9)
> Is there a reason this hasn't been fixed?
Lack of public demand? There's only one duplicate of this bug that has
been reported in the last 9 years...
> If not, I'
--- Comment #2 from bangerth at gmail dot com 2010-02-25 05:12 ---
I don't think we should be doing this. GCC strives to be standards-conforming
and the requested feature would purposefully make us violate the standard.
There is a point for extensions, but I don't think ch
--- Comment #4 from bangerth at gmail dot com 2010-03-03 19:30 ---
I think INVALID is the wrong resolution of this PR. This clearly is a bug
(if we offer a class we should make sure it can be used), but we may
choose to say that we won't work on this bug. The right resolution ther
--- Comment #5 from bangerth at gmail dot com 2010-03-03 19:31 ---
...is WONTFIX.
--
bangerth at gmail dot com changed:
What|Removed |Added
CC
--- Comment #8 from bangerth at gmail dot com 2010-03-03 19:40 ---
(In reply to comment #7)
> The use of a base class ( class B : A ) is not a declaration of A.
> Thus the base class ( class A ) is visible and not private.
>
> Reopen the bug and fix it.
Andrew was right:
--- Comment #3 from bangerth at gmail dot com 2010-03-07 05:49 ---
(In reply to comment #2)
> So does this mean bug #13687 is going to be reopened? Or is there some
> workaround that hasn't been mentioned?
No. I think the issue has been discussed at length there.
W.
--
--- Comment #1 from bangerth at gmail dot com 2010-03-07 23:41 ---
The error message I get is this:
g/x> c++ -c x.cc
x.cc: In member function 'void Bar::bar() [with T = A::Baz]':
x.cc:18: instantiated from here
x.cc:10: error: no matching function for call to 'Bar:
--- Comment #3 from bangerth at gmail dot com 2010-03-08 00:19 ---
But that would mean that the following code should be invalid
because the compiler should never find HasFoo::foo even at
instantiation time:
-
template
struct HasFoo {
void foo(T) { }
};
template
--- Comment #5 from bangerth at gmail dot com 2010-03-08 00:36 ---
OK, so the question is whether the testcase in comment #3 should be rejected
based on the wording of 14.6.2/3.
Jason, as our resident language lawyer, would you mind commenting?
W.
--
bangerth at gmail dot com
--- Comment #19 from bangerth at gmail dot com 2010-03-08 04:26 ---
*** Bug 43272 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13687
--- Comment #5 from bangerth at gmail dot com 2010-03-08 04:26 ---
What I'm saying is that this entire discussion is already present in PR13687
and that there is nothing more to say. The warning exists in C because it
can lead to hard-to-find bugs in C code because you can c
--- Comment #9 from bangerth at gmail dot com 2010-03-08 14:29 ---
*** Bug 43285 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6709
--- Comment #2 from bangerth at gmail dot com 2010-03-08 14:29 ---
*** This bug has been marked as a duplicate of 6709 ***
--
bangerth at gmail dot com changed:
What|Removed |Added
--- Comment #9 from bangerth at gmail dot com 2010-03-08 16:23 ---
(In reply to comment #7)
> The code that calls the function also *compiles* cleanly, and only the link
> fails.
By compiling I meant translating from source code to executable. That
includes linking. The point
--- Comment #6 from bangerth at gmail dot com 2010-03-18 20:47 ---
Also: 1e22 is not exactly representable as a floating point number. By
consequence, 1e22 is different numbers when stored as a double or a
long double, and we should expect different results when applying the
sine to it
--- Comment #3 from bangerth at gmail dot com 2010-03-20 11:26 ---
(In reply to comment #2)
> class Foo;
> Foo* f();
> int main() {
>Foo* p = f();
>delete [] p;
> }
I can't see how the compiler could possibly do anything useful in this case
if Foo is i
--- Comment #4 from bangerth at gmail dot com 2010-03-25 18:37 ---
(In reply to comment #2)
> So you are saying the standard thinks
> FixedPoint::allow_double_instantiations is dependent.
That is the correct question. We get the error message during
template parsing, not
--- Comment #8 from bangerth at gmail dot com 2010-04-02 11:37 ---
I think this is a bug the MingW maintainers should handle.
While I understand Andrew's position, it seems to me that this is nevertheless
a definite regression from the user's perspective.
W.
--
bangert
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=43648
--- Comment #2 from bangerth at gmail dot com 2010-04-05 12:46 ---
Thanks Richard for the quick confirmation.
I should have mentioned that this worked on previous versions up to at least
4.3.3.
W.
--
bangerth at gmail dot com changed:
What|Removed
--- Comment #2 from bangerth at gmail dot com 2010-04-05 12:56 ---
I think this should work. I can't see how it would be invalid as template
argument for integral_constant but valid for identity.
W.
--
bangerth at gmail dot com changed:
What|Re
--- Comment #15 from bangerth at gmail dot com 2010-04-05 15:28 ---
FWIW, let me say that I believe that few people use -Wfatal-errors. Most of
the time, experienced programmers are able to fix multiple bugs in one
go-around
if they get to see all error messages, and the less
--- Comment #6 from bangerth at gmail dot com 2010-04-07 16:17 ---
Jason, thanks a lot for the quick turnaround, and my apologies for not
testing this stuff on a more frequent basis so I find earlier than the day
before branch day :-)
W.
--
bangerth at gmail dot com changed
--- Comment #1 from bangerth at gmail dot com 2010-04-07 23:16 ---
(In reply to comment #0)
> I think the C++ standard can definitely be read to allow this optimization
I would most definitely think so. 7.2/6 specifically says that the values
an enum variable can take on are, in y
--- Comment #9 from bangerth at gmail dot com 2010-04-08 12:53 ---
I'm not saying we *should* apply a mask (in fact, I think that would be
silly). But we *could*, and if we did then VRP's actions might lead to
faster but not different code.
All I want to say is that VRP is
--- Comment #2 from bangerth at gmail dot com 2010-04-17 02:55 ---
Ouch. ParMetis is one of the most widely used libraries in the
parallel scientific computing area...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43771
--- Comment #2 from bangerth at gmail dot com 2010-04-18 19:02 ---
Confirmed. Including doesn't help.
--
bangerth at gmail dot com changed:
What|Removed |
--- Comment #7 from bangerth at gmail dot com 2010-04-19 02:59 ---
I think the point Andrew wanted to make is that it's a regression
*from the user perspective*. I had a half dozen places in our code
that now no longer compile in c++0x mode. Apparently others do too.
If the standa
--- Comment #12 from bangerth at gmail dot com 2010-04-19 14:57 ---
(In reply to comment #9)
> Also, make_pair's reason for existing is to deduce template arguments. If you
> don't want argument deduction why use make_pair?
True. I don't know why one would want t
--- Comment #15 from bangerth at gmail dot com 2010-04-19 15:51 ---
(In reply to comment #14)
> > Well it's about time someone put a stop to it ;-)
>
> Seriously though, it's quicker to write e.g.
> return std::pair(x, y)
> than
> return std::mak
--- Comment #9 from bangerth at gmail dot com 2010-04-19 22:18 ---
Dereferencing the null pointer invokes undefined behavior, independent on
whether the type of the dereferenced pointer is an empty class or not.
Typically, dereferencing NULL results in a trap. GCC simply preserves
this
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: bangerth at gmail dot com
(Reporting this for Bruno Turcksin .)
The loop in the following testcase cannot be vectorized, we get the error:
note: not vectorized: latch block not empty.
note: bad loop form.
The reason is
--- Additional Comments From bangerth at dealii dot org 2005-06-20 21:30
---
Since this PR prevents me from running my nightly tests for more than 2 months
now, could someone try to run the regression finder on the small testcase to
find out who broke this and when? The duplicate of
--- Additional Comments From bangerth at dealii dot org 2005-06-21 15:55
---
I also see this problem on the 4.0 branch now, with
gcc version 4.0.1 20050531 (prerelease)
I am pretty sure that it wasn't there in 4.0.0, but don't know for sure any
more...
W.
--- Additional Comments From bangerth at dealii dot org 2005-06-21 16:00
---
Giovanni,
I can confirm that your patch for PR 8271 also fixes the problem in this PR.
I would be extremely grateful if it would move somewhere...
Cheers
Wolfgang
--
What|Removed
--- Additional Comments From bangerth at dealii dot org 2005-06-21 16:03
---
I just verified that Giovanni's patch linked to in comment #4 also fixes the
regression reported in PR 21799. Apparently some unrelated change exposed the
problem in 21799, but the underlying issue is th
--- Additional Comments From bangerth at dealii dot org 2005-06-21 16:14
---
I don't have the time to check it today, but could try tomorrow. It certainly
sounds plausible. Nathan, could you comment on this problem?
Thanks
Wolfgang
--
What|Re
This used to compile but doesn't any more on mainline (ok on 4.0.x branch):
---
struct B {
void foo();
};
template class I : public B {};
template class D : private I {
I::B::foo;
};
--
g/x> /home/bangerth/bin/gcc-4.0.1
--
What|Removed |Added
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22136
With attached file, I get the following segfault with mainline:
examples/step-18> /home/bangerth/bin/gcc-4.1-pre/bin/c++ -c step-18.ii
step-18.ii:7102: warning: ‘__malloc__’ attribute ignored
step-18.ii: In constructor ‘std::_Vector_base<_Tp,
_Alloc>::_Vector_base(size_t, con
--
What|Removed |Added
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22139
--- Additional Comments From bangerth at dealii dot org 2005-06-21 17:58
---
Created an attachment (id=9125)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9125&action=view)
Preprocessed sources
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22139
--- Additional Comments From bangerth at dealii dot org 2005-06-21 18:00
---
This looks like a memory problem -- the backtrace is this:
(gdb) r -quiet step-18.ii -o /dev/null
Starting
program:
/home/bangerth/bin/gcc-4.1-pre/libexec/gcc/i686-pc-linux-gnu/4.1.0/cc1plus
-quiet step
--- Additional Comments From bangerth at dealii dot org 2005-06-21 18:03
---
I also get essentially the same backtrace (with the call to
ggc_set_mark (p=0x14)
at the top) from the 4.0.1pre CVS as of 2005-05-31, although this
happens at a different place in the source code. I&#
--
What|Removed |Added
Summary|[4.1 regression] Segfault |[4.0/4.1 regression]
||Segfault
http://gcc.gnu.org/bugzilla/sho
--- Additional Comments From bangerth at dealii dot org 2005-06-21 18:48
---
Created an attachment (id=9126)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9126&action=view)
Smaller testcase
Attached is another testcase that has only half as many lines (~40k) and
that
--- Additional Comments From bangerth at dealii dot org 2005-06-21 20:58
---
Good idea. So I tried it, and indeed this patch
2005-05-10 Nathan Sidwell <[EMAIL PROTECTED]>
PR c++/20723
* pt.c (more_specialized_fn): Member functions are unordered wrt
--- Additional Comments From bangerth at dealii dot org 2005-06-21 20:58
---
Unfortunately, the patch to this PR has caused the regression reported in
PR 21799 :-(
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19203
--- Additional Comments From bangerth at dealii dot org 2005-06-22 14:09
---
Um, Thomas, PR 21592 which you claim this is a duplicate of, is a C++ front
end bug. Did you mean that?
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22124
--- Additional Comments From bangerth at dealii dot org 2005-06-23 02:45
---
Is this really valid? class Y is undeclared at the point of the friend
declaration...
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22147
--- Additional Comments From bangerth at dealii dot org 2005-06-23 14:51
---
Mark, since you are looking for bugs to be fixed in 4.0.1 again, would
this regression between 4.0.0 and the present state of 4.0.1 interest
you? This is code that also appears in boost...
W.
--
http
--- Additional Comments From bangerth at dealii dot org 2005-06-28 13:57
---
Andrew is correct: name lookup proceeds from the present scope outward and
stops once it finds a matching name (note: name, not signature) or names. It
then tries to match the signature of the names to the
--- Additional Comments From bangerth at dealii dot org 2005-06-28 13:59
---
I concur, done.
W.
--
What|Removed |Added
Target Milestone|4.0.2
--- Additional Comments From bangerth at dealii dot org 2005-06-28 22:57
---
I tried to understand what you want to say, but couldn't. Would you mind
sending us a little piece of (complete, compilable) code that compiles with
SunCC but not with gcc?
Thanks
Wol
--- Additional Comments From bangerth at dealii dot org 2005-06-28 23:06
---
Cutting another line or two:
---
extern double sqrt (double) throw ();
void foo(double& d, int n)
{
double e=0;
for(int i=0; i /home/bangerth/bin/gcc-4.1-pre/bin/c++ -c x.cc
--- Additional Comments From bangerth at dealii dot org 2005-06-28 23:10
---
Volker, your testcase does not fail anymore. Should we close this PR? I
have other testcases that fail with the same error message and for which
I will open another PR shortly...
W.
--
http
--- Additional Comments From bangerth at dealii dot org 2005-06-28 23:17
---
Andrew's code in comment #4 is invalid (don't call no-arg functions with
arguments!), but here's a version that also passes through the c++
frontend and crashes the optimizers:
Attached code fails like so:
spec/src> /home/bangerth/bin/gcc-4.1-pre/bin/c++ -O3 -march=pentium4
-ftree-vectorize -c mapping_cartesian.ii
mapping_cartesian.cc: In constructor
‘MappingCartesian::InternalData::InternalData(const
Quadrature&)
[with int dim = 3]’:
mapping_cartesia
--- Additional Comments From bangerth at dealii dot org 2005-06-28 23:22
---
Created an attachment (id=9168)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9168&action=view)
Preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8
--- Additional Comments From bangerth at dealii dot org 2005-06-28 23:23
---
See PR 8...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21218
--
What|Removed |Added
Summary|[4.1 regression] ICE with - |[4.1 regression] ICE with -
|ftree-vectorize |ftree-vectorize in
--- Additional Comments From bangerth at dealii dot org 2005-06-28 23:25
---
This may be the same as PR 8, which still fails as of today...
W.
--
What|Removed |Added
--
What|Removed |Added
OtherBugsDependingO||21859
nThis||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8
--- Additional Comments From bangerth at dealii dot org 2005-06-28 23:31
---
I don't think its the same as PR 22037 -- they have different error messages!
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8
--- Additional Comments From bangerth at dealii dot org 2005-06-29 03:41
---
Created an attachment (id=9169)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9169&action=view)
New testcase
New testcase, much smaller: 100 lines + #include
--
What|
--
What|Removed |Added
CC||irar at il dot ibm dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8
--- Additional Comments From bangerth at dealii dot org 2005-06-29 13:45
---
> Well it compiles perfectly fine on a Sun Solaris Machine with
> Sun Studio 9 installed that has the Sun CC compiler. Also It
> was written by a Computer Science Professor at the Universi
--- Additional Comments From bangerth at dealii dot org 2005-06-29 13:47
---
> You will see these
> other errors that will show up as well but the code has no
> problems on the Sun Machine which means that g++ does not
> completely folllow the ANSI/ISO C++ standard
--- Additional Comments From bangerth at dealii dot org 2005-06-29 14:05
---
Let me point out a few problems in your code first:
list225.cpp, line 161: you can't write
typename const list::iterator& origVal) const
you need to reverse the order of const and
601 - 700 of 1203 matches
Mail list logo
