[Bug lto/88396] -flto -Wl,--whole-archive causes "multiple definition" errors in elfutils (only for bfd, not gold)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88396 --- Comment #5 from Sergei Trofimovich --- Filed the bug on binutils side as well: https://sourceware.org/PR23958
[Bug lto/88396] -flto -Wl,--whole-archive causes "multiple definition" errors in elfutils (only for bfd, not gold)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88396 --- Comment #4 from Sergei Trofimovich --- Created attachment 45175 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45175=edit gcc-lto-616038.tar.gz
[Bug lto/88396] -flto -Wl,--whole-archive causes "multiple definition" errors in elfutils (only for bfd, not gold)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88396 --- Comment #3 from Sergei Trofimovich --- (In reply to Andrew Pinski from comment #1) > >I'm not sure if it's an ld or gcc bug. > > Since it works with gold, this is more likely an BFD ld issue. > > What version of binutils are you trying with? Using binutils-2.31.1 / gcc-8.2.0 [1] here. (In reply to Andrew Pinski from comment #2) > Maybe at one point related to > https://sourceware.org/bugzilla/show_bug.cgi?id=12319 . Aha, thank you!! I'll file another bug against binutils/ld refering this one. [1]: gcc -v Using built-in specs. COLLECT_GCC=/usr/bin/gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/8.2.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /tmp/portage-tmpdir/portage/sys-devel/gcc-8.2.0-r5/work/gcc-8.2.0/configure --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/8.2.0 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/8.2.0 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/8.2.0/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/8.2.0/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/include/g++-v8 --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/8.2.0/python --enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --enable-nls --without-included-gettext --enable-checking=release --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 8.2.0-r5 p1.6' --disable-esp --enable-libstdcxx-time --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-multilib --with-multilib-list=m32,m64 --disable-altivec --disable-fixed-point --enable-targets=all --enable-libgomp --disable-libmudflap --disable-libssp --disable-libmpx --disable-systemtap --enable-vtable-verify --enable-libvtv --enable-lto --with-isl --disable-isl-version-check --enable-libsanitizer --enable-default-pie --enable-default-ssp Thread model: posix gcc version 8.2.0 (Gentoo 8.2.0-r5 p1.6)(In reply to Andrew Pinski from comment #2)
[Bug tree-optimization/88398] vectorization failure for a small loop to do byte comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88398 --- Comment #2 from Jiangning Liu --- memcmp doesn't return the position where they differ.
[Bug other/80203] libiberty fails to compile regex.c correctly when gcc is configured --with-sysroot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80203 Jeremy Huddleston Sequoia changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Jeremy Huddleston Sequoia --- This issue is not present in gcc8.
[Bug tree-optimization/88398] vectorization failure for a small loop to do byte comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88398 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization CC||pinskia at gcc dot gnu.org Severity|normal |enhancement --- Comment #1 from Andrew Pinski --- Maybe it should be converting it to memcmp instead
[Bug tree-optimization/88398] New: vectorization failure for a small loop to do byte comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88398
Bug ID: 88398
Summary: vectorization failure for a small loop to do byte
comparison
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jiangning.liu at amperecomputing dot com
Target Milestone: ---
For the small case below, GCC -O3 can't vectorize the small loop to do byte
comparison in func2.
void *malloc(long unsigned int);
typedef struct {
unsigned char *buffer;
} data;
static unsigned char *func1(data *d)
{
return d->buffer;
}
static int func2(int max, int pos, unsigned char *cur)
{
unsigned char *p = cur + pos;
int len = 0;
while (++len != max)
if (p[len] != cur[len])
break;
return cur[len];
}
int main (int argc) {
data d;
d.buffer = malloc(2*argc);
return func2(argc, argc, func1());
}
At the moment, the following code is generated for this loop,
4004d4: 38616862ldrbw2, [x3,x1]
4004d8: 6b5fcmp w2, w0
4004dc: 54a1b.ne4004f0
4004e0: 38616880ldrbw0, [x4,x1]
4004e4: 6b01027fcmp w19, w1
4004e8: 91000421add x1, x1, #0x1
4004ec: 5441b.ne4004d4
In fact, this loop can be vectorized by checking if the comparison size is
aligned to SIMD register length. It may introduce run time overhead, but cost
model could make decision on doing it or not.
[Bug lto/88396] -flto -Wl,--whole-archive causes "multiple definition" errors in elfutils (only for bfd, not gold)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88396 --- Comment #2 from Andrew Pinski --- Maybe at one point related to https://sourceware.org/bugzilla/show_bug.cgi?id=12319 .
[Bug driver/35532] Native GCC no longer searches $prefix/lib for startfiles when run from $objdir
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35532 --- Comment #18 from Andrew Pinski --- > 1. build and install Glibc --prefix=/tmp/foo Since glibc is not able to build this way any more, I doubt this can be supported.
[Bug driver/35532] Native GCC no longer searches $prefix/lib for startfiles when run from $objdir
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35532 Eric Gallager changed: What|Removed |Added Status|RESOLVED|WAITING Resolution|INVALID |--- --- Comment #17 from Eric Gallager --- Oops I didn't mean to close this yet; I decided to cc people instead so they can have a chance to comment before it gets closed
[Bug bootstrap/32497] Crosscomiling native sh3 gcc on a 64-bit host fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32497 --- Comment #15 from Eric Gallager --- (In reply to Valeriy E. Ushakov from comment #11) > Created attachment 44668 [details] > Diff against gcc-6.4.0 > > This is essentially the same diff except gcc now provides its own > HOST_WIDE_INT_C() macro, so the patch uses that instead of defining its own. can you please send it to the gcc-patches mailing list for review?
[Bug middle-end/88397] attribute malloc ignored on function pointers when alloc_size is accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88397 --- Comment #2 from Andrew Pinski --- > noreturn See the FIXME right above it: /* FIXME: logically, noreturn attributes should be listed as "false, true, true" and apply to function types. But implementing this would require all the places in the compiler that use TREE_THIS_VOLATILE on a decl to identify non-returning functions to be located and fixed to check the function type instead. */
[Bug middle-end/88397] attribute malloc ignored on function pointers when alloc_size is accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88397
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2018-12-07
Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #1 from Martin Sebor ---
Based on quick review of c-attribs.c it looks like attributes noreturn and
nothrow suffer from the same limitation as malloc. It should be easy to fix.
I'm testing the patch below. If it doesn't cause major problems I'll add
tests, update the manual, and post it.
Index: gcc/c-family/c-attribs.c
===
--- gcc/c-family/c-attribs.c(revision 266881)
+++ gcc/c-family/c-attribs.c(working copy)
@@ -257,7 +257,7 @@ const struct attribute_spec c_common_attribute_tab
would require all the places in the compiler that use TREE_THIS_VOLATILE
on a decl to identify non-returning functions to be located and fixed
to check the function type instead. */
- { "noreturn", 0, 0, true, false, false, false,
+ { "noreturn", 0, 0, false, true, true, false,
handle_noreturn_attribute,
attr_noreturn_exclusions },
{ "volatile", 0, 0, true, false, false, false,
@@ -330,7 +330,7 @@ const struct attribute_spec c_common_attribute_tab
{ "no_profile_instrument_function", 0, 0, true, false, false, false,
handle_no_profile_instrument_function_attribute,
NULL },
- { "malloc", 0, 0, true, false, false, false,
+ { "malloc", 0, 0, false, true, true, false,
handle_malloc_attribute, attr_alloc_exclusions },
{ "returns_twice", 0, 0, true, false, false, false,
handle_returns_twice_attribute,
@@ -372,7 +372,7 @@ const struct attribute_spec c_common_attribute_tab
handle_nonnull_attribute, NULL },
{ "nonstring", 0, 0, true, false, false, false,
handle_nonstring_attribute, NULL },
- { "nothrow",0, 0, true, false, false, false,
+ { "nothrow",0, 0, false, true, true, false,
handle_nothrow_attribute, NULL },
{ "may_alias", 0, 0, false, true, false, false, NULL, NULL },
{ "cleanup", 1, 1, true, false, false, false,
[Bug target/39222] out of memory bootstrapping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39222 --- Comment #7 from Eric Gallager --- (In reply to xiaoyuanbo from comment #6) > total root What did you mean by this?
[Bug target/38093] undefined predicates in bfin.md
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38093 --- Comment #3 from Eric Gallager --- Created attachment 45174 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45174=edit uudecoded (In reply to Andrew Pinski from comment #2) > (In reply to Eric Gallager from comment #1) > > That patch looks like binary; are you sure it's really a patch? > > It is uuencoded. And yes a text file will look that funny as uuencoded file. ah ok, attaching uudecoded version
[Bug target/37637] Build fails with reserved constraints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37637 Eric Gallager changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2018-12-07 Ever confirmed|0 |1 --- Comment #1 from Eric Gallager --- Does this still happen with newer versions of GCC?
[Bug driver/35532] Native GCC no longer searches $prefix/lib for startfiles when run from $objdir
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35532 Eric Gallager changed: What|Removed |Added Status|WAITING |RESOLVED CC||mmitchel at gcc dot gnu.org, ||pinskia at gcc dot gnu.org, ||rhill at gentoo dot org Resolution|--- |INVALID
[Bug c++/79604] attribute noreturn inconsistent between C and C++, undocumented for function pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79604 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-12-07 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=88397 Ever confirmed|0 |1 Known to fail||7.3.0, 8.2.0, 9.0 --- Comment #2 from Martin Sebor --- See also bug 88397 for a similar problem with attribute malloc (but one that affects both C and C++ the same way). Let me also confirm this bug since this is at least the second time I've run into it.
[Bug bootstrap/65725] Bootstrap errors on Solaris 10 x86-64, including object diffs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65725 --- Comment #4 from Eric Gallager --- (In reply to Richard Biener from comment #1) > Please always say how you configured GCC. Reporter has since done this; does this bug still need to stay in WAITING?
[Bug middle-end/88397] New: attribute malloc ignored on function pointers when alloc_size is accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88397 Bug ID: 88397 Summary: attribute malloc ignored on function pointers when alloc_size is accepted Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: msebor at gcc dot gnu.org Target Milestone: --- I noticed this while testing a fix for bug 88372. GCC accepts attributes alloc_align and alloc_size on declarations of function pointers but ignores (with a warning) attribute malloc. Besides being inconsistent, it makes it impossible to get GCC to emit optimally efficient code for calls via function pointers to malloc-like functions (such as malloc or aligned_alloc). The same limitation applies to defining function types with attribute malloc. $ cat u.c && gcc -O2 -S -Wall -Wextra u.c typedef __SIZE_TYPE__ size_t; __attribute__ ((alloc_align (1), alloc_size (2))) void* (*p)(size_t, size_t) = __builtin_aligned_alloc; __attribute__ ((alloc_align (1), alloc_size (2), malloc)) void* (*q)(size_t, size_t) = __builtin_aligned_alloc; u.c:7:1: warning: ‘malloc’ attribute ignored [-Wattributes] 7 | void* (*q)(size_t, size_t) = __builtin_aligned_alloc; | ^~~~
[Bug bootstrap/59447] --with-dwarf2 should be documented as meaning "DWARF 2 or later" instead of just "DWARF 2"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59447 Eric Gallager changed: What|Removed |Added CC||sandra at codesourcery dot com --- Comment #4 from Eric Gallager --- Sandra, if you're going thru documentation bugs by date last modified, this one might not show up as "old" even though it is actually old (only recent activity has been me confirming and retitling it)
[Bug target/88271] Omit test instruction after add
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88271 --- Comment #8 from Daniel Fruzynski --- I have results from Callgrind. Cycle estimation for MoveRows function (without children) is 58.29%. This is for app without test instruction. So in synthetic benchmark for this function only speed change would be about 2%.
[Bug c++/88146] ice in tsubst_copy, at cp/pt.c:16014
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88146 Alexandre Oliva changed: What|Removed |Added Depends on||87814 --- Comment #9 from Alexandre Oliva --- https://gcc.gnu.org/ml/gcc-patches/2018-12/msg00424.html Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87814 [Bug 87814] [9 Regression] ICE in in tsubst_copy, at cp/pt.c:15962 with range-v3
[Bug c++/87814] [9 Regression] ICE in in tsubst_copy, at cp/pt.c:15962 with range-v3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87814 --- Comment #7 from Alexandre Oliva --- https://gcc.gnu.org/ml/gcc-patches/2018-12/msg00423.html
[Bug c++/85569] [8 Regression] is_invocable(F, decltype(objs)...) fails with "not supported by dump_expr#" unless via indirection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85569 Alexandre Oliva changed: What|Removed |Added Status|ASSIGNED|NEW --- Comment #12 from Alexandre Oliva --- FTR, the installed patch does not fix the reported problem, but rather another problem that had surfaced after the report, that affected the (preprocessed) workaround testcase. GCC remains unable to compile the original testcase.
[Bug target/88271] Omit test instruction after add
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88271 --- Comment #7 from Daniel Fruzynski --- One more note: this particular function creates matrices with all possible permutations of row order of original matrix, which satisfies some additional criteria. So this optimization may be applicable to other algorithms which generates permutations.
[Bug lto/88396] -flto -Wl,--whole-archive causes "multiple definition" errors in elfutils (only for bfd, not gold)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88396 --- Comment #1 from Andrew Pinski --- >I'm not sure if it's an ld or gcc bug. Since it works with gold, this is more likely an BFD ld issue. What version of binutils are you trying with?
[Bug target/88271] Omit test instruction after add
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88271 --- Comment #6 from Daniel Fruzynski --- Average for version with test is 246.313ms, I deleted too many digits.
[Bug target/88271] Omit test instruction after add
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88271 --- Comment #5 from Daniel Fruzynski --- How to use perf? I did not have change to use it yet, I usually use time command or callgrind. I have run my app compiled with AVX2 instructions on Xeon E5-2683 v3, CentOS 7.6, on idle CPU. I run it 3 times for both versions (w/ and w/o test instructions). Here are results: With test: Average 246,3 ms, StdDev 0,198 W/o test: Average 244,013ms, StdDev 0,043 Version with test is 0,94% slower - this is result which I expected.
[Bug target/85593] [7/8/9 Regression] GCC on ARM allocates R3 for local variable when calling naked function with O2 optimizations enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85593 --- Comment #14 from Jakub Jelinek --- Author: jakub Date: Thu Dec 6 23:41:04 2018 New Revision: 266881 URL: https://gcc.gnu.org/viewcvs?rev=266881=gcc=rev Log: PR target/85593 * final.c (rest_of_handle_final): Don't call collect_fn_hard_reg_usage for functions with naked attribute. * gcc.target/i386/pr85593.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr85593.c Modified: trunk/gcc/ChangeLog trunk/gcc/final.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/85770] [9 Regression] ICE: in lra_eliminate, at lra-eliminations.c:1439 with -march=nano-1000
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85770 --- Comment #7 from Jakub Jelinek --- Author: jakub Date: Thu Dec 6 23:39:12 2018 New Revision: 266880 URL: https://gcc.gnu.org/viewcvs?rev=266880=gcc=rev Log: PR rtl-optimization/85770 * gcc.target/i386/pr85770.c: Require int128 effective target. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/i386/pr85770.c
[Bug fortran/88377] ICE in gfc_omp_clause_copy_ctor, at fortran/trans-openmp.c:614
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88377 --- Comment #2 from Jakub Jelinek --- Author: jakub Date: Thu Dec 6 23:29:04 2018 New Revision: 266879 URL: https://gcc.gnu.org/viewcvs?rev=266879=gcc=rev Log: PR fortran/88377 * trans-openmp.c (gfc_omp_clause_default_ctor, gfc_omp_clause_copy_ctor, gfc_omp_clause_assign_op, gfc_omp_clause_linear_ctor, gfc_omp_clause_dtor): Only consider GFC_DECL_GET_SCALAR_ALLOCATABLE vars as scalar allocatables if they have pointer type. * gfortran.dg/gomp/pr88377.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/gomp/pr88377.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-openmp.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/88367] [9 Regression] -fno-delete-null-pointer-checks doesn't work properly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88367 --- Comment #10 from Jakub Jelinek --- Author: jakub Date: Thu Dec 6 23:28:04 2018 New Revision: 266878 URL: https://gcc.gnu.org/viewcvs?rev=266878=gcc=rev Log: PR c/88367 * tree-vrp.c (extract_range_from_binary_expr): For POINTER_PLUS_EXPR with -fno-delete-null-pointer-checks, set_nonnull only if the pointer is non-NULL and offset is known to have most significant bit clear. * vr-values.c (vr_values::vrp_stmt_computes_nonzero): For ADDR_EXPR of MEM_EXPR, return true if the MEM_EXPR has non-zero offset with most significant bit clear. If offset does have most significant bit set and -fno-delete-null-pointer-checks, don't return true even if the base pointer is non-NULL. * gcc.dg/tree-ssa/pr88367.c: New test. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/pr88367.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vrp.c trunk/gcc/vr-values.c
[Bug c++/87506] [7/8/9 Regression] ICE with inherited constexpr constructor with const argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87506 --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Thu Dec 6 23:25:10 2018 New Revision: 266877 URL: https://gcc.gnu.org/viewcvs?rev=266877=gcc=rev Log: PR c++/87506 * constexpr.c (adjust_temp_type): Handle EMPTY_CLASS_EXPR. * g++.dg/cpp0x/constexpr-87506.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-87506.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/constexpr.c trunk/gcc/testsuite/ChangeLog
[Bug lto/88396] New: -flto -Wl,--whole-archive causes "multiple definition" errors in elfutils (only for bfd, not gold)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88396
Bug ID: 88396
Summary: -flto -Wl,--whole-archive causes "multiple definition"
errors in elfutils (only for bfd, not gold)
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at inbox dot ru
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Original example is a build failure of elfutils-0.175 against CFLAGS=-flto at:
https://bugs.gentoo.org/616038
Extracted minimal reproducer looks like that:
$ cat libdw.map
ELFUTILS_0.143 {
global:
dwarf_bytesize;
};
$ cat dwarf_bytesize.os.c
void dwarf_bytesize (void) {}
asm (".symver dwarf_bytesize,dwarf_bytesize@@@ELFUTILS_0.143");
Reproducer:
$ gcc -flto -c dwarf_bytesize.os.c -o dwarf_bytesize.os -fPIC
$ gcc-ar cr libdw_pic.a dwarf_bytesize.os
$ gcc-ranlib libdw_pic.a
$ gcc -flto -o libdw.so -shared -Wl,--version-script,libdw.map,--no-undefined
-Wl,--whole-archive libdw_pic.a -Wl,--no-whole-archive -fuse-ld=bfd
/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../x86_64-pc-linux-gnu/bin/ld.bfd:
/tmp/ccYR58eH.ltrans0.ltrans.o:(*IND*+0x0): multiple definition of
`dwarf_bytesize'; dwarf_bytesize.os (symbol from plugin):(.text+0x0): first
defined here
I'm not sure if it's an ld or gcc bug.
[Bug c++/86747] [8/9 Regression] rejects-valid with redundant friend declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86747 --- Comment #6 from Alexandre Oliva --- Author: aoliva Date: Thu Dec 6 23:18:40 2018 New Revision: 266875 URL: https://gcc.gnu.org/viewcvs?rev=266875=gcc=rev Log: [PR86747] tsubst friend tpl ctxt before looking it up for dupes When a member template is redeclared as a friend, we enter the context of the member before looking it up, and then we check that the decls are compatible. However, when the member template references template types of the enclosing context, say an enclosing template class, the compare fails because the friend decl is already tsubsted, whereas the looked up name isn't. The problem is that the enclosing context is taken from the friend declaration before tsubsting it, so we look up in the context of the generic template instead of that of the tsubsted one we're specializing. The solution is to tsubst the enclosing context when it's a non-namespace scope. for gcc/cp/ChangeLog PR c++/86747 * pt.c (tsubst_friend_class): Enter tsubsted class context. for gcc/testsuite/ChangeLog PR c++/86747 * g++.dg/pr86747.C: New. Added: trunk/gcc/testsuite/g++.dg/pr86747.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog
[Bug c++/86397] [7/8/9 Regression] g++ ICE at on valid code in nothrow_spec_p, at cp/except.c:1158
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86397 --- Comment #4 from Alexandre Oliva --- Author: aoliva Date: Thu Dec 6 23:18:30 2018 New Revision: 266874 URL: https://gcc.gnu.org/viewcvs?rev=266874=gcc=rev Log: [PR86397] resolve nondependent noexcept specs early in C++1[14] build_noexcept_spec refrained from resolving nondependent noexcept expressions when they were not part of the function types (C++ 11 and 14). This caused problems during mangling: canonical_eh_spec, when called on the template function type, would find an unresolved but not explicitly deferred expression, and nothrow_spec_p would reject it. We could relax the mangling logic to skip canonical_eh_spec, but since -Wnoexcept-type warns when mangling function names that change as noexcept specs become part of types and of mangling in C++17, and the test at mangling time may give incorrect results if the spec is not resolved, we might as well keep things simple and resolve nondependent noexcept specs sooner rather than later. This is what this patch does. for gcc/cp/ChangeLog PR c++/86397 * except.c (build_noexcept_spec): Resolve nondependent expressions. for gcc/testsuite/ChangeLog PR c++/86397 * g++.dg/cpp0x/pr86397-1.C: New. * g++.dg/cpp0x/pr86397-2.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/pr86397-1.C trunk/gcc/testsuite/g++.dg/cpp0x/pr86397-2.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/except.c trunk/gcc/testsuite/ChangeLog
[Bug target/88316] numerous big-endian issues with compatibility implementations of vector intrinsics for powerpc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88316 --- Comment #3 from pc at gcc dot gnu.org --- Author: pc Date: Thu Dec 6 22:14:55 2018 New Revision: 266870 URL: https://gcc.gnu.org/viewcvs?rev=266870=gcc=rev Log: [rs6000] Enable x86-compat vector intrinsics testing The testsuite tests for the compatibility implementations of x86 vector intrinsics for "powerpc" had been inadvertently made to PASS without actually running the test code. This patch removes the code which kept the tests from running the actual test code. 2018-12-06 Paul A. Clarke [gcc/testsuite] PR target/88316 * gcc.target/powerpc/bmi-check.h: Remove test for __BUILTIN_CPU_SUPPORTS__, thereby enabling test code to run. * gcc.target/powerpc/bmi2-check.h: Likewise. * gcc.target/powerpc/mmx-check.h: Likewise. * gcc.target/powerpc/sse-check.h: Likewise. * gcc.target/powerpc/sse2-check.h: Likewise. * gcc.target/powerpc/sse3-check.h: Likewise. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/powerpc/bmi-check.h trunk/gcc/testsuite/gcc.target/powerpc/bmi2-check.h trunk/gcc/testsuite/gcc.target/powerpc/mmx-check.h trunk/gcc/testsuite/gcc.target/powerpc/sse-check.h trunk/gcc/testsuite/gcc.target/powerpc/sse2-check.h trunk/gcc/testsuite/gcc.target/powerpc/sse3-check.h
[Bug target/88316] numerous big-endian issues with compatibility implementations of vector intrinsics for powerpc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88316 --- Comment #2 from pc at gcc dot gnu.org --- Author: pc Date: Thu Dec 6 22:11:01 2018 New Revision: 266869 URL: https://gcc.gnu.org/viewcvs?rev=266869=gcc=rev Log: [rs6000] Fix x86-compat vector intrinsics testcases for BE, 32bit Fix general endian issues found in the test cases for thecompatibility implementations of the x86 vector intrinsics. (The tests had been inadvertently made to PASS without actually running the test code. A later patch fixes this issue.) Additionally, a new is added, as some of the APIs therein are now used by the test cases. It is _not_ a complete implementation of the SSE4 interfaces, only the few "extract" interfaces uses by the tests. 2018-12-06 Paul A. Clarke [gcc] PR target/88316 * config/rs6000/smmintrin.h: New file. * config.gcc: Add smmintrin.h to extra_headers for powerpc*-*-*. [gcc/testsuite] PR target/88316 * gcc.target/powerpc/mmx-packssdw-1.c: Fixes for big-endian. * gcc.target/powerpc/mmx-packsswb-1.c: Likewise. * gcc.target/powerpc/mmx-packuswb-1.c: Likewise. * gcc.target/powerpc/mmx-pmulhw-1.c: Likewise. * gcc.target/powerpc/sse-cvtpi32x2ps-1.c: Likewise. * gcc.target/powerpc/sse-cvtpu16ps-1.c: Likewise. * gcc.target/powerpc/sse-cvtss2si-1.c: Likewise. * gcc.target/powerpc/sse-cvtss2si-2.c: Likewise. * gcc.target/powerpc/sse2-pshufhw-1.c: Likewise. * gcc.target/powerpc/sse2-pshuflw-1.c: Likewise. Added: trunk/gcc/config/rs6000/smmintrin.h Modified: trunk/gcc/ChangeLog trunk/gcc/config.gcc trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/powerpc/mmx-packssdw-1.c trunk/gcc/testsuite/gcc.target/powerpc/mmx-packsswb-1.c trunk/gcc/testsuite/gcc.target/powerpc/mmx-packuswb-1.c trunk/gcc/testsuite/gcc.target/powerpc/mmx-pmulhw-1.c trunk/gcc/testsuite/gcc.target/powerpc/sse-cvtpi32x2ps-1.c trunk/gcc/testsuite/gcc.target/powerpc/sse-cvtpu16ps-1.c trunk/gcc/testsuite/gcc.target/powerpc/sse-cvtss2si-1.c trunk/gcc/testsuite/gcc.target/powerpc/sse-cvtss2si-2.c trunk/gcc/testsuite/gcc.target/powerpc/sse2-pshufhw-1.c trunk/gcc/testsuite/gcc.target/powerpc/sse2-pshuflw-1.c
[Bug target/88316] numerous big-endian issues with compatibility implementations of vector intrinsics for powerpc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88316 --- Comment #1 from pc at gcc dot gnu.org --- Author: pc Date: Thu Dec 6 22:03:25 2018 New Revision: 266868 URL: https://gcc.gnu.org/viewcvs?rev=266868=gcc=rev Log: [rs6000] x86-compat vector intrinsics fixes for BE, 32bit Fix general endian and 32-bit mode issues found in the compatibility implementations of the x86 vector intrinsics when running the associated test suite tests. (The tests had been inadvertently made to PASS without actually running the test code. A later patch fixes this issue.) 2018-12-03 Paul A. Clarke PR target/88316 * config/rs6000/mmintrin.h (_mm_unpackhi_pi8): Fix for big-endian. (_mm_unpacklo_pi8): Likewise. (_mm_mulhi_pi16): Likewise. (_mm_packs_pi16): Fix for big-endian. Use preferred API. (_mm_packs_pi32): Likewise. (_mm_packs_pu16): Likewise. * config/rs6000/xmmintrin.h (_mm_cvtss_si32): Fix for big-endian. (_mm_cvtss_si64): Likewise. (_mm_cvtpi32x2_ps): Likewise. (_mm_shuffle_ps): Likewise. (_mm_movemask_pi8): Likewise. (_mm_mulhi_pu16): Likewise. (_mm_sad_pu8): Likewise. (_mm_sad_pu8): Likewise. (_mm_cvtpu16_ps): Fix for big-endian. Use preferred API. (_mm_cvtpu8_ps): Likewise. (_mm_movemask_ps): Better #else case for big-endian (no functional change). (_mm_shuffle_pi16): Likewise. * config/rs6000/emmintrin.h (_mm_movemask_pd): Fix for big-endian. Better #else case for big-endian (no functional change). (_mm_movemask_epi8): Likewise. (_mm_shufflehi_epi16): Likewise. (_mm_shufflelo_epi16): Likewise. (_mm_shuffle_epi32): Likewise. (_mm_mul_epu32): Fix for big-endian. (_mm_bsrli_si128): Likewise. (_mm_cvtps_pd): Better #else case for big endian. (_mm_mulhi_epi16): Likewise. (_mm_mul_epu32): Likewise. (_mm_slli_si128): Likewise. (_mm_sll_epi16): Likewise. (_mm_sll_epi32): Likewise. (_mm_sra_epi16): Likewise. (_mm_sra_epi32): Likewise. (_mm_srl_epi16): Likewise. (_mm_srl_epi32): Likewise. (_mm_mulhi_epu16): Likewise. (_mm_sad_epu8): Likewise. * config/rs6000/pmmintrin.h (_mm_hadd_ps): Fix for big-endian. (_mm_sub_ps): Likewise. * config/rs6000/mmintrin.h (_mm_cmpeq_pi8): Fix for 32-bit mode. * gcc/config/rs6000/tmmintrin.h (_mm_alignr_epi8): Use ENDIAN macros consistently (no functional changes). (_mm_alignr_pi8): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/emmintrin.h trunk/gcc/config/rs6000/mmintrin.h trunk/gcc/config/rs6000/pmmintrin.h trunk/gcc/config/rs6000/tmmintrin.h trunk/gcc/config/rs6000/xmmintrin.h
[Bug sanitizer/80953] Support libsanitizer on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80953 --- Comment #30 from Eric Botcazou --- > Is already included in sol2.h (ASAN_CC1_SPEC). OK. Then unwind info is needed in the epilogue?
[Bug c++/87861] [9 regression] ICE in output_constructor_regular_field, at varasm.c:5165
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87861 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-12-06 CC||law at redhat dot com Ever confirmed|0 |1
[Bug c++/88136] -Wdeprecated-copy is draconian and shouldn't be in -Wall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88136 --- Comment #4 from Jason Merrill --- Author: jason Date: Thu Dec 6 21:17:08 2018 New Revision: 266867 URL: https://gcc.gnu.org/viewcvs?rev=266867=gcc=rev Log: PR c++/88136 - -Wdeprecated-copy false positives Deprecating the copy operations because the class has a user-provided destructor turns out to have too many false positives; this patch adjusts -Wdeprecated-copy to only deprecate if the other copy operation is user-provided. To get the earlier behavior, people can explicitly request it with -Wdeprecated-copy-dtor. gcc/c-family/ * c.opt (Wdeprecated-copy-dtor): New. (Wdeprecated-copy): Move to -Wextra. gcc/cp/ * class.c (classtype_has_depr_implicit_copy): Rename from classtype_has_user_copy_or_dtor. * method.c (lazily_declare_fn): Adjust. * decl2.c (cp_warn_deprecated_use): Refer to -Wdeprecated-copy-dtor if deprecation is due to a destructor. Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c.opt trunk/gcc/cp/ChangeLog trunk/gcc/cp/class.c trunk/gcc/cp/cp-tree.h trunk/gcc/cp/decl2.c trunk/gcc/cp/method.c trunk/gcc/doc/invoke.texi trunk/gcc/testsuite/g++.dg/cpp0x/depr-copy1.C
[Bug target/88271] Omit test instruction after add
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88271
--- Comment #4 from Uroš Bizjak ---
(In reply to Daniel Fruzynski from comment #3)
> What about adding new pass at the end? It would look for various possible
> optimizations, which were missed earlier because they are cross-basic block.
We do have post-reload compare elimination that works cross-BB. However, it
runs before BB-reordering pass (which duplicates the compare), so this is what
compare elimination pass sees:
1: NOTE_INSN_DELETED
6: NOTE_INSN_BASIC_BLOCK 2
3: NOTE_INSN_FUNCTION_BEG
4: dx:SI=0x1
REG_EQUAL 0x1
5: ax:SI=0
REG_EQUAL 0
11: L11:
12: NOTE_INSN_BASIC_BLOCK 3
13: flags:CCZ=cmp(dx:SI,0) <--- here is the compare
14: pc={(flags:CCZ==0)?L24:pc}
REG_BR_PROB 536870916
15: NOTE_INSN_BASIC_BLOCK 4
17: dx:DI=sign_extend(ax:SI)
18: dx:SI=[dx:DI*0x4+`data']
19: {dx:SI=dx:SI<<0x1;clobber flags:CC;} <--- here is the "add"
20: {ax:SI=ax:SI+0x1;clobber flags:CC;}
35: pc=L11
36: barrier
24: L24:
25: NOTE_INSN_BASIC_BLOCK 5
26: {ax:SI=ax:SI-0x1;clobber flags:CC;}
28: dx:DI=sign_extend(ax:SI)
29: dx:SI=[dx:DI*0x4+`data']
37: pc=L11
38: barrier
39: NOTE_INSN_DELETED
The pass can't do anything in this case, several edges are going into BB3.
FYI, BB-reorder pass creates:
6: NOTE_INSN_BASIC_BLOCK 2
41: NOTE_INSN_PROLOGUE_END
3: NOTE_INSN_FUNCTION_BEG
4: dx:SI=0x1
REG_EQUAL 0x1
46: {ax:DI=0;clobber flags:CC;}
11: L11:
12: NOTE_INSN_BASIC_BLOCK 3
13: flags:CCZ=cmp(dx:SI,0)
REG_DEAD dx:SI
14: pc={(flags:CCZ==0)?L24:pc}
REG_DEAD flags:CCZ
REG_BR_PROB 536870916
15: NOTE_INSN_BASIC_BLOCK 4
17: dx:DI=sign_extend(ax:SI)
18: dx:SI=[dx:DI*0x4+`data']
19: {dx:SI=dx:SI<<0x1;clobber flags:CC;}
REG_UNUSED flags:CC
20: {ax:SI=ax:SI+0x1;clobber flags:CC;}
REG_UNUSED flags:CC
50: NOTE_INSN_BASIC_BLOCK 5
48: flags:CCZ=cmp(dx:SI,0)
REG_DEAD dx:SI
49: pc={(flags:CCZ==0)?L24:pc}
REG_DEAD flags:CCZ
REG_BR_PROB 536870916
and then scheduler reorders insn stream to:
...
15: NOTE_INSN_BASIC_BLOCK 4
17: dx:DI=sign_extend(ax:SI)
20: {ax:SI=ax:SI+0x1;clobber flags:CC;}
REG_UNUSED flags:CC
18: dx:SI=[dx:DI*0x4+`data']
19: {dx:SI=dx:SI<<0x1;clobber flags:CC;}
REG_UNUSED flags:CC
48: flags:CCZ=cmp(dx:SI,0)
REG_DEAD dx:SI
49: pc={(flags:CCZ!=0)?L51:pc}
REG_DEAD flags:CCZ
REG_BR_PROB 536870916
...
So, this is indeed an exceptional situation, it is pure coincidence that the
optimization possibility is created. We *can* rerun compare elimination pass
after the scheduler, but I suspect the above case will be the one and only it
will catch.
I'm curious if removing this extra instruction really improves the runtime
above the noise level. Can you profile the loop w/ and w/o compare insn using
perf?
[Bug tree-optimization/88372] alloc_size attribute is ignored on function pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88372 Martin Sebor changed: What|Removed |Added Keywords||patch --- Comment #4 from Martin Sebor --- Patch: https://gcc.gnu.org/ml/gcc-patches/2018-12/msg00401.html
[Bug sanitizer/80953] Support libsanitizer on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80953 --- Comment #29 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #28 from Eric Botcazou --- [...] >> -fno-delayed-branch made no difference. > > What about -fasynchronous-unwind-tables? Is already included in sol2.h (ASAN_CC1_SPEC).
[Bug tree-optimization/88240] Potential optimization bug: invalid pre-load of floating-point value could cause SIGFPE-underflow if value is integer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88240
--- Comment #10 from Thomas De Schampheleire ---
I was able to further investigate and reduce the problem.
Qemu is now out of the picture, I can reproduce the issue directly on a real
CPU. All I need to do is enable the 'underflow' exception bit using
feenableexcept. Note that, as you will see below in the gdb output, the
denormal exception is not enabled.
Toolchain is still the same: gcc 7.3.0, glibc 2.27, binutils 2.30. See details
in bug description.
Below is the simplified test program, based on [1] with the addition of the
exception enabling code.
#define _GNU_SOURCE
#include
#include
#include
static int callback(void *NotUsed, int argc, char **argv, char **azColName){
int i;
for(i=0; i end of added code
rc = sqlite3_open(argv[2], );
if( rc ){
fprintf(stderr, "Can't open database: %s\n", sqlite3_errmsg(db));
sqlite3_close(db);
return(1);
}
rc = sqlite3_exec(db, argv[3], callback, 0, );
if( rc!=SQLITE_OK ){
fprintf(stderr, "SQL error: %s\n", zErrMsg);
sqlite3_free(zErrMsg);
}
sqlite3_close(db);
return 0;
}
I compiled this code and sqlite3 (version 321, but I don't think the exact
version matters much) with the mentioned toolchain.
Compilation command used for the test program:
/home/tdescham/repo/isam/buildroot-qemu/output/host/opt/ext-toolchain/bin/i686-pc-linux-gnu-gcc
--sysroot
/home/tdescham/repo/isam/buildroot-qemu/output/host/i686-buildroot-linux-gnu/sysroot
-march=pentiumpro -o sqlite-test sqlite-test.c -lsqlite3 -lm -g -O0
To reproduce, first create a simple database, not yet enabling exceptions:
$ env
LD_LIBRARY_PATH=/home/tdescham/repo/isam/buildroot-qemu/output/staging/usr/lib
./sqlite-test 0 /tmp/foo.db "create table foobar (id int primary key, name
text)"
Not enabling exceptions.
fctrl = 037f
Now, we can trigger the bug by showing some SQL output, if we enable the
underflow exception:
$ env
LD_LIBRARY_PATH=/home/tdescham/repo/isam/buildroot-qemu/output/staging/usr/lib
./sqlite-test 1 /tmp/foo.db "select sql from sqlite_master where sql not NULL;"
Enabling exception: FE_UNDERFLOW
fctrl = 036f
fish: Job 2, 'env LD_LIBRARY_PATH=/home/tdesc…' terminated by signal SIGFPE
(Floating point exception)
If we do not enable the underflow exception, everything is fine:
$ env
LD_LIBRARY_PATH=/home/tdescham/repo/isam/buildroot-qemu/output/staging/usr/lib
./sqlite-test 0 /tmp/foo.db "select sql from sqlite_master where sql not NULL;"
Not enabling exceptions.
fctrl = 037f
sql = CREATE TABLE foobar (id int primary key, name text)
Here is the output of a debug session using gdb:
$ env
LD_LIBRARY_PATH=/home/tdescham/repo/isam/buildroot-qemu/output/staging/usr/lib
gdb ./sqlite-test
GNU gdb (Gentoo 8.1 p1) 8.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
[Bug c++/87380] Explicit instantations should use weak symbols on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87380 --- Comment #19 from Iain Sandoe --- Author: iains Date: Thu Dec 6 20:09:26 2018 New Revision: 266866 URL: https://gcc.gnu.org/viewcvs?rev=266866=gcc=rev Log: Darwin - fix PR c++/87380 This is [intentionally] broken C++ ABI, that was catering for a tool problem that existed in a very old Darwin toolchain. The issue is not present after Darwin7 (using default system tools) so confine the fix to that revision or earlier. 2018-12-06 Iain Sandoe PR c++/87380 * config/darwin.h (TARGET_WEAK_NOT_IN_ARCHIVE_TOC) Remove; use the default. * config/rs6000/darwin7.h (TARGET_WEAK_NOT_IN_ARCHIVE_TOC): New. Modified: trunk/gcc/ChangeLog trunk/gcc/config/darwin.h trunk/gcc/config/rs6000/darwin7.h
[Bug sanitizer/80953] Support libsanitizer on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80953 --- Comment #28 from Eric Botcazou --- > For a quick check, I just tried it on > c-c++-common/asan/heap-overflow-1.c at -O0 > > #0 0x11258 in main > /vol/gcc/src/hg/trunk/local/gcc/testsuite/c-c++-common/asan/heap-overflow-1. > c:21 > > vs. -O1: > > #0 0x1121c in main > /vol/gcc/src/hg/trunk/local/gcc/testsuite/c-c++-common/asan/heap-overflow-1. > c:24 > > -fno-delayed-branch made no difference. What about -fasynchronous-unwind-tables?
[Bug target/86393] GCC-8 appears to not detect AVX512 on iMac Pro 2018
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86393 Eric Gallager changed: What|Removed |Added CC||iains at gcc dot gnu.org See Also||https://bugs.llvm.org/show_ ||bug.cgi?id=36202 --- Comment #8 from Eric Gallager --- (In reply to MCCCS from comment #7) > The problem was that the LLVM assembler required -mavx512f. I've researched > it and found that this LLVM bug was fixed months and shipped with LLVM 7. > Apple updates Xcode's LLVM with one year delay, and it should be fixed the > next year with 10.15. > > To sum up: this is llvm 6 bug > > https://bugs.llvm.org/show_bug.cgi?id=36202 > https://llvm.org/viewvc/llvm-project?view=revision=324106 It still might be worth handling this on the GCC end in the meantime though.
[Bug c++/88373] [9 Regression] parse error in template argument list when using bitwise not with -std=c++2a switch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88373 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Marek Polacek --- Fixed, thanks for the report.
[Bug c++/88373] [9 Regression] parse error in template argument list when using bitwise not with -std=c++2a switch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88373 --- Comment #2 from Marek Polacek --- Author: mpolacek Date: Thu Dec 6 19:43:17 2018 New Revision: 266865 URL: https://gcc.gnu.org/viewcvs?rev=266865=gcc=rev Log: PR c++/88373 - wrong parse error with ~. * parser.c (cp_parser_template_name): Check tag_type for none_type. * g++.dg/cpp2a/fn-template19.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp2a/fn-template19.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog
[Bug target/88271] Omit test instruction after add
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88271 --- Comment #3 from Daniel Fruzynski --- What about adding new pass at the end? It would look for various possible optimizations, which were missed earlier because they are cross-basic block. In my case this example code is part of tight loop. From previous experiences with it I expect that this optimization could improve speed by something like 0.5%-1%. If you want to look on real code, is it at link below. CPU spends about 60% of time in this one function. This app runs on BOINC platform, so such microoptimization would be worthwhile there. https://github.com/sirzooro/RakeSearch/blob/optimizations2/RakeDiagSearch/RakeDiagSearch/MovePairSearch.cpp#L583
[Bug libstdc++/85145] [8/9 Regression] include_next broken icw/ --with-gxx-include-dir
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85145 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- So, what directories are searched if you configure g++ this way, in what order and where is stdlib.h available? echo '#include ' > test.C g++ -v -E -o test.ii test.C should print that kind of info (except for where stdlib.h actually is).
[Bug libstdc++/64883] FAIL: 17_intro/headers/c++*/all_attributes.cc (test for excess errors) on x86_64-apple-darwin10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64883 --- Comment #58 from Iain Sandoe --- Author: iains Date: Thu Dec 6 19:21:32 2018 New Revision: 266863 URL: https://gcc.gnu.org/viewcvs?rev=266863=gcc=rev Log: Fix PR libstdc++/64883 Darwin headers use always_inline so don't test that Because darwin system headers use always_inline rather than __always_inline__ the libstdc++ test will fail, even if our headers only use the reserved form of the attribute. Don't test it on Darwin, and assume that testing on other targets will catch any accidental misuses in libstdc++ headers. 2018-12-06 Jonathan Wakely Iain Sandoe PR libstdc++/64883 * testsuite/17_intro/headers/c++1998/all_attributes.cc: Don't test always_inline on Darwin. * testsuite/17_intro/headers/c++2011/all_attributes.cc: Likewise. * testsuite/17_intro/headers/c++2014/all_attributes.cc: Likewise. * testsuite/17_intro/headers/c++2017/all_attributes.cc: Likewise. * testsuite/17_intro/headers/c++2020/all_attributes.cc: Likewise. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/testsuite/17_intro/headers/c++1998/all_attributes.cc trunk/libstdc++-v3/testsuite/17_intro/headers/c++2011/all_attributes.cc trunk/libstdc++-v3/testsuite/17_intro/headers/c++2014/all_attributes.cc trunk/libstdc++-v3/testsuite/17_intro/headers/c++2017/all_attributes.cc trunk/libstdc++-v3/testsuite/17_intro/headers/c++2020/all_attributes.cc
[Bug rtl-optimization/84345] [8/9 Regression] ICE: qsort checking failed (error: qsort comparator non-negative on sorted output: 1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84345 --- Comment #5 from Jakub Jelinek --- Do we actually care about these now that we have gcc_qsort?
[Bug sanitizer/80953] Support libsanitizer on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80953 --- Comment #27 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #26 from Jakub Jelinek --- > Try -fno-delayed-branch then? The debug info and unwind info for delayed > slots > isn't really well defined... For a quick check, I just tried it on c-c++-common/asan/heap-overflow-1.c at -O0 #0 0x11258 in main /vol/gcc/src/hg/trunk/local/gcc/testsuite/c-c++-common/asan/heap-overflow-1.c:21 vs. -O1: #0 0x1121c in main /vol/gcc/src/hg/trunk/local/gcc/testsuite/c-c++-common/asan/heap-overflow-1.c:24 -fno-delayed-branch made no difference.
[Bug inline-asm/87733] local register variable not honored with earlyclobber
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733 --- Comment #8 from Peter Bergner --- (In reply to Alexander Monakov from comment #6) > Peter, can you please clarify, is this actually fixed (as in, one of your > patches addressed this particular issue) or just happens to be not > reproducible anymore? Segher and I had patches to combine and RA respectively that addressed this specific issue.
[Bug target/85593] [7/8/9 Regression] GCC on ARM allocates R3 for local variable when calling naked function with O2 optimizations enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85593 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #13 from Jakub Jelinek --- Created attachment 45173 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45173=edit gcc9-pr85593.patch Untested fix.
[Bug fortran/88139] ICE in get_c_type_name, at fortran/dump-parse-tree.c:3047
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88139 Thomas Koenig changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot gnu.org
[Bug c++/78022] constexpr int template rejected unless constructor is used before hand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78022 --- Comment #7 from Marek Polacek --- Or, let's say, started to be accepted.
[Bug target/88282] [9 Regression] ICE in df_install_refs at gcc/df-scan.c:2379
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88282 --- Comment #9 from Vladimir Makarov --- Author: vmakarov Date: Thu Dec 6 18:41:46 2018 New Revision: 266862 URL: https://gcc.gnu.org/viewcvs?rev=266862=gcc=rev Log: 2018-12-06 Vladimir Makarov PR target/88282 * ira.c (ira_init_register_move_cost): Use info from hard_regno_mode_ok instead of contains_reg_of_mode. * ira-costs.c (contains_reg_of_mode): Don't use cost from bigger hard register class for some fixed hard registers. Modified: trunk/gcc/ChangeLog trunk/gcc/ira-costs.c trunk/gcc/ira.c
[Bug c++/78022] constexpr int template rejected unless constructor is used before hand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78022 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #6 from Marek Polacek --- That was fixed by r261084.
[Bug target/87369] [9 Regression] Regression on aarch64/copysign-bsl.c since r264264
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87369 --- Comment #1 from Jeffrey A. Law --- I wonder if we would be better off having the bfxil pattern reject cases when just the high bit is on (which are those cases where we'd be able to use a bit instruction rather than bfxil.
[Bug tree-optimization/88214] ICE in bitmap_intersect_p() on 32-bit BE platforms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88214
--- Comment #6 from Martin Jambor ---
I'm going to test the following fix:
diff --git a/gcc/ipa-prop.c b/gcc/ipa-prop.c
index 7405235..4dbe268 100644
--- a/gcc/ipa-prop.c
+++ b/gcc/ipa-prop.c
@@ -1569,7 +1569,8 @@ determine_locally_known_aggregate_parts (gcall *call,
tree arg,
if (TREE_CODE (arg) == SSA_NAME)
{
tree type_size;
- if (!tree_fits_uhwi_p (TYPE_SIZE (TREE_TYPE (arg_type
+ if (!tree_fits_uhwi_p (TYPE_SIZE (TREE_TYPE (arg_type)))
+ || !POINTER_TYPE_P (TREE_TYPE (arg)))
return;
check_ref = true;
arg_base = arg;
[Bug inline-asm/87733] local register variable not honored with earlyclobber
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733 --- Comment #7 from Segher Boessenkool --- Feel free to send a patch. Yes it is fixed.
[Bug target/87369] [9 Regression] Regression on aarch64/copysign-bsl.c since r264264
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87369 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-12-06 CC||law at redhat dot com Ever confirmed|0 |1
[Bug target/85593] [7/8/9 Regression] GCC on ARM allocates R3 for local variable when calling naked function with O2 optimizations enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85593
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #12 from Jakub Jelinek ---
Generic code already checks "naked" attribute in a bunch of places, no need to
add a target hook IMHO.
attribs.c: /* A "naked" function attribute implies "noinline" and "noclone"
for
attribs.c: && lookup_attribute ("naked", attributes) != NULL
attribs.c: && lookup_attribute_spec (get_identifier ("naked")))
bb-reorder.c: && !lookup_attribute ("naked", DECL_ATTRIBUTES (fun->decl))
cfgexpand.c: if (lookup_attribute ("naked",
[Bug inline-asm/87733] local register variable not honored with earlyclobber
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733 --- Comment #6 from Alexander Monakov --- If this is fixed then the testcase should be added to the testsuite to make sure we catch it if we regress again (this worked before e.g. on gcc-4.1). Peter, can you please clarify, is this actually fixed (as in, one of your patches addressed this particular issue) or just happens to be not reproducible anymore?
[Bug inline-asm/55681] Qualifiers on asm statements are order-dependent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55681 --- Comment #5 from Segher Boessenkool --- Author: segher Date: Thu Dec 6 17:47:52 2018 New Revision: 266859 URL: https://gcc.gnu.org/viewcvs?rev=266859=gcc=rev Log: asm qualifiers (PR55681) PR55681 observes that currently only one qualifier is allowed for inline asm, so that e.g. "volatile asm" is allowed, "const asm" is also okay (with a warning), but "const volatile asm" gives an error. Also "goto" has to be last. This patch changes things so that only "asm-qualifiers" are allowed, that is "volatile" and "goto", in any combination, in any order, but without repetitions. PR inline-asm/55681 * doc/extend.texi (Basic Asm): Update grammar. (Extended Asm): Update grammar. gcc/c/ PR inline-asm/55681 * c-parser.c (c_parser_asm_statement): Update grammar. Allow any combination of volatile and goto, in any order, without repetitions. gcc/cp/ PR inline-asm/55681 * parser.c (cp_parser_asm_definition): Update grammar. Allow any combination of volatile and goto, in any order, without repetitions. gcc/testsuite/ PR inline-asm/55681 * gcc.dg/asm-qual-1.c: Test that "const" and "restrict" are refused. * gcc.dg/asm-qual-2.c: New test, test that asm-qualifiers are allowed in any order, but that duplicates are not allowed. Added: trunk/gcc/testsuite/gcc.dg/asm-qual-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/c/ChangeLog trunk/gcc/c/c-parser.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/doc/extend.texi trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/asm-qual-1.c
[Bug libstdc++/88374] crash when stepping into for loop where iterators are created and compared with gdb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88374 --- Comment #2 from Bob Steagall --- See https://sourceware.org/bugzilla/show_bug.cgi?id=20020, especially comment 7 for more data.
[Bug tree-optimization/88214] ICE in bitmap_intersect_p() on 32-bit BE platforms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88214 --- Comment #5 from Martin Jambor --- OK, I take it all back. SSA_NAME_RANGE_INFO and SSA_NAME_PTR_INFO share storage by design, the latter should not be accessed because the SSA_NAME is an integer but it still happens to be a base in a MEM_REF constructed as a part of ao_ref_init_from_ptr_and_size done during ipa-prop's function scan. So hopefully all is missing is a POINTER_TYPE_P somewhere.
[Bug inline-asm/87733] local register variable not honored with earlyclobber
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733 Segher Boessenkool changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |9.0 --- Comment #5 from Segher Boessenkool --- Fixed on trunk.
[Bug target/86753] [9 Regression] gcc.target/aarch64/sve/vcond_[45].c fail after recent combine patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86753 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||law at redhat dot com Resolution|--- |FIXED --- Comment #4 from Jeffrey A. Law --- Per Richard's c#2, the ultimate result is actually an improvement and Richard has twiddled the tests. WRT c#3, reports of problems on Haswell, if this is still an issue, please report it as a separate bug.
[Bug rtl-optimization/87763] [9 Regression] aarch64 target testcases fail after r265398
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||vmakarov at gcc dot gnu.org --- Comment #8 from Jakub Jelinek --- Well, you can have different alternatives for different microarchitectures if that is beneficial, just enable/disable those through enabled attribute.
[Bug middle-end/85881] [9 Regression] FAIL: g++.dg/pr80481.C -std=gnu++11 scan-assembler-not vmovaps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85881 Jeffrey A. Law changed: What|Removed |Added Status|NEW |RESOLVED CC||law at redhat dot com Resolution|--- |FIXED --- Comment #7 from Jeffrey A. Law --- This was fixed by Richi's out-of-ssa changes for pr70359 and 86270.
[Bug inline-asm/87733] local register variable not honored with earlyclobber
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733 --- Comment #4 from Peter Bergner --- Ok, so we can mark this as already fixed then and leave it at that. That's fine with me.
[Bug c++/88394] [8/9 Regression] g++ ICE (Segmentation fault) in insert_capture_proxy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88394 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-12-06 CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org Target Milestone|--- |8.3 Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r253265.
[Bug tree-optimization/88214] ICE in bitmap_intersect_p() on 32-bit BE platforms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88214 --- Comment #4 from Martin Jambor --- I don't think this has much to do with IPA-CP per se. What is happening is that call_may_clobber_ref_p_1 extracts SSA_NAME_PTR_INFO of an SSA_NAME that is a base of a MEM_REF and runs pt_solutions_intersect on it, but the SSA_NAME_PTR_INFO just has invalid pt.vars bitmap address 0x8000 in it (before IPA-CP changed anything). When I set a watch in gdb to find out how the value got there, it turned out to be from a rather unexpected context: Watchpoint 5: ((ptr_info_def *) 0x3fffaf246e20)->pt.vars Old value = (bitmap) 0xafafafafafafafaf New value = (bitmap) 0x8000 wi::copy > > (x=..., y=...) at /home/jamborm/gcc/mine/src/gcc/wide-int.h:1776 1776 do (gdb) bt #0 wi::copy > > (x=..., y=...) at /home/jamborm/gcc/mine/src/gcc/wide-int.h:1776 #1 0x112eea1c in trailing_wide_int_storage::operator= > > (this=0x3fffd920, x=...) at /home/jamborm/gcc/mine/src/gcc/wide-int.h:1432 #2 0x112edff8 in generic_wide_int::operator= > > (this=0x3fffd920, x=...) at /home/jamborm/gcc/mine/src/gcc/wide-int.h:916 #3 0x112ed96c in range_info_def::set_min > > ( this=0x3fffaf246e20, x=...) at /home/jamborm/gcc/mine/src/gcc/tree-ssanames.h:52 #4 0x112ea434 in set_range_info_raw (name=, range_type=VR_RANGE, min=..., max=...) at /home/jamborm/gcc/mine/src/gcc/tree-ssanames.c:360 #5 0x112ea91c in set_range_info (name=, range_type=VR_RANGE, min=..., max=...) at /home/jamborm/gcc/mine/src/gcc/tree-ssanames.c:398 #6 0x11c25b44 in evrp_range_analyzer::set_ssa_range_info (this=0x3fffe0f8, lhs=, vr=0x3fffddb0) at /home/jamborm/gcc/mine/src/gcc/gimple-ssa-evrp-analyze.c:116 #7 0x11c26a18 in evrp_range_analyzer::record_ranges_from_stmt (this=0x3fffe0f8, stmt=0x3fffaf43e290, temporary=false) at /home/jamborm/gcc/mine/src/gcc/gimple-ssa-evrp-analyze.c:312 #8 0x11c22ab4 in evrp_dom_walker::before_dom_children (this=0x3fffe0c0, bb=0x3fffaf450138) at /home/jamborm/gcc/mine/src/gcc/gimple-ssa-evrp.c:139 #9 0x11bdc634 in dom_walker::walk (this=0x3fffe0c0, bb=0x3fffaf450138) at /home/jamborm/gcc/mine/src/gcc/domwalk.c:353 #10 0x11c23448 in execute_early_vrp () at /home/jamborm/gcc/mine/src/gcc/gimple-ssa-evrp.c:311 #11 0x11c235f0 in (anonymous namespace)::pass_early_vrp::execute (this=0x1282aed0) at /home/jamborm/gcc/mine/src/gcc/gimple-ssa-evrp.c:348 That looks like some memory corruption or unwanted memory sharing...?
[Bug tree-optimization/85804] [8/9 Regression][AArch64] Mis-compilation of loop with strided array access and xor reduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85804
--- Comment #7 from Jakub Jelinek ---
FYI, this used to work fine before r256634 with which it started to ICE:
pr85804.c: In function ‘main’:
pr85804.c:4:5: internal compiler error: in vect_permute_load_chain, at
tree-vect-data-refs.c:5511
int main() {
^~~~
Starting with r257492 we don't ICE anymore, but miscompile it.
[Bug inline-asm/87733] local register variable not honored with earlyclobber
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733 Segher Boessenkool changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-12-06 Ever confirmed|0 |1 --- Comment #3 from Segher Boessenkool --- It fails on everything at least as far back as GCC 5. So it is not a regression. I'd say we don't backport your changes, given how hard it is to get it right, and no doubt it will need changes to backport, too.
[Bug target/88271] Omit test instruction after add
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88271 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- GCC can handle these in the combiner, but for that needs the two instructions (add, etc. or in this case left shift by 1) be in the same basic block as the comparison. That is not the case here, during combine the shift by 1 is in one bb, which jumps to another bb in which is the comparison, but that other bb is preceded also by the bb with just val = data[level]; We only duplicate the comparison late and we really can't use the combiner late after RA. So, I'm afraid it is too hard to do anything here and the benefit would be small.
[Bug sanitizer/80953] Support libsanitizer on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80953 --- Comment #26 from Jakub Jelinek --- Try -fno-delayed-branch then? The debug info and unwind info for delayed slots isn't really well defined...
[Bug sanitizer/80953] Support libsanitizer on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80953 --- Comment #25 from Eric Botcazou --- > It is definitely used, same as on Solaris/x86 where this issue doesn't > occur. Maybe related to delay slots then.
[Bug target/88234] UBsan and runtime error: signed integer overflow using unsigned vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88234 Segher Boessenkool changed: What|Removed |Added Status|RESOLVED|NEW Resolution|FIXED |--- --- Comment #15 from Segher Boessenkool --- Oh sorry, backports are still pending. Reopening.
[Bug inline-asm/87733] local register variable not honored with earlyclobber
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733 --- Comment #2 from Peter Bergner --- None of my recent IRA or LRA patches were back ported and I wasn't planning on it, given the fallout they caused. Do we know for sure this doesn't work on GCC 8? Given when Alexander opened this bug, I'm guessing he just got caught in the middle of all of my changes. If this works on GCC 8, we can probably just close that as already fixed.
[Bug libstdc++/87787] [9 Regression][UBSAN] runtime error: null pointer passed as argument 2, which is declared to never be null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87787 --- Comment #9 from Jonathan Wakely --- Not yet, sorry.
[Bug target/86393] GCC-8 appears to not detect AVX512 on iMac Pro 2018
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86393 --- Comment #7 from MCCCS --- The problem was that the LLVM assembler required -mavx512f. I've researched it and found that this LLVM bug was fixed months and shipped with LLVM 7. Apple updates Xcode's LLVM with one year delay, and it should be fixed the next year with 10.15. To sum up: this is llvm 6 bug https://bugs.llvm.org/show_bug.cgi?id=36202 https://llvm.org/viewvc/llvm-project?view=revision=324106
[Bug libstdc++/87787] [9 Regression][UBSAN] runtime error: null pointer passed as argument 2, which is declared to never be null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87787 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com --- Comment #8 from Jeffrey A. Law --- Jon, did you have a chance to dig into the questions from c#2 yet?
[Bug tree-optimization/88372] alloc_size attribute is ignored on function pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88372 Martin Sebor changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org --- Comment #3 from Martin Sebor --- Testing a patch.
[Bug c/88363] [9 Regression] alloc_align attribute doesn't accept enumerated arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88363 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-12-06 Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #4 from Martin Sebor --- I'll take care of this.
[Bug c++/88395] New: ICE: Segmentation fault signal terminated program cc1plus, with -std=c++2a -fconcepts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88395
Bug ID: 88395
Summary: ICE: Segmentation fault signal terminated program
cc1plus, with -std=c++2a -fconcepts
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: emmanuel.le-tr...@cnrs-orleans.fr
Target Milestone: ---
Both trunk and 8.2.1 segfault on this valid snippet
$ cat bug_4.cpp
template
concept bool Concept2 = requires (T t, U u)
{
{ t += u } -> T&;
};
template
concept bool Concept = Concept2 ;
struct S
{
template
constexpr S& operator += (T o);
};
constexpr S operator * (S a, S b)
{
return a += b;
}
$ g++-9 -std=c++2a -fconcepts -c bug_4.cpp
g++-9: internal compiler error: Segmentation fault signal terminated program
cc1plus
Please submit a full bug report,
with preprocessed source if appropriate.
See
[Bug c++/87935] [9 regression] new failures on arm since r265788
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87935 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-12-06 CC||law at redhat dot com Ever confirmed|0 |1
[Bug tree-optimization/88285] [9 Regression] gcc.dg/predict-22.c fails on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88285 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||law at redhat dot com Resolution|--- |FIXED --- Comment #3 from Jeffrey A. Law --- Fixed by Jakub's commit on the trunk.
[Bug c/88382] undocumented GNU C extension: C++ raw string literals permitted in GNU C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88382 --- Comment #2 from joseph at codesourcery dot com --- The extension is intentionally supported. Thus, it should be documented.
[Bug inline-asm/87733] local register variable not honored with earlyclobber
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733 Segher Boessenkool changed: What|Removed |Added CC||bergner at gcc dot gnu.org, ||segher at gcc dot gnu.org --- Comment #1 from Segher Boessenkool --- This is fixed on trunk. Peter, does that need a backport still?
[Bug target/88234] UBsan and runtime error: signed integer overflow using unsigned vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88234 Segher Boessenkool changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #14 from Segher Boessenkool --- Closing then.
[Bug c/88363] [9 Regression] alloc_align attribute doesn't accept enumerated arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88363 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- I think it is irrelevant what exact types the standards call integer types for how we define our extension, and it is irrelevant on how LLVM implemented it, they implemented many GNU extensions incorrectly. What matters is what makes sense. For these kinds of attributes (alloc_align, alloc_size) we are looking for a parameter that meaningfully will hold either a size or alignment. Supporting bool/_Bool for that kind of argument makes no sense, enums are borderline, though I'd say it is fine to warn about them. So I'd recommend just to add testcases that cover this behavior and close.
[Bug inline-asm/85185] Wider-than-expected load for struct member used as operand of inline-asm with memory clobber at -Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85185 Segher Boessenkool changed: What|Removed |Added CC||segher at gcc dot gnu.org --- Comment #8 from Segher Boessenkool --- I think it is still possible to make code for which LRA cannot create any valid allocation, just not using function parameters. Which is the only sane way to get in such a situation, of course.
[Bug target/87598] [8 Regression] Rejects "%a0" with constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87598 Jakub Jelinek changed: What|Removed |Added Summary|[8/9 Regression] Rejects|[8 Regression] Rejects |"%a0" with constant |"%a0" with constant --- Comment #13 from Jakub Jelinek --- Fixed on the trunk so far.
