On 8/1/19 9:26 AM, Paul McKenney wrote:
Excellent point, this discussion needs to be made official.
Please see attached for an initial draft of a working paper.
Thoughts?
The draft is a start but it (obviously) needs a lot of work to cover
the constraints and semantics so I'll just comment on
On Fri, Aug 02, 2019 at 05:30:07PM -0700, Steve Kargl wrote:
> The attached patch has been tested on x86_64-*-freebsd.
> There were no regressions.
>
> The patch suppresses error messages for function, subroutine,
> and entry statements if these appear in a submodule. The
> interface declared in
On Fri, Aug 2, 2019 at 10:14 AM Akshat Garg wrote:
>
>
> On Thu, Aug 1, 2019 at 8:57 PM Paul McKenney wrote:
>
>> Excellent point, this discussion needs to be made official.
>> Please see attached for an initial draft of a working paper.
>>
>> Thoughts?
>>
>>
The attached patch has been tested on x86_64-*-freebsd.
There were no regressions.
The patch suppresses error messages for function, subroutine,
and entry statements if these appear in a submodule. The
interface declared in the module must match the interface in
submodule (including the BIND(C) l
In free-form source code, DATA must be followed by whitespace.
This patch checks for whitespace, and if none is found, returns
MATCH_NO to give other matchers a chance to run.
2019-08-02 Steven G. Kargl
PR fortran/90985
* decl.c (gfc_match_data): In free-form code, DATA be foll
On Fri, Aug 2, 2019 at 7:35 AM Martin Liška wrote:
>
> On 8/2/19 1:06 PM, Richard Biener wrote:
> > On Fri, Aug 2, 2019 at 1:01 PM Martin Liška wrote:
> >>
> >> On 8/2/19 12:54 PM, Maxim Kuvyrkov wrote:
> On Aug 2, 2019, at 1:26 PM, Martin Liška wrote:
>
> On 8/2/19 10:41 AM, Maxi
I've committed the attached patch. After matching
EQUIVALNCE, the patch goobles any possible whitespace
and then checks that the next character is '('. If
it isn't '(', return MATCH_NO to give other matches a
chance to run.
2019-08-02 Steven G. Kargl
PR fortran/90297
* match
On Tue, Jul 2, 2019 at 4:50 AM Martin Liška wrote:
>
> Second part.
>
> Martin
This caused:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91334
--
H.J.
On Thu, Aug 01, 2019 at 04:26:11PM -0500, Segher Boessenkool wrote:
> On Thu, Aug 01, 2019 at 03:47:56PM -0400, Michael Meissner wrote:
> > Add future_cost placeholder.
> >
> > Currently, the -mcpu=future uses the power9 costs. This patch separates out
> > the cost to a separate structure so that
This patch adjusts the parallel-dims.c and serial-dims.c tests to
use relative, rather than absolute, line numbers for expected warning
emission.
ChangeLog
2019-07-31 Julian Brown
* testsuite/libgomp.oacc-c-c++-common/parallel-dims.c: Use relative
line numbers for warning.
This patch introduces versions of the gomp_print_{string,integer,double}
low-level printing functions that work for NVPTX.
ChangeLog
2019-07-31 Julian Brown
libgomp/
* config/nvptx/gomp_print.c (gomp_print_string, gomp_print_integer,
gomp_print_double): New.
*
This patch adjusts the implementation of function-argument flattening
by Cesar posted (for the og7 branch) here so that it only affects NVPTX:
https://gcc.gnu.org/ml/gcc-patches/2017-12/msg01456.html
Changes made are as follows (briefly):
* The GOACC_parallel_keyed_v2 libgomp entry point has b
This is a backport to the og9 branch of the patch posted here:
https://gcc.gnu.org/ml/gcc-patches/2019-06/msg00443.html
2019-06-25 Andrew Stubbs
Backport from mainline:
libgcc/
* config/gcn/t-amdgcn (LIB2ADD): Add unwind-gcn.c.
* config/gcn/unwind-gcn.c: New f
This is a backport to the og9 branch of the patch posted for mainline here:
https://gcc.gnu.org/ml/gcc-patches/2019-06/msg00444.html
2019-06-25 Kwok Cheung Yeung
Andrew Stubbs
Backport from mainline:
libgfortran/
* configure: Regenerate.
* config
This is a backport to the og9 branch of the patch posted to mainline here:
https://gcc.gnu.org/ml/gcc-patches/2019-06/msg00442.html
2019-06-25 Kwok Cheung Yeung
Andrew Stubbs
Backport from mainline:
gcc/
* config.gcc (thread_file): Set to gcn for AMD GCN
This is a backport to the og9 branch of the mainline patch posted here:
https://gcc.gnu.org/ml/gcc-patches/2019-05/msg01539.html
2019-05-22 Kwok Cheung Yeung
Andrew Stubbs
Backport from mainline:
* config.gcc (gcc_cv_initfini_array): Set for AMD GCN.
* c
This patch series provides basic offloading support for OpenMP and
OpenACC on openacc-gcc-9-branch, although OpenACC in particular is likely
to be buggy until we post follow-up fixes from our internal branch.
Further commentary is provided alongside each patch.
The series as a whole has been test
On 8/2/19 3:11 PM, Richard Biener wrote:
> On Tue, 30 Jul 2019, Bernd Edlinger wrote:
>
>>
>> I have no test coverage for the movmisalign optab though, so I
>> rely on your code review for that part.
>
> It looks OK. I tried to make it trigger on the following on
> i?86 with -msse2:
>
> typedef
On Fri, Aug 02, 2019 at 01:55:04PM -0400, Arvind Sankar wrote:
> On Fri, Aug 02, 2019 at 12:49:56PM -0500, Segher Boessenkool wrote:
> > On Fri, Aug 02, 2019 at 01:38:21PM -0400, Arvind Sankar wrote:
> > > Hi, I have taken a crack at the beginner GCC project mentioned at
> > > https://gcc.gnu.org/p
On Jul 30, 2019, Alexandre Oliva wrote:
> This was regstrapped on x86_64-linux-gnu, and tested internally on
> various other platforms. I intend to install it after the corresponding
> GDB changes, that I'm about to post, are in.
https://sourceware.org/ml/gdb-patches/2019-07/msg00671.html is no
Fixed by r215409. The test is nice, so I'm adding it.
Tested on x86_64-linux, applying to trunk.
2019-08-02 Marek Polacek
PR c++/56428
* g++.dg/cpp0x/nontype4.C: New test.
diff --git gcc/testsuite/g++.dg/cpp0x/nontype4.C
gcc/testsuite/g++.dg/cpp0x/nontype4.C
new file mode 1
On Fri, Aug 02, 2019 at 12:49:56PM -0500, Segher Boessenkool wrote:
> On Fri, Aug 02, 2019 at 01:38:21PM -0400, Arvind Sankar wrote:
> > Hi, I have taken a crack at the beginner GCC project mentioned at
> > https://gcc.gnu.org/projects/beginner.html to replace uses of GET_CODE
> > to check rtx_code
Fixed by r251438 and the test seems useful.
Tested on x86_64-linux, applying to trunk.
2019-08-02 Marek Polacek
PR c++/53009
* g++.dg/cpp0x/nontype3.C: New test.
diff --git gcc/testsuite/g++.dg/cpp0x/nontype3.C
gcc/testsuite/g++.dg/cpp0x/nontype3.C
new file mode 100644
index
On Fri, Aug 02, 2019 at 01:38:21PM -0400, Arvind Sankar wrote:
> Hi, I have taken a crack at the beginner GCC project mentioned at
> https://gcc.gnu.org/projects/beginner.html to replace uses of GET_CODE
> to check rtx_code with the appropriate predicate macros.
>
> Would someone be able to review
Committed as r274025 with approval in
https://gcc.gnu.org/ml/gcc-patches/2019-08/msg00146.html
$ svn diff -r274024:274025 -x -p
Index: ChangeLog
===
--- ChangeLog (Revision 274024)
+++ ChangeLog (Revision 274025)
@@ -1,5 +1,8 @@
This was fixed by r241425, but the test added in that revision doesn't
have an alias template. So adding this test.
Tested on x86_64-linux, applying to trunk.
2019-08-02 Marek Polacek
PR c++/77575
* g++.dg/cpp0x/nontype2.C: New test.
diff --git gcc/testsuite/g++.dg/cpp0x/non
Committed as r274023 with approval in
https://gcc.gnu.org/ml/gcc-patches/2019-08/msg00146.html
$ svn diff -rPREV:BASE -x -p
Index: ChangeLog
===
--- ChangeLog (Revision 274022)
+++ ChangeLog (Arbeitskopie)
@@ -1,3 +1,7 @@
+2019-0
On Fri, Aug 2, 2019 at 12:11 AM Kito Cheng wrote:
> gcc/ChangeLog
> * config/riscv/riscv.c (riscv_promote_function_mode): New.
> (TARGET_PROMOTE_FUNCTION_MODE): Use riscv_promote_function_mode.
> gcc/testsuite/ChangeLog
> * gcc.target/riscv/promote-type-for-libcall.c: New.
As suggested in PR 91201 to avoid zero-extension to HImode for SSE4.1 targets.
2019-08-02 Uroš Bizjak
PR target/91201
* config/i386/sse.md (*vec_extractv16qi_zext): New insn pattern.
testsuite/ChangeLog:
2019-08-02 Uroš Bizjak
PR target/91201
* gcc.target/i386/sse4_1-pr91
On Fri, Aug 02, 2019 at 05:14:20PM +0300, Maxim Kuvyrkov wrote:
> > On Aug 2, 2019, at 11:35 AM, Maxim Kuvyrkov
> > wrote:
> >> On Jul 22, 2019, at 12:05 PM, Maxim Kuvyrkov
> >> wrote:
> > 3. Conversion is now feature-complete. The scripts re-write author and
> > committer fields, as well as
When then and else are reversed, we would swap new_val and old_val.
The same has to be done for our new code paths.
Also, emit_conditional_move may perform swapping. In case we need to
swap, the cc comparison also needs to be swapped and for this we pass
the reversed cc comparison directly. An al
This patch checks allows immediate then/else operands for cmovs.
We rely on,emit_conditional_move returning NULL if something unsupported
was generated.
Also, minor refactoring is performed.
--
gcc/ChangeLog:
2018-11-14 Robin Dapp
* ifcvt.c (have_const_cmov): New function.
(
A swap-style idiom like
tmp = a
a = b
b = tmp
would be transformed like
tmp_tmp = cond ? a : tmp
tmp_a = cond ? b : a
tmp_b = cond ? tmp_tmp : b
[...]
including rewiring the first source operand to previous writes (e.g. tmp ->
tmp_tmp).
The code would recognize this, though, and cha
noce_convert_multiple_sets creates temporaries for the destination of
every emitted cmov and expects subsequent passes to get rid of them. This
does not happen every time and even if the temporaries are removed, code
generation can be affected adversely. In this patch, temporaries are
only create
This patch extends bb_ok_for_noce_convert_multiple_sets by a temporary
cost estimation that can be used by noce_convert_multiple_sets.
---
gcc/ifcvt.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/gcc/ifcvt.c b/gcc/ifcvt.c
index 253b8a96c1a..55205cac153 10
This patch duplicates the previous noce_emit_cmove logic. First it
passes the canonical comparison emits the sequence and costs it.
Then, a second, separate sequence is created by passing the cc compare
we extracted before. The costs of both sequences are compared and the
cheaper one is emitted.
This patch extracts a cc comparison from the initial compare/jump
insn and allows it to be passed to noce_emit_cmove and
emit_conditional_move.
---
gcc/ifcvt.c | 68
gcc/optabs.c | 7 --
gcc/optabs.h | 2 +-
3 files changed, 69 insertions
This patch saves the number of created conditional moves by
noce_convert_multiple_sets in the IF_INFO struct. This may be used by
the backend to easier decide whether to accept a generated sequence or
not.
---
gcc/ifcvt.c | 10 --
gcc/ifcvt.h | 4
2 files changed, 12 insertions(+),
Hi,
this patch series tries to address some problems of noce_convert_multiple_sets.
The main drawback is that it emits temporaries for each conversion which are
supposed to be eliminated in a later pass but are still included in cost
estimation.
In an attempt to alleviate this I have ifcvt store
This patch introduces an enum for ifcvt's various noce transformations.
As the transformation might be queried by the backend, I find it nicer
to allow checking for a proper type instead of a string comparison.
---
gcc/ifcvt.c | 46 ++--
gcc/ifcvt.h | 67 ++
> On Aug 2, 2019, at 2:06 PM, Richard Biener wrote:
>
> On Fri, Aug 2, 2019 at 1:01 PM Martin Liška wrote:
>>
>> On 8/2/19 12:54 PM, Maxim Kuvyrkov wrote:
On Aug 2, 2019, at 1:26 PM, Martin Liška wrote:
On 8/2/19 10:41 AM, Maxim Kuvyrkov wrote:
> In the end, I don't care mu
On 8/2/19 8:15 AM, Eric Botcazou wrote:
> Hi,
>
> an user reported that, for pairs of consecutive memory accesses, the SLSR
> pass
> can slightly pessimize the generated code at -O2 on the x86 architecture:
>
> struct x
> {
> int a[16];
> int b[16];
> };
>
> void
> set (struct x *p, unsigned
On Fri, Aug 02, 2019 at 01:06:12PM +0200, Richard Biener wrote:
> 1) Stay with SVN
> 2) Switch to the existing GIT mirror
> 3) Wait for ERS to complete his conversion to GIT
> 4) Use the existing new conversion to GIT fixing authors and commit messages
> 5) I don't care
> 6) I don't care as long as
> On Aug 2, 2019, at 11:35 AM, Maxim Kuvyrkov wrote:
>
>> On Jul 22, 2019, at 12:05 PM, Maxim Kuvyrkov
>> wrote:
>>
> ...
> As far as GCC conversion goes, below is what I plan to do and what not to
> do. This is based on comments from everyone in this thread:
>
> 1. Construc
This patch fixes PR c++/88095:
- Bug 88095 - class nontype template parameter UDL string literals
doesn't accepts deduction placeholder
- https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88095.
It also addresses a latent issue; literal operator templates with
template parameter packs of literal cl
On Fri, 2 Aug 2019, Richard Biener wrote:
> The qsort_r method is named vec::sort instead of being an overload
> of vec::qsort because that would need parentizing all uses as the
> macro definition otherwise matches...
Or simply handling a two-argument qsort call in the macro :) But I think
vec:
On Thu, Aug 01, 2019 at 09:20:19PM -0400, Jason Merrill wrote:
> On 8/1/19 5:53 PM, Marek Polacek wrote:
> > > Hmm, when would value_expr not be error_mark_node for __PRETTY_FUNCTION__
> > > in
> > > a template?
> >
> > E.g.
> >
> > template
> > struct S {
> >T *t{__PRETTY_FUNCTION__};
> > }
Hi,
an user reported that, for pairs of consecutive memory accesses, the SLSR pass
can slightly pessimize the generated code at -O2 on the x86 architecture:
struct x
{
int a[16];
int b[16];
};
void
set (struct x *p, unsigned int n, int i)
{
p->a[n] = i;
p->b[n] = i;
}
is compiled with
On Tue, 30 Jul 2019, Bernd Edlinger wrote:
> Hi Richard,
>
> it is already a while ago, but I had not found time to continue
> with this patch until now.
>
> I think I have now a better solution, which properly addresses your
> comments below.
>
> On 3/25/19 9:41 AM, Richard Biener wrote:
> > O
On Fri, 2019-08-02 at 12:22 +0200, Martin Liška wrote:
> On 7/31/19 3:13 PM, David Malcolm wrote:
> > On Wed, 2019-07-31 at 10:42 +0200, Martin Liška wrote:
> > > Hi.
> > >
> > > As seen here:
> > > https://github.com/RPGillespie6/fastcov/pull/18/files/f184dd8b6fc
> > > 14e0
> > > 75dfc0ea93de7be5
On Fri, 2019-08-02 at 14:02 +0200, Paolo Carlini wrote:
> Hi,
>
> On 31/07/19 21:39, David Malcolm wrote:
>
> [snip]
> > I don't care for "cp_expr_loc_or_loc".
> >
> > By "_or_here" do you mean "or input_location"?
> >
> > Calling it "cp_expr_loc_or_input_location" would spell out what it
> > d
Ping
On Tue, 16 Jul 2019, Marc Glisse wrote:
Adding a C++ maintainer in Cc:
https://gcc.gnu.org/ml/gcc-patches/2019-07/msg00808.html
On Wed, 10 Jul 2019, Marc Glisse wrote:
Hello,
this avoids folding __builtin_constant_p to 0 early when we are not forced
to do so. Clearly this has an effec
Hi,
On 31/07/19 21:39, David Malcolm wrote:
[snip]
I don't care for "cp_expr_loc_or_loc".
By "_or_here" do you mean "or input_location"?
Calling it "cp_expr_loc_or_input_location" would spell out what it
does, but would be rather long.
Thanks for your feedback. At this point I don't feel ve
On 8/2/19 1:06 PM, Richard Biener wrote:
> On Fri, Aug 2, 2019 at 1:01 PM Martin Liška wrote:
>>
>> On 8/2/19 12:54 PM, Maxim Kuvyrkov wrote:
On Aug 2, 2019, at 1:26 PM, Martin Liška wrote:
On 8/2/19 10:41 AM, Maxim Kuvyrkov wrote:
> In the end, I don't care much to which versi
Hi Richard,
> Testing went OK but it looks like acats doesn't honor
> RUNTESTFLAGS so I got no multilib testing for it :/
indeed, see PR testsuite/37703. I had the beginnings of a patch
http://gcc.gnu.org/ml/gcc-patches/2011-01/msg02310.html
http://gcc.gnu.org/ml/gcc-patches/201
On Fri, Aug 2, 2019 at 1:01 PM Martin Liška wrote:
>
> On 8/2/19 12:54 PM, Maxim Kuvyrkov wrote:
> >> On Aug 2, 2019, at 1:26 PM, Martin Liška wrote:
> >>
> >> On 8/2/19 10:41 AM, Maxim Kuvyrkov wrote:
> >>> In the end, I don't care much to which version of the repo we switch, as
> >>> long as w
On 8/2/19 12:54 PM, Maxim Kuvyrkov wrote:
>> On Aug 2, 2019, at 1:26 PM, Martin Liška wrote:
>>
>> On 8/2/19 10:41 AM, Maxim Kuvyrkov wrote:
>>> In the end, I don't care much to which version of the repo we switch, as
>>> long as we switch.
>>
>> Hi Maxim.
>>
>> I really appreciate that you've be
On Fri, Aug 2, 2019 at 10:24 AM Richard Biener
wrote:
>
> On Thu, Aug 1, 2019 at 7:11 PM Eric Botcazou wrote:
> >
> > > So isn't this an issue with the code before when we have a RANGE_EXPR
> > > that covers the wrapping point?
> >
> > No, see the reduced testcase attached in the PR.
> >
> > > Th
> On Aug 2, 2019, at 1:26 PM, Martin Liška wrote:
>
> On 8/2/19 10:41 AM, Maxim Kuvyrkov wrote:
>> In the end, I don't care much to which version of the repo we switch, as
>> long as we switch.
>
> Hi Maxim.
>
> I really appreciate that you've been working on that. Same as you I would
> like
On 8/2/19 10:41 AM, Maxim Kuvyrkov wrote:
> In the end, I don't care much to which version of the repo we switch, as long
> as we switch.
Hi Maxim.
I really appreciate that you've been working on that. Same as you I would like
to see
any change that will lead to a git repository.
I have couple
On 7/31/19 3:13 PM, David Malcolm wrote:
> On Wed, 2019-07-31 at 10:42 +0200, Martin Liška wrote:
>> Hi.
>>
>> As seen here:
>> https://github.com/RPGillespie6/fastcov/pull/18/files/f184dd8b6fc14e0
>> 75dfc0ea93de7be5c96298ddb#r308735088
>>
>> GCOV uses json::number for branch count, line count and
On 8/2/19 12:15 PM, Eric Botcazou wrote:
>> Yes, I've just verified that. Do you have access to the SPEC benchmark?
>
> Nope.
>
>> First big change is in before/exchange2.fppized.f90.130t.pre
>
> Is that at -Os? If not, then this isn't necessarily a problem. It looks
> like
> PRE is able to
> Yes, I've just verified that. Do you have access to the SPEC benchmark?
Nope.
> First big change is in before/exchange2.fppized.f90.130t.pre
Is that at -Os? If not, then this isn't necessarily a problem. It looks like
PRE is able to PRE-ify more stores, very likely because they no longer tr
Rainer Orth writes:
> External E-Mail
>
>
> Hi Senthil,
>
>> This patch prevents gcc.dg/torture/ssa-fre-{5,7}.c from failing
>> for the avr
>> target, by requiring effective-target int32.
>>
>> Committed as obvious to trunk.
>>
>> Regards
>> Senthil
>>
>> 2019-08-02 Senthil Kumar Selvaraj
>>
Attached patch fixes LTGT to trap on unordered operands. The patch
also adds a testcase that will enforce traps for LTGT on other
targets.
2019-08-02 Uroš Bizjak
PR target/91323
* config/i386/i386-expand.c (ix86_unordered_fp_compare) :
Return false.
testsuite/ChangeLog:
2019-08-0
On Fri, Aug 2, 2019 at 11:19 AM Martin Liška wrote:
>
> On 8/2/19 11:15 AM, Jan Hubicka wrote:
> >> On Fri, Aug 2, 2019 at 10:50 AM Jakub Jelinek wrote:
> >>>
> >>> On Fri, Aug 02, 2019 at 10:47:10AM +0200, Martin Liška wrote:
> > Can you strace if other fds are opened and not closed in the s
This takes the qsort_r support a bit further with an example
conversion of tree-ssa-loop-im.c (but not actually removing the
global variable...).
The qsort_r method is named vec::sort instead of being an overload
of vec::qsort because that would need parentizing all uses as the
macro definition
On 8/2/19 11:15 AM, Jan Hubicka wrote:
>> On Fri, Aug 2, 2019 at 10:50 AM Jakub Jelinek wrote:
>>>
>>> On Fri, Aug 02, 2019 at 10:47:10AM +0200, Martin Liška wrote:
> Can you strace if other fds are opened and not closed in the spot you had
> it
> before? Advantage of doing it there
> On Fri, Aug 2, 2019 at 10:50 AM Jakub Jelinek wrote:
> >
> > On Fri, Aug 02, 2019 at 10:47:10AM +0200, Martin Liška wrote:
> > > > Can you strace if other fds are opened and not closed in the spot you
> > > > had it
> > > > before? Advantage of doing it there is that it will not be done for
>
Hi Senthil,
> This patch prevents gcc.dg/torture/ssa-fre-{5,7}.c from failing for the avr
> target, by requiring effective-target int32.
>
> Committed as obvious to trunk.
>
> Regards
> Senthil
>
> 2019-08-02 Senthil Kumar Selvaraj
>
> * gcc.dg/torture/ssa-fre-5.c: Add dg-require-effective-ta
On 8/2/19 10:54 AM, Jakub Jelinek wrote:
> On Fri, Aug 02, 2019 at 10:48:55AM +0200, Martin Liška wrote:
>>> Just a nit, some lines are too long and perhaps mklog could be improved too.
>>> On the first line above, one would normally wrap it as:
>>> * testsuite/23_containers/array/comparison_op
On 01/08/2019 12:19, Bernd Edlinger wrote:
On 7/31/19 3:16 PM, Richard Earnshaw (lists) wrote:
On 30/07/2019 21:51, Bernd Edlinger wrote:
+/* { dg-options "-marm -march=armv6 -mno-unaligned-access -mfloat-abi=soft
-mabi=aapcs -O3" } */
This isn't going to work as-is, we test many combinati
> On Fri, Aug 2, 2019 at 10:50 AM Jakub Jelinek wrote:
> >
> > On Fri, Aug 02, 2019 at 10:47:10AM +0200, Martin Liška wrote:
> > > > Can you strace if other fds are opened and not closed in the spot you
> > > > had it
> > > > before? Advantage of doing it there is that it will not be done for
>
On Fri, Aug 2, 2019 at 10:50 AM Jakub Jelinek wrote:
>
> On Fri, Aug 02, 2019 at 10:47:10AM +0200, Martin Liška wrote:
> > > Can you strace if other fds are opened and not closed in the spot you had
> > > it
> > > before? Advantage of doing it there is that it will not be done for all
> > > the
Hi Segher,
Sorry for the late, I've addressed your comments in the attached patch.
Some points:
1) Remove explict AND part.
2) Rename predicate name to vint_reg_or_vint_const.
3) Split test cases into altivec and power8.
As to the predicate name and usage, I checked the current vector shift
On Fri, Aug 2, 2019 at 10:41 AM Maxim Kuvyrkov
wrote:
>
> > On Aug 1, 2019, at 11:43 PM, Jason Merrill wrote:
> >
> > On Mon, Jul 22, 2019 at 5:05 AM Maxim Kuvyrkov
> > wrote:
> >>
> >>> On Jul 16, 2019, at 5:14 PM, Maxim Kuvyrkov
> >>> wrote:
> >>>
> On Jul 16, 2019, at 3:34 PM, Jason Me
On Fri, Aug 02, 2019 at 10:48:55AM +0200, Martin Liška wrote:
> > Just a nit, some lines are too long and perhaps mklog could be improved too.
> > On the first line above, one would normally wrap it as:
> > * testsuite/23_containers/array/comparison_operators/constexpr.cc:
> > New test.
> >
This patch prevents gcc.dg/torture/ssa-fre-{5,7}.c from failing for the avr
target, by requiring effective-target int32.
Committed as obvious to trunk.
Regards
Senthil
2019-08-02 Senthil Kumar Selvaraj
* gcc.dg/torture/ssa-fre-5.c: Add dg-require-effective-target int32.
* gcc.dg/tortur
On Fri, Aug 02, 2019 at 10:47:10AM +0200, Martin Liška wrote:
> > Can you strace if other fds are opened and not closed in the spot you had it
> > before? Advantage of doing it there is that it will not be done for all the
> > -E/-S/-c compilations when the linker is not spawned.
>
> I've used th
On 8/2/19 9:48 AM, Jakub Jelinek wrote:
> On Fri, Aug 02, 2019 at 08:04:11AM +0200, Martin Liška wrote:
>> On 8/2/19 7:45 AM, Martin Liška wrote:
>>> I agree with that approach.
>>
>> I'm sending an example how it would look like for something
>> bigger:
>>
>> $ git diff
>> e8a3be407068bfb9c82f0f6
On 8/2/19 9:44 AM, Jakub Jelinek wrote:
> On Fri, Aug 02, 2019 at 08:30:47AM +0200, Martin Liška wrote:
>> On 8/1/19 4:41 PM, Jakub Jelinek wrote:
>>> On Thu, Aug 01, 2019 at 04:34:09PM +0200, Martin Liška wrote:
Ok, after deeper discussion with Honza, I would like to suggest the
origina
> On Aug 1, 2019, at 11:43 PM, Jason Merrill wrote:
>
> On Mon, Jul 22, 2019 at 5:05 AM Maxim Kuvyrkov
> wrote:
>>
>>> On Jul 16, 2019, at 5:14 PM, Maxim Kuvyrkov
>>> wrote:
>>>
On Jul 16, 2019, at 3:34 PM, Jason Merrill wrote:
On Tue, Jul 16, 2019 at 12:18 PM Maxim Kuvyrkov
> On Jul 22, 2019, at 12:05 PM, Maxim Kuvyrkov
> wrote:
>
...
As far as GCC conversion goes, below is what I plan to do and what not to
do. This is based on comments from everyone in this thread:
1. Construct GCC's git repo from SVN using same settings as current git
On Fri, Aug 2, 2019 at 9:50 AM Eric Botcazou wrote:
>
> Hi,
>
> some users tried to tweak the profile parameters in order to get more inlining
> and did the tweaking backwards, i.e. they actually got less inlining without
> realizing it. So the attached patch reworks the description of the 4 prof
On Thu, Aug 1, 2019 at 7:11 PM Eric Botcazou wrote:
>
> > So isn't this an issue with the code before when we have a RANGE_EXPR
> > that covers the wrapping point?
>
> No, see the reduced testcase attached in the PR.
>
> > Then index > max_index and may not catch the found element with
> >
> >
On Fri, Aug 2, 2019 at 9:54 AM Jakub Jelinek wrote:
>
> Hi!
>
> As mentioned in the PR, for SSE4.1 we use pextrb for vec_extractv16qiqi,
> but at least for element 0 we store the vector into memory and load the
> single byte from there and we can just use movd instead.
>
> The following patch does
Hi!
When Jonathan posted his libstdc++ patches for the math constants, I've
noticed that the constants in glibc grew up in number of digits since
they were added into libquadmath, apparently through:
https://sourceware.org/ml/libc-alpha/2012-05/msg02040.html
This backports that change to libquadma
Hi!
As mentioned in the PR, for SSE4.1 we use pextrb for vec_extractv16qiqi,
but at least for element 0 we store the vector into memory and load the
single byte from there and we can just use movd instead.
The following patch does that, just skips it for the case when we know we'll
go through mem
Hi,
some users tried to tweak the profile parameters in order to get more inlining
and did the tweaking backwards, i.e. they actually got less inlining without
realizing it. So the attached patch reworks the description of the 4 profile
parameters as well as changes a couple of things:
1. it
On Fri, Aug 02, 2019 at 08:04:11AM +0200, Martin Liška wrote:
> On 8/2/19 7:45 AM, Martin Liška wrote:
> > I agree with that approach.
>
> I'm sending an example how it would look like for something
> bigger:
>
> $ git diff
> e8a3be407068bfb9c82f0f6656b30d26cc2f484a~15..e8a3be407068bfb9c82f0f665
On Fri, Aug 02, 2019 at 08:30:47AM +0200, Martin Liška wrote:
> On 8/1/19 4:41 PM, Jakub Jelinek wrote:
> > On Thu, Aug 01, 2019 at 04:34:09PM +0200, Martin Liška wrote:
> >> Ok, after deeper discussion with Honza, I would like to suggest the
> >> original
> >> patch that was about proper detectio
> Note that the revision caused size increase of 548.exchange2_r SPEC 2017
> benchmark:
> https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=35.398.4
Are you sure? This should only change anything for nested functions.
--
Eric Botcazou
- argument and return value for libcall won't promote at
default_promote_function_mode_always_promote, however we expect it
should sign-extend as normal function.
- Witout this patch, this test case will fail at -march=rv64i -mabi=lp64.
- The implementation of riscv_promote_function_mode
> > gcc/ChangeLog
> > * config/riscv/riscv.c (riscv_promote_function_mode): New.
> > (TARGET_PROMOTE_FUNCTION_MODE): Use riscv_promote_function_mode.
> > gcc/testsuite/ChangeLog
> > * gcc.target/riscv/promote-type-for-libcall.c: New.
>
> Yes, this looks correct to me, though
94 matches
Mail list logo