https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90344
--- Comment #2 from Thomas Koenig ---
Author: tkoenig
Date: Sun May 5 13:53:24 2019
New Revision: 270882
URL: https://gcc.gnu.org/viewcvs?rev=270882&root=gcc&view=rev
Log:
2019-05-05 Thomas Koenig
PR fortran/90344
* gfortran.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90344
--- Comment #3 from Thomas Koenig ---
Author: tkoenig
Date: Sun May 5 14:01:51 2019
New Revision: 270883
URL: https://gcc.gnu.org/viewcvs?rev=270883&root=gcc&view=rev
Log:
2019-05-05 Thomas Koenig
PR fortran/90344
* frontend
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90344
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
--- Comment #15 from Thomas Koenig ---
Hi Tomas,
> I understand the compiler may not know and typically does not whether the
> called function accepts "character(len=1)" or "character(len=*)", so it may
> have to pass the 1. But the situation wh
at gcc dot gnu.org |tkoenig at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90351
--- Comment #1 from Thomas Koenig ---
Author: tkoenig
Date: Wed May 8 21:55:13 2019
New Revision: 271018
URL: https://gcc.gnu.org/viewcvs?rev=271018&root=gcc&view=rev
Log:
2019-05-08 Thomas Koenig
PR fortran/90351
PR fortran/90329
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
--- Comment #22 from Thomas Koenig ---
Author: tkoenig
Date: Wed May 8 21:55:13 2019
New Revision: 271018
URL: https://gcc.gnu.org/viewcvs?rev=271018&root=gcc&view=rev
Log:
2019-05-08 Thomas Koenig
PR fortran/90351
PR fortran/90329
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90351
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
Thomas Koenig changed:
What|Removed |Added
See Also||https://github.com/Referenc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90351
--- Comment #3 from Thomas Koenig ---
Author: tkoenig
Date: Thu May 9 17:40:30 2019
New Revision: 271038
URL: https://gcc.gnu.org/viewcvs?rev=271038&root=gcc&view=rev
Log:
2019-05-09 Thomas Koenig
Backport from trunk
PR fortran/9035
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
--- Comment #24 from Thomas Koenig ---
Author: tkoenig
Date: Thu May 9 17:40:30 2019
New Revision: 271038
URL: https://gcc.gnu.org/viewcvs?rev=271038&root=gcc&view=rev
Log:
2019-05-09 Thomas Koenig
Backport from trunk
PR fortran/903
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61968
--- Comment #9 from Thomas Koenig ---
Author: tkoenig
Date: Fri May 10 20:14:22 2019
New Revision: 271076
URL: https://gcc.gnu.org/viewcvs?rev=271076&root=gcc&view=rev
Log:
2019-05-10 Thomas Koenig
PR fortran/61968
* interface.c (com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61968
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
--- Comment #30 from Thomas Koenig ---
Hi Jakub,
> Untested workaround that isn't a too big hammer. This should just avoid
> tail calls in functions where the hidden string arguments for
> character(len=constant) dummy arguments are passed part
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
--- Comment #36 from Thomas Koenig ---
Author: tkoenig
Date: Sun May 19 08:22:41 2019
New Revision: 271376
URL: https://gcc.gnu.org/viewcvs?rev=271376&root=gcc&view=rev
Log:
2019-05-19 Thomas Koenig
PR fortran/90329
* invoke.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88821
--- Comment #6 from Thomas Koenig ---
Author: tkoenig
Date: Sun May 19 10:21:06 2019
New Revision: 271377
URL: https://gcc.gnu.org/viewcvs?rev=271377&root=gcc&view=rev
Log:
2019-05-19 Thomas Koenig
PR fortran/88821
* expr.c (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88821
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
||tkoenig at gcc dot gnu.org
Resolution|--- |FIXED
--- Comment #9 from Thomas Koenig ---
(In reply to Fred Krogh from comment #8)
> My apologies for posting this. In my original code the program just quit at
> the point of the test. I tho
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90294
Thomas Koenig changed:
What|Removed |Added
Resolution|FIXED |INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88821
--- Comment #8 from Thomas Koenig ---
Author: tkoenig
Date: Sun May 19 11:24:17 2019
New Revision: 271378
URL: https://gcc.gnu.org/viewcvs?rev=271378&root=gcc&view=rev
Log:
2019-05-19 Thomas Koenig
PR fortran/88821
* ChangeLog: Add f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78290
--- Comment #6 from Thomas Koenig ---
Author: tkoenig
Date: Sun May 19 11:26:20 2019
New Revision: 271379
URL: https://gcc.gnu.org/viewcvs?rev=271379&root=gcc&view=rev
Log:
2019-05-19 Thomas Koenig
PR fortran/78290
* gfortran
||tkoenig at gcc dot gnu.org
Resolution|--- |FIXED
--- Comment #7 from Thomas Koenig ---
(In reply to Dominique d'Humieres from comment #5)
> > Any need for a new test on top of those included in the revision?
>
> PING!
I c
||2019-05-19
CC||tkoenig at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Thomas Koenig ---
With your test case, I get
$ gfortran a.f90
a.f90:32:24:
32 | byte b2 / '
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90536
--- Comment #2 from Thomas Koenig ---
Hm, another question: Which gfortran version do you use?
If your version is _really_ old, it might not yet have
the -Wno-conversion flag.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90536
Thomas Koenig changed:
What|Removed |Added
Status|RESOLVED|NEW
Resolution|WONTFIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90536
--- Comment #9 from Thomas Koenig ---
Hi Steve,
what I meant is that
Program main
Integer(kind=1) :: n
n = 1
End
should not warn with -fno-range-check -Wall, and it does.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
--- Comment #2 from Thomas Koenig ---
I am a bit surprised at this, that the library version
of packing seems to be faster than the inlined one.
Or maybe some argument is now packed which should not be.
Increased code size is sort of expected,
at gcc dot gnu.org |tkoenig at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
--- Comment #3 from Thomas Koenig ---
I think I have an idea what might be the problem.
Does the code do something like
call foo(a)
...
subroutine foo(a)
real, dimension(:) :: a
call bar(a,size(n))
...
subroutine bar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
Thomas Koenig changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #4 from Thomas Koeni
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
Thomas Koenig changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #8 from Thomas Koeni
||2019-05-21
CC||tkoenig at gcc dot gnu.org
Resolution|DUPLICATE |---
Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot
gnu.org
Summary|Out of bounds error when|[9/10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90563
Thomas Koenig changed:
What|Removed |Added
Target Milestone|--- |8.4
Summary|[9/10 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
--- Comment #13 from Thomas Koenig ---
I'm afraid the tree dumps will not help a lot - I know what they
look like before and after, but I don't know what is wrong with it.
I would therefore ask you to reduce the test case, maybe starting
with th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
--- Comment #16 from Thomas Koenig ---
Hi Martin,
Is this for the slowdown or for the wrong-code issue?
To get another view, from a gdb seesion of the compiler:
call debug(expr)
call debug(fsym)
a look at expr->symtree->n.sym (I think call de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
--- Comment #19 from Thomas Koenig ---
Thanks.
A bit more:
What are the declarations of the actual srgument,
of the dummy argument (on the callee side),
and what is the argument in the call list?
Ill try to construct a test case tonight then.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
--- Comment #21 from Thomas Koenig ---
OK, if the callee is a C function... what is its declaration
on the Fortran side? Is there any interface, bind(c) or otherwise?
I suppose there must be something, otherwise nf_put_vara_double would
have a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
--- Comment #22 from Thomas Koenig ---
I've been trying out some things, and I cannot construct a failing
test case.
A sane way to build such an interface would be
cat tst.f90
module x
use, intrinsic :: iso_c_binding, only : c_double
impli
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
--- Comment #26 from Thomas Koenig ---
Author: tkoenig
Date: Sun May 26 14:02:51 2019
New Revision: 271630
URL: https://gcc.gnu.org/viewcvs?rev=271630&root=gcc&view=rev
Log:
2019-05-26 Thomas Koenig
PR fortran/90539
* trans-t
: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90639
Thomas Koenig changed:
What|Removed |Added
Target Milestone|--- |10.0
Summary|Boostrap failure
at gcc dot gnu.org |tkoenig at gcc dot
gnu.org
--- Comment #28 from Thomas Koenig ---
https://gcc.gnu.org/ml/fortran/2019-05/msg00173.html reports
the same symptoms for netcdf-fortran-4.4.5, presumably due
to the same issue.
I'll try to fix that one and then see if the SPEC fa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
--- Comment #30 from Thomas Koenig ---
Hi,
what I mean is if you use "up" several times and list the
source of the calling routines, do you encounter something like
call foo([1.0, 2.0, 3.0, 4.0])
or
call foo((/1.0, 2.0, 3.0, 4.0/))
?
Th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
--- Comment #32 from Thomas Koenig ---
Hi Martin,
this
3822 ierr = pio_put_var (tape(t)%File, ps0var, (/ps0/))
looks like the culprit (or rather, where gfortran currently
generates wrong code). This is consistent with the problem seen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
--- Comment #34 from Thomas Koenig ---
Created attachment 46420
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46420&action=edit
Patch which includes a check for being contiguous
This patch looks like it could do the job. I'll have to wor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
--- Comment #35 from Thomas Koenig ---
(In reply to Thomas Koenig from comment #34)
> Created attachment 46420 [details]
> Patch which includes a check for being contiguous
>
> This patch looks like it could do the job. I'll have to work a bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
--- Comment #36 from Thomas Koenig ---
... which should be
Index: testsuite/gfortran.dg/internal_pack_21.f90
===
--- testsuite/gfortran.dg/internal_pack_21.f90 (Revision 271629)
++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
--- Comment #37 from Thomas Koenig ---
Hm, with that patch, there still seems to be a failure in netcdf :-(
I will keep looking (possibly some small problem with the patch).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
--- Comment #38 from Thomas Koenig ---
So, I finally have a self-contained test case:
module t2
implicit none
contains
subroutine foo(a)
real, dimension(*) :: a
end subroutine foo
end module t2
module t1
use t2
implicit none
contai
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
Thomas Koenig changed:
What|Removed |Added
Attachment #46420|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
--- Comment #41 from Thomas Koenig ---
Just noticed that this causes a regression in
gfortran.fortran-torture/execute/arrayarg.f90 , but only at certain
optimization levels.
Oh well... need to look some more.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
Thomas Koenig changed:
What|Removed |Added
Attachment #46427|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
Thomas Koenig changed:
What|Removed |Added
Keywords||patch, wrong-code
--- Comment #44 from T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
--- Comment #45 from Thomas Koenig ---
Author: tkoenig
Date: Wed May 29 20:30:45 2019
New Revision: 271751
URL: https://gcc.gnu.org/viewcvs?rev=271751&root=gcc&view=rev
Log:
2019-05-29 Thomas Koenig
PR fortran/90539
* gfortra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
--- Comment #46 from Thomas Koenig ---
Let's see if the failures go away (they should) and also what the
performance impact is now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|WAITING
--- Comment #47 from Thomas Koen
||2019-06-01
CC||tkoenig at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Thomas Koenig ---
Another, not mutually exclusive approach would be to make libgfortran LTO
clean so the more complex minloc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90608
Thomas Koenig changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
--- Comment #50 from Thomas Koenig ---
Author: tkoenig
Date: Sun Jun 2 15:18:22 2019
New Revision: 271844
URL: https://gcc.gnu.org/viewcvs?rev=271844&root=gcc&view=rev
Log:
2019-06-02 Thomas Koenig
PR fortran/90539
* trans-e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77278
--- Comment #5 from Thomas Koenig ---
One thing we would also have to tackle is GFC_LOGICAL arguments.
C only has one bool type, which is (for gcc) equivalent to
logical(kind=1). We might just get by with
typedef enum { _zero=1, _one=1 } GFC_L
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77278
--- Comment #6 from Thomas Koenig ---
So, I played around with this a little. By putting in
-flto and -ffat-lto-binaries into CFLAGS, FFLAGS and LDFLAGS
into the Makefile in the libgfortran build directory, it is
possible to build an LTO-enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77278
--- Comment #9 from Thomas Koenig ---
Created attachment 46446
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46446&action=edit
LTO tree dump from simple test case
So, I tried out a simple program:
$ cat minloc.f90
program main
real, di
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77278
--- Comment #12 from Thomas Koenig ---
In libgfortran, we have
#define GFC_ARRAY_DESCRIPTOR(type) \
struct {\
type *base_addr;\
size_t offset;\
dtype_type dtype;\
index_type span;\
descriptor_dimension dim[];\
}
and then later
typede
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77278
--- Comment #18 from Thomas Koenig ---
Created attachment 46451
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46451&action=edit
Preprocessed source of library file for LTO mismatch
Hi,
here is a test case (preprocessed source from libgfo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77278
--- Comment #19 from Thomas Koenig ---
(In reply to rguent...@suse.de from comment #15)
Btw, I wonder what happens at
> the call boundary inside a single fortran module where
> the caller passes a dim[2] array to a subroutine
> handling arbitra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77278
--- Comment #21 from Thomas Koenig ---
(In reply to Jan Hubicka from comment #20)
> OK, the mismatched declaration types are:
> void (struct array01_integer(kind=4) &, float & restrict,
> logical(kind=4) *)
> and
> void (struct gfc_array_i4 * r
||2019-06-05
CC||tkoenig at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Thomas Koenig ---
I see this too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77278
--- Comment #25 from Thomas Koenig ---
(In reply to Jan Hubicka from comment #24)
> Hi,
> actually it won't help since C has only one bool type and not bools in
> different sizes (why would one need that?).
"Because it's in the Fortran language
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90744
--- Comment #4 from Thomas Koenig ---
(In reply to Tomáš Trnka from comment #3)
> I'm not sure how to fix this properly, but the following one-liner seems to
> work for me:
>
> --- a/gcc/fortran/trans-types.c
> +++ b/gcc/fortran/trans-types.c
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90744
--- Comment #6 from Thomas Koenig ---
(In reply to Tomáš Trnka from comment #5)
> (In reply to Thomas Koenig from comment #4)
> > Good analysis, and this is indeed the correct fix.
>
> OK. I thought that perhaps get_formal_from_actual_arglist()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90744
--- Comment #7 from Thomas Koenig ---
Author: tkoenig
Date: Sat Jun 8 13:50:42 2019
New Revision: 272082
URL: https://gcc.gnu.org/viewcvs?rev=272082&root=gcc&view=rev
Log:
2019-06-08 Thomas Koenig
Tomáš Trnka
PR fortran/90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90608
--- Comment #5 from Thomas Koenig ---
(In reply to ktkachov from comment #4)
> LTO'ing libgfortran aside, how much work would it be to teach the scalarizer
> to at least elide the temporary arrays in expressions like:
> A(:) = minloc(...) ?
> I t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77278
--- Comment #28 from Thomas Koenig ---
(In reply to Jan Hubicka from comment #27)
> >
> > I think that's reasonably easy to do for LTO. We'd want to keep
> > the default boolean_type_node size BOOLEAN_TYPEs separate but
> > can glob larger ones
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90786
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90786
--- Comment #7 from Thomas Koenig ---
Created attachment 46475
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46475&action=edit
Assembly for test case on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90786
--- Comment #8 from Thomas Koenig ---
Stepping through the assembly, the segfaulting instruction is
"blr x3", which jumps to a NULL pointer, with predictable results:
│165 // proc_ptr_51.f90:30: end module f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90786
--- Comment #9 from Thomas Koenig ---
The segfault occurs at
35res => c_()
according to gdb.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90813
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90744
--- Comment #8 from Thomas Koenig ---
Author: tkoenig
Date: Tue Jun 11 22:04:10 2019
New Revision: 272173
URL: https://gcc.gnu.org/viewcvs?rev=272173&root=gcc&view=rev
Log:
2019-06-11 Thomas Koenig
Tomáš Trnka
Backport from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90744
--- Comment #9 from Thomas Koenig ---
Author: tkoenig
Date: Wed Jun 12 19:54:34 2019
New Revision: 272213
URL: https://gcc.gnu.org/viewcvs?rev=272213&root=gcc&view=rev
Log:
2019-06-12 Thomas Koenig
Tomáš Trnka
Backport from trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90744
--- Comment #10 from Thomas Koenig ---
Author: tkoenig
Date: Wed Jun 12 20:08:38 2019
New Revision: 272214
URL: https://gcc.gnu.org/viewcvs?rev=272214&root=gcc&view=rev
Log:
2019-06-12 Thomas Koenig
Tomáš Trnka
Backport from trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90744
Thomas Koenig changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90870
--- Comment #1 from Thomas Koenig ---
Author: tkoenig
Date: Thu Jun 13 17:00:22 2019
New Revision: 272249
URL: https://gcc.gnu.org/viewcvs?rev=272249&root=gcc&view=rev
Log:
2019-06-13 Thomas Koenig
PR fortran/90870
* gfortran.dg/defe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90870
Thomas Koenig changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77278
--- Comment #29 from Thomas Koenig ---
Created attachment 46493
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46493&action=edit
Patch to put all libgfortran functions into a namespace
This is something we should be doing as part of making
at gcc dot gnu.org |tkoenig at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90937
--- Comment #5 from Thomas Koenig ---
Author: tkoenig
Date: Thu Jun 20 11:56:50 2019
New Revision: 272506
URL: https://gcc.gnu.org/viewcvs?rev=272506&root=gcc&view=rev
Log:
2019-06-20 Thomas Koenig
PR fortran/90937
* trans-ty
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90937
Thomas Koenig changed:
What|Removed |Added
Summary|[7/8/9/10 Regression] ICE: |[7/8/9 Regression] ICE: in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77278
--- Comment #31 from Thomas Koenig ---
(
> this patch makes Fortran logicals to become C unsigned types of
> corresponding size. I think it is better than making them signed
> because the globbing will affect aliasing within Fortran programs as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90937
--- Comment #7 from Thomas Koenig ---
Author: tkoenig
Date: Fri Jun 21 19:28:54 2019
New Revision: 272564
URL: https://gcc.gnu.org/viewcvs?rev=272564&root=gcc&view=rev
Log:
2019-06-21 Thomas Koenig
Backport from trunk
PR fort
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90937
--- Comment #8 from Thomas Koenig ---
Author: tkoenig
Date: Fri Jun 21 19:30:51 2019
New Revision: 272565
URL: https://gcc.gnu.org/viewcvs?rev=272565&root=gcc&view=rev
Log:
2019-06-21 Thomas Koenig
Backport from trunk
PR fort
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90937
--- Comment #9 from Thomas Koenig ---
Author: tkoenig
Date: Fri Jun 21 19:32:23 2019
New Revision: 272566
URL: https://gcc.gnu.org/viewcvs?rev=272566&root=gcc&view=rev
Log:
2019-06-21 Thomas Koenig
Backport from trunk
PR fort
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90937
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90813
Thomas Koenig changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #7 from Thomas Koenig -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
--- Comment #47 from Thomas Koenig ---
(In reply to Kaz Kylheku from comment #45)
> Hi everyone.
>
> Pardon my ignorance of C-Fortran bridging matters, but does any of the
> following make sense?
>
> The Fortran subroutine has no idea whether t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90813
--- Comment #10 from Thomas Koenig ---
I checked the *.optimized dump on POWER and x86_64 against each
other, and there are no differences (some renumbering of variables,
that's all).
Looking further...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90813
Thomas Koenig changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90813
--- Comment #12 from Thomas Koenig ---
Another data point.
If the test case is split across two files (the module separate
from the main program), then it works.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90813
Thomas Koenig changed:
What|Removed |Added
Component|fortran |rtl-optimization
--- Comment #14 from Th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90813
Thomas Koenig changed:
What|Removed |Added
Priority|P4 |P3
--- Comment #16 from Thomas Koenig -
1601 - 1700 of 3746 matches
Mail list logo
