https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95177
Thomas Koenig changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95177
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment
||90302
Status|UNCONFIRMED |NEW
Last reconfirmed||2020-05-18
CC||tkoenig at gcc dot gnu.org
--- Comment #2 from Thomas Koenig ---
Two ways to fix this: When checking for outer do loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94925
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
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=95119
Thomas Koenig changed:
What|Removed |Added
Target Milestone|--- |9.4
Summary|CLOSE hangs when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95119
Thomas Koenig changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #5 from Thomas
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
CC||jb at gcc dot gnu.org
--- Comment #3
||2020-05-14
CC||tkoenig at gcc dot gnu.org
Status|UNCONFIRMED |NEW
--- Comment #2 from Thomas Koenig ---
Confirmed with current trunk.
dot gnu.org |tkoenig at gcc dot
gnu.org
Severity|normal |enhancement
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2020-05-13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95101
Thomas Koenig changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
: 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=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]++;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95053
Thomas Koenig changed:
What|Removed |Added
Status|REOPENED|WAITING
--- Comment #16 from Thomas
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
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
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
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
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=edit
Assembly file on x86 with -O2 -funroll-loops
So, it seems the decisions made for unrolling are bad for this case
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 #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
Summary|[11 Regression] Excessive |[10/11 Regression]
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
--- Comment #4 from Thomas Koenig ---
9.3.0 is also not affected.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95018
Thomas Koenig changed:
What|Removed |Added
Target Milestone|--- |11.0
Summary|Excessive
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=edit
-fdump-tree-optimized dumpj
Finally, the -fdump-tree-optimized dump.
Unrolling already appears to happen in the
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=edit
Preprocessed source
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=edit
Generated assembly
The code generated for in_pack_i4.c from libgfort
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=edit
Preliminary partial patch
Here is a very preliminary implementation, which only looks at
the return values of maxloc
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/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
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
>
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=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_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=94788
Thomas Koenig changed:
What|Removed |Added
Status|NEW |WAITING
Blocks|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94788
Thomas Koenig changed:
What|Removed |Added
Version|10.0|9.3.1
Summary|[10
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
Status|UNCONFIRMED |NEW
Last reconfirmed|
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
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
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=94578
Thomas Koenig changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
|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=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.
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,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94737
Thomas Koenig changed:
What|Removed |Added
Status|NEW |RESOLVED
Summary|[8/9/10
CC| |tkoenig at gcc dot gnu.org
Target Milestone|--- |8.5
|UNCONFIRMED |NEW
Ever confirmed|0 |1
CC||tkoenig at gcc dot gnu.org
Keywords||ice-on-invalid-code,
||memory-hog
--- Comment #1
||2020-04-25
CC||tkoenig at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Thomas Koenig ---
Confirmed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93956
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
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=90350
Thomas Koenig changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
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=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=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
>
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
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=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
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
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=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.
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 #5 from Thomas Koenig ---
Works now, probably fixed by Paul's work on associate.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94347
Thomas Koenig changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
||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=93500
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
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=94090
Thomas Koenig changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
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
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),
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),
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
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=94030
Thomas Koenig changed:
What|Removed |Added
CC||jiri.pitt...@jh-inst.cas.cz
--- 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=93948
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment
||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
||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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94110
Thomas Koenig changed:
What|Removed |Added
Severity|normal |enhancement
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=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=94578
Thomas Koenig changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
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
>
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
@@
|--- |8.5
Summary|Bogus unused dummy argument |[8/9/10 Regression] Bogus
|warning/error |unused dummy argument
||warning/error
Assignee|unassigned at gcc dot gnu.org |tkoenig
||tkoenig at gcc dot gnu.org
Last reconfirmed||2020-04-13
Status|UNCONFIRMED |NEW
--- Comment #1 from Thomas Koenig ---
Confirmed.
|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
Status|NEW |RESOLVED
--- Comment #4 from Thomas Koenig ---
Fixed on trunk, closing.
Thanks for the bug report!
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
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=94091
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
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
||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=94109
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
Last
|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
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
||tkoenig at gcc dot gnu.org
Status|NEW |RESOLVED
--- Comment #4 from Thomas Koenig ---
Fixed, then.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94386
Thomas Koenig changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
501 - 600 of 3581 matches
Mail list logo
