This patch is composed to implement a loop transformation on one of its
conditional statements, which we call it semi-invariant, in that its
computation is impacted in only one of its branches.
Suppose a loop as:
void f (std::map m)
{
for (auto it = m.begin (); it != m.end (); +
On March 11, 2019 11:32:38 PM GMT+01:00, Jakub Jelinek wrote:
>Hi!
>
>All other expand_builtin* calls in builtins.c return NULL or return
>const0_rtx or return without ICEing when arg validation fails, but
>these
>two and as the testcases show, it can happen on invalid (at runtime)
>testcases. Fi
Let's try this patch -
20190311-pstl-integration.patch.bz2
Description: pstl-integration-patch
Jonathan Wakely writes:
> On 31/01/19 21:08 -0800, Thomas Rodgers wrote:
>>Update C++17 parallel algorithms to LLVM/MIT licensed upstream sources
>
> Some lines in bits/c++confi
Here we were wrongly treating binding a const lvalue ref to an xvalue as
direct binding, which is wrong under [dcl.init.ref] and [over.match.ref].
Tested x86_64-pc-linux-gnu, applying to trunk.
* call.c (build_user_type_conversion_1): Don't use a conversion to a
reference of the w
Ping: https://gcc.gnu.org/ml/gcc-patches/2019-02/msg02029.html
On 3/6/19 2:40 PM, Martin Sebor wrote:
Ping: https://gcc.gnu.org/ml/gcc-patches/2019-02/msg02029.html
(This is marked as a P1 regression.)
On 2/26/19 6:32 PM, Martin Sebor wrote:
Please disregard the original patch and consider th
Ping: https://gcc.gnu.org/ml/gcc-patches/2019-03/msg00147.html
On 3/4/19 5:28 PM, Martin Sebor wrote:
Attached is a patch with (mostly) my changes for GCC 9. To make
things easier to find I grouped related changes together within
the sections I changed. I put warnings under the same bullet,
bu
The -Wstringop-truncation handling for strncpy/stpncpy neglects
to consider that character arrays tracked by the strlen pass
are not necessarily nul-terminated. It unconditionally adds
one when computing the size of each sequence to account for
the nul. This leads to false positive warnings when
When we split:
(insn 18 17 76 2 (set (reg:SF 88 [ _19 ])
(float:SF (mem/c:SI (symbol_ref:DI ("d") [flags 0x2] ) [1 d+0 S4 A32]))) "x.ii":4:20 170 {*floatsisf2}
(expr_list:REG_EH_REGION (const_int 2 [0x2])
(nil)))
to
(insn 94 17 18 2 (set (reg:V4SF 115)
(vec_merge:V4
My recent patch caused us to call convert_for_initialization for a std:move's
argument to see if it would have succeeded had the returned expression been
just that argument.
That caused a bogus error in this test, because convert_for_initialization
might cause additional instantiations, and they m
This is a proposed GCC patch that allows targets to modify the names of
the libmvec routines that get called. Currently, if you build ToT GCC
on Aarch64 and include this glibc patch:
https://sourceware.org/ml/libc-alpha/2019-03/msg00106.html
And then compile a call to expf which gets vec
On Sun, Mar 10, 2019 at 10:36:48PM +0100, Thomas Koenig wrote:
> Am 10.03.19 um 22:12 schrieb Thomas Koenig:
>
> > You're probably right, I will fix this. Ugh...
>
> OK, so here is the updated test case, without the copyright stuff.
>
> OK for trunk now? :-)
>
Yes. Thanks for patch.
--
Ste
On Mon, Mar 11, 2019 at 10:09:02PM +0100, Janus Weil wrote:
>
> Technically the ICE is a regression, but since it happens on invalid
> code only, backporting is not essential IMHO (but might still be
> useful). Ok for trunk? And 8-branch?
Looks good to me with a minor suggestion. See below.
You
Hi!
All other expand_builtin* calls in builtins.c return NULL or return
const0_rtx or return without ICEing when arg validation fails, but these
two and as the testcases show, it can happen on invalid (at runtime)
testcases. Fixed thusly, bootstrapped/regtested on x86_64-linux and
i686-linux, ok
Hi!
As mentioned in the PR, for the case where the allocatable being privatized
is "not currently allocated", we only clear the data pointer and in code
where the user guarantees in the caller that the original variable is always
allocated, this can result in false positive -Wmaybe-uninitialized w
Hi!
The following testcase ICEs since my recent cxx_eval_loop_expr changes.
The problem is that the Forget saved values of SAVE_EXPRs. inside of the
loop can remove SAVE_EXPRs from new_ctx.values and if that is the last
iteration, we can also do the loop at the end of function (which has been
adde
Hi!
As mentioned in the PR, since r269453 dom can process stmts newly added
by fold_stmt. The problem is that at the start of the pass we construct
vr_values with the current number of SSA names and size the tables based on
that. When we process a stmt which sets on lhs a new SSA_NAME above that
Hi all,
the attached patch fixes an ICE-on-invalid problem with parametrized
derived types, more precisely a PDT without any parameters, and
regtests cleanly x86_64-linux-gnu. For the relevant standard quote,
see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89601#c4.
Technically the ICE is a regr
Nope, just do it after testing it and adjust with Christophes follow up
R
On Mon, 11 Mar 2019, 10:36 Andre Vieira (lists), <
andre.simoesdiasvie...@arm.com> wrote:
> Hi,
>
> Any objections to me backporting this to GCC 8 and 7?
>
> Cheers,
> Andre
>
> On 08/03/2019 17:30, Andre Vieira (lists) wr
Ok.
Ramana
On Mon, 11 Mar 2019, 20:24 Christophe Lyon,
wrote:
> On Mon, 11 Mar 2019 at 12:34, Richard Biener wrote:
> >
> > On Mon, 11 Mar 2019, Andre Vieira (lists) wrote:
> >
> > > Hi,
> > >
> > > Any objections to me backporting this to GCC 8 and 7?
> >
> > No, go ahead (after proper testin
This libbacktrace patch only runs the two ztest tests if HAVE_ELF is
true, since we only do uncompression on ELF. This should fix PR
89699. Bootstrapped and ran libbacktrace tests on
x86_64-pc-linux-gnu. Committed to mainline.
Ian
2019-03-11 Ian Lance Taylor
PR libbacktrace/89669
* Makefi
On Mon, 11 Mar 2019 at 12:34, Richard Biener wrote:
>
> On Mon, 11 Mar 2019, Andre Vieira (lists) wrote:
>
> > Hi,
> >
> > Any objections to me backporting this to GCC 8 and 7?
>
> No, go ahead (after proper testing).
>
Hi,
I've noticed that this new test fails on arm-none-linux-gnueabi
--with-m
A -Warray-bounds enhancement committed last year into GCC 9
introduced an assumption that the MEM_REF type argument has
a size. The test case submitted in PR89662 does pointer
addition on void*, in which the MEM_REF type is void*, which
breaks the assumption.
The attached change removes this ass
Hi Dominique,
how about the attached version? It is quite verbose and produces
messages like
Error: Expected list of 'lower-bound-expr:' or list of
'lower-bound-expr:upper-bound-expr' at (1)
(I did check other compilers. E.g. Intel and Oracle do print messages
using the 'legalese'. But user-f
On Mon, Mar 11, 2019 at 08:54:50PM +0100, Martin Liška wrote:
> /bin/sh /home/marxin/Programming/gcc/gcc/../move-if-change tmp-recog.c
> insn-recog.c
> /home/marxin/Programming/gcc/gcc/config/aarch64/aarch64.c: In function ‘void
> aarch64_override_options_internal(gcc_options*)’:
> /home/marxin/P
Hi.
This is a fix for my recent change in string messages.
It fixes:
/bin/sh /home/marxin/Programming/gcc/gcc/../move-if-change tmp-recog.c
insn-recog.c
/home/marxin/Programming/gcc/gcc/config/aarch64/aarch64.c: In function ‘void
aarch64_override_options_internal(gcc_options*)’:
/home/marxin/P
Bootstrap & regtest in progress on x86_64-unknown-linux-gnu.
Richard.
2019-03-11 Richard Biener
PR tree-optimization/89664
* tree-ssa-math-opts.c (execute_cse_reciprocals_1): Properly
free the occurance tree after the early out.
* gfortran.dg/pr89664.f90: Ne
Check for availability of POSIX sockatmark before using it.
Rename _S_ntoh overloads that are ambiguous when passed an integral type
that is neither uint16_t nor uint32_t.
PR libstdc++/89460
* configure.ac: Check for sockatmark.
* crossconfig.m4: Check for sockatmark.
Richard,
I don't necessarily disagree with anything in your comments and long
term I think that is the right direction, but I wonder if that level of
change is appropriate for GCC Stage 4 which is where we are now. Your
changes would require fixes in shared code, whereas setting
REG_ALLOC_ORDER o
On 3/11/19 2:13 AM, Martin Liška wrote:
Hi.
The patch adds a lot of option name wrapping in string format messages. I added
a new contrib
script (contrib/check-internal-format-escaping.py) that is parsing gcc.pot file
and reports
errors.
Patch can bootstrap on x86_64-linux-gnu and survives re
On 11.03.19 13:53, Robin Dapp wrote:
> Hi,
>
> this patch set adds new pipeline descriptions for z13 and z14. Based
> on that, the scoring and some properties are handled differently in
> the scheduler hooks.
>
> Regards
> Robin
>
> Robin Dapp (7):
> S/390: Change z13 pipeline description.
>
On Mon, 11 Mar 2019, Jakub Jelinek wrote:
> On Mon, Mar 11, 2019 at 02:25:59PM +0100, Martin Liška wrote:
> > @@ -38375,7 +38375,7 @@ rdseed_step:
> >mode0 = insn_data[icode].operand[0].mode;
> >if (!insn_data[icode].operand[0].predicate (op0, mode0))
> > {
> > - error ("
On 11/03/19 13:54 +, Jonathan Wakely wrote:
On 11/03/19 09:27 -0400, John David Anglin wrote:
On 2019-03-11 9:16 a.m., Jonathan Wakely wrote:
On 11/03/19 14:13 +0100, Andreas Schwab wrote:
On Mär 11 2019, Jonathan Wakely wrote:
What do you think about adding the following?
--- a/libstd
On 3/11/19 2:38 PM, Jakub Jelinek wrote:
> I think for D you need to go through Iain Buclaw, I have no idea if
> exp->error even has the gcc internal format infrastructure. Can you split
> that part of the patch and post it independently?
The patch addresses that.
Martin
>From 2285a99c9ca143534
On Mon, Mar 11, 2019 at 02:52:18PM +0100, Martin Liška wrote:
> On 3/11/19 2:32 PM, Jakub Jelinek wrote:
> > On Mon, Mar 11, 2019 at 10:12:14AM +0100, Martin Liška wrote:
> >> Now I understand that, thanks.
> >
> > %<-misr-vector-size=X%>
> > and
> > %<-mcache-block-size=X%>
> > need similar treat
On 3/11/19 2:52 PM, Martin Liška wrote:
> On 3/11/19 2:32 PM, Jakub Jelinek wrote:
>> On Mon, Mar 11, 2019 at 10:12:14AM +0100, Martin Liška wrote:
>>> Now I understand that, thanks.
>>
>> %<-misr-vector-size=X%>
>> and
>> %<-mcache-block-size=X%>
>> need similar treatment.
>
> Done.
>
>>
>> I st
On 11/03/19 09:27 -0400, John David Anglin wrote:
On 2019-03-11 9:16 a.m., Jonathan Wakely wrote:
On 11/03/19 14:13 +0100, Andreas Schwab wrote:
On Mär 11 2019, Jonathan Wakely wrote:
What do you think about adding the following?
--- a/libstdc++-v3/testsuite/lib/dg-options.exp
+++ b/libstdc
On 3/11/19 2:32 PM, Jakub Jelinek wrote:
> On Mon, Mar 11, 2019 at 10:12:14AM +0100, Martin Liška wrote:
>> Now I understand that, thanks.
>
> %<-misr-vector-size=X%>
> and
> %<-mcache-block-size=X%>
> need similar treatment.
Done.
>
> I still see
> %<-mcpu%>=%s
Fixed.
>
> %<-mfpu=crypto-neo
on 2019/3/11 下午6:24, Richard Biener wrote:
> On Mon, 11 Mar 2019, Kewen.Lin wrote:
>
>> on 2019/3/8 下午6:57, Richard Biener wrote:
>>> On Fri, Mar 8, 2019 at 2:40 AM Kewen.Lin wrote:
Hi,
As PR88497 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88497),
when we meet some cod
This is C++ so there's no reason to use macros here.
* testsuite/29_atomics/atomic_flag/test_and_set/explicit-hle.cc: Use
const variables instead of macros.
Tested x86_64-linux, committed to trunk.
commit 1eadaf7d34cfaaabb976e68a2fe163aab774463b
Author: Jonathan Wakely
Date:
PR libstdc++/89629
* libsupc++/hash_bytes.cc [__SIZEOF_SIZE_T__ == 8] (_Hash_bytes):
Use correct type for len_aligned.
* testsuite/20_util/hash/89629.cc: New test.
Tested powerpc64le-linux, committed to trunk.
This should be backported too.
commit 7463ece3012ec59
On Mon, Mar 11, 2019 at 02:25:59PM +0100, Martin Liška wrote:
> @@ -38375,7 +38375,7 @@ rdseed_step:
>mode0 = insn_data[icode].operand[0].mode;
>if (!insn_data[icode].operand[0].predicate (op0, mode0))
> {
> - error ("the xabort's argument must be an 8-bit immediate");
>
On Mon, Mar 11, 2019 at 10:12:14AM +0100, Martin Liška wrote:
> Now I understand that, thanks.
%<-misr-vector-size=X%>
and
%<-mcache-block-size=X%>
need similar treatment.
I still see
%<-mcpu%>=%s
%<-mfpu=crypto-neon...%>
might need to be %<-mfpu=crypto-neon%>... or just drop the ... ?
%<-std=*
This fixes a problem with vec_add/sub_u128 builtins. The
s390_expand_builtin backend function is supposed to convert the
operand to TImode *AND* load it into a vector register. The current
implementation did only the conversion and gave up then.
Will be applied to GCC 8 branch after a while.
gc
On 2019-03-11 9:16 a.m., Jonathan Wakely wrote:
> On 11/03/19 14:13 +0100, Andreas Schwab wrote:
>> On Mär 11 2019, Jonathan Wakely wrote:
>>
>>> What do you think about adding the following?
>>>
>>> --- a/libstdc++-v3/testsuite/lib/dg-options.exp
>>> +++ b/libstdc++-v3/testsuite/lib/dg-options.ex
Hi.
There's second part where I wrap apostrophes.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
>From fb2e96c246e0dd99afafcc3ec24e766657ca2496 Mon Sep 17 00:00:00 2001
From: marxin
Date: Mon, 11 Mar 2019 10:13:41 +0100
Subject: [PAT
On 11/03/19 14:13 +0100, Andreas Schwab wrote:
On Mär 11 2019, Jonathan Wakely wrote:
What do you think about adding the following?
--- a/libstdc++-v3/testsuite/lib/dg-options.exp
+++ b/libstdc++-v3/testsuite/lib/dg-options.exp
@@ -257,6 +257,15 @@ proc add_options_for_net_ts { flags } {
On Mär 11 2019, Jonathan Wakely wrote:
> What do you think about adding the following?
>
> --- a/libstdc++-v3/testsuite/lib/dg-options.exp
> +++ b/libstdc++-v3/testsuite/lib/dg-options.exp
> @@ -257,6 +257,15 @@ proc add_options_for_net_ts { flags } {
> return $flags
> }
>
> +# Add to FLAGS a
This patch adds handling of group-of-two instructions.
---
gcc/config/s390/s390.c | 36 +++-
1 file changed, 35 insertions(+), 1 deletion(-)
diff --git a/gcc/config/s390/s390.c b/gcc/config/s390/s390.c
index 4dcf1be4445..78a707267e8 100644
--- a/gcc/config/s390/s3
This patch adapts some scheduling-related parameters.
---
gcc/config/s390/s390.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/gcc/config/s390/s390.c b/gcc/config/s390/s390.c
index 78a707267e8..901807e7833 100644
--- a/gcc/config/s390/s390.c
+++ b/gcc/config/s390/
This patch makes the scheduling score execution-side aware.
---
gcc/config/s390/s390.c | 32 ++--
1 file changed, 18 insertions(+), 14 deletions(-)
diff --git a/gcc/config/s390/s390.c b/gcc/config/s390/s390.c
index 249df00268a..4dcf1be4445 100644
--- a/gcc/config/s390
This patch adds the z14 pipeline description.
---
gcc/config/s390/3906.md | 282
gcc/config/s390/s390.c | 23 +++-
gcc/config/s390/s390.h | 2 +-
gcc/config/s390/s390.md | 3 +
4 files changed, 307 insertions(+), 3 deletions(-)
create mode 100644 g
This patch adds a scheduling state struct and changes
the handling of end-group conditions.
---
gcc/config/s390/s390.c | 158 ++---
1 file changed, 68 insertions(+), 90 deletions(-)
diff --git a/gcc/config/s390/s390.c b/gcc/config/s390/s390.c
index 15926ec88cd
This patch adapts the z13 pipeline description.
---
gcc/config/s390/2964.md | 372 ++--
gcc/config/s390/s390.c | 39 ++---
2 files changed, 226 insertions(+), 185 deletions(-)
diff --git a/gcc/config/s390/2964.md b/gcc/config/s390/2964.md
index 19e641bd252..
This patch makes the detection of long-running instructions
independent of their latency and checks the execution unit
instead.
---
gcc/config/s390/s390.c | 73 +++---
1 file changed, 55 insertions(+), 18 deletions(-)
diff --git a/gcc/config/s390/s390.c b/gcc/
Hi,
this patch set adds new pipeline descriptions for z13 and z14. Based
on that, the scoring and some properties are handled differently in
the scheduler hooks.
Regards
Robin
Robin Dapp (7):
S/390: Change z13 pipeline description.
S/390: Add z14 pipeline description.
S/390: Change handl
On 09/03/19 12:46 -0500, John David Anglin wrote:
The hppa*-*-hpux* target has no builtin atomic support, so we need to
explicitly link
applications requiring atomic support against libatomic.
Okay?
Dave
--
John David Anglin dave.ang...@bell.net
2019-03-09 John David Anglin
PR li
Hi, I've just noticed this in your r266209 change from November:
On 16/11/18 10:42 +, Renlin Li wrote:
+return [check_v3_target_prop_cached et_parallel_mode {
+ global cxxflags
+ global v3-libgomp
# If 'make check-parallel' is running the test succeeds.
if { $
On 2/27/19 1:32 PM, Martin Liška wrote:
> Hi.
>
> The patch adds missing information into JSON intermediate format.
> Before the patch one can't assign 'lines' to 'functions' in case
> one has a group function (e.g. a template function).
>
> Patch can bootstrap on x86_64-linux-gnu and survives re
The following fixes a missed vectorization of std::min() when
only one argument is a temporary. The following patch is the least
intrusive and safest one - PRE already performs the necessary
work to make this vectorizable, it's just that we end up with
a dead store and clobber of a stack-local t
On Mon, 11 Mar 2019, Andre Vieira (lists) wrote:
> Hi,
>
> Any objections to me backporting this to GCC 8 and 7?
No, go ahead (after proper testing).
Richard.
> Cheers,
> Andre
>
> On 08/03/2019 17:30, Andre Vieira (lists) wrote:
> > Hi,
> >
> > vcvtb.f16.f64 and vcvtb.f64.f16 were being mad
On 11/03/19 08:58 +0100, Jakub Jelinek wrote:
On Sun, Mar 10, 2019 at 10:36:08PM +0100, Jakub Jelinek wrote:
Ok for trunk if normal bootstrap/regtest succeeds (i.e. including the default
flags
testing)?
Normal bootstrap/regtest on x86_64-linux and i686-linux succeeded too.
2019-03-10 Jakub
Hi.
Another 2 patches that I've just tested.
Thanks,
Martin
>From a4ec4d12444bc2fed3fbf559d6cae4618caab7c8 Mon Sep 17 00:00:00 2001
From: marxin
Date: Mon, 18 Feb 2019 09:46:19 +
Subject: [PATCH 2/2] Backport r268981
libcpp/ChangeLog:
2019-02-18 Martin Liska
PR c++/89383
* line-map.c
Hi,
Any objections to me backporting this to GCC 8 and 7?
Cheers,
Andre
On 08/03/2019 17:30, Andre Vieira (lists) wrote:
Hi,
vcvtb.f16.f64 and vcvtb.f64.f16 were being made available even for FPUs
that do not support double precision. This patch fixes that.
Regression tested for arm-none-
Hi,
ASAN was enabled for the SPARC architecture during GCC 9 development but it
doesn't really work on SPARC64/Linux because of the specific layout of the
virtual memory address space. Fortunately this is (easily) fixable and the
fix has been accepted upstream, along with other fixes for SPARC
On Mon, 11 Mar 2019, Kewen.Lin wrote:
> on 2019/3/8 下午6:57, Richard Biener wrote:
> > On Fri, Mar 8, 2019 at 2:40 AM Kewen.Lin wrote:
> >>
> >> Hi,
> >>
> >> As PR88497 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88497),
> >> when we meet some code pattern like:
> >>
> >>V1[0] + V1[1] + ...
> Hmm, this looks fragile - isn't the same effect when using
> -fdisable-tree-cunroll?
Maybe.
> That is, it looks like we could "move" the assert to decide_unrolling
> instead, deciding LPT_NONE?
We already have a guard for the assertion but it is bypassed here.
I'm going to commit this (equiva
On Mon, Mar 11, 2019 at 10:05 AM Eric Botcazou wrote:
>
> Hi,
>
> this is the failure of the assertion:
>
> /* Should not get here (such loop should be peeled instead). */
> gcc_assert (niter > max_unroll + 1);
>
> in unroll_loop_constant_iterations on a testcase both containing #pragma GCC
>
Hi.
I'm sending another patches that I've just tested.
Martin
>From 915af267eb22e5059737f4dbb6e9d48601bb0779 Mon Sep 17 00:00:00 2001
From: "ro@138bc75d-0d04-0410-961f-82ee72b054a4"
Date: Sun, 10 Mar 2019 16:43:48 +
Subject: [PATCH 4/4] Backport r269558
gcc/testsuite/ChangeLog:
2019-03-10
Hi Harald,
The patch looks good to me (although I did not test it), however I don’t like
the standard legalese in the error messages.
IMO
R1035 bounds-spec is lower-bound-expr :
R1036 bounds-remapping is lower-bound-expr : upper-bound-exp
should be rephrased in plain English.
Thanks for the w
Hi Thomas,
> Anything else? …
Yes, the tests gfortran.dg/assumed_type_2.f90 and
gfortran.dg/no_arg_check_2.f90 fail:
FAIL: gfortran.dg/assumed_type_2.f90 -O scan-tree-dump-times original
"sub_array_assumed (D" 3 (found 4 times)
FAIL: gfortran.dg/assumed_type_2.f90 -O scan-tree-dump
On 3/11/19 10:05 AM, Jakub Jelinek wrote:
> On Mon, Mar 11, 2019 at 09:57:36AM +0100, Martin Liška wrote:
>> On 3/11/19 9:30 AM, Jakub Jelinek wrote:
>>> On Mon, Mar 11, 2019 at 09:13:57AM +0100, Martin Liška wrote:
The patch adds a lot of option name wrapping in string format messages. I
>>>
I am testing the following patch to fix the g++.dg/pr80481.C FAIL
on x86_64. Copying of the loop force_vectorize flag caused the
epilogue loops no longer be unrolled because the vectorizer fails
to unset the force_vectorize flag after copying the loop causing
the unroller to not touch it. This
Hi,
after we have accidentally dropped the mailing list from our discussion
(my apologies for not spotting that in time), Richi has approved the
following patch which I have bootstrapped and tested on x86_64-linux
(all languages) and on i686-linux, aarch64-linux and ppc64-linux (C, C++
and Fortran
On Mon, Mar 11, 2019 at 09:57:36AM +0100, Martin Liška wrote:
> On 3/11/19 9:30 AM, Jakub Jelinek wrote:
> > On Mon, Mar 11, 2019 at 09:13:57AM +0100, Martin Liška wrote:
> >> The patch adds a lot of option name wrapping in string format messages. I
> >> added a new contrib
> >> script (contrib/ch
Hi,
this is the failure of the assertion:
/* Should not get here (such loop should be peeled instead). */
gcc_assert (niter > max_unroll + 1);
in unroll_loop_constant_iterations on a testcase both containing #pragma GCC
unroll and compiled with -fno-tree-loop-optimize. The proposed fix is
On 3/11/19 9:33 AM, Jakub Jelinek wrote:
> On Mon, Mar 11, 2019 at 09:30:15AM +0100, Jakub Jelinek wrote:
>> Similarly
>> %<-mstringop-strategy=rep%>_8byte
>> or
>> %<-mcpu=v8%>.30.a
>> or
>> %<-mfloat128%>-hardware
>> look wrong.
>
> %<-mspfp%>_fast
>
> too. I guess just go through the whole pa
On 3/11/19 9:30 AM, Jakub Jelinek wrote:
> On Mon, Mar 11, 2019 at 09:13:57AM +0100, Martin Liška wrote:
>> The patch adds a lot of option name wrapping in string format messages. I
>> added a new contrib
>> script (contrib/check-internal-format-escaping.py) that is parsing gcc.pot
>> file and re
On Mon, Mar 11, 2019 at 09:30:15AM +0100, Jakub Jelinek wrote:
> Similarly
> %<-mstringop-strategy=rep%>_8byte
> or
> %<-mcpu=v8%>.30.a
> or
> %<-mfloat128%>-hardware
> look wrong.
%<-mspfp%>_fast
too. I guess just go through the whole patch and look for cases where
%> is not followed by [" ] an
On Mon, Mar 11, 2019 at 09:13:57AM +0100, Martin Liška wrote:
> The patch adds a lot of option name wrapping in string format messages. I
> added a new contrib
> script (contrib/check-internal-format-escaping.py) that is parsing gcc.pot
> file and reports
> errors.
>
> Patch can bootstrap on x86
Hi.
The patch adds a lot of option name wrapping in string format messages. I added
a new contrib
script (contrib/check-internal-format-escaping.py) that is parsing gcc.pot file
and reports
errors.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Apart from that I built al
On Sun, Mar 10, 2019 at 10:36:08PM +0100, Jakub Jelinek wrote:
> Ok for trunk if normal bootstrap/regtest succeeds (i.e. including the default
> flags
> testing)?
Normal bootstrap/regtest on x86_64-linux and i686-linux succeeded too.
> 2019-03-10 Jakub Jelinek
>
> PR libstdc++/89641
>
On Fri, Mar 8, 2019 at 7:03 PM Richard Biener
wrote:
>
> On Fri, Mar 8, 2019 at 9:49 AM H.J. Lu wrote:
> >
> > On Thu, Mar 7, 2019 at 9:51 AM H.J. Lu wrote:
> > >
> > > On Wed, Mar 6, 2019 at 8:33 PM Richard Biener
> > > wrote:
> > > >
> > > > On Wed, Mar 6, 2019 at 8:46 AM H.J. Lu wrote:
> >
82 matches
Mail list logo
