Re: [PATCH] Multiversioning fixes (PR c++/55742, take 2)

2013-02-13 Thread Sriraman Tallam
On Wed, Feb 13, 2013 at 12:14 PM, Jakub Jelinek wrote: > On Wed, Feb 13, 2013 at 10:57:42AM -0800, Sriraman Tallam wrote: >> I committed a trivial patch to fix this problem. mv12-aux.C is >> auxiliary to mv12.C and should have the same test directives as >> mv12.C. >> >> 2013-02-13 Sriraman Talla

Re: [PATCH] Multiversioning fixes (PR c++/55742, take 2)

2013-02-13 Thread Jakub Jelinek
On Wed, Feb 13, 2013 at 10:57:42AM -0800, Sriraman Tallam wrote: > I committed a trivial patch to fix this problem. mv12-aux.C is > auxiliary to mv12.C and should have the same test directives as > mv12.C. > > 2013-02-13 Sriraman Tallam > > * g++.dg/ext/mv12-aux.C: Add directives to ma

Re: [PATCH] Multiversioning fixes (PR c++/55742, take 2)

2013-02-13 Thread Sriraman Tallam
On Wed, Feb 13, 2013 at 7:46 AM, Sriraman Tallam wrote: > > On Feb 13, 2013 1:21 AM, "Andreas Schwab" wrote: >> >> Sriraman Tallam writes: >> >> > Index: gcc/testsuite/g++.dg/ext/mv12-aux.C >> > === >> > --- gcc/testsuite/g++.dg/ext

Re: [PATCH] Multiversioning fixes (PR c++/55742, take 2)

2013-02-13 Thread Andreas Schwab
Sriraman Tallam writes: > Index: gcc/testsuite/g++.dg/ext/mv12-aux.C > === > --- gcc/testsuite/g++.dg/ext/mv12-aux.C (revision 0) > +++ gcc/testsuite/g++.dg/ext/mv12-aux.C (revision 0) > @@ -0,0 +1,11 @@ > +// Test case t

Re: [PATCH] Multiversioning fixes (PR c++/55742, take 2)

2013-02-11 Thread Jason Merrill
OK, thanks. Jason

Re: [PATCH] Multiversioning fixes (PR c++/55742, take 2)

2013-02-11 Thread Sriraman Tallam
Hi, Is this alright to commit? Thanks Sri On Thu, Feb 7, 2013 at 4:10 PM, Sriraman Tallam wrote: > On Thu, Feb 7, 2013 at 6:29 AM, Jason Merrill wrote: >> On 02/06/2013 08:39 PM, Sriraman Tallam wrote: >>> >>> +// Test to check if an error is generated when virtual functions >>> +// are mult

Re: [PATCH] Multiversioning fixes (PR c++/55742, take 2)

2013-02-07 Thread Sriraman Tallam
On Thu, Feb 7, 2013 at 6:29 AM, Jason Merrill wrote: > On 02/06/2013 08:39 PM, Sriraman Tallam wrote: >> >> +// Test to check if an error is generated when virtual functions >> +// are multiversioned. > > > This seems like a TODO, rather than something to test for. I don't see any > reason why we

Re: [PATCH] Multiversioning fixes (PR c++/55742, take 2)

2013-02-07 Thread Jason Merrill
On 02/06/2013 08:39 PM, Sriraman Tallam wrote: +// Test to check if an error is generated when virtual functions +// are multiversioned. This seems like a TODO, rather than something to test for. I don't see any reason why we couldn't support multiversioned virtual functions. error_at

Re: [PATCH] Multiversioning fixes (PR c++/55742, take 2)

2013-02-06 Thread Sriraman Tallam
Hi, I have attached a patch documenting Function Multiversioning and added a few more tests. I have also updated the wiki http://gcc.gnu.org/wiki/FunctionMultiVersioning. Please let me know if there are any more tests you specifically want. Please review. Thanks Sri On Wed, Jan 30, 2013 at

Re: [PATCH] Multiversioning fixes (PR c++/55742, take 2)

2013-01-30 Thread Jason Merrill
OK. Sriraman, are you working on documentation and more tests? Jason

[PATCH] Multiversioning fixes (PR c++/55742, take 2)

2013-01-21 Thread Jakub Jelinek
On Sat, Jan 19, 2013 at 11:19:04AM -0500, Jason Merrill wrote: > On 01/18/2013 03:22 PM, Jakub Jelinek wrote: > >else if (TREE_CODE (args) != STRING_CST) > >-gcc_unreachable (); > >+{ > >+ error ("invalid % attribute value"); > >+ return false; > >+} > > Maybe say that it

Re: [PATCH] Multiversioning fixes (PR c++/55742)

2013-01-19 Thread Jason Merrill
On 01/18/2013 03:22 PM, Jakub Jelinek wrote: else if (TREE_CODE (args) != STRING_CST) -gcc_unreachable (); +{ + error ("invalid % attribute value"); + return false; +} Maybe say that it needs to be a string? We also need more tests, both for the example in the PR (and

[PATCH] Multiversioning fixes (PR c++/55742)

2013-01-18 Thread Jakub Jelinek
Hi! As discussed in the PR, this patch attempts to change multiversioning so that backwards compatibility with the previous target attribute behavior is preserved. In particular, e.g. for void foo () __attribute__((target ("avx"))); void foo () { } the foo definition was just merged with the pre