https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94482
--- Comment #12 from Jakub Jelinek ---
Reduced testcase (-O2 -msse2 -m32):
typedef unsigned V __attribute__ ((__vector_size__ (16)));
union U
{
V j;
unsigned long long i __attribute__ ((__vector_size__ (16)));
};
static inline __attribute__(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94482
--- Comment #13 from Richard Biener ---
(In reply to Martin Liška from comment #9)
> (In reply to Evan Nemerson from comment #8)
> > Created attachment 48204 [details]
> > Reduced test case, ASan/UBSan clean
> >
> > Here is the reduced test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94483
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |9.4
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94482
Jakub Jelinek changed:
What|Removed |Added
Summary|Inserting into vector with |[8/9/10 Regression]
|o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94482
--- Comment #15 from Martin Liška ---
(In reply to Jakub Jelinek from comment #12)
> Reduced testcase (-O2 -msse2 -m32):
> typedef unsigned V __attribute__ ((__vector_size__ (16)));
> union U
> {
> V j;
> unsigned long long i __attribute__ ((
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94493
--- Comment #6 from Richard Biener ---
Can you try if not using PCH fixes the issue?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94482
Jakub Jelinek changed:
What|Removed |Added
Keywords||wrong-code
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94495
Bug ID: 94495
Summary: [10 Regression] Debug info size growth since
r10-7515-g2c0fa3ecf70d199a
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94495
Martin Liška changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93946
--- Comment #16 from Richard Biener ---
OK, now looking myself. RTL expansion creates
(insn 8 7 9 2 (set (mem/j:SI (reg/v/f:SI 47 [ bv ]) [1 bv_3(D)->b.u.f+0 S4
A32])
(reg:SI 49)) "t.c":12:13 -1
(nil))
(insn 9 8 10 2 (set (mem/j:SI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94495
--- Comment #1 from Jakub Jelinek ---
The numbers I got is that something grew up a little bit, something shrunk a
little bit, sometimes .debug_info grew up and .debug_loc shrunk, sometimes the
other way around, but in general it wasn't significa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93946
--- Comment #17 from Richard Biener ---
x86 splits large stores only after reload it seems. Also on x86 GIMPLE
store-merging triggers, merging the two = 0 stores so I need -fno-store-merging
to
even get two stores there. Still the issue in CSE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94482
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94482
--- Comment #17 from Richard Biener ---
This:
if (write)
{
gassign *stmt;
if (access->grp_partial_lhs)
ref = force_gimple_operand_gsi (gsi, ref, true, NULL_TREE,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93621
--- Comment #17 from Martin Jambor ---
Created attachment 48208
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48208&action=edit
WIP patch
This is the current version of my patch to fix this. I think that at
least for the purposes of JIT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94482
--- Comment #18 from Richard Biener ---
(In reply to Richard Biener from comment #17)
> This:
>
> if (write)
> {
> gassign *stmt;
>
> if (access->grp_partial_lhs)
> ref = force_g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94496
Bug ID: 94496
Summary: [D] Use aggressive optimizations in release mode
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94469
--- Comment #2 from Tom de Vries ---
(In reply to Richard Biener from comment #1)
> Do you know under which circumstances gdb asks which symbol to print?
> Because
> I've never seen this for C or C++ and it should be present for _all_ global
> v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94482
--- Comment #19 from Richard Biener ---
gcc.dg/torture/pr52244.c ICEs on the generated
VIEW_CONVERT_EXPR(u) = bar ();
since V_C_E on the LHS are generally unwanted (but Ada has them for aggregates
just not in outermost position). What's alwa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94497
Bug ID: 94497
Summary: Branchless clamp in the general case gets a branch in
a particular case ?
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94469
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2020-04-06
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94497
--- Comment #1 from Andrew Pinski ---
So there might be some jump threading going on which is causing this issue.
There might already be a bug about that case too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62080
--- Comment #7 from Andrew Pinski ---
I suspect this has been improved already.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94469
--- Comment #4 from Tom de Vries ---
(In reply to Tom de Vries from comment #2)
(In reply to Richard Biener from comment #3)
> Ah, thanks for the hints - that's something I can work with more easily than
> an Ada testcase ;)
Sure :)
FWIW, the g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94469
--- Comment #5 from Tom de Vries ---
(In reply to Tom de Vries from comment #4)
> (In reply to Tom de Vries from comment #2)
> (In reply to Richard Biener from comment #3)
> $ gdb -readnow -batch a.out -ex "p aaa" -ex "p bbb" -ex "p ccc"
> $1 =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94469
--- Comment #6 from Richard Biener ---
Btw, I still wonder how it works with abstract functions, inline and concrete
instances. Works in gdb, that is - will dig into it a bit after lunch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94474
--- Comment #1 from Bernd Edlinger ---
Hi,
I use a newer binutils versions FWIW, and buit GCC-10 from
a few days ago using those binutils.
$ readelf -version
GNU readelf (GNU Binutils) 2.32
Copyright (C) 2019 Free Software Foundation, Inc.
This
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62080
Marc Glisse changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94469
--- Comment #7 from Richard Biener ---
(In reply to Richard Biener from comment #6)
> Btw, I still wonder how it works with abstract functions, inline and
> concrete instances. Works in gdb, that is - will dig into it a bit after
> lunch.
So he
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94474
--- Comment #2 from Andrew Burgess ---
Sorry for including the wrong DWARF dump output in the bug report. I too had
seen the DW_AT_GNU_entry_view using a more recent binutils.
When you pose the question:
I am not sure if there are any view n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94474
--- Comment #3 from Bernd Edlinger ---
(In reply to Andrew Burgess from comment #2)
> Sorry for including the wrong DWARF dump output in the bug report. I too
> had seen the DW_AT_GNU_entry_view using a more recent binutils.
>
NP.
> When you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94474
--- Comment #4 from Bernd Edlinger ---
Can you please approve my patch now?
https://sourceware.org/pipermail/gdb-patches/2020-April/167385.html
Thanks
Bernd.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94307
--- Comment #7 from Martin Liška ---
Created attachment 48209
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48209&action=edit
Patch candidate for shift_out_of_bounds
Patch for GCC that supports -fsanitize-minimal-runtime for shift_out_of_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94325
--- Comment #3 from Jakub Jelinek ---
sizeof (MD) == sizeof (void *), so the clearing of the vptr in DD::~DD() when
DE::~DE() is invoked later on looks wrong.
But, without -fsanitize=vptr this isn't done.
I've added that guard in PR87095, see
htt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94469
--- Comment #8 from Tom de Vries ---
(In reply to Richard Biener from comment #7)
> (In reply to Richard Biener from comment #6)
> > Btw, I still wonder how it works with abstract functions, inline and
> > concrete instances. Works in gdb, that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94498
Bug ID: 94498
Summary: std::basic_string_view::copy not qualified constexpr
in c++2a
Product: gcc
Version: 9.3.0
Status: UNCONFIRMED
Severity: normal
() at t.c:5
5 return i;
(gdb) p i
1
while when using DW_TAG_partial_unit:
(gdb) p i
No symbol "i" in current context.
Compilation Unit @ offset 0xc7:
Length:0x3d (32-bit)
Version: 4
Abbrev Offset: 0x64
Pointer Size: 8
<0>: Abbrev Number: 1 (DW_TAG_compil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94325
--- Comment #4 from Jakub Jelinek ---
Created attachment 48210
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48210&action=edit
gcc10-pr94325.patch
The shot in the dark in whole patch form.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94469
--- Comment #10 from Richard Biener ---
It works again when re-adding the imports. info variables then shows
File t.c:
1: static const int i;
for the case of a single import. When I import twice (into two CUs) I
still see only one 'i' li
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94495
--- Comment #2 from Richard Biener ---
Looks like ~20% for the first case so possibly worth investigating. I can very
well imagine we now less often run into some cut-offs and generate debug while
we gave up previously.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94499
Bug ID: 94499
Summary: [concepts] bogus "local variable may not appear in
this context" error
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94442
Wilco changed:
What|Removed |Added
CC||wdijkstr at arm dot com
--- Comment #2 from Wilc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94474
--- Comment #5 from Andrew Burgess ---
Bernd,
Wouldn't DW_AT_GNU_exit_view be attached to the DW_TAG_inlined_subroutine
though?
So, as in this case, one subroutine has 2 ranges, but would then have one end
view number.
I don't understand wh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94474
--- Comment #6 from Bernd Edlinger ---
Right,
#+BEGIN_EXAMPLE
0030 00400545 00400545 (start == end)
0030 00400549 00400553
0030 00400430 00400435
0030
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94482
--- Comment #20 from Richard Biener ---
(In reply to Richard Biener from comment #19)
> gcc.dg/torture/pr52244.c ICEs on the generated
>
> VIEW_CONVERT_EXPR(u) = bar ();
>
> since V_C_E on the LHS are generally unwanted (but Ada has them for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94500
Bug ID: 94500
Summary: Wrong maximum value with small integer types and
AVX-512
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94500
--- Comment #1 from Benedikt Steinbusch ---
Created attachment 48212
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48212&action=edit
Fortran program that triggers the bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94501
Bug ID: 94501
Summary: bogus "no matches converting function ... to type ..."
error with variadic function template
Product: gcc
Version: 10.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94495
--- Comment #3 from Martin Liška ---
One TU difference from SPEC2006 454.calculix:
$ gfortran -c -o restarts.o -ISPOOLES -Ofast -g -std=legacy restarts.f
...
$ ~/Programming/bloaty/bloaty restarts.o -- /tmp/before.o
VM SIZE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94474
--- Comment #7 from Bernd Edlinger ---
> I don't understand why each range wouldn't need its own view number?
Each of the sub ranges end PC can be an exit point.
At least how I see it.
Please have a look at my patch.
It adds each of the ranges
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94425
--- Comment #3 from Iain Buclaw ---
For now I'll default it to ASM_VOLATILE_P. Perhaps with a possibility to turn
it off in the future as an aggressive optimization outlined in pr94496.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94498
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |9.4
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94495
--- Comment #4 from Martin Liška ---
There's a bigger object file:
$ /Programming/bloaty/bloaty nonlingeo.after.o
VM SIZE FILE SIZE
-- --
84.0% 32.7Ki .text
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94497
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2020-04-06
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94497
--- Comment #3 from Richard Biener ---
Created attachment 48213
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48213&action=edit
incomplete patch
In case anybody is interested to complete it ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94497
--- Comment #4 from Richard Biener ---
As a workaround you can use -ffinite-math-only -fno-signed-zeros if that is
applicable to the rest of your application.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94482
--- Comment #21 from Martin Jambor ---
As Richi already found out, the path in sra_modify_expr handling type
incompatible replacement does not work when the replaced expr comes
from within a BIT_FIELD_REF - it does only half of what is necessary.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94500
Jakub Jelinek changed:
What|Removed |Added
Last reconfirmed||2020-04-06
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94497
--- Comment #5 from Hadrien Grasland ---
Thanks for the clarifications! We could probably live with -fno-signed-zeros,
but I think -ffinite-math-only would be too much as an application-wide flag,
as I've spotted several occurences of the "do the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94474
--- Comment #8 from Andrew Burgess ---
Bernd,
Please could you keep discussion of GDB patches to the GDB mailing list unless
it is required to move this bug forward.
In this bug I make the claim that the DWARF GCC produces is not correct. So
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94502
Bug ID: 94502
Summary: [aarch64] Missing LR register location in FDE
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94500
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94230
--- Comment #8 from qinzhao at gcc dot gnu.org ---
(In reply to David Malcolm from comment #6)
> If you have a huge workload, one possible workaround would be to disable
> range tracking, perhaps tweaking line_table->default_range_bits, which woul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94462
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94500
--- Comment #4 from Jakub Jelinek ---
Created attachment 48214
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48214&action=edit
gcc8-pr94500.patch
Untested fix. Richi's r265004 commit has been an optimization which
essentially causes ix86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35968
--- Comment #12 from Patrick J. LoPresti ---
(In reply to Anders Kaseorg from comment #11)
> (In reply to Patrick J. LoPresti from comment #10)
> > Complexity: Linear on average.
> >
> > It is not obvious (to me) what distribution the "on averag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89096
--- Comment #31 from David Edelsohn ---
Just to be clear, the -brtl allows runtime overriding symbols. GCC is correctly
placing some symbols that should not be overridden in the text section. To
allow the runtime overriding, which is not needed f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94503
Bug ID: 94503
Summary: ICE in saved_diagnostic, at
analyzer/diagnostic-manager.cc:84
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94497
Richard Biener changed:
What|Removed |Added
Target||x86_64-*-* i?86-*-*
--- Comment #6 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94482
--- Comment #22 from Richard Biener ---
Note that when REALPART_EXPR/IMAGPART_EXPR or BIT_FIELD_REF was there using
a VIEW_CONVERT_EXPR on their op0 should be OK. Since we then have
grp_partial_def SRA will ensure the replacement is not written
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94155
--- Comment #4 from CVS Commits ---
The master branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:f84aded848f6fdd2704c9376263c6d1aee6bb0ca
commit r10-7568-gf84aded848f6fdd2704c9376263c6d1aee6bb0ca
Author: Marek Polacek
Date: Mo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94155
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94493
--- Comment #7 from Kurt Jaeger ---
This command produces -E output, see attached out.txt and err.txt:
g++9 \
-v \
-E \
-std=c++17 \
-DHAVE_CONFIG_H \
-I. \
-I../../src/include \
-isystem /
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94493
--- Comment #8 from Kurt Jaeger ---
Created attachment 48215
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48215&action=edit
stderr of working build
stdout is at: https://people.freebsd.org/~pi/logs/out.txt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94495
--- Comment #5 from Jakub Jelinek ---
Can be also reproduced with
void bar (int, int, int, int, int, int, int, int, int, int, int, int *);
int
foo (int a, int b, int c, int d, int e, int f, int g, int h, int i, int j, int
k)
{
int z[64];
if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94479
--- Comment #3 from Thomas Klausner ---
Here's a backtrace from 9.3.0:
rebase.i:5:1: warning: no semicolon at end of struct or union
5 | } e() {
| ^
rebase.i: In function 'e':
rebase.i:6:23: warning: initialization of 'char' from 'char
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94498
--- Comment #1 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:b696698767ba45b4d61a93205167e2f1f744d3f1
commit r10-7569-gb696698767ba45b4d61a93205167e2f1f744d3f1
Author: Jonathan Wakely
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87644
Fritz Reese changed:
What|Removed |Added
Known to fail||7.1.0, 7.2.0, 7.3.0, 8.1.0,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87923
Fritz Reese changed:
What|Removed |Added
Target Milestone|--- |10.0
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92989
--- Comment #12 from CVS Commits ---
The master branch has been updated by Richard Sandiford :
https://gcc.gnu.org/g:e83714f65d1f75fc5af39f9fdc520a909dfc7635
commit r10-7570-ge83714f65d1f75fc5af39f9fdc520a909dfc7635
Author: Richard Sandiford
D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92989
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolutio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93642
Egor Suvorov changed:
What|Removed |Added
CC||egor_suvorov at mail dot ru
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94504
Bug ID: 94504
Summary: On powerpc, -ffunction-sections -fdata-sections is not
as effective as expected for PIE executables.
Product: gcc
Version: 9.3.0
Status: UNCONFIRME
la as x.ii, pre-processed sources.
Kurt, I tried to reproduce this on x86_64-suse-linux (9.2.1 20200306),
i386-unknown-freebsd 11.3 (10.0.1 20200406), but did not succeed with
your input file and the invocation you shared.
Can you run your build with option -save-temps and see whether the resulting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94493
--- Comment #10 from Kurt Jaeger ---
If the option -fstack-protector-strong is used, the *.i* files are empty.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35968
--- Comment #13 from Anders Kaseorg ---
(In reply to Patrick J. LoPresti from comment #12)
> I am familiar with the usual algorithmic complexity definitions.
>
> So, just to be clear... Your assertion is that the C++ standards committee
> adopte
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90996
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
St
~~~^~~~
t.cxx:3:18: warning: suggest parentheses around '&&' within '||'
[-Wparentheses]
Reproducible with any recent gcc version including gcc-trunk-20200406 (on
godbolt).
[1]
http://gcc.1065356.n8.nabble.com/Logical-operator-inside-fold-expression-strange-warning-td1627740.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94505
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2020-04-06
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94492
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2020-04-06
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93686
--- Comment #3 from CVS Commits ---
The master branch has been updated by Fritz Reese :
https://gcc.gnu.org/g:d42a2e465d821517819a54f4f613bb6e6443dc05
commit r10-7572-gd42a2e465d821517819a54f4f613bb6e6443dc05
Author: Fritz Reese
Date: Mon Ap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93686
Fritz Reese changed:
What|Removed |Added
CC||foreese at gcc dot gnu.org
Sta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94489
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
Ke
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93686
--- Comment #5 from CVS Commits ---
The releases/gcc-9 branch has been updated by Fritz Reese
:
https://gcc.gnu.org/g:83c9ff0291e88d5940ec0962f386b57705ede648
commit r9-8457-g83c9ff0291e88d5940ec0962f386b57705ede648
Author: Fritz Reese
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93686
--- Comment #6 from Fritz Reese ---
Backported to 9.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90275
--- Comment #20 from Jeffrey A. Law ---
90275, the gift that keeps giving. While the failure is similar, this feels
slightly different.
In this case we've got:
(insn 60 54 61 4 (parallel [
(set (reg:CC 100 cc)
(com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94506
Bug ID: 94506
Summary: broken code generate on MIPS
Product: gcc
Version: 8.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
||foreese at gcc dot gnu.org
Last reconfirmed|2018-07-24 00:00:00 |2020-4-6
--- Comment #5 from Fritz Reese ---
I can confirm using valgrind that the invalid read is still present on trunk:
[...]
$ gfortran --version |& head -n1
GNU Fortran (GCC) 10.0.1 20200406 (experime
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90275
--- Comment #21 from Jeffrey A. Law ---
So we may be able to address this by setting "do_not_record" if we have
multiple sets in an insn, one of which is a reg->reg copy to a destination that
is mentioned in a REG_UNUSED note. We'd only need to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91799
Jeffrey A. Law changed:
What|Removed |Added
Priority|P1 |P2
1 - 100 of 126 matches
Mail list logo
