--- /dev/null
+Reporting Bugs in the GNU Compiler Collection for Ubuntu
+========================================================
+
+Before reporting a bug, please
+------------------------------
+
+- Check that the behaviour really is a bug. Have a look into some
+ ANSI standards document.
+
+- Check the list of well known bugs: http://gcc.gnu.org/bugs.html#known
+
+- Try to reproduce the bug with a current GCC development snapshot. You
+ usually can get a recent development snapshot from the gcc-snapshot
+ package in the current development distribution.
+
+ See: http://archive.ubuntu.com/ubuntu/pool/universe/g/gcc-snapshot/
+
+- Try to find out if the bug is a regression (an older GCC version does
+ not show the bug).
+
+- Check if the bug is already reported in the bug tracking systems.
+
+ Ubuntu: https://bugs.launchpad.net/~ubuntu-toolchain/+packagebugs
+ Debian: http://bugs.debian.org/debian-gcc@lists.debian.org
+ Upstream: http://gcc.gnu.org/bugzilla/
+
+
+Where to report a bug
+---------------------
+
+Please report bugs found in the packaging of GCC to Launchpad. See below
+how issues should be reported.
+
+Ubuntu's current policy is to closely follow the upstream development and
+only apply a minimal set of patches (which are summarized in the README.Debian
+document).
+
+If you think you have found an upstream bug, you did check the section
+above ("Before reporting a bug") and are able to provide a complete bug
+report (see below "How to report a bug"), then you may help the Ubuntu
+GCC package maintainers, if you report the bug upstream and then submit
+a bug report to Launchpad and tell us the upstream report number.
+This way you are able to follow the upstream bug handling as well. If in
+doubt, report the bug to Launchpad (but read "How to report a bug" below).
+
+Report the issue to https://bugs.launchpad.net/ubuntu/+source/gcc-4.7.
+
+
+How to report a bug
+-------------------
+
+There are complete instructions in the gcc info manual (found in the
+gcc-doc package), section Bugs.
+
+The manual can be read using M-x info in Emacs, or if the GNU info
+program is installed on your system by info --node "(gcc)Bugs". Or see
+the file BUGS included with the gcc source code.
+
+Online bug reporting instructions can be found at
+
+ http://gcc.gnu.org/bugs.html
+
+[Some paragraphs taken from the above URL]
+
+The main purpose of a bug report is to enable us to fix the bug. The
+most important prerequisite for this is that the report must be
+complete and self-contained, which we explain in detail below.
+
+Before you report a bug, please check the list of well-known bugs and,
+if possible in any way, try a current development snapshot.
+
+Summarized bug reporting instructions
+-------------------------------------
+
+What we need
+
+Please include in your bug report all of the following items, the
+first three of which can be obtained from the output of gcc -v:
+
+ * the exact version of GCC;
+ * the system type;
+ * the options given when GCC was configured/built;
+ * the complete command line that triggers the bug;
+ * the compiler output (error messages, warnings, etc.); and
+ * the preprocessed file (*.i*) that triggers the bug, generated by
+ adding -save-temps to the complete compilation command, or, in
+ the case of a bug report for the GNAT front end, a complete set
+ of source files (see below).
+
+What we do not want
+
+ * A source file that #includes header files that are left out
+ of the bug report (see above)
+ * That source file and a collection of header files.
+ * An attached archive (tar, zip, shar, whatever) containing all
+ (or some :-) of the above.
+ * A code snippet that won't cause the compiler to produce the
+ exact output mentioned in the bug report (e.g., a snippet with
+ just a few lines around the one that apparently triggers the
+ bug, with some pieces replaced with ellipses or comments for
+ extra obfuscation :-)
+ * The location (URL) of the package that failed to build (we won't
+ download it, anyway, since you've already given us what we need
+ to duplicate the bug, haven't you? :-)
+ * An error that occurs only some of the times a certain file is
+ compiled, such that retrying a sufficient number of times
+ results in a successful compilation; this is a symptom of a
+ hardware problem, not of a compiler bug (sorry)
+ * E-mail messages that complement previous, incomplete bug
+ reports. Post a new, self-contained, full bug report instead, if
+ possible as a follow-up to the original bug report
+ * Assembly files (*.s) produced by the compiler, or any binary files,
+ such as object files, executables, core files, or precompiled
+ header files
+ * Duplicate bug reports, or reports of bugs already fixed in the
+ development tree, especially those that have already been
+ reported as fixed last week :-)
+ * Bugs in the assembler, the linker or the C library. These are
+ separate projects, with separate mailing lists and different bug
+ reporting procedures
+ * Bugs in releases or snapshots of GCC not issued by the GNU
+ Project. Report them to whoever provided you with the release
+ * Questions about the correctness or the expected behavior of
+ certain constructs that are not GCC extensions. Ask them in
+ forums dedicated to the discussion of the programming language
+
+
+Known Bugs and Non-Bugs
+-----------------------
+
+[Please see /usr/share/doc/gcc/FAQ or http://gcc.gnu.org/faq.html first]
+
+
+C++ exceptions don't work with C libraries
+------------------------------------------
+
+[Taken from the closed bug report #22769] C++ exceptions don't work
+with C libraries, if the C code wasn't designed to be thrown through.
+A solution could be to translate all C libraries with -fexceptions.
+Mostly trying to throw an exception in a callback function (qsort,
+Tcl command callbacks, etc ...). Example:
+
+ #include <stdio.h>
+ #include <tcl.h>
+
+ class A {};
+
+ static
+ int SortCondition(void const*, void const*)
+ {
+ printf("throwing 'sortcondition' exception\n");
+ throw A();
+ }
+
+ int main(int argc, char *argv[])
+ {
+ int list[2];
+
+ try {
+ SortCondition(NULL,NULL);
+ } catch (A) {
+ printf("caught test-sortcondition exception\n");
+ }
+ try {
+ qsort(&list, sizeof(list)/sizeof(list[0]),sizeof(list[0]),
+ &SortCondition);
+ } catch (A) {
+ printf("caught real-sortcondition exception\n");
+ }
+ return 0;
+}
+
+Andrew Macleod <amacleod@cygnus.com> responded:
+
+When compiled with the table driven exception handling, exception can only
+be thrown through functions which have been compiled with the table driven EH.
+If a function isn't compiled that way, then we do not have the frame
+unwinding information required to restore the registers when unwinding.
+
+I believe the setjmp/longjmp mechanism will throw through things like this,
+but its produces much messier code. (-fsjlj-exceptions)
+
+The C compiler does support exceptions, you just have to turn them on
+with -fexceptions.
+
+Your main options are to:
+ a) Don't use callbacks, or at least don't throw through them.
+ b) Get the source and compile the library with -fexceptions (You have to
+ explicitly turn on exceptions in the C compiler)
+ c) always use -fsjlj-exceptions (boo, bad choice :-)
+
+
+g++: "undefined reference" to static const array in class
+---------------------------------------------------------
+
+The following code compiles under GNU C++ 2.7.2 with correct results,
+but produces the same linker error with GNU C++ 2.95.2.
+Alexandre Oliva <oliva@lsd.ic.unicamp.br> responded:
+
+All of them are correct. A static data member *must* be defined
+outside the class body even if it is initialized within the class
+body, but no diagnostic is required if the definition is missing. It
+turns out that some releases do emit references to the missing symbol,
+while others optimize it away.
+
+#include <iostream>
+
+class Test
+{
+ public:
+ Test(const char *q);
+ protected:
+ static const unsigned char Jam_signature[4] = "JAM";
+};
+
+Test::Test(const char *q)
+{
+ if (memcmp(q, Jam_signature, sizeof(Jam_signature)) != 0)
+ cerr << "Hello world!\n";
+}
+
+int main(void)
+{
+ Test::Test("JAM");
+ return 0;
+}
+
+g++: g++ causes passing non const ptr to ptr to a func with const arg
+ to cause an error (not a bug)
+---------------------------------------------------------------------
+
+Example:
+
+#include <stdio.h>
+void test(const char **b){
+ printf ("%s\n",*b);
+}
+int main(void){
+ char *test1="aoeu";
+ test(&test1);
+}
+
+make const
+g++ const.cc -o const
+const.cc: In function int main():
+const.cc:7: passing char ** as argument 1 of test(const char **) adds cv-quals without intervening const
+make: *** [const] Error 1
+
+Answer from "Martin v. Loewis" <martin@loewis.home.cs.tu-berlin.de>:
+
+> ok... maybe I missed something.. I haven't really kept up with the latest in
+> C++ news. But I've never heard anything even remotly close to passing a non
+> const var into a const arg being an error before.
+
+Thanks for your bug report. This is a not a bug in the compiler, but
+in your code. The standard, in 4.4/4, puts it that way
+
+# A conversion can add cv-qualifiers at levels other than the first in
+# multi-level pointers, subject to the following rules:
+# Two pointer types T1 and T2 are similar if there exists a type T and
+# integer n > 0 such that:
+# T1 is cv(1,0) pointer to cv(1,1) pointer to ... cv(1,n-1)
+# pointer to cv(1,n) T
+# and
+# T2 is cv(2,0) pointer to cv(2,1) pointer to ... cv(2,n-1)
+# pointer to cv(2,n) T
+# where each cv(i,j) is const, volatile, const volatile, or
+# nothing. The n-tuple of cv-qualifiers after the first in a pointer
+# type, e.g., cv(1,1) , cv(1,2) , ... , cv(1,n) in the pointer type
+# T1, is called the cv-qualification signature of the pointer type. An
+# expression of type T1 can be converted to type T2 if and only if the
+# following conditions are satisfied:
+# - the pointer types are similar.
+# - for every j > 0, if const is in cv(1,j) then const is in cv(2,j) ,
+# and similarly for volatile.
+# - if the cv(1,j) and cv(2,j) are different, then const is in every
+# cv(2,k) for 0 < k < j.
+
+It is the last rule that your code violates. The standard gives then
+the following example as a rationale:
+
+# [Note: if a program could assign a pointer of type T** to a pointer
+# of type const T** (that is, if line //1 below was allowed), a
+# program could inadvertently modify a const object (as it is done on
+# line //2). For example,
+# int main() {
+# const char c = 'c';
+# char* pc;
+# const char** pcc = &pc; //1: not allowed
+# *pcc = &c;
+# *pc = 'C'; //2: modifies a const object
+# }
+# - end note]
+
+If you question this line of reasoning, please discuss it in one of
+the public C++ fora first, eg. comp.lang.c++.moderated, or
+comp.std.c++.
+
+
+cpp removes blank lines
+-----------------------
+
+With the new cpp, you need to add -traditional to the "cpp -P" args, else
+blank lines get removed.
+
+[EDIT ME: scan Debian bug reports and write some nice summaries ...]
projects / cross.git / blobdiff