Hi,
this patch fixes two cases, where the __tsan_func_entry is present but
__tsan_func_exit is missing.
This results in bogus call stacks and memory leaks.
See PR 65400 for stripped down code samples where this was first discovered.
Boot-strapped and regression-tested on x86_64-linux-gnu.
OK f
Hi!
The following testcase is miscompiled on s390x-linux, because
make_field_assignment considers the actual byte swap as a field assignment.
The problem is in the widening of the MEM mode, in the testcase from
original QI to HI, that only works for little-endian, for big endian
we need to adjust
Hi!
This issue is practically the same as PR63341, except in this case it is for
dr_explicit_realign rather than dr_explicit_realign_optimized, and the bump
isn't passed through multiple functions and thus is easier to fix.
Without the patch we use (dataptr & -16) for the first load and
((dataptr
Hi!
The first testcase shows a bug in my bit test reassoc optimization,
extract_bit_test_mask is (intentionally) stripping nops, but was setting
*totallowp and operating with tbias in the type of unstripped expression,
which then results in different signedness of types used and confusing the
opti
On March 14, 2015 10:10:34 AM GMT+01:00, Jakub Jelinek wrote:
>Hi!
>
>The first testcase shows a bug in my bit test reassoc optimization,
>extract_bit_test_mask is (intentionally) stripping nops, but was
>setting
>*totallowp and operating with tbias in the type of unstripped
>expression,
>which th
On March 14, 2015 10:04:53 AM GMT+01:00, Jakub Jelinek wrote:
>Hi!
>
>This issue is practically the same as PR63341, except in this case it
>is for
>dr_explicit_realign rather than dr_explicit_realign_optimized, and the
>bump
>isn't passed through multiple functions and thus is easier to fix.
>
>W
Hi, Kyrill
Thank you for your suggestion.
I fixed it and regtested with aarch64-linux-gnu on QEMU.
This patch has no regressions for aarch64_be-linux-gnu big-endian target too.
OK for the trunk?
Thanks.
Jiang jiji
Index: gcc/ChangeLog
=
Bernd Edlinger writes:
> Hi,
>
> are there any more comments on this?
>
> I would like to apply the patch as is, unless we find a
> a way to get to a test case, maybe with a cross-compiler,
> where the MODE_ALIGNMENT is different from MODE_BITSIZE.
>
> Currently, I think that does not h
This is Richi's prototype patch in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36043#c23 with fixes for
blocks larger than one reg, big-endian, and BLOCK_REG_PADDING.
I also removed the operand_subword_force since we may as well let
narrow_bit_field_mem in extract_bit_field do that for us. It is
On Sat, Mar 14, 2015 at 6:02 AM, Alan Modra wrote:
> This is Richi's prototype patch in
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36043#c23 with fixes for
> blocks larger than one reg, big-endian, and BLOCK_REG_PADDING.
> I also removed the operand_subword_force since we may as well let
> nar
On Sat, Mar 14, 2015 at 06:14:40AM -0700, H.J. Lu wrote:
> On Sat, Mar 14, 2015 at 6:02 AM, Alan Modra wrote:
> > I'll also throw together a testcase or three. For execute tests I'm
> > thinking of using sbrk to locate an odd sized struct such that access
> > past the end segfaults, rather than m
On March 14, 2015 2:02:38 PM GMT+01:00, Alan Modra wrote:
>I'll also throw together a testcase or three. For execute tests I'm
>thinking of using sbrk to locate an odd sized struct such that access
>past the end segfaults, rather than mmap/munmap as was done in the
>pr36043 testcase. Does that
On 03/08/2015 04:58 PM, Steve Kargl wrote:
On Mon, Mar 09, 2015 at 01:07:25AM +0200, Janne Blomqvist wrote:
So I would prefer if we just hardcode the error values in the frontend
(-HUGE, 0, 0), in case somebody tries to use the kind=1,2 versions,
thus also removing the need for the new library f
Attachment on this one.
On 03/14/2015 07:22 AM, Jerry DeLisle wrote:
On 03/08/2015 04:58 PM, Steve Kargl wrote:
On Mon, Mar 09, 2015 at 01:07:25AM +0200, Janne Blomqvist wrote:
So I would prefer if we just hardcode the error values in the frontend
(-HUGE, 0, 0), in case somebody tries to use t
On Fri, Mar 13, 2015 at 03:54:57PM -0600, Martin Sebor wrote:
> Attached is a patch that eliminates the unused stack frame
> allocated by gcc 5 with -pg -mprofile-kernel on powepc64le
> and brings the code into parity with previous gcc versions.
>
> The patch doesn't do anything to change the emit
On Mar 14, 2015, at 6:58 AM, Bernhard Reutner-Fischer
wrote:
> On March 14, 2015 2:02:38 PM GMT+01:00, Alan Modra wrote:
>
>> I'll also throw together a testcase or three. For execute tests I'm
>> thinking of using sbrk to locate an odd sized struct such that access
>> past the end segfaults,
On Sat, Mar 14, 2015 at 10:51:28AM -0700, Mike Stump wrote:
> On Mar 14, 2015, at 6:58 AM, Bernhard Reutner-Fischer
> wrote:
> > On March 14, 2015 2:02:38 PM GMT+01:00, Alan Modra wrote:
> >
> >> I'll also throw together a testcase or three. For execute tests I'm
> >> thinking of using sbrk to
On Mar 14, 2015, at 10:56 AM, Jakub Jelinek wrote:
>> newlib doesn’t have mmap. Indeed, some machines will never have mmap.
>> newlib has sbrk.
>
> Still, I think it is preferrable to test with mmap…
I don’t see anything wrong with going the target mmap direction… my post was
just to provid
Hi,
On Sat, 14 Mar 2015 13:24:33, Mikael Pettersson wrote:
>
> Bernd Edlinger writes:
>> Hi,
>>
>> are there any more comments on this?
>>
>> I would like to apply the patch as is, unless we find a
>> a way to get to a test case, maybe with a cross-compiler,
>> where the MODE_ALIGNMENT is differe
On Sat, Mar 14, 2015 at 11:32:38PM +1030, Alan Modra wrote:
> I'll also throw together a testcase or three.
* gcc.dg/pr65408.c: New.
Index: gcc/testsuite/gcc.dg/pr65408.c
===
--- gcc/testsuite/gcc.dg/pr65408.c (revision
Hi, all,
This patch is just to rename some variables so that
one can easily tell that those variables are used to
describe general purpose registers.
No functionality changes. Committed as Rev.221306:
https://gcc.gnu.org/r221306
Best regards,
jasonwucj
diff --git a/gcc/config/nds32/nds32-md
21 matches
Mail list logo
