Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
Ok for trunk?
gcc/ChangeLog:
PR target/98468
* config/i386/sse.md (*bit_and_float_vector_all_ones): New
pre-reload splitter.
gcc/testsuite/ChangeLog:
* gcc.target/i386/pr98468.c: New test.
---
Also with corresponding target attribute, option default disabled.
Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
Ok for trunk?
gcc/ChangeLog:
* config/i386/i386-options.c (ix86_target_string): Handle
-mvect-compare-costs.
On 12/15/21 9:28 PM, H.J. Lu wrote:
I built nios2-linux-gnu cross compiler using glibc build-many-glibcs.py
script:
[snip]
using glibc master, binutils master and gcc master. Is there a way
to reproduce it with build-many-glibcs.py?
If it requires host tools built from binutils master,
On Wed, Dec 15, 2021 at 8:28 PM H.J. Lu wrote:
>
> On Wed, Dec 15, 2021 at 7:38 PM Sandra Loosemore
> wrote:
> >
> > On 11/13/21 9:33 AM, H.J. Lu via Gcc-patches wrote:
> > > Sync with binutils for building binutils with LTO:
> > >
> > > From 50ad1254d5030d0804cbf89c758359ae202e8d55 Mon Sep 17
On Wed, Dec 15, 2021 at 7:38 PM Sandra Loosemore
wrote:
>
> On 11/13/21 9:33 AM, H.J. Lu via Gcc-patches wrote:
> > Sync with binutils for building binutils with LTO:
> >
> > From 50ad1254d5030d0804cbf89c758359ae202e8d55 Mon Sep 17 00:00:00 2001
> > From: "H.J. Lu"
> > Date: Sat, 9 Jan 2021
On 11/13/21 9:33 AM, H.J. Lu via Gcc-patches wrote:
Sync with binutils for building binutils with LTO:
From 50ad1254d5030d0804cbf89c758359ae202e8d55 Mon Sep 17 00:00:00 2001
From: "H.J. Lu"
Date: Sat, 9 Jan 2021 06:43:11 -0800
Subject: [PATCH] GCC: Pass --plugin to AR and RANLIB
Detect GCC
On Linux/x86_64,
45b768cb80930c0beeb735727349c44ec66f7dd2 is the first bad commit
commit 45b768cb80930c0beeb735727349c44ec66f7dd2
Author: Thomas Schwinge
Date: Fri Dec 10 19:08:26 2021 +0100
testsuite: Be more informative for ICEs
caused
FAIL: g++.dg/modules/xtreme-header-3_a.H
On 12/15/21 20:54, Jakub Jelinek wrote:
On Wed, Dec 01, 2021 at 07:57:53PM +0530, Siddhesh Poyarekar wrote:
Recognize the __builtin_dynamic_object_size builtin and add paths in the
object size path to deal with it, but treat it like
__builtin_object_size for now. Also add tests to provide the
On 2021/12/15 18:34, Martin Liška wrote:
> On 12/15/21 02:58, Xionghu Luo wrote:
>> Also add verbose argument support like analyze_brprob.py
>>
>> contrib/ChangeLog:
>>
>> * analyze_brprob_spec.py: Add verbose argument.
>> ---
>> contrib/analyze_brprob_spec.py | 1 +
>> 1 file changed, 1
On Wed, Dec 15, 2021 at 01:29:57PM -0700, Jeff Law wrote:
> I think the generic parts are fine once Segher is happy with the rest of
> the bits.
https://gcc.gnu.org/pipermail/gcc-patches/2021-November/585478.html
(last lines)
:-)
Segher
On 12/16/21 00:13, Jakub Jelinek wrote:
On Wed, Dec 15, 2021 at 10:42:29PM +0530, Siddhesh Poyarekar wrote:
On 12/15/21 20:51, Jakub Jelinek wrote:
Shouldn't this also tree_int_cst_compare (old_wholeval, wholeval) ?
AFAICT, there is no situation where wholeval changes but val doesn't, so I
Hi!
On 2021-12-13T14:12:26-0500, David Malcolm wrote:
> On Mon, 2021-12-13 at 10:53 -0700, Martin Sebor via Gcc-patches wrote:
>> On 12/10/21 3:42 PM, Thomas Schwinge wrote:
>> > OK to push the attached "testsuite: Be more informative for ICEs"?
>>
>> Adding more detail here seems like a useful
On Wed, 15 Dec 2021, Jason Merrill wrote:
> On 12/10/21 09:53, Patrick Palka wrote:
> > In order to properly implement two-stage name lookup for dependent
> > operator expressions, we need to remember the result of unqualified
> > lookup of the operator at template definition time, and reuse
On 12/10/21 10:41, Patrick Palka wrote:
The function comment for adjust_field_tree_exp says this special case
is for handling trees whose operands may contain pointers to RTL instead
of to trees. But ever since r0-59671, which fixed/removed the last two
tree codes for which this was possible
On 12/14/21 17:26, Patrick Palka wrote:
Here during constraint checking for the recursive call to 'f',
substitution into the PARM_DECL 'd' in the atomic constraint gives us
the wrong local specialization because local_specializations at this
point contains entities associated with the _outer_
On 12/14/21 17:28, Martin Sebor wrote:
The attached patch avoids an ICE when using
the CLASSTYPE_IMPLICIT_INSTANTIATION() macro with an argument
that is not a class type but rather a typename_type.
The test case should trigger a warning but doesn't because
the code doesn't fully handle explicit
On 12/15/21 09:09, Jakub Jelinek wrote:
On Wed, Dec 15, 2021 at 08:58:45AM -0500, Patrick Palka wrote:
Oops, thanks Jakub, I didn't realize we don't run the testsuite with
-std=c++23 yet.
I guess it'd be too expensive to add another std to the testing matrix
at this point, but I wonder if the
On 12/15/21 16:28, Marek Polacek wrote:
On Wed, Dec 15, 2021 at 04:17:37PM -0500, Jason Merrill wrote:
On 12/15/21 15:20, Marek Polacek wrote:
On Mon, Dec 13, 2021 at 10:02:24AM -0500, Jason Merrill wrote:
On 12/10/21 17:29, Marek Polacek wrote:
My r11-2202 was trying to enforce
Hi!
On 12/15/21 12:16 PM, Segher Boessenkool wrote:
>> + /* Note: vec_nand also works but opt changes vec_nand's
>> + to vec_nor's anyway. */
> Maybe there should be a vec_not? There is one at the RTL level (called
> one_cmpl2).
As I recall, we have an issue open for this
On 12/15/21 12:49, Patrick Palka wrote:
This patch makes us remember the function selected by overload
resolution during ahead of time processing of a non-dependent call
expression, so that we avoid repeating most of the work of overload
resolution at instantiation time. This mirrors what we
On Wed, Dec 15, 2021 at 04:17:37PM -0500, Jason Merrill wrote:
> On 12/15/21 15:20, Marek Polacek wrote:
> > On Mon, Dec 13, 2021 at 10:02:24AM -0500, Jason Merrill wrote:
> > > On 12/10/21 17:29, Marek Polacek wrote:
> > > > My r11-2202 was trying to enforce [dcl.type.auto.deduct]/4, which says
>
On Wed, 15 Dec 2021 at 21:16, François Dumont wrote:
> Here is what I eventually would like to commit.
>
> I was not able to remove the _Safe_iterator_base branch in ptr_traits.h.
> When adding the _Safe_iterator overload in C++20 and removing the branch
> the 20_util/to_address/debug.cc test
On 12/15/21 15:11, Patrick Palka wrote:
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
OK.
gcc/ChangeLog:
* print-tree.c (print_node) : Dump
DECL_LANG_FLAG_8.
---
gcc/print-tree.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/gcc/print-tree.c
On 12/15/21 15:20, Marek Polacek wrote:
On Mon, Dec 13, 2021 at 10:02:24AM -0500, Jason Merrill wrote:
On 12/10/21 17:29, Marek Polacek wrote:
My r11-2202 was trying to enforce [dcl.type.auto.deduct]/4, which says
"If the placeholder-type-specifier is of the form type-constraint[opt]
Here is what I eventually would like to commit.
I was not able to remove the _Safe_iterator_base branch in ptr_traits.h.
When adding the _Safe_iterator overload in C++20 and removing the branch
the 20_util/to_address/debug.cc test started to fail because it was not
calling my overload. I
On 12/15/21 15:36, Patrick Palka wrote:
The r12-5403 fix apparently doesn't handle the case where the inner
lambda explicitly rather implicitly captures the capture proxy from
the outer lambda, and so we still reject the first example in the
testcase below.
The reason is that compared to an
On 12/10/21 09:53, Patrick Palka wrote:
In order to properly implement two-stage name lookup for dependent
operator expressions, we need to remember the result of unqualified
lookup of the operator at template definition time, and reuse that
result rather than performing another unqualified
The r12-5403 fix apparently doesn't handle the case where the inner
lambda explicitly rather implicitly captures the capture proxy from
the outer lambda, and so we still reject the first example in the
testcase below.
The reason is that compared to an implicit capture, the effective
initializer
On 11/24/2021 4:48 PM, Raoni Fassina Firmino via Gcc-patches wrote:
Changes since v6[6] and v5[5]:
- Based this version on the v5 one.
- Reworked all builtins back to the way they are in v5 and added the
following changes:
+ Added a test to target libc, only expanding with
On 11/13/2021 9:33 AM, H.J. Lu via Gcc-patches wrote:
Sync with binutils for building binutils with LTO:
From af019bfde9b13d628202fe58054ec7ff08d92a0f Mon Sep 17 00:00:00 2001
From: "H.J. Lu"
Date: Sat, 9 Jan 2021 06:51:15 -0800
Subject: [PATCH] Support the PGO build for binutils+gdb
Add
On 12/10/2021 8:06 AM, Robin Dapp wrote:
Hi Jeff,
I'd generally prefer to refactor the bits between the restart label and
the goto restart into a function and call it twice, passing in the
additional bits to allow for better costing. Can you look into that?
If it's going to be major
On Mon, Dec 13, 2021 at 10:02:24AM -0500, Jason Merrill wrote:
> On 12/10/21 17:29, Marek Polacek wrote:
> > My r11-2202 was trying to enforce [dcl.type.auto.deduct]/4, which says
> > "If the placeholder-type-specifier is of the form type-constraint[opt]
> > decltype(auto), T shall be the
On 12/15/21 12:41 PM, Segher Boessenkool wrote:
> On Wed, Dec 15, 2021 at 08:00:02AM -0600, Bill Schmidt wrote:
>>> No, all builtins should work in either mode, and always return long.
>>> If the patterns are broken, the *patterns* should be fixed :-)
>> OK, thanks! This is much clearer now.
>>
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
gcc/ChangeLog:
* print-tree.c (print_node) : Dump
DECL_LANG_FLAG_8.
---
gcc/print-tree.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/gcc/print-tree.c b/gcc/print-tree.c
index b5dc523fcb1..297492ad51c 100644
Oh ye I accidentally dropped that in the merge thank you.
I believe there is an implicit "global:" in the top of each version scope, so
it shouldn't
matter other than looking a bit deviant.
Regards,
Petter
Från: Antoni Boucher
Skickat: den 15 december 2021 15:19
Till: Petter Tomner; David
Hi,
This patch merges the D front-end implementation with upstream dmd
93108bb9e, and the D run-time libraries with druntime 6364e010 and
phobos 575b67a9b. The internal version of the language has been bumped
to v2.098.1-beta.1.
D front-end changes:
- Import dmd v2.098.1-beta.1.
-
On Wed, Dec 15, 2021 at 11:26:48PM +0530, Siddhesh Poyarekar wrote:
> > This makes me a little bit worried. Do you compute the wholesize SSA_NAME
> > at runtime always, or only when it is really needed and known not to always
> > be equal to the size?
> > I mean, e.g. for the cases where there is
On Wed, Dec 15, 2021 at 10:42:29PM +0530, Siddhesh Poyarekar wrote:
> On 12/15/21 20:51, Jakub Jelinek wrote:
> > Shouldn't this also tree_int_cst_compare (old_wholeval, wholeval) ?
> >
>
> AFAICT, there is no situation where wholeval changes but val doesn't, so I
> believe the val check should
On Wed, Dec 15, 2021 at 08:00:02AM -0600, Bill Schmidt wrote:
> > No, all builtins should work in either mode, and always return long.
> > If the patterns are broken, the *patterns* should be fixed :-)
>
> OK, thanks! This is much clearer now.
>
> I've opened an internal issue about the
Hi!
On Wed, Dec 15, 2021 at 08:21:24AM -0600, Bill Schmidt wrote:
> While replacing the built-in machinery, we agreed to defer some necessary
> refactoring of the overload processing. This patch cleans it up considerably.
>
> I've put in one FIXME for an additional level of cleanup that should
On 12/15/21 21:54, Jakub Jelinek wrote:
On Wed, Dec 01, 2021 at 07:57:54PM +0530, Siddhesh Poyarekar wrote:
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/builtin-dynamic-object-size-0.c
@@ -0,0 +1,72 @@
+/* { dg-do run } */
+/* { dg-options "-O2" } */
+
+typedef __SIZE_TYPE__ size_t;
+#define abort
This patch makes us remember the function selected by overload
resolution during ahead of time processing of a non-dependent call
expression, so that we avoid repeating most of the work of overload
resolution at instantiation time. This mirrors what we already do for
non-dependent operator
On 11/13/2021 9:33 AM, H.J. Lu via Gcc-patches wrote:
Sync with binutils for building binutils with LTO:
From 50ad1254d5030d0804cbf89c758359ae202e8d55 Mon Sep 17 00:00:00 2001
From: "H.J. Lu"
Date: Sat, 9 Jan 2021 06:43:11 -0800
Subject: [PATCH] GCC: Pass --plugin to AR and RANLIB
Detect
> On Dec 14, 2021, at 4:06 PM, Martin Sebor wrote:
>
>
Dynamically creating the string seems quite cumbersome here, and
it leaks the allocated block. I wonder if it might be better to
remove the gmsgid argument from the function and assign it to
one of the
On 12/15/21 20:51, Jakub Jelinek wrote:
Shouldn't this also tree_int_cst_compare (old_wholeval, wholeval) ?
AFAICT, there is no situation where wholeval changes but val doesn't, so
I believe the val check should be sufficient. Do you think otherwise?
Siddhesh
On Wed, Dec 01, 2021 at 07:57:54PM +0530, Siddhesh Poyarekar wrote:
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/builtin-dynamic-object-size-0.c
> @@ -0,0 +1,72 @@
> +/* { dg-do run } */
> +/* { dg-options "-O2" } */
> +
> +typedef __SIZE_TYPE__ size_t;
> +#define abort __builtin_abort
> +
>
On 12/15/2021 1:22 AM, Alexandre Oliva wrote:
On Dec 9, 2021, Jeff Law wrote:
I found a similar pattern of issuing clobbers for multi-word moves, but
not when reload_in_progress, in expr.c:emit_move_complex_parts. I don't
have a testcase, but I'm tempted to propose '!lra_in_progress &&'
gcc/ChangeLog:
* omp-low.c (lower_oacc_reductions): Only create a reference
if variable has pointer type.
---
gcc/omp-low.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/gcc/omp-low.c b/gcc/omp-low.c
index ae5cdfc5e260..2b8b848ec03a 100644
---
From: Tobias Burnus
Replacing of a by-reference variable in a private clause by a local variable
makes sense; however, for arrays, the size is not directly known by the type.
This causes an ICE via create_tmp_var which indirectly invokes
force_constant_size in this case - but the latter only
From: Tobias Burnus
Nearly all variable mapping is moved from 'kernels' to a surrounding
'data kernels' and then 'force_present' mapped for the 'kernels'. However, as
libgomp.oacc-c-c++-common/declare-vla.c shows, moving 'int i, N' will fail as
there is a special case for is_gimple_reg in
gcc/ChangeLog:
* gimplify.c (gimplify_omp_for): Enable localization on
"kernels" regions.
(gimplify_omp_workshare): Likewise.
---
gcc/gimplify.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/gcc/gimplify.c b/gcc/gimplify.c
index
From: Julian Brown
gcc/
* gimplify.c (localize_reductions): Rewrite references for
OMP_CLAUSE_PRIVATE also.
libgomp/
* testsuite/libgomp.oacc-fortran/privatized-ref-1.f95: New test.
* testsuite/libgomp.oacc-c++/privatized-ref-2.C: New test.
From: Julian Brown
gcc/
* gimplify.c (gimplify_omp_for): Use for_stmt in call to
localize_reductions.
---
gcc/gimplify.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/gcc/gimplify.c b/gcc/gimplify.c
index 04ffbc256442..daa69ccf6202 100644
---
From: Julian Brown
gcc/
* gimplify.c (gimplify_omp_workshare): Use OMP_CLAUSES, OMP_BODY
instead of OMP_TARGET_CLAUSES, OMP_TARGET_BODY.
---
gcc/gimplify.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/gcc/gimplify.c b/gcc/gimplify.c
index
From: Julian Brown
gcc/
* gimplify.c (privatize_reduction): New struct.
(localize_reductions_r, localize_reductions): New functions.
(gimplify_omp_for): Call localize_reductions.
(gimplify_omp_workshare): Likewise.
* omp-low.c
It seems that the check that rejects loops without data references is
only included to avoid handling non-profitable loops. Including those
loops in Graphite's analysis enables more consistent diagnostic
messages in OpenACC "kernels" code and does not introduce any
testsuite regressions. If
The find_common_loop function is used in Graphite to obtain a common
super-loop of all loops inside a SCoP. The function is applied to the
loop of the destination block of the edge that leads into the SESE
region and the loop of the source block of the edge that exits the
region. The exit block
The default values of some parameters that restrict Graphite's
resource usage are too low for many OpenACC codes. Furthermore,
exceeding the limits does not alwas lead to user-visible diagnostic
messages.
This commit increases the parameter values on OpenACC functions. The
values were chosen to
The additional dependences introduced by partial redundancy
elimination proper and by the code hoisting step of the pass very
often cause Graphite to fail on OpenACC functions. On the other hand,
the pass can also enable the analysis of OpenACC loops (cf. e.g. the
loop-auto-transfer-4.f90
The loop invariant motion pass correctly refuses to move statements
out of a loop if any other statement in the loop is unanalyzable. The
pass does not know how to handle the OpenACC internal function calls
which was not necessary until recently when the OpenACC device
lowering pass was moved to
From: Andrew Stubbs
This commit adds the code generation for the runtime alias checks for
OpenACC loops that have been analyzed by Graphite. The runtime alias
check condition gets generated in Graphite. It is evaluated by the
code generated for the IFN_GOACC_LOOP internal function calls. If
This commit concerns loops in OpenACC "kernels" region that have been marked
up with an explicit "independent" clause by the user, but for which Graphite
found data dependences. A discussion on the private internal OpenACC mailing
list suggested that warning the user about the dependences woud be
From: Andrew Stubbs
Address PR90591 "Avoid unnecessary data transfer out of OMP
construct", for simple (but common) cases.
This commit adds a pass that optimizes data mapping clauses.
Currently, it can optimize copy/map(tofrom) clauses involving scalars
to copyin/map(to) and further to
Commit 89f4f339130c ("For 'OMP_CLAUSE' in 'dump_generic_node', dump
the whole OMP clause chain") changed the dumping behavior for
OMP_CLAUSEs. The old behavior is required for a follow-up
commit ("openacc: Add data optimization pass") that optimizes single
OMP_CLAUSEs.
gcc/ChangeLog:
*
With the old "kernels" handling, unparallelized regions would
get executed with 1x1x1 partitioning even if the user provided
explicit num_gangs, num_workers clauses etc.
This commit restores this behavior by removing unused partitioning
after assigning the parallelism dimensions to loops.
gcc/ChangeLog:
* graph.c (oacc_get_fn_attrib): New declaration.
(find_loop_location): New declaration.
(draw_cfg_nodes_for_loop): Print value of the
can_be_parallel flag at the top of loops in OpenACC
functions.
---
gcc/graph.c | 35
Graphite rejects a SCoP if it contains a pair of data references for
which it cannot determine statically if they may alias. This happens
very often, for instance in C code which does not use explicit
"restrict". This commit adds the possibility to analyze a SCoP
nevertheless and perform an alias
Move this function from tree-loop-distribution.c to tree-data-ref.c
and make it non-static to enable its use from other parts of GCC.
gcc/ChangeLog:
* tree-loop-distribution.c (data_ref_segment_size): Remove function.
(latch_dominated_by_data_ref): Likewise.
The OpenACC device lowering pass must run after the Graphite pass to
allow for the use of Graphite for automatic parallelization of kernels
regions in the future. Experimentation has shown that it is best,
performancewise, to run pass_oacc_device_lower together with the
related passes
gcc/ChangeLog:
* graphite-sese-to-poly.c (build_poly_sr_1): Fix a typo and
a reference to a variable which does not exist.
* graphite-isl-ast-to-gimple.c (gsi_insert_earliest): Fix typo
in comment.
---
gcc/graphite-isl-ast-to-gimple.c | 2 +-
The SSA names for which this function gets used are always SCoP
parameters and hence "isl_id_for_parameter" is a better name. It also
explains the prefix "P_" for those names in the ISL representation.
gcc/ChangeLog:
* graphite-sese-to-poly.c (isl_id_for_ssa_name): Rename to ...
The Fortran front end presently linearizes accesses to
multi-dimensional arrays by combining the indices for the various
dimensions into a series of explicit multiplies and adds with
refactoring to allow CSE of invariant parts of the computation.
Unfortunately this representation interferes with
Extend dump output to make understanding why Graphite rejects to
include a loop in a SCoP easier (for GCC developers).
ChangeLog:
* graphite-scop-detection.c (scop_detection::can_represent_loop):
Output reason for failure to dump file.
From: Sandra Loosemore
OpenACC loop semantics require that the loop bound be computable
before entering the loop, rather than the C/C++ semantics where the
end test is evaluated on every iteration. Formerly the kernels loop
annotater permitted only constants and variables not modified in the
From: Sandra Loosemore
The code for identifying annotatable loops in OpenACC kernels regions
previously looked for the loop variable as the left-hand side of the
comparison in the loop end test. However, front end optimizations
sometimes switch the sense of the comparison, making this method
From: Sandra Loosemore
Several of the Fortran tests for kernels loop annotation were failing
due to changes in the formatting of "acc loop" constructs in the dump
file. Now the "auto" clause appears first, instead of after "private".
2020-08-23 Sandra Loosemore
gcc/testsuite/
From: Sandra Loosemore
This tweak to the OpenACC kernels loop annotation relaxes the
restrictions on function calls in the loop body. Normally calls to
functions not explicitly marked with a parallelism attribute are not
permitted, but C/C++ builtins and Fortran intrinsics have known
semantics
From: Sandra Loosemore
Normally explicit loop directives in a kernels region inhibit
automatic annotation of other loops in the same nest, on the theory
that users have indicated they want manual control over that section
of code. However there seems to be an expectation in user code that
the
From: Sandra Loosemore
Normally explicit loop directives in a kernels region inhibit
automatic annotation of other loops in the same nest, on the theory
that users have indicated they want manual control over that section
of code. However there seems to be an expectation in user code that
the
From: Sandra Loosemore
2020-08-19 Sandra Loosemore
gcc/
* tree.h (OACC_LOOP_COMBINED): New.
gcc/c/
* c-parser.c (c_parser_oacc_loop): Set OACC_LOOP_COMBINED.
gcc/cp/
* parser.c (cp_parser_oacc_loop): Set OACC_LOOP_COMBINED.
From: Sandra Loosemore
The g++ front end wraps the array length and low_bound values in
NON_LVALUE_EXPR, causing the subsequent tests for INTEGER_CST to fail.
The test case c-c++-common/goacc/kernels-loop-annotation-1.c was
tickling this bug and giving bogus errors in g++ because it was falling
From: Sandra Loosemore
2020-03-27 Sandra Loosemore
gcc/testsuite/
* gfortran.dg/goacc/classify-kernels-unparallelized.f95: Adjust
line numbering.
* gfortran.dg/goacc/classify-kernels.f95: Likewise.
* gfortran.dg/goacc/kernels-decompose-2.f95: Add
From: Sandra Loosemore
This patch implements the Fortran support for adding "#pragma acc loop auto"
annotations to loops in OpenACC kernels regions. It implements the same
-fopenacc-kernels-annotate-loops and -Wopenacc-kernels-annotate-loops options
that were previously added (and documented)
From: Sandra Loosemore
This patch detects loops in kernels regions that are candidates for
parallelization, and adds "#pragma acc loop auto" annotations to them.
This annotation is controlled by the -fopenacc-kernels-annotate-loops
option, which is enabled by default.
From: Sandra Loosemore
2020-03-27 Sandra Loosemore
gcc/testsuite/
* c-c++-common/goacc/kernels-decompose-2.c: Add
-fno-openacc-kernels-annotate-loops.
---
gcc/testsuite/c-c++-common/goacc/kernels-decompose-2.c | 1 +
1 file changed, 1 insertion(+)
diff --git
Hi,
this patch series implements the re-work of the OpenACC "kernels"
implementation that has been announced at the GNU Tools Track of this
year's Linux Plumbers Conference; see
https://linuxplumbersconf.org/event/11/contributions/998/. Versions
of the patches have also been committed to the
On Mon, Dec 13 2021, Jan Hubicka wrote:
>> >>> + || (only_for_nonzero &&
>> >>> !src_lats->bits_lattice.known_nonzero_p ()))
>> >>> +{
>> >>> + if (jfunc->bits)
>> >>> +return dest_lattice->meet_with (jfunc->bits->value,
>> >>> +
Ping:
https://gcc.gnu.org/pipermail/gcc-patches/2021-December/586402.html
Besides PR 99612 this also fixes the false positive reported
recently in PR 103372.
On 12/8/21 9:49 AM, Martin Sebor wrote:
Even with -Wno-system-headers enabled, the -Winvalid-memory-order
code tries to make sure calls
On Wed, Dec 01, 2021 at 07:57:53PM +0530, Siddhesh Poyarekar wrote:
> Recognize the __builtin_dynamic_object_size builtin and add paths in the
> object size path to deal with it, but treat it like
> __builtin_object_size for now. Also add tests to provide the same
> testing coverage for the new
On Wed, Dec 01, 2021 at 07:57:52PM +0530, Siddhesh Poyarekar wrote:
> static inline bool
> -object_sizes_set (struct object_size_info *osi, unsigned varno,
> - unsigned HOST_WIDE_INT val)
> +object_sizes_set (struct object_size_info *osi, unsigned varno, tree val,
> +
On Mon, Nov 29, 2021 at 05:25:30AM -0700, H.J. Lu wrote:
> > I'd like to ping this patch, but perhaps first it would be nice to discuss
> > it in the x86-64 psABI group.
> > The current psABI doesn't seem to mention zero sized bitfields at all
> > explicitly, so perhaps theoretically they should
Hi!
While replacing the built-in machinery, we agreed to defer some necessary
refactoring of the overload processing. This patch cleans it up considerably.
I've put in one FIXME for an additional level of cleanup that should be done
independently. The various helper functions (resolve_VEC_*)
Hi Petter.
I believe you have forgotten the line `global:` in the file
`gcc/jit/libgccjit.map`.
I'm not sure what this line does, but it is there for all other ABI.
David: What do you think?
Regards.
Le mardi 14 décembre 2021 à 17:22 +, Petter Tomner via Jit a
écrit :
> Hi!
>
> I have pushed
On Wed, Dec 15, 2021 at 08:58:45AM -0500, Patrick Palka wrote:
> Oops, thanks Jakub, I didn't realize we don't run the testsuite with
> -std=c++23 yet.
>
> I guess it'd be too expensive to add another std to the testing matrix
> at this point, but I wonder if the test harness should at least run
On 9/17/21 5:41 PM, Roger Sayle wrote:
>
> This patch adds upon my previous patch to prototype HFmode support on
> nvptx, which includes adding new target macros TARGET_SM75 and TARGET_SM80.
I've mode those parts into this patch.
> Tobias Burnus has questioned "whether it makes sense to add
Hi,
Add support for ptx isa version 7.0, required for the addition of -misa=sm_75
and -misa=sm_80.
Tested by setting the default ptx isa version to 7.0, and doing a build and
libgomp test run.
Committed to trunk.
Thanks,
- Tom
[nvptx] Add -mptx=7.0
gcc/ChangeLog:
*
On 12/14/21 8:23 PM, Segher Boessenkool wrote:
> On Tue, Dec 14, 2021 at 07:32:30AM -0600, Bill Schmidt wrote:
>> On 12/13/21 6:22 PM, Segher Boessenkool wrote:
>>> On Mon, Dec 13, 2021 at 02:37:43PM -0600, Bill Schmidt wrote:
On 12/13/21 10:54 AM, Segher Boessenkool wrote:
> On Mon,
On Wed, 15 Dec 2021, Jakub Jelinek wrote:
> On Mon, Dec 13, 2021 at 04:28:26PM -0500, Patrick Palka via Gcc-patches wrote:
> > * g++.dg/concepts/diagnostic18.C: Expect a "constraints on a
> > non-templated function" error.
> > * g++.dg/cpp23/auto-fncast10.C: New test.
>
> This test
The patch fixes a few ASAN errors (global variable access out of bounds).
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
gcc/testsuite/ChangeLog:
* gcc.dg/vect/vect-simd-18.c: Fix ASAN error.
*
Richard Sandiford via Gcc-patches writes:
> Tamar Christina writes:
>> Hi All,
>>
>> The new partial and full vector types added to AArch64, e.g.
>>
>> int8x8x2_t with mode V2x8QI are incorrectly being defined as being short
>> vectors and not being composite types.
>>
>> This causes the layout
1 - 100 of 116 matches
Mail list logo
