https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83572
--- Comment #4 from Arseny Solokha ---
*** Bug 83570 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83570
Bug ID: 83570
Summary: [8 Regression] [graphite] ICE in verify_dominators, at
dominance.c:1184 (error: dominator of 7 should be 15,
not 13)
Product: gcc
Version:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83575
--- Comment #2 from Arseny Solokha ---
*** Bug 83571 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83571
Bug ID: 83571
Summary: [8 Regression] ICE: verify_flow_info failed (error:
multiple hot/cold transitions found)
Product: gcc
Version: 8.0
Status: RESOLVED
Keywo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83575
Bug ID: 83575
Summary: [8 Regression] ICE: verify_flow_info failed (error:
multiple hot/cold transitions found)
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Ke
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83572
--- Comment #3 from Arseny Solokha ---
*** Bug 83576 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83572
--- Comment #2 from Arseny Solokha ---
*** Bug 83577 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83576
Bug ID: 83576
Summary: [8 Regression] [graphite] ICE in verify_dominators, at
dominance.c:1184 (error: dominator of 7 should be 15,
not 13)
Product: gcc
Version:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83565
--- Comment #12 from Jason Duerstock ---
Some additional information:
1) The code works properly under 6.4.0.
2) The code works properly with -O1 -fno-tree-ter.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83574
Arseny Solokha changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83578
Bug ID: 83578
Summary: [8 Regression] ICE: verify_flow_info failed (error:
multiple hot/cold transitions found)
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Ke
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83577
Bug ID: 83577
Summary: [8 Regression] [graphite] ICE in verify_dominators, at
dominance.c:1184 (error: dominator of 7 should be 15,
not 13)
Product: gcc
Version:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83574
Bug ID: 83574
Summary: [8 Regression] [graphite] ICE in verify_dominators, at
dominance.c:1184 (error: dominator of 7 should be 15,
not 13)
Product: gcc
Version:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83572
Bug ID: 83572
Summary: [8 Regression] [graphite] ICE in verify_dominators, at
dominance.c:1184 (error: dominator of 7 should be 15,
not 13)
Product: gcc
Version:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83573
Bug ID: 83573
Summary: Wrong constant folding
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83565
Jim Wilson changed:
What|Removed |Added
CC||wilson at gcc dot gnu.org
--- Comment #11 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83560
Jerry DeLisle changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83568
--- Comment #1 from Kan Wang ---
Sorry for wrong paste, the code should be
#include
bool initialized = false;
int init() {
initialized = true;
return 1;
}
struct A {
static thread_local int foo;
};
thread_local int A::foo { init(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83568
Bug ID: 83568
Summary: thread_local class members not initialized before
accessed using operator ::
Product: gcc
Version: 7.1.1
Status: UNCONFIRMED
Severity: no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35014
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
--- Comment
%k)) :: c
c%foo=a%foo+b%foo
end function
end module pdt_m
program test_pdt
use pdt_m
implicit none
type(vec) :: u,v,w
u%foo=[1,2,3]
v%foo=[2,3,4]
w=addvv(u,v)
print *,w
end program test_pdt
% gfortran-8 --version
GNU Fortran (Debian 8-20171223-1) 8.0.0 20171223 (experimental
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83566
--- Comment #1 from Ruslan ---
> As n decreases, the imprecision gradually gets smaller.
To avoid confusion: this statement is for fixed x>1000.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83566
Bug ID: 83566
Summary: cyl_bessel_j returns wrong result for x>1000 for high
orders.
Product: gcc
Version: 7.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83560
--- Comment #4 from urbanjost at comcast dot net ---
Yes - just to confirm, I only found a problem with the missing plus with
INTEGER values printed without an explicit format. Everything I tried with
floating-point values (REAL and COMPLEX) confo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47618
--- Comment #17 from Petr Špaček ---
I found this bug while searching for a way to solve exactly this problem, so
for the record: It sounds like very good and useful addition. Thank you!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83565
--- Comment #10 from Sergei Trofimovich ---
> The patch works on an attached example. Building 7.2.0 with your patch to
> check on openssl testsuite.
Full openssl-1.0.2n test suite now passes with this patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83315
Segher Boessenkool changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81837
Paolo Carlini changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83565
--- Comment #9 from Segher Boessenkool ---
#0 means subreg 0; in this case, (subreg:DI (reg:SI 357) 0) etc.
(The "slim" RTL dumps are lossy in places btw; in _this_ case you
can deduce it has to be DImode, but not always. OTOH slim dumps
take
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83565
--- Comment #8 from Sergei Trofimovich ---
Ah, tricky. That makes sense!
Shows again how bad I am at reading RTL logs. Is there a doc I could get
through to understand what '#0' means (my guess it's "zero-extend") in '22:
r358:DI=r357:SI#0^r341:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83540
--- Comment #4 from Harald Anlauf ---
(In reply to Dominique d'Humieres from comment #3)
> The code uses ALLOCATE without any realloc-lhs!-(
The problem shows up for any use of MATMUL as argument
to a procedure, whether user-defined or intrinsic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83565
--- Comment #7 from Segher Boessenkool ---
(In reply to Sergei Trofimovich from comment #5)
> gcc's try_combine() scares me lots :)
It's an acquired taste.
> Segher, can you guide me here what changes size of zero_extract in here from
> 0x1f to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83565
--- Comment #6 from Sergei Trofimovich ---
(In reply to James Clarke from comment #4)
> Created attachment 42961 [details]
> Zero-out high 32 bits after a rotate
>
> Please try the attached patch.
The patch works on an attached example. Buildin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83565
Sergei Trofimovich changed:
What|Removed |Added
CC||segher at kernel dot
crashing.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83565
--- Comment #4 from James Clarke ---
Created attachment 42961
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42961&action=edit
Zero-out high 32 bits after a rotate
Please try the attached patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83565
James Clarke changed:
What|Removed |Added
CC||jrtc27 at jrtc27 dot com
--- Comment #3 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83399
Segher Boessenkool changed:
What|Removed |Added
Keywords||ice-on-invalid-code
Tar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80791
--- Comment #11 from Segher Boessenkool ---
In the 64-bit Power ABIs, an int is passed as a sign-extended 64-bit register.
Take this trivial example:
int f(int x) { return x*x; }
which compiles to (on powerpc64-linux, BE):
.L.f:
mullw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83551
Paul Thomas changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35014
--- Comment #7 from cgw at alum dot mit.edu ---
Thanks for the suggestion. I will give it a try.
However, we're using a gcc from the distribution - either Ubuntu or Anaconda,
depending on the platform. We are not configuring and building our ow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83540
--- Comment #3 from Dominique d'Humieres ---
> Two possible methods: Either try to use ALLOCATE instead of
> assignment for front-end optimization, or simply disallow
> matmul for those cases.
The code uses ALLOCATE without any realloc-lhs!-(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35014
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|2008-0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83540
--- Comment #2 from Thomas Koenig ---
Two possible methods: Either try to use ALLOCATE instead of
assignment for front-end optimization, or simply disallow
matmul for those cases.
I am tempted to do the latter.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83551
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83540
Dominique d'Humieres changed:
What|Removed |Added
Keywords||wrong-code
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83560
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41874
Aso Renji changed:
What|Removed |Added
CC||asorenji at gmail dot com
--- Comment #13 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83565
--- Comment #2 from Sergei Trofimovich ---
Where the change happens (today's gcc master):
$./bin/ia64-unknown-linux-gnu-gcc -O1 -S a.c -fdump-rtl-all
$ fgrep -A3 zero_extract a.c.*
zero_extract extracted 31 bits at offset 1:
a.c.262r.i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83565
--- Comment #1 from Sergei Trofimovich ---
Here is disassembled dump of gcc -O1 result (it's slightly easier to reason
about than gcc's assembly output):
Dump of assembler code for function bug:
0x45f0 <+0>: [MII] mov r1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83565
Bug ID: 83565
Summary: RTL combine pass breaks shift result (at least on
ia64)
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83564
--- Comment #3 from Markus Trippelsdorf ---
(In reply to hjek from comment #2)
> (Perhaps the error message should be changed to say that?)
Yes. It was fixed for gcc-8.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83564
--- Comment #2 from hjek at mail dot com ---
Makes sense. Thanks.
(Perhaps the error message should be changed to say that?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83564
Markus Trippelsdorf changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83564
Bug ID: 83564
Summary: Compiling 'retdec' causes 'internal compiler error'
Product: gcc
Version: 6.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83553
--- Comment #4 from Jakub Jelinek ---
Author: jakub
Date: Sat Dec 23 08:43:10 2017
New Revision: 255988
URL: https://gcc.gnu.org/viewcvs?rev=255988&root=gcc&view=rev
Log:
PR c++/83553
* fold-const.c (struct contains_label_data):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83553
--- Comment #3 from Jakub Jelinek ---
Author: jakub
Date: Sat Dec 23 08:40:19 2017
New Revision: 255987
URL: https://gcc.gnu.org/viewcvs?rev=255987&root=gcc&view=rev
Log:
PR c++/83553
* fold-const.c (struct contains_label_data):
56 matches
Mail list logo
