On 10/31/23 18:05, Vineet Gupta wrote:
On 10/30/23 13:33, Jeff Law wrote:
+/* Helper function for riscv_extend_comparands to Sign-extend the OP.
+ However if the OP is SI subreg promoted with an inner DI, such as
+ (subreg/s/v:SI (reg/v:DI) 0
+ just peel off the SUBREG to get DI
On 10/31/23 17:41, Palmer Dabbelt wrote:
On Tue, 31 Oct 2023 16:18:35 PDT (-0700), jeffreya...@gmail.com wrote:
On 10/31/23 12:35, Vineet Gupta wrote:
riscv_promote_function_mode doesn't promote a SI to DI for libcalls
case.
The fix is what generic promote_mode () in explow.cc does. I rea
On 11/1/23 08:11, Eric Gallager wrote:
Hi, I'd like to ping the following patch:
https://gcc.gnu.org/pipermail/gcc-patches/2023-October/633191.html
OK for the trunk.
jeff
On 11/1/23 12:17, Edwin Lu wrote:
Now that all insns are guaranteed to have a type, ensure every insn
is associated with a cpu unit/insn reservation.
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_sched_variable_issue): add disabled
assert
OK. Really interested to see how often this
On 11/1/23 10:14, Patrick O'Neill wrote:
Other subword atomic patterns use riscv_subword_address to calculate
the aligned address, shift amount, mask and !mask. atomic_test_and_set
was implemented before the common function was added. After this patch
all subword atomic patterns use riscv_subw
On 11/1/23 00:56, Juzhe-Zhong wrote:
Consider this following intrinsic code:
void rvv_dot_prod(int16_t *pSrcA, int16_t *pSrcB, uint32_t n, int64_t *result)
{
size_t vl;
vint16m4_t vSrcA, vSrcB;
vint64m1_t vSum = __riscv_vmv_s_x_i64m1(0, 1);
while (n > 0) {
vl = _
On 10/31/23 17:25, Patrick O'Neill wrote:
This patch transitions the ztso testcases to use the testsuite infrastructure,
enabling the tests on both rv64 and rv32 targets.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/amo-table-ztso-amo-add-1.c: Add Ztso extension to
dg-options
On 10/31/23 12:35, Vineet Gupta wrote:
riscv_promote_function_mode doesn't promote a SI to DI for libcalls
case.
The fix is what generic promote_mode () in explow.cc does. I really
don't understand why the old code didn't work, but stepping thru the
debugger shows old code didn't and fixed do
xtractions from the low byte, HImode sign bit and top two bits of SImode.
Regression tested on the H8 with no regressions. Installing on the trunk.
Jeffcommit 0f9f3fc885a1f830ff09a095e8c14919c2796a9d
Author: Jeff Law
Date: Thu Nov 2 07:25:39 2023 -0600
[committed] Improve H8 sequences for
On 11/3/23 06:54, Maxim Kuvyrkov wrote:
The only difference compared to v1 is using vanilla automake 1.15.1
to regenerate Makefile.in.
I'll merge this as obvious if no-one objects in a day.
===
... to restore compatability with validate_failures.py .
The testsuite script validate_failures.py
On 11/6/23 06:18, Kito Cheng wrote:
Oh, you're right! I should have checked the master branch first... and
I was even wondering why it wasn't marked as such. Should perhaps
cherry pick this for gcc-13-with-riscv-opts?
gcc-13-with-riscv-opts mostly maintained by Ventana folks, so maybe
ask
On 5/16/23 19:29, Palmer Dabbelt wrote:
I think the most pressing need is bleeding edge gcc regression tracking.
@Jeff is anything setup on sourceware and/or usable ? I thought they
do have existing bots for some arches to spin up build / run - perhaps
runs are native and not qemu.
IIRC
On 5/16/23 20:08, Vineet Gupta wrote:
I think the most pressing need is bleeding edge gcc regression tracking.
@Jeff is anything setup on sourceware and/or usable ? I thought they
do have existing bots for some arches to spin up build / run - perhaps
runs are native and not qemu.
IIRC J
On 5/24/23 17:12, Vineet Gupta wrote:
On 5/24/23 15:13, Vineet Gupta wrote:
PASS: gcc.target/riscv/zmmul-2.c -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects (test for excess errors)
PASS: gcc.target/riscv/zmmul-2.c -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects scan-assembl
On 5/24/23 21:53, Kito Cheng wrote:
Jojo has a patch to try to split those things that should help this,
but seems not landed.
https://patchwork.ozlabs.org/project/gcc/patch/20201104015315.81416-1-jiejie_r...@c-sky.com/
Is JoJo still active? I haven't heard from JoJo in many months, perhaps
On 5/24/23 21:54, juzhe.zh...@rivai.ai wrote:
>> IIRC LLVM is using the table driven mechanism, so it's less impact
on the
compilation time when the instruction becomes more and more.
Oh, I see. Could you share more details ?
Maybe we can support this in GCC.
It's highly unlikely we'll swit
On 5/24/23 22:19, juzhe.zh...@rivai.ai wrote:
>> It's highly unlikely we'll switch from the mechanisms we're using.
They're pretty deeply embedded into how all the ports are developed and
work.
We just take a look at the build file. It seems that the functions
generated by define_insn
ar
ll probably spend some time to
try and chase this down for the sake of making testing easier.
OK for the trunk?
Jeff
commit f9a9119fa47f94348305a883fd88c23647fb1b07
Author: Jeff Law
Date: Sun Sep 25 12:23:59 2022 -0400
gcc/
* cfgcleanup.cc (bb_is_
Committed to the trunk.
commit 1b5432b401934962affe32cd7e42e864224e8062
Author: Jeff Law
Date: Mon Sep 26 09:14:55 2022 -0600
Update my address and DCO entry in MAINTAINERS file
/
* MAINTAINERS: Update my email address and DCO entry.
diff --git a/MAINTAINERS b
Updates my affiliation on the web pages.
Committed to the trunk.
Jeff
commit 57e71fb18e8fa397336266f105a22f45f0fa7704
Author: Jeff Law
Date: Mon Sep 26 09:19:36 2022 -0600
Update my affiliation on the steering committee page.
diff --git a/htdocs/steering.html b/htdocs/steering.html
ssion testing in progress). Verified this
fixes the v850 and rl78 build failures. Installing on the trunk
momentarily.
Jeff
commit fe527a06a77093bc3de4ee2007516a4e9fa30f18
Author: Jeff Law
Date: Tue Sep 27 01:44:38 2022 -0400
Fix ICEs due to recent jump-to-return optimization
This is another minor improvement to coremark. I suspect this only
improves code size as the load-immediate was likely issuing with the ret
statement on multi-issue machines.
Basically we're failing to utilize conditional equivalences during the
post-reload CSE pass. So if a particular b
n't currently exist for a given edge.
Bootstrapped and regression tested on x86_64. Installing on the trunk.
Jeff
commit fbd95c027edcc169cc3b40806375fbabc08500e0
Author: Jeff Law
Date: Fri Sep 30 18:59:24 2022 -0400
Minor cleanup/prep in DOM
It's a bit weird tha
prepared to handle
equivalences on edges.
Pushed to the trunk,
Jeff
commit 1214196da79aabbe5c14ed36e5a28012e141f04c
Author: Jeff Law
Date: Fri Sep 30 19:26:31 2022 -0400
More gimple const/copy propagation opportunities
While investigating a benchmark for optimization opportunities I ca
On 9/30/22 18:07, H.J. Lu wrote:
On Fri, Sep 30, 2022 at 4:06 PM Jeff Law wrote:
It's a bit weird that free_dom_edge_info leaves a dangling pointer in
e->aux. Not sure what I was thinking.
There's two callers. One wipes e->aux immediately after the call, the
other
On 10/7/22 04:51, Franz Sirl wrote:
Am 2022-09-25 um 18:28 schrieb Jeff Law:
This is a minor improvement for the core_list_find routine in coremark.
Basically for riscv, and likely other targets, we can end up with an
unconditional jump to a return statement. This is a result of
Just a couple more comments in-line.
On 10/18/22 09:18, Manolis Tsamis wrote:
+/* Implement TARGET_SHRINK_WRAP_GET_SEPARATE_COMPONENTS. */
+
+static sbitmap
+riscv_get_separate_components (void)
+{
+ HOST_WIDE_INT offset;
+ sbitmap components = sbitmap_alloc (FIRST_PSEUDO_REGISTER);
+ bi
On 11/2/22 08:12, Manolis Tsamis wrote:
On Wed, Oct 19, 2022 at 8:16 PM Jeff Law via Gcc-patches
wrote:
On 10/18/22 11:35, Palmer Dabbelt wrote:
I would have expected things to work fine with libcalls, perhaps with
the exception of the save/restore libcalls. So that needs deeper
On 11/2/22 07:54, Manolis Tsamis wrote:
I've revisited this testcase and I think it's not possible to make it
work with the current implementation.
It's not possible to trigger shrink wrapping in this case since the
wrapping of registers is guarded by
if (SMALL_OPERAND (offset)) { bitmap_set
On 10/23/19 9:07 AM, Jan Hubicka wrote:
> Hi,
> this patch reduces inline-heuristics-hint-percent so inliner behaves
> more similarly to what it did before I introduced this param.
>
> Bootstrapped/regtested x86_64-linux, comitted.
> I plan to do more tuning on this parameter, but the value of 160
On 10/25/19 2:35 AM, Tobias Burnus wrote:
> On 9/26/19 10:45 AM, Mark Eggleston wrote:
>> Original thread starts here
>> https://gcc.gnu.org/ml/gcc-patches/2019-09/msg01185.html
>> OK to commit?
>
> As Steve, I am not really happy about adding yet another option and
> especially not about legacy f
On 10/25/19 7:54 AM, Tobias Burnus wrote:
> Hi Jeff,
>
> On 10/25/19 3:22 PM, Jeff Law wrote:
>> So across Fedora the BOZ stuff tripped 2-3 packages. In comparison the
>> function argument stuff broke 30-40 packages, many of which still
>> don't build w
Ugh. I should have caught this earlier.
My Fedora tester failed recently on the "flatbuffers" package. It
worked on Oct 6th GCC snapshot, but was failing by Oct 13th snapshot.
Bisection ultimately landed on:
> commit d9d534895b775a453b8d8d291ef72d6dfa5f9e52 (HEAD, refs/bisect/bad)
> Author: ms
On 10/25/19 9:47 AM, Wilco Dijkstra wrote:
> GCC currently defaults to -fcommon. As discussed in the PR, this is an
> ancient
> C feature which is not conforming with the latest C standards. On many
> targets
> this means global variable accesses have a codesize and performance penalty.
> This
On 10/25/19 11:39 AM, Craig Blackmore wrote:
> This patch aims to allow more load/store instructions to be compressed by
> replacing a load/store of 'base register + large offset' with a new load/store
> of 'new base + small offset'. If the new base gets stored in a compressed
> register, then the
On 10/25/19 3:10 AM, Martin Liska wrote:
>
> gcc/ChangeLog:
>
> 2019-10-25 Martin Liska
>
> * ggc-common.c: Move Leak to the first column.
OK
jeff
On 10/25/19 7:21 AM, Martin Liška wrote:
> Hi.
>
> And there's one more integer overflow fix.
>
> Martin
>
>
> 0001-Fix-unsigned-type-overflow-in-memory-report.patch
>
> From 35c22704dc705508672f19b09e6d1b94bd956535 Mon Sep 17 00:00:00 2001
> From: Martin Liska
> Date: Fri, 25 Oct 2019 15:09:
On 10/25/19 3:32 AM, Martin Liska wrote:
>
> gcc/ChangeLog:
>
> 2019-10-25 Martin Liska
>
> * cgraphunit.c (symbol_table::compile): Pass
> title as dump_memory_report argument.
> * toplev.c (dump_memory_report): New argument.
> (finalize): Pass new argument.
> *
On 10/25/19 6:24 AM, Jozef Lawrynowicz wrote:
> Where possible, it is always desirable to use 430 format instructions when
> compiling for the 430X ISA and the large memory model. 430 instructions have
> reduced code size and faster execution time.
>
> This patch recognizes a couple of new pattern
On 10/26/19 1:10 PM, Oleg Endo wrote:
> On Sat, 2019-10-26 at 12:21 -0600, Jeff Law wrote:
>> On 10/25/19 11:39 AM, Craig Blackmore wrote:
>>> This patch aims to allow more load/store instructions to be
>>> compressed by
>>> replacing a load/store of '
On 10/26/19 1:33 PM, Andrew Waterman wrote:
> I don't know enough to say whether the legitimize_address hook is
> sufficient for the intended purpose, but I am sure that RISC-V's
> concerns are not unique: other GCC targets have to cope with
> offset-size constraints that are coupled to register-al
On 10/18/19 3:06 AM, Ilya Leoshkevich wrote:
> Bootstrapped and regtested on x86_64-redhat-linux, s390x-redhat-linux
> and ppc64le-redhat-linux. The offending patch is in gcc-9_1_0-release
> and gcc-9_2_0-release - do I need to backport this fix to gcc-9-branch?
>
>
> r266734 has introduced a ne
On 10/23/19 11:37 AM, Jozef Lawrynowicz wrote:
> For MSP430 in some configurations, GCC will generate code for mulhisi3 by
> inserting instructions to widen each 16-bit operand before calling a library
> routine for mulsi3.
> However, there exists a hardware multiply routine to perform this widenin
On 10/5/19 5:29 AM, Richard Sandiford wrote:
>
> Sure. This message is going to go to the other extreme, sorry, but I'm
> not sure which part will be the most convincing (if any).
No worries. Worst case going to the other extreme is I have to read it
more than once after nodding off halfway thro
On 9/29/19 1:51 PM, Martin Sebor wrote:
> -Wstringop-overflow detects a subset of past-the-end read and write
> accesses by built-in functions such as memcpy and strcpy. It relies
> on the functions' effects the knowledge of which is hardwired into
> GCC. Although it's possible for users to creat
On 10/1/19 11:16 AM, Martin Sebor wrote:
> Attached is an implementation of the __has_builtin special
> preprocessor operator/macro analogous to __has_attribute and
> (hopefully) compatible with the synonymous Clang feature (I
> couldn't actually find tests for it in the Clang test suite
> but if s
On 10/11/19 6:01 AM, Mihailo Stojanovic wrote:
> Currently, when a function argument of type double gets loaded into a
> vector register on a 32-bit target, it is firstly reloaded into two
> general purpose registers, and then loaded into a vector register using
> two insert.w instructions.
>
> Th
On 10/18/19 12:10 AM, Mihailo Stojanovic wrote:
> Mips built-in functions are currently not marked as pure, which
> invalidates pointers across built-in function calls. If a pointer is
> alive across built-in call, dereferencing it before and after the call
> will generate two load instructions ins
On 10/19/19 10:35 PM, Ian Lance Taylor wrote:
> On Sat, Oct 19, 2019 at 9:11 PM Miguel Saldivar
> wrote:
>>
>> Updated patch that uses `_Complex` and `_Imaginary`
>>
>> Thanks,
>> Miguel Saldivar
>>
>> From 742b37c88bea0118046ac359cabe5f250d69ee30 Mon Sep 17 00:00:00 2001
>> From: Miguel Saldivar
On 10/21/19 4:57 AM, Mihailo Stojanovic wrote:
> This expands the existing MIPS mulditi3 pattern by adding support for
> MIPS64R6 multiplication instructions.
>
> gcc/ChangeLog:
>
> * config/mips/mips.md (mulditi3): Generate patterns for high
> doubleword and low doubleword result
On 10/22/19 2:10 AM, Claudiu Zissulescu wrote:
> Hi Andrew,
>
> There are cases when an pic address gets complicated, and it needs to
> be resolved via force_reg function found in
> prepare_move_operands. When this happens, we need to disambiguate the
> pic address and re-legitimize it. Testcase a
On 10/22/19 2:13 AM, Claudiu Zissulescu wrote:
> From: Shahab Vahedi
>
> Hi Andrew,
>
> The movsi_ne variants are in a wrong order, leading to wrong
> computation of the internal attribute "cond". Hence, to errors when
> outputting annul-true or annul-false instructions. Testcase added.
>
> The
On 10/28/19 1:43 PM, Richard Biener wrote:
> On October 28, 2019 7:43:33 PM GMT+01:00, David Edelsohn
> wrote:
Has this been bootstrapped and regression tested?
>>>
>>> Yes, it bootstraps OK of course. I ran regression over the weekend,
>> there
>>> are a few minor regressions in lto due to
On 10/28/19 2:29 PM, Martin Sebor wrote:
> A recent enhancement to take advantage of non-constant strlen
> results constrained to a known range interacts badly with
> the nul-over-nul optimization. The optimization eliminates
> nul stores that overwrite the exiting terminating nul of
> the destina
On 10/28/19 4:36 PM, Martin Sebor wrote:
> While testing the patch for PR 92226 I posted earlier today
> I ran into a few cases where I expected the strlen range
> optimization to take place but it didn't.
>
> In other instances this wouldn't be surprising because
> the optimization was only intro
On 9/26/19 6:05 AM, Richard Sandiford wrote:
> Similarly to the simulate_builtin_function_decl patch, this one
> adds a hook for simulating an enum declaration in the source
> language. Again, the main SVE ACLE patch has tests for various
> error conditions.
>
> Tested on aarch64-linux-gnu and x8
On 10/29/19 6:26 AM, John Paul Adrian Glaubitz wrote:
> Hello!
>
> We have raised $5000 to support anyone willing to work on this for the
> m68k target [1]. We really need the m68k to stay as it's essential to
> be able to compile for Linux/m68k, NetBSD/m68k and AROS/m68k (a new
> and ABI-compatib
On 10/25/19 7:38 AM, Martin Liska wrote:
>
> gcc/ChangeLog:
>
> 2019-10-25 Martin Liska
>
> * cgraph.c (cgraph_node::local_info): Transform to ...
> (cgraph_node::local_info_node): ... this.
> (cgraph_node::dump): Remove cgraph_local_info and
> put its fields directly
On 10/30/19 11:52 AM, Gunther Nikl wrote:
> Richard Sandiford wrote:
>> FWIW it's already possible to do the transform you mention with:
>>
>> s/(cc0)/(reg:CC CC_REGNUM_RC)/g
>>
>> (define_int_iterator CC_REGNUM_RC [(CC_REGNUM "reload_completed")])
>
> Since "reload_completed" is referenced,
On 10/30/19 11:57 AM, John Paul Adrian Glaubitz wrote:
> On 10/30/19 6:52 PM, Gunther Nikl wrote:
>> Richard Sandiford wrote:
>>> FWIW it's already possible to do the transform you mention with:
>>>
>>> s/(cc0)/(reg:CC CC_REGNUM_RC)/g
>>>
>>> (define_int_iterator CC_REGNUM_RC [(CC_REGNUM "relo
On 10/30/19 2:12 AM, Richard Biener wrote:
> On Tue, Oct 29, 2019 at 8:34 PM Jeff Law wrote:
>
> I think the wiki has better examples. That said, I wonder how much can
> be automated here, for example when just considering CCmode (m68k has
> setcc IIRC) then for example all de
On 10/30/19 4:06 PM, Joseph Myers wrote:
> On Wed, 30 Oct 2019, Joseph Myers wrote:
>
>> This appears to have broken the build for Arm.
>
> And probably bfin and c6x as well, based on grep, but my bot only covers
> glibc targets so doesn't test those.
>
bfin and c6x are definitely affected. My
On 10/8/19 5:51 PM, Martin Sebor wrote:
> Attached is a resubmission of the -Wrestrict implementation for
> the sprintf family of functions. The original patch was posted
> in 2017 but never approved. This revision makes only a few minor
> changes to the original code, mostly necessitated by reba
On 10/30/19 3:58 AM, Claudiu Zissulescu wrote:
> Hi Jeff,
>
>> So I'm going to have to trust you on this one. It looks like you did
>> more than just reorder the alternatives. For example, the constraints
>> for operand0 look significantly different to me. THey're slightly
>> different for oper
On 10/11/19 10:34 AM, Martin Sebor wrote:
> I've fixed the bug in the attached patch. The rest can be suppressed
> by replacing the zero-length arrays with flexible array members but
> that's just trading one misuse for another. If the code can't be
> changed to avoid this (likely not an option s
On 10/30/19 9:07 AM, Mihailo Stojanović wrote:
> Hello Jeff,
>
> I already have write access on this e-mail address (but not on
> the @wavecomp.com address, which you have been putting
> into ChangeLogs), so I guess I could commit any further patches
> that get approved.
OK. I'll let you commit t
On 11/1/19 1:49 AM, Tobias Burnus wrote:
> On 10/31/19 11:16 PM, Steve Kargl wrote:
>
>> Jeff Law sent me an email … caused a regression for fixed-form
>> source code.
>
> Interesting, what kind of code is used in the real world!
It's from the dl_poly package in
On 11/1/19 9:08 AM, Marek Polacek wrote:
> On Fri, Nov 01, 2019 at 04:01:12PM +0100, Romain Geissler wrote:
>> Le mar. 22 oct. 2019 à 14:53, Richard Biener a écrit :
>>>
>>> Please make sure to get features intended for GCC 10 finished
>>> and reviewed before the end of stage 1.
>>>
>>
>> Hi,
>>
>
On 10/31/19 10:01 AM, Martin Liška wrote:
> Hi.
>
> operand_equal_p can properly handle situation where we have a CONSTRUCTOR
> where indices are NULL:
>
> if (!operand_equal_p (c0->value, c1->value, flags)
> /* In GIMPLE the indexes can be either NULL or matching i.
>
On 11/1/19 4:53 AM, Jozef Lawrynowicz wrote:
> Each different MSP430 MCU has two properties that affect code generation,
> which
> are the the CPU ISA and the hardware multiply support. These can be manually
> specified with the -mcpu= and -mhwmult= options, respectively.
> The existing -mmcu= opt
On 10/30/19 9:01 AM, Martin Liška wrote:
> Hi.
>
> There's a small code refactoring.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
> Thanks,
> Martin
>
>
> 0001-Come-up-with-ggc_delete.patch
>
> From dc92c8c3e31887b23ef419bc60e3c1607d0e9
On 10/24/19 2:56 PM, Jozef Lawrynowicz wrote:
> I added support for reduced code size printf and puts functions to Newlib for
> MSP430 a while ago [1]. By removing support for reentrancy, streams and
> buffering we can greatly reduce code size, which is always often a limitation
> when using printf
On 10/25/19 11:02 AM, Delia Burduv wrote:
> Hello Jeff,
>
> Yes, it is a backport to gcc-8. No, I don't have commit access. Could
> you please commit it for me?
Done.
Thanks for your patience.
jeff
On 11/4/19 6:35 AM, Richard Biener wrote:
> On Mon, Nov 4, 2019 at 10:09 AM Martin Liška wrote:
>>
>> On 11/1/19 10:51 PM, Jeff Law wrote:
>>> On 10/31/19 10:01 AM, Martin Liška wrote:
>>>> Hi.
>>>>
>>>> operand_equal_p can properly han
On 11/4/19 6:36 AM, Richard Biener wrote:
> On Mon, Nov 4, 2019 at 2:35 PM Richard Biener
> wrote:
>>
>> On Mon, Nov 4, 2019 at 10:09 AM Martin Liška wrote:
>>>
>>> On 11/1/19 10:51 PM, Jeff Law wrote:
>>>> On 10/31/19 10:01 AM, Martin Liška
On 11/3/19 5:12 AM, Oleg Endo wrote:
> On Fri, 2019-10-11 at 23:27 +0900, Oleg Endo wrote:
>> On Thu, 2019-10-03 at 19:34 -0600, Jeff Law wrote:
>>>
>>> So probably the most interesting target for this test is v850-elf
>>> as
>>> it's got a reaso
On 11/4/19 7:40 AM, Richard Sandiford wrote:
> The SVE port now tries to register variable-length VECTOR_TYPEs
> at start-up, so it's no longer possible to use the asserting
> to_constant on the number of vector elements. This patch punts
> on variable element counts instead, just like we do for o
On 11/3/19 8:29 PM, luoxhu wrote:
> -finline-functions is enabled by default for O2 since r276469, update the
> test cases with -fno-inline-functions.
>
> v2: disable inlining for the failed cases. Add two more failed cases
> not listed in BZ. Tested on P8LE, P8BE and P9LE.
>
>
> gcc/testsuite
On 11/4/19 3:05 PM, Martin Sebor wrote:
> While testing some other changes I noticed that -Warray-bounds
> fails to detect out-of-bounds indices to compound literals such
> as in:
>
> int *p = (int[]){ 1, 2, 3 };
> // ...
> p[3] = 7;
>
> This is because SRA transforms such references into a
On 10/31/19 5:41 PM, Jim Wilson wrote:
> The RISC-V backend wants to use a libcall when optimizing for size if
> more than 6 instructions are needed. Emit_move_complex asks for no
> libcalls. This case requires 8 insns for rv64 and 16 insns for rv32,
> so we get fallback code that emits a loop.
On 10/22/19 2:21 AM, Claudiu Zissulescu wrote:
> Cleanup sign/zero extend patterns (corrects the asm output string and
> constraint letters).
>
> gcc/
> -xx-xx Claudiu Zissulescu
>
> * config/arc/arc.md (zero_extendqihi2_i): Cleanup pattern.
> (zero_extendqisi2_ac): Likewise.
On 10/22/19 2:21 AM, Claudiu Zissulescu wrote:
> Update -mea option documentation.
>
> gcc/
> -xx-xx Claudiu Zissulescu
>
> * config/arc/arc.opt (mea): Update help string.
> * doc/invoke.texi(ARC): Update mea option info.
OK
jeff
On 10/22/19 2:21 AM, Claudiu Zissulescu wrote:
> Do not split immediate constants for predicated instructions.
>
> gcc/
> -xx-xx Claudiu Zissulescu
>
> * config/arc/arc.c (arc_split_ior): Add asserts.
> (arc_split_mov_const): Likewise.
> (arc_check_ior_const): Do not matc
On 11/4/19 8:26 PM, Martin Sebor wrote:
> -Warray-bounds doesn't yet have the logic to detect out-of-bounds
> indices into dynamically allocated arrays like VLAs because it
> doesn't track allocation calls. But the warning could detect
> such errors in accesses to VLAs with constant sizes even wit
On 11/5/19 5:00 PM, Martin Sebor wrote:
> After considering more instances of the enhanced -Warray-bounds
> and the new -Wzero-length-array-bounds warnings I realized that
> there are some where the former is being issued for zero-length
> arrays but where the latter would be more appropriate.
>
>
On 11/6/19 8:00 AM, Segher Boessenkool wrote:
> This introduces simplify_logical_relational_operation. Currently the
> only thing implemented it can simplify is the IOR of two CONDs of the
> same arguments.
>
> Tested on powerpc64-linux {-m32,-m64}.
>
> Is this okay for trunk?
>
>
> Segher
>
On 11/6/19 2:22 AM, Martin Liška wrote:
> On 11/5/19 11:40 AM, Jan Hubicka wrote:
>> + print " if (ptr->" name")";
>> + print " free (const_cast (ptr->" name"));";
>
> If I'm correct, you can call free even for a NULL pointer.
You can and I think we expunged all the NULL tests before cal
On 11/5/19 6:21 AM, Aldy Hernandez wrote:
> The base class for ranges is currently value_range_base, which is rather
> long and cumbersome. It also occurs more often than the derived class
> of value_range. To avoid confusion, and save typing, this patch does a
> global rename from value_range to
On 11/5/19 8:12 AM, Martin Liška wrote:
> Hi.
>
> When calling delete_function_version, we should also clear
> version_info_node once it can be seen GGC collect.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
> Thanks,
> Martin
>
> gcc/Chan
On 11/6/19 11:00 AM, Martin Sebor wrote:
> The -Wstringop-overflow warnings for single-byte and multi-byte
> stores mention the amount of data being stored and the amount of
> space remaining in the destination, such as:
>
> warning: writing 4 bytes into a region of size 0 [-Wstringop-overflow=]
>
On 11/5/19 1:35 AM, Martin Liška wrote:
> On 11/4/19 4:24 PM, Jeff Law wrote:
>> On 11/4/19 6:36 AM, Richard Biener wrote:
>>> On Mon, Nov 4, 2019 at 2:35 PM Richard Biener
>>> wrote:
>>>>
>>>> On Mon, Nov 4, 2019 at 10:09 AM Martin Liška wro
On 11/6/19 1:27 PM, Martin Sebor wrote:
> On 11/6/19 11:55 AM, Jeff Law wrote:
>> On 11/6/19 11:00 AM, Martin Sebor wrote:
>>> The -Wstringop-overflow warnings for single-byte and multi-byte
>>> stores mention the amount of data being stored and the amount of
>>>
On 10/31/19 3:55 PM, Georg-Johann Lay wrote:
> Hi, this adds the possibility to enable IEEE compatible double
> and long double support in avr-gcc.
>
> It supports 2 configure options
>
> --with-double={32|64|32,64|64,32}
> --with-long-double={32|64|32,64|64,32|double}
>
> which select the defau
On 11/6/19 4:09 PM, Maciej W. Rozycki wrote:
> On Fri, 1 Nov 2019, Martin Sebor wrote:
>
>> Rebuilding the kernel with the updated patch results in the following
>> breakdown of the two warnings (the numbers are total instances of each,
>> unique instances, and files they come from):
>>
>>-Wze
On 11/10/19 4:05 AM, Janne Blomqvist wrote:
> On Sun, Nov 10, 2019 at 11:43 AM Thomas Koenig wrote:
>>
>> Hi Janne,
>>
>>> Bump the minimum MPFR version to 3.1.0, released 2011-10-03. With this
>>> requirement one can still build GCC with the operating system provided
>>> MPFR on old but still sup
On 11/6/19 2:06 PM, Martin Sebor wrote:
> On 11/6/19 1:39 PM, Jeff Law wrote:
>> On 11/6/19 1:27 PM, Martin Sebor wrote:
>>> On 11/6/19 11:55 AM, Jeff Law wrote:
>>>> On 11/6/19 11:00 AM, Martin Sebor wrote:
>>>>> The -Wstringop-overflow warnings for si
On 11/6/19 3:34 PM, Martin Sebor wrote:
> On 11/6/19 2:06 PM, Martin Sebor wrote:
>> On 11/6/19 1:39 PM, Jeff Law wrote:
>>> On 11/6/19 1:27 PM, Martin Sebor wrote:
>>>> On 11/6/19 11:55 AM, Jeff Law wrote:
>>>>> On 11/6/19 11:00 AM, Martin Sebor wrote
On 11/12/19 7:56 AM, Dragan Mladjenovic wrote:
> From: "Dragan Mladjenovic"
>
> This was dormant for quite some time, but it started happening for me
> on gcc.c-torture/compile/pr65153.c sometime after r276645 for -mabi=32 linux
> runs.
>
> The pattern accepts any SMALL_OPERAND constant value w
On 11/12/19 1:15 AM, Richard Biener wrote:
> On Tue, Nov 12, 2019 at 6:10 AM Jeff Law wrote:
>>
>> On 11/6/19 3:34 PM, Martin Sebor wrote:
>>> On 11/6/19 2:06 PM, Martin Sebor wrote:
>>>> On 11/6/19 1:39 PM, Jeff Law wrote:
>>>>> On 11/6/19 1:27
On 11/13/19 2:37 AM, Martin Liška wrote:
>>
>> As Nick also mentioned many times, -grecord-gcc-switches is in DWARF
>> and this causes a great disadvantage: it gets stripped out.
>
> Well, that's still something I disagree. I bet RedHat is similarly to
> openSUSE also building all packages with a
301 - 400 of 15555 matches
Mail list logo
