On 2016.09.30 at 23:31 +0200, Marek Polacek wrote:
> This PR reports a bogus -Wimplicit-fallthrough warning on the attached test.
> The problem is that last_stmt_in_scope should for GIMPLE_TRY, if the last
> statement of the eval part can't fallthrough, return this statement and don't
> warn. And
It looks like my email being sent from my company is being dropped, re sending
via my gmail account.
Doug
From: Doug Gilmore
Sent: Friday, September 30, 2016 6:35 PM
To: gcc-patches@gcc.gnu.org; Christophe Lyon
Subject: Fix PR tree-optimization/77808, ICE i
It looks like my original message was dropped, resending -- Doug
From: Doug Gilmore
Sent: Friday, September 30, 2016 6:35 PM
To: gcc-patches@gcc.gnu.org; Christophe Lyon
Subject: Fix PR tree-optimization/77808, ICE in duplicate_ssa_name_ptr_info, at
tree-ss
My commit r240439 didn't handle the situation where setting
--param prefetch-latency=0 can cause the prefetch address to
be the same as the original address. In this case, no
copying of points-to information should be done.
Bootstrapped and regression tested on x86_64-linux, ok for
trunk?
Doug
F
On Fri, Sep 23, 2016 at 12:44:22PM +0200, Marek Polacek wrote:
> 2016-09-23 Marek Polacek
>
> PR c/77490
...
> * c-c++-common/Wbool-operation-1.c: New test.
I've noticed this test fails on i686-linux and likely also on powerpc-linux.
Fixed thusly, committed to trunk as obvious:
2
On Fri, Sep 30, 2016 at 05:32:31PM -0400, Jason Merrill wrote:
> On Fri, Sep 30, 2016 at 4:10 AM, Jakub Jelinek wrote:
> > On Thu, Sep 29, 2016 at 10:57:07PM +, Joseph Myers wrote:
> >> This is missing documentation of the new -Wregister option in invoke.texi.
> >
> > While I had it in my head
Committed r240686
M gcc/testsuite/ChangeLog
M gcc/testsuite/gfortran.fortran-torture/compile/write.f90
M gcc/testsuite/gfortran.fortran-torture/compile/arrayio.f90
M gcc/fortran/ChangeLog
M gcc/fortran/io.c
as obvious and trivi
Jakub Jelinek writes:
> 2016-09-30 Jakub Jelinek
>
> * configure.ac: Add target-libffi to target_libraries.
> Readd libgcj target disablings, modified to only target-libffi.
> Readd target addition of go to unsupported languages.
> * configure: Regenerated.
This is OK.
Hi Eric,
>> I haven't tried to readd the boehm-gc objc support that has also been
>> disabled, don't know about anybody using that.
>
> I always configure with --enable-objc-gc. The only reason Apple
> deprecated garbage collection for Objective C is because they replaced
> it with Automated Refer
On Mon, 2016-09-26 at 14:30 +, Bernd Edlinger wrote:
> Hi,
>
> this started, because I saw get_next_line returns -1 on error,
> instead
> of false: PR 77699.
>
> But when I was there I also saw that read_line_num is using memmove
> on
> non-aliased src & dest, instead of memcpy. But then I s
On 09/30/2016 01:40 PM, Marek Polacek wrote:
On Fri, Sep 30, 2016 at 01:08:19PM -0600, Martin Sebor wrote:
On 09/30/2016 11:05 AM, Martin Sebor wrote:
+permerror (input_location, "ISO C++11 only allows pointer "
+ "conversions for integer literals");
FWIW, I think it wou
On Fri, Sep 30, 2016 at 12:43 PM, Marek Polacek wrote:
> On Fri, Sep 23, 2016 at 10:31:33AM -0400, Jason Merrill wrote:
>> On Fri, Sep 23, 2016 at 9:15 AM, Marek Polacek wrote:
>> > On Wed, Sep 21, 2016 at 03:52:09PM -0400, Jason Merrill wrote:
>> >> On Mon, Sep 19, 2016 at 2:49 PM, Jason Merrill
On Sep 30, 2016, at 10:34 AM, Jeff Law wrote:
>> 2016-09-30 James Greenhalgh
>>
>> * gcc.dg/fpermitted-flt-eval-methods_1.c: New.
>> * gcc.dg/fpermitted-flt-eval-methods_2.c: New.
> OK.Are you going to need to do something for C++ (or gasp ObjC) in the
> future
ObjC should come
On Fri, Sep 30, 2016 at 7:10 AM, Bernd Schmidt wrote:
> On 09/30/2016 12:51 PM, Jakub Jelinek wrote:
>> On Fri, Sep 30, 2016 at 12:42:20PM +0200, Bernd Schmidt wrote:
>>> On 09/30/2016 11:45 AM, Jakub Jelinek wrote:
>>>
See Tom Tromey's explanation why accepting too much is bad (at least
On Fri, Sep 30, 2016 at 4:10 AM, Jakub Jelinek wrote:
> Hi!
>
> On Thu, Sep 29, 2016 at 10:57:07PM +, Joseph Myers wrote:
>> This is missing documentation of the new -Wregister option in invoke.texi.
>
> While I had it in my head when working on the patch, I forgot to do that in
> the end.
>
This PR reports a bogus -Wimplicit-fallthrough warning on the attached test.
The problem is that last_stmt_in_scope should for GIMPLE_TRY, if the last
statement of the eval part can't fallthrough, return this statement and don't
warn. And the same should be true for FALLTHROUGH (). This patch fi
I do this with a rather heavy heart, but since gcc6 compiles boost 1.62,
I'll rather have gcc7 do so as well, and I'll throw the tuple fix for lwg2729
to the wolves not because I want to, but because I have to.
Tested on Linux-x64.
2016-10-01 Ville Voutilainen
PR libstdc++/77802
* te
On Thu, Sep 29, 2016 at 06:21:13PM +0200, Marek Polacek wrote:
> On Tue, Sep 27, 2016 at 09:58:20PM +0200, Jakub Jelinek wrote:
> > On Tue, Sep 27, 2016 at 09:29:10PM +0200, Florian Weimer wrote:
> > > Not sure if I read this code correctly, but if we fall through from
> > > V32HImode, and we have
Hi!
As discussed earlier on IRC, the current way of registering target specific
passes has various issues:
1) for -da, the target specific dump files appear last, regardless on where
exactly they appear in the pass queue, so one has to look up the sources
or remember where the pass is invoke
On Fri, Sep 30, 2016 at 11:26:27AM +0200, Marek Polacek wrote:
> I haven't gone over the patch in detail yet, but I wonder if we should
> also accept /* Else, fall through. */ (to be found e.g. in aarch64-simd.md).
Here is the patch split into a series of 3 patches (the later patches depend
on th
On Feb 11 2016, Kelvin Nilsen wrote:
> * opts-global.c (handle_common_deferred_options): Introduce and
> initialize two global variables to remember command-line options
> specifying a stack-limiting register.
> * opts.h: Add extern declarations of the two new global v
On 9/30/16, Jakub Jelinek wrote:
> Hi!
>
> On Fri, Sep 30, 2016 at 01:48:12PM +0100, Andrew Haley wrote:
>> On 30/09/16 11:27, Marek Polacek wrote:
>> > Can we move forward with this patch, then?
>>
>> I've been travelling for several weeks. However, I'm back at my desk
>> now, so I can move this
On Fri, Sep 30, 2016 at 01:08:19PM -0600, Martin Sebor wrote:
> On 09/30/2016 11:05 AM, Martin Sebor wrote:
> > > +permerror (input_location, "ISO C++11 only allows pointer "
> > > + "conversions for integer literals");
> >
> > FWIW, I think it would be clearer to either ment
On 09/30/2016 11:05 AM, Martin Sebor wrote:
+permerror (input_location, "ISO C++11 only allows pointer "
+ "conversions for integer literals");
FWIW, I think it would be clearer to either mention the currently
selected language version or leave it out completely rather tha
On Fri, Sep 30, 2016 at 07:07:22PM +0200, Jan-Benedict Glaw wrote:
> When building for --target=sparc-leon-elf (using config-list.mk) with
> a current GCC, I get this error message (cf.
> http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=632317):
>
> g++ -fno-PIE -c -g -O2 -DIN_GCC
Hi!
On Fri, Sep 30, 2016 at 01:48:12PM +0100, Andrew Haley wrote:
> On 30/09/16 11:27, Marek Polacek wrote:
> > Can we move forward with this patch, then?
>
> I've been travelling for several weeks. However, I'm back at my desk
> now, so I can move this forward. I have all the approvals and
> e
This patch updates my email address from sell...@imgtec.com to
sell...@caviumnetworks.com
Steve Ellcey
sell...@caviumnetworks.com
2016-09-30 Steve Ellcey
* MAINTAINERS: Update email address.
Index: MAINTAINERS
===
--
The code I wrote to determine partitions on auto loops was too complicated,
making it hard for me to figure out the changes needed for tiling. I've
committed this patch, which doesn't do such egregious bit twiddling.
nathan
2016-09-30 Nathan Sidwell
* omp-low.c (oacc_loop_auto_partition):
On 30/09/16 12:08 +0100, Jonathan Wakely wrote:
As noted in Bugzilla (and pointed out in LLVM's bugzilla by Richard
Smith) we check for a ::gets() declaration with the default
-std=gnu++14 mode, so for glibc we don't find it, and then we declare
it ourselves in even though it's not meant to exis
On 30 September 2016 at 20:10, Doug Gilmore wrote:
>> From: Christophe Lyon [christophe.l...@linaro.org]
>> Sent: Thursday, September 29, 2016 12:17 PM
>> To: Matthew Fortune
>> Cc: Doug Gilmore; Richard Biener; gcc-patches@gcc.gnu.org;
>> rgue...@gcc.gnu.org
>> Subject: Re: [PATCH] Fix PR tree-o
> From: Christophe Lyon [christophe.l...@linaro.org]
> Sent: Thursday, September 29, 2016 12:17 PM
> To: Matthew Fortune
> Cc: Doug Gilmore; Richard Biener; gcc-patches@gcc.gnu.org; rgue...@gcc.gnu.org
> Subject: Re: [PATCH] Fix PR tree-optimization/77654
>
> On 23 September 2016 at 17:55, Matthew
On Sep 30 2016, James Greenhalgh wrote:
> * config/m68k/m68k.c (m68k_excess_precision): New.
> (TARGET_C_EXCESS_PRECISION): Define.
Ok.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something
On Fri, 30 Sep 2016, Jeff Law wrote:
> On 09/30/2016 11:34 AM, Joseph Myers wrote:
> > On Fri, 30 Sep 2016, James Greenhalgh wrote:
> >
> > > + case EXCESS_PRECISION_TYPE_STANDARD:
> > > + case EXCESS_PRECISION_TYPE_IMPLICIT:
> > > + /* Otherwise, the excess precision we want when we ar
This change drops forced alignment to 8 if requested alignment is higher
than 8: before the patch, -falign-functions=9 was generating
.p2align 4,,8
.p2align 3
which means: "align to 16 if the skip is 8 bytes or less; else align to 8".
After this change, ".p2align 3" is not emitted
falign-functions=N is too simplistic.
Ingo Molnar ran some tests and it seems that on latest x86 CPUs, 64-byte
alignment
of functions runs fastest (he tried many other possibilites):
this way, after a call CPU can fetch a lot of insns in the first cacheline fill.
However, developers are less tha
These patches are for this bug:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66240
"RFE: extend -falign-xyz syntax"
The test program:
int g();
int f(int i) {
i *= 3;
while (--i > 100) {
L1:if (g()) goto L1;
if (g()) goto L2;
}
return i
2016-09-27 Denys Vlasenko
* config/i386/i386-common.c (ix86_handle_option): Remove support
for obsolete -malign-loops, -malign-jumps and -malign-functions
options.
* config/i386/i386.opt: Likewise.
Index: gcc/common/config/i386/i386-common.c
On 09/30/2016 11:34 AM, Joseph Myers wrote:
On Fri, 30 Sep 2016, James Greenhalgh wrote:
+ case EXCESS_PRECISION_TYPE_STANDARD:
+ case EXCESS_PRECISION_TYPE_IMPLICIT:
+ /* Otherwise, the excess precision we want when we are
+ in a standards compliant mode, and the impli
PR 66443 concerns C++14 DR1611. It is now permitted to use the base-ctor of an
abstract class whos complete ctor is deleted because of a virtual base issue.
Specifically, given
class A {
A (int);
// no default ctor in C++14
};
class B : virtual A {
virtual void Foo () = 0; // abstract
//
On Fri, 30 Sep 2016, James Greenhalgh wrote:
> + case EXCESS_PRECISION_TYPE_STANDARD:
> + case EXCESS_PRECISION_TYPE_IMPLICIT:
> + /* Otherwise, the excess precision we want when we are
> +in a standards compliant mode, and the implicit precision we
> +provide can be
On 09/30/2016 10:56 AM, James Greenhalgh wrote:
Hi,
This option is added to control which values of FLT_EVAL_METHOD the
compiler is allowed to set.
ISO/IEC TS 18661-3 defines new permissible values for
FLT_EVAL_METHOD that indicate that operations and constants with
a semantic type that is an
On Fri, 30 Sep 2016, James Greenhalgh wrote:
>/* float.h needs to know this. */
> + /* We already have the option -fno-fp-int-builtin-inexact to ensure
> + certain built-in functions follow TS 18661-1 semantics. It might be
> + reasonable to have a new option to enable FLT_EVAL_METH
On 09/30/2016 10:56 AM, James Greenhalgh wrote:
Hi,
Now that we've worked on -fexcess-precision, the comment in targhooks.c
no longer holds. We can now permit _Float16 on any target which provides
HFmode and supports HFmode in libgcc.
Bootstrapped and tested on x86-64, and in series on AArch64
On 09/30/2016 11:01 AM, James Greenhalgh wrote:
Hi,
This patch ports the logic from m68k's TARGET_FLT_EVAL_METHOD to the new
target hook TARGET_C_EXCESS_PRECISION.
Patch tested by building an m68k-none-elf toolchain and running
m68k.exp (without the ability to execute) with no regressions, and
On 09/30/2016 10:56 AM, James Greenhalgh wrote:
Hi,
We've removed all uses of TARGET_FLT_EVAL_METHOD, so we can remove it
and poison it.
Bootstrapped and tested on x86-64 and AArch64. Tested on s390 and m68k
to the best of my ability (no execute tests).
OK?
Thanks,
James
---
gcc/
2016-09-3
On 09/29/2016 12:34 AM, Prasad Ghangal wrote:
Hi all,
I don't know if this is the right time to submit such patches.
But this patch attempts to fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31566
I have successfully bootstrapped and tested on x86_64-pc-linux-gnu
testcases:
file:
-Wall
te
On 09/25/2016 03:13 AM, Bernd Edlinger wrote:
Hi!
Currently CHECKING_P is not a boolean flag but a ternary option.
However the _P in the name implies it is a boolean.
That should be cleaned up again IMHO.
So this patch splits CHECKING_P into CHECKING_P and a new flag
ENABLE_EXTRA_CHECKING.
+ permerror (input_location, "ISO C++11 only allows pointer "
+ "conversions for integer literals");
FWIW, I think it would be clearer to either mention the currently
selected language version or leave it out completely rather than
hardcoding C++11. When t
Hi,
This patch enables the conversion functions we need for AArch64's _Float16
support. To do that we need to implement TARGET_SCALAR_MODE_SUPPORTED_P,
so do that now.
OK?
Thanks,
James
---
gcc/
2016-09-30 James Greenhalgh
* config/aarch64/aarch64-c.c (aarch64_scalar_mode_supporte
Hi,
This patch merges in the support added to glibc for HFmode conversions in
this patch:
commit 87ab10d6524fe4faabd7eb3eac5868165ecfb323
Author: James Greenhalgh
Date: Wed Sep 21 21:02:54 2016 +
[soft-fp] Add support for various half-precision conversion routines.
Hi,
Finally, this patch adds the back-end wiring to get AArch64 support for
the _Float16 type working.
Bootstrapped on AArch64 with no issues.
OK?
Thanks,
James
---
2016-09-30 James Greenhalgh
* config/aarch64/aarch64-c.c (aarch64_update_cpp_builtins): Update
__FLT_EVAL_ME
Hi,
This patch merges in the support added to glibc for HFmode conversions in
this patch:
commit 87ab10d6524fe4faabd7eb3eac5868165ecfb323
Author: James Greenhalgh
Date: Wed Sep 21 21:02:54 2016 +
[soft-fp] Add support for various half-precision conversion routines.
Hi,
This patch ports the logic from m68k's TARGET_FLT_EVAL_METHOD to the new
target hook TARGET_C_EXCESS_PRECISION.
Patch tested by building an m68k-none-elf toolchain and running
m68k.exp (without the ability to execute) with no regressions, and manually
inspecting the output assembly code when
On September 30, 2016 4:43:10 PM GMT+02:00, Kyrill Tkachov
wrote:
>
>On 30/09/16 15:36, Kyrill Tkachov wrote:
>> Hi Richard,
>>
>> On 29/09/16 11:45, Richard Biener wrote:
>>>
+
+ /* In some cases get_inner_reference may return a
+ MEM_REF [ptr + byteoffset]. For
Hi,
This patch ports the logic from s390's TARGET_FLT_EVAL_METHOD to the new
target hook TARGET_C_EXCESS_PRECISION.
Patch tested by building an s390-none-linux toolchain and running
s390.exp (without the ability to execute) with no regressions, and manually
inspecting the output assembly code wh
Hi,
This patch ports the logic from i386's TARGET_FLT_EVAL_METHOD to the new
target hook TARGET_C_EXCESS_PRECISION.
Bootstrapped and tested with no issues.
OK?
Thanks,
James
---
gcc/
2016-09-30 James Greenhalgh
* config/i386/i386.c (ix86_excess_precision): New.
(TARGET_C_
Hi Richard,
On 29/09/16 11:45, Richard Biener wrote:
+ gimple_seq seq = NULL;
+ unsigned int num_stmts = 0;
+ tree offset_type = get_type_for_merged_store (group);
+ tree last_vdef, new_vuse;
+ last_vdef = gimple_vdef (group->last_stmt);
+ new_vuse = gimple_vuse (group->last_stmt);
+ loc
Hi,
We've removed all uses of TARGET_FLT_EVAL_METHOD, so we can remove it
and poison it.
Bootstrapped and tested on x86-64 and AArch64. Tested on s390 and m68k
to the best of my ability (no execute tests).
OK?
Thanks,
James
---
gcc/
2016-09-30 James Greenhalgh
* config/s390/s390.
Hi,
This patch moves the logic for excess precision from using the
TARGET_FLT_EVAL_METHOD macro to the TARGET_EXCESS_PRECISION hook
introduced earlier in the patch series.
These logic changes follow Joseph's comments at
https://gcc.gnu.org/ml/gcc-patches/2016-09/msg00410.html
Briefly; we have f
Hi,
Now that we've worked on -fexcess-precision, the comment in targhooks.c
no longer holds. We can now permit _Float16 on any target which provides
HFmode and supports HFmode in libgcc.
Bootstrapped and tested on x86-64, and in series on AArch64.
OK?
Thanks,
James
---
2016-09-30 James Green
Hi,
This patch introduces TARGET_C_EXCESS_PRECISION. This hook takes a tri-state
argument, one of EXCESS_PRECISION_TYPE_IMPLICIT,
EXCESS_PRECISION_TYPE_STANDARD, EXCESS_PRECISION_TYPE_FAST. Which relate to
the implicit extra precision added by the target, the excess precision that
should be guara
Hi,
This option is added to control which values of FLT_EVAL_METHOD the
compiler is allowed to set.
ISO/IEC TS 18661-3 defines new permissible values for
FLT_EVAL_METHOD that indicate that operations and constants with
a semantic type that is an interchange or extended format should be
evaluated
Hi,
This patch set enables the _Float16 type specified in ISO/IEC TS 18661-3
for AArch64.
To do this, we first need to update the excess precision logic to support
possibly computing _Float16 values in 16-bit range and precision, and to
set the FLT_EVAL_METHOD macro to "16" as appropriate. That r
On Fri, Sep 30, 2016 at 06:49:17PM +0200, Jan-Benedict Glaw wrote:
> On Thu, 2016-09-29 18:01:46 +0200, Marek Polacek wrote:
> > My upcoming fix revealed more places that were missing a fall through
> > marker.
> >
> > Bootstrapped/regtested on x86_64-linux, ppc64-linux, and aarch64-linux-gnu
>
On 09/29/2016 09:21 PM, Tadek Kijkowski wrote:
Can I have plain-text mode, please, gmail?
:-) Only because you're asking nicely...
# Directory in which the compiler finds libraries etc.
libsubdir =
$(libdir)/gcc/$(real_target_noncanonical)/$(version)$(accel_dir_suffix)
# Directory in whi
On Thu, 2016-09-29 18:01:46 +0200, Marek Polacek wrote:
> My upcoming fix revealed more places that were missing a fall through marker.
>
> Bootstrapped/regtested on x86_64-linux, ppc64-linux, and aarch64-linux-gnu
> with
> my fix, applying to trunk.
>
> 2016-09-29 Marek Polacek
>
> *
On Fri, Sep 23, 2016 at 10:31:33AM -0400, Jason Merrill wrote:
> On Fri, Sep 23, 2016 at 9:15 AM, Marek Polacek wrote:
> > On Wed, Sep 21, 2016 at 03:52:09PM -0400, Jason Merrill wrote:
> >> On Mon, Sep 19, 2016 at 2:49 PM, Jason Merrill wrote:
> >> > I suppose that an INTEGER_CST of character ty
On 30/09/16 17:38, Rainer Orth wrote:
> but both Per and Tom are still libcpp maintainers, so no need to add
> them to the write-after-approval list.
Ooh, I had no idea. Will fix, thanks.
Andrew.
Hi Andrew,
> Pushed.
>
> 2016-09-30 Andrew Haley
>
> * MAINTAINERS: Move Per Bothner, Andrew Haley, and Tom Tromey to
> write-after approval after GCJ deletion.
but both Per and Tom are still libcpp maintainers, so no need to add
them to the write-after-approval list.
On 09/30/2016 10:18 AM, Bruce Korb wrote:
Hi Tadek,
Looks good to me. Thank you.
Clear to send (push).
Committed on behalf of Tadek.
Thanks,
jeff
Pushed.
2016-09-30 Andrew Haley
* MAINTAINERS: Move Per Bothner, Andrew Haley, and Tom Tromey to
write-after approval after GCJ deletion.
Index: MAINTAINERS
===
--- MAINTAINERS (revision 240658)
+++ MAINTAINERS (w
On Fri, Sep 30, 2016 at 10:10:55AM -0600, Martin Sebor wrote:
> I haven't been following the discussion very closely so I may have
> missed that what I'm about to suggest has been discussed and rejected
> for some valid reason, but if not let me try.
>
> It seems to me that the ultimate, long term
Hi Tadek,
Looks good to me. Thank you.
Clear to send (push).
I haven't been following the discussion very closely so I may have
missed that what I'm about to suggest has been discussed and rejected
for some valid reason, but if not let me try.
It seems to me that the ultimate, long term goal should be to have
actively maintained code bases gradually migrat
On 29/09/16 21:59 +0200, François Dumont wrote:
Hi
I think _GLIBCXX_BEGIN_NAMESPACE_ALGO should default to
_GLIBCXX_BEGIN_NAMESPACE_VERSION when parallel mode is not active.
Same for _GLIBCXX_BEGIN_NAMESPACE_CONTAINER, no ?
Hmm, yes, I think this is correct, otherwise we're missing the VE
On 05/09/16 17:25, Gerald Pfeifer wrote:
> And here is the patch for the web pages.
>
> Note I did not include all the removed java/* contents. Is there
> anything particular you'd like to retain there?
No, please delete it all.
Thanks,
Andrew.
On 09/30/2016 01:20 PM, Bernd Schmidt wrote:
On 09/29/2016 07:32 PM, Denys Vlasenko wrote:
On 09/29/2016 04:45 PM, Bernd Schmidt wrote:
On 09/28/2016 02:57 PM, Denys Vlasenko wrote:
- /* Comes from final.c -- no real reason to change it. */
-#define MAX_CODE_ALIGN 16
-
case OPT_malign_l
On 30/09/16 15:36, Kyrill Tkachov wrote:
Hi Richard,
On 29/09/16 11:45, Richard Biener wrote:
+
+ /* In some cases get_inner_reference may return a
+ MEM_REF [ptr + byteoffset]. For the purposes of this pass
+ canonicalize the base_addr to MEM_REF [ptr] and take
+
Hi Richard,
On 29/09/16 11:45, Richard Biener wrote:
+
+ /* In some cases get_inner_reference may return a
+MEM_REF [ptr + byteoffset]. For the purposes of this pass
+canonicalize the base_addr to MEM_REF [ptr] and take
+byteoffset i
In implementing tile I discovered two existing runtime tile tests. These were
only passing because tile was completely ignored. One of them exposes a latent
bug in collapse, in my WIP, but I don't want to get distracted by that right now.
Better to have tile tests test tile tiles.
nathan
201
Please find the updated patch,
Claudiu
gcc/
2016-05-09 Claudiu Zissulescu
* common/config/arc/arc-common.c (arc_option_optimization_table):
Remove compact casesi option.
* config/arc/arc.c (arc_override_options): Use compact casesi
option only for pre-ARCv2 core
This patch to libgo copies the locking code from the Go 1.7 master
library, replacing C code for locking with Go code. The result is
more efficient on most systems, though it is essentially the same on
GNU/Linux.
Add a shell script mkrsysinfo.sh to generate the runtime_sysinfo.go
file, so that we
std::abs isn't suitable for these functions because we need something
that works in constexpr functions and with unsigned types.
Also, is supposed to include .
PR libstdc++/77801
* include/experimental/numeric: Include .
(__abs): Define.
(gcd, lcm): Use __abs ins
On 09/30/16 12:14, Bernd Edlinger wrote:
> Eric Botcazou wrote:
>>> A comment before the SETs and a testcase would be nice. IIRC
>>> we do have stack size testcases via using -fstack-usage.
>>
>> Or -Wstack-usage, which might be more appropriate here.
>
> Yes. good idea. I was not aware that we
Hi All,
This is v2 of the patch which adds an optimized route to the fpclassify builtin
for floating point numbers which are similar to IEEE-754 in format.
I have addressed most comments from everyone except for two things:
1) Providing a back-end hook to override the functionality. While certai
On 30/09/16 14:13 +0100, Szabolcs Nagy wrote:
On 30/09/16 10:35, Szabolcs Nagy wrote:
On 29/09/16 14:37, Andre Vieira (lists) wrote:
On arm-none-eabi I'm seeing a failure for the long double type and inputs:
{ 1e-2l, 1e-4l, 1e-4l, 0.0150004999375l }
The abs(frac) is higher than the to
On 30/09/16 10:35, Szabolcs Nagy wrote:
> On 29/09/16 14:37, Andre Vieira (lists) wrote:
>>
>> On arm-none-eabi I'm seeing a failure for the long double type and inputs:
>> { 1e-2l, 1e-4l, 1e-4l, 0.0150004999375l }
>>
>> The abs(frac) is higher than the toler: 1.73455e-16 vs 1e-16. Is that
On 30/09/16 10:31, Matthew Wahab wrote:
The recently added tests gcc.target/arm/aapcs-{3,4}.c are intended
to check the behaviour of th ARM Alternative FP16 format. They both
check for compiler support of FP16 using dg-require-effective-target
arm_fp16_ok This is too weak since the directive is
Hi Martin,
> On 09/30/2016 02:31 PM, Rainer Orth wrote:
>> this would be i386-pc-solaris2.12. I'm not sure if the constructor
>> priority detection works in a cross scenario.
>>
>> I'm attaching the resulting assembly (although for Solaris as, the gas
>> build is still running).
>
> Hi. Sorry, I
On 30/09/16 11:27, Marek Polacek wrote:
> Can we move forward with this patch, then?
I've been travelling for several weeks. However, I'm back at my desk
now, so I can move this forward. I have all the approvals and
everybody has had time to respond. However, I'll need to pull some
more recent
On 09/30/2016 02:31 PM, Rainer Orth wrote:
> this would be i386-pc-solaris2.12. I'm not sure if the constructor
> priority detection works in a cross scenario.
>
> I'm attaching the resulting assembly (although for Solaris as, the gas
> build is still running).
Hi. Sorry, I have a stupid mistake
.long .LCFI33-.LFB1056
.byte 0xe
.byte 0x10
.byte 0x86
.byte 0x2
.byte 0x4
.long .LCFI34-.LCFI33
.byte 0xd
.byte 0x6
.byte 0x4
.long .LCFI35-.LCFI34
.byte 0xc
.byte 0x7
.byte 0x8
.align 8
.LEFDE23:
.hidden __dso_handle
.ident "GCC: (GNU) 7.0.0 20160930 (experimental) [trunk revision
240649]"
.section.text._ZN4TestC2Ev%_ZN4TestC5Ev,"ax",@progbits
_ZN4TestC5Ev:
.section.text._ZN4TestD2Ev%_ZN4TestD5Ev,"ax",@progbits
_ZN4TestD5Ev:
On Fri, Sep 30, 2016 at 2:26 PM, Jonathan Wakely wrote:
> This adjusts the front page and the news page for each release to
> clarify that past releases are no longer maintained.
>
> OK for wwwdocs?
Ok.
Thanks,
Richard.
>
This adjusts the front page and the news page for each release to
clarify that past releases are no longer maintained.
OK for wwwdocs?
Index: htdocs/index.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/index.html,v
retrieving revision
In working on tile I noticed an unnecessary modulo operation for the calculation
of the outermost loop's user iteration variable. By construction the modulo
operator is useless here. Took the opportunity of moving the modulo and
division operations next to eachother so it'd be easier to make u
On 09/30/16 05:22, Rainer Orth wrote:
While this would take care of the testsuite failures, this creates a
terrible user experience outside of the testsuite: if we know that
-fprofile-arcs -ftest-coverage cannot work on targets without
constructor priority support, the compiler should error out
It's unclear whether we'll handle /* Else, fall through. */ in the nearest
future, so I'll just change it to a recognizable format instead.
When this is in, I can remove the recently added -Wno-error lines in
Makefile.in.
Bootstrapped on aarch64-linux. I'm checking this in.
2016-09-30 Marek
On 09/29/2016 07:32 PM, Denys Vlasenko wrote:
On 09/29/2016 04:45 PM, Bernd Schmidt wrote:
On 09/28/2016 02:57 PM, Denys Vlasenko wrote:
- /* Comes from final.c -- no real reason to change it. */
-#define MAX_CODE_ALIGN 16
-
case OPT_malign_loops_:
warning_at (loc, 0, "-malign-loo
On 09/30/2016 11:22 AM, Rainer Orth wrote:
> Hi Martin,
>
>>> the testcase FAILs on Solaris 12 (both SPARC and x86):
>>>
>>> +FAIL: g++.dg/gcov/pr16855.C -std=gnu++11 gcov: 1 failures in line
>>> counts, 0 i
>>> n branch percentages, 0 in return percentages, 0 in intermediate format
>>> +FAIL: g++
On Fri, Sep 30, 2016 at 12:42:20PM +0200, Bernd Schmidt wrote:
> On 09/30/2016 11:45 AM, Jakub Jelinek wrote:
>
> > See Tom Tromey's explanation why accepting too much is bad (at least unless
> > we want multiple levels).
>
> And I still don't buy it. The case where someone writes "Don't fall thr
1 - 100 of 135 matches
Mail list logo
