[Bug inline-asm/88559] New: error: Stack Pointer register clobbered by '%rsp' in 'asm'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88559
Bug ID: 88559
Summary: error: Stack Pointer register clobbered by '%rsp' in
'asm'
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: inline-asm
Assignee: unassigned at gcc dot gnu.org
Reporter: jamrial at gmail dot com
Target Milestone: ---
Created attachment 45265
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45265&action=edit
Failing pre processed output
[jamrial@ArchVM ~]$ /usr/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --enable-libmpx --with-system-zlib --with-isl
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu
--disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object
--enable-linker-build-id --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu
--enable-gnu-indirect-function --enable-multilib --disable-werror
--enable-checking=release --enable-default-pie --enable-default-ssp
--enable-cet=auto
Thread model: posix
gcc version 8.2.1 20181127 (GCC)
[jamrial@ArchVM ~]$ /usr/bin/gcc -std=c11 -fPIC -pthread -g -O3 -c -o
postproc.o postproc.i
/---/
[jamrial@ArchVM ~]$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/lib/gcc/x86_64-pc-linux-gnu/9.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /home/jamrial/gcc-svn/configure --prefix=/usr/local
--libdir=/usr/local/lib --libexecdir=/usr/local/lib
--mandir=/usr/local/share/man --infodir=/usr/local/share/info
--enable-languages=c,c++ --enable-shared --enable-threads=posix --enable-libmpx
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-clocale=gnu --disable-libstdcxx-pch --disable-libssp
--enable-gnu-unique-object --enable-linker-build-id --enable-lto
--enable-plugin --enable-install-libiberty --with-linker-hash-style=gnu
--enable-gnu-indirect-function --disable-multilib --disable-bootstrap
--disable-werror --enable-default-pie --enable-default-ssp
Thread model: posix
gcc version 9.0.0 20181220 (experimental) (GCC)
[jamrial@ArchVM ~]$ gcc -std=c11 -fPIC -pthread -g -O3 -c -o postproc.o
postproc.i
In file included from src/libpostproc/postprocess.c:538:
src/libpostproc/postprocess_template.c: In function 'dering_MMX2':
src/libpostproc/postprocess_template.c:1097:5: error: Stack Pointer register
clobbered by '%rsp' in 'asm'
In file included from src/libpostproc/postprocess.c:540:
src/libpostproc/postprocess_template.c: In function 'dering_3DNow':
src/libpostproc/postprocess_template.c:1097:5: error: Stack Pointer register
clobbered by '%rsp' in 'asm'
/---/
This regression was introduced by a change committed between Dec 10 and Dec 17.
[Bug inline-asm/88559] error: Stack Pointer register clobbered by '%rsp' in 'asm'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88559 --- Comment #3 from James Almer --- This code has compiled and the resulting assembly worked without issues for like a dozen major GCC releases, and now it's suddenly invalid?
[Bug inline-asm/88559] error: Stack Pointer register clobbered by '%rsp' in 'asm'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88559 --- Comment #4 from James Almer --- To expand, as i mentioned and showed in the OP this code has compiled without issues up to some point between December 10 and December 17 with gcc trunk. I'm not arguing about clobbering the stack pointer being correct or not, I'm wondering if this a valid error for the code in question and not a bogus one product of a regression in gcc. Does the inline asm in the attached preprocessed output effectively try to clobber the stack pointer? And if so, why would it start erroring out now only after a recent gcc trunk commit if it was never meant to work? Has gcc been generating invalid assembly all this time?
[Bug tree-optimization/69726] New: Bogus warnings with -O3 -Wuninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69726 Bug ID: 69726 Summary: Bogus warnings with -O3 -Wuninitialized Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: jamrial at gmail dot com Target Milestone: --- Created attachment 37636 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37636&action=edit Test case [jamrial@ArchVM ~]$ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/local/lib/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /home/jamrial/gcc-svn/configure --prefix=/usr/local --libdir=/usr/local/lib --libexecdir=/usr/local/lib --mandir=/usr/local/share/man --infodir=/usr/local/share/info --enable-languages=c,c++,lto --enable-shared --enable-threads=posix --enable-libmpx --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object --enable-linker-build-id --enable-lto --enable-plugin --enable-install-libiberty --with-linker-hash-style=gnu --enable-gnu-indirect-function --disable-multilib --disable-bootstrap --disable-werror Thread model: posix gcc version 6.0.0 20160207 (experimental) (GCC) [jamrial@ArchVM ~]$ gcc -Wuninitialized -O3 -c bink_idct.c bink_idct.c: In function ‘bink_idct_put_c’: bink_idct.c:57:9: warning: ‘*((void *)&temp+224)’ is used uninitialized in this function [-Wuninitialized] int temp[64]; ^~~~ bink_idct.c:57:9: warning: ‘*((void *)&temp+192)’ is used uninitialized in this function [-Wuninitialized] bink_idct.c:57:9: warning: ‘*((void *)&temp+160)’ is used uninitialized in this function [-Wuninitialized] bink_idct.c:57:9: warning: ‘*((void *)&temp+128)’ is used uninitialized in this function [-Wuninitialized] bink_idct.c:57:9: warning: ‘*((void *)&temp+96)’ is used uninitialized in this function [-Wuninitialized] bink_idct.c:57:9: warning: ‘*((void *)&temp+64)’ is used uninitialized in this function [-Wuninitialized] bink_idct.c:57:9: warning: ‘*((void *)&temp+32)’ is used uninitialized in this function [-Wuninitialized] bink_idct.c:57:9: warning: ‘temp’ is used uninitialized in this function [-Wuninitialized] This doesn't happen with -fno-tree-vectorize or any optimization level below -O3. gcc 5.3 is unaffected. ffmpeg's test suite makes use of all these functions as you can see here http://coverage.ffmpeg.org/src/libavcodec/binkdsp.c.gcov.html and gcc 5.3 ubsan is happy with it as seen here http://fate.ffmpeg.org/report.cgi?time=20160209015611&slot=x86_64-archlinux-gcc-ubsan so they are most certainly bogus.
[Bug c++/70768] New: Increased compilation time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70768 Bug ID: 70768 Summary: Increased compilation time Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jamrial at gmail dot com Target Milestone: --- Created attachment 38332 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38332&action=edit Preprocessed output The attached preprocessed output (Created from the source using GCC 5, 6 and 7 for the purpose of this ticket) takes almost twice as long to compile using GCC 6.0.1 RC and especially GCC 7.0 compared to GCC 5.3 on a linux x86_64 machine with 2gb of RAM. > GCC 5.3.0, ArchLinux package [jamrial@ArchVM ~]$ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/5.3.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /build/gcc/src/gcc-5-20160209/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared --enable-threads=posix --enable-libmpx --with-system-zlib --with-isl --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object --enable-linker-build-id --enable-lto --enable-plugin --enable-install-libiberty --with-linker-hash-style=gnu --enable-gnu-indirect-function --disable-multilib --disable-werror --enable-checking=release Thread model: posix gcc version 5.3.0 (GCC) [jamrial@ArchVM ~]$ time c++ -ftemplate-backtrace-limit=0 -Wall -Wextra -pedantic -Werror -pedantic-errors -Wno-error=deprecated-declarations -Wno-missing-field-initializers -Wno-unused-parameter -march=haswell -Ofast -g0 -std=gnu++14 -o transform_gcc5.o -c transform_gcc5.ii real1m13.380s user1m11.920s sys 0m0.793s [jamrial@ArchVM ~]$ time c++ -ftemplate-backtrace-limit=0 -Wall -Wextra -pedantic -Werror -pedantic-errors -Wno-error=deprecated-declarations -Wno-missing-field-initializers -Wno-unused-parameter -march=haswell -Ofast -g0 -std=gnu++14 -o transform_gcc6.o -c transform_gcc6.ii real1m32.820s user1m23.093s sys 0m1.457s [jamrial@ArchVM ~]$ time c++ -ftemplate-backtrace-limit=0 -Wall -Wextra -pedantic -Werror -pedantic-errors -Wno-error=deprecated-declarations -Wno-missing-field-initializers -Wno-unused-parameter -march=haswell -Ofast -g0 -std=gnu++14 -o transform_gcc7.o -c transform_gcc7.ii real1m31.705s user1m20.663s sys 0m1.490s > GCC 6.0.1 RC [jamrial@ArchVM ~]$ gcc-6 -v Using built-in specs. COLLECT_GCC=gcc-6 COLLECT_LTO_WRAPPER=/usr/local/lib/gcc/x86_64-pc-linux-gnu/6.0.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /home/jamrial/gcc-svn/configure --prefix=/usr/local --libdir=/usr/local/lib --libexecdir=/usr/local/lib --mandir=/usr/local/share/man --infodir=/usr/local/share/info --enable-languages=c,c++,lto --enable-shared --enable-threads=posix --enable-libmpx --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object --enable-linker-build-id --enable-lto --enable-plugin --enable-install-libiberty --with-linker-hash-style=gnu --enable-gnu-indirect-function --disable-multilib --disable-bootstrap --disable-werror Thread model: posix gcc version 6.0.1 20160415 (prerelease) (GCC) [jamrial@ArchVM ~]$ time c++-6 -ftemplate-backtrace-limit=0 -Wall -Wextra -pedantic -Werror -pedantic-errors -Wno-error=deprecated-declarations -Wno-missing-field-initializers -Wno-unused-parameter -march=haswell -Ofast -g0 -std=gnu++14 -o transform_gcc5.o -c transform_gcc5.ii real1m14.796s user1m13.520s sys 0m0.787s [jamrial@ArchVM ~]$ time c++-6 -ftemplate-backtrace-limit=0 -Wall -Wextra -pedantic -Werror -pedantic-errors -Wno-error=deprecated-declarations -Wno-missing-field-initializers -Wno-unused-parameter -march=haswell -Ofast -g0 -std=gnu++14 -o transform_gcc6.o -c transform_gcc6.ii real2m29.020s user1m25.240s sys 0m6.537s [jamrial@ArchVM ~]$ time c++-6 -ftemplate-backtrace-limit=0 -Wall -Wextra -pedantic -Werror -pedantic-errors -Wno-error=deprecated-declarations -Wno-missing-field-initializers -Wno-unused-parameter -march=haswell -Ofast -g0 -std=gnu++14 -o transform_gcc7.o -c transform_gcc7.ii real2m27.268s user1m23.977s sys 0m7.167s > GCC 7.0 [jamrial@ArchVM ~]$ gcc-7 -v Using built-in specs. COLLECT_GCC=gcc-7 COLLECT_LTO_WRAPPER=/usr/local/lib/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /home/jamrial/gcc-svn/configure --prefix=/usr/local --libdir=/usr/local/lib --libexecdir=/usr/local/lib --mandir=/usr/local/share/man --infodir=/usr/local/share/info --enable-languages=c,c++,lto
[Bug c++/70768] Increased compilation time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70768 --- Comment #2 from James Almer --- (In reply to Markus Trippelsdorf from comment #1) > Well, you simply need more RAM to compile this testcase, because gcc-6 uses > slightly over 2GB peak, so your machine starts swapping. > On my machine (with 8GB RAM) gcc-6 is actually slightly faster. > > (For gcc-7 you need to configure it with --enable-checking=release to > compare timings.) Tried to assign more RAM to the vm and it indeed fixed the trashing and slowness with gcc-6 and newer. gcc-6/7 uses like 2.1GB of RAM to compile this file whereas gcc-5 uses only 1.6GB. Is this intended/expected, or can it be considered a memory hog?
[Bug tree-optimization/81744] New: ICE: verify_ssa failed, at tree-ssa.c:1186
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81744 Bug ID: 81744 Summary: ICE: verify_ssa failed, at tree-ssa.c:1186 Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: jamrial at gmail dot com Target Milestone: --- Created attachment 41942 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41942&action=edit Preprocessed output created with -freport-bug [jamrial@ArchVM ~]$ gcc -fno-math-errno -O3 -c ccV0zFt3.i src/libavfilter/af_compand.c: In function ‘config_output’: src/libavfilter/af_compand.c:328:12: error: definition in block 78 follows the use for SSA_NAME: _519 in statement: _126 = _519 + 4294967291; during GIMPLE pass: pcom src/libavfilter/af_compand.c:328:12: internal compiler error: verify_ssa failed 0xdb534b verify_ssa(bool, bool) /home/jamrial/gcc-svn/gcc/tree-ssa.c:1186 0xa99527 execute_function_todo /home/jamrial/gcc-svn/gcc/passes.c:1997 0xa9a442 execute_todo /home/jamrial/gcc-svn/gcc/passes.c:2044 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. [jamrial@ArchVM ~]$ gcc -fno-math-errno -fno-tree-vectorize -O3 -c ccV0zFt3.i src/libavfilter/af_compand.c: In function ‘config_output’: src/libavfilter/af_compand.c:328:12: error: definition in block 83 follows the use for SSA_NAME: _618 in statement: _611 = _618 + 4294967291; during GIMPLE pass: pcom src/libavfilter/af_compand.c:328:12: internal compiler error: verify_ssa failed 0xdb534b verify_ssa(bool, bool) /home/jamrial/gcc-svn/gcc/tree-ssa.c:1186 0xa99527 execute_function_todo /home/jamrial/gcc-svn/gcc/passes.c:1997 0xa9a442 execute_todo /home/jamrial/gcc-svn/gcc/passes.c:2044 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. Doesn't crash if i remove either -fno-math-errno or -O3. Adding -fno-tree-vectorize only changes the contents of the SSA_NAME error. This seems to be a regression introduced sometime during the past week.
[Bug c++/82080] New: ICE: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82080 Bug ID: 82080 Summary: ICE: Segmentation fault Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jamrial at gmail dot com Target Milestone: --- Created attachment 42105 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42105&action=edit Preprocessed output created with -freport-bug [jamrial@ArchVM ~]$ c++ -std=c++17 -c ccBqWFGo.ii /home/jamrial/range-v3/test/algorithm/partial_sort_copy.cpp: In lambda function: /home/jamrial/range-v3/test/algorithm/partial_sort_copy.cpp:50:44: internal compiler error: Segmentation fault int* e = output + std::min(N, M); ^ 0xd8570f crash_signal /home/jamrial/gcc-svn/gcc/toplev.c:341 0x62730f hash_table, tree_node*> >::hash_entry, xcallocator>::find_slot_with_hash(tree_node* const&, unsigned int, insert_option) /home/jamrial/gcc-svn/gcc/hash-table.h:874 0x6274ec hash_map, tree_node*> >::put(tree_node* const&, tree_node* const&) /home/jamrial/gcc-svn/gcc/hash-map.h:136 0x775c09 register_local_specialization(tree_node*, tree_node*) /home/jamrial/gcc-svn/gcc/cp/pt.c:1906 0x775c09 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) /home/jamrial/gcc-svn/gcc/cp/pt.c:18153 0x7750ba tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) /home/jamrial/gcc-svn/gcc/cp/pt.c:17549 0x77524c tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) /home/jamrial/gcc-svn/gcc/cp/pt.c:17070 0x624723 fold_non_dependent_expr(tree_node*) /home/jamrial/gcc-svn/gcc/cp/constexpr.c:4936 0x761b21 build_non_dependent_expr(tree_node*) /home/jamrial/gcc-svn/gcc/cp/pt.c:24955 0x81a82a build_x_binary_op(unsigned int, tree_code, tree_node*, tree_code, tree_node*, tree_code, tree_node**, int) /home/jamrial/gcc-svn/gcc/cp/typeck.c:3954 0x71bcee cp_parser_binary_expression /home/jamrial/gcc-svn/gcc/cp/parser.c:9271 0x71c474 cp_parser_assignment_expression /home/jamrial/gcc-svn/gcc/cp/parser.c:9404 0x71c8a7 cp_parser_constant_expression /home/jamrial/gcc-svn/gcc/cp/parser.c:9674 0x71d934 cp_parser_initializer_clause /home/jamrial/gcc-svn/gcc/cp/parser.c:21765 0x71ed2b cp_parser_initializer /home/jamrial/gcc-svn/gcc/cp/parser.c:21705 0x744710 cp_parser_init_declarator /home/jamrial/gcc-svn/gcc/cp/parser.c:19547 0x74bc66 cp_parser_simple_declaration /home/jamrial/gcc-svn/gcc/cp/parser.c:12980 0x74cbe5 cp_parser_block_declaration /home/jamrial/gcc-svn/gcc/cp/parser.c:12805 0x74d6e9 cp_parser_declaration_statement /home/jamrial/gcc-svn/gcc/cp/parser.c:12399 0x727253 cp_parser_statement /home/jamrial/gcc-svn/gcc/cp/parser.c:10877 [jamrial@ArchVM ~]$ c++ -v Using built-in specs. COLLECT_GCC=c++ COLLECT_LTO_WRAPPER=/usr/local/lib/gcc/x86_64-pc-linux-gnu/8.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /home/jamrial/gcc-svn/configure --prefix=/usr/local --libdir=/usr/local/lib --libexecdir=/usr/local/lib --mandir=/usr/local/share/man --infodir=/usr/local/share/info --enable-languages=c,c++,lto --enable-shared --enable-threads=posix --disable-bootstrap --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object --enable-linker-build-id --enable-lto --enable-plugin --enable-install-libiberty --with-linker-hash-style=gnu --enable-gnu-indirect-function --disable-multilib --disable-werror Thread model: posix gcc version 8.0.0 20170901 (experimental) (GCC)
[Bug c++/82080] ICE: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82080 James Almer changed: What|Removed |Added Attachment #42105|0 |1 is obsolete|| --- Comment #2 from James Almer --- Created attachment 42130 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42130&action=edit Preprocessed output created with -freport-bug This one should have no warning spam about missing builtins. The original preprocessed output was created with -march=native. Still ICEs for me on an x86_64 ArchLinux host.
[Bug c++/82080] ICE: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82080 --- Comment #4 from James Almer --- The regression seems to have started with revision r251433.
[Bug c++/80812] New: internal compiler error: in build_value_init_noctor, at cp/init.c:483
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80812
Bug ID: 80812
Summary: internal compiler error: in build_value_init_noctor,
at cp/init.c:483
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jamrial at gmail dot com
Target Milestone: ---
Created attachment 41379
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41379&action=edit
Preprocessed output created with -freport-bug
[jamrial@ArchVM tmp]$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/lib/gcc/x86_64-pc-linux-gnu/8.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /home/jamrial/gcc-svn/configure --prefix=/usr/local
--libdir=/usr/local/lib --libexecdir=/usr/local/lib
--mandir=/usr/local/share/man --infodir=/usr/local/share/info
--enable-languages=c,c++,lto --enable-shared --enable-threads=posix
--disable-bootstrap --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch
--disable-libssp --enable-gnu-unique-object --enable-linker-build-id
--enable-lto --enable-plugin --enable-install-libiberty
--with-linker-hash-style=gnu --enable-gnu-indirect-function --disable-multilib
--disable-werror
Thread model: posix
gcc version 8.0.0 20170518 (experimental) (GCC)
[jamrial@ArchVM tmp]$ c++ -std=c++17 -c cc6QFNbL.ii
In file included from /usr/local/include/c++/8.0.0/bits/move.h:54:0,
from /usr/local/include/c++/8.0.0/bits/stl_pair.h:59,
from /usr/local/include/c++/8.0.0/utility:70,
from /home/jamrial/range-v3/test/algorithm/replace.cpp:25:
/usr/local/include/c++/8.0.0/type_traits: In instantiation of ‘struct
std::is_constructible > [5]>’:
/home/jamrial/range-v3/include/range/v3/utility/concepts.hpp:504:42: required
by substitution of ‘template T
ranges::v3::detail::gcc_bugs_bugs_bugs(T) [with T = ]’
/home/jamrial/range-v3/include/range/v3/utility/concepts.hpp:111:55: required
by substitution of ‘template
meta::v1::apply, typename
meta::v1::detail::transform_::type,
meta::v1::bind_back, Ts ...> >,
void>::type> ranges::v3::detail::models_(Concept*) [with Ts = {std::pair, std::allocator >
> [5]}; Concept = ranges::v3::concepts::Constructible;
= ]’
/home/jamrial/range-v3/include/range/v3/utility/concepts.hpp:187:69: required
from ‘struct ranges::v3::concepts::models,
std::allocator > > [5]>’
/home/jamrial/range-v3/include/meta/meta.hpp:1183:56: required by
substitution of ‘template using strict_and =
meta::v1::and_c [with Bools =
{ranges::v3::concepts::models,
std::allocator > > [5]>}]’
/home/jamrial/range-v3/include/meta/meta.hpp:651:26: required by substitution
of ‘template class C, class ... Ts, template
class D> meta::v1::id > meta::v1::detail::try_defer_(int) [with C =
meta::v1::strict_and; Ts =
{ranges::v3::concepts::models,
std::allocator > > [5]>}; D = meta::v1::strict_and]’
/home/jamrial/range-v3/include/meta/meta.hpp:656:65: [ skipping 9
instantiation contexts, use -ftemplate-backtrace-limit=0 to disable ]
/home/jamrial/range-v3/include/range/v3/range_concepts.hpp:212:59: required
by substitution of ‘template T
ranges::v3::detail::gcc_bugs_bugs_bugs(T) [with T = ]’
/home/jamrial/range-v3/include/range/v3/utility/concepts.hpp:111:55: required
by substitution of ‘template
meta::v1::apply, typename
meta::v1::detail::transform_::type,
meta::v1::bind_back, Ts ...> >,
void>::type> ranges::v3::detail::models_(Concept*) [with Ts = {std::pair, std::allocator >
> [5]}; Concept = ranges::v3::concepts::View; =
]’
/home/jamrial/range-v3/include/range/v3/utility/concepts.hpp:187:69: required
from ‘struct ranges::v3::concepts::models,
std::allocator > > [5]>’
/home/jamrial/range-v3/include/range/v3/view/all.hpp:70:111: required by
substitution of ‘template::type>::type>())),
int>::type , class I, class S, class SIC, class SIRC> static
decltype (ranges::v3::view::all_fn::from_container(t, SIC(), SIRC()))
ranges::v3::view::all_fn::from_range(T&&) [with T = std::pair > (&)[5]; int _concept_requires_70 = 42;
typename std::enable_if<((_concept_requires_70 == 43) || (!
ranges::v3::concepts::models::type>::type>())),
int>::type = ; I = std::pair >*; S = std::pair >*; SIC =
ranges::v3::concepts::most_refined, std::pair, std::allocator > > (&)[5]>; SIRC =
ranges::v3::concepts::most_refined, std::pair, std::allocator >
>*, std::pair,
std::allocator > >*>]’
/home/jamrial/range-v3/include/range/v3/view/all.hpp:88:48: required by
substitution of ‘template()), int>::type
> decltype
(ranges::v3::view::all_fn::from_range(static_cast(t)))
ranges::v3::view::all_fn::operator()(T&&) const [with T = std::pair > (&am
[Bug c++/80812] internal compiler error: in build_value_init_noctor, at cp/init.c:483
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80812 --- Comment #1 from James Almer --- This started with r248153
[Bug c/83056] New: GCC suggests the use of previously reported undeclared identifiers when reporting new undeclared identifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83056
Bug ID: 83056
Summary: GCC suggests the use of previously reported undeclared
identifiers when reporting new undeclared identifiers
Product: gcc
Version: 7.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jamrial at gmail dot com
Target Milestone: ---
$ cat suggest.c
enum {
TYPE_A,
}
int fn(void)
{
int b = TYPE_B;
int c = TYPE_C;
int d = TYPE_D;
return 0;
}
$ gcc -O3 -Wall -c suggest.c
suggest.c: In function 'fn':
suggest.c:7:13: error: 'TYPE_B' undeclared (first use in this function); did
you mean 'TYPE_A'?
int b = TYPE_B;
^~
TYPE_A
suggest.c:7:13: note: each undeclared identifier is reported only once for each
function it appears in
suggest.c:8:13: error: 'TYPE_C' undeclared (first use in this function); did
you mean 'TYPE_B'?
int c = TYPE_C;
^~
TYPE_B
suggest.c:9:13: error: 'TYPE_D' undeclared (first use in this function); did
you mean 'TYPE_C'?
int d = TYPE_D;
^~
TYPE_C
For some reason, for every new undeclared identifier gcc suggest to use a
previously reported (but apparently similar) undeclared identifier.
Shouldn't it always suggest TYPE_A, the only defined identifier?
[Bug c++/78003] New: c++17: ICE in build_over_call, at cp/call.c:7847
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78003
Bug ID: 78003
Summary: c++17: ICE in build_over_call, at cp/call.c:7847
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jamrial at gmail dot com
Target Milestone: ---
Created attachment 39820
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39820&action=edit
Preprocessed output as created by -freport-bug
/home/jamrial/range-v3/include/range/v3/detail/variant.hpp:679:35: internal
compiler error: in build_over_call, at cp/call.c:7847
detail::variant_visit_(var.index(), data, detail::get_fn{&elem});
~~^
0x646c0f build_over_call
/home/jamrial/gcc-svn/gcc/cp/call.c:7844
0x650edf build_new_method_call_1
/home/jamrial/gcc-svn/gcc/cp/call.c:8661
0x650edf build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
/home/jamrial/gcc-svn/gcc/cp/call.c:8731
0x651eae build_special_member_call(tree_node*, tree_node*, vec**, tree_node*, int, int)
/home/jamrial/gcc-svn/gcc/cp/call.c:8263
0x647d0d build_temp
/home/jamrial/gcc-svn/gcc/cp/call.c:6395
0x647d0d convert_like_real
/home/jamrial/gcc-svn/gcc/cp/call.c:6805
0x648f6c perform_implicit_conversion_flags(tree_node*, tree_node*, int, int)
/home/jamrial/gcc-svn/gcc/cp/call.c:9887
0x643e6b convert_default_arg(tree_node*, tree_node*, tree_node*, int, int)
/home/jamrial/gcc-svn/gcc/cp/call.c:7180
0x6447c0 build_over_call
/home/jamrial/gcc-svn/gcc/cp/call.c:7748
0x6549af build_new_function_call(tree_node*, vec**, bool, int)
/home/jamrial/gcc-svn/gcc/cp/call.c:4204
0x7eee4c finish_call_expr(tree_node*, vec**, bool,
bool, int)
/home/jamrial/gcc-svn/gcc/cp/semantics.c:2440
0x6c0298 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/jamrial/gcc-svn/gcc/cp/pt.c:16786
0x6b4d45 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/jamrial/gcc-svn/gcc/cp/pt.c:15952
0x6b2d87 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/jamrial/gcc-svn/gcc/cp/pt.c:15258
0x6b45cc tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/jamrial/gcc-svn/gcc/cp/pt.c:15244
0x6b4410 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/jamrial/gcc-svn/gcc/cp/pt.c:15435
0x6b1875 instantiate_decl(tree_node*, int, bool)
/home/jamrial/gcc-svn/gcc/cp/pt.c:22189
0x6fa71b instantiate_pending_templates(int)
/home/jamrial/gcc-svn/gcc/cp/pt.c:22306
0x73e361 c_parse_final_cleanups()
/home/jamrial/gcc-svn/gcc/cp/decl2.c:4506
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.
[Bug tree-optimization/60902] [4.9 Regression] ffmpeg built with gcc 4.9 RC produces incorrect flac playback code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60902 James Almer changed: What|Removed |Added CC||jamrial at gmail dot com --- Comment #32 from James Almer --- Please, don't forget to backport the fix to the 4.9 branch. gcc 4.9.0 is almost unusable for ffmpeg because this didn't make it on time. Thanks.
[Bug target/65671] New: Assembly failure (invalid register operand) with -O3 -mavx512vl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65671 Bug ID: 65671 Summary: Assembly failure (invalid register operand) with -O3 -mavx512vl Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: jamrial at gmail dot com https://raw.githubusercontent.com/foo86/dcadec/e884d9a0d9127528bdc47c1f8db392363fb50876/libdcadec/idct_float.c gcc -O3 -mavx512f -mavx512vl -c -o libdcadec/idct_float.o libdcadec/idct_float.c /tmp/cc3BQBvH.s: Assembler messages: /tmp/cc3BQBvH.s:1602: Error: invalid register operand for `vextractf128' /tmp/cc3BQBvH.s:1624: Error: invalid register operand for `vextractf128' /tmp/cc3BQBvH.s:1670: Error: invalid register operand for `vextractf128' Lines in question from the resulting assembly file 1602: vextractf128$0x1, %ymm20, 144(%rdx) 1624: vextractf128$0x1, %ymm24, 272(%rdx) 1670: vextractf128$0x1, %ymm19, 400(%rdx) GCC 5.0.0 (20150329 snapshot) on x86_64-unknown-linux-gnu. Works fine with -mavx512f alone, so sounds like the assembler is trying to use VEX coding scheme with the new registers instead of EVEX.
[Bug target/65782] New: Assembly failure (invalid register for .seh_savexmm) with -O3 -mavx512f on mingw-w64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65782 Bug ID: 65782 Summary: Assembly failure (invalid register for .seh_savexmm) with -O3 -mavx512f on mingw-w64 Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: jamrial at gmail dot com Created attachment 35328 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35328&action=edit Assembly output https://raw.githubusercontent.com/foo86/dcadec/4dac90072f1a0ad368430dbbb568ac71def0241f/libdcadec/idct_float.c GCC 5.1.0 RC and mingw-w64 v4.0.1, cross-compiler. Can also be reproduced with GCC 4.9 [jamrial@archVM dcadec]$ x86_64-w64-mingw32-gcc -O3 -mavx512f -c -o libdcadec/idct_float.o libdcadec/idct_float.c /tmp/ccGUgVPR.s: Assembler messages: /tmp/ccGUgVPR.s:557: Error: invalid register for .seh_savexmm /tmp/ccGUgVPR.s:559: Error: invalid register for .seh_savexmm /tmp/ccGUgVPR.s:561: Error: invalid register for .seh_savexmm /tmp/ccGUgVPR.s:563: Error: invalid register for .seh_savexmm /tmp/ccGUgVPR.s:565: Error: invalid register for .seh_savexmm /tmp/ccGUgVPR.s:567: Error: invalid register for .seh_savexmm /tmp/ccGUgVPR.s:569: Error: invalid register for .seh_savexmm /tmp/ccGUgVPR.s:571: Error: invalid register for .seh_savexmm /tmp/ccGUgVPR.s:573: Error: invalid register for .seh_savexmm /tmp/ccGUgVPR.s:575: Error: invalid register for .seh_savexmm /tmp/ccGUgVPR.s:577: Error: invalid register for .seh_savexmm /tmp/ccGUgVPR.s:579: Error: invalid register for .seh_savexmm /tmp/ccGUgVPR.s:581: Error: invalid register for .seh_savexmm /tmp/ccGUgVPR.s:583: Error: invalid register for .seh_savexmm /tmp/ccGUgVPR.s:585: Error: invalid register for .seh_savexmm /tmp/ccGUgVPR.s:587: Error: invalid register for .seh_savexmm /tmp/ccGUgVPR.s:1482: Error: invalid register for .seh_savexmm /tmp/ccGUgVPR.s:1484: Error: invalid register for .seh_savexmm /tmp/ccGUgVPR.s:1486: Error: invalid register for .seh_savexmm /tmp/ccGUgVPR.s:1488: Error: invalid register for .seh_savexmm /tmp/ccGUgVPR.s:1490: Error: invalid register for .seh_savexmm /tmp/ccGUgVPR.s:1492: Error: invalid register for .seh_savexmm /tmp/ccGUgVPR.s:1494: Error: invalid register for .seh_savexmm /tmp/ccGUgVPR.s:1496: Error: invalid register for .seh_savexmm /tmp/ccGUgVPR.s:1498: Error: invalid register for .seh_savexmm /tmp/ccGUgVPR.s:1500: Error: invalid register for .seh_savexmm /tmp/ccGUgVPR.s:1502: Error: invalid register for .seh_savexmm /tmp/ccGUgVPR.s:1504: Error: invalid register for .seh_savexmm /tmp/ccGUgVPR.s:1506: Error: invalid register for .seh_savexmm /tmp/ccGUgVPR.s:1508: Error: invalid register for .seh_savexmm /tmp/ccGUgVPR.s:1510: Error: invalid register for .seh_savexmm /tmp/ccGUgVPR.s:1512: Error: invalid register for .seh_savexmm [jamrial@archVM dcadec]$ x86_64-w64-mingw32-gcc -v Using built-in specs. COLLECT_GCC=x86_64-w64-mingw32-gcc COLLECT_LTO_WRAPPER=/opt/mingw64/lib/gcc/x86_64-w64-mingw32/5.0.1/lto-wrapper Target: x86_64-w64-mingw32 Configured with: /home/jamrial/gcc-5.1.0-RC-20150412/configure --host=x86_64-unknown-linux-gnu --build=x86_64-unknown-linux-gnu --target=x86_64-w64-mingw32 --disable-multilib --enable-static --disable-shared --enable-64bit --prefix=/opt/mingw64 --with-sysroot=/opt/mingw64 --enable-version-specific-runtime-libs --with-dwarf --enable-fully-dynamic-string --enable-languages=c,c++ --enable-libssp --with-host-libstdcxx='-lstdc++ -lsupc++' --enable-lto --disable-win32-registry --libexecdir=/opt/mingw64/lib --disable-nls Thread model: win32 gcc version 5.0.1 20150412 (prerelease) (GCC) Attached is the resulting assembly file.
[Bug target/65871] New: bzhi builtin/intrinsic wrongly assumes bzhi instruction doesn't set the ZF flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65871
Bug ID: 65871
Summary: bzhi builtin/intrinsic wrongly assumes bzhi
instruction doesn't set the ZF flag
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jamrial at gmail dot com
unsigned foo(void);
int main(void)
{
if (__builtin_ia32_bzhi_si(foo(), foo()))
return 1;
return 0;
}
Compiled with -mbmi2 -O3
:
0: 53 push rbx
1: e8 00 00 00 00 call 6
6: 89 c3 movebx,eax
8: e8 00 00 00 00 call d
d: c4 e2 60 f5 c0 bzhi eax,eax,ebx
12: 85 c0 test eax,eax
14: 0f 95 c0setne al
17: 0f b6 c0movzx eax,al
1a: 5b poprbx
1b: c3 ret
It generates a redundant test instruction. According to
http://www.felixcloutier.com/x86/BZHI.html bzhi already sets the ZF flag on its
own.
Same happens when using inline assembly instead of the builtin to generate the
bzhi instruction. In all cases reproducible with GCC 4.9.2 and GCC 5.1.0.
Didn't test the 4.8 branch or trunk.
This aside, it would be nice if gcc could generate a bzhi instruction on its
own if it detects "X & ((1 << Y) - 1)" where Y is not a constant, same as it
does for several other bmi and tbm instructions, instead of needing to use the
builtin (Which is only available when targeting bmi2).
I can open a new bug report for that if needed.
[Bug target/65871] bzhi builtin/intrinsic wrongly assumes bzhi instruction doesn't set the ZF flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65871 --- Comment #1 from James Almer --- The same apparently happens with bextr, blsi, blsr, and most (if not all) of AMD's tbm instructions. They set the ZF flag but gcc still generates a test instruction. http://www.felixcloutier.com/x86/BEXTR.html http://www.felixcloutier.com/x86/BLSI.html http://www.felixcloutier.com/x86/BLSR.html http://support.amd.com/TechDocs/24594.pdf
[Bug target/65871] bzhi builtin/intrinsic wrongly assumes bzhi instruction doesn't set the ZF flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65871 --- Comment #4 from James Almer --- (In reply to Uroš Bizjak from comment #3) > Please see the patch, attached in Comment #2. > > While I can see the use (and benefit) to model the patterns that also set CC > register internally for BEXTR and BZHI instructions, I don't think other > listed instructions have clear usage scenarios to warrant additional > patterns. > > Can you perhaps show the benefit to have more insns modelled this way? Not really, i simply assumed that taking into consideration what flags these instructions affected in every case was the intended behavior, so figured it was worth pointing them out. I'm mainly interested in bzhi (and by extension bextr).
[Bug c++/65936] New: [6 Regression] ICE building libboost_log.so.1.58.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65936
Bug ID: 65936
Summary: [6 Regression] ICE building libboost_log.so.1.58.0
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jamrial at gmail dot com
Target Milestone: ---
Created attachment 35428
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35428&action=edit
Preprocessed source as generated by -freport-bug
In file included from ./boost/move/utility_core.hpp:29:0,
from ./boost/intrusive/list.hpp:39,
from libs/log/src/attribute_set.cpp:19:
./boost/log/attributes/attribute_set.hpp: In member function
‘boost::log::v2_mt_posix::attribute_set::operator
boost::rv&()’:
./boost/move/core.hpp:246:56: internal compiler error: canonical types differ
for identical types boost::rv* and
boost::rv*
{ return *static_cast< ::boost::rv* >(this); }\
^
./boost/log/attributes/attribute_set.hpp:82:5: note: in expansion of macro
‘BOOST_COPYABLE_AND_MOVABLE_ALT’
BOOST_COPYABLE_AND_MOVABLE_ALT(attribute_set)
^
0x746a4e comptypes(tree_node*, tree_node*, int)
/home/jamrial/gcc-6-20150426/gcc/cp/typeck.c:1428
0x7619de ocp_convert(tree_node*, tree_node*, int, int, int)
/home/jamrial/gcc-6-20150426/gcc/cp/cvt.c:704
0x607310 convert_like_real
/home/jamrial/gcc-6-20150426/gcc/cp/call.c:6557
0x612e0b initialize_reference(tree_node*, tree_node*, int, int)
/home/jamrial/gcc-6-20150426/gcc/cp/call.c:9746
0x750bf2 check_return_expr(tree_node*, bool*)
/home/jamrial/gcc-6-20150426/gcc/cp/typeck.c:8718
0x78e59e finish_return_stmt(tree_node*)
/home/jamrial/gcc-6-20150426/gcc/cp/semantics.c:887
0x731cbe cp_parser_jump_statement
/home/jamrial/gcc-6-20150426/gcc/cp/parser.c:11057
0x731cbe cp_parser_statement
/home/jamrial/gcc-6-20150426/gcc/cp/parser.c:9707
0x732252 cp_parser_statement_seq_opt
/home/jamrial/gcc-6-20150426/gcc/cp/parser.c:10095
0x7323ab cp_parser_compound_statement
/home/jamrial/gcc-6-20150426/gcc/cp/parser.c:10049
0x7325db cp_parser_function_body
/home/jamrial/gcc-6-20150426/gcc/cp/parser.c:19185
0x7325db cp_parser_ctor_initializer_opt_and_function_body
/home/jamrial/gcc-6-20150426/gcc/cp/parser.c:19221
0x73341a cp_parser_function_definition_after_declarator
/home/jamrial/gcc-6-20150426/gcc/cp/parser.c:23467
0x736a6c cp_parser_late_parsing_for_member
/home/jamrial/gcc-6-20150426/gcc/cp/parser.c:24150
0x711c71 cp_parser_class_specifier_1
/home/jamrial/gcc-6-20150426/gcc/cp/parser.c:20041
0x711c71 cp_parser_class_specifier
/home/jamrial/gcc-6-20150426/gcc/cp/parser.c:20067
0x711c71 cp_parser_type_specifier
/home/jamrial/gcc-6-20150426/gcc/cp/parser.c:14707
0x724eff cp_parser_decl_specifier_seq
/home/jamrial/gcc-6-20150426/gcc/cp/parser.c:11938
0x7361b1 cp_parser_simple_declaration
/home/jamrial/gcc-6-20150426/gcc/cp/parser.c:11515
0x72fe23 cp_parser_block_declaration
/home/jamrial/gcc-6-20150426/gcc/cp/parser.c:11462
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.
-
This is one of many ICEs i get while compiling libboost_log.so from Boost 1.58
with GCC 6.0.0 (20150426 snapshot) on ArchLinux x86_64. Most if not all seem to
have a similar backtrace, so I'm posting only the first.
[Bug target/65871] bzhi builtin/intrinsic wrongly assumes bzhi instruction doesn't set the ZF flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65871
--- Comment #7 from James Almer ---
Thanks for the above fix.
I forgot to test BMI1's andn. That one should have an insn modeled this way as
well.
int foo (unsigned int x, unsigned int y)
{
if (~x & y)
return 1;
return 0;
}
gcc -O2 -mbmi -c andn.c
:
0: c4 e2 40 f2 fe andn %esi,%edi,%edi
5: 31 c0 xor%eax,%eax
7: 85 ff test %edi,%edi
9: 0f 95 c0setne %al
c: c3 retq
http://www.felixcloutier.com/x86/ANDN.html
[Bug c++/66067] New: tree check ICE: accessed elt 1 of tree_vec with 0 elts in write_template_args, at cp/mangle.c:2574
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66067 Bug ID: 66067 Summary: tree check ICE: accessed elt 1 of tree_vec with 0 elts in write_template_args, at cp/mangle.c:2574 Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jamrial at gmail dot com Target Milestone: --- Created attachment 35494 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35494&action=edit Preprocessed source as generated by -freport-bug In file included from /home/jamrial/range-v3/include/range/v3/range_fwd.hpp:19:0, from /home/jamrial/range-v3/include/range/v3/begin_end.hpp:21, from /home/jamrial/range-v3/include/range/v3/core.hpp:17, from /home/jamrial/range-v3/test/container_conversion.cpp:17: /home/jamrial/range-v3/include/meta/meta.hpp: In instantiation of ‘constexpr const size_t meta::v1::detail::reverse_find_index_, ranges::v3::default_sentinel>, ranges::v3::iter_transform_view > >::adaptor >, ranges::v3::adaptor_sentinel, ranges::v3::adaptor_base> >&, const long int&>, 0>, meta::v1::defer, ranges::v3::default_sentinel>, ranges::v3::iter_transform_view > >::adaptor >, ranges::v3::adaptor_sentinel, ranges::v3::adaptor_base> >&, const long int&> >, std::integral_constant > > >, const long int&>::i’: /home/jamrial/range-v3/test/container_conversion.cpp:62:1: required from here /home/jamrial/range-v3/include/meta/meta.hpp:1645:46: internal compiler error: tree check: accessed elt 1 of tree_vec with 0 elts in write_template_args, at cp/mangle.c:2574 static constexpr std::size_t i = List::size() - reverse_find::size(); ^ 0xeefa55 tree_vec_elt_check_failed(int, int, char const*, int, char const*) /home/jamrial/gcc-6-20150506/gcc/tree.c:9517 0x78e1ff tree_vec_elt_check(tree_node*, int, char const*, int, char const*) /home/jamrial/gcc-6-20150506/gcc/tree.h:3073 0x78e1ff write_template_args /home/jamrial/gcc-6-20150506/gcc/cp/mangle.c:2574 0x78ee60 write_nested_name /home/jamrial/gcc-6-20150506/gcc/cp/mangle.c:1005 0x78cf71 write_name /home/jamrial/gcc-6-20150506/gcc/cp/mangle.c:910 0x78ddf9 write_template_template_arg /home/jamrial/gcc-6-20150506/gcc/cp/mangle.c:3210 0x78ddf9 write_template_arg /home/jamrial/gcc-6-20150506/gcc/cp/mangle.c:3171 0x78e0f8 write_template_args /home/jamrial/gcc-6-20150506/gcc/cp/mangle.c:2582 0x78ee4d write_nested_name /home/jamrial/gcc-6-20150506/gcc/cp/mangle.c:997 0x78cf71 write_name /home/jamrial/gcc-6-20150506/gcc/cp/mangle.c:910 0x78a5d6 write_class_enum_type /home/jamrial/gcc-6-20150506/gcc/cp/mangle.c:2553 0x78a5d6 write_type /home/jamrial/gcc-6-20150506/gcc/cp/mangle.c:2010 0x78e0f8 write_template_args /home/jamrial/gcc-6-20150506/gcc/cp/mangle.c:2582 0x78ee4d write_nested_name /home/jamrial/gcc-6-20150506/gcc/cp/mangle.c:997 0x78cf71 write_name /home/jamrial/gcc-6-20150506/gcc/cp/mangle.c:910 0x78a5d6 write_class_enum_type /home/jamrial/gcc-6-20150506/gcc/cp/mangle.c:2553 0x78a5d6 write_type /home/jamrial/gcc-6-20150506/gcc/cp/mangle.c:2010 0x78db44 write_template_arg /home/jamrial/gcc-6-20150506/gcc/cp/mangle.c:3164 0x78e0f8 write_template_args /home/jamrial/gcc-6-20150506/gcc/cp/mangle.c:2582 0x78ee4d write_nested_name /home/jamrial/gcc-6-20150506/gcc/cp/mangle.c:997
[Bug c++/66216] [6 Regression] Defaulted Operators and constructors not working with aligned attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66216 --- Comment #2 from James Almer --- (In reply to Jonathan Wakely from comment #1) > And now it gives an ICE on trunk, so it's regressed from rejects-valid to > ice-on-valid-code: > > a.cc:1:7: internal compiler error: canonical types differ for identical > types const CMymy and const CMymy > class CMymy This may be a duplicate of pr65936 then, or related.
[Bug c++/66067] [5/6 Regression] tree check ICE: accessed elt 1 of tree_vec with 0 elts in write_template_args, at cp/mangle.c:2574
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66067 James Almer changed: What|Removed |Added Known to work|5.1.0 | Summary|[6 Regression] tree check |[5/6 Regression] tree check |ICE: accessed elt 1 of |ICE: accessed elt 1 of |tree_vec with 0 elts in |tree_vec with 0 elts in |write_template_args, at |write_template_args, at |cp/mangle.c:2574|cp/mangle.c:2574 Known to fail||5.1.1 --- Comment #1 from James Almer --- While the above file compiles with 4.9.2 and 5.1, the following file fails with 5.1 with a segmentation fault error in the same line (6.0 however also fails with the tree check ICE). In file included from /home/jamrial/range-v3/include/range/v3/range_fwd.hpp:19:0, from /home/jamrial/range-v3/include/range/v3/begin_end.hpp:21, from /home/jamrial/range-v3/include/range/v3/core.hpp:17, from /home/jamrial/range-v3/test/algorithm/rotate.cpp:26: /home/jamrial/range-v3/include/meta/meta.hpp: In instantiation of ‘constexpr const size_t meta::v1::detail::reverse_find_index_, 0>, meta::v1::defer >, std::integral_constant > > >, const long int&>::i’: /home/jamrial/range-v3/test/algorithm/rotate.cpp:278:1: required from here /home/jamrial/range-v3/include/meta/meta.hpp:1645:46: internal compiler error: Segmentation fault static constexpr std::size_t i = List::size() - reverse_find::size();
[Bug c++/66067] [5/6 Regression] tree check ICE: accessed elt 1 of tree_vec with 0 elts in write_template_args, at cp/mangle.c:2574
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66067 --- Comment #2 from James Almer --- Created attachment 35594 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35594&action=edit Preprocessed source as generated by -freport-bug, from the second test case
[Bug c++/66270] New: ICE: canonical types differ for identical types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66270
Bug ID: 66270
Summary: ICE: canonical types differ for identical types
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jamrial at gmail dot com
Target Milestone: ---
Created attachment 35608
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35608&action=edit
Preprocessed source as generated by -freport-bug
GCC 6.0.0 svn 223625
In file included from Vec.h:3:0,
from Example.cc:8:
Vec8Float.h: In member function ‘avx::vec::Value& avx::vec::operator[](std::size_t)’:
Vec8Float.h:104:21: internal compiler error: canonical types differ for
identical types avx::vec::Value* {aka float*} and float*
return ymm[index];
^
0x72abbe comptypes(tree_node*, tree_node*, int)
/home/jamrial/gcc-svn/gcc/cp/typeck.c:1423
0x745b4a ocp_convert(tree_node*, tree_node*, int, int, int)
/home/jamrial/gcc-svn/gcc/cp/cvt.c:704
0x5ece73 convert_like_real
/home/jamrial/gcc-svn/gcc/cp/call.c:6591
0x5f897b initialize_reference(tree_node*, tree_node*, int, int)
/home/jamrial/gcc-svn/gcc/cp/call.c:9780
0x734c9c check_return_expr(tree_node*, bool*)
/home/jamrial/gcc-svn/gcc/cp/typeck.c:8730
0x76fc6e finish_return_stmt(tree_node*)
/home/jamrial/gcc-svn/gcc/cp/semantics.c:887
0x715a1e cp_parser_jump_statement
/home/jamrial/gcc-svn/gcc/cp/parser.c:11064
0x715a1e cp_parser_statement
/home/jamrial/gcc-svn/gcc/cp/parser.c:9707
0x715ff2 cp_parser_statement_seq_opt
/home/jamrial/gcc-svn/gcc/cp/parser.c:10095
0x71614b cp_parser_compound_statement
/home/jamrial/gcc-svn/gcc/cp/parser.c:10049
0x71637b cp_parser_function_body
/home/jamrial/gcc-svn/gcc/cp/parser.c:19223
0x71637b cp_parser_ctor_initializer_opt_and_function_body
/home/jamrial/gcc-svn/gcc/cp/parser.c:19259
0x717200 cp_parser_function_definition_after_declarator
/home/jamrial/gcc-svn/gcc/cp/parser.c:23519
0x71a804 cp_parser_late_parsing_for_member
/home/jamrial/gcc-svn/gcc/cp/parser.c:24202
0x6f58f9 cp_parser_class_specifier_1
/home/jamrial/gcc-svn/gcc/cp/parser.c:20079
0x6f58f9 cp_parser_class_specifier
/home/jamrial/gcc-svn/gcc/cp/parser.c:20105
0x6f58f9 cp_parser_type_specifier
/home/jamrial/gcc-svn/gcc/cp/parser.c:14734
0x708bce cp_parser_decl_specifier_seq
/home/jamrial/gcc-svn/gcc/cp/parser.c:11965
0x7181f8 cp_parser_single_declaration
/home/jamrial/gcc-svn/gcc/cp/parser.c:23773
0x718f3d cp_parser_explicit_specialization
/home/jamrial/gcc-svn/gcc/cp/parser.c:14630
[Bug c++/66371] New: ICE: canonical types differ for identical types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66371 Bug ID: 66371 Summary: ICE: canonical types differ for identical types Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jamrial at gmail dot com Target Milestone: --- Created attachment 35674 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35674&action=edit Preprocessed source as generated by -freport-bug GCC 6.0.0 svn 223906 In file included from /home/jamrial/range-v3/include/range/v3/range_interface.hpp:25:0, from /home/jamrial/range-v3/include/range/v3/range_facade.hpp:21, from /home/jamrial/range-v3/include/range/v3/core.hpp:21, from /home/jamrial/range-v3/test/container_conversion.cpp:17: /home/jamrial/range-v3/include/range/v3/to_container.hpp: In instantiation of ‘struct ranges::v3::detail::to_container_fn > >’: /home/jamrial/range-v3/include/range/v3/to_container.hpp:143:62: required from ‘Cont ranges::v3::to_(Rng&&) [with Cont = std::vector; Rng = ranges::v3::take_exactly_view&; int _concept_requires_140 = 42; typename std::enable_if<((_concept_requires_140 == 43) || (ranges::v3::Range() && ranges::v3::detail::ConvertibleToContainer())), int>::type = 0]’ /home/jamrial/range-v3/include/range/v3/range_interface.hpp:240:46: required from ‘ranges::v3::range_interface >::operator Container() [with Container = std::vector; D = ranges::v3::take_exactly_view; Alloc = std::allocator; int _concept_requires_237 = 42; typename std::enable_if<((_concept_requires_237 == 43) || ranges::v3::detail::ConvertibleToContainer()), int>::type = 0; Derived = ranges::v3::take_exactly_view; ranges::v3::cardinality Cardinality = (ranges::v3::cardinality)-1]’ /home/jamrial/range-v3/test/container_conversion.cpp:31:52: required from here /home/jamrial/range-v3/include/range/v3/to_container.hpp:74:22: internal compiler error: canonical types differ for identical types std::enable_if<((_concept_requires_73 == 43) || ((ranges::v3::Range() && ranges::v3::detail::ConvertibleToContainer >()) && ranges::v3::detail::to_container_fn > >::ReserveConcept())), int> and std::enable_if<((_concept_requires_73 == 43) || ((ranges::v3::Range() && ranges::v3::detail::ConvertibleToContainer >()) && ranges::v3::detail::to_container_fn >::ReserveConcept())), int> Cont impl(Rng && rng, std::true_type) const ^ 0x738b8e comptypes(tree_node*, tree_node*, int) /home/jamrial/gcc-svn/gcc/cp/typeck.c:1423 0x737610 structural_comptypes /home/jamrial/gcc-svn/gcc/cp/typeck.c:1338 0x66e122 reduce_template_parm_level /home/jamrial/gcc-svn/gcc/cp/pt.c:3704 0x66a120 tsubst(tree_node*, tree_node*, int, tree_node*) /home/jamrial/gcc-svn/gcc/cp/pt.c:12155 0x670e50 tsubst_copy /home/jamrial/gcc-svn/gcc/cp/pt.c:13054 0x676056 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) /home/jamrial/gcc-svn/gcc/cp/pt.c:15728 0x65b6b0 tsubst_expr /home/jamrial/gcc-svn/gcc/cp/pt.c:14393 0x66bf6b tsubst_template_arg /home/jamrial/gcc-svn/gcc/cp/pt.c:9690 0x666a42 tsubst_template_args /home/jamrial/gcc-svn/gcc/cp/pt.c:10241 0x666d3a tsubst_template_args /home/jamrial/gcc-svn/gcc/cp/pt.c:10201 0x660342 tsubst_decl /home/jamrial/gcc-svn/gcc/cp/pt.c:10624 0x669f4e tsubst(tree_node*, tree_node*, int, tree_node*) /home/jamrial/gcc-svn/gcc/cp/pt.c:11819 0x68de6b instantiate_class_template_1 /home/jamrial/gcc-svn/gcc/cp/pt.c:9357 0x68de6b instantiate_class_template(tree_node*) /home/jamrial/gcc-svn/gcc/cp/pt.c:9671 0x7336fb complete_type(tree_node*) /home/jamrial/gcc-svn/gcc/cp/typeck.c:146 0x7338ef complete_type_or_maybe_complain(tree_node*, tree_node*, int) /home/jamrial/gcc-svn/gcc/cp/typeck.c:158 0x7339d9 require_complete_type_sfinae(tree_node*, int) /home/jamrial/gcc-svn/gcc/cp/typeck.c:102 0x5ec059 build_cxx_call(tree_node*, int, tree_node**, int) /home/jamrial/gcc-svn/gcc/cp/call.c:7652 0x5f1701 build_over_call /home/jamrial/gcc-svn/gcc/cp/call.c:7567 0x600471 build_new_function_call(tree_node*, vec**, bool, int) /home/jamrial/gcc-svn/gcc/cp/call.c:4100 New version of the first file reported in pr66067, this time with a different ICE.
[Bug tree-optimization/67794] New: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67794 Bug ID: 67794 Summary: internal compiler error: Segmentation fault Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: jamrial at gmail dot com Target Milestone: --- Created attachment 36432 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36432&action=edit Preprocessed source as generated by -freport-bug In file included from /home/jamrial/ffmpeg/libavcodec/motion_est.c:295:0: /home/jamrial/ffmpeg/libavcodec/motion_est_template.c: In function ‘sab_diamond_search.isra.3’: /home/jamrial/ffmpeg/libavcodec/motion_est_template.c:679:12: internal compiler error: Segmentation fault static int sab_diamond_search(MpegEncContext * s, int *best, int dmin, ^ 0xabb4ff crash_signal /home/jamrial/gcc-svn/gcc/toplev.c:353 0xbce129 tree_check(tree_node const*, char const*, int, char const*, tree_code) /home/jamrial/gcc-svn/gcc/tree.h:3116 0xbce129 has_zero_uses /home/jamrial/gcc-svn/gcc/ssa-iterators.h:381 0xbce129 coalesce_with_default /home/jamrial/gcc-svn/gcc/tree-ssa-coalesce.c:1003 0xbce129 create_outofssa_var_map /home/jamrial/gcc-svn/gcc/tree-ssa-coalesce.c:1202 0xbcedd0 coalesce_ssa_name() /home/jamrial/gcc-svn/gcc/tree-ssa-coalesce.c:1736 0xb628fe remove_ssa_form /home/jamrial/gcc-svn/gcc/tree-outof-ssa.c:984 0xb628fe rewrite_out_of_ssa(ssaexpand*) /home/jamrial/gcc-svn/gcc/tree-outof-ssa.c:1208 0x701490 execute /home/jamrial/gcc-svn/gcc/cfgexpand.c:6100 gcc version 6.0.0 20151001 on x86_64-pc-linux-gnu. This regression was apparently introduced sometime in the last eight days.
[Bug rtl-optimization/67920] New: wrong code with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67920 Bug ID: 67920 Summary: wrong code with -O3 Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: jamrial at gmail dot com Target Milestone: --- Some change to trunk made in the last 18 days is making gcc miscompile the files libavcodec/jpeg2000dec.c libavcodec/j2kenc.c and libavcodec/avuidec.c from ffmpeg git head when -O3 is used. This doesn't happen with -O2. I tested with x86_64-pc-linux-gnu only. How to reproduce: git clone git://git.videolan.org/ffmpeg.git && cd ffmpeg && ./configure make fate-vsynth1-jpeg2000 fate-vsynth1-avui The tests will fail, the former showing both the encoder and decoder are producing garbage, and the latter only the decoder. Adding -fno-strict-aliasing -fwrapv does not make a difference. The command Makefile uses to compile all three files looks like this: gcc -I. -I/home/jamrial/ffmpeg/ -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -DZLIB_CONST -DHAVE_AV_CONFIG_H -std=c99 -fomit-frame-pointer -pthread -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=format-security -Werror=implicit-function-declaration -Werror=missing-prototypes -Werror=return-type -Werror=vla -Wformat -fdiagnostics-color=auto -Wno-maybe-uninitialized -c -o OUTPUT.o INPUT.c You can get that kind of verbose output by running make with V=1. Keep in mind you'll probably run into pr67794 while bisecting gcc trunk to find the commit that introduced this regression. Apologizes for not having a simpler test case.
[Bug rtl-optimization/67920] wrong code with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67920 --- Comment #1 from James Almer --- For reference you can also check http://fate.ffmpeg.org/report.cgi?time=20151010052205&slot=x86_64-archlinux-gcc-experimental
[Bug sanitizer/67921] New: "internal compiler error: in build_polynomial_chrec, at tree-chrec.h:147" when using -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67921 Bug ID: 67921 Summary: "internal compiler error: in build_polynomial_chrec, at tree-chrec.h:147" when using -fsanitize=undefined Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: jamrial at gmail dot com CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org Target Milestone: --- Created attachment 36478 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36478&action=edit Preprocessed source as generated by -freport-bug /home/jamrial/ffmpeg/libavcodec/dcaenc.c: In function ‘calc_masking’: /home/jamrial/ffmpeg/libavcodec/dcaenc.c:497:13: internal compiler error: in build_polynomial_chrec, at tree-chrec.h:147 static void calc_masking(DCAEncContext *c, const int32_t *input) ^ 0x11b8044 build_polynomial_chrec /home/jamrial/gcc-svn/gcc/tree-chrec.h:147 0xb9d6b9 interpret_rhs_expr /home/jamrial/gcc-svn/gcc/tree-scalar-evolution.c:1820 0xb99d34 interpret_expr /home/jamrial/gcc-svn/gcc/tree-scalar-evolution.c:1896 0xb99d34 analyze_scalar_evolution_1 /home/jamrial/gcc-svn/gcc/tree-scalar-evolution.c:1957 0xb9a837 analyze_scalar_evolution(loop*, tree_node*) /home/jamrial/gcc-svn/gcc/tree-scalar-evolution.c:2046 0xb9d75d interpret_rhs_expr /home/jamrial/gcc-svn/gcc/tree-scalar-evolution.c:1866 0xb99d34 interpret_expr /home/jamrial/gcc-svn/gcc/tree-scalar-evolution.c:1896 0xb99d34 analyze_scalar_evolution_1 /home/jamrial/gcc-svn/gcc/tree-scalar-evolution.c:1957 0xb9a837 analyze_scalar_evolution(loop*, tree_node*) /home/jamrial/gcc-svn/gcc/tree-scalar-evolution.c:2046 0xb9d78e interpret_rhs_expr /home/jamrial/gcc-svn/gcc/tree-scalar-evolution.c:1805 0xb99d34 interpret_expr /home/jamrial/gcc-svn/gcc/tree-scalar-evolution.c:1896 0xb99d34 analyze_scalar_evolution_1 /home/jamrial/gcc-svn/gcc/tree-scalar-evolution.c:1957 0xb9a837 analyze_scalar_evolution(loop*, tree_node*) /home/jamrial/gcc-svn/gcc/tree-scalar-evolution.c:2046 0xb9d4ee interpret_rhs_expr /home/jamrial/gcc-svn/gcc/tree-scalar-evolution.c:1795 0xb99d34 interpret_expr /home/jamrial/gcc-svn/gcc/tree-scalar-evolution.c:1896 0xb99d34 analyze_scalar_evolution_1 /home/jamrial/gcc-svn/gcc/tree-scalar-evolution.c:1957 0xb9a837 analyze_scalar_evolution(loop*, tree_node*) /home/jamrial/gcc-svn/gcc/tree-scalar-evolution.c:2046 0xb9e0ca analyze_scalar_evolution_in_loop /home/jamrial/gcc-svn/gcc/tree-scalar-evolution.c:2142 0xb9e212 simple_iv(loop*, loop*, tree_node*, affine_iv*, bool) /home/jamrial/gcc-svn/gcc/tree-scalar-evolution.c:3252 0xc10bf8 find_givs_in_stmt_scev /home/jamrial/gcc-svn/gcc/tree-ssa-loop-ivopts.c:1220
[Bug rtl-optimization/67920] wrong code with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67920 --- Comment #3 from James Almer --- (In reply to Andrew Pinski from comment #2) > Can you also compile with -fsanitize=undefined and try that? Can you also > try -fsanitize=address ? > > This might detect if it is a bug in the code vs a bug in GCC. Can't check with gcc 6 because of pr67921, but asan/ubsan in gcc 5.2.0 and clang 3.1 apparently don't complain about the code. ubsan gcc 5.2.0: http://fate.ffmpeg.org/report.cgi?time=20151010033356&slot=x86_64-archlinux-gcc-ubsan asan gcc 5.2.0: http://fate.ffmpeg.org/report.cgi?time=20151010181435&slot=x86_64-archlinux-gcc-asan Clang 3.1 asan: http://fate.ffmpeg.org/report.cgi?time=20151010171909&slot=x86_64-debian-asan-144800
[Bug tree-optimization/67920] [6 Regression] wrong code with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67920 James Almer changed: What|Removed |Added Component|rtl-optimization|tree-optimization --- Comment #5 from James Almer --- This is a regression introduced by r228599. I'm attaching the output of -save-temps for all three files, the good assembly from r228598 (last good commit) and the bad assembly from r228599. I can't generate a better or simpler testcase, sorry.
[Bug tree-optimization/67920] [6 Regression] wrong code with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67920 --- Comment #6 from James Almer --- Created attachment 36491 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36491&action=edit -save-temps output for all three files
[Bug tree-optimization/67920] [6 Regression] wrong code with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67920 --- Comment #9 from James Almer --- (In reply to Yuri Rumyantsev from comment #8) > Please check that revision 228760 will cure your issue. Looks like it did. Thanks.
[Bug target/65368] New: _bzhi_u32 intrinsic generates incorrect code when -O1 or above is specified and index is an immediate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65368
Bug ID: 65368
Summary: _bzhi_u32 intrinsic generates incorrect code when -O1
or above is specified and index is an immediate
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jamrial at gmail dot com
The code generated is a simple AND instruction that zeroes the high bits based
on the index value starting from the highest bit rather than the lowest.
Sample program:
--
#include
#include
int main(int argc, char **argv)
{
unsigned int j = _bzhi_u32(atoi(argv[1]), 11);
printf("%x\n", j);
return 0;
}
--
compiled with "gcc -O1 -mbmi2 -std=c99 -o bzhi bzhi.c"
[jamrial@ArchVM~]$ ./bzhi 4294967295
1f
Disassemble is as follows
:
0: 48 83 ec 08 subrsp,0x8
4: 48 8b 7e 08 movrdi,QWORD PTR [rsi+0x8]
8: ba 0a 00 00 00 movedx,0xa
d: be 00 00 00 00 movesi,0x0
12: e8 00 00 00 00 call 17
17: 89 c6 movesi,eax
19: 81 e6 ff ff 1f 00 andesi,0x1f
1f: bf 00 00 00 00 movedi,0x0
24: b8 00 00 00 00 moveax,0x0
29: e8 00 00 00 00 call 2e
2e: b8 00 00 00 00 moveax,0x0
33: 48 83 c4 08 addrsp,0x8
37: c3 ret
compiled with "gcc -mbmi2 -std=c99 -o bzhi bzhi.c"
[jamrial@ArchVM~]$ ./bzhi 4294967295
7ff
Disassemble is as follows
:
0: 55 push rbp
1: 48 89 e5movrbp,rsp
4: 48 83 ec 20 subrsp,0x20
8: 89 7d ecmovDWORD PTR [rbp-0x14],edi
b: 48 89 75 e0 movQWORD PTR [rbp-0x20],rsi
f: 48 8b 45 e0 movrax,QWORD PTR [rbp-0x20]
13: 48 83 c0 08 addrax,0x8
17: 48 8b 00movrax,QWORD PTR [rax]
1a: 48 89 c7movrdi,rax
1d: e8 00 00 00 00 call 22
22: 89 45 f8movDWORD PTR [rbp-0x8],eax
25: c7 45 f4 0b 00 00 00movDWORD PTR [rbp-0xc],0xb
2c: 8b 45 f4moveax,DWORD PTR [rbp-0xc]
2f: c4 e2 78 f5 45 f8 bzhi eax,DWORD PTR [rbp-0x8],eax
35: 89 45 fcmovDWORD PTR [rbp-0x4],eax
38: 8b 45 fcmoveax,DWORD PTR [rbp-0x4]
3b: 89 c6 movesi,eax
3d: bf 00 00 00 00 movedi,0x0
42: b8 00 00 00 00 moveax,0x0
47: e8 00 00 00 00 call 4c
4c: b8 00 00 00 00 moveax,0x0
51: c9 leave
52: c3 ret
When the index is not an immediate the actual bzhi instruction is always used
(with or without -Ox flags), and the result is the expected one.
[Bug target/68647] New: __builtin_popcountll doesn't generate popcnt instructions when targeting -mpopcnt on x86_32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68647
Bug ID: 68647
Summary: __builtin_popcountll doesn't generate popcnt
instructions when targeting -mpopcnt on x86_32
Product: gcc
Version: 5.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jamrial at gmail dot com
Target Milestone: ---
#include
int fn (uint64_t a) {
return __builtin_popcountll(a);
}
gcc -O2 -mpopcnt
xor eax, eax
popcnt rax, rdi
ret
clang -O2 -mpopcnt
popcnt rax, rdi
ret
gcc -O2 -m32 -mpopcnt
sub esp, 20
pushDWORD PTR [esp+28]
pushDWORD PTR [esp+28]
call__popcountdi2
add esp, 28
ret
clang -O2 -m32 -mpopcnt
popcnt ecx, dword ptr [esp + 8]
popcnt eax, dword ptr [esp + 4]
add eax, ecx
ret
Unrelated to this ticket, but GCC should also consider doing like clang and
make the builtins inline the relevant code when the target hardware lacks
support for the popcnt instruction.
I know of at least two projects that provide their own popcount functions
instead of using the builtins when popcnt is not available because the calls to
__popcount[sd]i2 are slow.
[Bug c/68780] _mm256_mul_epi32 intrinsic not working
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68780 --- Comment #1 from James Almer --- What i assume you want is _mm256_mullo_epi32(a, b), which maps to the vpmulld instruction (Multiply the packed 32-bit integers in a and b, producing intermediate 64-bit integers, and store the low 32 bits of the intermediate integers in dst), which for your testcase would result in eight 32-bit integers with value 2. _mm256_mul_epi32(a, b) maps to vpmuldq (Multiply the low 32-bit integers from each packed 64-bit element in a and b, and store the signed 64-bit results in dst), which for your testcase correctly gives four 64-bit integers with value 2.
[Bug tree-optimization/68806] New: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68806
Bug ID: 68806
Summary: internal compiler error: Segmentation fault
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jamrial at gmail dot com
Target Milestone: ---
Created attachment 36967
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36967&action=edit
Preprocessed source as generated by -freport-bug
/home/jamrial/x265/source/common/pixel.cpp: In function ‘int
{anonymous}::sad(const pixel*, intptr_t, const pixel*, intptr_t) [with int lx =
12; int ly = 16]’:
/home/jamrial/x265/source/common/pixel.cpp:40:5: internal compiler error:
Segmentation fault
int sad(const pixel* pix1, intptr_t stride_pix1, const pixel* pix2, intptr_t
stride_pix2)
^~~
0xcd660f crash_signal
/home/jamrial/gcc-svn/gcc/toplev.c:334
0x5b8f7d vec::operator[](unsigned int)
/home/jamrial/gcc-svn/gcc/vec.h:1180
0x5b8f7d vect_create_epilog_for_reduction
/home/jamrial/gcc-svn/gcc/tree-vect-loop.c:5000
0xf1cc4a vectorizable_reduction(gimple*, gimple_stmt_iterator*, gimple**,
_slp_tree*)
/home/jamrial/gcc-svn/gcc/tree-vect-loop.c:6172
0xf14550 vect_transform_stmt(gimple*, gimple_stmt_iterator*, bool*, _slp_tree*,
_slp_instance*)
/home/jamrial/gcc-svn/gcc/tree-vect-stmts.c:8224
0xf1a544 vect_transform_loop(_loop_vec_info*)
/home/jamrial/gcc-svn/gcc/tree-vect-loop.c:6865
0xf35f97 vectorize_loops()
/home/jamrial/gcc-svn/gcc/tree-vectorizer.c:554
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.
[Bug inline-asm/68952] New: Wrong code with AVX inline-asm in 32-bit mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68952
Bug ID: 68952
Summary: Wrong code with AVX inline-asm in 32-bit mode
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: inline-asm
Assignee: unassigned at gcc dot gnu.org
Reporter: jamrial at gmail dot com
Target Milestone: ---
Regression since GCC 4.9.0. -O0, -O1, -O2 and -O3 are all affected. -Os works
as intended.
float clipf(float a, float amin, float amax)
{
float ret;
__asm__ ("vminss %1, %3, %0 \n\t"
"vmaxss %2, %0, %0 \n\t"
: "=x"(ret) : "xm"(a), "x"(amin), "x"(amax));
return ret;
}
gcc-trunk -O2 -mavx -m32
gcc-5.3 -O2 -mavx -m32
gcc-4.9.2 -O2 -mavx -m32
subl$4, %esp
vmovss 16(%esp), %xmm1
vmovss 12(%esp), %xmm0
vminss 8(%esp), %xmm1, %xmm0 <--- amin overwritten
vmaxss %xmm0, %xmm0, %xmm0
vmovss %xmm0, (%esp)
flds(%esp)
addl$4, %esp
ret
gcc-4.8.2 -O2 -mavx -m32
subl$4, %esp
vmovss 16(%esp), %xmm1
vmovss 12(%esp), %xmm0
vminss 8(%esp), %xmm1, %xmm2
vmaxss %xmm0, %xmm2, %xmm2
vmovss %xmm2, (%esp)
flds(%esp)
addl$4, %esp
ret
gcc-trunk -Os -mavx -m32
gcc-5.3 -Os -mavx -m32
gcc-4.9.2 -Os -mavx -m32
pushl %ebp
movl%esp, %ebp
pushl %eax
vmovss 16(%ebp), %xmm1
vmovss 12(%ebp), %xmm0
vminss 8(%ebp), %xmm1, %xmm2
vmaxss %xmm0, %xmm2, %xmm2
vmovss %xmm2, -4(%ebp)
flds-4(%ebp)
leave
ret
[Bug c++/69203] New: ICE in potential_constant_expression_1, at cp/constexpr.c:4754
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69203 Bug ID: 69203 Summary: ICE in potential_constant_expression_1, at cp/constexpr.c:4754 Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jamrial at gmail dot com Target Milestone: --- Created attachment 37282 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37282&action=edit Preprocessed source as generated by -freport-bug /home/jamrial/range-v3/include/range/v3/utility/concepts.hpp:509:41: sorry, unimplemented: unexpected AST of kind loop_expr concepts::valid_expr( ^ (t.~T(), 42), ~ concepts::is_true(std::is_nothrow_destructible()), ~ concepts::has_type(&t), ~~~ concepts::has_type(&std::declval()), (delete p, 42), ~~~ (delete[] p, 42) )); ~ /home/jamrial/range-v3/include/range/v3/utility/concepts.hpp:509:41: internal compiler error: in potential_constant_expression_1, at cp/constexpr.c:4754 0x81ace8 potential_constant_expression_1 /home/jamrial/gcc-svn/gcc/cp/constexpr.c:4754 0x81a04f potential_constant_expression_1 /home/jamrial/gcc-svn/gcc/cp/constexpr.c:4692 0x81a04f potential_constant_expression_1 /home/jamrial/gcc-svn/gcc/cp/constexpr.c:4692 0x81aa81 potential_constant_expression_1 /home/jamrial/gcc-svn/gcc/cp/constexpr.c:4724 0x81a04f potential_constant_expression_1 /home/jamrial/gcc-svn/gcc/cp/constexpr.c:4692 0x81b623 potential_constant_expression(tree_node*) /home/jamrial/gcc-svn/gcc/cp/constexpr.c:4765 0x81b623 maybe_constant_value_1 /home/jamrial/gcc-svn/gcc/cp/constexpr.c:3941 0x81b623 maybe_constant_value(tree_node*, tree_node*) /home/jamrial/gcc-svn/gcc/cp/constexpr.c:3972 0x5da781 build_over_call /home/jamrial/gcc-svn/gcc/cp/call.c:7537 0x5eab81 build_op_call_1 /home/jamrial/gcc-svn/gcc/cp/call.c:4384 0x5eab81 build_op_call(tree_node*, vec**, int) /home/jamrial/gcc-svn/gcc/cp/call.c:4407 0x786378 finish_call_expr(tree_node*, vec**, bool, bool, int) /home/jamrial/gcc-svn/gcc/cp/semantics.c:2430 0x6527a2 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) /home/jamrial/gcc-svn/gcc/cp/pt.c:16489 0x655145 tsubst(tree_node*, tree_node*, int, tree_node*) /home/jamrial/gcc-svn/gcc/cp/pt.c:13417 0x665368 tsubst_function_type /home/jamrial/gcc-svn/gcc/cp/pt.c:12481 0x6554d7 tsubst(tree_node*, tree_node*, int, tree_node*) /home/jamrial/gcc-svn/gcc/cp/pt.c:13244 0x65da7c tsubst_decl /home/jamrial/gcc-svn/gcc/cp/pt.c:11692 0x655bde tsubst(tree_node*, tree_node*, int, tree_node*) /home/jamrial/gcc-svn/gcc/cp/pt.c:12697 0x66eeeb instantiate_template_1 /home/jamrial/gcc-svn/gcc/cp/pt.c:17256 0x66eeeb instantiate_template(tree_node*, tree_node*, int) /home/jamrial/gcc-svn/gcc/cp/pt.c:17307
[Bug tree-optimization/69320] New: wrong code generation at -O2 and higher
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69320
Bug ID: 69320
Summary: wrong code generation at -O2 and higher
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jamrial at gmail dot com
Target Milestone: ---
Created attachment 37377
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37377&action=edit
Assembly and preprocessed output of miscompiled file
http://fate.ffmpeg.org/report.cgi?time=20160116195307&slot=x86_64-archlinux-gcc-experimental
https://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/svq1enc.c;h=1e1745e7b10ed24e8a600d643b5aa951317f2aba;hb=HEAD
FFmpeg's svq1 encoder is being miscompiled by GCC 6 starting with revision
r232361. I'm attaching example assembly of the last good commit and the first
bad, alongside the preprocessed output.
To reproduce the issue you can download ffmpeg and run the fate svq1 tests (no
external samples needed to run), which will fail and create output video files
full of artifacts from the revision mentioned above onward:
git clone https://git.videolan.org/git/ffmpeg.git && cd ffmpeg && ./configure
&& make fate-vsynth{1,2,3}-svq1
[Bug c++/69203] ICE in potential_constant_expression_1, at cp/constexpr.c:4754
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69203 James Almer changed: What|Removed |Added Attachment #37282|0 |1 is obsolete|| --- Comment #2 from James Almer --- Created attachment 37439 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37439&action=edit New preprocessed source as generated by -freport-bug No, it's not fixed. Here's a new pre-processed output using svn trunk. Compile it with "std=c++14 -Wall", otherwise it apparently will not ICE. For example "g++ -std=c++14 -ftemplate-backtrace-limit=0 -Wall 69203_2.ii"
[Bug c++/66067] [6 Regression] tree check ICE: accessed elt 1 of tree_vec with 0 elts in write_template_args, at cp/mangle.c:2574
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66067 --- Comment #5 from James Almer --- Created attachment 35683 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35683&action=edit Preprocessed source as generated by -freport-bug, third test case, gcc 5.1.1 svn 223417 How about this one? Crashes with segmentation fault on gcc 5.1.1 svn 223417 (ArchLinux x86_64). With gcc 6.0.0 svn 223906 it crashes with apparently the same tree_check ICE as the first test case. I can post that -freport-bug output if needed.
[Bug c++/66067] [6 Regression] tree check ICE: accessed elt 1 of tree_vec with 0 elts in write_template_args, at cp/mangle.c:2574
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66067 --- Comment #7 from James Almer --- (In reply to Markus Trippelsdorf from comment #6) > (In reply to James Almer from comment #5) > > Created attachment 35683 [details] > > Preprocessed source as generated by -freport-bug, third test case, gcc 5.1.1 > > svn 223417 > > > > How about this one? Crashes with segmentation fault on gcc 5.1.1 > > (ArchLinux x86_64). > > > > With gcc 6.0.0 svn 223906 it crashes with apparently the same tree_check ICE > > as the first test case. > > I can post that -freport-bug output if needed. > > I'm using "gcc version 5.1.1 20150519". > Will recheck with an updated version tomorrow. That's the one that crashed for me with this new test case. svn 223417 (used for the 20150519 weekly snapshot).
[Bug c++/66067] [6 Regression] tree check ICE: accessed elt 1 of tree_vec with 0 elts in write_template_args, at cp/mangle.c:2574
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66067 --- Comment #8 from James Almer --- (In reply to James Almer from comment #7) > (In reply to Markus Trippelsdorf from comment #6) > > (In reply to James Almer from comment #5) > > > Created attachment 35683 [details] > > > Preprocessed source as generated by -freport-bug, third test case, gcc > > > 5.1.1 > > > svn 223417 > > > > > > How about this one? Crashes with segmentation fault on gcc 5.1.1 > > > (ArchLinux x86_64). > > > > > > With gcc 6.0.0 svn 223906 it crashes with apparently the same tree_check > > > ICE > > > as the first test case. > > > I can post that -freport-bug output if needed. > > > > I'm using "gcc version 5.1.1 20150519". > > Will recheck with an updated version tomorrow. > > That's the one that crashed for me with this new test case. svn 223417 (used > for the 20150519 weekly snapshot). Looks like a heisenbug. Can't reproduce it when i use the preprocessed output created by -freport-bug, only when i try to normally compile the file. If the same happens in your end, you could try (with gcc 5.1.1): git clone https://github.com/ericniebler/range-v3.git cd range-v3 && mkdir build && cd build cmake .. && make alg.partial_sort_copy
[Bug c++/66067] [6 Regression] tree check ICE: accessed elt 1 of tree_vec with 0 elts in write_template_args, at cp/mangle.c:2574
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66067 --- Comment #10 from James Almer --- (In reply to Markus Trippelsdorf from comment #9) > I've tested latest gcc-5 branch and still cannot reproduce the issue. > The only ICE I get building range-v3 is PR66405. Odd. I'll see about reporting the gcc 5 segmentation fault to ArchLinux (It's their x86_64 gcc package). Sorry for the noise. Let this bug report be for the tree check gcc 6 ICE from the first comment only.
[Bug c++/66426] New: ICE: unexpected expression ‘int(Constructible())...’ of kind expr_pack_expansion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66426
Bug ID: 66426
Summary: ICE: unexpected expression ‘int(Constructible())...’
of kind expr_pack_expansion
Product: gcc
Version: 4.9.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jamrial at gmail dot com
Target Milestone: ---
[jamrial@archVM ~]$ cat zip.c
template struct A;
template struct enable_if;
template struct B;
template using and_c = A>;
template using Constructible = int;
template struct common_tuple {
template <
typename... Us,
typename enable_if()...>::value>::type>
};
[jamrial@archVM ~]$ g++-trunk -O2 -std=c++11 -c zip2.c
zip2.c:10:1: error: expected unqualified-id before ‘}’ token
};
^
[jamrial@archVM ~]$ g++-5.1 -O2 -std=c++11 -c zip2.c
zip2.c:10:1: error: expected unqualified-id before ‘}’ token
};
^
[jamrial@archVM ~]$ g++-4.9 -O2 -std=c++11 -c zip.c
zip.c:9:63: internal compiler error: unexpected expression
‘int(Constructible())...’ of kind expr_pack_expansion
typename enable_if()...>::value>::type>
^
0x61cbd6 cxx_eval_constant_expression
/home/jamrial/gcc-4.9-20150603/gcc/cp/semantics.c:9833
0x61e5b6 cxx_eval_outermost_constant_expr
/home/jamrial/gcc-4.9-20150603/gcc/cp/semantics.c:9853
0x585cb0 convert_nontype_argument
/home/jamrial/gcc-4.9-20150603/gcc/cp/pt.c:5698
0x585cb0 convert_template_argument
/home/jamrial/gcc-4.9-20150603/gcc/cp/pt.c:6590
0x582252 coerce_template_parameter_pack
/home/jamrial/gcc-4.9-20150603/gcc/cp/pt.c:6713
0x582252 coerce_template_parms
/home/jamrial/gcc-4.9-20150603/gcc/cp/pt.c:6922
0x586c70 lookup_template_class_1
/home/jamrial/gcc-4.9-20150603/gcc/cp/pt.c:7594
0x586c70 lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
/home/jamrial/gcc-4.9-20150603/gcc/cp/pt.c:7895
0x6149b2 finish_template_type(tree_node*, tree_node*, int)
/home/jamrial/gcc-4.9-20150603/gcc/cp/semantics.c:2969
0x5d63fa cp_parser_template_id
/home/jamrial/gcc-4.9-20150603/gcc/cp/parser.c:13464
0x5d6613 cp_parser_class_name
/home/jamrial/gcc-4.9-20150603/gcc/cp/parser.c:19195
0x5cc673 cp_parser_qualifying_entity
/home/jamrial/gcc-4.9-20150603/gcc/cp/parser.c:5538
0x5cc673 cp_parser_nested_name_specifier_opt
/home/jamrial/gcc-4.9-20150603/gcc/cp/parser.c:5263
0x5e0ee2 cp_parser_simple_type_specifier
/home/jamrial/gcc-4.9-20150603/gcc/cp/parser.c:14666
0x5c3ebd cp_parser_type_specifier
/home/jamrial/gcc-4.9-20150603/gcc/cp/parser.c:14412
0x5c65cb cp_parser_type_specifier_seq
/home/jamrial/gcc-4.9-20150603/gcc/cp/parser.c:18137
0x5d4ee2 cp_parser_type_id_1
/home/jamrial/gcc-4.9-20150603/gcc/cp/parser.c:18010
0x5d4fde cp_parser_template_type_arg
/home/jamrial/gcc-4.9-20150603/gcc/cp/parser.c:18059
0x5d51d8 cp_parser_template_argument
/home/jamrial/gcc-4.9-20150603/gcc/cp/parser.c:13840
0x5d51d8 cp_parser_template_argument_list
/home/jamrial/gcc-4.9-20150603/gcc/cp/parser.c:13750
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.
Testcase based on the one from Comment 2 of pr66405.
[Bug c++/66426] ICE: unexpected expression ‘int(Constructible())...’ of kind expr_pack_expansion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66426
--- Comment #1 from James Almer ---
FWIW, testcase from Comment 2 of pr66405 unedited:
[jamrial@archVM ~]$ cat pr66405_c2.cpp
template struct A;
template struct enable_if;
template struct B;
template using and_c = A>;
template using Constructible = int;
template struct common_tuple {
template <
typename... Us,
typename enable_if()...>::value>::type>
common_tuple();
void foo();
};
template <> void common_tuple<>::foo(){};
[jamrial@archVM ~]$ g++-4.9 -O2 -std=c++11 -c pr66405_c2.cpp
pr66405_c2.cpp:9:63: internal compiler error: unexpected expression
‘int(Constructible())...’ of kind expr_pack_expansion
typename enable_if()...>::value>::type>
^
0x61cbd6 cxx_eval_constant_expression
/home/jamrial/gcc-4.9-20150603/gcc/cp/semantics.c:9833
0x61e5b6 cxx_eval_outermost_constant_expr
/home/jamrial/gcc-4.9-20150603/gcc/cp/semantics.c:9853
0x585cb0 convert_nontype_argument
/home/jamrial/gcc-4.9-20150603/gcc/cp/pt.c:5698
0x585cb0 convert_template_argument
/home/jamrial/gcc-4.9-20150603/gcc/cp/pt.c:6590
0x582252 coerce_template_parameter_pack
/home/jamrial/gcc-4.9-20150603/gcc/cp/pt.c:6713
0x582252 coerce_template_parms
/home/jamrial/gcc-4.9-20150603/gcc/cp/pt.c:6922
0x586c70 lookup_template_class_1
/home/jamrial/gcc-4.9-20150603/gcc/cp/pt.c:7594
0x586c70 lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
/home/jamrial/gcc-4.9-20150603/gcc/cp/pt.c:7895
0x6149b2 finish_template_type(tree_node*, tree_node*, int)
/home/jamrial/gcc-4.9-20150603/gcc/cp/semantics.c:2969
0x5d63fa cp_parser_template_id
/home/jamrial/gcc-4.9-20150603/gcc/cp/parser.c:13464
0x5d6613 cp_parser_class_name
/home/jamrial/gcc-4.9-20150603/gcc/cp/parser.c:19195
0x5cc673 cp_parser_qualifying_entity
/home/jamrial/gcc-4.9-20150603/gcc/cp/parser.c:5538
0x5cc673 cp_parser_nested_name_specifier_opt
/home/jamrial/gcc-4.9-20150603/gcc/cp/parser.c:5263
0x5e0ee2 cp_parser_simple_type_specifier
/home/jamrial/gcc-4.9-20150603/gcc/cp/parser.c:14666
0x5c3ebd cp_parser_type_specifier
/home/jamrial/gcc-4.9-20150603/gcc/cp/parser.c:14412
0x5c65cb cp_parser_type_specifier_seq
/home/jamrial/gcc-4.9-20150603/gcc/cp/parser.c:18137
0x5d4ee2 cp_parser_type_id_1
/home/jamrial/gcc-4.9-20150603/gcc/cp/parser.c:18010
0x5d4fde cp_parser_template_type_arg
/home/jamrial/gcc-4.9-20150603/gcc/cp/parser.c:18059
0x5d51d8 cp_parser_template_argument
/home/jamrial/gcc-4.9-20150603/gcc/cp/parser.c:13840
0x5d51d8 cp_parser_template_argument_list
/home/jamrial/gcc-4.9-20150603/gcc/cp/parser.c:13750
And testcase taken from gcc/testsuite/g++.dg/cpp0x/variadic-alias1.C (added in
svn 224163)
[jamrial@archVM ~]$ cat Varidic-alias1.C
template struct B;
template using and_c = B;
template using Constructible = int;
template struct common_tuple {
template {}...> >
common_tuple();
void foo();
};
template <> void common_tuple<>::foo(){}
[jamrial@archVM ~]$ g++-4.9 -O2 -std=c++11 -c Varidic-alias1.C
Varidic-alias1.C:6:55: internal compiler error: unexpected expression ‘{}...’
of kind expr_pack_expansion
typename = and_c{}...> >
^
0x61cbd6 cxx_eval_constant_expression
/home/jamrial/gcc-4.9-20150603/gcc/cp/semantics.c:9833
0x61e5b6 cxx_eval_outermost_constant_expr
/home/jamrial/gcc-4.9-20150603/gcc/cp/semantics.c:9853
0x585cb0 convert_nontype_argument
/home/jamrial/gcc-4.9-20150603/gcc/cp/pt.c:5698
0x585cb0 convert_template_argument
/home/jamrial/gcc-4.9-20150603/gcc/cp/pt.c:6590
0x582252 coerce_template_parameter_pack
/home/jamrial/gcc-4.9-20150603/gcc/cp/pt.c:6713
0x582252 coerce_template_parms
/home/jamrial/gcc-4.9-20150603/gcc/cp/pt.c:6922
0x586c70 lookup_template_class_1
/home/jamrial/gcc-4.9-20150603/gcc/cp/pt.c:7594
0x586c70 lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
/home/jamrial/gcc-4.9-20150603/gcc/cp/pt.c:7895
0x6149b2 finish_template_type(tree_node*, tree_node*, int)
/home/jamrial/gcc-4.9-20150603/gcc/cp/semantics.c:2969
0x5d63fa cp_parser_template_id
/home/jamrial/gcc-4.9-20150603/gcc/cp/parser.c:13464
0x5d6613 cp_parser_class_name
/home/jamrial/gcc-4.9-20150603/gcc/cp/parser.c:19195
0x5cc673 cp_parser_qualifying_entity
/home/jamrial/gcc-4.9-20150603/gcc/cp/parser.c:5538
0x5cc673 cp_parser_nested_name_specifier_opt
/home/jamrial/gcc-4.9-20150603/gcc/cp/parser.c:5263
0x5e0ee2 cp_parser_simple_type_specifier
/home/jamrial/gcc-4.9-20150603/gcc/cp/parser.c:14666
0x5c3ebd cp_parser_type_specifier
/home/jamrial/gcc-4.9-20150603/gcc/cp/parser.c:14412
0x5c65cb cp_parser_type_specifier_seq
/home/jamrial/gcc-4.9-20150603/gcc/c
[Bug target/65871] bzhi builtin/intrinsic wrongly assumes bzhi instruction doesn't set the ZF flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65871 --- Comment #9 from James Almer --- Created attachment 35804 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35804&action=edit Preprocessed code where a test instruction is still generated Please look at the attachment. [jamrial@archVM ~]$ gcc -std=c99 -march=haswell -O3 -c hevc_ps.i [jamrial@archVM ~]$ objdump --disassemble hevc_ps.o | grep -B2 -A2 bzhi 5854: c4 62 22 f7 d6 sarx %r11d,%esi,%r10d 5859: c4 62 22 f7 da sarx %r11d,%edx,%r11d 585e: c4 e2 70 f5 f6 bzhi %ecx,%esi,%esi 5863: 45 89 9e 68 33 00 00mov%r11d,0x3368(%r14) 586a: 41 89 c3mov%eax,%r11d -- 589d: 85 f6 test %esi,%esi 589f: 75 0d jne58ae 58a1: c4 e2 70 f5 d2 bzhi %ecx,%edx,%edx 58a6: 85 d2 test %edx,%edx 58a8: 0f 84 5a 03 00 00 je 5c08 [jamrial@archVM ~]$ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/local/lib/gcc/x86_64-unknown-linux-gnu/6.0.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /home/jamrial/gcc-svn/configure --prefix=/usr/local --libdir=/usr/local/lib --libexecdir=/usr/local/lib --mandir=/usr/local/share/man --infodir=/usr/local/share/info --enable-languages=c,c++,lto --enable-shared --disable-bootstrap --enable-threads=posix --enable-libmpx --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object --enable-linker-build-id --enable-lto --enable-plugin --enable-install-libiberty --with-linker-hash-style=gnu --enable-gnu-indirect-function --disable-multilib --disable-werror Thread model: posix gcc version 6.0.0 20150618 (experimental) (GCC) Not sure why the new model is not working here.
[Bug target/59767] __atomic_load_n with __ATOMIC_SEQ_CST should result in a memory barrier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59767
James Almer changed:
What|Removed |Added
CC||jamrial at gmail dot com
--- Comment #1 from James Almer ---
This still happens with gcc 4.9 and gcc 5.
int foo(int *bar)
{
return *bar;
}
and
int foo(int *bar)
{
return __atomic_load_n(bar, __ATOMIC_SEQ_CST);
}
Generate the exact same assembly. The latter should add an mfence before the
mov instruction.
[Bug middle-end/66872] fold a & ((1 << b) - 1) to a & ~(-1 << b)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66872 James Almer changed: What|Removed |Added CC||jamrial at gmail dot com --- Comment #1 from James Almer --- Ideally, for -mbmi2 (which is enabled with -march=haswell) the compiler should generate a single bzhi instruction instead, as i mentioned in pr65871. The generated code for your example would then be bzhi%esi, %edi, %eax ret Also, left shift of negative value is undefined behavior in C. Try compiling that code with -Wshift-negative-value using gcc trunk.
[Bug c++/72457] New: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72457
Bug ID: 72457
Summary: internal compiler error: Segmentation fault
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jamrial at gmail dot com
Target Milestone: ---
Created attachment 39010
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39010&action=edit
Preprocessed output as created by -freport-bug
/home/jamrial/range-v3/include/range/v3/utility/box.hpp:198:14: internal
compiler error: Segmentation fault
{}
^
0xd6e91f crash_signal
/home/jamrial/gcc-svn/gcc/toplev.c:335
0x86e332 cx_check_missing_mem_inits
/home/jamrial/gcc-svn/gcc/cp/constexpr.c:740
0x87def1 cx_check_missing_mem_inits
/home/jamrial/gcc-svn/gcc/hash-table.h:906
0x87def1 register_constexpr_fundef(tree_node*, tree_node*)
/home/jamrial/gcc-svn/gcc/cp/constexpr.c:800
0x67a190 maybe_save_function_definition
/home/jamrial/gcc-svn/gcc/cp/decl.c:14619
0x67a190 finish_function(int)
/home/jamrial/gcc-svn/gcc/cp/decl.c:14744
0x6aa5d6 instantiate_decl(tree_node*, int, bool)
/home/jamrial/gcc-svn/gcc/cp/pt.c:22170
0x7330ac mark_used(tree_node*, int)
/home/jamrial/gcc-svn/gcc/cp/decl2.c:5290
0x63f4f0 build_over_call
/home/jamrial/gcc-svn/gcc/cp/call.c:7818
0x64af0f build_new_method_call_1
/home/jamrial/gcc-svn/gcc/cp/call.c:8543
0x64af0f build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
/home/jamrial/gcc-svn/gcc/cp/call.c:8613
0x64be95 build_special_member_call(tree_node*, tree_node*, vec**, tree_node*, int, int)
/home/jamrial/gcc-svn/gcc/cp/call.c:8139
0x7bfa06 expand_default_init
/home/jamrial/gcc-svn/gcc/cp/init.c:1748
0x7bfa06 expand_aggr_init_1
/home/jamrial/gcc-svn/gcc/cp/init.c:1863
0x7c66a0 emit_mem_initializers(tree_node*)
/home/jamrial/gcc-svn/gcc/cp/init.c:1166
0x6afcc3 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/jamrial/gcc-svn/gcc/cp/pt.c:15222
0x6ad89a tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/jamrial/gcc-svn/gcc/cp/pt.c:15401
0x6aa52b instantiate_decl(tree_node*, int, bool)
/home/jamrial/gcc-svn/gcc/cp/pt.c:22148
0x7330ac mark_used(tree_node*, int)
/home/jamrial/gcc-svn/gcc/cp/decl2.c:5290
0x63f4f0 build_over_call
/home/jamrial/gcc-svn/gcc/cp/call.c:7818
Make sure to compile the preprocessed source with -Wall or it will not trigger
the ICE.
[Bug c++/66426] ICE: unexpected expression ‘int(Constructible())...’ of kind expr_pack_expansion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66426 James Almer changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #2 from James Almer --- Closing this as 4.9.4 was released and support for 4.9 has ended. I did not check to see if the issue can still be reproduced with 4.9.4
