On 3/24/20 11:45 AM, Marek Polacek wrote:
On Mon, Mar 23, 2020 at 10:41:28AM -0400, Jason Merrill wrote:
On 3/20/20 7:02 PM, Marek Polacek wrote:
On Fri, Mar 20, 2020 at 02:12:49PM -0400, Jason Merrill wrote:
On 3/20/20 1:06 PM, Marek Polacek wrote:
Wonderful. I've added a bunch of tests, an
Hi Kyrill,
Thanks for pointing out the two missing bug fixes.
Please see attached all the back-ported patches.
All the patches from trunk applied cleanly with no conflicts (except for the
ChangeLog files) to the gcc-9 branch.
An up to date gcc-9 branch on which I applied the attached patches has
Hi!
Just as a reminder, we still have a Bountysource campaign for the AVR backend
running in case someone is looking for an opportunity to make a little money
while working on GCC [1].
The campaign has not been as successful as the campaign for m68k [2] but there
is still a chance that we might g
On 3/23/20 11:06 AM, Marek Polacek wrote:
On Tue, Mar 17, 2020 at 04:05:31PM -0400, Jason Merrill wrote:
On 3/16/20 10:01 PM, Marek Polacek wrote:
On Mon, Mar 16, 2020 at 05:12:15PM -0400, Jason Merrill wrote:
On 3/16/20 10:57 AM, Marek Polacek wrote:
Now that convert_like creates an IMPLICIT
While looking at PR94186 I also noticed this regression; if a non-type
template parameter uses a type parameter in its type, we need to map both
template parameters.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/cp/ChangeLog
2020-03-24 Jason Merrill
* pt.c (any_template_parm_r):
It would have been trivial to make the error for non-bool constraint in
satisfy_atom unconditional, but that didn't give context for the error or
printing with the dependent form and template arguments. So I changed a
couple of places so that, when a hard error is encountered during quiet
substitu
In the testcase for PR94186, we have a SCOPE_REF with no location even
though at one point it was in a cp_expr which had a location. So let's make
the cp_expr constructor that takes a location apply it to the expression
when possible.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/cp/ChangeL
Thanks to Frank Ch. Eigler for the updated link.
Pushed.
Gerald
---
htdocs/contribute.html | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/htdocs/contribute.html b/htdocs/contribute.html
index 052f778e..3d03b9d1 100644
--- a/htdocs/contribute.html
+++ b/htdocs/contribute.html
Hi!
On 2020-03-23T16:29:40+0100, I wrote:
> On 2018-09-14T10:18:12-0600, Jeff Law wrote:
>> On 9/5/18 5:52 AM, a...@codesourcery.com wrote:
>>>
>>> The GCN toolchain must use the LLVM assembler and linker because there's no
>>> binutils port. The LLVM tools do not have the same diagnostic style
On Mar 17, 2020, at 2:52 PM, Maciej W. Rozycki wrote:
>
> On Fri, 28 Feb 2020, H.J. Lu wrote:
>>
>> Libffi 3.4 ABI was changed to support CET. But it isn't the first
>> time ABI change for libffi,
>
> Have we made any conclusions WRT the way to move forward with this stuff?
> Things remain b
Nathan Sidwell wrote:
On 3/24/20 2:08 PM, Iain Sandoe wrote:
Hi Nathan,
Thanks for the review,
comments embedded and a new version attached.
@David, you added the CALL_EXPR_MUST_TAIL_CALL which I’ve made use of
here (but with an observation). Perhaps you would be able to comment on
whether
rs6000: Update bswap64-4 test to reflect actual results
Hi,
Update existing testcase powerpc/bswap64-4.c to
reflect that we generate ldbrx and stdbrx instructions
for newer cpu targets. This is in contrast to the
pair of lwbrx and stwbrx instructions that are
generated with older cpu targets.
On 3/24/20 2:08 PM, Iain Sandoe wrote:
Hi Nathan,
Thanks for the review,
comments embedded and a new version attached.
@David, you added the CALL_EXPR_MUST_TAIL_CALL which I’ve made use of
here (but with an observation). Perhaps you would be able to comment on whether
I’ve (ab-)used it correctl
Hi Nathan,
Thanks for the review,
comments embedded and a new version attached.
@David, you added the CALL_EXPR_MUST_TAIL_CALL which I’ve made use of
here (but with an observation). Perhaps you would be able to comment on whether
I’ve (ab-)used it correctly?
OK for master now?
thanks
Iain
Natha
Thanks Hans-Peter for reviewing.
Here is Formatted ChangeLog Entry.
2020-03-24 Kamlesh Kumar
* rtl.h: Defined Tuple for bundling rtx, mode and unsignedness
(default as 0), Added Extra argument (unsignedp)
in emit_library_call and emit_library_call_value.
* except.c: Likewise.
* explow.c: Likew
I was looking into this yesterday but I ran into some issues.
The first is that blindly converting each output to in+out breaks
cases where an input already overlaps with an output:
asm ("..." : "=r" (out) : "0" (in));
This could be worked around by scanning the input list and only
converting
On Mon, 2020-03-16 at 18:00 -0600, Martin Sebor wrote:
> PR middle-end/94004 - missing -Walloca on calls to alloca due to -Wno-system-
> headers
>
> gcc/testsuite/ChangeLog:
>
> PR middle-end/94004
> * gcc.dg/Walloca-larger-than-3.c: New test.
> * gcc.dg/Walloca-larger-than-3.h:
On Tue, 24 Mar 2020, Hans-Peter Nilsson wrote:
> The new argument is default 0, so make use of that: do not patch
> all those files where 0 is fine.
Oops, I was tricked by the comment; it's not actually "default 0"
in the C++ sense. And you have an overloaded function with
different numbers of
On Mon, 2020-03-23 at 16:09 +0100, Martin Liška wrote:
> From 1431a34f70128bdce59c94dad1d10f91673f63eb Mon Sep 17 00:00:00 2001
> From: Martin Liska
> Date: Thu, 16 Jan 2020 10:38:41 +0100
> Subject: [PATCH] Make target_clones resolver fn static if possible.
>
> gcc/ChangeLog:
>
> 2020-03-17 Ma
On Tue, 2020-03-24 at 07:34 +0100, Martin Liška wrote:
> Hi.
>
> The patch respects --without-zstd and reports
> an error when we can't find header file with --with-zstd.
>
> Ready to be installed?
> Thanks,
> Martin
>
> gcc/ChangeLog:
>
> 2020-03-23 Martin Liska
>
> PR lto/94259
>
Although Martin provided stronger fix, this fixes lto/94249 on hppa-linux. It
seems we
never defined __BIG_ENDIAN__. Probably, a few packages test for it.
Tested on hppa-unknown-linux-gnu. Committed to trunk, gcc-9 and gcc-8.
Dave
2020-03-24 John David Anglin
PR lto/94249
Please excuse some cheap points:
On Mon, 23 Mar 2020, kamlesh kumar via Gcc-patches wrote:
> Attached patch fixes.
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88877.
> ChangeLog Entry.
>
> 2020-03-23 Kamlesh Kumar
>
> * rtl.h : Defined Tuple for bundling rtx, mode and
> unsignedness
On Mon, Mar 23, 2020 at 10:41:28AM -0400, Jason Merrill wrote:
> On 3/20/20 7:02 PM, Marek Polacek wrote:
> > On Fri, Mar 20, 2020 at 02:12:49PM -0400, Jason Merrill wrote:
> > > On 3/20/20 1:06 PM, Marek Polacek wrote:
> > > > Wonderful. I've added a bunch of tests, and some from the related DRs
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 Ukrainian team of translators. The file is available at:
https://translationproject.org/latest/gcc/uk.po
(This file, 'gcc-10.1-b20200322.uk.p
On Tue, Mar 24, 2020 at 06:30:12AM +, Yangfei (Felix) wrote:
> I modified combine emitting a simple AND operation instead of making one
> zero_extract for this scenario.
> Attached please find the new patch. Hope this solves both of our concerns.
This looks promising. I'll try it out, s
Hi Christophe,
> -Original Message-
> From: Gcc-patches On Behalf Of
> Christophe Lyon via Gcc-patches
> Sent: 24 March 2020 14:27
> To: gcc-patches@gcc.gnu.org
> Subject: [PATCH 1/3] [testsuite, arm] target-supports.exp: Add
> arm_fp_dp_ok effective-target
>
> Some tests require double-
Parts of the cmp-2.c test rely on double-precision support, making the
test fail on targets where the FPU supports single-precision only.
Split the test into single-precision (cmp-2.c) and double-precision
tests (cmp-3.c).
2020-03-24 Christophe Lyon
gcc/testsuite/
* gcc.target
Some tests require double-precision support, but the existing
arm_fp_ok effective-target only checks if hardware floating-point is
available, not what level. So this patch adds a new arm_fp_dp_ok
effective-target to check that double-precision is supported.
2020-03-24 Christophe Lyon
g
Switch to arm_fp_dp_ok effective-target in tests that require
double-precision support from the FPU.
2020-03-24 Christophe Lyon
gcc/testsuite/
* gcc/arm/vfp-1.c: Use arm_fp__ok effective-target.
* gcc.target/arm/vfp-ldmdbd.c: Likewise.
* gcc.target/arm/vfp-ldmia
Hi Jason,
Sorry I haven't been able to get back to this. I've been swamped with
other work, and we haven't had the resources to properly address this.
Jeff Chapman will be working on cleaning this up for when master/trunk
re-opens.
> I find the proposed always_continue semantics kind of nonsensi
On Tue, Mar 24, 2020 at 12:37 PM Yangfei (Felix) wrote:
>
> Hi!
>
> > -Original Message-
> > From: Richard Biener [mailto:richard.guent...@gmail.com]
> > Sent: Monday, March 23, 2020 11:25 PM
> > To: Yangfei (Felix)
> > Cc: gcc-patches@gcc.gnu.org
> > Subject: Re: [RFC] Should widening_mu
On Tue, Mar 24, 2020 at 10:45 AM Stefan Schulze Frielinghaus
wrote:
>
> On Mon, Mar 23, 2020 at 04:44:56PM +0100, Richard Biener wrote:
> > On Mon, Mar 23, 2020 at 4:34 PM Jakub Jelinek wrote:
> > >
> > > On Mon, Mar 23, 2020 at 04:29:12PM +0100, Richard Biener wrote:
> > > > I wonder if we can l
On Tue, Mar 24, 2020 at 02:16:40PM +0100, Tobias Burnus wrote:
> For nvptx, targetm_common.have_named_sections, hence one is
You mean targetm_common.have_named_sections is false, right?
> in the else branch of omp_finish_file – and the else branch
> did not handle target-link variables.
>
> With
For nvptx, targetm_common.have_named_sections, hence one is
in the else branch of omp_finish_file – and the else branch
did not handle target-link variables.
With this patch, the libgomp.c/target-link-1.c testcase now works.
When looking at the nvptx "assembler", I saw that TREE_PUBLIC was
set f
On 3/20/20 11:40 AM, Iain Sandoe via Gcc-patches wrote:
2020-03-20 Iain Sandoe
* coroutines.cc (coro_init_identifiers): Initialize an identifier
for the cororoutine handle 'address' method name.
(struct coro_aw_data): Add fields to cover the continuations.
(co
On Tue, 24 Mar 2020, Jakub Jelinek wrote:
> On Tue, Mar 24, 2020 at 10:59:19AM +0100, Richard Biener wrote:
> > Likely
> >
> > /* Delete dead statements. */
> > gsi = gsi_start_bb (bb);
> > while (!gsi_end_p (gsi))
> > {
> >
> > needs to instead work back-to-front for debug stmt adjus
Hi!
> -Original Message-
> From: Richard Biener [mailto:richard.guent...@gmail.com]
> Sent: Monday, March 23, 2020 11:25 PM
> To: Yangfei (Felix)
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [RFC] Should widening_mul should consider block frequency?
>
> On Mon, Mar 23, 2020 at 10:53 AM Y
On Tue, Mar 24, 2020 at 11:32:32AM +0100, Martin Liška wrote:
> >From 82b8731f304c734353c34ddaf1b1265341a90882 Mon Sep 17 00:00:00 2001
> From: Martin Liska
> Date: Tue, 24 Mar 2020 09:12:50 +0100
> Subject: [PATCH] Improve endianess detection.
>
> include/ChangeLog:
>
> 2020-03-24 Martin Liska
On 3/24/20 10:18 AM, Jakub Jelinek wrote:
Hi!
So, assuming I'm on glibc with GCC 4.5 on powerpc64-linux.
On Tue, Mar 24, 2020 at 09:49:42AM +0100, Martin Liška wrote:
+/* Detect endianess based on __BYTE_ORDER__ macro. */
+#if defined(__BYTE_ORDER__) && defined(__ORDER_BIG_ENDIAN__) && \
+
On Tue, Mar 24, 2020 at 10:59:19AM +0100, Richard Biener wrote:
> Likely
>
> /* Delete dead statements. */
> gsi = gsi_start_bb (bb);
> while (!gsi_end_p (gsi))
> {
>
> needs to instead work back-to-front for debug stmt adjustment to work
Indeed, that seems to work. Ok for trunk if i
On 3/11/20 2:28 PM, Tobias Burnus wrote:
Fortran patch:
https://gcc.gnu.org/pipermail/gcc-patches/current/541774.html
Like for Fortran, it also fixes some other issues – here for C++
related to namespaces. (For class, see PR c++/94140.)
Test case of the PR yields an ICE in the middle end and th
Hello, gentle maintainer.
This is a message from the Translation Project robot. (If you have
any questions, send them to .)
A new POT file for textual domain 'gcc' has been made available
to the language teams for translation. It is archived as:
https://translationproject.org/POT-files/gcc
On Tue, 24 Mar 2020, Martin Liška wrote:
> Hi.
>
> This patch caused:
>
> gcc
> /home/marxin/Programming/gcc/gcc/testsuite/gcc.c-torture/compile/990625-2.c
> -O3 -g -fno-tree-dce -c
> during GIMPLE pass: ifcvt
> /home/marxin/Programming/gcc/gcc/testsuite/gcc.c-torture/compile/990625-2.c:
> In fu
On Mon, Mar 23, 2020 at 06:00:06PM -0600, Jeff Law via Gcc-patches wrote:
> +/* Return true if CODE is valid for comparisons of mode MODE, false
> + otherwise.
> +
> + It is always safe to return false, even if the code was valid for the
> + given mode as that will merely suppress optimizatio
On Mon, Mar 23, 2020 at 04:44:56PM +0100, Richard Biener wrote:
> On Mon, Mar 23, 2020 at 4:34 PM Jakub Jelinek wrote:
> >
> > On Mon, Mar 23, 2020 at 04:29:12PM +0100, Richard Biener wrote:
> > > I wonder if we can leverage the bswap pass for rotate detection
> > > (see find_bswap_or_nop which ma
Hi!
So, assuming I'm on glibc with GCC 4.5 on powerpc64-linux.
On Tue, Mar 24, 2020 at 09:49:42AM +0100, Martin Liška wrote:
> +/* Detect endianess based on __BYTE_ORDER__ macro. */
> +#if defined(__BYTE_ORDER__) && defined(__ORDER_BIG_ENDIAN__) && \
> +defined(__ORDER_LITTLE_ENDIAN__) && de
Hi.
This patch caused:
gcc /home/marxin/Programming/gcc/gcc/testsuite/gcc.c-torture/compile/990625-2.c
-O3 -g -fno-tree-dce -c
during GIMPLE pass: ifcvt
/home/marxin/Programming/gcc/gcc/testsuite/gcc.c-torture/compile/990625-2.c: In
function ‘broken030599’:
/home/marxin/Programming/gcc/gcc/tes
> -Original Message-
> From: Jakub Jelinek
> Sent: 24 March 2020 08:20
> To: Richard Earnshaw ; Ramana
> Radhakrishnan ; Kyrylo Tkachov
>
> Cc: gcc-patches@gcc.gnu.org
> Subject: [PATCH] arm: Fix arm {,u}subvdi4 and usubvsi4 expanders [PR94286]
>
> Hi!
>
> The following testcase ICEs
On 3/24/20 9:31 AM, Jakub Jelinek wrote:
On Tue, Mar 24, 2020 at 09:19:12AM +0100, Martin Liška wrote:
2020-03-24 Martin Liska
PR lto/94249
* plugin-api.h: Add more robust endianess detection.
---
include/plugin-api.h | 43 +--
1 fil
On Tue, Mar 24, 2020 at 09:19:12AM +0100, Martin Liška wrote:
> 2020-03-24 Martin Liska
>
> PR lto/94249
> * plugin-api.h: Add more robust endianess detection.
> ---
> include/plugin-api.h | 43 +--
> 1 file changed, 41 insertions(+), 2 delet
Hi,
on 2020/3/18 下午11:10, Richard Biener wrote:
> On Wed, Mar 18, 2020 at 2:56 PM Kewen.Lin wrote:
>>
>> Hi Richi,
>>
>> Thanks for your comments.
>>
>> on 2020/3/18 下午6:39, Richard Biener wrote:
>>> On Wed, Mar 18, 2020 at 11:06 AM Kewen.Lin wrote:
>> This path can define overrun_p to fals
Hi!
The following testcase ICEs, because these expanders will happily create
a SImode 0x8000 CONST_INT, which is not valid RTL, as CONST_INTs need to
be sign extended from the mode precision to full HWI.
Fixed thusly, bootstrapped/regtested on armv7hl-linux-gnueabi, ok for trunk?
2020-03-24
All right, there's update endianess detection that should be robust
enough.
I've tested that on x86_64-linux-gnu and sparc64-linux.
Ready for master?
Thanks,
Martin
>From be4ce2c54672e7772586c13d6e37c63124624bbc Mon Sep 17 00:00:00 2001
From: Martin Liska
Date: Tue, 24 Mar 2020 09:12:50 +0100
S
On Tue, 24 Mar 2020, Jakub Jelinek wrote:
> Hi!
>
> The following testcase FAILs with -fcompare-debug. The problem is that
> create_iv behaves differently when inserting after into an empty bb (in that
> case sets location to goto_locus), or when inserting before gsi_end_p (i.e.
> at the end of
On Tue, 24 Mar 2020, Jakub Jelinek wrote:
> Hi!
>
> The following testcase shows -fcompare-debug bugs in ifcvt_local_dce,
> where the decisions what statements are needed is based also on debug stmt
> operands, which is wrong.
> So, this patch makes sure to never add debug stmt to the worklist, o
Hi!
The following testcase FAILs with -fcompare-debug. The problem is that
create_iv behaves differently when inserting after into an empty bb (in that
case sets location to goto_locus), or when inserting before gsi_end_p (i.e.
at the end of bb; in that case it will not set location, otherwise it
Hi!
The following testcase shows -fcompare-debug bugs in ifcvt_local_dce,
where the decisions what statements are needed is based also on debug stmt
operands, which is wrong.
So, this patch makes sure to never add debug stmt to the worklist, or never
add an assign to worklist just because it is us
On Tue, 24 Mar 2020, Jakub Jelinek wrote:
> Hi!
>
> The following testcase FAILs with -fcompare-debug, but not because -g vs.
> -g0 would make a difference, but because the second compilation is done with
> -w in order not to emit warnings twice and -w seems to affect the *.gkd dump
> content.
>
Hi!
The following testcase FAILs with -fcompare-debug, but not because -g vs.
-g0 would make a difference, but because the second compilation is done with
-w in order not to emit warnings twice and -w seems to affect the *.gkd dump
content.
This is because TREE_NO_WARNING flag, or warn_unused_func
Hi!
The following testcase FAILs with -fcompare-debug. The problem is that
the C++ FE initially uses IF_STMTs, tcc_statement which default to
TREE_SIDE_EFFECTS set, but later on is genericized into COND_EXPRs,
tcc_expression which default to TREE_SIDE_EFFECTS ored from all 3 operands.
Furthermore
60 matches
Mail list logo
