All TARGET_DEFAULT defines set MASK_FPU. There is no need to set it in
some CPU target flags enable.
gcc/
config/sparc/sparc.c (sparc_option_override): Remove MASK_FPU
from all CPU target flags enable members.
---
gcc/config/sparc/sparc.c | 10 +-
1 file changed, 5 insert
Add the -mfsmuld option to control the generation of the FsMULd
instruction. In general, this instruction is available in architecture
version V8 and V9 CPUs with FPU. Some CPUs of this category do not
support this instruction properly, e.g. AT697E, AT697F and UT699. Some
CPUs of this category d
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the Spanish team of translators. The file is available at:
http://translationproject.org/latest/gcc/es.po
(This file, 'gcc-7.1.0.es.po', has just
And not only the patches to the compiler, I forgot to include the testsuite
patches:
[gcc/testsuite]
2017-07-25 Michael Meissner
* gcc.target/powerpc/vsx-himode.c: Delete -mvsx-small-integer
option.
* gcc.target/powerpc/vsx-himode2.c: Likewise.
* gcc.target/powe
I forgot to include the patch for these changes:
[gcc]
2017-07-25 Michael Meissner
* config/rs6000/rs6000-cpus.def (ISA_2_7_MASKS_SERVER): Delete
-mvsx-small-integer option.
(ISA_3_0_MASKS_IEEE): Likewise.
(POWERPC_MASKS): Likewise.
* config/rs6000/rs600
Next up, the elimination of the -mvsx-small-integer option. This patch is a
little more complex than the previous patches. The -mvsx-small-integer was set
with -mpower8-vector or -mcpu=power8, and it would enable SImode to go into
vector registers. While power7 had the instructions to support 32
This patch to the Go frontend by Than McIntosh adds a new helper
routine Type::finish_pointer_types that walks through the pointer type
cache and looks for placeholder types that may have been created at
some point before conversion of named types, and invokes
Type::finish_backend() on said placeho
On Tue, Jul 25, 2017 at 09:53:21AM -0700, Carl Love wrote:
> /* { dg-do run { target { powerpc*-*-* && { p9vector_hw } } } } */
> /* { dg-skip-if "do not override -mcpu" { powerpc*-*-* } { "-mcpu=*" } {
> "-mcpu=power9" } } */
> /* { dg-options "-mcpu=power9 -O2 -mupper-regs-di" } */
>
> m64 2 t
Hi Mike,
On Tue, Jul 25, 2017 at 09:17:25AM -0400, Michael Meissner wrote:
> This patch eliminates TARGET_UPPER_REGS_DI. I deleted the poison attribute in
> patch #1. I will combine the ChangeLog and submit this patch and the previous
> patch together if approved.
Committing the patches separat
On 07/25/2017 03:25 PM, Wilco Dijkstra wrote:
> Jeff Law wrote:
>
>> My only concern here would be cases where we don't end up eliminating FP
>> to SP. But I'd think it's unlikely that we'd have enough auto-inc
>> opportunities on the frame pointer for it to matter much anyway.
>
> What kind of
On Tue, Jul 25, 2017 at 09:08:23AM -0400, Michael Meissner wrote:
> > After this all is done you can probably simplify the constraints a bit.
> > Looking forward to it :-)
>
> No, we can never remove constraints, since otherwise it would break user
> written asm statements.
As we discussed offlin
On Tue, Jul 25, 2017 at 12:30:13PM +0100, Kyrill Tkachov wrote:
> We sometimes use the __mode__ attribute to force certain sizes in C types.
> For example: typedef int ditype __attribute__ ((mode (DI)));
> Maybe you can do this to force the right sizes. I don't know if there are
> any targets
> th
Jakub Jelinek writes:
> Bootstrapped/regtested on x86_64-linux and i686-linux, where it improves
> e.g. the code generation for slp-43.c and slp-45.c testcases.
> make cc1 tested in cross-compilers to the remaining targets.
No objections for the MIPS part. I've pointed out this change to Sameera
Jeff Law wrote:
> My only concern here would be cases where we don't end up eliminating FP
> to SP. But I'd think it's unlikely that we'd have enough auto-inc
> opportunities on the frame pointer for it to matter much anyway.
What kind of case are you thinking of? Whether it is SP or FP doesn't
Hi Jakub,
On Tue, Jul 25, 2017 at 11:14:32AM +0200, Jakub Jelinek wrote:
> The following patch adjusts the vec_init and vec_extract optabs, so that
> they don't have in the expander names just the vector mode, but also another
> mode, for vec_extract the mode of the result and for vec_init the mod
The standard says that formatted/unformatted input operations should
catch any exceptions, set iostate bits in the istream, and rethrow if
the exception mask says to do so.
We're failing to do that when the exception happens in the
istream::sentry constructor, while it extracts characters to skip
On 07/20/2017 08:49 AM, Wilco Dijkstra wrote:
> Block auto increment on frame pointer references. This is never
> beneficial since the SFP expands into SP+C or FP+C during register
> allocation. The generated code for the testcase is now as expected:
>
> str x30, [sp, -32]!
> str
On 07/25/2017 08:10 AM, Richard Biener wrote:
> On Mon, Jul 17, 2017 at 9:29 AM, Yuri Gribov wrote:
>> Hi all,
>>
>> This is an updated version of patch in
>> https://gcc.gnu.org/ml/gcc-patches/2017-07/msg00409.html . It prevents
>> optimization in presense of sNaNs (and qNaNs when comparison oper
Richard Biener schrieb:
On Mon, Jul 24, 2017 at 10:19 AM, Georg-Johann Lay wrote:
Hi, as proposed in
https://gcc.gnu.org/ml/gcc-patches/2017-07/msg01294.html
this patch does more asprintf -> xasprintf replacements.
Bootstrapped + reg-tested on x86_64-linux.
Ok for trunk?
Ok.
Thanks,
Rich
On 23 Jul, Martin Sebor wrote:
> On 07/23/2017 02:42 PM, Volker Reichelt wrote:
>> On 21 Jul, Martin Sebor wrote:
>>> On 07/20/2017 10:35 AM, Volker Reichelt wrote:
Hi,
the following patch introduces a new C++ warning option
-Wduplicated-access-specifiers that warns about redund
> > 4) tree.c:
> >
> > 13535if (RECORD_OR_UNION_TYPE_P (t) && TYPE_BINFO (t) && TYPE_BINFO
> > (tv)
> > 13536&& TYPE_BINFO (t) != TYPE_BINFO (tv)
> > 13537/* FIXME: Java sometimes keep dump TYPE_BINFOs on variant
> > types.
> > 13538 Since there is no cheap way to
On 25 Jul, Marek Polacek wrote:
> On Sun, Jul 23, 2017 at 11:22:14PM +0200, Volker Reichelt wrote:
> [...]
>
> Not sure if the warning is too useful, but in any case...
>
>> + /* Emit warning. */
>> + gcc_rich_location richloc (token->location);
>> + richloc.add_fixit_remove ();
>> + if (col
I took his "okay" as an approval since he is listed as a maintainer.
-Original Message-
From: Jonathan Wakely [mailto:jwak...@redhat.com]
Sent: Tuesday, July 25, 2017 10:37 AM
To: Michael Collison
Cc: gcc-patches@gcc.gnu.org; libstd...@gcc.gnu.org; nd
Subject: Re: [PATCH v2][Aarch64] Ad
These historical members were finally removed from C++17, so they are
no longer reserved names and should not be declared by the library in
C++17 mode.
* include/bits/ios_base.h (ios_base::io_state, ios_base::open_mode)
(ios_base::seek_dir): Remove for C++17.
* include/std
On Tue, 25 Jul 2017, Richard Biener wrote:
I think we need Richard to say what the intent is for the valueization
function. It is used both to stop looking at defining stmt if the return is
NULL, and to replace/optimize one SSA_NAME with another, but currently it
seems hard to prevent looking at
On 25/07/17 18:33 +0100, Jonathan Wakely wrote:
On 25/07/17 18:31 +0100, Jonathan Wakely wrote:
On 18/07/17 05:53 +, Michael Collison wrote:
This is the second version of a patch for Aarc64 to add a vectorized mersenne twister to
libstdc++. The first version used intrinsics and included "a
On 7/25/17 11:53 AM, Carl Love wrote:
> /* { dg-do run { target { powerpc*-*-* && { p9vector_hw } } } } */
> /* { dg-skip-if "do not override -mcpu" { powerpc*-*-* } { "-mcpu=*" } {
> "-mcpu=power9" } } */
> /* { dg-options "-mcpu=power9 -O2 " } */
>
> With the same results as above. Note, I am
Aldy Hernandez writes:
> + /* Implicit conversion to `unsigned int' returns the number of pairs. */
> + operator unsigned () const { return num_pairs (); }
Yeah, I know I've said it before, but it's a bit of a hobby horse, so...
please, please don't do this! I think it would be far clearer if
On Tue, 2017-07-25 at 06:19 -0500, Segher Boessenkool wrote:
> Hi!
>
> On Mon, Jul 24, 2017 at 01:51:20PM -0700, Carl Love wrote:
> > On Fri, 2017-07-14 at 15:58 -0500, Segher Boessenkool wrote:
> > > On Fri, Jul 14, 2017 at 01:20:32PM -0700, Carl Love wrote:
> > > > --- /dev/null
> > > > +++ b/gc
On Tue, Jul 25, 2017 at 08:50:24AM -0600, Martin Sebor wrote:
> How hard would it be to also suppress the warning for benign
> comparisons like C++ manages to do? E.g., C warns on this
> code even though there's no problem with it:
>
> int foo (unsigned int b)
> {
> const int a = 1;
>
On 07/24/2017 02:25 AM, Jakub Jelinek wrote:
Seems TYPE_METHODS have been left in a couple of spots. For winnt-cxx.c
it apparently causes bootstrap failure (I have no way to test it for that
target, but given that the bootstrap is certainly broken right now, it
can't make things worse) and docum
On 07/24/2017 02:25 AM, Jakub Jelinek wrote:
Seems TYPE_METHODS have been left in a couple of spots. For winnt-cxx.c
it apparently causes bootstrap failure (I have no way to test it for that
target, but given that the bootstrap is certainly broken right now, it
can't make things worse) and docum
On Tue, 25 Jul 2017, Kyrill Tkachov wrote:
> For the uses of this function the order when the bitpos is the same
> does not matter, I just wanted to avoid returning zero to avoid perturbations
> due to qsort.
But you can't stabilize qsort in that manner, in fact by making the comparator
invalid yo
On Tue, Jul 25, 2017 at 11:25:25AM +0200, Robin Dapp wrote:
> Some questions/remarks, comments welcome:
> - ifcvt performs creates things that it expects other passes to clean
> up afterwards. In the case of the superfluous compares this might be
> possible but the code is actually wrong and we c
PR c/81544 complaints that we aren't detecting clashing noreturn /
warn_unused_result attributes so this patch adds that checking. Martin
plans to do more systematic checking in this area but meanwhile we
might want to go with this.
Bootstrapped/regtested on x86_64-linux, ok for trunk?
2017-07-2
Segher Boessenkool writes:
> Hi Richard,
>
> On Wed, Jul 12, 2017 at 05:33:42PM +0100, Richard Sandiford wrote:
>> The little-endian VSX code uses rotates to swap the two 64-bit halves of
>> 128-bit scalar modes. This is fine for TImode and V1TImode, but it
>> isn't really valid to use RTL rotate
On Fri, 2017-07-14 at 15:27 +0200, Marek Polacek wrote:
> On Thu, Jul 13, 2017 at 04:59:20PM -0400, David Malcolm wrote:
> > On Thu, 2017-07-13 at 16:39 -0400, Eric Gallager wrote:
> > > On 7/13/17, David Malcolm wrote:
> > > > On Thu, 2017-07-13 at 18:33 +0200, Marek Polacek wrote:
> > > > > A ti
On 2017/7/25 10:09 PM, Cesar Philippidis wrote:
> On 07/25/2017 05:51 AM, Chung-Lin Tang wrote:
>> On 2017/6/29 6:31 AM, Cesar Philippidis wrote:
>
>> Attached is the updated version of the patch, re-tested.
>>
>> Thomas, do you need some more time to look over it? Or should I commit it
>> first?
On Tue, Jul 25, 2017 at 3:52 PM, H.J. Lu wrote:
> On Fri, Jul 14, 2017 at 4:46 AM, H.J. Lu wrote:
>> On Fri, Jul 7, 2017 at 5:56 PM, H.J. Lu wrote:
>>> On Fri, Jul 07, 2017 at 09:58:42AM -0700, H.J. Lu wrote:
On Fri, Dec 20, 2013 at 8:06 AM, Jakub Jelinek wrote:
> Hi!
>
> Ho
Hi Bill,
On Sun, Jul 23, 2017 at 12:07:37PM -0500, Bill Schmidt wrote:
> Alan added code to have GCC align the .toc section in GCC 7, aligning to
> four bytes for 32-bit mode, and 8 bytes for 64-bit mode. This is normally
> unnecessary since alignment of the .toc has historically been handled by
On 07/25/2017 03:12 AM, Richard Biener wrote:
On Fri, Jul 21, 2017 at 9:30 PM, Aldy Hernandez wrote:
On Mon, Jul 17, 2017 at 6:23 AM, Richard Biener
wrote:
On Mon, Jul 17, 2017 at 8:51 AM, Aldy Hernandez wrote:
How does this look?
It's a change that on its own doesn't look worthwhile to me
How hard would it be to also suppress the warning for benign
comparisons like C++ manages to do? E.g., C warns on this
code even though there's no problem with it:
int foo (unsigned int b)
{
const int a = 1;
return (a < b);
}
Martin
On 07/25/2017 03:45 AM, Marek Polacek wrote:
P
2017-07-25 Uros Bizjak
* config/i386/i386.c (ix86_decompose_address): Do not check for
register RTX when looking at index_reg or base_reg.
* config/i386/i386.h (INCOMING_RETURN_ADDR_RTX): Use stack_pointer_rtx.
Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.
Commit
The attached fix to the Ada front-end introduces a regression in the ACATS
testsuite for cb4009a. The backtrace is:
#0 operation_could_trap_helper_p(tree_code, bool, bool, bool, bool,
tree_node*, bool*) () at /home/eric/gnat/gnat-head/src/gcc/tree-eh.c:2439
#1 0x012946d7 in stmt_could
On 25/07/17 15:42, Eric Botcazou wrote:
What is your opinion with respect to a -mno-fsmuld option or something
similar?
Far better in my opinion (at least for LEON3).
Attached is a variant with this option. It touches a lot more files.
--
Sebastian Huber, embedded brains GmbH
Address : Dor
Backported from trunk as:
https://gcc.gnu.org/r250522
Johann
gcc/
Backport from 2017-07-12 trunk r250151.
PR target/81407
* config/avr/avr.c (avr_encode_section_info)
[progmem && !TREE_READONLY]: Error if progmem object needs
constructing.
Index: config/
On Mon, Jul 24, 2017 at 4:31 PM, Marc Glisse wrote:
> On Mon, 24 Jul 2017, Bin.Cheng wrote:
>
>> On Mon, Jul 24, 2017 at 2:59 PM, Marc Glisse wrote:
>>>
>>> On Mon, 24 Jul 2017, Bin.Cheng wrote:
>>>
But since definition of _197 isn't in current stmt sequence, call "o31
= do_valueize (va
On 25/07/17 16:12, Sebastian Huber wrote:
On 25/07/17 15:42, Eric Botcazou wrote:
What is your opinion with respect to a -mno-fsmuld option or something
similar?
Far better in my opinion (at least for LEON3).
How should I add this option? For example:
diff --git a/gcc/config/sparc/sparc.o
On Fri, Jul 21, 2017 at 5:55 PM, Alexander Monakov wrote:
> Previous revision here:
> https://gcc.gnu.org/ml/gcc-patches/2017-07/msg01090.html
>
> Reassociate X * CST1 * CST2 to X * (CST1 * CST2).
>
> Changed in this revision:
> - remove the check for @2 being 0 or -1
Ok.
Thanks,
Richard.
>
On Fri, Jul 21, 2017 at 5:55 PM, Alexander Monakov wrote:
> Previous revision here:
> https://gcc.gnu.org/ml/gcc-patches/2017-07/msg00889.html
>
> Reassociate (X * CST) * Y to (X * Y) * CST, this pushes constants in
> multiplication chains to outermost factors, where they can be combined.
>
> Cha
On Jul 25 2017, Wilco Dijkstra wrote:
> diff --git a/gcc/testsuite/gcc.target/aarch64/pr79041-2.c
> b/gcc/testsuite/gcc.target/aarch64/pr79041-2.c
> new file mode 100644
> index
> ..cd34fbab85a92d00cba7091d4146deaaf3a862a9
> --- /dev/null
> +++ b/gcc/test
So a new pattern came up assigning to the iterator var of (for var (...)).
Disallow that, likewise protect 'type' (another commonly refered
identifier).
Bootstrap / regtest pending on x86_64-unknown-linux-gnu.
Richard.
2017-07-25 Richard Biener
* genmatch.c (dt_simplify::gen): Make
On 25/07/17 15:42, Eric Botcazou wrote:
What is your opinion with respect to a -mno-fsmuld option or something
similar?
Far better in my opinion (at least for LEON3).
How should I add this option? For example:
diff --git a/gcc/config/sparc/sparc.opt b/gcc/config/sparc/sparc.opt
index ae63d2
On Mon, Jul 17, 2017 at 9:29 AM, Yuri Gribov wrote:
> Hi all,
>
> This is an updated version of patch in
> https://gcc.gnu.org/ml/gcc-patches/2017-07/msg00409.html . It prevents
> optimization in presense of sNaNs (and qNaNs when comparison operator
> is > >= < <=) to preserve FP exceptions.
>
> N
On 07/25/2017 05:51 AM, Chung-Lin Tang wrote:
> On 2017/6/29 6:31 AM, Cesar Philippidis wrote:
> Attached is the updated version of the patch, re-tested.
>
> Thomas, do you need some more time to look over it? Or should I commit it
> first?
I'm not too concerned about the profiling stuff becaus
This patch makes some changes to the frame layout in order to simplify
stack probing. We want to use the save of LR as a probe in any non-leaf
function. With shrinkwrapping we may only save LR before a call, so it
is useful to define a fixed location in the callee-saves. So force LR at
the bottom
On Fri, Jul 14, 2017 at 4:46 AM, H.J. Lu wrote:
> On Fri, Jul 7, 2017 at 5:56 PM, H.J. Lu wrote:
>> On Fri, Jul 07, 2017 at 09:58:42AM -0700, H.J. Lu wrote:
>>> On Fri, Dec 20, 2013 at 8:06 AM, Jakub Jelinek wrote:
>>> > Hi!
>>> >
>>> > Honza recently changed the i?86 backend, so that it often d
On Tue, Jul 25, 2017 at 3:30 PM, Eric Botcazou wrote:
>> Eric, any comments?
>
> No objection for the build2_stat hunk, I think it's in keeping with the Ada
> semantics. But the tree_could_trap_p hunk is certainly an abomination...
>
>> We could also avoid tree_could_trap_p by special-casing only
> What is your opinion with respect to a -mno-fsmuld option or something
> similar?
Far better in my opinion (at least for LEON3).
--
Eric Botcazou
> Yes, everyone using LEON/LEON3 will no longer benefit from the FSMULD
> after this patch. This was discussed with Gaisler. We have to make a
> trade-off between correctness, performance and the number of GCC options.
IMO we shouldn't introduce regressions like this, i.e. people should never be
On 25/07/17 14:59, Sebastian Huber wrote:
On 25/07/17 14:59, Eric Botcazou wrote:
Prominent LEON2 chips like the AT697E and AT697F do not properly
support
the FSMULD instruction. LEON3 targets using the GRFPU-lite floating
point unit do not support the FSMULD in hardware. Disable this
instr
> Eric, any comments?
No objection for the build2_stat hunk, I think it's in keeping with the Ada
semantics. But the tree_could_trap_p hunk is certainly an abomination...
> We could also avoid tree_could_trap_p by special-casing only
> *_DIV_EXPR and *_MOD_EXPR
> with integer zero 2nd operand e
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2017-07-25 Richard Biener
PR tree-optimization/81455
* tree-ssa-loop-unswitch.c (find_loop_guard): Make sure to
not walk in cycles when looking for guards.
* gcc.dg/pr81455.c: New testcase
This fixes an oversight in an earlier patch of mine (SLP of inductions).
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2017-07-25 Richard Biener
PR tree-optimization/81529
* tree-vect-stmts.c (process_use): Disregard live induction PHIs
This patch eliminates TARGET_UPPER_REGS_DI. I deleted the poison attribute in
patch #1. I will combine the ChangeLog and submit this patch and the previous
patch together if approved.
It bootstraps and has no regressions on big endian power7 and little endian
power8. Can I install this patch on
Ramana Radhakrishnan
>
> BZ suggests that this affects GCC 6 but GCC 7 is fixed ? Should there
> be a backport to GCC 6 as well ?
>
> Can you please keep BZ up to date please ?
GCC7 was affected as well, the example in PR79041 didn't trigger in GCC7,
my patch has a better example that does show t
On 7/25/17 1:59 PM, Tamar Christina wrote:
Hi All,
The new ARM options parser generates from the following entry
begin cpu cortex-a55
...
architecture armv8.2-a+fp16+foo
option crypto add FP_ARMv8 CRYPTO
option dotprod add FP_ARMv8 FOO
option nofp remove ALL_FP
...
end cpu cortex-a5
On Tue, Jul 25, 2017 at 1:57 PM, Richard Biener
wrote:
> On Tue, Jul 25, 2017 at 2:38 PM, Bin.Cheng wrote:
>> On Tue, Jul 25, 2017 at 12:48 PM, Richard Biener
>> wrote:
>>> On Mon, Jul 10, 2017 at 10:24 AM, Bin.Cheng wrote:
On Tue, Jun 27, 2017 at 11:49 AM, Bin Cheng wrote:
> Hi,
On Tue, Jul 25, 2017 at 07:34:46AM -0500, Segher Boessenkool wrote:
> Hi Mike,
>
> On Mon, Jul 24, 2017 at 07:40:26PM -0400, Michael Meissner wrote:
> > This patch eliminates the TARGET_UPPER_REGS_{DF,SF} macros. The next patch
> > will eliminate TARGET_UPPER_REGS_DI.
> >
> > I had to tune the o
On Tue, Jul 25, 2017 at 2:19 PM, Marek Polacek wrote:
> On Thu, Jul 20, 2017 at 08:22:59PM +0200, Richard Biener wrote:
>> No, we shouldn't. Maybe trapping ops shouldn't be marked TREE_CONSTANT?
>> (Make sure to test with Ada...)
>
> That works for both testcases, but I can't say I really like th
On Tue, Jul 25, 2017 at 10:12:00AM +0300, Maxim Kuvyrkov wrote:
> >
> > SuSe/Novell choose to do its assignments per engineer, not for the whole
> > company, so I don't think you are covered as is.
>
> Torsten, any update on which way you are going to handle copyright assignment
> -- apply for
Ping.
On 2017/6/22 3:18 PM, Chung-Lin Tang wrote:
> On 2017/6/14 12:00 AM, Jakub Jelinek wrote:
>> I don't see sufficient information on what you want to change and why
>> and whether the changes are backwards compatible (say will a valid
>> OpenACC 2.0 program compiled by GCC 7 work against both
Hi All,
The new ARM options parser generates from the following entry
begin cpu cortex-a55
...
architecture armv8.2-a+fp16+foo
option crypto add FP_ARMv8 CRYPTO
option dotprod add FP_ARMv8 FOO
option nofp remove ALL_FP
...
end cpu cortex-a55
A list of all feature bits that using -mcpu=cort
On 25/07/17 14:59, Eric Botcazou wrote:
Prominent LEON2 chips like the AT697E and AT697F do not properly support
the FSMULD instruction. LEON3 targets using the GRFPU-lite floating
point unit do not support the FSMULD in hardware. Disable this
instruction for for all LEON/LEON3 targets for sim
On Tue, Jul 25, 2017 at 2:38 PM, Bin.Cheng wrote:
> On Tue, Jul 25, 2017 at 12:48 PM, Richard Biener
> wrote:
>> On Mon, Jul 10, 2017 at 10:24 AM, Bin.Cheng wrote:
>>> On Tue, Jun 27, 2017 at 11:49 AM, Bin Cheng wrote:
Hi,
This is a followup patch better handling below case:
> Prominent LEON2 chips like the AT697E and AT697F do not properly support
> the FSMULD instruction. LEON3 targets using the GRFPU-lite floating
> point unit do not support the FSMULD in hardware. Disable this
> instruction for for all LEON/LEON3 targets for simplicity.
And penalize everyone els
On Tue, Jul 25, 2017 at 1:13 PM, Wilco Dijkstra wrote:
> James Greenhalgh wrote:
>>
>> OK. Either like this, or with the conditions swapped around as Yvan
>> suggested to make backporting easier.
>
> I swapped the conditions around, not sure whether it helps...
> Also I needed an additional scan-a
On Tue, Jul 25, 2017 at 10:50 AM, Jakub Jelinek wrote:
> Hi!
>
> As mentioned in the PR, the following testcases ICE if AVX512BW/VL is enabled,
> but AVX512DQ is not. The problem is that for movti_internal we need to use
> vpextrq or vpinsrq instructions to extract or insert the 64-bit reg from
>
On 2017/6/29 6:31 AM, Cesar Philippidis wrote:
> On 06/27/2017 03:56 AM, Chung-Lin Tang wrote:
>> On 2017/6/27 6:45 AM, Cesar Philippidis wrote:
(1) Instead of essentially implementing the entire OpenACC async support
inside the plugin, we now use an opaque 'goacc_asyncqueue' implemented
On Tue, Jul 18, 2017 at 10:38:50AM +0200, Martin Liška wrote:
> 2017-06-27 Martin Liska
>
> PR sanitize/81186
8 spaces instead of tab?
> * function.c (expand_function_start): Set parm_birth_insn after
> static chain is initialized.
I don't like this description, after all
On Tue, Jul 25, 2017 at 12:48 PM, Richard Biener
wrote:
> On Mon, Jul 10, 2017 at 10:24 AM, Bin.Cheng wrote:
>> On Tue, Jun 27, 2017 at 11:49 AM, Bin Cheng wrote:
>>> Hi,
>>> This is a followup patch better handling below case:
>>> for (i = 0; i < n; i++)
>>>{
>>> a[i] = 1;
Hi Mike,
On Mon, Jul 24, 2017 at 07:40:26PM -0400, Michael Meissner wrote:
> This patch eliminates the TARGET_UPPER_REGS_{DF,SF} macros. The next patch
> will eliminate TARGET_UPPER_REGS_DI.
>
> I had to tune the optimization that turned load into FPR register and then
> move
> to Altivec regis
Add 64-bit support for RTEMS using the ELFv2 ABI with 64-bit long
double.
gcc/
* config.gcc (powerpc-*-rtems*): Remove rs6000/eabi.h. Add
rs6000/biarch64.h.
* config/rs6000/rtems.h (ASM_DECLARE_FUNCTION_SIZE): New macro.
(ASM_OUTPUT_SPECIAL_POOL_ENTRY_P): Likewise.
On Thu, Jul 20, 2017 at 08:22:59PM +0200, Richard Biener wrote:
> No, we shouldn't. Maybe trapping ops shouldn't be marked TREE_CONSTANT?
> (Make sure to test with Ada...)
That works for both testcases, but I can't say I really like the idea of
modifying build2... but it's where the TREE_CONSTANT
James Greenhalgh wrote:
>
> OK. Either like this, or with the conditions swapped around as Yvan
> suggested to make backporting easier.
I swapped the conditions around, not sure whether it helps...
Also I needed an additional scan-assembler, this was committed to
trunk and GCC7:
diff --git a/gcc/
On Tue, Jul 25, 2017 at 01:45:31PM +0200, Marek Polacek wrote:
> > This patch doesn't do anything about anon struct/union/class, I've tried
> > to handle it, the problem is that ANON_AGGR_TYPE_P flag is set too late,
> > after the debug hook adds the type DIE. Any thoughts on how to handle that?
>
On Sun, Jul 23, 2017 at 11:22:14PM +0200, Volker Reichelt wrote:
[...]
Not sure if the warning is too useful, but in any case...
> + /* Emit warning. */
> + gcc_rich_location richloc (token->location);
> + richloc.add_fixit_remove ();
> + if (colon_token->type == CPP_COLON)
> +richloc.ad
...also backported to gcc-6-branch:
https://gcc.gnu.org/r250511
Johann
gcc/
Backport from 2017-05-06 trunk r247719.
PR rtl-optimization/75964
* simplify-rtx.c (simplify_const_relational_operation): Remove
invalid handling of comparisons of integer ABS.
gcc/testsuite/
B
On Tue, Jul 11, 2017 at 4:35 PM, Martin Liška wrote:
> Hi.
>
> There's a small follow-up with remaining occurrences:
>
> 1) dwarf2out.c:
>
> 20213 origin_die = lookup_type_die (origin);
> 20214else if (TREE_CODE (origin) == BLOCK)
> 20215 origin_die = BLOCK_DIE (origin);
> 20216
No need to use a dedicated variable if we can use RECORD_OR_UNION_TYPE_P
directly and only once.
Bootstrapped/regtested on x86_64-linux, applying to trunk.
2017-07-25 Marek Polacek
* c-decl.c (grokfield): Remove local variable.
diff --git gcc/c/c-decl.c gcc/c/c-decl.c
index 50da185e3
On Mon, Jul 10, 2017 at 10:24 AM, Bin.Cheng wrote:
> On Tue, Jun 27, 2017 at 11:49 AM, Bin Cheng wrote:
>> Hi,
>> This is a followup patch better handling below case:
>> for (i = 0; i < n; i++)
>>{
>> a[i] = 1;
>> a[i+2] = 2;
>>}
>> Instead of generating roo
On Fri, Jul 21, 2017 at 10:33:12PM +0200, Jakub Jelinek wrote:
> Hi!
>
> DWARF5 introduced DW_AT_export_symbols that may be preset on
> DW_TAG_namespace or DW_TAG_{structure,union,class}_type to signalize
> inline or anonymous namespaces or anonymous structures/unions/classes.
>
> What we were em
On Mon, Jul 24, 2017 at 4:27 PM, Bin.Cheng wrote:
> Ping^1.
Ok.
Thanks and sorry for the delay.
Richard.
> Thanks,
> bin
>
> On Mon, Jul 10, 2017 at 9:23 AM, Bin.Cheng wrote:
>> On Tue, Jul 4, 2017 at 1:29 PM, Richard Biener
>> wrote:
>>> On Tue, Jul 4, 2017 at 2:06 PM, Bin.Cheng wrote:
Prominent LEON2 chips like the AT697E and AT697F do not properly support
the FSMULD instruction. LEON3 targets using the GRFPU-lite floating
point unit do not support the FSMULD in hardware. Disable this
instruction for for all LEON/LEON3 targets for simplicity.
This leads to a code size increas
Backported to v7:
https://gcc.gnu.org/r250509
Johann
gcc/
Backport from 2017-05-06 trunk r247719.
PR rtl-optimization/75964
* simplify-rtx.c (simplify_const_relational_operation): Remove
invalid handling of comparisons of integer ABS.
gcc/testsuite/
Back
Hi,
>> I haven't been clear in what I was asking for
Sorry. We understood right with the first comment but the second
part confused us a bit :).
>> Could you switch this back to an insn_and_split as it was in the previous
>> patch, and just drop the && reload_completed ?
Done.
Bootstrapped and
Status
==
It's time to do a GCC 7.2 release and thus please check if you have
backports for regression or wrong-code bugs pending. The plan is to
do GCC 7.2 RC1 mid next week and a release roughly a week after that.
Quality Data
Priority # Change from last report
-
On 24/07/17 09:50, Segher Boessenkool wrote:
On Wed, Jul 19, 2017 at 12:19:32AM -0600, Jeff Law wrote:
On 07/18/2017 01:36 PM, Segher Boessenkool wrote:
* simplify-rtx.c (simplify_truncation): Handle truncating an IOR
with a constant that is -1 in the truncated to mode.
OK. A
Rainer reports uint64_t clashes, so avoid it.
Tested on x86_64-unknown-linux-gnu, applied.
Richard.
2017-07-25 Richard Biener
PR tree-optimization/81410
* gcc.dg/vect/pr81410.c: Do not typedef uint64_t.
Index: gcc/testsuite/gcc.dg/vect/pr81410.c
On Mon, Jul 24, 2017 at 04:06:39PM -0600, Jeff Law wrote:
> > 2017-07-24 Segher Boessenkool
> >
> > gcc/testsuite/
> > PR rtl-optimization/81423
> > * gcc.c-torture/execute/pr81423.c: New testcase.
> I think int32plus just indicates ints are at least 32 bits. But a long
> or long long c
1 - 100 of 134 matches
Mail list logo
