Re: [EXT] Re: Can LTO minor version be updated in backward compatible way ?

2019-07-19 Thread Florian Weimer 
* Romain Geissler:

> That may fly in the open source world, however I expect some vendors
> shipping proprietary code might be fine with assembly/LTO
> representation of their product, but not source.

They can't ship LTO today anyway due to the format incompatibility, so
that's not really an argument against source-based LTO.

Thanks,
Florian

Boost testcase failure

2019-07-19 Thread navya deepika Garakapati 
Hi Devs,
consider below reduced testcase from boost lamda.
$cat result_of_tests.cpp
#include 
#include 
template typename boost::result_of::type apply1(F
f, A b) {
return f(b);
}
using namespace boost::lambda;
int main(int, char *[]) {
int one = 1;
int d= (apply1(_1 ,one) == 1);
printf("\n%d\n",d);
return 0;
}
when compiled with optimization O2
$g++ result_of_tests.cpp  -I ./boost_1_70_0 -O2
$./a.out
0

And,when we compile same testcase with O0
$g++ result_of_tests.cpp  -I ./boost_1_70_0 -O0
$./a.out
1

The above testcases is demonstrated with g++ compiler but behavior is same
on clang as well.
When we replace ,
  int d= (apply1(_1 ,one) == 1);
 with
  int d= (apply1(_1 ,one) == 1);

testcase gives correct result with or without optimization.

Wanted to confirm here,is it valid testcase or compiler optimization is
screwed up?

Thanks,
Navya

[RFC] Disabling ICF for interrupt functions

2019-07-19 Thread Jozef Lawrynowicz 
For MSP430, the folding of identical functions marked with the "interrupt"
attribute by -fipa-icf-functions results in wrong code being generated.
Interrupts have different calling conventions than regular functions, so
inserting a CALL from one identical interrupt to another is not correct and
will result in stack corruption.

I imagine there are other targets that also have different calling conventions
for interrupt functions compared to regular functions, and so folding them
would be undesirable.

Therefore, I would appreciate some feedback as to whether it would be welcomed
to fix this in a generic way or if I should just keep it MSP430 specific.

1. MSP430 specific
Add the "no_icf" attribute to functions marked with the "interrupt" attribute
when processing them in the backend.

2. Target Hook
Add a DEFHOOKPOD (e.g. TARGET_NO_INTERRUPT_ICF) which controls whether ICF is
disabled for functions with the interrupt attribute (in gcc/ipa-icf.c, where
"no_icf" attribute is processed).

3. Always on
Same as 2. but without the hook implementation - just check for the interrupt
attribute and disable ICF if it is present.

I'm personally leaning towards option 2, target hook, since other targets may
benefit from this.

Thanks,
Jozef

Re: [RFC] Disabling ICF for interrupt functions

2019-07-19 Thread Alexander Monakov 
On Fri, 19 Jul 2019, Jozef Lawrynowicz wrote:

> For MSP430, the folding of identical functions marked with the "interrupt"
> attribute by -fipa-icf-functions results in wrong code being generated.
> Interrupts have different calling conventions than regular functions, so
> inserting a CALL from one identical interrupt to another is not correct and
> will result in stack corruption.

But ICF by creating an alias would be fine, correct?  As I understand, the
real issue here is that gcc does not know how to correctly emit a call to
"interrupt" functions (because they have unusual ABI and exist basically to
have their address stored somewhere).

So I think the solution shouldn't be in disabling ICF altogether, but rather
in adding a way to recognize that a function has quasi-unknown ABI and thus
not directly callable (so any other optimization can see that it may not emit
a call to this function), then teaching ICF to check that when deciding to
fold by creating a wrapper.

(would it be possible to tell ICF that addresses of interrupt functions are
not significant so it can fold them by creating aliases?)

Alexander

gcc-8-20190719 is now available

2019-07-19 Thread gccadmin 
Snapshot gcc-8-20190719 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/8-20190719/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 8 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-8-branch 
revision 273610

You'll find:

 gcc-8-20190719.tar.xzComplete GCC

  SHA256=a8118dcc3e85f9bf83f83d5f5203bf8ddad29bfd419fd34cdc2bea7c0c29ad7c
  SHA1=e70b604f5da73f4fe75530c33564fd60bd02b1c9

Diffs from 8-20190712 are available in the diffs/ subdirectory.

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

Renaming vec_step in tree-vect-loop.c (to fix build on powerpc/clang)

2019-07-19 Thread Gerald Pfeifer 
I have seen an increasing number of reports of GCC failing to
build with clang on powerpc (on FreeBSD, though that's probably
immaterial).

Turns out that clang has vec_step as a reserved word on powerpc
with AltiVec.

We OTOH use vec_step s as a variable name in gcc/tree-vect-loop.c.


The best approach I can see is to rename vec_step.  Before I prepare
a patch: what alternate name/spelling would you prefer?

Thanks,
Gerald