Previous Thread
Next Thread
Print Thread
Page 2 of 2 1 2
Joined: Feb 2007
Posts: 507
C
Senior Member
Offline
Senior Member
C
Joined: Feb 2007
Posts: 507
Originally Posted By Belegdol
It does not seem to work here. Moreover, if you look at the RPM Fusion build log, asteroid.c is not the only file with this issue. There are plenty of files.


Any file including rescap.h might be affected. That's about every audio driver which uses discrete sound :-(

The root cause is that the macros are used in a static struct initializer. One topic on my todo list is to replace the static initializers with dynamic code which creates the node list.

However, the warning itself is valid - apart from the fact that we didn't ask for it.

With RES_K(200) we get a "(double) (200000)". This is than used as a static value in a place where the discrete sound system also accepts a node, which are represented by an integer. And there the double is narrowed to int.

That's a design "feature" of the discrete sound system. Yes, miles apart from type safety. As indicated above there are plans to change this. But I have no idea when I might have the time.






Joined: Mar 2004
Posts: 669
Senior Member
Offline
Senior Member
Joined: Mar 2004
Posts: 669
Adding -Wno-narrowing to CPPONLYFLAGS makes this issue go away. Compiling further, mame hits this:
Quote:
src/emu/video/polynew.h: In member function ‘UINT32 poly_manager<_BaseType, _ObjectData, _MaxParams, _MaxPolys>::render_triangle(const rectangle&, poly_manager<_BaseType, _ObjectData, _MaxParams, _MaxPolys>::render_delegate, int, const poly_manager<_BaseType, _ObjectData, _MaxParams, _MaxPolys>::vertex_t&, const poly_manager<_BaseType, _ObjectData, _MaxParams, _MaxPolys>::vertex_t&, const poly_manager<_BaseType, _ObjectData, _MaxParams, _MaxPolys>::vertex_t&) [with _BaseType = float; _ObjectData = gaelco3d_object_data; int _MaxParams = 1; int _MaxPolys = 2000; UINT32 = unsigned int; poly_manager<_BaseType, _ObjectData, _MaxParams, _MaxPolys>::render_delegate = delegate<void(int, const poly_manager<float, gaelco3d_object_data, 1, 2000>::extent_t&, const gaelco3d_object_data&, int)>]’:
src/emu/video/polynew.h:657:12: error: ‘param_start[paramnum]’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
src/emu/video/polynew.h:659:12: error: ‘param_dpdy[paramnum]’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
src/emu/video/polynew.h:658:12: error: ‘param_dpdx[paramnum]’ may be used uninitialized in this function [-Werror=maybe-uninitialized]


ETA: Due to RB's strong opinion on gcc maintainers I don't feel comfortable filing a bug in Red Hat bugzilla and posting a link to this thread there.

ETA2: Anyhow, I don't think it is a bug, at least judging from the manpage:
Quote:
-Wnarrowing (C++ and Objective-C++ only)
Warn when a narrowing conversion prohibited by C++11 occurs within { }, e.g.
Code:
int i = { 2.2 }; // error: narrowing from double to int

This flag is included in -Wall and -Wc++11-compat.
With -std=c++11, -Wno-narrowing suppresses the diagnostic required by the standard. Note that this does not affect the meaning of well-formed code; narrowing conversions are still considered ill-formed in SFINAE context.

Last edited by Belegdol; 06/03/12 11:19 PM.
Joined: Mar 2001
Posts: 16,859
Likes: 51
R
Very Senior Member
Offline
Very Senior Member
R
Joined: Mar 2001
Posts: 16,859
Likes: 51
The polynew.h stuff is a real live compiler bug. If paramcount > 0 there is no way it doesn't get initialized, and if it's not there's no way it gets used.

And while the other thing is correct as per their documentation, I think it's serious asshattery to enforce new C++11 standards on code that we explicitly specify -std=gnu++98 on. That's 2 standards prior to C++11.

Joined: Mar 2004
Posts: 669
Senior Member
Offline
Senior Member
Joined: Mar 2004
Posts: 669
Hmm, it is not a new one then (search for polynew.h):
http://buildsys.rpmfusion.org/logs/fedor...86_64/build.log

Joined: Mar 2001
Posts: 16,859
Likes: 51
R
Very Senior Member
Offline
Very Senior Member
R
Joined: Mar 2001
Posts: 16,859
Likes: 51
Oh, right, because you build with unsupported options. I forgot about that.

Joined: Mar 2004
Posts: 669
Senior Member
Offline
Senior Member
Joined: Mar 2004
Posts: 669
Yes, this is true. Anyhow, while in gcc-4.6 this warning required my unsupported options to appear, gcc-4.7 shows it by default.

Joined: Mar 2001
Posts: 16,859
Likes: 51
R
Very Senior Member
Offline
Very Senior Member
R
Joined: Mar 2001
Posts: 16,859
Likes: 51
u2 should work on F17 and anything else on GCC 4.7.x out of the box, at least without weird other compiler options.

I gotta put in a good word for Fedora's "preupgrade" tool here: I ran it on my F16 box, clicked the "Reboot and continue" button when it finished downloading, and when I came back to my computer it had finished the upgrade and was waiting for me to log in to F17. It even saw that I had rpmfusion added and automatically installed the appropriate Nvidia binary driver as part of the upgrade, so hardware OpenGL and everything was ready immediately.

Joined: Dec 2006
Posts: 149
J
Senior Member
Offline
Senior Member
J
Joined: Dec 2006
Posts: 149
Hello friends. Long time no see. I got this error when compiling mame 0.146 and 0.146u1:

Code:
In file included from src/emu/emu.h:66,
                 from src/emu/ioport.c:122:
src/emu/attotime.h: In static member function ‘static attotime attotime::from_msec(INT64)’:
src/emu/attotime.h:143: internal compiler error: in tree_nrv, at tree-nrv.c:143
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://qa.mandriva.com/> for instructions.
make: ** [obj/sdl64/emu/ioport.o] Erro 1


The GCC is:

gcc (GCC) 4.4.3
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Joined: Feb 2007
Posts: 507
C
Senior Member
Offline
Senior Member
C
Joined: Feb 2007
Posts: 507
Are you using specific compiler options?

Or just "make"?

You may try "make OPTIMIZE=2" and see whether this helps. Decrement down to 0 until you have success.

Joined: Dec 2006
Posts: 149
J
Senior Member
Offline
Senior Member
J
Joined: Dec 2006
Posts: 149
Originally Posted By couriersud
Are you using specific compiler options?

Or just "make"?

You may try "make OPTIMIZE=2" and see whether this helps. Decrement down to 0 until you have success.


I just "make" with -j option.

Well, set OPTIMIZE=0 works! Look likes a compiler problem and I already submited the bug for mandriva.

Thanks!

Page 2 of 2 1 2

Moderated by  R. Belmont 

Link Copied to Clipboard
Who's Online Now
0 members (), 23 guests, and 3 robots.
Key: Admin, Global Mod, Mod
ShoutChat
Comment Guidelines: Do post respectful and insightful comments. Don't flame, hate, spam.
Forum Statistics
Forums9
Topics9,019
Posts118,453
Members5,010
Most Online890
Jan 17th, 2020
Forum Host
These forums are hosted by www.retrogamesformac.com
Forum hosted by www.retrogamesformac.com