https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91518
--- Comment #3 from Xiong Hu XS Luo ---
(In reply to Richard Biener from comment #2)
> Not seen on x86_64. Given you bisected to r263875 it should appear with GCC
> 9 as well - are the actual GCC 9 releases also affected?
>
> I assume this is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90724
--- Comment #3 from prathamesh3492 at gcc dot gnu.org ---
(In reply to Eric Gallager from comment #2)
> (In reply to prathamesh3492 from comment #1)
> > Author: prathamesh3492
> > Date: Wed Aug 21 18:34:43 2019
> > New Revision: 274805
> >
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90724
--- Comment #2 from Eric Gallager ---
(In reply to prathamesh3492 from comment #1)
> Author: prathamesh3492
> Date: Wed Aug 21 18:34:43 2019
> New Revision: 274805
>
> URL: https://gcc.gnu.org/viewcvs?rev=274805=gcc=rev
> Log:
> 2019-08-21
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90552
--- Comment #6 from Eric Gallager ---
(In reply to uros from comment #5)
> Author: uros
> Date: Thu May 23 19:46:56 2019
> New Revision: 271576
>
> URL: https://gcc.gnu.org/viewcvs?rev=271576=gcc=rev
> Log:
> PR target/90552
> *
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89180
Bug 89180 depends on bug 91304, which changed state.
Bug 91304 Summary: maybe_unused attribute ignored on variable declared in if
declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91304
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91304
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91304
--- Comment #4 from Marek Polacek ---
Author: mpolacek
Date: Fri Aug 23 00:06:25 2019
New Revision: 274839
URL: https://gcc.gnu.org/viewcvs?rev=274839=gcc=rev
Log:
PR c++/91304 - prefix attributes ignored in condition.
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91490
Martin Sebor changed:
What|Removed |Added
Summary|[9/10 Regression] bogus |[9 Regression] bogus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90883
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91490
--- Comment #3 from Martin Sebor ---
Author: msebor
Date: Thu Aug 22 23:09:26 2019
New Revision: 274837
URL: https://gcc.gnu.org/viewcvs?rev=274837=gcc=rev
Log:
PR middle-end/91490 - bogus argument missing terminating nul warning on strlen
of a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91512
--- Comment #14 from Sunil Pandey ---
(In reply to Richard Biener from comment #7)
> (In reply to Sunil Pandey from comment #4)
> > Actually it is spec cpu 2017 521.wrf benchmark getting this problem while
> > compiling. Compilation taking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91481
--- Comment #6 from Segher Boessenkool ---
Author: segher
Date: Thu Aug 22 19:36:21 2019
New Revision: 274835
URL: https://gcc.gnu.org/viewcvs?rev=274835=gcc=rev
Log:
rs6000: Use unspec_volatile for darn (PR91481)
Every call to darn should
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91519
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||seurer at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91524
kargl at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91525
Bug ID: 91525
Summary: ICE (Segmentation Fault) on a bool conversion operator
with concepts
Product: gcc
Version: 8.3.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91473
--- Comment #9 from seurer at gcc dot gnu.org ---
Note pr91524
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91519
--- Comment #9 from Thomas Koenig ---
(In reply to kargl from comment #7)
> The function check_externals_expr
> is somewhat odd. It is declared to return int, but all return
> statements are 'return 0'. This suggests to me that proper
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91524
Bug ID: 91524
Summary: [10 regression] module_comm_dm.fppized.f90 in cpu 2017
ICEs in fortran compiler starting with r274551
Product: gcc
Version: 10.0
Status:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91519
--- Comment #8 from Thomas Koenig ---
Yes, the treatment of namespaces was dogdgy.
This is fixed in https://gcc.gnu.org/ml/gcc-patches/2019-08/msg01438.html (not
yet reviewed).
HJ, does this patch also fix the original test case?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91519
kargl at gcc dot gnu.org changed:
What|Removed |Added
Status|WAITING |NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91519
kargl at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91519
--- Comment #7 from kargl at gcc dot gnu.org ---
Thomas, this is fixed by
% svn diff gcc/fortran/frontend-passes.c
Index: gcc/fortran/frontend-passes.c
===
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91522
--- Comment #3 from Richard Biener ---
Uh, all other DF_REG_REG_CHAIN uses need to be updated as well I guess, how
we convert defs and uses seems to be a slight mess :/ I'm going to try
to rewrite this part to
for insn in insns
for def in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91115
--- Comment #7 from Fred Hsueh ---
This looks more like an odd interaction with ASAN and fork(). The process
reporting the stack-buffer-overflow is actually a fork() child of the main
process.
Something similar to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91523
Bug ID: 91523
Summary: Register allocation picks sub-optimal alternative with
scratch registers
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91522
--- Comment #2 from Richard Biener ---
So in particular
for (ref = DF_INSN_UID_DEFS (insn_uid); ref; ref = DF_REF_NEXT_LOC (ref))
if (!HARD_REGISTER_P (DF_REF_REG (ref)))
for (def = DF_REG_DEF_CHAIN (DF_REF_REGNO (ref));
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91521
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91522
Richard Biener changed:
What|Removed |Added
Keywords||compile-time-hog
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91522
Bug ID: 91522
Summary: [10 Regression] STV is slow
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91512
--- Comment #13 from Richard Biener ---
Btw, for me module_configure.fppized.f90 is much more problematic, compiling
longest and using most memory. IIRC that one has long series of initialization
expressions. And
load CSE after reload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91521
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91512
--- Comment #12 from Thomas Koenig ---
(In reply to rguent...@suse.de from comment #11)
> > One or two dimensional?
>
> Two or three dimensional. I didn't review all callees and
> arguments but there seems to be a 1:1 match, so both
> callers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78176
--- Comment #35 from Maciej W. Rozycki ---
So presumably the actual solution for n32 would be the same as with x32
and SIB, which IIUC cannot rely on hardware wrapping around the address
space either.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78176
--- Comment #34 from Maciej W. Rozycki ---
(In reply to mpf from comment #29)
> I don't remember the detail of this issue but I believe I was convinced that
> it is down to the lack of setting PX appropriately in HW. UX==0, PX==1. The
> PX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91521
Richard Biener changed:
What|Removed |Added
Keywords||rejects-valid
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91507
--- Comment #3 from Richard Biener ---
Note that lldb has
(lldb) p zzz
(char *[2]) $0 = ([0] = "abc", [1] = "cde")
for the proposed variant with an extra DW_AT_type in the specification DIE and
(lldb) p zzz
error: incomplete type 'char *[]'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91512
--- Comment #11 from rguenther at suse dot de ---
On Thu, 22 Aug 2019, tkoenig at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91512
>
> --- Comment #10 from Thomas Koenig ---
>
> > Yes, but in the WRF file I see no
* operator->() { return this; }
};
int main()
{
int pt(foo()->bar());
return pt;
}
With g++ 9.1.0, 9.2.0, 10.0.0 20190822 (experimental), compilation fails with
"error: ‘parameter’ function with trailing return type not declared with ‘auto’
type specifier"
error messag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78176
--- Comment #33 from Thomas De Schampheleire ---
(In reply to Andrew Pinski from comment #32)
> >I'm currently using -march=octeon3 or -march=octeon2 as appropriate.
>
> Can you report this to Marvell (Cavium)? O32 was not used much on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78176
--- Comment #32 from Andrew Pinski ---
>I'm currently using -march=octeon3 or -march=octeon2 as appropriate.
Can you report this to Marvell (Cavium)? O32 was not used much on Octeon.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78176
--- Comment #31 from Thomas De Schampheleire ---
(In reply to Maciej W. Rozycki from comment #27)
> Yes, it is the same problem, the same address calculation occurs here,
> and the lack of 32-bit address space wraparound is a part of the n32
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91512
--- Comment #10 from Thomas Koenig ---
> Yes, but in the WRF file I see no assumed-shape arrays but all
> appear to be of dimension(low:high,...) style.
One or two dimensional?
Code like
subroutine foo(a)
real, intent(in), dimension(*)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78176
--- Comment #30 from Thomas De Schampheleire ---
(In reply to mpf from comment #29)
> I don't remember the detail of this issue but I believe I was convinced that
> it is down to the lack of setting PX appropriately in HW. UX==0, PX==1. The
> PX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80481
--- Comment #11 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #10)
.L31:
leaq(%rdx), %rsi
negq%rsi
vpermps (%r9,%rsi), %zmm8, %zmm0
--> vmovaps %zmm0, %zmm1
vmaxps (%r11,%rdx), %zmm3,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80481
Uroš Bizjak changed:
What|Removed |Added
Target Milestone|--- |10.0
--- Comment #10 from Uroš Bizjak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91512
--- Comment #9 from rguenther at suse dot de ---
On Thu, 22 Aug 2019, tkoenig at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91512
>
> --- Comment #8 from Thomas Koenig ---
> This should be exposed by
>
> module y
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91512
--- Comment #8 from Thomas Koenig ---
This should be exposed by
module y
contains
subroutine bar(a,n)
real, dimension(n), intent(inout) :: a
a = a + 1.0
end subroutine bar
end module y
module x
use y
contains
subroutine foo(a)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78176
--- Comment #29 from mpf at gcc dot gnu.org ---
I don't remember the detail of this issue but I believe I was convinced that it
is down to the lack of setting PX appropriately in HW. UX==0, PX==1. The PX
control bit forces address calculations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91507
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91520
Iain Sandoe changed:
What|Removed |Added
Keywords||assemble-failure
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91520
Bug ID: 91520
Summary: AVX512 target assembler fails for x86_64 Darwin
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91512
--- Comment #7 from Richard Biener ---
(In reply to Sunil Pandey from comment #4)
> Actually it is spec cpu 2017 521.wrf benchmark getting this problem while
> compiling. Compilation taking forever, you can see while compiling file
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91519
--- Comment #6 from Hongtao.liu ---
Created attachment 46744
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46744=edit
Fortran source code
Command line to reproduce this issue.
gfortran -m64 -c -o module_comm_dm_3.fppized.o -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61250
Iain Sandoe changed:
What|Removed |Added
Target Milestone|--- |7.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61250
--- Comment #24 from Iain Sandoe ---
Created attachment 46743
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46743=edit
Make sure we process the PRAGMA_GCC_PCH_PREPROCESS first
We need to make sure that we've acted on the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91512
--- Comment #6 from Richard Biener ---
Sounds similar to PR91509. The rev. in question can end up exposing a lot more
loops which I think is not necessarily bad but may uncover issues in the
compiler. For PR91509 it is the prefetching pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91514
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization, openmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91518
Richard Biener changed:
What|Removed |Added
Target||powerpc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91510
--- Comment #4 from Richard Biener ---
Created attachment 46742
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46742=edit
original testcase
Original testcase.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78176
--- Comment #28 from Richard Biener ---
(In reply to James Cowgill from comment #0)
> Before the ldxc1 instruction is executed, gdb reports that the values in v0
> and s0 are both large integers (above 0x8000):
> (gdb) print/x $v0
> $1 =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91519
--- Comment #5 from Hongtao.liu ---
(In reply to kargl from comment #4)
> We need the Fortran source not the *.mod file.
You can use samp.f90.
61 matches
Mail list logo
