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
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
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
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
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
>
>
>
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
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
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
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
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
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
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,
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
>
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
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
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
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:
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
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..
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
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
package: rnahybrid
version: 2.1.2-1
severity: serious
Hi,
rnahybrid FTBFS on armel:
https://buildd.debian.org/status/logs.php?pkg=rnahybrid=2.1.2-1%2Bb1=armel
Cheers,
Ivo
29 matches
Mail list logo