After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 320098 - Unsupported gcc flag in gst-libs/ext/ffmpeg/libavcodec/alpha/Makefile.am
Unsupported gcc flag in gst-libs/ext/ffmpeg/libavcodec/alpha/Makefile.am
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-libav
0.8.5
Other Linux
: Normal normal
: 0.8.8
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2005-10-28 16:15 UTC by Loïc Minier
Modified: 2005-10-28 19:15 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Loïc Minier 2005-10-28 16:15:58 UTC
Hi,

While building gst-ffmpeg on alpha for Debian, a build failure occured due to
the fact that gst-libs/ext/ffmpeg/libavcodec/alpha/Makefile.am uses the
-freduce-all-givs flag which has been removed in gcc 4.0.

You can safely remove this flag.

Cheers,
Comment 1 Ronald Bultje 2005-10-28 16:20:11 UTC
0.8.5 is fairly old... :). Do you know what the flag does? Like, would it cause
register-usage-reduction or something which could screw up, or is it just
something random that makes no apparent difference? I'm asking this so I know
whether to add a check for it or just remove it completely, even for the gcc3 build.

Thanks for testing btw.
Comment 2 Loïc Minier 2005-10-28 16:56:06 UTC
I reported against 0.8.5 because it's the first version FTBFSing with this that
I noticed: <http://buildd.debian.org/build.php?arch=&pkg=gst-ffmpeg>.

The flag was meant temporarily to sort out optimizations and enhance gcc, and
has been deprecated since 3.3 at least.  It's removal is described at
<http://gcc.gnu.org/gcc-4.0/changes.html> as follows:
"The options -freduce-all-givs and -fmove-all-movables have been discontinued.
They were used to circumvent a shortcoming in the heuristics of the old loop
optimization code with respect to common Fortran constructs. The new (tree) loop
optimizer works differently and doesn't need those work-arounds."

I think it's not important for a 3.3 build, but might enhance the loop
optimizations slightly, if the other loop enhancement options are not present,
but I won't test.
Comment 3 Ronald Bultje 2005-10-28 19:15:23 UTC
Applied, thanks.