https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94030
Thomas Koenig changed:
What|Removed |Added
Keywords||ice-on-invalid-code
Target Milestone|-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92976
Thomas Koenig changed:
What|Removed |Added
Target Milestone|10.0|8.5
Summary|[8/9/10 Regressio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92976
--- Comment #4 from Thomas Koenig ---
Fix on trunk was https://gcc.gnu.org/g:957a1b14e99596610abb0777ca86a1c80dde24e0
.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94386
Thomas Koenig changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
||tkoenig at gcc dot gnu.org
Status|NEW |RESOLVED
--- Comment #4 from Thomas Koenig ---
Fixed, then.
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
This is with commit e26bd694c790b7c8f68c6736b2683c60a8fcbcfe, as
of just now.l The machine is gcc135.fsffrance.org, in case anybody
|NEW
Last reconfirmed||2020-04-10
CC||tkoenig at gcc dot gnu.org
--- Comment #1 from Thomas Koenig ---
Unfortunately, the test case fails with different ways on
current trunk:
$ gfortran -g a.f90
$ ./a.out
at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94109
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
Last
||2020-04-11
Status|UNCONFIRMED |NEW
CC||tkoenig at gcc dot gnu.org
Severity|normal |enhancement
--- Comment #1 from Thomas Koenig ---
Would be useful, yes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94091
Thomas Koenig changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94091
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94090
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94090
Thomas Koenig changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot
gnu.org
||tkoenig at gcc dot gnu.org
Status|NEW |RESOLVED
--- Comment #4 from Thomas Koenig ---
Fixed on trunk, closing.
Thanks for the bug report!
|WAITING
CC||tkoenig at gcc dot gnu.org
Last reconfirmed||2020-04-13
--- Comment #1 from Thomas Koenig ---
(In reply to José Rui Faustino de Sousa from comment #0)
> Created attachment 48000 [details]
>
||tkoenig at gcc dot gnu.org
Last reconfirmed||2020-04-13
Status|UNCONFIRMED |NEW
--- Comment #1 from Thomas Koenig ---
Confirmed.
gcc dot
gnu.org
--- Comment #2 from Thomas Koenig ---
This should be a one-line fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94270
--- Comment #3 from Thomas Koenig ---
Not quite a one-liner, but looks good:
diff --git a/gcc/fortran/interface.c b/gcc/fortran/interface.c
index 75a50c999b7..8f041f0a0a8 100644
--- a/gcc/fortran/interface.c
+++ b/gcc/fortran/interface.c
@@ -531
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94270
--- Comment #7 from Thomas Koenig ---
(In reply to Ignacio Fernández Galván from comment #6)
> Will the fix be backported to gcc7? I noticed this when Ubuntu updated the
> gcc7 version, so I would like to have the chance of seeing it fixed
> even
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94578
Thomas Koenig changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94578
--- Comment #4 from Thomas Koenig ---
Looks like span is not handled in reshape (at all).
It will be interesting to see how other intrinsics
such as maxloc and just about everything else
handles this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94270
Thomas Koenig changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94110
Thomas Koenig changed:
What|Removed |Added
Severity|normal |enhancement
Summary|Erroneous
||tkoenig at gcc dot gnu.org
Ever confirmed|0 |1
Status|UNCONFIRMED |WAITING
--- Comment #1 from Thomas Koenig ---
Can you simplify this somewhat, and not use assumed shape
in your test case? This adds a complication
||pault at gcc dot gnu.org,
||tkoenig at gcc dot gnu.org
Last reconfirmed||2020-04-14
Status|UNCONFIRMED |NEW
--- Comment #2 from Thomas Koenig ---
(In reply to martin from comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93948
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93500
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94030
Thomas Koenig changed:
What|Removed |Added
CC||jiri.pitt...@jh-inst.cas.cz
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88452
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94578
--- Comment #5 from Thomas Koenig ---
Somewhat smaller test case:
program main
implicit none
type foo
integer :: x, y
end type foo
integer :: i
integer, dimension (2,2) :: array2d
integer, dimension(:), pointer :: array1d
type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94578
--- Comment #6 from Thomas Koenig ---
Also wrong:
program main
implicit none
type foo
integer :: x, y
end type foo
integer :: i
integer, dimension (2,2) :: array2d
integer, dimension(:), pointer :: array1d
type(foo), dimension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94578
--- Comment #8 from Thomas Koenig ---
The bug appears to affect intrinsics only, for example this
program main
implicit none
type foo
integer :: x, y
end type foo
integer, dimension(:), pointer :: bp
type (foo), dimension(4), targ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94578
--- Comment #9 from Thomas Koenig ---
Here's what a solution could look like. I am not really sure that this
is the way to go, there may be some corner cases (pointer to an
argument which was passed as a transposed argument?) which this
might get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94090
Thomas Koenig changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94143
Thomas Koenig changed:
What|Removed |Added
Last reconfirmed||2020-04-18
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93500
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
||2020-04-19
CC||tkoenig at gcc dot gnu.org
Status|UNCONFIRMED |NEW
--- Comment #2 from Thomas Koenig ---
Works with current trunk and gcc 9.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94347
Thomas Koenig changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93338
--- Comment #5 from Thomas Koenig ---
Works now, probably fixed by Paul's work on associate.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93338
--- Comment #6 from Thomas Koenig ---
Correction: Fails with -O, does not fail without optimization.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93338
--- Comment #7 from Thomas Koenig ---
(In reply to Richard Biener from comment #2)
> Likely another missing DECL_EXPR for variable-size stuff. TYPE_SIZE has
>
> (bitsizetype) (sizetype) _29 * 8
>
> and _29 is released.
This is confusing.
G
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91800
Thomas Koenig changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93956
--- Comment #4 from Thomas Koenig ---
Taking the slightly modified test case
program array_temps
implicit none
type :: tt
integer :: u = 1
integer :: v = 2
end type tt
type(tt), dimension(:), pointer :: r
integer :: n
int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93956
--- Comment #5 from Thomas Koenig ---
So, the problem seems to be that sym->attr.subref_array_pointer is
not set on the original test case. It should be set by
p => get(r(:)) (or by an equivalent call get2(r)) because
we don't know what the part
at gcc dot gnu.org |tkoenig at gcc dot
gnu.org
--- Comment #6 from Thomas Koenig ---
Let's see if I can get this fixed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92993
Thomas Koenig changed:
What|Removed |Added
Summary|[8/9/10 Regression] ICE in |[8/9 Regression] ICE in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91512
--- Comment #26 from Thomas Koenig ---
(In reply to Bill Seurer from comment #25)
> This is affecting us on powerpc64 as well. It takes twice as long to build
> the spec2017 test cases with most of the difference in a few of the fortran
> compil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93956
--- Comment #7 from Thomas Koenig ---
Created attachment 48328
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48328&action=edit
Patch which sould create the right temporaries
Well, this should to the trick - at least fixes the test case.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90350
Thomas Koenig changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93956
--- Comment #11 from Thomas Koenig ---
Fixed on all open branches.
Thanks a lot for the bug report!
Regards
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93956
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
||2020-04-25
CC||tkoenig at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Thomas Koenig ---
Confirmed.
|UNCONFIRMED |NEW
Ever confirmed|0 |1
CC||tkoenig at gcc dot gnu.org
Keywords||ice-on-invalid-code,
||memory-hog
--- Comment #1
CC| |tkoenig at gcc dot gnu.org
Target Milestone|--- |8.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94737
Thomas Koenig changed:
What|Removed |Added
Status|NEW |RESOLVED
Summary|[8/9/10 Regr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94737
--- Comment #6 from Thomas Koenig ---
(In reply to Lee Busby from comment #4)
> (In reply to kargl from comment #3)
> > (In reply to Thomas Koenig from comment #2)
> > > Correction, this is not a regression.
> > >
> > > F2018 has, in 19.2, parag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94737
--- Comment #8 from Thomas Koenig ---
So, test case committed.
Thanks for the bug report! Even though it turned out to be invalid,
it still ended up making the compiler better.
|1
Last reconfirmed||2020-04-27
Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot
gnu.org
--- Comment #1 from Thomas Koenig ---
Assigning to myself so I do not forget this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94578
Thomas Koenig changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94769
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94788
--- Comment #8 from Thomas Koenig ---
I'd like to understand what went wrong here... I suspect that
the fix exposed another bug somewhere :-(
Is it possible to isolate a test case like that? If that is
the offending patch, I think it is probabl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94788
--- Comment #10 from Thomas Koenig ---
(In reply to Richard Biener from comment #3)
> Can you maybe bisect this to a specific (fortran) commit in GCC?
Richard, when is the last time (presumably) that either a fix can go in or
the patch can be re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94788
Thomas Koenig changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93956
Thomas Koenig changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94788
Thomas Koenig changed:
What|Removed |Added
Version|10.0|9.3.1
Summary|[10 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94788
Thomas Koenig changed:
What|Removed |Added
Status|NEW |WAITING
Blocks|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94788
--- Comment #27 from Thomas Koenig ---
(In reply to Jürgen Reuter from comment #25)
> Ok, Simon and I try our best, working independently, me reducing the
> existing case further, and he tries to write a small reproducer from scratch.
Thanks a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94841
Thomas Koenig changed:
What|Removed |Added
Resolution|--- |FIXED
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 94841, which changed state.
Bug 94841 Summary: [10 Regression]527.cam4_r 7.68% regression on Intel
Cascadelaker with -O2, 9.57% regression with -Ofast -march=native
-funroll-loops -flto
https://gcc.gnu.org/bugzilla/show_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94788
Thomas Koenig changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #33 from Thomas Koenig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94788
--- Comment #35 from Thomas Koenig ---
(In reply to Jürgen Reuter from comment #34)
> Created attachment 48411 [details]
> Final reproducer, less than 300 lines ;)
>
> This one should be sufficient. No further files or input is necessary, it
> s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94788
--- Comment #37 from Thomas Koenig ---
(In reply to Jürgen Reuter from comment #36)
> Hm, I hope I didn't change the flavor of the bug, but you can cross-check
> with the very first reproducer which contains our code more or less
> unchanged (exc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94788
--- Comment #40 from Thomas Koenig ---
Yes, that test case works.
Thanks a lot for putting in all the effort!
Because we need -fsanitize=address to reliably detect this
bug, I have proposed
https://gcc.gnu.org/pipermail/gcc-patches/2020-May/54
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93114
--- Comment #2 from Thomas Koenig ---
Created attachment 48430
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48430&action=edit
Preliminary partial patch
Here is a very preliminary implementation, which only looks at
the return values of m
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
Created attachment 48488
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48488&action=edit
Generated assembly
The code generated for in_pack_i4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95018
--- Comment #1 from Thomas Koenig ---
Created attachment 48489
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48489&action=edit
Preprocessed source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95018
--- Comment #2 from Thomas Koenig ---
Created attachment 48490
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48490&action=edit
-fdump-tree-optimized dumpj
Finally, the -fdump-tree-optimized dump.
Unrolling already appears to happen in th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95018
Thomas Koenig changed:
What|Removed |Added
Target Milestone|--- |11.0
Summary|Excessive unroll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95018
--- Comment #4 from Thomas Koenig ---
9.3.0 is also not affected.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95018
--- Comment #5 from Thomas Koenig ---
For 9.3.0, I get
$ objdump --disassemble in_pack_i4.o | wc -l
123
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95018
Thomas Koenig changed:
What|Removed |Added
Summary|[11 Regression] Excessive |[10/11 Regression]
|un
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95018
--- Comment #7 from Thomas Koenig ---
Just checked aarch64, and that also isn't affected:
tkoenig@gcc116:~/gcc-bin/aarch64-unknown-linux-gnu/libgfortran$ objdump
--disassemble in_pack_i4.o | wc -l
95
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95018
Thomas Koenig changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95018
--- Comment #9 from Thomas Koenig ---
Created attachment 48502
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48502&action=edit
Assembly file on x86 with -O2 -funroll-loops
So, it seems the decisions made for unrolling are bad for this cas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95018
--- Comment #14 from Thomas Koenig ---
Most Fortran arrays are one- or two-dimensional.
Assuming a 10*10 two-dimensional array that is being packed, the
condition will be tested 121 times and the loop body will be entered
12 times. Only once wil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95018
--- Comment #16 from Thomas Koenig ---
Hi,
I was unable to find a performance problem, so I take back my
presumption of the original problem. I have checked two versions
of the preprocessed source, with
+#pragma GCC unroll 1
while (coun
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95018
--- Comment #21 from Thomas Koenig ---
(In reply to Richard Biener from comment #19)
> Is libgfortran built with -O2 -funroll-loops or with -O3 (IIRC -O3?).
Just plain -O2 (for size reasons), with matmul as an exception
where we add -funroll-lo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95018
--- Comment #22 from Thomas Koenig ---
Here are the details of how I tested this.
I generated the in_pack_r4.i and in_unpack_r4.i by adding -save-temps to the
Makefile options in ~/trunk-bin/powerpc64le-unknown-linux-gnu/libgfortran ,
then remov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95053
Thomas Koenig changed:
What|Removed |Added
Status|REOPENED|WAITING
--- Comment #16 from Thomas Koen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95018
--- Comment #29 from Thomas Koenig ---
It is also interesting that this variant
--- a/libgfortran/generated/in_pack_i4.c
+++ b/libgfortran/generated/in_pack_i4.c
@@ -88,7 +88,7 @@ internal_pack_4 (gfc_array_i4 * source)
count[0]++;
: libfortran
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
Here are some ideas:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95018#c30
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95101
Thomas Koenig changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
dot gnu.org |tkoenig at gcc dot
gnu.org
Severity|normal |enhancement
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2020-05-13
||2020-05-14
CC||tkoenig at gcc dot gnu.org
Status|UNCONFIRMED |NEW
--- Comment #2 from Thomas Koenig ---
Confirmed with current trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95119
Thomas Koenig changed:
What|Removed |Added
CC||jb at gcc dot gnu.org
--- Comment #3 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95119
--- Comment #4 from Thomas Koenig ---
So, in order for this to hang, two close statements
on the same unit are needed, the first one with an
error message.
Seems like the unit is not unlocked on the error return.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95119
Thomas Koenig changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #5 from Thomas Koen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95119
Thomas Koenig changed:
What|Removed |Added
Target Milestone|--- |9.4
Summary|CLOSE hangs when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95053
--- Comment #26 from Thomas Koenig ---
(In reply to wschmidt from comment #24)
> I'm afraid I disagree. A divide-by-zero that cannot ever be executed is
> not an error.
Well, there is PR90302. We could insert some piece of code into the
IL.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94925
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
1 - 100 of 3733 matches
Mail list logo
