[Bug tree-optimization/61306] New: wrong code at -Os and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61306
Bug ID: 61306
Summary: wrong code at -Os and above on x86_64-linux-gnu
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The current gcc trunk miscompiles the following code on x86_64-linux at -Os and
above in both 32-bit and 64-bit modes.
This is a regression from 4.9.x.
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.10.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 4.10.0 20140524 (experimental) [trunk revision 210888] (GCC)
$
$ gcc-trunk -O1 small.c; a.out
$ gcc-4.9.0 -Os small.c; a.out
$
$ gcc-trunk -Os small.c
$ a.out
Aborted (core dumped)
$
---
short a = -1;
int b;
char c;
int
main ()
{
c = a;
b = a | c;
if (b != -1)
__builtin_abort ();
return 0;
}
[Bug c/61053] [4.9/4.10 Regression] _Alignas(long long) reduces alignment of long long
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61053 Hans-Peter Nilsson changed: What|Removed |Added CC||hp at gcc dot gnu.org --- Comment #5 from Hans-Peter Nilsson --- Aren't you missing a back-port to the 4.9 branch before this can be called "fixed" with a 4.9.1 milestone?
[Bug c++/61305] New: internal compiler error: in cp_tree_equal, at cp/tree.c:2371
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61305
Bug ID: 61305
Summary: internal compiler error: in cp_tree_equal, at
cp/tree.c:2371
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: john.lindgren at aol dot com
Created attachment 32849
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32849&action=edit
C++ source
Trying to compile the attached C++ file gives an internal compiler error with
GCC 4.6.3 on Ubuntu 12.04 i386. On a newer x86_64 system running Arch Linux,
GCC 4.9.0 compiles the same file without any problem, so it's possible that the
bug has already been fixed and needs to be backported to 4.6.x.
$ g++ -c -std=gnu++0x preferences.cc
preferences.cc:236:21: in constexpr expansion of ‘WidgetSpin(((const
char*)("Amplify all files:")), {(ValueType)1u, 0u, 0u, ((const
char*)"replay_gain_preamp")}, {-1.5e+1, 1.5e+1,
1.5551115123125782702118158340454e-1, ((const char*)("dB"))},
(WidgetIsChild)1u)’
preferences.cc:241:1: in constexpr expansion of
‘PreferencesWidget((WidgetType)4u, label, cfg.WidgetConfig::value,
cfg.WidgetConfig::callback, 0u, (child == (WidgetIsChild)1u),
cfg.WidgetConfig::type, cfg.WidgetConfig::section, cfg.WidgetConfig::name,
WidgetVariant(spin))’
preferences.cc:241:1: internal compiler error: in cp_tree_equal, at
cp/tree.c:2371
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
Preprocessed source stored into /tmp/ccBkkPXe.out file, please attach this to
your bugreport.
$ gcc --version
gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3
Copyright (C) 2011 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.
$ uname -a
Linux VirtualUbuntu 3.2.0-61-generic-pae #93-Ubuntu SMP Fri May 2 21:46:08 UTC
2014 i686 i686 i386 GNU/Linux
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #211 from Jan Hubicka --- Elfhack is rather sensitive to LTO, but it works for me, so this seems like binutils issue or some elfhack change that happened recently. I wrote instructions for building firefox with LTO here http://hubicka.blogspot.ca/2014/04/linktime-optimization-in-gcc-2-firefox.html Here I am attaching -ftime-report after the symtab hashtable was removed Execution times (seconds) phase setup : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.02 ( 0%) wall 1536 kB ( 0%) ggc phase opt and generate : 54.29 (58%) usr 1.28 (18%) sys 55.58 (50%) wall 720779 kB (18%) ggc phase stream in : 33.54 (36%) usr 1.84 (26%) sys 35.39 (32%) wall 3389310 kB (82%) ggc phase stream out: 6.00 ( 6%) usr 4.02 (56%) sys 19.99 (18%) wall 0 kB ( 0%) ggc garbage collection : 1.86 ( 2%) usr 0.00 ( 0%) sys 1.86 ( 2%) wall 0 kB ( 0%) ggc callgraph optimization : 0.23 ( 0%) usr 0.00 ( 0%) sys 0.24 ( 0%) wall 9 kB ( 0%) ggc ipa dead code removal : 5.70 ( 6%) usr 0.18 ( 3%) sys 6.15 ( 6%) wall 92 kB ( 0%) ggc ipa inheritance graph : 0.09 ( 0%) usr 0.00 ( 0%) sys 0.09 ( 0%) wall 883 kB ( 0%) ggc ipa virtual call target : 5.58 ( 6%) usr 0.06 ( 1%) sys 5.32 ( 5%) wall 0 kB ( 0%) ggc ipa devirtualization: 0.13 ( 0%) usr 0.00 ( 0%) sys 0.20 ( 0%) wall 9201 kB ( 0%) ggc ipa cp : 2.34 ( 2%) usr 0.21 ( 3%) sys 2.55 ( 2%) wall 223628 kB ( 5%) ggc ipa inlining heuristics : 26.97 (29%) usr 0.67 ( 9%) sys 27.66 (25%) wall 865791 kB (21%) ggc ipa comdats : 0.21 ( 0%) usr 0.00 ( 0%) sys 0.21 ( 0%) wall 0 kB ( 0%) ggc ipa lto gimple in : 0.07 ( 0%) usr 0.11 ( 2%) sys 0.21 ( 0%) wall 0 kB ( 0%) ggc ipa lto gimple out : 0.46 ( 0%) usr 0.19 ( 3%) sys 0.65 ( 1%) wall 0 kB ( 0%) ggc ipa lto decl in : 24.76 (26%) usr 1.28 (18%) sys 26.08 (23%) wall 2571773 kB (63%) ggc ipa lto decl out: 5.45 ( 6%) usr 0.28 ( 4%) sys 5.75 ( 5%) wall 0 kB ( 0%) ggc ipa lto cgraph I/O : 1.13 ( 1%) usr 0.24 ( 3%) sys 1.38 ( 1%) wall 414551 kB (10%) ggc ipa lto decl merge : 2.57 ( 3%) usr 0.01 ( 0%) sys 2.58 ( 2%) wall 8227 kB ( 0%) ggc ipa lto cgraph merge: 1.72 ( 2%) usr 0.00 ( 0%) sys 1.72 ( 2%) wall 12166 kB ( 0%) ggc whopr wpa : 1.04 ( 1%) usr 0.00 ( 0%) sys 1.04 ( 1%) wall 2 kB ( 0%) ggc whopr wpa I/O : 0.03 ( 0%) usr 3.55 (50%) sys 13.51 (12%) wall 0 kB ( 0%) ggc whopr partitioning : 4.97 ( 5%) usr 0.06 ( 1%) sys 5.02 ( 5%) wall 3738 kB ( 0%) ggc ipa reference : 3.62 ( 4%) usr 0.12 ( 2%) sys 3.75 ( 3%) wall 0 kB ( 0%) ggc ipa profile : 0.33 ( 0%) usr 0.01 ( 0%) sys 0.33 ( 0%) wall 0 kB ( 0%) ggc ipa pure const : 3.86 ( 4%) usr 0.01 ( 0%) sys 3.88 ( 3%) wall 0 kB ( 0%) ggc tree eh : 0.00 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 0 kB ( 0%) ggc tree CFG cleanup: 0.01 ( 0%) usr 0.00 ( 0%) sys 0.00 ( 0%) wall 0 kB ( 0%) ggc varconst: 0.05 ( 0%) usr 0.16 ( 2%) sys 0.13 ( 0%) wall 0 kB ( 0%) ggc unaccounted todo: 0.65 ( 1%) usr 0.00 ( 0%) sys 0.64 ( 1%) wall 0 kB ( 0%) ggc TOTAL : 93.84 7.14 110.98 4111626 kB there are some improvements in devirtualization performance that used quite few decl->symbol lookups. (about 20%)
[Bug rtl-optimization/61278] ICE with LTO (lto-wrapper failed) on x86_64-linux-gnu in 64-bit mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61278
--- Comment #3 from Zhendong Su ---
Here is another (somewhat simpler) test case that points to the same issue:
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.10.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 4.10.0 20140524 (experimental) [trunk revision 210885] (GCC)
$
$ gcc-trunk -O1 -c small.c
small.c: In function ‘fn2’:
small.c:20:1: internal compiler error: Segmentation fault
}
^
0x989def crash_signal
../../gcc-trunk/gcc/toplev.c:337
0x5d4fa0 bitmap_clear
../../gcc-trunk/gcc/bitmap.c:311
0x5d4fa0 bitmap_copy(bitmap_head*, bitmap_head const*)
../../gcc-trunk/gcc/bitmap.c:534
0x961bf7 move_insn_for_shrink_wrap
../../gcc-trunk/gcc/shrink-wrap.c:209
0x961bf7 prepare_shrink_wrap(basic_block_def*)
../../gcc-trunk/gcc/shrink-wrap.c:337
0x961feb try_shrink_wrapping(edge_def**, edge_def*, bitmap_head*, rtx_def*)
../../gcc-trunk/gcc/shrink-wrap.c:463
0x78bbf1 thread_prologue_and_epilogue_insns
../../gcc-trunk/gcc/function.c:5661
0x78bbf1 rest_of_handle_thread_prologue_and_epilogue
../../gcc-trunk/gcc/function.c:6213
0x78bbf1 execute
../../gcc-trunk/gcc/function.c:6252
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$
---
int a, b, c, *d, e, f, g, h;
int
fn1 ()
{
return a - b;
}
int *
fn2 (int *p)
{
h = c;
for (e = 0; e == 0; e = fn1 () + 1)
for (; f; f++)
if (c)
g = 0;
else
return d = p;
return 0;
}
[Bug libfortran/61173] [4.9/4.10 Regression] Erroneous "end of file" with internal read
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61173 --- Comment #6 from Jerry DeLisle --- Author: jvdelisle Date: Sat May 24 19:30:38 2014 New Revision: 210899 URL: http://gcc.gnu.org/viewcvs?rev=210899&root=gcc&view=rev Log: 2014-05-24 Jerry DeLisle PR libfortran/61173 gfortran.dg/arrayio_14.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/arrayio_14.f90 Modified: trunk/gcc/testsuite/ChangeLog
[Bug middle-end/57625] internal compiler error: seg fault when building gcc 4.7.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57625 --- Comment #5 from Mikael Pettersson --- The failure of gcc-4.8.0 and later to build gcc-4.7.2 w/ --disable-bootstrap started with r186592. I'm getting loads of errors from glibc stating that malloc detects memory corruption in cc1.
[Bug libfortran/61173] [4.9/4.10 Regression] Erroneous "end of file" with internal read
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61173 --- Comment #5 from Jerry DeLisle --- Author: jvdelisle Date: Sat May 24 19:26:02 2014 New Revision: 210898 URL: http://gcc.gnu.org/viewcvs?rev=210898&root=gcc&view=rev Log: 2014-05-23 Jerry DeLisle PR libfortran/61173 * io/list_read.c (eat_spaces): If the next character pointed to is a space, don't seek, must be at the end. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/list_read.c
[Bug fortran/59612] [F03] iso_fortran_env segfaults with -fdump-fortran-original
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59612 Dominique d'Humieres changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from Dominique d'Humieres --- > Should not this PR be closed as FIXED? No answer since more than three months. I rechecked today that the test in comment 0 does not ICE with revisions from 4.7.4 up to trunk (4.10) r210889. Closing as FIXED.
[Bug middle-end/61141] [4.10 Regression] c-common.c:1502:1: ICE: in reset_insn_used_flags, at emit-rtl.c:2677
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61141 --- Comment #6 from John David Anglin --- I added a gcc_assert in pa_output_call to detect branch sequences with a deleted insn. I didn't trigger. The reason the submitted patch works is the RTL "cleanup" that deletes insns in delay slots is being run after assembly output has been generated. See backtrace: Breakpoint 2, reset_all_used_flags () at ../../gcc/gcc/emit-rtl.c:2723 2723if (INSN_P (insn)) (gdb) bt #0 reset_all_used_flags () at ../../gcc/gcc/emit-rtl.c:2723 #1 0x40771df0 in verify_rtl_sharing () at ../../gcc/gcc/emit-rtl.c:2752 #2 0x40bc3b58 in execute_function_todo (fn=0x83fffdca2d20, data=0x40) at ../../gcc/gcc/passes.c:1794 #3 0x40bc2090 in do_per_function (callback=0x40357710, data=0x40) at ../../gcc/gcc/passes.c:1504 #4 0x40bc3e0c in execute_todo (flags=64) at ../../gcc/gcc/passes.c:1834 #5 0x40bc55d8 in execute_one_pass (pass=0x80010037b7b8) at ../../gcc/gcc/passes.c:2194 #6 0x40bc55d8 in execute_one_pass (pass=0x80010037b7b8) at ../../gcc/gcc/passes.c:2194 Backtrace stopped: previous frame identical to this frame (corrupt stack?) (gdb) p debug_rtx (insn) (note:TI 238 239 302 NOTE_INSN_DELETED)
[Bug fortran/55789] [4.7 Regression] Needless realloc with array constructor.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55789 --- Comment #18 from dominiq at gcc dot gnu.org --- Author: dominiq Date: Sat May 24 15:45:02 2014 New Revision: 210894 URL: http://gcc.gnu.org/viewcvs?rev=210894&root=gcc&view=rev Log: 2014-05-24 Dominique d'Humieres Backport r195492 and r195815 2013-01-27 Paul Thomas PR fortran/55789 * gfortran.dg/associate_14.f90: New test. PR fortran/56047 * gfortran.dg/associate_13.f90: New test. 2013-02-06 Paul Thomas PR fortran/55789 * gfortran.dg/array_constructor_41.f90: New test. Added: branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/array_constructor_41.f90 branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/associate_13.f90 branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/associate_14.f90 Modified: branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
[Bug fortran/56047] [4.8 Regression] [OOP] ICE in in gfc_conv_expr_op
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56047 --- Comment #21 from dominiq at gcc dot gnu.org --- Author: dominiq Date: Sat May 24 15:45:02 2014 New Revision: 210894 URL: http://gcc.gnu.org/viewcvs?rev=210894&root=gcc&view=rev Log: 2014-05-24 Dominique d'Humieres Backport r195492 and r195815 2013-01-27 Paul Thomas PR fortran/55789 * gfortran.dg/associate_14.f90: New test. PR fortran/56047 * gfortran.dg/associate_13.f90: New test. 2013-02-06 Paul Thomas PR fortran/55789 * gfortran.dg/array_constructor_41.f90: New test. Added: branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/array_constructor_41.f90 branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/associate_13.f90 branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/associate_14.f90 Modified: branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
[Bug other/61300] powerpc64le miscompile with K&R-style function definition at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61300 David Edelsohn changed: What|Removed |Added Target||powerpc64le-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2014-05-24 CC||dje at gcc dot gnu.org Ever confirmed|0 |1
[Bug fortran/55789] [4.7 Regression] Needless realloc with array constructor.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55789 --- Comment #17 from dominiq at gcc dot gnu.org --- Author: dominiq Date: Sat May 24 15:36:14 2014 New Revision: 210893 URL: http://gcc.gnu.org/viewcvs?rev=210893&root=gcc&view=rev Log: 2014-05-24 Dominique d'Humieres Backport r195492 and r195815 2013-01-27 Paul Thomas PR fortran/55789 PR fortran/56047 * gfortran.h : Add associate_var to symbol_attr. * resolve.c (resolve_assoc_var): Set associate_var attribute. If the target class_ok is set, set it for the associate variable. * check.c (allocatable_check): Associate variables should not have the allocatable attribute even if their symbols do. * class.c (gfc_build_class_symbol): Symbols with associate_var set will always have a good class container. 2013-02-06 Paul Thomas PR fortran/55789 * trans-array.c (trans_array_constructor): Remove condition 'dynamic' = true if the loop ubound is a VAR_DECL. Modified: branches/gcc-4_7-branch/gcc/fortran/ChangeLog branches/gcc-4_7-branch/gcc/fortran/check.c branches/gcc-4_7-branch/gcc/fortran/class.c branches/gcc-4_7-branch/gcc/fortran/gfortran.h branches/gcc-4_7-branch/gcc/fortran/resolve.c branches/gcc-4_7-branch/gcc/fortran/trans-array.c
[Bug fortran/56047] [4.8 Regression] [OOP] ICE in in gfc_conv_expr_op
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56047 --- Comment #20 from dominiq at gcc dot gnu.org --- Author: dominiq Date: Sat May 24 15:36:14 2014 New Revision: 210893 URL: http://gcc.gnu.org/viewcvs?rev=210893&root=gcc&view=rev Log: 2014-05-24 Dominique d'Humieres Backport r195492 and r195815 2013-01-27 Paul Thomas PR fortran/55789 PR fortran/56047 * gfortran.h : Add associate_var to symbol_attr. * resolve.c (resolve_assoc_var): Set associate_var attribute. If the target class_ok is set, set it for the associate variable. * check.c (allocatable_check): Associate variables should not have the allocatable attribute even if their symbols do. * class.c (gfc_build_class_symbol): Symbols with associate_var set will always have a good class container. 2013-02-06 Paul Thomas PR fortran/55789 * trans-array.c (trans_array_constructor): Remove condition 'dynamic' = true if the loop ubound is a VAR_DECL. Modified: branches/gcc-4_7-branch/gcc/fortran/ChangeLog branches/gcc-4_7-branch/gcc/fortran/check.c branches/gcc-4_7-branch/gcc/fortran/class.c branches/gcc-4_7-branch/gcc/fortran/gfortran.h branches/gcc-4_7-branch/gcc/fortran/resolve.c branches/gcc-4_7-branch/gcc/fortran/trans-array.c
[Bug go/61303] gccgo: segfault, regression since 4.8.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61303
--- Comment #1 from Maciej Bliziński ---
I did some more testing. Running it under truss makes the binary work:
> truss -f -o /tmp/crashtest.truss bin/crashtest
2014/05/24 17:15:34 Making a request to
http://buildfarm.opencsw.org/pkgdb/rest/catalogs/unstable/sparc/SunOS5.10/for-generation/as-dicts/
2014/05/24 17:15:44 Retrieved {unstable sparc SunOS5.10} with 3704 packages
2014/05/24 17:15:44 Writing {unstable sparc SunOS5.10} to catalog
2014/05/24 17:15:44 Catalog index written successfully
Running the same binary without truss makes it crash:
> bin/crashtest
2014/05/24 17:16:03 Making a request to
http://buildfarm.opencsw.org/pkgdb/rest/catalogs/unstable/sparc/SunOS5.10/for-generation/as-dicts/
[hangs and eventually segfaults]
Running the same binary under gdb makes it segfault immediately:
> gdb bin/crashtest
GNU gdb (GDB) 7.7
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "sparc-sun-solaris2.10".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
[Bug tree-optimization/61304] New: Missed vectorization: control flow in loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61304
Bug ID: 61304
Summary: Missed vectorization: control flow in loop
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target: x86_64-linux-gnu
(taken from a stackoverflow question about a bug in llvm, replace -1 with -2 if
you want to test llvm and avoid the bug)
gcc -O3 fails to vectorize the following program because it sees control flow
in the loop. If I move i++ before the "if", which becomes i == 0, we still fail
to vectorize because we get confused about the number of iterations. Finally,
if I stop at i == 2048, we do vectorize, but the generated code could do with
some improvements (that would be for a different PR though).
#include
#include
int main()
{
uint32_t i = 0;
uint32_t count = 0;
while (1)
{
float n;
memcpy(&n, &i, sizeof(float));
if(n >= 0.0f && n <= 1.0f)
count++;
if (i == -1)
break;
i++;
}
return count;
}
[Bug go/61303] New: gccgo: segfault, regression since 4.8.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61303
Bug ID: 61303
Summary: gccgo: segfault, regression since 4.8.2
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: go
Assignee: ian at airs dot com
Reporter: maciej at opencsw dot org
CC: cmang at google dot com
> ./bin/gen-catalog-index --help
Usage of ./bin/gen-catalog-index:
-arch="sparc": { sparc | i386 }
-catalog-release="unstable": e.g. unstable, bratislava, kiel, dublin
-os-release="SunOS5.10": e.g. SunOS5.10
-output="catalog": The name of the file to generate.
-pkgdb-url="http://buildfarm.opencsw.org/pkgdb/rest": Web address of the
pkgdb app.
> ./bin/gen-catalog-index -output foo
2014/05/24 13:50:23 Making a request to
http://buildfarm.opencsw.org/pkgdb/rest/catalogs/unstable/sparc/SunOS5.10/for-generation/as-dicts/
2014/05/24 13:50:32 Retrieved {unstable sparc SunOS5.10} with 3704 packages
2014/05/24 13:50:32 Writing {unstable sparc SunOS5.10} to foo
2014/05/24 13:50:32 Catalog index written successfully
> cp ./bin/gen-catalog-index{,.bak}
> rm ./bin/gen-catalog-index
> make bin/gen-catalog-index
gccgo -g -o bin/gen-catalog-index src/gen-catalog-index/gen-catalog-index.o
src/opencsw/diskformat/diskformat.o
> rm foo
> ./bin/gen-catalog-index -output foo
2014/05/24 13:51:05 Making a request to
http://buildfarm.opencsw.org/pkgdb/rest/catalogs/unstable/sparc/SunOS5.10/for-generation/as-dicts/
Segmentation Fault (core dumped)
> dbx - core
Corefile specified executable:
"/home/raos/opencsw/.buildsys/v2/go/bin/gen-catalog-index"
For information about new features see `help changes'
To remove this message, put `dbxenv suppress_startup_message 7.6' in your
.dbxrc
Reading gen-catalog-index
dbx: warning: core object name "gen-catalog-ind" matches
object name "gen-catalog-index" within the limit of 14. assuming they match
core file header read successfully
Reading ld.so.1
Reading libgo.so.5.0.0
dbx: warning: unknown location expression code (0x9e)
Reading libm.so.2
Reading libgcc_s.so.1
Reading libc.so.1
Reading libpthread.so.1
Reading libsocket.so.1
Reading libnsl.so.1
Reading librt.so.1
Reading libaio.so.1
Reading libmd.so.1
Reading libc_psr.so.1
t@3 (l@3) terminated by signal SEGV (no mapping at the fault address)
0xfe730e98: _memcpy+0x04bc: st %o4, [%o0]
(dbx) where
current thread: t@3
=>[1] _memcpy(0x0, 0xff0d1f6c, 0x61, 0x60100, 0x30, 0x0), at 0xfe730e98
[2] runtime_netpoll(0x1, 0x80, 0xce1e1e3b, 0x0, 0xff0d1ff0, 0x180), at
0xfeb8e004
[3] schedule(0x1, 0xfef32f6c, 0x0, 0x0, 0xff0f3d28, 0xff0f5800), at
0xfeb92e90
[4] runtime_mstart(0xde811800, 0xce1e2000, 0x0, 0xce310a38, 0x4,
0xce310a38), at 0xfeb93130
(dbx) threads
t@1 a l@1 ?() sleep on 0x3f3c0 in __lwp_park()
t@2 a l@2 ?() sleep on 0x3f3f8 in __lwp_park()
o>t@3 a l@3 ?() signal SIGSEGV in _memcpy()
t@4 a l@4 ?() sleep on 0x3f810 in __lwp_park()
(dbx) quit
This is a regression since gcc-4.8.2. The same go code works when compiled with
gccgo-4.8.2 and fails when compiled with gccgo-4.9.0.
[Bug libfortran/61173] [4.9/4.10 Regression] Erroneous "end of file" with internal read
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61173 --- Comment #4 from Jerry DeLisle --- Patch here: https://gcc.gnu.org/ml/gcc-patches/2014-05/msg02065.html
[Bug fortran/61297] have an -Wunused-type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61297 Dominique d'Humieres changed: What|Removed |Added Keywords||diagnostic Priority|P3 |P5 Status|UNCONFIRMED |NEW Last reconfirmed||2014-05-24 Ever confirmed|0 |1 Severity|normal |enhancement --- Comment #1 from Dominique d'Humieres --- This is the 784th PR opened for gfortran/libgfortran. If you want diagnostic improvements, you should consider to provide the man power!
[Bug c++/61302] When returning nullptr in a comma operator, side effects are lost.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61302 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Jonathan Wakely --- I think this is PR 54170 *** This bug has been marked as a duplicate of bug 54170 ***
[Bug c++/54170] Call to lambda elided
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54170 Jonathan Wakely changed: What|Removed |Added CC||fox at ucw dot cz --- Comment #16 from Jonathan Wakely --- *** Bug 61302 has been marked as a duplicate of this bug. ***
[Bug libstdc++/60793] Add target *-*-dragonfly* to dg-options on 172 libstdc++ tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60793 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #14 from Jonathan Wakely --- Before: https://gcc.gnu.org/ml/gcc-testresults/2014-05/msg01994.html After: https://gcc.gnu.org/ml/gcc-testresults/2014-05/msg02139.html
[Bug c++/61302] New: When returning nullptr in a comma operator, side effects are lost.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61302
Bug ID: 61302
Summary: When returning nullptr in a comma operator, side
effects are lost.
Product: gcc
Version: 4.7.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: fox at ucw dot cz
Consider the following code:
#include
void* test(void) {
return printf("Hello world.\n"), nullptr;
}
int main(void) {
return test() ? 0 : 1;
}
When compiled with g++-4.7.3, no "Hello world.\n" is printed.
The g++-4.8.1 works fine.
I though this would be connected to #52988, but it is not,
the attachment 27157 of #52988 works fine in g++-4.7.3.
[Bug tree-optimization/61301] missed optimization of move if vector passed by reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61301 --- Comment #2 from vincenzo Innocente --- > At least when shuffle2 is inlined it is likely to become like shuffle1... not sure for the case of a struct such as foo (unless the instance of foo itself in on the stack in the same context)
[Bug tree-optimization/61301] missed optimization of move if vector passed by reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61301 --- Comment #1 from Marc Glisse --- forwprop recognizes a constructor of bit_field_ref and turns it into a vec_perm_expr, but it can't handle a constructor of mem_ref (that requires looking for clobbers etc, not a job for forwprop). SLP sees the mem_ref properly but says it didn't find any opportunity. I doubt bswap handles this kind of thing. At least when shuffle2 is inlined it is likely to become like shuffle1...
[Bug tree-optimization/61299] [4.9/4.10 Regression] Performance regression for the SIMD rotate operation with GCC vector extensions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61299 --- Comment #3 from Siarhei Siamashka --- (In reply to Marc Glisse from comment #2) > That's PR 57233 I believe. Oh, sorry for the duplicate. Don't know how I missed it when searching for similar bugs.
[Bug tree-optimization/61299] [4.9/4.10 Regression] Performance regression for the SIMD rotate operation with GCC vector extensions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61299 --- Comment #2 from Marc Glisse --- That's PR 57233 I believe.
[Bug tree-optimization/61301] New: missed optimization of move if vector passed by reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61301
Bug ID: 61301
Summary: missed optimization of move if vector passed by
reference
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: vincenzo.innocente at cern dot ch
in the following test shuffle2 generates not optimized moves.
the other two are ok.
the problem occurs in real life when the vector is a data member of a class
and the function is a method, as in "foo"
typedef float __attribute__( ( vector_size( 16 ) ) ) float32x4_t;
typedef int __attribute__( ( vector_size( 16 ) ) ) int32x4_t;
float32x4_t shuffle1(float32x4_t x) {
return float32x4_t{x[1],x[0],x[3],x[2]};
}
float32x4_t shuffle2(float32x4_t const & x) {
return float32x4_t{x[1],x[0],x[3],x[2]};
}
float32x4_t shuffle3(float32x4_t const & x) {
return __builtin_shuffle(x,int32x4_t{1,0,3,2});
}
struct foo {
float32x4_t x;
float32x4_t shuffle2() const;
float32x4_t shuffle3() const;
};
float32x4_t foo::shuffle2() const {
return float32x4_t{x[1],x[0],x[3],x[2]};
}
float32x4_t foo::shuffle3() const {
return __builtin_shuffle(x,int32x4_t{1,0,3,2});
}
compiled with
c++ -std=c++11 -Ofast -march=nehalem -S shuffle.cc; cat shuffle.s
generates:
__Z8shuffle1U8__vectorf:
LFB0:
shufps$177, %xmm0, %xmm0
ret
__Z8shuffle2RKU8__vectorf:
LFB1:
movss12(%rdi), %xmm1
insertps$0x10, 8(%rdi), %xmm1
movss4(%rdi), %xmm0
insertps$0x10, (%rdi), %xmm0
movlhps%xmm1, %xmm0
ret
__Z8shuffle3RKU8__vectorf:
LFB2:
movaps(%rdi), %xmm0
shufps$177, %xmm0, %xmm0
ret
[Bug tree-optimization/61299] [4.9/4.10 Regression] Performance regression for the SIMD rotate operation with GCC vector extensions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61299 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-05-24 CC||glisse at gcc dot gnu.org, ||jakub at gcc dot gnu.org Target Milestone|--- |4.9.1 Summary|[4.9 Regression]|[4.9/4.10 Regression] |Performance regression for |Performance regression for |the SIMD rotate operation |the SIMD rotate operation |with GCC vector extensions |with GCC vector extensions Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r198772. We now recognize it as vector rotate by fold-const (though, at gimple level r198769 still doesn't handle vector types, maybe it should), but if there is no corresponding vector compare, guess tree-vect-generic.c should transform it back to shifts.
[Bug c/61271] 10 * possible coding error with logical not (!)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61271 --- Comment #8 from Andrew Pinski --- (In reply to Manuel López-Ibáñez from comment #5) > I'm almost tempted to check svn blame to see who wrote these... a fair acto > of contrition would be to implement the warning for GCC. ;-) We ran into this before (see bug 49474) and I filed bug 49706 for the warning.
[Bug c/61271] 10 * possible coding error with logical not (!)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61271 --- Comment #7 from Uroš Bizjak --- (In reply to David Binderman from comment #0) > ../../src/trunk/gcc/config/i386/i386.c:37905:10: warning: logical not is > only applied to the left hand side of this comparison > [-Wlogical-not-parentheses] > > Source code is > >|| (!GET_CODE (x) != LABEL_REF > > Confusing with the double negative. Maybe > >|| (GET_CODE (x) == LABEL_REF > > was intended. Actually, this is a bypass for %rip relative addresses. --cut here-- Index: i386.c === --- i386.c (revision 210889) +++ i386.c (working copy) @@ -37904,7 +37904,7 @@ *total = 2; else if (flag_pic && SYMBOLIC_CONST (x) && (!TARGET_64BIT - || (!GET_CODE (x) != LABEL_REF + || (GET_CODE (x) != LABEL_REF && (GET_CODE (x) != SYMBOL_REF || !SYMBOL_REF_LOCAL_P (x) *total = 1; --cut here-- or in a more human-readable form: else if (flag_pic && SYMBOLIC_CONST (x) && !(TARGET_64BIT && (GET_CODE (x) == LABEL_REF || (GET_CODE (x) == SYMBOL_REF && SYMBOL_REF_LOCAL_P (x) *total = 1;
[Bug target/61249] _mm_frcz_ss, _mm_frcz_sd: __builtin_ia32_vfrczss, __builtin_ia32_vfrczsd require 2 arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61249 Uroš Bizjak changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-05-24 Target Milestone|--- |4.8.4 Ever confirmed|0 |1 --- Comment #6 from Uroš Bizjak --- (In reply to Michael Tautschnig from comment #5) > Created attachment 32843 [details] > Update documentation Thank you, the patch is OK. Please provide the ChangeLog entry and post the patch to gcc-patches@ mailing list, as outlined in [1]. I'll take care to committing the patch to SVN repository. [1] https://gcc.gnu.org/contribute.html
