[Bug middle-end/25140] aliases, including weakref, break alias analysis
--- Comment #7 from geoffk at gcc dot gnu dot org 2009-09-26 11:51 --- I looked up 'weakref' in the GCC documentation because I'd forgotten exactly what it was supposed to do, and noticed that it's actually documented as applying only to functions. So, maybe we could just say that this attribute is only allowed for functions, and produce an error on line 3. Alexandre's original mail proposing the extension, http://gcc.gnu.org/ml/gcc/2005-10/msg00235.html, suggests the attribute for both variables and functions, but the explanation of why you'd want this feature only talks about functions. The weakref documentation does specifically talk about the case where the function is referenced both via the weakref and directly through the original symbol, and I think the typical use cases actually do this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25140
[Bug middle-end/25140] aliases, including weakref, break alias analysis
--- Comment #9 from geoffk at gcc dot gnu dot org 2009-09-26 12:15 --- (In reply to comment #8) Hm, I only can see references to symbol not to either function or variable declaration in the documentation. Can you cite the part that makes you think it restricts the use to functions? It's documented in the section on function attributes, but not listed in the section on variable attributes. Compare 'deprecated' or 'weak', which are listed in both places. It does say 'symbol' in referring to the target, but I doubt it's really supposed to mean that you can declare a function as a weakref to a variable (and that couldn't work anyway on most platforms, the variable will be in a non-executable region of memory). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25140
[Bug target/37033] [4.4 Regression] Revision 138733 breaks -g vs -g0 for PCH
--- Comment #10 from geoffk at gcc dot gnu dot org 2008-11-28 07:34 --- Yes, the test is still valid. It is reporting a real problem. I will suggest a change to __GCC_HAVE_DWARF2_CFI_ASM that permits the testcase to continue working. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37033
[Bug c++/7221] wrong linkage of typedef-named classes
-- geoffk at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|geoffk at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7221
[Bug pch/9471] #pragma system_header vs. precompiled headers
-- geoffk at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|geoffk at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9471
[Bug pch/11654] incorrect stabs when using pre-compiled headers
-- geoffk at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|geoffk at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11654
[Bug target/37808] [4.4 Regression]: Revision 141067 breaks Linux/x86
--- Comment #6 from geoffk at gcc dot gnu dot org 2008-10-12 19:44 --- Confirmed, the regression tester sees it too. -- geoffk at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-10-12 19:44:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37808
[Bug middle-end/34621] [4.3 Regression] gcc.c-torture/execute/va-arg-25.c:32: internal compiler error: in expand_call, at calls.c:2785
--- Comment #6 from geoffk at gcc dot gnu dot org 2008-01-21 16:43 --- I suspect that the patch changed bad code generation into a crash, which is not a regression... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34621
[Bug c/34735] C99 6.7.4/3 is not diagnose
--- Comment #3 from geoffk at gcc dot gnu dot org 2008-01-14 00:55 --- The quoted paragraph does not apply to the first code example, because an inline definition is defined in paragraph 6 as: If all of the #64257;le scope declarations for a function in a translation unit include the inline function speci#64257;er without extern, then the de#64257;nition in that translation unit is an inline de#64257;nition. In this case, one of the declarations does not include the inline function specifier, so it's not an inline definition. I am unclear on how the standard is supposed to apply to the second example, but IMO we should give the warning anyway. -- geoffk at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34735
[Bug c++/33871] [4.3 Regression] typeinfo name referenced in ... defined in discarded section
--- Comment #14 from geoffk at gcc dot gnu dot org 2007-10-30 03:44 --- I don't fully understand the linker error message. It seems to me that if there's a reference to the typeinfo name then that just means the linker shouldn't be discarding it. The original problem was encountered on Darwin and so that's where the testcase would be expected to fail. Should the typeinfo for an anonymous namespace class be local if it inherits from a class that is outside the anonymous namespace? Yes. If that is the case, what should typeid(reference to base of anonymous class instance) in another module return? The same thing it does now, which I believe is the typeinfo of the base class. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33871
[Bug target/32961] [4.2/4.3 Regression]: Gcc has different requirements for x86 shift xmm intrinsics
--- Comment #6 from geoffk at gcc dot gnu dot org 2007-10-17 21:28 --- Shouldn't you have to use _mm_sll_epi32(s, _mm_cvtsi32_si128 (c)) instead? Or does the 'i' in 'slli' stand for 'int' not 'immediate'? I thought that the list of _mm_sl* intrinsics in the assembly reference guide (Intel doc 253667, http://www.intel.com/design/processor/manuals/253667.pdf, page 4-172 and 4-173) were supposed to match up one-for-one with the instructions forms (on page 4-170). The assembly reference also says that _mm_slli_epi32 generates a single instruction, as it is listed in table C-1. On the other hand, icc's documentation, http://download.intel.com/support/performancetools/c/linux/v9/intref_cls.pdf, on page 137, says for _mm_slli_si128, 'imm must be an immediate', but doesn't say that for _mm_slli_epi32. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32961
[Bug target/32961] [4.2/4.3 Regression]: Gcc has different requirements for x86 shift xmm intrinsics
--- Comment #8 from geoffk at gcc dot gnu dot org 2007-10-18 04:53 --- (In reply to comment #7) Icc generates: 0: 66 0f 6e cf movd %edi,%xmm1 4: 66 0f f2 c1 pslld %xmm1,%xmm0 Right, that's what icc's documentation would suggest. But that documentation seems inconsistent with the assembly reference guide. It may be that the assembly reference guide is the one that's wrong, or that icc intentionally extends it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32961
[Bug c++/21755] Warning from function template in system header
--- Comment #2 from geoffk at gcc dot gnu dot org 2007-07-13 22:56 --- I'm not even sure this is a bug; maybe it's a clue that you should have instantiated baz() with an unsigned type. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21755
[Bug bootstrap/32617] explow.c references DECL_ALIGN of a FUNCTION_DECL
--- Comment #2 from geoffk at gcc dot gnu dot org 2007-07-10 23:09 --- Subject: Bug 32617 Author: geoffk Date: Tue Jul 10 23:08:52 2007 New Revision: 126529 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126529 Log: 2007-07-09 Geoffrey Keating [EMAIL PROTECTED] PR 32617 * c-common.c (c_alignof_expr): Look at DECL_ALIGN of FUNCTION_DECLs. (handle_aligned_attribute): Allow use on FUNCTION_DECLs. * varasm.c (assemble_start_function): Honor DECL_ALIGN for FUNCTION_DECLs. Don't use align_functions_log if DECL_USER_ALIGN. * print-tree.c (print_node): Print DECL_ALIGN and DECL_USER_ALIGN even for FUNCTION_DECLs. * c-decl.c (merge_decls): Propagate DECL_ALIGN even for FUNCTION_DECLs. * tree.h (DECL_ALIGN): Update for new location of 'align'. (DECL_FUNCTION_CODE): Update for new location and name of 'function_code'. (DECL_OFFSET_ALIGN): Update for new location of 'off_align'. (struct tree_decl_common): Move 'align' and 'off_align' out of union, ensure they're still on a 32-bit boundary. Remove other fields in union 'u1'. (struct tree_function_decl): Add field 'function_code' replacing 'u1.f' in tree_decl_common. * tree.c (build_decl_stat): Set initial value of DECL_ALIGN. * doc/extend.texi (Function Attributes): Add 'aligned' attribute. (Variable Attributes): Cross-reference 'aligned' attribute to Function Attributes. * flags.h (force_align_functions_log): Delete. * toplev.c (force_align_functions_log): Delete. Index: gcc/testsuite/ChangeLog 2007-07-09 Geoffrey Keating [EMAIL PROTECTED] PR 32617 * gcc.c-torture/execute/align-3.c: New. Index: gcc/java/ChangeLog 2007-07-09 Geoffrey Keating [EMAIL PROTECTED] PR 32617 * lang.c (java_init): Remove setting of force_align_functions_log. * class.c (add_method_1): Set DECL_ALIGN of non-static method to cope with ptrmemfunc_vbit_in_pfn. Index: gcc/cp/ChangeLog 2007-07-09 Geoffrey Keating [EMAIL PROTECTED] PR 32617 * decl.c (cxx_init_decl_processing): Don't set force_align_functions_log. (grokfndecl): Honour ptrmemfunc_vbit_in_pfn. * typeck.c (cxx_alignof_expr): When alignof is used on a plain FUNCTION_DECL, return its alignment. Added: trunk/gcc/testsuite/gcc.c-torture/execute/align-3.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-common.c trunk/gcc/c-decl.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/cp/typeck.c trunk/gcc/doc/extend.texi trunk/gcc/flags.h trunk/gcc/java/ChangeLog trunk/gcc/java/class.c trunk/gcc/java/lang.c trunk/gcc/print-tree.c trunk/gcc/testsuite/ChangeLog trunk/gcc/toplev.c trunk/gcc/tree.c trunk/gcc/tree.h trunk/gcc/varasm.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32617
[Bug c/32692] Inconsistent warning/error with static and non-static declarations
--- Comment #4 from geoffk at gcc dot gnu dot org 2007-07-09 19:34 --- 'external linkage' is not the same thing as 'the declaration contains the keyword extern'. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32692
[Bug bootstrap/32617] New: explow.c references DECL_ALIGN of a FUNCTION_DECL
In explow.c, there's this code:
if (GET_CODE (x) == SYMBOL_REF)
{
align = BITS_PER_UNIT;
if (SYMBOL_REF_DECL (x) DECL_P (SYMBOL_REF_DECL (x)))
align = DECL_ALIGN (SYMBOL_REF_DECL (x));
}
If SYMBOL_REF_DECL(x) is a FUNCTION_DECL, DECL_ALIGN() does not have valid
data, so this code will cause the alignment of a function's MEM to be set to
random data.
--
Summary: explow.c references DECL_ALIGN of a FUNCTION_DECL
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: geoffk at gcc dot gnu dot org
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32617
[Bug bootstrap/32617] explow.c references DECL_ALIGN of a FUNCTION_DECL
-- geoffk at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |geoffk at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-07-03 21:05:56 |2007-07-03 21:53:07 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32617
[Bug middle-end/26061] error and warning count
--- Comment #12 from geoffk at gcc dot gnu dot org 2007-07-03 00:45 --- [Here's what I sent to gcc-patches as a review of this patch:] Doing this will certainly break many tools which parse the output of GCC, especially in the case of a successful compilation which produced some warnings. I think, though, that it would be safe to produce one extra notice in the case of a compilation which produced errors, saying how many errors were output; that would help in the case where the last few hundred messages from GCC are warnings and the user wonders why their build failed. It should be combined with the message we already have about 'treating warnings about errors because of -Werror'. I'm hard-pressed to think of a reason why, if this is implemented, you would want to be able to switch it off, so I see no reason to have a flag (unless someone else thinks of a reason). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26061
[Bug target/30058] [4.3 regression] bootstrap broken on i386-unknown-netbsdelf2.0.2
-- geoffk at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|geoffk at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30058
[Bug tree-optimization/20216] [4.0 Regression] Simple loop runs out of stack at -O1
--- Comment #15 from geoffk at gcc dot gnu dot org 2007-06-26 01:18 --- Subject: Bug 20216 Author: geoffk Date: Tue Jun 26 01:18:08 2007 New Revision: 126014 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126014 Log: PR 20216 * gcc.dg/pr20216.c: New. Added: trunk/gcc/testsuite/gcc.dg/pr20216.c Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20216
[Bug target/32347] ICE on gcc/testsuite/gcc-dg/vmx/ops.c
--- Comment #15 from geoffk at gcc dot gnu dot org 2007-06-21 18:31 --- Doesn't fail on powerpc-darwin (nor apparently on powerpc-aix). -- geoffk at gcc dot gnu dot org changed: What|Removed |Added CC|geoffk at geoffk dot org| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32347
[Bug debug/32444] New: missing debug information for structure components
Given the following short program,
struct pt
{
int x, y;
};
struct pt sum(struct pt *p)
{
struct pt tmp = { 0, 0 };
int i;
for (i = 0; i 100; i++)
{
tmp.x += p[i].x;
tmp.y += p[i].y;
}
return tmp;
}
on powerpc-darwin, built with -O2, I see that the main loop is storing tmp.x in
r8 and tmp.y in r10 (or possibly the other way around). Yet, the debug
information contains no location information for 'tmp'. A similar thing
happens on i386-darwin where the values are stored in eax and edx.
Also, on i386-darwin, 'i' is also not present in the debug information,
although it is in %ecx.
L2:
addl-8(%esi,%ecx,8), %eax
addl-4(%esi,%ecx,8), %edx
addl$1, %ecx
cmpl$101, %ecx
jne L2
--
Summary: missing debug information for structure components
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: geoffk at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32444
[Bug debug/32444] missing debug information for structure components
--- Comment #1 from geoffk at gcc dot gnu dot org 2007-06-21 01:08 --- Happens even with -O1. One of the causes is SRA, but there's more... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32444
[Bug debug/32444] missing debug information for structure components
--- Comment #2 from geoffk at gcc dot gnu dot org 2007-06-21 01:13 --- The problem with 'i' is ivopts. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32444
[Bug debug/32445] New: no debug information for loop counters
In this short program, on i386-darwin (probably all i386),
struct pt
{
int x, y;
};
struct pt sum(struct pt *p)
{
struct pt tmp = { 0, 0 };
int i;
for (i = 0; i 100; i++)
{
tmp.x += p[i].x;
tmp.y += p[i].y;
}
return tmp;
}
when compiled with -O1 -g, there is no location information for 'i', despite it
being in %ecx. This is because ivopts has replaced 'i' with a variable with
exactly the same value but a different name, breaking the debug information.
--
Summary: no debug information for loop counters
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: geoffk at gcc dot gnu dot org
GCC target triplet: i386-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32445
[Bug debug/32444] missing debug information for structure components
--- Comment #3 from geoffk at gcc dot gnu dot org 2007-06-21 01:24 --- I split out the problem with 'i' to PR 32445. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32444
[Bug libgcj/31093] Multicast PromiscuousTraffic
--- Comment #3 from geoffk at gcc dot gnu dot org 2007-06-14 20:56 --- Subject: Bug 31093 Author: geoffk Date: Thu Jun 14 20:56:25 2007 New Revision: 125721 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125721 Log: PR 31093 * decl2.c (determine_visibility): Remove duplicate code for handling type info. Added: trunk/gcc/testsuite/g++.dg/ext/visibility/anon4.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl2.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31093
[Bug c++/31903] [4.3 Regression] typeinfo of classes in anon namespace isn't being marked static
--- Comment #11 from geoffk at gcc dot gnu dot org 2007-06-14 21:11 --- Should be fixed with this change: r125721 | geoffk | 2007-06-14 13:56:25 -0700 (Thu, 14 Jun 2007) | 4 lines PR 31093 * decl2.c (determine_visibility): Remove duplicate code for handling type info. -- geoffk at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31903
[Bug c++/31903] [4.3 Regression] typeinfo of classes in anon namespace isn't being marked static
--- Comment #10 from geoffk at gcc dot gnu dot org 2007-06-13 22:31 --- I think this problem is limited to just typeinfo. -- geoffk at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |geoffk at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-05-12 14:30:49 |2007-06-13 22:31:14 date|| Summary|[4.3 Regression] unwanted |[4.3 Regression] typeinfo of |anonymous namespacing |classes in anon namespace |linkage |isn't being marked static http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31903
[Bug bootstrap/32161] New: stage1 libgcc is being built unoptimized
The stage1 libgcc.a and crt files are being built with -O0. This means that the stage2 cc1 is using unoptimized libgcc.a, but the stage3 cc1 is using optimized libgcc.a, which is causing them to be different, which is one of a number of causes for Comparing stages 2 and 3 warning: ./cc1-checksum.o differs warning: ./cc1obj-checksum.o differs warning: ./cc1plus-checksum.o differs on Darwin. I suspect this is related to PR 32009 but am not sure they're the same bug. -- Summary: stage1 libgcc is being built unoptimized Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: geoffk at gcc dot gnu dot org GCC target triplet: *-*-darwin* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32161
[Bug c++/31903] [4.3 Regression] unwanted anonymous namespacing linkage
--- Comment #9 from geoffk at gcc dot gnu dot org 2007-05-13 23:18 --- No DECL whose mangled name includes the name of an anonymous namespace should be TREE_PUBLIC. That is the bug here. There are no problems with typeinfo on systems where typeinfo is compared by address, which includes Linux and Darwin. On other systems you'll notice that the symbols are uniqued. I don't believe there are any reasons why the names have to be unique on these systems. Andrew, if you know some reasons, it would help if you listed them. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31903
[Bug c++/31775] static object mangling conflicts with extern object
--- Comment #5 from geoffk at gcc dot gnu dot org 2007-05-06 01:01 --- Subject: Bug 31775 Author: geoffk Date: Sun May 6 00:01:36 2007 New Revision: 124467 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124467 Log: Index: libiberty/ChangeLog 2007-05-04 Geoffrey Keating [EMAIL PROTECTED] * cp-demangle.c (d_name): Detect local-source-name. (d_prefix): Likewise. (d_unqualified_name): Implement local-source-name. Index: gcc/cp/ChangeLog 2007-05-04 Geoffrey Keating [EMAIL PROTECTED] PR 31775 * mangle.c (write_mangled_name): Mangle static variable names. (write_unqualified_name): Use local-source-name for namespace-scope static variables. Index: gcc/testsuite/ChangeLog 2007-05-04 Geoffrey Keating [EMAIL PROTECTED] PR 31775 * g++.dg/other/nested-extern.cc: New. * g++.dg/other/nested-extern-1.C: New. * g++.dg/other/nested-extern-2.C: New. Added: trunk/gcc/testsuite/g++.dg/other/nested-extern-1.C trunk/gcc/testsuite/g++.dg/other/nested-extern-2.C trunk/gcc/testsuite/g++.dg/other/nested-extern.cc Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/mangle.c trunk/gcc/testsuite/ChangeLog trunk/libiberty/ChangeLog trunk/libiberty/cp-demangle.c trunk/libiberty/testsuite/demangle-expected -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31775
[Bug c++/31775] static object mangling conflicts with extern object
--- Comment #6 from geoffk at gcc dot gnu dot org 2007-05-06 01:27 --- That should do it. -- geoffk at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31775
[Bug c/31537] duplicate weakref emitted with IMA
--- Comment #4 from geoffk at gcc dot gnu dot org 2007-05-03 20:14 ---
The following testcase should be equivalent to the original one but not involve
IMA:
void f1()
{
static __gthrw_pthread_once __attribute__ ((__weakref__ (pthread_once)));
}
void f2()
{
static __gthrw_pthread_once __attribute__ ((__weakref__ (pthread_once)));
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31537
[Bug c/31537] duplicate weakref emitted with IMA
--- Comment #2 from geoffk at gcc dot gnu dot org 2007-05-02 21:23 --- Since these are both 'static', shouldn't they be named things like __gthrw_pthread_once.247 in the assembler? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31537
[Bug c++/31775] New: static object mangling conflicts with extern object
In [basic.link] paragraph 6, there's an example that shows that (unlike in C)
it is permissible to define an object 'static' in a namespace scope and then
have another object which is 'extern', and reference both in the same
translation unit.
The compiler optimises that example so that there's no way to see the incorrect
behaviour, but a slightly modified version is:
extern C void abort();
static int i;
int *p = i;
int main()
{
int i;
{
extern int i;
i = 1;
*p = 2;
if (i == 2)
abort ();
}
return 0;
}
I believe this should fail to compile with a link error, because the extern
version of 'i' is never defined. On Darwin, what this does (apparently) is
crash with a bus error trying to write to the first instruction of main, which
is probably a linker bug; I expect that on other OSs it will call abort().
The basic problem is that 'static int i' needs to be a different name in the
assembly than 'extern int i'.
--
Summary: static object mangling conflicts with extern object
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: geoffk at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31775
[Bug c++/31775] static object mangling conflicts with extern object
--- Comment #1 from geoffk at gcc dot gnu dot org 2007-05-01 19:56 ---
This testcase is the same principle, but might use a different code path in the
compiler:
extern C void abort();
extern int *p;
int main()
{
extern int i;
i = 1;
*p = 2;
if (i == 2)
abort ();
return 0;
}
static int i;
int *p = i;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31775
[Bug c++/31775] static object mangling conflicts with extern object
--- Comment #3 from geoffk at gcc dot gnu dot org 2007-05-02 00:54 --- You would add a translation unit that says int i; or similar. It's not main::i, it's ::i, because of [basic.link] paragraph 7: When a block scope declaration of an entity with linkage is not found to refer to some other declaration, then that entity is a member of the innermost enclosing namespace. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31775
[Bug c++/31775] static object mangling conflicts with extern object
--- Comment #4 from geoffk at gcc dot gnu dot org 2007-05-02 01:46 --- I just happen to have a patch which fixes this. -- geoffk at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |geoffk at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-05-02 01:46:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31775
[Bug target/28197] longjmp and alloca cause bus error at -O0
--- Comment #3 from geoffk at gcc dot gnu dot org 2007-04-25 19:49 --- I'm fairly sure this is in fact a bug in GCC. The problem is that in a routine which uses setjmp, alloca() must ensure that the previous stack backchain is preserved, which means it needs to allocate enough space for its allocation, the linkage area, *and* arguments for any called function. It's not allocating enough space for called function arguments. In the routine given, it's only allocating 32 bytes where it actually needs to allocate 64. -- geoffk at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28197
[Bug target/28197] longjmp and alloca cause bus error at -O0
-- geoffk at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-04-25 19:50:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28197
[Bug target/26792] [4.2 Regression] need to use autoconf when using newly-added libgcc functions
--- Comment #34 from geoffk at gcc dot gnu dot org 2007-04-25 00:14 --- I don't know what patches you're referring to, so no. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26792
[Bug target/30058] [4.3 regression] bootstrap broken on i386-unknown-netbsdelf2.0.2
--- Comment #4 from geoffk at gcc dot gnu dot org 2007-03-16 20:12 --- Confirmed. (Yes, this means I'm finally able to reproduce it!) -- geoffk at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2007-01-06 17:51:30 |2007-03-16 20:12:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30058
[Bug target/30058] [4.3 regression] bootstrap broken on i386-unknown-netbsdelf2.0.2
-- geoffk at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |geoffk at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-03-16 20:12:47 |2007-03-16 20:13:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30058
[Bug objc/31013] [4.3 Regression] objc PCH is broken on powerpc-darwin again
--- Comment #6 from geoffk at gcc dot gnu dot org 2007-03-10 00:00 --- Subject: Bug 31013 Author: geoffk Date: Sat Mar 10 00:00:09 2007 New Revision: 122774 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122774 Log: PR 31013 * gccspec.c (lang_specific_driver): Do nothing when NEXT_OBJC_RUNTIME is declared. * config/darwin.h (REAL_LIBGCC_SPEC): When -fgnu-runtime is passed, use shared libgcc. Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/config/darwin.h branches/gcc-4_2-branch/gcc/gccspec.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31013
[Bug driver/31089] New: gccspec.c doesn't handle -x options
gccspec.c assumes that it can detect Objective-C files because they have a .m extension, but a user can pass '-ObjC' or '-x objective-c' or '-x c' to override the extension. -- Summary: gccspec.c doesn't handle -x options Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: geoffk at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31089
[Bug objc/31013] [4.3 Regression] objc PCH is broken on powerpc-darwin again
--- Comment #4 from geoffk at gcc dot gnu dot org 2007-03-08 19:56 --- Subject: Bug 31013 Author: geoffk Date: Thu Mar 8 19:56:37 2007 New Revision: 122709 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122709 Log: PR 31013 * gccspec.c (lang_specific_driver): Do nothing when NEXT_OBJC_RUNTIME is declared. * config/darwin.h (REAL_LIBGCC_SPEC): When -fgnu-runtime is passed, use shared libgcc. Modified: trunk/gcc/ChangeLog trunk/gcc/config/darwin.h trunk/gcc/gccspec.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31013
[Bug objc/31013] [4.3 Regression] objc PCH is broken on powerpc-darwin again
--- Comment #5 from geoffk at gcc dot gnu dot org 2007-03-08 20:31 --- This should be fixed now. -- geoffk at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31013
[Bug objc/31013] [4.3 Regression] objc PCH is broken on powerpc-darwin again
--- Comment #2 from geoffk at gcc dot gnu dot org 2007-03-07 00:16 --- The change to gccspec.c was made by Franz Sirl on 2001-06-16, revision 43421. The mail on gcc-patches is at http://gcc.gnu.org/ml/gcc-patches/2001-04/msg01394.html. There's further discussion at http://gcc.gnu.org/ml/gcc-patches/2001-03/msg00427.html. I think it's relying on the property that the GNU runtime is (always?) linked with the dynamic libgcc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31013
[Bug c/30762] [4.2/4.3 Regression] IMA messes up with inlining
--- Comment #9 from geoffk at gcc dot gnu dot org 2007-03-07 01:38 --- Confirmed. -- geoffk at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-07 01:38:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30762
[Bug c/30762] [4.2/4.3 Regression] IMA messes up with inlining
--- Comment #10 from geoffk at gcc dot gnu dot org 2007-03-07 01:52 --- c_types_compatible_p says the two types are compatible, but it never gets called. I don't think the back-end is involved. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30762
[Bug c/30762] [4.2/4.3 Regression] IMA messes up with inlining
--- Comment #11 from geoffk at gcc dot gnu dot org 2007-03-07 02:01 --- No, I take it back, the back-end is involved. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30762
[Bug objc/31013] [4.3 Regression] objc PCH is broken on powerpc-darwin again
--- Comment #1 from geoffk at gcc dot gnu dot org 2007-03-02 18:59 --- This is because gccspec.c is adding -shared-libgcc when it sees an Objective-C file, but inconsistently; it doesn't handle -x options, it doesn't handle the -objC flag. On Darwin, it's wrong to add -shared-libgcc like this because the objective-C runtime uses setjmp/longjmp exceptions and some versions of Darwin don't have a shared libgcc to use. -- geoffk at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |geoffk at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-02 18:59:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31013
[Bug target/30980] [4.3 Regression] Recent complex miscompilation
--- Comment #8 from geoffk at gcc dot gnu dot org 2007-02-27 17:25 --- I'm confident that my patch could not possibly have affected targets other than Darwin, and should not have significantly affected code generation even there. Complex arithmetic testcases will fail for other reasons on Darwin (like PR 24577). -- geoffk at gcc dot gnu dot org changed: What|Removed |Added CC|geoffk at gcc dot gnu dot | |org | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30980
[Bug target/25127] [4.0/4.1/4.2/4.3 Regression] internal compiler error: in rs6000_emit_prologue, at config/rs6000/rs6000.c:14039
--- Comment #12 from geoffk at gcc dot gnu dot org 2007-01-25 19:18 --- I'm working on this. -- geoffk at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |geoffk at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-02-02 20:22:25 |2007-01-25 19:18:42 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25127
[Bug target/25127] [4.0/4.1/4.2/4.3 Regression] internal compiler error: in rs6000_emit_prologue, at config/rs6000/rs6000.c:14039
--- Comment #13 from geoffk at gcc dot gnu dot org 2007-01-25 19:20 --- ... at least, I think I have a patch which will fix it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25127
[Bug target/25127] [4.0/4.1/4.2/4.3 Regression] internal compiler error: in rs6000_emit_prologue, at config/rs6000/rs6000.c:14039
--- Comment #14 from geoffk at gcc dot gnu dot org 2007-01-25 20:32 --- Subject: Bug 25127 Author: geoffk Date: Thu Jan 25 20:32:06 2007 New Revision: 121184 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121184 Log: 2007-01-24 Geoffrey Keating [EMAIL PROTECTED] PR 25127 * config/rs6000/rs6000.c (first_altivec_reg_to_save): On Darwin, save Altivec registers in an eh_return function. (compute_vrsave_mask): Likewise. (rs6000_stack_info): Correct AIX/Darwin stack alignment computation for saving Altivec registers. (rs6000_emit_prologue): Don't allocate stack twice in eh_return function. Correct expected value of altivec_save_offset when using save_world. Describe save of R0 to stack when using save_world. Describe stack pointer adjustment when using save_world. Remove duplicated eh_return parameter register saving. Update sp_offset variable after save_world. * config/rs6000/t-darwin (LIB2FUNCS_STATIC_EXTRA): Remove darwin-world.asm. (LIB2FUNCS_EXTRA): Add darwin-world.asm. * config/rs6000/darwin.h (SUBTARGET_OVERRIDE_OPTIONS): -m64 implies Altivec. Index: gcc/testsuite/ChangeLog 2007-01-24 Geoffrey Keating [EMAIL PROTECTED] * gcc.target/powerpc/darwin-ehreturn-1.c: New. * g++.dg/eh/simd-2.C: Also run on Darwin. * g++.dg/eh/simd-3.C: New. * g++.dg/eh/simd-4.C: New. Added: trunk/gcc/testsuite/g++.dg/eh/simd-3.C trunk/gcc/testsuite/g++.dg/eh/simd-4.C trunk/gcc/testsuite/gcc.target/powerpc/darwin-ehreturn-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/darwin.h trunk/gcc/config/rs6000/rs6000.c trunk/gcc/config/rs6000/t-darwin trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/eh/simd-2.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25127
[Bug target/25127] [4.0/4.1/4.2/4.3 Regression] internal compiler error: in rs6000_emit_prologue, at config/rs6000/rs6000.c:14039
--- Comment #15 from geoffk at gcc dot gnu dot org 2007-01-26 00:04 --- Subject: Bug 25127 Author: geoffk Date: Fri Jan 26 00:03:28 2007 New Revision: 121190 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121190 Log: 2007-01-24 Geoffrey Keating [EMAIL PROTECTED] PR 25127 * config/rs6000/rs6000.c (first_altivec_reg_to_save): On Darwin, save Altivec registers in an eh_return function. (compute_vrsave_mask): Likewise. (rs6000_stack_info): Correct AIX/Darwin stack alignment computation for saving Altivec registers. (rs6000_emit_prologue): Don't allocate stack twice in eh_return function. Correct expected value of altivec_save_offset when using save_world. Describe save of R0 to stack when using save_world. Describe stack pointer adjustment when using save_world. Remove duplicated eh_return parameter register saving. Update sp_offset variable after save_world. * config/rs6000/t-darwin (LIB2FUNCS_STATIC_EXTRA): Remove darwin-world.asm. (LIB2FUNCS_EXTRA): Add darwin-world.asm. * config/rs6000/darwin.h (SUBTARGET_OVERRIDE_OPTIONS): -m64 implies Altivec. Index: gcc/testsuite/ChangeLog 2007-01-24 Geoffrey Keating [EMAIL PROTECTED] * gcc.target/powerpc/darwin-ehreturn-1.c: New. * g++.dg/eh/simd-2.C: Also run on Darwin. * g++.dg/eh/simd-3.C: New. * g++.dg/eh/simd-4.C: New. Added: branches/gcc-4_2-branch/gcc/testsuite/g++.dg/eh/simd-3.C - copied unchanged from r121184, trunk/gcc/testsuite/g++.dg/eh/simd-3.C branches/gcc-4_2-branch/gcc/testsuite/g++.dg/eh/simd-4.C - copied unchanged from r121184, trunk/gcc/testsuite/g++.dg/eh/simd-4.C branches/gcc-4_2-branch/gcc/testsuite/gcc.target/powerpc/darwin-ehreturn-1.c - copied unchanged from r121184, trunk/gcc/testsuite/gcc.target/powerpc/darwin-ehreturn-1.c Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/config/rs6000/darwin.h branches/gcc-4_2-branch/gcc/config/rs6000/rs6000.c branches/gcc-4_2-branch/gcc/config/rs6000/t-darwin branches/gcc-4_2-branch/gcc/testsuite/ChangeLog branches/gcc-4_2-branch/gcc/testsuite/g++.dg/eh/simd-2.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25127
[Bug target/25127] [4.0/4.1/4.2/4.3 Regression] internal compiler error: in rs6000_emit_prologue, at config/rs6000/rs6000.c:14039
--- Comment #16 from geoffk at gcc dot gnu dot org 2007-01-26 00:05 --- This should be fixed now in the trunk and 4.2 branches. -- geoffk at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|geoffk at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25127
[Bug bootstrap/30589] [4.3 regression] C99 extern inline patch broke bootstrap on i386-pc-mingw32
--- Comment #4 from geoffk at gcc dot gnu dot org 2007-01-26 00:23 --- This is probably because the mingw math.h header does not support C99. Francois, where does this header come from? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30589
[Bug c/30580] New: GCC doesn't set floating-point exceptions when performing fp-int conversions
The attached file, tflt2int.c, prints lots of errors and then Failed with at least 223 failures on powerpc-darwin, and according to the file fails on lots of other architectures with GCC as well (but with different numbers of failures). It should pass. -- Summary: GCC doesn't set floating-point exceptions when performing fp-int conversions Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: geoffk at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30580
[Bug c/30580] GCC doesn't set floating-point exceptions when performing fp-int conversions
--- Comment #1 from geoffk at gcc dot gnu dot org 2007-01-24 22:04 --- Created an attachment (id=12952) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12952action=view) tflt2int.c testcase From http://www.tybor.com/tflt2int.c. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30580
[Bug c/30580] GCC doesn't set floating-point exceptions when performing fp-int conversions
--- Comment #3 from geoffk at gcc dot gnu dot org 2007-01-25 06:01 --- It's optional, but if you support Annex F of the C99 standard then F.4 says: If the floating value is infinite or NaN or if the integral part of the floating value exceeds the range of the integer type, then the invalid floating-point exception is raised and the resulting value is unspecified. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30580
[Bug c++/30566] New: -Wshadow warns about clashes between nested function parameters in C++
The following program:
void f( int x )
{
class InnerClass
{
public:
static void g( int x )
{
// empty
}
};
}
produces a warning:
t.cc: In static member function 'static void f(int)::InnerClass::g(int)':
t.cc:7: warning: declaration of 'int x' shadows a parameter
t.cc:1: warning: shadowed declaration is here
But it would be invalid for any function in InnerClass to try and use the outer
int x (and in fact if you try it, you correctly get an error).
--
Summary: -Wshadow warns about clashes between nested function
parameters in C++
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: geoffk at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30566
[Bug middle-end/30568] New: -ftrapping-math should prevent folding/dead code stripping of some builtins
This program:
#include stdio.h
#include math.h
#include fenv.h
main()
{
unsigned flags;
feclearexcept(FE_ALL_EXCEPT);
(void)acos(1.1);
flags = fetestexcept(FE_ALL_EXCEPT);
printf((void)acos( %e ) gives flags 0x%8x\n, 1.1, flags FE_ALL_EXCEPT);
}
when compiled with -ftrapping-math, should show that some flags are set,
FE_INVALID I think (maybe others). Instead it shows that no flags are set,
because GCC has completely folded out the call to acos().
--
Summary: -ftrapping-math should prevent folding/dead code
stripping of some builtins
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: geoffk at gcc dot gnu dot org
GCC target triplet: *-*-darwin*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30568
[Bug middle-end/30568] -ftrapping-math should prevent folding/dead code stripping of some builtins
--- Comment #1 from geoffk at gcc dot gnu dot org 2007-01-24 02:11 --- Other builtins where this can apply are pow() and lround(). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30568
[Bug c/30569] New: FLT_ROUNDS is wrong
ginclude/float.h has: /* Addition rounds to 0: zero, 1: nearest, 2: +inf, 3: -inf, -1: unknown. */ /* ??? This is supposed to change with calls to fesetround in fenv.h. */ #undef FLT_ROUNDS #define FLT_ROUNDS 1 GCC should have a builtin which returns the correct value for FLT_ROUNDS at any time, and use it in this header. -- Summary: FLT_ROUNDS is wrong Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: FIXME Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: geoffk at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30569
[Bug c++/30205] RFE: g++ --unmangle
--- Comment #2 from geoffk at gcc dot gnu dot org 2006-12-20 03:25 --- collect2 already does this on platforms which don't use GNU ld. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30205
[Bug ada/30094] bogus use of CROSS_COMPILE in adaint.c
--- Comment #1 from geoffk at gcc dot gnu dot org 2006-12-07 20:34 --- This function was added in revision 118240, with http://gcc.gnu.org/ml/gcc-patches/2006-10/msg01646.html. -- geoffk at gcc dot gnu dot org changed: What|Removed |Added CC||charlet at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30094
[Bug ada/30094] New: bogus use of CROSS_COMPILE in adaint.c
adaint.c contains several lines like #if defined (_WIN32) ! defined (__vxworks) ! defined (CROSS_COMPILE) which, although completely uncommented, appear to be trying to detect whether or not the system has an _tfopen function or an fopen function. The function is present on the target system independent of whether this file is being compiled on the target system or on, say, a linux system, so testing CROSS_COMPILE here is inappropriate. -- Summary: bogus use of CROSS_COMPILE in adaint.c Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: geoffk at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30094
[Bug c++/29873] New: need to rework behaviour of 'typedef struct { ... } x;'
GCC rejects this code:
template void (*p)() struct pp
{
static void (*the_p)();
};
template void (*p)() void (* ppp::the_p )() = p;
typedef struct
{
static void f() { }
struct ppf mypp;
} f_struct;
void g()
{
ppf_struct::f::the_p = 0;
}
with
t9.cc:10: error: 'anonymous struct::f' is not a valid template argument for
type 'void (*)()' because function 'static voidanonymous struct::f()' has not
external linkage
t9.cc: In function 'void g()':
t9.cc:15: error: 'f_struct::f' is not a valid template argument for type 'void
(*)()' because function 'static void f_struct::f()' has not external linkage
t9.cc:15: error: invalid type in declaration before '=' token
I believe this is incorrect. f_struct has external linkage by [basic.link]
paragraph 4 item 3, and then f_struct::f has external linkage by paragraph 5.
There is a FIXME in decl.c that says:
/* FIXME remangle member functions; member functions of a
type with external linkage have external linkage. */
which is related but not quite the same thing; it's not just the mangling that
is a problem.
--
Summary: need to rework behaviour of 'typedef struct { ... } x;'
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: geoffk at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29873
[Bug c++/29356] typedef name denoting unnamed class should have external linkage
--- Comment #2 from geoffk at gcc dot gnu dot org 2006-11-16 23:46 --- Yes, it definitely is. Thank you! -- geoffk at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|VERIFIED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29356
[Bug c++/7221] wrong linkage in member functions of typedef-named classes
--- Comment #3 from geoffk at gcc dot gnu dot org 2006-11-16 23:47 --- See rejects-valid example in 29356. -- geoffk at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |geoffk at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Keywords||rejects-valid Last reconfirmed|2005-12-11 23:01:14 |2006-11-16 23:47:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7221
[Bug c++/7221] wrong linkage in member functions of typedef-named classes
--- Comment #4 from geoffk at gcc dot gnu dot org 2006-11-17 00:04 --- *** Bug 29873 has been marked as a duplicate of this bug. *** -- geoffk at gcc dot gnu dot org changed: What|Removed |Added CC||geoffk at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7221
[Bug c++/29873] need to rework behaviour of 'typedef struct { ... } x;'
--- Comment #2 from geoffk at gcc dot gnu dot org 2006-11-17 00:04 --- Yes, this is a duplicate of 7221 as well. (This is the rejects-valid case.) *** This bug has been marked as a duplicate of 7221 *** -- geoffk at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29873
[Bug c++/7221] wrong linkage in member functions of typedef-named classes
--- Comment #5 from geoffk at gcc dot gnu dot org 2006-11-17 00:04 --- I mean, see rejects-valid example in bug 29873. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7221
[Bug c++/29773] name mangling for nested functions is wrong
--- Comment #1 from geoffk at gcc dot gnu dot org 2006-11-09 21:49 --- There is a contradiction here in the ABI. The formal syntax in the ABI says that a local-name cannot appear inside a nested-name, but the example I mentioned is trying to show that it does. However, the formal syntax in the ABI also says that a local-name does not end with a type specification, and if that was true, you couldn't use it for a nested function, because you need to include their argument types to allow overloading. Possibly this is just bug(s) in the ABI, and GCC is doing the right thing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29773
[Bug c++/29773] New: name mangling for nested functions is wrong
Given the following translation unit:
inline int (*foo())()
{
struct localstruct {
static int f() {
return 3;
}
};
return localstruct::f;
}
GCC mangles foo::localstruct::f as '_ZZ3foovEN11localstruct1fEv'.
According to the C++ ABI (see especially the third example in section 5.1.6) it
should be
_ZNZ3foovE11localstruct1fEv
That is, it should be function name bare-function-type at the top level,
not a local-name.
This is of course an ABI-breaking change.
--
Summary: name mangling for nested functions is wrong
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ABI
Severity: major
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: geoffk at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29773
[Bug c/11377] fault or warn modifiable static in extern inline definition
--- Comment #5 from geoffk at gcc dot gnu dot org 2006-11-01 04:47 --- Subject: Bug 11377 Author: geoffk Date: Wed Nov 1 04:47:30 2006 New Revision: 118356 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118356 Log: * c-decl.c (grokdeclarator): Don't set DECL_EXTERNAL on inline static functions in c99 mode. PR 16622 * doc/extend.texi (Inline): Update. * c-tree.h (struct language_function): Remove field 'extern_inline'. * c-decl.c (current_extern_inline): Delete. (pop_scope): Adjust test for an undefined nested function. Add warning about undeclared inline function. (diagnose_mismatched_decls): Update comments. Disallow overriding of inline functions in a translation unit in C99. Allow inline declarations in C99 at any time. (merge_decls): Boolize variables. Handle C99 'extern inline' semantics. (grokdeclarator): Set DECL_EXTERNAL here for functions. Handle C99 inline semantics. (start_function): Don't clear current_extern_inline. Don't set DECL_EXTERNAL. (c_push_function_context): Don't push current_extern_inline. (c_pop_function_context): Don't restore current_extern_inline. PR 11377 * c-typeck.c (build_external_ref): Warn about static variables used in extern inline functions. * c-decl.c (start_decl): Warn about static variables declared in extern inline functions. Added: trunk/gcc/testsuite/gcc.dg/inline-13.c trunk/gcc/testsuite/gcc.dg/inline-14.c trunk/gcc/testsuite/gcc.dg/inline-15.c trunk/gcc/testsuite/gcc.dg/inline-16.c trunk/gcc/testsuite/gcc.dg/inline6.c trunk/gcc/testsuite/gcc.dg/inline7.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-decl.c trunk/gcc/c-tree.h trunk/gcc/c-typeck.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/inline-10.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11377
[Bug c/16622] [C99] extern inline is handled wrong in C99 mode
--- Comment #13 from geoffk at gcc dot gnu dot org 2006-11-01 04:47 --- Subject: Bug 16622 Author: geoffk Date: Wed Nov 1 04:47:30 2006 New Revision: 118356 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118356 Log: * c-decl.c (grokdeclarator): Don't set DECL_EXTERNAL on inline static functions in c99 mode. PR 16622 * doc/extend.texi (Inline): Update. * c-tree.h (struct language_function): Remove field 'extern_inline'. * c-decl.c (current_extern_inline): Delete. (pop_scope): Adjust test for an undefined nested function. Add warning about undeclared inline function. (diagnose_mismatched_decls): Update comments. Disallow overriding of inline functions in a translation unit in C99. Allow inline declarations in C99 at any time. (merge_decls): Boolize variables. Handle C99 'extern inline' semantics. (grokdeclarator): Set DECL_EXTERNAL here for functions. Handle C99 inline semantics. (start_function): Don't clear current_extern_inline. Don't set DECL_EXTERNAL. (c_push_function_context): Don't push current_extern_inline. (c_pop_function_context): Don't restore current_extern_inline. PR 11377 * c-typeck.c (build_external_ref): Warn about static variables used in extern inline functions. * c-decl.c (start_decl): Warn about static variables declared in extern inline functions. Added: trunk/gcc/testsuite/gcc.dg/inline-13.c trunk/gcc/testsuite/gcc.dg/inline-14.c trunk/gcc/testsuite/gcc.dg/inline-15.c trunk/gcc/testsuite/gcc.dg/inline-16.c trunk/gcc/testsuite/gcc.dg/inline6.c trunk/gcc/testsuite/gcc.dg/inline7.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-decl.c trunk/gcc/c-tree.h trunk/gcc/c-typeck.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/inline-10.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16622
[Bug c/16622] [C99] extern inline is handled wrong in C99 mode
--- Comment #14 from geoffk at gcc dot gnu dot org 2006-11-01 04:48 --- Subject: Bug 16622 Author: geoffk Date: Wed Nov 1 04:48:15 2006 New Revision: 118357 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118357 Log: * c-decl.c (grokdeclarator): Don't set DECL_EXTERNAL on inline static functions in c99 mode. PR 16622 * doc/extend.texi (Inline): Update. * c-tree.h (struct language_function): Remove field 'extern_inline'. * c-decl.c (current_extern_inline): Delete. (pop_scope): Adjust test for an undefined nested function. Add warning about undeclared inline function. (diagnose_mismatched_decls): Update comments. Disallow overriding of inline functions in a translation unit in C99. Allow inline declarations in C99 at any time. (merge_decls): Boolize variables. Handle C99 'extern inline' semantics. (grokdeclarator): Set DECL_EXTERNAL here for functions. Handle C99 inline semantics. (start_function): Don't clear current_extern_inline. Don't set DECL_EXTERNAL. (c_push_function_context): Don't push current_extern_inline. (c_pop_function_context): Don't restore current_extern_inline. PR 11377 * c-typeck.c (build_external_ref): Warn about static variables used in extern inline functions. * c-decl.c (start_decl): Warn about static variables declared in extern inline functions. Modified: trunk/gcc/doc/extend.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16622
[Bug c/11377] fault or warn modifiable static in extern inline definition
--- Comment #6 from geoffk at gcc dot gnu dot org 2006-11-01 04:48 --- Subject: Bug 11377 Author: geoffk Date: Wed Nov 1 04:48:15 2006 New Revision: 118357 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118357 Log: * c-decl.c (grokdeclarator): Don't set DECL_EXTERNAL on inline static functions in c99 mode. PR 16622 * doc/extend.texi (Inline): Update. * c-tree.h (struct language_function): Remove field 'extern_inline'. * c-decl.c (current_extern_inline): Delete. (pop_scope): Adjust test for an undefined nested function. Add warning about undeclared inline function. (diagnose_mismatched_decls): Update comments. Disallow overriding of inline functions in a translation unit in C99. Allow inline declarations in C99 at any time. (merge_decls): Boolize variables. Handle C99 'extern inline' semantics. (grokdeclarator): Set DECL_EXTERNAL here for functions. Handle C99 inline semantics. (start_function): Don't clear current_extern_inline. Don't set DECL_EXTERNAL. (c_push_function_context): Don't push current_extern_inline. (c_pop_function_context): Don't restore current_extern_inline. PR 11377 * c-typeck.c (build_external_ref): Warn about static variables used in extern inline functions. * c-decl.c (start_decl): Warn about static variables declared in extern inline functions. Modified: trunk/gcc/doc/extend.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11377
[Bug target/15834] NO_IMPLICIT_EXTERN_C should be gotten rid of
--- Comment #9 from geoffk at gcc dot gnu dot org 2006-11-01 04:53 --- Subject: Bug 15834 Author: geoffk Date: Wed Nov 1 04:53:33 2006 New Revision: 118358 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118358 Log: PR 15834 * config/darwin.h (NO_IMPLICIT_EXTERN_C): Define. Modified: trunk/gcc/ChangeLog trunk/gcc/config/darwin.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15834
[Bug target/23067] Incorrect struct layout on darwin
--- Comment #26 from geoffk at gcc dot gnu dot org 2006-11-01 05:28 --- Subject: Bug 23067 Author: geoffk Date: Wed Nov 1 05:28:41 2006 New Revision: 118365 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118365 Log: In gcc/: PR 23067 * c-decl.c (start_struct): Don't create self-containing structures. * config/rs6000/rs6000.c (darwin_rs6000_special_round_type_align): New. * config/rs6000/rs6000-protos.h (darwin_rs6000_special_round_type_align): New. * config/rs6000/darwin.h (ADJUST_FIELD_ALIGN): Rewrite. (ROUND_TYPE_ALIGN): Use darwin_rs6000_special_round_type_align. In gcc/testsuite/: PR 23067 * gcc.target/powerpc/darwin-abi-3.c: Remove XFAIL. * gcc.target/powerpc/darwin-abi-6.c: Remove XFAIL. * gcc.target/powerpc/darwin-abi-7.c: Remove XFAIL. * gcc.target/powerpc/darwin-abi-8.c: Remove XFAIL. * gcc.target/powerpc/darwin-abi-9.c: Remove XFAIL. * gcc.target/powerpc/darwin-abi-10.c: Remove XFAIL. * gcc.target/powerpc/darwin-abi-11.c: Remove XFAIL. In libobjc/: * encoding.c (darwin_rs6000_special_round_type_align): New. In libffi/: * src/powerpc/ffi_darwin.c (darwin_adjust_aggregate_sizes): New. (ffi_prep_cif_machdep): Call darwin_adjust_aggregate_sizes for Darwin. * testsuite/libffi.call/nested_struct4.c: Remove Darwin XFAIL. * testsuite/libffi.call/nested_struct6.c: Remove Darwin XFAIL. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/darwin.h trunk/gcc/config/rs6000/rs6000-protos.h trunk/gcc/config/rs6000/rs6000.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/powerpc/darwin-abi-10.c trunk/gcc/testsuite/gcc.target/powerpc/darwin-abi-11.c trunk/gcc/testsuite/gcc.target/powerpc/darwin-abi-3.c trunk/gcc/testsuite/gcc.target/powerpc/darwin-abi-6.c trunk/gcc/testsuite/gcc.target/powerpc/darwin-abi-7.c trunk/gcc/testsuite/gcc.target/powerpc/darwin-abi-8.c trunk/gcc/testsuite/gcc.target/powerpc/darwin-abi-9.c trunk/libffi/ChangeLog trunk/libffi/src/powerpc/ffi_darwin.c trunk/libffi/testsuite/libffi.call/nested_struct4.c trunk/libffi/testsuite/libffi.call/nested_struct6.c trunk/libobjc/ChangeLog trunk/libobjc/encoding.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23067
[Bug target/15834] NO_IMPLICIT_EXTERN_C should be gotten rid of
--- Comment #10 from geoffk at gcc dot gnu dot org 2006-11-01 05:37 --- I can't tell if this bug is fixed. However, Darwin now has NO_IMPLICIT_EXTERN_C set. -- geoffk at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|geoffk at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15834
[Bug c/16622] [C99] extern inline is handled wrong in C99 mode
--- Comment #17 from geoffk at gcc dot gnu dot org 2006-11-01 05:38 --- This should now be behaving correctly. -- geoffk at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16622
[Bug target/23067] Incorrect struct layout on darwin
--- Comment #28 from geoffk at gcc dot gnu dot org 2006-11-01 05:39 --- All these testcases are now fixed. I don't promise that the two compilers have exactly the same ABI, especially for C++, but the testcases pass. -- geoffk at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23067
[Bug c/11377] fault or warn modifiable static in extern inline definition
--- Comment #7 from geoffk at gcc dot gnu dot org 2006-11-01 05:40 --- This should now be fixed. -- geoffk at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11377
[Bug libfortran/29302] nan_inf_fmt.f90 segfaults on Darwin PPC starting with Xcode 2.4
--- Comment #10 from geoffk at gcc dot gnu dot org 2006-10-31 01:02 --- Hi Jack, I have no idea what's causing this, and I don't know why you think I do. I am the one asking you to provide a testcase in the Radar. You're claiming that this is a bug in Xcode 2.4 (which is supported by Apple), and not a bug in gfortran (which is not supported by Apple). I am asking for a testcase which removes the non-supported part and shows the bug. My comment about strtol_l is because if atoi() tail-calls strtol_l, possibly after changing parameters, then you would see strtol_l in the backtrace; that would be normal and not a bug or a symptom of a bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29302
[Bug libfortran/29302] nan_inf_fmt.f90 segfaults on Darwin PPC starting with Xcode 2.4
--- Comment #11 from geoffk at gcc dot gnu dot org 2006-10-31 01:03 --- Please do not add '[EMAIL PROTECTED]' to the CC list of any bugzilla bug. -- geoffk at gcc dot gnu dot org changed: What|Removed |Added CC|geoffk at apple dot com | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29302
[Bug target/26510] [4.1/4.2/4.3 Regression] --disable-shared broken for darwin platform
--- Comment #7 from geoffk at gcc dot gnu dot org 2006-10-29 20:29 --- I think I'll just declare that GCC requires a shared libgcc on Darwin. -- geoffk at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26510
[Bug debug/29436] [4.0/4.1/4.2 Regression] ICE in modified_type_die
--- Comment #12 from geoffk at gcc dot gnu dot org 2006-10-18 17:08 --- Isn't this a dup of bug 28834? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29436
[Bug target/3920] [PPC] wrong register number for CTR in stabs
--- Comment #8 from geoffk at gcc dot gnu dot org 2006-10-18 18:41 --- The stabs numbering should probably match whatever AIX does. -- geoffk at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|geoffk at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3920
[Bug target/25630] darwin-ppc, wrong alignment of nested structs
--- Comment #2 from geoffk at gcc dot gnu dot org 2006-10-16 21:46 --- I think this is a dup of bug 23067; they have the same underlying problem, which is that FSF GCC doesn't emulate the Apple GCC algorithm for structure layout exactly. *** This bug has been marked as a duplicate of 23067 *** -- geoffk at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25630
[Bug target/23067] Incorrect struct layout on darwin
--- Comment #25 from geoffk at gcc dot gnu dot org 2006-10-16 21:46 --- *** Bug 25630 has been marked as a duplicate of this bug. *** -- geoffk at gcc dot gnu dot org changed: What|Removed |Added CC||andreast at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23067
[Bug target/23067] Incorrect struct layout on darwin
-- geoffk at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |geoffk at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Known to fail|3.3.3 3.4.0 4.0.0 4.1.0 |3.3.3 3.4.0 4.0.0 4.1.0 ||4.2.0 Last reconfirmed|2005-12-10 05:34:46 |2006-10-16 21:47:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23067
[Bug c/11377] fault or warn modifiable static in extern inline definition
-- geoffk at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11377
[Bug target/15834] NO_IMPLICIT_EXTERN_C should be gotten rid of
-- geoffk at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15834
[Bug c/16622] [C99] extern inline is handled wrong in C99 mode
-- geoffk at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16622
[Bug target/23067] Incorrect struct layout on darwin
-- geoffk at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23067
