[Bug c++/105467] Dependency file produced by C++ modules causes Ninja errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105467 --- Comment #6 from jpakkane at gmail dot com --- According to C++ foundation's developer survey [1] the most popular build system for C++ projects is CMake by quite a massive margin. Based on personal experience almost everybody uses CMake's Ninja backend rather than the Make backend on unixy platforms simply because it is so much faster CMake does not support modules in the Make backend [2]. Some people even claim that properly supporting Make to build C++ modules is not possible if you want to make it actually production quality and reliable. Modules are very much a forward looking thing. People who still use plain Make are most likely doing so on legacy projects that can not adopt modules in the near future in any case. Thus it would seem that the most probable ways C++ modules are going to be used are a) VS projects b) whatever Xcode ends up implementing c) Ninja files. [1] https://isocpp.org/files/papers/CppDevSurvey-2023-summary.pdf [2] https://cmake.org/cmake/help/latest/manual/cmake-cxxmodules.7.html
[Bug c++/105467] Dependency file produced by C++ modules causes Ninja errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105467 --- Comment #4 from jpakkane at gmail dot com --- As a build system developer I'd like that the most common usage (i.e. using Ninja) would be the default and work without extra compiler flags.
[Bug c++/105467] Dependency file produced by C++ modules causes Ninja errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105467 --- Comment #2 from jpakkane at gmail dot com --- It would be preferable to have the default work out of the box than having every end user having to add compiler flags to make things work. Ninja is the most popular underlying build system for modules, having it work by default would make things easier for many people.
[Bug c++/105467] New: Dependency file produced by C++ modules causes Ninja errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105467 Bug ID: 105467 Summary: Dependency file produced by C++ modules causes Ninja errors Product: gcc Version: 11.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jpakkane at gmail dot com Target Milestone: --- Currently if you try to build C++ modules using Ninja and a dependency file, things fail with this fairly cryptic error message (that comes from Ninja): inputs may not also have inputs The commend line is this: g++ -Igcc/modtest.p -Igcc '-I../test cases/unit/85 cpp modules/gcc' -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wnon-virtual-dtor -std=c++20 -O0 -g -fmodules-ts -MD -MQ gcc/modtest.p/src0.cxx.o -MF gcc/modtest.p/src0.cxx.o.d -o gcc/modtest.p/src0.cxx.o -c '../test cases/unit/85 cpp modules/gcc/src0.cxx and the generated dependency file looks like this: gcc/modtest.p/src0.cxx.o gcm.cache/M0.gcm: \ ../test\ cases/unit/85\ cpp\ modules/gcc/src0.cxx \ /usr/include/stdc-predef.h gcc/modtest.p/src0.cxx.o gcm.cache/M0.gcm: M1.c++m M0.c++m: gcm.cache/M0.gcm .PHONY: M0.c++m gcm.cache/M0.gcm:| gcc/modtest.p/src0.cxx.o CXX_IMPORTS += M1.c++m This sets things up so that the object file depends on the sources and the generated module file depends on the object file only. Ninja does not like this and errors out because it thinks that outputs (the .o file in this case) may not be used as a dependency to other outputs. A possible fix would be to set the dependencies of the module output to be the same source files as are used for the object file. Something like this: gcc/modtest.p/src0.cxx.o gcm.cache/M0.gcm: \ ../test\ cases/unit/85\ cpp\ modules/gcc/src0.cxx \ /usr/include/stdc-predef.h gcc/modtest.p/src0.cxx.o gcm.cache/M0.gcm: M1.c++m M0.c++m: gcm.cache/M0.gcm .PHONY: M0.c++m gcm.cache/M0.gcm: \ ../test\ cases/unit/85\ cpp\ modules/gcc/src0.cxx \ /usr/include/stdc-predef.h CXX_IMPORTS += M1.c++m The corresponding Ninja bug is here: https://github.com/ninja-build/ninja/issues/1962
[Bug c++/84544] New: Missing warning when returning a reference to internal variable inside a lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84544
Bug ID: 84544
Summary: Missing warning when returning a reference to internal
variable inside a lambda
Product: gcc
Version: 7.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jpakkane at gmail dot com
Target Milestone: ---
Suppose you have a C++14 method like this:
auto f1() {
int x = 3;
auto l = [&]() -> int& { return x; };
return l;
}
Here the returned lambda contains a reference to the stack allocated integer
that goes out of scope. Gcc does not give a warning for this. If you call
function f1 like this:
int& f2() {
auto l = f1();
return l();
}
Then Gcc does print the following warning (but only with -O2 or higher):
: In function 'int& f2()':
:9:14: warning: function returns address of local variable
[-Wreturn-local-addr]
return l();
^
:2:9: note: declared here
int x = 3;
^
Compiler returned: 0
It would be useful if gcc generated a warning for f1 already.
[Bug other/84351] New: Provide dependency information also when linking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84351 Bug ID: 84351 Summary: Provide dependency information also when linking Product: gcc Version: 7.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: jpakkane at gmail dot com Target Milestone: --- The -M flag and its like is very useful for reliable dependencies. It would be great if the same would work also when linking. The use case is the following. Suppose you build a project with a dependency that comes in via pkg-config. The eventual link line looks like this: gcc -o final_exe source.o -L/path/to/my/place -L/path/to/somewhere/else -lmydep It is very difficult to tell where the dependency library will be picked up from. If the user updates any library by doing a "make/ninja install" from the dependency file, then it is hard to know that the dependency libraries have changed and thus require a rebuild. (usually doing an install updates headers, which _do_ trigger a rebuild but some systems only overwrite installed files if they have changed so looking only at header files is not reliable). If linking supported generating dependency files like -M does for source compilations, this would not be a problem and
[Bug c++/82763] New: std::is_pod works incorrectly with volatile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82763
Bug ID: 82763
Summary: std::is_pod works incorrectly with volatile
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jpakkane at gmail dot com
Target Milestone: ---
The following program prints "is_pod 1":
#include
#include
#include
typedef struct
{
int64_t dt_us;
} __attribute__ ((packed)) mytime_t ;
struct MyTimeDate
{
volatile mytime_t mytime;
};
int main(int argc, const char *argv[])
{
std::cout << "is_pod " << std::is_pod::value << std::endl;
return 0;
}
However Clang prints "is_pod 0". Originally this was filed as a bug in Clang
here:
https://bugs.llvm.org/show_bug.cgi?id=35076
However that bug has a long explanation on why Clang is doing the right thing
and that Gcc behaves incorrectly.
[Bug other/81541] New: Potential size optimisation: reusing common function endings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81541
Bug ID: 81541
Summary: Potential size optimisation: reusing common function
endings
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: jpakkane at gmail dot com
Target Milestone: ---
In embedded development code size optimizations are very important and there
are some optimizations that commercial compilers do but GCC does not seem to.
As an example compiling the following code:
int func5() {
int i = 0;
i+=func2();
i+=func3();
i+=func4();
return i+func1();
}
int func6() {
int i=1;
i+=func3();
i+=func3();
i+=func4();
return i+func1();
}
On ARM using -Os produces the following assembly:
func5():
push{r4, lr}
bl func2()
mov r4, r0
bl func3()
add r4, r4, r0
bl func4()
add r4, r4, r0
bl func1()
add r0, r4, r0
pop {r4, lr}
bx lr
func6():
push{r4, lr}
bl func3()
add r4, r0, #1
bl func3()
add r4, r4, r0
bl func4()
add r4, r4, r0
bl func1()
add r0, r4, r0
pop {r4, lr}
bx lr
Note how the ends of both of these functions have identical endings. This could
be converted to the following:
func5():
push{r4, lr}
bl func2()
mov r4, r0
common_tail:
bl func3()
add r4, r4, r0
bl func4()
add r4, r4, r0
bl func1()
add r0, r4, r0
pop {r4, lr}
bx lr
func6():
push{r4, lr}
bl func3()
add r4, r0, #1
b common_tail
which has smaller code size.
I did a simple experiment and based on that this might not be all that useful
on x86:
http://nibblestew.blogspot.com/2017/07/experiment-binary-size-reduction-by.html
On ARM and similar platforms this would probably be beneficial, especially
given that commercial compilers perform this optimization.
[Bug c++/78773] "Empty" const only class not optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78773 --- Comment #2 from jpakkane at gmail dot com --- I tried constexpr and it did not have any effect so I just left it out for simplicity. Sorry for the dupe. I tried searching but could not come up with a suitable search term to find it.
[Bug c++/78773] New: "Empty" const only class not optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78773
Bug ID: 78773
Summary: "Empty" const only class not optimized away
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jpakkane at gmail dot com
Target Milestone: ---
Suppose we have the following very simple class for accessing a memory mapped
register:
class MemoryMappedRegister {
public:
MemoryMappedRegister(const int value) :
ptr{reinterpret_cast<char*>(value)} {}
void write(char v) const { *ptr = v; }
private:
volatile char* const ptr;
};
const MemoryMappedRegister MyReg(12345);
void set_value(char v) {
MyReg.write(v);
}
That is, the only reason for this class to exist is to provide a nicer UI to
register poking than C macros. When compiled with GCC (up to the version of 7
in gcc.godbolt.org as of this writing) using -O2 -std=c++14 the output is this:
set_value(char):
mov rax, QWORD PTR MyReg[rip]
mov BYTE PTR [rax], dil
ret
mov QWORD PTR MyReg[rip], 12345
ret
That is, it reserves space for the object to store the always constant pointer
value and loads it indirectly. When compiled with Clang 3.9 the output is this:
set_value(char): # @set_value(char)
mov byte ptr [12345], dil
ret
Here no space is reserved for the object and the write is using immediate mode.
[Bug c++/77307] New: Bring memset + free optimisation to C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77307
Bug ID: 77307
Summary: Bring memset + free optimisation to C++
Product: gcc
Version: 6.1.1
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jpakkane at gmail dot com
Target Milestone: ---
For the following code gcc will remove the call to memset:
void destroy(char *buf, size_t bufsize) {
memset(buf, 0, bufsize);
free(buf);
}
However if you change it to delete[] like this:
void destroy(char *buf, size_t bufsize) {
memset(buf, 0, bufsize);
delete[] buf;
}
memset is called. Tested on gcc.godbolt.org, Clang and ICC seem to behave in
the same way.
In this case there are no destructors to run so the reasoning for removing the
memset call should be the same for both cases (assuming the C++ standard does
not have some weird requirements of which I am unaware).
[Bug fortran/62162] New: Gfortran produces incorrect dependency files when using -MQ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62162 Bug ID: 62162 Summary: Gfortran produces incorrect dependency files when using -MQ Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jpakkane at gmail dot com Create a simple Fortran file stuff.f95 that looks like this: MODULE Circle REAL, PARAMETER :: Pi = 3.1415927 REAL :: radius END MODULE Circle Then compile it with this: gfortran -cpp -MD -MQ stuff.f95.o -o stuff.f95.o -c stuff.f95 Then print the output of the dependency file, which looks like this: stuff.o stuff.f95.o circle.mod: stuff.f95 The bug here is that Gfortran writes both the default target (stuff.o) and the one specified with -MQ (stuff.f95.o). It should only print the latter. The same happens if you use -MT instead of -MQ.
[Bug fortran/62162] Gfortran produces incorrect dependency files when using -MQ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62162 --- Comment #2 from jpakkane at gmail dot com --- Seems to be. There are some claims that it would be fixed in 4.6 but as the comments state, is still around in 4.9.
[Bug fortran/62162] Gfortran produces incorrect dependency files when using -MQ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62162 --- Comment #4 from jpakkane at gmail dot com --- That seems the reasonable thing to do. Hopefully someone looks into this soon.
[Bug c++/61113] New: Mark private methods hidden automatically
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61113
Bug ID: 61113
Summary: Mark private methods hidden automatically
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jpakkane at gmail dot com
Suppose you compile a class defined like this using -fvisibility=hidden:
class __attribute__ ((visibility(default))) Thing final {
public:
void publicFunc();
private:
void privateFunc();
};
Dumping the .so file with nm -C -D gives this:
1626 T Thing::publicFunc()
166c T Thing::privateFunc()
That is, both the private and public methods are exported in the symbol table.
The latter is wasteful because private methods can only be called from within
the class and those methods are always in the same .so (or maybe there are
pathological cases why someone might want to split class implementation over
multiple .so files, but it seems unlikely).
This also inhibits compiler optimizations as described on the Gcc visibility
wiki page.
You can hide the method manually by declaring it like this:
void __attribute__ ((visibility(hidden))) privateFunc();
If your code base is big, this a lot of work to do manually. Therefore it would
be nice if there was a way to hide private methods automatically. Alternatives
include a compiler flag such as -fvisibility-private-hidden or a heuristic that
tags private methods hidden if -fvisibility=hidden is specified on the command
line and the method's visibility has not been specified explicitly (so that
people can expose their private methods if they really want to).
[Bug c++/61113] Mark private methods hidden automatically
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61113
--- Comment #2 from jpakkane at gmail dot com ---
In that case it would fail. But you can make it work by doing this (assuming
compilation with -fvisibility=hidden):
class __attribute__ ((visibility(default))) Thing final {
public:
void publicFunc() { privateFunc(); }
private:
void __attribute__ ((visibility(default))) privateFunc();
};
That is, explicitly specifying visibility would override whatever heuristics or
command line flags one might have. Calling private methods from public inline
methods remains possible, but takes an extra definition. (There is also the
problem that calling private methods from inline functions make those private
methods part of your ABI, albeit indirectly. You can't change their signatures
without breaking code compiled against the old version.)
I guess the issue here boils down to which is more common: calling private
functions from inline methods or the need to decorate private methods manually
with hidden attributes.
I have only had to deal with the latter case but more experienced people might
have a different opinion.
For what it's worth, GCC's documentation seems to advocate making everything
hidden by default and granting visibility only when needed.
[Bug lto/58251] -flto causes ICE lto1: internal compiler error: in splice_child_die, at dwarf2out.c:4706
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58251 --- Comment #5 from jpakkane at gmail dot com --- I retried this with Gcc 4.8.2 on trusty and no longer get the crash. I have not tried to reproduce David Kredba's issue so that might still remain.
[Bug lto/58251] New: -flto causes ICE lto1: internal compiler error: in splice_child_die, at dwarf2out.c:4706
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58251 Bug ID: 58251 Summary: -flto causes ICE lto1: internal compiler error: in splice_child_die, at dwarf2out.c:4706 Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: jpakkane at gmail dot com With Gcc 4.8.1 on Ubuntu Saucy x86-64 I can reliably trigger an ICE. As the issue happens during link, I can't reduce it to a single file test case. The steps to reproduce are these: bzr branch lp:libcolumbus cd libcolumbus mkdir build cd build CXXFLAGS=-flto cmake -DCMAKE_BUILD_TYPE=relwithdebinfo .. make The output is this: Linking CXX shared library columbus.cpython-33m.so lto1: internal compiler error: in splice_child_die, at dwarf2out.c:4706 Please submit a full bug report, with preprocessed source if appropriate. See file:///usr/share/doc/gcc-4.8/README.Bugs for instructions. lto-wrapper: /usr/bin/c++ returned 1 exit status /usr/bin/ld: lto-wrapper failed collect2: error: ld returned 1 exit status You need CMake, libicu-dev, python3-dev and libboost-python-dev to compile the library. The version of libboost-python in Ubuntu Saucy is 1.53.
[Bug c++/54780] G++ does not find precompiled headers in some cases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54780 --- Comment #3 from jpakkane at gmail dot com 2012-10-03 07:53:59 UTC --- Thanks for the explanation and workaround. I guess this is not a big issue if you are using Autotools, where the established practice is to compile inside the source directory. It might cause a lot of head scratching for users of other build systems or those few autotools users that use a dedicated build directory.
[Bug c++/54780] New: G++ does not find precompiled headers in some cases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54780 Bug #: 54780 Summary: G++ does not find precompiled headers in some cases Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: jpakk...@gmail.com Created attachment 28326 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28326 Some dummy sources demonstrating the issue Using GCC of Ubuntu Quantal, version gcc version 4.7.2 (Ubuntu/Linaro 4.7.2-2ubuntu1). Under some circumstances g++ does not find precompiled headers that are in the search path. I have attached a simple test case that demonstrates the issue. Just run compile.sh that comes with it and watch the output. In the test case there is a common.h header that includes a bunch of STL headers. It is in a subdirectory called hdir. The file is first precompiled and placed in the subdirectory pchdir. The script then compiles a bunch of files that include common.h but do very little else. Both pchdir and hdir are passed in with -I. The precompiled header is found and compilation is fast. Next the script copies common.h to the main directory and compiles the sources again using the exact same compiler switches. What happens is that g++ does not find the precompiled header, probably because it first looks in the source dir and finds common.h but not the corresponding pch and just stops looking. This makes the compilation very slow. Then the script copies the precompiled header to the main directory and compiles the files again. Now g++ finds the pch and compilation is again fast. Summing all this up: precompiled headers can not be used if the header is in the source directory and the pch is in some other directory which is included with -I. This is a problem when doing out-of-source builds.
