[Bug other/32998] -frecord-gcc-switches issues
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32998 --- Comment #12 from Roland McGrath roland at redhat dot com 2010-10-05 19:24:56 UTC --- Preprocessing stuff is probably best left to the -g3 info instead. cc1* options make sense for DW_AT_producer.
[Bug other/32998] -frecord-gcc-switches issues
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32998 --- Comment #10 from Roland McGrath roland at redhat dot com 2010-10-05 00:41:45 UTC --- (In reply to comment #9) Wouldn't be appropriate to append these flags also/instead to DW_AT_producer? This way they get easily associated with the specific CU. That makes some sense. It also should get the strings nicely merged by the linker in the .debug_str section.
[Bug c++/45153] DWARF DW_AT_external flag set for undefined variables
--- Comment #8 from roland at redhat dot com 2010-08-13 08:08 --- I think you've confused static variables (file scope) with C++ static members (global scope). At any rate, this is not the place to get an education about DWARF. You can use the dwarf-discuss mailing list for those questions. The DIEs you cited are correct for the code. There is no gcc bug here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45153
[Bug c++/45153] DWARF DW_AT_external flag set for undefined variables
--- Comment #6 from roland at redhat dot com 2010-08-13 00:43 --- DW_AT_external is correct for anything that has global linkage, whether or not is defined. The absence of DW_AT_external, in a DIE that is not inside a DW_TAG_subprogram scope, means that it has file linkage, like a static variable in C/C++ does. A C++ static member has global linkage, not file linkage. DW_AT_declaration is used for any DIE that is for a non-defining declaration. That is a separate axis of consideration than DW_AT_external, which only about the linkage. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45153
[Bug c++/41091] Using section attribute in c and c++ function causes section type conflict
--- Comment #4 from roland at redhat dot com 2010-08-11 23:52 ---
The compiler is being internally inconsistent here. It somtimes decides that
__attribute__((section (name))) means a name section in a COMDAT group, and
sometimes decides that it means just a plain name section. If it's going to
have that behavior implicitly, then it should not call this a conflict.
Instead, it should implicitly recognize that the particular COMDAT version of
name is a different animal than the non-COMDAT name.
In fact, it has an arguably more severe version of this bug too:
class C
{
public:
void m()
{
static int TWO __attribute__((section(.consts))) = 2;
}
};
class D
{
public:
void m()
{
static int THREE __attribute__((section(.consts))) = 2;
}
};
int
main (int argc, char **argv)
{
C inst = C();
inst.m();
D inst2 = D();
inst2.m();
return 0;
}
For that, it happily puts TWO and THREE initializers both in the COMDAT group
for C::m()::TWO, which is quite clearly wrong. The left hand uses multiple
different sections of the same name, but the right hand thinks that any section
matching the simple name it's looking for is the same thing regardless of
whether or not its a distinct COMDAT variant.
--
roland at redhat dot com changed:
What|Removed |Added
CC||roland at redhat dot com,
||jakub at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41091
[Bug c/45123] New: -pedantic warning about string inside __asm
With this file (that's a string of 512 spaces):
main()
{
__asm(
);
}
gcc -o asmloser asmloser.c -ansi -pedantic
asmloser.c: In function main:
asmloser.c:3: warning: string length 512 is greater than the length 509 ISO
C90 compilers are required to support
Since we are inside __asm here and that circumvents -pedantic, the pedantic
warning should not apply to the string inside, which isn't even a C string
constant, it's just GCC extension syntax.
--
Summary: -pedantic warning about string inside __asm
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: roland at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45123
[Bug debug/44712] Debug info for partially inlined functions
--- Comment #2 from roland at redhat dot com 2010-07-01 18:56 ---
The foo.part.0 DW_TAG_subprogram should get DW_AT_artificial.
IMHO that is equivalent to any other hypothetical case where
the compiler decides to spin a function where there was not
exactly one in the source. That fits OpenMP cases, and also
any other hypothetical case, e.g. if for plain:
for (i = ...) { long stretch of cse'able using i }
for (j = ...) { long stretch of cse'able using j }
the compiler decides the best thing is to make a subroutine
of { long stretch of cse'able using argument } and turn each
loop body into a call.
It's not immediately clear to me what purpose is served by
DW_AT_abstract_origin on the foo.part.0 DW_TAG_subprogram. In the
trivial example as given, I'm not sure there is any positive reason to
have it at all. But I suppose there is a DW_TAG_formal_parameter for
foo.part.0's argument, and that should have DW_AT_abstract_origin to the
source foo DW_TAG_subprogram's DW_TAG_formal_parameter.
If there are various unperturbed things in the foo scope (types, statics,
unused variables, etc.) then DW_AT_abstract_origin is right to indicate
those are in scope where foo.part.0's PC ranges lie.
It would be nice to get the implied semantic copying of whatever is not
overridden in the cases less close to an inline. e.g. my cse'able
case above (or real-world OpenMP equivalent), would like to have the
compiler-invented subroutine use DW_AT_abstract_origin or equivalent to
pull in the scope of the DW_TAG_lexical_block or whatever it was that is
the semantic scope of the synthetic callee.
IMHO the foo.part.0 case should actually be considered one of these
cases rather than a traditional out of line instance of an abstract
inline instance. foo.part.0 is not really the equivalent of any source
subprogram. It's really a subset of that, equivalent either to some
source DW_TAG_lexical_block or just to a portion of a DW_TAG_subprogram.
I think we should recommend new DWARF spec wording (extending 3.3.8) for
this use. Such uses are squarely within the permissive rather than
prescriptive principle (1.3) anyway.
Let any scope entry, i.e. DW_TAG_lexical_block et al, be an abstract
instance root, not just DW_TAG_subprogram. (Possibly you could put a
DW_AT_inline on such entries, but that doesn't really make sense.
Instead just reword 3.3.8.1 to define abstract instance entry
independent of DW_AT_inline.) Then some DW_TAG_subprogram might have
DW_AT_abstract_origin pointing to that abstract instance root, and have
children with DW_AT_abstract_origin pointing to a corresponding child of
the non-subprogram abstract instance root.
When a concrete instance entry points to an abstract instance entry of a
different tag, it only makes sense if the concrete instance entry is
marked artificial. e.g., artifical subprogram - lexical_block. (If
the subprogram weren't artificial, there would be a source-centric
abstract instance entry for it to point to that is a subprogram.)
In some cases there may be no natural source-centric abstract instance
entry to refer to. (This is probably so in the bar example--it is if
foo.part.0 takes the x parameter and contains the if (x = 0) test,
not just its then-block. It certainly would be in a case where foo
were written without braces in that then-clause.) Then I see two
options that might make sense:
1. Use the containing semantic scope as DW_AT_abstract_origin for the
artificial subprogram. In the example, foo.part.0 points to the
DW_AT_subprogram for foo (as you say it happens to do today).
This seems fine when the artificial subprogram is quite close to a
semantic match for the source subprogram, i.e. a close subset like
foo.part.0 is of the source foo.
But it's less clear when it would be some large subprogram (or
other, inner scope entry), of which the synthetic call represents
only a small part. e.g. my cse'able cases when those loops
appear inside a huge main with a hundred other things.
It also becomes potentially ambiguous how to take it. If the
referent is a DW_TAG_subprogram that does not have DW_AT_inline,
then you could say that this must be the container of an artificial
call rather than the normal abstract inline instance entry
corresponding to a normal concrete inline instance entry. But if
the referent DW_TAG_subprogram happens to be an abstract inline
instance root independently, it would have DW_AT_inline though that
means nothing for this reference. I suppose you always know
whether the referring subprogram is marked artifical and that alone
disambiguates, so maybe this is OK. Still it's perhaps just too
subtle/confusing what this kind of reference means.
2. Emit an artifical entry in the semantic scope of the code that was
moved into the synthetic callee, just to be what the artificial
subprogram's abstract_origin points to.
This could overload an existing tag
[Bug libstdc++/41628] New: _GLIBCXX_DEBUG feature: check for unstable iterators
I just had a bug whose issue was using stale unstable iterators after changing the container. It would be nice for _GLIBCXX_DEBUG to catch those. e.g., container object holds a mutation count and increments it on every call that is allowed to destabilize extant iterators in the API (even if it doesn't, like a set insert with no change if the spec says that can invalidate), iterator holds ptr to container object and the mutation count sampled at iterator creation time, all iterator ops throw if the mutation count no longer matches the container. -- Summary: _GLIBCXX_DEBUG feature: check for unstable iterators Product: gcc Version: 4.4.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: roland at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41628
[Bug debug/41439] New: choose DW_OP_stack_value over DW_OP_implicit_value more often, please
The comment in address_of_int_loc_descriptor doesn't make a lot of sense to me.
In any case of a value no larger than address size, you can use
DW_OP_stack_value to get the same size or smaller. When the size is the same,
such as DW_OP_implicit_value(address-sized block) vs
DW_OP_addr(address-consant) DW_OP_stack_value (both address-size + 2 bytes), I
think DW_OP_stack_value is preferable because consumers do not have to involve
overly-general variable-sized-stuff-with-relocs logic that the general case of
constant blocks involves. There is no need for a DW_OP_{bit_,}piece in these
cases when the expressed value is in the low bits of the value computed on the
stack.
--
Summary: choose DW_OP_stack_value over DW_OP_implicit_value more
often, please
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: roland at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41439
[Bug c/40517] strict-aliasing warning contains internal variable name
--- Comment #3 from roland at redhat dot com 2009-06-23 20:27 --- I don't understand. Why can't it print the source-level variable name? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40517
[Bug debug/40040] gfortran invalid DW_AT_location for overridable variables
--- Comment #4 from roland at redhat dot com 2009-05-06 19:45 --- Hmm. I am concerned by the idea of relocs for DWARF sections in final-linked objects. That is a hassle that consumers have not had to handle before. (AFAIK only consumers that handle ET_REL pseudo-final objects such as Linux kernel .ko modules cope with reloc sections at all.) I think what's ideal in the abstract is that the location expression indicates how the variable is really accessed, i.e. loading the address from the GOT or whatever it really does. That might not always be possible in the defining declaration. e.g., when the definition is in a CU where there are no accesses, perhaps it can't tell whether other CUs will be using direct addressing (e.g. @GOTOFF) or GOT-indirect. I read DWARF 3 section 4.1 item 4 to suggest that there should be a defining DW_TAG_variable whose DW_AT_location can be the base one, i.e. direct address in the definer, plus non-defining DW_TAG_variable (with DW_AT_declaration) DIEs whose DW_AT_location expressions indicate how the variable is accessed in each scope using it. So, in the main program CU the DW_TAG_variable should have DW_AT_declaration, DW_AT_external, and a DW_AT_location describing the main program's copy (or its GOT lookup if PIC). In the non-defining accessing CUs in a DSO, there should be a similar DIE whose DW_AT_location describes that DSO's GOT lookup, etc. If the defining CU also contains accesses, then the defining DW_TAG_variable's DW_AT_location would describe the GOT access if that's what that CU uses, and then no DIE anywhere would have the direct address location expression for the DSO initializer/copy. I don't know how ready GDB et al are to cope with this, but it seems like the correct route to me. They'd have to find the right DIE for the scope of the access, so it has the appropriate location expression. For blind global lookups, it would have to be sure to use the dominating DIE, i.e. choose one somewhere in the main program before the defining definition in the DSO. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40040
[Bug other/32998] -frecord-gcc-switches issues
--- Comment #3 from roland at redhat dot com 2007-08-06 19:19 --- Absolute file names are a very bad idea. That makes for gratuitous differences in builds due to the build or source directory name, i.e. unrepeatable builds. The names in .debug_line and .debug_info are already expected by post-processing tools and taken care of. Do not add another location in the object that might contain absolute file names. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32998
[Bug c/20043] New: transparent_union doesn't allow restrict qualifier removal
GCC 4 now produces a conflicting types error for code that gcc 3.4 accepts without complaint. This usage pattern occurs when using glibc's sys/socket.h with _GNU_SOURCE defined, followed by a POSIX-compliant redeclaration of function like `accept'. This is what transparent_union was invented to support. -- Summary: transparent_union doesn't allow restrict qualifier removal Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: roland at redhat dot com CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20043
[Bug c/20043] transparent_union doesn't allow restrict qualifier removal
--- Additional Comments From roland at redhat dot com 2005-02-17 23:16 --- Created an attachment (id=8218) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8218action=view) small test case for this bug 3.4 likes this fine, but 4.0 does not. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20043
