[Bug testsuite/42348] Syntax of dg-skip-if in two obj-c++ tests
--- Comment #1 from mrs at apple dot com 2009-12-10 18:13 ---
In general you can answer what we think is best by checking the llvm-gcc
sources from llvm, and in this case, we are using:
/* { dg-options -fnext-runtime -fno-constant-cfstrings } */
/* { dg-do compile { target powerpc*-*-darwin* i?86*-*-darwin* } } */
/* { dg-require-effective-target ilp32 } */
for const-str-9.mm. For template-4.mm:
/* { dg-do run { target powerpc*-*-darwin* } } */
/* { dg-require-effective-target ilp32 } */
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42348
[Bug other/42333] complex division failure on darwin10 with -lm
--- Comment #25 from mrs at apple dot com 2009-12-09 18:29 --- I've filed radr://7457013 for libSystem (aka libm on 10.6) to improve the accuracy of ___divdc3. If that were fixed, then having -lm or not wouldn't matter. -- mrs at apple dot com changed: What|Removed |Added CC||mrs at apple dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42333
[Bug other/42333] complex division failure on darwin10 with -lm
--- Comment #27 from mrs at apple dot com 2009-12-09 18:48 --- nm | grep ___divdc3 on all the objects and libraries on the link line, will tell you from where this symbol can be resolved. Reading the link line, will tell you the order ld will resolve in, but you have to realize that .dylibs always resolve first, before .a files (such a libgcc.a). This is explained in the ld man page. See -search_paths_first for more detail. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42333
[Bug c++/41313] r150553 causes g++.dg/tree-prof/partition1.C compilation and execution test failures on *-apple-darwin*
--- Comment #32 from mrs at apple dot com 2009-10-05 20:55 --- I suspect the other case is simply: if (flag_exceptions) flag_reorder_blocks_and_partition = 0; be added, just like the code for flag_unwind_tables. I suspect this, as the testcase is *.C. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41313
[Bug c++/41313] r150553 causes g++.dg/tree-prof/partition1.C compilation and execution test failures on *-apple-darwin*
--- Comment #33 from mrs at apple dot com 2009-10-05 21:16 --- I'm fine with the latest patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41313
[Bug target/41595] object-c++ mangled local labels are not correctly recognized.
--- Comment #2 from mrs at apple dot com 2009-10-05 21:21 --- Ok. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41595
[Bug c++/41313] g++.dg/tree-prof/partition1.C compilation and execution test failures on *-apple-darwin*
--- Comment #18 from mrs at apple dot com 2009-10-01 19:14 --- Yes. If someone wants to propose a better solution, they will... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41313
[Bug other/39888] TLS emutls not linked to automatically on Darwin
--- Comment #58 from mrs at apple dot com 2009-10-01 19:18 --- Seems reasonable. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888
[Bug c++/41313] g++.dg/tree-prof/partition1.C compilation and execution test failures on *-apple-darwin*
--- Comment #20 from mrs at apple dot com 2009-10-02 02:03 --- flag_reorder_blocks_and_partition was the complete name of the variable last I looked. If flag_unwind_tables is true and this variable is true, that's the bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41313
[Bug other/39888] TLS emutls not linked to automatically on Darwin
--- Comment #51 from mrs at apple dot com 2009-09-30 19:45 --- Looks much better than past versions... Seems like muse-shared-libgcc-ext should be the default, and possibly that we don't even need the switch? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888
[Bug c++/41313] g++.dg/tree-prof/partition1.C compilation and execution test failures on *-apple-darwin*
--- Comment #10 from mrs at apple dot com 2009-09-30 20:54 --- When targeting darwin10, the .eh symbols don't have to be generated anymore. They are from darwin.c, darwin_emit_unwind_label. if (darwin_macosx_version_min strverscmp (darwin_macosx_version_min, 10.6) = 0) can be used, and the entirety of the routine can be avoided. That said, this is a bug somewhere, it can be found by binary searching the testcase on the compiler sources until the change that dupped these is found. I don't believe it has always been broken. Or, you can just put a breakpoint on this routine, and when the second one is hit, find a variable that is different that the first time it is hit, and pass that as a parameter and the bail out, just like ! for_eh. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41313
[Bug c++/41313] g++.dg/tree-prof/partition1.C compilation and execution test failures on *-apple-darwin*
--- Comment #15 from mrs at apple dot com 2009-10-01 00:54 --- Yeah, the patch in #11 is about the right for half the problem (darwin10), if it weren't for ld's warning message. I don't know quite why it is doing that, so guess we'll just have to nix that idea. So, the next best thing would be to just turn off hot/cold partitioning for darwin. In override_option in darwin.c, just do hot_cold = 0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41313
[Bug other/39888] TLS emutls not linked to automatically on Darwin
--- Comment #19 from mrs at apple dot com 2009-09-23 20:43 --- Subject: Re: TLS emutls not linked to automatically on Darwin On Sep 22, 2009, at 8:02 PM, howarth at nitro dot med dot uc dot edu wrote: Doesn't this imply that you can't make force libgcc to be found before libSystem under SL? No. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888
[Bug other/39888] TLS emutls not linked to automatically on Darwin
--- Comment #20 from mrs at apple dot com 2009-09-23 20:48 --- Subject: Re: TLS emutls not linked to automatically on Darwin On Sep 23, 2009, at 8:50 AM, howarth at nitro dot med dot uc dot edu wrote: What about just leveraging PIC-code libgcc.a on darwin by creating a libgcc_ext Around we go... The question is why do that? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888
[Bug other/39888] TLS emutls not linked to automatically on Darwin
--- Comment #21 from mrs at apple dot com 2009-09-23 20:49 --- Subject: Re: TLS emutls not linked to automatically on Darwin On Sep 23, 2009, at 9:19 AM, howarth at nitro dot med dot uc dot edu wrote: What we need is an approach that links in libgcc.a or libgcc_s to a dummy libgcc_ext Why? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888
[Bug other/39888] TLS emutls not linked to automatically on Darwin
--- Comment #22 from mrs at apple dot com 2009-09-23 20:52 --- Subject: Re: TLS emutls not linked to automatically on Darwin On Sep 23, 2009, at 11:40 AM, howarth at nitro dot med dot uc dot edu wrote: Also I don't see why the macro above has any advantages over just using -unexported_symbols_list -mmacosx-version-min= won't work. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888
[Bug other/39888] TLS emutls not linked to automatically on Darwin
--- Comment #6 from mrs at apple dot com 2009-09-22 18:56 --- I wonder if we could just trim out the symbols from libgcc that are in libSystem, and arrange for gcc's installed libgcc to be found first. Advantage, simplicity, less target specific work, easy to understand. Downside, OS upgrades require recompiling the world, to the extent there are new symbols in libgcc that are then added to libSystem in later OS releases. ld has magic in it that can appear and disappear symbols from a dylib depending upon which OS is targeted. Target old OSes, all the usual symbols are there, target newer OSes, large swaths disappear (but are found anyway in libSystem). Also, all this fun stuff it relevant to darwin10 and later only (not darwin9). I'm not a fan of yet more compile flags in general. I'd rather have a nice design that covers the bases, that doesn't really need yet more flags. The hiding trick goes something like: #define NOT_HERE_BEFORE_10_6(sym) \ extern const char sym##_tmp3 __asm($ld$hide$os10.3$_ #sym ); \ __attribute__((visibility(default))) const char sym##_tmp3 = 0; \ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888
[Bug other/39888] TLS emutls not linked to automatically on Darwin
--- Comment #8 from mrs at apple dot com 2009-09-22 21:17 --- I meant the idea that libSystem has new symbols in it is relevant only to darwin10. The system libgcc_s is present on older OSes, so those aspects are still relevant. Yeah, to solve that problem one would either have to have a new name, or possibly an explicit path. I've not tried the later, but it might offer a way to construct the library with fewer mods. from darwin10: $ nm /usr/lib/libgcc_s.1.dylib | grep Unwind_Bac 0019f9c6 S $ld$hide$os10.4$__Unwind_Backtrace 0019f9c7 S $ld$hide$os10.5$__Unwind_Backtrace 00163b30 T __Unwind_Backtrace $ nm /usr/lib/libSystem.dylib | grep Unwind_Bac 0019f9c6 S $ld$hide$os10.4$__Unwind_Backtrace 0019f9c7 S $ld$hide$os10.5$__Unwind_Backtrace 00163b30 T __Unwind_Backtrace also note, there is add as well as hide; $ nm /usr/lib/libgcc_s.10.5.dylib | grep Unwind_Back 0f0a S $ld$add$os10.4$__Unwind_Backtrace 0f0b S $ld$add$os10.5$__Unwind_Backtrace As for what functions (symbols), well, the ones in common between libSystem/libgcc_s on the system and libgcc from gcc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888
[Bug bootstrap/41180] can not build gcc 4.4.1 on Snow Leopard Mac OS X 10.6
--- Comment #30 from mrs at apple dot com 2009-09-04 01:49 --- I admit that having gcc automagically add -m32 isn't strictly needed, the user can do that. The problem is when they don't do that. What behavior do we want? We can pick: 1) Just work. 2) Fail immediately, telling them they did it wrong. 3) Grind away for hours, just to fail in some obscure hard to understand way Status quo is #3. Now, we have the choice to do this, or to do 1. Argue against 1; it is import to fail in some obscure way because... I have never see a compelling argument. I did the change up as I was supporting users that grew tied of it failing all the time. I grew tied of it failing all the time. For me, it's an easy choice. The cost of the few lines is well worth the benefit to me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41180
[Bug bootstrap/41224] [4.5 Regression] Bootstrap broken on powerpc-apple-darwin9 at revision 151318
--- Comment #11 from mrs at apple dot com 2009-09-02 17:41 --- dwarfdump exists on 10.5 and 10.6. Not sure if that would help at all (I've not been following what people are doing). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41224
[Bug bootstrap/41224] [4.5 Regression] Bootstrap broken on powerpc-apple-darwin9 at revision 151318
--- Comment #13 from mrs at apple dot com 2009-09-02 20:17 --- Subject: Re: [4.5 Regression] Bootstrap broken on powerpc-apple-darwin9 at revision 151318 On Sep 2, 2009, at 12:57 PM, howarth at nitro dot med dot uc dot edu wrote: --- Comment #12 from howarth at nitro dot med dot uc dot edu 2009-09-02 19:57 --- (In reply to comment #11) dwarfdump exists on 10.5 and 10.6. Not sure if that would help at all (I've not been following what people are doing). Can you find out if the darwin's strip reorders the sections? This seems to by why Solaris's comparison of stage2 and stage3 is failing (PR41228)? If so is there an option to suppress the reordering? No option. I suspect it can. You should be able to run otool and print the sections out. As I recall, the order printed, is the order in the file. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41224
[Bug bootstrap/41180] can not build gcc 4.4.1 on Snow Leopard Mac OS X 10.6
--- Comment #21 from mrs at apple dot com 2009-09-02 20:37 --- The patch in #19 is wrong. If you configure a x86-ppc64 compile, it would want to use -m32, which is wrong. We experimented with a change like that in #20 and it resulted in failures; I can't imagine any good coming from it. In short, CC isn't a variable that can be changed here, like this, only tentative_cc can be. I don't know what these two bits are trying to fix, so, I can't say what the right solution is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41180
[Bug bootstrap/41180] can not build gcc 4.4.1 on Snow Leopard Mac OS X 10.6
--- Comment #26 from mrs at apple dot com 2009-09-03 00:20 --- First, config.guess is orthogonal to the entire discussion, because of that, we never need to mention it again. Next, we do a case analysis of every combination of host/target and build We engineer each case to work as desired. Once that is done, you'll discover that we absolutely do need the i386 case to set -m32. If that isn't done, the compiler defaults to 64-bit, and that runs counter to the command implied by the i386, which is to generate 32-bit code. So, the fragment I sent is absolutely required, unchanged. You can know this is true by configure --build=i386-apple-darwin10 on a 64-bit SL box and running file on gcc/expr.o. If it is 64-bit, it is wrong. -m32 should never be set because the x86_64 case. x86_64 means 64-bit, so, the most it implies is -m64. For this reason, #19 must be wrong. x86_64 implying -m64 is useful for gcc's that default to 32-bit code-gen. I don't have that in my tree, as I don't have to worry much about older systems and older compilers. For the FSF tree, it would be nice to have that. You can know this is true by configuring --build=x86_64-apple-darwin on a Leopard box (where gcc defaults to 32-bit) and running file on gcc/expr.o. If it is 32-bit, it is wrong. darwin10 supports and runs on 32-bit only processors. In that case, x86_64 isn't the default code-gen, contrary to your statement in #22. It is improper to test target in #20, as target has no influence. --host=i386-apple-darwin --target=arm-elf implies -m32. Build one, then run file gcc/expr.o. If that file is 64-bit, it is wrong. The changes to configure.ac are independent of config.guess, so your assertion that the changes are only appropriate after config.guess is accepted, is wrong. You can see this by configure --build=i386-apple-darwin10 and running file gcc/expr.o and noticing it is wrong currently on SL. It is says 64-bit, it is wrong. For the comment in #24, no, that isn't its only purpose. The purpose of it would be to allow one to configure --host=i386-apple-darwin10 --build=i386-apple-darwin10, and have gcc do what it is told to do, which is to generate 32-bit binaries. Now, all that aside, you only need to change the patches I suggested, if there is an error in them. You've not identified one error, therefore you don't need to change them. If you want to change them, please explain the error. Lastly, tentative_cc won't work as well as setting CC. My comment in #15 is wrong, CC must be used. As for the libraries. You have to build them appropriately, and give to gcc, the appropriate libs. I build them universal, so what I give gcc is trivially, always good. If you build just one architecture, you have to build the libraries with the same 32/64-bitness as you want to build the compiler. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41180
[Bug bootstrap/41180] can not build gcc 4.4.1 on Snow Leopard Mac OS X 10.6
--- Comment #16 from mrs at apple dot com 2009-08-31 17:37 --- Oops, I mean #12 and #13. For #13, make sure there isn't an existing entry already. If there is, the code should be added to it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41180
[Bug bootstrap/41180] can not build gcc 4.4.1 on Snow Leopard Mac OS X 10.6
--- Comment #15 from mrs at apple dot com 2009-08-31 17:35 --- #13 looks fine. #14 needs a build to confirm it works. I've tested the style of #14 in the gcc-4.2.1 tree and it works as expected. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41180
[Bug bootstrap/41180] can not build gcc 4.4.1 on Snow Leopard Mac OS X 10.6
--- Comment #18 from mrs at apple dot com 2009-08-31 20:37 --- That file just has: # APPLE LOCAL file dynamic-no-pic # The -mdynamic-no-pic ensures that the compiler executable is built without # position-independent-code -- the usual default on Darwin. BOOT_CFLAGS=-g -O2 -mdynamic-no-pic in it. This just results in a faster compiler, otherwise, there should be no real change. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41180
[Bug target/34587] gcc.dg/initpri1.c fails on *-apple-darwin
--- Comment #13 from mrs at apple dot com 2009-02-17 19:18 --- Ok to add that to darwin.h. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34587
[Bug libstdc++/36164] abi breakage, stdio_sync_filebuf routines missing
--- Comment #8 from mrs at apple dot com 2009-01-24 04:18 --- First, you didn't test 4.0.0, so all your reasoning is invalid. Second, claiming no ABI breakage when there is abi breakage is silly. I guess if you have no customers with no software, with do previously deployed software and you don't care about abi breakage, you can get away with it. Unfortunately, this doesn't apply in our case. I'd rather you close this out as won't fix, if you can't be bothered to even actually check the abi of gcc-4.0.0 and compare it against 4.2.1, it is more honest. Closing it as invalid is wrong. :-( -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36164
[Bug libstdc++/36173] abi breakage, stdio_filebuf routines missing
--- Comment #4 from mrs at apple dot com 2009-01-24 04:22 --- First, you didn't test 4.0.0, so all your reasoning is invalid. Second, claiming no ABI breakage when there is abi breakage is silly. I guess if you have no customers with no software, with do previously deployed software and you don't care about abi breakage, you can get away with it. Unfortunately, this doesn't apply in our case. I'd rather you close this out as won't fix, if you can't be bothered to even actually check the abi of gcc-4.0.0 and compare it against 4.2.1, it is more honest. Closing it as invalid is wrong. :-( -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36173
[Bug bootstrap/38300] [4.4 Regression] libstdc++ and libgcj contain a reference to _Unwind_GetIPInfo
--- Comment #9 from mrs at apple dot com 2008-12-18 12:21 --- Ok with the: + *-*-darwin[3-8]*) have_unwind_getipinfo=no ;; spelling. It matches the spelling in the rest of the compiler, which makes it easier to spot and modify. Technically, the: *-*-darwin[0-8]|*-*-darwin[0-8].*) ... is a bit more perfect, but, I'm not terribly worried about darwin1 or darwin2 systems. They won't work for other reasons. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38300
[Bug testsuite/35677] Intermitent failure FAIL: libgomp.fortran/crayptr2.f90
--- Comment #21 from mrs at apple dot com 2008-12-12 18:42 --- My long term guidance would be to engineer gcc to use its copy of the libgcc_s dylib and link against it. This would mean that the newly installed libgcc_s should be found first, over /usr/lib, and that development and support mirror linux, in all the usual ways. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35677
[Bug c++/19351] operator new[] can return heap blocks which are too small
--- Comment #17 from mrs at apple dot com 2008-12-09 23:24 --- I agree, Apple would like this as well... radr://5739832 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19351
[Bug c/38375] New: infinite loop on invalid struct redefinition
struct sqt13 {};
struct sqt13 {
struct sqt13 x;
} y = { 3.0 };
takes infinite time/memory to compile.
GNU C (GCC) version 4.4.0 20081003 (experimental) [trunk revision 140855]
(i686-apple-darwin9)
--
Summary: infinite loop on invalid struct redefinition
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mrs at apple dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38375
[Bug c/38375] infinite loop on invalid struct redefinition
--- Comment #1 from mrs at apple dot com 2008-12-02 21:43 --- Radar 6400208 -- mrs at apple dot com changed: What|Removed |Added CC||mrs at apple dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38375
[Bug c/36113] fix C enumerators
--- Comment #5 from mrs at apple dot com 2008-11-18 20:26 --- The C standard mandates that all enumeration constants have the same type, gcc violates this requirement. -- mrs at apple dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36113
[Bug c++/38087] Pseudo destructor call
--- Comment #3 from mrs at apple dot com 2008-11-12 18:33 --- I'm merely eching bits from the clang development list... Now they think the above doesn't apply, but 3.4.5p3 does: 3 If the unquali#64257;ed-id is #8764; type-name, the type-name is looked up in the context of the entire post#64257;x-expression. If the type T of the object expression is of a class type C, the type-name is also looked up in the scope of class C. At least one of the lookups shall #64257;nd a name that refers to (possibly cv-quali#64257;ed) T. :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38087
[Bug testsuite/37202] FAIL: gcc.dg/visibility-1[4-9].c
--- Comment #13 from mrs at apple dot com 2008-11-11 23:13 --- The darwin patch is fine. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37202
[Bug c++/38087] New: Pseudo destructor call
In 5.2.4p2 [expr.pseudo]:
The cv-unqualified versions of
the object type and of the type designated by the pseudo-destructor-
name shall be the same type.
class B { };
class C : public B {
void m() {
this-~B();
}
};
I tried:
GNU C++ (GCC) version 4.4.0 20081003 (experimental) [trunk revision 140855]
(i686-apple-darwin9)
and it gave no error.
--
Summary: Pseudo destructor call
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mrs at apple dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38087
[Bug middle-end/37864] New: incorrect warning from fold
We found an interesting bootstrap failure in gcc after changing a machine
definition some, the important bits are below. Something is wrong, but it is
hard to say exactly what. The warning would be fine, if there were no
preprocessor involved. But, it is. The warning doesn't make any sense for the
source in stmt.c, and the definitions in insn-*.h are also valid. When the
preprocessor combines them, then the result is worthy of warning about, but,
that's hardly the fault of stmt.c, or the machine definition. Logically, we
want to only issue the warning if the code in question came from the user, not
as a combination of macro preprocessing. I can't recall any other place in the
compiler when we take into consideration the preprocessor like this, so that
makes this case weird in my book.
So, some solutions:
Don't use -Werror, because stmt.c can warn on some .md files.
Remove the warning, the benefit isn't work the risk of false positives.
Keep the warning, but somehow take into consideration the preprocessor (ick).
Recode how the insn-*.h files are generated to avoid the warning.
Redo stmt.c to use a local variable and then use that in the conditional.
Thoughts? Currently we're taking the last approach, but it just feels icky.
Longer term, would be nice if gcc were architected so that this can't crop up.
$ cat /tmp/t.c
extern int target_flags;
#define ARM ((target_flags (1 16)) != 0)
#define THUMB (!ARM)
#define LONGCALL ((target_flags (1 11)) != 0)
#define ARMLONGCALL ((target_flags ((116) | (111))) != 0)
// 4.2 version:
//#define HAVE_tablejump (ARM || LONGCALL)
// shows same problem in 4.4
#define HAVE_tablejump (ARMLONGCALL)
#define HAVE_casesi (THUMB)
void foo();
void expand_case()
{
if (0
/* If neither casesi or tablejump is available, we can
only go this way. */
|| (!HAVE_casesi !HAVE_tablejump))
foo();
}
$ ./xgcc -B./ -c /tmp/t.c -O
/tmp/t.c: In function 'expand_case':
/tmp/t.c:21: warning: 'and' of mutually exclusive equal-tests is always 0
gcc version 4.4.0 20081003 (experimental) [trunk revision 140855] (GCC)
--
Summary: incorrect warning from fold
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mrs at apple dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37864
[Bug c++/37728] New: if scoping for declarations
In:
http://lists.cs.uiuc.edu/pipermail/llvmdev/2008-October/017449.html
we were discussing possible bugs in g++ scoping for if statements.
$ cat t.cc
void foo() {
if (int x = 0) {
int x;
}
}
$ ./xgcc -B./ -c t.cc
$
they expected this to produce a redeclaration error on the inner declaration
for X.
Tested on gcc version 4.4.0 20081003 (experimental) [trunk revision 140855]
(GCC)
There were other concerns about for, but, others seem to think gcc does the
right thing with them.
--
Summary: if scoping for declarations
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mrs at apple dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37728
[Bug c++/37465] New: ctors never override virtual functions
class A {
virtual int B() { return 0; }
};
class B: A {
B() { }
};
gives an error, but should compile (as gross as it is). I'm hoping there is a
prohibition against it, but didn't find one.
--
Summary: ctors never override virtual functions
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mrs at apple dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37465
[Bug c++/37465] ctors never override virtual functions
--- Comment #1 from mrs at apple dot com 2008-09-10 18:28 --- radr://6202462 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37465
[Bug c++/37260] New: infinite loop in init
gcc version 4.4.0 20080827 (experimental) [trunk revision 138965] (GCC)
produces:
/tmp/t.cc:9: error: initializer for pthread_once_t must be brace-enclosed
/tmp/t.cc:9: error: initializer for pthread_once_t must be brace-enclosed
/tmp/t.cc:9: error: initializer for pthread_once_t must be brace-enclosed
/tmp/t.cc:9: error: initializer for pthread_once_t must be brace-enclosed
/tmp/t.cc:9: error: initializer for pthread_once_t must be brace-enclosed
/tmp/t.cc:9: error: initializer for pthread_once_t must be brace-enclosed
/tmp/t.cc:9: error: initializer for pthread_once_t must be brace-enclosed
[...]
for
struct pthread_once_t { };
struct test {
pthread_once_t once;
};
int main(void) {
struct test foo = {
once: PTHREAD_ONCE_INITIALIZER
};
return 0;
}
:-(
--
Summary: infinite loop in init
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mrs at apple dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37260
[Bug c++/37260] infinite loop in init
--- Comment #1 from mrs at apple dot com 2008-08-27 22:47 --- I think reshape_init_r doesn't handle init when it ia error_mark_node. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37260
[Bug c++/37085] New: global friends in classes
Global friend inside a class regressed.
$ cat /tmp/t.cc
class test1 {
public:
friend void newtest1(int x) {
}
};
int main(int argc, char *argv[]) {
newtest1(5);
}
$ ./xgcc -B./ /tmp/t.cc -c
/tmp/t.cc: In function int main(int, char**):
/tmp/t.cc:8: error: newtest1 was not declared in this scope
GNU C++ (GCC) version 4.4.0 20080811 (experimental) [trunk revision 138965]
(i686-apple-darwin9)
This worked just fine in gcc 4.0.1.
radr://6135771
--
Summary: global friends in classes
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mrs at apple dot com
GCC host triplet: i686-apple-darwin9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37085
[Bug c++/37085] global friends in classes
--- Comment #1 from mrs at apple dot com 2008-08-11 21:39 --- Oh, see 11.4p5 (ANSI 98 standard) for details on this type of code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37085
[Bug c++/17729] [4.2/4.3/4.4 Regression] Duplicate __attribute__((deprecated)) warning
--- Comment #12 from mrs at apple dot com 2008-07-23 21:12 --- radr://4232969 -- mrs at apple dot com changed: What|Removed |Added CC||mrs at apple dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17729
[Bug c/36868] New: -ftrapv doesn't trap
The -ftrapv doesn't seem to want to generate code that will trap on overflow
with optimization. I've tried with and without -fwrapv to try and get it to
work.
$ cat t.c
#include stdio.h
int foo( int a) {
if (a + 100 a) {
printf(Integer overflow detected!\n);
} else {
printf(Integer overflow not detected!\n);
}
return a;
}
int main() {
foo(0x7fff);
}
mrs2 $ ./xgcc -B./ -fno-wrapv -ftrapv t.c -O2
mrs2 $ a.out
Integer overflow detected!
mrs2 $ ./xgcc -B./ -fwrapv -ftrapv t.c -O2
mrs2 $ a.out
Integer overflow detected!
mrs2 $ ./xgcc -B./ -fwrapv -ftrapv t.c
mrs2 $ a.out
Abort trap
mrs2 $ ./xgcc -B./ -fno-wrapv -ftrapv t.c
mrs2 $ a.out
Abort trap
--
Summary: -ftrapv doesn't trap
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mrs at apple dot com
GCC host triplet: i686-apple-darwin9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36868
[Bug libstdc++/36173] New: abi breakage, stdio_filebuf routines missing
A few routines seem to have disappeared from 4.0.0 to 4.2.1: _ZN9__gnu_cxx13stdio_filebufIcSt11char_traitsIcEE2fdEv; _ZN9__gnu_cxx13stdio_filebufIcSt11char_traitsIcEE4fileEv; _ZN9__gnu_cxx13stdio_filebufIcSt11char_traitsIcEEC1EP7__sFILESt13_Ios_Openmodem; _ZN9__gnu_cxx13stdio_filebufIcSt11char_traitsIcEEC1EiSt13_Ios_Openmodem; _ZN9__gnu_cxx13stdio_filebufIcSt11char_traitsIcEEC1Ev; _ZN9__gnu_cxx13stdio_filebufIcSt11char_traitsIcEEC2EP7__sFILESt13_Ios_Openmodem; _ZN9__gnu_cxx13stdio_filebufIcSt11char_traitsIcEEC2EiSt13_Ios_Openmodem; _ZN9__gnu_cxx13stdio_filebufIcSt11char_traitsIcEEC2Ev; _ZN9__gnu_cxx13stdio_filebufIcSt11char_traitsIcEED0Ev; _ZN9__gnu_cxx13stdio_filebufIcSt11char_traitsIcEED1Ev; _ZN9__gnu_cxx13stdio_filebufIcSt11char_traitsIcEED2Ev; _ZN9__gnu_cxx13stdio_filebufIwSt11char_traitsIwEE2fdEv; _ZN9__gnu_cxx13stdio_filebufIwSt11char_traitsIwEE4fileEv; _ZN9__gnu_cxx13stdio_filebufIwSt11char_traitsIwEEC1EP7__sFILESt13_Ios_Openmodem; _ZN9__gnu_cxx13stdio_filebufIwSt11char_traitsIwEEC1EiSt13_Ios_Openmodem; _ZN9__gnu_cxx13stdio_filebufIwSt11char_traitsIwEEC1Ev; _ZN9__gnu_cxx13stdio_filebufIwSt11char_traitsIwEEC2EP7__sFILESt13_Ios_Openmodem; _ZN9__gnu_cxx13stdio_filebufIwSt11char_traitsIwEEC2EiSt13_Ios_Openmodem; _ZN9__gnu_cxx13stdio_filebufIwSt11char_traitsIwEEC2Ev; _ZN9__gnu_cxx13stdio_filebufIwSt11char_traitsIwEED0Ev; _ZN9__gnu_cxx13stdio_filebufIwSt11char_traitsIwEED1Ev; _ZN9__gnu_cxx13stdio_filebufIwSt11char_traitsIwEED2Ev; _ZTVN9__gnu_cxx13stdio_filebufIcSt11char_traitsIcEEE; _ZTVN9__gnu_cxx13stdio_filebufIwSt11char_traitsIwEEE; Adding these back to libstdc++-v3/config/abi/pre/gnu.ver seems to make it better. -- Summary: abi breakage, stdio_filebuf routines missing Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mrs at apple dot com GCC target triplet: powerpc-apple-darwin9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36173
[Bug libstdc++/36164] New: abi breakage, stdio_sync_filebuf routines missing
A few routines seem to have disappeared from 4.0.0 to 4.2.1: mrs2 $ nm /usr/lib/libstdc++.6.0.4.dylib | grep __ZN9__gnu_cxx18stdio_sync_filebuf | c++filt 000252d2 T __gnu_cxx::stdio_sync_filebufchar, std::char_traitschar ::file() 000252fc T __gnu_cxx::stdio_sync_filebufchar, std::char_traitschar ::sync() 000252de T __gnu_cxx::stdio_sync_filebufchar, std::char_traitschar ::uflow() 00025894 T __gnu_cxx::stdio_sync_filebufchar, std::char_traitschar ::seekoff(long long, std::_Ios_Seekdir, std::_Ios_Openmode) 00025a3c T __gnu_cxx::stdio_sync_filebufchar, std::char_traitschar ::seekpos(std::fpos__mbstate_t, std::_Ios_Openmode) 0002554c T __gnu_cxx::stdio_sync_filebufchar, std::char_traitschar ::overflow(int) 00025b02 T __gnu_cxx::stdio_sync_filebufchar, std::char_traitschar ::pbackfail(int) 00025bda T __gnu_cxx::stdio_sync_filebufchar, std::char_traitschar ::underflow() 00025542 T __gnu_cxx::stdio_sync_filebufchar, std::char_traitschar ::stdio_sync_filebuf(__sFILE*) 00025504 T __gnu_cxx::stdio_sync_filebufchar, std::char_traitschar ::stdio_sync_filebuf(__sFILE*) 0002530e T __gnu_cxx::stdio_sync_filebufwchar_t, std::char_traitswchar_t ::file() 0002531a T __gnu_cxx::stdio_sync_filebufwchar_t, std::char_traitswchar_t ::sync() 00025bbc T __gnu_cxx::stdio_sync_filebufwchar_t, std::char_traitswchar_t ::uflow() 00025968 T __gnu_cxx::stdio_sync_filebufwchar_t, std::char_traitswchar_t ::seekoff(long long, std::_Ios_Seekdir, std::_Ios_Openmode) 0002532c T __gnu_cxx::stdio_sync_filebufwchar_t, std::char_traitswchar_t ::seekpos(std::fpos__mbstate_t, std::_Ios_Openmode) 00025ab8 T __gnu_cxx::stdio_sync_filebufwchar_t, std::char_traitswchar_t ::overflow(int) 00025b4a T __gnu_cxx::stdio_sync_filebufwchar_t, std::char_traitswchar_t ::pbackfail(int) 00025b92 T __gnu_cxx::stdio_sync_filebufwchar_t, std::char_traitswchar_t ::underflow() 000254fa T __gnu_cxx::stdio_sync_filebufwchar_t, std::char_traitswchar_t ::stdio_sync_filebuf(__sFILE*) 000254bc T __gnu_cxx::stdio_sync_filebufwchar_t, std::char_traitswchar_t ::stdio_sync_filebuf(__sFILE*) mrs2 $ nm /usr/lib/libstdc++.6.0.9.dylib | grep __ZN9__gnu_cxx18stdio_sync_filebuf | c++filt 0002c57c T __gnu_cxx::stdio_sync_filebufchar, std::char_traitschar ::file() 0002c5dc T __gnu_cxx::stdio_sync_filebufchar, std::char_traitschar ::seekpos(std::fpos__mbstate_t, std::_Ios_Openmode) 0002c588 T __gnu_cxx::stdio_sync_filebufwchar_t, std::char_traitswchar_t ::file() 0002c9ae T __gnu_cxx::stdio_sync_filebufwchar_t, std::char_traitswchar_t ::seekpos(std::fpos__mbstate_t, std::_Ios_Openmode) :-( This breaks Norton Anti Virus v11. Radar 5897367 -- Summary: abi breakage, stdio_sync_filebuf routines missing Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mrs at apple dot com GCC target triplet: powerpc-apple-darwin9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36164
[Bug libstdc++/36164] abi breakage, stdio_sync_filebuf routines missing
--- Comment #3 from mrs at apple dot com 2008-05-07 02:40 --- Adding: +_ZN9__gnu_cxx18stdio_sync_filebufIcSt11char_traitsIcEE4syncEv; +_ZN9__gnu_cxx18stdio_sync_filebufIcSt11char_traitsIcEE5uflowEv; +_ZN9__gnu_cxx18stdio_sync_filebufIcSt11char_traitsIcEE6xsgetnEPci; +_ZN9__gnu_cxx18stdio_sync_filebufIcSt11char_traitsIcEE6xsputnEPKci; + _ZN9__gnu_cxx18stdio_sync_filebufIcSt11char_traitsIcEE7seekoffExSt12_Ios_SeekdirSt13_Ios_Openmode; +_ZN9__gnu_cxx18stdio_sync_filebufIcSt11char_traitsIcEE8overflowEi; +_ZN9__gnu_cxx18stdio_sync_filebufIcSt11char_traitsIcEE9pbackfailEi; +_ZN9__gnu_cxx18stdio_sync_filebufIcSt11char_traitsIcEE9underflowEv; +_ZN9__gnu_cxx18stdio_sync_filebufIcSt11char_traitsIcEEC1EP7__sFILE; +_ZN9__gnu_cxx18stdio_sync_filebufIcSt11char_traitsIcEEC2EP7__sFILE; +_ZN9__gnu_cxx18stdio_sync_filebufIcSt11char_traitsIcEED0Ev; +_ZN9__gnu_cxx18stdio_sync_filebufIcSt11char_traitsIcEED1Ev; +_ZN9__gnu_cxx18stdio_sync_filebufIcSt11char_traitsIcEED2Ev; +_ZN9__gnu_cxx18stdio_sync_filebufIwSt11char_traitsIwEE4syncEv; +_ZN9__gnu_cxx18stdio_sync_filebufIwSt11char_traitsIwEE5uflowEv; +_ZN9__gnu_cxx18stdio_sync_filebufIwSt11char_traitsIwEE6xsgetnEPwi; +_ZN9__gnu_cxx18stdio_sync_filebufIwSt11char_traitsIwEE6xsputnEPKwi; + _ZN9__gnu_cxx18stdio_sync_filebufIwSt11char_traitsIwEE7seekoffExSt12_Ios_SeekdirSt13_Ios_Openmode; +_ZN9__gnu_cxx18stdio_sync_filebufIwSt11char_traitsIwEE8overflowEi; +_ZN9__gnu_cxx18stdio_sync_filebufIwSt11char_traitsIwEE9pbackfailEi; +_ZN9__gnu_cxx18stdio_sync_filebufIwSt11char_traitsIwEE9underflowEv; +_ZN9__gnu_cxx18stdio_sync_filebufIwSt11char_traitsIwEEC1EP7__sFILE; +_ZN9__gnu_cxx18stdio_sync_filebufIwSt11char_traitsIwEEC2EP7__sFILE; +_ZN9__gnu_cxx18stdio_sync_filebufIwSt11char_traitsIwEED0Ev; +_ZN9__gnu_cxx18stdio_sync_filebufIwSt11char_traitsIwEED1Ev; +_ZN9__gnu_cxx18stdio_sync_filebufIwSt11char_traitsIwEED2Ev; back to libstdc++-v3/config/abi/pre/gnu.ver seems to make it better. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36164
[Bug libstdc++/36164] abi breakage, stdio_sync_filebuf routines missing
--- Comment #4 from mrs at apple dot com 2008-05-07 02:58 --- Thinking and supposing are bad substitutes for solid engineering. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36164
[Bug c/36113] New: fix C enumerators
For compatibility with C++ and more reasonable GNU semantics, would we place
make the below program not print 0. Essentially, the type of all the
enumerators should be the underlying type of the enum, not the type that fits
the init.
#include stdio.h
#include stdint.h
#include stdlib.h
#include inttypes.h
int main(void) {
enum {
dummy = (1ULL63),
SomeConstant = 0x1
} MyEnum;
#define MY_MACRO(value) ((value) 60)
printf(MY_MACRO(SomeConstant) == 0x%llx.\n, MY_MACRO(SomeConstant));
return 0;
}
--
Summary: fix C enumerators
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mrs at apple dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36113
[Bug c/36113] fix C enumerators
--- Comment #1 from mrs at apple dot com 2008-05-02 20:16 --- Radar 5881867 -- mrs at apple dot com changed: What|Removed |Added CC||mrs at apple dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36113
[Bug c/36113] fix C enumerators
-- mrs at apple dot com changed: What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36113
[Bug libstdc++/35934] New: abi breakage in search (4.0.0 - 4.2.1)
From http://gcc.gnu.org/ml/libstdc++/2008-04/msg00034.html In gcc-4.0.0 search was instantiated in string-inst.cc: // Used in str::find. template const C* search(const C*, const C*, const C*, const C*, bool(*)(const C, const C)); and if a user compiled their code with -frepo, they can wind up with an external reference to this, that is bound to the shared library for libstdc++ for 4.0.0. Now, fast forward to 4.2.1. It cleverly removes the instantiation for this and the users application no longer works. I think this should reproduce on any target that uses config/abi/pre/gnu.ver. The fix seems to be to add std::search* back to libstdc++-v3/config/abi/pre/gnu.ver and template const C* search(const C*, const C*, const C*, const C*, bool(*)(const C, const C)); back to libstdc++-v3/src/string-inst.cc, to undo the abi break caused by: r101112 | bkoz | 2005-06-16 16:30:55 -0700 (Thu, 16 Jun 2005) | 61 lines 2005-06-17 Jakub Jelinek [EMAIL PROTECTED] * config/abi/ia64-linux-gnu/baseline_symbols.txt: Update. * config/abi/s390x-linux-gnu/baseline_symbols.txt: Update. * config/abi/s390-linux-gnu/baseline_symbols.txt: Update. * config/abi/x86_64-linux-gnu/baseline_symbols.txt: Update. * config/abi/x86_64-linux-gnu/32/baseline_symbols.txt: Update. * config/abi/powerpc-linux-gnu/baseline_symbols.txt: Update. * config/abi/i486-linux-gnu/baseline_symbols.txt: Update. * config/abi/i386-linux-gnu/baseline_symbols.txt: Update. * config/abi/powerpc64-linux-gnu/baseline_symbols.txt: New file. * config/abi/powerpc64-linux-gnu/32/baseline_symbols.txt: New file. 2005-06-16 Jakub Jelinek [EMAIL PROTECTED] * src/compatibility.cc: Include bits/c++config.h first. (_GLIBCXX_SYMVER_COMPATIBILITY): Define if _GLIBCXX_SYMVER and PIC are both defined. * include/bits/char_traits.h (char_traits::eq): Rename only if _GLIBCXX_SYMVER_COMPATIBILITY is defined. 2005-06-16 Jakub Jelinek [EMAIL PROTECTED] * acinclude.m4 ((GLIBCXX_ENABLE_SYMVERS): Rename _GLIBCXX_SIZE_T_IS_INT to _GLIBCXX_SIZE_T_IS_UINT. Define _GLIBCXX_PTRDIFF_T_IS_INT. * configure: Regenerate. * config.h.in: Regenerate. * src/compatibility.cc (istream:ignore(streamsize)): Use _GLIBCXX_PTRDIFF_T_IS_INT instead of _GLIBCXX_SIZE_T_IS_INT. * config/abi/compatibility.h: Rename _GLIBCXX_SIZE_T_IS_INT to _GLIBCXX_SIZE_T_IS_UINT. Use _GLIBCXX_PTRDIFF_T_IS_INT instead for symbols with streamsize arguments. 2005-06-16 Jakub Jelinek [EMAIL PROTECTED] * config/linker-map.gnu: Also export _ZNSt13basic_istreamIwSt11char_traitsIwEE6ignoreE[il][il]. 2005-06-15 Benjamin Kosnik [EMAIL PROTECTED] * configure.ac (libtool_VERSION): To 6:5:0. * configure: Regenerate. * config/linker-map.gnu: Edit. * src/istream.cc: Move istream::ignore(streamsize) specializations... * src/compatibility.cc: ...here. New. * include/bits/char_traits.h (char_traits::eq): Rename when appropriate. * acinclude.m4 (GLIBCXX_ENABLE_SYMVERS): Define _GLIBCXX_SIZE_T_IS_INT. Bump glibcxx_min_gnu_ld_version to 21590. * configure: Regenerate. * acconfig.h: Remove _GLIBCXX_ASM_SYMVER. * config.h.in: Regenerate. * src/Makefile.am (sources): Add compatibility.cc. * src/Makefile.in: Regenerate. * include/Makefile.am (host_headers_noinst): Add compatibility.h. * include/Makefile.in: Regenerate. * testsuite/testsuite_abi.h (symbol): Add data members. * testsuite/testsuite_abi.cc (check_version): Add GLIBCXX_3.4.5. Remove deprecated versions. Do a better job version checking. -- Summary: abi breakage in search (4.0.0 - 4.2.1) Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mrs at apple dot com GCC host triplet: i686-apple-darwin9 GCC target triplet: i686-apple-darwin9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35934
[Bug libstdc++/35935] New: abi breakage in search (4.0.0 - 4.2.1)
From http://gcc.gnu.org/ml/libstdc++/2008-04/msg00034.html In gcc-4.0.0 search was instantiated in string-inst.cc: // Used in str::find. template const C* search(const C*, const C*, const C*, const C*, bool(*)(const C, const C)); and if a user compiled their code with -frepo, they can wind up with an external reference to this, that is bound to the shared library for libstdc++ for 4.0.0. Now, fast forward to 4.2.1. It cleverly removes the instantiation for this and the users application no longer works. I think this should reproduce on any target that uses config/abi/pre/gnu.ver. The fix seems to be to add std::search* back to libstdc++-v3/config/abi/pre/gnu.ver and template const C* search(const C*, const C*, const C*, const C*, bool(*)(const C, const C)); back to libstdc++-v3/src/string-inst.cc, to undo the abi break caused by: r101112 | bkoz | 2005-06-16 16:30:55 -0700 (Thu, 16 Jun 2005) | 61 lines 2005-06-17 Jakub Jelinek [EMAIL PROTECTED] * config/abi/ia64-linux-gnu/baseline_symbols.txt: Update. * config/abi/s390x-linux-gnu/baseline_symbols.txt: Update. * config/abi/s390-linux-gnu/baseline_symbols.txt: Update. * config/abi/x86_64-linux-gnu/baseline_symbols.txt: Update. * config/abi/x86_64-linux-gnu/32/baseline_symbols.txt: Update. * config/abi/powerpc-linux-gnu/baseline_symbols.txt: Update. * config/abi/i486-linux-gnu/baseline_symbols.txt: Update. * config/abi/i386-linux-gnu/baseline_symbols.txt: Update. * config/abi/powerpc64-linux-gnu/baseline_symbols.txt: New file. * config/abi/powerpc64-linux-gnu/32/baseline_symbols.txt: New file. 2005-06-16 Jakub Jelinek [EMAIL PROTECTED] * src/compatibility.cc: Include bits/c++config.h first. (_GLIBCXX_SYMVER_COMPATIBILITY): Define if _GLIBCXX_SYMVER and PIC are both defined. * include/bits/char_traits.h (char_traits::eq): Rename only if _GLIBCXX_SYMVER_COMPATIBILITY is defined. 2005-06-16 Jakub Jelinek [EMAIL PROTECTED] * acinclude.m4 ((GLIBCXX_ENABLE_SYMVERS): Rename _GLIBCXX_SIZE_T_IS_INT to _GLIBCXX_SIZE_T_IS_UINT. Define _GLIBCXX_PTRDIFF_T_IS_INT. * configure: Regenerate. * config.h.in: Regenerate. * src/compatibility.cc (istream:ignore(streamsize)): Use _GLIBCXX_PTRDIFF_T_IS_INT instead of _GLIBCXX_SIZE_T_IS_INT. * config/abi/compatibility.h: Rename _GLIBCXX_SIZE_T_IS_INT to _GLIBCXX_SIZE_T_IS_UINT. Use _GLIBCXX_PTRDIFF_T_IS_INT instead for symbols with streamsize arguments. 2005-06-16 Jakub Jelinek [EMAIL PROTECTED] * config/linker-map.gnu: Also export _ZNSt13basic_istreamIwSt11char_traitsIwEE6ignoreE[il][il]. 2005-06-15 Benjamin Kosnik [EMAIL PROTECTED] * configure.ac (libtool_VERSION): To 6:5:0. * configure: Regenerate. * config/linker-map.gnu: Edit. * src/istream.cc: Move istream::ignore(streamsize) specializations... * src/compatibility.cc: ...here. New. * include/bits/char_traits.h (char_traits::eq): Rename when appropriate. * acinclude.m4 (GLIBCXX_ENABLE_SYMVERS): Define _GLIBCXX_SIZE_T_IS_INT. Bump glibcxx_min_gnu_ld_version to 21590. * configure: Regenerate. * acconfig.h: Remove _GLIBCXX_ASM_SYMVER. * config.h.in: Regenerate. * src/Makefile.am (sources): Add compatibility.cc. * src/Makefile.in: Regenerate. * include/Makefile.am (host_headers_noinst): Add compatibility.h. * include/Makefile.in: Regenerate. * testsuite/testsuite_abi.h (symbol): Add data members. * testsuite/testsuite_abi.cc (check_version): Add GLIBCXX_3.4.5. Remove deprecated versions. Do a better job version checking. -- Summary: abi breakage in search (4.0.0 - 4.2.1) Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mrs at apple dot com GCC host triplet: i686-apple-darwin9 GCC target triplet: i686-apple-darwin9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35935
[Bug c++/35688] New: template visibility botch
/* { dg-require-visibility } */
/* { dg-options -fvisibility=hidden } */
/* { dg-final { scan-hidden __ZN1s6vectorI1AEC1Ev } } */
/* { dg-final { scan-hidden __ZN1s3fooI1AEEvT_ } } */
/* Radar 5813435 */
namespace s __attribute__((visibility(default))) {
template class T
class vector {
public:
vector() { }
};
template class T
void foo(T t) {
}
}
class A {
public:
A() { }
};
s::vectorA v;
int main() {
A a;
s::foo(a);
}
should pass (if I got the spelling for the symbols correct wrt leading _).
radr://5813435
--
Summary: template visibility botch
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mrs at apple dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35688
[Bug c++/35640] New: invalid access to protected base class
class A {
};
class B: protected A {
};
class C: protected A {
public:
C(B b);
};
C::C(B b)
: A(b)
{
}
int main() {
B b;
C c(b);
return 0;
}
should give an error for : A(b), the conversion from B to A is invalid as A is
protected.
This still fails on 4.4.0 20080317
radr://5805511
--
Summary: invalid access to protected base class
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mrs at apple dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35640
[Bug debug/35462] New: anonymous struct in c++ has wrong name in -gdwarf-2
typedef struct {
int x;
} mystruct;
mystruct m;
should either have no name or a name of mystruct in C++. I see:
.ascii anonymous struct\0 ; DW_AT_name
and
.ascii $_0\0 ; external name
This works as expected in C.
Still fails in 20080308. I think this is target independent.
--
Summary: anonymous struct in c++ has wrong name in -gdwarf-2
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mrs at apple dot com
GCC target triplet: powerpc-apple-darwin9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35462
[Bug debug/35463] New: typedef missing in debug information with -gdwarf-2 for c++
typedef struct {
int x;
} mystruct;
mystruct m;
is missing any debug information for mystruct. If one compiles as C, mystruct
is present.
Still broken in 20080308 compiler. Should be target independent.
--
Summary: typedef missing in debug information with -gdwarf-2 for
c++
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mrs at apple dot com
GCC target triplet: powerpc-apple-darwin9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35463
[Bug debug/35462] anonymous struct in c++ has wrong name in -gdwarf-2
--- Comment #1 from mrs at apple dot com 2008-03-04 20:14 --- radr://5070293 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35462
[Bug debug/35463] typedef missing in debug information with -gdwarf-2 for c++
--- Comment #1 from mrs at apple dot com 2008-03-04 20:15 --- radr://5070293 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35463
[Bug c/35449] New: extended asm documentation wrong
In doc/extend.texi we have:
int foo ()
@{
int x = 42;
int *y = x;
int result;
asm (magic stuff accessing an 'int' pointed to by '%1'
=d (r) : a (y), m (*y));
return result;
@}
two problems, r != result. Second problem, there should be a : before the
output constraint.
The current docs on the web site are unchanged.
--
Summary: extended asm documentation wrong
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mrs at apple dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35449
[Bug c++/35450] New: ice on valid template
#include iostream
struct test_a{ void load(){} };
struct test_b{ };
template template typename class Concept, typename Model
struct models
{
typedef char (yes)[2];
typedef char no;
template template typename class C, typename M, typename CM::type
P = 0
struct hint
{ };
template typename M
static yes test(M*, hintConcept, M * = 0);
static no test(...);
static const bool value = (sizeof(test((Model*)0))==sizeof(yes));
};
template typename Class, typename Type
struct member
{
typedef Type Class::* type;
};
template typename Model
struct loadable
{ };
int main()
{
std::cout modelsloadable, test_a::value std::endl;
}
# with 4.2.1:
$ g++-4.2 t.cc
t.cc: In instantiation of modelsloadable, test_a:
t.cc:37: instantiated from here
t.cc:14: internal compiler error: Bus error
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://developer.apple.com/bugreporter for instructions.
And the same with a compiler from today as well:
$ /Volumes/pool1/mrs/packages/gcc-20080308/bin/g++ t.cc
t.cc: In instantiation of modelsloadable, test_a:
t.cc:37: instantiated from here
t.cc:14: internal compiler error: Bus error
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
This works on comeau.
radr://5772368
--
Summary: ice on valid template
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mrs at apple dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35450
[Bug c++/35405] [4.2/4.3/4.4 Regression] Internal compiler error
--- Comment #3 from mrs at apple dot com 2008-03-04 01:19 --- My bug is related to this, but mine is an ice on valid. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35405
[Bug target/10901] non-local goto's don't work on powerpc-darwin
--- Comment #18 from mrs at apple dot com 2008-02-21 19:48 --- Nope. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10901
[Bug bootstrap/32009] [4.3/4.4 Regression] building gcc4-4.3/4.4.0-20070518 failed on OSX 10.3.9
--- Comment #28 from mrs at apple dot com 2008-02-20 15:44 --- Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32009
[Bug c/35198] New: missed evaluation of VM array type
void* a(void* x) {return (int (*)[10][printf(hi\n)])x;}
int main() { int i; a(i); }
should print hi. This was still broken in 4.3 in July, 2007.
--
Summary: missed evaluation of VM array type
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mrs at apple dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35198
[Bug target/34000] GCC pedwarns about use of static inline functions from system headers in extern inline functions
--- Comment #14 from mrs at apple dot com 2008-02-13 20:49 --- I think we should do this; further, I think we should add pedantic to it as well. Only people that want to be hurt by the standard should be. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34000
[Bug target/34000] GCC pedwarns about use of static inline functions from system headers in extern inline functions
--- Comment #11 from mrs at apple dot com 2008-02-13 02:59 ---
Ok, how about:
#ifdef __GNUC_STDC_INLINE__
#define __EXTERN_INLINE __inline __attribute__((always_inline))
#else
#define __EXTERN_INLINE extern __inline __attribute__((always_inline))
#endif
__EXTERN_INLINE void foo() ;
__EXTERN_INLINE void foo() {
__asm (nop);
}
void bar1() {
foo();
}
I think that will work... See any gotchas (other than linking when it can't be
inlined)?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34000
[Bug target/34000] GCC pedwarns about use of static inline functions from system headers in extern inline functions
--- Comment #9 from mrs at apple dot com 2008-02-12 22:04 --- Ah, I see now, you're right, that doesn't work. :-( -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34000
[Bug libstdc++/35173] New: trivial long - int implicit conversions
; static const category time = 1L 3; static const category monetary = 1L 4; static const category messages = 1L 5; bits/ios_base.h: _S_boolalpha = 1L 0, _S_dec= 1L 1, _S_fixed = 1L 2, _S_hex= 1L 3, _S_internal = 1L 4, _S_left = 1L 5, _S_oct= 1L 6, _S_right = 1L 7, _S_scientific = 1L 8, _S_showbase = 1L 9, _S_showpoint = 1L 10, _S_showpos= 1L 11, _S_skipws = 1L 12, _S_unitbuf= 1L 13, _S_uppercase = 1L 14, _S_app= 1L 0, _S_ate= 1L 1, _S_bin= 1L 2, _S_in = 1L 3, _S_out= 1L 4, _S_trunc = 1L 5, _S_ios_openmode_end = 1L 16 _S_badbit = 1L 0, _S_eofbit = 1L 1, _S_failbit= 1L 2, _S_ios_iostate_end = 1L 16 _S_ios_seekdir_end = 1L 16 -- Summary: trivial long - int implicit conversions Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: trivial Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mrs at apple dot com GCC build triplet: i686-apple-darwin9 GCC host triplet: i686-apple-darwin9 GCC target triplet: i686-apple-darwin9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35173
[Bug target/34000] GCC pedwarns about use of static inline functions from system headers in extern inline functions
--- Comment #7 from mrs at apple dot com 2008-02-12 18:01 --- Testcase for comment #6? I believe we tested every case and it works fine. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34000
[Bug c/34000] GCC pedwarns about use of static inline functions from system headers in extern inline functions
--- Comment #4 from mrs at apple dot com 2008-02-12 01:28 --- We fixed the mmintrin.h issues by using inline when __GNUC_STDC_INLINE__, and static inline otherwise in our tree. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34000
[Bug objc++/34193] [4.3 regression] FAIL: obj-c++.dg/gnu-runtime-2.mm (test for excess errors)
--- Comment #2 from mrs at apple dot com 2008-02-08 03:10 --- It should be const char**argv. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34193
[Bug libstdc++/35081] New: abi breakage in typeinfo (4.0.1 - 4.2.1)
is not supported.
+type_info operator=(const type_info);
+type_info(const type_info);
};
/**
@@ -169,9 +167,11 @@
{
public:
bad_cast() throw() { }
+
// This declaration is not useless:
// http://gcc.gnu.org/onlinedocs/gcc-3.0.2/gcc_6.html#SEC118
virtual ~bad_cast() throw();
+
// See comment in eh_exception.cc.
virtual const char* what() const throw();
};
@@ -181,9 +181,11 @@
{
public:
bad_typeid () throw() { }
+
// This declaration is not useless:
// http://gcc.gnu.org/onlinedocs/gcc-3.0.2/gcc_6.html#SEC118
virtual ~bad_typeid() throw();
+
// See comment in eh_exception.cc.
virtual const char* what() const throw();
};
?
--
Summary: abi breakage in typeinfo (4.0.1 - 4.2.1)
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: blocker
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mrs at apple dot com
GCC build triplet: *-apple-darwin*
GCC host triplet: *-apple-darwin*
GCC target triplet: *-apple-darwin*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35081
[Bug c/34819] New: incomplete enum's assert
$ cat t.c
enum e ve;
void f0 (int i)
{
ve + i;
}
$ gcc -c t.c
enum.c: In function f0:
enum.c:6: internal compiler error: in create_tmp_var, at gimplify.c:368
Please submit a full bug report,
with preprocessed source if appropriate.
Works in c++:
/tmp/t.c:1: error: use of enum e without previous declaration
/tmp/t.c:1: error: invalid type in declaration before ; token
Also fails in 4.3.0 20070713.
--
Summary: incomplete enum's assert
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mrs at apple dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34819
[Bug c++/34783] New: unwanted limited range warning in template code
It seems silly for a project to get warnings in the below case. It seems silly
to require that one specialize just to avoid the warning.
$ cat t.cc
void bar();
template class T
void foo(T t) {
if (t 257) bar();
}
void bee() {
foo(1);
foo(char(1));
}
$ g++ t.cc -c
t.cc: In function void foo(T) [with T = char]:
t.cc:9: instantiated from here
t.cc:4: warning: comparison is always true due to limited range of data type
--
Summary: unwanted limited range warning in template code
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mrs at apple dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34783
[Bug c++/34783] unwanted limited range warning in template code
--- Comment #2 from mrs at apple dot com 2008-01-14 20:08 --- No, that bug report has a hack around, not a fix. A fix would make it work by default out of the box. A fix would avoid these for templated types and leave them for non-templated types. -- mrs at apple dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34783
[Bug c++/34783] unwanted limited range warning in template code
--- Comment #4 from mrs at apple dot com 2008-01-14 23:21 --- Ah, I thought someone just hadn't gotten around to moving the state to fixed, sorry. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34783
[Bug middle-end/34516] New: trivial sentinels
Please implement http://gcc.gnu.org/ml/gcc-patches/2006-06/msg01047.html
This is useful because previously, gcc-4.0.1 didn't warn about this case:
void f(void *last, ...) __attribute__((sentinel(0,1)));
main() {
f((void*)0);
}
but gcc-4.2 does. We have APIs that make use of the null being in the first
argument and they used the sentinel check, but now clients get lots of warnings
due to the `new' behavior.
We've added this to our compiler, just 49 lines...
radr://5631180
--
Summary: trivial sentinels
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mrs at apple dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34516
[Bug bootstrap/32009] [4.3 Regression] building gcc4-4.3.0-20070518 failed on OSX 10.3.9
--- Comment #22 from mrs at apple dot com 2007-12-17 04:10 --- :-( -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32009
[Bug middle-end/17736] Optimization for global initialization with trivial constructors
--- Comment #3 from mrs at apple dot com 2007-12-06 23:46 --- radr://2961456 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17736
[Bug fortran/34136] [regression against g77] Add entry point and symbol for linker
--- Comment #8 from mrs at apple dot com 2007-11-26 20:58 --- Apparently there are two distinct ways to make this work, either, output a reference to bdtest, or ensure that the linker tries to resolve commons from libraries. Linux uses the later approach. To be portable, gfortran needs to generate the reference to bdtest on those platforms that need it. Darwin would be one such system. I've filed radr://5613343 need to search for definitions for common symbols so we won't need such help at some point. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34136
[Bug fortran/34136] [regression against g77] Add entry point and symbol for linker
--- Comment #12 from mrs at apple dot com 2007-11-27 02:42 --- Yes, the second set contains: _U0.457: .long _bdtest_ which is the part the makes the whole thing work on systems like darwin. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34136
[Bug c/34010] New: ppc64 bad stdargs codegen for zero sized objects
The fix for http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24306 breaks -m64 struct-layout-1.c. It breaks the abi of every target, which is wrong. On ppc -m64, it results in a self inconsistent abi. This correct fix would be to modify ix86_function_arg_boundary function to give PARM_BOUNDARY for zero sized objects. -- Summary: ppc64 bad stdargs codegen for zero sized objects Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: critical Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mrs at apple dot com GCC target triplet: powerpc-apple-darwin9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34010
[Bug middle-end/24306] [4.0 Regression] va_arg gets confused when skipping over certain zero-sized types with -msse
--- Comment #12 from mrs at apple dot com 2007-11-07 01:06 --- This patch is wrong. See http://gcc.gnu.org/PR34010 for details. -- mrs at apple dot com changed: What|Removed |Added CC||mrs at apple dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24306
[Bug target/32961] GCC 4.2 has different requirements for x86 shift xmm intrinsics
--- Comment #2 from mrs at apple dot com 2007-10-16 19:29 --- I can confirm the bug and that Intel's documentation does not have a immediate restriction on any of the epi functions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32961
[Bug rtl-optimization/32466] illegal loop store motion of bitfield
--- Comment #2 from mrs at apple dot com 2007-06-27 19:18 --- Radar 5276895 -- mrs at apple dot com changed: What|Removed |Added CC||mrs at apple dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32466
[Bug c/4076] -Wunused doesn't warn about static function only called by itself.
--- Comment #20 from mrs at apple dot com 2007-06-19 23:36 --- The patch was approved today on the gcc-patches list. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4076
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #122 from mrs at apple dot com 2007-05-22 20:41 --- When the standard was originally written, I do think we may have missed out on some finer points of the C object model, mainly to do with restrictions on what one is not permitted to do stemming from the declared type. The intent was to very closely match the C object model, but formalize it better and add just enough to do subtypes and dynamic types and so on. I think it is reasonable to leave it as strict as C is for C style code so that it can be optimized well. I think it is reasonable to push the tighening language into the standard, as that is what we meant and our wording was meant to be as tight as C. The effective type of an object for an access to its stored value is the declared type of the object, if any. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug c++/31903] New: unwanted anonymous namespacing linkage
It appears that 4.2 isn't making anonymous namespace variables unique (it's
also making them global). This is preventing LLVM from compiling with the 4.2
compiler.
$ cat foo.cpp
#include typeinfo
namespace {
class foo {
virtual void bar();
};
}
void foo::bar() {}
#ifdef FOO
const std::type_info X = typeid(foo);
#else
const std::type_info Y = typeid(foo);
#endif
extern const std::type_info X;
#ifndef FOO
int main() {}
#endif
$ g++-4.2 foo.cpp -c -o a.o
$ g++-4.2 foo.cpp -c -o b.o -DFOO
$ g++-4.2 a.o b.o
ld64-73.6 failed: duplicate symbol typeinfo for (anonymous namespace)::fooin
b.o and a.o
--
Summary: unwanted anonymous namespacing linkage
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mrs at apple dot com
GCC target triplet: i686-apple-darwin9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31903
[Bug target/31903] unwanted anonymous namespacing linkage
--- Comment #3 from mrs at apple dot com 2007-05-11 22:44 --- I think this is a bug on Linux as well, though, I suspect it don't fail to build, but rather I think it will compare the two typeinfo objects as equal even though they are unrelated to each other. -- mrs at apple dot com changed: What|Removed |Added CC||mrs at apple dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31903
[Bug target/31903] unwanted anonymous namespacing linkage
--- Comment #5 from mrs at apple dot com 2007-05-12 00:00 --- Odd, I see: X: .long _ZTIN12_GLOBAL__N_13fooE .weak _ZTSN12_GLOBAL__N_13fooE .section.gnu.linkonce.r._ZTSN12_GLOBAL__N_13fooE,a,@progbits .type _ZTSN12_GLOBAL__N_13fooE, @object .size _ZTSN12_GLOBAL__N_13fooE, 21 _ZTSN12_GLOBAL__N_13fooE: .string N12_GLOBAL__N_13fooE on my darwin-i386-unknown-linux-gnu compiler? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31903
[Bug libstdc++/31906] -Xcompiler is inserted after -Xlinker when building libstdc++
--- Comment #2 from mrs at apple dot com 2007-05-12 05:51 --- Can you work around it with the -Xlinker,-arg1,val1,-arg2,val2 syntax? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31906
[Bug target/26792] [4.2 Regression] need to use autoconf when using newly-added libgcc functions
--- Comment #37 from mrs at apple dot com 2007-04-25 01:42 --- libgcc_s.10.5.dylib now includes __Unwind_GetIPInfo on mainline and in 4.2... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26792
[Bug target/26792] [4.2 Regression] need to use autoconf when using newly-added libgcc functions
--- Comment #38 from mrs at apple dot com 2007-04-25 01:56 --- I think a non-working --with-system-libunwind corner case on darwin is a P4 at best? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26792
[Bug tree-optimization/29585] [4.2 Regression] tree check: expected ssa_name, have var_decl in is_old_name, at tree-into-ssa.c:558
--- Comment #17 from mrs at apple dot com 2007-04-13 03:09 --- The followup problem has now been fixed in 4.2. -- mrs at apple dot com changed: What|Removed |Added CC|mrs at apple dot com| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29585
[Bug c++/31513] [4.2/4.3 Regression] Miscompilation of Function Passing Bit Field Value to Function
--- Comment #4 from mrs at apple dot com 2007-04-09 20:25 --- radr://5076058 -- mrs at apple dot com changed: What|Removed |Added CC||mrs at apple dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31513
