revision r181278 gives me a bootstrap/build error on cygwin for gcc trunk: cc1: warning: unrecognized command line option "-Wno-narrowing"
revision r181278 gives me a bootstrap/build error on cygwin for gcc trunk like this gcc-4 -c -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat -fno-common -DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -I/usr/include -I/usr/include -I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/bid -I../libdecnumber../../gcc/gcc/varasm.c -o varasm.o ../../gcc/gcc/varasm.c: In function 'default_elf_asm_output_limited_string': ../../gcc/gcc/varasm.c:7534:16: error: 'ELF_ASCII_ESCAPES' undeclared (first use in this function) ../../gcc/gcc/varasm.c:7534:16: note: each undeclared identifier is reported only once for each function it appears in ../../gcc/gcc/varasm.c: In function 'default_elf_asm_output_ascii': ../../gcc/gcc/varasm.c:7586:42: error: 'ELF_STRING_LIMIT' undeclared (first use in this function) ../../gcc/gcc/varasm.c:7601:13: error: 'ASCII_DATA_ASM_OP' undeclared (first use in this function) ../../gcc/gcc/varasm.c:7601:31: error: expected ')' before string constant ../../gcc/gcc/varasm.c:7601:31: error: too few arguments to function 'fputs' ../../gcc/gcc/varasm.c:7604:13: error: 'ELF_ASCII_ESCAPES' undeclared (first use in this function) At top level: cc1: warning: unrecognized command line option "-Wno-narrowing" make[3]: *** [varasm.o] Error 1 make[3]: *** Waiting for unfinished jobs make[3]: Leaving directory `/usr/local/src/trunk/objdir/gcc' make[2]: *** [all-stage1-gcc] Error 2 make[2]: Leaving directory `/usr/local/src/trunk/objdir' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/usr/local/src/trunk/objdir' make: *** [all] Error 2 backing off to the prior revision gives me no error like that... -- Cheers, /ChJ
Re: revision r181278 gives me a bootstrap/build error on cygwin for gcc trunk: cc1: warning: unrecognized command line option "-Wno-narrowing"
Hi, > revision r181278 gives me a bootstrap/build error on cygwin for gcc > trunk like this Just to make sure nobody is midled by th subject of your message: your bootstrap problem obviously has nothing to do with the warning itself. The latter has been discussed already on these mailing lists, is absolutely bening. Paolo
Re: revision r181278 gives me a bootstrap/build error on cygwin for gcc trunk: cc1: warning: unrecognized command line option "-Wno-narrowing"
> Just to make sure nobody is midled by th subject of your message: > your bootstrap problem obviously has nothing to do with the warning itself. > The latter has been discussed already on these mailing lists, is absolutely > bening. I have open pr51094 for this bootstrap failure. Note that it is due to r181279 (r181278 is a date bump). Cheers, Dominique
Re: revision r181278 gives me a bootstrap/build error on cygwin for gcc trunk: cc1: warning: unrecognized command line option "-Wno-narrowing"
On 11/11/2011 07:02 AM, Christian Jönsson wrote: revision r181278 gives me a bootstrap/build error on cygwin for gcc trunk like this I've now conditioned those functions on the macro being defined. Does that fix it for you? Jason
Continue strict-volatile-bitfields fixes
-fstrict-volatile-bitfields doesn't work incorrectly in some cases
when storing into a volatile bit-field.
Bernd provided a fix here about 1 year ago:
http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00217.html.
But it is pending to trunk. Here are my humble opinions and hopefully
we can revive it:
1. The fix could have helped lots of those who use volatile bit-fields,
but has been blocked for 1 year by ABI version 1, a feature that I believe
no one nowadays is using with latest gcc. Either error out ABI version 1
for some target, or just revising the failed ABI test case is OK for me.
2. This bug impacts all targets, especially target with
strict-volatile-bitfields default enabled like ARM. The test case Bernd
provided can be revised to a target independent case.
+++ gcc/testsuite/gcc.dg/volatile-bitfields-4.c (revision 0)
@@ -0,0 +1,15 @@
+/* { dg-do run } */
+/* { dg-options "-fstrict-volatile-bitfields" } */
+
+extern void abort(void);
+struct thing {
+ volatile unsigned short a: 8;
+ volatile unsigned short b: 8;
+} t = {1,2};
+
+int main()
+{
+ t.a = 3;
+ if (t.a !=3 || t.b !=2) abort();
+ return 0;
+}
Re: revision r181278 gives me a bootstrap/build error on cygwin for gcc trunk: cc1: warning: unrecognized command line option "-Wno-narrowing"
Den 11 november 2011 16:30 skrev Jason Merrill: > On 11/11/2011 07:02 AM, Christian Jönsson wrote: >> >> revision r181278 gives me a bootstrap/build error on cygwin for gcc >> trunk like this > > I've now conditioned those functions on the macro being defined. Does that > fix it for you? yup, thanks. -- Cheers, /ChJ
Re: [PATCH, testsuite]: Do not run simulate-thread on alpha*-*-linux*
Hi Uros, Is your patch dealing with gcc.dg/simulate-thread/atomic-other-* running for ever without timeout? If yes, I have seen the same problem on powerpc-apple-darwin9. Could you add powerpc*-apple-darwin* to your patch? TIA Dominique
Re: [PATCH, testsuite]: Do not run simulate-thread on alpha*-*-linux*
On Fri, Nov 11, 2011 at 6:51 PM, Dominique Dhumieres wrote: > Is your patch dealing with gcc.dg/simulate-thread/atomic-other-* running > for ever without timeout? If yes, I have seen the same problem on > powerpc-apple-darwin9. Could you add powerpc*-apple-darwin* to your > patch? Yes, the problem is with atomic-other-*. Looking at [1], I think that this problem will bite all LL/SC targets (alpha, powerpc, MIPS and ARM), so we should start with generic alpha*-*-* and powerpc*-*-* target selectors ... [1] http://en.wikipedia.org/wiki/LL/SC Uros.
Re: [PATCH, testsuite]: Do not run simulate-thread on alpha*-*-linux*
For the record, Jakub's comment on IRC: > with older gdb you simply had to find the stwcx > or whatever SC insn is, put a breakpoint after > it and continue instead of single stepping Dominique
Re: [PATCH v2 9/10] Tilera (and Linux asm-generic) support for glibc
On 11/11/2011 1:09 PM, Roland McGrath wrote:
2011-11-09 Chris Metcalf
* bits/byteswap.h (__bswap*): Use __builtin_bswap for gcc 4.3 and
above. Improves code generation for gcc 4.3 and 4.4 compilers
without bswap pattern detection.
This seems reasonable if some GCC folks can confirm that 4.3 and later
produce optimal code for __builtin_bswap{32,64} on all machines.
I'm cc'ing the gcc mailing list with this reply, so if someone there
can provide an authoritative statement, that would be great. It looks
like right now the i386/x86_64, ia64, and s390 architecture don't use
this header anyway, so it's less important for them. But powerpc and
sparc do use the header (in the core glibc), and most of the
architectures in the "ports" part of glibc do as well.
Roland, Joseph, if we don't hear something definitive from the gcc
folks, I'm inclined to revert this piece back to what I had in the v1
patch, where I provide a tile-specific byteswap.h using
__builtin_bswapNN(), so our gcc 4.4 will generate good code.
--
Chris Metcalf, Tilera Corp.
http://www.tilera.com
Re: [PATCH v2 9/10] Tilera (and Linux asm-generic) support for glibc
On Fri, Nov 11, 2011 at 12:13 PM, Chris Metcalf wrote: > I'm cc'ing the gcc mailing list with this reply, so if someone there > can provide an authoritative statement, that would be great. It looks > like right now the i386/x86_64, ia64, and s390 architecture don't use > this header anyway, so it's less important for them. But powerpc and > sparc do use the header (in the core glibc), and most of the > architectures in the "ports" part of glibc do as well. > > Roland, Joseph, if we don't hear something definitive from the gcc > folks, I'm inclined to revert this piece back to what I had in the v1 > patch, where I provide a tile-specific byteswap.h using > __builtin_bswapNN(), so our gcc 4.4 will generate good code. Right now it does not emit good code for MIPS 32/64 R2. Though I have patches to emit better code for that target. Thanks, Andrew Pinski
Re: [PATCH v2 9/10] Tilera (and Linux asm-generic) support for glibc
On 11/11/2011 3:17 PM, Andrew Pinski wrote: On Fri, Nov 11, 2011 at 12:13 PM, Chris Metcalf wrote: I'm cc'ing the gcc mailing list with this reply, so if someone there can provide an authoritative statement, that would be great. It looks like right now the i386/x86_64, ia64, and s390 architecture don't use this header anyway, so it's less important for them. But powerpc and sparc do use the header (in the core glibc), and most of the architectures in the "ports" part of glibc do as well. Roland, Joseph, if we don't hear something definitive from the gcc folks, I'm inclined to revert this piece back to what I had in the v1 patch, where I provide a tile-specific byteswap.h using __builtin_bswapNN(), so our gcc 4.4 will generate good code. Right now it does not emit good code for MIPS 32/64 R2. Though I have patches to emit better code for that target. In retrospect, I guess the right question is not whether it produces bad code per se, but whether it produces worse code than for the standard generic byteswap.h: #define __bswap_16(x) \ x)>> 8)& 0xff) | (((x)& 0xff)<< 8)) #define __bswap_32(x) \ x)& 0xff00)>> 24) | (((x)& 0x00ff)>> 8) | \ (((x)& 0xff00)<< 8) | (((x)& 0x00ff)<< 24)) #define __bswap_64(x) \ x)& 0xff00ull)>> 56) \ | (((x)& 0x00ffull)>> 40) \ | (((x)& 0xff00ull)>> 24) \ | (((x)& 0x00ffull)>> 8) \ | (((x)& 0xff00ull)<< 8) \ | (((x)& 0x00ffull)<< 24) \ | (((x)& 0xff00ull)<< 40) \ | (((x)& 0x00ffull)<< 56)) (The 16-bit swap would be done via __builtin_bswap32(x)>> 16.) If it's no worse for any platform, and better for some, that's probably sufficient reason to make the change in glibc to use it. -- Chris Metcalf, Tilera Corp. http://www.tilera.com
Re: [PATCH v2 9/10] Tilera (and Linux asm-generic) support for glibc
On Fri, Nov 11, 2011 at 12:41 PM, Chris Metcalf wrote: > (The 16-bit swap would be done via __builtin_bswap32(x)>> 16.) > If it's no worse for any platform, and better for some, that's > probably sufficient reason to make the change in glibc to use it. It does produce worse code if the target does not implement the patterns because the function is not inlined by default. It produces a call to bswapsi and bswapdi. Thanks, Andrew Pinski
Re: gcc vs. glibc bootstrapping of libgcc_eh.a
Thanks Mike, silly me, it seems that crosstool_ng is exactly what I need! Off-topic, but .. anyone have a clue about why my canadian-cross of gcc is picking up its own internal limits.h, instead of glibc's limits.h? Since gcc's limits.h doesn't have ‘SSIZE_MAX’ which gcc/config/host-linux.c wants. I suppose I can just google the answer, can't I? --linas On 9 November 2011 20:49, Mike Frysinger wrote: > comes up every few years > http://sourceware.org/ml/libc-help/2011-08/msg00073.html > -mike >
Re: [PATCH v2 9/10] Tilera (and Linux asm-generic) support for glibc
On Fri, 11 Nov 2011, Andrew Pinski wrote: > On Fri, Nov 11, 2011 at 12:41 PM, Chris Metcalf wrote: > > (The 16-bit swap would be done via __builtin_bswap32(x)>> 16.) > > If it's no worse for any platform, and better for some, that's > > probably sufficient reason to make the change in glibc to use it. > > It does produce worse code if the target does not implement the > patterns because the function is not inlined by default. It produces > a call to bswapsi and bswapdi. Out-of-line does not necessarily mean "worse"; it will be slower in isolation, but probably results in smaller code size (for bswap32 and bswap64, that is) and for most code in practice it seems reduced cache usage produces speed gains that outweigh local slowdown from smaller code. -- Joseph S. Myers jos...@codesourcery.com
Re: gcc vs. glibc bootstrapping of libgcc_eh.a
Linas Vepstas writes: > Thanks Mike, silly me, it seems that crosstool_ng is exactly what I need! > > Off-topic, but .. anyone have a clue about why my canadian-cross of > gcc is picking up its own internal limits.h, instead of glibc's > limits.h? Since gcc's limits.h doesn't have ‘SSIZE_MAX’ which > gcc/config/host-linux.c wants. I suppose I can just google the > answer, can't I? To clarify, your Canadian Cross should always be using gcc's internal limits.h, so that is not surprising. The right question is why the internal limits.h does not have a #include_next of the glibc limits.h (via syslimits.h). I don't know the answer in your case, but I do know that the test for whether there is a system limits.h, and that therefore gcc should use a #include_next, is a fragile one. Ian
Re: gcc vs. glibc bootstrapping of libgcc_eh.a
On Friday 11 November 2011 16:27:18 Linas Vepstas wrote: > Thanks Mike, silly me, it seems that crosstool_ng is exactly what I need! > > Off-topic, but .. anyone have a clue about why my canadian-cross of > gcc is picking up its own internal limits.h, instead of glibc's > limits.h? Since gcc's limits.h doesn't have ‘SSIZE_MAX’ which > gcc/config/host-linux.c wants. I suppose I can just google the > answer, can't I? gcc is supposed to provide a limits.h. but at the end of that file, it does: #include_next this way you get both the gcc and the glibc defines. what you're asking about is semi-common, but it's been so long since i solved that issue that i don't remember the answer off the top of my head. i do know that crosstool-ng takes care of it for you ;). -mike signature.asc Description: This is a digitally signed message part.
gcc-4.6-20111111 is now available
Snapshot gcc-4.6-2011 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-2011/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.6 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_6-branch revision 181301 You'll find: gcc-4.6-2011.tar.bz2 Complete GCC MD5=bf0f2b5a5a3482accdad6c763134cd88 SHA1=2f609d9a9244059aaaf242c54ede53e8e48bb95e Diffs from 4.6-2004 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.6 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
bootstrap regression on sparc
While building libstdc++ I get an assertion failure in haifa-sched.c, specifically the assertion on line 3437 is failing: gcc_assert (!jump_p || ((common_sched_info->sched_pass_id == SCHED_RGN_PASS) && IS_SPECULATION_BRANCHY_CHECK_P (insn)) || (common_sched_info->sched_pass_id == SCHED_EBB_PASS)); I haven't looked more deeply at it, but the first recent suspicious change are the basic block handling changes Alan made two days ago: 2011-11-09 Alan Modra * function.c (bb_active_p): Delete. (dup_block_and_redirect, active_insn_between): New functions. (convert_jumps_to_returns, emit_return_for_exit): New functions, split out from.. (thread_prologue_and_epilogue_insns): ..here. Delete shadowing variables. Don't do prologue register clobber tests when shrink wrapping already failed. Delete all last_bb_active code. Instead compute tail block candidates for duplicating exit path. Remove these from antic set. Duplicate tails when reached from both blocks needing a prologue/epilogue and blocks not needing such. * ifcvt.c (dead_or_predicable): Test both flag_shrink_wrap and HAVE_simple_return. * bb-reorder.c (get_uncond_jump_length): Make global. * bb-reorder.h (get_uncond_jump_length): Declare. * cfgrtl.c (rtl_create_basic_block): Comment typo fix. (rtl_split_edge): Likewise. Warning fix. (rtl_duplicate_bb): New function. (rtl_cfg_hooks): Enable can_duplicate_block_p and duplicate_block. * Makefile.in (function.o): Update dependencies.
Re: Delegating Constructors?
Jason Merrill writes: >> Hmm, has he been contacted recently? The original patch was from ages >> ago... > > Yes, I've been in communication with him and the FSF. I expect this > to be sorted out soon so we can put in the patch. Cool, thanks! -miles -- Cynic, n. A blackguard whose faulty vision sees things as they are, not as they ought to be. Hence the custom among the Scythians of plucking out a cynic's eyes to improve his vision.
Re: bootstrap regression on sparc
From: David Miller Date: Fri, 11 Nov 2011 20:41:23 -0500 (EST) > I haven't looked more deeply at it, but the first recent suspicious change > are the basic block handling changes Alan made two days ago: > > 2011-11-09 Alan Modra > > * function.c (bb_active_p): Delete. ... I've verified that the bootstrap succeeds with this change reverted.
