[Bug c++/14912] Do not print default template arguments in error messages
--- Additional Comments From giovannibajo at libero dot it 2005-03-26 11:59 --- Subject: Re: Do not print default template arguments in error messages gdr at integrable-solutions dot net [EMAIL PROTECTED] wrote: The first patch will deal with just removal of default arguments, and I believe that the less intrusive and clean solution is to display default in the with clause. please: (1) don't do an unconditional removal; (2) don't show default. I would oppose any patch short of that. Yes, the remove will be conditioned on a flag (but I believe this has to become the default). which flag? A compiler option? I don't think a multiplication of compiler options for this stuff is a good way to go. Then what? You said don't do an unconditional removal. What did you mean, exactly? Giovanni Bajo -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912
[Bug c++/14912] Do not print default template arguments in error messages
--- Additional Comments From dave at boost-consulting dot com 2005-03-26
12:57 ---
Subject: Re: Do not print default template arguments in error messages
gdr at integrable-solutions dot net [EMAIL PROTECTED] writes:
--- Additional Comments From gdr at integrable-solutions dot net
2005-03-26 04:13 ---
Subject: Re: Do not print default template arguments in error messages
dave at boost-consulting dot com [EMAIL PROTECTED] writes:
[...]
| Please, I'm begging you not to go down this road. GCC is one of the
I know you have strong opinions on what compilers should print; we had
part of this discussions on -core and it did not seem like that was a
universal solution that handles all the cases.
First, I don't know if I've misunderstood what you meant by show how
it was written, so I'd really appreciate if you'd clarify that before
we go any further down this road. To make it easy on you, let me try
to be very clear about what I fear. If you run this through the
Comeau on-line compiler:
template class T
struct foo1
{
// ...
typedef T* pointer;
};
template class T
struct foo2
{
// ...
typedef T** pointer; // oops, should've been T*
};
template class U, class V
struct bar
{
bar( V v )
{
U u = v;
}
};
template class U, class V
struct baz
{
baz()
{
bar
typename foo1U::pointer,
typename foo2V::pointer
b(0);
};
};
bazint,int x;
You'll get a message that says:
line 20: error: a value of type foo2int::pointer cannot be
used to initialize an entity of type foo1int::pointer
U u = v;
^
detected during:
instantiation of barU, V::bar(V) [with U=foo1int::pointer,
V=foo2int::pointer] at line 32
instantiation of bazU, V::baz() [with U=int, V=int] at line 36
It is the appearance of foo1int::pointer and foo2int::pointer
in the error message, rather than int* and int**, that I'm
concerned about. Nothing in the error message points at
the definition of foo1 or foo2 above, so the user gets no help in
understanding which one might be the true cause of the error. And
even if it pointed at foo1 or foo2, in general the real source of
foo2T::pointer could easily have been some other template:
template class T
struct foo1
{
typedef typename foobarT::value_type* pointer;
};
This happens very typically in the standard library, where nested
types are transferred and modified from allocators into containers and
so forth. I want to be sure that GCC continues to show int*
and int** in these cases.
I'm going to scheme that handle the majority of the cases right.
Assuming your intention is to do what I fear (otherwise, please ignore
the rest):
On what basis can you say that? Have you got some measurement of what
the majority of cases look like, and an objective way to understand
what right is?
No solution universally handles all the cases perfectly, but we can
make some objective analysis of how tractable it is to find any given
piece of important information in the various schemes. Going down the
EDG path may make a few kinds of analysis incrementally easier, but it
makes other kinds vastly harder, to the point of being nearly
impossible. I keep a copy of GCC on hand at all times just for
situations like this, no mater what compiler I'm using. I find it
ironic that if GCC makes the change I fear, the only compiler left
that yields workable error messages in these kinds of situations will
be from Microsoft.
| only compilers that gets it right today (VC8 will follow), and all
| the ones that try to follow the show how it was written rule
| often give errors that are, for all practical purposes, unusable.
| If you make GCC work like the others, it will be a leap backwards
| and a terrible disservice to users.
yes, you're entitled to your opinions.
This is very disappointing. Condescencion is entirely uncalled for.
I won't claim to know what your level of expertise is, but I know I've
done more comparative research on template-related error messages than
most people. If you care about GCC's usability you ought at least to
take what I say seriously.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912
[Bug c++/14912] Do not print default template arguments in error messages
--- Additional Comments From gdr at integrable-solutions dot net 2005-03-26 15:40 --- Subject: Re: Do not print default template arguments in error messages giovannibajo at libero dot it [EMAIL PROTECTED] writes: | --- Additional Comments From giovannibajo at libero dot it 2005-03-26 11:59 --- | Subject: Re: Do not print default template arguments in error messages | | gdr at integrable-solutions dot net [EMAIL PROTECTED] wrote: | | The first patch will deal with just removal of default | arguments, and I believe that the less intrusive and clean | solution is to | display default in the with clause. | please: |(1) don't do an unconditional removal; |(2) don't show default. | I would oppose any patch short of that. | | Yes, the remove will be conditioned on a flag (but I believe this | has to become | the default). | | which flag? A compiler option? I don't think a multiplication of | compiler options for this stuff is a good way to go. | | Then what? You said don't do an unconditional removal. What did you mean, | exactly? Use the format flags -- I think I already said that -- '#'. If it is present (i.e. the verbose parameter non zero, therefore the flags asking for default values) then honor it. Otherwise effectively don't print the default values. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912
[Bug c++/20647] New: Wrong typeid for incomplete types
On linux x86, using the following 2 little sources files :
-- 1.C
#include typeinfo
class A {
public:
A() {}
};
extern void foo(const std::type_info);
int main()
{
foo(typeid(A*));
return 0;
}
---
-- 2.C
#include iostream
#include typeinfo
class A;
void foo(const std::type_info t)
{
if (t == typeid(A*))
{
std::cout OK\n;
}
else
{
std::cout KO\n;
}
}
---
and compiling with g++ 1.C 2.C gives me KO output. This means that the
comparison of the type_info passed to foo and the one computed by typeid(A*)
where A* is an incomplete type failed.
In the binary there are 2 type_info symbols for A* :
% nm a.out| grep TIP1A
0804884c r _ZTIP1A
0804882c V _ZTIP1A
I tried this test with many compilers and it worked with g++ 3.2 and failed with
g++ 3.3, 3.4 and pre4.0 (with the same binutils). Precise versions :
% gcc-3.2 --version
gcc-3.2 (GCC) 3.2.3 (Debian)
% gcc-3.3 --version
gcc-3.3 (GCC) 3.3.5 (Debian 1:3.3.5-8ubuntu2)
% gcc-3.4 --version
gcc-3.4 (GCC) 3.4.4 20050209 (prerelease) (Debian 3.4.3-9ubuntu3)
% gcc-4.0 --version
gcc-4.0 (GCC) 4.0.0 20050301 (prerelease) (Debian 4.0-0pre6ubuntu6)
--
Summary: Wrong typeid for incomplete types
Product: gcc
Version: 3.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: frederic dot riss at gmail dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20647
[Bug c++/14912] Do not print default template arguments in error messages
--- Additional Comments From gdr at integrable-solutions dot net 2005-03-26 15:55 --- Subject: Re: Do not print default template arguments in error messages dave at boost-consulting dot com [EMAIL PROTECTED] writes: | --- Additional Comments From dave at boost-consulting dot com 2005-03-26 12:57 --- | Subject: Re: Do not print default template arguments in error messages | | gdr at integrable-solutions dot net [EMAIL PROTECTED] writes: | | --- Additional Comments From gdr at integrable-solutions dot net 2005-03-26 04:13 --- | Subject: Re: Do not print default template arguments in error messages | | dave at boost-consulting dot com [EMAIL PROTECTED] writes: | | [...] | | | Please, I'm begging you not to go down this road. GCC is one of the | | I know you have strong opinions on what compilers should print; we had | part of this discussions on -core and it did not seem like that was a | universal solution that handles all the cases. | | First, I don't know if I've misunderstood what you meant by show how | it was written, If user writes vectorint, I would like to print vectorT [with T = int], not vectorint, default (or variants). Similarly, if user wirtes vectorint, allocatorint , then ideally I would also like to print vectorT, Allocator [with T = int, Allocator = alloctorint]. There are discussions about carret diagnostics, but this is not it. [...] | I'm going to scheme that handle the majority of the cases right. | | Assuming your intention is to do what I fear (otherwise, please ignore | the rest): I can't ignore ignore the rest, not because I'm goiing to do something stupid but because you also request to tke what you're saying seriously. And also, because, I'm a bit fed up of your arrogance. [...] | | only compilers that gets it right today (VC8 will follow), and all | | the ones that try to follow the show how it was written rule | | often give errors that are, for all practical purposes, unusable. | | If you make GCC work like the others, it will be a leap backwards | | and a terrible disservice to users. | | yes, you're entitled to your opinions. | | This is very disappointing. Condescencion is entirely uncalled for. oh really? when people try to do things, you immediately think or fear that they are going to do the wrong thing. Oh yeah, that is not called condescencion, you're just feeling they are stupid. | I won't claim to know what your level of expertise is, but I know I've | done more comparative research on template-related error messages than | most people. If you care about GCC's usability you ought at least to | take what I say seriously. Oh, I do read what you write -- everytime I have the chance. I know also from experience usually it is probably good not to say anything contrary to your opinions. But I can't resist, especially when you don't quite understand the variations. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912
[Bug c++/14912] Do not print default template arguments in error messages
--- Additional Comments From dave at boost-consulting dot com 2005-03-26 16:14 --- This is obviously becoming personal. I wanted a record of my technical concerns in the bug database, but as the tone has changed I don't think it's appropriate to continue this here. I will reply to Gaby offline and try to clear up the misunderstandings there. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912
[Bug c++/20647] Wrong typeid for incomplete types
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-26 16:59 --- Hmm, this works without weak symbols. -- What|Removed |Added Summary|Wrong typeid for incomplete |Wrong typeid for incomplete |types |types http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20647
[Bug target/20636] [4.1 Regression] Bootstrap failure on Linux/PowerPC64 with rtl checking
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-26 17:35 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20636
[Bug target/20636] [4.1 Regression] Bootstrap failure on Linux/PowerPC64 with rtl checking
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-26 17:35 --- Subject: Bug 20636 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-03-26 17:35:44 Modified files: gcc: ChangeLog gcc/config/rs6000: rs6000.md Log message: 2005-03-26 Andrew Pinski [EMAIL PROTECTED] PR target/20636 * config/rs6000/rs6000.md (extendsfdf2_fpr): Check to make sure that we have a REG before getting its REGNO. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.8000r2=2.8001 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/rs6000/rs6000.md.diff?cvsroot=gccr1=1.356r2=1.357 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20636
[Bug fortran/18476] internal compiler error on strange read
--- Additional Comments From paulthomas2 at wanadoo dot fr 2005-03-26 17:37 --- Tobi and Thomas, This one is fixed: as of 20050324, you get a nice friendly error message: In file namelist/pr18476.f90:6 read(chr,nml) 1 Error: Variable 'nml' has not been assigned a format label at (1) I just spent an hour tracking down the source without trying gfc first. *dughhh* -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18476
[Bug fortran/18476] internal compiler error on strange read
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-26 17:44 --- Fixed since at least 20050321. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18476
[Bug fortran/18959] ICE in cshift of character array
-- Bug 18959 depends on bug 18476, which changed state. Bug 18476 Summary: internal compiler error on strange read http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18476 What|Old Value |New Value Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18959
[Bug fortran/19292] [meta-bug] g77 features lacking in gfortran
-- Bug 19292 depends on bug 18476, which changed state. Bug 18476 Summary: internal compiler error on strange read http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18476 What|Old Value |New Value Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19292
[Bug fortran/14067] no warning when character data statement overflows declared size
-- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Last reconfirmed|2004-12-15 04:44:48 |2005-03-26 17:48:40 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14067
[Bug fortran/18476] internal compiler error on strange read
--- Additional Comments From tobi at gcc dot gnu dot org 2005-03-26 17:50 --- This is most probably related to Feng Wang's 2005-03-15 patch. -- What|Removed |Added Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18476
[Bug target/20634] code fails to compile/code generation issue with -funit-at-a-time
-- What|Removed |Added Component|rtl-optimization|target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20634
[Bug java/20648] New: [4.1 regression] ICE in cfg_layout_redirect_edge_and_branch_force
While building libjava: $ /bin/sh ./libtool --mode=compile /tmp/cvs/gcc-20050326/Build/./gcc/gcj -B/tmp/cvs/gcc-20050326/Build/./gcc/ -B/usr/local/ia64-suse-linux/bin/ -B/usr/local/ia64-suse-linux/lib/ -isystem /usr/local/ia64-suse-linux/include -isystem /usr/local/ia64-suse-linux/sys-include -funwind-tables -fclasspath= -fbootclasspath=/tmp/cvs/gcc-20050326/Build/ia64-suse-linux/libjava':'../../../libjava':'../../../libjava/external/w3c_dom':'../../../libjava/external/sax --encoding=UTF-8 -Wno-deprecated -g -O2 -fjni -findirect-dispatch -c -o gnu-xml.lo `find gnu/xml -name '*.class' -print` /tmp/cvs/gcc-20050326/Build/./gcc/gcj -B/tmp/cvs/gcc-20050326/Build/./gcc/ -B/usr/local/ia64-suse-linux/bin/ -B/usr/local/ia64-suse-linux/lib/ -isystem /usr/local/ia64-suse-linux/include -isystem /usr/local/ia64-suse-linux/sys-include -funwind-tables -fclasspath= -fbootclasspath=/tmp/cvs/gcc-20050326/Build/ia64-suse-linux/libjava:../../../libjava:../../../libjava/external/w3c_dom:../../../libjava/external/sax --encoding=UTF-8 -Wno-deprecated -g -O2 -fjni -findirect-dispatch -c gnu/xml/dom/ls/ReaderInputStream.class gnu/xml/dom/ls/WriterOutputStream.class gnu/xml/dom/ls/FilteredSAXEventSink.class gnu/xml/dom/ls/DomLSInput.class gnu/xml/dom/ls/DomLSOutput.class gnu/xml/dom/ls/DomLSParser.class gnu/xml/dom/ls/SAXEventSink.class gnu/xml/dom/ls/DomLSSerializer.class gnu/xml/dom/ls/DomLSException.class gnu/xml/dom/DomXPathNSResolver.class gnu/xml/dom/ImplementationList.class gnu/xml/dom/DomNsNode.class gnu/xml/dom/DomXPathExpression.class gnu/xml/dom/DomNSResolverContext.class gnu/xml/dom/JAXPFactory\$JAXPBuilder.class gnu/xml/dom/DTDAttributeTypeInfo.class gnu/xml/dom/DomNotation.class gnu/xml/dom/DomDocument.class gnu/xml/dom/DomEvent\$DomMutationEvent.class gnu/xml/dom/DomCharacterData.class gnu/xml/dom/DomComment.class gnu/xml/dom/DomNode\$DomEventException.class gnu/xml/dom/Consumer.class gnu/xml/dom/Consumer\$Backdoor.class gnu/xml/dom/DomImpl.class gnu/xml/dom/DomDocumentFragment.class gnu/xml/dom/DomNode\$ListenerRecord.class gnu/xml/dom/DomEntity.class gnu/xml/dom/DomCDATASection.class gnu/xm l/dom/DomProcessingInstruction.class gnu/xml/dom/DomDocumentConfiguration.class gnu/xml/dom/DomNode\$ShadowList.class gnu/xml/dom/DomNode.class gnu/xml/dom/DomDocumentBuilderFactory.class gnu/xml/dom/DomEvent\$DomUIEvent.class gnu/xml/dom/ImplementationSource.class gnu/xml/dom/JAXPFactory.class gnu/xml/dom/DomNamedNodeMap.class gnu/xml/dom/DomEntityReference.class gnu/xml/dom/DomElement.class gnu/xml/dom/DomDoctype.class gnu/xml/dom/DomExtern.class gnu/xml/dom/DomNode\$LiveNodeList.class gnu/xml/dom/DomDocumentBuilder.class gnu/xml/dom/DomText.class gnu/xml/dom/DomDOMException.class gnu/xml/dom/DomAttr.class gnu/xml/dom/DomNodeIterator.class gnu/xml/dom/DTDElementTypeInfo.class gnu/xml/dom/DomEvent.class gnu/xml/dom/DomXPathResult.class gnu/xml/dom/DomIterator.class gnu/xml/util/SAXNullTransformerFactory.class gnu/xml/util/XCat\$Catalog.class gnu/xml/util/XCat\$Loader.class gnu/xml/util/SAXNullTransformerFactory\$ListenerAdapter.class gnu/xml/util/XMLWriter.class gnu/xml/util/SAXNullTransformerFactory\$DomTerminus.class gnu/xml/util/DoParse\$MyErrorHandler.class gnu/xml/util/SAXNullTransformerFactory\$DomHandler.class gnu/xml/util/SAXNullTransformerFactory\$NullTransformer.class gnu/xml/util/XHTMLWriter.class gnu/xml/util/DomParser.class gnu/xml/util/XCat\$DoneDelegation.class gnu/xml/util/SAXNullTransformerFactory\$LocatorAdapter.class gnu/xml/util/Resolver.class gnu/xml/util/XCat.class gnu/xml/util/SAXNullTransformerFactory\$NullHandler.class gnu/xml/util/DoParse.class gnu/xml/transform/Bindings.class gnu/xml/transform/OtherwiseNode.class gnu/xml/transform/DocumentFunction.class gnu/xml/transform/ProcessingInstructionNode.class gnu/xml/transform/FunctionAvailableFunction.class gnu/xml/transform/UnparsedEntityUriFunction.class gnu/xml/transform/CopyNode.class gnu/xml/transform/NumberNode.class gnu/xml/transform/FormatNumberFunction.class gnu/xml/transform/URIResolverEntityResolver.class gnu/xml/transform/SortKey.class gnu/xml/transform/NodeNumberNode.class gnu/xml/transform/TextNode.class gnu/xml/transform/KeyFunction.class gnu/xml/transform/Key.class gnu/xml/transform/ChooseNode.class gnu/xml/transform/StreamSerializer.class gnu/xml/transform/ElementAvailableFunction.class gnu/xml/transform/CallTemplateNode.class gnu/xml/transform/ApplyImportsNode.class gnu/xml/transform/TransformerImpl.class gnu/xml/transform/WhenNode.class gnu/xml/transform/MessageNode.class gnu/xml/transform/SAXSerializer.class gnu/xml/transform/ParameterNode.class gnu/xml/transform/WithParam.class gnu/xml/transform/CurrentFunction.class gnu/xml/transform/CommentNode.class gnu/xml/transform/TemplatesImpl.class gnu/xml/transform/AbstractNumberNode.class gnu/xml/transform/IfNode.class gnu/xml/transform
[Bug target/20634] code fails to compile/code generation issue with -funit-at-a-time
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-26 18:22 --- For the first problem with code generation issue, does -fno-strict-aliasing helps? For the second problem with respect with the ICE, well only -O1 -fschedule-insns -funit-at-a-time is needed to reproduce the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20634
[Bug middle-end/20648] [4.1 regression] ICE in cfg_layout_redirect_edge_and_branch_force
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-26 18:25 --- Roger told me he saw the same thing. This is a middle-end bug. -- What|Removed |Added Component|java|middle-end Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20648
[Bug target/20503] openssl compiled with -mcpu=i686 triggers `__i686.get_pc_thunk.bx' referenced in section `.text' of /usr/lib/libc_nonshared.a(elf-init.oS): defined in discarded section `.gnu.linkonce.t.__i686.get_pc_thunk.bx' of /usr/lib/libc_nonshared.a(elf-init.oS)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-26 18:30 --- Well first we need the preprocessed source. Also are you using the GCC provided by SuSE, well I would report it to them first. -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Severity|minor |normal Status|UNCONFIRMED |WAITING GCC build triplet|Reading specs from | |/usr/lib/gcc-lib/i586-suse- | |linux/3.3.4/specs | Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20503
[Bug ada/19384] ACATS c940005 fail (no ZCX) or timeout (ZCX) at runtime on ppc-darwin/linux
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-26 18:32 --- (In reply to comment #2) Is this test still failing on mainline ? On ppc-darwin this passes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19384
[Bug target/20518] Clobber registers,in inline asm. Problem when using rcall
-- What|Removed |Added Component|inline-asm |target GCC build triplet|3.4.3 | GCC host triplet|win | Version|unknown |3.4.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20518
[Bug tree-optimization/19893] gcc.dg/vect/vect-76.c execution test fails on ia64-hpux
-- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-03-26 18:33:30 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19893
[Bug c/20533] documentation: attribute 'used', applied to a variable
-- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-03-26 18:34:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20533
[Bug libstdc++/20534] Erroneous #include of cassert
-- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20534
[Bug target/20546] Loading and storing of packed structure elements uses wrong endian for PPC EABI Little Endian
-- What|Removed |Added GCC target triplet||powerpcle-*-* Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20546
[Bug target/20529] m6811-elf-g++ ICE
-- What|Removed |Added Keywords||ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20529
[Bug c++/20552] ICE on invalid code
-- What|Removed |Added Summary|ICE |ICE on invalid code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20552
[Bug c/20562] no unused warning for static arrays
-- What|Removed |Added Keywords||diagnostic http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20562
[Bug target/20582] ip2k-elf doesn't build
-- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-03-26 18:42:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20582
[Bug libstdc++/20534] Erroneous #include of cassert
--- Additional Comments From gdr at integrable-solutions dot net 2005-03-26 18:44 --- Subject: Re: Erroneous #include of cassert pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes: | -- |What|Removed |Added | | CC||pinskia at gcc dot gnu dot |||org | Status|UNCONFIRMED |WAITING I think it is not OK to include cassert or assert.h. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20534
[Bug c++/14912] Do not print default template arguments in error messages
--- Additional Comments From giovannibajo at libero dot it 2005-03-26
19:24 ---
OK, before I clean up the patch, I'll post an example. For this code:
--
#include map
#include vector
#include string
std::mapstd::string, std::vectorint m;
void bar(void)
{
std::vectorint k;
m.insert(std::make_pair(0, k));
}
--
I get this:
path/stl_pair.h: In constructor 'std::pair_T1, _T2::pair(const
std::pair_U1, _U2) [with _U1 = int, _U2 = std::vectorint, _T1 = const
std::string, _T2 = std::vectorint]':
test3.cc:10: instantiated from here
path/stl_pair.h:90: error: invalid conversion from 'const int' to 'const
char*'
path/stl_pair.h:90: error: initializing argument 1
of 'std::basic_string_CharT, _Traits, _Alloc::basic_string(const _CharT*,
const _Alloc) [with _CharT = char]'
(I manually edited 'path')
Without my patch, I get this:
path/stl_pair.h: In constructor `std::pair_T1, _T2::pair(const
std::pair_U1, _U2) [with _U1 = int, _U2 = std::vectorint,
std::allocatorint , _T1 = const std::string, _T2 = std::vectorint,
std::allocatorint ]':
test3.cc:10: instantiated from here
path/stl_pair.h:90: error: invalid conversion from `const int' to `const
char*'
path/stl_pair.h:90: error: initializing argument 1 of
`std::basic_string_CharT, _Traits, _Alloc::basic_string(const _CharT*, const
_Alloc) [with _CharT = char, _Traits = std::char_traitschar, _Alloc =
std::allocatorchar]'
If someone wants to submit an additional testcase, I'm happy to test it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912
[Bug c++/14912] Do not print default template arguments in error messages
--- Additional Comments From giovannibajo at libero dot it 2005-03-26
19:26 ---
Another comparison:
---
#include vector
template class T, int N=0, int X=1
struct A
{
std::vectorT v;
void foo(void)
{ v.doesnotexist(); }
};
void foo(void)
{
Aint,0 a;
a.foo();
}
---
Patched:
test.cc: In member function 'void AT, N, X::foo() [with T = int]':
test.cc:14: instantiated from here
test.cc:9: error: 'class std::vectorint' has no member named 'doesnotexist'
Unpatched:
test.cc: In member function `void AT, N, X::foo() [with T = int, int N = 0,
int X = 1]':
test.cc:14: instantiated from here
test.cc:9: error: 'class std::vectorint, std::allocatorint ' has no member
named 'doesnotexist'
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912
[Bug c/20649] New: Segmentation fault in decl_function_context (tree.c:5116)
Compiling glibc on i686 with GCC 4.0 CVS 20050325 I get this segmentation fault compiling the testsuite: /opt/gcc/4.0-devel/libexec/gcc/i686-suse-linux-gnu/4.0.0/cc1 -fpreprocessed inl-tester.i -quiet -dumpbase inl-tester.c -mpreferred-stack-boundary=2 -mtune=pentiumpro -auxbase-strip /home/aj/builds/glibc/string/inl-tester.o -g -O2 -Wall -Winline -Wstrict-prototypes -Wwrite-strings -std=gnu99 -version -o inl-tester.s GNU C version 4.0.0 20050325 (prerelease) (i686-suse-linux-gnu) compiled by GNU C version 4.0.0 20050325 (prerelease). GGC heuristics: --param ggc-min-expand=63 --param ggc-min-heapsize=63397 tester.c: In function #8216;test_stpncpy#8217;: tester.c:279: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. Using gdb I get the following stacktrace: Program received signal SIGSEGV, Segmentation fault. decl_function_context (decl=0x0) at /home/aj/cvs/gcc-4_0-branch/gcc/tree.c:5116 5116 if (TREE_CODE (decl) == ERROR_MARK) (gdb) bt #0 decl_function_context (decl=0x0) at /home/aj/cvs/gcc-4_0-branch/gcc/tree.c:5116 #1 0x08140c3d in gen_decl_die (decl=value optimized out, context_die=0x4180ed34) at /home/aj/cvs/gcc-4_0-branch/gcc/dwarf2out.c:10502 #2 0x081440ef in decls_for_scope (stmt=0x417e8ccc, context_die=0x4180ed34, depth=2) at /home/aj/cvs/gcc-4_0-branch/gcc/dwarf2out.c:12404 #3 0x08144280 in gen_lexical_block_die (stmt=0x417e8ccc, context_die=0x0, depth=2) at /home/aj/cvs/gcc-4_0-branch/gcc/dwarf2out.c:11647 #4 0x08143e60 in gen_block_die (stmt=0x417e8ccc, context_die=0x4180ebfc, depth=2) at /home/aj/cvs/gcc-4_0-branch/gcc/dwarf2out.c:12365 #5 0x0814417b in decls_for_scope (stmt=value optimized out, context_die=0x4180ebfc, depth=1) at /home/aj/cvs/gcc-4_0-branch/gcc/dwarf2out.c:12417 #6 0x08143fd8 in gen_block_die (stmt=0x417e8c98, context_die=0x4180eb60, depth=1) at /home/aj/cvs/gcc-4_0-branch/gcc/dwarf2out.c:11676 #7 0x0814417b in decls_for_scope (stmt=value optimized out, context_die=0x4180eb60, depth=0) at /home/aj/cvs/gcc-4_0-branch/gcc/dwarf2out.c:12417 #8 0x08142bb6 in gen_subprogram_die (decl=0x40b5b21c, context_die=0x0) at /home/aj/cvs/gcc-4_0-branch/gcc/dwarf2out.c:11475 #9 0x081405c1 in gen_decl_die (decl=0x40b5b21c, context_die=0x401f58f0) at /home/aj/cvs/gcc-4_0-branch/gcc/dwarf2out.c:12682 #10 0x082e4507 in rest_of_compilation () at /home/aj/cvs/gcc-4_0-branch/gcc/passes.c:334 #11 0x0809d9ad in execute_pass_list (pass=0x84335e0) at /home/aj/cvs/gcc-4_0-branch/gcc/tree-optimize.c:533 #12 0x0809dc4b in tree_rest_of_compilation (fndecl=0x40b5b21c) at /home/aj/cvs/gcc-4_0-branch/gcc/tree-optimize.c:668 #13 0x0805a526 in c_expand_body (fndecl=0x40b5b21c) at /home/aj/cvs/gcc-4_0-branch/gcc/c-decl.c:6439 #14 0x08309433 in cgraph_expand_function (node=0x40b5e8dc) at /home/aj/cvs/gcc-4_0-branch/gcc/cgraphunit.c:833 #15 0x08309e6d in cgraph_optimize () at /home/aj/cvs/gcc-4_0-branch/gcc/cgraphunit.c:1698 #16 0x082caa48 in toplev_main (argc=0, argv=0xbfffef44) at /home/aj/cvs/gcc-4_0-branch/gcc/toplev.c:1009 #17 0x40046e80 in __libc_start_main () from /lib/tls/libc.so.6 #18 0x08049aa1 in _start () at start.S:119 -- Summary: Segmentation fault in decl_function_context (tree.c:5116) Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: aj at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: i686-linux-gnu GCC host triplet: i686-linux-gnu GCC target triplet: i686-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20649
[Bug c/20649] Segmentation fault in decl_function_context (tree.c:5116)
--- Additional Comments From aj at gcc dot gnu dot org 2005-03-26 19:39 --- Created an attachment (id=8458) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8458action=view) Preprocessed source file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20649
[Bug debug/20649] [4.0/4.1 Regression] Segmentation fault in decl_function_context (tree.c:5116)
-- What|Removed |Added Component|c |debug Keywords||ice-on-valid-code Summary|Segmentation fault in |[4.0/4.1 Regression] |decl_function_context |Segmentation fault in |(tree.c:5116) |decl_function_context ||(tree.c:5116) Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20649
[Bug debug/20649] [4.0/4.1 Regression] Segmentation fault in decl_function_context (tree.c:5116)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-26 19:44 --- *** This bug has been marked as a duplicate of 19345 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20649
[Bug debug/19345] [4.0/4.1 Regression] Segmentation fault with VLA and inlining and dwarf2
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-26 19:44 --- *** Bug 20649 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19345
[Bug c++/14912] Do not print default template arguments in error messages
--- Additional Comments From gdr at integrable-solutions dot net
2005-03-26 19:52 ---
Subject: Re: Do not print default template arguments in error messages
giovannibajo at libero dot it [EMAIL PROTECTED] writes:
| --- Additional Comments From giovannibajo at libero dot it 2005-03-26
19:24 ---
| OK, before I clean up the patch, I'll post an example. For this code:
|
| --
| #include map
| #include vector
| #include string
|
| std::mapstd::string, std::vectorint m;
|
| void bar(void)
| {
| std::vectorint k;
| m.insert(std::make_pair(0, k));
| }
| --
|
| I get this:
|
| path/stl_pair.h: In constructor 'std::pair_T1, _T2::pair(const
| std::pair_U1, _U2) [with _U1 = int, _U2 = std::vectorint, _T1 = const
| std::string, _T2 = std::vectorint]':
| test3.cc:10: instantiated from here
| path/stl_pair.h:90: error: invalid conversion from 'const int' to 'const
| char*'
| path/stl_pair.h:90: error: initializing argument 1
| of 'std::basic_string_CharT, _Traits, _Alloc::basic_string(const _CharT*,
| const _Alloc) [with _CharT = char]'
|
| (I manually edited 'path')
| Without my patch, I get this:
That is fair improvement. I realize we don't retain std::string in
the last diagnostic, but we don't need to do that before you check-in
your patch -- that is a whole project in itself.
-- Gaby
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912
[Bug libffi/20650] New: float.c fails to build with weird error message
float.c from the libffi test suite fails to build on ppc-linux: /mnt/slice1/gcc-trunk/gcc/libffi/testsuite/libffi.call/float.c: In function 'floating': :1441796: error: impossible constraint in 'asm' compiler exited with status 1 [EMAIL PROTECTED] objdir]$ ./gcc/xgcc -v Using built-in specs. Target: powerpc-unknown-linux-gnu Configured with: /mnt/slice1/gcc-trunk/gcc/configure --prefix=/mnt/slice1/gcc-trunk/testbin --enable-languages=c,c++,java --disable-multilib --enable-java-awt=gtk,xlib --enable-gtk-cairo --disable-checking --disable-static Thread model: posix gcc version 4.1.0 20050326 (experimental) I'll attach the .i and .s file -- Summary: float.c fails to build with weird error message Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libffi AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: andreast at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: powerpc-unknown-linux-gnu GCC host triplet: powerpc-unknown-linux-gnu GCC target triplet: powerpc-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20650
[Bug libffi/20650] float.c fails to build with weird error message
--- Additional Comments From andreast at gcc dot gnu dot org 2005-03-26 20:34 --- Created an attachment (id=8459) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8459action=view) preprocessed source. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20650
[Bug libffi/20650] float.c fails to build with weird error message
--- Additional Comments From andreast at gcc dot gnu dot org 2005-03-26 20:35 --- Created an attachment (id=8460) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8460action=view) preprocessed asm -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20650
[Bug middle-end/20650] float.c fails to build with weird error message
-- What|Removed |Added Component|libffi |middle-end Keywords||rejects-valid Summary|float.c fails to build with |float.c fails to build with |weird error message |weird error message http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20650
[Bug middle-end/20650] float.c fails to build with weird error message
-- What|Removed |Added Attachment #8459|application/octet-stream|text/plain mime type|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20650
[Bug other/20594] Building AVR cross compiler: cannot build libgcc2
--- Additional Comments From dannysmith at users dot sourceforge dot net 2005-03-26 20:41 --- -I. -I -I../../gcc-3.4.3/gcc -I../../gcc-3.4.3/gcc/ ^^ This looks a lot like PR12974 See comment #19 There may be a second problem here, though. On older versions of MS Windows (NT4 and win9x), trailing _forward_ slashes cause no problems for stat(). On newer versions, (eg XP) stat() does not recognise a directory that ends in a '\\' or '/', unless it is a drive root dir, such as c:/, where it is obligatory. So on older versions the second -I../../gcc-3.4.3/gcc/ would find the headers, even if this -I -I../../gcc-3.4.3/gcc causes problems. Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20594
[Bug target/20634] code fails to compile/code generation issue with -funit-at-a-time
--- Additional Comments From halcy0n at gentoo dot org 2005-03-26 21:09 --- (In reply to comment #3) For the first problem with code generation issue, does -fno-strict-aliasing helps? No, same problem still. Only adding -fno-unit-at-a-time fixes the issue. I should add that it works fine with gcc 3.4 and -funit-at-a-time. For the second problem with respect with the ICE, well only -O1 -fschedule-insns -funit-at-a-time is needed to reproduce the problem. Yes, I get the ICE with only these options. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20634
[Bug fortran/20651] New: gfortran: ICE in gfc_conv_ss_descriptor, at fortran/trans-array.c:1224
Hi, program gfcbug26 integer, parameter, dimension (1) :: I = (/ 65 /) print *, achar ( I( (/ (/ 1 /) /) ) ) end program gfcbug26 crashes gfortran with: gfcbug26.f90: In function 'MAIN__': gfcbug26.f90:3: internal compiler error: in gfc_conv_ss_descriptor, at fortran/trans-array.c:1224 Cheers, -ha -- Summary: gfortran: ICE in gfc_conv_ss_descriptor, at fortran/trans-array.c:1224 Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: anlauf at hep dot tu-darmstadt dot de CC: gcc-bugs at gcc dot gnu dot org GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20651
[Bug fortran/12366] array assignment fails
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-26 22:02 --- *** Bug 20651 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||anlauf at hep dot tu- ||darmstadt dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12366
[Bug fortran/20651] gfortran: ICE in gfc_conv_ss_descriptor, at fortran/trans-array.c:1224
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-26 22:02 --- *** This bug has been marked as a duplicate of 12366 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20651
[Bug c++/20589] error: 'anonymous enum' is/uses anonymous type'
--- Additional Comments From bangerth at dealii dot org 2005-03-26 22:53 --- Well, I wanted to give an inuitive reasoning. On the other hand, how do you propose to make up a unique name if an unnamed enum is used in two different translation units as a template argument? W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20589
[Bug c++/14912] Do not print default template arguments in error messages
--- Additional Comments From bangerth at dealii dot org 2005-03-26 22:57 --- Giovanni, in your example in comment #27, you get this: Patched: test.cc: In member function 'void AT, N, X::foo() [with T = int]': test.cc:14: instantiated from here test.cc:9: error: 'class std::vectorint' has no member named 'doesnotexist' That's a good improvement, but do you think you could write the first line with AT instead of AT,N,X? I find it confusing to see the second and third template argument, but then no explanation as to their values... Thanks Wolfgang -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912
[Bug c/20652] New: rejects code with an error: aliased to undefined symbol
-- extern int foo; extern int bar __attribute__ ((alias (foo))); -- $ gcc foo.i foo.i:2: error: bar aliased to undefined symbol foo $ this code is taken from glibc/sysdeps/wordsize-64/wcstol_l.c and it was accepted by gcc 3.4 and earlier. -- Summary: rejects code with an error: aliased to undefined symbol Product: gcc Version: 4.0.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: belyshev at depni dot sinp dot msu dot ru CC: gcc-bugs at gcc dot gnu dot org,rth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20652
[Bug c++/14912] Do not print default template arguments in error messages
--- Additional Comments From giovannibajo at libero dot it 2005-03-27 00:56 --- (In reply to comment #31) Patched: test.cc: In member function 'void AT, N, X::foo() [with T = int]': test.cc:14: instantiated from here test.cc:9: error: 'class std::vectorint' has no member named 'doesnotexist' That's a good improvement, but do you think you could write the first line with AT instead of AT,N,X? I find it confusing to see the second and third template argument, but then no explanation as to their values... That's exactly what I was hinting at at the end of comment #7. I then implemented the solution proposed in comment #8 (showing them with default), until Gaby said it would be a showstopper. I will investigate printing AT instead of AT,N,X, but I am not confident it can be done easily (if at all). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912
[Bug c++/14912] Do not print default template arguments in error messages
--- Additional Comments From dave at boost-consulting dot com 2005-03-27 01:52 --- This is obviously becoming personal. I wanted a record of my technical concerns in the bug database, but as the tone has changed I don't think it's appropriate to continue this here. I will reply to Gaby offline and try to clear up the misunderstandings there. -- What|Removed |Added CC|dave at boost-consulting dot| |com | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912
[Bug c++/14912] Do not print default template arguments in error messages
--- Additional Comments From gdr at integrable-solutions dot net 2005-03-27 03:16 --- Subject: Re: Do not print default template arguments in error messages giovannibajo at libero dot it [EMAIL PROTECTED] writes: | (In reply to comment #31) | | Patched: | test.cc: In member function 'void AT, N, X::foo() [with T = int]': | test.cc:14: instantiated from here | test.cc:9: error: 'class std::vectorint' has no member | named 'doesnotexist' | | That's a good improvement, but do you think you could write the first line | with AT instead of AT,N,X? I find it confusing to see the second and | third template argument, but then no explanation as to their values... | | That's exactly what I was hinting at at the end of comment #7. I then | implemented the solution proposed in comment #8 (showing them with default), | until Gaby said it would be a showstopper. *If* you print N and X then yes it is surprising not to say what they bind to (explanation); but default is not good. However, if you do not print them, then you don't have to explain what they mean. | I will investigate printing AT instead of AT,N,X, but I am not confident it | can be done easily (if at all). If you're going to print only the binding of T, and not for N nor X, then you do know that you don't have to print them, i.e. they are instantiated with default values. Granted, as the code in error.c currently is, you would have those information only after the fact (in dump_bindings()). However, the code path in cxx-pretty-print.c is different and more amenable to that kind of thing. Alternatively, you could do lazy printing with error.c but that is more complicated than it should be. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912
Re: [Bug c++/20589] error: 'anonymous enum' is/uses anonymous type'
bangerth at dealii dot org [EMAIL PROTECTED] writes: | Well, I wanted to give an inuitive reasoning. I understood that; I just don't think they are conclusive :-) | On the other hand, how do you propose to make up a unique name if an | unnamed enum is used in two different translation units as a template | argument? They are different types, therefore have different internal names -- like unnamed namespaces. -- Gaby
[Bug c++/20589] error: 'anonymous enum' is/uses anonymous type'
--- Additional Comments From gdr at integrable-solutions dot net 2005-03-27 03:18 --- Subject: Re: error: 'anonymous enum' is/uses anonymous type' bangerth at dealii dot org [EMAIL PROTECTED] writes: | Well, I wanted to give an inuitive reasoning. I understood that; I just don't think they are conclusive :-) | On the other hand, how do you propose to make up a unique name if an | unnamed enum is used in two different translation units as a template | argument? They are different types, therefore have different internal names -- like unnamed namespaces. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20589
[Bug middle-end/20442] [3.3/3.4/4.0 Regression] problem mixing C++ exceptions and setjmp/longjmp with SJLJ exceptions
--- Additional Comments From paulthomas2 at wanadoo dot fr 2005-03-27
06:19 ---
(In reply to comment #0)
Recent correspondence between John Eaton and me.
__
On 25-Mar-2005, Paul Thomas paulthomas2 at wanadoo dot fr wrote:
| Well, we have a response on the more recent bug - it's a bit negative
| insofar as the advice is don't do what you're doing - it might appear to
| work but, in fact, does not. I have replied to say that I am consulting
| with you and might or might not scrub the PR.
OK.
| --- Additional Comments From rth at gcc dot gnu dot org 2005-03-24
| 22:34 ---
| Sorry, but this test case is never going to work -- with either sjlj
| exceptions
| or unwind exceptions. By longjmp-ing from the middle of a catch clause,
| you've
| left the c++ library with live exceptions hanging around in global state.
| With
| unwind exceptions it may appear to work, but is sure to fail in subtle
| ways.
So should it be OK to move the longjmp outside the catch clause?
For example, to simply set a flag inside the catch clause and call
longjmp later? Note that doing that in my example program still
fails. Try the new version below. If you define CRASHME, it will
fail, and the longjmp is called outside the catch clause. If you
don't define CRASHME, the longjmp happens in a completely separate
function and it appears to work (tested on a Cygwin system with the
current GCC).
In Octave, I think I can move the call to longjmp outside the catch
clause without too much trouble, but I don't think I can easily move
it to a completely separate function.
| What I would strongly recommend is using either setjmp or
| exceptions, but not both.
Perhaps I'm misunderstanding precisely what is meant by this. If it
is that one should never use setjmp and exceptions in the same
program, then I don't think this is a realistic solution given that
real programs often mix code from various sources. If I'm writing C++
and prefer to use exceptions, then I can't call any library code that
might happen to use setjmp somewhere along the way?
jwe
#include csetjmp
#include iostream
jmp_buf context;
class
exception
{
// empty;
};
static bool do_longjump_return = false;
static void
callback_fcn (void)
{
try
{
std::cerr toit: throwing exception std::endl;
throw exception ();
}
catch (exception)
{
do_longjump_return = true;
std::cerr toit: caught exception, preparing to longjump
std::endl;
}
#if defined (CRASHME)
if (do_longjump_return)
{
std::cerr foreign code: exception in callback, longjumping
std::endl;
longjmp (context, 1);
}
#endif
}
typedef void (*fptr) (void);
void
foreign_code (fptr f)
{
std::cerr foreign code: executing callback std::endl;
(*f) ();
#if ! defined (CRASHME)
if (do_longjump_return)
{
std::cerr foreign code: exception in callback, longjumping
std::endl;
longjmp (context, 1);
}
#endif
}
static void
doit (void)
{
if (setjmp (context) == 0)
{
std::cerr doit: calling foreign code that uses callback_fcn
std::endl;
foreign_code (callback_fcn);
}
else
{
std::cerr doit: longjump landed, throwing exception std::endl;
throw exception ();
}
}
int
main (void)
{
try
{
std::cerr main: calling doit std::endl;
doit ();
}
catch (exception)
{
std::cerr main: caught exception std::endl;
}
return 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20442
[Bug middle-end/20442] [3.3/3.4/4.0 Regression] problem mixing C++ exceptions and setjmp/longjmp with SJLJ exceptions
--- Additional Comments From paulthomas2 at wanadoo dot fr 2005-03-27
06:23 ---
(In reply to comment #5)
(In reply to comment #0)
John Eaton's last word on the subject:
__
Here is a fix for the Ctrl-C crashes Octave on Cygwin problem.
My apologies to the GCC people for thinking this was a bug with GCC.
jwe
liboctave/ChangeLog:
2005-03-26 John W. Eaton [EMAIL PROTECTED]
* cmd-edit.cc (do_readline): Wrap call to ::octave_rl_readline
with {BEGIN,END}_INTERRUPT_IMMEDIATELY_IN_FOREIGN_CODE.
src/ChangeLog:
2005-03-26 John W. Eaton [EMAIL PROTECTED]
* input.cc (gnu_readline): Don't wrap call to command_editor::readline
with {BEGIN,END}_INTERRUPT_IMMEDIATELY_IN_FOREIGN_CODE.
Index: liboctave/cmd-edit.cc
===
RCS file: /cvs/octave/liboctave/cmd-edit.cc,v
retrieving revision 1.23
diff -u -r1.23 cmd-edit.cc
--- liboctave/cmd-edit.cc 25 Nov 2003 06:05:20 - 1.23
+++ liboctave/cmd-edit.cc 26 Mar 2005 17:53:14 -
@@ -36,6 +36,8 @@
#include unistd.h
#endif
+#include quit.h
+
#include cmd-edit.h
#include cmd-hist.h
#include lo-error.h
@@ -192,7 +194,13 @@
eof = false;
- char *line = ::octave_rl_readline (prompt.c_str ());
+ char *line = 0;
+
+ BEGIN_INTERRUPT_IMMEDIATELY_IN_FOREIGN_CODE;
+
+ line = ::octave_rl_readline (prompt.c_str ());
+
+ END_INTERRUPT_IMMEDIATELY_IN_FOREIGN_CODE;
if (line)
{
Index: src/input.cc
===
RCS file: /cvs/octave/src/input.cc,v
retrieving revision 1.160
diff -u -r1.160 input.cc
--- src/input.cc 4 Mar 2005 02:46:08 - 1.160
+++ src/input.cc 26 Mar 2005 17:53:27 -
@@ -177,12 +177,8 @@
{
bool eof;
- BEGIN_INTERRUPT_IMMEDIATELY_IN_FOREIGN_CODE;
-
retval = command_editor::readline (s, eof);
- END_INTERRUPT_IMMEDIATELY_IN_FOREIGN_CODE;
-
if (! eof retval.empty ())
retval = \n;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20442
