[Bug tree-optimization/60899] undef reference generated with -fdevirtualize-speculatively

[xinliangli at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60899

--- Comment #4 from davidxl  ---
(In reply to davidxl from comment #3)
> (In reply to Jan Hubicka from comment #2)
> > David,
> > it seems a_m.C should be different form a.C.  From chain of events you
> > describe I think
> > we need to figure out why the last folding happens.  Does the function pass 
> > can_refer_decl_in_current_unit_p and if so, how does cgraph node look at
> > that time?
> > 
> > Honza
> 
> Cut & paste error:
> 
> // a_m.cc
> 
> #include "a.h"
> struct D2: public DI {
>   virtual int doit () { return 3; }
> };
> 
> extern int bar(DI*);
> int main()
> {
>   D2 d2;
>   return bar(&d2);
> }


stepping into can_refer_decl_in_current_unit_p indicates it returns true (for
A::foo and A::vtable) at the condition @line 106.

[Bug tree-optimization/60899] undef reference generated with -fdevirtualize-speculatively

[hubicka at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60899

--- Comment #5 from Jan Hubicka  ---
I am running benchmarks I do not want to disturb, but the following should fix
the problem.
$ svn diff ../../gcc/gimple-fold.c
Index: ../../gcc/gimple-fold.c
===
--- ../../gcc/gimple-fold.c (revision 209526)
+++ ../../gcc/gimple-fold.c (working copy)
@@ -105,7 +105,9 @@ can_refer_decl_in_current_unit_p (tree d
  external var.  */
   if (!from_decl
   || TREE_CODE (from_decl) != VAR_DECL
-  || !DECL_EXTERNAL (from_decl)
+  || (!DECL_EXTERNAL (from_decl)
+ && (vnode = varpool_get_node (from_decl)) != NULL
+ && vnode->definition)
   || (flag_ltrans
  && symtab_get_node (from_decl)->in_other_partition))
 return true;

[Bug target/60900] New: ICE: in emit_library_call_value_1, at calls.c:4187 with -mabi=ms -mlong-double-128

[zsojka at seznam dot cz]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60900

Bug ID: 60900
   Summary: ICE: in emit_library_call_value_1, at calls.c:4187
with -mabi=ms -mlong-double-128
   Product: gcc
   Version: 4.10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz

Created attachment 32634
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32634&action=edit
reduced testcase

Compiler output:
$ gcc -mabi=ms -mlong-double-128 testcase.c
testcase.c: In function 'foo':
testcase.c:3:3: internal compiler error: in emit_library_call_value_1, at
calls.c:4187
   return a;
   ^
0x73c2d6 emit_library_call_value_1
/mnt/svn/gcc-trunk/gcc/calls.c:4186
0x742bbf emit_library_call_value(rtx_def*, rtx_def*, libcall_type,
machine_mode, int, ...)
/mnt/svn/gcc-trunk/gcc/calls.c:4369
0xa3b650 expand_fix(rtx_def*, rtx_def*, int)
/mnt/svn/gcc-trunk/gcc/optabs.c:5364
0x860e56 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
/mnt/svn/gcc-trunk/gcc/expr.c:8706
0x755e62 expand_gimple_stmt_1
/mnt/svn/gcc-trunk/gcc/cfgexpand.c:3248
0x755e62 expand_gimple_stmt
/mnt/svn/gcc-trunk/gcc/cfgexpand.c:3308
0x757f17 expand_gimple_basic_block
/mnt/svn/gcc-trunk/gcc/cfgexpand.c:5148
0x75a256 execute
/mnt/svn/gcc-trunk/gcc/cfgexpand.c:5758
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug libstdc++/59439] std::locale uses atomic instructions on construction

[antoshkka at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59439

Antony Polukhin  changed:

   What|Removed |Added

 CC||antoshkka at gmail dot com

--- Comment #7 from Antony Polukhin  ---
(In reply to Jonathan Wakely from comment #5)
> There's a good reason boost::lexical_cast is special-cased for the common
> int-to-string conversions that don't need fancy formatting.

I'm the current maintainer of boost::lexical_cast and I'd like to add my 2
cetns.

Construction of std::locale is a common case all around the Boost libraries.
Here are some of the cases when std::locale is constructed:
* in almost any conversion with boost::lexical_cast
* in all the string related algorithms in Boost.Algorithm (like compare(),
erase(), find() and others)
* in methods of Boost.Locale like to_upper, to_lower, normalize and others...
* in parsers of Boost.PropertyTree

In most cases I've seen only the global 'C' locale is used in user code, so
optimizing it's construction/descruction/copying will have a good impact on
code performance.

[Bug rtl-optimization/60901] New: [4.8/4.9/4.10 Regression] ICE: SIGSEGV in add_to_deps_list with -fsel-sched-pipelining-outer-loops

[zsojka at seznam dot cz]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60901

Bug ID: 60901
   Summary: [4.8/4.9/4.10 Regression] ICE: SIGSEGV in
add_to_deps_list with
-fsel-sched-pipelining-outer-loops
   Product: gcc
   Version: 4.10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz

Created attachment 32635
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32635&action=edit
reduced testcase

Compiler output (under valgrind):
$ gcc -O -fselective-scheduling -fschedule-insns -fsel-sched-pipelining
-fsel-sched-pipelining-outer-loops -fno-tree-dominator-opts testcase.c
==23085== Invalid read of size 8
==23085==at 0x1394529: add_to_deps_list(_dep_link*, _deps_list*)
(sched-deps.c:247)
==23085==by 0x13A1493: sd_add_dep(_dep*, bool) (sched-deps.c:1344)
==23085==by 0x13A1B85: add_or_update_dep_1(_dep*, bool, rtx_def*, rtx_def*)
(sched-deps.c:1286)
==23085==by 0x13A212C: haifa_note_dep(rtx_def*, unsigned int)
(sched-deps.c:1866)
==23085==by 0x1394CB2: add_dependence_1(rtx_def*, rtx_def*, reg_note)
(sched-deps.c:1901)
==23085==by 0x13992C3: add_dependence(rtx_def*, rtx_def*, reg_note)
(sched-deps.c:1557)
==23085==by 0xDE227A: ix86_dependencies_evaluation_hook(rtx_def*, rtx_def*)
(i386.c:26191)
==23085==by 0xADC311: sched_rgn_compute_dependencies(int)
(sched-rgn.c:2746)
==23085==by 0xB0D4E3: sel_sched_region(int) (sel-sched.c:6933)
==23085==by 0xB0F329: run_selective_scheduling() (sel-sched.c:7798)
==23085==by 0xADF44D: (anonymous namespace)::pass_sched::execute(function*)
(sched-rgn.c:3618)
==23085==by 0xA484E0: execute_one_pass(opt_pass*) (passes.c:2159)
==23085==by 0xA48785: execute_pass_list(opt_pass*) (passes.c:2212)
==23085==by 0xA48797: execute_pass_list(opt_pass*) (passes.c:2213)
==23085==by 0x785208: expand_function(cgraph_node*) (cgraphunit.c:1774)
==23085==by 0x7871EB: compile() (cgraphunit.c:1908)
==23085==by 0x787954: finalize_compilation_unit() (cgraphunit.c:2329)
==23085==by 0x63ADA3: c_write_global_declarations() (c-decl.c:10401)
==23085==by 0xB3BF2C: compile_file() (toplev.c:562)
==23085==by 0xB3DEFF: toplev_main(int, char**) (toplev.c:1914)
==23085==by 0x5A46BF4: (below main) (in /lib64/libc-2.17.so)
==23085==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==23085== 

Tested revisions:
r209530 - ICE
4.9 r209346 - ICE
4.8 r209342 - ICE
4.7 r209345 - OK

[Bug c/60902] New: ffmpeg built with gcc 4.9 RC produces incorrect flac playback code

[arthur.marsh at internode dot on.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60902

Bug ID: 60902
   Summary: ffmpeg built with gcc 4.9 RC produces incorrect flac
playback code
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arthur.marsh at internode dot on.net

Using the gcc-4.9 version 4.9-20140411-2 on Debian GNU/Linux amd64, I'm getting
incorrect code for ffmpeg flac format decoding (same source code compiled with
gcc-4.8 version 4.8.2-19 works fine).

The problem only affects some flac files that have nonetheless been passed as
valid by flac version 1.3.0.

The error returned is similar to:

[flac @ 0x7f3b540092e0] invalid subframe paddingB sq=0B f=0/0
[flac @ 0x7f3b540092e0] decode_frame() failed

The bug report against ffmpeg is at:

https://trac.ffmpeg.org/ticket/3559

I am *NOT* a C programmer and am not familiar with the flac format decoding
process but am posting this in case anyone who is might be prepared to
investigate further.

Thanks for any help or suggestions.

[Bug target/60902] ffmpeg built with gcc 4.9 RC produces incorrect flac playback code

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60902

Andrew Pinski  changed:

   What|Removed |Added

 Target||X86_64-*-Linux-gnu
  Component|c   |target

--- Comment #1 from Andrew Pinski  ---
What options are you compiling ffmpeg with?

[Bug tree-optimization/60903] New: [4.8/4.9/4.10 Regression] ICE: in verify_loop_structure, at cfgloop.c:1647: : edge from 13 to 14 should be marked irreducible

[zsojka at seznam dot cz]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60903

Bug ID: 60903
   Summary: [4.8/4.9/4.10 Regression] ICE: in
verify_loop_structure, at cfgloop.c:1647: : edge from
13 to 14 should be marked irreducible
   Product: gcc
   Version: 4.10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz

Created attachment 32636
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32636&action=edit
reduced testcase

Compiler output:
$ gcc -Os -fno-tree-copy-prop -ftree-loop-distribute-patterns
-fno-tree-scev-cprop --param=allow-store-data-races=0 testcase.c
testcase.c: In function 'foo':
testcase.c:4:1: error: edge from 13 to 14 should be marked irreducible
 foo ()
 ^
testcase.c:4:1: error: basic block 14 should be marked irreducible
testcase.c:4:1: error: edge from 14 to 12 should be marked irreducible
testcase.c:4:1: internal compiler error: in verify_loop_structure, at
cfgloop.c:1647
0x762369 verify_loop_structure()
/mnt/svn/gcc-trunk/gcc/cfgloop.c:1647
0xbb2c32 execute
/mnt/svn/gcc-trunk/gcc/tree-loop-distribution.c:1821
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

$ gcc -v
Using built-in specs.
COLLECT_GCC=/mnt/svn/gcc-trunk/binary-latest/bin/gcc
COLLECT_LTO_WRAPPER=/mnt/svn/gcc-trunk/binary-209530-lto-fortran-checking-yes-rtl-df/libexec/gcc/x86_64-unknown-linux-gnu/4.10.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /mnt/svn/gcc-trunk//configure --enable-checking=yes,rtl,df
--enable-languages=c,c++,lto,fortran
--prefix=/mnt/svn/gcc-trunk/binary-209530-lto-fortran-checking-yes-rtl-df/
--without-cloog --without-ppl
Thread model: posix
gcc version 4.10.0 20140419 (experimental) (GCC) 

Tested revisions:
r209530 - ICE
4.9 r209346 - ICE
4.8 r209342 - ICE
4.7 r209345 - OK

[Bug target/60902] ffmpeg built with gcc 4.9 RC produces incorrect flac playback code

[arthur.marsh at internode dot on.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60902

--- Comment #2 from Arthur Marsh  ---
Created attachment 32637
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32637&action=edit
config.mak produced by ./configure --cc=gcc-4.9 --host-cc=gcc-4.9
--dep-cc=gcc-4.9

[Bug target/60902] ffmpeg built with gcc 4.9 RC produces incorrect flac playback code

[arthur.marsh at internode dot on.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60902

--- Comment #3 from Arthur Marsh  ---
I've attached the config.mak produced by ./configure --cc=gcc-4.9
--host-cc=gcc-4.9 --dep-cc=gcc-4.9

The CFLAGS from config.mak:

CFLAGS=   -std=c99 -fomit-frame-pointer -pthread -D_GNU_SOURCE=1 -D_REENTRANT
-I
/usr/include/SDL -g -Wdeclaration-after-statement -Wall -Wdisabled-optimization
-Wpointer-arith -Wredundant-decls -Wwrite-strings -Wtype-limits -Wundef
-missing-prototypes -Wno-pointer-to-int-cast -Wstrict-prototypes -Wempty-body
-Wno-parentheses -Wno-switch -Wno-format-zero-length -Wno-pointer-sign -O3
-fno-math-errno -fno-signed-zeros -fno-tree-vectorize
-Werror=implicit-function-declaration -Werror=missing-prototypes
-Werror=return-type -Werror=vla -Wno-maybe-uninitialized

[Bug target/60902] ffmpeg built with gcc 4.9 RC produces incorrect flac playback code

[arthur.marsh at internode dot on.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60902

--- Comment #4 from Arthur Marsh  ---
I've attached the config.mak produced by ./configure --cc=gcc-4.9
--host-cc=gcc-4.9 --dep-cc=gcc-4.9

The CFLAGS from config.mak:

CFLAGS=   -std=c99 -fomit-frame-pointer -pthread -D_GNU_SOURCE=1 -D_REENTRANT
-I
/usr/include/SDL -g -Wdeclaration-after-statement -Wall -Wdisabled-optimization
-Wpointer-arith -Wredundant-decls -Wwrite-strings -Wtype-limits -Wundef
-missing-prototypes -Wno-pointer-to-int-cast -Wstrict-prototypes -Wempty-body
-Wno-parentheses -Wno-switch -Wno-format-zero-length -Wno-pointer-sign -O3
-fno-math-errno -fno-signed-zeros -fno-tree-vectorize
-Werror=implicit-function-declaration -Werror=missing-prototypes
-Werror=return-type -Werror=vla -Wno-maybe-uninitialized

[Bug target/60902] ffmpeg built with gcc 4.9 RC produces incorrect flac playback code

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60902

--- Comment #5 from Andrew Pinski  ---
Can you try adding -fno-strict-aliasing -fwrapv ?

Next is does ffmpeg have inline-asm for the flac codec?  This requires some C
code knowledge though.

[Bug target/60902] ffmpeg built with gcc 4.9 RC produces incorrect flac playback code

[mpolacek at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60902

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #6 from Marek Polacek  ---
(In reply to Andrew Pinski from comment #5)
> Can you try adding -fno-strict-aliasing -fwrapv ?

And -fno-aggressive-loop-optimizations.  I see the vectorizer is already turned
off.

[Bug target/60902] ffmpeg built with gcc 4.9 RC produces incorrect flac playback code

[arthur.marsh at internode dot on.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60902

--- Comment #7 from Arthur Marsh  ---
OK, I modified the CFLAGS statement in config.mak to what is below, re-ran make
clean and make, and still experienced the same problems.

CFLAGS=   -std=c99 -fomit-frame-pointer -pthread -D_GNU_SOURCE=1 -D_REENTRANT
-I/usr/include/SDL -g -Wdeclaration-after-statement -Wall
-Wdisabled-optimization -Wpointer-arith -Wredundant-decls -Wwrite-strings
-Wtype-limits -Wundef -Wmissing-prototypes -Wno-pointer-to-int-cast
-Wstrict-prototypes -Wempty-body -Wno-parentheses -Wno-switch
-Wno-format-zero-length -Wno-pointer-sign -O3 -fno-math-errno -fno-signed-zeros
-fno-tree-vectorize -Werror=implicit-function-declaration
-Werror=missing-prototypes -Werror=return-type -Werror=vla
-Wno-maybe-uninitialized -fno-strict-aliasing -fwrapv
-fno-aggressive-loop-optimizations

Thanks for your interest.

[Bug target/60902] ffmpeg built with gcc 4.9 RC produces incorrect flac playback code

[arthur.marsh at internode dot on.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60902

--- Comment #8 from Arthur Marsh  ---
PS, no assembly language in the flac decoding process as far as I could see.

[Bug target/60902] ffmpeg built with gcc 4.9 RC produces incorrect flac playback code

[trippels at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60902

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||trippels at gcc dot gnu.org

--- Comment #9 from Markus Trippelsdorf  ---
Compiling ffmpeg with -fsanitize=undefined shows:

 % ffplay -v 9 -loglevel 99 -i 10.innocent_starter.tiny.flac
...
Input #0, flac, from '10.innocent_starter.tiny.flac':
  Metadata:
ARTIST  : 水樹奈々
ALBUM   : THE MUSEUM
TITLE   : innocent starter
DATE: 2007
GENRE   : JPop
track   : 10
CDDB: e111e110
  Duration: 00:04:40.64, bitrate: 59 kb/s
Stream #0:0, 56, 1/44100: Audio: flac, 44100 Hz, stereo, s16
detected 4 logical cores
[ffplay_abuffer @ 0x7fc9940066a0] Setting 'sample_rate' to value '44100'
[ffplay_abuffer @ 0x7fc9940066a0] Setting 'sample_fmt' to value 's16'
[ffplay_abuffer @ 0x7fc9940066a0] Setting 'channels' to value '2'
[ffplay_abuffer @ 0x7fc9940066a0] Setting 'time_base' to value '1/44100'
[ffplay_abuffer @ 0x7fc9940066a0] Setting 'channel_layout' to value '0x3'
[ffplay_abuffer @ 0x7fc9940066a0] tb:1/44100 samplefmt:s16 samplerate:44100
chlayout:0x3
[AVFilterGraph @ 0x7fc994001790] query_formats: 2 queried, 3 merged, 0 already
done, 0 delayed
Audio frame changed from rate:44100 ch:2 fmt:s16 layout:stereo serial:-1 to
rate:44100 ch:2 fmt:s16 layout:stereo serial:1
[ffplay_abuffer @ 0x7fc988000f00] Setting 'sample_rate' to value '44100'
[ffplay_abuffer @ 0x7fc988000f00] Setting 'sample_fmt' to value 's16'
[ffplay_abuffer @ 0x7fc988000f00] Setting 'channels' to value '2'
[ffplay_abuffer @ 0x7fc988000f00] Setting 'time_base' to value '1/44100'
[ffplay_abuffer @ 0x7fc988000f00] Setting 'channel_layout' to value '0x3'
[ffplay_abuffer @ 0x7fc988000f00] tb:1/44100 samplefmt:s16 samplerate:44100
chlayout:0x3
[AVFilterGraph @ 0x7fc988000be0] query_formats: 2 queried, 3 merged, 0 already
done, 0 delayed
/var/tmp/portage/media-video/ffmpeg-2.2.1/work/ffmpeg-2.2.1/libavcodec/golomb.h:332:28:
runtime error: left shift of negative value -1
/var/tmp/portage/media-video/ffmpeg-2.2.1/work/ffmpeg-2.2.1/libavcodec/flacdsp_template.c:85:36:
runtime error: left shift of negative value -4
/var/tmp/portage/media-video/ffmpeg-2.2.1/work/ffmpeg-2.2.1/libavcodec/flacdsp_template.c:86:36:
runtime error: left shift of negative value -4
/var/tmp/portage/media-video/ffmpeg-2.2.1/work/ffmpeg-2.2.1/libavcodec/flacdsp_template.c:100:36:
runtime error: left shift of negative value -5
/var/tmp/portage/media-video/ffmpeg-2.2.1/work/ffmpeg-2.2.1/libavcodec/flacdsp_template.c:101:36:
runtime error: left shift of negative value -2
[flac @ 0x7fc994003a20] invalid subframe paddingB sq=0B f=0/0   
[flac @ 0x7fc994003a20] decode_frame() failed
/var/tmp/portage/media-video/ffmpeg-2.2.1/work/ffmpeg-2.2.1/libavcodec/flacdsp.c:63:16:
runtime error: signed integer overflow: 1246 * -2064943 cannot be represented
in type 
'int'
/var/tmp/portage/media-video/ffmpeg-2.2.1/work/ffmpeg-2.2.1/libavcodec/flacdsp.c:63:12:
runtime error: signed integer overflow: 1722048318 + 1035287866 cannot be
represented 
in type 'int'
/var/tmp/portage/media-video/ffmpeg-2.2.1/work/ffmpeg-2.2.1/libavcodec/flacdsp.c:58:20:
runtime error: signed integer overflow: 1777 * -2064943 cannot be represented
in type 
'int'
/var/tmp/portage/media-video/ffmpeg-2.2.1/work/ffmpeg-2.2.1/libavcodec/flacdsp.c:56:20:
runtime error: signed integer overflow: -1668 * -2064943 cannot be represented
in type
 'int'
/var/tmp/portage/media-video/ffmpeg-2.2.1/work/ffmpeg-2.2.1/libavcodec/flacdsp.c:58:16:
runtime error: signed integer overflow: 1024856828 + 1571300099 cannot be
represented 
in type 'int'
/var/tmp/portage/media-video/ffmpeg-2.2.1/work/ffmpeg-2.2.1/libavcodec/flacdsp.c:61:16:
runtime error: signed integer overflow: 1246 * -3189343 cannot be represented
in type 
'int'
/var/tmp/portage/media-video/ffmpeg-2.2.1/work/ffmpeg-2.2.1/libavcodec/flacdsp.c:56:16:
runtime error: signed integer overflow: -1372495215 + -1772004530 cannot be
represente
d in type 'int'
/var/tmp/portage/media-video/ffmpeg-2.2.1/work/ffmpeg-2.2.1/libavcodec/flacdsp.c:61:12:
runtime error: signed integer overflow: -1496662804 + -1546546990 cannot be
represente
d in type 'int'
[flac @ 0x7fc994003a20] invalid subframe padding
[flac @ 0x7fc994003a20] decode_frame() failed
/var/tmp/portage/media-video/ffmpeg-2.2.1/work/ffmpeg-2.2.1/libavcodec/flacdsp_template.c:71:36:
runtime error: left shift of negative value -2349
/var/tmp/portage/media-video/ffmpeg-2.2.1/work/ffmpeg-2.2.1/libavcodec/flacdsp_template.c:72:36:
runtime error: left shift of negative value -5961
[flac @ 0x7fc994004c20] invalid subframe paddingB sq=0B f=0/0   
[flac @ 0x7fc994004c20] decode_frame() failed
[flac @ 0x7fc994004c20] invalid subframe paddingB sq=0B f=0/0   
[flac @ 0x7fc994004c20] decode_frame() failed
[fla

[Bug target/60902] ffmpeg built with gcc 4.9 RC produces incorrect flac playback code

[arthur.marsh at internode dot on.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60902

--- Comment #10 from Arthur Marsh  ---
I haven't been able to reproduce what was shown in comment 9, but appreciate
the effort taken to reproduce the problem.

[Bug target/60902] ffmpeg built with gcc 4.9 RC produces incorrect flac playback code

[trippels at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60902

--- Comment #11 from Markus Trippelsdorf  ---
OK I'm down to one function from ./libavcodec/flacdec.c:

208 __attribute__ ((optimize(0)))
209 static int decode_residuals(FLACContext *s, int32_t *decoded, int
pred_order)
210 {
211 int i, tmp, partition, method_type, rice_order;
212 int rice_bits, rice_esc;
213 int samples;
214
215 method_type = get_bits(&s->gb, 2);
216 if (method_type > 1) {
217 av_log(s->avctx, AV_LOG_ERROR, "illegal residual coding method
%d\n",
218method_type);
219 return AVERROR_INVALIDDATA;
220 }
221
222 rice_order = get_bits(&s->gb, 4);
223
224 samples= s->blocksize >> rice_order;
225 if (samples << rice_order != s->blocksize) {
226 av_log(s->avctx, AV_LOG_ERROR, "invalid rice order: %i blocksize
%i\n",
227rice_order, s->blocksize);
228 return AVERROR_INVALIDDATA;
229 }
230
231 if (pred_order > samples) {
232 av_log(s->avctx, AV_LOG_ERROR, "invalid predictor order: %i >
%i\n",
233pred_order, samples);
234 return AVERROR_INVALIDDATA;
235 }
236
237 rice_bits = 4 + method_type;
238 rice_esc  = (1 << rice_bits) - 1;
239
240 decoded += pred_order;
241 i= pred_order;
242 for (partition = 0; partition < (1 << rice_order); partition++) {
243 tmp = get_bits(&s->gb, rice_bits);
244 if (tmp == rice_esc) {
245 tmp = get_bits(&s->gb, 5);
246 for (; i < samples; i++)
247 *decoded++ = get_sbits_long(&s->gb, tmp);
248 } else {
249 for (; i < samples; i++) {
250 *decoded++ = get_sr_golomb_flac(&s->gb, tmp, INT_MAX, 0);
251 }
252 }
253 i= 0;
254 }
255
256 return 0;
257 }
258

Without __attribute__ ((optimize(0))) it gets miscompiled.

[Bug target/60902] ffmpeg built with gcc 4.9 RC produces incorrect flac playback code

[trippels at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60902

--- Comment #12 from Markus Trippelsdorf  ---
Created attachment 32638
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32638&action=edit
Unreduced testcase

[Bug target/60902] ffmpeg built with gcc 4.9 RC produces incorrect flac playback code

[trippels at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60902

Markus Trippelsdorf  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
  Known to work||4.7.3, 4.8.3
   Keywords||wrong-code
   Last reconfirmed||2014-04-20
 CC||law at gcc dot gnu.org
 Ever confirmed|0   |1
   Target Milestone|--- |4.9.0
  Known to fail||4.9.0

--- Comment #13 from Markus Trippelsdorf  ---
Started with r205279.

[Bug tree-optimization/60902] ffmpeg built with gcc 4.9 RC produces incorrect flac playback code

[trippels at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60902

--- Comment #14 from Markus Trippelsdorf  ---
Created attachment 32639
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32639&action=edit
good assembler output r205278

[Bug tree-optimization/60902] ffmpeg built with gcc 4.9 RC produces incorrect flac playback code

[trippels at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60902

--- Comment #15 from Markus Trippelsdorf  ---
Created attachment 32640
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32640&action=edit
bad assembler output r205279

[Bug tree-optimization/60899] undef reference generated with -fdevirtualize-speculatively

[ppluzhnikov at google dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60899

Paul Pluzhnikov  changed:

   What|Removed |Added

 CC||ppluzhnikov at google dot com

--- Comment #6 from Paul Pluzhnikov  ---
Google ref: b/13453242

[Bug tree-optimization/60904] New: ffmpeg built with gcc 4.9 RC produces incorrect shorten playback code

[cehoyos at ag dot or.at]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60904

Bug ID: 60904
   Summary: ffmpeg built with gcc 4.9 RC produces incorrect
shorten playback code
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cehoyos at ag dot or.at

gcc 4.9.0 RC miscompiles FFmpeg's shorten decoder, this is reproducible with
current FFmpeg git head and the last release, 2.2.1:
The problem can be reproduced with the fate tests (FFmpeg's self test, the
samples are large):
$ ./configure && make ffmpeg
$ make SAMPLES=fate-samples fate-rsync
$ make SAMPLES=fate-samples fate-shorten

Or you can try to convert or playback the sample:
$ rsync -t
rsync://fate-suite.ffmpeg.org/fate-suite/lossless-audio/luckynight-partial.shn
.
$ ffmpeg -i luckynight-partial.shn out.wav
$ ffplay luckynight-partial.shn

The sample is supposed to be nine seconds long but only two seconds are played
/ converted.

Works fine with many previous versions of gcc, including 4.8.2 and 4.7.2.

This may or may not be related to Bug 60902
I originally found it when testing FFmpeg ticket #3559:
https://trac.ffmpeg.org/ticket/3559

[Bug tree-optimization/60905] New: ffmpeg built with gcc 4.9 RC produces incorrect loco playback code

[cehoyos at ag dot or.at]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60905

Bug ID: 60905
   Summary: ffmpeg built with gcc 4.9 RC produces incorrect loco
playback code
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cehoyos at ag dot or.at

gcc 4.9.0 RC miscompiles FFmpeg's loco decoder (an old video format), this is
reproducible with current FFmpeg git head (e70b9b32) and the last release,
2.2.1:
The problem can be reproduced with the fate tests (FFmpeg's self test, the
samples are large):
$ ./configure && make ffmpeg
$ make SAMPLES=fate-samples fate-rsync
$ make SAMPLES=fate-samples fate-loco-rgb
$ make SAMPLES=fate-samples fate-loco-yuy2
Both tests take a very long time instead of fractions of a second and output
incorrect data.

Also reproducible without running the tests:
$ rsync -t rsync://fate-suite.ffmpeg.org/fate-suite/loco/pig* .
$ ffmpeg -i pig-loco-0.avi out1.avi
$ ffmpeg -i pig-loco-rgb.avi out2.avi
The output files look completely broken.

Works fine with many previous versions of gcc, including 4.8.2 and 4.7.2.

This may or may not be related to Bug 60902 and Bug 60904

I originally found the problem when testing FFmpeg ticket #3559:
https://trac.ffmpeg.org/ticket/3559

[Bug tree-optimization/60904] ffmpeg built with gcc 4.9 RC produces incorrect shorten playback code

[trippels at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60904

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||trippels at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #1 from Markus Trippelsdorf  ---
r205279 is bad, r205278 is fine.
Must be a dup of PR60902.

*** This bug has been marked as a duplicate of bug 60902 ***

[Bug tree-optimization/60902] [4.9/4.10 Regression] ffmpeg built with gcc 4.9 RC produces incorrect flac playback code

[trippels at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60902

--- Comment #16 from Markus Trippelsdorf  ---
*** Bug 60904 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/60902] [4.9/4.10 Regression] ffmpeg built with gcc 4.9 RC produces incorrect flac playback code

[trippels at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60902

--- Comment #17 from Markus Trippelsdorf  ---
Created attachment 32641
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32641&action=edit
Testcase from PR60904

[Bug tree-optimization/60905] ffmpeg built with gcc 4.9 RC produces incorrect loco playback code

[trippels at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60905

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||trippels at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #1 from Markus Trippelsdorf  ---
Same thing. Also dup of PR60902.

*** This bug has been marked as a duplicate of bug 60902 ***

[Bug tree-optimization/60902] [4.9/4.10 Regression] ffmpeg built with gcc 4.9 RC produces incorrect flac playback code

[trippels at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60902

--- Comment #18 from Markus Trippelsdorf  ---
*** Bug 60905 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/60902] [4.9/4.10 Regression] ffmpeg built with gcc 4.9 RC produces incorrect flac playback code

[trippels at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60902

--- Comment #19 from Markus Trippelsdorf  ---
Created attachment 32642
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32642&action=edit
Testcase from PR60905

[Bug target/60906] New: target attribute causes other attributes to be ignored

[harald at gigawatt dot nl]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60906

Bug ID: 60906
   Summary: target attribute causes other attributes to be ignored
   Product: gcc
   Version: 4.8.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: harald at gigawatt dot nl

When the target attribute is used to select a function based on CPU, other
attributes get ignored. This can lead to missed optimisations and/or wrong
code, depending on the specific attribute.

Missed optimisation:

void foo() __attribute__((target("default"), noreturn));
void foo() __attribute__((target("arch=corei7"), noreturn));

void bar() { foo(); foo(); }

The second call to foo, and the following return, could be optimised away (and
are if the target attribute is not used).

Wrong code:

#include 

int __attribute__((target("default"), regparm(3))) f(int x) { return x; }
int __attribute__((target("arch=corei7"), regparm(3))) f(int x) { return x; }

int main() {
  assert(f(3) == 3);
}

The assertion fails (on x86-32). Tested with 4.8.2.

[Bug lto/50394] [meta-bug] Issues with building libreoffice with LTO

[nheghathivhistha at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50394

David Kredba  changed:

   What|Removed |Added

 CC||nheghathivhistha at gmail dot 
com

--- Comment #28 from David Kredba  ---
Gcc trunk revision 209488 built for me libreoffice 4.2.3.3 with -flto=4
-fuse-linker-plugin and resulting binaries works.

[Bug lto/50394] [meta-bug] Issues with building libreoffice with LTO

[hubicka at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50394

Jan Hubicka  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #29 from Jan Hubicka  ---
Indeed, at the moment I see now important showstoppers for Libreoffice, only
thing I need is ar/nm/ranlib wrapper on my path.

I am closing this sort of open-ended PR until some problems reappears ;))

[Bug bootstrap/60830] [4.9 Regression] ICE on bootstrapping on cygwin

[bernd.edlinger at hotmail dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830

--- Comment #29 from Bernd Edlinger  ---
Hmm, that is really strange.

the crash happens in __gcc_deregister_frame.
just break at this function and step.
The first call is GetModuleHandle (LIBGCC_SONAME) which
returns NULL, so the weak default __deregister_frame_info
is used. BUT the address is wrong by 0x10.

00401170 <___gcc_deregister_frame>:
  401170:   55  push   %ebp
  401171:   89 e5   mov%esp,%ebp
  401173:   83 ec 18sub$0x18,%esp
  401176:   c7 04 24 20 71 47 00movl   $0x477120,(%esp)
  40117d:   ff 15 50 b4 4c 00   call   *0x4cb450
  401183:   83 ec 04sub$0x4,%esp
  401186:   85 c0   test   %eax,%eax
  401188:   ba 10 25 47 00  mov$0x472510,%edx
  40118d:   74 16   je 4011a5
<___gcc_deregister_frame+0x35>
  40118f:   c7 44 24 04 67 71 47movl   $0x477167,0x4(%esp)
  401196:   00
  401197:   89 04 24mov%eax,(%esp)
  40119a:   ff 15 54 b4 4c 00   call   *0x4cb454
  4011a0:   83 ec 08sub$0x8,%esp
  4011a3:   89 c2   mov%eax,%edx
  4011a5:   85 d2   test   %edx,%edx
  4011a7:   74 09   je 4011b2
<___gcc_deregister_frame+0x42>
  4011a9:   c7 04 24 38 b0 4b 00movl   $0x4bb038,(%esp)
  4011b0:   ff d2   call   *%edx

=> this call goes to 0x472510 instead of 0x472520.


  4724ff:   e8 fc 01 00 00  call   472700 <_free>
  472504:   8b 44 24 1c mov0x1c(%esp),%eax
  472508:   83 c4 28add$0x28,%esp
  47250b:   5b  pop%ebx
  47250c:   c3  ret
  47250d:   89 d0   mov%edx,%eax
  47250f:   ba e4 ac 4c 00  mov$0x4cace4,%edx
  472514:   eb a6   jmp4724bc
<___deregister_frame_info_bases+0x6c>
  472516:   8d 76 00lea0x0(%esi),%esi
  472519:   8d bc 27 00 00 00 00lea0x0(%edi,%eiz,1),%edi

00472520 <___deregister_frame_info>:
  472520:   e9 2b ff ff ff  jmp472450
<___deregister_frame_info_bases>
  472525:   8d 74 26 00 lea0x0(%esi,%eiz,1),%esi
  472529:   8d bc 27 00 00 00 00lea0x0(%edi,%eiz,1),%edi

[Bug fortran/59678] [F03] Segfault on equalizing variables of a complex derived type

[talebi.hossein at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59678

--- Comment #15 from Hossein Talebi  ---
Hi, will this bug be fixed anytime soon or is it fixed already in GCC4.9?

[Bug c/60907] New: Can't break inside empty loop (without any optimization)

[a3at.mail at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60907

Bug ID: 60907
   Summary: Can't break inside empty loop (without any
optimization)
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: a3at.mail at gmail dot com

It is very useful to break inside empty loops for debugging with gdb.
But unfortunately code generated by gcc don't allow to do this, unlike clang
(3.4-2)

Steps to reproduce:
==
$ cat test.c
#include 
int main()
{
for (int i = 0; i < 10; ++i) {

}
return 0;
}

$ gcc -std=c99 -g3 -O0 test.c -o test; gdb -ex 'dprintf 5,"i: %i\n", i' -ex run
-batch ./test
Dprintf 1 at 0x4004c4: file test.c, line 5.
warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?
No symbol "i" in current context.

**We hit en error here because the breakpoint is installed behind the loop.**

$ clang -std=c99 -g3 -O0 test.c -o test; gdb -ex 'dprintf 5,"i: %i\n", i' -ex
run -batch ./test
warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?
i: 0
i: 1
i: 2
i: 3
i: 4
i: 5
i: 6
i: 7
i: 8
i: 9
[Inferior 1 (process 13274) exited normally]

More information:

$ gcc -Wall -Werror -std=c99 -g3 -O0 test.c -o test; gdb -ex 'disas/m main' -ba
tch ./test  
Dump of assembler code for function main:
3   {
   0x004004ad <+0>: push   rbp
   0x004004ae <+1>: movrbp,rsp

4   for (int i = 0; i < 10; ++i) {
   0x004004b1 <+4>: movDWORD PTR [rbp-0x4],0x0
   0x004004b8 <+11>:jmp0x4004be 
   0x004004ba <+13>:addDWORD PTR [rbp-0x4],0x1
   0x004004be <+17>:cmpDWORD PTR [rbp-0x4],0x9
   0x004004c2 <+21>:jle0x4004ba 

5
6   }
7   return 0;
   0x004004c4 <+23>:moveax,0x0

8   }
   0x004004c9 <+28>:poprbp
   0x004004ca <+29>:ret

End of assembler dump.

$ clang -Wall -Werror -std=c99 -g3 -O0 test.c -o test; gdb -ex 'disas/m main' -
batch ./test 
Dump of assembler code for function main:
3   {
   0x004004d0 <+0>: push   rbp
   0x004004d1 <+1>: movrbp,rsp
   0x004004d4 <+4>: movDWORD PTR [rbp-0x4],0x0

4   for (int i = 0; i < 10; ++i) {
   0x004004db <+11>:movDWORD PTR [rbp-0x8],0x0
   0x004004e2 <+18>:cmpDWORD PTR [rbp-0x8],0xa
   0x004004e9 <+25>:jge0x400504 
   0x004004f4 <+36>:moveax,DWORD PTR [rbp-0x8]
   0x004004f7 <+39>:addeax,0x1
   0x004004fc <+44>:movDWORD PTR [rbp-0x8],eax
   0x004004ff <+47>:jmp0x4004e2 
   0x00400504 <+52>:moveax,0x0

5
6   }
   0x004004ef <+31>:jmp0x4004f4 

7   return 0;
   0x00400509 <+57>:poprbp
   0x0040050a <+58>:ret

End of assembler dump.

So, jmp just after 6 line, allow us to breaking inside loop.

Versions:

gcc (Debian 4.8.2-16) 4.8.2
Debian clang version 3.4-2 (tags/RELEASE_34/final) (based on LLVM 3.4)
(just in case):
GNU gdb (GDB) 7.6.2 (Debian 7.6.2-1)

[Bug tree-optimization/60899] undef reference generated with -fdevirtualize-speculatively

[xinliangli at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60899

--- Comment #7 from davidxl  ---
(In reply to Paul Pluzhnikov from comment #6)
> Google ref: b/13453242

Verified that the proposed patch fixed the problem in b/1345242.

[Bug tree-optimization/60899] undef reference generated with -fdevirtualize-speculatively

[hubicka at ucw dot cz]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60899

--- Comment #8 from Jan Hubicka  ---
> Verified that the proposed patch fixed the problem in b/1345242.

Great, thanks! I still would preffer to see DECL_EXTERNAL bit on vtable that is
not emit in the current unit. But C++ visibility code is bit of mess, so if
Jason think it is impractical to arrange it, lets go with this patch.

[Bug sanitizer/59068] libsanitizer doesn't build on x86_64-unknown-linux-gnu with Linux 2.6.18

[y.gribov at samsung dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59068

Yury Gribov  changed:

   What|Removed |Added

 CC||y.gribov at samsung dot com

--- Comment #3 from Yury Gribov  ---
(In reply to Kostya Serebryany from comment #1)
> From another discussion
> (http://gcc.gnu.org/ml/gcc-patches/2013-12/msg00174.html): 
> 
> I suggest to simply disable libsanitizer build on the older systems
> which is what happens de facto now.

Sounds like a simple check for minimum kernel version in libsanitizer configure
would do the trick. Can anyone suggest a reliable way to obtain version of
target kernel? We need something that would work all the way back to 2.x
kernels.

[Bug sanitizer/60892] GCC fails to build with Linux 2.6.21 headers.

[y.gribov at samsung dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60892

Yury Gribov  changed:

   What|Removed |Added

 CC||y.gribov at samsung dot com

--- Comment #1 from Yury Gribov  ---
Duplicate of bug 59068 ?