compiler-bug

Oracle JDK and Eclipse JDT compilers disagree! Which is compiling this incorrectly? Unusual generics and inferrence

由 爱⌒轻易说出口 提交于 2019-12-05 16:45:57
I have a piece of code which is compiling inconsistently between Oracle JDK 7 and Eclipse JDT 7, but since I'm not sure about which compiler is making the mistake(s) I thought I should ask for opinions here before submitting any bug reports. This is the simplest test I could come up with to demonstrate the inconsistency: interface Foo<S extends Foo<S, T>, T> { // should this compile? public <X extends Foo<S, Y>, Y> Y method1(); // what about this? public <X extends Foo<? extends S, Y>, Y> Y method2(); } Oracle JDK gives an error on method1 but not method2, whereas Eclipse has no problem with

g++ (4.7.2) bug or feature, when initializing static arrays at compile-time?

由 ◇◆丶佛笑我妖孽 提交于 2019-12-05 15:17:05
Okay, so I was trying to do something clever by initializing a bunch of constexpr static int const arrays at compile-time. Even though the runtime-performance is not at all governed by initializing these arrays, it seemed like a fun little exercise. I wrote a test-setup to see if it was possible, and I ended up being able to do this: struct Test { constexpr static int const array[10] = Array<int, 10, 0, Increment>::array; }; constexpr int const Test::array[10]; int main() { cout << Test::array[3] << '\n'; } Here, Array has a static member called array which contains 10 int s, starting at 0,

Happily linking incompatible types leads to chaos

由 穿精又带淫゛_ 提交于 2019-12-05 14:37:44
I've been trying to figure out some boundaries of g++ , especially linking (C++) object files. I found the following curiosity which I tried to compress as much as possible before asking. Code File common.h #ifndef _COMMON_H #define _COMMON_H #include <iostream> #define TMPL_Y(name,T) \ struct Y { \ T y; \ void f() { \ std::cout << name << "::f " << y << std::endl; \ } \ virtual void vf() { \ std::cout << name << "::vf " << y << std::endl; \ } \ Y() { \ std::cout << name << " ctor" << std::endl; \ } \ ~Y() { \ std::cout << name << " dtor" << std::endl; \ } \ } #define TMPL_Z(Z) \ struct Z { \

Clang and the binary fold expressions — The curse of the empty parameter pack

由 旧巷老猫 提交于 2019-12-05 14:29:16
问题 Specifically Clang 3.6.0, the one currently hosted by Coliru. All these snippets are called from : int main() { foo(); std::cout << "\n----\n"; foo(1, 2, 3); } The following code : template <class... Args> void foo(Args... args) { std::cout << ... << args; } Triggers the following compilation error : main.cpp:7:17: error: expected ';' after expression std::cout << ... << args; ^ ; main.cpp:7:15: error: expected expression std::cout << ... << args; ^ So I tried putting parentheses around the

Can sizeof nested twice ever be a dependent expression?

由 我只是一个虾纸丫 提交于 2019-12-05 11:24:17
问题 I noticed that gcc 5.0 rejects the following code, while clang 3.6 accepts it. template<int n> struct I { typedef int Type; }; template<typename T> struct A { typedef I<sizeof(sizeof(T))>::Type Type; }; The two compilers seem to differ on whether sizeof(sizeof(T)) is a type-dependent or value-dependent expression. If the expression were dependent, then it follows that I<sizeof(sizeof(T))> is a dependent type, meaning that typename should be required. This is covered by the following wording

brace-or-equal-Initializer in unions

由 荒凉一梦 提交于 2019-12-05 09:48:16
问题 Related: How to initialize a non-POD member in Union The standard says At most one non-static data member of a union may have a brace-or-equal-initializer. But struct Point { Point() {} Point(int x, int y): x_(x), y_(y) {} int x_, y_; }; union U { int z; double w; Point p = Point(1,2); }; #include <iostream> int main () { U u; std::cout << u.p.x_ << ":" << u.p.y_ << std::endl; } prints 4196960:0 instead of the expected 1:2 . I consider this a compiler bug. Is that so? 回答1: C++11 [class.ctor]

Constexpr if with a non-bool condition

由 荒凉一梦 提交于 2019-12-04 23:37:13
I seem to have found something that Clang and GCC disagree on. Here's the code: int main() { if constexpr (2) {} } This successfully compiles with GCC 7.4.0, but it fails with Clang 7.0.0 with this error message: test.cpp:3:17: error: constexpr if condition evaluates to 2, which cannot be narrowed to type 'bool' [-Wc++11-narrowing] if constexpr (2) {} ^ 1 error generated. cppreference doesn't seem to mention "narrowing", so this seems like a Clang bug, but I'm not entirely certain. If this is a bug with either compiler, has it already been reported? StoryTeller - Unslander Monica Clang is

Is this a bug in dynamic?

由 流过昼夜 提交于 2019-12-04 10:26:34
问题 When implementing dynamic dispatch using dynamic on a generic class, and the generic type parameter is a private inner class on another class, the runtime binder throws an exception. For example: using System; public abstract class Dispatcher<T> { public T Call(object foo) { return CallDispatch((dynamic)foo); } protected abstract T CallDispatch(int foo); protected abstract T CallDispatch(string foo); } public class Program { public static void Main() { TypeFinder d = new TypeFinder(); Console

Why do gcc and clang each produce different output for this program? (conversion operator vs constructor)

由 好久不见. 提交于 2019-12-04 08:15:30
问题 program: #include <stdio.h> struct bar_t { int value; template<typename T> bar_t (const T& t) : value { t } {} // edit: You can uncomment these if your compiler supports // guaranteed copy elision (c++17). Either way, it // doesn't affect the output. // bar_t () = delete; // bar_t (bar_t&&) = delete; // bar_t (const bar_t&) = delete; // bar_t& operator = (bar_t&&) = delete; // bar_t& operator = (const bar_t&) = delete; }; struct foo_t { operator int () const { return 1; } operator bar_t ()

A bug in GCC implementation of bit-fields

由 隐身守侯 提交于 2019-12-04 03:02:45
Working in C11, the following struct: struct S { unsigned a : 4; _Bool b : 1; }; Gets layed out by GCC as an unsigned (4 bytes) of which 4 bits are used, followed by a _Bool (4 bytes) of which 1 bit is used, for a total size of 8 bytes. Note that C99 and C11 specifically permit _Bool as a bit-field member. The C11 standard (and probably C99 too) also states under §6.7.2.1 'Structure and union specifiers' ¶11 that: An implementation may allocate any addressable storage unit large enough to hold a bit-field. If enough space remains, a bit-field that immediately follows another bit-field in a
订阅 compiler-bug