[Bug c/94196] New: Multiple issues with attributes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94196
Bug ID: 94196
Summary: Multiple issues with attributes
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: momchil.velikov at gmail dot com
Target Milestone: ---
Created attachment 48046
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48046&action=edit
reproducer/examples
Taking as an example the noreturn attribute.
It is documented as a function attribute.
Yet it is accepted as a type attribute, e.g. in
typedef void (*T2)(void) __attribute__((noreturn));
T2 g2;
void __attribute__((noreturn)) f2(void) {
g2();
}
or with some declarations, e.g.:
typedef void T1(void);
T1 g1a __attribute__((noreturn));
void __attribute__((noreturn)) f1a(void) {
g1a();
}
T1 *g1b __attribute__((noreturn));
void __attribute__((noreturn)) f1b(void) {
g1b();
}
but only sometimes (only with a function pointer types?):
- it is not accepted with function types, e.g.:
typedef void T3(void) __attribute__((noreturn));
T3 g3;
void __attribute__((noreturn)) f3(void) {
g3();
}
- or with pointer to function pointer types, e.g.
typedef void (**T4)(void) __attribute__((noreturn));
T4 g4;
void __attribute__((noreturn)) f4(void) {
(*g4)();
}
- or with array of function pointers, e.g.:
typedef void (*T5[4])(void) __attribute__((noreturn));
T5 g5;
void __attribute__((noreturn)) f5(int i) {
g5[i]();
}
- etc
cf. https://gcc.godbolt.org/z/jUnGER
[Bug target/92808] New: GCC sets BTI flag in .note.gnu.property section even though not all functions are compiled with BTI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92808
Bug ID: 92808
Summary: GCC sets BTI flag in .note.gnu.property section even
though not all functions are compiled with BTI
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: momchil.velikov at gmail dot com
Target Milestone: ---
When GCC compiles the following source
```
__attribute__((target("branch-protection=pac-ret"))) int f() { return 0; }
__attribute__((target("branch-protection=bti"))) int g() { return 0; }
```
with
aarch64-none-linux-gnu-gcc -c x7.c
the `.note.gnu.property` section has the BTI flag set:
```
$ llvm-readelf --notes x7.o
Displaying notes found at file offset 0x0090 with length 0x0020:
OwnerData size Description
GNU 0x0010NT_GNU_PROPERTY_TYPE_0 (property note)
Properties:aarch64 feature: BTI
```
IMHO, the flag should be clear, since not all of the functions are compiled
with BTI.
[Bug c++/60994] gcc does not recognize hidden/shadowed enumeration as valid nested-name-specifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60994 --- Comment #9 from Momchil Velikov --- https://gcc.gnu.org/ml/gcc-patches/2014-05/msg00659.html(In reply to Jakub Jelinek from comment #8) > Have you pinged your patch? If a patch isn't reviewed within a week or two, > you should ping it on gcc-patches. Yep, I did and got feedback. https://gcc.gnu.org/ml/gcc-patches/2014-05/msg00659.html Unfortunately, I'm kinda busy with other things right now ...
[Bug c++/64418] New: User-defined conversion not properly suppressed in certain cases of list-initialisation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64418
Bug ID: 64418
Summary: User-defined conversion not properly suppressed in
certain cases of list-initialisation
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: momchil.velikov at gmail dot com
Consider the example:
--- 8< --
struct C {
C(const C &);
};
struct X {
operator C() const;
};
C a{X()};
--- 8< --
This program is successfully compiled. However, I believe this is an
erroneous behavior.
The variable "a" is initialised by direct list-initialization
according to 8.5.4. [dcl.init.list] #3 and 13.3.1.7 [over.match.list].
As the class C does not have an initializer-list ctor, all the
constructors of C are tried with the elements of the initializer list
as arguments.
GCC tries and in fact finds a user-defined conversion sequence from X
to the first parameter of the C's copy-ctor.
However, according to 13.3.3.1 [over.best.ics] #4,
"[...] when considering the argument of a constructor [...] that is a
candidate by [...] by 13.3.1.7 [...] or when the initializer list has
exactly one element and a conversion to some class X or reference to
(possibly cv-qualified) X is considered for the first parameter of a
constructor of X [...] only standard conversion sequences and ellipsis
conversion sequences are considered.
Bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51553 is related to this one.
[Bug c++/59366] A friend function template defined in a class is found without ADL
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59366 --- Comment #1 from Momchil Velikov --- Proposed fix: http://gcc.gnu.org/ml/gcc-patches/2014-05/msg00198.html
[Bug c++/60994] gcc does not recognize hidden/shadowed enumeration as valid nested-name-specifier
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60994 --- Comment #5 from Momchil Velikov --- Proposed fix: http://gcc.gnu.org/ml/gcc-patches/2014-04/msg01938.html
[Bug c++/60994] gcc does not recognize hidden/shadowed enumeration as valid nested-name-specifier
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60994
--- Comment #3 from Momchil Velikov ---
(In reply to Markus Trippelsdorf from comment #1)
> Implicit enum to int conversion is not provided for a scoped enumeration.
This is not the reported error.
In fact, the correct output of the compiler would be to report the invalid
implicit conversion. It does not.
With explicit conversion to int, the compiler still gives an error, but the
error message is not helpful and obscures the cause of the problem, i.e.,
compiling this:
enum struct A
{
n = 3
};
int
foo()
{
int A;
return int(A::n);
}
results in:
b.cc: In function 'int foo()':
b.cc:10:10: error: expected primary-expression before 'int'
return int(A::n);
^
b.cc:10:10: error: expected ';' before 'int'
b.cc:10:10: error: expected primary-expression before 'int'
[Bug c++/60994] New: gcc does not recognize hidden/shadowed enumeration as valid nested-name-specifier
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60994
Bug ID: 60994
Summary: gcc does not recognize hidden/shadowed enumeration as
valid nested-name-specifier
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: momchil.velikov at gmail dot com
gcc version 4.10.0 20140428 (experimental) (GCC)
Compiling (with c++ -c -std=c++11 b.cc) the following program
enum struct A
{
n = 3
};
int
foo()
{
int A;
return A::n;
}
results in the error:
b.cc: In function 'int foo()':
b.cc:10:10: error: 'A' is not a class, namespace, or enumeration
return A::n;
^
According to the C++11 Standard, [basic.lookup.qual] #1
"If a :: scope resolution operator in a nested-name-specifier is not preceded
by a decltype-specifier, lookup of the name preceding that :: considers only
namespaces, types, and templates whose specializations are types."
GCC ought not to resolve "A" to the local variable, but to the enumeration
type. This is very similar to the example in the standard
struct A
{
static int n;
};
int
foo()
{
int A;
return A::n;
}
which is compiled correctly by GCC, though.
[Bug c++/60755] lambda capturing `this` doesn't honor const qualifier of the enclosing member function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60755 Momchil Velikov changed: What|Removed |Added CC||momchil.velikov at gmail dot com --- Comment #2 from Momchil Velikov --- Possible duplicate of http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60463
[Bug c++/60463] Lambda function can call a non-const member function with const this
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60463
Momchil Velikov changed:
What|Removed |Added
CC||momchil.velikov at gmail dot
com
--- Comment #1 from Momchil Velikov ---
Just stumbled upon essentially the same problem with
c++ (GCC) 4.10.0 20140412 (experimental) [master revision
094da06:e25c6c8:855372a3d3c40b76fed8ff368d37b77d14a488eb]
#include
struct S {
void foo() const;
void bar();
int x = 0;
};
void S::foo() const {
auto f = [&]() { bar(); };
f();
std::cout << x << std::endl;
}
void S::bar() { ++x; }
int main() {
S s;
s.foo();
return 0;
}
