Re: Qt5 switching qreal from float to double on arm*

2013-11-04 Thread Konstantinos Margaritis
On Sat, 02 Nov 2013 15:29:05 -0300
Lisandro Damián Nicanor Pérez Meyer perezme...@gmail.com wrote:

 Hi! Starting from Qt 5.2.0 (most probably from rc1 and definitely not
 from beta1 currently in experimental) Qt5 will switch qreal from
 float to double on arm*.
 
 We have the option to keep some archs in float by passing a
 compilation parameter. I've done so for armel and sh4, so only armhf
 will switch to double.
 
 Of course we are still on time to discuss this, and this is the
 reason of this mail. What do you think WRT the above changes?

FWIW, I was a bit sceptical about switching qreal to double. True this
would minimise the patches some packages would need on armhf, but OTOH,
I don't know what would happen to packages that use both GL graphics
and Qt at the same time. All armhf platforms support only OpenGLES and
not full OpenGL stack which supports *only* 32-bit floats.

However Lissandro just told me on IRC that GL-stuff on Qt5 switched to
float for exactly that reason). So apart from speed I don't see a
reason for not going that route. If anything, FPU in recent armv7-a
systems has become increasingly better so this will be better in a
couple of years (it will still suck on a Cortex-A8, but will be less
apparent on a Cortex-A15 or better).

FTR, I don't think many apps would mind that much. Most apps that
would actually care for speed/accuracy would use float/double directly
and not qreal, for most it would save us the burden of patching (eg.
scribus, qgis).

So unless, we find some particular strong cases for *not* switching to
double, I'd vote in favour of that.

Regards

Konstantinos


pgptRxGgvRfTP.pgp
Description: PGP signature


Re: please update patches / investigate build failures for gcc-4.7 snapshot builds

2011-12-31 Thread Konstantinos Margaritis
On 19 December 2011 14:55, Konstantinos Margaritis
mar...@genesi-usa.com wrote:
 On 19 December 2011 01:55, Matthias Klose d...@debian.org wrote:
 Please have a look at the gcc-4.7 package in experimental, update patches 
 (hurd,
 kfreebsd, ARM is fixed in svn), and investigate the build failures (currently
 ia64, but more will appear).

 Attached is the build failure on armhf (clean chroot with all bdeps 
 satisfied).

Just tested 4.7-20111222-1 as well, it built fine, installed and
tested 5 known gcc ICEs (ace, webkit, 2 neon-related ones, a gfortran
one) and all but one neon ICE were fixed :)

Regards

Konstantinos


-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/cabsevwt_qdasf6hg_ev2e3vvexdnnrxdvsqjerfbz6rbae4...@mail.gmail.com



Re: GCC-4.5 as the default for (at least some) architectures

2011-04-26 Thread Konstantinos Margaritis
On 26 April 2011 18:03, Matthias Klose d...@debian.org wrote:
 I'll make GCC 4.6 the default after the release of
 GCC 4.5.3, expected later this week, at least on amd64, armel, i386 and
 powerpc.

Could you include armhf in the list as well?

Thanks

Konstantinos


-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/BANLkTimddKkTaiy1fyka6zMOj0o1YzBS=a...@mail.gmail.com



Re: GCC-4.5 as the default for (at least some) architectures

2011-03-01 Thread Konstantinos Margaritis
On 2 March 2011 03:34, Matthias Klose d...@debian.org wrote:

 I'll make gcc-4.5 the default for (at least some) architectures within the
 next
 two weeks before more transitions start.  GCC-4.5 is already used as the
 default
 compiler for almost any other distribution, so there shouldn't be many
 surprises
 on at least the common architectures.  About 50% of the build failures
 exposed
 by GCC-4.5 are fixed [1].  I didn't see issues on amd64 and i386, armel
 (although optimized for a different processor) and powerpc (some object
 files
 linked into shared libs had to be built as pic).

 As the maintainer file for the ports in GCC is a bit outdated, I'd like to
 ask
 which architectures should do the switch together with the four
 architectures
 mentioned above, and which not, and which ones should be better delayed, or
 dropped.

 Could you add armhf to the list?

Konstantinos