David,
I will take the "thank you for restoring bootstrap for AIX" as implied
in your e-mail.
Second, the patch that you applied is unacceptable. ASYNC_IO already is
set to zero for AIX.
There is a clear procedure for this something that you deem
"unacceptable": Submit a patch (for which I
Thomas,
Once the plural.c file has been re-generated incorrectly using the local
Yacc, it must be deleted and checked out again. Did you pull it fresh from
the repository in your AIX tree after the incorrect checkout?
Thanks, David
On Wed, Aug 22, 2018 at 5:30 PM Thomas Koenig wrote:
> Hi
Thomas,
After your complaint about bootstrap on gcc119, I tried it again. My
bootstrap worked correctly. I used exactly the public instructions.
Others have been able to bootstrap on gcc119. The problem is local to
you. Does your environment have any special variables?
You can see the
Hi David,
This patch broke bootstrap on AIX again. This is completely unacceptable.
Again, sorry for the breakage.
I faced quite some challenges trying to get bootstrap to
work on gcc119. Despite quite a few e-mails (plus hints in a PR)
that I received, none of the hints for bootstrap I got
Thomas,
This patch broke bootstrap on AIX again. This is completely unacceptable.
In file included from
*/nasfarm/edelsohn/src/src/libgfortran/runtime/error.c:28*:
*/nasfarm/edelsohn/src/src/libgfortran/io/async.h:333:3:* *error: *unknown
type name '*__gthread_cond_t*'
333 |
Hi everybody,
Nicolas has committed the patch as r263750.
PR 87048 now traces the armeb regression, which is
assumed to resurface now. Let's really try and fix
that one before 9.0 :-)
Regards
Thomas
Hi Christophe,
Hi,
This is done by
+#if defined(__GTHREAD_HAS_COND) && defined(__GTHREADS_CXX0X) &&
!defined(__ARMEB__)
+#define ASYNC_IO 1
+#else
+#define ASYNC_IO 0
+#endif
I tried this version of the patch, and I'm still seeing the regression
on array_constructor_8.f90.
Urgh...
On Fri, 17 Aug 2018 at 17:41, Thomas Koenig wrote:
>
> Hi Christophe,
>
Hi,
> sorry that this took so long, but a holiday followed by a
> business trip seven timezones away can do that :-)
>
Sorry, I am on holidays too, and not back yet :)
> > I applied this patch, and again I still see
Hi Christophe,
sorry that this took so long, but a holiday followed by a
business trip seven timezones away can do that :-)
I applied this patch, and again I still see regressions on
armeb-none-linux-gnueabihf
--with-cpu cortex-a9
--with-fpu neon-fp16
The info that you supplied in the PR
On Sat, 4 Aug 2018 at 00:42, Thomas König wrote:
>
> Hi Cristophe,
>
> this is seriously weird - there is not even an I/O statement in that test
> case.
>
> One question: Is this real hardware or an emulator?
I'm using QEMU
> Also, Could you try a few things?
>
> Run the test case manually. Do
Hi Cristophe,
this is seriously weird - there is not even an I/O statement in that test case.
One question: Is this real hardware or an emulator?
Also, Could you try a few things?
Run the test case manually. Do you still fail?
Is there an error if the executable is run under valgrind?
If you
On Thu, 2 Aug 2018 at 19:05, Nicolas Koenig wrote:
>
> On Thu, Aug 02, 2018 at 05:42:46PM +0200, Christophe Lyon wrote:
> > On Thu, 2 Aug 2018 at 13:35, Nicolas Koenig
> > wrote:
> > >
> > >
> > > Hello everyone,
> > >
> > > Here is an updated version of the patch that hopefully fixes the
> >
On Thu, Aug 02, 2018 at 05:42:46PM +0200, Christophe Lyon wrote:
> On Thu, 2 Aug 2018 at 13:35, Nicolas Koenig wrote:
> >
> >
> > Hello everyone,
> >
> > Here is an updated version of the patch that hopefully fixes the compilation
> > problems by disabling async I/O if conditions are not
On Thu, 2 Aug 2018 at 13:35, Nicolas Koenig wrote:
>
>
> Hello everyone,
>
> Here is an updated version of the patch that hopefully fixes the compilation
> problems by disabling async I/O if conditions are not supported by the target.
>
> I would appreciate if people could test it on systems on
14 matches
Mail list logo
