[Bug preprocessor/94127] New: #pragma system_header marks unrelated files as system headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94127
Bug ID: 94127
Summary: #pragma system_header marks unrelated files as system
headers
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: aleksey.covacevice at gmail dot com
Target Milestone: ---
When compiling `x.c` as below:
/* x.c */
#include
#include
/* sys.h */
#pragma GCC system_header
#include "sys2.h"
/* usr.h */
#include "other.h"
/* sys2.h empty */
/* other.h empty */
file "other.h" gets marked as a system header, as per -fdebug-cpp:
{P:./other.h;F:./usr.h;L:1;C:0;S:1;M:0x7f323a64b180;E:0,LOC:260288,R:260288}
^^^
This affects dependency generation with -MMD.
If `sys.h` includes `` (in angle brackets), or includes nothing at all,
this does not happen. Neither does it happen if `x.c` includes either file with
quotes.
Nothing in the documentation suggests this behavior is intended.
[Bug preprocessor/94127] #pragma system_header marks unrelated files as system headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94127 --- Comment #2 from Aleksey Covacevice --- (In reply to Jonathan Wakely from comment #1) > I think it's intended. > > You should put the pragma after including other headers if you don't want > them to be affected. What does the pragma have to do with *any* of the other include files, specially considering that `usr.h` has been included from the main source file in the example?
[Bug c++/90189] Spurious "error: parameter packs not expanded" when a dependent name coincides
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90189
Aleksey Covacevice changed:
What|Removed |Added
CC||aleksey.covacevice at gmail
dot co
||m
--- Comment #1 from Aleksey Covacevice ---
Another such situation:
template
struct any;
template
using any_t = typename any::type;
template
struct str { any_t>> func(); };
Changing `type` to something else, in either `any_t` or `str`, allows the code
to compile.
5.1.0 accepts the code; 5.2.0 onward reject it.
Possibly related to #61022.
[Bug tree-optimization/94010] New: [missed optimization] -fmerge-all-constants misses simple array merging
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94010
Bug ID: 94010
Summary: [missed optimization] -fmerge-all-constants misses
simple array merging
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: aleksey.covacevice at gmail dot com
Target Milestone: ---
-fmerge-all-constants misses a very simple optimization scenario involving an
array:
extern void g(const char* c);
void f() {
const char c[] = "12345";
g(c);
}
produces a local array (with or without the flag).
If `const char c[]` is replaced by `const char* c`, the above code produces a
global array as expected.
This seems to be the case in every GCC version I have tested, starting from
4.9.
[Bug c/94010] [missed optimization] constant automatic string variable not elided
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94010 --- Comment #3 from Aleksey Covacevice --- (In reply to Richard Biener from comment #1) > It isn't so much about -fmerge-all-constants, this is about not eliding > the automatic variable for the string constant. > > Note it may be the language standard doesn't permit changing the > linkage of 'c', code may end up writing to it, expecting automatic > storage. > Richard, the same optimization is performed by Clang but it requires -fmerge-all-constants (GCC indeed doesn't, in the pointer case). So, perhaps, this optimization should be still related to this flag since the language standard might not allow for such (and the flag breaks compliance anyway)? > So this eliding could be done by the frontend already. Note there's > heuristic > in the gimplifier to eventually emit a copy from a string constant rather > than doing inline initialization but the gimplifier cannot really elide the > variable. > > Also this must have come up in the past.
[Bug tree-optimization/91091] New: [missed optimization] Missing aliasing optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91091
Bug ID: 91091
Summary: [missed optimization] Missing aliasing optimization
Product: gcc
Version: 5.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: aleksey.covacevice at gmail dot com
Target Milestone: ---
Consider the following:
struct s { int x; };
struct t { int x; };
void swap(struct s* p, struct t* q) {
p->x = q->x;
q->x = p->x;
}
Aliasing rules forbid `p` and `q` to point to the same object; yet, GCC 5.4 and
most subsequent versions produce (-O3):
swap(s*, t*):
mov eax, DWORD PTR [rsi]
mov DWORD PTR [rdi], eax
mov DWORD PTR [rsi], eax // Possible alias between p and q
ret
whereas GCC versions 4.5.3 to 5.3 and versions 8.1 to 8.2 correctly produce:
swap(s*, t*):
mov eax, DWORD PTR [rsi]
mov DWORD PTR [rdi], eax
ret
All versions produce the correct code if __restrict__ is used on any pointer.
This behavior can be verified on Godbolt: https://godbolt.org/z/WYMoFI
[Bug libstdc++/87493] chrono::system_clock unusable with std::tm due to misaligned precisions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87493 Aleksey Covacevice changed: What|Removed |Added CC||aleksey.covacevice at gmail dot co ||m --- Comment #3 from Aleksey Covacevice --- VinÃcius: I couldn't reproduce the issue at hand. I've tested a number of `std::tm` combinations manually, and also checked through all `time_t` values from `INT_MIN` to `INT_MAX` without any failures. Could you provide a sample input for which the assertion fails? Recall that, from POSIX, `tm.tm_year` is supposed to be a number counted from 1900. Mistakenly inputting larger values will silently overflow things along the way.
[Bug c++/77875] New: C++ core issue 1288
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77875
Bug ID: 77875
Summary: C++ core issue 1288
Product: gcc
Version: 6.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: aleksey.covacevice at gmail dot com
Target Milestone: ---
GCC does not fully implement the resolution for core issue 1288
(http://wg21.link/cwg1288).
Example:
int i; (int&){i};
GCC yields "invalid cast of an rvalue expression of type 'int' to type 'int&'".
More info and discussion:
http://stackoverflow.com/questions/39840117/brace-initialization-vs-parenthesis-bug
[Bug pch/46110] New: Precompiled headers: GCC fails to properly locate include files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46110 Summary: Precompiled headers: GCC fails to properly locate include files Product: gcc Version: 4.4.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: pch AssignedTo: unassig...@gcc.gnu.org ReportedBy: aleksey.covacev...@gmail.com Created attachment 22102 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22102 Test case script GCC fails to properly locate include files when using precompiled headers that are located in a deeper directory in the search path. This problem happens when a file "z.h" includes two other files, "x.h" and "y.h", such that "y.h" also includes "x.h", and they are all located in another directory in the include path (yielding include lines such as '#include "dir/x.h"'). The issue is much better explained through a test case. The following command sequence is a simple test case that yields the symptom: == #!/bin/sh mkdir -p include/dir pch/dir touch include/dir/x.h echo "#include \"dir/x.h\"" > include/dir/y.h echo "#include \"dir/x.h\"" > include/dir/z.h echo "#include \"dir/y.h\"" >> include/dir/z.h gcc -I pch -I include include/dir/x.h -o pch/dir/x.h.gch gcc -I pch -I include include/dir/y.h -o pch/dir/y.h.gch gcc -I pch -I include include/dir/z.h -o pch/dir/z.h.gch == The output is the following: == In file included from include/dir/z.h:2: include/dir/y.h:1:19: error: pch/dir/x.h: No such file or directory == If the include path "-I pch" is ommited from the above commands (i.e., removing the precompiled headers from the search path), everything runs fine. Also, if the subdirectory "dir/" is properly removed from every place above, everything runs fine. Now, if the include path "-I include" is ommited, the output is: == include/dir/z.h:2:19: error: dir/y.h: No such file or directory == although the precompiled header "pch/dir/y.h.gch" already exists (there should be no reason to avoid using it, "-Winvalid-pch" does not report anything and the compilation for "y.h", which is pretty similar, proceeds fine). The snippet above should also help generate proper ".i" files for further investigation. Running GCC on a Ubuntu 9.10 x86 host. Output of gcc -v: Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.4.1-4ubuntu9' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-targets=all --disable-werror --with-arch-32=i486 --with-tune=generic --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu Thread model: posix gcc version 4.4.1 (Ubuntu 4.4.1-4ubuntu9) Cheers, Alek
[Bug preprocessor/46110] Precompiled headers: GCC fails to properly locate include files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46110 --- Comment #2 from Aleksey Covacevice 2010-10-21 21:31:14 UTC --- Richard, thanks for the reply. Actually the documentation states that other preprocessor directives (such as "#define"s) can appear before the include line that would include the PCH. Nevertheless, that is not really the case. In fact it also states that only a single precompiled header can be used in a particular compilation, and I think the symptom must be somewhat related to this. I believe this must be a bug, because even if GCC couldn't use a PCH for any reason previously stated, it should ignore it and use the original include file, which in this scenario it can be properly found in the search path. Thanks again, Alek
[Bug c++/71165] std::array with aggregate initialization generates huge code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71165
Aleksey Covacevice changed:
What|Removed |Added
CC||aleksey.covacevice at gmail
dot co
||m
--- Comment #3 from Aleksey Covacevice ---
I also confirm this. Also present in 5.4.0 and 6.1.0 (at least).
The following test case contains 3 scenarios, each one originated from
uncommenting the respective line in main():
#include
using namespace std;
struct X {
X() { cerr << __func__ << endl; }
~X() { cerr << __func__ << endl; }
};
template
struct Object1 { Type Value; };
template
struct Object2 { Type Value{}; };
int main() {
//X object[0x1000]; // (1)
//Object1 object; // (2)
//Object2 object; // (3)
}
Scenarios (1) and (2) produce roughly the same executable, in either -O0 and
-Ofast. Scenario (3) takes an enormous time to compile, produces a much larger
executable, -Winline complains about not being able to inline things and, on
occasion, cc1plus crashes (specially if you raise the size of the arrays
involved).
Output (for scenario 3):
Test.c++: In function 'int main()':
Test.c++:14:8: warning: inlining failed in call to 'constexpr Object2::Object2() noexcept (false)': --param large-function-growth limit
reached [-Winline]
struct Object2 { Type Value{}; };
^
Test.c++:19:21: warning: called from here [-Winline]
Object2 object; // (3)
