On Mon, Feb 25, 2019 at 05:54:44PM -0800, Bob Deen via fortran wrote:
> On 2/19/19 2:44 PM, Thomas Koenig wrote:
> > Bob,
> >
> >> Some of us still use varargs interfaces (in my case, Fortran calling C
> >> stdarg subroutines).
> >
> > The problem for us is that that sometimes using varargs made
On 2/19/19 2:44 PM, Thomas Koenig wrote:
Bob,
Some of us still use varargs interfaces (in my case, Fortran calling C
stdarg subroutines).
The problem for us is that that sometimes using varargs made standard-
conforming Fortran code like, in file a.f
subroutine foo(a)
print *
Bob,
Some of us still use varargs interfaces (in my case, Fortran calling C
stdarg subroutines).
The problem for us is that that sometimes using varargs made standard-
conforming Fortran code like, in file a.f
subroutine foo(a)
print *,a
end
and in file main.f
progra
On 2/18/19 12:48 AM, Janne Blomqvist wrote:
On Sun, Feb 17, 2019 at 8:19 PM Thomas Koenig wrote:
Hello world,
the attached patch fixes a rather bad ABI violation on POWER systems.
...
I agree, although we're close to the GCC-9 release, it's better to get
this in now. So Ok.
I wonder if we
On Mon, Feb 18, 2019 at 10:30 PM Thomas Koenig
wrote:
> Hi Janne,
>
> > I'm not really sure if there is any good reason why GFortran occasionally
> > generates these varargs declarations, hence my suggestion to get rid of
> > them. Unless the middle-end is planning to get rid of untyped function
Hi Janne,
I'm not really sure if there is any good reason why GFortran occasionally
generates these varargs declarations, hence my suggestion to get rid of
them. Unless the middle-end is planning to get rid of untyped function
decls?
Are they still being generated after the patch went in? I'm
On Mon, Feb 18, 2019 at 7:25 PM Segher Boessenkool <
seg...@kernel.crashing.org> wrote:
> On Mon, Feb 18, 2019 at 10:48:35AM +0200, Janne Blomqvist wrote:
> > I wonder if we shouldn't exorcise all the varargs stuff, it seems to
> > cause more problems than benefits? But not in stage4 if we can avo
I have now committed the patch as r268992. Janne and Richard, thanks
for the review and the comments.
Am 18.02.19 um 13:50 schrieb Richard Biener:
On Sun, Feb 17, 2019 at 7:19 PM Thomas Koenig wrote:
Regression tests turned up a few ICEs (now fixed), plus two
very invalid test cases, which I
On Mon, Feb 18, 2019 at 10:48:35AM +0200, Janne Blomqvist wrote:
> I wonder if we shouldn't exorcise all the varargs stuff, it seems to
> cause more problems than benefits? But not in stage4 if we can avoid
> it..
On the Power ABIs at least, unprototyped functions (a K&R thing for C) are
handled t
On Mon, Feb 18, 2019 at 2:51 PM Richard Biener
wrote:
> The patch looks good to me. I wonder how the frontend handles
> the 2nd call to doesntwork_p8 for
>
> program main
> implicit none
> character :: c
> character(len=20) :: res, doesntwork_p8
> external do
On Sun, Feb 17, 2019 at 7:19 PM Thomas Koenig wrote:
>
> Hello world,
>
> the attached patch fixes a rather bad ABI violation on POWER systems.
>
> In the absence of an explicit interface and if a procedure is not in
> the same file, gfortran currently generates wrong function decls -
> a longstan
On Sun, Feb 17, 2019 at 8:19 PM Thomas Koenig wrote:
>
> Hello world,
>
> the attached patch fixes a rather bad ABI violation on POWER systems.
>
> In the absence of an explicit interface and if a procedure is not in
> the same file, gfortran currently generates wrong function decls -
> a longstan
On Sun, Feb 17, 2019 at 07:18:52PM +0100, Thomas Koenig wrote:
> I'd still like confirmation from one of the POWER people that
> this also fixes the bug on that architecture.
I bootstrapped and regression tested on powerpc64le-linux, and confirm
that the patch fixes the bug. Thanks!
--
Alan Mod
Hello world,
the attached patch fixes a rather bad ABI violation on POWER systems.
In the absence of an explicit interface and if a procedure is not in
the same file, gfortran currently generates wrong function decls -
a longstanding problem that also creates problems with LTO, because
it (corre
14 matches
Mail list logo
