On March 26, 2021 4:20:28 PM GMT+01:00, Florian Weimer
wrote:
>* Richard Biener:
>
>>> I think H.J. needs this for a function that isn't even
>always_inline,
>>> just extern inline __attribute__ ((gnu_inline)). Is that aspect
>>> something that could be solved for GCC 11?
>>
>> But that should
On Fri, Mar 26, 2021 at 03:42:22PM +0100, Tobias Burnus wrote:
> How about the following patch? It moves the aux function to
> libgomp.c-c++-common/on_device_arch.c
> and #includes it in the new wrapper files
> libgomp.{c,fortran}/on_device_arch.c.
> (Based on the observation that #include with
Hi,
The libgdruntime_convenience library was built with `-fversion=Shared',
but the libphobos part wasn't when creating the static library.
As there are no issues compiling in Shared code into the static library,
to avoid mismatches the flag is now always present when --enable-shared
is turned
Hi,
This patch fixes a build issue on sparc64-freebsd targets, all platforms
that could run on SPARC should include this header in order to avoid
errors from memmodel being used in sparc-protos.h.
Bootstrapped on x86_64-freebsd12 and committed to mainline.
Regards
Iain
---
gcc/ChangeLog:
On Tue, Mar 16, 2021 at 05:31:03PM -0500, will schmidt wrote:
> This addresses PR gdb/27525. The lnia and other variations
> of the addpcis instruction write the value of the NIA into a target register.
> If we are single-stepping across a breakpoint, the instruction is executed
> from a
Hi,
I'm seeing random scan-assembler-times failures in pr96770.c when LTO is used.
I suspect this is because the \\+4 string matches the LTO sections, sometimes.
I propose this small patch to avoid the issue, by matching arr\\+4 instead. OK?
2021-03-26 Christophe Lyon
gcc/testsuite/
*
Hi!
On 2021-03-25T12:54:31+0100, I wrote:
> On 2021-02-12T07:46:48-0800, Julian Brown wrote:
>> --- /dev/null
>> +++ b/libgomp/testsuite/libgomp.oacc-fortran/derivedtypes-arrays-1.f90
>> @@ -0,0 +1,109 @@
>> +[...]
>> +!$acc serial present(var3%t2(5)%t1%arr1)
>> +var3%t2(5)%t1%arr1(:,:) = 6
>>
Hi,
This patch defines IN_TARGET_CODE in all D language support files in the
back-end, to be consistent with other machine-specific files.
Bootstrapped and regression tested on x86_64-linux-gnu, and committed to
mainline as obvious.
Regards,
Iain.
---
gcc/ChangeLog:
*
> On 21/03/2021 12:58 Iain Buclaw wrote:
>
>
> Hi,
>
> This patch adds necessary backend support for MinGW/Cygwin targets so
> that all relevant predefined version conditions are available, a
> prerequesite for building most parts of libphobos.
>
After some more testing done building
* Jakub Jelinek via Gcc-patches:
> On Thu, Mar 25, 2021 at 11:36:37AM -0700, H.J. Lu via Gcc-patches wrote:
>> How can we move forward with it? I'd like to resolve it in GCC 11.
>
> I think it is too late for GCC 11 for this.
> Especially if the solution would be that we change the behavior of
On Fri, Mar 26, 2021 at 2:49 PM Florian Weimer wrote:
>
> * Jakub Jelinek via Gcc-patches:
>
> > On Thu, Mar 25, 2021 at 11:36:37AM -0700, H.J. Lu via Gcc-patches wrote:
> >> How can we move forward with it? I'd like to resolve it in GCC 11.
> >
> > I think it is too late for GCC 11 for this.
>
Hi Jakub,
great suggestion – I did now as proposed.
On 26.03.21 15:46, Jakub Jelinek via Gcc-patches wrote:
On Fri, Mar 26, 2021 at 03:42:22PM +0100, Tobias Burnus wrote:
How about the following patch? It moves the aux function to
libgomp.c-c++-common/on_device_arch.c
and #includes it in the
* Richard Biener:
>> I think H.J. needs this for a function that isn't even always_inline,
>> just extern inline __attribute__ ((gnu_inline)). Is that aspect
>> something that could be solved for GCC 11?
>
> But that should already work, no? Yes, it won't inline but also not
> error. Unless
On Fri, Mar 26, 2021 at 11:26 AM Jakub Jelinek wrote:
>
> On Fri, Mar 26, 2021 at 11:13:21AM +0100, Richard Biener wrote:
> > On Fri, Mar 26, 2021 at 9:34 AM Jakub Jelinek via Gcc-patches
> > wrote:
> > >
> > > On Thu, Mar 25, 2021 at 11:36:37AM -0700, H.J. Lu via Gcc-patches wrote:
> > > > How
On Thu, Mar 25, 2021 at 12:21:42PM -0500, will schmidt wrote:
> On Wed, 2021-03-10 at 18:50 +0100, Ulrich Weigand wrote:
> > Will Schmidt wrote:
> >
> > > This is a patch written by Alan Modra. With his permission
> > > I'm submitting this for review and helping get this upstream.
> > >
> > >
Hi Thomas, hi all,
your commit causes compile fails:
cc1: fatal error: ../lib/on_device_arch.c: No such file or directory
FAIL: libgomp.c/../libgomp.c-c++-common/task-detach-6.c (test for excess errors)
FAIL: libgomp.c/pr99555-1.c (test for excess errors)
FAIL:
On Fri, Mar 26, 2021 at 04:19:56PM +0100, Tobias Burnus wrote:
> Hi Jakub,
>
> great suggestion – I did now as proposed.
>
> On 26.03.21 15:46, Jakub Jelinek via Gcc-patches wrote:
> > On Fri, Mar 26, 2021 at 03:42:22PM +0100, Tobias Burnus wrote:
> > > How about the following patch? It moves
On 26/03/2021 15:35, Christophe Lyon via Gcc-patches wrote:
> Hi,
>
> I'm seeing random scan-assembler-times failures in pr96770.c when LTO is used.
>
> I suspect this is because the \\+4 string matches the LTO sections, sometimes.
>
> I propose this small patch to avoid the issue, by matching
On петък, 26 март 2021 г. 18:29:23 EET Jeff Law wrote:
> I am pleased to announce that the GCC Steering Committee has appointed
> Dimitar Dimitrov as maintainer of the TI PRU port in GCC.
>
>
> Dimitar, please update your listing in the MAINTAINERS file. Sorry it's
> taken so long to make this
On 3/26/21 3:41 PM, Marek Polacek wrote:
NSDMIs are a C++11 thing, and here we ICE with them on the non-C++11
path. Fortunately all we need is a small tweak to my recent r11-7835
patch (and a small tweak to the new test).
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
OK.
Currently each element in a gather load is costed as a scalar_load
and each element in a scatter store is costed as a scalar_store.
The load side seems to work pretty well in practice, since many
CPU-specific costs give loads quite a high cost relative to
arithmetic operations. However, stores
This patch makes the AArch64 vector code use its own vector
costs structure, rather than just using the default unsigned[3].
Unfortunately, it's not easy to make this change specific to
use_new_vector_costs, so this part is one that affects all CPUs.
The change is relatively mechanical though.
GCC usually costs the SVE and Advanced SIMD versions of a loop
and picks the one with the lowest cost. By default it will choose
SVE over Advanced SIMD in the event of tie.
This is normally the correct behaviour, not least because SVE can
handle every scalar iteration count whereas Advanced SIMD
This patch adds dedicated vector costs for Neoverse V1.
Previously we just used the Cortex-A57 costs, which isn't
ideal given that Cortex-A57 doesn't support SVE.
gcc/
* config/aarch64/aarch64.c (neoversev1_advsimd_vector_cost)
(neoversev1_sve_vector_cost): New cost structures.
This patch comes in two versions: submit.diff with Change.Logs or
submit2.diff with Change2.Logs.
The first fixes the problem by changing array temporaries from class
expressions into class temporaries. This permits the use of
gfc_get_class_from_expr to obtain the vptr for these temporaries and
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99766
The patch was successfully bootstrapped and tested on aarch64.
commit 0d37e2d3ead072ba57e03fcb97a041504a22e721
Author: Vladimir Makarov
Date: Fri Mar 26 17:09:24 2021 +
[PR99766] Consider relaxed memory
During development of modules, I had difficulty deciding whether the
module flags of a template should live on the decl_template_result, the
template_decl, or both. I chose the latter, and require them to be
consistent. This and a few other defects show how hard that consistency
is. Hence
When SVE is enabled, GCC needs to do a three-way comparison
between scalar, Advanced SIMD and SVE code. The normal costs
tend to be latency-based, which is well-suited to SLP. However,
comparing sums of latency costs means that we effectively treat
the code as executing sequentially. This can
SVE uses VECT_COMPARE_COSTS to tell the vectoriser to try as many
variations as it knows and pick the one with the lowest cost.
This serves two purposes:
(1) It means we can compare SVE loops that operate on packed vectors
with SVE loops that operate on unpacked vectors.
(2) It means that we
In practice it seems to be better not to cost a vector induction.
The scalar code generally needs the same induction but doesn't
cost it, making an apples-for-apples comparison harder. Most
inductions also have a low latency and their cost usually gets
hidden by other operations.
Like with the
If the scalar code does an integer load followed by an integer
extension, we've tended to cost that as two separate operations,
even though the extension is probably going to be free in practice.
This patch treats the extension as having zero cost, like we already
do for extending SVE loads.
Like
So far the costing of COND_EXPRs hasn't distinguished between
cases in which the condition is calculated separately or is
built into the COND_EXPR itself. This patch adds the cost
of any embedded comparison.
Like with the previous patches, this one only becomes active if
a CPU selects
Alex Coplan writes:
> Hi all,
>
> Here is a v2 patch which provides a more obviously fake answer to
> TARGET_BUILTIN_DECL: this can hopefully go in for GCC 11. For GCC 12, it
> seems that we should consider removing the target hook.
>
> Original patch:
>
On Fri, Mar 26, 2021 at 5:09 AM Richard Biener
wrote:
>
> On Fri, Mar 26, 2021 at 11:26 AM Jakub Jelinek wrote:
> >
> > On Fri, Mar 26, 2021 at 11:13:21AM +0100, Richard Biener wrote:
> > > On Fri, Mar 26, 2021 at 9:34 AM Jakub Jelinek via Gcc-patches
> > > wrote:
> > > >
> > > > On Thu, Mar
On 25/03/21 11:57 +, Jonathan Wakely wrote:
On 25/03/21 07:17 -0300, Alexandre Oliva wrote:
On Mar 24, 2021, Jonathan Wakely wrote:
This works for me on x86_64-linux and powerpc64le-linux, and also on
x86_64-linux when I kluge the config macros so that the new code path
gets used. Does
This patch is part of a series that makes opt-in tweaks to the
AArch64 vector cost model.
At the moment, all reductions are costed as vec_to_scalar, which
also includes things like extracting a single element from a vector.
This is a bit too coarse in practice, since the cost of a reduction
Most postincrements are cheap on Neoverse V1, but it's
generally better to avoid them on LD[34] and ST[34] instructions.
This patch adds separate address costs fields for these cases.
Other CPUs continue to use the same costs for all postincrements.
gcc/
* config/aarch64/aarch64-protos.h
Storing one element of a vector is costed as a vec_to_scalar
followed by a scalar_store. However, vec_to_scalar is also
used for reductions and for vector-to-GPR moves, which makes
it difficult to pick one cost for them all.
This patch therefore adds a cost for extracting one element
of a vector
At the moment, we cost LD[234] and ST[234] as N vector loads
or stores, which effectively treats the implied permute as free.
This patch adds additional costs for the permutes, which apply on
top of the costs for the loads and stores.
Like with the previous patches, this one only becomes active
Richard Biener writes:
> On Wed, 24 Mar 2021, Stam Markianos-Wright wrote:
>
>> Hi all,
>>
>> This patch resolves bug:
>>
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96974
>>
>> This is achieved by forcing a re-calculation of *stmt_vectype_out if an
>> incompatible combination of
NSDMIs are a C++11 thing, and here we ICE with them on the non-C++11
path. Fortunately all we need is a small tweak to my recent r11-7835
patch (and a small tweak to the new test).
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
gcc/cp/ChangeLog:
PR c++/98352
*
On 3/26/21 1:29 PM, Jakub Jelinek wrote:
On Thu, Mar 25, 2021 at 05:43:57PM -0400, Jason Merrill via Gcc-patches wrote:
Will e.g. GDB be happy about the changes?
I would expect so, but it would be good to have someone from GDB verify.
Ok, have verified it now on the testcase from the PR
Following on from the previous reduction costs patch, this one
adds costs for the SVE CLAST[AB] and FADDA instructions.
These instructions occur within the loop body, whereas the
reductions handled by the previous patch occur outside.
Like with the previous patch, this one only becomes active if
On Thu, Mar 25, 2021 at 05:43:57PM -0400, Jason Merrill via Gcc-patches wrote:
> > Will e.g. GDB be happy about the changes?
>
> I would expect so, but it would be good to have someone from GDB verify.
Ok, have verified it now on the testcase from the PR (stubbed out what it
calls, called it
This patch fixes an off-by-one buffer overflow issue.
Please commit.
diff --git a/gcc/fortran/misc.c b/gcc/fortran/misc.c
index 8a96243e80d..3d449ae17fe 100644
--- a/gcc/fortran/misc.c
+++ b/gcc/fortran/misc.c
@@ -124,8 +124,10 @@ gfc_basic_typename (bt type)
const char *
gfc_typename
Changes in Version 9 since Version 8:
Revised code to meet gcc coding standards in all files, especially
with respect to adding spaces around operations and removing
excess () in #define macro definitions.
Major revision to gcc/testsuite/gcc.c-torture/execute/ieee/cdivchkld.c
Prior
On Linux/x86_64,
d82797420c2238e31a7a25fe6db6bd05cd37224d is the first bad commit
commit d82797420c2238e31a7a25fe6db6bd05cd37224d
Author: Nathan Sidwell
Date: Fri Mar 26 10:46:31 2021 -0700
c++: imported templates and alias-template changes [PR 99283]
caused
FAIL:
On 2021-03-23 09:35, Jonathan Wakely wrote:
On 23/03/21 09:26 -0700, Thiago Macieira via Libstdc++ wrote: On
Tuesday, 23 March 2021 08:39:43 PDT Thomas Rodgers wrote: I will be
submitting a new patch for the
atomic.wait/barrier/latch/semaphore functionality a bit later today
that
subsumes
I review the allocator aware move constructors of _GLIBCXX_DEBUG containers.
I think the recently added __gnu_debug basic_string one is also missing
the rvalue reference, no ?
libstdc++: _GLIBCXX_DEBUG Fix allocator aware move constructor
Fix several allocator aware move construtor
The bug has been fixed for a few years now. r11-7869 adds the test
for it: https://gcc.gnu.org/g:980b12cc81979e52f491bf0dfe961d30c07fe864
Martin
ChangeLog:
* MAINTAINERS: Add myself as pru port maintainer.
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 1722f0aa8fc..0fbbc0519d0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -96,6 +96,7 @@ nvptx portTom
From: "luo...@cn.ibm.com"
32bit and P7 VSX could also benefit a lot from the variable vec_insert
implementation with shift/insert/shift back method.
Tested pass on P7BE/P8BE/P8LE{-m32,m64} and P9LE{m64}.
gcc/ChangeLog:
PR target/99718
* config/rs6000/altivec.md
Hi Paul,
I do not understand the !UNLIMITED_POLY(fsym) part of the patch.
In particular, your patch causes foo.f90 to fail by wrongly diagnosting:
Fortran runtime error: Pointer actual argument 'cptr' is not associated
I have only did some light tests – but it seems that just removing
'&&
On Fri, Mar 26, 2021 at 9:34 AM Jakub Jelinek via Gcc-patches
wrote:
>
> On Thu, Mar 25, 2021 at 11:36:37AM -0700, H.J. Lu via Gcc-patches wrote:
> > How can we move forward with it? I'd like to resolve it in GCC 11.
>
> I think it is too late for GCC 11 for this.
> Especially if the solution
On Fri, Mar 26, 2021 at 11:13:21AM +0100, Richard Biener wrote:
> On Fri, Mar 26, 2021 at 9:34 AM Jakub Jelinek via Gcc-patches
> wrote:
> >
> > On Thu, Mar 25, 2021 at 11:36:37AM -0700, H.J. Lu via Gcc-patches wrote:
> > > How can we move forward with it? I'd like to resolve it in GCC 11.
> >
>
On Thu, Mar 25, 2021 at 7:37 PM H.J. Lu wrote:
>
> On Thu, Mar 25, 2021 at 7:54 AM Jakub Jelinek via Gcc-patches
> wrote:
> >
> > On Thu, Mar 25, 2021 at 03:40:51PM +0100, Richard Biener wrote:
> > > I think the "proper" way to do this is to have 'open' above end up
> > > refering to the
On Thu, Mar 25, 2021 at 11:36:37AM -0700, H.J. Lu via Gcc-patches wrote:
> How can we move forward with it? I'd like to resolve it in GCC 11.
I think it is too late for GCC 11 for this.
Especially if the solution would be that we change the behavior of existing
attribute, we would need enough
Hi Tobias,
Please go ahead and commit the patch. I think that your analysis is correct
about expr_null and that your patch is the best way to deal with the
problem.
Best regards
Paul
On Tue, 23 Mar 2021 at 17:54, Tobias Burnus wrote:
> Hi Paul,
>
> On 23.03.21 18:34, Paul Richard Thomas
Hi, sorry for late response,
On 2021/3/23 16:50, Richard Biener wrote:
>>> It definitely should be before uncprop (but context stops there). And yes,
>>> re-running passes isn't the very, very best thing to do without explaining
>>> it cannot be done in other ways. Not for late stage 3 anyway.
This patch is straightforward but the isolation of the problem was rather
less so. Many thanks to Juergen for testcase reduction.
Regtested on FC33/x86_64 - OK for master?
Paul
Fortran: Fix problem with runtime pointer chack [PR99602].
2021-03-26 Paul Thomas
gcc/fortran/ChangeLog
PR
60 matches
Mail list logo
