https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95442
Nicholas Krause changed:
What|Removed |Added
CC||xerofoify at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68837
--- Comment #5 from HaoChen Gui ---
I think there are two ways avoiding sign extension for offset loading.
a. Make sure all offsets be positive. There exists backward jumps as well as
STC will reorder the basic block. So the offset might be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95631
kargl at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |INVALID
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95632
Bug ID: 95632
Summary: Redundant zero extension
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95631
--- Comment #3 from Andrew Pinski ---
Note I think this is a bug in the RISCV backend that selects the small data
section for read only constants. Rather than we want to support this
extension.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95631
--- Comment #2 from Andrew Pinski ---
PR 17887 was the same issue against g77.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95631
--- Comment #1 from Andrew Pinski ---
Well we decided long time ago not to support that extension.
See PR 37974 and maybe even some g77 bug reports.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95631
Bug ID: 95631
Summary: Unable to redefine a literal with `-std=legacy'
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
[previous Subject: Re: dejagnu version update? [CORRECTION: not a
regression in DejaGnu; GDB testsuite bug] ]
[adding Tom Tromey to CC list per advice from Rob Savoye]
[adding main DejaGnu mailing list to CC list]
In brief for those new to this, the GDB testsuite is currently broken
when run
Committed with adding comments for those two functions.
On Thu, Jun 11, 2020 at 5:10 AM Jim Wilson wrote:
>
> On Wed, Jun 10, 2020 at 1:08 AM Kito Cheng wrote:
> > * config/riscv/riscv.c (gpr_save_reg_order): New.
> > (riscv_expand_prologue): Use riscv_gen_gpr_save_insn to gen
Committed.
On Thu, Jun 11, 2020 at 5:13 AM Jim Wilson wrote:
>
> On Wed, Jun 10, 2020 at 1:08 AM Kito Cheng wrote:
> > * config/riscv/riscv-protos.h (riscv_output_gpr_save): Remove.
> > * config/riscv/riscv-sr.c (riscv_sr_match_prologue): Update
> > value.
> > *
On May 26, 2020, Alexandre Oliva wrote:
> On May 19, 2020, Joseph Myers wrote:
>> Allowing a missing executable name is reasonable enough, but I was
>> actually thinking that the messages should print "gcc" or whatever command
>> the user ran in place of "collect2".
> Should we make the
On Jun 9, 2020, Richard Biener wrote:
> How about simply unconditionally doing dump_flags | TDF_SLIM here
> to have the whole mem_expr on one line.
SGTM
> OK with that change.
Thanks, here's what I'm installing.
slim up mem exprs to avoid line breaks in -fverbose-asm
From: Alexandre Oliva
Thanks for viewing and pushing this.
Thanks,
Haijian Zhang
> -Original Message-
> From: Richard Sandiford [mailto:richard.sandif...@arm.com]
> Sent: Thursday, June 11, 2020 12:01 AM
> To: Zhanghaijian (A)
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH PR95523] aarch64:ICE in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95540
--- Comment #7 from Iain Sandoe ---
to summarise.
This doesn't appear to be a bug in GCC (or clang) but something perhaps that
could benefit from a clarifying note in the std?
On Thu, 11 Jun 2020, Patrick McGehearty wrote:
> I will study real.c carefully along with the C99 std
> to determine if I can find useful values for RMIN2 and RMINSCAL
> for each format which are within range for all instances
> of that format. A quick skim of real.c shows we have ieee half
I will study real.c carefully along with the C99 std
to determine if I can find useful values for RMIN2 and RMINSCAL
for each format which are within range for all instances
of that format. A quick skim of real.c shows we have ieee half precision
and two arm half precision formats, for example.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95629
--- Comment #2 from Iain Sandoe ---
preliminary analysis on pr95510 (which might be a dup) has the assert failing
because the first operand of the target expression is a CTOR not a call.
However, accepting a CTOR there just leads to a fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95629
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
Ever
On Jun 9, 2020, Martin Jambor wrote:
>> Before your changes, GCC produced the expected:
>>
>> $ ls -1 build-gcc/gcc/testsuite/brig/variables.*???t.*
>> build-gcc/gcc/testsuite/brig/variables.hsail.brig.004t.original
>> build-gcc/gcc/testsuite/brig/variables.hsail.brig.005t.gimple
>>
>> Are
On Wed, Jun 10, 2020 at 04:27:27PM -0600, Jeff Law wrote:
> On Mon, 2019-07-22 at 12:39 -0400, Arvind Sankar wrote:
> > The gcc configure script does not use the config/picflag.m4 macro to
> > customize PICFLAG according to the host when using --enable-host-shared.
> >
> > Fix configure.ac to do
On Wed, 10 Jun 2020, Patrick McGehearty wrote:
> #ifdef L_divhc3
> #define RBIG (correct value for half precision)
> #define RMIN (correct value for half precision)
> #define RMIN2 ... (correct value for half precision)
> #define RMINSCAL ... (correct value for half precision)
> #endif
>
Joseph,
Thank you again for your prompt and insightful response.
It's now clear that I was engaged in wishful thinking that I only needed
to handle double precision in my proposed change. I understand now that
the text above the routine:
- - - - -
#if defined(L_divhc3) || defined(L_divsc3) ||
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10037
Jonathan Wakely changed:
What|Removed |Added
Resolution|FIXED |INVALID
On Mon, 2019-07-22 at 12:39 -0400, Arvind Sankar wrote:
> The gcc configure script does not use the config/picflag.m4 macro to
> customize PICFLAG according to the host when using --enable-host-shared.
>
> Fix configure.ac to do so.
>
> Tested bootstrap on x86_64-linux-gnu.
>
> 2019-07-22
On Jun 9, 2020, Thomas Schwinge wrote:
> Are you able to easily create/suggest patches for these? (You're
> probably not set up for offloading compilation...)
I can try, but I can certainly use help, if not in coding, at least with
testing.
> Can you suggest
> how/where to adjust:
A follow up note relating to use of fused multiply add in complex divide:
While reviewing bugs relating to complex divide in libgcc, I
rediscovered bug 59714 - complex division is surprising on targets
with FMA.
The specific concern was when you divide (1.0 + 3.0i) by itself and
fused multiply
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95630
Bug ID: 95630
Summary: rejects-valid on comparison of pointers to complete vs
incomplete types in C11 mode
Product: gcc
Version: unknown
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95628
David Edelsohn changed:
What|Removed |Added
Target|powerpc64*-linux-gnu|powerpc*-*-*
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95578
--- Comment #2 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:a73051a0ea9ce8281e748a74dd924a6eb8fb3723
commit r11-1186-ga73051a0ea9ce8281e748a74dd924a6eb8fb3723
Author: Patrick Palka
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93571
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95629
Bug ID: 95629
Summary: consteval operator== crashes compiler
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
On Wed, 10 Jun 2020, Jonathan Wakely wrote:
> On 10/06/20 15:32 -0400, Patrick Palka via Libstdc++ wrote:
> > ranges::copy and a number of other ranges algorithms have unwrapping
> > optimizations for iterators of type __normal_iterator, move_iterator and
> > reverse_iterator. But in the checks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95628
Bill Seurer changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95628
Bug ID: 95628
Summary: [11 regression] ICE in gcc build after r11-1181
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94833
--- Comment #5 from CVS Commits ---
The releases/gcc-8 branch has been updated by Carl Love :
https://gcc.gnu.org/g:c6dce1d8083a2fdc94be167a2465db7fd837ccae
commit r8-10304-gc6dce1d8083a2fdc94be167a2465db7fd837ccae
Author: Carl Love
Date:
Since r10-7096 convert_like, when called in a template, creates an
IMPLICIT_CONV_EXPR when we're converting to/from array type.
In this test, we have e[f], and we're converting f (of type class A) to
int, so convert_like in build_new_op_1 created the IMPLICIT_CONV_EXPR
that got into
Another indication that perhaps this warning is emitted too early. We
crash because same_type_p gets a null type: we have an enumerator
without a fixed underlying type and finish_enum_value_list hasn't yet
run. So check if the type is null before calling same_type_p.
(This is a regression and
On Wed, Jun 10, 2020 at 1:08 AM Kito Cheng wrote:
> * config/riscv/riscv.c (gpr_save_reg_order): New.
> (riscv_expand_prologue): Use riscv_gen_gpr_save_insn to gen gpr_save.
> (riscv_gen_gpr_save_insn): New.
> ...
Looks good to me. Though these two new functions should
On Wed, Jun 10, 2020 at 1:08 AM Kito Cheng wrote:
> * config/riscv/riscv-protos.h (riscv_output_gpr_save): Remove.
> * config/riscv/riscv-sr.c (riscv_sr_match_prologue): Update
> value.
> * config/riscv/riscv.c (riscv_output_gpr_save): Remove.
> *
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95346
--- Comment #3 from CVS Commits ---
The releases/gcc-10 branch has been updated by Iain D Sandoe
:
https://gcc.gnu.org/g:5bb75908cbcc0d2ddfbadedfcd716b33694fd9c4
commit r10-8269-g5bb75908cbcc0d2ddfbadedfcd716b33694fd9c4
Author: Iain Sandoe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51447
--- Comment #22 from CVS Commits ---
The master branch has been updated by Alexandre Oliva :
https://gcc.gnu.org/g:06ef9c119c56568e5f77a5189aa382cb97c95a9e
commit r11-1185-g06ef9c119c56568e5f77a5189aa382cb97c95a9e
Author: Alexandre Oliva
On 10/06/20 15:32 -0400, Patrick Palka via Libstdc++ wrote:
ranges::copy and a number of other ranges algorithms have unwrapping
optimizations for iterators of type __normal_iterator, move_iterator and
reverse_iterator. But in the checks that guard these optimizations we
currently only test
Hi Jason,
Jason Merrill wrote:
> On Tue, Jun 9, 2020 at 5:04 AM Iain Sandoe wrote:
>
> /* Don't bother reversing an operator with two identical parameters.
> */
> - else if (args->length () == 2 && (flags & LOOKUP_REVERSED))
> + else if (args && args->length () == 2 &&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95440
--- Comment #2 from CVS Commits ---
The master branch has been updated by Iain D Sandoe :
https://gcc.gnu.org/g:a9eec9625ea7165292958be04899b057804192fb
commit r11-1184-ga9eec9625ea7165292958be04899b057804192fb
Author: Iain Sandoe
Date: Wed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95348
--- Comment #32 from Qing Zhao ---
> I would be more interested in overall statistics for your training scenario.
> How much can you get from ~1TB of data?
The profile directory generated by the new executable compiled with this patch
was 112G
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95348
--- Comment #31 from Qing Zhao ---
> The explanation is not sufficient.
You mean the following explanation: (in comment 18)
we tried the scheme that all the processes generate profiling feedback data to
the single directory,
but looks like a
On Wed, Jun 10, 2020 at 06:52:10PM +0300, Alexander Popov wrote:
> On 09.06.2020 21:47, Kees Cook wrote:
> > On Thu, Jun 04, 2020 at 04:49:55PM +0300, Alexander Popov wrote:
> >> Add 'verbose' plugin parameter for stackleak gcc plugin.
> >> It can be used for printing additional info about the
On Wed, Jun 10, 2020 at 06:47:14PM +0300, Alexander Popov wrote:
> On 09.06.2020 21:46, Kees Cook wrote:
> The inline asm statement that is used for instrumentation is arch-specific.
> Trying to add
> asm volatile("call stackleak_track_stack")
> in gcc plugin on aarch64 makes gcc break
Hi Alexandre,
Alexandre Oliva wrote:
On Jun 9, 2020, Iain Sandoe wrote:
I have an ugly patch that makes this work for Darwin (essentially, by
having two versions of the LTO tests
We could deal with that in a similar way to how .dwo files are handled,
namely, with explicit handling in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95627
Martin Liška changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
Early ping.
> Gesendet: Donnerstag, 04. Juni 2020 um 20:47 Uhr
> Von: "Harald Anlauf"
> An: "fortran" , "gcc-patches"
> Betreff: [PATCH, PR fortran/95503] [9/10/11 Regression] ICE in
> gfc_is_simply_contiguous, at fortran/expr.c:5844
>
> The following patch fixes an almost obvious ICE in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95627
Bug ID: 95627
Summary: [11 Regression] ICE in rs6000_density_test at
rs6000.c:4992 since
r11-1181-g371cc683371bedb0e53ebcee0c0e89604a1e74b1
Product: gcc
Version:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95348
--- Comment #30 from Martin Liška ---
(In reply to Qing Zhao from comment #29)
> >
> > And you still haven't replied to my essential question: Why can't you merge
> > profiles into one directory during run? Or at least merge to a reasonable
> >
ranges::copy and a number of other ranges algorithms have unwrapping
optimizations for iterators of type __normal_iterator, move_iterator and
reverse_iterator. But in the checks that guard these optimizations we
currently only test that the iterator of the iterator/sentinel pair has
the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95596
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95578
Patrick Palka changed:
What|Removed |Added
Target Milestone|--- |10.2
Hi!
On Wed, Jun 10, 2020 at 09:14:07AM -0700, Carl Love wrote:
> On Wed, 2020-06-10 at 10:46 -0500, will schmidt wrote:
> > Compare that to the other predicates (config/rs6000/predicates.md)
> >
> > Those have explicit checks against both ends of the valid range of
> > values. i.e.
> >
> > ;;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92102
Jonathan Wakely changed:
What|Removed |Added
CC||godeffroy.valet at m4x dot org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95626
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95560
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
Hi!
On Tue, Jun 09, 2020 at 05:01:45PM -0700, Carl Love wrote:
> On Fri, 2020-06-05 at 16:28 -0500, Segher Boessenkool wrote:
> > > +;; Return 1 if op is a 32-bit constant signed integer
> > > +(define_predicate "s32bit_cint_operand"
> > > + (and (match_code "const_int")
> > > +
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95626
Bug ID: 95626
Summary: [concepts] incorrect ambiguous overload with
constraints "A && !B" vs "!B"
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity:
Hi Carl,
On Wed, Jun 10, 2020 at 09:05:36AM -0700, Carl Love wrote:
> I committed this patch to mainline and backported to GCC 9.
>
> I have looked at GCC 8. The functional issue is there, i.e. the
> vcmpnez is used instead of vcmpne. However the test case
> builtins-8-p9-runnable.c does
On Jun 9, 2020, Iain Sandoe wrote:
> That means that the intermediate objects proceed all the way to .s
> output - and thus the ‘final’ pass is run (producing the extra files seen).
> You can mimic this with x86 Linux by appending -ffat-lto-objects to an
> LTO command line.
I see, thanks.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92939
Martin Sebor changed:
What|Removed |Added
Known to fail||10.1.0
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443
Bug 88443 depends on bug 92939, which changed state.
Bug 92939 Summary: missing -Wstringop-overflow on negative index from the end
of array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92939
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95353
Martin Sebor changed:
What|Removed |Added
Known to fail|11.0|
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95353
--- Comment #12 from CVS Commits ---
The master branch has been updated by Martin Sebor :
https://gcc.gnu.org/g:a2c2cee92e5defff9bf23d3b1184ee96e57e5fdd
commit r11-1183-ga2c2cee92e5defff9bf23d3b1184ee96e57e5fdd
Author: Martin Sebor
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92939
--- Comment #1 from CVS Commits ---
The master branch has been updated by Martin Sebor :
https://gcc.gnu.org/g:a2c2cee92e5defff9bf23d3b1184ee96e57e5fdd
commit r11-1183-ga2c2cee92e5defff9bf23d3b1184ee96e57e5fdd
Author: Martin Sebor
Date: Wed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82608
Martin Sebor changed:
What|Removed |Added
Target Milestone|--- |11.0
See Also|
On Jun 9, 2020, Rainer Orth wrote:
> this is wrong unfortunately: braces are the Tcl equivalent of single
> quotes so you're setting skip_lto to the string inside.
Aah, thanks. So when $skip_lto is expanded in the ifs, the whole thing
is evaluated, and that's why it works anyway?
> While
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82608
Martin Sebor changed:
What|Removed |Added
Known to fail||10.1.0, 11.0, 8.4.0, 9.3.0
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82581
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86889
Martin Sebor changed:
What|Removed |Added
Last reconfirmed|2018-08-09 00:00:00 |2020-6-10
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456
Bug 56456 depends on bug 88992, which changed state.
Bug 88992 Summary: missing -Warray-bounds indexing into a zero-length array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88992
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88992
Martin Sebor changed:
What|Removed |Added
Resolution|--- |FIXED
Assignee|unassigned at
On 10/06/20 18:40 +0200, François Dumont wrote:
On 10/06/20 4:49 pm, Jonathan Wakely wrote:
On 10/06/20 08:18 +0200, François Dumont via Libstdc++ wrote:
On 09/06/20 10:53 pm, Jonathan Wakely wrote:
This reminds me that I was going to extend the condition for using
memcmp to also apply to
Tamar Christina writes:
> Hi All,
>
> The test in check_effective_target_exceptions_enabled uses a C++ keyword
> `throw`
> and the test fails with a syntax error on any non-g++ test. I now tell the
> testsuite driver that this is a C++ input file so it runs it as such in all
> the
> drivers.
On Wed, Jun 10, 2020 at 9:57 AM Tamar Christina wrote:
>
> Hi All,
>
> The amdgcn-amdhsa test seems to be running for all targets unconditionally
> while
> only really makes sense for certain targets. This patch adds an opt-out list
> and opts out arm targets.
>
> Regtested on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95625
Bug ID: 95625
Summary: missing detail in -Waddress initializing a function
argument
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: minor
Hi All,
The test in check_effective_target_exceptions_enabled uses a C++ keyword `throw`
and the test fails with a syntax error on any non-g++ test. I now tell the
testsuite driver that this is a C++ input file so it runs it as such in all the
drivers.
Regtested on aarch64-none-linux-gnu and no
"Kewen.Lin" writes:
> diff --git a/gcc/tree-vect-loop-manip.c b/gcc/tree-vect-loop-manip.c
> index ca68d04a919..1fac5898525 100644
> --- a/gcc/tree-vect-loop-manip.c
> +++ b/gcc/tree-vect-loop-manip.c
> @@ -420,8 +420,8 @@ vect_set_loop_controls_directly (class loop *loop,
> loop_vec_info
Hi All,
The amdgcn-amdhsa test seems to be running for all targets unconditionally while
only really makes sense for certain targets. This patch adds an opt-out list
and opts out arm targets.
Regtested on aarch64-none-linux-gnu and no issues.
Ok for master?
Thanks,
Tamar
On 10/06/20 4:49 pm, Jonathan Wakely wrote:
On 10/06/20 08:18 +0200, François Dumont via Libstdc++ wrote:
On 09/06/20 10:53 pm, Jonathan Wakely wrote:
This reminds me that I was going to extend the condition for using
memcmp to also apply to unsigned integers with sizeof(T) > 1 on big
endian
[cc-ing Joel as the originator, and ]
On Tue, 9 Jun 2020, Jacob Bachmeyer wrote:
> >> I ran a quick bisection and the culprit turned out to be:
> >>
> >> ba60272a5ac6f6a7012acca03f596a6ed003f044 is the first bad commit
> >> commit ba60272a5ac6f6a7012acca03f596a6ed003f044
> >> Author: Jacob
"Yangfei (Felix)" writes:
> Hi,
>
> PR: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95570
>
> Here, we are doing loop versioning for alignment. The only dr here is a
> gather-statter operation: x[start][i].
> Scalar evolution analysis for this dr failed, so DR_STEP is NULL_TREE, which
>
The inactive development branches are sorted alphabetically except for the
openacc-gcc-*-branch entries, which are grouped with the gomp*-branch entries.
Would it be better to place devel/omp/gcc-9 alphabetically (in which case it
will go between debuglocus and dwarf4), or by topic (in which
On 6/10/20 12:00 PM, Andreas Schwab wrote:
On Jun 10 2020, Nathan Sidwell wrote:
needed 'origin' -- eg 'git merge origin master'
That's an octopus merge. I don't think you want that.
ah. Somehow I convinced myself that was how to merge from master, but I
guess my formulation resulted in
On Wed, 2020-06-10 at 10:46 -0500, will schmidt wrote:
> > On Fri, 2020-06-05 at 16:28 -0500, Segher Boessenkool wrote:
> > > > +;; Return 1 if op is a 32-bit constant signed integer
> > > > +(define_predicate "s32bit_cint_operand"
> > > > + (and (match_code "const_int")
> > > > +
On Fri, 2020-05-08 at 15:35 -0400, Lewis Hyatt wrote:
> On Fri, Jan 31, 2020 at 03:31:59PM -0500, David Malcolm wrote:
> > On Fri, 2020-01-31 at 14:31 -0500, Lewis Hyatt wrote:
> > > Hello-
> > >
> > > Here is the second patch that I mentioned when I submitted the
> > > other
> > > related
> > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95576
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
The following avoids allocating stmt info structs for debug stmts.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
2020-06-10 Richard Biener
* tree-vect-loop.c (vect_determine_vectorization_factor):
Skip debug stmts.
(_loop_vec_info::_loop_vec_info):
The following avoids leading debug stmts in BB vectorizer regions.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
2020-06-10 Richard Biener
PR tree-optimization/95576
* tree-vect-slp.c (vect_slp_bb): Skip leading debug stmts.
* g++.dg/vect/pr95576.cc:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95576
--- Comment #5 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:36e95a9e539a08275a0a6ef542a7fae5baa5710f
commit r11-1180-g36e95a9e539a08275a0a6ef542a7fae5baa5710f
Author: Richard Biener
Date:
Segher, Bill:
I committed this patch to mainline and backported to GCC 9.
I have looked at GCC 8. The functional issue is there, i.e. the
vcmpnez is used instead of vcmpne. However the test case
builtins-8-p9-runnable.c does not exist in GCC 8. The patch consists
of the functional fix:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95523
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Hi,
"Zhanghaijian (A)" writes:
> This is a simple fix for pr95523.
> When registering the tuple type in register_tuple_type, the TYPE_ALIGN
> (tuple_type) will be changed by -fpack-struct=n.
> We need to maintain natural alignment in handle_arm_sve_h.
> Bootstrap and tested on aarch64 Linux
On Jun 10 2020, Nathan Sidwell wrote:
> needed 'origin' -- eg 'git merge origin master'
That's an octopus merge. I don't think you want that.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95523
--- Comment #5 from CVS Commits ---
The master branch has been updated by Richard Sandiford :
https://gcc.gnu.org/g:b5cebc9ab7f6ab47067dc04cae17bf9921a62a18
commit r11-1179-gb5cebc9ab7f6ab47067dc04cae17bf9921a62a18
Author: z00219097
Date:
1 - 100 of 239 matches
Mail list logo
