[Bug c/29129] [4.2/4.3/4.4 Regression] [DR#341] unnamed parameters using [*]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29129 zhonghao at pku dot org.cn changed: What|Removed |Added CC||zhonghao at pku dot org.cn --- Comment #13 from zhonghao at pku dot org.cn --- I tried the latest gcc, but it rejects the sample code: :1:23: error: expected primary-expression before ']' token 1 | void f(unsigned int [*]); | ^ Compiler returned: 1 Is this a regression? Or, the idea is changed, and this code shall be rejected?
[Bug c/64480] List designated initializer triggers -Wmissing-field-initializers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64480 zhonghao at pku dot org.cn changed: What|Removed |Added CC||zhonghao at pku dot org.cn --- Comment #4 from zhonghao at pku dot org.cn --- Is this bug fixed? I tried the latest gcc, but it still rejects the sample code.
[Bug c/63495] struct __attribute__ ((aligned (8))) broken on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63495
zhonghao at pku dot org.cn changed:
What|Removed |Added
CC||zhonghao at pku dot org.cn
--- Comment #7 from zhonghao at pku dot org.cn ---
I tried to compile the sample code with the latest gcc.
struct __attribute__ ((aligned (8))) s { char c; };
_Static_assert (_Alignof (struct s) >= 8, "wrong alignment");
However, it does not compile. Is this a regression?
[Bug c/85696] OpenMP with variably modified and default(none) won't compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85696 zhonghao at pku dot org.cn changed: What|Removed |Added CC||zhonghao at pku dot org.cn --- Comment #11 from zhonghao at pku dot org.cn --- Is this bug really fixed? I tried the latest version, but it is still rejected: :1:28: error: use of parameter outside function body before ']' token 1 | void foo(int n, int a[][n]) |^ : In function 'void foo(...)': :4:9: error: 'a' was not declared in this scope 4 | a[23][0] = 42; | ^ Compiler returned: 1
[Bug c++/109426] New: Gcc runs into Infinite loop, when resolving templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109426
Bug ID: 109426
Summary: Gcc runs into Infinite loop, when resolving templates
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: zhonghao at pku dot org.cn
Target Milestone: ---
The code is as follows:
typedef struct astruct_d
{
void *data;
} astruct;
/* Generate a whole bunch of unique fake mallocs, this
keeps the vartrack dump simpler to understand (all
the "size" arguments have a unique name). */
#define DE0(X) \
void *malloc##X (unsigned long size##X);
#define DE1(X) \
DE0(X##0) DE0(X##1) DE0(X##2) DE0(X##3) DE0(X##4) \
DE0(X##5) DE0(X##6) DE0(X##7) DE0(X##8) DE0(X##9)
#define DE2(X) \
DE1(X##0) DE1(X##1) DE1(X##2) DE1(X##3) DE1(X##4) \
DE1(X##5) DE1(X##6) DE1(X##7) DE1(X##8) DE1(X##9)
#define DE3(X) \
DE2(X##0) DE2(X##1) DE2(X##2) DE2(X##3) DE2(X##4) \
DE2(X##5) DE2(X##6) DE2(X##7) DE2(X##8) DE2(X##9)
#define DE4(X) \
DE3(X##0) DE3(X##1) DE3(X##2) DE3(X##3) DE3(X##4) \
DE3(X##5) DE3(X##6) DE3(X##7) DE3(X##8) DE3(X##9)
DE4(0)
#undef DE0
#undef DE1
#undef DE2
#undef DE3
#undef DE4
void foo (void)
{
/* Now call all those mallocs and generate a series of
variables while at it. */
#define DE0(X) \
astruct *A##X = (astruct *) malloc##X(sizeof (astruct));
#define DE1(X) \
DE0(X##0) DE0(X##1) DE0(X##2) DE0(X##3) DE0(X##4) \
DE0(X##5) DE0(X##6) DE0(X##7) DE0(X##8) DE0(X##9)
#define DE2(X) \
DE1(X##0) DE1(X##1) DE1(X##2) DE1(X##3) DE1(X##4) \
DE1(X##5) DE1(X##6) DE1(X##7) DE1(X##8) DE1(X##9)
#define DE3(X) \
DE2(X##0) DE2(X##1) DE2(X##2) DE2(X##3) DE2(X##4) \
DE2(X##5) DE2(X##6) DE2(X##7) DE2(X##8) DE2(X##9)
#define DE4(X) \
DE3(X##0) DE3(X##1) DE3(X##2) DE3(X##3) DE3(X##4) \
DE3(X##5) DE3(X##6) DE3(X##7) DE3(X##8) DE3(X##9)
DE4(0)
DE4(1)
}
GCC runs into an infinite loop:
code0.c:35:18: warning: cast to pointer from integer of different size
[-Wint-to-pointer-cast]
35 | astruct *A##X = (astruct *) malloc##X(sizeof (astruct));
| ^
code0.c:37:32: note: in expansion of macro ‘DE0’
37 | DE0(X##0) DE0(X##1) DE0(X##2) DE0(X##3) DE0(X##4) \
|^~~
code0.c:41:42: note: in expansion of macro ‘DE1’
41 | DE1(X##5) DE1(X##6) DE1(X##7) DE1(X##8) DE1(X##9)
| ^~~
code0.c:44:2: note: in expansion of macro ‘DE2’
44 | DE2(X##5) DE2(X##6) DE2(X##7) DE2(X##8) DE2(X##9)
| ^~~
code0.c:46:22: note: in expansion of macro ‘DE3’
46 | DE3(X##0) DE3(X##1) DE3(X##2) DE3(X##3) DE3(X##4) \
| ^~~
code0.c:49:1: note: in expansion of macro ‘DE4’
49 | DE4(1)
| ^~~
[Bug c++/105997] New: A possible optimization bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105997
Bug ID: 105997
Summary: A possible optimization bug
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: zhonghao at pku dot org.cn
Target Milestone: ---
ZynAddSubFX is a musical synthesizer. I find a strange code in this project:
https://github.com/zynaddsubfx/zynaddsubfx/blob/master/src/Misc/MiddleWare.cpp
#if defined(__GNUC__) && !defined(__clang__) && !defined(__INTEL_COMPILER)
#pragma GCC push_options
#pragma GCC optimize("O0")
#endif
void gcc_10_1_0_is_dumb(const std::vector ,
const int N,
char *types,
rtosc_arg_t *args)
{
types[N] = 0;
for(int i=0; ihttps://github.com/zynaddsubfx/zynaddsubfx/commit/a1abae354e826802f8b6f990cae225d6fb06b2ac
"Disable gcc optimizations for a specific function
Due to a gcc opt bug a piece of code was put in a separate function to
prevent gcc from optimizing it. Later versions of gcc inlined the
function and the bug reappeared. So now we explicitly tell gcc to not
optimize it."
Is it real a GCC bug?
[Bug middle-end/105905] A possible rounding error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105905
--- Comment #2 from zhonghao at pku dot org.cn ---
A programmer answered me, and provided some details. Here, I copy his response:
"This code:
Vector2 v{Math::sin(37.0_degf), Math::cos(37.0_degf)};
Utility::print("{:.10}\n", v[1]);
Utility::print("{:.10}\n", (v*v.lengthInverted())[1]);
Utility::print("{:.10}\n", (v/v.length())[1]);
prints the following in a debug build (-march=native -g) and in a release build
without -march=native (so just -O3.
0.7986354828
0.7986354828
0.7986354828
However, it prints the following in a -march=native -O3 build.
0.7986354828
0.798635602
0.7986355424
Okay, so I thought it's some optimization kicking in, producing a different
result, but then I realized that this code:
Vector2 v{Math::sin(37.0_degf), Math::cos(37.0_degf)};
// Utility::print("{:.10}\n", v[1]);
Utility::print("{:.10}\n", (v*v.lengthInverted())[1]);
Utility::print("{:.10}\n", (v/v.length())[1]);
prints
0.7986354828
0.7986354828
even with -march=native -O3. So, ummm, the v[1] in combination with
Utility::print() causes that particular optimization to kick in, and if it's
not there, it doesn't optimize anything? If I change Utility::print() to
std::printf(), it also stops being strange and prints 0.7986354828 three times.
So I suppose there has to be sufficiently complex code around these operations
to make some optimization kick in? I tried to look at the disassembly, the
"strange" variant has a bunch of FMA calls, the non-strange variant has none,
but those calls could also have been somewhere else, I'm not that good at
understanding the compiler output.
I tested with GCC 10 as well, and it has the same weird behavior as 11.
Unfortunately I don't remember if I was at GCC 10 or 9 before that commit.
Clang prints 0.7986354828 always.
"
[Bug c++/105905] New: A possible rounding error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105905 Bug ID: 105905 Summary: A possible rounding error Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: zhonghao at pku dot org.cn Target Milestone: --- magnum is a data visualization library. I notice that its programmers complained a rounding error in gcc. It occurs when compiling their code in the release version. To fix the problem, they change their test cases, which is a workaround: https://github.com/mosra/magnum/commit/fb51f25a7b613aa5be744deea5a4ddb88f3de064 I also open an issue in magnum. Its programmers can provide more feedback.
[Bug c++/105884] New: A possible optimization bug when uint64_t is used with -O2/-O3.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105884 Bug ID: 105884 Summary: A possible optimization bug when uint64_t is used with -O2/-O3. Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: zhonghao at pku dot org.cn Target Milestone: --- zapret is a tool to bypass network blocking: https://github.com/bol-van/zapret/blob/master/docs/readme.eng.md I notice that its programmers complain an optimization bug. This bug is triggered when gcc optimizes uint64_t. The commit is https://github.com/bol-van/zapret/commit/9402cd2cf0a16352a3401f7bce1a894bf131138b Please check the problem.
[Bug c++/105882] New: A possible constexpr bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105882
Bug ID: 105882
Summary: A possible constexpr bug
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: zhonghao at pku dot org.cn
Target Milestone: ---
The code sample is as follows:
#include
struct real128
{
__float128 m_value;
template
constexpr bool get(T ) const
{
using value_type = typename T::value_type;
rop.real(static_cast(m_value));
rop.imag(static_cast(0));
return true;
}
};
constexpr auto fappo(real128 x)
{
std::complex ret{1,2};
x.get(ret);
return ret;
}
constexpr auto flap = fappo(real128{4});
gcc rejects this code, but clang accepts it. mp++ is a library for
multiprecision arithmetic. Its programmers disable several code lines, when gcc
compiles this project. Please check:
https://github.com/bluescarni/mppp/commit/628651b9928e35dc09c0c2de3d2561abababb55f
[Bug c++/105881] New: GCC release mode can crash Torque3D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105881 Bug ID: 105881 Summary: GCC release mode can crash Torque3D Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: zhonghao at pku dot org.cn Target Milestone: --- Torque3D is an open source game engine: https://torque3d.org/ When I read its code, I notice that it fixes a crash, and this crash can be caused by GCC. The bug report is https://github.com/TorqueGameEngines/Torque3D/pull/559 The fix looks simple: https://github.com/TorqueGameEngines/Torque3D/commit/1b55dce613dab6122aa7660d546328e83b103534 I have sent this bug report to Torque3D programmers. Hope that they can provide more details of this bug.
[Bug c++/105460] New: sizeof (unsigned int) != sizeof (uint8_t *)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105460 Bug ID: 105460 Summary: sizeof (unsigned int) != sizeof (uint8_t *) Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: zhonghao at pku dot org.cn Target Milestone: --- Clang's comments say there is an `unsigned int`-sized "reserved" member here, because when the objc4 modern runtime is used on LP64 platforms, there would otherwise be a 32-bit-sized hole here for alignment reasons. However, it doesn't actually add the "reserved" field to its AST data structures. GCC *does* add the field explicitly. On LP64, adding it or not is irrelevant. But on AVR, sizeof (unsigned int) == sizeof (uint8_t *), and it matters. An example is from:https://github.com/mhjacobson/avr-objc/commit/6187e336d706f1a87a7f0cbd9efa838f9d966737 This means that I have to compile Objective-C code either all with clang or all with GCC.
[Bug c++/105457] New: error: '__builtin_huge_valq()' is not a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105457
Bug ID: 105457
Summary: error: '__builtin_huge_valq()' is not a constant
expression
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: zhonghao at pku dot org.cn
Target Milestone: ---
The code is as follows:
template
struct infinity{};
template <> struct infinity<__float128> { static constexpr __float128 value =
__builtin_huge_valq(); };
int main() {
auto x = infinity<__float128>::value;
}
GCC 7.1+ accepts this code, but GCC 6.4 rejects it. I tried clang and other
compilers. They all reject the code:https://godbolt.org/z/qWb5oe4dx
The above code comes from kokkos:
https://github.com/mosra/corrade/commit/59823941093bee9f99e5a63cb4218b53a7bd5495
Look like a gcc bug?
