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
La
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
--- 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, d
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 #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=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=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 touc
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 #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
cla
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=95535
Gabriel Ravier changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
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=96933
Kewen Lin changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
CC|
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 doesn't
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=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=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=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 #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, th
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91490
Gustaw Smolarczyk changed:
What|Removed |Added
CC||wielkiegie at gmail dot com
--- Comm
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 8.3,
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=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=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=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=96769
Christophe Lyon changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
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 che
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=96929
Jakub Jelinek changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
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=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
D
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=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=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=84930
Marek Polacek changed:
What|Removed |Added
CC||kirshamir at gmail dot com
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96936
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
Reso
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 numbe
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=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=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: norm
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
--- Comment #2 from Simon Marchi ---
Created attachment 49181
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49181&action=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=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=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=96939
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #1 fr
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 against
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=87767
--- Comment #13 from Hongtao.liu ---
Created attachment 49182
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49182&action=edit
bcst_vector_operand
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 (matc
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
P
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=96939
Jakub Jelinek changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
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 believe
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 #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=96391
Jan Smets changed:
What|Removed |Added
CC||jan.smets at nokia dot com
--- Comment #5 fr
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=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 #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=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, q
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 co
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: T
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
Carl Love changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Comment #9 from Carl Love ---
Is
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=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 +11
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 Se
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
Date:
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=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=95164
Marek Polacek changed:
What|Removed |Added
Keywords||patch
--- Comment #4 from Marek Polacek
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
76 matches
Mail list logo
