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
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,
> 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
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
-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:
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, tha
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
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 probl
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
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 confir
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
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 architect
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 do
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.
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 u
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’ whi
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 lim
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
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)
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 vis
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 verifi
21 matches
Mail list logo
