[Bug c++/89683] New: Function-style cast inside alignas on struct does not compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89683
Bug ID: 89683
Summary: Function-style cast inside alignas on struct does not
compile
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: deaeod at gmail dot com
Target Milestone: ---
The following snippet does not compile with g++:
struct alignas(unsigned(8)) s {};
Workaround:
struct alignas((unsigned)8) s {};
[Bug c++/69494] Optimizer eliminates assignment to volatile subobject
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69494 --- Comment #2 from Lukas --- I was wrong about what part of the standard defines the behavior for volatile access. Paragraph 8 of [intro.execution] specifies that access to volatile objects is observable behavior. Access is defined in [defns.access] as reading or modifying the value of an object. Paragraph one of [intro.object] says that "an object is a region of storage." Paragraph two says that objects can contain other objects and calls the latter subobjects. Paragraph eight of [basic.types] defines 'object type' to contain cv-qualified versions of types that are not function types, references, or void. According to these passages dev.tcc is both an object and a subobject. The standard makes no explicit mention of volatile subobjects because whether or not an object is a subobject does not matter, at least when talking about volatile.
[Bug c++/70091] New: Codegen emits dead load on x86-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70091
Bug ID: 70091
Summary: Codegen emits dead load on x86-64
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: deaeod at gmail dot com
Target Milestone: ---
Code (http://goo.gl/MA8I0I):
struct bitfield {
void and_assign() volatile {
_raw = _and(_raw, 1); // this reads twice from _raw
//mov eax, DWORD PTR [rsp-24]
//mov eax, DWORD PTR [rsp-24]
//and eax, 1
//mov DWORD PTR [rsp-24], eax
_raw = _raw & 1; // this reads once from _raw
//mov eax, DWORD PTR [rsp-24]
//and eax, 1
//mov DWORD PTR [rsp-24], eax
}
static unsigned _and(unsigned lhs, unsigned rhs) {
return lhs & rhs;
}
unsigned _raw;
};
void test_device() {
volatile bitfield tcc;
tcc.and_assign();
}
I tested this snippet with g++ 4.8.2 and 4.9.0 on x86-64 only, so im not sure
if this bug applies to other targets. g++ 4.8.2 does not emit two loads from
_raw in any case, 4.9 and later behave as described in the comments. Note that
optimization level does not influence the generated code.
[Bug c++/83167] New: decltype((x)) inside lambda is considered odr-use if x is not a reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83167
Bug ID: 83167
Summary: decltype((x)) inside lambda is considered odr-use if x
is not a reference
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: deaeod at gmail dot com
Target Milestone: ---
https://godbolt.org/g/NmA3ZP
#include
int main() {
int x = 1;
int&& y = static_cast(x);
auto A = []{ static_assert(std::is_same_v); };
auto B = [=]{ static_assert(std::is_same_v); };
auto C = []{ static_assert(std::is_same_v); };
auto D = [=]{ static_assert(std::is_same_v); };
}
I expected this to compile cleanly, but static asserts A and B fail under g++.
A fails because x wasnt captured and B fails because the deduced type is const
int&.
Here is how i would argue for my expectation:
http://eel.is/c++draft/expr.prim.lambda#capture-11.sentence-3
-- "An id-expression that is not an odr-use refers to the original entity,
never to a member of the closure type."
http://eel.is/c++draft/basic.def.odr#def:potentially_evaluated
-- "An expression is potentially evaluated unless it is an unevaluated
operand or a subexpression thereof."
http://eel.is/c++draft/basic.def.odr#def:odr-used
-- "A variable x whose name appears as a potentially-evaluated expression
ex is odr-used by ex unless [...]"
http://eel.is/c++draft/dcl.type.simple#4.sentence-3
-- "The operand of the decltype specifier is an unevaluated operand."
[Bug c++/66672] std::is_same wrong result for captured reference value inside a lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66672 Lukas changed: What|Removed |Added CC||deaeod at gmail dot com --- Comment #2 from Lukas --- I think gcc's result of 10 is correct, and i believe every other compiler is wrong. Consider the following passages: http://eel.is/c++draft/expr.prim.lambda#capture-11.sentence-3 -- "An id-expression that is not an odr-use refers to the original entity, never to a member of the closure type." http://eel.is/c++draft/basic.def.odr#def:potentially_evaluated -- "An expression is potentially evaluated unless it is an unevaluated operand or a subexpression thereof." http://eel.is/c++draft/basic.def.odr#def:odr-used -- "A variable x whose name appears as a potentially-evaluated expression ex is odr-used by ex unless [...]" http://eel.is/c++draft/dcl.type.simple#4.sentence-3 -- "The operand of the decltype specifier is an unevaluated operand." Combining (1) and (3) means that variable names refer to the original entity, not the member of the closure, unless that variable name appears in a potentially evaluated expression. (2) and (4) combined say that the operand of decltype is not a potentially evaluated expression. Thus, variable names inside a decltype expression always refer to the outside entities.
[Bug c++/69494] New: Optimizer eliminates assignment to volatile subobject
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69494
Bug ID: 69494
Summary: Optimizer eliminates assignment to volatile subobject
Product: gcc
Version: 5.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: deaeod at gmail dot com
Target Milestone: ---
Compiler options: -O1
Code: (http://goo.gl/W1Iubr)
#include
struct device {
volatile unsigned tcc;
};
void test_device() {
device dev;
unsigned tcc = rand();
dev.tcc = tcc;
}
I expected GCC to generate code that accesses dev.tcc, but failed to find it. I
tested all versions and targets of GCC available at http://gcc.godbolt.org but
never did the compiler generate code for the assignment to dev.tcc at a level
of optimization higher than zero.
I think this is a bug because paragraph 12 of section [intro.execution] of the
C++14 standard specifies that accessing volatile glvalues of objects is a
side-effect, thus observable behavior.
GCC does warn about dev being unused but set, which is misleading as dev is not
being set, but dev.tcc is, and assigning to dev.tcc has side-effects.
