> Hi,
> with Jan's patch commited in r278878 we can use symver attribute for functions
> and variables. The symver attribute is designed for replacing toplevel asm
> statements containing ".symver" which may be removed by LTO. Unfortunately,
> a quick test shown GCC still generates buggy so file
Hi Thomas,
updated version committed (r279456) – which adds 'acc_device_gcn' to
openacc_lib.h – besides the other cleanup.
On 12/16/19 9:41 PM, Thomas Schwinge wrote
I'll point out there also exists 'libgomp/config/accel/openacc.f90',
I have now updated that file in the same way – and added
I've noticed a few minor problems with this patch series after I sent it
out (mostly testcase stuff, one documentation tidy-up, but also that one
patch didn't bootstrap due to something fixed in a later patch).
I also rely on a documentation change that isn't part of the series.
I figure I
Hi,
as reported in PR 92971, IPA-CP's
cgraph_edge_brings_all_agg_vals_for_node defines one local variable with
the static keyword which is a clear mistake, probabley a cut'n'paste
error when I originally wrote the code.
I'll commit the following as obvious after a round of bootstrap and
testing.
On 12/16/19 2:45 PM, Martin Jambor wrote:
> On Sat, Dec 07 2019, Jeff Law wrote:
>> [...]
> I'm afraid I that -Wmaybe-uninitialized is getting out of hand. I bet
> that some users regularly get these warnings coming from c++ header
> "libraries" (like they sometimes come out our vec.h which
This patch implements the count leading and trailing zeros instruction
patterns in the AMD GCN backend.
This is prerequisite for implementing the extract_last patterns.
Andrew Stubbs
Mentor Graphics / CodeSourcery
Add clz and ctz for amdgcn
2019-12-17 Andrew Stubbs
gcc/
*
This patch implements the vector extract last instruction patterns in
the AMD GCN backend.
This is both an optimization and a "fix" for pr92772, in which the
conditional reduction algorithm is broken for architectures with masked
vectors.
This fixes too many testcase failures in vect.exp to
On 2019-12-17 09:32 +0100, Jan Hubicka wrote:
> > Hi,
> > with Jan's patch commited in r278878 we can use symver attribute for
> > functions
> > and variables. The symver attribute is designed for replacing toplevel asm
> > statements containing ".symver" which may be removed by LTO.
Hi,
the previous patch unfortunately does not fix the first testcase in PR
92706 and since I am afraid it might be the important one, I also
focused on that. The issue here is again total scalarization accesses
clashing with those representing accesses in the IL - on another
aggregate but here
Hi,
PR 92486 shows that DSE, when seeing a "normal" gimple aggregate
assignment coming from a C struct assignment and one a representing a
folded memcpy, can kill the latter and keep in place only the former,
which does not copy padding - at least when SRA decides to totally
scalarize a least one
Hi,
this patch fixes the second testcase in PR 92706 by performing total
scalarization only quite a bit later, when we already have access
trees constructed and even done propagation of accesses from RHSs of
assignment to LHSs.
The new code simultaneously traverses the existing access tree and
Hi,
because the follow-up patches perform some non-trivial operations on
SRA patches, I wrote myself a verifier. And sure enough, it has
spotted two issues, one of which is fixed in this patch too - we did
not correctly set the parent link when creating artificial accesses
for propagation across
Hi Julian!
As a first step, can you please split out just the code required to make
the OpenACC 'acc_attach*', 'acc_detach*' runtime library routines work?
Assuming there were no other defects in libgomp, whould this already make
the 'libgomp.oacc-c-c++-common/deep-copy-3.c',
This patch only changes a comment, so I'm committing it as "obvious".
The point is that I don't intend to spend the time to fix the bug
because implementing the fold_extract_last is both a work around and an
optimization, but future ports might encounter the same problem and
hopefully the
On Tue, Dec 17, 2019 at 01:50:32PM +0100, Martin Jambor wrote:
> Hi,
>
> as reported in PR 92971, IPA-CP's
> cgraph_edge_brings_all_agg_vals_for_node defines one local variable with
> the static keyword which is a clear mistake, probabley a cut'n'paste
> error when I originally wrote the code.
>
Hi Christophe,
On 11/18/19 9:00 AM, Christophe Lyon wrote:
On Wed, 13 Nov 2019 at 15:46, Christophe Lyon
wrote:
>
> On Tue, 12 Nov 2019 at 12:13, Richard Earnshaw (lists)
> wrote:
> >
> > On 18/10/2019 14:18, Christophe Lyon wrote:
> > > + bool not_supported = arm_arch_notm || flag_pic
Hi!
When looking at the PR, I wrote a cleanup patch with various things I've
noticed, with latest Martin's changes half of them aren't valid anymore, but
I found further ones.
So, besides formatting fixes, this patch tries to make sure the rng1 ranges
are meaningful even in some corner cases.
Hi!
I'd like to ping this patch (with the sizeof (c) -> sizeof (c) / sizeof (c[0])
testsuite fix Andreas pointed out).
Thanks!
On Tue, Dec 10, 2019 at 10:57:35AM +0100, Jakub Jelinek wrote:
> 2019-12-10 Jakub Jelinek
>
> PR target/92841
> * config/i386/i386.md
Hi Mihail,
On 12/16/19 6:29 PM, Mihail Ionescu wrote:
Hi Kyrill,
On 11/12/2019 09:55 AM, Kyrill Tkachov wrote:
Hi Mihail,
On 10/23/19 10:26 AM, Mihail Ionescu wrote:
[PATCH, GCC/ARM, 4/10] Clear GPR with CLRM
Hi,
=== Context ===
This patch is part of a patch series to add support for
Ping?
On Wed, 11 Dec 2019 at 18:19, Christophe Lyon
wrote:
>
> Ping?
>
> Le jeu. 5 déc. 2019 à 11:13, Christophe Lyon a
> écrit :
>>
>> ping?
>> https://gcc.gnu.org/ml/gcc-patches/2019-11/msg01667.html
>>
>> Kyrill approved the previous version modulo a typo fix, but Richard
>> wanted a better
Hello,
This patch to libstdc++ configure ensures that pthread_rwlock_t is used only
when pthread is used for gthreads implementation.
The original issue is that VxWorks comes with its native tasking layer and an
optional pthread layer built above it. As pthread is an optional feature of the
Hi!
The bug report complained just about missing RDPID and WBNOINVD in znver2
description and double comma before CLWB, but reading the docs I found
various other nits and when trying to compare it with what the compiler
actually does, I found ugly formatting there too.
Bootstrapped/regtested on
Hi,
On Tue, Dec 17 2019, Thomas Schwinge wrote:
> On 2019-11-14T16:35:31+0100, Frederik Harwath
> wrote:
>> this patch implements OpenACC 2.6 "acc_get_property" and related functions.
>
> [...]
>
>> --- a/libgomp/plugin/plugin-hsa.c
>> +++ b/libgomp/plugin/plugin-hsa.c
>> @@ -699,6 +699,32 @@
On 16/12/2019 23:00, Thomas Schwinge wrote:
There is no AMD GCN support yet. This will be added later on.
ACK, just to note that there now is a 'libgomp/plugin/plugin-gcn.c' that
at least needs to get a stub implementation (can mostly copy from
'libgomp/plugin/plugin-hsa.c'?) as otherwise the
Hi Mihail,
On 12/16/19 6:28 PM, Mihail Ionescu wrote:
Hi Kyrill
On 11/06/2019 03:59 PM, Kyrill Tkachov wrote:
Hi Mihail,
On 11/4/19 4:49 PM, Kyrill Tkachov wrote:
Hi Mihail,
On 10/23/19 10:26 AM, Mihail Ionescu wrote:
> [PATCH, GCC/ARM, 2/10] Add command line support
>
> Hi,
>
> ===
Hi Mihail,
On 12/16/19 6:29 PM, Mihail Ionescu wrote:
Hi Kyrill,
On 11/06/2019 04:12 PM, Kyrill Tkachov wrote:
Hi Mihail,
On 10/23/19 10:26 AM, Mihail Ionescu wrote:
[PATCH, GCC/ARM, 3/10] Save/restore FPCXTNS in nsentry functions
Hi,
=== Context ===
This patch is part of a patch series
On Tue, Dec 17, 2019 at 10:09 AM Jakub Jelinek wrote:
>
> Hi!
>
> The bug report complained just about missing RDPID and WBNOINVD in znver2
> description and double comma before CLWB, but reading the docs I found
> various other nits and when trying to compare it with what the compiler
> actually
This suppresses an array out of bounds warning in mkdeps.c as proposed
by Martin Sebor in the bugzilla.
array subscript 2 is outside array bounds of ‘const char [2]’
Since this warning does occur during bootstrap it currently breaks
werror builds on IBM Z.
The problem can be reproduced also on
On Tue, Dec 10, 2019 at 10:57 AM Jakub Jelinek wrote:
>
> Hi!
>
> The stack_protect_set_1_ pattern intentionally clears the register it
> used as a temporary to read the canary from the register and push it back
> on the stack for security reasons, to make sure the stack canary isn't
> spilled
If argument for a self-recursive call is a simple pass-through, the call
edge is also considered as source of any value originated from
non-recursive call to the function. Scalar pass-through and full aggregate
pass-through due to pointer pass-through have also been handled.
But we missed another
On 12/17/19 2:33 PM, Christophe Lyon wrote:
On Tue, 17 Dec 2019 at 11:34, Kyrill Tkachov
wrote:
Hi Christophe,
On 11/18/19 9:00 AM, Christophe Lyon wrote:
On Wed, 13 Nov 2019 at 15:46, Christophe Lyon
wrote:
On Tue, 12 Nov 2019 at 12:13, Richard Earnshaw (lists)
wrote:
On 18/10/2019
On 12/13/19 11:15 AM, Richard Sandiford wrote:
> Stam Markianos-Wright writes:
>> Hi all,
>>
>> This small patch adds support for the ARM v8.6 extensions +bf16 and
>> +i8mm to the testsuite. This will be tested through other upcoming
>> patches, which is why we are not providing any explicit
On Dez 17 2019, Jan Hubicka wrote:
> Index: symtab.c
> ===
> --- symtab.c (revision 279178)
> +++ symtab.c (working copy)
> @@ -1952,6 +1952,11 @@ symtab_node::get_partitioning_class (voi
>if (DECL_EXTERNAL (decl))
>
Hi Jakub!
On 2019-11-06T18:43:39+, Julian Brown wrote:
> In particular, [a new big patch] incorporates the idea [...]
> relating to adding the new "attach_count" field to the memory-mapping
> splay tree key type without growing that structure in the common case
> (i.e. when structure
Hi!
On Tue, Dec 10, 2019 at 10:02:47PM +0100, Jakub Jelinek wrote:
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> Or do you want to use an additional bit for that?
>
> 2019-12-10 Jakub Jelinek
>
> PR c++/59655
> * pt.c (push_tinst_level_loc): If
Hi!
On Wed, Dec 11, 2019 at 07:12:23PM -0500, Michael Meissner wrote:
> --- gcc/config/rs6000/rs6000.c(revision 279141)
> +++ gcc/config/rs6000/rs6000.c(working copy)
> @@ -5541,6 +5541,10 @@ num_insns_constant_gpr (HOST_WIDE_INT va
> && (value >> 31 == -1 || value >> 31
Hi!
On Wed, Dec 11, 2019 at 07:15:15PM -0500, Michael Meissner wrote:
> This patch adds an alternative to use PLI to load up large SImode constants if
> -mcpu=future is used.
>
> * config/rs6000/rs6000.md (movsi_internal1): Add alternative to
> use PLI to load up 34-bit constants if
On Wed, Dec 11, 2019 at 07:17:02PM -0500, Michael Meissner wrote:
> This patch adds an alternative to use PADDI to add large SImode and DImode
> constants if -mcpu=future is used.
> 2019-12-09 Michael Meissner
>
> * config/rs6000/predicates.md (add_operand): Allow eI constants.
>
Hi all,
I have committed the attached patch adding myself to the Write After
Approval section of the MAINTAINERS file.
ChangeLog:
2019-12-17 Mihail Ionescu
* MAINTAINERS (write_after_approval): Add myself.
Regards,
Mihail
diff --git a/MAINTAINERS b/MAINTAINERS
index
On Sat, 14 Dec 2019 at 22:35, Jeff Law wrote:
>
> On Fri, 2019-12-13 at 17:55 -0700, Martin Sebor wrote:
> > After more testing by Jeff's buildbot and correcting the problems
> > it exposed I have committed the attached patch in r279392.
> And just to close the loop on this. Your last version
Hi,
while hacking firefox to work around ABI compatibility issues with LLVM
I ran into an ICE where comdat group was resolved externaly but contains
a static alias (for thunk). In this case parittioner attempts to put
that static definition into a partition which triggers an ICE.
> Hi Jan,
>
> I'm using GNU ld 2.33.1.
>
> I'll attach a testcase simplified from fuse-3.9 code. "local: *;" in the
> versioning script triggers the issue. Without it there would be no problem.
Thanks.
You are right that I did not play with local:. Now I wonder what is the
intended behaviour
On Tue, 17 Dec 2019 at 16:31, Kyrill Tkachov
wrote:
>
>
> On 12/17/19 2:33 PM, Christophe Lyon wrote:
> > On Tue, 17 Dec 2019 at 11:34, Kyrill Tkachov
> > wrote:
> >> Hi Christophe,
> >>
> >> On 11/18/19 9:00 AM, Christophe Lyon wrote:
> >>> On Wed, 13 Nov 2019 at 15:46, Christophe Lyon
> >>>
On Tue, 17 Dec 2019 at 11:34, Kyrill Tkachov
wrote:
>
> Hi Christophe,
>
> On 11/18/19 9:00 AM, Christophe Lyon wrote:
> > On Wed, 13 Nov 2019 at 15:46, Christophe Lyon
> > wrote:
> > >
> > > On Tue, 12 Nov 2019 at 12:13, Richard Earnshaw (lists)
> > > wrote:
> > > >
> > > > On 18/10/2019
Prevent conversion of character data in array constructors.
Fix for PR fortran/92896 [10 Regression] [DEC] ICE in reduce_unary, at
fortran/arith.c:1283.
This was caused by an unintended side affect of "Allow CHARACTER
literals in assignments and data statements" (revision 277975). If the
Hi Richard,
> This changelog entry is inadequate. It's also not in the correct style.
>
> It should say what has changed, not just that it has changed.
Sure, but there is often no useful space for that. We should auto generate
changelogs if they are deemed useful. I find the commit message a
On 12/17/19 1:58 AM, Jakub Jelinek wrote:
Hi!
When looking at the PR, I wrote a cleanup patch with various things I've
noticed, with latest Martin's changes half of them aren't valid anymore, but
I found further ones.
So, besides formatting fixes, this patch tries to make sure the rng1 ranges
On Tue, Dec 17, 2019 at 03:41:41PM +, Mark Eggleston wrote:
> gcc/fortran/ChangeLog
>
> Mark Eggleston
>
> PR fortran/92896
> * array.c (walk_array_constructor): Replace call to cfg_convert_type
s/cfg_convert_type/gfc_convert_type
> with call to gfc_convert_type_warn
Hi!
On Wed, Dec 11, 2019 at 07:48:39PM -0500, Michael Meissner wrote:
> This patch fixes a bug with vector extracts using a PC-relative address and a
> variable offset with using -mcpu=future.
>
> Consider the code:
>
> #include
>
> static vector double vd;
> vector double
Hi,
LRA is getting measurably slower since GCC 8, at least on x86, and things are
worsening since GCC 9. While this might be legitimate when optimization is
enabled, it's a pure waste of cycles at -O0 so the attached patch switches LRA
over to using the simple algorithm when optimization is
On 12/10/19 4:02 PM, Jakub Jelinek wrote:
Hi!
On the following testcase, we emit 2 errors and 1 warning, when the user
really should see one error. The desirable error is static_assert failure,
the bogus error is during error recovery, complaining that a no_linkage
template isn't defined when
Hi!
On Wed, Dec 11, 2019 at 07:29:05PM -0500, Michael Meissner wrote:
> +(define_memory_constraint "em"
> + "A memory operand that does not contain a prefixed address."
> + (and (match_code "mem")
> + (match_operand 0 "non_prefixed_memory")))
> +
> +(define_memory_constraint "ep"
> + "A
On Tue, Dec 17, 2019 at 05:28:05PM +, Mark Eggleston wrote:
>
> On 17/12/2019 17:06, Steve Kargl wrote:
> > On Tue, Dec 17, 2019 at 03:41:41PM +, Mark Eggleston wrote:
> >> gcc/fortran/ChangeLog
> >>
> >> Mark Eggleston
> >>
> >> PR fortran/92896
> >> * array.c
> Would it be equivalent to:
> 1) output foo_v2 local
> 2) producing static alias with local name (.L1)
> 3) do .symver .L1,foo@@@VERS_2
> That is somewhat more systematic and would not lead to false
> visibilities.
I spent some time playing with this. An in order to
1) be able to handle foo_v2
On Tue, Dec 17, 2019 at 7:47 PM Steve Kargl
wrote:
>
> On Tue, Dec 17, 2019 at 05:28:05PM +, Mark Eggleston wrote:
> >
> > On 17/12/2019 17:06, Steve Kargl wrote:
> > > On Tue, Dec 17, 2019 at 03:41:41PM +, Mark Eggleston wrote:
> > >> gcc/fortran/ChangeLog
> > >>
> > >> Mark
On Tue, Dec 17, 2019 at 08:04:30PM +0200, Janne Blomqvist wrote:
>
> Well, frontends are nowadays C++, so
>
> a) No need to include stdbool.h, bool is a builtin type.
>
> b) optional arguments are a thing (they are also used elsewhere in the
> Fortran frontend).
>
Ah, yes. The creep of C++
Hi!
On 2019-12-17T12:28:32+0100, Thomas Schwinge wrote:
> As a first step, can you please split out just the code required to make
> the OpenACC 'acc_attach*', 'acc_detach*' runtime library routines work?
I've now simply done this myself (that is, code extraction from Julian's
patch, not any
Hi Thomas,
I am reasonably comfortable with the current patch (regarding your
TODOs) – see attachment. It is the previous patch plus your changes plus
one additional condition (see below) in target.c's first
GOMP_MAP_IF_PRESENT handling.
I intent to re-test it tomorrow and then commit it,
On 17/12/2019 17:06, Steve Kargl wrote:
On Tue, Dec 17, 2019 at 03:41:41PM +, Mark Eggleston wrote:
gcc/fortran/ChangeLog
Mark Eggleston
PR fortran/92896
* array.c (walk_array_constructor): Replace call to cfg_convert_type
s/cfg_convert_type/gfc_convert_type
On 12/16/19 6:31 PM, Martin Sebor wrote:
+ class_decl_loc_t *rdl = class2loc.get (type_decl);
+ if (!rdl)
+{
+ rdl = _or_insert (type_decl);
I was thinking
class_decl_loc_t *rdl = _or_insert (type_decl);
OK with that change.
Jason
Hi!
On the following testcase, complain & tf_error is 0 during sfinae, so we
don't emit error, but we called structural_type_p with explain=true anyway,
which emitted the inform messages.
Fixed by doing it only when we emit the error.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for
Hi!
When the prototype of defaulted comparison operator is incorrect, we set
DECL_MAYBE_DELETED, but don't set DECL_DEFAULTED_FN and other flags, so we
ICE during synthetize_method.
Seems only marking DECL_MAYBE_DELETED those operators that we are also going
to mark DECL_DEFAULTED_FN results in
Hi!
As discussed on IRC, defaulted comparison operators were added only in
C++2a, so we shouldn't accept it in older standard modes.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2019-12-17 Jakub Jelinek
PR c++/92973
* method.c
Hello.
As pointed out in the PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92591#c1, the test can be
fixed by DFA-checking more adjacent row sequences in the partial
schedule.
I've found that on powerpc64 gcc.c-torture/execute/pr61682.c test
catches same issue with -Os
Hi!
big ? "-fno-pie" : "-fno-pie" doesn't make much sense, either we want to
use big ? "-fno-PIE" : "-fno-pie", but as both mean the same thing, I think
just using "-fno-pie" is good enough. + a few formatting nits and one
comment typo.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok
I noticed we didn't have a hint for std::byte yet.
Tested x86_64-pc-linux-gnu, applying to trunk.
---
gcc/cp/name-lookup.c| 2 ++
gcc/testsuite/g++.dg/lookup/missing-std-include-9.C | 3 +++
2 files changed, 5 insertions(+)
create mode 100644
We changed months back to use the pre-generic form for constexpr evaluation,
but explain_invalid_constexpr_fn was still using DECL_SAVED_TREE. This
mostly works, but misses some issues due to folding. So with this patch we
save the pre-generic form of constexpr functions even when we know they
The variable templates patch way back when forgot to add handling here. The
simplest answer seems to be recursing to the underlying declaration.
Tested x86_64-pc-linux-gnu, applying to trunk.
* decl.c (redeclaration_error_message): Recurse for variable
templates.
---
On Tue, Dec 17, 2019 at 11:15:29AM -0600, Segher Boessenkool wrote:
> Hi!
>
> On Wed, Dec 11, 2019 at 07:29:05PM -0500, Michael Meissner wrote:
> > +(define_memory_constraint "em"
> > + "A memory operand that does not contain a prefixed address."
> > + (and (match_code "mem")
> > +
On Mon, Dec 16, 2019 at 04:00:14PM -0500, Jason Merrill wrote:
> On 12/16/19 3:55 PM, Jason Merrill wrote:
> > On 12/14/19 4:25 PM, Marek Polacek wrote:
> > > On Fri, Dec 13, 2019 at 05:56:57PM -0500, Jason Merrill wrote:
> > > > On 12/13/19 3:20 PM, Marek Polacek wrote:
> > > > > + /* Given
Whilst analyzing the reproducer for detecting CVE-2005-1689
(krb5-1.4.1's src/lib/krb5/krb/recvauth.c), the analyzer reports
a false double-free of the form:
krb5_xfree(inbuf.data);
krb5_read_message(..., );
krb5_xfree(inbuf.data); /* false diagnostic here. */
where the call to
I attempted to use the analyzer to detect CVE-2005-1689, a double-free in
krb5-1.4.1's src/lib/krb5/krb/recvauth.c
With v1-v4 of the analyzer, it emits 11 double-free warnings:
https://dmalcolm.fedorapeople.org/gcc/2019-11-13/CVE-2005-1689.html
of which most were either false positives or
gcc/analyzer/ChangeLog:
* ChangeLog: New file.
---
gcc/analyzer/ChangeLog | 10 ++
1 file changed, 10 insertions(+)
create mode 100644 gcc/analyzer/ChangeLog
diff --git a/gcc/analyzer/ChangeLog b/gcc/analyzer/ChangeLog
new file mode 100644
index ..7144b69596e2
---
Whilst analyzing the reproducer for detecting CVE-2005-1689
(krb5-1.4.1's src/lib/krb5/krb/recvauth.c), the analyzer reported
11 double-free diagnostics on lines of the form:
krb5_xfree(inbuf.data);
with no deduplication occcurring.
The root cause is that the diagnostics each have a
gcc/analyzer/ChangeLog:
* diagnostic-manager.cc (dedupe_winners::add): Add logging
of deduplication decisions made.
---
gcc/analyzer/diagnostic-manager.cc | 23 ---
1 file changed, 20 insertions(+), 3 deletions(-)
diff --git
On Tue, Dec 17, 2019 at 05:29:44PM -0500, Michael Meissner wrote:
> On Tue, Dec 17, 2019 at 11:15:29AM -0600, Segher Boessenkool wrote:
> > > +;; Return true if the operand is a valid memory address that does not
> > > use a
> > > +;; prefixed address.
> > > +(define_predicate
On 12/16/19 6:20 PM, Jason Merrill wrote:
On 11/29/19 6:23 PM, Strager Neds wrote:
How can we solve this problem? Some ideas (none of which I like):
* Disallow this code, possibly with an improved diagnostic.
* Silently make the section SECTION_LINKONCE if there is a conflict.
* Silently
On Tue, Dec 17, 2019 at 05:35:24PM -0600, Segher Boessenkool wrote:
> On Tue, Dec 17, 2019 at 05:29:44PM -0500, Michael Meissner wrote:
> > On Tue, Dec 17, 2019 at 11:15:29AM -0600, Segher Boessenkool wrote:
> > > > +;; Return true if the operand is a valid memory address that does not
> > > >
PR92923 shows a problem where builtin function usage is causing performance
problems due to unneeded subreg usage. These are being caused by the front-
end emitting unneeded VIEW_CONVERT_EXPR's on the builtin functions operands.
These in tern where caused by a lack of overloaded builtin entries
This patch has been broken out of the "OpenACC 2.6 manual deep copy
support" patch, last posted here:
https://gcc.gnu.org/ml/gcc-patches/2019-11/msg02376.html
This part contains the Fortran front-end support for parsing the new
attach and detach clauses, as well as derived-type members on
This patch has been broken out of the "OpenACC 2.6 manual deep copy
support" patch, last posted here:
https://gcc.gnu.org/ml/gcc-patches/2019-11/msg02376.html
This part contains the C and C++ changes to parse attach and detach
clauses and struct member accesses via "." or "->" on other
This patch has been broken out of the "OpenACC 2.6 manual deep copy
support" patch, last posted here:
https://gcc.gnu.org/ml/gcc-patches/2019-11/msg02376.html
This part contains the middle-end support for OpenACC 2.6 attach and
detach operations, either as standalone clauses or as
This patch has been broken out of the "OpenACC 2.6 manual deep copy
support" patch, last posted here:
https://gcc.gnu.org/ml/gcc-patches/2019-11/msg02376.html
This part adds C and C++ execution tests to libgomp.
Tested alongside other patches in this series with offloading to
NVPTX. OK?
Hi:
This patch is to simplify A * C + (-D) -> (A - D/C) * C when C is a
power of 2 and D mod C == 0.
bootstrap and make check is ok.
changelog
gcc/
* gcc/match.pd (A * C + (-D) = (A - D/C) * C. when C is a
power of 2 and D mod C == 0): Add new simplification.
gcc/testsuite
On Tue, Dec 17, 2019 at 6:33 PM Hongtao Liu wrote:
>
> Hi:
> This patch is to simplify A * C + (-D) -> (A - D/C) * C when C is a
> power of 2 and D mod C == 0.
> bootstrap and make check is ok.
I don't see why D has to be negative here.
>TREE_CODE (TREE_TYPE (@0)) == INTEGER_TYPE
+ &&
This is a rebased version of the reference count consistency checking
patch last posted upstream here:
https://gcc.gnu.org/ml/gcc-patches/2019-10/msg00239.html
This is not necessary for proper operation of the rest of the patches
in this series, but has proved useful in development.
Tested
This patch was previously posted here:
https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00321.html
This version is the same as the last-posted version. The middle-end patch
later in the series depends on this. Tested alongside other patches in
this series with offloading to NVPTX. OK?
Thanks,
This patch was previously approved here, but I have not committed it yet
(without the other patches in this series):
https://gcc.gnu.org/ml/gcc-patches/2019-10/msg01156.html
Included for completeness. I will commit this alongside other patches
if they are approved (or it could probably go in
This patch has been broken out of the "OpenACC 2.6 manual deep copy
support" patch, last posted here:
https://gcc.gnu.org/ml/gcc-patches/2019-11/msg02376.html
It contains just the minimal libgomp bits necessary to support the OpenACC
runtime API routines (acc_attach, acc_detach and
This patch has been broken out of the "OpenACC 2.6 manual deep copy
support" patch, last posted here:
https://gcc.gnu.org/ml/gcc-patches/2019-11/msg02376.html
This part contains the libgomp runtime support for the GOMP_MAP_ATTACH and
GOMP_MAP_DETACH mapping kinds (etc.), as introduced by the
This patch has been broken out of the "OpenACC 2.6 manual deep copy
support" patch, last posted here:
https://gcc.gnu.org/ml/gcc-patches/2019-11/msg02376.html
This part is included for completeness. It is the same as the patch
posted by Thomas here:
This is a rebased version of the reference-count overhaul patch last
posted here:
https://gcc.gnu.org/ml/gcc-patches/2019-11/msg02235.html
This version omits parts of the above patch already committed upstream and
merges some recent REFCOUNT_INFINITY changes. This patch causes the newish
Hi,
This patch series provides support for OpenACC 2.6's manual deep copy
(attach/detach) feature. Many of these patches have been submitted
previously, but this series has been rebased and the large deep-copy
part proper has been split into several pieces for ease of review.
Tested with
The compiler gave a wrong error about "must override" in the following
case. A private type is completed with a derived type that inherits a
must-override function. Outside that package, a type extension of the
private type is declared. The function on that type extension is not
visible, and is
Ada202X allows some aspects related to shared variable control to appear
on formal type declarations. These aspects represent new enforceable
parts of the contract between generic units and instantiations.
Tested on x86_64-pc-linux-gnu, committed on trunk
2019-12-18 Ed Schonberg
gcc/ada/
This patch fixes an issue whereby compile-time checks on return
aggregates with anonymous access discriminants were not performed when
multiple of such discriminants were present, the aggregate was within an
extended return statement, or the aggregate was within a qualified
expression.
Tested on
Fix three-letter typos like "alllowed" or "corrresponding". They can be
detected with this command:
$ grep "[[:alpha:]]\([[:lower:]]\+\)\1\1" ...
but need to be manually filtered for things like "ieee", "dd-mm-" or
hexadecimal literals.
Tested on x86_64-pc-linux-gnu, committed on trunk
In certain cases of conversions to interface types, the compiler
generates a special function to handle the conversion. In cases where
such a function has an extra accessibility-level formal and the target
type of the conversion has a designated type that comes from a limited
view (via
This adds references to Ada 2020 in the section documenting the two size
attributes used by GNAT, namely Object_Size and Value_Size, as well as
in the head comment of Subtypes_Statically_Match.
Tested on x86_64-pc-linux-gnu, committed on trunk
2019-12-18 Eric Botcazou
gcc/ada/
*
This patch fixes a bug in which if a parent package has a use clause in
its private part, and a child of that parent has a use clause for the
same thing in its context clause, the compiler incorrectly warns that
the one in the child is redundant.
Tested on x86_64-pc-linux-gnu, committed on trunk
1 - 100 of 108 matches
Mail list logo
