The tester started spitting out these errors on bfin recently:
> Tests that now fail, but worked before (3 tests):
>
> bfin-sim: c-c++-common/torture/vector-compare-1.c -Os (test for excess
> errors)
> bfin-sim: c-c++-common/torture/vector-compare-1.c -Os (test for excess
> errors)
>
On Tue, 2020-03-10 at 19:39 +0300, Roman Zhuykov wrote:
> Hi!
>
> Current modulo-sched implementation is a bit faulty from -fcompile-debug
> perspective.
>
> I found that few years ago, the most simple example is pr42631.c which fails
> (with just -fmodulo-sched or together with
On Sat, 2020-02-29 at 06:16 -0800, H.J. Lu wrote:
> There is no need to set mode attribute to XImode since ix86_output_ssemov
> can properly encode xmm16-xmm31 registers with and without AVX512VL.
>
> gcc/
>
> PR target/89229
> * config/i386/i386.c (ix86_output_ssemov): Handle
On Tue, 2020-03-10 at 17:22 +, Matthew Malcomson wrote:
> When using `check-function-bodies`, the subroutine `parse_function_bodies`
> uses
> the `fluff` regexp to remove uninteresting assembly lines.
>
> Arm targets generate assembly with some lines prefixed by `@`, these lines are
> left
On Wed, 2020-03-11 at 14:22 +0800, Kewen.Lin via Gcc-patches wrote:
> Hi,
>
> Gentle ping this patch, also request to backport to gcc9 after some burn-in
> time.
>
> BR,
> Kewen
>
> on 2020/2/26 下午2:17, Kewen.Lin wrote:
> > Hi,
> >
> > This patch is to apply the same fix as r267528 to another
On Sat, 2020-02-29 at 06:16 -0800, H.J. Lu wrote:
> There is no need to set mode attribute to XImode nor V8DFmode since
> ix86_output_ssemov can properly encode xmm16-xmm31 registers with and
> without AVX512VL.
>
> gcc/
>
> PR target/89229
> * config/i386/i386.c
On Sat, 2020-02-29 at 06:16 -0800, H.J. Lu wrote:
> There is no need to set mode attribute to XImode since ix86_output_ssemov
> can properly encode xmm16-xmm31 registers with and without AVX512VL.
>
> gcc/
>
> PR target/89229
> * config/i386/i386.c (ix86_output_ssemov): Handle
On Sat, 2020-02-29 at 06:16 -0800, H.J. Lu wrote:
> There is no need to set mode attribute to XImode since ix86_output_ssemov
> can properly encode xmm16-xmm31 registers with and without AVX512VL.
>
> Remove ext_sse_reg_operand since it is no longer needed.
>
> PR target/89229
> *
On Sat, 2020-02-29 at 06:16 -0800, H.J. Lu wrote:
> There is no need to set mode attribute to V16SFmode since ix86_output_ssemov
> can properly encode xmm16-xmm31 registers with and without AVX512VL.
>
> gcc/
>
> PR target/89229
> * config/i386/i386.c (ix86_output_ssemov): Handle
On Wed, 2020-03-11 at 13:04 +, Nidal Faour via Gcc-patches wrote:
> This patch is a code density oriented and attempt to remove redundant
> sign/zero
> extension from assignment statement.
> The approach taken is to use VRP data while expanding the assignment to RTL to
> determine whether a
On Thu, 2020-03-12 at 13:23 -0500, Segher Boessenkool wrote:
>
> > > I don't know if this patch makes matters worse or not. It doesn't seem
> > > suitable for stage 4 though. And Richard said the cse.c part breaks
> > > rs6000, if that is true, yes I do object ;-)
> > The rs6000 port breakage
On Sat, 2020-02-08 at 10:41 -0600, Segher Boessenkool wrote:
> On Fri, Feb 07, 2020 at 09:00:40AM -0700, Jeff Law wrote:
> > On Thu, 2020-02-06 at 07:56 -0600, Segher Boessenkool wrote:
> > > On Wed, Feb 05, 2020 at 11:48:23AM -0700, Jeff Law wrote:
> > > > Yea, it's closely related. In your case
On Thu, 2020-03-12 at 13:23 -0500, Segher Boessenkool wrote:
> On Thu, Mar 12, 2020 at 12:03:08PM -0600, Jeff Law wrote:
> > On Sat, 2020-02-08 at 10:41 -0600, Segher Boessenkool wrote:
> > > I don't think each stanza of code should use it's own "noop-ness", no.
> > Richard's patch is actually
On Thu, 2020-03-12 at 19:49 +0200, Darius Galis wrote:
> Hello,
>
> The following patch removes the CTRLREG_CPEN register variable.
> According to the RX software manual:
> https://www.renesas.com/cn/en/doc/products/mpumcu/doc/rx_family/r01us0316ej0100-rxv3sm.pdf
> there is no control register
On Mon, 2020-03-09 at 14:33 -0600, Martin Sebor wrote:
> On 3/5/20 5:26 PM, Jeff Law wrote:
> > On Fri, 2020-02-14 at 15:41 -0700, Martin Sebor wrote:
> > > Because attribute weakref introduces a kind of a definition, it can
> > > only be applied to declarations of symbols that are not defined.
On Thu, 2020-03-12 at 15:26 -0500, Segher Boessenkool wrote:
> On Thu, Mar 12, 2020 at 12:47:04PM -0600, Jeff Law wrote:
> > On Thu, 2020-03-12 at 13:23 -0500, Segher Boessenkool wrote:
> > > > else if (n_sets == 1
> > > > - && MEM_P (trial)
> > > > + &&
On Fri, 2020-04-03 at 00:26 +0200, Jakub Jelinek wrote:
> Hi!
>
> The ix86_get_mask_mode hook uses int mask for 512-bit vectors or 128/256-bit
> vectors with AVX512VL (that is correct), and only for V*[SD][IF]mode if not
> AVX512BW (also correct), but with AVX512BW it would stop checking the
>
On Wed, 2020-04-08 at 09:23 -0700, H.J. Lu wrote:
> On Wed, Apr 8, 2020 at 9:16 AM Jeff Law wrote:
> > On Tue, 2020-03-31 at 08:11 -0700, H.J. Lu via Gcc-patches wrote:
> > > Since constant_call_address_operand has
> > >
> > > ;; Test for a pc-relative call operand
> > > (define_predicate
On Tue, 2020-03-31 at 08:11 -0700, H.J. Lu via Gcc-patches wrote:
> Since constant_call_address_operand has
>
> ;; Test for a pc-relative call operand
> (define_predicate "constant_call_address_operand"
> (match_code "symbol_ref")
> {
> if (ix86_cmodel == CM_LARGE || ix86_cmodel ==
On Mon, 2020-04-06 at 14:58 +0530, kamlesh kumar via Gcc-patches wrote:
> Hi Richard,
> Here is a discussion we did some time ago
> https://gcc.gnu.org/pipermail/gcc/2019-January/227834.html
> please see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88877 for more
> info regarding the bug.
>
> We
On Fri, 2020-04-03 at 17:37 +0100, Richard Sandiford wrote:
> Ping for the doc/sourcebuild.texi and lib/scanasm.exp parts.
>
> Richard Sandiford writes:
> > In g:2171a9207f51bc486ed9c502cb4da706f594615e I'd tried to fix
> > various ILP32 testsuite failures by restricting some tests to LP64.
> >
On Wed, 2020-04-08 at 12:27 -0300, Alexandre Oliva wrote:
> On Mar 27, 2020, Alexandre Oliva wrote:
>
> > So, here are some potential fixes:
> > - install the patchlet for fp16-aapcs-3.c above, and be done with it
> > - add an arm_fp16_hw requirement to this test
> > - add to
On Wed, 2020-04-08 at 20:23 +0200, Jakub Jelinek wrote:
> Hi!
>
> The following testcase ICEs on m68k (and another one Jeff mailed me
> privately on microblaze).
> The problem is that reload creates two DEBUG_INSNs with the same
> value of (plus:P (reg:P sp) (const_int 0)), we compute correctly
On Wed, 2020-04-08 at 12:09 -0600, Tom Tromey wrote:
> Merge top-level configury changes from gdb
>
> We recently rearranged the gdb source tree to move a common library
> and gdbserver to the top-level. This made the build more uniform and
> also a bit faster (due to sharing of built objects).
On Wed, 2020-04-08 at 19:47 +0200, Sebastian Huber wrote:
> Add a start/end file specification if the -qrtems option is present.
> Allow targets to customize it.
>
> Support the standard -nodefaultlibs option.
>
> gcc/
>
> * config/rtems.h (RTEMS_STARTFILE_SPEC): Define if undefined.
>
This isn't precisely the same issue that we were originally tracking with 90275,
but it's closely related and we might as well stuff it in the same bucket.
This time instead of having a NOP copy insn that we can completely ignore and
ultimately remove, we have a NOP set within a multi-set
On Thu, 2020-04-16 at 19:15 -0400, David Malcolm via Gcc-patches wrote:
> Validates. The wording could probably use some work.
>
> OK to push to the website repo?
OK. As are any small updates if you wanted to twiddle the wording.
jeff
>
On Fri, 2020-04-17 at 08:18 -0700, H.J. Lu wrote:
> On Wed, Apr 8, 2020 at 9:41 AM Jeff Law wrote:
> > On Wed, 2020-04-08 at 09:23 -0700, H.J. Lu wrote:
> > > On Wed, Apr 8, 2020 at 9:16 AM Jeff Law wrote:
> > > > On Tue, 2020-03-31 at 08:11 -0700, H.J. Lu via Gcc-patches wrote:
> > > > > Since
On Thu, 2020-04-16 at 10:05 +0200, Richard Biener wrote:
> This adjusts emit_move_multi_word to handle moves into paradoxical
> subregs parts that are not there and resolve_clobber to handle
> such subregs.
>
> Bootstrap & regtest running on x86_64-unknown-linux-gnu.
>
> The testcase involves
In this BZ we're getting a debug compare failure. Thanks to a nice hint from
Jakub it was pretty easy to track it back to the register renaming pass which
was
making different renaming decisions based on the existence of DEBUG_INSNs.
The culprit is check_new_reg_p which potentially changes
On Tue, 2020-04-07 at 18:25 +0200, Martin Jambor wrote:
> Hi,
>
> On Tue, Apr 07 2020, Richard Biener wrote:
> > On Tue, 7 Apr 2020, Martin Jambor wrote:
> >
> > > Hi,
> > >
> > > when sra_modify_expr is invoked on an expression that modifies only
> > > part of the underlying replacement, such
On Tue, 2020-04-07 at 21:31 +0200, Martin Jambor wrote:
> Hi Jeff,
>
> On Tue, Apr 07 2020, Jeff Law wrote:
> > On Tue, 2020-04-07 at 18:25 +0200, Martin Jambor wrote:
> > > Hi,
> > >
> > > On Tue, Apr 07 2020, Richard Biener wrote:
> > > > On Tue, 7 Apr 2020, Martin Jambor wrote:
> > > >
> > >
Whee, more fallout from the cselib work. This is clearly another backend bug.
The H8 port has this peephole:
;; Turn
;;
;; mov.l er7,er0
;; add.l #10,er0 (takes 8 bytes)
;;
;; into
;;
;; sub.l er0,er0
;; add.b #10,r0l
;; add.l er7,er0 (takes 6 bytes)
(define_peephole2
[(set
On Tue, 2020-04-07 at 22:35 +, Joseph Myers wrote:
> This introduces an ICE building glibc for m68k (and the same ICE appears
> for microblaze, though I haven't bisected there). See bug 94526.
Yea, I've already forwarded Jakub the microblaze testcase.
jeff
On Wed, 2020-04-08 at 00:55 +0200, Jakub Jelinek wrote:
> Hi!
>
> The following testcase shows two separate issues caused by the cselib
> changes.
> One is that through the cselib sp tracking improvements on
> ... r12 = rsp; rsp -= 8; push cst1; push cst2; push cst3; call
> rsp += 32; rsp -= 8;
On Sun, 2020-04-05 at 08:45 +0100, Richard Sandiford wrote:
> lra_assign has an assert to make sure that no pseudo is allocated
> to a conflicting hard register. It used to be restricted to
> !flag_ipa_ra, but in g:a1e6ee38e708ef2bdef4 I'd enabled it for
> flag_ipa_ra too. It then tripped a few
On Sat, 2020-04-04 at 00:00 +0100, Maciej W. Rozycki wrote:
> Fix a problem with the libatomic testsuite using a method to determine
> the compiler to use resulting in the tool being different from one the
> library has been built with, and causing a catastrophic failure from the
> lack of a
On Fri, 2020-04-03 at 23:55 +0100, Maciej W. Rozycki via Gcc-patches wrote:
> Use an Autoconf template rather an inline piece of scriptery to set
> DejaGNU's $CC_FOR_TARGET and $CXX_FOR_TARGET variables from $CC and $CXX
> respectively, making it easier to maintain and making it take advantage
On Fri, 2020-04-03 at 23:55 +0100, Maciej W. Rozycki via Gcc-patches wrote:
> Use Autoconf substitution in the template used for extra DejaGNU site
> configuration, which is a documented supported way to pass information
> from the `configure' script, rather than resorting to a hack with
>
On Fri, 2020-04-03 at 23:56 +0100, Maciej W. Rozycki via Gcc-patches wrote:
> Update code in `libffi-init' to use $CC_FOR_TARGET in determining the
> value of $ld_library_path, as using a different compiler location from
> one actually used in testing may have odd consequences.
>
> As this
On Sat, 2020-04-04 at 00:01 +0100, Maciej W. Rozycki wrote:
> Fix a problem with commit c8e759b4215b ("libgomp/test: Fix compilation
> for build sysroot") that caused a regression in some standalone test
> environments where testsuite/libgomp-test-support.exp is used, but the
> compiler is
On Sat, 2020-04-04 at 00:01 +0100, Maciej W. Rozycki wrote:
> Fix a problem with the libffi testsuite using a method to determine the
> compiler to use resulting in the tool being different from one the
> library has been built with, and causing a catastrophic failure from the
> inability to
On Fri, 2020-04-03 at 23:56 +0100, Maciej W. Rozycki via Gcc-patches wrote:
> ---
> testsuite/lib/libffi.exp |6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
OK when prereqs have been committed.
jeff
>
On Tue, 2020-04-07 at 00:33 +0200, Jakub Jelinek wrote:
> Hi!
>
> getopt.c hangs the compiler on h8300-elf with -O2 -g, because the
> IL contains addition of constant 0, the first PLUS operand is determined
> to have the SP_DERIVED_VALUE_P and the new code in cselib recurses
> indefinitely on
On Mon, 2020-04-13 at 12:39 -0600, Martin Sebor via Gcc-patches wrote:
> GCC 10 has changed the formatting of zero-length arrays in diagnostics
> to include their bound, but it also inadvertently added the zero bound
> to flexible array members which are confusingly represented differently
>
On Mon, 2020-04-13 at 06:25 -0600, Zackery Spytz via Gcc-patches wrote:
> Hello,
>
> The realloc() function was missing from parts of the documentation!
THanks. Applied.
jeff
>
On Thu, 2020-04-09 at 14:42 +0100, Maciej W. Rozycki via Gcc-patches wrote:
> On Thu, 2 Apr 2020, Maciej W. Rozycki wrote:
>
> > Match GCC commit bfe78b08471f ("RISC-V: Using fmv.x.w/fmv.w.x rather
> > than fmv.x.s/fmv.s.x") and commit 879bc686a0aa ("doc: RISC-V: Update
> > binutils requirement
On Thu, 2020-04-09 at 15:36 +0100, Maciej W. Rozycki wrote:
> On Thu, 9 Apr 2020, Jeff Law wrote:
>
> > > > Match GCC commit bfe78b08471f ("RISC-V: Using fmv.x.w/fmv.w.x rather
> > > > than fmv.x.s/fmv.s.x") and commit 879bc686a0aa ("doc: RISC-V: Update
> > > > binutils requirement to 2.30").
>
On Thu, 2020-03-12 at 14:43 -0700, Jim Wilson wrote:
> On Thu, Mar 12, 2020 at 2:38 AM Richard Biener via Gcc-patches
> wrote:
> > On Thu, Mar 12, 2020 at 4:06 AM Jeff Law via Gcc-patches
> > wrote:
> > > On Wed, 2020-03-11 at 13:04 +, Nidal Faour via Gcc-patche
On Fri, 2020-03-13 at 09:09 +0100, Christophe Lyon wrote:
> Hi,
>
>
> On Thu, 12 Mar 2020 at 23:12, Jeff Law via Gcc-patches
> wrote:
> > On Thu, 2020-03-12 at 13:23 -0500, Segher Boessenkool wrote:
> > > On Thu, Mar 12, 2020 at 12:03:08PM -0600, Jeff Law wrote:
&g
On Sat, 2020-04-04 at 11:15 -0700, Michael Eager wrote:
> OK to apply.
>
> On 4/4/20 1:59 AM, Nagaraju Mekala wrote:
> > Hello All,
> >
> > There is a bug in trap instruction generation.
> > Instead of "bri 0" instruction "brki r0, -1" was used, corrected it
> > now.
> >
> >
On Sat, 2020-04-04 at 11:16 -0700, Michael Eager wrote:
> OK to apply.
>
> On 4/4/20 2:18 AM, Nagaraju Mekala wrote:
> > Hello All,
> >
> > Fixed missing save of r18 in fast_interrupt.
> > Register 18 is used as a clobber register, and must be stored when entering
> > a
> > fast_interrupt.
So here's an approach to try and address PR80635.
In this BZ we're getting a false positive uninitialized warning using
std::optional.
As outlined in the BZ this stems from SRA using a VIEW_CONVERT_EXPR which isn't
handled terribly well by the various optimizers/analysis passes.
We have these
On Sun, 2020-04-05 at 20:48 +0200, Richard Biener wrote:
> On April 5, 2020 5:25:15 PM GMT+02:00, Jeff Law via Gcc-patches <
> gcc-patches@gcc.gnu.org> wrote:
> > So here's an approach to try and address PR80635.
> >
> > In this BZ we're getting a false positi
On Thu, 2020-04-02 at 12:29 -0600, Zackery Spytz via Gcc-patches wrote:
> Hello,
>
> The free() function was missing from a part of the documentation!
THanks for the patch. I've pushed it to the trunk.
jeff
On Wed, 2020-03-25 at 10:41 -0600, Martin Sebor wrote:
> On 3/25/20 9:40 AM, Jeff Law wrote:
> > On Tue, 2020-03-17 at 19:35 -0600, Martin Sebor via Gcc-patches wrote:
> > > PR tree-optimization/94131 - ICE on printf with a VLA string and
> > > -fno-tree-
> > > ccp
> > >
> > >
On Wed, 2020-03-25 at 23:10 -0400, Hans-Peter Nilsson wrote:
> On Wed, 25 Mar 2020, Jeff Law via Gcc-patches wrote:
>
> The patch you sent, as well as what you committed as r10-7383,
> was just a ChangeLog entry.
>
> > Bootstrapped on sh4-linux-gnu and sh4eb-linux-gnu
On Mon, 2020-03-09 at 17:56 +0100, Martin Liška wrote:
> On 3/9/20 4:36 PM, H.J. Lu wrote:
> > We nee to support different variables, like TLS, data and bss variables.
>
> Why do we need TLS? Right now, it's not supported by nm. Or am I wrong?
>
> About BSS and DATA I agree that it would be
On Thu, 2020-03-26 at 12:38 -0600, Jeff Law wrote:
> On Wed, 2020-03-25 at 23:10 -0400, Hans-Peter Nilsson wrote:
> > On Wed, 25 Mar 2020, Jeff Law via Gcc-patches wrote:
> >
> > The patch you sent, as well as what you committed as r10-7383,
> > was just a ChangeLog ent
Whee, more fallout from the pr90275 changes. Thankfully this time it's a target
issue.
The sh4/sh4eb ports are failing vector-compare-1 execution tests after the cse
changes. They only run once a week, so this wasn't caught immediately and took
some time to reproduce and analyze.
Ultimately
On Wed, 2020-03-18 at 20:29 +0100, Kamil Rytarowski wrote:
> Set /tmp first, then /var/tmp. /tmp is volatile on NetBSD and
> /var/tmp not. This improves performance in the common use.
> The downstream copy of GCC was patched for this preference
> since 2015.
>
> Remove occurence of /usr/tmp as it
On Wed, 2020-03-25 at 15:46 -0600, Martin Sebor via Gcc-patches wrote:
> PR 61339 - mismatch between struct and class [-Wmismatched-tags]
>
> ChangeLog:
>
> * htdocs/codingconventions.html (Struct Definitions): Remove
> old convention.
> (Class Definitions): Same.
> *
On Fri, 2020-03-20 at 11:04 +0100, Jakub Jelinek via Gcc-patches wrote:
> Hi!
>
> With this simple patch, on i686-linux and x86_64-linux with -m32 (no change
> for -m64), the find_base_term visited_vals.length () > 100 find_base_term
> statistics changed (fbt is before this patch, fbt2 with this
On Wed, 2020-01-29 at 18:32 +0300, Alexander Monakov wrote:
> On Tue, 28 Jan 2020, Jeff Law wrote:
>
> > On Tue, 2019-10-08 at 18:04 +0300, Alexander Monakov wrote:
> > > On Thu, 3 Oct 2019, Jeff Law wrote:
> > >
> > > > You may want to review the 2018 discussion:
> > > >
> > > >
On Mon, 2019-12-30 at 00:46 +0100, Jakub Jelinek wrote:
> Hi!
>
> The AVX512F documentation clearly states that in instructions where the
> destination is a memory only merging-masking is possible, not zero-masking,
> and the assembler enforces that.
>
> The testcase in this patch fails to
On Mon, 2020-03-09 at 11:55 +0300, Nicholas Guriev wrote:
> gcc/c-family/ChangeLog:
>
> PR pch/86674
> * c-pch.c (c_common_valid_pch): Use cpp_warning with CPP_W_INVALID_PCH
> reason to fix -Werror=invalid-pch and -Wno-error=invalid-pch switches.
THanks. This looks pretty
On Mon, 2020-02-10 at 19:22 +0300, Paul Gofman wrote:
> ChangeLog:
> PR target/91489
> * config/i386/i386.md (simple_return): Also check
> for ms_hook_prologue function attribute.
> * config/i386/i386.c (ix86_can_use_return_insn_p):
> Also check for ms_hook_prologue
On Fri, 2020-03-27 at 10:10 +0100, Martin Liška wrote:
> On 3/26/20 5:54 PM, Jeff Law wrote:
> > On Mon, 2020-03-09 at 17:56 +0100, Martin Liška wrote:
> > > On 3/9/20 4:36 PM, H.J. Lu wrote:
> > > > We nee to support different variables, like TLS, data and bss variables.
> > >
> > > Why do we
va-arg-22.c started failing on the m32r target (-O1 only) after Jakub's recent
cselib changes.
The m32r port has this pattern:
(define_insn "cpymemsi_internal"
[(set (mem:BLK (match_operand:SI 0 "register_operand" "r")) ;; destination
(mem:BLK (match_operand:SI 1 "register_operand"
This fixes more fallout from Jakub's cselib changes. This shows up as an ICE
building stdarg-3 from the testsuite after Jakub's changes. However, a reduced
testcase will fail miserably all the way back to gcc-7 (as far back as I
tested).
The xstormy port only allows a subset of the
On Tue, 2020-03-17 at 19:35 -0600, Martin Sebor via Gcc-patches wrote:
> PR tree-optimization/94131 - ICE on printf with a VLA string and -fno-tree-ccp
>
> gcc/testsuite/ChangeLog:
>
> PR tree-optimization/94131
> * gcc.dg/pr94131.c: New test.
>
> gcc/ChangeLog:
>
> PR
On Fri, 2020-03-27 at 00:46 +0100, Jakub Jelinek wrote:
> Hi!
>
> This define_insn has two issues.
> One is that with -mavx512f -mno-avx512vl it can emit an AVX512VL-only insn
> - 128-bit or 256-bit EVEX encoded vpternlog{d,q}.
> Another one is that because there is no vpternlog{b,w}, we emit
On Mon, 2020-03-30 at 14:10 +0200, Martin Liška wrote:
> Hi.
>
> I would like to XFAIL the mentioned test-case. It fails
> for quite some time and it has PR created.
>
> Ready to be installed?
> Thanks,
> Martin
>
> gcc/testsuite/ChangeLog:
>
> 2020-03-30 Martin Liska
>
> PR
On Mon, 2020-03-30 at 16:06 +0200, Martin Liška wrote:
> Hi.
>
> I would like to relax scanned pattern, see the PR.
>
> Ready to be installed?
> Thanks,
> Martin
>
> gcc/testsuite/ChangeLog:
>
> 2020-03-30 Martin Liska
>
> PR testsuite/94402
> * gfortran.dg/vect/vect-8.f90:
On Fri, 2020-03-27 at 00:26 +0100, Jakub Jelinek wrote:
> On Wed, Mar 25, 2020 at 05:59:36PM -0600, Jeff Law via Gcc-patches wrote:
> > Sorry. I know you asked me to look at this eons ago, but ever time I just
> > get
> > lost.
> >
> > I get the distinct impr
On Sun, 2020-03-29 at 22:33 +0200, Dragan Mladjenovic wrote:
> diff --git a/htdocs/gcc-10/changes.html b/htdocs/gcc-10/changes.html
> index b5cbcebf..1e1eaf43 100644
> --- a/htdocs/gcc-10/changes.html
> +++ b/htdocs/gcc-10/changes.html
> @@ -692,7 +692,17 @@ a work-in-progress.
>
>
>
> -
> +
On Tue, 2020-03-24 at 10:50 +0100, Jakub Jelinek wrote:
> On Mon, Mar 23, 2020 at 06:00:06PM -0600, Jeff Law via Gcc-patches wrote:
> > +/* Return true if CODE is valid for comparisons of mode MODE, false
> > + otherwise.
> > +
> > + It is always safe to ret
On Tue, 2020-04-28 at 17:51 +0200, Jakub Jelinek wrote:
> Hi!
>
> Untested. If the rs6000+generic change makes it in, is this ok for trunk
> too?
>
> 2020-04-28 Jakub Jelinek
>
> PR target/94706
> * config/ia64/ia64.c (hfa_element_mode): Use DECL_FIELD_ABI_IGNORED
>
This is a minor H8 specific bugfix. The H8/SX multiply instructions are all 4
bytes in length, but the machine description claims they are 2 bytes in length.
This can cause GCC to emit a short branch when a long branch was actually
needed.
Sadly the assembler didn't complain and instead the
On Thu, 2020-04-23 at 21:08 +0200, Jakub Jelinek via Gcc-patches wrote:
> Hi!
>
> On Tue, Apr 21, 2020 at 11:57:02AM +0200, Jakub Jelinek wrote:
> > I haven't added (yet) checks if the alternate compiler does support these
> > options (I think that can be done incrementally), so for now this
On Wed, 2020-04-22 at 09:36 -0600, Martin Sebor via Gcc-patches wrote:
> On 4/22/20 7:28 AM, Christophe Lyon wrote:
> > On Tue, 21 Apr 2020 at 11:07, Richard Biener via Gcc-patches
> > wrote:
> > > On Mon, Apr 20, 2020 at 11:29 PM Martin Sebor via Gcc-patches
> > > wrote:
> > > > The restrict
On Wed, 2020-04-22 at 16:42 +0200, Jakub Jelinek via Gcc-patches wrote:
> Hi!
>
> The following patch provides some further math library fallbacks.
> fmaf can be implemented using fma if available, fma and fmal can use
> x * y + z as fallback, it is not perfect, but e.g. glibc on various arches
>
On Mon, 2020-04-20 at 11:43 +, Christophe Lyon via Gcc-patches wrote:
> Some tests use --save-temps, but schedule-cleanups strictly matches
> -save-temps, so we leave many temporary files after validation.
> Instead of fixing every offending testcase, it's simpler and
> future-proof to make
On Wed, 2020-04-22 at 15:50 -0500, Segher Boessenkool wrote:
>
> > > In some ways it feels like it would be easier to resurrect RTL SSA :-)
>
> Why was RTL SSA abandoned?
>
> It might well work to keep everything in SSA form all the way to RA.
> Hrm, that doesn't sound bad at all :-)
>
> (The
On Wed, 2020-04-22 at 15:36 +0200, Jakub Jelinek wrote:
> Hi!
>
> ia64 seems to be affected too, but the backend doesn't have any
> -Wpsabi warnings and I'm not sure if we really need them for an (almost?)
> dead target.
>
> Untested by me, but Andreas confirmed it fixed all struct-layout-1.exp
On Wed, 2020-04-22 at 11:50 +0200, Jakub Jelinek via Gcc-patches wrote:
> Hi!
>
> On Tue, Apr 21, 2020 at 03:58:52PM +0100, Richard Sandiford wrote:
> > > if (TREE_CODE (field) != FIELD_DECL)
> > > continue;
> > >
> > > - sub_count = aapcs_vfp_sub_candidate (TREE_TYPE (field),
On Wed, 2020-04-22 at 15:36 -0600, Martin Sebor via Gcc-patches wrote:
> When computing the size of an object with a flexible array member
> the object size pass doesn't consider that the initializer of such
> an object can result in its size being in excess of the size of
> the enclosing type.
On Thu, 2020-04-23 at 16:32 +0100, Richard Sandiford wrote:
> Jeff Law via Gcc-patches writes:
> > On Thu, 2020-04-23 at 15:07 +0200, Richard Biener wrote:
> > > On Thu, Apr 23, 2020 at 2:52 PM Segher Boessenkool
> > > wrote:
> > > > On Thu, Apr 23, 2020 at
On Thu, 2020-04-23 at 15:07 +0200, Richard Biener wrote:
> On Thu, Apr 23, 2020 at 2:52 PM Segher Boessenkool
> wrote:
> > On Thu, Apr 23, 2020 at 02:25:40PM +0200, Richard Biener wrote:
> > > > > But being stuck with something means no progress... I know
> > > > > very well it's 100 times
On Thu, 2020-04-23 at 07:07 -0500, Segher Boessenkool wrote:
>
> > I think at least one step would be uncontroversical(?), namely moving
> > the RTL expansion "magic"
> > up to a GIMPLE pass. Where the "magic" would be to turn
> > GIMPLE stmts not directly expandable via an existing optab into
>
And another case were the H8 port had the wrong lengths which resulted in using
a
short branch instead of the necessary long branch and the short branch going off
into never-never land. It usually "worked" anyway, but if addresses in the C
runtime line up just right we'd get a fault.
I know
On Tue, 2020-04-28 at 11:44 +0200, Richard Biener via Gcc-patches wrote:
>
> Btw, does s390 have different inlining parameters somehow?
I think so. We saw a ton of backend warnings that were specific to the s390
builds in Fedora that appeared to be triggered by different inlining decisions.
It
On Thu, 2020-04-30 at 20:02 +0100, Richard Sandiford wrote:
> Jeff Law writes:
> > On Thu, 2020-04-30 at 08:54 +0100, Richard Sandiford wrote:
> > > Peter Bergner writes:
> > > > On 4/29/20 4:15 PM, Peter Bergner wrote:
> > > > > On 4/29/20 3:28 PM, Richard Sandiford wrote:
> > > > > > (Sorry
On Thu, 2020-04-30 at 08:54 +0100, Richard Sandiford wrote:
> Peter Bergner writes:
> > On 4/29/20 4:15 PM, Peter Bergner wrote:
> > > On 4/29/20 3:28 PM, Richard Sandiford wrote:
> > > > (Sorry for going ahead and writing an alternative patch, since if we do
> > > > go for this, I guess the
On Tue, 2020-04-28 at 09:03 +0200, Stefan Schulze Frielinghaus via Gcc-patches
wrote:
> Ensure that CF does not equal NULL in function output_stack_usage_1
> before calling fprintf. This fixes the following warning/error:
>
> gcc/toplev.c:976:13: error: argument 1 null where non-null expected [-
On Sat, 2020-04-25 at 21:33 +0100, Maciej W. Rozycki wrote:
> On Wed, 22 Apr 2020, Jeff Law wrote:
>
> > > libffi/
> > > * Makefile.am (DISTCLEANFILES): New variable.
> > > * configure.ac: Produce `local.exp'.
> > > * Makefile.in: Regenerate.
> > > * configure: Regenerate.
> > > *
On Tue, 2020-04-28 at 20:43 -0300, Alexandre Oliva wrote:
> On Apr 28, 2020, Bernhard Reutner-Fischer wrote:
>
> > ISTM the corresponding documentation hunk for sourcebuild.texi is missing.
>
> Thanks, I wasn't aware that testsuite effective targets were documented
> there.
>
> Here's the
On Tue, 2020-04-28 at 20:03 -0500, Segher Boessenkool wrote:
> Hi!
>
> On Tue, Apr 28, 2020 at 08:38:56AM +0100, Richard Sandiford wrote:
> > Also, the (const:P ...) ought to be there even outside of a MEM. E.g. we
> > ought to have:
> >
> > (set (reg X) (const:P (plus:P (symbol_ref:P S)
On Tue, 2020-04-28 at 00:31 -0400, Patrick Palka via Gcc-patches wrote:
> The bundled vimrc script, when enabled, currently sets the text width to
> 80 characters for all files within the source directory. Unfortunately
> this means the setting also applies when editing .git/COMMIT_EDITMSG,
>
On Fri, 2020-05-01 at 12:52 +0100, Richard Earnshaw wrote:
> On 01/05/2020 12:01, Kyrylo Tkachov wrote:
> > Hi JangNing (please reply inline in the future as that is the preferred
> > style
> > on this mailing list)
> >
> > > -Original Message-
> > > From: JiangNing OS
> > > Sent: 01
1 - 100 of 3176 matches
Mail list logo
