Snapshot gcc-6-20161013 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/6-20161013/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 6 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-6
On 10/13/2016 11:42 AM, Prathamesh Kulkarni wrote:
Hi,
I am getting the following error when bootstrapping trunk (tried with r241108)
on x86_64-unknown-linux-gnu during stage-1:
../../../../gcc/libstdc++-v3/src/c++11/compatibility-thread-c++0x.cc:121:12:
error: ISO C++ forbids declaration of \u2
On 13 October 2016 at 20:30, Prathamesh Kulkarni
wrote:
> On 13 October 2016 at 23:12, Prathamesh Kulkarni
> wrote:
>> Hi,
>> I am getting the following error when bootstrapping trunk (tried with
>> r241108)
>> on x86_64-unknown-linux-gnu during stage-1:
>>
>> ../../../../gcc/libstdc++-v3/src/c+
On 13 October 2016 at 23:12, Prathamesh Kulkarni
wrote:
> Hi,
> I am getting the following error when bootstrapping trunk (tried with r241108)
> on x86_64-unknown-linux-gnu during stage-1:
>
> ../../../../gcc/libstdc++-v3/src/c++11/compatibility-thread-c++0x.cc:121:12:
> error: ISO C++ forbids dec
Hi,
I am getting the following error when bootstrapping trunk (tried with r241108)
on x86_64-unknown-linux-gnu during stage-1:
../../../../gcc/libstdc++-v3/src/c++11/compatibility-thread-c++0x.cc:121:12:
error: ISO C++ forbids declaration of \u2018_Bind_simple_helper\u2019
with no type [-fpermissi
Web search shows that -Wmaybe-uninitialized is an imprecise check, and that
boost::optional is already a known sore spot, but I wanted to pass along this
small test case in case the warning's owner wanted to do further improvements.
We solved our one grumpy instance with auto x = make_optio
Attention everyone,
I've just committed a patch to move MEMMODE_* macros and enum memmodel
definitions from coretypes.h to memmodel.h. As a consequence, people who include
emit-rtl.h anywhere or include tm_p.h in the middle end need to include
memmodel.h beforehand. This is because emit-rtl.h
> If set_len really does 'ignore' signedness, then we are not treating X
> as having signedness SGN.
It does not, my interpretation is that it sign-extends when the value is not
already sign-extended, probably for the reason exposed by Richard. But that's
admittedly quite confusing so a comment
On Thu, Oct 13, 2016 at 10:34 AM, Andre Vieira (lists)
wrote:
>
>> That is correct. In RTL constants are always sign-extended from their
>> precision to HOST_BITS_PER_WIDE_INT, regardless if it is "signed" or
>> "unsigned" constant. Whether you treat the low precision bits of the
>> constant as
On 12/10/16 18:59, Eric Botcazou wrote:
>> During the development of a patch I encountered some strange behavior
>> and decided to investigate. The result of which is I think I found a bug
>> with 'wide_int_storage::set_len' in gcc/wide-int.h.
>>
>> The function reads:
>> inline void
>> wide_int_st
> That is correct. In RTL constants are always sign-extended from their
> precision to HOST_BITS_PER_WIDE_INT, regardless if it is "signed" or
> "unsigned" constant. Whether you treat the low precision bits of the
> constant as signed or unsigned is something encoded in the operation on it.
>
>
On Thu, 13 Oct 2016, Prathamesh Kulkarni wrote:
On 12 October 2016 at 14:43, Richard Biener wrote:
On Wed, 12 Oct 2016, Marc Glisse wrote:
On Wed, 12 Oct 2016, Prathamesh Kulkarni wrote:
I was having a look at PR71636 and added the following pattern to match.pd:
x & ((1U << b) - 1) -> x &
On 12 October 2016 at 14:43, Richard Biener wrote:
> On Wed, 12 Oct 2016, Marc Glisse wrote:
>
>> On Wed, 12 Oct 2016, Prathamesh Kulkarni wrote:
>>
>> > I was having a look at PR71636 and added the following pattern to match.pd:
>> > x & ((1U << b) - 1) -> x & ~(~0U << b)
>> > However the transfo
13 matches
Mail list logo
