ICE on invalid code.
On 2007-09-16 14:14Z, Alexander Favorov wrote:
>
> typedef enum {unknown_output=-1,text_output=0,comment_output=1,html_output=2}
> output_mode_type;
'::text_output' is an enumerator.
> class Diagnostics:public ostringstream
> {
...
> public:
> output_mode_type output
Alexander Favorov wrote:
> g++ DiagnosticsTest.cpp
>
> produces such an output:
>
> In file included from DiagnosticsTest.cpp:6:
> Diagnostics.hpp:29: internal compiler error: in
> type_dependent_expression_p, at cp/pt.c:12037
> Please submit a full bug report,
> with preprocessed source if appro
g++ DiagnosticsTest.cpp
produces such an output:
In file included from DiagnosticsTest.cpp:6:
Diagnostics.hpp:29: internal compiler error: in
type_dependent_expression_p, at cp/pt.c:12037
Please submit a full bug report,
with preprocessed source if appropriate.
See http://cygwin.com/problems.h
Christopher Faylor wrote:
> On Sun, May 28, 2006 at 08:48:19AM -0700, Jim Kleckner wrote:
>> Indeed, cgf is a magician and his patch in snapshot *2006-05-27 appears
>> to fix the signal handler issue for Python. As mentioned in his patch
>> message, this may fix the signal handler issues for many
On Sun, May 28, 2006 at 08:48:19AM -0700, Jim Kleckner wrote:
>Jim Kleckner wrote:
>>Brian Dessent wrote:
>>>As you can see, this all is contingent upon a program like GDB using
>>>the Windows debug API. Without that, the entire issue is irrelevant,
>>>so I can't see how this possibly would apply
Jim Kleckner wrote:
Brian Dessent wrote:
As you can see, this all is contingent upon a program like GDB using the
Windows debug API. Without that, the entire issue is irrelevant, so I
can't see how this possibly would apply to Python.
Thanks for explaining how the Windows debug API is the
Brian Dessent wrote:
As you can see, this all is contingent upon a program like GDB using the
Windows debug API. Without that, the entire issue is irrelevant, so I
can't see how this possibly would apply to Python.
Thanks for explaining how the Windows debug API is the one
actually catching
Jim Kleckner wrote:
> This appears related to the signal handling problem that GDB experiences
> and documented at length. One starting point for this discussion is the
> thread here:
> http://www.cygwin.com/ml/cygwin/2006-05/msg00691.html
I don't see any way that these two issues are related.
Jim Kleckner wrote:
Could someone provide a pointer to the GDB change?
The changelog is here: *http://tinyurl.com/rnhjw
win32_nat.c is listed here: **http://tinyurl.com/rnhjw
The key change diffs appear to be here:
**http://tinyurl.com/z5vze
*
--
Unsubscribe info: http://cygwin.com/m
Max Bowsher wrote:
Hi,
I compiled a C++ Python Extension, and found that it caused the Python
interpreter process to silently die (with a *zero* exitcode!) when it
attempted to load the extension module.
I traced the problem to the line:
static ios_base::Init __ioinit;
in .
It seems that whe
Hi,
I compiled a C++ Python Extension, and found that it caused the Python
interpreter process to silently die (with a *zero* exitcode!) when it
attempted to load the extension module.
I traced the problem to the line:
static ios_base::Init __ioinit;
in .
It seems that when the module is dlope
11 matches
Mail list logo
