On Tue, 1 Jul 2014, Jonathan Wakely wrote:
> On 1 July 2014 20:58, John David Anglin wrote:
> > On 1-Jul-14, at 5:32 AM, Jonathan Wakely wrote:
> >
> >> On 1 July 2014 09:40, Matthias Klose wrote:
> >>>
> >>> - HPPA (build log [2]), is missing all the future_base symbols and
> >>> exception_ptr1
On Thu, Jul 03, 2014 at 07:52:59PM +0200, Tobias Grosser wrote:
> On 03/07/2014 19:23, Roman Gareev wrote:
> >Dear gcc contributors,
> >
> >could you please answer a few questions about std::map? Does gcc have
> >a policy that forbids using of map in the source code of gcc? Can this
> >using create
Snapshot gcc-4.8-20140703 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.8-20140703/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.8 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On 03/07/2014 19:23, Roman Gareev wrote:
Dear gcc contributors,
could you please answer a few questions about std::map? Does gcc have
a policy that forbids using of map in the source code of gcc? Can this
using create a new installation dependency, which requires libstdc++?
I would be very grate
On 03/07/2014 19:24, Roman Gareev wrote:
However, this form doesn't have loop guards which are generated by
>>graphite_create_new_loop_guard in gcc/graphite-isl-ast-to-gimple.c and
>>by graphite_create_new_loop_guard in graphite-clast-to-gimple.c.
>
>
>Maybe the guards are directly constant fold
On 07/03/2014 07:11 PM, Marek Polacek wrote:
On Thu, Jul 03, 2014 at 07:06:29PM +0200, Toon Moene wrote:
Compiler version: 4.10.0 20140702 (experimental) (GCC)
Platform: x86_64-unknown-linux-gnu
configure flags: --prefix=/home/toon/compilers/install --with-gnu-as
--with-gnu-ld --with-build-conf
>> However, this form doesn't have loop guards which are generated by
>> graphite_create_new_loop_guard in gcc/graphite-isl-ast-to-gimple.c and
>> by graphite_create_new_loop_guard in graphite-clast-to-gimple.c.
>
>
> Maybe the guards are directly constant folded? Can you try with:
I've tried this
Dear gcc contributors,
could you please answer a few questions about std::map? Does gcc have
a policy that forbids using of map in the source code of gcc? Can this
using create a new installation dependency, which requires libstdc++?
I would be very grateful for your comments.
--
On Thu, Jul 03, 2014 at 07:06:29PM +0200, Toon Moene wrote:
> Compiler version: 4.10.0 20140702 (experimental) (GCC)
> Platform: x86_64-unknown-linux-gnu
> configure flags: --prefix=/home/toon/compilers/install --with-gnu-as
> --with-gnu-ld --with-build-config=bootstrap-ubsan --enable-languages=all
Compiler version: 4.10.0 20140702 (experimental) (GCC)
Platform: x86_64-unknown-linux-gnu
configure flags: --prefix=/home/toon/compilers/install --with-gnu-as
--with-gnu-ld --with-build-config=bootstrap-ubsan --enable-languages=all
--disable-multilib --disable-nls --with-arch=core-avx2 --with-tu
On Jul 3 2014, Uros Bizjak wrote:
Maybe a new hook should be introduced instead: TARGET_IEEE_FORMAT_P
(mode). For some targets, even soft-fp supports required rounding
modes and can generate exceptions.
Before doing anything, it would be a good idea to decide on what IEEE
conformance means. T
On Thu, Jul 3, 2014 at 9:14 AM, Uros Bizjak wrote:
> On Wed, Jul 2, 2014 at 11:13 PM, FX wrote:
>> I’ve recently added IEEE support for the Fortran front-end and library. As
>> part of that, the front-end should be able to determine which of the
>> available floating-point types are IEEE-confor
On Wed, Jul 2, 2014 at 11:13 PM, FX wrote:
> I’ve recently added IEEE support for the Fortran front-end and library. As
> part of that, the front-end should be able to determine which of the
> available floating-point types are IEEE-conforming [1]. Right now, I’ve taken
> a conservative approac
13 matches
Mail list logo