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)
The bug is at:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53770
Regards, Peter
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
> chan
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 o
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 cl
"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.
>
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,
>
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/bugzi
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
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 are
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 t
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 str
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.
N
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
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 li
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.
16 matches
Mail list logo