Submitter-Id: net
Originator:Johan Walles
Organization:
Confidential: no
Synopsis: Internal compiler error on (probably) legal code
Severity: critical
Priority: medium
Category: c
Class: ice-on-legal-code
Release: 3.0.2 20011014 (Debian prerelease)
On Tue, 27 Nov 2001, Daniel Jacobowitz wrote:
As with that bug, no, GCC should complain about dollars starting
identifiers. Try using b$c instead of $b.
Oddly enough, our powerpc gcc packages have --no-dollars-in-identifiers
enabled by default, despite gas having no problems handling things
On Tue, Nov 27, 2001 at 06:04:21PM +0100, Guido Guenther wrote:
[..]
Thanks for the testcase. I meant to make one when alpha started having EH
problems awhile back, but never got to itMatthias, I believe this one
will also catch the case that I saw on alpha.
Interesting enough the
On Tue, Nov 27, 2001 at 01:33:25PM -0500, Christopher C. Chimelis wrote:
On Tue, 27 Nov 2001, Daniel Jacobowitz wrote:
As with that bug, no, GCC should complain about dollars starting
identifiers. Try using b$c instead of $b.
Oddly enough, our powerpc gcc packages have
You won't be able to build X86 kernels if you do that :) Well, not
with things like NTFS support, at least.
That isn't really true, is it? Atleast in the NTFS code, I cannot find
such code (and I can't remember writing it, either :-).
I'm most strongly of the opinion that this isn't
I haven't seen any reponse from Ben, so I'm going to go ahead and
move the bug to glibc. It would be rather unfortunate if this
isn't fixed for woody, but at this point that may be impossible.
--
John R. DailyProgeny Linux Systems
Consultant
On Tue, 27 Nov 2001, Martin v. Loewis wrote:
According to the GCC documentation, the rationale for this feature is
that traditional C allows it, but ISO C and ISO C++ disallow it.
So I'd say that, if all Debian packages either build fine without it,
or enable it when needed, turning it off
On Tue, 27 Nov 2001, Martin v. Loewis wrote:
That isn't really true, is it? Atleast in the NTFS code, I cannot find
such code (and I can't remember writing it, either :-).
Hehehe...I seem to remember seeing such code in the kernel source, but
that was some time ago and I haven't looked for it
On Tue, 27 Nov 2001, Daniel Jacobowitz wrote:
I could have sworn it was NTFS...
util.h:
typedef enum {
FILE_$Mft = 0,
FILE_$MftMirr = 1,
etc.
I'm fairly certain that DOLLARS_IN_IDENTIFIERS affects the legality of
that enum.
Yes, it does and you're correct.
On Tue, 27 Nov 2001, John R. Daily wrote:
I haven't seen any reponse from Ben, so I'm going to go ahead and
move the bug to glibc. It would be rather unfortunate if this
isn't fixed for woody, but at this point that may be impossible.
Ok. I'll work it out with him when he gets back from
On Tue, 27 Nov 2001, Martin v. Loewis wrote:
Unlikely. The original gdb backtrace indicated that somebody was
jumping to address 0. I think potential causes are:
1. dynamic initialization of a shared library has not been carried
out. It would be interesting to verify that all shared
The followup to #120333 indicates this is a bug with g++; is anyone
looking into this? i see no discussing on debian-gcc about it, but i'm
reluctant to simply reassign it to gcc.
--
Revolutions do not require corporate support.
On Wed, 28 Nov 2001, Matthew Wilcox wrote:
The followup to #120333 indicates this is a bug with g++; is anyone
looking into this? i see no discussing on debian-gcc about it, but i'm
reluctant to simply reassign it to gcc.
I'm trying to get to it :-) It looks very similar to an EH problem
13 matches
Mail list logo
