[Bug rtl-optimization/94026] combine missed opportunity to simplify comparisons with zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94026 --- Comment #3 from Andrew Pinski --- I think part of this optimization should be done on the tree level.
[Bug translation/90119] Merge translation msgids that only differ in placeholders
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90119 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #12 from Eric Gallager --- I think Roland has another bug open that is similar to this one, but I forget the number...
[Bug c/84919] [8/9 Regression] error: passing argument 1 to restrict-qualified parameter aliases with argument 5 [-Werror=restrict]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84919 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #22 from Eric Gallager --- (In reply to Martin Sebor from comment #20) > Fixed on trunk (GCC 10). The fix cannot be backported on its own without > introducing false negatives. so... if it can't be backported... then does this bug need to stay open?
[Bug rtl-optimization/94026] combine missed opportunity to simplify comparisons with zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94026
--- Comment #2 from Fei Yang ---
The test case is reduced from spec2017 benchmark.
int FastBoard::count_pliberties(const int i) {
return count_neighbours(EMPTY, i);
}
// count neighbours of color c at vertex v
int FastBoard::count_neighbours(const int c, const int v) {
assert(c == WHITE || c == BLACK || c == EMPTY);
return (m_neighbours[v] >> (NBR_SHIFT * c)) & 7;
}
bool FastBoard::self_atari(int color, int vertex) {
assert(get_square(vertex) == FastBoard::EMPTY);
// 1) count new liberties, if we add 2 or more we're safe
if (count_pliberties(vertex) >= 2) {
return false;
}
..
[Bug c++/94162] New: ICE [neg] bad return type in defaulted <=>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94162
Bug ID: 94162
Summary: ICE [neg] bad return type in defaulted <=>
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dacamara.cameron at gmail dot com
Target Milestone: ---
Whenever the return type of a defaulted <=> is not a comparison category gcc
ICEs:
#include
struct S {
int a;
bool operator<=>(const S&) const = default;
};
bool b = S{} < S{};
$ gcc -std=c++2a -c t.cpp
t.cpp:5:8: internal compiler error: in genericize_spaceship, at
cp/method.c:1050
5 | bool operator<=>(const S&) const = default;
|^~~~
Please submit a full bug report,
with preprocessed source if appropriate.
See
[Bug c++/94161] New: Implement DR 228: Use of template keyword with non-member templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94161
Bug ID: 94161
Summary: Implement DR 228: Use of template keyword with
non-member templates
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mpolacek at gcc dot gnu.org
Target Milestone: ---
This should compile:
template
struct X {
void f();
};
template
struct Y {
void g(X x) {
x.template X::f();
}
};
Since the DR says that the name prefixed by 'template' doesn't have to be a
member template.
[Bug c++/94161] Implement DR 228: Use of template keyword with non-member templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94161 Marek Polacek changed: What|Removed |Added Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Keywords||rejects-valid Last reconfirmed||2020-03-12
[Bug c++/94057] [9/10 Regression] -std=gnu++20 causes failure naming nested templated class since r9-4536
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94057 --- Comment #5 from Marek Polacek --- (We accept it when the template keyword is added: "typename A::template B".)
[Bug target/92303] [10 regression] gcc.target/sparc/ultrasp12.c times out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92303 --- Comment #11 from Vladimir Makarov --- Jakub, thank you for the analysis. I've been working on this PR too. I hope the patch will be ready on Friday or at the beginning of the next week.
[Bug c++/92010] [8/9/10 Regression] gcc internal error since 8x on warning write-strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92010
--- Comment #6 from Patrick Palka ---
(In reply to Patrick Palka from comment #5)
> The ICE seems to be revealing a latent issue: In the following example
> (which GCC accepts), according to the static_assert labelled (1), the type
> of t is const int*, but according to the static_assert labelled (2), the
> type of t is int *const.
>
>
>
> template
> void foo(const T t)
> {
> static_assert(__is_same(decltype(t), const int*)); // (1)
> }
>
> static_assert(__is_same(decltype(foo), void(int *))); // (2)
>
> int
> main()
> {
> foo(nullptr);
> }
So the question becomes, what should the type of t be here? According to
https://eel.is/c++draft/temp#deduct-3:
"A top-level qualifier in a function parameter declaration does not affect the
function type but still affects the type of the function parameter variable
within the function."
The above suggests that the type of foo should be the same regardless of
where the parameter t is const-qualified. Going by this then, it appears that
the static_assert (2) is right and (1) is wrong. Can anyone confirm?
(On the other hand, Clang thinks (1) is right and (2) is wrong.)
[Bug c++/92010] [8/9/10 Regression] gcc internal error since 8x on warning write-strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92010
--- Comment #5 from Patrick Palka ---
The ICE seems to be revealing a latent issue: In the following example (which
GCC accepts), according to the static_assert labelled (1), the type of t is
const int*, but according to the static_assert labelled (2), the type of t is
int *const.
template
void foo(const T t)
{
static_assert(__is_same(decltype(t), const int*)); // (1)
}
static_assert(__is_same(decltype(foo), void(int *))); // (2)
int
main()
{
foo(nullptr);
}
[Bug libstdc++/94160] std::pmr::pool_options::max_blocks_per_chunk=1 causes pool resources to return null pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94160 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2020-03-12 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1
[Bug libstdc++/94160] New: std::pmr::pool_options::max_blocks_per_chunk=1 causes pool resources to return null pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94160 Bug ID: 94160 Summary: std::pmr::pool_options::max_blocks_per_chunk=1 causes pool resources to return null pointers Product: gcc Version: 10.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: libstdc++ Assignee: redi at gcc dot gnu.org Reporter: redi at gcc dot gnu.org Target Milestone: --- This calculation in __pool_resource::_M_alloc_pools() can result in blocks_per_chunk being set to zero, and then _Pool::allocate always returns null: blocks_per_chunk = std::min(blocks_per_chunk, _M_opts.max_blocks_per_chunk); // Allow space for bitset to track which blocks are used/unused: blocks_per_chunk *= 1 - 1.0 / (__CHAR_BIT__ * block_size);
[Bug target/94158] Expanded strlen causes out-of-bounds read on AMD64 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94158 --- Comment #7 from Parker Thompson --- (In reply to Jakub Jelinek from comment #6) > GCC assumes pointers returned by malloc are at least MALLOC_ABI_ALIGNMENT > bytes aligned. That is because: > "The pointer returned if the allocation succeeds is suitably aligned so that > it may be assigned to a pointer to any type of object and then used to > access such an object or an array of such objects in the space allocated > (until the space is explicitly deallocated)." > glibc normally guarantees 2 * sizeof (void *) alignment, GCC by default > assumes just a wordsize alignment. > So, if your malloc replacement doesn't provide such alignment, it is > incorrect. Ahhh I see, I apologize for my misunderstanding.
[Bug target/94158] Expanded strlen causes out-of-bounds read on AMD64 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94158 --- Comment #6 from Jakub Jelinek --- GCC assumes pointers returned by malloc are at least MALLOC_ABI_ALIGNMENT bytes aligned. That is because: "The pointer returned if the allocation succeeds is suitably aligned so that it may be assigned to a pointer to any type of object and then used to access such an object or an array of such objects in the space allocated (until the space is explicitly deallocated)." glibc normally guarantees 2 * sizeof (void *) alignment, GCC by default assumes just a wordsize alignment. So, if your malloc replacement doesn't provide such alignment, it is incorrect.
[Bug target/94158] Expanded strlen causes out-of-bounds read on AMD64 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94158 --- Comment #5 from Andrew Pinski --- (In reply to Andrew Pinski from comment #4) > (In reply to Parker Thompson from comment #3) > > As for alloc alignment, glibc strdup() does not use aligned_alloc, just > > malloc. Which by my read of the spec does not guarantee alignment. > > malloc requires alignement of alignof(max_align_t) (definition in the newest > C and C++ standards) but beforehand it was required to be aligned enough to > support all standard types. C11 is where the definition changes to use max_align_t. https://en.cppreference.com/w/c/types/max_align_t
[Bug target/94158] Expanded strlen causes out-of-bounds read on AMD64 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94158 Andrew Pinski changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #4 from Andrew Pinski --- (In reply to Parker Thompson from comment #3) > As for alloc alignment, glibc strdup() does not use aligned_alloc, just > malloc. Which by my read of the spec does not guarantee alignment. malloc requires alignement of alignof(max_align_t) (definition in the newest C and C++ standards) but beforehand it was required to be aligned enough to support all standard types.
[Bug c++/94159] New: parse error on a declaration of a dependent class using a class-key instead of typename
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94159
Bug ID: 94159
Summary: parse error on a declaration of a dependent class
using a class-key instead of typename
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
The declaration of the q member below is rejected with a parse error,
suggesting GCC is confused about what's going on. Other compilers (all of
Clang, ICC, and VC++) accept both declarations without a complaint.
No version prior GCC version accepted the code so it's not a regression.
$ cat x.C && gcc -S -Wall -Wextra -Wpedantic x.C
template
struct A {
template
struct B { };
};
template
struct C
{
typename A::template B *p; // accepted
struct A::template B *q; // error
void f ()
{
struct A::template B *r = p; // accepted
}
};
x.C:11:30: error: expected identifier before ‘*’ token
11 | struct A::template B *q; // error
| ^
[Bug rtl-optimization/90275] [8/9 Regression] ICE: in insert_regs, at cse.c:1128 with -O2 -fno-dce -fno-tree-dce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90275 Jeffrey A. Law changed: What|Removed |Added Summary|[8/9/10 Regression] ICE: in |[8/9 Regression] ICE: in |insert_regs, at cse.c:1128 |insert_regs, at cse.c:1128 |with -O2 -fno-dce |with -O2 -fno-dce |-fno-tree-dce |-fno-tree-dce --- Comment #12 from Jeffrey A. Law --- This should be fixed on the trunk now. The patch could be safely backported to the release branches if someone was interested.
[Bug middle-end/92071] [10 regression][ARM] ice in gen_movsi, at config/arm/arm.md:5378
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92071 Eric Botcazou changed: What|Removed |Added Component|target |middle-end --- Comment #14 from Eric Botcazou --- Recategorizing
[Bug target/94158] Expanded strlen causes out-of-bounds read on AMD64 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94158 --- Comment #3 from Parker Thompson --- (In reply to Andrew Pinski from comment #2) > Also aligned_alloc normally does not allow alignment of 1. > > So GCC is doing the correct thing. The replacement of strdup here is just to illustrate the issue with expansion alignment of strlen() by forcing a crash. I encountered this issue when working with a custom malloc replacement that would enforce out-of-bounds read checks. Using the same reproduction with clang did not produce a crash / oob-read. As for alloc alignment, glibc strdup() does not use aligned_alloc, just malloc. Which by my read of the spec does not guarantee alignment.
[Bug target/94158] Expanded strlen causes out-of-bounds read on AMD64 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94158 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 Last reconfirmed||2020-03-12 --- Comment #2 from Andrew Pinski --- Also aligned_alloc normally does not allow alignment of 1. So GCC is doing the correct thing.
[Bug target/94158] Expanded strlen causes out-of-bounds read on AMD64 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94158 --- Comment #1 from Andrew Pinski --- A pointer returned from strdup has to be valid to be able pass to free. Your testcase makes that invalid.
[Bug target/94158] New: Expanded strlen causes out-of-bounds read on AMD64 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94158
Bug ID: 94158
Summary: Expanded strlen causes out-of-bounds read on AMD64
target
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: par...@cyber-itl.org
Target Milestone: ---
On AMD64/Linux, When strlen() is expanded, if the argument to strlen comes from
a source like strdup() or other functions returning allocator generated
pointers, the expanded strlen() makes an assumption about the alignment of the
char array.
Expanded strlen():
callq 0x4011e0
mov%rax,%rsi
mov%rax,%rdx
mov(%rdx),%ecx
add$0x4,%rdx
lea-0x1010101(%rcx),%eax
not%ecx
and%ecx,%eax
and$0x80808080,%eax
je 0x40109a
If the input argument is not 4-byte aligned, the "mov (%rdx),%ecx" can read up
to 3 bytes off the end of the allocated array.
Testing with GCC 9.2.1 this expanding behavior can be trigger with -O2 and -O3.
On git HEAD (c56871dd15a258c8775740194e6ed960a1f3d850) it requires the
'-minline-all-stringops' flag and -O2 / -O3.
Reproduction:
#include
#include
#define PAGE_SIZE 4096
#define ALIGN_SIZE(x) (((x) + PAGE_SIZE - 1) & ~(PAGE_SIZE - 1))
char *strdup(const char *str) {
size_t size = __builtin_strlen(str) + 1;
size_t len = ALIGN_SIZE(size);
char *ptr = (char *) mmap(NULL, len + PAGE_SIZE, PROT_READ | PROT_WRITE,
MAP_ANONYMOUS | MAP_PRIVATE, 0, 0);
munmap([len], PAGE_SIZE);
char *dest = ptr + PAGE_SIZE - size;
__builtin_memcpy(dest, str, size);
return dest;
}
int main(int argc, char **argv) {
char blah[] = "DD";
char *dest = strdup(blah);
__builtin_printf("%s %ld\n", dest, __builtin_strlen(dest));
return 0;
}
Newer than 9.2.1:
gcc -minline-all-stringops -O2 -o strlen-crash ./strlen-crash.c
9.2.1 and below:
gcc -O2 -o strlen-crash ./strlen-crash.c
./strlen-crash # Should SIGSEGV on the 'mov (%rdx),%ecx' instruction, if
expanded.
GCC -v output:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-pkgversion='Arch Linux 9.2.1+20200130-2'
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++,d --enable-shared
--enable-threads=posix --with-system-zlib --with-isl --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch
--disable-libssp --enable-gnu-unique-object --enable-linker-build-id
--enable-lto --enable-plugin --enable-install-libiberty
--with-linker-hash-style=gnu --enable-gnu-indirect-function --enable-multilib
--disable-werror --enable-checking=release --enable-default-pie
--enable-default-ssp --enable-cet=auto gdc_include_dir=/usr/include/dlang/gdc
Thread model: posix
gcc version 9.2.1 20200130 (Arch Linux 9.2.1+20200130-2)
GCC -v from git HEAD (c56871dd15a258c8775740194e6ed960a1f3d850):
Using built-in specs.
COLLECT_GCC=./bin/gcc
COLLECT_LTO_WRAPPER=/tmp/gcc/build-bins/libexec/gcc/x86_64-pc-linux-gnu/10.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --prefix=/tmp/gcc/build-bins/
--enable-languages=c,c++ --disable-bootstrap --disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.0.1 20200312 (experimental) (GCC)
[Bug target/87560] ICE in curr_insn_transform, at lra-constraints.c:3892
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87560 Bill Schmidt changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #11 from Bill Schmidt --- Backport complete, closing.
[Bug target/87560] ICE in curr_insn_transform, at lra-constraints.c:3892
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87560 --- Comment #10 from Bill Schmidt --- rs6000: Fix -mpower9-vector -mno-altivec ICE (PR87560) PR87560 reports an ICE when a test case is compiled with -mpower9-vector and -mno-altivec. This patch terminates compilation with an error when this combination (and other unreasonable ones) are requested. Bootstrapped and tested on powerpc64le-unknown-linux-gnu with no regressions. Reported error is now: f951: Error: '-mno-altivec' turns off '-mpower9-vector' 2020-03-12 Bill Schmidt Backport from master 2020-03-02 Bill Schmidt PR target/87560 * rs6000-cpus.def (OTHER_ALTIVEC_MASKS): New #define. * rs6000.c (rs6000_disable_incompatible_switches): Add table entry for OPTION_MASK_ALTIVEC.
[Bug c/93218] Test bug for testing git email integration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93218 --- Comment #28 from cgf-use-the-mailinglist-please at gnu dot org --- email to gcc DASH bugzilla AT gcc DOT gnu DOT org
[Bug c/93218] Test bug for testing git email integration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93218 --- Comment #26 from Jakub Jelinek --- Yet another test. --- Comment #27 from cgf-use-the-mailinglist-please at gnu dot org --- This time with no directory mods.
[Bug c++/69778] Bogus "qualifiers cannot be applied" error with redundant (but legal) 'typename'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69778 Marek Polacek changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2020-03-12 CC||mpolacek at gcc dot gnu.org --- Comment #3 from Marek Polacek --- Confirmed.
[Bug c/93218] Test bug for testing git email integration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93218 --- Comment #24 from Jakub Jelinek --- Yet another test. --- Comment #25 from Jakub Jelinek --- Yet another test.
[Bug c/93218] Test bug for testing git email integration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93218 --- Comment #23 from Jakub Jelinek --- Yet another test.
[Bug c/93218] Test bug for testing git email integration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93218 --- Comment #22 from Jakub Jelinek --- Yet another test.
[Bug c/93218] Test bug for testing git email integration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93218 --- Comment #21 from cgf-use-the-mailinglist-please at gnu dot org --- Test with directory permissions set.
[Bug c/93218] Test bug for testing git email integration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93218 --- Comment #20 from cgf-use-the-mailinglist-please at gnu dot org --- YA test via email.
[Bug c/93218] Test bug for testing git email integration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93218 --- Comment #19 from Jakub Jelinek --- Yet another test.
[Bug c/93218] Test bug for testing git email integration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93218 --- Comment #18 from Jakub Jelinek --- Yet another test.
[Bug c++/78286] typename, type members and non-type members: code should be rejected, but it is not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78286 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Marek Polacek --- Dup. *** This bug has been marked as a duplicate of bug 48920 ***
[Bug c++/48920] typename specifier should not ignore non-type names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48920 Marek Polacek changed: What|Removed |Added CC||michele.caini at gmail dot com --- Comment #4 from Marek Polacek --- *** Bug 78286 has been marked as a duplicate of this bug. ***
[Bug c++/89636] Duplicate diagnostic when resolving ambiguity between variable and function template using implicit typename
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89636 Marek Polacek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 CC||mpolacek at gcc dot gnu.org Last reconfirmed||2020-03-12 --- Comment #1 from Marek Polacek --- Confirmed. With -std=c++2a: Starting with commit 96c35892bea68ac180f19079cf08fea3b6cda0a8 Author: Marek Polacek Date: Sat Dec 1 17:56:27 2018 + Implement P0634R3, Down with typename! there is no error at all, and starting with commit b6d0f41ac5c1786911858b4763bb6f92519166f4 Author: Marek Polacek Date: Mon Jan 28 22:14:27 2019 + PR c++/88358 - name wrongly treated as type. there are two errors. So mine.
[Bug c/93218] Test bug for testing git email integration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93218 --- Comment #17 from Jakub Jelinek --- Yet another test.
[Bug c/93218] Test bug for testing git email integration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93218 --- Comment #16 from Jakub Jelinek --- Yet another test.
[Bug lto/94157] [10 Regression] error: lto-wrapper failed with -Wa,--noexecstack -Wa,--noexecstack since r10-6807-gf1a681a174cdfb82
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94157 --- Comment #4 from prathamesh3492 at gcc dot gnu.org --- (In reply to Martin Liška from comment #3) > I've got a patch candidate, will send it to GCC patches mailing list. Sorry for the breakage, and thanks for taking a look! Regards, Prathamesh
[Bug c++/64924] Callback function passed as a parameter with typename declaration produces an ICE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64924 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek --- Still ICEs with GCC 10.
[Bug lto/94157] [10 Regression] error: lto-wrapper failed with -Wa,--noexecstack -Wa,--noexecstack since r10-6807-gf1a681a174cdfb82
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94157 --- Comment #3 from Martin Liška --- I've got a patch candidate, will send it to GCC patches mailing list.
[Bug libstdc++/93244] std::filesystem::path::generic_string doesn't convert the first slash on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93244 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #12 from Martin Liška --- commit r9-8365-g362c8772e7779d9e4730e2e51628ccaadce98bd0 Author: Jonathan Wakely Date: Thu Mar 12 17:39:04 2020 + libstdc++: Ensure root-dir converted to forward slash (PR93244) Backport from mainline 2020-01-13 Jonathan Wakely PR libstdc++/93244 * include/bits/fs_path.h (path::generic_string) [_GLIBCXX_FILESYSTEM_IS_WINDOWS]: Convert root-dir to forward-slash. * testsuite/27_io/filesystem/path/generic/generic_string.cc: Check root-dir is converted to forward slash in generic pathname. * testsuite/27_io/filesystem/path/generic/utf.cc: New test. * testsuite/27_io/filesystem/path/generic/wchar_t.cc: New test.
[Bug libstdc++/94063] filesystem::path concatenation doesn't work for Windows root-paths
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94063 --- Comment #6 from Martin Liška --- commit r9-8369-g7ef07b622d8c2fca35813bf50669dcd663fe5cf2 Author: Jonathan Wakely Date: Thu Mar 12 17:39:05 2020 + libstdc++: Handle type-changing path concatenations (PR 94063) The filesystem::path::operator+= and filesystem::path::concat functions operate directly on the native format of the path and so can cause a path to mutate to a completely different type. For Windows combining a filename "x" with a filename ":" produces a root-name "x:". Similarly, a Cygwin root-directory "/" combined with a root-directory and filename "/x" produces a root-name "//x". Before this patch the implemenation didn't support those kind of mutations, assuming that concatenating two filenames would always produce a filename and concatenating with a root-dir would still have a root-dir. This patch fixes it simply by checking for the problem cases and creating a new path by re-parsing the result of the string concatenation. This is slightly suboptimal because the argument has already been parsed if it's a path, but more importantly it doesn't reuse any excess capacity that the path object being modified might already have allocated. Backport from mainline 2020-03-09 Jonathan Wakely PR libstdc++/94063 * src/c++17/fs_path.cc (path::operator+=(const path&)): Add kluge to handle concatenations that change the type of the first component. (path::operator+=(basic_string_view)): Likewise. * testsuite/27_io/filesystem/path/concat/94063.cc: New test.
[Bug target/91913] [8/9 Regression] ICE in extract_constrain_insn, at recog.c:2211
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91913 --- Comment #13 from Martin Liška --- commit r8-10119-g3d46f4875c6c50e8095294b6b700d6678a7e2f1e Author: Richard Earnshaw Date: Fri Mar 6 10:04:51 2020 + arm: correct constraints on movsi_compare0 [PR91913] The peephole that detects a mov of one register to another followed by a comparison of the original register against zero is only used in Arm state; but the instruction that matches this is generic to all 32-bit compilation states. That instruction lacks support for SP which is permitted in Arm state, but has restrictions in Thumb2 code. This patch fixes the problem by allowing SP when in ARM state for all registers; in Thumb state it allows SP only as a source when the register really is copied to another target. gcc/ChangeLog: PR target/91913 Backport from master * config/arm/arm.md (movsi_compare0): Allow SP as a source register in Thumb state and also as a destination in Arm state. Add T16 variants. gcc/testsuite/ChangeLog: 2020-02-10 Jakub Jelinek PR target/91913 Backport from master * gfortran.dg/pr91913.f90: New test.
[Bug target/91913] [8/9 Regression] ICE in extract_constrain_insn, at recog.c:2211
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91913 --- Comment #14 from Martin Liška --- commit r9-8364-g08f00a213f8a1b99bbf3ad3c337dea249a288cf1 Author: Richard Earnshaw Date: Fri Mar 6 10:04:51 2020 + arm: correct constraints on movsi_compare0 [PR91913] The peephole that detects a mov of one register to another followed by a comparison of the original register against zero is only used in Arm state; but the instruction that matches this is generic to all 32-bit compilation states. That instruction lacks support for SP which is permitted in Arm state, but has restrictions in Thumb2 code. This patch fixes the problem by allowing SP when in ARM state for all registers; in Thumb state it allows SP only as a source when the register really is copied to another target. gcc/ChangeLog: PR target/91913 Backport from master * config/arm/arm.md (movsi_compare0): Allow SP as a source register in Thumb state and also as a destination in Arm state. Add T16 variants. gcc/testsuite/ChangeLog: 2020-02-10 Jakub Jelinek PR target/91913 Backport from master * gfortran.dg/pr91913.f90: New test.
[Bug c++/64259] Erroneous "declaration 'struct ...' does not declare anything" when using "typename"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64259 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek --- GCC 10 still prints the warning: 64259.C:8:30: warning: declaration ‘struct details::B’ does not declare anything 8 | using BB = typename details::B; | ^
[Bug lto/94157] [10 Regression] error: lto-wrapper failed with -Wa,--noexecstack -Wa,--noexecstack since r10-6807-gf1a681a174cdfb82
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94157 Martin Liška changed: What|Removed |Added Target Milestone|--- |10.0 Version|9.0 |10.0 CC||prathamesh3492 at gcc dot gnu.org Priority|P3 |P1
[Bug c++/58590] Hidden typename not ill-formed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58590 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #11 from Marek Polacek --- The original test is still rejected: 58590.C:9:31: error: static assertion failed 9 | static_assert(sizeof(f(0)) == 2, ""); | ^~~~
[Bug lto/94157] [10 Regression] error: lto-wrapper failed with -Wa,--noexecstack -Wa,--noexecstack since r10-6807-gf1a681a174cdfb82
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94157 Martin Liška changed: What|Removed |Added Summary|[10 Regression] error: |[10 Regression] error: |lto-wrapper failed with |lto-wrapper failed with |-Wa,--noexecstack |-Wa,--noexecstack |-Wa,--noexecstack |-Wa,--noexecstack since ||r10-6807-gf1a681a174cdfb82 --- Comment #2 from Martin Liška --- Started with r10-6807-gf1a681a174cdfb82. One can reproduce with: $ gcc foo.c -c -flto && gcc -fPIE -Wa,--noexecstack -Wa,--noexecstack foo.o -o a.out -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack /usr/bin/ld: error: lto-wrapper failed collect2: error: ld returned 1 exit status ==14211== Invalid write of size 1 ==14211==at 0x483B98C: strcat (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==14211==by 0x408A08: run_gcc(unsigned int, char**) (lto-wrapper.c:1320) ==14211==by 0x4057C5: main (lto-wrapper.c:1981) ==14211== Address 0x1fff001000 is not stack'd, malloc'd or (recently) free'd
[Bug lto/94157] [10 Regression] error: lto-wrapper failed with -Wa,--noexecstack -Wa,--noexecstack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94157 Martin Liška changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Last reconfirmed||2020-03-12 --- Comment #1 from Martin Liška --- Ok, I can reproduce that now..
[Bug c/93218] Test bug for testing git email integration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93218 --- Comment #15 from Jakub Jelinek --- Yet another test.
[Bug c/93218] Test bug for testing git email integration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93218 --- Comment #14 from Jakub Jelinek --- Yet another test.
[Bug c/93218] Test bug for testing git email integration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93218 --- Comment #13 from Jakub Jelinek --- Yet another test.
[Bug middle-end/93566] [8/9/10 Regression] tree-nested.c ICE on C OpenMP array section reduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93566
--- Comment #2 from Jakub Jelinek ---
void
foo (int *x)
{
int c[10] = { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 };
int bar (int i) { return c[i]; }
#pragma omp parallel for reduction(+:x[:10])
for (int i = 0; i < 10; i++)
x[i] = bar (i);
}
ICEs too.
[Bug lto/94157] New: [10 Regression] error: lto-wrapper failed with -Wa,--noexecstack -Wa,--noexecstack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94157
Bug ID: 94157
Summary: [10 Regression] error: lto-wrapper failed with
-Wa,--noexecstack -Wa,--noexecstack
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Using gcc10 package I see a strange error:
$ echo "int main() {}" > x.c
$ gcc -flto -c x.c
$ gcc -Wa,--noexecstack -Wa,--noexecstack x.o
/usr/lib64/gcc/x86_64-suse-linux/10/../../../../x86_64-suse-linux/bin/ld:
error: lto-wrapper failed
collect2: error: ld returned 1 exit status
$ gcc -Wa,--noexecstack x.o
[fine]
I can't reproduce that with locally built GCC and gcc9 package seems fine.
[Bug c++/53102] typename gives access to private type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53102 Marek Polacek changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED CC||mpolacek at gcc dot gnu.org --- Comment #3 from Marek Polacek --- Fixed in GCC 4.8.1, likely by r0-117899-g0e69fdf016311cb8570c43d8ec67e9d5cb2f2aeb.
[Bug c++/54164] C++11: confusing error messages for spurious "typename"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54164 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #1 from Marek Polacek --- Fixed in GCC 4.9.0. Now we say: 54164.C:6:25: error: expected nested-name-specifier before ‘base’ 6 | using type = typename base; |
[Bug lto/94156] Multiple definition of destructor and non-virtual thunk for classes that use multiple inheritance when building static library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94156 --- Comment #1 from Michał Urbański --- This discussion looks related: https://gcc.gnu.org/legacy-ml/gcc/2003-09/msg00984.html
[Bug c/93218] Test bug for testing git email integration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93218 --- Comment #12 from Jakub Jelinek --- Yet another test.
[Bug c/93218] Test bug for testing git email integration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93218 --- Comment #11 from Jakub Jelinek --- Yet another test.
[Bug c/93218] Test bug for testing git email integration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93218 --- Comment #10 from Jakub Jelinek --- Yet another test.
[Bug c/93218] Test bug for testing git email integration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93218 --- Comment #8 from Jakub Jelinek --- Yet another test. --- Comment #9 from Jakub Jelinek --- Yet another test.
[Bug c/93218] Test bug for testing git email integration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93218 --- Comment #7 from Jakub Jelinek --- Yet another test.
[Bug c/93218] Test bug for testing git email integration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93218 --- Comment #6 from Jakub Jelinek --- Yet another test.
[Bug c/93218] Test bug for testing git email integration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93218 --- Comment #5 from Jakub Jelinek --- Yet another test.
[Bug c++/94057] [9/10 Regression] -std=gnu++20 causes failure naming nested templated class since r9-4536
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94057
--- Comment #4 from Marek Polacek ---
The root cause isn't the C++20 feature it seems. The following version with
explicit 'typename' is rejected, but compiles fine with clang/icc:
template class A {
template class B {
B(typename A::B&);
void fn(typename A::B &);
};
};
[Bug libstdc++/93244] std::filesystem::path::generic_string doesn't convert the first slash on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93244 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Jonathan Wakely --- Fixed for 9.4
[Bug libstdc++/94063] filesystem::path concatenation doesn't work for Windows root-paths
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94063 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jonathan Wakely --- Fixed for 9.4
[Bug c++/94057] [9/10 Regression] -std=gnu++20 causes failure naming nested templated class since r9-4536
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94057
--- Comment #3 from Marek Polacek ---
Not relate to parameter packs. Also happens with normal member functions:
template class A {
template class B {
B(A::B&);
void fn(A::B &);
};
};
[Bug target/94135] PPC: subfic instead of neg used for rotate right
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94135 --- Comment #3 from Segher Boessenkool --- Both subfic and neg are 1-2 if run on the integer units. neg can run on more units, but it is always 2 cycles then! (And the conditions where you *can* have 1 cycle are not very often satisfied, anyway).
[Bug c/93218] Test bug for testing git email integration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93218 --- Comment #4 from Jakub Jelinek --- Yet another test.
[Bug libstdc++/94033] [10 Regression] is_trivially_copy_constructible<> fails with compiler error on complicated object with private default constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94033 Jonathan Wakely changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=94003 --- Comment #12 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #11) > #ifdef FIX > static_assert( !std::is_nothrow_default_constructible::value ); > #endif Or slightly simpler, just instantiate the trait that's giving the wrong answer, which others depend on: #ifdef FIX static_assert( !std::is_constructible::value ); #endif See also PR 94003. Anyway, I have a patch for the library traits to avoid the problem.
[Bug debug/83935] DWARF for a variant part is incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83935 Tom Tromey changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |INVALID --- Comment #11 from Tom Tromey --- I'm fully on board with the GCC approach here, and I think this is something that should be changed in the DWARF standard. And, there's a DWARF bug for it. And finally, I have some patches to teach gdb to understand the GCC output here. So, I'm closing this as invalid.
[Bug c++/41437] No access control for classes in template functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41437 Jonathan Wakely changed: What|Removed |Added Keywords||wrong-code Last reconfirmed|2010-09-20 15:53:01 |2020-3-12 --- Comment #10 from Jonathan Wakely --- As Bug 94003 shows, this is also a wrong-code bug.
[Bug c++/90925] gcc allows calling private overridden operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90925
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed|2019-06-19 00:00:00 |2020-3-12
--- Comment #5 from Jonathan Wakely ---
(In reply to zhonghao from comment #0)
> My gcc is 10.0.0, and my code is:
>
> class a {
> private: template a <<(b);
> };
> a c();
> template a fn2() {
> int d;
> return c() << d;
> }
>
> gcc accepts the code, but clang rejects it:
>
> error: 'operator<<' is a private member of 'a'
> return c() << d;
> ~~~ ^ ~
> note: implicitly declared private here
> template a <<(b);
>^
> 1 error generated.
This is probably another dup of PR 41437
[Bug c++/79163] Access-checking not done in template argument list of partial specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79163 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Target Milestone|--- |8.2 Resolution|--- |FIXED --- Comment #2 from Jonathan Wakely --- Seems to be fixed in 8.2 and later, by r261151: PR c++/61806 - missed SFINAE with partial specialization. * cp-tree.h (deferring_access_check_sentinel): Add deferring_kind parameter to constructor. * pt.c (instantiate_class_template_1): Enable access checking before call to most_specialized_partial_spec.
[Bug c++/59002] [meta-bug] Access checking in templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59002 Bug 59002 depends on bug 79163, which changed state. Bug 79163 Summary: Access-checking not done in template argument list of partial specialization https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79163 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/59002] [meta-bug] Access checking in templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59002 Bug 59002 depends on bug 66475, which changed state. Bug 66475 Summary: Access checking in templates circumvented with 'using' (C++11) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66475 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/66475] Access checking in templates circumvented with 'using' (C++11)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66475 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |7.0 Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #1 from Jonathan Wakely --- Fixed by r243624: re PR c++/69481 (ICE with C++11 alias using with templates) cp/ PR c++/69481 * cp-tree.h (TYPE_TEMPLATE_INFO): Remove alias type checking. (TYPE_ALIAS_TEMPLATE_INFO): New. (TYPE_TEMPLATE_INFO_MAYBE_ALIAS): New. Use those macros. * error.c (dump_alias_template_specialization): Adjust. * pt.c (maybe_process_partial_specialization) iterative_has_template_arg, find_parameter_packs_r, alias_template_specialization_p, dependent_alias_template_spec_p, get_underlying_template, lookup_template_class_1, unify): Adjust template using decl access. testsuite/ PR c++/69481 * g++.dg/cpp0x/pr69481.C: New. Since GCC 7.1 we print: 66475.cc:19:11: error: 'using Base = struct Foo' is private within this context Bar::Base x; // shouldn't compile, Base is private ^~~~ 66475.cc:10:22: note: declared private here using Base = Foo; // the combination of this and the public export of a type from Base below, causes this example to compile even though it shouldn't ^
[Bug target/94145] Longcalls mis-optimize loading the function address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94145 --- Comment #10 from Segher Boessenkool --- The resolved address can only change before the first call to it, so we could even automatically insert code checking that, perhaps. My other concern is not slowing down the code if LD_BIND_NOW is in use.
[Bug c++/92010] [8/9/10 Regression] gcc internal error since 8x on warning write-strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92010 Patrick Palka changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Status|NEW |ASSIGNED CC||ppalka at gcc dot gnu.org --- Comment #4 from Patrick Palka --- Looking into it.
[Bug fortran/94129] Using almost any openacc !$acc directive causes ICE "compressed stream: data error"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94129 --- Comment #8 from Martin Liška --- @Richi: Can you please enable zstd for our nvptx cross compiler: $ x86_64-suse-linux-accel-nvptx-none-gcc-10 -v ... Supported LTO compression algorithms: zlib We'll need to add BuildRequires: libzstd-devel into cross spec file.
[Bug target/91913] [8/9 Regression] ICE in extract_constrain_insn, at recog.c:2211
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91913 Richard Earnshaw changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #12 from Richard Earnshaw --- Fixed on gcc-9 with https://gcc.gnu.org/pipermail/gcc-cvs/2020-March/271649.html (https://gcc.gnu.org/g:08f00a213f8a1b99bbf3ad3c337dea249a288cf1) Fixed on gcc-8 with https://gcc.gnu.org/pipermail/gcc-cvs/2020-March/271650.html (https://gcc.gnu.org/g:3d46f4875c6c50e8095294b6b700d6678a7e2f1e)
[Bug lto/94156] New: Multiple definition of destructor and non-virtual thunk for classes that use multiple inheritance when building static library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94156 Bug ID: 94156 Summary: Multiple definition of destructor and non-virtual thunk for classes that use multiple inheritance when building static library Product: gcc Version: 9.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: michal314314 at gmail dot com CC: marxin at gcc dot gnu.org Target Milestone: --- Created attachment 48024 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48024=edit main.ii from the example Following linker errors appear when creating the final executable: cd /d D:\Files\C++\workspace_windows\elements_fork\build_fork\examples\buttons && "C:\Program Files\CMake\bin\cmake.exe" -E cmake_link_script CMakeFiles\Buttons.dir\link.txt --verbose=1 "C:\Program Files\CMake\bin\cmake.exe" -E remove -f CMakeFiles\Buttons.dir/objects.a C:\mingw64\mingw64\bin\gcc-ar.exe cr CMakeFiles\Buttons.dir/objects.a @CMakeFiles\Buttons.dir\objects1.rsp C:\mingw64\mingw64\bin\g++.exe -O3 -DNDEBUG -flto -fno-fat-lto-objects -mwindows -Wl,--whole-archive CMakeFiles\Buttons.dir/objects.a -Wl,--no-whole-archive -o Buttons.exe -Wl,--out-implib,libButtons.dll.a -Wl,--major-image-version,0,--minor-image-version,0 @CMakeFiles\Buttons.dir\linklibs.rsp C:/mingw64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.1/../../../../x86_64-w64-mingw32/bin/ld.exe: radio_button.cpp.obj (symbol from plugin):(.gnu.linkonce.t._ZN5cycfi8elements18basic_radio_buttonD1Ev[_ZThn208_N5cycfi8elements18basic_radio_buttonD1Ev]+0x0): multiple definition of `cycfi::elements::basic_radio_button::~basic_radio_button()'; main.cpp.obj (symbol from plugin):(.gnu.linkonce.t._ZN5cycfi8elements18basic_radio_buttonD1Ev[_ZThn24_N5cycfi8elements18basic_radio_buttonD1Ev]+0x0): first defined here C:/mingw64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.1/../../../../x86_64-w64-mingw32/bin/ld.exe: radio_button.cpp.obj (symbol from plugin):(.gnu.linkonce.t._ZN5cycfi8elements18basic_radio_buttonD1Ev[_ZThn208_N5cycfi8elements18basic_radio_buttonD1Ev]+0x0): multiple definition of `non-virtual thunk to cycfi::elements::basic_radio_button::~basic_radio_button()'; main.cpp.obj (symbol from plugin):(.gnu.linkonce.t._ZN5cycfi8elements18basic_radio_buttonD1Ev[_ZThn24_N5cycfi8elements18basic_radio_buttonD1Ev]+0x0): first defined here C:/mingw64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.1/../../../../x86_64-w64-mingw32/bin/ld.exe: radio_button.cpp.obj (symbol from plugin):(.gnu.linkonce.t._ZN5cycfi8elements18basic_radio_buttonD1Ev[_ZThn208_N5cycfi8elements18basic_radio_buttonD1Ev]+0x0): multiple definition of `non-virtual thunk to cycfi::elements::basic_radio_button::~basic_radio_button()'; main.cpp.obj (symbol from plugin):(.gnu.linkonce.t._ZN5cycfi8elements18basic_radio_buttonD1Ev[_ZThn24_N5cycfi8elements18basic_radio_buttonD1Ev]+0x0): first defined here collect2.exe: error: ld returned 1 exit status Build command (generated by CMake): C:\mingw64\mingw64\bin\g++.exe -DNOMINMAX -DWIN32_LEAN_AND_MEAN -D_UNICODE @CMakeFiles/EmptyStarter.dir/includes_CXX.rsp -O3 -DNDEBUG -flto -fno-fat-lto-objects -std=gnu++17 -o CMakeFiles\EmptyStarter.dir\main.cpp.obj -c C:\files\personal\repos\elements\examples\empty\main.cpp My observations so far: - This is not an ODR violation problem. I have verified no classes got accidental duplicate definitions or duplicate source files. - There is no diamond inheritance in the project. - The problem does not occur when building elements as a shared library. It occurs when I build elements as a static library and then try to link any executable (including ones from its examples directory or my external projects). - The problem occurs in CMake Release build type - The problem does not occur when LTO is not enabled - The only multiple reference errors I get are definitions of destructors and non-virtual thunks for classes that use multiple inheritance. Removing such classes or changing their inheritance to be linear results in successful linking. - The problem only reproduces on Windows but it does reproduce across at least 2 MinGW distributions and across many GCC versions (tried multiple ones in range 8.3 - 9.2.1) - The problem does not reproduce on smaller examples. I have tried minimizing the repository to only affected classes but then the issue does not appear. Apparently optimization-related problems manifest only with certain code path/size. What I suspect: - The issue looks similarly to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47218 - This looks like a bug in linker/LTO because symbols from the LTO plugin contain "gnu.linkonce" which sounds like a weak symbol mechanism that is similar to how C++ templates are expected to possibly contain duplicate instantations and symbols across different translation units. I have made sample commits
[Bug libstdc++/94033] [10 Regression] is_trivially_copy_constructible<> fails with compiler error on complicated object with private default constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94033
--- Comment #11 from Jonathan Wakely ---
I think it doesn't show up for gcc-9 because there are also std::tuple changes
on master that make the bug show up.
And I think what's happening is another instance of PR 41437. When
std::optional is instantiated it causes
std::is_constructible to be instantiated, but gives the wrong answer
because of PR 41437.
Later when the value of std::is_nothrow_default_constructible is
needed, the bad instantiation of is_constructible is reused, which
means that the first condition in the __and_ here is true (but shouldn't be)
and so we try the second condition, which is ill-formed:
/// is_nothrow_default_constructible
template
struct is_nothrow_default_constructible
: public __and_,
__is_nt_default_constructible_impl<_Tp>>
{ };
/home/jwakely/gcc/10/include/c++/10.0.1/type_traits:966:47: error:
'mutation::mutation()' is private within this context
966 | : public integral_constant
| ^
We should never try to construct _Tp() when it isn't default constructible. The
cached bad value of is_constructible makes us try to do something
impossible.
Lending weight to this theory is the fact that explicitly checking
is_constructible_v *before* instantiating optional makes
the bug go away:
#include
#include
template struct abc {};
template
struct future : public
abc>::value> {};
class mutation {
mutation();
friend class std::optional;
};
#ifdef FIX
static_assert( !std::is_nothrow_default_constructible::value );
#endif
using mutation_opt = std::optional;
future foo();
template future consume_partitions() {
return foo();
}
future bar() { return consume_partitions(); }
future zed();
future apply_counter_update() { return zed(); }
Define FIX to make the bug vanish.
[Bug libstdc++/94033] [10 Regression] is_trivially_copy_constructible<> fails with compiler error on complicated object with private default constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94033 --- Comment #10 from Jonathan Wakely --- I have a fix for master, I'm just trying to figure out why we aren't seeing this on the gcc-9 branch too.
[Bug libstdc++/94033] [10 Regression] is_trivially_copy_constructible<> fails with compiler error on complicated object with private default constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94033 --- Comment #9 from Avi Kivity --- Thanks. I'll test 9.3 as soon as it hits koji.
[Bug libstdc++/94033] [10 Regression] is_trivially_copy_constructible<> fails with compiler error on complicated object with private default constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94033 --- Comment #8 from Jonathan Wakely --- 5c7938eb3f1a116b1cf9a28090f2cc5e08814ce4 is a different change to 58487c21b6a47c3fff6c6958684de866216a5593 The gcc-9 commit that corresponds to 58487c21b6a47c3fff6c6958684de866216a5593 is d9940358fa46306072ce408c4b5a1fcb3d01a0a2 which was already in gcc-9.2.0
[Bug c++/94155] internal compiler error: in gimplify_init_ctor_eval, at gimplify.c:4664
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94155 Marek Polacek changed: What|Removed |Added Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-03-12
[Bug c++/93805] [8/9/10 Regression] A suspicious -Werror=noexcept warning since r8-2461-g9fb82e652cee118b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93805
--- Comment #3 from Patrick Palka ---
Reduced test case:
$ cat 93805.C
struct B
{
B() {}
};
struct C
{
B b = B();
};
C c;
$ g++ -Wnoexcept 93805.C
93805.C:11:3: warning: noexcept-expression evaluates to ‘false’ because of a
call to ‘B::B()’ [-Wnoexcept]
11 | C c;
| ^
93805.C:3:3: note: but ‘B::B()’ does not throw; perhaps it should be declared
‘noexcept’
3 | B() {}
| ^
The commit in question adds a complain parameter to get_defaulted_eh_spec and
passes it down to synthesized_method_walk, and we eventually call
expr_noexcept_p in walk_field_subops with complain=tf_warning_or_error instead
of with complain=tf_none originally, which is the immediate cause of the
warning.
We're calling expr_noexcept_p from there to determine whether the NSDMI of C::b
is noexcept (so that we can determine the exception specification of C's
synthesized default constructor), and we're warning because the NSDMI of C::b
is not noexcept, but it could be if the non-throwing ctor B::B were marked
noexcept.
ISTM we can either disable the -Wnoexcept warning here, or we can keep the
warning but improve the warning message in this case.
[Bug c++/94153] [8/9/10 Regression] internal compiler error: in cp_lexer_new_from_tokens, at cp/parser.c:700
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94153 --- Comment #4 from Martin Liška --- (In reply to Slava Barinov from comment #3) > (In reply to Martin Liška from comment #1) > > Well, it's ICE on invalid code which is very common case. > Hm. So no need to report them? Well, we have a bazillion of such error recovery issues for C++.
[Bug libstdc++/94033] [10 Regression] is_trivially_copy_constructible<> fails with compiler error on complicated object with private default constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94033 --- Comment #7 from Avi Kivity --- That commit is in gcc 9.3, so I'm guessing 9.3 is affected too. 5c7938eb3f1a116b1cf9a28090f2cc5e08814ce4 tags/releases/gcc-9.3.0~221
[Bug target/94145] Longcalls mis-optimize loading the function address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94145 --- Comment #9 from Richard Biener --- (In reply to Alan Modra from comment #8) > (In reply to Richard Biener from comment #7) > > OTOH CSEing the load from the PLT once it is resolved _would_ be an > > optimization. > > Possibly. Sometimes making the call sequence seem more efficient runs into > stalls particularly when the called function is short. > > > Asks for loop peeling I guess? > > Yeah, that might be one way to get the first call of a function inside a > loop over and done with. And so you'd know the PLT entry was resolved and > thus no longer volatile. I suppose there's no (portable) way to "speculate" the call, thus _just_ eventually resolve the PLT? That way we could do such hoisted PLT loads as load PTL + speculate call load PTL or rather always do resolve-and-load-PLT since the times we want to lazily load the PLT with resolving later are scarce?
[Bug rtl-optimization/94148] The DF framework uses bb->aux, which is for passes only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94148 Segher Boessenkool changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |segher at gcc dot gnu.org --- Comment #2 from Segher Boessenkool --- Yes, and it assumes it stays cleared for any new blocks, and some more subtleties. I have a patch.
[Bug c++/94155] internal compiler error: in gimplify_init_ctor_eval, at gimplify.c:4664
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94155 Jonathan Wakely changed: What|Removed |Added Keywords||needs-reduction --- Comment #1 from Jonathan Wakely --- The same variable definition works at namespace scope, I only get the ICE an function scope. My brief attempts to reduce it to remove std::pair made the ICE go away.
[Bug target/94103] Wrong optimization: reading value of a variable changes its representation for optimizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94103 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #9 from Martin Liška --- commit r10-7145-g1dc00a8ec9aeba86b74b16bff6f171824bb7b4a1 Author: Richard Biener Date: Thu Mar 12 14:18:35 2020 +0100 tree-optimization/94103 avoid CSE of loads with padding VN currently replaces a load of a 16 byte entity 128 bits of precision (TImode) with the result of a load of a 16 byte entity with 80 bits of mode precision (XFmode). That will go downhill since if the padding bits are not actually filled with memory contents those bits are missing. 2020-03-12 Richard Biener PR tree-optimization/94103 * tree-ssa-sccvn.c (visit_reference_op_load): Avoid type punning when the mode precision is not sufficient. * gcc.target/i386/pr94103.c: New testcase.
[Bug c++/94155] New: internal compiler error: in gimplify_init_ctor_eval, at gimplify.c:4664
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94155
Bug ID: 94155
Summary: internal compiler error: in gimplify_init_ctor_eval,
at gimplify.c:4664
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
CC: mpolacek at gcc dot gnu.org
Target Milestone: ---
I get an ICE with this use of parenthesized aggregate init (which needs
-std=gnu++2a to compile, and is a new feature so isn't a regression):
#include
void f()
{
std::pair> p[2]( {1, {1, 1}}, {1, {1, 1}} );
}
t.cc:4:39: internal compiler error: in gimplify_init_ctor_eval, at
gimplify.c:4664
0x72e354 gimplify_init_ctor_eval
/home/jwakely/src/gcc/gcc/gcc/gimplify.c:4664
0xda9064 gimplify_init_constructor
/home/jwakely/src/gcc/gcc/gcc/gimplify.c:5107
0xda9cc5 gimplify_modify_expr_rhs
/home/jwakely/src/gcc/gcc/gcc/gimplify.c:5370
0xda9eea gimplify_modify_expr
/home/jwakely/src/gcc/gcc/gcc/gimplify.c:5721
0xdac158 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/jwakely/src/gcc/gcc/gcc/gimplify.c:13602
0xdafc36 gimplify_stmt(tree_node**, gimple**)
/home/jwakely/src/gcc/gcc/gcc/gimplify.c:6823
0xdb87d8 gimplify_and_add(tree_node*, gimple**)
/home/jwakely/src/gcc/gcc/gcc/gimplify.c:486
0xdb87d8 gimplify_decl_expr
/home/jwakely/src/gcc/gcc/gcc/gimplify.c:1816
0xdad35d gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/jwakely/src/gcc/gcc/gcc/gimplify.c:13799
0xdafc36 gimplify_stmt(tree_node**, gimple**)
/home/jwakely/src/gcc/gcc/gcc/gimplify.c:6823
0xdad1d9 gimplify_cleanup_point_expr
/home/jwakely/src/gcc/gcc/gcc/gimplify.c:6565
0xdad1d9 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/jwakely/src/gcc/gcc/gcc/gimplify.c:13994
0xdafc36 gimplify_stmt(tree_node**, gimple**)
/home/jwakely/src/gcc/gcc/gcc/gimplify.c:6823
0xdb09be gimplify_bind_expr
/home/jwakely/src/gcc/gcc/gcc/gimplify.c:1424
0xdad324 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/jwakely/src/gcc/gcc/gcc/gimplify.c:13803
0xdafc36 gimplify_stmt(tree_node**, gimple**)
/home/jwakely/src/gcc/gcc/gcc/gimplify.c:6823
0xdb16eb gimplify_body(tree_node*, bool)
/home/jwakely/src/gcc/gcc/gcc/gimplify.c:14851
0xdb1ac7 gimplify_function_tree(tree_node*)
/home/jwakely/src/gcc/gcc/gcc/gimplify.c:14995
0xc166d7 cgraph_node::analyze()
/home/jwakely/src/gcc/gcc/gcc/cgraphunit.c:669
0xc1957a analyze_functions
/home/jwakely/src/gcc/gcc/gcc/cgraphunit.c:1210
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
