On Thu, Sep 28, 2017 at 01:49:50AM +0300, Adrian Bunk wrote:
> What compile times exactly did you measure?
>
> The numbers I got are:
> -O0: 11s
> -O1: 82m
> -O2: 249m
Maybe I did it wrong and failed to change the flag then. I must admit
I did find it odd that I saw no change in time between -O1
I was able to build rnahybrid 2.1.2-3 on armel in 104 minutes on some
more powerful hardware. I must definitely retract what I've said about
an "infinite loop".
Replacing loop nests with memset did not make a huge difference (I
gave up after 26 minutes).
Control: reopen -1
On Wed, Sep 27, 2017 at 10:42:05AM -0400, Lennart Sorensen wrote:
> On Wed, Sep 27, 2017 at 04:39:39PM +0200, Andreas Tille wrote:
>...
> > To make things really clear for me: Edmund suggested another upload
> > with only -O1 (how can I make sure that -O1 is used only on armel?)
Those loop nests that set every element of a multi-dimensional array
to (floating-point) zero could perhaps be replaced with memset (not
officially portable) or memcpy (from a local variable of the same type
with an initialiser).
On Wed, Sep 27, 2017 at 04:39:39PM +0200, Andreas Tille wrote:
> I realised that the first patch was included but I considered it better
> to split it into two.
All good.
> To make things really clear for me: Edmund suggested another upload
> with only -O1 (how can I make sure that -O1 is used on
As interesting as this is, can you take me, Peter Steffen and Matthias
Hoechsmann off this list?
Thanks, and good luck
Marc
On 27/09/17 16:30, "Lennart Sorensen" wrote:
On Tue, Sep 26, 2017 at 08:19:59PM +0100, Edmund Grimley Evans wrote:
> It's a possibility to bear in mind, definite
Hi Lennart,
On Wed, Sep 27, 2017 at 10:30:31AM -0400, Lennart Sorensen wrote:
> On Tue, Sep 26, 2017 at 08:43:32PM +0200, Andreas Tille wrote:
> > Hi Lennart,
> >
> > thanks again for your analysis of the code.
> >
> > To summarise: We should go with the patch you suggested originally
> >
> >
On Tue, Sep 26, 2017 at 08:43:32PM +0200, Andreas Tille wrote:
> Hi Lennart,
>
> thanks again for your analysis of the code.
>
> To summarise: We should go with the patch you suggested originally
>
>
> https://anonscm.debian.org/git/debian-med/rnahybrid.git/tree/debian/patches/fix_loop_inde
On Tue, Sep 26, 2017 at 08:19:59PM +0100, Edmund Grimley Evans wrote:
> It's a possibility to bear in mind, definitely, but the
> perhaps-infinite loop can be observed with a cross-compiler:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=876825
I just tried doing the cross compile manually
Hi Edmund,
On Wed, Sep 27, 2017 at 10:23:38AM +0100, Edmund Grimley Evans wrote:
> For what it's worth, rnahybrid seems to build on armel with this in
> debian/rules:
>
> export DEB_CFLAGS_MAINT_APPEND=-O0
>
> Perhaps it would work with -O1 if I had more patience.
Do you think I should try anot
For what it's worth, rnahybrid seems to build on armel with this in
debian/rules:
export DEB_CFLAGS_MAINT_APPEND=-O0
Perhaps it would work with -O1 if I had more patience.
> The failure in build may in fact just be because the build machine is
> too slow.
It's a possibility to bear in mind, definitely, but the
perhaps-infinite loop can be observed with a cross-compiler:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=876825
(I will test with the compilers in uns
Hi Lennart,
thanks again for your analysis of the code.
On Tue, Sep 26, 2017 at 02:21:16PM -0400, Lennart Sorensen wrote:
> On Tue, Sep 26, 2017 at 02:09:56PM -0400, wrote:
> >
> > > > At some point I introduced an additional letter to the alphabet, the X
> > > > (a masking letter; see input.h
Well, I changed it at some point, and I sure had something in mind with that. I
suggest you go for fixing the loops now and see what happens.
All the best
Marc
On 26/09/17 20:09, "Lennart Sorensen" wrote:
On Tue, Sep 26, 2017 at 07:30:40PM +0200, Andreas Tille wrote:
> Hi Marc,
>
On Tue, Sep 26, 2017 at 02:09:56PM -0400, wrote:
> On Tue, Sep 26, 2017 at 07:30:40PM +0200, Andreas Tille wrote:
> > Hi Marc,
> >
> > thanks for the quick response.
> >
> > On Tue, Sep 26, 2017 at 06:45:42PM +0200, Marc Rehmsmeier wrote:
> > > Hi Andreas,
> > >
> > > I am not entirely sure wha
On Tue, Sep 26, 2017 at 07:30:40PM +0200, Andreas Tille wrote:
> Hi Marc,
>
> thanks for the quick response.
>
> On Tue, Sep 26, 2017 at 06:45:42PM +0200, Marc Rehmsmeier wrote:
> > Hi Andreas,
> >
> > I am not entirely sure what I was doing there and then. That seems to be
> > version 2.1.2, c
Hi Marc,
thanks for the quick response.
On Tue, Sep 26, 2017 at 06:45:42PM +0200, Marc Rehmsmeier wrote:
> Hi Andreas,
>
> I am not entirely sure what I was doing there and then. That seems to be
> version 2.1.2, correct?
Yes, that's correct. We always try to package the latest upstream
> I
On Tue, Sep 26, 2017 at 12:21:20PM -0400, Lennart Sorensen wrote:
> Here is a patch that removes all the warnings I see. Maybe that will
> help. I don't have an armel to test on.
>
> Most of the warnings are due to missing #include in a lot of places.
The failure in build may in fact just be be
On Tue, Sep 26, 2017 at 05:48:40PM +0200, Andreas Tille wrote:
> Hi Lennart,
>
> thanks for your suggestions. I hereby will forward it upstream hoping
> for comments.
Here is a patch that removes all the warnings I see. Maybe that will
help. I don't have an armel to test on.
Most of the warni
Hi Lennart,
thanks for your suggestions. I hereby will forward it upstream hoping
for comments.
Kind regards
Andreas.
On Tue, Sep 26, 2017 at 11:10:04AM -0400, Lennart Sorensen wrote:
> On Tue, Sep 26, 2017 at 09:57:09AM +0100, Edmund Grimley Evans wrote:
> > The infinite loop is still th
On Tue, Sep 26, 2017 at 09:57:09AM +0100, Edmund Grimley Evans wrote:
> The infinite loop is still there with gcc-7. I've created bug #876825.
>
> Before you exclude armel, you could perhaps try doing something about
> this warning, which is given not just on armel and may or may not be
> related
The infinite loop is still there with gcc-7. I've created bug #876825.
Before you exclude armel, you could perhaps try doing something about
this warning, which is given not just on armel and may or may not be
related to the compiler going into an infinite loop:
energy.c:539:104: warning: iterati
Hi,
On Fri, Apr 28, 2017 at 11:45:43AM +0100, Edmund Grimley Evans wrote:
> There may be no demand for this package (rnahybrid) on armel, but the
> FTBFS might be caused by a bug in gcc-6, which would be worth
> reporting if someone can confirm it.
We have gcc-7 now. Would anybody volunteer to c
There may be no demand for this package (rnahybrid) on armel, but the
FTBFS might be caused by a bug in gcc-6, which would be worth
reporting if someone can confirm it.
On Thu, Apr 27, 2017 at 07:23:20AM +, Gianfranco Costamagna wrote:
> Hello,
>
> > rnahybrid FTBFS on armel:
>
>
> the warning above is somewhat important
> (too many nested loops), and this usually relates badly with
> high optimization levels
>...
The warning is about an off-by-one in the
Hi Gianfranco,
On Thu, Apr 27, 2017 at 07:23:20AM +, Gianfranco Costamagna wrote:
> > rnahybrid FTBFS on armel:
>
> the warning above is somewhat important
> (too many nested loops), and this usually relates badly with
> high optimization levels
>
> gcc -DHAVE_CONFIG_H -I. -I.. -I/usr/includ
Hello,
> rnahybrid FTBFS on armel:
>
the warning above is somewhat important
(too many nested loops), and this usually relates badly with
high optimization levels
gcc -DHAVE_CONFIG_H -I. -I.. -I/usr/include -Wdate-time -D_FORTIFY_SOURCE=2 -g
-O0 -fdebug-prefix-map=/home/locutusofborg/rnahybr
tags 861281 help
thanks
Hi,
I admit I have no idea what the problem might be and the build log (see
below) does not enable me to spot the issue. Any help would be welcome
since otherwise the only solution I could imagine is to ask ftpmaster to
remove the armel port of this package.
Kind regards
package: rnahybrid
version: 2.1.2-1
severity: serious
Hi,
rnahybrid FTBFS on armel:
https://buildd.debian.org/status/logs.php?pkg=rnahybrid&ver=2.1.2-1%2Bb1&arch=armel
Cheers,
Ivo
29 matches
Mail list logo
