Hi Jason,
I managed to reproduce this fault now.
and entered a bug tracker for it:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64265
any ideas how this patch could move the __tsan_func_entry into the loop?
Thanks
Bernd.
On Wed, 10 Dec 2014 00:10:07, Bernd Edlinger wrote:
>
> Hi Jason,
>
>>
Hi Jason,
> I ran the tramp3d benchmark over 500 iterations before and after the
change and couldn't see any measurable difference in runtime. The
binary with my
> change was 0.4% smaller.
I'm going to go ahead and check it in; if a performance hit shows up on
the automated testing we can revi
On 11/17/2014 10:27 AM, Richard Biener wrote:
The generated code for g++.dg/torture/pr37922.C is pretty different at -O2,
but it's hard for me to tell whether the changes are good, bad, or neutral.
There is always the possibility of running the C++ portion of SPEC CPU 2006...
I ran the tramp3
On Mon, Nov 17, 2014 at 4:25 PM, Jason Merrill wrote:
> On 11/17/2014 05:26 AM, Richard Biener wrote:
>>
>> Did you inspect generated code for a few testcases?
>
>
> The generated code for g++.dg/torture/pr37922.C is pretty different at -O2,
> but it's hard for me to tell whether the changes are g
On 11/17/2014 05:26 AM, Richard Biener wrote:
Did you inspect generated code for a few testcases?
The generated code for g++.dg/torture/pr37922.C is pretty different at
-O2, but it's hard for me to tell whether the changes are good, bad, or
neutral.
Jason
On Sun, Nov 16, 2014 at 6:04 AM, Jason Merrill wrote:
> I've had a TODO in genericize_cp_loop for a long time suggesting that we
> should genericize to LOOP_EXPR rather than gotos, and now that I need to
> interpret the function body for constexpr evaluation, making this change
> will also simplif
I've had a TODO in genericize_cp_loop for a long time suggesting that we
should genericize to LOOP_EXPR rather than gotos, and now that I need to
interpret the function body for constexpr evaluation, making this change
will also simplify that handling.
This change also does away with canonical
