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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95164
Marek Polacek changed:
What|Removed |Added
Keywords||patch
--- Comment #4 from Marek Polacek
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:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96924
Iain Buclaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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
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
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
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:
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
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.
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
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
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
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
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:
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:
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)
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)
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96929
Jakub Jelinek changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
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:
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)
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96512
H.J. Lu changed:
What|Removed |Added
Status|WAITING |RESOLVED
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96512
--- Comment #6 from N Schaeffer ---
Hello,
Working further on this, it seems to be a problem in the assembler step, but
only on some installations.
I have a system where gcc 8.3 to 9 and 10 are good (no bug), while another
system where gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91490
Gustaw Smolarczyk changed:
What|Removed |Added
CC||wielkiegie at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96934
--- Comment #1 from Gustaw Smolarczyk ---
It seems that part of this issue was already reported in another bug report
(though the report is about flexible array members, the comment does not
reference them):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96933
--- Comment #2 from Kewen Lin ---
(In reply to Segher Boessenkool from comment #1)
> Is that actually faster though? The original has shorter dependency
> chains. Or is this to avoid some LHS/SHL?
Yes, I tested it with one constructed case,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96731
--- Comment #5 from Tony E Lewis ---
Thanks very much for your work on this.
That's a shame but I appreciate the problems you've highlighted.
> I don't plan to work on this any further for now.
Yes, fair enough.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96933
--- Comment #1 from Segher Boessenkool ---
Is that actually faster though? The original has shorter dependency
chains. Or is this to avoid some LHS/SHL?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96931
--- Comment #4 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:fab77644842869adc8871e133e4c3f4c35b2b245
commit r11-3009-gfab77644842869adc8871e133e4c3f4c35b2b245
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96931
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96934
Bug ID: 96934
Summary: Copy initialization of struct involving aggregate
array initialization miscompiles in GCC 9
Product: gcc
Version: 9.3.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96920
--- Comment #3 from Richard Biener ---
It's similar to PR96698 where we had a nested cycle where a cycle PHI was fed
by an induction. Here we're feeding the cycle PHI by another cycle PHI so the
fancy detection of computing a latch value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96933
Kewen Lin changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96933
Bug ID: 96933
Summary: inefficient code for char/short vec CTOR
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95535
Gabriel Ravier changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83591
--- Comment #7 from Tony E Lewis ---
Thanks for this comment T vd Sijs. Yes - I'm also able to compile this without
problem in 9.3 (and in 10.1).
Manuel López-Ibáñez: are you happy that all underlying issues are resolved and
this can be closed?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94893
Gabriel Ravier changed:
What|Removed |Added
Target|x86_64-*-* |
Blocks|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86419
--- Comment #9 from Dimitrij Mijoski ---
Ignore my last comment, here is it fixed.
Looking again at my proposed fix in comment #7, i concluded it is not the best
fix. It will fix the testsuite in the same comment #7, but I discovered another
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94880
Gabriel Ravier changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86419
--- Comment #8 from Dimitrij Mijoski ---
Looking again at my proposed fix in comment #6, i concluded it is not the best
fix. It will fix the testsuite in the same comment #6, but I discovered another
class of errors related to the lines I am
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96898
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96931
--- Comment #3 from Richard Biener ---
So the testcase only triggers on trunk because store commoning is new there and
it transforms (interestingly!)
[local count: 10631108]:
p3 ();
bl = 0;
[local count: 1073741824]:
bl.0_1 = bl;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96932
Bug ID: 96932
Summary: [nvptx] atomic_exchange missing barrier
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96931
--- Comment #2 from Richard Biener ---
diff --git a/gcc/tree-predcom.c b/gcc/tree-predcom.c
index b1d6e63559c..af71c269f4b 100644
--- a/gcc/tree-predcom.c
+++ b/gcc/tree-predcom.c
@@ -1960,7 +1960,8 @@ initialize_root_vars_lm (class loop *loop,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96898
--- Comment #2 from Tom de Vries ---
Hmm, I found this difference:
- AFAIU, GOMP_atomic_start/end have barrier semantics
- libatomics protect_start/end are always paired with explicit barriers, so
presumably these don't have barrier semantics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96931
Richard Biener changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96931
Bug ID: 96931
Summary: [11 Regression] ICE in add_phi_arg, at
tree-phinodes.c:359
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96918
--- Comment #7 from Richard Biener ---
(In reply to Jakub Jelinek from comment #6)
> Or the generic code could try to expand vector rotates by multiplies of
> BITS_PER_UNIT as vector permutations, perhaps only if there is no optab for
> it. Or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96930
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96926
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |9.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96927
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |11.0
81 matches
Mail list logo
