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 different from
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
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
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
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
On March 14, 2015 10:04:53 AM GMT+01:00, Jakub Jelinek ja...@redhat.com 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
On March 14, 2015 10:10:34 AM GMT+01:00, Jakub Jelinek ja...@redhat.com 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,
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 happen.
On Sat, Mar 14, 2015 at 6:02 AM, Alan Modra amo...@gmail.com 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
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 06:14:40AM -0700, H.J. Lu wrote:
On Sat, Mar 14, 2015 at 6:02 AM, Alan Modra amo...@gmail.com 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 March 14, 2015 2:02:38 PM GMT+01:00, Alan Modra amo...@gmail.com 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
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
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
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 emitted
On Mar 14, 2015, at 6:58 AM, Bernhard Reutner-Fischer rep.dot@gmail.com
wrote:
On March 14, 2015 2:02:38 PM GMT+01:00, Alan Modra amo...@gmail.com 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
On Sat, Mar 14, 2015 at 10:51:28AM -0700, Mike Stump wrote:
On Mar 14, 2015, at 6:58 AM, Bernhard Reutner-Fischer rep.dot@gmail.com
wrote:
On March 14, 2015 2:02:38 PM GMT+01:00, Alan Modra amo...@gmail.com wrote:
I'll also throw together a testcase or three. For execute tests I'm
On Mar 14, 2015, at 10:56 AM, Jakub Jelinek ja...@redhat.com 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
21 matches
Mail list logo
