[Bug c++/56394] New: pointer arithmetic breaks with __attribute__((packed))

2013-02-19 Thread maxim.yegorushkin at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56394 Bug #: 56394 Summary: pointer arithmetic breaks with __attribute__((packed)) Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity:

[Bug c++/56394] pointer arithmetic breaks with __attribute__((packed))

2013-02-19 Thread maxim.yegorushkin at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56394 Maxim Yegorushkin maxim.yegorushkin at gmail dot com changed: What|Removed |Added Status|RESOLVED

[Bug c++/56394] pointer arithmetic breaks with __attribute__((packed))

2013-02-19 Thread maxim.yegorushkin at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56394 --- Comment #4 from Maxim Yegorushkin maxim.yegorushkin at gmail dot com 2013-02-19 14:21:52 UTC --- (In reply to comment #2) (In reply to comment #1) Also reproduces with optimization but with -fno-inline. The issue must

[Bug c++/56394] pointer arithmetic breaks with __attribute__((packed))

2013-02-19 Thread maxim.yegorushkin at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56394 --- Comment #6 from Maxim Yegorushkin maxim.yegorushkin at gmail dot com 2013-02-19 14:31:10 UTC --- (In reply to comment #5) (In reply to comment #4) (In reply to comment #2) (In reply to comment #1) Also reproduces

[Bug plugins/53126] New: gcc-4.7.0 error gcc-ar: Cannot find plugin

2012-04-26 Thread maxim.yegorushkin at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53126 Bug #: 53126 Summary: gcc-4.7.0 error gcc-ar: Cannot find plugin Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: critical

[Bug plugins/53126] gcc-4.7.0 error gcc-ar: Cannot find plugin

2012-04-26 Thread maxim.yegorushkin at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53126 --- Comment #1 from Maxim Yegorushkin maxim.yegorushkin at gmail dot com 2012-04-26 08:24:43 UTC --- Created attachment 27245 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27245 The Makefile I use to download gcc and libs, build and install

[Bug libstdc++/53941] New: Range-based for feature is not implemented for std::pair.

2012-07-12 Thread maxim.yegorushkin at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53941 Bug #: 53941 Summary: Range-based for feature is not implemented for std::pair. Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED

[Bug libstdc++/53941] Range-based for feature is not implemented for std::pair.

2012-07-12 Thread maxim.yegorushkin at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53941 --- Comment #2 from Maxim Yegorushkin maxim.yegorushkin at gmail dot com 2012-07-12 14:36:52 UTC --- Fair enough. I wasn't sure whether std::pair should work as a range, so I went to http://gcc.gnu.org/gcc-4.7/cxx0x_status.html which refers

[Bug c++/57863] New: std::vector::emplace_back() internal compiler error when passing wrong number of arguments

2013-07-09 Thread maxim.yegorushkin at gmail dot com
Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: maxim.yegorushkin at gmail dot com Passing wrong number of arguments into std::vector::emplace_back() causes an internal compiler error: #include vector

[Bug c++/47589] New: internal compiler error: Segmentation fault

2011-02-02 Thread maxim.yegorushkin at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47589 Summary: internal compiler error: Segmentation fault Product: gcc Version: 4.4.5 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo:

[Bug c++/47589] internal compiler error: Segmentation fault

2011-02-02 Thread maxim.yegorushkin at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47589 --- Comment #1 from Maxim Yegorushkin maxim.yegorushkin at gmail dot com 2011-02-02 15:43:45 UTC --- Created attachment 23215 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23215 Archived preprocessed source Could not attach the preprocessed

[Bug c++/64085] New: ICE on C++14 lambda by-reference capture with an initializer

2014-11-26 Thread maxim.yegorushkin at gmail dot com
Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: maxim.yegorushkin at gmail dot com $ cat test.cc #include functional #include iostream templateclass T auto make_monad(T arg) { return [captive = std::forwardT(arg

[Bug c++/64085] ICE on C++14 lambda by-reference capture with an initializer

2014-11-26 Thread maxim.yegorushkin at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64085 --- Comment #1 from Maxim Yegorushkin maxim.yegorushkin at gmail dot com --- It compiles fine if I replace the line in question with: return [captive = static_castT(arg)](auto a) {

[Bug c++/68897] New: No option to disable just "warning: enumeral and non-enumeral type in conditional expression"

2015-12-14 Thread maxim.yegorushkin at gmail dot com
NCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: maxim.yegorushkin at gmail dot com Target Milestone: --- The following code: enum X { A }; unsigned foo(bool b) { return b ? A : 2u;

[Bug c++/79578] New: Unnecessary instructions in generated code

2017-02-17 Thread maxim.yegorushkin at gmail dot com
++ Assignee: unassigned at gcc dot gnu.org Reporter: maxim.yegorushkin at gmail dot com Target Milestone: --- When the following code is compiled with gcc-7 and earlier versions with flags --std=c++14 -O3 -pthread: #include #include struct A { std

[Bug c++/79578] Unnecessary instructions in generated code

2017-02-17 Thread maxim.yegorushkin at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79578 --- Comment #1 from Maxim Egorushkin --- clang-3.9.1 generates code that I expect: f(char*): # @f(char*) movl$131073, (%rdi) # imm = 0x20001 movq%rdi, %rax retq

[Bug libstdc++/71556] set::get_time() requires leading 0s for %H and friends

2017-07-04 Thread maxim.yegorushkin at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71556 Maxim Egorushkin changed: What|Removed |Added CC||maxim.yegorushkin at gmail dot com

[Bug tree-optimization/82434] New: -fstore-merging does not work reliably.

2017-10-05 Thread maxim.yegorushkin at gmail dot com
-optimization Assignee: unassigned at gcc dot gnu.org Reporter: maxim.yegorushkin at gmail dot com Target Milestone: --- Consider the following code: struct A { long a; bool b, c, d, e; }; struct B { long a; bool b, c, d, e

[Bug libstdc++/82502] New: Cannot roundtrip / stream-read a hexfloat double.

2017-10-10 Thread maxim.yegorushkin at gmail dot com
: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: maxim.yegorushkin at gmail dot com Target Milestone: --- The following code successfully outputs double's in hexfloat format, but it cannot read them back: #include #include #include int main

[Bug c++/82409] New: Superflous pxor instructions in the generated assembly.

2017-10-02 Thread maxim.yegorushkin at gmail dot com
Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: maxim.yegorushkin at gmail dot com Target Milestone: --- For the following function: double f(int a, int b) { return static_cast(a - b) / (a + b); } g++-7.2 with flags "-O3

[Bug target/83133] Superflous x86 test instructions in generated assembly.

2017-11-24 Thread maxim.yegorushkin at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83133 --- Comment #6 from Maxim Egorushkin --- (In reply to Uroš Bizjak from comment #3) > (In reply to Maxim Egorushkin from comment #2) > > > Could you provide an example where that "dangerous optimization" would break > > well-formed code please?

[Bug rtl-optimization/83133] New: Superflous x86 test instructions in generated assembly.

2017-11-23 Thread maxim.yegorushkin at gmail dot com
Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: maxim.yegorushkin at gmail dot com Target Milestone: --- Consider the following code: int negative(int); int positive(int); int nonnegative(int); int nonpositive(int

[Bug target/83133] Superflous x86 test instructions in generated assembly.

2017-11-24 Thread maxim.yegorushkin at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83133 --- Comment #13 from Maxim Egorushkin --- (In reply to Uroš Bizjak from comment #9) > (In reply to Maxim Egorushkin from comment #6) > > > This code underflows a signed integer, which is undefined behaviour, if I am > > not mistaken. So, this

[Bug target/83133] Superflous x86 test instructions in generated assembly.

2017-11-24 Thread maxim.yegorushkin at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83133 --- Comment #10 from Maxim Egorushkin --- (In reply to Uroš Bizjak from comment #8) > (In reply to jos...@codesourcery.com from comment #5) > > Both 32-bit and 64-bit ABIs make the values of flags in EFLAGS (other than > > DF) undefined on

[Bug target/83133] Superflous x86 test instructions in generated assembly.

2017-11-24 Thread maxim.yegorushkin at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83133 --- Comment #12 from Maxim Egorushkin --- (In reply to jos...@codesourcery.com from comment #7) > On Fri, 24 Nov 2017, maxim.yegorushkin at gmail dot com wrote: > > > This code underflows a signed integer, which is undefined behavi

[Bug target/83133] Superflous x86 test instructions in generated assembly.

2017-11-24 Thread maxim.yegorushkin at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83133 --- Comment #11 from Maxim Egorushkin --- (In reply to jos...@codesourcery.com from comment #7) > On Fri, 24 Nov 2017, maxim.yegorushkin at gmail dot com wrote: > > > This code underflows a signed integer, which is undefined behavi

[Bug target/83133] Superflous x86 test instructions in generated assembly.

2017-11-24 Thread maxim.yegorushkin at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83133 --- Comment #2 from Maxim Egorushkin --- (In reply to Uroš Bizjak from comment #1) > (In reply to Maxim Egorushkin from comment #0) > > g function assembly contains a superflous test instruction. It should not > > generate that instruction,

[Bug tree-optimization/78972] [6/7/8 Regression] poor x86 simd instruction scheduling

2018-01-16 Thread maxim.yegorushkin at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78972 Maxim Egorushkin changed: What|Removed |Added CC||maxim.yegorushkin at gmail dot com

[Bug tree-optimization/78972] [6/7/8 Regression] poor x86 simd instruction scheduling

2018-01-16 Thread maxim.yegorushkin at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78972 --- Comment #14 from Maxim Egorushkin --- (In reply to Jeffrey A. Law from comment #13) > Folks where unhappy with various aspects of that patch. Bernd left Red Hat > shortly thereafter and the patch hasn't been updated since his departure. I

[Bug c++/83555] New: Unnecessary null check when static_cast is used with references.

2017-12-22 Thread maxim.yegorushkin at gmail dot com
Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: maxim.yegorushkin at gmail dot com Target Milestone: --- When the following code is compiled with `g++ --std=c++14 -O3`: struct A { int a; }; struct B { int b; }; struct C

[Bug c++/85251] New: Using declaration for base class constructor looses explicit.

2018-04-06 Thread maxim.yegorushkin at gmail dot com
Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: maxim.yegorushkin at gmail dot com Target Milestone: --- Example: #include struct A { template A(Args&&... args) { std::printf("%s\n", _

[Bug c++/90606] New: Replace mfence with faster xchg for std::memory_order_seq_cst.

2019-05-23 Thread maxim.yegorushkin at gmail dot com
Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: maxim.yegorushkin at gmail dot com Target Milestone: --- The following example: #include std::atomic a; void foo_seq_cst(int b) { a = b; } Compiles with `gcc-9.1 -O3 -std

[Bug c++/91415] Invalid warning for C++17 sequencing of shift operator E1<

2019-08-10 Thread maxim.yegorushkin at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91415 --- Comment #1 from Maxim Egorushkin --- gcc-9.1 produces the same warning.

[Bug c++/91415] New: Invalid warning for C++17 sequencing of shift operator E1<

2019-08-10 Thread maxim.yegorushkin at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91415 Bug ID: 91415 Summary: Invalid warning for C++17 sequencing of shift operator E1<

[Bug c++/91757] New: Function block scope thread_local variable with unique global symbol linkage is not unique at run-time.

2019-09-12 Thread maxim.yegorushkin at gmail dot com
: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: maxim.yegorushkin at gmail dot com Target Milestone: --- Consider the following application comprised of an executable and a shared library loaded

[Bug target/91722] New: gcc generates sub-optimal assembly when AVX instructions are used.

2019-09-10 Thread maxim.yegorushkin at gmail dot com
Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: maxim.yegorushkin at gmail dot com Target Milestone: --- The following code: #include __m256 copysign_ps(__m256 from, __m256 to) { constexpr float signbit = -0.f

[Bug target/91796] New: Sub-optimal YMM register allocation.

2019-09-17 Thread maxim.yegorushkin at gmail dot com
Assignee: unassigned at gcc dot gnu.org Reporter: maxim.yegorushkin at gmail dot com Target Milestone: --- The following code when compiled with `g++ -O3 -mavx2 -std=c++11` __m256d copysign2_pd(__m256d from, __m256d to) { auto a = _mm256_castpd_si256(from

[Bug target/91320] New: [9.1] x86-64 code generation / register allocation regressed.

2019-08-01 Thread maxim.yegorushkin at gmail dot com
Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: maxim.yegorushkin at gmail dot com Target Milestone: --- The following code: #include size_t g(boost::dynamic_bitset<> const& a, bool value) { auto count

[Bug target/92149] New: Enefficient x86_64 code

2019-10-18 Thread maxim.yegorushkin at gmail dot com
Assignee: unassigned at gcc dot gnu.org Reporter: maxim.yegorushkin at gmail dot com Target Milestone: --- The following code: #include #include #include using std::uint64_t; using A = std::array; template constexpr A pack(T v) { using C = unsigned

[Bug target/92149] Enefficient x86_64 code

2019-10-18 Thread maxim.yegorushkin at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92149 --- Comment #2 from Maxim Egorushkin --- I notice that g++ always zeros out unused high-order bits. Clang++ never does. Both follow the same System V ABI.

[Bug target/92149] Enefficient x86_64 code

2019-10-18 Thread maxim.yegorushkin at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92149 --- Comment #3 from Maxim Egorushkin --- System V ABI doesn't seem to require unused bytes to contain any specific value. There is a specific note for _Bool: When a value of type _Bool is returned or passed in a register or on the stack, bit 0

[Bug target/91796] Sub-optimal YMM register allocation.

2019-09-20 Thread maxim.yegorushkin at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91796 --- Comment #1 from Maxim Egorushkin --- In addition, the code tries to generate avx_signbit using 2 instructions: comparision vpcmpeqq and shift vpsllq to avoid loading anything from memory. However, the compiler replaces the code with loading

[Bug target/92038] Extremely inefficient x86_64 code for trivally copyable types passed in registers.

2019-10-09 Thread maxim.yegorushkin at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92038 --- Comment #1 from Maxim Egorushkin --- I have reported a few bugs this year related to poor code generation:

[Bug target/92038] Extremely inefficient x86_64 code for trivally copyable types passed in registers.

2019-10-09 Thread maxim.yegorushkin at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92038 --- Comment #2 from Maxim Egorushkin --- The competition often generates ideal code, but gcc team doesn't seem to care at all.

[Bug target/91796] Sub-optimal YMM register allocation.

2019-10-10 Thread maxim.yegorushkin at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91796 --- Comment #3 from Maxim Egorushkin --- It seems to me that register allocation has been a weak spot in gcc for years. gcc often allocates registers in such a way that extra register moves are necessary, compared to competition, like in this

[Bug target/92038] New: Extremely inefficient x86_64 code for trivally copyable types passed in registers.

2019-10-09 Thread maxim.yegorushkin at gmail dot com
Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: maxim.yegorushkin at gmail dot com Target Milestone: --- The following code: #include void f(std::variant); void g() { f({}); } When compiled

[Bug c++/93700] New: new expression ignores deleted operator new.

2020-02-12 Thread maxim.yegorushkin at gmail dot com
++ Assignee: unassigned at gcc dot gnu.org Reporter: maxim.yegorushkin at gmail dot com Target Milestone: --- The following code: struct C { C() { throw 1; } static void* operator new(unsigned long); static void operator delete(void*) = delete

[Bug target/93622] New: bool register arguments are underspecified on x86_64

2020-02-07 Thread maxim.yegorushkin at gmail dot com
Component: target Assignee: unassigned at gcc dot gnu.org Reporter: maxim.yegorushkin at gmail dot com Target Milestone: --- bool register arguments are underspecified on x86_64 The following code: #include struct A { int32_t a; uint32_t b : 1

[Bug target/93622] bool register arguments are underspecified on x86_64

2020-02-07 Thread maxim.yegorushkin at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93622 --- Comment #2 from Maxim Egorushkin --- (In reply to Jakub Jelinek from comment #1) > clang doesn't follow the psABI. How can it possibly do so while staying binary compatible?

[Bug target/93622] bool register arguments are underspecified on x86_64

2020-02-07 Thread maxim.yegorushkin at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93622 --- Comment #4 from Maxim Egorushkin --- I guess you are right, since clang compiles bool f(int a, int b) { return a == b; } into f(int, int): cmp edi, esi seteal ret Where sete does't change the 7

[Bug target/93897] New: Poor trivial structure initialization code.

2020-02-23 Thread maxim.yegorushkin at gmail dot com
: target Assignee: unassigned at gcc dot gnu.org Reporter: maxim.yegorushkin at gmail dot com Target Milestone: --- The following code: #include struct B { std::int64_t x; std::int32_t y; std::int32_t z; }; B f(std::int64_t x, std::int32_t

[Bug target/91320] [9/10 Regression] x86-64 code generation / register allocation regressed.

2020-01-18 Thread maxim.yegorushkin at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91320 --- Comment #2 from Maxim Egorushkin --- It reproduces with boost-1.64, https://godbolt.org/z/89HiMR I don't have boost-1.64 currently available to generate a reprocessed source.

[Bug c++/94184] New: Global variable inline constructor elision.

2020-03-15 Thread maxim.yegorushkin at gmail dot com
++ Assignee: unassigned at gcc dot gnu.org Reporter: maxim.yegorushkin at gmail dot com Target Milestone: --- The following code: struct A { int a_; A(int a) : a_(a) {} }; struct B { int a_; constexpr B(int a) : a_

[Bug target/91796] Sub-optimal YMM register allocation.

2020-05-23 Thread maxim.yegorushkin at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91796 --- Comment #8 from Maxim Egorushkin --- Another example https://stackoverflow.com/questions/61975526/gcc-optimization-better-at-o0-than-o3

[Bug target/96562] Rather poor assembly generated for copy-list-initialization in return statement.

2020-08-10 Thread maxim.yegorushkin at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96562 --- Comment #1 from Maxim Egorushkin --- Correction: Span f(unsigned char* p, unsigned char* q) { return {p, static_cast(q - p)}; }

[Bug target/96562] New: Rather poor assembly generated for copy-list-initialization in return statement.

2020-08-10 Thread maxim.yegorushkin at gmail dot com
Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: maxim.yegorushkin at gmail dot com Target Milestone: --- Rather poor assembly generated for trivial code. The following code: template struct Span

[Bug target/96562] Rather poor assembly generated for copy-list-initialization in return statement.

2020-08-11 Thread maxim.yegorushkin at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96562 --- Comment #5 from Maxim Egorushkin --- (In reply to H.J. Lu from comment #2) > Add -mavx to -O2 triggers this. The bug seems to be caused by -msse4.1, -mno-sse4.1 fixes it. Changing size from `unsigned` to `unsigned long` makes the bug

[Bug target/93897] Poor trivial structure initialization code with -O3

2020-08-11 Thread maxim.yegorushkin at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93897 --- Comment #3 from Maxim Egorushkin --- It seems to get triggered by uint32_t, see also https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96562 Any plans to fix this bug?

[Bug libstdc++/81122] [DR 2381] parsing f stopped after '0' when reading std::hexfloat >> f;

2020-06-12 Thread maxim.yegorushkin at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81122 --- Comment #19 from Maxim Egorushkin --- (In reply to Jonathan Wakely from comment #17) > At this time LWG 2381 is still open. Until the proposed fix (or some other > fix) is resolved by making a change to the draft standard, I do not want to

[Bug target/96234] New: Sub-optimal register allocation with a signed integer literal.

2020-07-17 Thread maxim.yegorushkin at gmail dot com
Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: maxim.yegorushkin at gmail dot com Target Milestone: --- The following code: #include #include namespace A { inline uint64_t as_nanoseconds(struct timespec* ts

[Bug middle-end/110764] [12/13/14 Regression] False positive -Warray-bounds warning swapping std::thread::id

2023-07-21 Thread maxim.yegorushkin at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110764 --- Comment #8 from Maxim Egorushkin --- It was supposed to be one comment, but I kept clicking "save changes" button because it provided no visual feedback that the comment was being posted.

[Bug middle-end/110764] [12/13/14 Regression] False positive -Warray-bounds warning swapping std::thread::id

2023-07-21 Thread maxim.yegorushkin at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110764 Maxim Egorushkin changed: What|Removed |Added CC||maxim.yegorushkin at gmail dot com

[Bug middle-end/110764] [12/13/14 Regression] False positive -Warray-bounds warning swapping std::thread::id

2023-07-21 Thread maxim.yegorushkin at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110764 --- Comment #7 from Maxim Egorushkin --- > Can you provide the preprocessed source? Since I can't seem to reproduce it > with the above. It should be compiled with "-pthread -std=gnu++14 -O3 -Wall -Wextra -Werror" to trigger the

[Bug middle-end/110764] [12/13/14 Regression] False positive -Warray-bounds warning swapping std::thread::id

2023-07-21 Thread maxim.yegorushkin at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110764 --- Comment #6 from Maxim Egorushkin --- > Can you provide the preprocessed source? Since I can't seem to reproduce it > with the above. It should be compiled with "-pthread -std=gnu++14 -O3 -Wall -Wextra -Werror" to trigger the

[Bug middle-end/110764] [12/13/14 Regression] False positive -Warray-bounds warning swapping std::thread::id

2023-07-21 Thread maxim.yegorushkin at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110764 --- Comment #4 from Maxim Egorushkin --- Full context: https://github.com/max0x7ba/atomic_queue/issues/55