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=77278
--- Comment #30 from Jan Hubicka ---
Hi,
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
well.
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
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=77278
--- Comment #27 from Jan Hubicka ---
>
> 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 with integer types in the canonical type
> merging.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77278
--- Comment #26 from rguenther at suse dot de ---
On Thu, 6 Jun 2019, tkoenig at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77278
>
> --- Comment #25 from Thomas Koenig ---
> (In reply to Jan Hubicka from comment #24
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=77278
--- Comment #24 from Jan Hubicka ---
Hi,
actually it won't help since C has only one bool type and not bools in
different sizes (why would one need that?).
I guess it would be easiest to turn Fortran frontend to use integers here.
Honza
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77278
--- Comment #23 from Jan Hubicka ---
> 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 ar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77278
--- Comment #22 from rguenther at suse dot de ---
On Tue, 4 Jun 2019, tkoenig at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77278
>
> --- Comment #19 from Thomas Koenig ---
> (In reply to rguent...@suse.de from comme
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77278
--- Comment #20 from Jan Hubicka ---
OK, the mismatched declaration types are:
void (struct array01_integer(kind=4) &, float & restrict,
logical(kind=4) *)
and
void (struct gfc_array_i4 * restrict, struct gfc_array_r4 * restrict,
GFC_LOGICAL_4)
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 #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 #17 from Jan Hubicka ---
A small self-contained example would be welcome, I can take a look why aliasing
oracle does not mess things up.
Concerning the warning, those are quite hard to do - the line information
should point to mismat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77278
--- Comment #16 from Martin Jambor ---
Hi,
On Tue, Jun 04 2019, Jan Hubicka wrote:
>>
>> Yeah, I do remember this. I think we settled on the above
>> (previously you had dim[7] in the library I think) to be
>> compatible. Still a C simple tes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77278
--- Comment #15 from rguenther at suse dot de ---
On Tue, 4 Jun 2019, hubicka at ucw dot cz wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77278
>
> --- Comment #14 from Jan Hubicka ---
> >
> > Yeah, I do remember this. I think we set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77278
--- Comment #14 from Jan Hubicka ---
>
> Yeah, I do remember this. I think we settled on the above
> (previously you had dim[7] in the library I think) to be
> compatible. Still a C simple testcase complains:
>
> typedef struct { int ndim; in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77278
--- Comment #13 from rguenther at suse dot de ---
On Tue, 4 Jun 2019, tkoenig at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77278
>
> --- Comment #12 from Thomas Koenig ---
> In libgfortran, we have
>
> #define GFC_
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
Richard Biener changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77278
--- Comment #10 from rguenther at suse dot de ---
On June 3, 2019 6:54:10 PM GMT+02:00, "tkoenig at gcc dot gnu.org"
wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77278
>
>--- Comment #9 from Thomas Koenig ---
>Created attachment 46446
>
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 #8 from rguenther at suse dot de ---
On Sun, 2 Jun 2019, tkoenig at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77278
>
> --- Comment #6 from Thomas Koenig ---
...
> So, dt_parm_1 is still filled with info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77278
--- Comment #7 from Richard Biener ---
(In reply to Thomas Koenig from comment #5)
> 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 g
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 #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
Bug 77278 depends on bug 68649, which changed state.
Bug 68649 Summary: [7/8/9 Regression] note: code may be misoptimized unless
-fno-strict-aliasing is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68649
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77278
Bug 77278 depends on bug 68717, which changed state.
Bug 68717 Summary: [7/8/9 Regression] New (bogus?) warnings when compiling some
gfortran.dg tests with -flto after r231239
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68717
What
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77278
--- Comment #4 from Dominique d'Humieres ---
> This led to error messages like
>
> lto1: warning: type of '_gfortran_st_write' does not match original
> declaration [-Wlto-type-mismatch]
> ../../../trunk/libgfortran/io/transfer.c:3746:1:
> note:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77278
--- Comment #3 from Thomas Koenig ---
Some information about the type mismatch.
The first mismatch about gfortran_st_write is
lto1: warning: type of '_gfortran_st_write' does not match original declaration
[-Wlto-type-mismatch]
Breakpoint 1, w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77278
--- Comment #2 from Thomas Koenig ---
Here's a test case which shows a performance loss with LTO-enabled
libgfortran.
program main
implicit none
integer, parameter :: n=10**7
integer :: i
real, dimension(n) :: a
real :: t1, t2, t3
ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77278
Thomas Koenig changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
33 matches
Mail list logo
