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 mean
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 code is
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
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 it is completed or not.
: 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< typename T
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 code in other
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 could
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=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 #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://github.com
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=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=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
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=e
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 firs
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 tell what
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 c
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 prov
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
>
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
: 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
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=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 #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
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
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 #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=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=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=edit
A testcase that shows the problem.
The following testc
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
: 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=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 #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
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
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=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=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
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=edit
A reduced repro
I was also able to reduce the code further (see the attach). Compile with:
g++ -std=gnu+
++
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
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
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
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 #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 #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
1 - 100 of 107 matches
Mail list logo
