abi_tag questions

[Stephan Bergmann]

I have two questions regarding the abi_tag attribute (as documented at 
):



1  "The attribute can also be applied to an inline namespace, but does 
not affect the mangled name of the namespace; in this case it is only 
used for -Wabi-tag warnings and automatic tagging of functions and 
variables."


I would naively assume that the "automatic tagging" part means that with


inline namespace n __attribute__((__abi_tag__("t"))) { void f() {} }


n::f would be tagged, but that appears not to be the case?


2  "The argument can be a list of strings of arbitrary length."

Does that mean the list can be empty?


void f() __attribute__((__abi_tag__()));


fails with "error: wrong number of arguments specified for ‘__abi_tag__’ 
attribute" while



inline namespace n __attribute__((__abi_tag__())) {}


is accepted by recent trunk GCC (as well as older versions).

(I stumbled across the latter on Fedora 23, where libstdc++'s 
 "Fix 
abi_tag in special modes" is not yet fixed, so it contains such an empty 
abi_tag on an inline namespace, and Clang with patch 
 "add gcc abi_tag support" produces an 
error.)

Re: abi_tag questions

[Jonathan Wakely]

On 4 November 2015 at 14:37, Stephan Bergmann  wrote:
> I have two questions regarding the abi_tag attribute (as documented at
> ):
>
>
> 1  "The attribute can also be applied to an inline namespace, but does not
> affect the mangled name of the namespace; in this case it is only used for
> -Wabi-tag warnings and automatic tagging of functions and variables."
>
> I would naively assume that the "automatic tagging" part means that with
>
>> inline namespace n __attribute__((__abi_tag__("t"))) { void f() {} }
>
>
> n::f would be tagged, but that appears not to be the case?

It's not tagged, because the tagged namespace "n" is already part of
the mangled name.

> 2  "The argument can be a list of strings of arbitrary length."
>
> Does that mean the list can be empty?
>
>> void f() __attribute__((__abi_tag__()));
>
>
> fails with "error: wrong number of arguments specified for ‘__abi_tag__’
> attribute" while
>
>> inline namespace n __attribute__((__abi_tag__())) {}
>
>
> is accepted by recent trunk GCC (as well as older versions).

That seems like a bug.

> (I stumbled across the latter on Fedora 23, where libstdc++'s
>  "Fix abi_tag
> in special modes" is not yet fixed, so it contains such an empty abi_tag on
> an inline namespace, and Clang with patch 
> "add gcc abi_tag support" produces an error.)

Re: abi_tag questions

[Jonathan Wakely]

On 4 November 2015 at 17:18, Jonathan Wakely  wrote:
> On 4 November 2015 at 14:37, Stephan Bergmann  wrote:
>> I have two questions regarding the abi_tag attribute (as documented at
>> ):
>>
>>
>> 1  "The attribute can also be applied to an inline namespace, but does not
>> affect the mangled name of the namespace; in this case it is only used for
>> -Wabi-tag warnings and automatic tagging of functions and variables."
>>
>> I would naively assume that the "automatic tagging" part means that with
>>
>>> inline namespace n __attribute__((__abi_tag__("t"))) { void f() {} }
>>
>>
>> n::f would be tagged, but that appears not to be the case?
>
> It's not tagged, because the tagged namespace "n" is already part of
> the mangled name.

Oops, I meant to add that automatic tagging happens in cases like:

inline namespace n __attribute__((__abi_tag__("t"))) { struct X { }; }

X f();

Here ::f will be tagged, because its return type is a type defined in
a tagged namespace.

Re: abi_tag questions

[Stephan Bergmann]

On 11/04/2015 12:50 PM, Jonathan Wakely wrote:

On 4 November 2015 at 17:18, Jonathan Wakely  wrote:

On 4 November 2015 at 14:37, Stephan Bergmann  wrote:

I have two questions regarding the abi_tag attribute (as documented at
):


1  "The attribute can also be applied to an inline namespace, but does not
affect the mangled name of the namespace; in this case it is only used for
-Wabi-tag warnings and automatic tagging of functions and variables."

I would naively assume that the "automatic tagging" part means that with


inline namespace n __attribute__((__abi_tag__("t"))) { void f() {} }



n::f would be tagged, but that appears not to be the case?


It's not tagged, because the tagged namespace "n" is already part of
the mangled name.


Oops, I meant to add that automatic tagging happens in cases like:

inline namespace n __attribute__((__abi_tag__("t"))) { struct X { }; }

X f();

Here ::f will be tagged, because its return type is a type defined in
a tagged namespace.


Thanks, got it.

Re: [RFC PR43721] Optimize a/b and a%b to single divmod call

[Richard Biener]

On Wed, 4 Nov 2015, Prathamesh Kulkarni wrote:

> On 2 November 2015 at 18:31, Richard Biener  wrote:
> > On Mon, 2 Nov 2015, Prathamesh Kulkarni wrote:
> >
> >> On 2 November 2015 at 13:20, Prathamesh Kulkarni
> >>  wrote:
> >> > On 30 October 2015 at 15:57, Richard Biener  
> >> > wrote:
> >> >> On Fri, Oct 30, 2015 at 8:39 AM, Prathamesh Kulkarni
> >> >>  wrote:
> >> >>> Hi,
> >> >>> I have attached revamped version of Kugan's patch
> >> >>> (https://gcc.gnu.org/ml/gcc/2013-06/msg00100.html) for PR43721.
> >> >>> Test-case: http://pastebin.com/QMfpXLD9
> >> >>> divmod pass dump: http://pastebin.com/yMY1ikCp
> >> >>> Assembly: http://pastebin.com/kk2HZpvA
> >> >>>
> >> >>> The approach I took is similar to sincos pass, which involves two 
> >> >>> parts:
> >> >>> a) divmod pass that transforms:
> >> >>> t1 = a / b;
> >> >>> t2 = a % b;
> >> >>> to the following sequence:
> >> >>> complex_tmp = DIVMOD (a, b);
> >> >>> t1 = REALPART_EXPR(a);
> >> >>> t2 = IMAGPART_EXPR(b);
> >> >>>
> >> >>> b) DIVMOD(a, b) is represented as an internal-fn and is expanded by
> >> >>> expand_DIVMOD().
> >> >>> I am not sure if I have done this correctly. I was somehow looking to
> >> >>> reuse expand_divmod() but am not able to figure out how to do that
> >> >>> (AFAIU expand_divmod() strictly returns either the quotient or
> >> >>> remainder but never both which is what I want), so ended up with
> >> >>> manually expanding to rtx.
> >> >>>
> >> >>> While going through the sincos pass in execute_cse_sincos_1, I didn't
> >> >>> understand the following:
> >> >>>  if (gimple_purge_dead_eh_edges (gimple_bb (stmt)))
> >> >>>   cfg_changed = true;
> >> >>> Um why is the call to gimple_purge_dead_eh_edges necessary here?
> >> >>
> >> >> The call replacement might no longer throw.
> >> >>
> >> >>> A silly question, what options to pass to gcc to print statistics ? I
> >> >>> added statistics_counter_event to keep track of number of calls
> >> >>> inserted/used but not sure how to print them :/
> >> >>
> >> >> -fdump-tree-XXX-stats or -fdump-statistics-stats
> >> > Thanks, I can see it now -;)
> >> >>
> >> >>> I would be grateful for suggestions for improving the patch.
> >> >>
> >> >> First of all new functions need comments (expand_DIVMOD).
> >> >>
> >> >> Second - what's the reasoning for the pass placement seen?  I think
> >> >> the transform is a lowering one, improving RTL expansion.  The
> >> >> DIVMOD representation is harmful for GIMPLE optimizers.
> >> >>
> >> >> Third - I'd have integrated this with an existing pass - we have another
> >> >> lowering / RTL expansion kind pass which is pass_optimize_widening_mul.
> >> >> Please piggy-back on it.
> >> >>
> >> >> You seem to do the transform unconditionally even if the target has
> >> >> instructions for division and modulus but no instruction for divmod
> >> >> in which case you'll end up emitting a library call in the end instead
> >> >> of a div and mod instruction.  I think the transform should be gated on
> >> >> missing div/mod instructions or the availability of a divmod one.
> >> >>
> >> >> + if (is_gimple_assign (stmt)
> >> >> + && TREE_CODE_CLASS (gimple_assign_rhs_code (stmt)) == 
> >> >> tcc_binary)
> >> >> +   {
> >> >> + if (gimple_assign_rhs_code (stmt) == TRUNC_DIV_EXPR)
> >> >> +   cfg_changed |= execute_divmod_1 (stmt);
> >> >>
> >> >> you can directly check gimple_assign_rhs_code.  I'd check for 
> >> >> TRUNC_MOD_EXPR
> >> >> which seems to be less common and thus should cut down compile-time.
> >> >>
> >> >> +  /* Case 2: When both are in top_bb */
> >> >> +  else if (op1_def_in_bb && op2_def_in_bb)
> >> >> +{
> >> >> +  /* FIXME: better way to compare iterators?.  */
> >> >> +  gimple_stmt_iterator gsi = get_later_stmt (top_bb,
> >> >> def_stmt_op1, def_stmt_op2);
> >> >>
> >> >> You can't use get_later_stmt, it's a vectorizer speciality.  To do
> >> >> this test efficiently
> >> >> you need stmt UIDs computed.
> >> >>
> >> >> I miss a testcase (or two).
> >> > I have tried to address your comments in the attached patch.
> >> oops, unsigned uid_no = 0; should be outside the loop in
> >> pass_optimize_widening_mul::execute.
> >> Done in this version of the patch.
> >>
> >> Thanks,
> >> Prathamesh
> >> > Could you please review it for me ?
> >
> > For the testcases you need a new target check for divmod.
> Sorry I didn't understand.
> Should I add sth similar to /* {  dg-require-effective-target divmod } */ ?

Yes.

> >
> >> > I have a few questions:
> >> >
> >> > a) Is the check for availability of divmod correct ?
> >
> > You simply want optab_handler (tab, mode) != CODE_FOR_nothing
> >
> > The libfunc is always available.
> Um I am probably missing something, I thought libfuncs are initialized
> by init_optabs()
> but the target can override/delete that with the target hook
> targetm.init_libfuncs () ?
> On AArch64 optab_libfunc (sdivmod_optab, SImode) returned NULL_RTX.

Hum, I se

gcc-4.9-20151104 is now available

[gccadmin]

Snapshot gcc-4.9-20151104 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.9-20151104/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.9 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_9-branch 
revision 229787

You'll find:

 gcc-4.9-20151104.tar.bz2 Complete GCC

  MD5=a49019ce23c79f0f097636340ee6c455
  SHA1=751ddf37ff1656cc9de442c1127a8b56089d671e

Diffs from 4.9-20151028 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.9
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.

GCC XML diagnostics

[Mikhail Maltsev]

Hi all!

I'm pleased to say that two students of Lomonosov Moscow State University, Yuri
Kemaev and Pavel Adamenko decided to work on a project related to GCC and
hopefully will become new contributors.

I'll be assisting them with this project. We have chosen to work on PR19165:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19165 (machine-readable diagnostics
output). Could any of maintainers please confirm that it is still a desired
feature (the PR is marked as NEW, but just in case...)?

We are aware of GCC development schedule and thus aiming at GCC 7. Also we have
seen David's series of patches related to diagnostics and will probably work on
top of them, i.e. with those patches applied (because most of them are already
approved).

I created several test cases which exhibit various entities (such as locations
in files, includes, macro expansions, notes, etc.), which can occur in GCC
diagnostics (which are worth keeping in mind when designing the XML diagnostics
format):

https://github.com/miyuki-chan/gcc-xml-diagn/tree/master/examples

Any advices about other test cases which are worth taking into account and the
format itself?

-- 
Regards,
Mikhail Maltsev