On Wed, Sep 16, 2020 at 08:00:01AM -0400, Nathan Sidwell wrote:
> is libgomp/testsuite/libgomp.c++/udr-3.C well formed?
>
> Specifically V::baz?
>
> If you remove the templatedness and plug in typedefs for T & D on its only
> instantiation (as the attached does), you get the following errors:
>
On Wed, Sep 16, 2020 at 02:33:03PM +0200, Mark Wielaard wrote:
> > 2020-09-15 Jakub Jelinek
> >
> > * configure.ac (HAVE_AS_GDWARF_5_DEBUG_FLAG,
> > HAVE_AS_WORKING_DWARF_4_FLAG): New tests.
> > * gcc.c (ASM_DEBUG_DWARF_OPTION): Define.
> > (ASM_DEBUG_SPEC): Use ASM_DEBUG_DWARF_
On Wed, Sep 16, 2020 at 04:08:16PM +0200, Tobias Burnus wrote:
> Using linear (added by the compiler) + explicit lastprivate gives an error.
>
> To quote Jakub from the PR:
> "If it is the FE that adds the linear clause, then it
> shouldn't when there is explicit lastprivate clause.
> This is a ne
On Wed, Sep 16, 2020 at 02:11:32PM -0400, Nathan Sidwell wrote:
> Jakub,
> are you ok with the bool return from cp_check_omp_declare_reduction? That
> seemed like the least invasive change.
>
> This corrects the earlier problems with removing the template header
> from local omp reductions. And i
On Wed, Sep 16, 2020 at 02:38:22PM -0400, Nathan Sidwell wrote:
> On 9/16/20 2:31 PM, Jakub Jelinek wrote:
> > On Wed, Sep 16, 2020 at 02:11:32PM -0400, Nathan Sidwell wrote:
> > > Jakub,
> > > are you ok with the bool return from cp_check_omp_declare_reduction? That
> > > seemed like the least inv
On Thu, Sep 17, 2020 at 06:03:28PM +0200, Mark Wielaard wrote:
> On Mon, 2020-08-24 at 22:26 +0200, Mark Wielaard wrote:
> > On Mon, Aug 24, 2020 at 07:44:27PM +0200, Jakub Jelinek wrote:
> > > On Mon, Aug 24, 2020 at 02:56:56PM +0200, Mark Wielaard wrote:
> > > > Some DWARF tests scan the assembly
On Thu, Sep 17, 2020 at 12:18:40PM -0600, Jeff Law via Gcc-patches wrote:
> >> In an LTO world the TU isn't indivisible anymore. LTO will happily
> >> discard things which don't appear to be used. So parts of the TU may
> >> be in the main program, other parts may be in DSOs used by the main
> >
Hi!
The following testcase is miscompiled on i686-linux, because
we try to expand a double-word bitwise logic operation with op0
being a (mem:DI u) and target (mem:DI u+4), i.e. partial overlap, and
thus end up with:
movl4(%esp), %eax
andlu, %eax
movl%eax, u+4
!
On Fri, Sep 18, 2020 at 01:39:16PM +0200, Richard Biener wrote:
> This corrects the mask for creation of x << s | x >> (-x & mask)
> from a rotate x <
> Bootstrap / regtest running on x86_64-unknown-linux-gnu.
>
> 2020-09-18 Richard Biener
>
> PR tree-optimization/97081
> * tree-v
On Fri, Sep 18, 2020 at 01:39:16PM +0200, Richard Biener wrote:
> --- a/gcc/tree-vect-patterns.c
> +++ b/gcc/tree-vect-patterns.c
> @@ -2456,7 +2456,6 @@ vect_recog_rotate_pattern (vec_info *vinfo,
>append_pattern_def_seq (vinfo, stmt_vinfo, def_stmt);
> }
>stype = TREE_TYPE (def);
On Tue, Sep 22, 2020 at 09:11:48AM +0200, Tobias Burnus wrote:
> > Okay – or do we find more issues?
I'm afraid so.
> + if (omp_declare_target_fn_p (decl)
> + || lookup_attribute ("omp declare target host",
> +DECL_ATTRIBUTES (decl)))
> + re
Hi!
These two builtin calls are added already during parsing before pointer
subtractions or comparisons, normally they perform runtime verification
of whether the pointers point to the same object or different objects,
but during constant expressione valuation we don't really need those
builtins f
Hi!
This fixes
FAIL: compiler driver --help=common option(s): "^ +-.*[^:.]$" absent from
output: " --param=modref-max-tests= Maximum number of tests perofmed by
On Tue, Sep 22, 2020 at 10:13:46AM +0200, Jakub Jelinek via Gcc-patches wrote:
> --- gcc/params.opt.jj 2020-09-21 11:15:53.816516949 +0200
> +++ gcc/params.opt2020-09-22 09:59:37.121115589 +0200
> @@ -882,7 +882,7 @@ Maximum number of refs stored in each mo
>
> -param=m
On Tue, Sep 22, 2020 at 04:11:19PM +0200, Tobias Burnus wrote:
> + while (node->alias_target)
> + {
> + node = node->ultimate_alias_target ();
At least in theory, ultimate_alias_target can look through multiple aliases.
While it might not do that most of the time because th
On Tue, Sep 22, 2020 at 02:19:12PM +0200, Richard Biener via Gcc-patches wrote:
> On September 22, 2020 1:22:12 PM GMT+02:00, "Martin Liška"
> wrote:
> >Hi.
> >
> >The patch is about a bail out limit that needs to be added to switch
> >lowering.
> >Currently the algorithm is quadratic and needs s
On Wed, Sep 23, 2020 at 02:53:54PM +0200, Tobias Burnus wrote:
> (Pre-remark: the following applies to the host; the offloading
> is only involved as otherwise the (.gnu.)offload_{vars,funcs}
> global variable/table wouldn't exist.)
>
> Due to partitioning, it can happen that the offloading table
On Wed, Sep 23, 2020 at 03:52:12PM +0200, Tobias Burnus wrote:
> + if (TREE_CODE (*tp) == FUNCTION_DECL)
> {
> + tree decl = *tp;
>tree id = get_identifier ("omp declare target");
> - if (!DECL_EXTERNAL (*tp) && DECL_SAVED_TREE (*tp))
> - ((vec *) data)->safe_push (*tp);
On Sun, Sep 20, 2020 at 07:08:09PM -0400, Marek Polacek via Gcc-patches wrote:
> We crash here because since r11-3302 the C FE uses codes like SWITCH_STMT
> in the else branches in the attached test, and inchash::add_expr in
> do_warn_duplicated_branches doesn't handle these front-end codes. In
>
On Thu, Sep 24, 2020 at 11:41:00AM +0200, Tobias Burnus wrote:
> Following Jakub's suggestion, I also added
> __attribute__((used))
> to the tree belonging to both tables in omp-offload.c's omp_finish
> but that did not help, either.
That is really DECL_PRESERVED_P, the attribute is turned into
On Wed, Sep 23, 2020 at 04:51:01PM +0200, Mark Wielaard wrote:
> This adds a get_DW_UT_name function to dwarfnames using dwarf2.def
> for use in binutils readelf to show the unit types in a DWARF5 header.
>
> Also remove DW_CIE_VERSION which was already removed in binutils/gdb
> and is not used in
The following change adds support for non-rectangular simd loops.
While working on that, I've noticed we actually don't vectorize collapsed
simd loops at all, because the code that I thought would be vectorizable
actually is not vectorized. While in theory for the constant lower/upper
bounds and c
Hi!
As mentioned in the PR, since 2005 we reject if array elements are smaller
than their alignment (i.e. overaligned elements), because such arrays don't
make much sense, only their first element is guaranteed to be aligned as
user requested, but the next element can't be.
The following testcases
Hi!
libcpp has two specialized altivec implementations of search_line_fast,
one for power8+ and the other one otherwise.
Both use __attribute__((altivec(vector))) and the GCC builtins rather than
altivec.h and the APIs from there, which is fine, but should be restricted
to when libcpp is built wit
On Fri, Sep 25, 2020 at 01:11:37PM +0200, Richard Biener wrote:
> This adds rough support to avoid "'target_mem_ref' not supported by"
> in diagnostics. There were recent patches by Martin to sanitize
> dumping of MEM_REF so I'm not trying to interfere with this here.
Is that correct?
I mean, TAR
On Wed, Sep 23, 2020 at 05:45:12PM +0200, Tobias Burnus wrote:
> On 9/23/20 4:06 PM, Jakub Jelinek wrote:
>
> > What I really meant was:
> I did now something based on this.
> > > + gcc_assert (node->alias && node->analyzed);
>
> I believe from previous testing that node->analyzed is
Hi!
I'd like to ping a few patches:
https://gcc.gnu.org/pipermail/gcc-patches/2020-August/552451.html
- allow plugins to deal with global_options layout changes
https://gcc.gnu.org/pipermail/gcc-patches/2020-September/553420.html
- --enable-link-serialization{,=N} support
https://gcc.gnu.or
Hi!
On Fri, Sep 25, 2020 at 01:37:16PM +0200, Richard Biener wrote:
> See my comment above for Martins attempts to improve things. I don't
> really want to try decide what to do with those late diagnostic IL
> printing but my commit was blamed for showing target-mem-ref unsupported.
>
> I don't
On Fri, Sep 25, 2020 at 11:13:06AM +0200, Martin Liška wrote:
> --- a/gcc/tree-switch-conversion.c
> +++ b/gcc/tree-switch-conversion.c
> @@ -1268,6 +1268,15 @@ jump_table_cluster::can_be_handled (const vec *> &clusters,
>if (range == 0)
> return false;
>
> + unsigned HOST_WIDE_INT lhs
Hi!
As mentioned earlier, the vectorizer punts on vectorization of loops with
non-constant
steps. As for OpenMP loops it is by the language restriction always possible
to compute
the number of loop iterations before the loop, this change helps those cases
by computing it and using an alternate
On Mon, Sep 28, 2020 at 09:50:00PM +0200, Stefan Schulze Frielinghaus wrote:
> This patch breaks quite a view test cases (target-attribute/tattr-*) on
> IBM Z. Having a look at function cl_target_option_restore reveals that
> some members of opts_set are reduced to 1 or 0 depending on whether a
>
On Tue, Sep 01, 2020 at 09:16:23PM +0800, Chung-Lin Tang wrote:
> this patch set implements parts of the target mapping changes introduced
> in OpenMP 5.0, mainly the attachment requirements for pointer-based
> list items, and the clause ordering.
>
> The first patch here are the C/C++ front-end c
On Tue, Sep 29, 2020 at 11:46:24AM -0700, H.J. Lu via Gcc-patches wrote:
> Fix a typo in config/i386/enqcmdintrin.h by replacing
> with :
>
> [hjl@gnu-cfl-2 x86-gcc]$ echo "#include " | gcc -S -o
> /dev/null -x c -
> In file included from :1:
> /usr/lib/gcc/x86_64-redhat-linux/10/include/enqcmdi
On Tue, Sep 29, 2020 at 11:58:39AM -0700, H.J. Lu wrote:
> Here is the V2 patch. OK for master and GCC 10 branches?
Yes, thanks.
Jakub
On Tue, Sep 29, 2020 at 08:25:44PM +0100, Andrew Stubbs wrote:
> 2020-09-29 Andrew Stubbs
>
> * parallel.c (gomp_resolve_num_threads): Ignore nest_var on nvptx
> and amdgcn targets.
>
> diff --git a/libgomp/parallel.c b/libgomp/parallel.c
> index 2423f11f44a..0618056a7fe 100644
> -
On Fri, Sep 25, 2020 at 04:30:26PM -0400, Jason Merrill via Gcc-patches wrote:
> On 9/15/20 3:57 AM, Jakub Jelinek wrote:
> > The following testcase is miscompiled (in particular the a and i
> > initialization). The problem is that build_special_member_call due to
> > the immediate constructors (b
Hi!
As mentioned in the PR, we only support due to a bug in constant expressions
std::construct_at on non-automatic variables, because we VERIFY_CONSTANT the
second argument of placement new, which fails verification if it is an
address of an automatic variable.
The following patch fixes it by not
On Mon, Sep 28, 2020 at 09:50:00PM +0200, Stefan Schulze Frielinghaus via
Gcc-patches wrote:
> This patch breaks quite a view test cases (target-attribute/tattr-*) on
> IBM Z. Having a look at function cl_target_option_restore reveals that
> some members of opts_set are reduced to 1 or 0 dependin
On Tue, Sep 29, 2020 at 03:40:40PM -0600, Martin Sebor via Gcc-patches wrote:
> I will commit this patch later this week unless I hear concerns
> or suggestions for changes.
That is not how the patch review process works.
> + arat = tree_cons (get_identifier ("array"), flag, NULL_TREE);
Be
On Wed, Sep 30, 2020 at 01:21:44PM +0200, Stefan Schulze Frielinghaus wrote:
> I think the problem boils down that on S/390 we distinguish between four
> states of a flag: explicitely set to yes/no and implicitely set to
> yes/no. If set explicitely, the option wins. For example, the options
> `-
On Wed, Sep 30, 2020 at 01:37:46PM +0200, Tobias Burnus wrote:
> We missed to handle nested procedures.
>
> OK for the trunk?
Yes, thanks.
Jakub
On Fri, Sep 18, 2020 at 04:31:55PM +0800, Hongyu Wang via Gcc-patches wrote:
> Very Appreciated for your review again
>
> I just update the patch with adding XSAVE dependency and use
> __builtin_cpu_supports for runtime test.
Several tests FAIL when using older binutils that don't support AMX.
F
On Wed, Sep 30, 2020 at 02:27:38PM +0200, Florian Weimer wrote:
> --- a/gcc/doc/invoke.texi
> +++ b/gcc/doc/invoke.texi
> @@ -29258,6 +29258,13 @@ of the selected instruction set.
> @item x86-64
> A generic CPU with 64-bit extensions.
>
> +@item x86-64-v2
> +@itemx x86-64-v3
> +@itemx x86-64-v4
On Wed, Sep 30, 2020 at 04:05:41PM +0200, Florian Weimer wrote:
> > I think the documentation should state that these are not valid in -mtune=,
> > just in -march=, and that using -march=x86-64-v* will not change tuning.
> > I guess there should be some testsuite coverage for the for some unexpecte
On Wed, Sep 30, 2020 at 04:29:34PM +0200, Florian Weimer wrote:
> > Thinking about it more, wouldn't it better to just imply generic tuning
> > for these -march= options?
>
> I think this is what the patch does? See the x86-64-v3-haswell.c
> test.
No, I think it will have that behavior solely wh
On Wed, Sep 30, 2020 at 06:06:31PM +0200, Florian Weimer wrote:
> This is what I came up with. It is not valid to set ix86_arch to
> PROCESSOR_GENERIC, which is why PTA_NO_TUNE is still needed.
Ok, LGTM, but would prefer Uros to have final voice.
Jakub
Hi!
The following patch fixes
-FAIL: gcc.dg/pr94780.c (internal compiler error)
-FAIL: gcc.dg/pr94780.c (test for excess errors)
-FAIL: gcc.dg/pr94842.c (internal compiler error)
-FAIL: gcc.dg/pr94842.c (test for excess errors)
on s390x-linux. The fix is essentially the same as has been applied t
On Wed, Sep 30, 2020 at 03:24:08PM +0200, Stefan Schulze Frielinghaus via
Gcc-patches wrote:
> On Wed, Sep 30, 2020 at 01:39:11PM +0200, Jakub Jelinek wrote:
> > On Wed, Sep 30, 2020 at 01:21:44PM +0200, Stefan Schulze Frielinghaus wrote:
> > > I think the problem boils down that on S/390 we disti
On Fri, Oct 02, 2020 at 05:33:13PM +, Joseph Myers wrote:
> On Fri, 2 Oct 2020, Tobias Burnus wrote:
>
> > However, this flag can be added into the offload-target's libgomp.spec,
> > which avoids all kind of issues. That's what this patch now does.
> >
> > I tested it with x86_64-gnu-linux w/
On Fri, Oct 02, 2020 at 04:21:12PM +0200, Stefan Schulze Frielinghaus via
Gcc-patches wrote:
> > > Sure, no problem at all. In that case I stop to investigate further and
> > > wait for you.
> >
> > Here is a patch that implements that.
> >
> > Can you please check if it fixes the s390x regress
On Sun, Oct 04, 2020 at 09:13:29AM +0200, Andreas Schwab wrote:
> This breaks ia64:
>
> In file included from ./tm.h:23,
> from ../../gcc/gencheck.c:23:
> ./options.h:7816:40: error: ISO C++ forbids zero-size array 'explicit_mask'
> [-Werror=pedantic]
> 7816 | unsigned HOST_WI
On Sun, Oct 04, 2020 at 09:16:00PM +0200, Jakub Jelinek via Gcc-patches wrote:
> On Sun, Oct 04, 2020 at 09:13:29AM +0200, Andreas Schwab wrote:
> > This breaks ia64:
> >
> > In file included from ./tm.h:23,
> > from ../../gcc/gencheck.c:23:
> >
Hi!
I've noticed a -Wnarrowing warning on gimple-ssa-store-merging.c, this
change fixes that up.
Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk as
obvious.
2020-10-05 Jakub Jelinek
* gimple-ssa-store-merging.c
(imm_store_chain_info::output_merged_st
Hi!
I'd like to ping a few patches:
https://gcc.gnu.org/pipermail/gcc-patches/2020-August/552451.html
- allow plugins to deal with global_options layout changes
https://gcc.gnu.org/pipermail/gcc-patches/2020-September/553420.html
- --enable-link-serialization{,=N} support
https://gcc.gnu.or
On Mon, Sep 14, 2020 at 11:47:56AM +0200, Jakub Jelinek via Gcc-patches wrote:
> On Mon, Sep 14, 2020 at 11:02:26AM +0200, Jan Hubicka wrote:
> > Especially for the new param machinery, most of streamed values are
> > probably going to be the default values. Perhaps somehow we c
On Mon, Oct 05, 2020 at 11:48:32AM +0200, Christophe Lyon via Gcc-patches wrote:
> > For 'no such binding' errors, we iterate over binding levels to find a
> > close match. At the namespace level we were using DECL_ANTICIPATED to
> > skip undeclared builtins. But (a) there are other unnameable th
On Fri, Oct 02, 2020 at 12:59:54PM -0400, Andrew MacLeod via Gcc-patches wrote:
>
> The ranger is needed to map those values to the switch variable, and also
> apply any previous ranges or derived values (ie, if you ask for the range of
> 'y' in case 2, it will return unsigned int [6,6].
>
>
On Mon, Oct 05, 2020 at 09:39:01AM -0400, Nathan Sidwell wrote:
> My change to namespace-scope spell corrections ignored the issue that
> different targets might have different builtins, and therefore perturb
> iteration order. This fixes it by using an intermediate array of
> identifier, wh
Hi!
This ICEs because node->alias_target is (not yet) a FUNCTION_DECL, but
IDENTIFIER_NODE.
I guess we should retry the discovery before LTO streaming out, the reason
to do it this early is that it can affect the gimplification and omp lowering.
Bootstrapped/regtested on x86_64-linux and i686-li
Hi!
As written in the comment, tree-ssa-math-opts.c wouldn't create a DIVMOD
ifn call for division + modulo by constant for the fear that during
expansion we could generate better code for those cases.
If the divisoris a power of two, that is certainly the case always,
but otherwise expand_divmod
On Tue, Oct 06, 2020 at 09:37:21AM +0200, Aldy Hernandez via Gcc-patches wrote:
> Pushed as obvious.
>
> gcc/ChangeLog:
>
> * value-range.h (irange_allocator::allocate): Increase
> newir storage by one.
> ---
> gcc/value-range.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
On Tue, Oct 06, 2020 at 10:47:34AM +0200, Andreas Schwab wrote:
> On Okt 06 2020, Jakub Jelinek via Gcc-patches wrote:
>
> > I mean, we could just use:
> > size_t nbytes = sizeof (irange) + sizeof (tree) * 2 * num_pairs;
> > irange *r = (irange *) obstack_a
On Tue, Oct 06, 2020 at 10:56:35AM +0200, Tobias Burnus wrote:
> As reported in the PR, the in-tree build of GMP fails for BSD.
> The reason is that with_gmp is set if there is a gmp.h under
> /usr/local – such that in-tree GMP is build but later not used,
> which causes build fails if /usr/local h
On Tue, Oct 06, 2020 at 11:20:52AM +0200, Aldy Hernandez wrote:
> > > diff --git a/gcc/value-range.h b/gcc/value-range.h
> > > index 94b48e55e77..7031a823138 100644
> > > --- a/gcc/value-range.h
> > > +++ b/gcc/value-range.h
> > > @@ -670,7 +670,7 @@ irange_allocator::allocate (unsigned num_pairs)
On Tue, Oct 06, 2020 at 08:22:13AM +0200, Richard Biener wrote:
> > I was really hoping bbs 4 and 5 would be one loop (the one I set safelen
> > and force_vectorize etc. for) and that basic blocks 6 and 7 would be
> > together with that inner loop another loop, but apparently loop discovery
> > thi
On Tue, Oct 06, 2020 at 08:47:53AM -0400, Andrew MacLeod wrote:
> > I think the proper alignment will be guaranteed if irange and tree[] are
> > obstack_alloc'd separately. They don't need to be adjacent, do they?
> >
> >
> They do not, it just seemed wasteful to do 2 allocs each time, and it'd
Hi!
On Tue, Oct 06, 2020 at 11:28:22AM +0200, Andreas Schwab wrote:
> options-save.c: In function 'void cl_target_option_save(cl_target_option*,
> gcc_options*, gcc_options*)':
> options-save.c:8526:26: error: unused variable 'mask'
> [-Werror=unused-variable]
> 8526 | unsigned HOST_WIDE_INT
On Tue, Oct 06, 2020 at 03:48:38PM +0200, Martin Liška wrote:
> On 10/6/20 9:47 AM, Richard Biener wrote:
> > But is it really extensible with the current implementation? I doubt so.
>
> I must agree with the statement. So let's make the pass properly.
> I would need a help with the algorithm whe
On Tue, Oct 06, 2020 at 12:20:14PM +0200, Martin Liška wrote:
> On 10/6/20 10:00 AM, Richard Biener wrote:
> > On Tue, Oct 6, 2020 at 9:01 AM Martin Liška wrote:
> > >
> > > On 10/5/20 6:34 PM, Ian Lance Taylor wrote:
> > > > On Mon, Oct 5, 2020 at 9:09 AM Martin Liška wrote:
> > > > >
> > > >
On Tue, Oct 06, 2020 at 04:48:40PM +0200, Tom de Vries wrote:
> On 10/5/20 3:15 PM, Tom de Vries wrote:
> > On 2/7/20 4:29 PM, Jakub Jelinek wrote:
> >> On Fri, Feb 07, 2020 at 09:56:38AM +0100, Harwath, Frederik wrote:
> >>> * {target-32.c, thread-limit-2.c}:
> >>> no "usleep" implemented for nvpt
On Tue, Oct 06, 2020 at 10:42:12AM -0600, Martin Sebor wrote:
> The manual documents the [0] extension and mentions but discourages
> using [1]. Nothing is said about other sizes and the warnings such
> as -Warray-bounds have been increasingly complaining about accesses
> past the declared constan
On Tue, Oct 06, 2020 at 01:41:54PM -0400, Andrew MacLeod wrote:
> On 10/6/20 1:32 PM, Jakub Jelinek via Gcc-patches wrote:
> > On Tue, Oct 06, 2020 at 10:42:12AM -0600, Martin Sebor wrote:
> > > The manual documents the [0] extension and mentions but discourages
> > >
On Tue, Oct 06, 2020 at 02:09:42PM -0400, Andrew MacLeod wrote:
> + size_t nbytes = sizeof (tree) * 2 * num_pairs;
> +
> + // Allocate the irnge and required memory for the vector
> + void *r = (irange *) obstack_alloc (&m_obstack, sizeof (irange));
Then either
void *r = (void *) obstack_all
Hi!
The following testcase FAILs, because we don't mark the child OpenMP function
as cfun->calls_alloca when it does call alloca. When optimizing, during DCE we
reset those flags and recompute them again, but with -O0 DCE is not performed.
Fixed by calling notice_special_calls when moving insns
Hi!
The arm target hook for divmod wasn't prepared to handle constants passed to
the function.
Fixed thusly, bootstrapped/regtested on armv7hl-linux-gnueabi, ok for trunk?
2020-10-08 Jakub Jelinek
PR target/97322
* config/arm/arm.c (arm_expand_divmod_libfunc): Pass mode inste
On Thu, Oct 08, 2020 at 11:58:21AM +0200, Aldy Hernandez via Gcc-patches wrote:
> I am quoting my analysis from the PR. Could an aarch64 expert pontificate
> here?
>
> This test is checking the final assembly for a specific sequence. I don't
> speak aarch64 assembly, but the IL is different comi
On Thu, Oct 08, 2020 at 12:22:11PM +0200, Jakub Jelinek via Gcc-patches wrote:
> We have several enhancement reports in bugzilla from Gabriel Ravier on this
> topic I think.
See e.g. PR94801, PR94793, PR95863 on the topic.
Jakub
On Thu, Oct 08, 2020 at 11:04:01AM +, Wilco Dijkstra wrote:
> > Perhaps another way out of this would be document and enforce that
> > __builtin_c[lt]z{,l,ll} etc calls are undefined at zero, but C[TL]Z ifn
> > calls are defined there based on *_DEFINED_VALUE_AT_ZERO (*) == 2, and then
> > we w
On Thu, Oct 08, 2020 at 11:22:34AM +, Wilco Dijkstra wrote:
> >> I think a better way forward would be to make the builtin_clz/ctz more
> >> defined.
> >> Having undefined values is a source of unnecessary bugs given practically
> >> all
> >> modern targets return the number of bits for the z
On Thu, Oct 08, 2020 at 11:37:24AM +, Wilco Dijkstra via Gcc-patches wrote:
> Which optimizations does it enable that aren't possible if the value is
> defined?
See bugzilla. Note other compilers heavily optimize on those builtins
undefined at value zero.
> > We just should make sure that w
On Thu, Oct 08, 2020 at 11:46:36AM +0200, Aldy Hernandez via Gcc-patches wrote:
> This was a pasto by yours truly while porting the __builtin code from
> vr_values::extract_range_basic.
>
> I've tested Andrew's patch, and pushed it.
Note for next time, I think you should use --author when committ
On Thu, Oct 08, 2020 at 12:22:11PM +0200, Jakub Jelinek via Gcc-patches wrote:
> Perhaps another way out of this would be document and enforce that
> __builtin_c[lt]z{,l,ll} etc calls are undefined at zero, but C[TL]Z ifn
> calls are defined there based on *_DEFINED_VALUE_AT_ZERO (*)
On Thu, Oct 08, 2020 at 04:28:37PM +0200, Aldy Hernandez wrote:
> On 10/8/20 3:54 PM, Jakub Jelinek wrote:
> > On Thu, Oct 08, 2020 at 12:22:11PM +0200, Jakub Jelinek via Gcc-patches
> > wrote:
> > > Perhaps another way out of this would be document and enforce that
>
On Thu, Oct 08, 2020 at 04:55:07PM +0200, Aldy Hernandez via Gcc-patches wrote:
> > Yes, for max == 0 aka [0, 0] I wanted:
> > 1) if mini == -1, i.e. the DEFINED_VALUE_AT_ZERO == 2 VALUE is -1, return
> > [-1, -1]
> > 2) if maxi == prec, i.e. DEFINED_VALUE_AT_ZERO == 2 VALUE is prec, return
> > [
On Fri, Oct 09, 2020 at 10:11:29AM +0200, Aldy Hernandez wrote:
> OK for trunk?
Sure.
>
> gcc/testsuite/ChangeLog:
>
> PR testsuite/97337
> * gcc.dg/pr97315-1.c: Moved to...
> * g++.dg/opt/pr97315-1.C: ...here.
> ---
> gcc/testsuite/{gcc.dg/pr97315-1.c => g++.dg/opt/pr97315-1.
On Tue, Oct 06, 2020 at 03:40:52PM -0400, Jason Merrill via Gcc-patches wrote:
> On 10/4/20 11:28 PM, Patrick Palka wrote:
> > cp_tree_equal currently considers alignof the same as __alignof__, but
> > these operators are semantically different ever since r8-7957. In the
> > testcase below, this c
On Mon, Oct 12, 2020 at 10:13:09AM +0200, Tobias Burnus wrote:
> This is a tiny update – and probably not the last for the GCC 11 status
> and especially as the project page is still linked prominently at some
> external pages:
>
> Update the GOMP project page a bit; some more revisions wouldn't h
On Thu, Aug 04, 2022 at 09:17:09PM +0800, Chung-Lin Tang wrote:
> On 2022/6/28 10:06 PM, Jakub Jelinek wrote:
> > On Thu, Jun 23, 2022 at 11:47:59PM +0800, Chung-Lin Tang wrote:
> > > with the way that chunk_size < 1 is handled for gomp_iter_dynamic_next:
> > >
> > > (1) chunk_size <= -1: wraps in
Hi!
The following patch attempts to implement C++23 P1169R4 - static operator()
paper's compiler side (there is some small library side too not implemented
yet). This allows static members as user operator() declarations and
static specifier on lambdas without lambda capture. As decl specifier
p
Hi!
While icv_addr[1] = false; assignments where icv_addr has void *
element type is correct and matches how it is used (in those cases
the void * pointer is then cast to bool and used that way), there is no
reason not to add explicit (void *) casts there which are there already
for (void *) true.
Hi!
My change to match.pd (that added the two simplifications this patch
touches) results in more |/^/& assignments with pointer arguments,
but since r12-1608 we reject pointer operands for BIT_NOT_EXPR.
Disallowing them for BIT_NOT_EXPR and allowing for BIT_{IOR,XOR,AND}_EXPR
leads to a match.pd
On Wed, Sep 14, 2022 at 08:09:08AM +, Richard Biener wrote:
> Are nested functions a thing for OpenMP? But yes, punt on them
> for now.
For Fortran certainly because they are part of the language, for C
too because they are GNU extension.
But declare simd is mostly best effort, so we can at l
On Wed, Sep 14, 2022 at 07:58:47AM +, Richard Biener wrote:
> > My change to match.pd (that added the two simplifications this patch
> > touches) results in more |/^/& assignments with pointer arguments,
> > but since r12-1608 we reject pointer operands for BIT_NOT_EXPR.
> >
> > Disallowing th
On Tue, Sep 13, 2022 at 02:01:42PM -0700, Julian Brown wrote:
> --- a/gcc/omp-low.cc
> +++ b/gcc/omp-low.cc
> @@ -1599,8 +1599,11 @@ scan_sharing_clauses (tree clauses, omp_context *ctx)
> {
> /* If this is an offloaded region, an attach operation should
>only
On Tue, Sep 13, 2022 at 02:01:43PM -0700, Julian Brown wrote:
> This patch has been split out from the previous one to avoid a
> confusingly-interleaved diff. The two patches will be committed squashed
> together.
>
> 2022-09-13 Julian Brown
>
> gcc/
> * gimplify.c (omp_target_reorder_c
On Tue, Sep 13, 2022 at 02:01:44PM -0700, Julian Brown wrote:
> static tree
> -insert_struct_comp_map (enum tree_code code, tree c, tree struct_node,
> - tree prev_node, tree *scp)
> +build_struct_comp_nodes (enum tree_code code, tree grp_start, tree grp_end,
> +
On Tue, Sep 13, 2022 at 02:01:45PM -0700, Julian Brown wrote:
> @@ -9443,6 +9499,41 @@ omp_containing_struct (tree expr)
>return expr;
> }
>
Missing function comment here.
> +static bool
> +omp_mapped_by_containing_struct (hash_map + omp_mapping_group
On Tue, Sep 13, 2022 at 02:03:15PM -0700, Julian Brown wrote:
> This patch moves GOMP_MAP_ATTACH{_ZERO_LENGTH_ARRAY_SECTION} nodes to
> the end of the clause list, for offload regions. This ensures that when
> we do the attach operation, both the "attachment point" and the target
> region have bot
On Tue, Sep 13, 2022 at 02:03:16PM -0700, Julian Brown wrote:
> @@ -3440,6 +3437,50 @@ gfc_trans_omp_clauses (stmtblock_t *block,
> gfc_omp_clauses *clauses,
> {
> if (pointer || (openacc && allocatable))
> {
> + gfc
On Tue, Sep 13, 2022 at 02:03:17PM -0700, Julian Brown wrote:
> This patch trivially adds braces and reindents the
> OMP_CLAUSE_TO/OMP_CLAUSE_FROM/OMP_CLAUSE__CACHE_ stanza in
> c_finish_omp_clause and finish_omp_clause, in preparation for the
> following patch (to clarify the diff a little).
>
>
701 - 800 of 4686 matches
Mail list logo
