i686-linux-gnu-4.7/usr/share/doc/gcc-4.7-base/README.Bugs

   1 Reporting Bugs in the GNU Compiler Collection for Ubuntu
   2 ========================================================
   3
   4 Before reporting a bug, please
   5 ------------------------------
   6
   7 - Check that the behaviour really is a bug. Have a look into some
   8   ANSI standards document.
   9
  10 - Check the list of well known bugs: http://gcc.gnu.org/bugs.html#known
  11
  12 - Try to reproduce the bug with a current GCC development snapshot. You
  13   usually can get a recent development snapshot from the gcc-snapshot
  14   package in the current development distribution.
  15
  16   See: http://archive.ubuntu.com/ubuntu/pool/universe/g/gcc-snapshot/
  17
  18 - Try to find out if the bug is a regression (an older GCC version does
  19   not show the bug).
  20
  21 - Check if the bug is already reported in the bug tracking systems.
  22
  23     Ubuntu:   https://bugs.launchpad.net/~ubuntu-toolchain/+packagebugs
  24     Debian:   http://bugs.debian.org/debian-gcc@lists.debian.org
  25     Upstream: http://gcc.gnu.org/bugzilla/
  26
  27
  28 Where to report a bug
  29 ---------------------
  30
  31 Please report bugs found in the packaging of GCC to Launchpad. See below
  32 how issues should be reported.
  33
  34 Ubuntu's current policy is to closely follow the upstream development and
  35 only apply a minimal set of patches (which are summarized in the README.Debian
  36 document).
  37
  38 If you think you have found an upstream bug, you did check the section
  39 above ("Before reporting a bug") and are able to provide a complete bug
  40 report (see below "How to report a bug"), then you may help the Ubuntu
  41 GCC package maintainers, if you report the bug upstream and then submit
  42 a bug report to Launchpad and tell us the upstream report number.
  43 This way you are able to follow the upstream bug handling as well. If in
  44 doubt, report the bug to Launchpad (but read "How to report a bug" below).
  45
  46 Report the issue to https://bugs.launchpad.net/ubuntu/+source/gcc-4.7.
  47
  48
  49 How to report a bug
  50 -------------------
  51
  52 There are complete instructions in the gcc info manual (found in the
  53 gcc-doc package), section Bugs.
  54
  55 The manual can be read using M-x info in Emacs, or if the GNU info
  56 program is installed on your system by info --node "(gcc)Bugs". Or see
  57 the file BUGS included with the gcc source code.
  58
  59 Online bug reporting instructions can be found at
  60
  61         http://gcc.gnu.org/bugs.html
  62
  63 [Some paragraphs taken from the above URL]
  64
  65 The main purpose of a bug report is to enable us to fix the bug. The
  66 most important prerequisite for this is that the report must be
  67 complete and self-contained, which we explain in detail below.
  68
  69 Before you report a bug, please check the list of well-known bugs and,
  70 if possible in any way, try a current development snapshot.
  71
  72 Summarized bug reporting instructions
  73 -------------------------------------
  74
  75 What we need
  76
  77 Please include in your bug report all of the following items, the
  78 first three of which can be obtained from the output of gcc -v:
  79
  80     * the exact version of GCC;
  81     * the system type;
  82     * the options given when GCC was configured/built;
  83     * the complete command line that triggers the bug;
  84     * the compiler output (error messages, warnings, etc.); and
  85     * the preprocessed file (*.i*) that triggers the bug, generated by
  86       adding -save-temps to the complete compilation command, or, in
  87       the case of a bug report for the GNAT front end, a complete set
  88       of source files (see below).
  89
  90 What we do not want
  91
  92     * A source file that #includes header files that are left out
  93       of the bug report (see above)
  94     * That source file and a collection of header files.
  95     * An attached archive (tar, zip, shar, whatever) containing all
  96       (or some :-) of the above.
  97     * A code snippet that won't cause the compiler to produce the
  98       exact output mentioned in the bug report (e.g., a snippet with
  99       just a few lines around the one that apparently triggers the
 100       bug, with some pieces replaced with ellipses or comments for
 101       extra obfuscation :-)
 102     * The location (URL) of the package that failed to build (we won't
 103       download it, anyway, since you've already given us what we need
 104       to duplicate the bug, haven't you? :-)
 105     * An error that occurs only some of the times a certain file is
 106       compiled, such that retrying a sufficient number of times
 107       results in a successful compilation; this is a symptom of a
 108       hardware problem, not of a compiler bug (sorry)
 109     * E-mail messages that complement previous, incomplete bug
 110       reports. Post a new, self-contained, full bug report instead, if
 111       possible as a follow-up to the original bug report
 112     * Assembly files (*.s) produced by the compiler, or any binary files,
 113       such as object files, executables, core files, or precompiled
 114       header files
 115     * Duplicate bug reports, or reports of bugs already fixed in the
 116       development tree, especially those that have already been
 117       reported as fixed last week :-)
 118     * Bugs in the assembler, the linker or the C library. These are
 119       separate projects, with separate mailing lists and different bug
 120       reporting procedures
 121     * Bugs in releases or snapshots of GCC not issued by the GNU
 122       Project. Report them to whoever provided you with the release
 123     * Questions about the correctness or the expected behavior of
 124       certain constructs that are not GCC extensions. Ask them in
 125       forums dedicated to the discussion of the programming language
 126
 127
 128 Known Bugs and Non-Bugs
 129 -----------------------
 130
 131 [Please see /usr/share/doc/gcc/FAQ or http://gcc.gnu.org/faq.html first]
 132
 133
 134 C++ exceptions don't work with C libraries
 135 ------------------------------------------
 136
 137 [Taken from the closed bug report #22769] C++ exceptions don't work
 138 with C libraries, if the C code wasn't designed to be thrown through.
 139 A solution could be to translate all C libraries with -fexceptions.
 140 Mostly trying to throw an exception in a callback function (qsort,
 141 Tcl command callbacks, etc ...). Example:
 142
 143     #include <stdio.h>
 144     #include <tcl.h>
 145
 146     class A {};
 147
 148     static
 149     int SortCondition(void const*, void const*)
 150     {
 151         printf("throwing 'sortcondition' exception\n");
 152         throw A();
 153     }
 154
 155     int main(int argc, char *argv[])
 156     {
 157         int list[2];
 158
 159         try {
 160             SortCondition(NULL,NULL);
 161         } catch (A) {
 162             printf("caught test-sortcondition exception\n");
 163         }
 164         try {
 165             qsort(&list, sizeof(list)/sizeof(list[0]),sizeof(list[0]),
 166                  &SortCondition);
 167         } catch (A) {
 168             printf("caught real-sortcondition exception\n");
 169         }
 170         return 0;
 171 }
 172
 173 Andrew Macleod <amacleod@cygnus.com> responded:
 174
 175 When compiled with the table driven exception handling, exception can only
 176 be thrown through functions which have been compiled with the table driven EH.
 177 If a function isn't compiled that way, then we do not have the frame
 178 unwinding information required to restore the registers when unwinding.
 179
 180 I believe the setjmp/longjmp mechanism will throw through things like this,
 181 but its produces much messier code.  (-fsjlj-exceptions)
 182
 183 The C compiler does support exceptions, you just have to turn them on
 184 with -fexceptions.
 185
 186 Your main options are to:
 187   a) Don't use callbacks, or at least don't throw through them.
 188   b) Get the source and compile the library with -fexceptions (You have to
 189      explicitly turn on exceptions in the C compiler)
 190   c) always use -fsjlj-exceptions (boo, bad choice :-)
 191
 192
 193 g++: "undefined reference" to static const array in class
 194 ---------------------------------------------------------
 195
 196 The following code compiles under GNU C++ 2.7.2 with correct results,
 197 but produces the same linker error with GNU C++ 2.95.2.
 198 Alexandre Oliva <oliva@lsd.ic.unicamp.br> responded:
 199
 200 All of them are correct.  A static data member *must* be defined
 201 outside the class body even if it is initialized within the class
 202 body, but no diagnostic is required if the definition is missing.  It
 203 turns out that some releases do emit references to the missing symbol,
 204 while others optimize it away.
 205
 206 #include <iostream>
 207
 208 class Test
 209 {
 210   public:
 211     Test(const char *q);
 212   protected:
 213     static const unsigned char  Jam_signature[4]   = "JAM";
 214 };
 215
 216 Test::Test(const char *q)
 217 {
 218   if (memcmp(q, Jam_signature, sizeof(Jam_signature)) != 0)
 219   cerr << "Hello world!\n";
 220 }
 221
 222 int main(void)
 223 {
 224   Test::Test("JAM");
 225   return 0;
 226 }
 227
 228 g++: g++ causes passing non const ptr to ptr to a func with const arg
 229      to cause an error (not a bug)
 230 ---------------------------------------------------------------------
 231
 232 Example:
 233
 234 #include <stdio.h>
 235 void test(const char **b){
 236         printf ("%s\n",*b);
 237 }
 238 int main(void){
 239         char *test1="aoeu";
 240         test(&test1);
 241 }
 242
 243 make const
 244 g++     const.cc   -o const
 245 const.cc: In function int main():
 246 const.cc:7: passing char ** as argument 1 of test(const char **) adds cv-quals without intervening const
 247 make: *** [const] Error 1
 248
 249 Answer from "Martin v. Loewis" <martin@loewis.home.cs.tu-berlin.de>:
 250
 251 > ok... maybe I missed something.. I haven't really kept up with the latest in
 252 > C++ news.  But I've never heard anything even remotly close to passing a non
 253 > const var into a const arg being an error before.
 254
 255 Thanks for your bug report. This is a not a bug in the compiler, but
 256 in your code. The standard, in 4.4/4, puts it that way
 257
 258 # A conversion can add cv-qualifiers at levels other than the first in
 259 # multi-level pointers, subject to the following rules:
 260 # Two pointer types T1 and T2 are similar if there exists a type T and
 261 # integer n > 0 such that:
 262 #   T1 is cv(1,0) pointer to cv(1,1) pointer to ... cv(1,n-1)
 263 #   pointer to cv(1,n) T
 264 # and
 265 #   T2 is cv(2,0) pointer to cv(2,1) pointer to ... cv(2,n-1)
 266 #   pointer to cv(2,n) T
 267 # where each cv(i,j) is const, volatile, const volatile, or
 268 # nothing. The n-tuple of cv-qualifiers after the first in a pointer
 269 # type, e.g., cv(1,1) , cv(1,2) , ... , cv(1,n) in the pointer type
 270 # T1, is called the cv-qualification signature of the pointer type. An
 271 # expression of type T1 can be converted to type T2 if and only if the
 272 # following conditions are satisfied:
 273 #  - the pointer types are similar.
 274 #  - for every j > 0, if const is in cv(1,j) then const is in cv(2,j) ,
 275 #    and similarly for volatile.
 276 #  - if the cv(1,j) and cv(2,j) are different, then const is in every
 277 #    cv(2,k) for 0 < k < j.
 278
 279 It is the last rule that your code violates. The standard gives then
 280 the following example as a rationale:
 281
 282 # [Note: if a program could assign a pointer of type T** to a pointer
 283 # of type const T** (that is, if line //1 below was allowed), a
 284 # program could inadvertently modify a const object (as it is done on
 285 # line //2). For example,
 286 # int main() {
 287 #   const char c = 'c';
 288 #   char* pc;
 289 #   const char** pcc = &pc; //1: not allowed
 290 #   *pcc = &c;
 291 #   *pc = 'C'; //2: modifies a const object
 292 # }
 293 # - end note]
 294
 295 If you question this line of reasoning, please discuss it in one of
 296 the public C++ fora first, eg. comp.lang.c++.moderated, or
 297 comp.std.c++.
 298
 299
 300 cpp removes blank lines
 301 -----------------------
 302
 303 With the new cpp, you need to add -traditional to the "cpp -P" args, else
 304 blank lines get removed.
 305
 306 [EDIT ME: scan Debian bug reports and write some nice summaries ...]