Synopsis: GCC 3.2: 'throw "exception";' not caught by catch
State-Changed-From-To: open->closed
State-Changed-By: bangerth
State-Changed-When: Wed Oct 30 12:55:51 2002
State-Changed-Why:
Not a bug. An exception specification attached to a function
does not impl
Old Synopsis: gcc 3.1 fails to build on sunos 4.1.4
New Synopsis: [Sun OS 4.1.4] gcc 3.1 fails to build
State-Changed-From-To: open->feedback
State-Changed-By: bangerth
State-Changed-When: Mon Nov 25 14:59:50 2002
State-Changed-Why:
I was surprised to see that SunOS4 is indeed still in
Synopsis: GCC crash when sizeof (long) > sizeof (char *),
(splay_tree_compare_fn)strcmp is wrong
State-Changed-From-To: open->feedback
State-Changed-By: bangerth
State-Changed-When: Sat Mar 15 18:44:31 2003
State-Changed-Why:
Do you have a small testcase that triggers the bug, so that
Synopsis: gcc does not warn for always-false "if (!a & 0x4)" bitwise and on boolean
value
State-Changed-From-To: open->analyzed
State-Changed-By: bangerth
State-Changed-When: Sat Mar 22 04:31:36 2003
State-Changed-Why:
Patches already floating around
http://gcc.gnu.org/cg
o
I wouldn't be surprised if an accidentially working program breaks when
you change something like the layout of the vt.
That being said, I reopened the report to let others have a second look on
things.
Regards
Wolfgang
--
--- Comment #9 from bangerth at dealii dot org 2006-04-18 03:21 ---
> It does not matter either. The evaluation of a function argument is an atomic
> procedure.
No, it actually isn't.
> If it starts it should generate a result. Isn't it strange if the
> compi
--- Comment #4 from bangerth at dealii dot org 2006-04-18 03:28 ---
This is not a bug. While the name in a function call is looked up from
inside the class, the name of a member function is looked up in the
global scope. There, the member in question here is inaccessible.
W
--- Comment #1 from bangerth at dealii dot org 2006-04-18 03:30 ---
Confirmed.
--
bangerth at dealii dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #2 from bangerth at dealii dot org 2006-04-18 03:45 ---
Confirmed, though this doesn't seem to have anything to do with PR 9050.
Here's a shorter testcase:
--
struct B{};
struct Bar : virtual B {
template Bar( T const& cast )
--- Comment #3 from bangerth at dealii dot org 2006-04-18 03:47 ---
Confirmed.
--
bangerth at dealii dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #8 from bangerth at dealii dot org 2006-04-18 03:50 ---
We've had numerous such reports in the past. The compiler can't do anything
to detect whether it has run out of stack space. What happens is that a
program allocates stack space, the operating systems gives
--
bangerth at dealii dot org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27053
--- Comment #3 from bangerth at dealii dot org 2006-04-19 02:57 ---
As usual, a shorter testcase would have been appreciated. However, here there
is really nothing that we can do: the executable doesn't link at all. I
have plenty of missing symbols, for example
hide::notAsse
--- Comment #5 from bangerth at dealii dot org 2006-04-19 14:11 ---
No, because then I can't play around with the source. But seriously,
how is the code supposed to be linkable when for example noAssembler
only has a declaration, no definition?
W.
--
http://gcc.gnu.org/bug
--- Comment #6 from bangerth at dealii dot org 2006-04-19 21:20 ---
No. Class C is implicitly a friend of itself.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26838
--- Comment #2 from bangerth at dealii dot org 2006-04-19 21:26 ---
(In reply to comment #0)
> However, the path foo->int->unsigned int is shorter than the path
> foo->A->int->unsigned int, so the former should be chosen.
There is no separate conversion A-&
--- Comment #7 from bangerth at dealii dot org 2006-04-20 03:46 ---
(In reply to comment #6)
> The problem pretty clearly had something to do with overloading operator,()
> and
> a call inside the STL leaking out to an overload in our code, because it went
> away when I
--- Comment #8 from bangerth at dealii dot org 2006-04-20 04:13 ---
Thinking about it some more, I can come up with something. Take this
code here:
-
class specReg{};
template
int operator,(int i, T t) { abort(); return i; }
#include
int main()
{
std::vector v
--- Comment #22 from bangerth at dealii dot org 2006-04-20 14:10 ---
(In reply to comment #17)
> Yes, you pick up my operator in Wolfgang's test case. But in the original
> submission the vector code is *before* my operators, which are consequently
> out
> of scope
--- Comment #24 from bangerth at dealii dot org 2006-04-20 18:16 ---
(In reply to comment #23)
> Actually I don't see why the comma operator can be overridden in C++ (yes this
> I am raising a question about why the standards says it can).
It was mid-March when Stroustru
--- Comment #1 from bangerth at dealii dot org 2006-05-03 16:00 ---
This seems to work on the 4.1.x branch, however. So it must be a regression.
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27397
--- Comment #1 from bangerth at dealii dot org 2006-05-03 16:01 ---
Confirmed.
--
bangerth at dealii dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #1 from bangerth at dealii dot org 2006-05-22 22:46 ---
Confirmed. I guess the workaround is to simply not use the parenthesis.
Nevertheless, this is a regression introduced with the new parser in 3.4.0.
W.
--
bangerth at dealii dot org changed:
What
--- Comment #1 from bangerth at dealii dot org 2006-05-26 14:56 ---
This didn't fail with 4.0.2pre, so it must be a regression on a release branch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27722
--- Comment #1 from bangerth at dealii dot org 2006-05-26 14:59 ---
Confirmed. A regression.
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #2 from bangerth at dealii dot org 2006-05-26 15:00 ---
Confirmed. A regression.
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #4 from bangerth at dealii dot org 2006-05-26 15:04 ---
(In reply to comment #1)
> I think GCC 4.2.0 is correct in saying the function call is ambiguous, bar is
> still a template class.
Most definitely, foo::bar is not a template class, and the only
thing the cal
--- Comment #1 from bangerth at dealii dot org 2006-05-26 15:04 ---
Confirmed.
--
bangerth at dealii dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #1 from bangerth at dealii dot org 2006-05-26 15:06 ---
Confirmed.
--
bangerth at dealii dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #1 from bangerth at dealii dot org 2006-05-26 15:06 ---
Confirmed..
--
bangerth at dealii dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #1 from bangerth at dealii dot org 2006-05-26 15:08 ---
Confirmed.
--
bangerth at dealii dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #4 from bangerth at dealii dot org 2006-05-26 15:14 ---
Confirmed. Though it is worth mentioning that icc has the same "problem".
--
bangerth at dealii dot org changed:
What|Removed
--- Comment #1 from bangerth at dealii dot org 2006-05-26 15:16 ---
Confirmed.
--
bangerth at dealii dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #2 from bangerth at dealii dot org 2006-05-26 15:18 ---
This works fine with 4.0.2, and 4.1-pre and 4.2-pre snapshots I have here.
Could you check that it works for you as well with a recent snapshot?
Thanks
W.
--
bangerth at dealii dot org changed:
What
--- Comment #2 from bangerth at dealii dot org 2006-05-26 15:21 ---
> template
> void f(A, vector A, int);
You meant __vector here.
Certainly, the expectation is that the vector attribute will apply to the
type only after instantiation. Whether that is feasible is a different
--- Comment #1 from bangerth at dealii dot org 2006-05-26 14:57 ---
Confirmed.
--
bangerth at dealii dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #5 from bangerth at dealii dot org 2006-05-26 14:58 ---
Just for completeness' sake: confirmed.
--
bangerth at dealii dot org changed:
What|Removed |
--- Comment #1 from bangerth at dealii dot org 2006-05-26 15:26 ---
gcc parses this as
template
typename A::I foo (T) { return 0; }
i.e. as meaning that the argument is not an integer, but a function that
returns an integer.
A simpler testcase is this (icc accepts it, though I'
--- Comment #1 from bangerth at dealii dot org 2006-05-26 15:28 ---
Confirmed.
--
bangerth at dealii dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #2 from bangerth at dealii dot org 2006-05-26 15:29 ---
Confirmed, but low priority. One should just follow the first error message.
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #2 from bangerth at dealii dot org 2006-05-26 15:37 ---
Confirmed. We should not be calling the conversion operator.
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #2 from bangerth at dealii dot org 2006-05-26 15:38 ---
As mentioned before, this is legal code.
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #2 from bangerth at dealii dot org 2006-05-28 18:58 ---
(In reply to comment #0)
> I'm not quite sure whether writing "class" before "A::B::C" is valid
> or has to be replaced by "typename".
This is the subject of DR 180.
W.
--- Comment #1 from bangerth at dealii dot org 2006-05-31 02:23 ---
Confirmed
--
bangerth at dealii dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #3 from bangerth at dealii dot org 2006-05-31 02:28 ---
Can you verify whether this problem persists in the gcc 4.0.x series or
later? gcc 3.4.x is no longer maintained, and any patch will not be
backported.
Thanks
W.
--
bangerth at dealii dot org changed
--- Comment #1 from bangerth at dealii dot org 2006-05-31 02:28 ---
Confirmed.
--
bangerth at dealii dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #1 from bangerth at dealii dot org 2006-05-31 02:29 ---
Confirmed
--
bangerth at dealii dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #1 from bangerth at dealii dot org 2006-05-31 02:31 ---
I confirm the ICE with 4.0.x. With 4.1.x, we get a duplicate error message:
g/x> /home/bangerth/bin/gcc-4.1-pre/bin/c++ -c x.cc
x.cc:12: error: variable-size type declared outside of any function
x.cc:12: er
--- Comment #1 from bangerth at dealii dot org 2006-05-31 02:32 ---
Confirmed
--
bangerth at dealii dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #1 from bangerth at dealii dot org 2006-05-31 02:33 ---
Confirmed
--
bangerth at dealii dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #5 from bangerth at dealii dot org 2006-05-31 14:57 ---
Thanks for the feedback. It is apparently fixed then...
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
--
bangerth at dealii dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27826
--- Comment #11 from bangerth at dealii dot org 2006-06-08 17:26 ---
(In reply to comment #8)
> Bangerth, why did you change the Priority? That is the job of the Release
> manager.
Actually, as a remark, I believe this isn't true. Bugmasters have always
adjusted initial pr
--- Comment #16 from bangerth at dealii dot org 2006-06-15 03:39 ---
(In reply to comment #13)
> and the test case never exceeded 1 GB vm with r11. I would certainly hope
> that gcc would politely report vm exhaustion as out-of-memory or some such
> rather than segfaulti
--- Comment #10 from bangerth at dealii dot org 2006-06-15 03:45 ---
This problem persists with gcc4.1.x from 2006-06-13. I believe I get the
same glibc fault in one of my codes, which isn't particularly surprising
given that Volker used widely used std:: components in his progr
--- Comment #2 from bangerth at dealii dot org 2006-06-16 22:51 ---
Confirmed.
--
bangerth at dealii dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #3 from bangerth at dealii dot org 2006-06-16 22:55 ---
The code is invalid, however: explicit specializations must be declared
before they are first used. In the snippet, B::B is used in foo()
before the specialization is declared. The ICE consequently also goes
away if a
--- Comment #1 from bangerth at dealii dot org 2006-06-16 22:56 ---
This doesn't show up in 4.1.2pre 20060605, so must have been introduced after
that.
--
bangerth at dealii dot org changed:
What|Removed |
--- Comment #2 from bangerth at dealii dot org 2006-06-16 23:00 ---
Actually, 4.0.x is the only compiler that I can get to ICE:
g/x> /home/bangerth/bin/gcc-4.0.x/bin/c++ -O3 -c x.cc
x.cc: In instantiation of 'B<0>':
x.cc:8: instantiated from here
x.cc:5: error: n
--- Comment #1 from bangerth at dealii dot org 2006-06-16 23:02 ---
Confirmed.
--
bangerth at dealii dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #3 from bangerth at dealii dot org 2006-07-11 08:29 ---
As usual, a reduced (or at least smaller than 51,000 lines) testcase would be
supremely helpful...
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #41 from bangerth at dealii dot org 2009-01-06 15:46 ---
(In reply to comment #40)
> I read all comments and saw a patch. But I don't know how I can fix my gcc
> with
> this patch.
The easiest way is to wait for gcc 4.4.
W.
--
http://gcc.gnu.org/bugzill
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bangerth at dealii dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3
work
}
doesn't appear to work:
g/x> /home/bangerth/bin/x86/gcc-mainline/bin/c++ -std=c++0x -c x.cc
x.cc: In function 'void foo()':
x.cc:6: error: no match for call to '(std::_Bind))(int)>) (int)'
/home/bangerth/bin/x86/gcc-mainline/lib/gcc/i686-pc-linux-gnu
--- Comment #1 from bangerth at dealii dot org 2009-01-16 23:15 ---
Btw, the equivalent that uses boost::bind works just fine.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38889
--- Comment #5 from bangerth at dealii dot org 2009-01-17 01:41 ---
(In reply to comment #2)
> I'm seeing the same thing with Boost.Bind (boost 1.37, GCC 4.2.1).
boost.bind appears to work just fine for me, though!?
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35569
--- Comment #7 from bangerth at dealii dot org 2009-01-18 03:58 ---
(In reply to comment #6)
> Maybe this issue isn't sufficiently clarified in the audit. Unless I'm badly
> mistaken (Jon, Chris will correct me), this is not a bug for a C++03 + TR1
> bind
>
--- Comment #3 from bangerth at dealii dot org 2009-01-23 19:26 ---
I see this as well. It triggers a ton of time in boost::graph code.
I think it should have higher priority than P3.
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #7 from bangerth at dealii dot org 2009-01-23 19:31 ---
I see this as well. It triggers a lot when using boost::graph which
uses empty classes as tags all over the place. A simple case with
boost::graph would be this:
--
#include
using namespace
--- Comment #5 from bangerth at gmail dot com 2009-01-27 16:00 ---
Richard,
this isn't a duplicate of PR 38851: while the testcase there indeed now
passes, the one in the current PR still fails.
Best
Wolfgang
--
bangerth at gmail dot com changed:
What|Re
--
bangerth at gmail dot com changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38908
--- Comment #9 from bangerth at gmail dot com 2009-01-28 17:27 ---
Created an attachment (id=17203)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17203&action=view)
Failing testcase
Richard,
I hate to break the news to you but there are even more cases. Attached
is a fi
--- Comment #10 from bangerth at gmail dot com 2009-01-28 17:28 ---
Re-open
--
bangerth at gmail dot com changed:
What|Removed |Added
Status|RESOLVED
--- Comment #5 from bangerth at gmail dot com 2009-01-30 15:00 ---
(In reply to comment #4)
> However, I'm still analyzing whether we really want to reject. As data points,
> ICC doesn't, even in strict mode; on the other hand Comeau rejects the
> identifier "
--- Comment #3 from bangerth at gmail dot com 2009-01-30 15:03 ---
This is probably related to PR 2288.
--
bangerth at gmail dot com changed:
What|Removed |Added
--- Comment #5 from bangerth at gmail dot com 2009-01-30 15:05 ---
*** Bug 39038 has been marked as a duplicate of this bug. ***
--
bangerth at gmail dot com changed:
What|Removed |Added
--- Comment #4 from bangerth at gmail dot com 2009-01-30 15:05 ---
*** This bug has been marked as a duplicate of 18770 ***
--
bangerth at gmail dot com changed:
What|Removed |Added
--- Comment #1 from bangerth at gmail dot com 2009-01-30 15:13 ---
Yes, I think this would be an optimizing compiler could potentially perform.
At the same time I think you are expecting too much from the compiler: it
would have to have a semantic understanding of what the strlen
--- Comment #1 from bangerth at gmail dot com 2009-01-30 15:20 ---
Confirmed. The original testcase had a function argument of type
pointer-to-pointer-to-array-of-unknown-size, but this testcase
also fails:
template
bool f (T_ p);
bool g ()
{ return f(0
--
bangerth at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed
--- Comment #1 from bangerth at gmail dot com 2009-01-30 15:23 ---
Confirmed.
--
bangerth at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #1 from bangerth at gmail dot com 2009-01-30 15:27 ---
Confirmed. This used to work in 4.1 where we got the following error
(which does not earn the prize for the prettiest error message ever):
g/x> /home/bangerth/bin/gcc-4.1.1/bin/c++ -c x.cc
x.cc: In function '
--- Comment #2 from bangerth at gmail dot com 2009-01-30 15:28 ---
Thinking some more about it, I believe that the code is actually valid.
icc accepts it, for comparison.
W.
--
bangerth at gmail dot com changed:
What|Removed |Added
--- Comment #5 from bangerth at gmail dot com 2009-01-30 15:29 ---
I think Jason confirmed this already...
--
bangerth at gmail dot com changed:
What|Removed |Added
--- Comment #10 from bangerth at gmail dot com 2009-01-30 15:37 ---
(In reply to comment #9)
> Following the twisted maze that is BOOST_CLASS_EXPORT() leads me to think that
> it is (very) roughly equivalent to this:
>
> void dummy(boost::archive::xml_iarchive &
--- Comment #3 from bangerth at gmail dot com 2009-01-30 15:45 ---
Confirmed. There is no need to convolve error messages like that.
W.
--
bangerth at gmail dot com changed:
What|Removed |Added
--- Comment #16 from bangerth at gmail dot com 2009-01-30 15:49 ---
(In reply to comment #5)
> Excuse me, but I do not understand what makes this code invalid. Could anybody
> explain? If so, does this apply to all the test cases given (also for bugs
> that
> are marked a
--- Comment #17 from bangerth at gmail dot com 2009-01-30 15:51 ---
*** Bug 38681 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 2009-01-30 15:51 ---
(In reply to comment #5)
> Did I understand this wrong ? Does the correct interpretation of the standard
> not allow for member-function-pointers as non-type arguments ?
It does, but it requires them to be in a co
--- Comment #2 from bangerth at gmail dot com 2009-01-30 15:58 ---
The standard details certain side effects of throwing exceptions such
as allocating and freeing memory as well as setting expressions that
std::uncaught_exception can evaluate. These side effects can not
always be
--- Comment #2 from bangerth at gmail dot com 2009-01-30 16:02 ---
Confirmed. Gcc would have to keep track of the actual types of variables.
W.
--
bangerth at gmail dot com changed:
What|Removed |Added
gcc dot gnu dot org
ReportedBy: bangerth at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40155
--- Comment #1 from bangerth at gmail dot com 2009-05-15 02:56 ---
Oh, should've said:
g/x> /home/bangerth/bin/x86/gcc-mainline/bin/c++ -std=c++0x -c x.cc
x.cc:9: error: invalid conversion from 'int (*)(double)' to 'int (*)()'
x.cc:5: error: too man
processed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
>> c++ -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../mainline/configure --enable-languages=c,c++
--enable-checking --with-mpfr=/home/bangerth/bin/x86
--with-
--- Comment #6 from bangerth at gmail dot com 2009-07-06 20:56 ---
(In reply to comment #3)
I had to stare at the testcase in comment #3 for a little while and thought
others may have to as well: it fails because the inheritance from Base is
*private*, not because the dynamically
--- Comment #4 from bangerth at gmail dot com 2009-08-05 17:54 ---
(In reply to comment #3)
> &c.f isn't even valid, it should be &C::f
>
> I didn't check the code, but that message isn't used for member variables or
> nested types, so if it does on
--- Comment #5 from bangerth at gmail dot com 2009-08-05 17:57 ---
However, one of my gripes with the previous error message is that it's
just too obscure: where did I forget the '&', and why would I have wanted
to write them in the first place? It could have said
--- Comment #7 from bangerth at gmail dot com 2009-08-05 18:47 ---
(In reply to comment #6)
> Examples where the ampersand probably makes more sense are:
>
> g++.dg/rtti/typeid8.C
> g++.dg/conversion/memfn2.C
> g++.old-deja/g++.other/asm2.C
Possibly, but in all thos
--- 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 #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
1 - 100 of 1203 matches
Mail list logo
