https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105857
--- Comment #16 from andysem at mail dot ru ---
Thanks for the fix. And for the explanation.
Yes, backport would be nice.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105857
--- Comment #7 from andysem at mail dot ru ---
Reproduces for me:
$ g++ -g2 -O0 -o codecvt_length_bug codecvt_length_bug.cpp
$ ./codecvt_length_bug
*** buffer overflow detected ***: terminated
Aborted (core dumped)
$ g++ -v
Using built-in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105857
--- Comment #8 from andysem at mail dot ru ---
I think, sanitizers won't detect it unless you build libstdc++ with them
enabled. I would expect valgrind to detect it though.
I think, Ubuntu builds libstdc++ with _FORTIFY_SOURCE enabled,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105857
--- Comment #3 from andysem at mail dot ru ---
I'm not sure about the meaning of the wrong-code keyword, but just to clear, I
do not consider the code sample in the bug report to be wrong (i.e. incorrect
usage of the standard library). If
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116697
--- Comment #2 from andysem at mail dot ru ---
When we say "uninitialized", we refer to a specific data access, i.e. when a
certain operation uses an object whose value is unspecified as input. With some
stretch, you could consider a
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: andysem at mail dot ru
Target Milestone: ---
Consider this example:
struct array
{
char m_buf[10];
typedef char* iterator;
iterator begin() { return m_buf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113099
--- Comment #13 from andysem at mail dot ru ---
(In reply to Jonathan Wakely from comment #12)
> (In reply to andysem from comment #11)
> > > I'm not sure what you mean by "the compiler is free to generate code that
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113099
--- Comment #11 from andysem at mail dot ru ---
> I'm not sure what you mean by "the compiler is free to generate code that
> takes it into account." Takes what into account? What problem does that
> freedom cause?
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113099
--- Comment #4 from andysem at mail dot ru ---
> It's mostly OK to mix code with -frtti and -fno-rtti, but sometimes it bites
> you.
Note that in this case, it is the standard library that is built with -frtti
and the rest of the co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113099
--- Comment #3 from andysem at mail dot ru ---
I think, a failing dynamic_cast would not be useful as this would make
std::use_facet unusable with -fno-rtti.
Re. ODR violation in the latest code, while it is true that the
dynamic/static_cast is
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: andysem at mail dot ru
Target Milestone: ---
Consider this test case:
```
#include
class __attribute__((__visibility__("default"))) my_cod
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110096
andysem at mail dot ru changed:
What|Removed |Added
CC||andysem at mail dot ru
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109761
--- Comment #2 from andysem at mail dot ru ---
I don't see how completeness of outer is related to nested's destructor. Or put
it another way, how nested's destructor noexcept specification has anything to
do with outer, whether
rsion: 11.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: andysem at mail dot ru
Target Milestone: ---
Consider the following piece of code:
template< typena
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98612
andysem at mail dot ru changed:
What|Removed |Added
CC||andysem at mail dot ru
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108401
--- Comment #7 from andysem at mail dot ru ---
To be clear, I'm not asking the compiler to recognize the particular pattern of
alternating 0x00 and 0xFF bytes. Because hardcoding this particular pattern
won't improve generated cod
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108401
--- Comment #6 from andysem at mail dot ru ---
(In reply to Andrew Pinski from comment #1)
> >and gcc 12 generates a worse code:
>
> it is not worse really; depending on the how fast moving between the
> register sets is.
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: andysem at mail dot ru
Target Milestone: ---
Consider the following code:
#include
__m256i load_00FF()
{
__m256i mm = _mm256_setzero_si256();
return _mm256_srli_epi16(_mm256_cmpeq_epi64(mm, mm), 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98978
--- Comment #6 from andysem at mail dot ru ---
(In reply to Jonathan Wakely from comment #5)
> (In reply to andysem from comment #3)
> > Is there no way to improve standard components implementation? I'd imagine
> > you c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106808
--- Comment #10 from andysem at mail dot ru ---
(In reply to andysem from comment #8)
> (In reply to Jonathan Wakely from comment #7)
> >
> > Do you want ODR violations? Because that's how you get ODR violations.
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106808
--- Comment #8 from andysem at mail dot ru ---
(In reply to Jonathan Wakely from comment #7)
> (In reply to andysem from comment #6)
> > So do you think this is a problem in Boost.Filesystem?
>
> I don't know yet, I can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106808
--- Comment #6 from andysem at mail dot ru ---
So do you think this is a problem in Boost.Filesystem?
I would say this is a regression in string_view as the code is valid in
pre-C++23, and I would expect it to stay valid in C++23 onwards
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106808
--- Comment #4 from andysem at mail dot ru ---
It fails the same way with 12.2 and trunk on godbolt:
https://gcc.godbolt.org/z/rT6TWhhvP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106808
--- Comment #3 from andysem at mail dot ru ---
I don't have the environment to build gcc locally, so I can't readily test
trunk. But I have been told the same issue reproduces with gcc-12
20220319-1ubuntu1 from Ubuntu 22.04:
https://
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: andysem at mail dot ru
Target Milestone: ---
Created attachment 53528
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53528&action=edit
Prepr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105857
--- Comment #2 from andysem at mail dot ru ---
> outside the [s, s + max_size) range
This should be [from, from_to) range. Sorry, posted a little too soon.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105857
--- Comment #1 from andysem at mail dot ru ---
Created attachment 53089
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53089&action=edit
Test case to reproduce the problem.
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: andysem at mail dot ru
Target Milestone: ---
Consider the following test case:
#include
#include
const std::size_t max_size = 10u;
const char text[] = "
!\"#$%&'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88165
--- Comment #13 from andysem at mail dot ru ---
(In reply to Jonathan Wakely from comment #10)
> (In reply to Fedor Chelnokov from comment #7)
> > This struct definition:
> > ```
> > struct A {
> > struc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102293
--- Comment #6 from andysem at mail dot ru ---
Ok, thanks for confirming.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102293
--- Comment #4 from andysem at mail dot ru ---
(In reply to Martin Liška from comment #3)
> Dup.
>
> *** This bug has been marked as a duplicate of bug 100161 ***
This bug isn't about a warning but about an ICE. Are you posi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102293
--- Comment #2 from andysem at mail dot ru ---
The code compiles if -std=c++03 is replaced with e.g. -std=c++11.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102293
--- Comment #1 from andysem at mail dot ru ---
I forgot to mention that the same code compiles successfully with gcc 9.4.0.
And here is the output from gcc 11.1.0:
In file included from ./boost/assert.hpp:58,
from
./boost
: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: andysem at mail dot ru
Target Milestone: ---
Created attachment 51443
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51443&acti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100477
--- Comment #9 from andysem at mail dot ru ---
(In reply to Martin Sebor from comment #8)
>
> Submitting a bug for the LTO problem is only helpful if it comes with a test
> case to reproduce it. I have heard about problems suppressing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100477
--- Comment #7 from andysem at mail dot ru ---
(In reply to Martin Sebor from comment #6)
> In C/C++ the size of the largest object is PTRDIFF_MAX - 1 bytes. This is
> necessary so that the difference between the address of its first by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100477
--- Comment #5 from andysem at mail dot ru ---
(In reply to Martin Sebor from comment #4)
> The case of _size being very large and n very small may be handled correctly
> by the original code thanks to the check for _capacity but becau
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100477
--- Comment #3 from andysem at mail dot ru ---
To put it another way, the case of _size being large and n small is valid, and
memset (and resize in general) do behave correctly in this case. Which is why
the warning is bogus and the suggested
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100477
andysem at mail dot ru changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution
: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: andysem at mail dot ru
Target Milestone: ---
Consider the following test case:
#include
#include
class Container
{
public:
typedef unsigned char value_type;
typedef value_type* pointer;
typedef std
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99971
--- Comment #10 from andysem at mail dot ru ---
Thanks. Will this be backported to 10 and 11 branches?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99971
--- Comment #6 from andysem at mail dot ru ---
Hmm, it looks like the original code has changed enough so that the problem no
longer reproduces, with or without __restrict__. I don't have the older version
of the code, so I can't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99971
--- Comment #3 from andysem at mail dot ru ---
I tried adding __restrict__ to the equivalents of x, y1 and y2 in the original
larger code base and it didn't help. The compiler (gcc 10.2) would still
generate the same half-vectorized code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99971
--- Comment #1 from andysem at mail dot ru ---
For reference, an ideal version of this code should look something like this:
test(A&, A const&, A const&):
movdqu (%rsi), %xmm0
movdqu (%rdi), %xmm1
movdqu (
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: andysem at mail dot ru
Target Milestone: ---
Consider the following code sample:
struct A
{
unsigned int a, b, c, d;
A& operator+= (A const& that)
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99563
--- Comment #8 from andysem at mail dot ru ---
Thanks again.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99563
--- Comment #5 from andysem at mail dot ru ---
Thanks. Will there be a fix in branch 10?
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: andysem at mail dot ru
Target Milestone: ---
Consider the following code:
#include
constexpr unsigned int block_size = 8u;
float compute_generic(const double* data, unsigned int width, unsigned int
height);
inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98978
--- Comment #3 from andysem at mail dot ru ---
(In reply to Jonathan Wakely from comment #1)
> This would be an ABI break, and so not going to happen.
Is there no way to improve standard components implementation? I'd imagine you
could
normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: andysem at mail dot ru
Target Milestone: ---
Using std::optional with some types may considerably increase object sizes
since it adds alignof(T) bytes worth of overhead. Som
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97891
--- Comment #5 from andysem at mail dot ru ---
Using a register is beneficial even for bytes and words if there are multiple
of mov instructions. But there has to be a single reg0 for all movs.
I'm not very knowlegeable about gcc internals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97891
--- Comment #1 from andysem at mail dot ru ---
As a side note, the "xorl %edx, %edx" in the original code should have been
moved outside the loop, as it was in the code with __asm__ block.
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: andysem at mail dot ru
Target Milestone: ---
Consider the following example code:
struct A
{
long a;
short b;
int c;
char d;
long x;
bool y;
int z;
char* p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59325
--- Comment #8 from andysem at mail dot ru ---
(In reply to Jonathan Wakely from comment #6)
> (In reply to andysem from comment #2)
> > (In reply to Jonathan Wakely from comment #1)
> > > You can use a #pragma to disable -W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96846
--- Comment #4 from andysem at mail dot ru ---
(In reply to Jakub Jelinek from comment #3)
> mov edx, DWORD PTR [rdi]
> cmp edx, esi
> seteal
> cmp edx, r9d
> sete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96846
--- Comment #2 from andysem at mail dot ru ---
(In reply to Jakub Jelinek from comment #1)
In the godbolt link there is also a third case, which is similar to the second
one, but does not reuse the source register for comparison results
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: andysem at mail dot ru
Target Milestone: ---
This has been reported already in bug 86352, but that bug also describes a few
other issues, so I decoded to create a separate bug focused on
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: andysem at mail dot ru
Target Milestone: ---
Created attachment 49097
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49097&action=edit
Preprocessed source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96337
--- Comment #13 from andysem at mail dot ru ---
I think, this inliner change needs to be reverted. People expect -O2 to produce
decently optimized binaries, and starting with gcc 10.x it doesn't deliver. -O3
traditionally enabled optimiza
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95750
--- Comment #6 from andysem at mail dot ru ---
Also, I think (%%rsp) can be rather far from the top of the stack if the stack
frame is large. This may mean it's less likely to be in data cache. Having a
dummy variable ensures that it is clo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95750
--- Comment #5 from andysem at mail dot ru ---
> Please also read [1] why we avoid -4(%%esp).
I believe, memcheck would complain because the value at -4(%%rsp) would be
uninitialized. This is unfortunate. The workaround could be to initialize
: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: andysem at mail dot ru
Target Milestone: ---
ARMv8.3-RCPC extension adds new ldapr[b/h] instructions for Load-AcquirePC
semantics that better matches C++ memory order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95750
--- Comment #2 from andysem at mail dot ru ---
gcc 10.1 only optimizes __atomic_store_n(seq_cst) to xchg, but not the fence.
Also, consider applying the same optimization to __sync_synchronize().
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: andysem at mail dot ru
Target Milestone: ---
Currently, __atomic_thread_fence(seq_cst) on x86 and x86-64 generates mfence
instruction. A dummy atomic instruction (a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63359
andysem at mail dot ru changed:
What|Removed |Added
CC||andysem at mail dot ru
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: andysem at mail dot ru
Target Milestone: ---
The following test case fails to compile in C++11 mode:
#include
#include
#include
void foo()
{
typedef std::istream_iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88101
--- Comment #3 from andysem at mail dot ru ---
As discussed in bug #93916, the approach of zeroing the storage before
constructing the object with internal padding doesn't work and is not required
to work by the C++ standard.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93916
--- Comment #9 from andysem at mail dot ru ---
Ok, so it seems then that what I need cannot be implemented portably. In that
case, this bug can be closed. Thanks to everyone.
But we do need a solution for bug #88101 (and Boost.Atomic) eventually.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93916
--- Comment #8 from andysem at mail dot ru ---
(In reply to rguent...@suse.de from comment #5)
> > Is there any other way to achieve the effect of initializing padding in a
> > struct?
>
> The only way I see would be to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93916
--- Comment #4 from andysem at mail dot ru ---
Are you saying that implementation is allowed to not preserve unused storage
state upon construction and assignment? Because I don't think this is what the
standard says.
Is there any other w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93916
--- Comment #1 from andysem at mail dot ru ---
Created attachment 47902
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47902&action=edit
A test case that demonstrates the problem
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: andysem at mail dot ru
Target Milestone: ---
This bug is related to bug #88101.
Consider this test case:
#include
#include
#include
struct struct_with_padding
{
char x;
short y
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88101
--- Comment #2 from andysem at mail dot ru ---
Another use case is C++20 atomic_ref, which may be bound to an object whose
padding bits are in indeterminate state. An intrinsic to clear padding bits
without altering the object value could be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93594
--- Comment #3 from andysem at mail dot ru ---
...and probably other permute variants involving zeroed input registers, e.g.:
__m256i cvt_permute_zero_v1(__m128i low)
{
return _mm256_permute2x128_si256(_mm256_setzero_si256
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93594
--- Comment #2 from andysem at mail dot ru ---
Another test case:
__m256i cvt_permute(__m128i low)
{
return _mm256_permute2x128_si256(_mm256_castsi128_si256(low),
_mm256_castsi128_si256(low), 0x80);
}
https://gcc.godbolt.org/z/4Ddt3C
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: andysem at mail dot ru
Target Milestone: ---
When _mm256_set_m128i/_mm256_setr_m128i intrinsics are used to zero the upper
half of the resulting register, gcc generates unnecessary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93425
--- Comment #1 from andysem at mail dot ru ---
Also, the compilation succeeds if I explicitly specify the NumberT template
parameter at the call site.
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: andysem at mail dot ru
Target Milestone: ---
The following code fails to compile:
template< typename T >
struct plus {};
template< typename Q
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88101
andysem at mail dot ru changed:
What|Removed |Added
CC||andysem at mail dot ru
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79929
andysem at mail dot ru changed:
What|Removed |Added
CC||andysem at mail dot ru
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85386
--- Comment #1 from andysem at mail dot ru ---
Apparently, the is_nothrow_default_constructible workaround doesn't work
reliably either, at least not in the full code base from which this testcase
was reduced.
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: andysem at mail dot ru
Target Milestone: ---
Created attachment 43923
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43923&action=edit
A testcase that shows the problem.
The fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85254
--- Comment #1 from andysem at mail dot ru ---
Created attachment 43869
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43869&action=edit
Compilable test case
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: andysem at mail dot ru
Target Milestone: ---
Created attachment 43868
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43868&action=edit
Preprocessed test case
This problem was initially reported to Boost here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878
--- Comment #17 from andysem at mail dot ru ---
I'll clarify why I think load() should be allowed to issue writes on the
memory. According to [atomics.types.operations]/18 in N4713,
compare_exchange_*() is a load operation if the comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878
--- Comment #14 from andysem at mail dot ru ---
> On Intel, all CAS operations always write, even if thr compare failed.
I understand that. The question is whether this is allowed behavior for
atd::atomic::load() operation according to th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878
--- Comment #12 from andysem at mail dot ru ---
Is read-only memory a valid use case for __atomic intrinsics anyway? These
intrinsics are primarily targeted to implement std::atomic, but does the
standard guarantee these operations (primarily
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83624
--- Comment #3 from andysem at mail dot ru ---
As you noted, --pedantic-errors makes that code an error, so it is not an
equivalent replacement.
Also, GNU-specific attributes can and often are supported by other compilers.
When they are not, the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83624
--- Comment #1 from andysem at mail dot ru ---
Created attachment 42983
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42983&action=edit
Test code to reproduce the warning
I've attached a repro test case. Compile with:
g++ -st
++
Assignee: unassigned at gcc dot gnu.org
Reporter: andysem at mail dot ru
Target Milestone: ---
Gcc 7.2.0 warns about __attribute__((__strong__)) on a using directive in C++03
code.
In file included from ../../../boost/log/detail/custom_terminal_spec.hpp:25:0
ormal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: andysem at mail dot ru
Target Milestone: ---
Created attachment 42380
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42380&action=edit
A testcase that shows the p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878
andysem at mail dot ru changed:
What|Removed |Added
CC||andysem at mail dot ru
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61043
--- Comment #13 from andysem at mail dot ru ---
Ok. For the record, opened bug 77845.
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: andysem at mail dot ru
Target Milestone: ---
Created attachment 39752
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39752&action=edit
The testcase that miscompiles with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61043
andysem at mail dot ru changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61043
--- Comment #8 from andysem at mail dot ru ---
Created attachment 39751
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39751&action=edit
A new testcase which produces invalid code with gcc 5.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61043
andysem at mail dot ru changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65239
andysem at mail dot ru changed:
What|Removed |Added
CC||andysem at mail dot ru
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72659
--- Comment #1 from andysem at mail dot ru ---
Created attachment 39022
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39022&action=edit
A reduced repro
I was also able to reduce the code further (see the attach). Compile with:
g
++
Assignee: unassigned at gcc dot gnu.org
Reporter: andysem at mail dot ru
Target Milestone: ---
Created attachment 39021
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39021&action=edit
Preprocessed code that fails to compile
The attached preprocessed code (compres
1 - 100 of 113 matches
Mail list logo
