power10: Add tests for PCREL_OPT.
This patch add the PCREL_OPT tests for the previous two patches.
I have built compilers with and without these set of 3 patches doing a
bootstrap build and make check. There were no regressions, and the new tests
passed. Can I check these patches into the
power10: Add PCREL_OPT store support.
This patch adds support for optimizing power10 stores to an external variable to
eliminate loading the address of the variable, and then doing a subsequent load
using that address.
The previous patch added the support for optimizing power10 loads from an
power10: Add PCREL_OPT load support.
This patch adds support for optimizing power10 loads of an external variable to
eliminate loading the address of the variable, and then doing a subsequent load
using that address.
The next patch will add the support for optimizing power10 stores to an
The ELF-v2 ISA 3.1 support for Power10 has relocations to optimize cases where
the code is references an external variable in only one location. This patch
is similar to the optimizations that the linker already does to optimize TOC
accesses.
This patch is a revision of the patches last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96941
Bug ID: 96941
Summary: Initial PPC64LE transcendental auto-vectorization
functionality
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Snapshot gcc-9-20200904 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/9-20200904/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 9 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95164
Marek Polacek changed:
What|Removed |Added
Keywords||patch
--- Comment #4 from Marek Polacek
This patch fixes a long-standing bug in reshape_init_r. Since r209314
we implement DR 1467 which handles list-initialization with a single
initializer of the same type as the target. In this test this causes
a crash in reshape_init_r when we're processing a constructor that has
undergone the DR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96913
--- Comment #3 from Sergei Trofimovich ---
Specifically I think this is already a wrong format on disk:
> _json.gcda:01a7: 0:COUNTERS topn 0 counts
> _json.gcda:01a9: 48:COUNTERS indirect_call 24 counts
> _json.gcda:
From: Sergei Trofimovich
gcc/ChangeLog:
* gcc/profile.c (sort_hist_values): Clarify hist format:
start with a value, not counter.
---
gcc/profile.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/profile.c b/gcc/profile.c
index f5c206813c7..fe8963cc9e9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96924
Iain Buclaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
Hi,
Array concatenate expressions were creating more SAVE_EXPRs than what
was necessary. The internal error itself was the result of a forced
temporary being made on a TREE_ADDRESSABLE type.
Bootstrapped and regression tested on x86_64-linux-gnu/-m32/-mx32.
Committed to mainline and backported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96924
--- Comment #2 from CVS Commits ---
The releases/gcc-10 branch has been updated by Iain Buclaw
:
https://gcc.gnu.org/g:40af8b2eff82f28d83b2a5fe153cbc53af665956
commit r10-8711-g40af8b2eff82f28d83b2a5fe153cbc53af665956
Author: Iain Buclaw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96924
--- Comment #1 from CVS Commits ---
The master branch has been updated by Iain Buclaw :
https://gcc.gnu.org/g:f8eabd47ac5335ebab0d83ff61fb680a46888be8
commit r11-3015-gf8eabd47ac5335ebab0d83ff61fb680a46888be8
Author: Iain Buclaw
Date: Fri
Richard, thank you for working on this issue and for as usually detailed
explanation of the problem.
On 2020-08-28 9:52 a.m., Richard Sandiford wrote:
...
The patch is quite aggressive in that it does this for all reload
pseudos in all reload instructions. I wondered about reusing the
On Sat, 29 Aug 2020, Hu Jiangping wrote:
> This patch add 'cd' command before 'make check-gcc' command
> when run the testsuite on selected tests.
No, don't do that; those targets work fine from the toplevel
too, and then include the language libs.
> Richard and I agree it would be good for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96940
--- Comment #2 from Jan Smets ---
This is the workaround I currently have. It avoids calling min_location().
diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index 90111e4c786..f49019e81d0 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -11005,8
> On Sep 4, 2020, at 1:04 PM, Segher Boessenkool
> wrote:
>
> On Fri, Sep 04, 2020 at 12:18:12PM -0500, Qing Zhao wrote:
>>> I call this very expensive, already,
>>
>> Yes, I think that 17.56% on average is quite expensive. That’s the data for
>> -fzero-call-used-regs=all, the worst case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96939
--- Comment #7 from Jakub Jelinek ---
AFAIK targetm.override_options_after_change is called at the end of switching
optimization (but not target) options.
So, that is a good hook to e.g. adjust something cached from those non-target
Optimization
On Fri, Sep 4, 2020 at 11:09 AM Segher Boessenkool
wrote:
>
> On Fri, Sep 04, 2020 at 10:34:23AM -0700, H.J. Lu wrote:
> > > You probably have to do this for every target separately? But it is not
> > > enough to handle it in the epilogue, you also need to make sure it is
> > > done on every
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85830
Carl Love changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Comment #9 from Carl Love ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85830
Carl Love changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85830
--- Comment #7 from CVS Commits ---
The releases/gcc-10 branch has been updated by Carl Love :
https://gcc.gnu.org/g:e86814328251ea7da83038605df01d8def8d873a
commit r10-8710-ge86814328251ea7da83038605df01d8def8d873a
Author: Carl Love
Date:
On Fri, Sep 04, 2020 at 10:34:23AM -0700, H.J. Lu wrote:
> > You probably have to do this for every target separately? But it is not
> > enough to handle it in the epilogue, you also need to make sure it is
> > done on every path that returns *without* epilogue.
>
> This feature is designed for
On Fri, Sep 04, 2020 at 12:18:12PM -0500, Qing Zhao wrote:
> > I call this very expensive, already,
>
> Yes, I think that 17.56% on average is quite expensive. That’s the data for
> -fzero-call-used-regs=all, the worst case i.e, clearing all the call-used
> registers at the return.
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96939
--- Comment #6 from Richard Earnshaw ---
(In reply to Jakub Jelinek from comment #4)
> Doesn't seem to be related to me, in the other PR everything is compiled
> with one set of options and no target attribute is involved either.
No, that's a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96939
--- Comment #5 from Richard Earnshaw ---
I batted my head against this when reworking the command line options stuff a
couple of years back, but the documentation on how the different hooks should
interact (especially for LTO and streaming) is,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96939
--- Comment #4 from Jakub Jelinek ---
Doesn't seem to be related to me, in the other PR everything is compiled with
one set of options and no target attribute is involved either.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96940
--- Comment #1 from Jan Smets ---
Likely duplicate of Bug 96391
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96391)
That one has a testcase for i686-w64-mingw32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96939
--- Comment #3 from Andrew Pinski ---
I think this is related to or a dup of bug 96882.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96391
Jan Smets changed:
What|Removed |Added
CC||jan.smets at nokia dot com
--- Comment #5
On Fri, Sep 4, 2020 at 8:18 AM Segher Boessenkool
wrote:
>
> Hi!
>
> On Mon, Aug 24, 2020 at 03:49:50PM -0500, Qing Zhao wrote:
> > > Do you want to do this before or after the epilogue code is generated?
> >
> > static rtx_insn *
> > make_epilogue_seq (void)
> > {
> > if
> On Sep 4, 2020, at 10:43 AM, Segher Boessenkool
> wrote:
>
> On Thu, Sep 03, 2020 at 10:13:35AM -0700, Kees Cook wrote:
>> On Thu, Sep 03, 2020 at 09:29:54AM -0500, Qing Zhao wrote:
>>> On average, all the options starting with “used_…” (i.e, only the
>>> registers that are used in the
On 9/3/20 2:44 PM, Martin Sebor wrote:
On 9/1/20 1:22 PM, Jason Merrill wrote:
On 8/11/20 12:19 PM, Martin Sebor via Gcc-patches wrote:
-Wplacement-new handles array indices and pointer offsets the same:
by adjusting them by the size of the element. That's correct for
the latter but wrong for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96898
--- Comment #5 from Jakub Jelinek ---
It wouldn't be a fallback. omp-low.c just decides if it is going to use
GOMP_atomic_{start,end} synchronization, __atomic_* or __sync_* to perform the
reduction. And whether that uses the same or different
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83591
--- Comment #8 from Manuel López-Ibáñez ---
(In reply to Tony E Lewis from comment #7)
> Manuel López-Ibáñez: are you happy that all underlying issues are resolved
> and this can be closed?
Sure.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96898
--- Comment #4 from Tom de Vries ---
(In reply to Jakub Jelinek from comment #3)
> For OpenMP reductions, we really don't care what kind of mutex protects the
> updates, as long as it is the same for all updates of the same reduction.
> I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96939
Jakub Jelinek changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96938
--- Comment #1 from Marc Glisse ---
With "char tmp" instead of "int tmp", we get the same code as the first
function.
Hi!
On Fri, Sep 04, 2020 at 12:44:17PM -0300, Raoni Fassina Firmino wrote:
> > > + switch (INTVAL (operands[1]))
> > > +{
> > > +case (1 << (31 - 6)): /* FE_INEXACT */
> >
> > I would just write it as 0x02000 etc.? much clearer, and you have
> > the comment demagicificating it
Excerpts from Alan Modra's message of September 4, 2020 3:34 pm:
> So this one is on top of the previously posted patch.
>
> * d-demangle.c (string_need): Take a size_t n arg, and use size_t tem.
> (string_append): Use size_t n.
> (string_appendn, string_prependn): Take a size_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96940
Bug ID: 96940
Summary: ICE in linemap_compare_locations, at
libcpp/line-map.c:1359
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87767
--- Comment #14 from Hongtao.liu ---
(In reply to Jakub Jelinek from comment #12)
> What I mean is that we should try to simplify the md file, instead of adding
> hundreds of new *_bcst patterns.
> We have e.g.
> (define_insn "*3"
> [(set
Changes since v1[1]:
- Fixed english spelling;
- Fixed code-style;
- Changed match operand predicate in feclearexcept and feraiseexcept;
- Changed testcase options;
- Minor changes in test code to be C90 compatible;
- Other minor changes sugested by Segher;
- Changed subject line tag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87767
--- Comment #13 from Hongtao.liu ---
Created attachment 49182
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49182=edit
bcst_vector_operand
Hi Segher,
on 2020/9/4 下午10:16, Segher Boessenkool wrote:
> Hi!
>
> On Fri, Sep 04, 2020 at 04:47:37PM +0800, Kewen.Lin wrote:
Apart from that, one P9 specific point is that the update form load isn't
preferred, the reason is that the instruction can not retire until both
parts
Hi,
I am about to sent a v2, but thought to reply here as well.
On Tue, Aug 18, 2020 at 07:09:21PM -0500, Segher Boessenkool wrote:
> Hi!
>
> On Fri, Aug 14, 2020 at 07:54:23PM -0300, Raoni Fassina Firmino via
> Gcc-patches wrote:
> > So, this patch adds new rs6000 expand optimizations for
On Thu, Sep 03, 2020 at 10:13:35AM -0700, Kees Cook wrote:
> On Thu, Sep 03, 2020 at 09:29:54AM -0500, Qing Zhao wrote:
> > On average, all the options starting with “used_…” (i.e, only the
> > registers that are used in the routine will be zeroed) have very low
> > runtime overheads, at most
Hi Andrea,
on 2020/9/4 下午8:11, Andrea Corallo wrote:
> Hi all,
>
> just a small patch removing a piece of unreachable code in
> 'vect_estimate_min_profitable_iters' given the condition
> (LOOP_VINFO_USING_PARTIAL_VECTORS_P (loop_vinfo)) is always true as
> checked just above.
>
FWIW, I had
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87530
--- Comment #3 from Marek Polacek ---
No longer accepted since r11-2411. The test should probably be added.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96913
--- Comment #2 from Sergei Trofimovich ---
(In reply to Sergei Trofimovich from comment #0)
> The hang happens on real tauthon-2.8.2 interpreter from PR96394 (no nice
> reproducer yet).
>
> In this instance I tried to build tauthon-2.8.2
On Mon, Aug 24, 2020 at 03:43:11PM -0500, Qing Zhao wrote:
> > On Aug 24, 2020, at 3:20 PM, Segher Boessenkool
> > wrote:
> >> For this testing? (Is CPU2017 good enough)?
> >
> > I would use something more real-life, not 12 small pieces of code.
>
> Then, what kind of real-life benchmark you
Hi!
On Mon, Aug 24, 2020 at 03:49:50PM -0500, Qing Zhao wrote:
> > Do you want to do this before or after the epilogue code is generated?
>
> static rtx_insn *
> make_epilogue_seq (void)
> {
> if (!targetm.have_epilogue ())
> return NULL;
>
> start_sequence ();
> emit_note
On Thu, Sep 03, 2020 at 04:46:43PM -0300, Alexandre Oliva wrote:
> On Sep 3, 2020, Segher Boessenkool wrote:
> > The idea is that none of them will need adjustment. This hook runs
> > before the "none" code will run, and it can just clear all clobbers
> > then.
>
> Uhh... That's not how asm
Hi!
On Thu, Sep 03, 2020 at 04:31:35PM -0300, Alexandre Oliva wrote:
> Except when it doesn't ;-)
Heh. PRs welcome :-)
> Under:
>
> /* If the actions of the earlier insns must be kept
> in addition to substituting them into the latest one,
> we must make a new PARALLEL for the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96939
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #1
On Fri, 2020-09-04 at 03:47 -0500, Segher Boessenkool wrote:
> Hi!
>
> On Fri, Sep 04, 2020 at 08:55:43AM +0200, Richard Biener wrote:
> > On Thu, Sep 3, 2020 at 8:10 PM Segher Boessenkool
> > wrote:
> > > On Thu, Sep 03, 2020 at 10:37:33AM -0500, will schmidt wrote:
> > > > On Wed, 2020-09-02
On 04/09/2020 15:19, Richard Biener wrote:
On Fri, Sep 4, 2020 at 10:13 AM Erick Ochoa
wrote:
On 03/09/2020 12:19, Richard Biener wrote:
On Thu, Sep 3, 2020 at 10:58 AM Jakub Jelinek via Gcc wrote:
On Thu, Sep 03, 2020 at 10:22:52AM +0200, Erick Ochoa wrote:
So, I am just wondering
> On Sep 3, 2020, at 8:23 PM, Rodriguez Bahena, Victor
> wrote:
>
>
>
> -Original Message-
> From: Qing Zhao mailto:qing.z...@oracle.com>>
> Date: Thursday, September 3, 2020 at 12:55 PM
> To: Kees Cook mailto:keesc...@chromium.org>>
> Cc: Segher Boessenkool
Hi!
On Fri, Sep 04, 2020 at 04:47:37PM +0800, Kewen.Lin wrote:
> >> Apart from that, one P9 specific point is that the update form load isn't
> >> preferred, the reason is that the instruction can not retire until both
> >> parts complete, it can hold up subsequent instructions from retiring.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96939
Bug ID: 96939
Summary: LTO vs. different arm arch options
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96938
Bug ID: 96938
Summary: Failure to optimize bit-setting pattern when not using
temporary
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96937
--- Comment #2 from Simon Marchi ---
Created attachment 49181
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49181=edit
Output from creduce
I compile the reproducer program with:
/opt/gcc/git/bin/g++ -x c++ -g3 -O2 -c bug.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96937
--- Comment #1 from Simon Marchi ---
I passed the program in creduce, the result is not pretty but it's not too big
and still reproduces the problem, so I'll attach it anyway.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96937
Bug ID: 96937
Summary: Duplicate DW_TAG_formal_parameter in out-of-line
DW_TAG_subprogram instance
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity:
Hello,
On 03 сен 08:17, H.J. Lu wrote:
> On Thu, Sep 3, 2020 at 8:08 AM Kirill Yukhin via Gcc-patches
> wrote:
> >
> > Hello,
> >
> > On 06 июл 09:58, Hongyu Wang via Gcc-patches wrote:
> > > Hi:
> > >
> > > This patch is about to support Intel Advanced Matrix Extensions (AMX)
> > > which will
Hi Bin,
On Fri, Sep 04, 2020 at 04:27:32PM +0800, Bin.Cheng wrote:
> On Fri, Sep 4, 2020 at 6:37 AM Segher Boessenkool
> wrote:
> > It should have cost, certainly, but not address_cost I think. The total
> > cost of an ldu should be a tiny bit less than that of ld + that of addi;
> > the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96920
Richard Biener changed:
What|Removed |Added
Known to work||11.0
Known to fail|11.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96698
--- Comment #3 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:46a58c779af3055a4b10b285a1f4be28abe4351c
commit r11-3013-g46a58c779af3055a4b10b285a1f4be28abe4351c
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96920
--- Comment #5 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:46a58c779af3055a4b10b285a1f4be28abe4351c
commit r11-3013-g46a58c779af3055a4b10b285a1f4be28abe4351c
Author: Richard Biener
Date:
The following adds the capability to code-generate live lanes in
basic-block vectorization using lane extracts from vector stmts
rather than keeping the original scalar code around for those.
This eventually makes previously not profitable vectorizations
profitable (the live scalar code was
So this one is on top of the previously posted patch.
* d-demangle.c (string_need): Take a size_t n arg, and use size_t tem.
(string_append): Use size_t n.
(string_appendn, string_prependn): Take a size_t n arg.
(TEMPLATE_LENGTH_UNKNOWN): Define as -1UL.
*
On Fri, Sep 4, 2020 at 10:13 AM Erick Ochoa
wrote:
>
>
>
> On 03/09/2020 12:19, Richard Biener wrote:
> > On Thu, Sep 3, 2020 at 10:58 AM Jakub Jelinek via Gcc
> > wrote:
> >>
> >> On Thu, Sep 03, 2020 at 10:22:52AM +0200, Erick Ochoa wrote:
> >>> So, I am just wondering is there an interface
On Fri, Sep 4, 2020 at 11:32 AM Hu, Jiangping
wrote:
>
> > I think the pages under gcc.gnu.org/projects/ are all hopelessly
> > out-of-date and more recent (but still usually out-of-date) info
> > is found on the wiki.
> >
> > So I'm not sure these kind of changes make sense.
> >
> > Eventually
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96933
--- Comment #4 from Segher Boessenkool ---
Yes, timing suggests there is some SHL/LHS flush.
On p9 and later we can use mtvsrdd instead of mtvsrd (moving two
bytes into place at one), which reduces the number of moves from
16 to 8, and the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96936
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84930
Marek Polacek changed:
What|Removed |Added
CC||kirshamir at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96935
--- Comment #3 from Jan Smets ---
A bisect resulted in this commit :
commit 0d48e8779c6a9ac88f5efd1b4a2d40f43ef75faf
Author: David Malcolm
Date: Fri Oct 5 19:02:17 2018 +
Support string locations for C++ in -Wformat (PR c++/56856)
On Tue, 1 Sep 2020, Martin Storsjö wrote:
Previously, the SEH version of _Unwind_Backtrace did unwind
the stack and call the provided callback function as intended,
but there was little the caller could do within the callback to
actually get any info about that particular level in the unwind.
Hi,
On Fri, 4 Sep 2020, Jakub Jelinek wrote:
On Tue, Sep 01, 2020 at 04:01:42PM +0300, Martin Storsjö wrote:
This fixes compilation of codepaths for dos-like filesystems
with Clang. When built with clang, it treats C input files as C++
when the compiler driver is invoked in C++ mode,
This refines the previous fix for PR96698 by re-doing how and where
we arrange for setting vectorized cycle PHI backedge values.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Richard.
2020-09-04 Richard Biener
PR tree-optimization/96698
PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96936
Bug ID: 96936
Summary: brace initialization of const char* from string
literal in specific cases doesn't compile
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96820
Martin Jambor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96820
--- Comment #8 from CVS Commits ---
The releases/gcc-10 branch has been updated by Martin Jambor
:
https://gcc.gnu.org/g:75f5776b3fc4dad7453f8b9cf1690bd2ad628991
commit r10-8709-g75f5776b3fc4dad7453f8b9cf1690bd2ad628991
Author: Martin Jambor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96920
--- Comment #4 from Richard Biener ---
Another example:
int a[1024];
int b[2048];
void foo (int x, int y)
{
for (int i = 0; i < 1024; ++i)
{
int tem0 = b[2*i];
int tem1 = b[2*i+1];
for (int j = 0; j < 32; ++j)
{
how to check the location corresponding to a gimple statement? My instrument
stmt include some memory access, I wish get right source code line. By context
it is possible get wrong line.
---Original---
From: "Richard Biener"
On Thu, Sep 3, 2020 at 8:19 PM Hans-Peter Nilsson wrote:
> On Thu, 27 Aug 2020, Pip Cet via Gcc wrote:
> > I may be missing an obvious workaround, but it seems we currently emit
> > a #line directive when including lines from machine description files
> > in C files, but never emit a second
Richard Biener writes:
> On Fri, 4 Sep 2020, Andrea Corallo wrote:
>
>> Hi all,
>>
>> just a small patch removing a piece of unreachable code in
>> 'vect_estimate_min_profitable_iters' given the condition
>> (LOOP_VINFO_USING_PARTIAL_VECTORS_P (loop_vinfo)) is always true as
>> checked just
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96929
Jakub Jelinek changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
On Fri, 4 Sep 2020, Andrea Corallo wrote:
> Hi all,
>
> just a small patch removing a piece of unreachable code in
> 'vect_estimate_min_profitable_iters' given the condition
> (LOOP_VINFO_USING_PARTIAL_VECTORS_P (loop_vinfo)) is always true as
> checked just above.
>
> Bootstrapped on
Hi all,
just a small patch removing a piece of unreachable code in
'vect_estimate_min_profitable_iters' given the condition
(LOOP_VINFO_USING_PARTIAL_VECTORS_P (loop_vinfo)) is always true as
checked just above.
Bootstrapped on aarch64-unknown-linux-gnu.
Okay for trunk?
Andrea
>From
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96933
--- Comment #3 from Richard Biener ---
very likely the byte stores and then the following vector load will also
trigger
STLF issues.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96935
--- Comment #2 from Richard Biener ---
Guess the error is simply that we fall back to no columns and thus start.column
== 0 and we do
char_span literal = line.subspan (start.column - 1, literal_length);
which means input.c:1467 should
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96769
Christophe Lyon changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96769
--- Comment #2 from CVS Commits ---
The master branch has been updated by Christophe Lyon :
https://gcc.gnu.org/g:2033a63cbd0aab27d3a8450b4a4a5b371d583c85
commit r11-3011-g2033a63cbd0aab27d3a8450b4a4a5b371d583c85
Author: Christophe Lyon
Date:
> I obtained perf stat results for following benchmark runs:
>
> -O2:
>
> 7856832.692380 task-clock (msec) #1.000 CPUs utilized
> 3758 context-switches #0.000 K/sec
> 40 cpu-migrations #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96935
--- Comment #1 from Jan Smets ---
Proper backtrace (10.2)
x.cpp: In function ‘void a()’:
x.cpp:3: internal compiler error: in subspan, at input.h:69
3 | #define DB_PRINTF(str, fmt, args...) db_printf(indent_len, 50, fmt,
str, ##args)
Excerpts from Alan Modra's message of September 4, 2020 2:59 am:
> On Thu, Sep 03, 2020 at 11:02:50PM +0200, Iain Buclaw wrote:
>> Excerpts from Alan Modra's message of September 3, 2020 3:01 pm:
>> > Running the libiberty testsuite
>> > ./test-demangle < libiberty/testsuite/d-demangle-expected
>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96935
Bug ID: 96935
Summary: ICE in subspan, at input.h:69
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
On 03/09/2020 09:24, Christophe Lyon via Gcc-patches wrote:
> This patch moves the move-immediate splitter after the regular ones so
> that it has lower precedence, and updates its constraints.
>
> For
> int f3 (void) { return 0x1100; }
> int f3_2 (void) { return 0x12345678; }
>
> we now
1 - 100 of 160 matches
Mail list logo
