Re: AVR gives weird error with LTO
2009/12/31 Weddington, Eric : > > >> -Original Message- >> From: Andrew Hutchinson [mailto:andrewhutchin...@cox.net] >> Sent: Wednesday, December 30, 2009 4:34 PM >> To: Richard Guenther >> Cc: Dave Korn; Rafael Espindola; GCC Development; Weddington, >> Eric; Denis Chertykov >> Subject: Re: AVR gives weird error with LTO >> >> >> >> Thank you David and Rafel >> >> >> >> I will dig further into collect2. I had noted that avr.h >> has the following: >> >> >> >> >> >> /* This is undefined macro for collect2 disabling */ >> >> #define LINKER_NAME "ld" >> >> >> > >> > That's indeed going to break LTO. >> > >> > Richard. >> > >> > >> That seems to be the key issue. >> Without #define LINKER_NAME, AVR is running LTO/WHOPR tests ok ! (No >> idea if it does anything useful though) >> >> Now to figure out why it was added in 2000 (rth). Hopefully Eric >> Weddington or Denis might have some idea and perhaps know if it still >> has a purpose. > > That was before my time. I didn't get involved (peripherally) until 2002. So > it's either Denis Chertykov or Marek Michalkiewicz (CCed). I havn't any ideas about LINKER_NAME definition. Denis.
Over-sensitive warning, or some quirk of C++ language rules?
Hi all,
Simple testcase, using h...@155680.
$ cat badwarn.cpp
extern void bar (void);
int foo (void) __attribute__ ((__noreturn__));
int
foo (void)
{
while (1)
{
bar ();
}
}
$ g++-4 -c badwarn.cpp -Wall
badwarn.cpp: In function 'int foo()':
badwarn.cpp:12:1: warning: no return statement in function returning non-void
The noreturn attribute doesn't make any difference; it still complains even
without it. However compiling the example as C (either by renaming the
extension or using "-x -c") makes the warning go away.
I would expect GCC to realise that the loop never exits and not worry about
the missing return value. In C++ of course there are exceptional exits from
that loop even when the loop condition is known to be always true. Does this
mean that the return statement is needed even if it's only ever going to be
skipped straight over during throwing an exception or longjmp()ing? If this
isn't intentional, I'll file a PR.
cheers,
DaveK
Combined tree fails to build -- libtool version mismatch?
Hi, I'm trying to build a combined tree following the instructions of http://gcc.gnu.org/simtest-howto.html, and I get this failure: /bin/sh ./libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../../combined/bfd -I. -I../../combined/bfd -I../../combined/bfd/../include -DBINDIR='"/usr/local/bin"' -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Werror -g -O2 -MT archive.lo -MD -MP -MF .deps/archive.Tpo -c -o archive.lo ../../combined/bfd/archive.c libtool: Version mismatch error. This is libtool 2.2.7a, but the libtool: definition of this LT_INIT comes from libtool 2.2.6. libtool: You should recreate aclocal.m4 with macros from libtool 2.2.7a libtool: and run autoconf again. make[4]: *** [archive.lo] Error 63 make[4]: Leaving directory `/home/stevenb/devel/cross/build-unpatched/bfd' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/home/stevenb/devel/cross/build-unpatched/bfd' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/stevenb/devel/cross/build-unpatched/bfd' make[1]: *** [all-bfd] Error 2 make[1]: *** Waiting for unfinished jobs This is with gcc SVN revision 155740, and src checked out yesterday (top of src/Changelog is the fix from Kaveh and FX for gcc PR42424). Not knowing a thing about libtool, I hope someone can tell me what's wrong here ;-) Ciao! Steven
Re: Why Thumb-2 only allows very limited access to the PC?
OK, I filed a bug to trace it. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42671 thanks Guozhi On Thu, Jan 7, 2010 at 6:23 PM, Richard Earnshaw wrote: > > On Wed, 2010-01-06 at 18:26 +, Paul Brook wrote: >> On Wednesday 06 January 2010, Carrot Wei wrote: >> > So thumb2 can also use the instructions similar to thumb1, right? It >> > potentially has better performance and smaller code size. >> >> Technically yes, however in ARMv7 the relevant instruction (add.n , pc) >> is deprecated. > > Where'd you get that idea? > > Annex D of the ARM ARM says that the 16-bit instructions that add SP and > PC together (writing either SP or PC) are deprecated, but there's > nothing else using PC that's mentioned there other than trying to move > PC into SP or vice-versa. All the deprecated instructions in this area > are pretty meaningless in real life anyway. > > R. > >
Re: Over-sensitive warning, or some quirk of C++ language rules?
On 2010-01-10, at 00:31, Dave Korn wrote:
> Simple testcase, using h...@155680.
>
>
> $ cat badwarn.cpp
>
> extern void bar (void);
> int foo (void) __attribute__ ((__noreturn__));
>
> int
> foo (void)
> {
> while (1)
> {
>bar ();
> }
> }
>
> $ g++-4 -c badwarn.cpp -Wall
> badwarn.cpp: In function 'int foo()':
> badwarn.cpp:12:1: warning: no return statement in function returning non-void
>
gcc 4.0.1, 4.2.1, and 4.3.4 don't warn about this. Looks like a regression.
-- Ross Smith
Re: Combined tree fails to build -- libtool version mismatch?
On 01/09/2010 12:16 PM, Steven Bosscher wrote: This is with gcc SVN revision 155740, and src checked out yesterday (top of src/Changelog is the fix from Kaveh and FX for gcc PR42424). Not knowing a thing about libtool, I hope someone can tell me what's wrong here;-) src and gcc's libtool are out-of-sync (2.2.6 vs. 2.2.7a respectively). Since gcc's files dominate, you have ltmain.sh from GCC but bfd's configure uses src's libtool configuration. Binutils should adopt GCC's libtool.m4, ltmain.sh, lt~obsolete.m4, ltoptions.m4, ltsugar.m4, ltversion.m4 and src should rerun autoconf on all of its scripts (CCing gdb, newlib and cygwin mailing lists). DJ, can you add these files to the list that we get email about? Paolo
Re: Combined tree fails to build -- libtool version mismatch?
On Sat, Jan 9, 2010 at 6:26 AM, Paolo Bonzini wrote: > On 01/09/2010 12:16 PM, Steven Bosscher wrote: >> >> This is with gcc SVN revision 155740, and src checked out yesterday >> (top of src/Changelog is the fix from Kaveh and FX for gcc PR42424). >> >> Not knowing a thing about libtool, I hope someone can tell me what's >> wrong here;-) > > src and gcc's libtool are out-of-sync (2.2.6 vs. 2.2.7a respectively). Since > gcc's files dominate, you have ltmain.sh from GCC but bfd's configure uses > src's libtool configuration. > > Binutils should adopt GCC's libtool.m4, ltmain.sh, lt~obsolete.m4, > ltoptions.m4, ltsugar.m4, ltversion.m4 and src should rerun autoconf on all > of its scripts (CCing gdb, newlib and cygwin mailing lists). > > DJ, can you add these files to the list that we get email about? > Many files in the top directories between gcc and src are out of sync. You can do a diff on them to check it out. -- H.J.
Re: Over-sensitive warning, or some quirk of C++ language rules?
On Sat, Jan 9, 2010 at 4:17 AM, Ross Smith wrote:
> On 2010-01-10, at 00:31, Dave Korn wrote:
>
>> Simple testcase, using h...@155680.
>>
>>
>> $ cat badwarn.cpp
>>
>> extern void bar (void);
>> int foo (void) __attribute__ ((__noreturn__));
>>
>> int
>> foo (void)
>> {
>> while (1)
>> {
>> bar ();
>> }
>> }
>>
>> $ g++-4 -c badwarn.cpp -Wall
>> badwarn.cpp: In function 'int foo()':
>> badwarn.cpp:12:1: warning: no return statement in function returning non-void
>>
>
> gcc 4.0.1, 4.2.1, and 4.3.4 don't warn about this. Looks like a regression.
>
> -- Ross Smith
>
>
It is caused by revision 138140:
http://gcc.gnu.org/ml/gcc-cvs/2008-07/msg00852.html
--
H.J.
Re: Combined tree fails to build -- libtool version mismatch?
On 01/09/2010 04:48 PM, H.J. Lu wrote: On Sat, Jan 9, 2010 at 6:26 AM, Paolo Bonzini wrote: On 01/09/2010 12:16 PM, Steven Bosscher wrote: This is with gcc SVN revision 155740, and src checked out yesterday (top of src/Changelog is the fix from Kaveh and FX for gcc PR42424). Not knowing a thing about libtool, I hope someone can tell me what's wrong here;-) src and gcc's libtool are out-of-sync (2.2.6 vs. 2.2.7a respectively). Since gcc's files dominate, you have ltmain.sh from GCC but bfd's configure uses src's libtool configuration. Binutils should adopt GCC's libtool.m4, ltmain.sh, lt~obsolete.m4, ltoptions.m4, ltsugar.m4, ltversion.m4 and src should rerun autoconf on all of its scripts (CCing gdb, newlib and cygwin mailing lists). DJ, can you add these files to the list that we get email about? Many files in the top directories between gcc and src are out of sync. You can do a diff on them to check it out. I know (as hinted above build maintainers get emails about out-of-sync email), but they do not break the build... Paolo
Re: Combined tree fails to build -- libtool version mismatch?
* Paolo Bonzini wrote on Sat, Jan 09, 2010 at 03:26:33PM CET: > > Binutils should adopt GCC's libtool.m4, ltmain.sh, lt~obsolete.m4, > ltoptions.m4, ltsugar.m4, ltversion.m4 and src should rerun autoconf > on all of its scripts (CCing gdb, newlib and cygwin mailing lists). I just pinged that very change this morning. I will commit it later tonight. Cheers, Ralf
Re: Over-sensitive warning, or some quirk of C++ language rules?
H.J. Lu wrote: > It is caused by revision 138140: > > http://gcc.gnu.org/ml/gcc-cvs/2008-07/msg00852.html Thanks for finding that HJ! This is now PR42674. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42674 cheers, DaveK
Adding a new GCC Bugzilla Keyword?
I noticed while filing a PR that we have a keyword for: non-weakOnly affects targets which do not support weak symbols. I'd like to ask (Dan?) if we can add a new one along similar lines: non-elf Only affects non-ELF targets. As an inevitable side-effect of the fact that linux is the most popular GCC platform and the one where most development work takes place, we do suffer from the occasional all-the-world's-an-ELF-ism. There's usually a way of making GCC DTRT on other formats by other means, so I think this category would be useful. How about it? cheers, DaveK
Re: dwarf2 - multiple DW_TAG_variable for global variable
This dwarf code started appearing since this patch:
r145293 | jakub | 2009-03-30 14:35:03 + (Mon, 30 Mar 2009) | 11 lines
PR debug/39563
* c-decl.c (struct c_binding): Add locus field.
(bind): Add locus argument, set locus field from it.
(pop_scope): For b->nested VAR_DECL or FUNCTION_DECL,
add a DECL_EXTERNAL copy of b->decl to current BLOCK_VARS.
(push_file_scope, pushtag, pushdecl, pushdecl_top_level,
implicitly_declare, undeclared_variable, lookup_label,
declare_label, c_make_fname_decl, c_builtin_function,
c_builtin_function_ext_scope, store_parm_decls_newstyle): Adjust
bind callers.
Jan, can you confirm that this is indeed the correct DWARF that is being
generated.
Thank you,
Nenad
On 1/4/10 11:34 PM, Nenad Vukicevic wrote:
I installed gcc-4.5-20091224 snapshot and noticed that for simple
variable declaration
I get two DW_TAG_variable dies in the object file. For example, the
following
code
int x;
main()
{x=1;}
generates (with -g -gdwarf2 -O0 switches):
<1><54>: Abbrev Number: 4 (DW_TAG_variable)
<55> DW_AT_name: (indirect string, offset: 0x36): x
<59> DW_AT_decl_file : 1
<5a> DW_AT_decl_line : 1
<5b> DW_AT_type: <0x4d>
<5f> DW_AT_external: 1
<60> DW_AT_declaration : 1
<1><61>: Abbrev Number: 5 (DW_TAG_variable)
<62> DW_AT_name: (indirect string, offset: 0x36): x
<66> DW_AT_decl_file : 1
<67> DW_AT_decl_line : 1
<68> DW_AT_type: <0x4d>
<6c> DW_AT_external: 1
<6d> DW_AT_location: 9 byte block: 3 0 0 0 0 0 0 0 0
(DW_OP_addr: 0)
Is the above normal? 4.3.2 compiler generates only one die, the second
one with
DW_AT_location attribute, which is correct.
I also noticed that this example (were variable is not used):
int x;
main()
{}
generates only one DW_TAG_variable, the one with DW_AT_location,
which again
should be correct.
I ran into this problem by porting some GDB code that uses DWARF2 and
got surprised
to see this change from the previous version of gcc (4.3).
Thanks,
Nenad
Re: dwarf2 - multiple DW_TAG_variable for global variable
On 01/09/10 12:39:55, Nenad Vukicevic wrote: > This dwarf code started appearing since this patch: Here's the GCC bug report that led to this patch: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39563 It references a GDB fix as well: http://sourceware.org/ml/gdb-patches/2009-03/threads.html#00595 http://sourceware.org/ml/gdb-patches/2009-04/threads.html#00040 http://sourceware.org/ml/gdb-cvs/2009-04/msg00021.html
Re: dwarf2 - multiple DW_TAG_variable for global variable
On Sat, 09 Jan 2010 22:01:54 +0100, Gary Funck wrote: > On 01/09/10 12:39:55, Nenad Vukicevic wrote: > > This dwarf code started appearing since this patch: > > Here's the GCC bug report that led to this patch: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39563 Such DIEs duplicities are being tracked at: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39524 (Unaware how/if any were caused by the PR 39563.) Regards, Jan
Re: dwarf2 - multiple DW_TAG_variable for global variable
We used GCC regression testing to pin point PR39563 when
multiple (but not equal) definitions started appearing in
dwarf code. We used the head version of GCC, gcc-4.5.20091224
to be precise, for testing this abnormally.
I also saw appearance of DIEs duplicates you mention in PR 39524
in the following example:
extern int x;
int main(){x=1;}
gcc 4.3.2 - does NOT have duplicates
gcc 4..4.1 20090725 (REDHAT 4.4.1-2) - does have duplicates
gcc 4.4.2 - does NOT have duplicates
gcc 4.5.20091224 - does have duplicates
Duplicates are in the form described in PR39524.
In the case of this code:
int x;
int main(){x=1;}
I see duplicates in the form of:
<1><54>: Abbrev Number: 4 (DW_TAG_variable)
<55> DW_AT_name: (indirect string, offset: 0x38): x
<59> DW_AT_decl_file : 1
<5a> DW_AT_decl_line : 1
<5b> DW_AT_type: <0x4d>
<5f> DW_AT_external: 1
<60> DW_AT_declaration : 1
<1><61>: Abbrev Number: 5 (DW_TAG_variable)
<62> DW_AT_name: (indirect string, offset: 0x38): x
<66> DW_AT_decl_file : 1
<67> DW_AT_decl_line : 1
<68> DW_AT_type: <0x4d>
<6c> DW_AT_external: 1
<6d> DW_AT_location: 9 byte block: 3 0 0 0 0 0 0 0 0 (DW_OP_addr: 0)
in 4.4.1 and 4.5 releases.
Any idea if this is a correct dwarf? Or must be treated as a duplicate
somehow?
Thanks,
Nenad
On 1/9/10 1:18 PM, Jan Kratochvil wrote:
On Sat, 09 Jan 2010 22:01:54 +0100, Gary Funck wrote:
On 01/09/10 12:39:55, Nenad Vukicevic wrote:
This dwarf code started appearing since this patch:
Here's the GCC bug report that led to this patch:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39563
Such DIEs duplicities are being tracked at:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39524
(Unaware how/if any were caused by the PR 39563.)
Regards,
Jan
Sorry to mention aliasing again, but is the standard IN6_ARE_ADDR_EQUAL really wrong?
Hello,
I don't want to reopen the long-rumbling discussion about what gcc ought to
/want/ to do; I'd just like to know if warning in this case is indeed what it
wants to do. The standard definition of IN6_ARE_ADDR_EQUAL looks a bit like
this:
#define IN6_ARE_ADDR_EQUAL(a, b) \
(((const uint32_t *)(a))[0] == ((const uint32_t *)(b))[0] \
&& ((const uint32_t *)(a))[1] == ((const uint32_t *)(b))[1] \
&& ((const uint32_t *)(a))[2] == ((const uint32_t *)(b))[2] \
&& ((const uint32_t *)(a))[3] == ((const uint32_t *)(b))[3])
That's cygwin's, but glibc is roughly the same (modulo s/const/__const/g).
Anyhow it gives a strict aliasing warning now, that it didn't used to in
4.3.4: reduced testcase is
-
$ cat walias1.c
typedef unsigned char uint8_t;
typedef unsigned int uint32_t;
struct in6_addr
{
uint8_t __s6_addr[16];
};
static inline int
address_in_use (unsigned char *a, struct in6_addr *in6)
{
if const uint32_t *)(a))[0]
== ((const uint32_t *)(in6->__s6_addr))[0]
&& ((const uint32_t *)(a))[1]
== ((const uint32_t *)(in6->__s6_addr))[1]
&& ((const uint32_t *)(a))[2]
== ((const uint32_t *)(in6->__s6_addr))[2]
&& ((const uint32_t *)(a))[3]
== ((const uint32_t *)(in6->__s6_addr))[3]))
return 1;
return 0;
}
ad...@ubik /tmp/warning
$ /usr/bin/gcc-4 -c walias1.c -Wstrict-aliasing -O2
ad...@ubik /tmp/warning
$ gcc-4 -c walias1.c -Wstrict-aliasing -O2
walias1.c: In function 'address_in_use':
walias1.c:14:3: warning: dereferencing type-punned pointer will break
strict-aliasing rules
-
Is that really right? The type of the pointer (in6->__s6_addr) that we're
casting is unsigned char *, so shouldn't it already alias everything anyway
and dereferencing it be allowed, like it is for the casted (a)? I'll file a
PR if so. (I can't pretend I find the language in the spec easy to follow.)
cheers,
DaveK
