Hi,
On Thu, 5 Mar 2015 16:36:48, Richard Biener wrote:
>
> On Thu, Mar 5, 2015 at 4:05 PM, Bernd Edlinger
> wrote:
>>
>> every access is split in 4 QImode accesses. but that is as
>> expected, because the structure is byte aligned.
>
> No, it is not expected bec
Hi,
On Fri, 6 Mar 2015 10:09:30, Eric Botcazou wrote:
>
>> Hmm. As you also modify the no-strict-volatile-bitfield path I'm not sure
>> you don't regress the case where EP_insv can work on memory. I agree
>> that simplifying the strict-volatile-bitfield path to extract the memory
>> within strict-
On Fri, 6 Mar 2015 10:52:53, Eric Botcazou wrote:
>
>> I know it because strict_volatile_bitfield_p checks this:
>> /* Check for cases of unaligned fields that must be split. */
>> if (bitnum % BITS_PER_UNIT + bitsize> modesize
>>
>> Therefore, if bitsize == modesize, we know that bitnum % BITS_PER
Hi,
I have a box, where only python-minimal-2.7 seems to be installed and I have
tried to use make -k -j2; but this results in
./dg-extract-results.sh
Traceback (most recent call last):
File "./dg-extract-results.py", line 13, in
import io
ImportError: No module named io
This causes cont
ied to fix the comments.
Reg-tested on x86_64 successfully and ARM is still running.
Is it OK for trunk?
Thanks
Bernd.
gcc:
2015-03-06 Bernd Edlinger
* expmed.c (strict_volatile_bitfield_p): For STRICT_ALIGNMENT
check that MEM_
Hi Richard and Eric,
On Mon, 9 Mar 2015 15:30:31, Richard Biener wrote:
>> Reg-tested on x86_64 successfully and ARM is still running.
ARM completed without regressions meanwhile.
>>
>> Is it OK for trunk?
>
> Looks ok to me apart from
>
> /* Check for cases of unaligned fields that must be spli
Hi Jakub,
with my OPC UA Server, I observe a reproducible crash in
ScopedReport::AddThread: tctx==NULL
in "if ((u32)rep_->threads[i]->id == tctx->tid)".
Apparently, Dmitry has already fixed that in the obvious way.
So we should cherry pick these two changes from LLVM: 224508 and 224755
See atta
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.
Thanks
Bernd.
> Date: Tue, 10 Mar 2015 14
for trunk?
Thanks
Bernd.
2015-03-14 Bernd Edlinger
PR sanitizer/65400
* ipa-split.c (plit_function): Insert a call to TSAN_FUNC_EXIT again.
* tsan.c (instrument_gimple): Reset the tail call flag on each call
statement
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 cros
trapped and reg-tested on x86_64-linux-gnu.
OK for trunk?
Thanks
Bernd.
gcc:
2015-03-15 Bernd Edlinger
* expmed.c (strict_volatile_bitfield_p): Check that MEM_ALIGN allows
a MODESIZE access.
(store_bit_field, extract_bit_field):
Hi,
On Mon, 16 Mar 2015 20:31:53, Hans-Peter Nilsson wrote:
>
> On Mon, 16 Mar 2015, Eric Botcazou wrote:
>>> If we have BIGGEST_ALIGNMENT=16 that means we have likely a 16 bit
>>> architecture. I doubt that the strict alignment code makes any sense for
>>> modesize> BIGGEST_ALIGNMENT.
>>
>> Note
Hi,
I'd like to ping for this patch, which I hope can still go in the gcc-5 release:
See https://gcc.gnu.org/ml/gcc-patches/2015-03/msg00817.html for the
patch files.
Thanks,
Bernd.
> Date: Mon, 16 Mar 2015 11:53:00 +0100
>
>
> Hi,
>
>
> when looking at the m68k I realized the following, which
Ping again...
it's a wrong code bug.
Thanks
Bernd.
> Date: Mon, 23 Mar 2015 10:09:35 +0100
>
> Hi,
>
> I'd like to ping for this patch, which I hope can still go in the gcc-5
> release:
> See https://gcc.gnu.org/ml/gcc-patches/2015-03/msg00817.html for the
> patch files.
>
>
> Thanks,
> Bernd.
Hi,
On Mon, 30 Mar 2015 12:33:47, Richard Biener wrote:
>
> On Mon, Mar 16, 2015 at 11:53 AM, Bernd Edlinger
> wrote:
>>
>> Hi,
>>
>>
>> when looking at the m68k I realized the following, which is
>> a general problem...
>>
>> If the a
hanges in this area (even if I did so in
> the past).
>
Sorry, but I just have to continue...
So, now I removed these unaligned access parts again from the patch,
Attached you will find the new reduced version of the patch.
Boot-strapped and regression-tested on x86_64-linux-gnu.
OK for trunk?
anks
Bernd.
gcc/ChangeLog:
2014-06-11 Bernd Edlinger
PR rtl-optimization/61047
* rtlanal.c (get_initial_register_offset): New function.
(rtx_addr_can_trap_p_1): Check offsets of stack references.
testsuite/ChangeLog:
2014-06-11 Bernd Edlinger
PR rtl-op
Hi,
On Thu, 11 Jun 2015 10:02:03, Jakub Jelinek wrote:
>
> IMHO the
> #if 0
> #endif
> stuff doesn't belong to the patch.
>
I just wanted to leave a hint, how I debugged this function, and how
to assess the performance of the decision that is taken here.
I mean, the boot-strap would certainly pa
Hi,
On Thu, 11 Jun 2015 12:57:34 +0200, Jakub Jelinek wrote:
>
> On Thu, Jun 11, 2015 at 12:38:40PM +0200, Bernd Edlinger wrote:
>> On Thu, 11 Jun 2015 10:02:03, Jakub Jelinek wrote:
>>>
>>> IMHO the
>>> #if 0
>>> #endif
>>> stuff doesn&
Hi,
On Thu, 11 Jun 2015 16:38:23, Richard Biener wrote:
>
> Sounds like a red-zone is not accounted for?
>
No, I know about the red-zone:
+#ifdef RED_ZONE_SIZE
+ HOST_WIDE_INT red_zone_size = RED_ZONE_SIZE;
+#else
+ HOST_WIDE_INT red_zone_size = 0;
+#endif
otherwise there would
Hi,
On Thu, 11 Jun 2015 12:56:50, Richard Biener wrote:
>
> I also think we need to be conservative. I didn't look at the patch in detail
> to check whether we are indeed conservative here (what about offsets
> that are not visibly constant like for if (n> m) ... a[m];?).
>
we only handle constan
Hi,
On Thu, 11 Jun 2015 13:17:47 +0200, Eric Botcazou wrote:
>
>> Other than that, as I said already in the PR, I'm in favor of applying it to
>> the trunk (only, not release branches) and watching for performance and/or
>> wrong-code issues, but Eric is against it. What do others think about it?
anks
Bernd.
gcc/ChangeLog:
2015-06-11 Bernd Edlinger
PR rtl-optimization/61047
* rtlanal.c (get_initial_register_offset): New function.
(rtx_addr_can_trap_p_1): Check offsets of stack references.
testsuite/ChangeLog:
2015-06-11 Bernd Edlinger
PR rtl-optimiza
Hi,
the bogus offsets-issue is now entered in bugzilla, see PR66614.
It is however only a very minor issue, and does probably have
no impact on the generated code at all.
How should I continue with the rtx_addr_can_trap-patch?
Is it OK to commit?
Thanks
Bernd.
-
Hi,this patch fixes a regression that was triggered by commit
r225260.See pr66747 for details.Is it OK for
trunk?ThanksBernd. 2015-07-04 Bernd Edlinger
PR target/66747
* config/mips/mips.c (mips_cfun_has_inflexible_gp_ref_p): Handle
> Richard
Yes, I agree.
I have now updated my patch as suggested.
A mips-img-linux-gnu cross compiler builds as expected.
OK for trunk?
Thanks
Bernd.
2015-07-04 Bernd Edlinger
PR target/66747
* config/mips/mips.c (mips_find_gp
;
> Hi,
>
>
>
> On Sun, 4 Jan 2015 14:54:56, Bernd Edlinger wrote:
>>
>> Hi Jakub,
>>
>>
>> I think I have found a reasonable test case, see the attached patch file.
>> The use case is: a class that destroys an owned thread in the destructor.
>&
:
That is we now use a tsan-invisible barrier_wait function
instead of the not very reliable sleep(1).
barrier_wait is bypassing the tsan interceptor, because
it is accessed with dlsym (dlopen ("libpthread.so.0", RTLD_LAZY),
"pthread_barrier_wait").
Bernd.
> On Fri, Jan 1
Hi,
this patch fixes the Ada bootstrap under cygwin-32. See PR ada/64640.
Boot-strapped successfully under cygwin-32/XP.
OK for trunk?
Thanks
Bernd.
2015-01-19 Bernd Edlinger
PR ada/64640
* adaint.c: Handle __CYGWIN__ like
Hi,
this patch fixes libffi build problems under cygwin-32. See PR 64645.
Successfully boot-strapped under Cygwin-32/XP with libjava.
OK for trunk?
Thanks
Bernd.
2015-01-19 Bernd Edlinger
PR libffi/64645
* src/x86/sysv.S: Exclude
Hi,
On Mon, 19 Jan 2015 18:49:21, Konstantin Serebryany wrote:
>
> [text-only]
>
> On Mon, Jan 19, 2015 at 7:42 AM, Mike Stump wrote:
>> On Jan 19, 2015, at 12:43 AM, Dmitry Vyukov wrote:
>>> I can't really make my mind on this. I would mildly prefer sleep's (if
>>> they work reliably!).
>>
>>
Hi,
On Tue, 20 Jan 2015 17:47:29, Konstantin Serebryany wrote:
>>
>> We discussed two alternatives to sleep:
>>
>> 1. step function, optionally with sched_yield to make it somewhat less busy
>> waiting:
>> __attribute__((no_sanitize_thread))
>> void step (int i)
>> {
>> while (__atomic_load_n (&s
Hi,
On Wed, 21 Jan 2015 12:58:27, Dmitry Vyukov wrote:
>
>
> The step approach looks better to me at first sight.
>
> Busy waiting looks like a weak argument in this context. It's
> absolutely non performance-critical and a yield or usleep(10) will
> solve it more than sufficiently.
>
> I will ch
Hi Jakub & Mike,
> test.c:3:6: internal compiler error: in expand_TSAN_FUNC_EXIT, at
> internal-fn.c:243
> void step (int i)
It looks like your patches shot each other down..
How about this, maybe with a compile-time test of the step function in
c-c++common/tsan?
Thanks
Bernd.
On Wed, 21 Jan 2015 12:31:57, Jakub Jelinek wrote:
>
> On Wed, Jan 21, 2015 at 12:17:51PM +0100, Bernd Edlinger wrote:
>>> test.c:3:6: internal compiler error: in expand_TSAN_FUNC_EXIT, at
>>> internal-fn.c:243
>>> void step (int i)
>>
>>
>&
Hi,
On 21 Jan 2015 17:57:10, Dmitry Vyukov wrote:
> Subject: Re: [PING] [PATCH] Fix parameters of __tsan_vptr_update
> To: bernd.edlin...@hotmail.de
> CC: konstantin.s.serebry...@gmail.com; mikest...@comcast.net;
> k...@google.com; ja...@redhat.com; richard.guent...@gmail.com;
> gcc-patches@gcc.
Hi,
this patch fixed the no_sanitize_thread decl attribute again.
Boot-strapped and regression-tested on x86_64-linux-gnu.
OK for trunk?
Thanks
Bernd.
gcc/ChangeLog:
2015-01-21 Bernd Edlinger
* gimplify.c (gimplify_function_tree): Check the
.
2015-01-21 Bernd Edlinger
PR target/50928
* config/m32c/m32c.c (encode_pattern_1): Removed gcc_unreachable here.
(DEBUG_RELOAD): Removed define.
(m32c_limit_reload_class): Enable traces with if DEBUG0.
(m32c_function_arg): Added a type
Hi,
On Thu, 22 Jan 2015 17:56:19, DJ Delorie wrote:
>
>
> OK for trunk.
>
> OK for 4.9 branch if it's OK with the release manager.
>
> Do you need someone to apply it for you?
No, I have write-after-approval access.
I just did not post this patch earlier, because I do not have an
environment to
Hi,
this patch fixes the ada bootstrap under cygwin-64.
Boot-strapped under x86_64-pc-cygwin.
OK for trunk?
Thanks
Bernd.
2015-01-27 Bernd Edlinger
Fix build under cygwin/64.
* adaint.h: Add check for __CYGWIN__.
* mingw32
Hi,
after the recent version bump of the libjava libraries, java under cygwin is
broken.
The reason is that libgcc/config/i386/cygming-crtbegin.c needs to know the exact
version number to load the symbol _Jv_RegisterClasses from cyggcj-16.dll.
This patch fixes the cyggcj-xx.dll version numbers
Hi,
this patch fixes PR64980 and PR61960 at the same time.
The unreduced test case for PR64230 is also included, because a previous version
of this patch caused this test to fail but the complete test suite passed
without any
indication of any problem.
Boot-strapped and regression-tested on X8
t; without any
> indication of any problem.
>
> Boot-strapped and regression-tested on X86_64-unknown-linux-gnu.
>
> OK for trunk?
>
>
> Thanks,
> Bernd.
>
>
> PS: Special thanks to Dominique for his help with testing of this patch.
>
Ping...
> From: bernd.edlin...@hotmail.de
> To: gcc-patches@gcc.gnu.org
> CC: richard.guent...@gmail.com; hubi...@ucw.cz
> Subject: RE: [PING**2] [PATCH] Fix PR ipa/61190, 2nd editionâ
> Date: Mon, 27 Oct 2014 09:23:41 +0100
>
>
> Ping again...
>
> Tha
already rather
much test coverage.
The most easy adjustment seems to change the existing test cases to use static
declarations.
Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?
Thanks
Bernd.
gcc/cp:
2018-12-15 Bernd Edlinger
PR c++/88261
* typeck2.c (digest_init_r
Thanks Jakub,
for the additional test cases, they work just fine, so I added them as-is.
Bernd.
On 12/15/18 10:33 AM, Jakub Jelinek wrote:
> On Sat, Dec 15, 2018 at 08:36:25AM +0000, Bernd Edlinger wrote:
>> this patch implements an error message, for non-static initializa
Hi,
if I understood that right, then clobbering sp is and has always been ignored.
If that is right, then I would much prefer a warning, that says exactly that,
because that would also help to understand why removing that clobber statement
is safe even for old gcc versions.
Since your patch did
On 12/17/18 2:42 PM, Christophe Lyon wrote:
> On Mon, 17 Dec 2018 at 14:35, Richard Sandiford
> wrote:
>>
>> Christophe Lyon writes:
>>> On Mon, 17 Dec 2018 at 12:47, Richard Sandiford
>>> wrote:
>>>>
>>>> Dimitar Dimitrov writes:
&g
On 12/17/18 2:35 PM, Richard Sandiford wrote:
> Christophe Lyon writes:
>> On Mon, 17 Dec 2018 at 12:47, Richard Sandiford
>> wrote:
>>>
>>> Dimitar Dimitrov writes:
>>>> On Sun, Dec 16 2018 at 14:36:26 EET Bernd Edlinger wrote:
>>>>>
Hi,
> Unfortunately another PCS bug has come to light with the layout of
> structs whose alignment is dominated by a 64-bit bitfield element. Such
> fields in the type list appear to have alignment 1, but in reality, for
> the purposes of alignment of the underlying structure, the alignment is
>
On 12/17/18 7:46 PM, Richard Sandiford wrote:
> Segher Boessenkool writes:
>> On Mon, Dec 17, 2018 at 11:47:42AM +, Richard Sandiford wrote:
>>> Dimitar Dimitrov writes:
>>>> On Sun, Dec 16 2018 at 14:36:26 EET Bernd Edlinger wrote:
>>>>> Hi,
make the LRA register allocator switch
frame_pointer_needed to 1, and therefore in all likelihood,
all targets should use that consistently.
On 12/17/18 12:47 PM, Richard Sandiford wrote:
> Dimitar Dimitrov writes:
>> On Sun, Dec 16 2018 at 14:36:26 EET Bernd Edlinger wrote:
>>>
On 12/18/18 3:16 PM, Bernd Edlinger wrote:
> Hi,
>
> while I looked closely at the asm statement in the gdb,
> I realized that the SP clobber forces the function to use
> the frame pointer, and prevents the red zone. That
> makes the push / pop sequence in the asm statement
On 12/20/18 6:50 PM, Martin Sebor wrote:
> On 12/20/18 10:46 AM, Martin Sebor wrote:
>> On 12/17/18 7:58 AM, Jason Merrill wrote:
>>> On 12/15/18 3:36 AM, Bernd Edlinger wrote:
>>>> this patch implements an error message, for non-static initialization of a
>>
On 12/21/18 2:03 AM, Martin Sebor wrote:
> On 12/20/18 2:07 PM, Bernd Edlinger wrote:
>> On 12/20/18 6:50 PM, Martin Sebor wrote:
>>> On 12/20/18 10:46 AM, Martin Sebor wrote:
>>>> On 12/17/18 7:58 AM, Jason Merrill wrote:
>>>>> On 12/15/18 3:3
Hi Jeff,
I wonder if it would make sense at this point to rename one of the two
get_strlen_range functions?
I always found it hard to tell which function is actually meant when they only
differ in the number of parameters.
Regards
Bernd.
On 12/22/18 7:53 PM, Bernd Edlinger wrote:
> On 12/21/18 2:03 AM, Martin Sebor wrote:
>> On 12/20/18 2:07 PM, Bernd Edlinger wrote:
>>> On 12/20/18 6:50 PM, Martin Sebor wrote:
>>>> On 12/20/18 10:46 AM, Martin Sebor wrote:
>>>>> On 12/17/18 7:58 AM, Ja
On 1/4/19 10:22 PM, Jason Merrill wrote:
> On 1/4/19 10:30 AM, Bernd Edlinger wrote:
>> On 12/22/18 7:53 PM, Bernd Edlinger wrote:
>>> On 12/21/18 2:03 AM, Martin Sebor wrote:
>>>> On 12/20/18 2:07 PM, Bernd Edlinger wrote:
>>>>> On 12/20/18 6:50 PM, Ma
Hi,
co-incidentally my "Make strlen range computations more conservative" patch
contained a fix on the same spot, I just did not have a test case for it:
@@ -3184,7 +3146,10 @@ get_min_string_length (tree rhs, bool *f
&& TREE_READONLY (rhs))
rhs = DECL_INITIAL (rhs);
- if (rhs && TR
On 1/5/19 1:31 PM, Jakub Jelinek wrote:
> On Sat, Jan 05, 2019 at 12:20:24PM +0000, Bernd Edlinger wrote:
>> co-incidentally my "Make strlen range computations more conservative" patch
>> contained a fix on the same spot, I just did not have a test case for it:
init_elt,
process_init_constructor_array, process_init_constructor_record,
process_init_constructor_union, process_init_constructor): Add the
flags parameter and pass it thru.
(store_init_value): Pass LOOKUP_ALLOW_FLEXARRAY_INIT parameter to
digest_init_flags for static decls.
gcc/testsuite:
2019-01-05 Bern
On 1/7/19 1:08 AM, Martin Sebor wrote:
> On 1/5/19 9:04 AM, Bernd Edlinger wrote:
>> On 1/4/19 10:22 PM, Jason Merrill wrote:
>>> Hmm, I'm uncomfortable with starting to pass in the decl just for the sake
>>> of deciding whether this diagnostic should be a p
if my patch, using the suggested warning option,
and a note with the details.
Bootstrapped on x86_64-pc-linux-gnu.
Is it OK for trunk?
Thanks
Bernd.
2018-01-07 Bernd Edlinger
* doc/invoke.texi: Document -Wstack-clobber.
* common.opt (-Wstack-clobber): New default-enabled warning.
* cfge
Hi Richard,
it is already a while ago, but I had not found time to continue
with this patch until now.
I think I have now a better solution, which properly addresses your
comments below.
On 3/25/19 9:41 AM, Richard Biener wrote:
> On Fri, 22 Mar 2019, Bernd Edlinger wrote:
>
>> O
ux, it might be confused with
a network path in another well known O/S.
So I'd like to remove the duplicated slash here.
Boot-strapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?
Thanks
Bernd.2019-08-01 Bernd Edlinger
* Make-lang.in (lto.install-common): Remove unnece
/lto/ChangeLog (Arbeitskopie)
@@ -1,3 +1,8 @@
+2019-08-01 Bernd Edlinger
+
+ * Make-lang.in (lto.install-common): Remove unnecessary slash
+ between $(DESTDIR) and $(bindir).
+
2019-07-25 Martin Liska
* lto-common.c (compare_tree_sccs_1): Use new macros
Index: gcc/lto/
On 7/31/19 3:16 PM, Richard Earnshaw (lists) wrote:
>
>
> On 30/07/2019 21:51, Bernd Edlinger wrote:
>> +/* { dg-options "-marm -march=armv6 -mno-unaligned-access -mfloat-abi=soft
>> -mabi=aapcs -O3" } */
>
> This isn't going to work as-is, we test ma
-08-02 Bernd Edlinger
+
+ * function.c (assign_param_data_one): Remove unused data members.
+
2019-08-02 Steve Ellcey
* omp-simd-clone.c (simd_clone_adjust_return_type): Remove call to
Index: function.c
@@
2019-08-02 Bernd Edlinger
+ * function.c (assign_parm_adjust_stack_rtl): Revise STRICT_ALIGNMENT
+ check to use targetm.slow_unaligned_access instead.
+
* function.c (assign_param_data_one): Remove unused data members.
2019-08-02 Steve Ellcey
Index: function.c
On 8/2/19 3:11 PM, Richard Biener wrote:
> On Tue, 30 Jul 2019, Bernd Edlinger wrote:
>
>>
>> I have no test coverage for the movmisalign optab though, so I
>> rely on your code review for that part.
>
> It looks OK. I tried to make it trigger on the f
latest gcc-9 branch, I want
to ask right away, if it is okay to back-port after a while.
Boot-strapped and reg-tested on x86_64-pc-linux-gnu and armv7-linux-gnueabihf.
Is it OK for trunk?
Thanks,
Bernd.
2019-07-30 Bernd Edlinger
PR tree-optimization/91109
* lra-remat.c (update_scratch_ops
On 8/2/19 9:01 PM, Bernd Edlinger wrote:
> On 8/2/19 3:11 PM, Richard Biener wrote:
>> On Tue, 30 Jul 2019, Bernd Edlinger wrote:
>>
>>>
>>> I have no test coverage for the movmisalign optab though, so I
>>> rely on your code review for that part.
>>
Hi Jakub,
I think this wrong code bug would be good to be fixed in 9.2.
Would you like me to go ahead, or should it wait for 9.3 ?
Thanks
Bernd.
On 8/7/19 3:32 PM, Vladimir Makarov wrote:
> On 8/5/19 4:37 PM, Bernd Edlinger wrote:
>> Hi!
>>
>>
>> PR 91109 is a w
Hi!
I'd like to ping for this patch:
https://gcc.gnu.org/ml/gcc-patches/2019-08/msg00546.html
Thanks
Bernd.
/ChangeLog
===
--- gcc/ChangeLog (revision 274486)
+++ gcc/ChangeLog (revision 274487)
@@ -1,3 +1,7 @@
+2019-08-14 Bernd Edlinger
+
+ * builtins.c (expand_builtin_init_descriptor): Set memory alignment.
+
2019-08-14
On 8/14/19 2:00 PM, Richard Biener wrote:
> On Thu, 8 Aug 2019, Bernd Edlinger wrote:
>
>> On 8/2/19 9:01 PM, Bernd Edlinger wrote:
>>> On 8/2/19 3:11 PM, Richard Biener wrote:
>>>> On Tue, 30 Jul 2019, Bernd Edlinger wrote:
>>>>
>>>>
(Revision 274530)
+++ gcc/ChangeLog (Revision 274531)
@@ -1,3 +1,7 @@
+2019-08-15 Bernd Edlinger
+
+ * function.c (assign_parm_setup_reg): Handle misaligned stack arguments.
+
2019-08-15 Martin Liska
* tree-ssa-dce.c (propagate_necessity): We can't reach
On 8/15/19 10:55 AM, Richard Biener wrote:
> On Wed, 14 Aug 2019, Bernd Edlinger wrote:
>
>> On 8/14/19 2:00 PM, Richard Biener wrote:
>>
>> Well, yes, but I was scared away by the complexity of emit_move_insn_1.
>>
>> It could be done, but in the moment I wo
On 8/15/19 2:54 PM, Richard Biener wrote:
> On Thu, 15 Aug 2019, Bernd Edlinger wrote:
>
>>>>>
>>>>> Hmm. So your patch overrides user-alignment here. Woudln't it
>>>>> be better to do that more conciously by
>>>>>
>>
with no assignment
and continuing the loop in that case.
Boot-strapped and reg-tested on x86_64-pc-linux-gnu and arm-linux-gnueabihf.
Is it OK for trunk?
Thanks
Bernd.
2019-08-12 Bernd Edlinger
PR tree-optimization/91109
* lra-int.h (lra_need_for_scratch_reg_p): Declare.
* lra.c (lra
a problem. Since this would affect many targets, and
more
kinds of variables that may probably not have a strict alignment problem.
But I am ready to take your advice though.
Boot-strapped and reg-tested on x86_64-pc-linux-gnu and arm-linux-gnueabihf
Is it OK for trunk?
Thanks
Bernd.
2019-08
ing the larger stack alignment
known to the middle-end, and the test cases.
Boot-strapped and reg-tested on x86_64-pc-linux-gnu and arm-linux-gnueabihf.
Is it OK for trunk?
Thanks
Bernd.
2019-08-15 Bernd Edlinger
PR middle-end/89544
* function.c (assign_parm_find_stack_rtl): Use larger a
On 8/15/19 9:46 PM, Bernd Edlinger wrote:
> Hi,
>
> as discussed in the PR 91109 audit trail,
> my previous patch missed a case where no spilling is necessary,
> but the re-materialized instruction has now scratch regs without
> a hard register assignment. And thus the LRA
On 8/15/19 9:47 PM, Bernd Edlinger wrote:
> Hi,
>
> this is the split out part from the "Fix not 8-byte aligned ldrd/strd on
> ARMv5 (PR 89544)"
> which is sanitizing the middle-end interface to the back-end for strict
> alignment,
> and a couple of bug-fixes tha
8/20/19 4:39 PM, John David Anglin wrote:
> On 2019-08-15 3:47 p.m., Bernd Edlinger wrote:
>> 2019-08-15 Bernd Edlinger
>>
>> PR middle-end/89544
>> * function.c (assign_parm_find_stack_rtl): Use larger alignment
>> when possible.
> This patch b
On 8/23/19 12:57 AM, Jeff Law wrote:
> On 8/15/19 1:47 PM, Bernd Edlinger wrote:
>> Hi,
>>
>> this is the split out part from the "Fix not 8-byte aligned ldrd/strd on
>> ARMv5 (PR 89544)"
>> which is sanitizing the middle-end interface to the back-end f
On 8/27/19 11:25 AM, Kyrill Tkachov wrote:
> Hi Bernd,
>
> On 8/15/19 8:47 PM, Bernd Edlinger wrote:
>> Hi,
>>
>> this is the split out part from the "Fix not 8-byte aligned ldrd/strd on
>> ARMv5 (PR 89544)"
>> which is sanitizing the middle-end i
execute
>
> /tmp/6852788_4.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/cfgexpand.c:6538
>
> Christophe
>
Okay, sorry for the breakage.
What is happening in gen_cpymem_ldrd_strd is of course against the rules:
It uses emit_move_insn on only 4-byte aligned DI-mode memo
On 8/29/19 11:08 AM, Christophe Lyon wrote:
> On Thu, 29 Aug 2019 at 10:58, Kyrill Tkachov
> wrote:
>>
>> Hi Bernd,
>>
>> On 8/28/19 10:36 PM, Bernd Edlinger wrote:
>>> On 8/28/19 2:07 PM, Christophe Lyon wrote:
>>>> Hi,
>>>>
&g
09-01 Bernd Edlinger
PR middle-end/91605
* expr.c (expand_assignment): Avoid DECL_P with DECL_RTL
not being MEM_P.
testsuite:
2019-09-01 Bernd Edlinger
PR middle-end/91605
* g++.target/i386/pr91605.C: New test.
Index: gcc/e
275265)
@@ -171,7 +171,7 @@
* config/i386/i386-features.c (convert_scalars_to_vector): Do not
add the MD problem.
-2019-09-28 Bernd Edlinger
+2019-08-28 Bernd Edlinger
Richard Biener
* expr.c (expand_assignment): Handle misaligned DECLs.
@@ -2861,12
On 9/2/19 9:50 AM, Richard Biener wrote:
> On Sun, 1 Sep 2019, Bernd Edlinger wrote:
>
>> Hi,
>>
>> this fixes an oversight in r274986.
>> We need to avoid using movmisalign on DECL_P which are not in memory,
>> similar to the !mem_ref_refers_to_non_mem_p
apped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?
Thanks
Bernd.
2019-09-02 Bernd Edlinger
* testsuite/lib/libphobos.exp (libphobos_init): Add multi-lib libgcc dirs
to the ld_library_path var.
Index: libphobos/testsui
, this happens
after the we handle misaligned stuff, and therefore causes assertions when
that value is used later on, but this is no wrong-code.
Bootstrapped and reg-tested on x86_64-pc-linux-gnu and arm-linux-gnueabihf.
Is it OK for trunk?
Thanks
Bernd.
2019-09-03 Bernd Edlinger
PR middle
On 9/3/19 9:05 AM, Jakub Jelinek wrote:
> On Tue, Sep 03, 2019 at 07:02:53AM +0000, Bernd Edlinger wrote:
>> 2019-09-03 Bernd Edlinger
>>
>> PR middle-end/91603
>> PR middle-end/91612
>> PR middle-end/91613
>> * expr.c (expand
On 9/3/19 1:12 PM, Richard Biener wrote:
> On Tue, 3 Sep 2019, Bernd Edlinger wrote:
>
>> On 9/3/19 9:05 AM, Jakub Jelinek wrote:
>>> On Tue, Sep 03, 2019 at 07:02:53AM +, Bernd Edlinger wrote:
>>>> 2019-09-03 Bernd Edlinger
>>>>
>>&g
On 9/3/19 8:40 PM, Jeff Law wrote:
> On 9/1/19 4:36 AM, Bernd Edlinger wrote:
>> Hi,
>>
>> this fixes an oversight in r274986.
>> We need to avoid using movmisalign on DECL_P which are not in memory,
>> similar to the !mem_ref_refers_to_non_mem_p which unf
ld be to use two movsi instead of the unaligned_load/storedi,
but that would end up in ldm/stm which looks plain wrong to me.
Tested using various arm-linux-gnueabihf cross-compilers.
Is it OK for trunk?
Thanks
Bernd.
2019-09-03 Bernd Edlinger
PR target/91614
* gcc.target/arm/unali
On 9/4/19 2:53 PM, Richard Earnshaw (lists) wrote:
> On 15/08/2019 20:47, Bernd Edlinger wrote:
>> On 8/15/19 6:29 PM, Richard Biener wrote:
>>>>>
>>>>> Please split it into the parts for the PR and parts making the
>>>>> asserts not trigger.
On 9/4/19 4:14 PM, Richard Earnshaw (lists) wrote:
> On 04/09/2019 14:28, Bernd Edlinger wrote:
>> On 9/4/19 2:53 PM, Richard Earnshaw (lists) wrote:
>>> Index: gcc/testsuite/gcc.target/arm/unaligned-argument-2.c
>>>
701 - 800 of 1395 matches
Mail list logo
