GCC 4.5 branch is now frozen
The GCC 4.5 branch is now frozen for the final release off that branch and will then be officially closed. Thanks for your cooperation, Richard.
GCC 4.5.4 Release Candidate available from gcc.gnu.org
A release candidate for GCC 4.5.4 is available from ftp://gcc.gnu.org/pub/gcc/snapshots/4.5.4-RC-20120625 and shortly its mirrors. I have so far bootstrapped and tested the release candidate on x86_64-linux. Please test it and report any issues to bugzilla. If all goes well, I'd like to release 4.5.4 at the end of next week after which the 4.5 branch will be retired.
Re: Code optimization: warning for code that hangs
Hello, So far so good, but J::F() is strange: Dump of assembler code for function J::F(): 0x00400498 <+0>:subrsp,0x8 0x0040049c <+4>:movrax,QWORD PTR [rdi] 0x0040049f <+7>:movrax,QWORD PTR [rax] 0x004004a2 <+10>:movrax,QWORD PTR [rax] 0x004004a5 <+13>:movrax,QWORD PTR [rax] 0x004004a8 <+16>:movrax,QWORD PTR [rax] 0x004004ab <+19>:movrax,QWORD PTR [rax] 0x004004ae <+22>:movrax,QWORD PTR [rax] 0x004004b1 <+25>:movrax,QWORD PTR [rax] 0x004004b4 <+28>:movrdi,QWORD PTR [rax] 0x004004b7 <+31>:call 0x400498 0x004004bc <+36>:addrsp,0x8 0x004004c0 <+40>:ret End of assembler dump. What are those mov rax,QWORD PTR [rax]'s ? No comments on this part? Shouldn't the optimizer eliminated a few of those loads? Regards, Peter
Re: ARM GCC 4.8 test suite
On 20/06/12 15:27, Sebastian Huber wrote:
> Hi,
>
> maybe it makes sense to look at some test suite comments since now all non
> EABI
> configurations have been removed (is this correct?).
>
No, not quite. All configurations using the FPA have been removed.
That's not quite the same thing.
NetBSD is still supported (though it's not been tested in a while) and
that uses the ATPCS (or something quite close to it).
R.
> The problem was pointed out here:
>
> http://gcc.gnu.org/ml/gcc-patches/2012-05/msg00950.html
>
> Here are some samples of the test suite (4.8-20120617):
>
> gcc/testsuite/g++.old-deja/g++.other/vaarg2.C:// { dg-options "-Wno-abi" {
> target arm_eabi } }
>
> gcc/testsuite/g++.dg/ext/visibility/arm1.C:// { dg-do compile { target
> arm*-*-eabi* arm*-*-symbianelf* } }
>
> gcc/testsuite/g++.dg/ext/visibility/arm2.C:// { dg-do compile { target
> arm*-*-*eabi* arm*-*-symbianelf* } }
>
> gcc/testsuite/g++.dg/ext/visibility/arm3.C:// { dg-do compile { target
> arm*-*-*eabi* } }
>
> gcc/testsuite/g++.dg/abi/arm_va_list.C:// { dg-require-effective-target
> arm_eabi }
>
> Does it make sense to replace all "arm*-*-eabi*", "arm*-*-*eabi*", and
> "arm*-*-symbianelf*" combinations with "arm_eabi"?
>
I'll look at them when I get round to that part of the tools. There's
still some clean-up work in the main part of the compiler to finish
before I move onto other parts.
R.
ARM: gcc generates two identical strd instructions to store 8 bytes
Hi all,
I am using the gcc ARM cross-compiler (gcc version 4.6.3 (Ubuntu/Linaro
4.6.3-1ubuntu5)). Compiling the test.c code (in attachement) with:
'arm-linux-gnueabi-gcc -S test.c'
I obtain the test.s assembly code (in attachement). At lines 56 and 57
of the test.s there is two identical strd instructions:
56 strdr2, [r7]
57 strdr2, [r7]
I have checked the semantic of the ARM strd instruction and I have not
seen any side effect of this instruction that could explain why gcc need
to put this instruction two times in a row. For me, one is sufficient to
store the 8-bytes variable into memory.
Is there an explanation?
Thanks.
Nathanaël Prémillieu
#include
#include
int main()
{
int a = rand();
long long int b = rand();
if(a % 2)
{
b *= 999;
}
printf("%lld\n", b);
}
.syntax unified
.arch armv7-a
.eabi_attribute 27, 3
.fpu vfpv3-d16
.eabi_attribute 20, 1
.eabi_attribute 21, 1
.eabi_attribute 23, 3
.eabi_attribute 24, 1
.eabi_attribute 25, 1
.eabi_attribute 26, 2
.eabi_attribute 30, 6
.eabi_attribute 34, 1
.eabi_attribute 18, 4
.thumb
.file "test.c"
.section.rodata
.align 2
.LC0:
.ascii "%lld\012\000"
.text
.align 2
.global main
.thumb
.thumb_func
.type main, %function
main:
@ args = 0, pretend = 0, frame = 16
@ frame_needed = 1, uses_anonymous_args = 0
push{r7, lr}
sub sp, sp, #16
add r7, sp, #0
bl rand
str r0, [r7, #12]
bl rand
mov r1, r0
mov r2, r1
asr r3, r2, #31
strdr2, [r7]
ldr r3, [r7, #12]
and r3, r3, #1
uxtbr3, r3
cmp r3, #0
beq .L2
ldr r3, [r7, #4]
movwr2, #999
mul r2, r2, r3
ldr r3, [r7, #0]
mov r1, #0
mul r3, r1, r3
addsr1, r2, r3
ldr r2, [r7, #0]
movwr3, #999
umull r2, r3, r2, r3
addsr1, r1, r3
mov r3, r1
strdr2, [r7]
strdr2, [r7]
.L2:
movwr3, #:lower16:.LC0
movtr3, #:upper16:.LC0
mov r0, r3
ldrdr2, [r7]
bl printf
mov r0, r3
add r7, r7, #16
mov sp, r7
pop {r7, pc}
.size main, .-main
.ident "GCC: (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3"
.section.note.GNU-stack,"",%progbits
How to document many darwin-specific, undocumented target macros
Hello, By my count, there are a lot of undocumented target macro defines that are darwin specific. In total there are 59 undocumented cases, and 16 of them are darwin specific. (To get to this count, I've simply looked at all #defines in config/* + config/*/*, looked up the ones that are used in the gcc/ directory, and that are not documented in doc/*.texi -- see full list at the bottom of this e-mail). The darwin specific cases are the following: COLLECT_RUN_DSYMUTIL DEBUG_ABBREV_SECTION DEBUG_ARANGES_SECTION DEBUG_FRAME_SECTION DEBUG_INFO_SECTION DEBUG_LINE_SECTION DEBUG_LOC_SECTION DEBUG_MACINFO_SECTION DEBUG_MACRO_SECTION DEBUG_PUBNAMES_SECTION DEBUG_PUBTYPES_SECTION DEBUG_RANGES_SECTION DEBUG_STR_SECTION DSYMUTIL FRAME_BEGIN_LABEL ASM_DEBUG_SPEC Most of them deal with debugging things that Mach-O does not support in the "normal" way that ELF does, e.g. all the DEBUG_*_SECTION defines, like so: dwarf2out.c:#define DEBUG_FRAME_SECTION ".debug_frame" config/darwin.h:#define DEBUG_FRAME_SECTION "__DWARF,__debug_frame,regular,debug" dwarf2out.c:#define DEBUG_INFO_SECTION ".debug_info" config/darwin.h:#define DEBUG_INFO_SECTION "__DWARF,__debug_info,regular,debug" dwarf2out.c:#define DEBUG_ABBREV_SECTION".debug_abbrev" config/darwin.h:#define DEBUG_ABBREV_SECTION "__DWARF,__debug_abbrev,regular,debug" dwarf2out.c:#define DEBUG_ARANGES_SECTION ".debug_aranges" config/darwin.h:#define DEBUG_ARANGES_SECTION "__DWARF,__debug_aranges,regular,debug" dwarf2out.c:#define DEBUG_MACINFO_SECTION ".debug_macinfo" config/darwin.h:#define DEBUG_MACINFO_SECTION "__DWARF,__debug_macinfo,regular,debug" dwarf2out.c:#define DEBUG_LINE_SECTION ".debug_line" config/darwin.h:#define DEBUG_LINE_SECTION "__DWARF,__debug_line,regular,debug" dwarf2out.c:#define DEBUG_LOC_SECTION ".debug_loc" config/darwin.h:#define DEBUG_LOC_SECTION "__DWARF,__debug_loc,regular,debug" dwarf2out.c:#define DEBUG_PUBNAMES_SECTION ".debug_pubnames" config/darwin.h:#define DEBUG_PUBNAMES_SECTION "__DWARF,__debug_pubnames,regular,debug" dwarf2out.c:#define DEBUG_PUBTYPES_SECTION ".debug_pubtypes" config/darwin.h:#define DEBUG_PUBTYPES_SECTION "__DWARF,__debug_pubtypes,regular,debug" dwarf2out.c:#define DEBUG_STR_SECTION ".debug_str" config/darwin.h:#define DEBUG_STR_SECTION "__DWARF,__debug_str,regular,debug" dwarf2out.c:#define DEBUG_RANGES_SECTION".debug_ranges" config/darwin.h:#define DEBUG_RANGES_SECTION "__DWARF,__debug_ranges,regular,debug" I am not sure how to proceed with these target macros. I could documenting these target macros, but where are the default names taken from (a spec somewhere), and is this the Right solution given that only darwin uses non-default names? In fact darwin does follow the naming convention, the only difference is that it wraps the section name in a segment label (always "__DWARF__") and adds some flags (always "regular,debug"). I would have expected there to be a way to change a section name in a target-specific way (something like a targetm.asm_out.adjust_section_name to transform ".debug_blah" to "__DWARF,__debug_blah,regular,debug") but it seems such a mechanism doesn't exist. Maybe add a hook for this? Thoughts/comments/suggestions welcome... Ciao! Steven Complete list: missing: ADDR_VEC_ALIGN missing: ADJUST_INSN_LENGTH missing: ASCII_DATA_ASM_OP missing: ASM_OUTPUT_ADDR_DIFF_VEC missing: ASM_OUTPUT_ADDR_VEC missing: ASM_OUTPUT_EXTERNAL_LIBCALL missing: ASM_OUTPUT_LIMITED_STRING missing: ASM_PN_FORMAT missing: COLLECT_RUN_DSYMUTIL missing: CPU_UNITS_QUERY missing: DEBUG_ABBREV_SECTION missing: DEBUG_ARANGES_SECTION missing: DEBUG_FRAME_SECTION missing: DEBUG_INFO_SECTION missing: DEBUG_LINE_SECTION missing: DEBUG_LOC_SECTION missing: DEBUG_MACINFO_SECTION missing: DEBUG_MACRO_SECTION missing: DEBUG_PUBNAMES_SECTION missing: DEBUG_PUBTYPES_SECTION missing: DEBUG_RANGES_SECTION missing: DEBUG_STR_SECTION missing: DSYMUTIL missing: DWARF2_ADDR_SIZE missing: ELF_ASCII_ESCAPES missing: ELF_STRING_LIMIT missing: FENCE_FOLLOWING_MOVNT missing: FP_REG_P missing: FRAME_BEGIN_LABEL missing: HAVE_AS_LEB128 missing: HAVE_AS_TLS missing: INSN_LENGTH_ALIGNMENT missing: IS_STACK_MODE missing: JCR_SECTION_NAME missing: JMP_BUF_SIZE missing: LOGICAL_OP_NON_SHORT_CIRCUIT missing: MY_ISCOFF missing: NAME__MAIN missing: NORMAL_MODE missing: PIC_CASE_VECTOR_ADDRESS missing: READ_CAN_USE_WRITE_PREFETCH missing: SPARC_STACK_BOUNDARY_HACK missing: STACK_POP_CODE missing: STACK_REG_P missing: STRING_ASM_OP missing: SYMBOL__MAIN missing: TARGET_64BIT missing: TARGET_64BIT_DEFAULT missing: TARGET_AIX_VERSION missing: TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DATA_T missing: VMS_DEBUG_MAIN_POINTER missing: ASM_DEBUG_SPEC missing: EXTRA_SPEC_FUNCTIONS missing: GOMP_SELF_SPECS missing: GTM_SELF_SPECS missing: LINK_SSP_SPEC missing: MFLIB_SPEC missing: MFWRAP_SPEC missing: STARTFILE_PREFIX_SPEC
Re: LTO inlining of transactional builtins
On 2012-06-22 06:08, Richard Guenther wrote: > Do I understand correctly that inlining the builtin at expansion time is not > good because the implementation detail may depend on how libitm was > configured? More or less, yes. We want tm in gcc to be useful to researchers experimenting in the area. That means not building stuff into the main compiler beyond the ABI. The ABI is just a function call. However, in some implementations (including our own) the ABI call is a small wrapper that calls a function in a dispatch table. Avoiding the call-to-call at least in static linking situations is more or less exactly what LTO does best. Unfortunately, we have a real phase ordering problem here. LTO is also what gives us the visibility into the program itself and allows us to clone functions for tm based on what's in the transaction. r~
Re: LTO inlining of transactional builtins
a) If a user provides a builtin implementation to LTO, it is discarded, since by design LTO prefers builtins to user-provided versions of them. In LTO, builtins are their own prevailing decl. There is an enhancement request PR here: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51997 It definitely should be the other way around and builtins should get their proper entry in the now existent symbol table. Well, the way we stream builtin decls as special cases is indeed weird. I recall I once tried to remove that code and it lead to some regressions, but in general it should no tbe neccesary. Yes, we seem to special-case builtins all over the place. I have a kludge disabling this, just to work on (b) below. b) LTO streaming happens before TMMARK. Since the TMMARK pass is the one that instruments memory operations into __builtin_ITM_* calls, even if (a) was fixed, LTRANS would have nothing to inline. Which also means that this has nothing to do with LTO per-se, just that you'd need LTO to see the bodies of the "builtins". Use a small C testcase where you provide the implementation of one of the builtins (well, the one you end up using) and face the same issue. Do I understand correctly that inlining the builtin at expansion time is not good because the implementation detail may depend on how libitm was configured? Unfortunately, the tmmark pass can't be moved earlier, because the point is to delay its work so memory and loop optimizations can do its thing before memory operations are irreconcilably transformed into function calls. This is the main problem however. As Richi pointed out, even in C this won't work. We decide inlining at WPA time and since then no inlining is possible and all unreachable functions are removed. So when you invent new calls to builtins on the way you can't expect them to be resonably inlinined. Yes, I have been playing with marking any such provided builtins with cgraph_mark_force_output_node() in the IPA-tm pass. I assume that anyone linking with implementations of the TM builtins must either want them inlined, or want them in the final link. But your idea of a new inline attribute is cleaner and far more generic. Also you would not have the TM builtin bodies available in your ltrans unit because nothing calls them. So anything that requires LTO (to see the bodies in the first place) but does not expose the calls before LTO bytecode output is not going to work. Marking with cgraph_mark_force_output_node() in the IPA-tm pass fixes this. Well, only way I see here is to a) have special purpose local inlining pass to handle these newly born bultins. Basically you can re-purpose early inliner for this and run it after your pass (and we can generalize the machinery for other kind of beasts if needed) The early inliner fits better for this than late inliner. Yes, this is what I've been doing, but I paused for yall's input when I had to either rematerialize the gimple bodies, or keep the gimple optimizations from removing them as each function got compiled. b) introduce new kind of functions that are those builtins. You need Sort of combination of always_inline, extern and used attributes but not quite. The new kind of function must 1) make partitioner to ship the functions into every partition, 2) make unreachable function removal to not remove them even if they seem useless, 3) make code generation to never produce offline copies of them even if they are not removed by the unreachable function pass. 4) make the final check happy that this type of function may be kept in memory till end of compilation. If this seems neccesary I can implement this for you, but I am always hesitant to add a new type of function into the machinery - we already face the complexity of having quite few of them. I would be delighted if you could work on this, if you think a more general solution to just forcing the node to be outputted is necessary. But first let's get rth's input, because I'm still unsure whether the payoff for inlining so late is sufficient to merit all this work. Aldy
Re: LTO inlining of transactional builtins
> a) If a user provides a builtin implementation to LTO, it is discarded, since by design LTO prefers builtins to user-provided versions of them. In LTO, builtins are their own prevailing decl. There is an enhancement request PR here: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51997 >>> >>> It definitely should be the other way around and builtins should get their >>> proper entry in the now existent symbol table. >> >> Well, the way we stream builtin decls as special cases is indeed weird. I >> recall >> I once tried to remove that code and it lead to some regressions, but in >> general >> it should no tbe neccesary. > > Yes, we seem to special-case builtins all over the place. I have a > kludge disabling this, just to work on (b) below. If you can turn the kludge into a patch, I think it would be great to have it in mainline. I do not see builtins to be inherently special here. I was bit by this code several times. >> >> This is the main problem however. As Richi pointed out, even in C this won't >> work. >> We decide inlining at WPA time and since then no inlining is possible and >> all unreachable >> functions are removed. So when you invent new calls to builtins on the way >> you can't expect them to be resonably inlinined. > > Yes, I have been playing with marking any such provided builtins with > cgraph_mark_force_output_node() in the IPA-tm pass. I assume that > anyone linking with implementations of the TM builtins must either want > them inlined, or want them in the final link. But your idea of a new > inline attribute is cleaner and far more generic. This wayou ensure that the function is not removed at beggining of IPA queue (and it gets streamed from LTRANS to WPA). You however won't arrange it to land into every partition, so we really need special functionality here if the inlining decisions has to be deferred to ltrans stage. Moreover if your function is static inline it will be output as offline copy into every compilation unit that is not what we want. > >>> Also you would not have the TM builtin bodies available in your ltrans unit >>> because nothing calls them. So anything that requires LTO (to see the >>> bodies in the first place) but does not expose the calls before LTO bytecode >>> output is not going to work. > > Marking with cgraph_mark_force_output_node() in the IPA-tm pass fixes this. > >> Well, only way I see here is to >> >> a) have special purpose local inlining pass to handle these newly born >> bultins. >> Basically you can re-purpose early inliner for this and run it after your >> pass >> (and we can generalize the machinery for other kind of beasts if needed) >> The early inliner fits better for this than late inliner. > > Yes, this is what I've been doing, but I paused for yall's input when I > had to either rematerialize the gimple bodies, or keep the gimple > optimizations from removing them as each function got compiled. There is mechanizm to save function bodies for recursive inlining. You only need to make save_inline_function_body to return true on your functions. > >> >> b) introduce new kind of functions that are those builtins. You need >> Sort of combination of always_inline, extern and used attributes but not >> quite. >> The new kind of function must >> 1) make partitioner to ship the functions into every partition, >> 2) make unreachable function removal to not remove them even if they >> seem useless, >> 3) make code generation to never produce offline copies of them even if >> they >>are not removed by the unreachable function pass. >> 4) make the final check happy that this type of function may be kept in >> memory >>till end of compilation. >> >> If this seems neccesary I can implement this for you, but I am always >> hesitant >> to add a new type of function into the machinery - we already face the >> complexity >> of having quite few of them. > > I would be delighted if you could work on this, if you think a more > general solution to just forcing the node to be outputted is necessary. > But first let's get rth's input, because I'm still unsure whether the > payoff for inlining so late is sufficient to merit all this work. Well, as I told earlier, this is bit sliperly concept, so I am not completelly wed to it. Shipping the functions into every ltrans unit "just for case" is somewhat expensive if the feature gets widespread use and there is problem on what to do with functions used only by those special functions: cgraph will need to know that these also stays till end of compilation but need not to be output unlss the functions needing them are. At the moment all decisions about what functions to output are done prior the final compilation stage and this makes whole stuff more interwinded. On the other hand if we want to support for LTO we need to solve this problem for i.e. libgcc and basic runtime, too. So perhaps we could have
Regression: incorrect line numbers in debug info since 4.5+
Hello,
I found out while single stepping a new template function in gdb that
gcc generates bad/inaccurate line numbers in the debug info.
Optimization was turned off, but the execution jumped strangely, see
below. gcc-4.4 and the current clang produced the expected results, gcc
4.5, 4.6, 4.7, 4.8 all had problems. The code was factored out from a
proof-of-concept hack.
Here is the trace that was produced in gdb by single stepping the
program with 'n'. The program was compiled w/ gcc 4.8.0 git commit e7ae865c:
COLLECT_GCC=gcc-4.8.0
COLLECT_LTO_WRAPPER=/home/usr-local/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ./configure --enable-languages=c,c++
--program-suffix=-4.8.0
Thread model: posix
gcc version 4.8.0 20120605 (experimental) (GCC)
g++-4.8.0 -g -O0 -Wall -Wextra -o dbginfobug.o -c dbginfobug.cpp
g++-4.8.0 -g -o dbginfobug dbginfobug.o
11 while (C c = *f++) {
12 if (c == '$') {
56 if (o < e) {
57 *o = c;
59 ++o;
// the first anomaly: the line printed is AFTER the loop, while we're
still in the loop
// this happens only with 4.8, after each iteration
62 printf("RESULT (%zu chars): '%s'\n", o - buf, buf);
11 while (C c = *f++) {
12 if (c == '$') {
56 if (o < e) {
57 *o = c;
59 ++o;
62 printf("RESULT (%zu chars): '%s'\n", o - buf, buf);
...
62 printf("RESULT (%zu chars): '%s'\n", o - buf, buf);
11 while (C c = *f++) {
12 if (c == '$') {
13 C c2 = *f;
14 if (c2 == '$') {
18 unsigned ai = gai;
19 if (c2 == '{') {
20 ++f;
21 C c3 = *f;
22 if (c3 >= '0' && c3 <= '9') {
23 ai = 0;
24 while (C c4 = *f) {
25 if (c4 < '0'
|| c4 > '9') {
28 ai *= 10;
29 ai += c4 - '0';
30 ++f;
24 while (C c4 = *f) {
25 if (c4 < '0'
|| c4 > '9') {
// doesn't stop on the break with 4.8, stops with earlier versions
// !!! we should be after the closing brace of the loop, yet we're still
inside
30 ++f;
(gdb) p c4
// this is quite a gotcha: c4 of type C is not in the scope anymore, but
some constant
// of type mynumber creeps in the scope from libm.
// this wasn't too helpful understanding what's going on...
$16 = {i = {1431655765, -1079683755}, x = -0.041664}
(gdb) p f
$17 = 0x400a18 "}\n"
36 C x = *f++;
// f was not incremented (correctly), despite it stood on the line ++f
(gdb) p f
$18 = 0x400a18 "}\n"
37 if (x == '}') {
// now it stops on this break. what's the difference compared to the
above if() where it didn't stop?
38 break;
62 printf("RESULT (%zu chars): '%s'\n", o - buf, buf);
11 while (C c = *f++) {
12 if (c == '$') {
I attached the cpp source, and also the preprocessed version, if it
makes any difference.
I couldn't find anything similar in bz, please let me know whether this
is a new issue and I will file a bugreport.
Regards, Peter
#include
#include
template
void do_print(C* buf, size_t siz, const C* fmt)
{
const C* f = fmt;
C* o = buf;
C* e = buf + siz;
unsigned gai = 0;
while (C c = *f++) {
if (c == '$') {
C c2 = *f;
if (c2 == '$') {
++f;
goto lit;
}
unsigned ai = gai;
if (c2 == '{') {
++f;
C c3 = *f;
if (c3 >= '0' && c3 <= '9') {
ai = 0;
while (C c4 = *f) {
if (c4 < '0' || c4 > '9') {
break;
}
ai *= 10;
ai += c4 - '0';
++f;
}
} else {
++gai;
}
do {
C x = *f++;
if (x == '}') {
break;
}
if (x == 0) {
fprintf(stderr, "ERROR: no closing brace\n");
return;
}
if (x == 'f') {
break;
} else {
fprintf(stderr, "ERROR: invalid format specifier char '%c'\n", x);
return;
}
} while (1);
} else {
++gai;
}
} else {
lit:
if (o < e) {
*o = c;
}
++o;
}
}
printf("RESULT (%zu chars): '%s'\n", o - buf, buf);
}
void fo
Re: Regression: incorrect line numbers in debug info since 4.5+
"Peter A. Felvegi" writes: > I found out while single stepping a new template function in gdb that > gcc generates bad/inaccurate line numbers in the debug > info. Thanks for reporting this. In the future, please send messages like this to gcc-h...@gcc.gnu.org, not gcc@gcc.gnu.org. Thanks. > I couldn't find anything similar in bz, please let me know whether > this is a new issue and I will file a bugreport. Please do open a bug report following the instructions at http://gcc.gnu.org/bugs/ . Thanks. Ian
Re: Regression: incorrect line numbers in debug info since 4.5+
On 25 June 2012 17:15, Peter A. Felvegi wrote: > Hello, > > I found out while single stepping a new template function in gdb that gcc > generates bad/inaccurate line numbers in the debug info. Optimization was > turned off, but the execution jumped strangely, see below. gcc-4.4 and the > current clang produced the expected results, gcc 4.5, 4.6, 4.7, 4.8 all had > problems. The code was factored out from a proof-of-concept hack. Which version of GDB? As documented at http://gcc.gnu.org/gcc-4.5/changes.html GCC now generates unwind info also for epilogues. DWARF debuginfo generated by GCC now uses more features of DWARF3 than before, and also some DWARF4 features. GDB older than 7.0 is not able to handle either of these, so to debug GCC 4.5 generated binaries or libraries GDB 7.0 or later is needed. You can disable use of DWARF4 features with the -gdwarf-3 -gstrict-dwarf options, or use -gdwarf-2 -gstrict-dwarf to restrict GCC to just DWARF2, but epilogue unwind info is emitted unconditionally whenever unwind info is emitted.
Re: Regression: incorrect line numbers in debug info since 4.5+
Hello, Which version of GDB? As documented at http://gcc.gnu.org/gcc-4.5/changes.html GCC now generates unwind info also for epilogues. DWARF debuginfo generated by GCC now uses more features of DWARF3 than before, and also some DWARF4 features. GDB older than 7.0 is not able to handle either of these, so to debug GCC 4.5 generated binaries or libraries GDB 7.0 or later is needed. You can disable use of DWARF4 features with the -gdwarf-3 -gstrict-dwarf options, or use -gdwarf-2 -gstrict-dwarf to restrict GCC to just DWARF2, but epilogue unwind info is emitted unconditionally whenever unwind info is emitted. I was using 7.4.1, under Debian Wheezy, amd64. Tried the dwarf 2 options, but then I wasn't even able to step into the template function from foo(): when hitting step on the function name, the next line was the fn closing brace, in asm it jumped from preparing the reg args to the leaveq after the call. When stepped inside the fn via si, the first 'next' attempt failed gdb saying that the fn contained no line number info, and stopped at the outer leaveq as before. With dwarf-3 and 4, the already reported buggy behaviour occured when single stepping the function. Regards, Peter
Re: How to document many darwin-specific, undocumented target macros
On Jun 25, 2012, at 6:48 AM, Steven Bosscher wrote: > In fact darwin does follow the > naming convention, the only difference is that it wraps the section > name in a segment label (always "__DWARF__") and adds some flags > (always "regular,debug"). I would have expected there to be a way to > change a section name in a target-specific way (something like a > targetm.asm_out.adjust_section_name to transform ".debug_blah" to > "__DWARF,__debug_blah,regular,debug") but it seems such a mechanism > doesn't exist. Maybe add a hook for this? A section name transform hook does seem cleaner to me. Additionally, this could be used to aid portability of using the section selection across darwin and non-darwin targets, so I think it has value beyond a cleaner interface.
Re: Regression: incorrect line numbers in debug info since 4.5+
The bug is at: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53770 Regards, Peter
Re: ARM: gcc generates two identical strd instructions to store 8 bytes
On 26 June 2012 00:48, Nathanaël Prémillieu wrote: > Hi all, > > I am using the gcc ARM cross-compiler (gcc version 4.6.3 (Ubuntu/Linaro > 4.6.3-1ubuntu5)). Compiling the test.c code (in attachement) with: > > 'arm-linux-gnueabi-gcc -S test.c' > > I obtain the test.s assembly code (in attachement). At lines 56 and 57 of > the test.s there is two identical strd instructions: > > 56 strd r2, [r7] > 57 strd r2, [r7] > > I have checked the semantic of the ARM strd instruction and I have not seen > any side effect of this instruction that could explain why gcc need to put > this instruction two times in a row. For me, one is sufficient to store the > 8-bytes variable into memory. > > Is there an explanation? Hi Nathanaël. Your question is more appropriate for the gcc-help list. This list is about the development of GCC itself. You've built with optimisation turned off so GCC has generated correct but inefficient code. The double store could be side effect of expanding the 64 bit multiply into the component 32 bit multiplies or the conditional. Try building at -O or higher. -- Michael
