Jan Finjord <[EMAIL PROTECTED]> writes:
> Was this email received by you?
Dear Jan,
This message was received, and is now archived at
http://lists.debian.org/debian-gcc/2002/debian-gcc-200211/msg00208.html
Most likely, nothing will happen in response to this message: There
are no Fortran expe
"Ken-y KING" <[EMAIL PROTECTED]> writes:
> checking for gcc... gcc
> checking for C compiler default output... configure: error: C compiler cannot
> create executables
Please study the file config.log.
Regards,
Martin
These additional overloads where added to libstdc++ in anticipation of
a resolution to defect report 118, see
http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#118
However, this defect report is resolved in a different way now (by
removing extractor functions, instead of adding get meth
This is not a bug in the compiler, but in your code. Looking at the
declaration
foo_t a::b::frobnicate() {
I notice that the scope of a::b is only reentered at the opening ( of
the method declaration, thus "foo_t" is *not* found to be the
typedef. Instead, it is treated as a plain identifier (o
Florian Weimer <[EMAIL PROTECTED]> writes:
> But using GraphViz, even in this way, is not consistent with FSF
> policies--so it would be rather easy to force you to change it,
> theoretically speaking.
Can you explain which FSF policy this is inconsistent with? This
sounds like saying that you ca
Philip Blundell <[EMAIL PROTECTED]> writes:
> Autoconf 2.50 doesn't seem to work for building gcc 3.1 (it triggers the
> "recursion limit reached" problem). For gcc-3.0, changing the build
> dependency from autoconf to autoconf2.13 fixed this, and I guess the
> same would work for gcc-3.1.
I tho
Daniel Jacobowitz <[EMAIL PROTECTED]> writes:
> This should presumably be reported to GCC rather than to us...
> Libstdc++ folks, please maintain the CC's. Any thoughts?
GCC is clearly behaving correctly. typedefs are resolved before
mangling, since symbols that differ only in typedef usage mus
Greg Stark <[EMAIL PROTECTED]> writes:
> Well, that's not what my documentation from GCC 2.95 says:
>
> On some machines it may be impossible to determine the return
> address of any function other than the current one; in such cases,
> or when the top of the stack has been reached
Gregory Seidman <[EMAIL PROTECTED]> writes:
> Did you take a look at the ldd -v output? It shows none of the
> shared objects depending on that strange libstdc++. Also, AFAIK, I
> am only using three C++ libraries: Qt, Xerces, and glut; I have
> compiled each of them with apt-get source --compile
Daniel Jacobowitz <[EMAIL PROTECTED]> writes:
> But the value of J is not required to coordinate with any sequence
> points in the implementation, only in the abstract machine...
In the code, there are two modifications to i, namely
i++;
j = 6;
i--;
So at the first seque
Zack Weinberg <[EMAIL PROTECTED]> writes:
> so indeed it looks like neither 'unix' nor '__unix__' is defined.
> (I imagine a patch to define __unix__ would be acceptable, but we
> are not adding any more predefined symbols that violate the user's
> namespace.)
I'd assume that this would be adde
Joel Baker <[EMAIL PROTECTED]> writes:
> Not sure at all why it would define 'unix' on m68k and not i386...
Unfortunately, the gcc public CVS does not answer this question: it
goes back only to 11-Aug-97, at which time m68k/netbsd.h was created
(in the then-egcs CVS); in that version, it reads
Joel Baker <[EMAIL PROTECTED]> writes:
> Next stupid question: which standard covers 'unix', so that I can make sure
> all the pieces are met and that I'm not about to force GCC to tell a lie
> that will come back to haunt me later...
I'm not sure why NetBSD doesn't define __unix__; it is a good
"Joel Baker" <[EMAIL PROTECTED]> writes:
> Both are ELF systems, and both define the OS standard symbol for their
> respective OSen. However, what I can't figure out is why the NetBSD config
> doesn't have -Dunix - it certainly seems to support the various files that
> I've seen that used as a tri
Erich Schubert <[EMAIL PROTECTED]> writes:
> This thread could be interesting for those working on the new GCC 3.2.
> I don't think it might help much, but maybe it lets someone find a great
> solution.
I don't think there is a great solution. It has been decided by
distributors and GCC maintaine
Michael Meskes <[EMAIL PROTECTED]> writes:
> Could anyone of you please try to compile tora with gcc 3+ and look into
> the error messages?
It might be easier if you just report the errors that you get, perhaps
along with code fragments that the error messages refer to.
Regards,
Martin
Joel Baker <[EMAIL PROTECTED]> writes:
> That's from the build area... binutils is currently:
>
> binutils 2.13.90.0.4-1 The GNU assembler, ...
> binutils-dev 2.13.90.0.4-1 The GNU binary utilities ...
> binutils-doc 2.13.90.0.4-1 Documentation for the GNU assembler, ...
> binutils-m
Joel Baker <[EMAIL PROTECTED]> writes:
> I believe they're from the dynamic linker (ld.elf_so), in this case.
That would indicate that the dynamic linker does not know what .hidden
symbols are, which is a problem on its own.
> > We have to consider __dso_handle and __cxa_atexit separately. For
>
Joel Baker <[EMAIL PROTECTED]> writes:
> > /tmp/Build/gcc-3.2/gcc-3.2-3.2ds0/build/i386-unknown-netbsdelf1.6./libstdc++-v3/src/.libs/libstdc++.so:
> > undefined reference to `__dso_handle'
> > /tmp/Build/gcc-3.2/gcc-3.2-3.2ds0/build/i386-unknown-netbsdelf1.6./libstdc++-v3/src/.libs/libstdc++.so:
Joel Baker <[EMAIL PROTECTED]> writes:
> # of expected passes5176
> # of unexpected failures1114
> # of expected failures 977
> # of untested testcases 15
> # of unsupported tests 3
Those you should look at, first. gcc creates a detailed log file of
a
"Joel Baker" <[EMAIL PROTECTED]> writes:
> Can anyone tell me where I should be looking in the logs, the test suite
> results, or the like, to find out what's causing this? Build
> environment, output logs, .deb files, or just about anything else
> available on request, but I don't want to spam th
[EMAIL PROTECTED] writes:
> If I do
>
>#include
>
> 'assert' is not being put into the namespace std, although the comment
> in cassert implies it will be, and it should be, as far as I know.
>
> (I think this is happening with errno, too.)
You are mistaken. assert is a macro, and must be
Steve Langasek <[EMAIL PROTECTED]> writes:
> > Jeff Bailey planned to put these libraries in /usr/lib/gcc-2.95 (like
> > in the libc5/6 transition) and rename the packages containing the 2.95
> > libraries.
>
> How would this work? Would those using gcc-2.95 software have to set an
> rpath or $L
Matthew Wilcox <[EMAIL PROTECTED]> writes:
> All of them? I sw someone do a count and there were around 1000 packages
> currently in the archive. 10%. Per architecture. Is Jeff really going
> to bNMU all of these packages on the same day for all architectures?
I think this is the plan. You'll
Steve Langasek <[EMAIL PROTECTED]> writes:
> I sincerely hope that g++ 3.2 applications will be allowed to coexist on
> the system with g++ 2.95.x applications.
I don't think this will happen, atleast not for shared libraries. Any
scheme that tries to solve this problem will be horribly complex
Matthew Wilcox <[EMAIL PROTECTED]> writes:
> This is a proposal. You will be notified when this is a real plan
I think Jeff Bailey's plan is entirely different, and I like his plan
more. Here are the differences.
> * If you maintain a library written in C++, add a `c' to the end of
>
Jack Howarth <[EMAIL PROTECTED]> writes:
> It is unclear how many arches have been checked at this point other
> than ia64 and ppc; I am assuming i386 must be okay.
It's an issue on i386 as well.
Regards,
Martin
James Antill <[EMAIL PROTECTED]> writes:
> Package: gcc
> Version: 2:2.95.4-14
> Severity: normal
[...]
> I've included a C file that should work not matter what value the
> TST_SINGLE_ARG is set to.
This is fixed in gcc 3.
Regards,
Martin
Jan-Hendrik Palic <[EMAIL PROTECTED]> writes:
> Hmm ok .. but, I thought we have a binary incompatibility, when the
> glibc is compiled with gcc-3.x? If we upload glibc build with gcc-3.x,
> this will break the whole debian-unstable, no?
The incompatibility is minor, and must be fixed before anyb
Jan-Hendrik Palic <[EMAIL PROTECTED]> writes:
> since this is my first time to get a distribution to a newer standard
> compiler and I have no experiance with it, I want to ask, what is the
> way to switch over to gcc-3.2?
>
> A completely relaunch of debian or a slowly step step by step upload o
Neil Booth <[EMAIL PROTECTED]> writes:
> If it's a system header, why are you lying to the compiler?
I'm not lying, I use
> Maybe a real-life example and not "a.h" would help.
Ok, here is the real-life example. Consider
#include
int main(){}
which is compiled with
g++-3.1 -MM -I/opt/JBuil
Neil Booth <[EMAIL PROTECTED]> writes:
> > >Description:
> > In gcc 3.1, -MM prints dependencies even to files included with
> > angle brackets (), if those are found through -I options.
> > This behaviour is unintuitive and a change from earlier versions.
>
> Why are you using <> bra
Chris Halls <[EMAIL PROTECTED]> writes:
> > If so, the virtual table for that class should not be emitted in
> > test.o, and it appears that g++ 3.1 behaves correctly in this respect.
>
> I take it that the 'typeinfo' should also not be emitted, as well as the
> virtual table?
Correct.
> g++ 3.
Chris Halls <[EMAIL PROTECTED]> writes:
> I have posted the test script and preprocessed source here:
> http://apt-proxy.sourceforge.net/ooo/g++test
> http://apt-proxy.sourceforge.net/ooo/test.cxx.bz2
Maybe I'm missing something, but... Is it the case that
ucb::ContentProviderImplHelper::~Con
Dawid Jarosz <[EMAIL PROTECTED]> writes:
> I'm wodering why this code doesn't work. It looks like when the program
> is about to throw exception i cashes with SIGABR signal.
I can't reproduce this. What architecture, what gcc package, what
compiler flags?
Regards,
Martin
"Alexei Khlebnikov" <[EMAIL PROTECTED]> writes:
> I think, libs compiled with gcc 2.95 just should reside in separate
> directory, say, /usr/lib/gcc-2.95-compat. Gcc 3.2.x should be run as
> gcc or gcc-3.2. Gcc 2.95.x should be run as gcc-2.95.
That will work; the question then is how to automat
Marek Habersack <[EMAIL PROTECTED]> writes:
> OK, I found the statement about the preceeding non-witespace tokens but,
> still, I would think that something that breaks the kernel compile should be
> important no matter how trivial to work-around it is...
The question is whether it should be fixe
[EMAIL PROTECTED] writes:
> printf(KERN_ERR "[" DRM_NAME ":%s] *ERROR* " fmt , __FUNCTION__, ##
> args)
[...]
> which is invalid C syntax. ##' gets rid of the comma, so we get the
> following instead:
>
> fprintf (stderr, "success!\n")
>
>
> Which is not the case. That bug breaks
Jack Howarth <[EMAIL PROTECTED]> writes:
>I think the primary problem debian will have with gcc 3.2 (or
> 3.1.1 for that matter) is dealing with rebuilding glibc under it.
> Because the gcc 3.1 fixed a bug relating to incorrectly linking in
> libgcc symbols into binaries, glibc trunk and glibc
When g++ 3.2 becomes the next Debian compiler, it will be necessary to
recompile a lot of packages. Also, it will be necessary to have the
old binary packages, and their shared libraries, coexist.
Is there a specific plan to implement this coexistence? I can think of
the following strategies:
- d
"" <[EMAIL PROTECTED]> writes:
> However, as I understand it, the bug indicated a problem with the
> compiler (an internal error), so other programs compiled with the
> compiler would fail.
That's incorrect. If the compiler encounters an internal error, it
refuses to compile. So programs that s
"Nikita V. Youshchenko" <[EMAIL PROTECTED]> writes:
> "asm" statement here clobbers %ebx register. And it tells the compiler
> after the third semicolon that %ebx is clobbered, so compiler should not
> depend on any value stored there.
Notice that this really is a bug in your program. In PIC co
> Version 2.95 got it right: This is no valid C++ (What happens if someone
> adds a constructor to the struct?).
While this is indeed not well-formed C++ 98, this is a defect in C++
itself (as it breaks C compatibility). Defect Report 80 (which will be
included in the upcoming technical corrigendu
Matt Reynolds <[EMAIL PROTECTED]> writes:
> As a Java developer and Debian addict, I've been curious how "we're"
> going about dealing with Sun's decision to move to gcc 3.1 in their next
> incremental release of their JDK.
> http://developer.java.sun.com/developer/bugParade/bugs/4694590.htm
I'm forwarding this to the French translator, Michel Robitaille.
Michel, can you please correct these errors and submit a new catalog?
> This would be a bug in fr.po:
>
> | #: cp/call.c:2834
> | msgid "%s for `%T %s' operator"
> | msgstr "%s pour l'opÃrateur Â%T %sÂ"
> |
> | #: cp/call.c:2837
> |
Christof Petig <[EMAIL PROTECTED]> writes:
> Perhaps the namepace of the first argument determines the namespace
> searched for the operator ?
All arguments determine the namespaces search for functions. This is
called Koenig lookup (after Andrew Koenig, inventor of this
mechanism), or argument-d
"Kapil Khosla" <[EMAIL PROTECTED]> writes:
> I guess by reading the man page I have understood that g++ is just
> a script which calls gcc compiler with options to recognize C++.
That is not true (anymore); it is now a proper binary.
Regards,
Martin
--
To UNSUBSCRIBE, email to [EMAIL PROTEC
"Kapil Khosla" <[EMAIL PROTECTED]> writes:
> I thought g++ was the C++ compiler , why do I have to upgrade gcc to
> make it work. What really is g++ ?
It is the C++ compiler driver (just like gcc is the C compiler
driver). The C++ compiler proper is cc1plus (like cc1 for C).
Regards,
Martin
--
Chris Cheney <[EMAIL PROTECTED]> writes:
> Does anyone know if/when Debian is planning on switching the default
> compiler to gcc 3.1.x. I am waiting to upload KDE 3 to see if gcc 3.1
> will become the default compiler anytime soon.
Perhaps never. For the upcoming Debian release, the compiler wi
Torsten Knodt <[EMAIL PROTECTED]> writes:
> thats not what I wanted to do. I think IBM and the other big users
> of this patch, will do this themselves. But I think in the meantime
> it would be a win to debian. Yes, it's mostly not a good idea to
> have features patches in the debian diff, but th
Torsten Knodt <[EMAIL PROTECTED]> writes:
> Link to the announcement on gcc-patches:
> http://gcc.gnu.org/ml/gcc-patches/2001-06/msg01753.html
I don't think that a Debian bug report is the right place to "push" a
patch into gcc (i.e. to lobby for it).
Instead, you should assume that all patches
Jack Howarth <[EMAIL PROTECTED]> writes:
>Have you tried running the orginal test case from
>
> http://gcc.gnu.org/ml/gcc-patches/1999-12n/msg00664.html
>
> with gcc 3.1 built without the g++-cxa-atexit.dpatch.
Yes, and it works fine for me with and without the patch.
> Both HJ Lu and Jaku
Jack Howarth <[EMAIL PROTECTED]> writes:
> As I said in my previous message, we are NOT losing __cxa_atexit.
> By dropping the current patch we are using the __cxa_atexit
> provided by glibc >= 2.2 instead of the one provided by gcc itself.
I understand that. The patch is still needed.
> The
"H . J . Lu" <[EMAIL PROTECTED]> writes:
> > The patch, in itself, is correct. Applications that want to conform to
> > the C++ ABI *must* use __cxa_atexit. It is not the default in g++
> > since not all C libraries support __cxa_atexit. However, GNU libc does
> > support this function, so Debian
Jack Howarth <[EMAIL PROTECTED]> writes:
>Here is another message from Jakub on the complete unnecessity
> of debian using the patch...
This is not relevant.
> It is not about being or not being accurate for gcc 3.1, it is about glibc
> 2001-02-26 or later having:
>
> /* This is defined by
Jack Howarth <[EMAIL PROTECTED]> writes:
> HJ Lu has requested that we regress out the g++-cxa-atexit.dpatch
> patch.
The patch, in itself, is correct. Applications that want to conform to
the C++ ABI *must* use __cxa_atexit. It is not the default in g++
since not all C libraries support __cxa
Jack Howarth <[EMAIL PROTECTED]> writes:
> In that case it also passes the test case properly. It seems to me
> that if the only reason we included the g++-cxa-atexit.dpatch
> was to satisfy the known problem...
>
> Global destructors are not run in the correct order.
>
>
> Global destructors sh
Matthias Klose <[EMAIL PROTECTED]> writes:
> As Chris and Martin have pointed out, the behaviour should not be
> changed. To get the warning, use `-std=c89' or `-std=c99'. But I'm
> unsure, why compiling with -fno-dollars-in-identifiers doesn't print a
> warning. Is this correct?
No, that's a bug
Matthias Klose <[EMAIL PROTECTED]> writes:
> I would like to get feedback, on which alternative to base the gcc-3.1
> packages:
>
> a) 3.1 as to be released (without dwarf2 support)
As Redhat has demonstrated in the past, it is highly desirable that
the distributed gcc is based on a released gcc
[Nicolai, if you disagree with the analysis below, please let us know]
Sean Perry <[EMAIL PROTECTED]> writes:
> the code below is from Josuttis' "The C++ standard library" and I
> have seen it elsewhere. It works under 2.95.4.
AFAICT, the code is incorrect.
> int main(int argc, char* argv[]) {
"Felix Kühling" <[EMAIL PROTECTED]> writes:
> I got strange parse errors
This is a known problem, see
http://gcc.gnu.org/bugs.html#parsing
Regards,
Martin
"Eric T. Korb" <[EMAIL PROTECTED]> writes:
> Does anyone know how to build GCC3.0 for Debian 2.2_rev3 such that
> wchar_t is fully functional? I'm getting compilation errors on:
> /home/ekorb/OpenVXI_2.0/src/VXI/DocumentModel.cpp:38: undefined
> reference to `std::_Format_cache::_Format_cac
Daniel Sjölie <[EMAIL PROTECTED]> writes:
> Not sure, not my code, but would gdb say this if it wasn't true?
> > > (gdb) print _ptr
> > > $5 = (Object *) 0x808f170
It certainly would. gdb just reports what the compiler (and thus the
code) claims to be the static type of the pointer.
Regards,
Mar
Daniel SjÂÃlie <[EMAIL PROTECTED]> writes:
> 0x400a9c59 in osgDB::ReaderWriter::ReadResult::getNode() (this=0xb2a0)
> at /home/source/osg/cvs/include/osgDB/ReaderWriter:64
> 64 osg::Node* getNode() { return
> dynamic_cast(_object.get()); }
> (gdb) s
>
> Program recei
Peter Koellner <[EMAIL PROTECTED]> writes:
> sure. maybe i did not made quite clear, that i did not expect help with
> the compilation error at all, but was asking for the current method to set
> up a debian system for kernel development tasks, so that i don't get
> a response of "use the right co
Pavel Machek <[EMAIL PROTECTED]> writes:
> In its previous incarnation, bug was hidden by going to new gcc
> version... But it looks like it only raised a bar a bit.
This is really a bug in your code; you are exceeding a compiler limit,
thus the code behaves undefined. There is a bug in the compi
> So, concluding, the following isn't correct?
>
> ,
> | #
> | #If SWISH++ doesn't work correctly with optimization on, but it
> | #works just fine with it off, then there is a bug in your
> | #compiler's optimizer.
> `
No. Something like
# If SWISH++ doesn't work
> /usr/include/g++-v3/backward/iostream.h:35: using directive `ostream'
> introduced ambiguous type `ostream''
> I know it's probably due to libraries versions mismatch, but I got libstdc++
> exactly the same version as gcc.
I'm now pretty sure tha it is *not* due to library version mismatch,
but
> What are the known issues with those compilers?
The list is long, see
http://gcc.gnu.org/cgi-bin/gnatsweb.pl
> Is the trial and error method the usual approach ? ;-)
No. Instead, one needs to clearly identify the problem. If it is a
compiler bug, it would fall into the class "generates bad co
> Ok, I got my compiler up and running and compiling some of my old works in C,
> but now when I use even 'iostream' compiler finds eggog like that:
> 'In file included from /usr/include/g++-v3/backward/stream.h:32,
> from String.cc:14:
> /usr/include/g++-v3/backward/iostream.h:35: using directive
> Since we will have to prepare Woody's release soon, I think
> the best way is to disable translation just now tempolarily
> and then start the investigation of this problem.
I recommend the same thing. Gettext support in gcc 2.95 is known not
to work; the GCC maintainers even claim that it is kn
> Without -pedantic there is not even a warning (even with -W -Wall).
> 10.2.1 says "for a qualified-id, name lookup begins in the scope of
> 10.2.the nested-name-specifier". In which scope, I don't think the
> 10.2.reference to pop() or HWQueue, for that matter, is ambiguous.
This is caused by
> But an unexpected failure suggests a new error. That should fail and
> stop the build.
That impression is incorrect. An unexpected failure may or may not be
a new error. If you are concerned about unexpected failures, you'd
have to investigate them. Stopping the build is not appropriate, since
e
> > > possibly include a glibc header, otherwise certain C++ programs will
> > > simply fail out of the box.
> >
> > I don't believe that this is true.
> [...]
> > > http://gcc.gnu.org/ml/libstdc++/2000-12/msg00215.html
>
> Well, there's my example. :-)
Just to make sure we are talking abou
> If you have questions (or better yet, patches *grin*), by all means include
> the list. However, if you do, I'd recommend /not/ cc'ing @bugs.debian.org,
> because those auto-acks are awfully annoying.
{Removing [EMAIL PROTECTED], adding [EMAIL PROTECTED]
See http://bugs.debian.org/126703 for p
> > I can't see a reason for libstdc++ requiring _GNU_SOURCE except for the
> > desire to re-export symbols in std::, for which I would propose a
> > different strategy.
>
> It would help to know why this was done in the first place; there could be
> other reasons.
Sure, that could be possible. A
> > That would remove the need to define _GNU_SOURCE in the command line.
>
> There are other related problems, such as #108663. It seems that
> _GNU_SOURCE is required anyway when using g++-3.0.
Well, I'm proposing to fix the dependency of libstdc++ to require
_GNU_SOURCE (which is passed throu
> This is evil ;-)
I agree. It would be better if c++config.h would take compiler and
library configurations into account. For *-*-linux-gnu, c++config.h
should contain fragments like
#ifdef __USE_ISOC99
#define _GLIBCPP_USE_C99 1
#endif
That would remove the need to define _GNU_SOURCE in the co
> It would be nice to have more cross-compilers available,
> so that it can become possible cross-compile programs for other
> platforms. Cross-compilers should at least be available for all
> platforms that are supported by Linux.
Notice that much more is necessary for cross-compilation than ju
> > I would recommend to download an old binary, say from SLS 1.0 or so.
> > It will come as a tar file, so it should be easy to install.
>
> Ok, but what's SLS?
Softlanding Linux System, one of the original Linux distributions
(with kernels before 1.0).
Regards,
Martin
> What is the best (easiest :) way to get a gcc capable of
> producing i386-aout targets? I've apt-getted the source of
> gcc-2.95, but it has really scared me, and I didn't found
> the way to accomplish this.
I would recommend to download an old binary, say from SLS 1.0 or so.
It will come as a
> Right. I'm reporting that
>
> 1) gcc's behavior changed in this regard in 2.96 and 3.00 from 2.95 and
>previous, and
Why is that a problem? The compiler does not need to be consistent.
> 2) gcc sometimes uses these values directly without defining the variables,
>while other times gc
> In my opinion, tfunc_t is a pointer to function, not reference. This
> is because the function name (without a context) is a pointer to
> that function, not a reference. If I am wrong, please, let me know.
You are wrong. tfunc_t is neither of type "pointer to function" nor of
type "reference to
> Nor do I believe that the HOWTO suggests that stdio is bad.
Well, it says "Ditch C". It says so only to get my attention, but I
still read it as "if you want to performance, do not use stdio" (and
it actually says that).
Regards,
Martin
> > - require changes to glibc
> > - thus fail to work on older versions of glibc
> > - may break support for older C++ compiler in glibc
> > - break the iostreams ABI of g++ 3.0.
> >
> > To my knowledge, nothing has been done beyond considering solutions so
> > far, but you may ask on the libstdc
> > In gcc 2.95, tieing stdout and cout was achieved by having the same
> > buffer objects. Since the ABI changed, and since the buffer is in
> > glibc, this isn't possilbe anymore.
>
> So, is the final behaviour (aka: non-buffered output) the standard
> behaviour? My guess is not ... if so,
> I tried to investigate and found nothing. I was thinking maybe
> there is a switch for it or something, but found none. Anyway, by
> default, the output should be buffered, AFAIK ... and unless I am
> missing anything.
>
> Any clues?
That appears to be the implementation of the requirement that
> Ugh, yep. Recompiling the dependencies also with the current toolchain
> should fix this, correct? I'm not saying to do it, but it would be an
> interesting experiment if all else fails (read: weapon of last resort).
I think there are still problems compiling glibc with gcc 3; glibc
will clai
> Step 3: Start making the case upstream with the gcc SC, or at least try.
> As you've pointed out, it takes forever to get rid of an option
> or change it in gcc, which is understandable in a way, so why not
> start sooner than later, right? :-)
Exactly.
> The latter is u
> I could have sworn it was NTFS...
>
> util.h:
> typedef enum {
> FILE_$Mft = 0,
> FILE_$MftMirr = 1,
What kernel version? In 2.4.10, this reads
typedef enum {
FILE_Mft= 0,
FILE_MftMirr= 1,
FILE_LogFile= 2,
...
Regards,
Martin
> 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 Debi
> So, my question is, what are the criteria for determining whether or not
> gcc should reject identifiers with dollars?
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
> > 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 program works as expected when compiled with
> -static like "g++
> > gcc by default allows dollars in identifiers on i386.
> > Unfortunately, the assembler does not like them.
>
> I'll spare the explanation of why the assembler barfs (since I'm assuming
> that it's as obvious to everyone else as it is to me)
Could you kindly elaborate a little? I assume one pr
> Please answer somebody wether it is a bug and wether I should submit it to
> GNATS.
I believe this is not a bug, because there are no const-qualified
function types in C++.
If you don't agree, please let us known what you think the value of
TFunc is. IMO, the only reasonable assumption is that
> > It does compile cleanly when replacing with or with
> > .
>
> It may be that that is the proper way to do it; I'm not familiar enough with
> STL to know. Perhaps someone on debian-gcc can comment on this?
Including is certainly the wrong approach; it gives you an rb
tree, not a hash table.
> Seen on two machines including latest debian unstable, so I hope I'm
> not hallucinating:
>
> gcc -Wall -W -Wfloat-equal -Wbad-function-cast -Wcast-qual -Wconversion
> -Wstrict-prototypes -Wmissing-prototypes -I.
> -I/3dsar1/asf_tools/src_lib/asf_inc
> -I/3dsar1/asf_tools/src_lib/asf_odl/incl
> I think it's probably best to wait with forwarding until Matthias or Martin
> have had a chance to look at this.
It's an ICE, so there is definitely a compiler bug. Since it also
occurs on all versions, it should be forwarded upstream; Matthias will
certainly do that.
Of course, there are a num
> I believe that Martin and the others are saying that
> -Wreturn-type catches this specific problem, but that it is not the
> default behaviour because the code is still valid (although the outcome
> may not be what the programmer desired). Am I correct?
Close. The code is valid, but that alon
> Not exactly. Here is what I'm talking about:
I know there are cases that could be detected, like the one you
produce below. However, as soon as you have a function call in the
function, or an operator call, you cannot determine reliably anymore
whether the function will return.
> Are you a g++
1 - 100 of 130 matches
Mail list logo
