On Tue, Nov 13, 2012 at 1:57 PM, Sriraman Tallam wrote:
> Patch committed now after making the changes.
>
Your libgcc change caused:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55370
--
H.J.
Patch committed now after making the changes.
Thanks,
-Sri.
On Mon, Nov 12, 2012 at 6:39 PM, Jason Merrill wrote:
> On 11/12/2012 08:11 PM, Sriraman Tallam wrote:
>>
>> + && !targetm.target_option.function_versions (fn,
>> +TREE_PURPOSE (match)))
>
>
> The second argume
On 11/12/2012 08:11 PM, Sriraman Tallam wrote:
+ && !targetm.target_option.function_versions (fn,
+TREE_PURPOSE (match)))
The second argument should be lined up with the left paren if it's on a
different line. Perhaps formatting this as
&& !(targetm.target_option.f
Hi Jason,
Made the changes. Also fixed one more segfault bug when ifunc is
not supported.
Thanks,
-Sri.
On Sun, Nov 11, 2012 at 9:04 PM, Jason Merrill wrote:
> On 11/09/2012 08:33 PM, Sriraman Tallam wrote:
>>
>> + /* Skip calling decls_match for versioned functions. */
>> +
On 11/09/2012 08:33 PM, Sriraman Tallam wrote:
+ /* Skip calling decls_match for versioned functions. */
+ if (DECL_FUNCTION_VERSIONED (fn)
+ && DECL_FUNCTION_VERSIONED (TREE_PURPOSE (match)))
+ continue;
+ if (!decls_match (fn, TREE_PURPOSE (match)
Hi Jason,
Made all the changes and attached patch. Ok to commit?
Thanks,
-Sri.
On Tue, Nov 6, 2012 at 7:52 AM, Jason Merrill wrote:
> On 11/05/2012 09:38 PM, Sriraman Tallam wrote:
>>
>> + /* For multi-versioned functions, more than one match is just fine.
>>
>> +Call decls_matc
> This should be fixed by a patch I committed directly before you
> sent your mail (which is why you did not see it yet). Can you
> please verify?
Bootstrap has completed at revision 193278 (with the patch for
dwarf2out.c.
Thanks,
Dominique
On Tue, 6 Nov 2012, Dominique Dhumieres wrote:
> /opt/gcc/build_a/./prev-gcc/g++ -B/opt/gcc/build_a/./prev-gcc/
> -B/opt/gcc/gcc4.8a/x86_64-apple-darwin10.8.0/bin/ -nostdinc++
> -B/opt/gcc/build_a/prev-x86_64-apple-darwin10.8.0/libstdc++-v3/src/.libs
> -B/opt/gcc/build_a/prev-x86_64-apple-darwin
> I have now committed the attached patch.
This (r193204) breaks bootstrap on x86_64-apple-darwin10:
...
/opt/gcc/build_a/./prev-gcc/g++ -B/opt/gcc/build_a/./prev-gcc/
-B/opt/gcc/gcc4.8a/x86_64-apple-darwin10.8.0/bin/ -nostdinc++
-B/opt/gcc/build_a/prev-x86_64-apple-darwin10.8.0/libstdc++-v3/sr
On Mon, 5 Nov 2012, Sriraman Tallam wrote:
>I have now committed the attached patch.
...and broke bootstrap on *-unknown-freebsd* and other targets
that way:
/scratch2/tmp/gerald/gcc-HEAD/gcc/config/i386/i386.c:28820:1: error:
'tree_node* make_dispatcher_decl(tree)' defined but not use
On Tue, Nov 6, 2012 at 7:52 AM, Jason Merrill wrote:
> On 11/05/2012 09:38 PM, Sriraman Tallam wrote:
>>
>> + /* For multi-versioned functions, more than one match is just fine.
>>
>> +Call decls_match to make sure they are different because they are
>> +versioned. */
>> +
On 11/05/2012 09:38 PM, Sriraman Tallam wrote:
+ /* For multi-versioned functions, more than one match is just fine.
+Call decls_match to make sure they are different because they are
+versioned. */
+ if (DECL_FUNCTION_VERSIONED (fn))
+ {
+ for (match = T
On 10/30/2012 05:49 PM, Sriraman Tallam wrote:
AFAIU, this should not be a problem. For duplicate declarations,
duplicate_decls should merge them and they should never be seen here.
Did I miss something?
With extern "C" functions you can have multiple declarations of the same
function in diffe
On Tue, Oct 30, 2012 at 12:10 PM, Jason Merrill wrote:
> On 10/27/2012 09:16 PM, Sriraman Tallam wrote:
>>
>> + /* See if there's a match. For functions that are
>> multi-versioned,
>> +all the versions match. */
>> if (same_type_p (target_fn_type, static_fn_type (
On 10/27/2012 09:16 PM, Sriraman Tallam wrote:
+ /* See if there's a match. For functions that are multi-versioned,
+all the versions match. */
if (same_type_p (target_fn_type, static_fn_type (fn)))
- matches = tree_cons (fn, NULL_TREE, matches);
+
On Mon, Oct 29, 2012 at 5:55 AM, Jan Hubicka wrote:
>> Index: gcc/cgraph.c
>> ===
>> --- gcc/cgraph.c (revision 192623)
>> +++ gcc/cgraph.c (working copy)
>> @@ -132,6 +132,74 @@ static GTY(()) struct cgraph_edge *free_edges
> Index: gcc/cgraph.c
> ===
> --- gcc/cgraph.c (revision 192623)
> +++ gcc/cgraph.c (working copy)
> @@ -132,6 +132,74 @@ static GTY(()) struct cgraph_edge *free_edges;
> /* Did procss_same_body_aliases run? */
> bool same
On Fri, Oct 26, 2012 at 9:07 AM, Xinliang David Li wrote:
> On Fri, Oct 26, 2012 at 8:54 AM, Jan Hubicka wrote:
>> Hi,
>> sorry for jumping in late, for too long I did not had chnce to look at my
>> TODO.
>> I have two comments...
>>> Index: gcc/cgraphbuild.c
>>>
On Fri, Oct 26, 2012 at 8:54 AM, Jan Hubicka wrote:
> Hi,
> sorry for jumping in late, for too long I did not had chnce to look at my
> TODO.
> I have two comments...
>> Index: gcc/cgraphbuild.c
>> ===
>> --- gcc/cgraphbuild.c (revis
Hi,
sorry for jumping in late, for too long I did not had chnce to look at my TODO.
I have two comments...
> Index: gcc/cgraphbuild.c
> ===
> --- gcc/cgraphbuild.c (revision 192623)
> +++ gcc/cgraphbuild.c (working copy)
> @@ -34,6 +34
On Fri, Oct 19, 2012 at 10:33 PM, Sriraman Tallam
wrote:
Yes, the support is only for C++ for now. "target" attribute is not
new and if the user tries to use this with 'C' then a duplicate
defintion error would occur just like now.
I have plans to implement this for C too.
Would it be hard t
On 2012-10-12 18:19 , Sriraman Tallam wrote:
When the front-end sees more than one decl for "foo", it calls a target hook to
determine if they are versions. To prevent duplicate definition errors with
other
versions of "foo", "decls_match" function in cp/decl.c is made to return false
when 2
On Fri, Oct 5, 2012 at 3:50 PM, Jason Merrill wrote:
> On 10/05/2012 05:57 PM, Sriraman Tallam wrote:
>>
>> In general, the dispatcher is always necessary since it is not known
>> what function version will be called at compile time. This is true
>> whether it is a direct or an indirect call.
>
>
On 10/05/2012 05:57 PM, Sriraman Tallam wrote:
In general, the dispatcher is always necessary since it is not known
what function version will be called at compile time. This is true
whether it is a direct or an indirect call.
So you want to compile with lowest common denominator flags and then
On Fri, Oct 5, 2012 at 10:43 AM, Jason Merrill wrote:
> On 08/24/2012 08:34 PM, Sriraman Tallam wrote:
>>
>> + /* If the address of a multiversioned function dispatcher is taken,
>> + generate the body to dispatch the right function at run-time. This
>>
>> + is needed as the address can
On 08/24/2012 08:34 PM, Sriraman Tallam wrote:
+ /* For function versions, their parms and types match
+but they are not duplicates. Record function versions
+as and when they are found. */
+ if (TREE_CODE (fn) == FUNCTION_DECL
+ && TREE_CODE
On 10/05/2012 01:43 PM, Jason Merrill wrote:
On 08/24/2012 08:34 PM, Sriraman Tallam wrote:
+ /* If the address of a multiversioned function dispatcher is taken,
+ generate the body to dispatch the right function at run-time. This
+ is needed as the address can be used to do an indirec
On 08/24/2012 08:34 PM, Sriraman Tallam wrote:
+ /* If the address of a multiversioned function dispatcher is taken,
+ generate the body to dispatch the right function at run-time. This
+ is needed as the address can be used to do an indirect call. */
It seems to me that you don't ne
Hi Jason, Sri has addressed the comments you had on FE part. Can you
take a look if it is ok? Stage-1 is going to be closed soon, and we
hope to get this major feature in 4.8.
thanks,
David
On Tue, Sep 18, 2012 at 9:29 AM, Sriraman Tallam wrote:
> Ping.
>
> On Fri, Aug 24, 2012 at 5:34 PM,
Ping.
On Fri, Aug 24, 2012 at 5:34 PM, Sriraman Tallam wrote:
> Hi Jason,
>
>I have created a new patch to use target hooks for all the
> functionality and make the front-end just call the target hooks at the
> appropriate places. This is more like what you suggested in a previous
> mail. In
On Thu, Jul 19, 2012 at 1:39 PM, Jason Merrill wrote:
>
> On 07/10/2012 03:14 PM, Sriraman Tallam wrote:
>>
>> I am using the questions you asked previously
>> to explain how I solved each of them. When working on this patch, these
>> are the exact questions I had and tried to address it.
>>
>> *
On 07/10/2012 03:14 PM, Sriraman Tallam wrote:
I am using the questions you asked previously
to explain how I solved each of them. When working on this patch, these
are the exact questions I had and tried to address it.
* Does this attribute affect a function signature?
The function signature s
On Tue, Jul 10, 2012 at 2:46 AM, Jason Merrill wrote:
> On 07/09/2012 11:27 PM, Xinliang David Li wrote:
>>
>> Ok. Do you have specific comments on the patch?
>
>
> My comment is "Perhaps we want to implement this using a more generic
> mechanism." I was thinking to defer a detailed code review
On 07/09/2012 11:27 PM, Xinliang David Li wrote:
Ok. Do you have specific comments on the patch?
My comment is "Perhaps we want to implement this using a more generic
mechanism." I was thinking to defer a detailed code review until that
question is settled.
Jason
Ok. Do you have specific comments on the patch?
thanks,
David
On Sun, Jul 8, 2012 at 4:20 AM, Jason Merrill wrote:
> On 07/07/2012 08:38 PM, Xinliang David Li wrote:
>>>
>>> It seems to me that what you have here are target-specific attributes
>>> that
>>> affect the signature of a function su
On 07/07/2012 08:38 PM, Xinliang David Li wrote:
It seems to me that what you have here are target-specific attributes that
affect the signature of a function such that they make two declarations
different that would otherwise declare the same function. Stepping away from
the specific notion of v
On Fri, Jul 6, 2012 at 11:05 PM, Jason Merrill wrote:
> On 06/14/2012 04:13 PM, Sriraman Tallam wrote:
>>
>> C++ Frontend maintainers, Could you please take a look at the
>> front-end part when you find the time?
>
>
> It seems to me that what you have here are target-specific attributes that
On 06/14/2012 04:13 PM, Sriraman Tallam wrote:
C++ Frontend maintainers, Could you please take a look at the
front-end part when you find the time?
It seems to me that what you have here are target-specific attributes
that affect the signature of a function such that they make two
declara
On Fri, Jul 6, 2012 at 2:14 AM, Richard Guenther
wrote:
>
> On Thu, Jun 14, 2012 at 10:13 PM, Sriraman Tallam wrote:
> > +cc c++ front-end maintainers
> >
> > Hi,
> >
> >C++ Frontend maintainers, Could you please take a look at the
> > front-end part when you find the time?
>
> So you have (f
On Thu, Jun 14, 2012 at 10:13 PM, Sriraman Tallam wrote:
> +cc c++ front-end maintainers
>
> Hi,
>
>C++ Frontend maintainers, Could you please take a look at the
> front-end part when you find the time?
So you have (for now?) omitted the C frontend change(s)?
>Honza, your thoughts on the
Ping.
On Thu, Jun 14, 2012 at 1:13 PM, Sriraman Tallam wrote:
> +cc c++ front-end maintainers
>
> Hi,
>
> C++ Frontend maintainers, Could you please take a look at the
> front-end part when you find the time?
>
> Honza, your thoughts on the callgraph part?
>
> Richard, any further comments/
+cc c++ front-end maintainers
Hi,
C++ Frontend maintainers, Could you please take a look at the
front-end part when you find the time?
Honza, your thoughts on the callgraph part?
Richard, any further comments/feedback?
Additionally, I am working on generating better mangled names f
On Mon, Jun 4, 2012 at 3:29 PM, Sriraman Tallam wrote:
> Bug fixed and new patch attached.
>
> Patch also available for review at http://codereview.appspot.com/5752064
>
I think you should also export __cpu_indicator_init in libgcc_s.so.
Also, is this feature C++ only? Can you make it to work fo
On Mon, Jun 4, 2012 at 11:59 AM, Sriraman Tallam wrote:
> Hi,
>
> Attaching updated patch for function multiversioning which brings
> in plenty of changes.
>
> * As suggested by Richard earlier, I have made cgraph aware of
> function versions. All nodes of function versions are chained and the
>
Sriraman Tallam writes:
> Any reason why gcc should not be made to prefer libgcc_s.so too like g++?
It's controlled by the -shared-libgcc and -static-libgcc options.
The -shared-libgcc option is the default for g++ because several years
ago a shared libgcc was required to make exception handlin
On Sat, May 26, 2012 at 7:23 PM, Sriraman Tallam wrote:
>>
>> Ｔhat is because libgcc_s.so is preferred by g++. We can do one
>> of 3 things:
>>
>> 1. Abuse libgcc_eh.a by moving __cpu_model and __cpu_indicator_init
>> from libgcc.a to libgcc_eh.a.
>> 2. Rename libgcc_eh.a to libgcc_static.a and mo
On Sat, May 26, 2012 at 7:06 PM, H.J. Lu wrote:
> On Sat, May 26, 2012 at 5:23 PM, Sriraman Tallam wrote:
>> On Sat, May 26, 2012 at 4:56 PM, H.J. Lu wrote:
>>> On Sat, May 26, 2012 at 3:34 PM, Sriraman Tallam
>>> wrote:
On Fri, May 25, 2012 at 10:05 PM, H.J. Lu wrote:
> On Fri, May
On Sat, May 26, 2012 at 5:23 PM, Sriraman Tallam wrote:
> On Sat, May 26, 2012 at 4:56 PM, H.J. Lu wrote:
>> On Sat, May 26, 2012 at 3:34 PM, Sriraman Tallam wrote:
>>> On Fri, May 25, 2012 at 10:05 PM, H.J. Lu wrote:
On Fri, May 25, 2012 at 8:38 PM, Sriraman Tallam
wrote:
>
>>>
On Sat, May 26, 2012 at 4:56 PM, H.J. Lu wrote:
> On Sat, May 26, 2012 at 3:34 PM, Sriraman Tallam wrote:
>> On Fri, May 25, 2012 at 10:05 PM, H.J. Lu wrote:
>>> On Fri, May 25, 2012 at 8:38 PM, Sriraman Tallam
>>> wrote:
On May 25, 2012 7:15 PM, "H.J. Lu" wrote:
>
>
> O
On Sat, May 26, 2012 at 3:34 PM, Sriraman Tallam wrote:
> On Fri, May 25, 2012 at 10:05 PM, H.J. Lu wrote:
>> On Fri, May 25, 2012 at 8:38 PM, Sriraman Tallam wrote:
>>>
>>> On May 25, 2012 7:15 PM, "H.J. Lu" wrote:
On May 25, 2012 6:54 PM, "Sriraman Tallam" wrote:
>
>
On Fri, May 25, 2012 at 10:05 PM, H.J. Lu wrote:
> On Fri, May 25, 2012 at 8:38 PM, Sriraman Tallam wrote:
>>
>> On May 25, 2012 7:15 PM, "H.J. Lu" wrote:
>>>
>>>
>>> On May 25, 2012 6:54 PM, "Sriraman Tallam" wrote:
>>> >
>>> >
>>> > >>
>>> > >> On Fri, May 25, 2012 at 5:0 > > BTW, I noticed:
On Fri, May 25, 2012 at 8:38 PM, Sriraman Tallam wrote:
>
> On May 25, 2012 7:15 PM, "H.J. Lu" wrote:
>>
>>
>> On May 25, 2012 6:54 PM, "Sriraman Tallam" wrote:
>> >
>> >
>> > >>
>> > >> On Fri, May 25, 2012 at 5:0 > > BTW, I noticed:
>>
>> > >
>> > > [hjl@gnu-6 pr14170]$ readelf -sW libgcc.a |
On Fri, May 25, 2012 at 5:27 PM, H.J. Lu wrote:
> On Fri, May 25, 2012 at 5:16 PM, Sriraman Tallam wrote:
>> Hi H.J.,
>>
>> On Fri, May 25, 2012 at 5:07 PM, H.J. Lu wrote:
>>> On Mon, May 14, 2012 at 11:28 AM, Sriraman Tallam
>>> wrote:
Hi H.J,
Attaching new patch with 2 test
On Fri, May 25, 2012 at 5:16 PM, Sriraman Tallam wrote:
> Hi H.J.,
>
> On Fri, May 25, 2012 at 5:07 PM, H.J. Lu wrote:
>> On Mon, May 14, 2012 at 11:28 AM, Sriraman Tallam
>> wrote:
>>> Hi H.J,
>>>
>>> Attaching new patch with 2 test cases, mv2.C checks ISAs only and
>>> mv1.C checks ISAs and
Hi H.J.,
On Fri, May 25, 2012 at 5:07 PM, H.J. Lu wrote:
> On Mon, May 14, 2012 at 11:28 AM, Sriraman Tallam wrote:
>> Hi H.J,
>>
>> Attaching new patch with 2 test cases, mv2.C checks ISAs only and
>> mv1.C checks ISAs and arches mixed. Right now, checking only arches is
>> not needed as they
On Mon, May 14, 2012 at 11:28 AM, Sriraman Tallam wrote:
> Hi H.J,
>
> Attaching new patch with 2 test cases, mv2.C checks ISAs only and
> mv1.C checks ISAs and arches mixed. Right now, checking only arches is
> not needed as they are mutually exclusive, any order should be fine.
>
> Patch also
On Fri, May 11, 2012 at 7:04 PM, Sriraman Tallam wrote:
> Hi H.J.,
>
> I have updated the patch to improve the dispatching method like we
> discussed. Each feature gets a priority now, and the dispatching is
> done in priority order. Please see i386.c for the changes.
>
> Patch also available fo
On Wed, May 9, 2012 at 12:01 PM, Sriraman Tallam wrote:
> Hi,
>
> Attached new patch with more bug fixes. I will fix the dispatching
> method to use prioirty of attributes in the next iteration.
>
> Patch also available for review here: http://codereview.appspot.com/5752064
>
The patch looks OK
On Wed, May 2, 2012 at 11:04 AM, H.J. Lu wrote:
> On Wed, May 2, 2012 at 10:44 AM, Sriraman Tallam wrote:
>
> 1. Since AVX > SSE4 > SSSE3 > SSE3 > SSE2 > SSE, with
> foo for AVX and SSE3, on AVX processors, which foo will be
> selected?
foo for AVX will get called since
On Wed, May 2, 2012 at 10:44 AM, Sriraman Tallam wrote:
1. Since AVX > SSE4 > SSSE3 > SSE3 > SSE2 > SSE, with
foo for AVX and SSE3, on AVX processors, which foo will be
selected?
>>>
>>> foo for AVX will get called since that appears ahead.
>>>
>>> The dispatching is done in t
On Wed, May 2, 2012 at 9:05 AM, H.J. Lu wrote:
> On Wed, May 2, 2012 at 8:08 AM, Sriraman Tallam wrote:
>> On Wed, May 2, 2012 at 6:42 AM, H.J. Lu wrote:
>>> On Tue, May 1, 2012 at 7:45 PM, Sriraman Tallam wrote:
Hi H.J,
Done now. Patch attached.
Thanks,
-Sri.
>>
On Wed, May 2, 2012 at 8:08 AM, Sriraman Tallam wrote:
> On Wed, May 2, 2012 at 6:42 AM, H.J. Lu wrote:
>> On Tue, May 1, 2012 at 7:45 PM, Sriraman Tallam wrote:
>>> Hi H.J,
>>>
>>> Done now. Patch attached.
>>>
>>> Thanks,
>>> -Sri.
>>>
>>> On Tue, May 1, 2012 at 5:08 PM, H.J. Lu wrote:
On Wed, May 2, 2012 at 6:42 AM, H.J. Lu wrote:
> On Tue, May 1, 2012 at 7:45 PM, Sriraman Tallam wrote:
>> Hi H.J,
>>
>> Done now. Patch attached.
>>
>> Thanks,
>> -Sri.
>>
>> On Tue, May 1, 2012 at 5:08 PM, H.J. Lu wrote:
>>> On Tue, May 1, 2012 at 4:51 PM, Sriraman Tallam wrote:
Hi,
>>
On Tue, May 1, 2012 at 7:45 PM, Sriraman Tallam wrote:
> Hi H.J,
>
> Done now. Patch attached.
>
> Thanks,
> -Sri.
>
> On Tue, May 1, 2012 at 5:08 PM, H.J. Lu wrote:
>> On Tue, May 1, 2012 at 4:51 PM, Sriraman Tallam wrote:
>>> Hi,
>>>
>>> New patch attached, updated test case and fixed bugs r
On Tue, May 1, 2012 at 4:51 PM, Sriraman Tallam wrote:
> Hi,
>
> New patch attached, updated test case and fixed bugs related to
> __PRETTY_FUNCTION_.
>
> Patch also available for review here: http://codereview.appspot.com/5752064
@@ -0,0 +1,39 @@
+/* Simple test case to check if Multiversioning
On Fri, Apr 27, 2012 at 8:36 AM, H.J. Lu wrote:
> On Fri, Apr 27, 2012 at 7:53 AM, Sriraman Tallam wrote:
>> On Fri, Apr 27, 2012 at 7:38 AM, H.J. Lu wrote:
>>> On Fri, Apr 27, 2012 at 7:35 AM, Sriraman Tallam
>>> wrote:
On Fri, Apr 27, 2012 at 6:38 AM, H.J. Lu wrote:
> On Thu, Apr 2
On Fri, Apr 27, 2012 at 7:53 AM, Sriraman Tallam wrote:
> On Fri, Apr 27, 2012 at 7:38 AM, H.J. Lu wrote:
>> On Fri, Apr 27, 2012 at 7:35 AM, Sriraman Tallam wrote:
>>> On Fri, Apr 27, 2012 at 6:38 AM, H.J. Lu wrote:
On Thu, Apr 26, 2012 at 10:08 PM, Sriraman Tallam
wrote:
> Hi,
On Fri, Apr 27, 2012 at 7:38 AM, H.J. Lu wrote:
> On Fri, Apr 27, 2012 at 7:35 AM, Sriraman Tallam wrote:
>> On Fri, Apr 27, 2012 at 6:38 AM, H.J. Lu wrote:
>>> On Thu, Apr 26, 2012 at 10:08 PM, Sriraman Tallam
>>> wrote:
Hi,
I have made the following changes in this new patch
On Fri, Apr 27, 2012 at 7:35 AM, Sriraman Tallam wrote:
> On Fri, Apr 27, 2012 at 6:38 AM, H.J. Lu wrote:
>> On Thu, Apr 26, 2012 at 10:08 PM, Sriraman Tallam
>> wrote:
>>> Hi,
>>>
>>> I have made the following changes in this new patch which is attached:
>>>
>>> * Use target attribute itself
On Fri, Apr 27, 2012 at 6:38 AM, H.J. Lu wrote:
> On Thu, Apr 26, 2012 at 10:08 PM, Sriraman Tallam wrote:
>> Hi,
>>
>> I have made the following changes in this new patch which is attached:
>>
>> * Use target attribute itself to create function versions.
>> * Handle any number of ISA names and
On Thu, Apr 26, 2012 at 10:08 PM, Sriraman Tallam wrote:
> Hi,
>
> I have made the following changes in this new patch which is attached:
>
> * Use target attribute itself to create function versions.
> * Handle any number of ISA names and arch= args to target attribute,
> generating the right
71 matches
Mail list logo
