git commits no longer visible on bugzilla?
Hi, it seems that git commits are no longer automatically transferred to the relevant PRs. Recent example: I don't see https://gcc.gnu.org/pipermail/gcc-cvs/2020-December/338684.html in PR98156, although the ChangeLog was Upper cobound is determined by num_images(), not this_image(). gcc/testsuite/ChangeLog: PR testsuite/98156 * gfortran.dg/coarray/alloc_comp_1.f90: Upper cobound is determined by num_images(), not this_image(). Is this by design / have the format requirement changed / ... ? Regards Thomas
Re: Testsuite integration for devel/coarray_native
Am 06.12.20 um 18:37 schrieb dhumieres.domini...@free.fr:
Hi Thomas,
I'm currently trying to put together a testsuite for the shared coarray
branch. What I have so far is a directory
gcc/testsuite/gfortran.dg/caf-shared
which contains the attached dejagnu file plus the test cases
I don't see the point to introduce a new directory.
IMO all the tests for coarray should pass for shared coarray
The problem is that there is a significantly different ABI (there was
no reasonable choice to use the existing one), so there are different
(and, as of now, many more :-) bugs.
The policy is to have no failing test cases, so we need something
separate during development at least.
Also, the current tests do not actually implement multi-image coarrays,
unlike what the shared library does.
and a simple test would be to add
foreach flags $option_list {
verbose "Testing $nshort (libcaf_single), $flags" 1
set gfortran_aux_module_flags "-fcoarray=shared $flags
-lcaf_shared"
dg-test $test "-fcoarray=shared $flags -lcaf_shared
$maybe_atomic_lib" ""
cleanup-modules ""
}
at the end of gfortran.dg/coarray/caf.exp.
This will cover the check of more than 60 programs.
With ~ 40 failures, at the moment :-)
In addition greping for "fcoarray=" in gfortran.dg shows 200 programs
which should be moved to gfortran.dg/coarray/.
Some of them are duplicates.
but I am not sure if this is the right way to go about this
(would this work in the absence of an installed caf_shared library,
would this cause lots of failures on systems without pthreads, ...?)
Presently if shared coarray is not supported it is impossible to bootstrap.
What goes wrong? Do you have an idea how to fix it? The build
magic should have taken care of it, but of course if there is
no access to a system where things fail (and not even a feedback that
this is the case, until what you just wrote), it is almost impossible
to debug.
This is, of course, a fundamental problem of developing for
platforms where people don't have access to. Asynchronous I/O
was plagued by similar problem. We had been hoping for concrete
bug reports, but little luck so far, with the exception of
pthread barriers on MacOS, which was fixed.
IMO for the moment it is putting "la charrue avant le boeufs" (the plow
before the oxen) to discuss what to do for the tests before having
a solution to bootstrap without -lcaf_shared.
What exactly is the failure? Is it possible to get access to a
system where this failure occurs? I tried bootstrapping on all BSD
systems in the gcc compile farm, but apart from a few days
of wasted work and a few bootstrap PRs, that didn't result in anything
useful.
Having said that, I have actually committed the cas.exp to the branch
(with Nicolas' approval) so it is now possible to run a regression-test.
When you're doing things to the scalarizer and to array descriptors,
this is a must, regressions come easy and fast in that area...
So far, there is a grand total of 19 tests which pass.
I don't thing the shared coarray tests should go under libgomp.
libgomp has the infrastructursts, which is also good - it makes little
sense to run on 16 CPUs for ee to run pthreads, which is also required.
It also doesn't parralelize teach test case in parallel with
make -j16 check-fortran.
This is, for example, why the asynchronous I/O tests, which also
require pthreads, are found under libgomp.
Best regards
Thomas
gcc-11-20201206 is now available
Snapshot gcc-11-20201206 is now available on https://gcc.gnu.org/pub/gcc/snapshots/11-20201206/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 11 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch master revision 9da33826bb9b7d76f85057c18a0b65d0e14baa3d You'll find: gcc-11-20201206.tar.xz Complete GCC SHA256=ba7d7b00305aafbeeddc0d79349dc98b3dbc356f8eb22a38b75debdc363991d4 SHA1=8a870c1fad120b546fc76f7a13b8048df32a73e9 Diffs from 11-20201129 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-11 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Help with PR97872
On Fri, 4 Dec 2020 at 17:18, Richard Biener wrote:
>
> On Fri, 4 Dec 2020, Prathamesh Kulkarni wrote:
>
> > On Thu, 3 Dec 2020 at 16:35, Richard Biener wrote:
> > >
> > > On Thu, 3 Dec 2020, Prathamesh Kulkarni wrote:
> > >
> > > > On Tue, 1 Dec 2020 at 16:39, Richard Biener wrote:
> > > > >
> > > > > On Tue, 1 Dec 2020, Prathamesh Kulkarni wrote:
> > > > >
> > > > > > Hi,
> > > > > > For the test mentioned in PR, I was trying to see if we could do
> > > > > > specialized expansion for vcond in target when operands are -1 and
> > > > > > 0.
> > > > > > arm_expand_vcond gets the following operands:
> > > > > > (reg:V8QI 113 [ _2 ])
> > > > > > (reg:V8QI 117)
> > > > > > (reg:V8QI 118)
> > > > > > (lt (reg/v:V8QI 115 [ a ])
> > > > > > (reg/v:V8QI 116 [ b ]))
> > > > > > (reg/v:V8QI 115 [ a ])
> > > > > > (reg/v:V8QI 116 [ b ])
> > > > > >
> > > > > > where r117 and r118 are set to vector constants -1 and 0
> > > > > > respectively.
> > > > > > However, I am not sure if there's a way to check if the register is
> > > > > > constant during expansion time (since we don't have df analysis
> > > > > > yet) ?
> > > > > >
> > > > > > Alternatively, should we add a target hook that returns true if the
> > > > > > result of vector comparison is set to all-ones or all-zeros, and
> > > > > > then
> > > > > > use this hook in gimple ISEL to effectively turn VEC_COND_EXPR into
> > > > > > nop ?
> > > > >
> > > > > Would everything match-up for a .VEC_CMP IFN producing a non-mask
> > > > > vector type? ISEL could special case the a ? -1 : 0 case this way.
> > > > I think the vec_cmp pattern matches but it produces a masked vector
> > > > type.
> > > > In the attached patch, I simply replaced:
> > > > _1 = a < b
> > > > x = _1 ? -1 : 0
> > > > with
> > > > x = view_convert_expr<_1>
> > > >
> > > > For the test-case, isel generates:
> > > > vector(8) _1;
> > > > vector(8) signed char _2;
> > > > uint8x8_t _5;
> > > >
> > > >[local count: 1073741824]:
> > > > _1 = a_3(D) < b_4(D);
> > > > _2 = VIEW_CONVERT_EXPR(_1);
> > > > _5 = VIEW_CONVERT_EXPR(_2);
> > > > return _5;
> > > >
> > > > and results in desired code-gen:
> > > > f1:
> > > > vcgt.s8 d0, d1, d0
> > > > bx lr
> > > >
> > > > Altho I guess, we should remove the redundant conversions during isel
> > > > itself ?
> > > > and result in:
> > > > _1 = a_3(D) < b_4(D)
> > > > _5 = VIEW_CONVERT_EXPR(_1)
> > > >
> > > > (Patch is lightly tested with only vect.exp)
> > >
> > > + /* For targets where result of comparison is all-ones or all-zeros,
> > > + a < b ? -1 : 0 can be reduced to a < b. */
> > > +
> > > + if (integer_minus_onep (op1) && integer_zerop (op2))
> > > +{
> > >
> > > So this really belongs here:
> > >
> > > tree op0_type = TREE_TYPE (op0);
> > > tree op0a_type = TREE_TYPE (op0a);
> > >
> > > <---
> > >
> > > if (used_vec_cond_exprs >= 2
> > > && (get_vcond_mask_icode (mode, TYPE_MODE (op0_type))
> > > != CODE_FOR_nothing)
> > > && expand_vec_cmp_expr_p (op0a_type, op0_type, tcode))
> > > {
> > >
> > >
> > > + gassign *def_stmt = dyn_cast (SSA_NAME_DEF_STMT (op0));
> > > + tree op0a = gimple_assign_rhs1 (def_stmt);
> > > + tree op0_type = TREE_TYPE (op0);
> > > + tree op0a_type = TREE_TYPE (op0a);
> > > + enum tree_code tcode = gimple_assign_rhs_code (def_stmt);
> > > +
> > > + if (expand_vec_cmp_expr_p (op0a_type, op0_type, tcode))
> > > + {
> > > + tree conv_op = build1 (VIEW_CONVERT_EXPR, TREE_TYPE (lhs), op0);
> > > + gassign *new_stmt = gimple_build_assign (lhs, conv_op);
> > > + gsi_replace (gsi, new_stmt, true);
> > >
> > > and you need to verify that the mode of the lhs and the mode of op0
> > > agree and that the target can actually expand_vec_cmp_expr_p
> > Thanks for the suggestions, does the attached patch look OK ?
> > Sorry, I am not sure how to check if target can actually expand vec_cmp ?
> > I assume that since expand_vec_cmp_expr_p queries optab and if it gets
> > a valid cmp icode, that
> > should be sufficient ?
>
> Yes
Hi Richard,
I tested the patch, and it shows one regression for pr78102.c, because
of extra pcmpeqq in code-gen for x != y on x86.
For the test-case:
__v2di
baz (const __v2di x, const __v2di y)
{
return x != y;
}
Before patch:
baz:
pcmpeqq %xmm1, %xmm0
pcmpeqd %xmm1, %xmm1
pandn %xmm1, %xmm0
ret
After patch,
Before ISEL:
vector(2) _1;
__v2di _4;
[local count: 1073741824]:
_1 = x_2(D) != y_3(D);
_4 = VEC_COND_EXPR <_1, { -1, -1 }, { 0, 0 }>;
return _4;
After ISEL:
vector(2) _1;
__v2di _4;
[local count: 1073741824]:
_1 = x_2(D) != y_3(D);
_4 = VIEW_CONVERT_EXPR<__v2di>(_1);
return _4;
which results in:
pcmpeqq %xmm1, %xmm0
pxor%xmm1, %xmm1
pcmpeqq %xmm1, %xmm0
ret
IIUC, the new code-gen is essentially compari
Re: DWARF64 gcc/clang flag discussion
On Fri, Dec 4, 2020 at 7:01 PM Alexander Yermolovich wrote: > > > -- > *From:* Richard Biener > *Sent:* Friday, December 4, 2020 12:36 AM > *To:* David Blaikie > *Cc:* Alexander Yermolovich ; Jakub Jelinek < > ja...@redhat.com>; Mark Wielaard ; gcc@gcc.gnu.org < > gcc@gcc.gnu.org>; ikud...@accesssoftek.com ; > mask...@google.com > *Subject:* Re: DWARF64 gcc/clang flag discussion > > On Thu, Dec 3, 2020 at 6:52 PM David Blaikie wrote: > > > > On Wed, Dec 2, 2020 at 5:10 PM Alexander Yermolovich > wrote: > > > > -- > *From:* David Blaikie > *Sent:* Wednesday, December 2, 2020 1:12 PM > *To:* Alexander Yermolovich > *Cc:* Richard Biener ; Jakub Jelinek < > ja...@redhat.com>; Mark Wielaard ; gcc@gcc.gnu.org < > gcc@gcc.gnu.org>; ikud...@accesssoftek.com ; > mask...@google.com > *Subject:* Re: DWARF64 gcc/clang flag discussion > > > > On Wed, Dec 2, 2020 at 10:44 AM Alexander Yermolovich > wrote: > > > > -- > *From:* David Blaikie > *Sent:* Tuesday, December 1, 2020 10:33 AM > *To:* Alexander Yermolovich > *Cc:* Richard Biener ; Jakub Jelinek < > ja...@redhat.com>; Mark Wielaard ; gcc@gcc.gnu.org < > gcc@gcc.gnu.org>; ikud...@accesssoftek.com ; > mask...@google.com > *Subject:* Re: DWARF64 gcc/clang flag discussion > > > > On Mon, Nov 30, 2020 at 5:04 PM Alexander Yermolovich > wrote: > > > > -- > *From:* David Blaikie > *Sent:* Monday, November 30, 2020 12:09 PM > *To:* Alexander Yermolovich > *Cc:* Richard Biener ; Jakub Jelinek < > ja...@redhat.com>; Mark Wielaard ; gcc@gcc.gnu.org < > gcc@gcc.gnu.org>; ikud...@accesssoftek.com ; > mask...@google.com > *Subject:* Re: DWARF64 gcc/clang flag discussion > > On Mon, Nov 30, 2020 at 11:36 AM Alexander Yermolovich > wrote: > > Thank you David for driving the conversation, sorry I was on vacation. > > > All good - really appreciate everyone chipping in whenever/however they > can! > > > > I guess discussion is from perspective of having both flags > gdwarf32/gdwarf64. In which case it's a valid question on whether they > should imply -g like -gdwarf-#. > But can this be viewed as only a -gdwarf64 flag, that is a qualifier to > other debug flags that enable debug information? DWARF spec says that 32bit > should be a default, and 64bit should be used rarely (paraphrasing). So > when user enabled debug information the default expectation is that it will > be 32bit. There is no real need for a flag to say "I want debug > information, and I want it 32bit". > > > I'm not quite with you here, I think. I believe it's important to be able > to opt into and out of things at any point on the command line - because of > how complex build systems build up command lines. You might have a > -gdwarf64 set as a project default, but for some reason want to opt into > -gdwarf32 in other parts (perhaps you're building the debug info for your > interface library you intend to ship to clients who might only have DWARF32 > support, but your library is big and needs DWARF64 for the rest). A general > architectural principle of most command line arguments to the compiler is > that they can be opted into/out of fairly symmetrically (hence all the > -*no-* variant flags). > > [Alex] Ah I see, good point. > > > On the other hand, 64bit DWARF format must be enabled. So from users > perspective it's "I want debug information enabled for particular DWARF > version and level, oh and I want it to be 64bit". > > > But there's also the possibility of wanting to turn on DWARF64 for any > debug info in your build, but not necessarily wanting to turn on debug info > while doing so. Eg: you have a big build system, with a variety of users > and flags all over the place - maybe users opting in to -g2 on some files > and -g1 on others, and/or under different build modes. And the project as a > whole is reaching the DWARF64 tipping point and you'd like to say "if we're > generating DWARF, make it DWARF64". We've recently encountered this sort of > situation with -gsplit-dwarf and with -gdwarf-N (in switching to DWARFv5 we > had this situation where there's a big code base/build system with many > users, many uses of different -gN-type flags and it'd be impractical to go > and add -gdwarf-5 to all the -gN uses to make them all use DWARFv5, so we > added -fdebug-default-version=N (I might be misremembering the spelling) to > Clang to support this use case of "If we're generating DWARF, make it > DWARFv5") > > [Alex] I think we are saying similar thing. The -gdwarf64 doesn't enable > debug generation, but if it is enabled it will be 64bit. A "qualifier" of > sorts. > > > OK. My concern there, though I think it's the preferable semantics for the > -gdwarf64 flag when considered in isolation, is now -gdwarf64 and -gdwarf-5 > would have some fairly subtly different semantics (the latter enables debug > info and the former does not) in contrast to how close their spelling is. > (in ad
Re: how to get the library DECL for a built-in function
On Sat, Dec 5, 2020 at 1:55 AM Martin Sebor via Gcc wrote:
>
> On 12/4/20 4:33 PM, Martin Sebor wrote:
> > I'm looking for a way to get the FUNCTION_DECL for the library
> > (i.e., non-built-in) form of a function given the corresponding
> > built-in DECL. Is there an API I can all with either the built
> > -in DECL or its code to get it in the middle end?
> >
> > In C, what I'm looking for appears to be DECL_CHAIN(decl), at
> > least for the example I looked at. I.e., the library libdecl
> > for a corresponding __bultin_xxx DECL is DECL_CHAIN (DECL).
> >
> > But in C++, it looks like it's the other way around and it's
> > the built-in decl that's the DECL_CHAIN(DECL) for the built-in
> > DECL, and AFAIK there's no good way to get from the latter to
> > the former.
>
> To expand on this: I expected to get the library DECL for
> a declared function by calling
> symtab_node::get_from_asmname(libname) like for instance:
>
>tree id = get_identifier ("free");
>symtab_node *node = symtab_node::get_from_asmname (id);
>
> but what I get back is a DECL for __builtin_free instead.
> The DECL for "free" is the result of DECL_CHAIN() in C but
> not in C++.
The C family FEs aggressively "merge" decls, but usually
from builtin into the user provided one. Did you see whether
node->next_sharing_asm_name get's you anywhere?
(I've always wanted to see the user provided decl prevail
in what builtin_decl_implicit returns)
DECL_CHAIN on these is purely FE local from their global
name bindings structures, we should probably clear it
somewhere (LTO doesn't write it for example).
Richard.
>
> >
> > Thanks
> > Martin
> >
> >
> >
> >
>
Re: Help with PR97872
On Mon, 7 Dec 2020, Prathamesh Kulkarni wrote:
> On Fri, 4 Dec 2020 at 17:18, Richard Biener wrote:
> >
> > On Fri, 4 Dec 2020, Prathamesh Kulkarni wrote:
> >
> > > On Thu, 3 Dec 2020 at 16:35, Richard Biener wrote:
> > > >
> > > > On Thu, 3 Dec 2020, Prathamesh Kulkarni wrote:
> > > >
> > > > > On Tue, 1 Dec 2020 at 16:39, Richard Biener wrote:
> > > > > >
> > > > > > On Tue, 1 Dec 2020, Prathamesh Kulkarni wrote:
> > > > > >
> > > > > > > Hi,
> > > > > > > For the test mentioned in PR, I was trying to see if we could do
> > > > > > > specialized expansion for vcond in target when operands are -1
> > > > > > > and 0.
> > > > > > > arm_expand_vcond gets the following operands:
> > > > > > > (reg:V8QI 113 [ _2 ])
> > > > > > > (reg:V8QI 117)
> > > > > > > (reg:V8QI 118)
> > > > > > > (lt (reg/v:V8QI 115 [ a ])
> > > > > > > (reg/v:V8QI 116 [ b ]))
> > > > > > > (reg/v:V8QI 115 [ a ])
> > > > > > > (reg/v:V8QI 116 [ b ])
> > > > > > >
> > > > > > > where r117 and r118 are set to vector constants -1 and 0
> > > > > > > respectively.
> > > > > > > However, I am not sure if there's a way to check if the register
> > > > > > > is
> > > > > > > constant during expansion time (since we don't have df analysis
> > > > > > > yet) ?
> > > > > > >
> > > > > > > Alternatively, should we add a target hook that returns true if
> > > > > > > the
> > > > > > > result of vector comparison is set to all-ones or all-zeros, and
> > > > > > > then
> > > > > > > use this hook in gimple ISEL to effectively turn VEC_COND_EXPR
> > > > > > > into nop ?
> > > > > >
> > > > > > Would everything match-up for a .VEC_CMP IFN producing a non-mask
> > > > > > vector type? ISEL could special case the a ? -1 : 0 case this way.
> > > > > I think the vec_cmp pattern matches but it produces a masked vector
> > > > > type.
> > > > > In the attached patch, I simply replaced:
> > > > > _1 = a < b
> > > > > x = _1 ? -1 : 0
> > > > > with
> > > > > x = view_convert_expr<_1>
> > > > >
> > > > > For the test-case, isel generates:
> > > > > vector(8) _1;
> > > > > vector(8) signed char _2;
> > > > > uint8x8_t _5;
> > > > >
> > > > >[local count: 1073741824]:
> > > > > _1 = a_3(D) < b_4(D);
> > > > > _2 = VIEW_CONVERT_EXPR(_1);
> > > > > _5 = VIEW_CONVERT_EXPR(_2);
> > > > > return _5;
> > > > >
> > > > > and results in desired code-gen:
> > > > > f1:
> > > > > vcgt.s8 d0, d1, d0
> > > > > bx lr
> > > > >
> > > > > Altho I guess, we should remove the redundant conversions during isel
> > > > > itself ?
> > > > > and result in:
> > > > > _1 = a_3(D) < b_4(D)
> > > > > _5 = VIEW_CONVERT_EXPR(_1)
> > > > >
> > > > > (Patch is lightly tested with only vect.exp)
> > > >
> > > > + /* For targets where result of comparison is all-ones or all-zeros,
> > > > + a < b ? -1 : 0 can be reduced to a < b. */
> > > > +
> > > > + if (integer_minus_onep (op1) && integer_zerop (op2))
> > > > +{
> > > >
> > > > So this really belongs here:
> > > >
> > > > tree op0_type = TREE_TYPE (op0);
> > > > tree op0a_type = TREE_TYPE (op0a);
> > > >
> > > > <---
> > > >
> > > > if (used_vec_cond_exprs >= 2
> > > > && (get_vcond_mask_icode (mode, TYPE_MODE (op0_type))
> > > > != CODE_FOR_nothing)
> > > > && expand_vec_cmp_expr_p (op0a_type, op0_type, tcode))
> > > > {
> > > >
> > > >
> > > > + gassign *def_stmt = dyn_cast (SSA_NAME_DEF_STMT
> > > > (op0));
> > > > + tree op0a = gimple_assign_rhs1 (def_stmt);
> > > > + tree op0_type = TREE_TYPE (op0);
> > > > + tree op0a_type = TREE_TYPE (op0a);
> > > > + enum tree_code tcode = gimple_assign_rhs_code (def_stmt);
> > > > +
> > > > + if (expand_vec_cmp_expr_p (op0a_type, op0_type, tcode))
> > > > + {
> > > > + tree conv_op = build1 (VIEW_CONVERT_EXPR, TREE_TYPE (lhs),
> > > > op0);
> > > > + gassign *new_stmt = gimple_build_assign (lhs, conv_op);
> > > > + gsi_replace (gsi, new_stmt, true);
> > > >
> > > > and you need to verify that the mode of the lhs and the mode of op0
> > > > agree and that the target can actually expand_vec_cmp_expr_p
> > > Thanks for the suggestions, does the attached patch look OK ?
> > > Sorry, I am not sure how to check if target can actually expand vec_cmp ?
> > > I assume that since expand_vec_cmp_expr_p queries optab and if it gets
> > > a valid cmp icode, that
> > > should be sufficient ?
> >
> > Yes
> Hi Richard,
> I tested the patch, and it shows one regression for pr78102.c, because
> of extra pcmpeqq in code-gen for x != y on x86.
> For the test-case:
> __v2di
> baz (const __v2di x, const __v2di y)
> {
> return x != y;
> }
>
> Before patch:
> baz:
> pcmpeqq %xmm1, %xmm0
> pcmpeqd %xmm1, %xmm1
> pandn %xmm1, %xmm0
> ret
>
> After patch,
> Before ISEL:
> vector(2) _1;
> __v2di _4;
>
>[local count: 1073741824]:
> _1 = x_2(D) != y_3(D);
> _4 =
