--- Comment #1 from bangerth at gmail dot com 2009-08-25 15:51 ---
Confirmed. This is indeed awkward, and not actually all that hard to get
into using makefiles (was @< the input or output file again??).
--
bangerth at gmail dot com changed:
What|Remo
--- Comment #6 from bangerth at gmail dot com 2009-08-26 18:49 ---
It's also fixed on mainline and it works on 4.2.1. I don't have a version of
4.3 lying around, but that would be the only open branch which appears to
still have the problem.
Would someone mind testing this on
--- Comment #8 from bangerth at gmail dot com 2009-08-26 19:43 ---
(In reply to comment #7)
> pr.cc:38: error: invalid operands of types ‘bool’ and
> ‘int’ to binary
> ‘operator==’
This is doubly fascinating as there is no operator== in this line ;-)
W.
--
http://gc
--- Comment #5 from bangerth at gmail dot com 2009-08-27 11:35 ---
The warning isn't triggered any more with current mainline.
Can someone gives this a try with the current 4.4.x branch?
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40146
--- Comment #3 from bangerth at gmail dot com 2009-08-31 22:05 ---
(In reply to comment #2)
> I think this bug should be fixed in trunk (4.5) by the patch for PR
> debug/30161.
> Can we close this bug or should we wait for GDB ?
What does GDB currently say for the testcase sho
--- Comment #5 from bangerth at gmail dot com 2009-08-31 22:49 ---
(In reply to comment #4)
> > What does GDB currently say for the testcase shown in the initial report?
>
> I think GDB doesn't know about the new type debug information added by gcc
> yet. So it wo
--- Comment #1 from bangerth at gmail dot com 2009-10-26 04:52 ---
Confirmed. Though I'd note that if this was a *nested* function (not a function
in a *nested structure*) -- or a lambda function--, then the warning would make
sense.
--
bangerth at gmail dot com ch
--- Comment #3 from bangerth at gmail dot com 2009-10-28 05:17 ---
(In reply to comment #0)
> There are many other such deviations we noticed in this compiler from the
> normal C++ principles.
In addition to the previous answer: since gcc3.3, many many bugs have been
fixed whe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45606
Wolfgang Bangerth changed:
What|Removed |Added
CC||bangerth at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10200
Wolfgang Bangerth changed:
What|Removed |Added
CC||bangerth at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15272
Wolfgang Bangerth changed:
What|Removed |Added
CC||bangerth at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6936
Wolfgang Bangerth changed:
What|Removed |Added
CC||bangerth at gmail dot com
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11814
Wolfgang Bangerth changed:
What|Removed |Added
CC||bangerth at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10291
Wolfgang Bangerth changed:
What|Removed |Added
CC||bangerth at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10852
Wolfgang Bangerth changed:
What|Removed |Added
CC||bangerth at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30539
--- Comment #3 from Wolfgang Bangerth 2012-01-03
19:11:09 UTC ---
Excellent, and thanks! It's good to see that some of the 5+ year old reports
are still being closed on occasion :-)
(Although I have to say that this one was one of the more humor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316
Wolfgang Bangerth changed:
What|Removed |Added
CC||bangerth at gmail dot com
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47043
Wolfgang Bangerth changed:
What|Removed |Added
CC||joseph.h.garvin at gmail
||bangerth at gmail dot com
Resolution||DUPLICATE
--- Comment #1 from Wolfgang Bangerth 2013-01-05
23:31:11 UTC ---
Confirmed, and a duplicate of an PR that had already been confirmed.
*** This bug has been marked as a
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
--- Comment #7 from bangerth at gmail dot com 2009-11-24 21:52 ---
Jason, is this PR related to your recent work on injecting class names into
scopes? I don't know what makes gcc reject the constructor specialization,
but it seems to me that it might be because it parses the X<&
--- Comment #3 from bangerth at gmail dot com 2010-01-05 13:20 ---
(In reply to comment #2)
> I believe this should be flagged P1, even if it doesn't seem to be a
> regression.
I'm obviously not impartial, but this is the sort of code that template
packs are supposed
--- Comment #3 from bangerth at gmail dot com 2010-01-12 20:58 ---
Dodji,
thanks for the patch. As a matter of etiquette (I think we've had
this conversation with others in the past already): in your patch,
you mark the testcase as "Contributed by Dodji Seketeli",
--- Comment #5 from bangerth at gmail dot com 2010-01-12 21:52 ---
(In reply to comment #4)
> I will stop adding the 'Contributed by' line from now, and will remove
> it from this patch. If you want, I can remove it from all the test cases
> I did commit.
I don'
--- Comment #10 from bangerth at gmail dot com 2010-01-25 18:39 ---
This works with gcc 4.3 and 4.4 I don't have mainline lying around
here but if it really fails there it would be a 4.5 regression
which should get it P1 status. Can someone try?
W.
--
bangerth at gmail do
--- Comment #3 from bangerth at gmail dot com 2010-01-25 18:42 ---
Someone on a win64 machine may have to check this.
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42768
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44629
Wolfgang Bangerth changed:
What|Removed |Added
CC||bangerth at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44629
--- Comment #14 from Wolfgang Bangerth 2011-03-10
04:27:49 UTC ---
(In reply to comment #13)
> Once you know A's T, you have a desired type int (*)(T, T) from which to
> determine which specialization of the template to use.
Hm, I agree that the
--- Comment #2 from bangerth at gmail dot com 2010-09-07 18:08 ---
Corresponding paper, for reference:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2258.pdf
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45114
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45329
Wolfgang Bangerth changed:
What|Removed |Added
CC||bangerth at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45329
--- Comment #3 from Wolfgang Bangerth 2010-11-18
02:42:01 UTC ---
(In reply to comment #2)
> > In either case, assuming that a sufficient number of arguments are
> > involved and if they are all templates of the kind
> > std::vector>
> > (with a
--- Comment #5 from bangerth at gmail dot com 2010-05-07 13:15 ---
*** This bug has been marked as a duplicate of 11856 ***
--
bangerth at gmail dot com changed:
What|Removed |Added
--- Comment #28 from bangerth at gmail dot com 2010-05-07 13:15 ---
*** Bug 44021 has been marked as a duplicate of this bug. ***
--
bangerth at gmail dot com changed:
What|Removed |Added
--- Comment #7 from bangerth at gmail dot com 2010-06-04 16:36 ---
As the author of the benchmark I can confirm that we apparently forgot
to include the proper header file. So you can call it a defect in 447.dealII.
The question is how to deal with this, of course.
W.
--
bangerth
--- Comment #2 from bangerth at gmail dot com 2010-06-10 03:27 ---
This is a regression:
2.95: struct S {anonymous}::f()
3.4: S ::f()
4.0: S::f()
W.
--
bangerth at gmail dot com changed:
What|Removed |Added
--- Comment #8 from bangerth at gmail dot com 2010-07-01 21:38 ---
I think that would already be an improvement.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40793
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48818
Wolfgang Bangerth changed:
What|Removed |Added
CC||bangerth at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49717
Summary: Debug version checking algorithmic preconditions may
have different complexity
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: normal
Priority:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49717
Wolfgang Bangerth changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11582
Wolfgang Bangerth changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
101 - 189 of 189 matches
Mail list logo
