[Bug ipa/79337] [7 Regression] Significant memory leaks in IPA CP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79337 --- Comment #1 from Martin Liška --- Author: marxin Date: Fri Feb 3 08:20:02 2017 New Revision: 245145 URL: https://gcc.gnu.org/viewcvs?rev=245145&root=gcc&view=rev Log: Fix memory leaks in IPA CP (PR ipa/79337). 2017-02-03 Martin Liska PR ipa/79337 * ipa-prop.c (ipa_node_params_t::insert): Remove current implementation. (ipa_node_params_t::remove): Likewise. * ipa-prop.h (ipa_node_params::ipa_node_params): Make default initialization from removed ipa_node_params_t::insert. (ipa_node_params::~ipa_node_params): Move from removed ipa_node_params_t::release. * symbol-summary.h (symbol_summary::m_released): New member. Do not release a summary twice. Do not allow to call finalizer for types of a summary that live in GGC memory. Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-prop.c trunk/gcc/ipa-prop.h trunk/gcc/symbol-summary.h
[Bug tree-optimization/79339] [7 Regression] Memory leak in gimple-ssa-sprintf.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79339 --- Comment #2 from Martin Liška --- Author: marxin Date: Fri Feb 3 08:20:57 2017 New Revision: 245146 URL: https://gcc.gnu.org/viewcvs?rev=245146&root=gcc&view=rev Log: Fix memory leaks in gimple-ssa-sprintf.c (PR tree-optimization/79339). 2017-02-03 Martin Liska PR tree-optimization/79339 * gimple-ssa-sprintf.c (format_floating_max): Call mpfr_clear. (format_floating): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/gimple-ssa-sprintf.c
[Bug tree-optimization/79339] [7 Regression] Memory leak in gimple-ssa-sprintf.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79339 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Martin Liška --- Fixed.
[Bug ipa/79337] [7 Regression] Significant memory leaks in IPA CP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79337 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Martin Liška --- Fixed.
[Bug fortran/79335] [7 Regression] Conditional jump or move depends on uninitialised in value get_scalar_to_descriptor_type(tree_node*, symbol_attribute) (trans-expr.c:53)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79335 --- Comment #1 from Martin Liška --- Jeff, increasing priority would be good as it triggers many uninitialised warnings in valgrind that makes it hard to distinguish between this PR and a possibly different one. Thanks.
[Bug lto/79061] [7 Regression][LTO][ASAN] LTO plus ASAN fails with "AddressSanitizer: initialization-order-fiasco"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79061 --- Comment #33 from chefmax at gcc dot gnu.org --- Author: chefmax Date: Fri Feb 3 09:13:06 2017 New Revision: 245148 URL: https://gcc.gnu.org/viewcvs?rev=245148&root=gcc&view=rev Log: PR lto/79061 * asan.c (asan_add_global): Force has_dynamic_init to zero in LTO mode. Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/asan.c
[Bug other/79341] Many Asan tests fail on s390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341 --- Comment #4 from Dominik Vogt --- From /sysdeps/s390/dl-tls.h: /* The special thing about the s390 TLS ABI is that we do not have the standard __tls_get_addr function but the __tls_get_offset function which differs in two important aspects: 1) __tls_get_offset gets a got offset instead of a pointer to the tls_index structure 2) __tls_get_offset returns the offset of the requested variable to the thread descriptor instead of a pointer to the variable. */ So, ist a NULL function called here because __tls_get_addr_internal does not exist?
[Bug other/79341] Many Asan tests fail on s390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341 --- Comment #5 from Dominik Vogt --- Okay, the symbol __tls_get_addr_internal exists since Glibc-2.19 on s390*, and the test machine has Glibc-2.18. Is this something that needs to be fixed in libsanitizer, or does the test machine need an upgrade?
[Bug other/79341] Many Asan tests fail on s390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341 --- Comment #6 from Andreas Krebbel --- I don't think modifying libsanitizer to support older Glibcs is required. The only change we might want to consider is adding a configure check to libsanitizer.
[Bug other/79341] Many Asan tests fail on s390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #7 from Jakub Jelinek ---
Ah, that might explain this, I've been using glibc 2.25 prerelease during
testing.
The glibc change has been a fix for
https://sourceware.org/bugzilla/show_bug.cgi?id=16214
I don't know the s390{,x} TLS good enough to judge whether this is something
fixable in libsanitizer (if acceptable for upstream, then for compiler-rt, if
not, as gcc local patch), or whether we just should in configure.tgt say
UNSUPPORTED for glibc 2.19 (or whatever is the oldest glibc that works with
it).
I can help with the configure.tgt check if we decide to go that way, provided
we know the minimum glibc version.
[Bug other/79341] Many Asan tests fail on s390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341 --- Comment #8 from Dominik Vogt --- The symbol was introduced to Glibc after 2.18 and before 2.19.
[Bug other/79341] Many Asan tests fail on s390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341 --- Comment #9 from Jakub Jelinek --- gcc/configure.ac has: # Determine the version of glibc, if any, used on the target. AC_MSG_CHECKING([for target glibc version]) AC_ARG_WITH([glibc-version], [AS_HELP_STRING([--with-glibc-version=M.N], [assume GCC used with glibc version M.N or later])], [ if [echo "$with_glibc_version" | grep '^[0-9][0-9]*\.[0-9][0-9]*$']; then glibc_version_major=`echo "$with_glibc_version" | sed -e 's/\..*//'` glibc_version_minor=`echo "$with_glibc_version" | sed -e 's/.*\.//'` else AC_MSG_ERROR([option --with-glibc-version requires a version number M.N]) fi], [ glibc_version_major=0 glibc_version_minor=0 [if test -f $target_header_dir/features.h \ && glibc_version_major_define=`$EGREP '^[ ]*#[]*define[ ]+__GLIBC__[]+[0-9]' $target_header_dir/features.h` \ && glibc_version_minor_define=`$EGREP '^[ ]*#[]*define[ ]+__GLIBC_MINOR__[ ]+[0-9]' $target_header_dir/features.h`; then glibc_version_major=`echo "$glibc_version_major_define" | sed -e 's/.*__GLIBC__[ ]*//'` glibc_version_minor=`echo "$glibc_version_minor_define" | sed -e 's/.*__GLIBC_MINOR__[]*//'` fi]]) AC_MSG_RESULT([$glibc_version_major.$glibc_version_minor]) AC_DEFINE_UNQUOTED([TARGET_GLIBC_MAJOR], [$glibc_version_major], [GNU C Library major version number used on the target, or 0.]) AC_DEFINE_UNQUOTED([TARGET_GLIBC_MINOR], [$glibc_version_minor], [GNU C Library minor version number used on the target, or 0.]) The problem is that this isn't available in the toplevel configure when sourcing libsanitizer/configure.tgt to decide easily on UNSUPPORTED. So we'd have to say supported there and later perhaps change that. Seems we have already a precedent, libsanitizer/configure.ac has: AC_MSG_CHECKING([for necessary platform features]) case "$target" in *-*-linux*) # Some old Linux distributions miss required syscalls. sanitizer_supported=no AC_TRY_COMPILE([#include ],[ syscall (__NR_gettid); syscall (__NR_futex); syscall (__NR_exit_group); ], [sanitizer_supported=yes]) ;; *) sanitizer_supported=yes ;; esac AC_MSG_RESULT($sanitizer_supported) AM_CONDITIONAL(SANITIZER_SUPPORTED, test "$sanitizer_supported" = yes) so it should then for s390*-*-linux* also test for glibc >= 2.19 using AC_TRY_COMPILE and preprocessor macros or so?
[Bug other/79341] Many Asan tests fail on s390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341 --- Comment #10 from Jakub Jelinek --- (In reply to Jakub Jelinek from comment #9) Perhaps say: AC_TRY_COMPILE([#include ],[ syscall (__NR_gettid); syscall (__NR_futex); syscall (__NR_exit_group); +#if (defined(__s390__) || defined(__s390x__)) && !__GLIBC_PREREQ (2, 19) +#error Too old glibc +#endif ], [sanitizer_supported=yes])
[Bug target/79353] [7 regression] ICE in curr_insn_transform, at lra-constraints.c:3773
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79353 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2017-02-03 CC||ebotcazou at gcc dot gnu.org Target Milestone|--- |7.0 Summary|ICE in curr_insn_transform, |[7 regression] ICE in |at lra-constraints.c:3773 |curr_insn_transform, at ||lra-constraints.c:3773 Ever confirmed|0 |1 --- Comment #1 from Eric Botcazou --- > Currently don't have the preprocessed as this was a build on a buildd. But I > can do a manual build easily and provide the preprocessed source if necessary. Yes, please.
[Bug other/79341] Many Asan tests fail on s390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341 --- Comment #11 from Dominik Vogt --- Hm, Stefan says that RHEL 7.3 has a Glibc-2.17 with a backport of the patch.
[Bug fortran/79335] [7 Regression] Conditional jump or move depends on uninitialised in value get_scalar_to_descriptor_type(tree_node*, symbol_attribute) (trans-expr.c:53)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79335 --- Comment #2 from vehre at gcc dot gnu.org --- Gfortran is a P4 project. Higher than P4 is not possible.
[Bug other/79341] Many Asan tests fail on s390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341 --- Comment #12 from Dominik Vogt --- > so it should then for s390*-*-linux* also test for glibc >= 2.19 using > AC_TRY_COMPILE and preprocessor macros or so? Or something like $ nm /lib/ld-*.*.so | grep __tls_get_addr_internal ?
[Bug other/79341] Many Asan tests fail on s390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #13 from Dominik Vogt ---
The opinion of whoever added the S390 code to sanitizer_common_interceptors.inc
("chefmax") might help?
[Bug other/79341] Many Asan tests fail on s390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341 --- Comment #14 from Jakub Jelinek --- Another option is executable testcase trying to dlsym __tls_get_addr_internal (but that is not cross-compilation friendly), or perhaps nm or readelf on the dynamic linker (but that is not really that easy for cross-compilation either, one has to find it in a sysroot etc.). Perhaps the glibc version check and if that check fails and not cross-compiling, try the dlsym way?
[Bug middle-end/78468] [7 regression] libgomp.c/reduction-10.c and many more FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78468 --- Comment #34 from Eric Botcazou --- > I still disagree with reverting the patch. There was plenty of time to > identify and fix affected backends instead of doing nothing for half five > months and then claiming that the patch is potentially too disruptive at > this point in the release cycle. That was your job though and apparently you didn't do it.
[Bug other/79341] Many Asan tests fail on s390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
Jakub Jelinek changed:
What|Removed |Added
CC||m.ostapenko at samsung dot com
--- Comment #15 from Jakub Jelinek ---
(In reply to Dominik Vogt from comment #13)
> The opinion of whoever added the S390 code to
> sanitizer_common_interceptors.inc ("chefmax") might help?
Maxim has just merged the code from upstream. compiler-rt svn says:
273041 koriakin #else // SANITIZER_S390
273041 koriakin // On s390, we have to intercept two functions here:
273041 koriakin // - __tls_get_addr_internal, which is a glibc-internal
function that is like
273041 koriakin // the usual __tls_get_addr, but returns a TP-relative
offset instead of
...
We would need to ask upstream. That said, the usual resolution upstream is
that they are only interested in latest OSes, compatibility for older releases
is sometimes just a low priority, but often actively unwanted there.
[Bug sanitizer/78663] [7 Regression] Hundreds of asan failures on x86_64-apple-darwin10 at r243019
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78663 --- Comment #8 from Dominique d'Humieres --- > Created attachment 40646 > --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40646&action=edit > Fix 2 I have tested the patch on darwin10 and 16. On darwin10 the failures are fixed as with the Iain's patch, no regression on darwin16. Thanks.
[Bug c++/79113] [7 Regression] ICE inheriting a default constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79113 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #3 from Jakub Jelinek --- This got fixed with r244592 and the testcase looks sufficiently similar to the PR78488 that it isn't IMHO worth adding yet another test. *** This bug has been marked as a duplicate of bug 78488 ***
[Bug c++/78488] [7 Regression] P0136R1 ICE when building call to inherited default constructor.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78488 Jakub Jelinek changed: What|Removed |Added CC||ed at catmur dot co.uk --- Comment #8 from Jakub Jelinek --- *** Bug 79113 has been marked as a duplicate of this bug. ***
[Bug fortran/79344] [7 Regression] segmentation faults and run-time errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79344 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P4 CC||jakub at gcc dot gnu.org
[Bug tree-optimization/79340] [7 Regression] Memory leaks in tree-vect-slp.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79340 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- I'll have a look.
[Bug other/79341] Many Asan tests fail on s390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341 Florian Weimer changed: What|Removed |Added CC||fw at gcc dot gnu.org --- Comment #16 from Florian Weimer --- __tls_get_addr_internal is a GLIBC_PRIVATE symbol. There is no ABI stability associated with it whatsoever. If you want to use it, we need to properly export it on the glibc side and make it part of the psABI.
[Bug target/77333] Incorrect stack adjust in epilogue when targeting i686-w64-mingw32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77333 --- Comment #16 from Martin Jambor --- Please check whether the following patch (it is against trunk should apply on top of GCC 6 too) fixes the issue for you. It can potentially open a whole can of worms so I want to make sure it helps before taking it further. Even if it does, I would also like to ask you to run the whole gcc testsuite (as many languages as you can) with and without the patch on i686-w64-mingw32 and compare the results before I propose it on the mailing list. diff --git a/gcc/cgraph.c b/gcc/cgraph.c index ef2dc50282c..29ec61b3d0d 100644 --- a/gcc/cgraph.c +++ b/gcc/cgraph.c @@ -1425,7 +1425,7 @@ cgraph_edge::redirect_call_stmt_to_callee (void) new_stmt = chkp_copy_call_skip_bounds (new_stmt); gimple_call_set_fndecl (new_stmt, e->callee->decl); - gimple_call_set_fntype (new_stmt, gimple_call_fntype (e->call_stmt)); + gimple_call_set_fntype (new_stmt, TREE_TYPE (e->callee->decl)); if (gimple_vdef (new_stmt) && TREE_CODE (gimple_vdef (new_stmt)) == SSA_NAME)
[Bug sanitizer/79341] Many Asan tests fail on s390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341 Jakub Jelinek changed: What|Removed |Added CC||dodji at gcc dot gnu.org, ||dvyukov at gcc dot gnu.org, ||kcc at gcc dot gnu.org Component|other |sanitizer --- Comment #17 from Jakub Jelinek --- Yeah, I know that, I believe there have been some discussions between glibc and libsanitizer and I was hoping the libsanitizer maintainers would get it resolved, but apparently it has not been.
[Bug sanitizer/79341] Many Asan tests fail on s390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341 --- Comment #18 from Jakub Jelinek --- Plus one thing is interception (which still requires that the private symbol has stable ABI), and another thing is calling that symbol even when it isn't called in the original program (which is what must be going on here, because on glibc 2.18 nothing is calling a symbol which doesn't exist there when not using libsanitizer).
[Bug preprocessor/79346] -Wundef should not warn for standard macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79346 --- Comment #1 from David Brown --- Some more white-list suggestions for C++ : __STDCPP_DEFAULT_NEW_ALIGNMENT__ __STDCPP_STRICT_POINTER_SAFETY__ __STDCPP_THREADS__ C++14 also has "Whether __STDC__ is predefined and if so, what its value is, are implementation-defined". What makes it a candidate for a white-list.
[Bug fortran/79335] [7 Regression] Conditional jump or move depends on uninitialised in value get_scalar_to_descriptor_type(tree_node*, symbol_attribute) (trans-expr.c:53)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79335 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2017-02-03 Blocks||68800 Ever confirmed|0 |1 --- Comment #3 from Dominique d'Humieres --- I cannot reproduce the "Conditional jump or move depends on uninitialised value(s)" on darwin10 with valgrind-3.7.0 at r245121 (I don't have a working valgrind on darwin16). Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68800 [Bug 68800] Fortran FE produces many memory leaks
[Bug target/79355] New: poor code for AVX vector compare
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79355
Bug ID: 79355
Summary: poor code for AVX vector compare
Product: gcc
Version: 6.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: mirq-gccboogs at rere dot qmqm.pl
Target Milestone: ---
gcc-6.2 (and previous versions) generates a very inefficient code for AVX when
comparing 32-byte vectors:
$ cat a.c
#include
__v8su eq2(__v8su a, __v8su b)
{
return a == b;
}
$ gcc -S -Ofast -mavx a.c -o -
.file "a.c"
.text
.p2align 4,,15
.globl eq2
.type eq2, @function
eq2:
.LFB4856:
.cfi_startproc
vmovd %xmm0, %edx
vmovd %xmm1, %eax
leaq8(%rsp), %r10
.cfi_def_cfa 10, 0
vpextrd $1, %xmm0, %ecx
andq$-32, %rsp
cmpl%eax, %edx
[... extracting and comparing every element here ...]
vpinsrd $1, %r11d, %xmm5, %xmm1
vpinsrd $1, %r9d, %xmm7, %xmm0
popq%r10
.cfi_def_cfa 10, 0
vpunpcklqdq %xmm3, %xmm0, %xmm0
vpunpcklqdq %xmm2, %xmm1, %xmm1
popq%rbp
leaq-8(%r10), %rsp
.cfi_def_cfa 7, 8
vinsertf128 $0x1, %xmm1, %ymm0, %ymm0
ret
When it could instead generate (i.e. split vector in half and combine
afterwards):
vextractf128$0x1, %ymm0, %xmm2
vextractf128$0x1, %ymm1, %xmm3
vpcmpeqd%xmm1, %xmm0, %xmm0
vpcmpeqd%xmm3, %xmm2, %xmm2
vinsertf128 $0x1, %xmm2, %ymm0, %ymm0
ret
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/6/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 6.3.0-5'
--with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs
--enable-languages=c,ada,c++,java
,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-6
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --disable-browser-plugin --enable-java-awt=gtk
--enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-amd64/jre
--enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--with-target-system-zlib --enable-objc-gc=auto --enable-multiarch
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 6.3.0 20170124 (Debian 6.3.0-5)
[Bug tree-optimization/68823] [6/7 Regression][graphite] tramp3d-v4 compiled with -floop-nest-optimize crashes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68823
--- Comment #5 from Martin Liška ---
Created attachment 40662
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40662&action=edit
Isolated graphite dump for miscompiled function
As shown in the dump file, there are dependencies for the problematic stmts:
Adding must write to depedence graph: pdr_121 (write
in gimple stmt: MEM[(Element_t[2] &)_7][0] = _9;
data accesses: { S_3[i2] -> [2, o1, 0] : 8*floor((o1)/8) = o1 and
18446744073709551616*floor((8i2 - o1)/18446744073709551616) = 8i2 - o1 and 0 <=
o1 <= 18446744073709551608 }
Adding read to depedence graph: pdr_124 (read
in gimple stmt: _15 = MEM[(int *)_14];
data accesses: { S_6[i1] -> [2, o1] : 18446744073709551616*floor((-8i1 +
o1)/18446744073709551616) = -8i1 + o1 and 0 <= o1 <= 18446744073709551608 }
If I understand the notation correctly, both have equal alias set (2). Do you
see Sebastian why the dependence is not caught?
Thanks
[Bug tree-optimization/68823] [6/7 Regression][graphite] tramp3d-v4 compiled with -floop-nest-optimize crashes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68823 --- Comment #6 from Martin Liška --- And I'm also trying to reduce a self-contained test-case.
[Bug sanitizer/79341] Many Asan tests fail on s390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341 --- Comment #19 from Andreas Krebbel --- koriakin stands for Marcin Kościelnicki who implemented LLVM sanitizer support for z as part of a bounty. Ulrich Weigand led the discussions with him. CC'ing Uli. My personal opinion is that support of older Glibcs is not important in that case. All relevant distros for z already have a Glibc with that symbol and asan is new feature. As a debugging tool I think asan is a special case also regarding ABI compatibility. We probably do not want to export the internal symbol and make it part of the ABI because of a single user. I think adding a comment to Glibc code making people aware that this needs to be kept in sync with libsanitizer would be sufficient.
[Bug rtl-optimization/64081] [5/6/7 Regression] r217827 prevents RTL loop unroll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64081 --- Comment #31 from Aldy Hernandez --- (In reply to David Edelsohn from comment #30) > .../src/src/configure --disable-werror --with-gmp=/opt/cfarm > --with-libiconv-prefix=/opt/cfarm --disable-libstdcxx-pch > --with-included-gettext > > By the way, it's a lot faster if the src and build directories are in > /scratch. It's a ramdisk for transient, temporary files, so don't leave > things there permanently. Helps a little, but I now get the following during link: /scratch/aldyh/bld/bisect/./prev-gcc/xg++ ... ... c-family/c-ada-spec.o c-family/c-cilkplus.o c-family/array-notation-common.o c-family/cilk.o c-family/c-ubsan.o default-c.o rs6000-c.o cc1plus-checksum.o libbackend.a main.o tree-browser.o libcommon-target.a libcommon.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a ../libcpp/libcpp.a ./../intl/libintl.a /opt/cfarm/lib/libiconv.a ../libbacktrace/.libs/libbacktrace.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -L/opt/cfarm/lib -lmpc -lmpfr -lgmp -L../zlib -lz ld: 0711-380 STABSTRING ERROR: Symbol table entry 1152, object file c/c-lang.o Length of stabstring in .debug section is invalid. The stabstring is being deleted. ld: 0711-380 STABSTRING ERROR: Symbol table entry 848, object file c-family/stub-objc.o Length of stabstring in .debug section is invalid. The stabstring is being deleted. ld: 0711-380 STABSTRING ERROR: Symbol table entry 1172, object file attribs.o Length of stabstring in .debug section is invalid. The stabstring is being deleted. ld: 0711-380 STABSTRING ERROR: Symbol table entry 870, object file c/c-errors.o Length of stabstring in .debug section is invalid. The stabstring is being deleted. ld: 0711-380 STABSTRING ERROR: Symbol table entry 5636, object file c/c-decl.o Length of stabstring in .debug section is invalid. The stabstring is being deleted. etc etc etc.
[Bug fortran/79335] [7 Regression] Conditional jump or move depends on uninitialised in value get_scalar_to_descriptor_type(tree_node*, symbol_attribute) (trans-expr.c:53)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79335
Martin Liška changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #4 from Martin Liška ---
I see, now P4 makes sense for me.
It's easy to find out why it uses uninitialized value:
generate_coarray_sym_init contains: symbol_attribute attr;
then in the function we do not assign to attr and at line 5132 we call:
desc = gfc_conv_scalar_to_descriptor (&se, decl, attr);
which immediately at the beginning calls:
type = get_scalar_to_descriptor_type (scalar, attr);
and the function does the invalid use:
│48 static tree
│49 get_scalar_to_descriptor_type (tree scalar, symbol_attribute attr)
│50 {
│51enum gfc_array_kind akind;
│52
>│53if (attr.pointer)
│54 akind = GFC_ARRAY_POINTER_CONT;
[Bug target/79211] ICE in extract_insn, at recog.c:2311
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79211 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P1 --- Comment #5 from Jakub Jelinek --- This regressed with r236795.
[Bug tree-optimization/78348] [7 REGRESSION] 15% performance drop for coremark-pro/nnet-test after r242038
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78348 --- Comment #11 from Dominik Vogt --- Fails if configured with "--with-arch=zEC12", passes without that.
[Bug sanitizer/79341] Many Asan tests fail on s390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341 --- Comment #20 from Florian Weimer --- (In reply to Andreas Krebbel from comment #19) > As a debugging tool I think asan is a special case also regarding ABI > compatibility. We probably do not want to export the internal symbol and > make it part of the ABI because of a single user. We have users in GCC and LLVM already, and both projects have many downstream forks. This means that it's going to be difficult to adjust all users as part of a system glibc update. GLIBC_PRIVATE is internal to glibc. Please do not depend on these symbols. They can change or go away at any time. For example, the prototype of __libc_res_nsearch changed during a security update.
[Bug sanitizer/78663] [7 Regression] Hundreds of asan failures on x86_64-apple-darwin10 at r243019
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78663 --- Comment #9 from chefmax at gcc dot gnu.org --- Author: chefmax Date: Fri Feb 3 12:17:59 2017 New Revision: 245149 URL: https://gcc.gnu.org/viewcvs?rev=245149&root=gcc&view=rev Log: PR sanitizer/78663 * sanitizer_common/sanitizer_mac.cc: Cherry-pick upstream r293992. * sanitizer_common/sanitizer_platform_interceptors.h: Likewise. Modified: trunk/libsanitizer/ChangeLog trunk/libsanitizer/sanitizer_common/sanitizer_mac.cc trunk/libsanitizer/sanitizer_common/sanitizer_platform_interceptors.h
[Bug c/79356] New: XPASS in attr-alloc_size-11.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79356
Bug ID: 79356
Summary: XPASS in attr-alloc_size-11.c
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: vogt at linux dot vnet.ibm.com
CC: krebbel at gcc dot gnu.org, msebor at gcc dot gnu.org
Target Milestone: ---
Host: s390x
Target: s390x
The test has two xfails that do pass on s390x with --with-arch=zEC12 (not
tested without that):
--
/* The following tests fail because of missing range information. */
TEST (signed char, SCHAR_MIN + 2, ALLOC_MAX); /* { dg-warning "argument 1
ran\
ge \\\[13, \[0-9\]+\\\] exceeds maximum object size 12" "missing range info
for\
signed char" { xfail *-*-* } } */
TEST (short, SHRT_MIN + 2, ALLOC_MAX); /* { dg-warning "argument 1 range
\\\[13\
, \[0-9\]+\\\] exceeds maximum object size 12" "missing range info for short"
{\
xfail *-*-* } } */
--
The test was added in r244290:
--
PR tree-optimization/78775 - [7 Regression] ICE in
maybe_warn_alloc_args_ove
gcc/ChangeLog:
PR tree-optimization/78775
* builtins.c (get_size_range): Move...
* calls.c: ...to here.
(alloc_max_size): Accept zero argument.
(operand_signed_p): Remove.
(maybe_warn_alloc_args_overflow): Call get_size_range.
* calls.h (get_size_range): Declare.
gcc/testsuite/ChangeLog:
PR tree-optimization/78775
* gcc.dg/attr-alloc_size-4.c: Add test cases.
* gcc.dg/attr-alloc_size-10.c: New test.
* gcc.dg/attr-alloc_size-11.c: New test.
* gcc.dg/builtin-stringop-chk-7.c: New test.
* gcc.dg/pr78775.c: New test.
* gcc.dg/pr78973-2.c: New test.
* gcc.dg/pr78973.c: New test.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@244290
138bc75d-0d04-0410-96
--
[Bug sanitizer/79341] Many Asan tests fail on s390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341 --- Comment #21 from Jakub Jelinek --- Could libsanitizer call __tls_get_offset instead, after setting %r12 or whatever else is needed for it to make work and then perhaps adjust the result if needed? E.g. on s390x __tls_get_offset is internally: __tls_get_offset:\n\ la %r2,0(%r2,%r12)\n\ jg __tls_get_addr\n\ and in the interceptor: #ifdef __s390x__ "la %r2, 0(%r2,%r12)\n" "jg __interceptor___tls_get_addr_internal_protected\n" #else at which point the original %r2 and %r12 is lost and it is hard to call the original __tls_get_offset, it might be better to pass the original %r2 and %r12 values to some C function and from that compute the r2 + r12 the code perhaps needs for its own thing, but then we could (again in assembly) call the original __tls_get_offset again if needed. That said, if asan wants to intercept also what dlsym will internally call, then that will not really work. But does libasan on other targets rely on dlsym calling __tls_get_addr internally in those cases? That would be yet another reliance on glibc internals.
[Bug rtl-optimization/70478] [LRA] S/390: Performance regression - superfluous stack frame
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70478 Dominik Vogt changed: What|Removed |Added CC||vogt at linux dot vnet.ibm.com --- Comment #4 from Dominik Vogt --- Is there any new information on this issue?
[Bug tree-optimization/79340] [7 Regression] Memory leaks in tree-vect-slp.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79340 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Created attachment 40663 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40663&action=edit gcc7-pr79340.patch Untested fix.
[Bug target/79354] [7 Regression] -mcpu=power8 -O2 generates power9 instruction on powerpc64le-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79354 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
[Bug rtl-optimization/70478] [LRA] S/390: Performance regression - superfluous stack frame
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70478 --- Comment #5 from Andreas Krebbel --- (In reply to Dominik Vogt from comment #4) > Is there any new information on this issue? Adding the ? constraint modifier was an overall loss. So I did not pursue this any further.
[Bug sanitizer/78663] [7 Regression] Hundreds of asan failures on x86_64-apple-darwin10 at r243019
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78663 --- Comment #10 from Jakub Jelinek --- So fixed?
[Bug sanitizer/79341] Many Asan tests fail on s390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341 --- Comment #22 from Ulrich Weigand --- (In reply to Jakub Jelinek from comment #21) > Could libsanitizer call __tls_get_offset instead, after setting %r12 or > whatever else is needed for it to make work and then perhaps adjust the > result if needed? > E.g. on s390x __tls_get_offset is internally: > __tls_get_offset:\n\ > la %r2,0(%r2,%r12)\n\ > jg __tls_get_addr\n\ > and in the interceptor: > #ifdef __s390x__ > "la %r2, 0(%r2,%r12)\n" > "jg __interceptor___tls_get_addr_internal_protected\n" > #else > at which point the original %r2 and %r12 is lost and it is hard to call the > original __tls_get_offset, it might be better to pass the original %r2 and > %r12 values to some C function and from that compute the r2 + r12 the code > perhaps needs for its own thing, but then we could (again in assembly) call > the original __tls_get_offset again if needed. Yes, it would appear to be safer to call __tls_get_offset instead. You probably do not even need the original %r12, but simply subtract %r12 (whatever it currently is) from %r2 before calling the original __tls_get_offset. The value of %r12 is not used for anything except adding it to %r2. > That said, if asan wants to intercept also what dlsym will internally call, > then that will not really work. But does libasan on other targets rely on > dlsym calling __tls_get_addr internally in those cases? That would be yet > another reliance on glibc internals. As I understand it, they do make that assumption; libsanitizer must get involved at the point any new TLS data section is allocated. Since this allocation may happen as a result of a dlsym call, those cases have to be intercepted as well.
[Bug sanitizer/79341] Many Asan tests fail on s390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #23 from Jakub Jelinek ---
(In reply to Ulrich Weigand from comment #22)
> (In reply to Jakub Jelinek from comment #21)
> > Could libsanitizer call __tls_get_offset instead, after setting %r12 or
> > whatever else is needed for it to make work and then perhaps adjust the
> > result if needed?
> > E.g. on s390x __tls_get_offset is internally:
> > __tls_get_offset:\n\
> > la %r2,0(%r2,%r12)\n\
> > jg __tls_get_addr\n\
> > and in the interceptor:
> > #ifdef __s390x__
> > "la %r2, 0(%r2,%r12)\n"
> > "jg __interceptor___tls_get_addr_internal_protected\n"
> > #else
> > at which point the original %r2 and %r12 is lost and it is hard to call the
> > original __tls_get_offset, it might be better to pass the original %r2 and
> > %r12 values to some C function and from that compute the r2 + r12 the code
> > perhaps needs for its own thing, but then we could (again in assembly) call
> > the original __tls_get_offset again if needed.
>
> Yes, it would appear to be safer to call __tls_get_offset instead.
> You probably do not even need the original %r12, but simply subtract
> %r12 (whatever it currently is) from %r2 before calling the original
> __tls_get_offset. The value of %r12 is not used for anything except
> adding it to %r2.
If it is that easy, then perhaps glibc should drop __tls_get_addr_internal and
just call __tls_get_offset that way internally too?
Otherwise, if we still wrap __tls_get_addr_internal (perhaps for compatibility
reasons) and just make sure we call __tls_get_offset instead on s390{,x} with
the adjusted argument, we could support even older glibcs.
[Bug rtl-optimization/64081] [5/6/7 Regression] r217827 prevents RTL loop unroll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64081 --- Comment #32 from David Edelsohn --- How far are you going back in the bisection effort? You may be earlier than the point at which GCC on AIX generated stab strings continuation lines. At worst you manually can apply the continuation code from gcc/xcoffout.h /* XCOFF32 maximum length is 64K; XLC limits to 16K. */ #define DBX_CONTIN_LENGTH 16384 /* XLC uses '?' as continuation character. */ #define DBX_CONTIN_CHAR '?'
[Bug c/79357] New: Doubling a single complex float is not vectorised
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79357
Bug ID: 79357
Summary: Doubling a single complex float is not vectorised
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: drraph at gmail dot com
Target Milestone: ---
Consider the following code:
#include
complex float f(complex float x) {
return 2*x;
}
gcc with -O3 -march=core-avx2 gives:
f:
vmovq QWORD PTR [rsp-8], xmm0
vmovss xmm1, DWORD PTR [rsp-8]
vmovss xmm0, DWORD PTR [rsp-4]
vaddss xmm1, xmm1, xmm1
vaddss xmm0, xmm0, xmm0
vmovss DWORD PTR [rsp-16], xmm1
vmovss DWORD PTR [rsp-12], xmm0
vmovq xmm0, QWORD PTR [rsp-16]
ret
Better and still suitable without -ffast-math would be:
f:
vmulpsxmm0, xmm0, XMMWORD PTR .L_2il0floatpacket.1[rip] #3.12
ret
[Bug tree-optimization/68823] [6/7 Regression][graphite] tramp3d-v4 compiled with -floop-nest-optimize crashes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68823
--- Comment #7 from Sebastian Pop ---
(In reply to Martin Liška from comment #5)
> Created attachment 40662 [details]
> Isolated graphite dump for miscompiled function
>
> As shown in the dump file, there are dependencies for the problematic stmts:
>
> Adding must write to depedence graph: pdr_121 (write
> in gimple stmt: MEM[(Element_t[2] &)_7][0] = _9;
> data accesses: { S_3[i2] -> [2, o1, 0] : 8*floor((o1)/8) = o1 and
> 18446744073709551616*floor((8i2 - o1)/18446744073709551616) = 8i2 - o1 and 0
> <= o1 <= 18446744073709551608 }
>
> Adding read to depedence graph: pdr_124 (read
> in gimple stmt: _15 = MEM[(int *)_14];
> data accesses: { S_6[i1] -> [2, o1] : 18446744073709551616*floor((-8i1 +
> o1)/18446744073709551616) = -8i1 + o1 and 0 <= o1 <= 18446744073709551608 }
>
> If I understand the notation correctly, both have equal alias set (2). Do
> you see Sebastian why the dependence is not caught?
>
S_3[i2] -> [2, o1, 0]
S_6[i1] -> [2, o1]
we do not detect the dependence because the two arrays do not have the same
number of subscripts: also on the gimple representation we have
MEM[(Element_t[2] &)_7][0] = _9;
vs.
_15 = MEM[(int *)_14];
[Bug rtl-optimization/78241] [7 Regression] wrong code with -funroll-loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78241 --- Comment #5 from Pat Haugen --- Author: pthaugen Date: Fri Feb 3 14:20:30 2017 New Revision: 245152 URL: https://gcc.gnu.org/viewcvs?rev=245152&root=gcc&view=rev Log: PR rtl-optimization/78241 * loop-unroll.c (unroll_loop_runtime_iterations): Don't adjust 'niter', but emit initial peel copy if niter expr is not reliable. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/powerpc/pr70669.c
[Bug target/79353] [7 regression] ICE in curr_insn_transform, at lra-constraints.c:3773
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79353 --- Comment #2 from James Clarke --- Created attachment 40664 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40664&action=edit Reduced Reproduction This was reduced from parfor.c with the help of creduce. To reproduce (minimal set of flags I found): /home/jrtc27/src/gcc/obj/./gcc/xgcc -B/home/jrtc27/src/gcc/obj/./gcc/ -B/usr/local/sparc64-unknown-linux-gnu/bin/ -B/usr/local/sparc64-unknown-linux-gnu/lib/ -m32 -fPIC -O2 -c parfor.i -o /tmp/parfor.o
[Bug c/79358] New: gcc.dg/c99-stdint-1.c fails with excess error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79358
Bug ID: 79358
Summary: gcc.dg/c99-stdint-1.c fails with excess error
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: vogt at linux dot vnet.ibm.com
CC: krebbel at gcc dot gnu.org
Target Milestone: ---
Host: s390x
Target: s390x
FAIL: gcc.dg/c99-stdint-1.c (test for excess errors)
Excess errors:
.../gcc/testsuite/gcc.dg/c99-stdint-1.c:37:57: error: initialization from
incompatible pointer type [-Wincompatible-pointer-types]
--
Reduced test case, compiled with "-std=iso9899:1999 -pedantic-errors -fhosted"
and either -m31 or -m64:
void
foo (void)
{
__typeof__((4294967295U)) a;
__typeof__((long unsigned int)0 + 0) *b = &a;
}
[Bug c/79358] gcc.dg/c99-stdint-1.c fails with excess error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79358 --- Comment #1 from Dominik Vogt --- (built with --enable-bootstrap, --enable-multilib and --with-arch=zEC12)
[Bug tree-optimization/68823] [6/7 Regression][graphite] tramp3d-v4 compiled with -floop-nest-optimize crashes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68823 --- Comment #8 from Sebastian Pop --- The code in fault is called from pdr_add_memory_accesses() Maybe the problem is in parsing the gimple MEM[] into a data reference.
[Bug c/448] -related issues (C99 issues)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=448 Dominik Vogt changed: What|Removed |Added CC||vogt at linux dot vnet.ibm.com --- Comment #34 from Dominik Vogt --- A __typeof__-Problem on s390x: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79358
[Bug tree-optimization/68823] [6/7 Regression][graphite] tramp3d-v4 compiled with -floop-nest-optimize crashes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68823 --- Comment #9 from Sebastian Pop --- /* Determines the base object and the list of indices of memory reference DR, analyzed in LOOP and instantiated in loop nest NEST. */ static void dr_analyze_indices (struct data_reference *dr, loop_p nest, loop_p loop) This function initializes the subscripts with their access functions: DR_ACCESS_FNS (dr) = access_fns; The number of subscripts (or "dimensions") is then the length of that array: #define DR_NUM_DIMENSIONS(DR) DR_ACCESS_FNS (DR).length ()
[Bug c++/79094] Pack expansion in using-declaration rejects an attempt to inherit a pack of constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79094
lucdanton at free dot fr changed:
What|Removed |Added
CC||lucdanton at free dot fr
--- Comment #1 from lucdanton at free dot fr ---
Another case that wants a dependent type expanded alongside the bases, but
where
the declarator does not name a constructor:
template
struct unvariadic: private A, private B {
// okay, provided A and B each declare appropriate
// target_type and operator target_type() members
using A::operator typename A::target_type,
B::operator typename B::target_type;
};
template
struct variadic: private Bases... {
// error: parameter packs not expanded with '...':
using Bases::operator typename Bases::target_type...;
};
[Bug tree-optimization/79338] [6/7 Regression] Memory leak in tree-parloops.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79338 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Created attachment 40665 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40665&action=edit gcc7-pr79338.patch Untested fix. I admit I don't know much what the code is doing, but it is clear the vectorizer doesn't allow concurrent uses of vect_analyze_loop_form on overlapping loops, because that function e.g. allocates stmt info for each statement in the loop. This patch attempts to defer the work where the inner loop vinfo is needed until after the outer loop's vinfo is removed. I don't see any differences in the outer-4.c dumps.
[Bug c/79359] New: Squaring a complex float gives inefficient code with or without -ffast-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79359
Bug ID: 79359
Summary: Squaring a complex float gives inefficient code with
or without -ffast-math
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: drraph at gmail dot com
Target Milestone: ---
Consider:
#include
complex float f(complex float x) {
return x*x;
}
This PR has two parts.
Part 1.
In gcc 7 with -Ofast -march=core-avx2 gives
f:
vmovq QWORD PTR [rsp-8], xmm0
vmovss xmm2, DWORD PTR [rsp-4]
vmovss xmm0, DWORD PTR [rsp-8]
vmulss xmm1, xmm2, xmm2
vfmsub231ss xmm1, xmm0, xmm0
vmulss xmm0, xmm0, xmm2
vmovss DWORD PTR [rsp-16], xmm1
vaddss xmm0, xmm0, xmm0
vmovss DWORD PTR [rsp-12], xmm0
vmovq xmm0, QWORD PTR [rsp-16]
ret
Using the Intel C Compiler with -O3 -march=core-avx2 we get:
f:
vmovshdup xmm1, xmm0#3.12
vshufps xmm2, xmm0, xmm0, 177 #3.12
vmulpsxmm4, xmm1, xmm2 #3.12
vmovsldup xmm3, xmm0#3.12
vfmaddsub213ps xmm0, xmm3, xmm4 #3.12
ret
which is somewhat better.
Part 2.
If we instead use -O3 alone for gcc we get:
f:
vmovq QWORD PTR [rsp-16], xmm0
vmovss xmm3, DWORD PTR [rsp-12]
vmovss xmm2, DWORD PTR [rsp-16]
vmovaps xmm1, xmm3
vmovaps xmm0, xmm2
jmp __mulsc3
which is much slower potentially.
In ICC if we use -fp-model precise we get:
f:
vmovshdup xmm1, xmm0#3.12
vshufps xmm2, xmm0, xmm0, 177 #3.12
vmulpsxmm4, xmm1, xmm2 #3.12
vmovsldup xmm3, xmm0#3.12
vfmaddsub213ps xmm0, xmm3, xmm4 #3.12
ret
which is the same as above and if we use -fp-model strict we get:
f:
vmovsldup xmm1, xmm0#3.12
vmovshdup xmm2, xmm0#3.12
vshufps xmm3, xmm0, xmm0, 177 #3.12
vmulpsxmm4, xmm1, xmm0 #3.12
vmulpsxmm5, xmm2, xmm3 #3.12
vaddsubps xmm0, xmm4, xmm5 #3.12
ret
The Intel docs claim that -fp-model strict is value safe (as is the "precise"
option), turns on floating point exception semantics and turns off fuse add
multiply.
jakub on IRC asked if it was really true that the icc code handles all the
corner cases (NaNs etc.) correctly and suggested going through all the corner
cases in mulsc3 and seeing what the ICC code emits.
[Bug lto/66295] [5/6/7 Regression] LTO generates incorrect resolver call for function multiversioning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66295 --- Comment #7 from Martin Liška --- Author: marxin Date: Fri Feb 3 15:22:47 2017 New Revision: 245155 URL: https://gcc.gnu.org/viewcvs?rev=245155&root=gcc&view=rev Log: Simplify creation of target_clones (PR lto/66295) 2017-02-03 Martin Liska PR lto/66295 * multiple_target.c (create_dispatcher_calls): Redirect edge from a caller of a dispatcher. (expand_target_clones): Make the clones local. (ipa_target_clone): Do both target clones and resolvers. (ipa_dispatcher_calls): Remove the pass. (pass_dispatcher_calls::gate): Likewise. (make_pass_dispatcher_calls): Likewise. * passes.def (pass_target_clone): Put as very first IPA early pass. 2017-02-03 Martin Liska PR lto/66295 * gcc.target/i386/mvc9.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/mvc9.c Modified: trunk/gcc/ChangeLog trunk/gcc/multiple_target.c trunk/gcc/passes.def trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/78241] [7 Regression] wrong code with -funroll-loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78241 --- Comment #6 from Pat Haugen --- (In reply to Pat Haugen from comment #5) > Author: pthaugen > Date: Fri Feb 3 14:20:30 2017 > New Revision: 245152 > Ignore this, used wrong commit message on another patch.
[Bug tree-optimization/79338] [6/7 Regression] Memory leak in tree-parloops.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79338
--- Comment #2 from Tom de Vries ---
AFAIU, free_stmt_vec_info_vec intends to free the allocated memory:
...
void
free_stmt_vec_info_vec (void)
{
unsigned int i;
stmt_vec_info info;
FOR_EACH_VEC_ELT (stmt_vec_info_vec, i, info)
if (info != NULL)
free_stmt_vec_info (STMT_VINFO_STMT (info));
gcc_assert (stmt_vec_info_vec.exists ());
stmt_vec_info_vec.release ();
}
...
But free_stmt_vec_info starts with:
...
void
free_stmt_vec_info (gimple *stmt)
{
stmt_vec_info stmt_info = vinfo_for_stmt (stmt);
...
So:
- in free_stmt_vec_info_vec we start out with stmt_vec_info_vec element info,
- then we find the corresponding gimple stmt (STMT_VINFO_STMT (info)),
- and then in free_stmt_vec_info we find the stmt_vect_info for the gimple
(vinfo_for_stmt (stmt)).
This only guarantees the freeing of info, if
vinfo_for_stmt(STMT_VINFO_STMT (info)) == info.
The 'vinfo_for_stmt(STMT_VINFO_STMT (info)) == info' invariant is broken by
doing twice:
...
gimple *stmt = gsi_stmt (si);
gimple_set_uid (stmt, 0);
set_vinfo_for_stmt (stmt, new_stmt_vec_info (stmt, res));
...
Once for vect_analyze_loop_form (loop), and once for vect_analyze_loop_form
(loop->inner).
[Bug target/79158] gcc.target/powerpc/pr70669.c fails on powerpc BE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79158 Pat Haugen changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Pat Haugen --- Fixed in r245152 (but I used wrong commit message so didn't automatically show up in this pr).
[Bug c/79358] gcc.dg/c99-stdint-1.c fails with excess error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79358 --- Comment #2 from Andreas Krebbel --- The reduced testcase fails with -m31 and -m64 but the original probably only with -m31 - right?! Looks like the following Glibc problem which has been fixed a while ago: commit 26011b5cfa6a1a8d8005d65f11d97498444a4e95 2014-03-24 Stefan Liebler [BZ #16712] * sysdeps/s390/s390-32/bits/wordsize.h (__WORDSIZE32_SIZE_ULONG): New define. * sysdeps/s390/s390-64/bits/wordsize.h (__WORDSIZE32_SIZE_ULONG): Likewise. * sysdeps/generic/stdint.h (SIZE_MAX): Define as UL if __WORDSIZE32_SIZE_ULONG.
[Bug rtl-optimization/78634] [7 Regression] 30% performance drop after r242832.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78634 Dominik Vogt changed: What|Removed |Added CC||krebbel at gcc dot gnu.org, ||rdapp at linux dot vnet.ibm.com, ||vogt at linux dot vnet.ibm.com --- Comment #4 from Dominik Vogt --- This commit has broken a test case on s390x: FAIL: gcc.target/s390/loc-1.c scan-assembler \tlocgrne\t%r2,%r4 The load-on-condition instruction is no longer used because the branch cost is very low on s390x (1). Using -mbranch-cost=2 fixes the test failure.
[Bug rtl-optimization/64081] [5/6/7 Regression] r217827 prevents RTL loop unroll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64081 --- Comment #33 from Aldy Hernandez --- Created attachment 40666 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40666&action=edit patch attempting to bootstrap 219827 on gcc119 (AIX 7.2)
[Bug rtl-optimization/64081] [5/6/7 Regression] r217827 prevents RTL loop unroll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64081 --- Comment #34 from Aldy Hernandez --- (In reply to David Edelsohn from comment #32) > How far are you going back in the bisection effort? You may be earlier than > the point at which GCC on AIX generated stab strings continuation lines. At > worst you manually can apply the continuation code from gcc/xcoffout.h > > /* XCOFF32 maximum length is 64K; XLC limits to 16K. */ > #define DBX_CONTIN_LENGTH 16384 > > /* XLC uses '?' as continuation character. */ > #define DBX_CONTIN_CHAR '?' David, thanks for your input here, BTW. Same problem, even if I add your above two lines to rs6000.h. I am starting with r219827 as suggested here: https://gcc.gnu.org/ml/gcc-patches/2016-02/msg00451.html The aforementioned revision gets us around January 18, 2015, which is around the time y'all were discussing the bootstrap failure. My tree contains: 1. The rtl patch being discussed 2. A patch for r233572 to get GCC 6.x to build GCC 5.x (see BZ#69959). 3. Your suggested changes for xcoff continuation. I am attaching the changes to r219827 that still exhibit STABSTRING ERROR problems while bootstrapping. These are in comment 33. Any tips greatly appareciated.
[Bug c/79358] gcc.dg/c99-stdint-1.c fails with excess error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79358 --- Comment #3 from Dominik Vogt --- > The reduced testcase fails with -m31 and -m64 but the original probably only > with -m31 - right?! The unreduced testcase fails with -m31 and -m64. I've tried the reduced test case only with -m64.
[Bug c/79358] gcc.dg/c99-stdint-1.c fails with excess error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79358 --- Comment #4 from Dominik Vogt --- I.e. this is a Glibc related problem? The test machine has Glibc-2.18.
[Bug middle-end/78468] [7 regression] libgomp.c/reduction-10.c and many more FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78468 --- Comment #35 from Dominik Vogt --- (In reply to Eric Botcazou from comment #34) > > I still disagree with reverting the patch. There was plenty of time to > > identify and fix affected backends instead of doing nothing for half five > > months and then claiming that the patch is potentially too disruptive at > > this point in the release cycle. > > That was your job though and apparently you didn't do it. Don't be silly. I've fixed all regresseions that have shown up, except the one on Sparc because you refused to accept changes to the Sparc backend. It's all documented in this discussion thread, so please stop inventing excuses to put the blame on others.
[Bug rtl-optimization/64081] [5/6/7 Regression] r217827 prevents RTL loop unroll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64081 --- Comment #35 from Aldy Hernandez --- Hmmm, I see the changes in gcc/dbxout.h may override the DBX_* changes I made to config/rs6000/rs6000.h. I'll attempt to patch gcc/dbxout.h instead. I will report back. BTW David, if there's a point in the GCC history with stabs continuation support you suggest I start my bisection, let me know. Hopefully that will also exhibit a bootstrap failure with the RTL patch in this PR.
[Bug target/77333] Incorrect stack adjust in epilogue when targeting i686-w64-mingw32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77333 --- Comment #17 from Martin Jambor --- OK, so it turns out I botched my testing and the patch from the previous commit cause PR57330 and we would need something like the patch below (with a big fat comment why the condition is necessary, if we go this way at all, that is). Still, I need someone to test this really helps to fix the problem and to do a testsuite run. [PR 77333] Set clone call fntype to callee type 2017-02-03 Martin Jambor PR target/77333 * cgraph.c (redirect_call_stmt_to_callee): Set call stmt fntype to type of the decl if lhs has compatible type. diff --git a/gcc/cgraph.c b/gcc/cgraph.c index ef2dc50282c..b91de6788c7 100644 --- a/gcc/cgraph.c +++ b/gcc/cgraph.c @@ -1425,7 +1425,15 @@ cgraph_edge::redirect_call_stmt_to_callee (void) new_stmt = chkp_copy_call_skip_bounds (new_stmt); gimple_call_set_fndecl (new_stmt, e->callee->decl); - gimple_call_set_fntype (new_stmt, gimple_call_fntype (e->call_stmt)); + + tree lhs = gimple_call_lhs (new_stmt); + tree decl_restype = TREE_TYPE (TREE_TYPE (e->callee->decl)); + if (lhs + && (VOID_TYPE_P (decl_restype) + || !useless_type_conversion_p (TREE_TYPE (lhs), decl_restype))) + gimple_call_set_fntype (new_stmt, gimple_call_fntype (e->call_stmt)); + else + gimple_call_set_fntype (new_stmt, TREE_TYPE (e->callee->decl)); if (gimple_vdef (new_stmt) && TREE_CODE (gimple_vdef (new_stmt)) == SSA_NAME)
[Bug tree-optimization/79352] [7 Regression] -fprintf-return-value doesn't handle flexible-like array members properly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79352 --- Comment #3 from Martin Sebor --- Author: msebor Date: Fri Feb 3 16:38:15 2017 New Revision: 245156 URL: https://gcc.gnu.org/viewcvs?rev=245156&root=gcc&view=rev Log: PR tree-optimization/79352 - -fprintf-return-value doesn't handle flexible-like array members properly gcc/ChangeLog: PR tree-optimization/79352 * gimple-fold.c (get_range_strlen): Add argument. (get_range_strlen): Change return type to bool. (get_maxval_strlen): Pass in a dummy argument. * gimple-fold.h (get_range_strlen): Change return type to bool. * gimple-ssa-sprintf.c (get_string_length): Set unlikely counter. * tree.h (array_at_struct_end_p): Add argument. * tree.c (array_at_struct_end_p): Handle it. gcc/testsuite/ChangeLog: PR tree-optimization/79352 * gcc.dg/tree-ssa/pr79352.c: New test. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/pr79352.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimple-fold.c trunk/gcc/gimple-fold.h trunk/gcc/gimple-ssa-sprintf.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree.c trunk/gcc/tree.h
[Bug tree-optimization/79352] [7 Regression] -fprintf-return-value doesn't handle flexible-like array members properly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79352 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Martin Sebor --- Fix committed in r245156.
[Bug c++/79360] New: [5.4/6/7 Regression] ICE with NSDMI and enum in union
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79360
Bug ID: 79360
Summary: [5.4/6/7 Regression] ICE with NSDMI and enum in union
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reichelt at gcc dot gnu.org
Target Milestone: ---
Compiling the following valid code results in a crash
===
union U
{
enum E { e };
};
struct A
{
U u{};
};
===
bug3.cc:8:7: internal compiler error: in process_init_constructor_union, at
cp/typeck2.c:1562
U u{};
^
0x6f222d process_init_constructor_union
../../gcc/gcc/cp/typeck2.c:1561
0x6f222d process_init_constructor
../../gcc/gcc/cp/typeck2.c:1616
0x6f222d digest_init_r
../../gcc/gcc/cp/typeck2.c:1125
0x6f4230 digest_init_flags(tree_node*, tree_node*, int, int)
../../gcc/gcc/cp/typeck2.c:1170
0x6f4230 digest_nsdmi_init(tree_node*, tree_node*)
../../gcc/gcc/cp/typeck2.c:1186
0x76539f cp_parser_late_parse_one_default_arg
../../gcc/gcc/cp/parser.c:27167
0x74f693 cp_parser_late_parsing_nsdmi
../../gcc/gcc/cp/parser.c:27200
0x74f693 cp_parser_class_specifier_1
../../gcc/gcc/cp/parser.c:22265
0x750a59 cp_parser_class_specifier
../../gcc/gcc/cp/parser.c:22318
0x750a59 cp_parser_type_specifier
../../gcc/gcc/cp/parser.c:16409
0x751827 cp_parser_decl_specifier_seq
../../gcc/gcc/cp/parser.c:13326
0x778901 cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:12647
0x779845 cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:12592
0x752527 cp_parser_declaration
../../gcc/gcc/cp/parser.c:12489
0x782c8b cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:12365
0x782f6a cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:4369
0x782f6a c_parse_file()
../../gcc/gcc/cp/parser.c:38356
0x8df643 c_common_parse_file()
../../gcc/gcc/c-family/c-opts.c:1107
Please submit a full bug report, [etc.]
This bug appears in GCC 5.4.0, 6.x, 7.0, but not in GCC 5.3.0 or before.
[Bug c/79358] gcc.dg/c99-stdint-1.c fails with excess error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79358
--- Comment #5 from joseph at codesourcery dot com ---
On Fri, 3 Feb 2017, vogt at linux dot vnet.ibm.com wrote:
> void
> foo (void)
> {
> __typeof__((4294967295U)) a;
> __typeof__((long unsigned int)0 + 0) *b = &a;
> }
That's not a meaningful reduction. The relevant reduction would be to
just one of the CHECK_* macro calls in the test, which would show which
macro (in the system's header) has an incorrect definition.
You could then consider fixing this with a fixincludes fix for buggy
system headers (as well as fixing the headers upstream).
[Bug c/79358] gcc.dg/c99-stdint-1.c fails with excess error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79358
--- Comment #6 from Dominik Vogt ---
(In reply to Andreas Krebbel from comment #2)
> The reduced testcase fails with -m31 and -m64 but the original probably only
> with -m31 - right?!
Sorry, you're right. I was doing too many things in parallel.
Another attempt at reduction:
--
#include
#include
#define CHECK_UNSIGNED(TYPE) \
do { TYPE a; int b[(TYPE)-1 < 0 ? -1 : 1]; } while (0)
#define CHECK_EXPR_TYPE(TYPE, EXPR) \
do { __typeof__(EXPR) a; __typeof__((TYPE)0 + 0) *b = &a; } while (0)
#define UNSIGNED_MAX_COND(TYPE, EXPR) \
((EXPR) == (TYPE)-1)
#define CHECK_UNSIGNED_LIMITS_2(TYPE, MAX, MAXBD) \
CHECK_UNSIGNED(TYPE); \
CHECK_EXPR_TYPE(TYPE, (MAX)); \
do { int a[(UNSIGNED_MAX_COND(TYPE, (MAX))\
&& (MAX) >= (MAXBD)) ? 1 : -1]; } while (0)
void
test_misc_limits (void)
{
CHECK_UNSIGNED_LIMITS_2(__SIZE_TYPE__, SIZE_MAX, 65535U);
}
--
[Bug c/79358] gcc.dg/c99-stdint-1.c fails with excess error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79358
--- Comment #7 from Dominik Vogt ---
Or even
--
#include
#include
#define FOO(TYPE, EXPR) __typeof__(EXPR) a; __typeof__((TYPE)0 + 0) *b = &a;
void foo (void)
{
FOO(__SIZE_TYPE__, (SIZE_MAX));
}
--
So __typeof__(SIZE_MAX) is different from __typeof__(__SIZE_TYPE__) when using
-m31.
[Bug c/79358] gcc.dg/c99-stdint-1.c fails with excess error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79358 --- Comment #8 from Dominik Vogt --- Gdb says: (gdb) ptype __typeof__(size_t) type = unsigned long (gdb) ptype __typeof__(SIZE_MAX) type = unsigned int Two different types for unsigned 32 bit integers.
[Bug c++/68858] Cannot use fold expression in requirements with two parameters packs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68858 --- Comment #1 from Casey Carter --- This seems to be a duplicate of PR 68812.
[Bug target/79354] [7 Regression] -mcpu=power8 -O2 generates power9 instruction on powerpc64le-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79354 --- Comment #8 from Jakub Jelinek --- Author: jakub Date: Fri Feb 3 17:34:56 2017 New Revision: 245157 URL: https://gcc.gnu.org/viewcvs?rev=245157&root=gcc&view=rev Log: PR target/79354 * config/rs6000/rs6000.md (movsi_from_sf): Use wb constraint instead of wu for stxssp alternative. * gcc.target/powerpc/pr79354.c: New test. * gcc.c-torture/execute/pr79354.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr79354.c trunk/gcc/testsuite/gcc.target/powerpc/pr79354.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.md trunk/gcc/testsuite/ChangeLog
[Bug c/79358] gcc.dg/c99-stdint-1.c fails with excess error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79358 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #9 from Jakub Jelinek --- What glibc do you have? E.g. glibc 2.24 has in stdint.h # if __WORDSIZE == 64 # define SIZE_MAX (18446744073709551615UL) # else # ifdef __WORDSIZE32_SIZE_ULONG # define SIZE_MAX (4294967295UL) # else # define SIZE_MAX (4294967295U) # endif # endif and it seems s390 defines the right macros: ./sysdeps/s390/s390-32/bits/wordsize.h:# define __WORDSIZE32_SIZE_ULONG 1 ./sysdeps/s390/s390-64/bits/wordsize.h:# define __WORDSIZE32_SIZE_ULONG 1 so even SIZE_MAX should be unsigned long. While e.g. RHEL7 glibc (2.17) has: # if __WORDSIZE == 64 # define SIZE_MAX (18446744073709551615UL) # else # define SIZE_MAX (4294967295U) # endif so it seems this test actually tests libc rather than gcc if stdint.h is provided by libc and not gcc.
[Bug c/79358] gcc.dg/c99-stdint-1.c fails with excess error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79358 --- Comment #10 from Jakub Jelinek --- It is a pitty glibc headers didn't use __SIZE_MAX__ if available, because that appears to be correct.
[Bug c++/79361] New: [5/6/7 Regression] ICE redefining a template function as defaulted or deleted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79361
Bug ID: 79361
Summary: [5/6/7 Regression] ICE redefining a template function
as defaulted or deleted
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reichelt at gcc dot gnu.org
Target Milestone: ---
The following two invalid testcases trigger ICEs on trunk:
===
template void foo(T);
template<> void foo(int) {}
template<> void foo(int) = delete;
===
bug.cc:4:17: error: redefinition of 'void foo(T) [with T = int]'
template<> void foo(int) = delete;
^~~~
bug.cc:3:17: note: 'void foo(T) [with T = int]' previously declared here
template<> void foo(int) {}
^~~~
bug.cc: In function 'void foo(T) [with T = int]':
bug.cc:3:17: internal compiler error: tree check: expected block, have
error_mark in lower_function_body, at gimple-low.c:98
0x102f4bc tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/gcc/tree.c:9814
0x14904c7 tree_check(tree_node*, char const*, int, char const*, tree_code)
../../gcc/gcc/tree.h:3060
0x14904c7 lower_function_body
../../gcc/gcc/gimple-low.c:98
0x14904c7 execute
../../gcc/gcc/gimple-low.c:181
Please submit a full bug report, [etc.]
===
template void foo(T);
template<> void foo(int) {}
template<> void foo(int) = default;
===
bug.cc:4:17: error: redefinition of 'void foo(T) [with T = int]'
template<> void foo(int) = default;
^~~~
bug.cc:3:17: note: 'void foo(T) [with T = int]' previously declared here
template<> void foo(int) {}
^~~~
bug.cc:4:33: error: a template cannot be defaulted
template<> void foo(int) = default;
^~~
bug.cc: In function 'void foo(T) [with T = int]':
bug.cc:3:17: internal compiler error: Segmentation fault
template<> void foo(int) {}
^~~~
0xd9292f crash_signal
../../gcc/gcc/toplev.c:333
0x14901ae tree_check(tree_node*, char const*, int, char const*, tree_code)
../../gcc/gcc/tree.h:3059
0x14901ae lower_function_body
../../gcc/gcc/gimple-low.c:98
0x14901ae execute
../../gcc/gcc/gimple-low.c:181
Please submit a full bug report, [etc.]
These bugs appeared in GCC 4.5.0.
[Bug c/79358] gcc.dg/c99-stdint-1.c fails with excess error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79358 --- Comment #11 from Jakub Jelinek --- OT, the gcc/config/s390/linux.h SIZE_TYPE definition looks weird: (TARGET_64BIT ? "long unsigned int" : "long unsigned int") As both strings are the same, it would be much cleaner to just say "long unsigned int" Now everybody reading it will just try to spot the changes between those 2 strings.
[Bug target/79353] [7 regression] ICE in curr_insn_transform, at lra-constraints.c:3773
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79353 Eric Botcazou changed: What|Removed |Added Status|WAITING |NEW --- Comment #3 from Eric Botcazou --- > This was reduced from parfor.c with the help of creduce. To reproduce > (minimal set of flags I found): > > /home/jrtc27/src/gcc/obj/./gcc/xgcc -B/home/jrtc27/src/gcc/obj/./gcc/ > -B/usr/local/sparc64-unknown-linux-gnu/bin/ > -B/usr/local/sparc64-unknown-linux-gnu/lib/ -m32 -fPIC -O2 -c parfor.i -o > /tmp/parfor.o Thanks, I can reproduce with -mcpu=v8.
[Bug target/79353] [7 regression] ICE in curr_insn_transform, at lra-constraints.c:3773
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79353 Eric Botcazou changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org --- Comment #4 from Eric Botcazou --- Fixing.
[Bug target/79354] [7 Regression] -mcpu=power8 -O2 generates power9 instruction on powerpc64le-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79354 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Jakub Jelinek --- Fixed.
[Bug rtl-optimization/64081] [5/6/7 Regression] r217827 prevents RTL loop unroll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64081 --- Comment #36 from David Edelsohn --- The DBX_CONTIN patch should be in gcc/xcoffout.h, not in rs6000.h. The patch originally was added 2015-02-06.
[Bug c++/79362] New: internal compiler error: Segmentation fault - mmap: Cannot allocate memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79362
Bug ID: 79362
Summary: internal compiler error: Segmentation fault - mmap:
Cannot allocate memory
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: falemagn at gmail dot com
Target Milestone: ---
I cannot reproduce the bug locally, so I cannot provide more details, but it
does happen on godbolt where I was experimenting with the adherence to the
standard of various compilers.
This is the code that fails:
struct Base {
};
struct Derived: Base {
using Base::Base;
Derived(int value):
m_value(value)
{}
int m_value;
};
Derived t;
The error given reads like this:
:14:9: internal compiler error: Segmentation fault
Derived t;
^
mmap: Cannot allocate memory
Locally, I've traced the compiler with the massif valgrind's tool, but the
maximum amount of memory allocated was at around 1MiB.
You can check gcc7 output on godbolt at this link: https://godbolt.org/g/FnyE9N
[Bug c++/79363] New: [6/7 Regression] ICE with NSDMI and array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79363
Bug ID: 79363
Summary: [6/7 Regression] ICE with NSDMI and array
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reichelt at gcc dot gnu.org
Target Milestone: ---
The following valid code snippet triggers an ICE since GCC 6.1.0:
==
struct A {};
struct B
{
B() {}
int i;
A a[]{};
};
==
bug.cc: In constructor 'B::B()':
bug.cc:5:7: internal compiler error: tree check: expected tree that contains
'common' structure, have 'constructor' in perform_member_init, at cp/init.c:725
B() {}
^
0x10301f4 tree_contains_struct_check_failed(tree_node const*,
tree_node_structure_enum, char const*, int, char const*)
../../gcc/gcc/tree.c:9986
0x7c3da2 contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
../../gcc/gcc/tree.h:3174
0x7c3da2 perform_member_init
../../gcc/gcc/cp/init.c:725
0x7c3da2 emit_mem_initializers(tree_node*)
../../gcc/gcc/cp/init.c:1203
0x76a3d6 cp_parser_ctor_initializer_opt
../../gcc/gcc/cp/parser.c:14016
0x76a3d6 cp_parser_ctor_initializer_opt_and_function_body
../../gcc/gcc/cp/parser.c:21423
0x772dc1 cp_parser_function_definition_after_declarator
../../gcc/gcc/cp/parser.c:26206
0x77319c cp_parser_late_parsing_for_member
../../gcc/gcc/cp/parser.c:27088
0x74f9c9 cp_parser_class_specifier_1
../../gcc/gcc/cp/parser.c:22292
0x750a59 cp_parser_class_specifier
../../gcc/gcc/cp/parser.c:22318
0x750a59 cp_parser_type_specifier
../../gcc/gcc/cp/parser.c:16409
0x751827 cp_parser_decl_specifier_seq
../../gcc/gcc/cp/parser.c:13326
0x778901 cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:12647
0x779845 cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:12592
0x752527 cp_parser_declaration
../../gcc/gcc/cp/parser.c:12489
0x782c8b cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:12365
0x782f6a cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:4369
0x782f6a c_parse_file()
../../gcc/gcc/cp/parser.c:38356
0x8df643 c_common_parse_file()
../../gcc/gcc/c-family/c-opts.c:1107
Please submit a full bug report, [etc.]
[Bug target/78862] tile*: ICE with -fstack-protetor-strong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78862 --- Comment #1 from walt at gcc dot gnu.org --- Author: walt Date: Fri Feb 3 18:41:57 2017 New Revision: 245159 URL: https://gcc.gnu.org/viewcvs?rev=245159&root=gcc&view=rev Log: PR target/78862 * config/tilegx/tilegx.md (tilegx_expand_prologue): Add blockage after initial stackframe link reg save. * config/tilepro/tilepro.md (tilepro_expand_prologue): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/config/tilegx/tilegx.c trunk/gcc/config/tilepro/tilepro.c
[Bug target/78862] tile*: ICE with -fstack-protetor-strong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78862 --- Comment #2 from walt at gcc dot gnu.org --- Author: walt Date: Fri Feb 3 18:46:57 2017 New Revision: 245160 URL: https://gcc.gnu.org/viewcvs?rev=245160&root=gcc&view=rev Log: PR target/78862 * config/tilegx/tilegx.md (tilegx_expand_prologue): Add blockage after initial stackframe link reg save. * config/tilepro/tilepro.md (tilepro_expand_prologue): Likewise. Modified: branches/gcc-6-branch/gcc/ChangeLog branches/gcc-6-branch/gcc/config/tilegx/tilegx.c branches/gcc-6-branch/gcc/config/tilepro/tilepro.c
[Bug libstdc++/60936] [5/6/7 Regression] Binary code bloat with std::string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60936 --- Comment #27 from Jonathan Wakely --- Author: redi Date: Fri Feb 3 18:59:05 2017 New Revision: 245162 URL: https://gcc.gnu.org/viewcvs?rev=245162&root=gcc&view=rev Log: PR libstdc++/60936 reduce coupling between objects in libstdc++.a Move explicit instantiation definitions for string I/O functions into their own files so that iostream and locale definitions are not needed for uses of strings without I/O. Move functions for throwing C++11 exceptions into the individual files defining the exception types, so that using any of the functions from functexcept.cc doesn't pull in large pieces of the C++11 library. Finally, avoid using __int_to_char in snprintf_lite.cc to avoid pulling in locale-inst.cc for one function. PR libstdc++/60936 * src/c++11/Makefile.am: Add new files. * src/c++11/Makefile.in: Regenerate. * src/c++11/cow-string-inst.cc [!_GLIBCXX_USE_CXX11_ABI] (operator<<, operator>>, getline): Move explicit instantiations to ... * src/c++11/cow-string-io-inst.cc: ... new file. * src/c++11/cow-wstring-inst.cc [!_GLIBCXX_USE_CXX11_ABI] (operator<<, operator>>, getline): Move explicit instantiations to ... * src/c++11/cow-wstring-io-inst.cc: ... new file. * src/c++11/functexcept.cc (__throw_ios_failure, __throw_system_error) (__throw_future_error, __throw_bad_function_call): (__throw_regex_error): Move functions for C++11 exceptions to the files that define the exception types. * src/c++11/functional.cc (__throw_bad_function_call): Move here. * src/c++11/future.cc (__throw_future_error): Likewise. * src/c++11/ios.cc (__throw_ios_failure): Likewise. * src/c++11/regex.cc (__throw_regex_error): Likewise. * src/c++11/snprintf_lite.cc (__concat_size_t): Print decimal representation directly instead of calling __int_to_char. * src/c++11/sso_string.cc (__sso_string): New file for definition of __sso_string type. * src/c++11/string-io-inst.cc [_GLIBCXX_USE_CXX11_ABI]: New file for explicit instantiations of narrow string I/O functions. * src/c++11/system_error.cc (__throw_system_error): Move here. (__sso_string): Move to new file. * src/c++11/wstring-io-inst.cc [_GLIBCXX_USE_CXX11_ABI]: New file for explicit instantiations of wide string I/O functions. * src/c++98/misc-inst.cc [_GLIBCXX_USE_CXX11_ABI] (operator<<) (operator>>, getline): Remove explicit instantiations from here. Added: trunk/libstdc++-v3/src/c++11/cow-string-io-inst.cc - copied, changed from r245159, trunk/libstdc++-v3/src/c++11/cow-wstring-inst.cc trunk/libstdc++-v3/src/c++11/cow-wstring-io-inst.cc - copied, changed from r245159, trunk/libstdc++-v3/src/c++11/cow-wstring-inst.cc trunk/libstdc++-v3/src/c++11/sso_string.cc - copied, changed from r245159, trunk/libstdc++-v3/src/c++11/system_error.cc trunk/libstdc++-v3/src/c++11/string-io-inst.cc - copied, changed from r245159, trunk/libstdc++-v3/src/c++11/functional.cc trunk/libstdc++-v3/src/c++11/wstring-io-inst.cc - copied, changed from r245159, trunk/libstdc++-v3/src/c++11/cow-wstring-inst.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/src/c++11/Makefile.am trunk/libstdc++-v3/src/c++11/Makefile.in trunk/libstdc++-v3/src/c++11/cow-string-inst.cc trunk/libstdc++-v3/src/c++11/cow-wstring-inst.cc trunk/libstdc++-v3/src/c++11/functexcept.cc trunk/libstdc++-v3/src/c++11/functional.cc trunk/libstdc++-v3/src/c++11/future.cc trunk/libstdc++-v3/src/c++11/ios.cc trunk/libstdc++-v3/src/c++11/regex.cc trunk/libstdc++-v3/src/c++11/snprintf_lite.cc trunk/libstdc++-v3/src/c++11/system_error.cc trunk/libstdc++-v3/src/c++98/misc-inst.cc
[Bug testsuite/65484] FAIL: g++.dg/vect/pr36648.cc on powerpc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65484 --- Comment #4 from Bill Schmidt --- Author: wschmidt Date: Fri Feb 3 19:06:58 2017 New Revision: 245164 URL: https://gcc.gnu.org/viewcvs?rev=245164&root=gcc&view=rev Log: 2017-02-03 Bill Schmidt Backport from mainline 2017-01-27 Bill Schmidt PR target/65484 * g++.dg/vect/pr36648.cc: Modify to reflect that the loop is not vectorized on POWER unless hardware misaligned loads are available. Modified: branches/gcc-5-branch/gcc/testsuite/ChangeLog branches/gcc-5-branch/gcc/testsuite/g++.dg/vect/pr36648.cc
