static_cast behavior with subclasses when default constructor available
>Submitter-Id: net
>Originator:Nicolas Burrus
>Organization: LRDE
>Confidential: no
>Synopsis: static_cast behavior with subclasses when default constructor
>available
>Severity: serious
>Priority: medium
>Category: c++
>Class: rejects-legal
>Release: 3.3.1 20030626 (Debian prerelease) (Debian testing/unstable)
>Environment:
System: Linux ouagadougou 2.4.20 #1 Tue Jun 10 07:33:08 CEST 2003 i686 GNU/Linux
Architecture: i686
host: i386-pc-linux-gnu
build: i386-pc-linux-gnu
target: i386-pc-linux-gnu
configured with: ../src/configure -v
--enable-languages=c,c++,java,f77,pascal,objc,ada,treelang --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-gxx-include-dir=/usr/include/c++/3.3 --enable-shared --with-system-zlib
--enable-nls --without-included-gettext --enable-__cxa_atexit
--enable-clocale=gnu --enable-debug --enable-java-gc=boehm
--enable-java-awt=xlib --enable-objc-gc i386-linux
>Description:
Considering the following code:
template struct static_abort {};
template
struct any
{
const E& self() const { return static_cast(*this); }
};
struct range : public any
{
range() {}
template
range(const U&)
{
typedef typename static_abort::ret t;
}
};
int main()
{
const any& r = *new range();
r.self();
}
To convert any into range, g++-3.3.1 tries to use the generic
constructor of range instead of using the subclass relationship
between them. Even if I could not find in the C++ standard a priority
rule for this particular case, previous versions of g++ (up to 3.3),
Intel c++ compiler, and Comeau c++ compiler choose the subclassing
conversion when possible.
>How-To-Repeat:
Compile the given code.
>Fix:
Use reinterpret_cast instead of static_cast.
Bug#200003: cpp: contains non-free manpages
Package: cpp Severity: serious The manpages fsf-funding(7), gpl(7), and gfdl(7) are included in the cpp package. These are clearly non-free (non-modifiable). [Plus they aren't mentioned in the copyright file, which claims the package is GPLed] They should almost certainly be removed entirely, and #181495 should instead be fixed by eliminating the references from the cpp manpage (possibly inserting references to /usr/share/common-licenses). -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | Dept. of Computing, `. `' | Imperial College, `- -><- | London, UK pgp7HgXh1NqDW.pgp Description: PGP signature
Bug#200011: g++/g++-3.0 segfaults when mixing __complex__-syntax and std::complex by mistake
Package: g++-3.0
Version: 1:3.0.4-7
Description:
g++/gcc (Version: 1:3.0.4-7, 2:2.95.4-14 and possibly others) crashes
with segmentation-fault when compiling this:
===bang.cc===
#include
int main(int argc, char *argv[])
{
std::complex a(1.0, 1.0);
std::complex b(1.0, 1.0);
// while replacing the GNU-proprietary __complex__,__real__,
// __imag__-syntax with STL's complex-template-class I forgot
// this line which causes the segmentation fault:
__imag__ a = - (__imag__ b);
return 0;
}
===bang.cc===
The error message (using g++-3.0 1:3.0.4-7):
==
$ g++ -c bang.cc
bang.cc: In function `int main(int, char**)':
bang.cc:9: Internal error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://www.gnu.org/software/gcc/bugs.html> for instructions.
==
although mixing types and syntax was my fault, the compiler should not
crash with a segmentation fault.
Thanks!
--
Michael
Weitzel ... all work and no play makes Jack a dull boy ...
[Bug optimization/11366] [3.3 regression] miscompiles XDM-AUTHORIZATION-1 key generation and/or validation in XFree86 at -O2
PLEASE REPLY TO [EMAIL PROTECTED] ONLY, *NOT* [EMAIL PROTECTED] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11366 --- Additional Comments From reichelt at gcc dot gnu dot org 2003-07-04 11:38 --- Might be related to PR 11198. --- You are receiving this mail because: --- You reported the bug, or are watching the reporter.
Bug#200011: g++/g++-3.0 segfaults when mixing __complex__-syntax and std::complex by mistake
On Friday 04 July 2003 13:29, Michael Weitzel wrote: > Description: > g++/gcc (Version: 1:3.0.4-7, 2:2.95.4-14 and possibly others) crashes > with segmentation-fault when compiling this: Still applies to 3:3.3-1 -- vbi -- One good turn usually gets most of the blanket. pgpKptSM0On7o.pgp Description: signature
Bug#200011: g++/g++-3.0 segfaults when mixing __complex__-syntax and std::complex by mistake
Hi,
I can confirm this. It's still there in gcc 3.4 20030629. Test case:
void f (int a)
{
__imag__ a;
}
--
Falk
Bug#200011: g++/g++-3.0 segfaults when mixing __complex__-syntax and std::complex by mistake
Whoops, compiled the wrong file. Test case:
void f (void)
{
struct { } a;
__imag__ a;
}
Only occurs with g++, not gcc.
--
Falk
Bug#196563: libgnome build trouble (was: Re: Processed: Re: Bug#196563: fontconfig: [m68k] segfault during postinst)
> > > The fontconfig segfault happens with any of the 2.1.92-2, 2.2.0-2 or > > > 2.2.0-5 versions of fontconfig/libfontconfig on kullervo. > > > > Ok, that would at first glance appear to void my hypothesis; however, > > fontconfig uses freetype, and that could have been miscompiled. Can you > > Indeed, all freetype/libfreetype combos did work fine with > libfreetype6_2.1.4-1_m68k.deb and libfreetype6_2.1.4-2_m68k.deb from the > apt cache. This problem still persists and prevents libgnome 2.2.2-1 from being built (on a4000t). libgnome in turn causes a lot of gnome 2 package build failures ... I'll try to manually build libgnome now after having fontconfig and libfreetype6_2.1.4-2 preinstalled. Other packages with fontconfig segfaults: kdeedu_4:3.1.2-1 libbonobouimm1.3_1.3.5-3 libgnomeui_2.2.1-1 libgnomeuimm1.3_1.3.16-3 Please make sure you have libfreetype6_2.1.4-2 before retrying them. Michael
Bug#200003: cpp: contains non-free manpages
Andrew Suffield writes: > Package: cpp > Severity: serious > > The manpages fsf-funding(7), gpl(7), and gfdl(7) are included in the > cpp package. These are clearly non-free (non-modifiable). this doesn't make sense. you are not allowed to change a copyright, even for software distributed in main. AFAIK the distribution of license texts is allowed in main, even if the license itself is non-free. I'd like a confirmation from debian-legal, as I don't see something about this in "2.1, Package copyright and sections". > [Plus they aren't mentioned in the copyright file, which claims the > package is GPLed] how should a copyright of a license text included in the debian/copyright file? > They should almost certainly be removed entirely, why? > and #181495 should instead be fixed by eliminating the references > from the cpp manpage (possibly inserting references to > /usr/share/common-licenses). doesn't help, as the GFDL isn't in common-licenses. Matthias
Bug#177840: [Bug optimization/9812] [3.3/3.4 regression] [m68k] ICE in extract_insn, at recog.c:2148
PLEASE REPLY TO [EMAIL PROTECTED] ONLY, *NOT* [EMAIL PROTECTED] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9812 --- Additional Comments From doko at cs dot tu-berlin dot de 2003-07-04 20:30 --- Subject: Re: Bug#177840: [3.3/3.4 regression] [m68k] ICE in extract_insn, at recog.c:2148 wilson at tuliptree dot org writes: > The resulting patch works for this testcase. I suspect we will get > better PIC FP code also, since we aren't needlessly forcing non-XFmode > constants into memory. This gives a medium size patch that will need a > lot of testing, and may not be appropriate for the gcc-3.3.1 release. > > I can't really test this with m68k crosses, and I don't have access to > native m68k hardware. bootstrapped on m68k-linux and i386-linux (together with your patch for PR10021) with no new regressions on the 3.3 branch. --- You are receiving this mail because: --- You reported the bug, or are watching the reporter.
Bug#177840: [Bug optimization/9812] [3.3/3.4 regression] [m68k] ICE in extract_insn, at recog.c:2148
wilson at tuliptree dot org writes: > The resulting patch works for this testcase. I suspect we will get > better PIC FP code also, since we aren't needlessly forcing non-XFmode > constants into memory. This gives a medium size patch that will need a > lot of testing, and may not be appropriate for the gcc-3.3.1 release. > > I can't really test this with m68k crosses, and I don't have access to > native m68k hardware. bootstrapped on m68k-linux and i386-linux (together with your patch for PR10021) with no new regressions on the 3.3 branch.
Bug#200003: cpp: contains non-free manpages
On Fri, Jul 04, 2003 at 10:18:50PM +0200, Matthias Klose wrote: > AFAIK the distribution of > license texts is allowed in main, even if the license itself is > non-free. This would seem to be only common sense. If I take it upon myself to educate the world about the evil and stupidity of the EULA of the Infinidim Corporation, I might release a package containing infinidim-eula(7), unmodified from its original distributed form. (Along with separate treatises like why-infinidim-is-stupid(7) and except-for-the-gray-skin-they-look-just-like-vogons(7).) Even though the Infinidim EULA is a non-free license, that shouldn't preclude us from distributing the /test/ of the license, only software released /under/ that license. (Assuming, of course, that the EULA doesn't prohibit copying of the EULA itself, which would be a remarkably stupid thing to do, and certainly doesn't apply to the actual texts in question.) -- If ye love wealth greater than liberty, the tranquility of servitude greater than the animating contest for freedom, go home and leave us in peace. We seek not your counsel, nor your arms. Crouch down and lick the hand that feeds you; and may posterity forget that ye were our countrymen.- Samuel Adams
Bug#200003: cpp: contains non-free manpages
On Fri, Jul 04, 2003 at 10:18:50PM +0200, Matthias Klose wrote: > Andrew Suffield writes: > > Package: cpp > > Severity: serious > > The manpages fsf-funding(7), gpl(7), and gfdl(7) are included in the > > cpp package. These are clearly non-free (non-modifiable). > this doesn't make sense. you are not allowed to change a copyright, > even for software distributed in main. AFAIK the distribution of > license texts is allowed in main, even if the license itself is > non-free. I'd like a confirmation from debian-legal, as I don't see > something about this in "2.1, Package copyright and sections". fsf-funding(7) is non-modifiable, and is not a license text. Do you agree that it does not meet the requirements for inclusion in main? > > [Plus they aren't mentioned in the copyright file, which claims the > > package is GPLed] > how should a copyright of a license text included in the > debian/copyright file? > > They should almost certainly be removed entirely, > why? > > and #181495 should instead be fixed by eliminating the references > > from the cpp manpage (possibly inserting references to > > /usr/share/common-licenses). > doesn't help, as the GFDL isn't in common-licenses. I think it's strange to see these licenses as manpages, and would argue that it's inconsistent and redundant to include them in this form. Debian has an established policy that guarantees where a user can find the license for a given package; these manpages are therefore extraneous and should probably be removed. But I think it's the fsf-funding manpage that justifies the severity of this bug. -- Steve Langasek postmodern programmer pgpdQi1gvxWkl.pgp Description: PGP signature
Bug#199361: marked as done (cpp-3.3: cpp0 not installed in /usr/lib/gcc-lib/*/3.3)
Your message dated Fri, 4 Jul 2003 22:33:01 +0200 with message-id <[EMAIL PROTECTED]> and subject line Bug#199361: cpp-3.3: cpp0 not installed in /usr/lib/gcc-lib/*/3.3 has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) -- Received: (at submit) by bugs.debian.org; 30 Jun 2003 10:32:29 + >From [EMAIL PROTECTED] Mon Jun 30 05:32:28 2003 Return-path: <[EMAIL PROTECTED]> Received: from rwcrmhc53.comcast.net (rwcrmhc13.comcast.net) [204.127.198.39] by master.debian.org with esmtp (Exim 3.35 1 (Debian)) id 19WvxT-0006e2-00; Mon, 30 Jun 2003 05:32:28 -0500 Received: from blueberry (h0050fc0490ee.ne.client2.attbi.com[24.60.246.230](untrusted sender)) by attbi.com (rwcrmhc13) with ESMTP id <20030630103226015004t6coe>; Mon, 30 Jun 2003 10:32:26 + Received: from as by blueberry with local (Exim 3.35 #1 (Debian)) id 19WvxR-0001GS-00; Mon, 30 Jun 2003 06:32:25 -0400 From: Ariel Shkedi <[EMAIL PROTECTED]> To: Debian Bug Tracking System <[EMAIL PROTECTED]> Subject: cpp-3.3: cpp0 not installed in /usr/lib/gcc-lib/*/3.3 X-Mailer: reportbug 1.50 Date: Mon, 30 Jun 2003 06:32:25 -0400 Message-Id: <[EMAIL PROTECTED]> Sender: Ariel Shkedi <[EMAIL PROTECTED]> Delivered-To: [EMAIL PROTECTED] X-Spam-Status: No, hits=-6.0 required=4.0 tests=BAYES_01,HAS_PACKAGE version=2.53-bugs.debian.org_2003_06_27 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53-bugs.debian.org_2003_06_27 (1.174.2.15-2003-03-30-exp) Package: cpp-3.3 Version: 1:3.3-2 Severity: normal File: /usr/bin/cpp-3.3 cpp0 is not installed in /usr/lib/gcc-lib/*/3.3 this causes problems when you try to compile using the -V flag. i.e. if gcc is symlinked to the 3.0 version, gcc -v 3.3 should run version 3.3, but without cpp0 in the proper place it failes. All the other versions of gcc do have cpp0 there. There might be other files missing, I don't know. Please try using the -V option (when gcc is symlinked to a different version) before releasing. -- System Information Debian Release: 3.0 Architecture: i386 Kernel: Linux blueberry 2.4.19 #11 Tue Jun 10 22:44:28 EDT 2003 i686 Locale: LANG=C, LC_CTYPE=C Versions of packages cpp-3.3 depends on: ii gcc-3.3-base 1:3.3-2The GNU Compiler Collection (base ii libc6 2.3.1-16 GNU C Library: Shared libraries an --- Received: (at 199361-done) by bugs.debian.org; 4 Jul 2003 20:34:31 + >From [EMAIL PROTECTED] Fri Jul 04 15:34:29 2003 Return-path: <[EMAIL PROTECTED]> Received: from mail.cs.tu-berlin.de [130.149.17.13] by master.debian.org with esmtp (Exim 3.35 1 (Debian)) id 19YXGG-0007Km-00; Fri, 04 Jul 2003 15:34:28 -0500 Received: from bolero.cs.tu-berlin.de ([EMAIL PROTECTED] [130.149.19.1]) by mail.cs.tu-berlin.de (8.9.3/8.9.3) with ESMTP id WAA09483; Fri, 4 Jul 2003 22:33:02 +0200 (MET DST) Received: (from [EMAIL PROTECTED]) by bolero.cs.tu-berlin.de (8.11.6+Sun/8.9.3) id h64KX1l19432; Fri, 4 Jul 2003 22:33:01 +0200 (MEST) From: Matthias Klose <[EMAIL PROTECTED]> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <[EMAIL PROTECTED]> Date: Fri, 4 Jul 2003 22:33:01 +0200 To: Daniel Jacobowitz <[EMAIL PROTECTED]>, [EMAIL PROTECTED] Subject: Re: Bug#199361: cpp-3.3: cpp0 not installed in /usr/lib/gcc-lib/*/3.3 In-Reply-To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> X-Mailer: VM 7.03 under 21.4 (patch 6) "Common Lisp" XEmacs Lucid Delivered-To: [EMAIL PROTECTED] X-Spam-Status: No, hits=-11.3 required=4.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_VM autolearn=ham version=2.53-bugs.debian.org_2003_06_27 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53-bugs.debian.org_2003_06_27 (1.174.2.15-2003-03-30-exp) Daniel Jacobowitz writes: > There is no cpp0 any more; it was eliminated entirely. therefore closing the report.
Processed: gcc: submitted Debian report #200011 to gcc-gnats as PR 11437
Processing commands for [EMAIL PROTECTED]: > # submitted Debian report #200011 to gcc-gnats as PR 11437 > # http://gcc.gnu.org/PR11437 > forwarded 200011 http://gcc.gnu.org/PR11437 Bug#200011: g++/g++-3.0 segfaults when mixing __complex__-syntax and std::complex by mistake Noted your statement that Bug has been forwarded to http://gcc.gnu.org/PR11437. > retitle 200011 [PR 11437] [3.3/3.4] g++ segfaults Bug#200011: g++/g++-3.0 segfaults when mixing __complex__-syntax and std::complex by mistake Changed Bug title. > tags 200011 + upstream Bug#200011: [PR 11437] [3.3/3.4] g++ segfaults There were no tags set. Tags added: upstream > thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database)
[Bug c++/11437] ICE in lookup_name_real
PLEASE REPLY TO [EMAIL PROTECTED] ONLY, *NOT* [EMAIL PROTECTED] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11437 bangerth at dealii dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2003-07-04 21:53:44 date|| Summary|[3.3/3.4] g++ segfaults |ICE in lookup_name_real Target Milestone|3.4 |--- --- Additional Comments From bangerth at dealii dot org 2003-07-04 21:53 --- Confirmed. This crashes every gcc version I have since at least 2.95. Here's a backtrace: #0 lookup_name_real (name=0x0, prefer_type=0, nonclass=1, namespaces_only=0, flags=2) at ../../gcc-3.4-CVS/gcc/cp/decl.c:5879 #1 0x0806cfe1 in lookup_name_nonclass (name=0x0) at ../../gcc-3.4-CVS/gcc/cp/decl.c:5957 #2 0x0806d002 in lookup_function_nonclass (name=0x0, args=0xe) at ../../gcc-3.4-CVS/gcc/cp/decl.c:5963 #3 0x080531ca in build_new_op (code=132, flags=3, arg1=0x401ad804, arg2=0x0, arg3=0x0) at ../../gcc-3.4-CVS/gcc/cp/call.c:3712 #4 0x08118d90 in build_x_unary_op (code=132, xarg=0x401ad804) at ../../gcc-3.4-CVS/gcc/cp/typeck.c:3896 #5 0x080fcdde in cp_parser_unary_expression (parser=0x0, address_p=false) at ../../gcc-3.4-CVS/gcc/cp/parser.c:4483 #6 0x080fd61c in cp_parser_pm_expression (parser=0x401ab4c0) at ../../gcc-3.4-CVS/gcc/cp/parser.c:4944 #7 0x081068d2 in cp_parser_binary_expression (parser=0x401ab4c0, token_tree_map=0x84923a0, fn=0x80fd600 ) at ../../gcc-3.4-CVS/gcc/cp/parser.c:13553 #8 0x080fd6c1 in cp_parser_multiplicative_expression (parser=0x0) at ../../gcc-3.4-CVS/gcc/cp/parser.c:4998 #9 0x081068d2 in cp_parser_binary_expression (parser=0x401ab4c0, token_tree_map=0x84923c0, fn=0x80fd6a0 ) at ../../gcc-3.4-CVS/gcc/cp/parser.c:13553 #10 0x080fd6f1 in cp_parser_additive_expression (parser=0x0) at ../../gcc-3.4-CVS/gcc/cp/parser.c:5021 #11 0x081068d2 in cp_parser_binary_expression (parser=0x401ab4c0, token_tree_map=0x84923d8, fn=0x80fd6d0 ) at ../../gcc-3.4-CVS/gcc/cp/parser.c:13553 #12 0x080fd721 in cp_parser_shift_expression (parser=0x0) at ../../gcc-3.4-CVS/gcc/cp/parser.c:5044 #13 0x081068d2 in cp_parser_binary_expression (parser=0x401ab4c0, token_tree_map=0x8492400, fn=0x80fd700 ) at ../../gcc-3.4-CVS/gcc/cp/parser.c:13553 #14 0x080fd751 in cp_parser_relational_expression (parser=0x0) at ../../gcc-3.4-CVS/gcc/cp/parser.c:5079 #15 0x081068d2 in cp_parser_binary_expression (parser=0x401ab4c0, token_tree_map=0x8492438, fn=0x80fd730 ) at ../../gcc-3.4-CVS/gcc/cp/parser.c:13553 #16 0x080fd781 in cp_parser_equality_expression (parser=0x0) at ../../gcc-3.4-CVS/gcc/cp/parser.c:5102 #17 0x081068d2 in cp_parser_binary_expression (parser=0x401ab4c0, token_tree_map=0x8492450, fn=0x80fd760 ) at ../../gcc-3.4-CVS/gcc/cp/parser.c:13553 #18 0x080fd7b1 in cp_parser_and_expression (parser=0x0) at ../../gcc-3.4-CVS/gcc/cp/parser.c:5123 #19 0x081068d2 in cp_parser_binary_expression (parser=0x401ab4c0, token_tree_map=0x8492460, fn=0x80fd790 ) at ../../gcc-3.4-CVS/gcc/cp/parser.c:13553 #20 0x080fd7e1 in cp_parser_exclusive_or_expression (parser=0x0) at ../../gcc-3.4-CVS/gcc/cp/parser.c:5144 #21 0x081068d2 in cp_parser_binary_expression (parser=0x401ab4c0, token_tree_map=0x8492470, fn=0x80fd7c0 ) at ../../gcc-3.4-CVS/gcc/cp/parser.c:13553 #22 0x080fd811 in cp_parser_inclusive_or_expression (parser=0x0) at ../../gcc-3.4-CVS/gcc/cp/parser.c:5166 #23 0x081068d2 in cp_parser_binary_expression (parser=0x401ab4c0, token_tree_map=0x8492480, fn=0x80fd7f0 ) at ../../gcc-3.4-CVS/gcc/cp/parser.c:13553 #24 0x080fd841 in cp_parser_logical_and_expression (parser=0x0) at ../../gcc-3.4-CVS/gcc/cp/parser.c:5187 #25 0x081068d2 in cp_parser_binary_expression (parser=0x401ab4c0, token_tree_map=0x8492490, fn=0x80fd820 ) at ../../gcc-3.4-CVS/gcc/cp/parser.c:13553 #26 0x080fd871 in cp_parser_logical_or_expression (parser=0x0) at ../../gcc-3.4-CVS/gcc/cp/parser.c:5208 #27 0x080fd999 in cp_parser_assignment_expression (parser=0x401ab4c0) at ../../gcc-3.4-CVS/gcc/cp/parser.c:5307 #28 0x080fdaf8 in cp_parser_expression (parser=0x401ab4c0) at ../../gcc-3.4-CVS/gcc/cp/parser.c:5456 #29 0x080fdedd in cp_parser_expression_statement (parser=0x401ab4c0) at ../../gcc-3.4-CVS/gcc/cp/parser.c:5747 #30 0x080fdc6a in cp_parser_statement (parser=0x401ab4c0) at ../../gcc-3.4-CVS/gcc/cp/parser.c:5660 #31 0x080fdfd7 in cp_parser_statement_seq_opt (parser=0x401ab4c0) at ../../gcc-3.4-CVS/gcc/cp/parser.c:5805 #32 0x080fdf76 in cp_parser_compound_statement (parser=0x401ab4c0) at ../../gcc-3.4-CVS/gcc/cp/parser.c:5778 #33 0x081033eb in cp_parser_ctor_ini
[Bug c++/11437] ICE in lookup_name_real
PLEASE REPLY TO [EMAIL PROTECTED] ONLY, *NOT* [EMAIL PROTECTED] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11437 --- Additional Comments From bangerth at dealii dot org 2003-07-04 21:54 --- I forgot to say: I don't know whether the code is legal, but it shouldn't ICE anyway, in particular not without any other message. W. --- You are receiving this mail because: --- You reported the bug, or are watching the reporter.
[Bug optimization/11350] [3.3/3.4 regression] undefined labels with -Os -fPIC
PLEASE REPLY TO [EMAIL PROTECTED] ONLY, *NOT* [EMAIL PROTECTED] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11350 pinskia at physics dot uc dot edu changed: What|Removed |Added Attachment #4295 is|0 |1 obsolete|| --- You are receiving this mail because: --- You reported the bug, or are watching the reporter.
