6 ms·

This appears to be fixed if you `return {c, 0}` to fully initialize the struct.

by Areading314 6y ago

mcolavita 6y ago
The first example is, but the second and third are not.
xyproto 6y ago
Having to keep tricks and workarounds in mind at all times is a big part of why C++ is disliked by many programmers.
- gumby 6y ago
  This is not an issue with the C++ language. It is clearly a compiler bug (well, misoptimization). There are plenty of real reasons for liking or disliking C++ but your response reads like a knee-jerk response.
  - xyproto 6y ago
    Vtables, are they always predictably optimized? Whole program linking? Consts and constexpr? Yes, it's possible to know exactly how everything is compiled down to assembly with enough experience, but all abstractions carry a requirements of knowledge about how well they are optimized.
    - gumby 6y ago
      Those are not language specification issues, apart from const and constexpr. If you are doing systems programming you may quite reasonably care about fine details and at least C++ is one of the languages that gives you the tools to do so if it matters to your use case. But the high (abstraction) level of C++ development, in particular modern C++ which is largely pointer-free, make is pretty easy to rapidly write code with a minimum of foot gunning. I'm more concerned with the unpredictable performance of java or python. Others write excellent code in those languages without needing to worry about that, which is also great.
  - kazinator 6y ago
    The bug is alarming. The code is not even peephole optimized up to 1985-ish standards Regarding { c, 0 } versus { c }, I don't expect in a mature C or C++ compiler for such high level differences in an expression to affect instruction selection. Both { c } and { c, 0 } say exactly the same thing: one member is initialized and the rest are zero. I would expect that there is no difference in intermediate representations at all, long before we get to a code generating back end. The compiler should convert the initializer to a canonical representation early on and not deal with different cases of it thereafter. This is definitely a WTH?
    - gumby 6y ago
      > The bug is alarming. I used to run a compiler company (Cygnus). People were always complaining that the compiler was broken when the bug was in their code. That being said we also got lots of real bug reports and sometimes you'd look at them and say "how the hell does anybody compile code when this happens?" Of course really those cases were indeed bad but only infrequently triggered. But they are codebases like any other and code has bugs. I still find bugs every few months in various compilers. Usually they are already known. And code quality bugs are lower priority than conformance (accuracy) bugs.
- gnulinux 6y ago
  Not only that this issue has nothing to do with C++ language but an implementation of C++, but also this exact same issue and a lot worse (i.e. missed optimization opportunity) can and will happen in every single language and every single implementation. Just submit a bug report and move on.
kazinator 6y ago
return { c } fully initializes the struct according to the language semantics, and the inefficient code does that. What you've written is just a different way of spelling the full initialization, which should not have a radical effect on the generated code.
- Areading314 6y ago
  Agreed, just thought it was noteworthy
  - kazinator 6y ago
    It's alarming that such a high level difference has that much influence over code generation, in such a mature compiler.

This appears to be fixed if you `return {c, 0}` to fully initialize the struct.

mcolavita 6y ago

The first example is, but the second and third are not.

xyproto 6y ago

Having to keep tricks and workarounds in mind at all times is a big part of why C++ is disliked by many programmers.

gumby 6y ago
This is not an issue with the C++ language. It is clearly a compiler bug (well, misoptimization). There are plenty of real reasons for liking or disliking C++ but your response reads like a knee-jerk response.
- xyproto 6y ago
  Vtables, are they always predictably optimized? Whole program linking? Consts and constexpr? Yes, it's possible to know exactly how everything is compiled down to assembly with enough experience, but all abstractions carry a requirements of knowledge about how well they are optimized.
  - gumby 6y ago
    Those are not language specification issues, apart from const and constexpr. If you are doing systems programming you may quite reasonably care about fine details and at least C++ is one of the languages that gives you the tools to do so if it matters to your use case. But the high (abstraction) level of C++ development, in particular modern C++ which is largely pointer-free, make is pretty easy to rapidly write code with a minimum of foot gunning. I'm more concerned with the unpredictable performance of java or python. Others write excellent code in those languages without needing to worry about that, which is also great.
- kazinator 6y ago
  The bug is alarming. The code is not even peephole optimized up to 1985-ish standards Regarding { c, 0 } versus { c }, I don't expect in a mature C or C++ compiler for such high level differences in an expression to affect instruction selection. Both { c } and { c, 0 } say exactly the same thing: one member is initialized and the rest are zero. I would expect that there is no difference in intermediate representations at all, long before we get to a code generating back end. The compiler should convert the initializer to a canonical representation early on and not deal with different cases of it thereafter. This is definitely a WTH?
  - gumby 6y ago
    > The bug is alarming. I used to run a compiler company (Cygnus). People were always complaining that the compiler was broken when the bug was in their code. That being said we also got lots of real bug reports and sometimes you'd look at them and say "how the hell does anybody compile code when this happens?" Of course really those cases were indeed bad but only infrequently triggered. But they are codebases like any other and code has bugs. I still find bugs every few months in various compilers. Usually they are already known. And code quality bugs are lower priority than conformance (accuracy) bugs.
gnulinux 6y ago
Not only that this issue has nothing to do with C++ language but an implementation of C++, but also this exact same issue and a lot worse (i.e. missed optimization opportunity) can and will happen in every single language and every single implementation. Just submit a bug report and move on.

kazinator 6y ago

return { c } fully initializes the struct according to the language semantics, and the inefficient code does that. What you've written is just a different way of spelling the full initialization, which should not have a radical effect on the generated code.

Areading314 6y ago
Agreed, just thought it was noteworthy
- kazinator 6y ago
  It's alarming that such a high level difference has that much influence over code generation, in such a mature compiler.