On 10/11/23 17:17, Kito Cheng wrote:
Yeah, I'll take you suggestion and go ahead, Robin's suggestion is
great but it's just a little too magic :P
So there'll be a V2 of this patch, right? Just want to make sure state
is correct in patchwork.
jeff
On 10/11/23 10:42, Florian Weimer wrote:
Add -std=gnu89 to some tests which evidently target C89-only language
features.
gcc/testsuite/
* gcc.c-torture/compile/920501-11.c: Compile with -std=gnu89.
* gcc.c-torture/compile/920501-23.c: Likewise.
* gcc.c-torture/compile
On 10/11/23 10:53, Florian Weimer wrote:
These changes are assumed not to interfere with the test objective,
but it was not possible to reproduce the historic test case failures
(with or without the modification here).
gcc/testsuite/
* gcc.c-torture/compile/2105-1.c: Add missing
On 10/11/23 10:55, Florian Weimer wrote:
The updated test cases still reproduce the bugs with old compilers.
gcc/testsuite/
* gcc.c-torture/compile/pc44485.c (func_21): Add missing cast.
* gcc.c-torture/compile/pr106101.c: Use builtins to avoid
calls to undeclared fun
On 10/9/23 08:59, Juzhe-Zhong wrote:
These cases won't check SLP for load_lanes support target.
Add vectorization check for situations.
gcc/testsuite/ChangeLog:
* gcc.dg/vect/pr97832-2.c: Add vectorization check.
* gcc.dg/vect/pr97832-3.c: Ditto.
* gcc.dg/vect/pr9783
On 10/12/23 12:28, Kito Cheng wrote:
Sorry for the late comment after Jeff say ok, but I guess we may
consider add "-fno-schedule-insns -fno-schedule-insns2" to avoid
disturbing from schedule like some of our test case in
gcc/testsuite/gcc.target/riscv/rvv?
It wouldn't be a bad idea to bring m
On 10/6/23 01:45, Stefan Schulze Frielinghaus wrote:
If a CONST_INT represents an integer of a mode with fewer bits than in
HOST_WIDE_INT, then the integer is sign extended. For those two
optimizations touched by this patch, the integers of interest have only
the most significant bit set w.r.
On 10/14/23 16:14, Roger Sayle wrote:
This patch is my proposed solution to PR rtl-optimization/91865.
Normally RTX simplification canonicalizes a ZERO_EXTEND of a ZERO_EXTEND
to a single ZERO_EXTEND, but as shown in this PR it is possible for
combine's make_compound_operation to unintentiona
On 10/14/23 17:32, Roger Sayle wrote:
This patch improves the initial RTL expanded for double word shifts
on architectures with conditional moves, so that later passes don't
need to clean-up unnecessary and/or unused instructions.
Consider the general case, x << y, which is expanded well as:
On 10/15/23 02:14, Roger Sayle wrote:
I’ve done it again. ENOPATCH.
*From:*Roger Sayle
*Sent:* 15 October 2023 09:13
*To:* 'gcc-patches@gcc.gnu.org'
*Cc:* 'Claudiu Zissulescu'
*Subject:* [ARC PATCH] Split asl dst,1,src into bset dst,0,src to
implement 1<
This patch adds a pre-reload spli
On 10/15/23 02:12, Roger Sayle wrote:
This patch adds a pre-reload splitter to arc.md, to use the bset (set
specific bit instruction) to implement 1
On 10/16/23 12:01, Manolis Tsamis wrote:
This is a new RTL pass that tries to optimize memory offset calculations
by moving them from add immediate instructions to the memory loads/stores.
For example it can transform this:
addi t4,sp,16
add t2,a6,t4
shl t3,t2,1
ld a2,0(t3)
On 10/15/23 12:16, Vineet Gupta wrote:
A bunch of FP tests expecting specific FP asm output fail when built
with zfa because different insns are generated. And this happens
because those tests don't have an explicit -march and the default
used to configure gcc could end up with zfa causing the
On 10/15/23 03:49, Roger Sayle wrote:
Hi Jeff,
Thanks for the speedy review(s).
From: Jeff Law
Sent: 15 October 2023 00:03
To: Roger Sayle ; gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] PR 91865: Avoid ZERO_EXTEND of ZERO_EXTEND in
make_compound_operation.
On 10/14/23 16:14, Roger Sayle
This just moves a few functions out of riscv.cc into riscv-string.cc in
an attempt to keep riscv.cc manageable. This was originally Christoph's
code and I'm just pushing it on his behalf.
Full disclosure: I built rv64gc after changing to verify everything
still builds. Given it was just li
easy, copy the result
into the proper target when needed.
Bootstrapped and regression tested on x86. Pushed to the trunk.
Jeffcommit b626751a4e87b090531c648631df33ac20c4fab8
Author: Jeff Law
Date: Mon Oct 16 17:14:38 2023 -0600
Fix minor problem in stack probing
probe_stack_
On 9/28/23 15:43, Vineet Gupta wrote:
RISC-V suffers from extraneous sign extensions, despite/given the ABI
guarantee that 32-bit quantities are sign-extended into 64-bit registers,
meaning incoming SI function args need not be explicitly sign extended
(so do SI return values as most ALU insns
On 10/17/23 12:51, Vineet Gupta wrote:
Update the test to potentially generate two SEXT.W instructions: one for
incoming function arg, other for function return.
But after commit 8eb9cdd14218
("expr: don't clear SUBREG_PROMOTED_VAR_P flag for a promoted subreg")
the test is not supposed to ge
On 10/17/23 14:48, Alex Coplan wrote:
haifa-sched.cc:remove_notes asserts that it lands on a real (non-note)
insn after advancing past NOTE_INSN_EPILOGUE_BEG, but with the upcoming
post-RA aarch64 load pair pass enabled, we can land on
NOTE_INSN_DELETED.
This patch adjusts remove_notes to rem
On 10/17/23 03:19, Richard Biener wrote:
On Thu, Oct 12, 2023 at 10:15 AM Richard Sandiford
wrote:
Richard Biener writes:
On Tue, Aug 22, 2023 at 12:42 PM Szabolcs Nagy via Gcc-patches
wrote:
From: Richard Sandiford
The prologue/epilogue pass allows the prologue sequence
to contain j
On 10/14/23 16:14, Roger Sayle wrote:
This patch is my proposed solution to PR rtl-optimization/91865.
Normally RTX simplification canonicalizes a ZERO_EXTEND of a ZERO_EXTEND
to a single ZERO_EXTEND, but as shown in this PR it is possible for
combine's make_compound_operation to unintentiona
On 10/17/23 01:04, Robin Dapp wrote:
Natively, things seem fine, but for cross, I get failures on a few
targets (hppa2.0-unknown-linux-gnu, hppa64-unknown-linux-gnu).
With ./configure --host=x86_64-pc-linux-gnu
--target=hppa2.0-unknown-linux-gnu --build=x86_64-pc-linux-gnu && make
-j$(nproc),
commit just fixes trailing whitespace problems.
Jeff
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index a8c2629cdac..15becdc2466 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,7 @@
+2018-07-02 Jeff Law
+
+ * config/h8300/h8300.md: Remove trailing whitespace.
+
2018-07-02 Jim
dex 15becdc2466..a1f2d351983 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,5 +1,11 @@
2018-07-02 Jeff Law
+ * config/h8300/h8300.md (movqi_h8300, movqi_h8300hs): Consolidate
+ the H8/300, H8/300H and H8/S variants into a single pattern.
+ (movhi_h8300, movqi_h830
Another batch of cleanups/consolidations.
First, the move patterns. This consolidates the movXX expanders -- this
can slightly change the generated code on the H8/SX due to an
inconsistency in the old movhi expander that is fixed by this change.
The expanders for logicals and basic arithmetic w
Another round.
This merges the movmd/movsd related patterns. Their primary difference
was normal vs advanced mode, so we can just use the P mode iterator and
significantly reduce duplication here.
This also merges two of the btst patterns and fixes the pattern's
condition. This also allows the
On 07/03/2018 04:59 PM, Martin Sebor wrote:
> The pretty-printer formats NaNs simply as Nan, even though
> there is much more to a NaN than than that. At the very
> least, one might like to know if the NaN is signaling or
> quiet, negative or positive. If it's not in a canonical
> form, one might
On 07/03/2018 03:31 AM, Aldy Hernandez wrote:
> On 07/02/2018 07:08 AM, Christophe Lyon wrote:
>
On 11/07/2017 10:33 AM, Aldy Hernandez wrote:
> While poking around in the backwards threader I noticed that we bail if
>
> we have already seen a starting BB.
>
> /* D
On 07/03/2018 01:11 PM, Martin Liška wrote:
> On 07/03/2018 10:53 AM, Martin Liška wrote:
>> Thank you Jeff.
>>
>> I found some issues when doing build of all targets
>> (contrib/config-list.mk).
>> I'll update patch and test that affected cross-compilers still produce
>> same output.
>
> Hello.
>
So the H8 port has movmd and movsd instructions which are used to
implement block moves and stpcpy. Those expanders and patters are
necessarily fairly ugly, but not enough to warrant trying to simplify.
What is worth simplifying is the fact that we have two copies of each
pattern and splitter be
On 07/03/2018 04:50 PM, Martin Sebor wrote:
> In computing the size of expected output for non-constant floating
> arguments the sprintf pass doesn't consider the possibility that
> the argument value may be not finite (i.e., it can be infinity or
> NaN). Infinities and NaNs are formatted as "inf"
This patch consolidates the ior/xor expanders, patterns and splitters
using a code iterator.
This does make us a bit more lenient on what we accept for xor operands
than we were before. However, AFAICT xor should accept the same
operands as ior on all the supported H8 variants.
The additional l
After consolidating HI and SI mode patterns for logical bit operators,
the remaining patterns "logical3_sn" "logical3" are in
effect identical.
This patch deletes logical3_sn.
This (not surprisingly) makes no difference in the generated code :-)
Installed on the trunk
Jeff
* config/h83
On 07/03/2018 11:24 AM, Martin Liška wrote:
> Hi.
>
> As new option mangles absolute path of a compiled file, it's hard
> to come up with a scan-file pattern. Note similar test is done in
> gcc.dg/profile-dir-*.c that I adjusted few days ago.
>
> Ready for trunk?
> Thanks,
> Martin
>
> gcc/tests
On 07/03/2018 11:23 AM, Martin Liška wrote:
> Hi.
>
> I'm sending fix for DOS-based system, it's a compilation error that
> I introduced some time ago. Plus I add Jonathan's correction of a
> documentation
> entry.
>
> Ready for trunk?
> Thanks,
> Martin
>
> gcc/ChangeLog:
>
> 2018-07-03 Marti
On 06/29/2018 09:54 AM, Martin Sebor wrote:
>
> All the warnings I have seen are because of declarations like
> the one in the test below that checks for the presence of symbol
> sin in the library:
>
> char sin ();
> int main () { return sin (); }
>
> GCC has warned for this code by default
On 07/03/2018 10:53 AM, H.J. Lu wrote:
> On Tue, Jul 3, 2018 at 9:12 AM, Uros Bizjak wrote:
>> On Tue, Jul 3, 2018 at 5:32 PM, H.J. Lu wrote:
>>> On Fri, Jun 8, 2018 at 3:27 AM, H.J. Lu wrote:
On x86, swapcontext may return via indirect branch when shadow stack
is enabled. To support
On 07/03/2018 07:50 AM, Nathan Sidwell wrote:
> could a global reviewer comment? This touches a lot of target-specific
> config files. David has kindly checked AIX is ok, the known target
> needing the functionality.
>
> https://gcc.gnu.org/ml/gcc-patches/2018-06/msg01568.html
So it's almost cer
On 05/23/2018 11:15 AM, Maxim Ostapenko wrote:
> Hi,
>
>
> as described in PR, when using both ASan and UBSan
> (-fsanitize=address,undefined ), we have symbols collision for global
> functions, like __sanitizer_set_report_path. This leads to fuzzy results
> when printing reports into files e.
On 07/05/2018 06:00 AM, Sebastian Huber wrote:
> * config.guess: Sync with upstream version 2018-06-26.
> * config.sub: Sync with upstream version 2018-07-02.
OK. And I think in general syncing to the latest version from upstream
ought not require explicit approval.
Richi/Jakub have t
On 07/05/2018 10:51 AM, Palmer Dabbelt wrote:
> On Thu, 05 Jul 2018 05:00:20 PDT (-0700),
> sebastian.hu...@embedded-brains.de wrote:
>> * config.guess: Sync with upstream version 2018-06-26.
>> * config.sub: Sync with upstream version 2018-07-02.
>> ---
>> config.guess | 6 +++---
>> conf
On 07/05/2018 08:53 AM, Bernhard M. Wiedemann wrote:
> On 2018-06-29 17:09, Jeff Law wrote:
>> In the immediate term, applying the patch to both instances seems wise.
>>
>> Bernhard, do you have commit privs?
>
> no, and I dont really want privs, since I expect to be
On 07/04/2018 03:24 PM, James Clarke wrote:
> config/
> * dfp.m4 (enable_decimal_float): Enable for x86_64*-*-gnu* to
> catch x86_64 kFreeBSD and Hurd.
>
> gcc/
> * configure: Regenerate.
>
> libdecnumber/
> * configure: Regenerate.
>
> libgcc/
> * configure: Regene
On 07/04/2018 02:12 AM, Aldy Hernandez wrote:
>
>
> On 07/03/2018 08:16 PM, Jeff Law wrote:
>> On 07/03/2018 03:31 AM, Aldy Hernandez wrote:
>>> On 07/02/2018 07:08 AM, Christophe Lyon wrote:
>>>
>>>>>> On 11/07/2017 10:33 AM, Aldy Hernandez
On 07/05/2018 09:35 AM, Qing Zhao wrote:
> Hi,
>
> I have sent two emails with the updated patches on 7/3:
>
> https://gcc.gnu.org/ml/gcc-patches/2018-07/msg00065.html
> https://gcc.gnu.org/ml/gcc-patches/2018-07/msg00070.html
>
> however, these 2 emails were not successfully forwarded to the
>
On 04/10/2018 06:27 AM, Martin Liška wrote:
> On 04/10/2018 11:19 AM, Jakub Jelinek wrote:
>> On Mon, Apr 09, 2018 at 02:31:04PM +0200, Martin Liška wrote:
>>> gcc/testsuite/ChangeLog:
>>>
>>> 2018-03-28 Martin Liska
>>>
>>> * gcc.dg/string-opt-1.c:
>> I guess you really didn't mean to keep
On 07/02/2018 03:50 PM, Peter Bergner wrote:
> I'd like to PING:
>
> https://gcc.gnu.org/ml/gcc-patches/2018-06/msg01713.html
>
> I've included the entire patch below, since I missed the test cases in
> the original submission and Segher asked for some updated text for the
> hook documentation
On 07/04/2018 11:32 AM, Martin Sebor wrote:
> On 07/03/2018 08:33 PM, Jeff Law wrote:
>>
>>>
>>> But since the number of warnings here hasn't changed, the ones
>>> in GCC logs predate my changes. So updating the tests seems
>>> like an improvement
On 06/28/2018 09:14 AM, Martin Sebor wrote:
> On 06/27/2018 11:20 PM, Jeff Law wrote:
>> On 06/26/2018 05:32 PM, Martin Sebor wrote:
>>> Attached is an updated patch to tighten up the warning and also
>>> prevent ICEs in the middle-end like in PR 86308 or PR 8620
On 06/05/2018 08:13 AM, Olivier Hainque wrote:
> Hello,
>
> The attached patch is a proposal to improve specs processing
> so %* works in spec function arguments (it doesn't as of today).
>
> The immediate motivation is to allow a cleaner implementation of
> the -mmacosx-version-min support on da
On 06/24/2018 08:41 PM, Kugan Vivekanandarajah wrote:
> Hi Jeff,
>
> Thanks for the comments.
>
> On 23 June 2018 at 02:06, Jeff Law wrote:
>> On 06/22/2018 03:11 AM, Kugan Vivekanandarajah wrote:
>>> When we set niter with maybe_zero, currently final_value_relacem
On 07/05/2018 05:54 PM, Martin Sebor wrote:
> GCC folds strlen() calls to empty substrings within arrays
> whose elements are explicitly initialized with NULs but
> fails to do the same for elements that are zeroed out
> implicitly. For example:
>
> const char a[7] = "123\000\000\000";
> int
On 07/05/2018 09:18 PM, Jim Wilson wrote:
> On Thu, Jul 5, 2018 at 12:22 PM, Liviu Ionescu wrote:
>>> On 5 Jul 2018, at 22:17, Jim Wilson wrote:
>>> ... I can fix the gcc config.sub to make it work.
>> Or you can edit `gcc/config.gcc` and trigger an error for `riscv-linux*`.
>
> I added patches
As noted in BZ 86010 we can be more aggressive when trimming tails of
mem* or str* calls in gimple DSE since trimming a tail doesn't affect
alignment and residuals are usually handled pretty efficiently in libc.
Additionally, if the total number of live bytes left is smaller than a
word, then it's
.
Installing on the trunk.
Jeff
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index 8496a38c291..4952b18983f 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,7 @@
+2018-07-05 Jeff Law
+
+ * gcc.dg/tree-ssa/asm-2.c (REGISTER): Override for v850 too
On 07/05/2018 11:39 PM, Richard Biener wrote:
> On July 6, 2018 12:03:11 AM GMT+02:00, Jeff Law wrote:
>> On 06/24/2018 08:41 PM, Kugan Vivekanandarajah wrote:
>>> Hi Jeff,
>>>
>>> Thanks for the comments.
>>>
>>> On 23 June 2018 at 02:0
On 07/06/2018 08:41 AM, Richard Biener wrote:
> On Fri, Jul 6, 2018 at 3:30 PM Tom de Vries wrote:
>>
>> Hi,
>>
>> this patch fixes a sigsegv when using -fdump-tree-all-enumerate_locals, by
>> handling cfun->cfg == NULL conservatively in dump_enumerated_decls.
>>
>> OK for trunk?
>
> Ok for the t
On 07/06/2018 10:20 AM, Richard Sandiford wrote:
> Paul Koning writes:
>> @@ -8615,6 +8639,34 @@ so here's a silly made-up example:
>>"")
>> @end smallexample
>>
>> +There are two special macros defined for use in the preparation statements:
>> +@code{DONE} and @code{FAIL}. Use them with a
On 07/09/2018 08:36 AM, Aldy Hernandez wrote:
>{ dg-do run }
>{ do-options "-O2 -fno-tree-strlen" } */
>
> I don't think this is doing anything.
>
> If you look at the test run you can see that -fno-tree-strlen is never
> passed (I think you actually mean -fno-optimize-strlen for th
On 07/09/2018 01:19 AM, Aldy Hernandez wrote:
>>
>> I'd like decisions about how to expand branches deferred until rtl
>> expansion. Kai was poking at this in the past but never really got any
>> traction.
>
> For the record, the problem in this testcase is that switch lowering is
> riddled with
On 07/06/2018 02:59 PM, Peter Bergner wrote:
> On 7/5/18 2:36 PM, Jeff Law wrote:
>> On 07/02/2018 03:50 PM, Peter Bergner wrote:
>>> I'd like to PING:
>>>
>>> https://gcc.gnu.org/ml/gcc-patches/2018-06/msg01713.html
>>>
>>> I've i
On 07/09/2018 10:38 AM, Richard Earnshaw wrote:
>
> The patches I posted earlier this year for mitigating against
> CVE-2017-5753 (Spectre variant 1) attracted some useful feedback, from
> which it became obvious that a rethink was needed. This mail, and the
> following patches attempt to address
On 07/10/2018 08:25 AM, Richard Biener wrote:
> On Tue, Jul 10, 2018 at 4:10 PM Martin Sebor wrote:
>>
>> On 07/10/2018 01:12 AM, Richard Biener wrote:
>>> On Mon, Jul 9, 2018 at 11:26 PM Martin Sebor wrote:
On 07/09/2018 08:36 AM, Aldy Hernandez wrote:
>{ dg-do run }
>{
On 07/10/2018 07:17 AM, Richard Biener wrote:
> On Tue, Jul 10, 2018 at 3:06 PM Kugan Vivekanandarajah
> wrote:
>>
>> Hi,
>>
>> Jeff told me that the recent popcount built-in detection is causing
>> kernel build issues as
>> ERROR: "__popcountsi2"
>> [drivers/net/wireless/broadcom/brcm80211/brcmfm
On 07/10/2018 07:27 AM, Jakub Jelinek wrote:
> On Tue, Jul 10, 2018 at 03:17:48PM +0200, Richard Biener wrote:
>> On Tue, Jul 10, 2018 at 3:06 PM Kugan Vivekanandarajah
>>> Jeff told me that the recent popcount built-in detection is causing
>>> kernel build issues as
>>> ERROR: "__popcountsi2"
>>>
On 07/10/2018 02:49 AM, Richard Earnshaw (lists) wrote:
> On 10/07/18 00:13, Jeff Law wrote:
>> On 07/09/2018 10:38 AM, Richard Earnshaw wrote:
>>>
>>> To address all of the above, these patches adopt a new approach, based
>>> in part on a posting by Chandler
On 07/10/2018 08:14 AM, Richard Earnshaw (lists) wrote:
> On 10/07/18 14:48, Bill Schmidt wrote:
>>
>>> On Jul 10, 2018, at 3:49 AM, Richard Earnshaw (lists)
>>> wrote:
>>>
>>> On 10/07/18 00:13, Jeff Law wrote:
>>>> On 07/09/2018 10
On 07/10/2018 04:53 AM, Richard Earnshaw (lists) wrote:
> On 10/07/18 11:10, Richard Biener wrote:
>> On Tue, Jul 10, 2018 at 10:39 AM Richard Earnshaw (lists)
>> wrote:
>>>
>>> On 10/07/18 08:19, Richard Biener wrote:
On Mon, Jul 9, 2018 at 6:39 PM Richard Earnshaw
wrote:
>
>
>
On 07/08/2018 06:03 PM, Paul Koning wrote:
> In doing CCmode work I was confused how define_subst handles cases where the
> same argument appears more than once. The attached clarifies this.
>
> Ok for trunk?
>
> paul
>
> ChangeLog:
>
> 2018-07-08 Paul Koning
>
> * doc/md.texi
On 07/10/2018 05:14 AM, Aldy Hernandez wrote:
> I believe I missed this companion patch when I submitted...
>
> Subject: jump threading multiple paths that start from the same BB
>
> The attached patch changes thread_through_all_blocks to allow threads
> that start from the same basic block as
On 07/10/2018 10:50 AM, Paul Koning wrote:
> "mode" is documented as a variable attribute but not as a type attribute.
> This fixes that omission. I simply copied the other text, it seemed suitable
> as it stands.
>
> The attributes are normally listed in alphabetical order but "mode" was out
| |
>
>
> Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
> Target was tested with stack clash on and off by default.
>
> Ok for trunk?
>
> Thanks,
> Tamar
>
>
| |
>
>
> Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
> Target was tested with stack clash on and off by default.
>
> Ok for trunk?
>
> Thanks,
> Tamar
>
>
On 07/11/2018 05:21 AM, Tamar Christina wrote:
> Hi All,
>
> This patch adds a hook to tell the mid-end about the probing requirements of
> the
> target. On AArch64 we allow a specific range for which no probing needs to
> be done. This same range is also the amount that will have to be probed
On 07/11/2018 05:22 AM, Tamar Christina wrote:
> Hi All,
>
> This patch defines a configure option to allow the setting of the default
> guard size via configure flags when building the target.
>
> The new flag is:
>
> * --with-stack-clash-protection-guard-size=
>
> The value of configured bas
On 07/11/2018 05:24 AM, Tamar Christina wrote:
> Hi All,
>
> This patch adds the ability for backends to add custom constrains to the param
> values by defining a new hook option_validate_param.
>
> This hook is invoked on every set_param_value which allows the back-end to
> ensure that the param
On 07/11/2018 05:24 AM, Tamar Christina wrote:
> Hi All,
>
> This patch builds on a previous patch to pass param options down from
> configure
> by adding more expansive validation and correctness checks.
>
> These are set very early on and allow the target to validate or reject the
> values as
On 07/07/2018 02:15 AM, Jakub Jelinek wrote:
> Hi!
>
> On Fri, Jul 06, 2018 at 12:47:07PM +0200, Jakub Jelinek wrote:
>> On Thu, Jul 05, 2018 at 11:57:26PM +0300, Grazvydas Ignotas wrote:
>>> I think it would be more efficient if you took care of it. I won't
>>> have time for at least a few days a
On 07/10/2018 10:43 AM, Richard Earnshaw (lists) wrote:
> On 10/07/18 16:42, Jeff Law wrote:
>> On 07/10/2018 02:49 AM, Richard Earnshaw (lists) wrote:
>>> On 10/07/18 00:13, Jeff Law wrote:
>>>> On 07/09/2018 10:38 AM, Richard Earnshaw wrote:
>>>>>
>
On 07/09/2018 10:38 AM, Richard Earnshaw wrote:
> This patch is the main part of the speculation tracking code. It adds
> a new target-specific pass that is run just before the final branch
> reorg pass (so that it can clean up any new edge insertions we make).
> The pass is only run with -mtrack-
On 07/11/2018 02:07 PM, Steve Ellcey wrote:
> I have a reload/register allocation question and possible patch. While
> working on the Aarch64 SIMD ABI[1] I ran into a problem where GCC was
> saving and restoring registers that it did not need to. I tracked it
> down to lra-constraints.c and its u
On 07/12/2018 02:41 AM, Christophe Lyon wrote:
> Hi,
>
> It can be useful to print the number of tests in each category, eg:
> Tests that now work, but didn't before (65 tests):
> instead of
> Tests that now work, but didn't before:
>
> This small patch does that.
>
> OK?
>
> Thanks,
>
> Chris
On 07/11/2018 06:20 PM, Paul Koning wrote:
> This patch removes the obsolete documentation for
> decrement_and_branch_until_zero. It also adds detail to the description for
> doloop_end. In particular, it describes the required form of the conditional
> branch part of the pattern.
>
> Ok for
On 07/11/2018 04:03 PM, Qing Zhao wrote:
> Hi, This is the 3rd version of the patch for the last part of PR78809.
>
> the major change in this version is to address the following concerns raised
> by Martin:
>
>> One of the basic design principles that I myself have
>> accidentally violated in
On 07/11/2018 07:11 AM, Richard Biener wrote:
>
> The following fixes PR86452 by using scope_die_for which correctly
> deals with -g1 in not creating (new) DIEs for namespaces. With
> a larger LTO testcase we run into this with a namespace DIE not
> readily available but I'm not sure the issue is
On 07/06/2018 06:08 AM, Christophe Lyon wrote:
> Hi Jeff,
>
> On Fri, 6 Jul 2018 at 05:44, Jeff Law wrote:
>>
>> As noted in BZ 86010 we can be more aggressive when trimming tails of
>> mem* or str* calls in gimple DSE since trimming a tail doesn't affect
>&g
On 07/12/2018 11:17 AM, Paul Koning wrote:
>
>
>> On Jul 12, 2018, at 12:55 PM, Jeff Law wrote:
>>
>> On 07/11/2018 06:20 PM, Paul Koning wrote:
>>> This patch removes the obsolete documentation for
>>> decrement_and_branch_until_zero. It also adds de
On 07/12/2018 11:39 AM, Tamar Christina wrote:
>>> +
>>> + /* Round size to the nearest multiple of guard_size, and calculate the
>>> + residual as the difference between the original size and the rounded
>>> + size. */
>>> + HOST_WIDE_INT rounded_size = size & -guard_size;
>>> + HOST_WI
gcc/ChangeLog
index 9179987e98c..c9e3f0b956d 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,9 @@
+2018-07-15 Jeff Law
+
+ PR target/85993
+ * config/sh/sh.c (output_mi_thunk): Remove dead conditional
+ block.
+
2018-07-14 Jim Wilson
* config/riscv/linux.h (TARGET
On 07/13/2018 05:09 PM, Martin Sebor wrote:
>>> + /* At level 2 check also intermediate offsets. */
>>> + int i = 0;
>>> + if (extrema[i] < -strbounds[1]
>>> + || extrema[i = 1] > strbounds[1] + eltsize)
>>> + {
>>> + HOST_WIDE_INT tmpidx = extrema[i].to_shwi () / eltsize.to_shwi
>
On 07/16/2018 07:54 AM, Tamar Christina wrote:
> The 07/13/2018 17:46, Jeff Law wrote:
>> On 07/12/2018 11:39 AM, Tamar Christina wrote:
>>>>> +
>>>>> + /* Round size to the nearest multiple of guard_size, and calculate the
>>>>> + residu
On 07/16/2018 12:30 PM, Bill Schmidt wrote:
> Hi,
>
> I occasionally get questions about powerpc64le-linux-gnu being a primary
> platform
> for GCC, since the release criteria don't specifically call it out (see
> https://gcc.gnu.org/gcc-8/criteria.html). Currently powerpc64-linux-gnu (for
> big
On 07/16/2018 02:41 PM, Jakub Jelinek wrote:
> Hi!
>
> builtin_memcpy_read_str is a function meant to be called just as a callback
> and verifies that we don't cross a '\0' boundary in the string. For
> inline_string_cmp, we've checked that the length returned from c_getstr
> is fine, so we can c
On 07/04/2018 04:23 AM, marxin wrote:
> gcc/ChangeLog:
>
> 2018-07-11 Martin Liska
>
> * align.h: New file.
> * config/alpha/alpha.c (alpha_align_insns_1): Use align_functions
> directly.
> * config/i386/i386.c (ix86_avoid_jump_mispredicts): Use new return type
> align
On 07/05/2018 08:48 AM, Thomas Preudhomme wrote:
> In case of high register pressure in PIC mode, address of the stack
> protector's guard can be spilled on ARM targets as shown in PR85434,
> thus allowing an attacker to control what the canary would be compared
> against. ARM does lack stack_prote
On 07/17/2018 09:19 AM, Martin Sebor wrote:
> My enhancement to extract constant strings out of complex
> aggregates committed last week introduced a couple of bugs in
> dealing with non-constant indices and offsets. One of the bugs
> was fixed earlier today (PR 86528) but another one remains. It
+1,8 @@
+2018-07-17 Jeff Law
+
+ * config/nios2/nios2.c (nios2_label_align): Update for recent
+ changes which dropped ALIGN_LABELS_LOG.
+
2018-07-17 Andreas Schwab
* config/m68k/m68k.md (umulsi3_highpart+1, const_umulsi3_highpart)
diff --git a/gcc/config/nios2/nios2.c b
More fallout from the alignment changes. This time in frv_align_label.
Committed to the trunk.
jeff
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index d8057a074a1..51e91221147 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,5 +1,8 @@
2018-07-17 Jeff Law
+ * config/frv/frv.c
On 07/17/2018 02:23 AM, Richard Biener wrote:
>
> This cures the ICEs and wrong assembler that currently happen when
> using -flto with -gdwarf-5. gdb is also happy with small test programs
> but readelf is still complaining (see PR, I have no clue what goes
> wrong).
>
> Bootstrapped on x86_64-
Similar to the others...
Committed to the trunk.
Jeff
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 51e91221147..ac4abdaf1ba 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,5 +1,8 @@
2018-07-17 Jeff Law
+ * config/mips/mips.c (vr4130_align_insns): Update for recent
101 - 200 of 15555 matches
Mail list logo
