Hi,
Following patch has not been reviewed for two weeks. I think the
patch is trivial,
it doesn't affect other parts of GCC.
https://gcc.gnu.org/ml/gcc-patches/2018-05/msg01005.html
And I don't have write permission to GCC
Thanks
Zhouyi
On Mon, May 21, 2018 at 12:09 PM, Zhouyi Zhou
On Sun, 3 Jun 2018, Jakub Jelinek wrote:
> Hi!
>
> We canonicalize x < type_max_val (type (x)) as x != type_max_val (type (x))
> and similarly for x > type_min_val (type (x)). Unfortunately the former
> form is what is often more beneficial for merge_ranges, if we have as in the
> testcase e.g.
https://gcc.gnu.org/ml/gcc-patches/2018-04/msg01172.html
Thanks in advance.
--
Eric Botcazou
Hi,
the previous patch makes it possible to merge bit-field stores whose RHS is a
constant or a SSA name, but there is a hitch: if the SSA name is the result of
an "interesting" load, then the optimization is blocked. That's because the
GIMPLE store-merging pass not only attempts to merge
On Sun, 3 Jun 2018, Jakub Jelinek wrote:
> Hi!
>
> The second argument of OMP_CRITICAL is IDENTIFIER_NODE, but we were ICEing
> on that with -Wduplicate-branches, because we didn't know how to hash it.
> operand_equal_p handles it the way it should, only pointer equal
> IDENTIFIER_NODEs are the
On Fri, 1 Jun 2018, Joseph Myers wrote:
> On Fri, 1 Jun 2018, Michael Meissner wrote:
>
> > I'm wondering if there are other suggestions to make this patch acceptable.
> >
> > As I mentioned previously, the initialization process needs to go through
> > all
> > of the widening tables in order
Hi,
On 01/06/2018, 23:29, Jason Merrill wrote:
On Fri, Jun 1, 2018 at 5:03 PM, Paolo Carlini wrote:
while working on some bugs I noticed that in a few places in decl.c we could
do better in terms of locations within the current infrastructure, some
simple, straightforward improvements. I'm
The XScale cpu configuration in GCC has always been somewhat
non-conforming. Although XScale isn't an architecture (it's simply an
implementation of ARMv5te), we do by tradition emit a specific
pre-define for it. We achieve this effect by adding an additional
feature bit to the xscale CPU
On 04/06/18 00:51, Gerald Pfeifer wrote:
One suggestion: Since you follow a "latest first" for the entries in
the file, would it make sense to follow the same order for patch
summaries/commit messages as well?
Sure. I'll reverse the sort order in the summary for the next update.
-tgc
On 05/21/2018 07:19 PM, Jason Merrill wrote:
> On Mon, May 21, 2018 at 9:33 AM, Martin Liška wrote:
>> On 10/24/2017 10:24 PM, Jason Merrill wrote:
>>> On Thu, Sep 14, 2017 at 5:22 AM, Martin Liška wrote:
On 08/10/2017 09:43 PM, Jason Merrill wrote:
> On 07/14/2017 01:35 AM, Martin
My patch for 84785 started setting processing_template_decl while
substituting into a default template argument that might use template
parameters we don't yet have arguments for. That broke this testcase
because when processing_template_decl is set, we don't actually try to
perform the
Hi,
This patch implements Tremont -march/-mtune.
2018-06-04 Olga Makhotina
gcc/
* config.gcc: Support "tremont".
* config/i386/driver-i386.c (host_detect_local_cpu): Detect "tremont".
* config/i386/i386-c.c (ix86_target_macros_internal): Handle
Hi!
On Wed, May 23, 2018 at 08:45:19AM +0200, Jakub Jelinek wrote:
> As mentioned in the PR, vptestm* instructions with the same input operand used
> twice perform the same comparison as vpcmpeq* against zero vector, with the
> advantage that a register holding CONST0_RTX (mode) is not needed.
>
On Sat, Jun 2, 2018 at 12:22 AM David Malcolm wrote:
>
> On Fri, 2018-06-01 at 17:31 +0200, Richard Biener wrote:
> > On June 1, 2018 3:40:15 PM GMT+02:00, David Malcolm > com> wrote:
> > > On Fri, 2018-06-01 at 11:50 +0200, Richard Biener wrote:
> > > > On Tue, May 29, 2018 at 10:33 PM David
On Mon, Jun 4, 2018 at 3:08 PM, Jakub Jelinek wrote:
> Hi!
>
> On Wed, May 23, 2018 at 08:45:19AM +0200, Jakub Jelinek wrote:
>> As mentioned in the PR, vptestm* instructions with the same input operand
>> used
>> twice perform the same comparison as vpcmpeq* against zero vector, with the
>>
This inlines a function to make the flow clearer.
Bootstrapped / tested on x86_64-unknown-linux-gnu, applied.
Richard.
2018-06-04 Richard Biener
* tree-cfgcleanup.c (cleanup_tree_cfg_1): Fold into...
(cleanup_tree_cfg_noloop): ... single caller. Do
Hi,
when building with --with-tune=zEC12 and calling the resulting gcc with
--march=z13 (no extra -mtune), the binary would unexpectedly be compiled
with -march=z13 -mtune=zEC12. This patch avoids using the default tune
parameter if -march is specified as argument but the user can still
Hi!
In OpenMP 5.0, although the simd loop iteration vars are still predetermined
linear (for non-collapsed loops or collapse(1)) or lastprivate (collapse>1),
one can explicitly make the iteration variable private or lastprivate;
especially the former is useful to make it clear nothing needs to be
Hi!
In the PR we have insns:
Trying 23 -> 24:
23: r123:SI=zero_extend(r122:HI)
REG_DEAD r122:HI
24: [r115:SI]=r123:SI
REG_DEAD r123:SI
which should be combined to
(set (mem:SI (reg/f:SI 115 [ pretmp_19 ]) [1 *pretmp_19+0 S4 A32])
(and:SI (subreg:SI (reg:HI 122) 0)
On Wed, May 30, 2018 at 8:46 AM Richard Sandiford
wrote:>
> The handling of bitfield references in expand_expr_real_1 includes:
>
> machine_mode ext_mode = mode;
>
> if (ext_mode == BLKmode
> && ! (target != 0 && MEM_P (op0)
> && MEM_P
On Wed, May 30, 2018 at 7:54 AM, H.J. Lu wrote:
> In glibc, sysdeps/i386/nptl/tls.h has
>
> typedef struct
> {
> void *tcb;/* Pointer to the TCB. Not necessarily the
>thread descriptor used by libpthread. */
> dtv_t *dtv;
> void *self; /*
On Mon, Jun 4, 2018 at 8:32 AM Eric Botcazou wrote:
>
> Hi,
>
> the previous patch makes it possible to merge bit-field stores whose RHS is a
> constant or a SSA name, but there is a hitch: if the SSA name is the result of
> an "interesting" load, then the optimization is blocked. That's because
On Mon, Jun 4, 2018 at 10:18 AM Kugan Vivekanandarajah
wrote:
>
> Hi Richard,
>
> Thanks for the review.
>
> On 1 June 2018 at 22:20, Richard Biener wrote:
> > On Fri, Jun 1, 2018 at 4:12 AM Kugan Vivekanandarajah
> > wrote:
> >>
> >> Hi Richard,
> >>
> >> This is the revised patch based on the
Hi Nicolas,
I have applied your patch on top of revision r261130 on x86_64-apple-darwin17
(SSD with APFS file system).
The only remaining failure on my own tests is for the test (pr35840)
write(10,*, asynchronous="Y"//"E"//trim("S "))
end
giving at run time
At line 1 of file pr35840.f90
Hi,
Since pre-Icelake ISA already had 128bit version vpclmul and vaes, we already
have intrinsics for them(_mm_aesdec_si128, _mm_aesdeclast_si128,
_mm_aesenc_si128, _mm_aesenclast_si128, _mm_clmulepi64_si128). Therefore
intrinsics for them, introduced with Icelake instructions are redundant.
Hi Richard,
Thanks for the review.
On 1 June 2018 at 22:20, Richard Biener wrote:
> On Fri, Jun 1, 2018 at 4:12 AM Kugan Vivekanandarajah
> wrote:
>>
>> Hi Richard,
>>
>> This is the revised patch based on the review and the discussion in
>> https://gcc.gnu.org/ml/gcc/2018-05/msg00179.html.
>>
[ was: Re: [MAINTAINERS, committed] Update email address ]
On 06/02/2018 10:28 AM, Gerald Pfeifer wrote:
Hi Tom,
On Fri, 1 Jun 2018, tdevries wrote:
I've updated my email address in the MAINTAINERS file.
it looks you're still in the Write After Approval section while
also being listed as
PING^1
On 05/25/2018 01:36 PM, Martin Liška wrote:
> Hi.
>
> As requested by Eric, let's print working directory just in intermediate
> format:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84846#c8
>
> gcov.exp tests works with the patch.
>
> Ready for trunk?
> Martin
>
> gcc/ChangeLog:
>
On Wed, 30 May 2018, Jan Hubicka wrote:
> >
> > This makes tracer not explode with -fno-guess-branch-probabilities.
> > I've settled with find_best_successor/predecessor not returning
> > anything if _any_ edge in the interesting direction doesn't have
> > ->count () initialized (rather than
On 04/06/18 18:52, DJ Delorie wrote:
Jozef Lawrynowicz writes:
For the currently released msp430i* devices, only digits follow the i, so no
upper or lower case conversion is needed.
Thinking of the future... do we expect any new devices with letters?
Should we plan for them? Or better to
On Mon, Jun 04, 2018 at 11:03:49AM -0500, Kelvin Nilsen wrote:
> The existing documentation incorrectly specifies that the second argument of
> vec_lvsl and vec_lvsr instructions are volatile *. This patch removes
> the volatile qualifier from the documentation of these arguments.
>
> his
Hi
I'd like to propose this patch to avoid std::distance calls. In a number
of situation in algos we already have the size of the buffer we need so
we shouldn't have to compute it again.
I don't think there is any abi concern for this inline constructor,
isn't there ?
*
On Mon, Jun 04, 2018 at 02:37:20PM -0500, Kelvin Nilsen wrote:
>
> This patch removes extraneous line breaks to condense the number of lines
> require in the "PowerPC AltiVec Built-in Functions" section of the gcc.pdf
> manual by about 7 pages. Besides improving the appearance of this
>
This patch by Than McIntosh fixes type traversal in the Go frontend to
avoid compiler crashes for test cases where a type T includes an
expression that refers back to the type without actually explicitly
mentioning T. Examples include:
var x [uintptr(unsafe.Sizeof())]byte
var a [len(a)]int
On Sat, 2018-06-02 at 13:27 +0200, Gerald Pfeifer wrote:
> On Mon, 14 May 2018, Martin Sebor wrote:
> > > Martin, what do you think? Would that have avoided the
> > > challenges
> > > your ran into? Anything to better clarify or otherwise improve?
> >
> > Thanks for the improvement! I think it
Ping.
Steve Ellcey
sell...@cavium.com
On Thu, 2018-01-11 at 15:44 -0800, Steve Ellcey wrote:
> This is a patch for PR target/79924, which says the error messages
> called from aarch64_err_no_fpadvsimd cannot be translated due to
> how they are constructed. To make them translatable and not
This patch removes extraneous line breaks to condense the number of lines
require in the "PowerPC AltiVec Built-in Functions" section of the gcc.pdf
manual by about 7 pages. Besides improving the appearance of this
documentation, there are two additional benefits:
1. Subsequent patches that
> In the PR we have insns:
>
> Trying 23 -> 24:
>23: r123:SI=zero_extend(r122:HI)
> REG_DEAD r122:HI
>24: [r115:SI]=r123:SI
> REG_DEAD r123:SI
>
> which should be combined to
>
> (set (mem:SI (reg/f:SI 115 [ pretmp_19 ]) [1 *pretmp_19+0 S4 A32])
> (and:SI (subreg:SI
On Mon, Jun 04, 2018 at 01:28:01PM -0400, Jason Merrill wrote:
> On Mon, Jun 4, 2018 at 11:44 AM, Marek Polacek wrote:
> > I've had no luck in reducing the testcase in this PR, creduce won't get even
> > past the initial passes, and reducing by hand didn't get me very far,
> > either.
> >
> >
On 04/06/18 17:06 +0100, Jonathan Wakely wrote:
PR libstdc++/85930
* include/bits/shared_ptr_base.h (_Sp_make_shared_tag::_S_ti): Align
the static variable correctly.
And _really_ align it this time, so the alignment-specifier isn't
ignored (with the warning suppressed
* Claudiu Zissulescu [2018-05-21 13:20:29 +0300]:
> From: claziss
>
> When we pass an mcpu to the compiler we have two types of (hardware
> configuration) flags that are set:
>
> 1. Architecture specific, for example code-density is always enabled
> for ARCHS architectures. These options are
On Mon, Jun 04, 2018 at 12:46:42PM -0500, Segher Boessenkool wrote:
> Hi Mike,
>
> On Fri, Jun 01, 2018 at 07:28:40PM -0400, Michael Meissner wrote:
> > This patch also makes __ibm128 or __float128 use the long double mode if
> > long
> > double uses the IBM extended double or IEEE 128-bit
On 04/06/18 22:13 +0200, François Dumont wrote:
Hi
I'd like to propose this patch to avoid std::distance calls. In a
number of situation in algos we already have the size of the buffer we
need so we shouldn't have to compute it again.
Just one place, in __inplace_merge, no?
I don't think
Eric Botcazou writes:
>> In the PR we have insns:
>>
>> Trying 23 -> 24:
>>23: r123:SI=zero_extend(r122:HI)
>> REG_DEAD r122:HI
>>24: [r115:SI]=r123:SI
>> REG_DEAD r123:SI
>>
>> which should be combined to
>>
>> (set (mem:SI (reg/f:SI 115 [ pretmp_19 ]) [1 *pretmp_19+0 S4
* Claudiu Zissulescu [2018-05-21 13:20:28 +0300]:
> From: claziss
>
> QuarkSE has lp_count width set to 16 bits. Update the compiler to
> consider it.
>
> Ok to apply?
> Claudiu
>
> gcc/
> 2017-07-11 Claudiu Zissulescu
>
> * config/arc/arc-arch.h (arc_extras): New enum.
>
I am testing the following patch to fix an ICE with sincos
folding with mismatched arguments.
Bootstrap / regtest running on x86_64-unknown-linux-gnu.
Richard.
2018-06-04 Richard Biener
PR tree-optimization/85955
* builtins.c (fold_builtin_sincos): Convert pointers to
Hi Dominique and Rainer,
First of all thanks for testing!
Hi Dominique, Nicolas,
I have applied your patch on top of revision r261130 on
x86_64-apple-darwin17 (SSD with APFS file system).
I've tried it on i386-pc-solaris2.11 and sparc-sun-solaris2.11.
I also see two regressions
FAIL:
This fixes a problem reported on the RISC-V foundation sw-dev mailing list. In
a function that calls __builtin_eh_return, such as Unwind_RaiseException, the
return value gets clobbered when we restore the EH_RETURN_DATA_REGNO registers.
The RISC-V port is using arg registers for
Ping: https://gcc.gnu.org/ml/gcc-patches/2018-05/msg01189.html
On 05/29/2018 10:19 AM, Martin Sebor wrote:
Ping: https://gcc.gnu.org/ml/gcc-patches/2018-05/msg01189.html
On 05/22/2018 07:40 PM, Martin Sebor wrote:
Here's another small refinement to -Wstringop-truncation to
avoid diagnosing
Ping: https://gcc.gnu.org/ml/gcc-patches/2018-05/msg01698.html
On 05/29/2018 08:57 PM, Martin Sebor wrote:
Warning for a strncpy call whose bound is the same as the size
of the source and suggesting to use the size of the source is
less than helpful when both sizes are the same, as in:
char
On Mon, Jun 04, 2018 at 06:05:59PM -0400, Michael Meissner wrote:
> > > This
> > > allows templates to work again with those types (the template code aborts
> > > if
> > > you have two distinct types use the same mangling). However, overloaded
> > > types
> > > won't work, but I suspect these
On Mon, Jun 04, 2018 at 05:19:07PM -0500, Segher Boessenkool wrote:
> You can still have overloads, just not two between the same type. So you
> can have both __ibm128 and __ieee128.
Yes of course, but the test is explicitly testing whether you can overloads
with the same type.
> > The test in
On 06/03/2018 06:59 PM, Nicolas Koenig wrote:
> Hello everyone,
>
> this patch adds asynchronous I/O support. Thomas and I finally finished
> a feature-complete and debugged version, so here it is. In order to use
> asynchronous I/O, it is still necessary to link against libpthread,
> libgomp or
> I can see why WORD_REGISTER_OPERATIONS allows some REG cases,
> but why does LOAD_EXTEND_OP have an effect on them?
LOAD_EXTEND_OP has an effect on all paradoxical SUBREGs because of spilling.
This was even originally decoupled from WORD_REGISTER_OPERATIONS in reload,
see this comment from
Ping: https://gcc.gnu.org/ml/gcc-patches/2018-05/msg01671.html
(In IRC last week Franz reported successfully testing the patch.
Thanks again.)
On 05/29/2018 01:21 PM, Martin Sebor wrote:
To make review and testing easier (thank you, Franz), attached
is an updated patch rebased on top of
On 04/06/2018 23:09, Jonathan Wakely wrote:
On 04/06/18 22:13 +0200, François Dumont wrote:
Hi
I'd like to propose this patch to avoid std::distance calls. In a
number of situation in algos we already have the size of the buffer
we need so we shouldn't have to compute it again.
Just one
PR63177 shows a bug in how we determine which gas options we decide to pass to
the
assembler. Normally, we pass the -m option to the assembler if we used the
-mcpu= option. However, if we don't compile with -mcpu=, then we will
check some of the -m options and pass an appropriate -m
option
to
The attached patch re-arranges the code in gfc_simply_mod().
This allows gfortran to test if the 2nd argument is zero.
Tested on i586-*-freebsd and x86_64-*-freebsd. OK to commit?
2018-06-04 Steven G. Kargl
PR fortran/86045
* simplify.c (gfc_simplify_mod): Re-arrange code to
On Mon, Jun 04, 2018 at 08:46:42AM +0200, Richard Biener wrote:
> On Fri, 1 Jun 2018, Joseph Myers wrote:
>
> > On Fri, 1 Jun 2018, Michael Meissner wrote:
> >
> > > I'm wondering if there are other suggestions to make this patch
> > > acceptable.
> > >
> > > As I mentioned previously, the
Without this patch absif2 always FAILs. There is no testcase for
that, nor do we see it during bootstrap, but it is obvious.
Bootstrapped and tested on powerpc64-linux {-m32,-m64}; committing
to trunk.
Segher
2018-06-04 Segher Boessenkool
* config/rs6000/rs6000.md (abs2): Handle
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-8.1.0.es.po', has
Here we were missing SFINAE when choosing a partial specialization
because we requested the instantiation from an access-deferred context
and didn't push into checking context until too late.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 77b60d23c71206b7ac3c9d9817db3787383ea2fd
Author:
On Tue, 29 May 2018, Richard Biener wrote:
>
> The following fixes the situation where the initial sweep over the
> CFG to remove trivially dead code regions causes excessive compile-time
> because of using remove_edge_and_dominated_blocks and thus
> iterate_fix_dominators.
>
> The good thing
On 05/29/2018 10:11 AM, Martin Sebor wrote:
As discussed at (*) I'd like to backport the following patch
to GCC 8 to suppress a class of -Wstringop-truncation warnings.
If there are no concerns/objections I will go ahead and commit
it this week.
The existing documentation incorrectly specifies that the second argument of
vec_lvsl and vec_lvsr instructions are volatile *. This patch removes
the volatile qualifier from the documentation of these arguments.
his patch has bootstrapped and tested without regressions on
* include/bits/postypes.h (fpos): Define special members as defaulted.
Tested powerpc64le-linux, committed to trunk.
commit 24dddbfdccf816b749601980ed05d2bce72e3d24
Author: Jonathan Wakely
Date: Mon Jun 4 16:50:29 2018 +0100
Define std::fpos special members as defaulted
Hi Dominique, Nicolas,
> I have applied your patch on top of revision r261130 on
> x86_64-apple-darwin17 (SSD with APFS file system).
I've tried it on i386-pc-solaris2.11 and sparc-sun-solaris2.11.
> I also see two regressions
>
> FAIL: gfortran.dg/f2003_inquire_1.f03 -O1 execution test
>
>
Hi Nicolas,
> P.S.: I would very much recommend removing the #undef DEBUG in async.h. I
> have to admit, I am quite proud of the debug printouts. They even build a
> data structure in the background telling you were a locked mutex was
> locked.
however, doing so breaks quite a number of tests in
All,
The attach patch fixes a regression introduced by r258347. In that
revision, an attempt is made to reduce a scalar integer expression
to a constant in a CHARACTER(LEN=...) type declaration. If successful,
life is good. If unsuccessful, the original scalar integer expression is
simply
I've had no luck in reducing the testcase in this PR, creduce won't get even
past the initial passes, and reducing by hand didn't get me very far, either.
But the problem seems to be merely that we're not handling USING_DECLs in
cp_tree_equal, and we can get there via comp_template_arguments. In
Updating my email address, apologies for being out of date for a while.
Matthew
* MAINTAINERS: Update my email address.
---
ChangeLog | 4
MAINTAINERS | 2 +-
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index f9f376a..54b7958 100644
In the GCC board support package distributed by TI for msp430 devices, the
preprocessor symbol definition for the MSP430i series of devices expected by
the msp430.h header file differs from the standard template.
For other devices, the expected symbol has all characters in upper case, but
for
PR libstdc++/85930
* include/bits/shared_ptr_base.h (_Sp_make_shared_tag::_S_ti): Align
the static variable correctly.
Tested powerpc64le-linux, committed to trunk.
commit b0aa443f66d21f904ea0144b16df4b14ef9df09c
Author: Jonathan Wakely
Date: Mon Jun 4 16:45:42 2018
Jozef Lawrynowicz writes:
> + if (strncmp (target_mcu, "msp430i", 7) == 0)
> + snprintf (mcu_name, sizeof (mcu_name) - 1, "__MSP430i%s__",
> + target_mcu + 7);
> + else
Do you need to TOUPPER the parts of target_mcu after char 7 ?
On Mon, Jun 4, 2018 at 11:44 AM, Marek Polacek wrote:
> I've had no luck in reducing the testcase in this PR, creduce won't get even
> past the initial passes, and reducing by hand didn't get me very far, either.
>
> But the problem seems to be merely that we're not handling USING_DECLs in
>
On 04/06/18 18:26, DJ Delorie wrote:
Jozef Lawrynowicz writes:
+ if (strncmp (target_mcu, "msp430i", 7) == 0)
+ snprintf (mcu_name, sizeof (mcu_name) - 1, "__MSP430i%s__",
+ target_mcu + 7);
+ else
Do you need to TOUPPER the parts of target_mcu after char 7 ?
Hi all,
This patch adds support for generating LDPs and STPs of Q-registers.
This allows for more compact code generation and makes better use of the ISA.
It's implemented in a straightforward way by allowing 16-byte modes in the
sched-fusion machinery and adding appropriate peepholes in
Hi Mike,
On Fri, Jun 01, 2018 at 07:28:40PM -0400, Michael Meissner wrote:
> This patch also makes __ibm128 or __float128 use the long double mode if long
> double uses the IBM extended double or IEEE 128-bit representations.
Does that need to be the same patch? Please split such things out
Jozef Lawrynowicz writes:
> For the currently released msp430i* devices, only digits follow the i, so no
> upper or lower case conversion is needed.
Thinking of the future... do we expect any new devices with letters?
Should we plan for them? Or better to wait, in case there are more
Ping^2
Steve Ellcey
sell...@cavium.com
On Thu, 2018-05-17 at 14:50 -0700, Steve Ellcey wrote:
> Ping.
>
> Steve Ellcey
> sell...@cavium.com
>
>
> On Wed, 2018-05-02 at 12:47 -0700, Steve Ellcey wrote:
> >
> > This is a new version of a patch I sent out last year to stop gcc from
> > trying
80 matches
Mail list logo
