[Bug c++/59165] New: gcc looks up begin(), end() for for-range loops for ints in namespace std
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59165
Bug ID: 59165
Summary: gcc looks up begin(), end() for for-range loops for
ints in namespace std
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: thakis at chromium dot org
This compiles, but shouldn't:
$ cat gcc4.8bug.cc
// builds with gcc4.8, but shouldn't
namespace std {
int* begin(int i) { return (int*)0; }
int* end(int i) { return (int*)0; }
}
int main() {
for (int a : 10) { }
}
$ gcc-4.8.1 -c gcc4.8bug.cc -std=c++11
# works
The standard says that begin() and end() for foreach loops should be looked up
in the associated namespace of the type of the expression (6.5.4p1)
"""otherwise, begin-expr and end-expr are begin(__range) and end(__range),
respectively, where begin and end are looked up in the associated namespaces
(3.4.2). [ Note: Ordinary unqualified lookup (3.4.1) is not performed. — end
note ]"""
10 has type int, which is a fundamental type, and hence doesn't have an
associated namespace. So this shouldn't compile. (It doesn't compile in clang.)
$ gcc-4.8.1 --version
gcc-4.8.1 (GCC) 4.8.1
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[Bug libstdc++/79980] New: Possible bug in codecvt.cpp bitmask setting code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79980 Bug ID: 79980 Summary: Possible bug in codecvt.cpp bitmask setting code Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: thakis at chromium dot org Target Milestone: --- codecvt.cpp has this snippet: if (read_utf16_bom(from, mode) == little_endian) mode = codecvt_mode(mode & little_endian); That probably should read if (read_utf16_bom(from, mode) == little_endian) mode = codecvt_mode(mode | little_endian); instead?
[Bug preprocessor/60875] New: `_Pragma("message \"foo\")"` doesn't work in expression contexts.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60875
Bug ID: 60875
Summary: `_Pragma("message \"foo\")"` doesn't work in
expression contexts.
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: thakis at chromium dot org
Actual:
$ cat test.cc
int main() {
return _Pragma("message \"hello\"") 1234;
}
$ ~/gcc482prefix/bin/gcc -c test.cc -Wall
test.cc: In function ‘int main()’:
test.cc:2:1: error: ‘#pragma’ is not allowed here
return _Pragma("message \"my warning\"") 1234;
^
test.cc:2:44: error: expected ‘;’ before numeric constant
return _Pragma("message \"my warning\"") 1234;
^
test.cc:2:49: warning: statement has no effect [-Wunused-value]
return _Pragma("message \"my warning\"") 1234;
^
Expected (which is what clang does, and what MSVS does with `
__pragma(message...`):
Display the message instead.
(clang's output:
$ ../../../chrome/src/third_party/llvm-build/Release+Asserts/
bin/clang -c test.cc -Wall
test.cc:2:10: warning: my warning [-W#pragma-messages]
return _Pragma("message \"my warning\"") 1234;
^
:2:2: note: expanded from here
message "my warning"
^
1 warning generated.
)
A silly workaround is to use _Pragma("message_workaround...), then gcc will
warn like so:
test.cc:2:10: warning: unknown pragma ignored [-Wunknown-pragmas]
return _Pragma("message_workaround \"my warning\"") 1234;
^
It'd be nice if _Pragma(message...) could be used directly, instead of having
to rely on -Wunknown-pragmas for this functionality.
(The usecase we have for this in Chromium is that we want to make the compiler
print a diagnostic every time some symbols are used, so we define the symbols
as
#define MY_SYMBOL _Pragma("message \"foo\"") SYMBOL
This works fine in clang and MSVC, but for gcc we have to use a dummy pragma
and rely on -Wunknown-pragmas.)
[Bug preprocessor/60875] `_Pragma("message \"foo\")"` doesn't work in expression contexts.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60875 --- Comment #2 from thakis at chromium dot org --- That only works on declarations, not in an expression, right? (We do have a workaround that works with gcc. But "pragma message" matches the semantics of what we want to do, and it works with MSVC and clang, so it'd be nice if it worked in gcc too.)
[Bug c++/61596] New: -Wunused-local-typedefs warns incorrectly on a typedef that's referenced indirectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61596
Bug ID: 61596
Summary: -Wunused-local-typedefs warns incorrectly on a typedef
that's referenced indirectly
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: thakis at chromium dot org
-Wunused-local-typedefs warns that the typedef in line "XXX" is unused, but
it's used in line "YYY":
auto f() {
struct S {
typedef int t; // XXX
};
return S();
}
void g() {
auto x = f();
decltype(x)::t y; // YYY
}
/example.cpp: In function ‘auto f()’:
2 : warning: typedef ‘f()::S::t’ locally defined but not used
[-Wunused-local-typedefs]
struct S { typedef int t; };
^
(This is with 4.9.0. Testcase from Richard Smith.)
[Bug c++/64816] New: gcc claims that constructor is private when it should be accessible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64816
Bug ID: 64816
Summary: gcc claims that constructor is private when it should
be accessible
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: thakis at chromium dot org
I came across this while trying to build chromium for android with libc++ and
gcc. Here's an attempt at a reduction:
$ cat repro2.cc
namespace std {
template class __wrap_iter {
private:
__wrap_iter(_Iter __x) {}
template friend class basic_string;
template friend class vector;
};
template class basic_string {
public:
typedef const char *const_pointer;
typedef __wrap_iter const_iterator;
const_iterator begin() const {return const_iterator(const_pointer(0));}
};
typedef basic_string string;
template class vector {
public:
typedef const _Tp *const_pointer;
typedef __wrap_iter const_iterator;
const_iterator begin() const {return const_iterator(const_pointer(0));}
};
} // namespace std
void g(const std::vector &v) { v.begin(); }
# gcc doesn't like this (also broken in 4.4 and 4.9):
$ gcc-4.8.1 -c repro2.cc
gcc-4.8.1: warning: couldn’t understand kern.osversion ‘14.0.0
repro2.cc: In instantiation of ‘std::vector<_Tp>::const_iterator
std::vector<_Tp>::begin() const [with _Tp = char;
std::vector<_Tp>::const_iterator = std::__wrap_iter]’:
repro2.cc:30:46: required from here
repro2.cc:5:3: error: ‘std::__wrap_iter<_Iter>::__wrap_iter(_Iter) [with _Iter
= const char*]’ is private
__wrap_iter(_Iter __x) {}
^
repro2.cc:25:71: error: within this context
const_iterator begin() const {return const_iterator(const_pointer(0));}
^
It's true that the constructor is private, but vector is also a friend.
clang likes it (icc too):
$ bin/clang -c repro2.cc
To make this more mysterious, gcc stops rejecting the problem if:
1.) I change `typedef const char *const_pointer;` to `typedef const _CharT
*const_pointer;`
2.) or I declare `template class vector;` before class __wrap_iter
3.) or I remove class basic_string (and typedef string) -- even though they
aren't referenced anywhere.
[Bug c++/64816] gcc claims that constructor is private when it should be accessible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64816 --- Comment #1 from thakis at chromium dot org --- (Here's a patch with a libc++-side workaround: http://reviews.llvm.org/D7201 But it'd be good to fix this in the compiler too, of course.)
[Bug c++/63872] New: -Wunused-local-typedefs warns incorrectly on a typedef that's referenced from a template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63872
Bug ID: 63872
Summary: -Wunused-local-typedefs warns incorrectly on a typedef
that's referenced from a template
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: thakis at chromium dot org
$ cat test2.cc
typedef char YesType;
struct NoType { YesType dummy[2]; };
template
struct ShouldAbortOnSelfReset {
template
static NoType Test(const typename U::AllowSelfReset*);
template
static YesType Test(...);
static const bool value = sizeof(Test(0)) == sizeof(YesType);
};
template
struct Foo {
void reset() {
ShouldAbortOnSelfReset::value;
}
};
void f() {
struct NoOpDeleter {
typedef void AllowSelfReset;
inline void operator()(int*) {}
};
Foo f;
f.reset();
}
$ ~/gcc482prefix/bin/gcc -c test2.cc -std=c++11 -Wall
test2.cc: In function ‘void f()’:
test2.cc:24:18: warning: typedef ‘f()::NoOpDeleter::AllowSelfReset’ locally
defined but not used [-Wunused-local-typedefs]
typedef void AllowSelfReset;
^
test2.cc: In instantiation of ‘void Foo::reset() [with T =
f()::NoOpDeleter]’:
test2.cc:29:11: required from here
Warning on this is very dangerous, since removing the typedef will change the
meaning of the code but it's still going to compile.
This is with 4.8.2, but it also happens in gcc 4.9.
[Bug c++/63872] -Wunused-local-typedefs warns incorrectly on a typedef that's referenced from a template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63872 --- Comment #2 from thakis at chromium dot org --- I think warning on unused typedefs in local classes is generally a useful feature, not a bug. The bug here is that it's warning on a typedef in a local class that is being used.
[Bug c++/61596] -Wunused-local-typedefs warns incorrectly on a typedef that's referenced indirectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61596
--- Comment #2 from thakis at chromium dot org ---
Here's a similar example that doesn't need C++1y, regular C++11 is sufficient:
thakis@ubu:~$ cat test.cc
template
void template_fun(T t) {
typename T::Foo s3foo; // YYY
(void)s3foo;
}
void template_fun_user() {
struct Local {
typedef int Foo; // XXX
} p;
template_fun(p);
}
thakis@ubu:~$ g++ -c test.cc -std=c++11 -Wall
test.cc: In function ‘void template_fun_user()’:
test.cc:8:17: warning: typedef ‘template_fun_user()::Local::Foo’ locally
defined but not used [-Wunused-local-typedefs]
typedef int Foo;
^
Maybe a possible fix is to store all typedefs that get this warning as
candidates, and then emit warnings at the end of the translation unit for all
candidates that are still unreferenced at that point.
[Bug driver/83931] Add support for -nostdlib++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83931 thakis at chromium dot org changed: What|Removed |Added CC||thakis at chromium dot org --- Comment #4 from thakis at chromium dot org --- https://github.com/gcc-mirror/gcc/commit/fc2fb4fd547fb39d76237a3a1a50f5c4f3646936 (in gcc 13.1 as far as I can tell) fixed this. Someone with permissions to do so can close this out. Looks like I can't do it.
