: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: andysem at mail dot ru
In C++11 mode, libstdc++ marks some standard components from C++03 as
deprecated and emits warnings whenever these components are used. In particular
std::auto_ptr, std::bind1st and std::bind2nd
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59325
--- Comment #2 from andysem at mail dot ru ---
(In reply to Jonathan Wakely from comment #1)
You can use a #pragma to disable -Wdeprecated locally
But the legacy C++ is used in the library, which code I'd like to avoid
changing.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59325
--- Comment #4 from andysem at mail dot ru ---
(In reply to Jonathan Wakely from comment #3)
Doing this before any other includes will work:
#include bits/c++config
#undef _GLIBCXX_DEPRECATED
#define _GLIBCXX_DEPRECATED
I'm not convinced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53991
--- Comment #8 from andysem at mail dot ru ---
We have a similar problem in Boost.Atomic:
https://svn.boost.org/trac/boost/ticket/10204
There we mark all boost::atomic functions as always_inline to make sure the
compiler sees the memory order
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: andysem at mail dot ru
Created attachment 32726
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32726action=edit
A test case to reproduce the problem
I have a test case (attached) with several
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61043
--- Comment #2 from andysem at mail dot ru ---
(In reply to Andi Kleen from comment #1)
Yes LTO doesn't support different options for different files, and combines
some of them (which happens in your case) and ignores some others.
You could
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: andysem at mail dot ru
Target Milestone: ---
gcc emits 'unused variable' warnings for variables whose initialization might
have side effects.
class Foo
{
public:
static bool init
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71402
--- Comment #4 from andysem at mail dot ru ---
(In reply to Martin Sebor from comment #2)
> I just happened to be looking into this report and it's not clear to me
> whether or not the warning should be expected in this case. The
> docu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71402
--- Comment #6 from andysem at mail dot ru ---
(In reply to Martin Sebor from comment #5)
> I understand that and agree that there is a set of use cases where users
> don't expect a warning. There is also another set of cases where a w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71402
--- Comment #8 from andysem at mail dot ru ---
(In reply to Manuel López-Ibáñez from comment #7)
>
> In your testcase, this works just fine:
That testcase probably doesn't verify the fix for pragma since, as you said,
the warnin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71402
--- Comment #10 from andysem at mail dot ru ---
$ cat gcc_unused_variable.h
class Foo
{
public:
static bool init();
};
static bool FooInit = Foo::init();
$ cat gcc_unused_variable.cpp
#pragma GCC diagnostic push
#pragma GCC diagnostic
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: andysem at mail dot ru
Target Milestone: ---
Created attachment 38690
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38690=edit
Compiler output with -frep
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71402
--- Comment #12 from andysem at mail dot ru ---
(In reply to Manuel López-Ibáñez from comment #11)
> 5.3 has the bug I mentioned above. It makes the pragmas believe that, for
> this warning, the location is at the end of the file, which is
++
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=edit
Preprocessed code that fails to compile
The attached preprocessed code (compressed due to s
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=edit
A reduced repro
I was also able to reduce the code further (see the attach). Compile with:
g++ -std=gnu+
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=edit
The testcase that miscompiles with gcc
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=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=edit
A new testcase which produces invalid code with gcc 5.4
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=edit
A testcase that shows the prob
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=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=83624
--- Comment #1 from andysem at mail dot ru ---
Created attachment 42983
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42983=edit
Test code to reproduce the warning
I've attached a repro test case. Compile with:
g++ -std=gnu++03
++
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
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
: 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=edit
Preprocessed test case
This problem was initially reported to Boost here:
ht
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=edit
Compilable test case
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=edit
A testcase that shows the problem.
The following testc
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.
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 #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 fails
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=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=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
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=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=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 way
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
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=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
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=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
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
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
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
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
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
>
: 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=edit
Preprocessed source of the t
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 optimizations
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
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().
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
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 initial
: 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 #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 close
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
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=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.
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=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 firs
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
andysem at mail dot ru changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution
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
: 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=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
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
: 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=99563
--- Comment #5 from andysem at mail dot ru ---
Thanks. Will there be a fix in branch 10?
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=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 #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 tell what
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 c
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 (
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 prov
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=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
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.
: 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=e
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
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=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=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.
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=105857
--- Comment #1 from andysem at mail dot ru ---
Created attachment 53089
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53089=edit
Test case to reproduce the problem.
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://github.com
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 #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
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=edit
Preprocessed c
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 could
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
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.
>
> I un
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.
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 code in other
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=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=110096
andysem at mail dot ru changed:
What|Removed |Added
CC||andysem at mail dot ru
1 - 100 of 107 matches
Mail list logo
