[Bug c++/55252] Caret diagnostic doesn't show useful location when macro clashes with name in system header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55252 --- Comment #19 from Dodji Seketeli --- (In reply to Tom Tromey from comment #16) > I've tripped across this enough that I've actually filed dups twice now. > > I think it would be best to change the ordering here. > That is, the initial error ought to generally be the > location of the outermost expansion. Then, the remaining > notes ought to delineate the macro expansions. > > While it is true that this will yield a sub-optimal result in some > cases, I think that it will have better results in the preponderance > of cases. That is, there's no way to be perfect here but gcc could be more > useful. I am starting to think the same here. In the unwinding, it seems less surprising to start from the code the user has the most chance to have written herself, that is, the code at the point of expansion of the outermost macro, rather than the point where the offending token was spelled -- which can be hidden anywhere. If everyone agrees, then I am okay to change the unwinding direction for the next stage 1. Manuel, Jonathan, what do you think?
[Bug preprocessor/64803] [5 Regression] __LINE__ inside macro is not constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64803 Dodji Seketeli changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Dodji Seketeli --- A fix for this issue was committed to trunk in revision r220367 and should be available in GCC 5. I am thus closing this problem report as FIXED. Thank you for reporting this problem!
[Bug preprocessor/64803] [5 Regression] __LINE__ inside macro is not constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64803 --- Comment #8 from Dodji Seketeli --- Author: dodji Date: Tue Feb 3 09:26:46 2015 New Revision: 220367 URL: https://gcc.gnu.org/viewcvs?rev=220367&root=gcc&view=rev Log: PR preprocessor/64803 - __LINE__ inside macro is not constant Consider the example code mentionned in this PR: $ cat -n test.c 1#define C(a, b) a ## b 2#define L(x) C(L, x) 3#define M(a) goto L(__LINE__); __LINE__; L(__LINE__): 4M(a /* --> this is the line of the expansion point of M. */ 5 ); /* --> this is the line of the end of the invocation of M. */ $ "cc1 -quiet -E test.c" yields: goto L5; 5; L4: ; Notice how we have a 'L4' there, where it should be L5. That is the issue. My understanding is that during the *second* expansion of __LINE__ (the one between the two L(__LINE__)), builtin_macro() is called by enter_macro_context() with the location of the expansion point of M (which is at line 4). Then _cpp_builtin_macro_text() expands __LINE__ into the line number of the location of the last token that has been lexed, which is the location of the closing parenthesis of the invocation of M, at line 5. So that invocation of __LINE__ is expanded into 5. Now let's see why the last invocation of __LINE__ is expanded into 4. In builtin_macro(), we have this code at some point: /* Set pfile->cur_token as required by _cpp_lex_direct. */ pfile->cur_token = _cpp_temp_token (pfile); cpp_token *token = _cpp_lex_direct (pfile); /* We should point to the expansion point of the builtin macro. */ token->src_loc = loc; The first two statements insert a new token in the stream of lexed token and pfile->cur_token[-1], is the "new" last token that has been lexed. But the location of pfile->cur_token[-1] is the same location as the location of the "previous" pfile->cur_token[-1], by courtesy of _cpp_temp_token(). So normally, in subsequent invocations of builtin_macro(), the location of pfile->cur_token[-1] should always be the location of the closing parenthesis of the invocation of M at line 5. Except that that code in master now has the statement "token->src_loc = loc;" on the next line. That statement actually sets the location of pfile->cur_token[-1] to 'loc'. Which is the location of the expansion point of M, which is on line 4. So in the subsequent call to builtin_macro() (for the last expansion of __LINE__ in L(__LINE__)), for _cpp_builtin_macro_text(), pfile->cur_token[-1].src_loc is going to have a line number of 4. I think the core issue here is that the location that is passed to builtin_macro() from enter_macro_context() is not correct when we are in presence of a top-most function-like macro invocation; in that case, that location should be the location of the closing parenthesis of the macro invocation. Otherwise, if we are in presence of a a top-most object-like macro invocation then the location passed down to builtin_macro should be the location of the expansion point of the macro. That way, in the particular case of the input code above, the location received by builtin_macro() will always have line number 5. Boostrapped and tested on x86_64-unknown-linux-gnu against trunk. libcpp/ChangeLog: * internal.h (cpp_reader::top_most_macro_node): New data member. * macro.c (enter_macro_context): Pass the location of the end of the top-most invocation of the function-like macro, or the location of the expansion point of the top-most object-like macro. (cpp_get_token_1): Store the top-most macro node in the new pfile->top_most_macro_node data member. (_cpp_pop_context): Clear the new cpp_reader::top_most_macro_node data member. gcc/testsuite/ChangeLog: * gcc.dg/cpp/builtin-macro-1.c: New test case. Signed-off-by: Dodji Seketeli Added: trunk/gcc/testsuite/gcc.dg/cpp/builtin-macro-1.c Modified: trunk/gcc/testsuite/ChangeLog trunk/libcpp/ChangeLog trunk/libcpp/internal.h trunk/libcpp/macro.c
[Bug preprocessor/64803] [5 Regression] __LINE__ inside macro is not constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64803 Dodji Seketeli changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #7 from Dodji Seketeli --- I have proposed the patch for review at https://gcc.gnu.org/ml/gcc-patches/2015-01/msg02693.html
[Bug preprocessor/64803] [5 Regression] __LINE__ inside macro is not constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64803 --- Comment #6 from Dodji Seketeli --- Created attachment 34622 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34622&action=edit Refined candidate fix patch with regression test and cover letter I have successfully tested this refined patch locally and I am currently bootstrapping it. I'll submit it right away if it passes bootstrap. Thanks for testing the previous one!
[Bug c/64803] [5 Regression] __LINE__ inside macro is not constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64803 --- Comment #3 from Dodji Seketeli --- Created attachment 34614 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34614&action=edit Candidate fix This is the patch that I am currently testing. It seems to fix the issue for me. Please let me know if it works for you.
[Bug c/61861] Incorrect column number for -Wdiscarded-qualifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61861 Dodji Seketeli changed: What|Removed |Added CC||dodji at gcc dot gnu.org Resolution|FIXED |DUPLICATE --- Comment #8 from Dodji Seketeli --- Hello, I was on the road when this patch was submitted so I missed it. Sorry. It looks too like this issue is related to PR61817. I even sent a patch for this at http://comments.gmane.org/gmane.comp.gcc.patches/316794 but then later you sent your patch and it went in :-) I think the initial patch I sent solves this issue as well. Both of our patches have a something common: they make builtin_macro() take an additional parameter that is the location of the expansion point of the built-in macro we are looking at. One the differences in handling is that you set the token->src_loc to the location of the expansion point of the built-in macro; but then normally, the convention is that that token->src_loc must always be spelling location. It must never be a virtual location. And the issue is that the location of the expansion point can be a virtual location. So we should not set token->src_loc like that, I think. But do not worry; I'll update the patch, test it, submit it and keep you guys posted. Cheers. *** This bug has been marked as a duplicate of bug 61817 ***
[Bug preprocessor/61817] Inconsistent location of tokens in the expansion list of a built-in macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61817 Dodji Seketeli changed: What|Removed |Added CC||chengniansun at gmail dot com --- Comment #2 from Dodji Seketeli --- *** Bug 61861 has been marked as a duplicate of this bug. ***
[Bug preprocessor/61817] Inconsistent location of tokens in the expansion list of a built-in macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61817 --- Comment #1 from Dodji Seketeli --- I sent a patch for this at http://comments.gmane.org/gmane.comp.gcc.patches/316794
[Bug preprocessor/60723] Line directives with incorrect system header flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60723 --- Comment #22 from Dodji Seketeli --- So finally the two patches that have been proposed at https://gcc.gnu.org/ml/gcc-patches/2014-07/msg01063.html and https://gcc.gnu.org/ml/gcc-patches/2014-07/msg01064.html have been accepted and committed to trunk. I'll wait before closing this bug that the stakeholders following this test the tree with the new patches. In the mean time, I'll look at the additional issue PR61817. Thanks.
[Bug preprocessor/60723] Line directives with incorrect system header flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60723
--- Comment #21 from Dodji Seketeli ---
Author: dodji
Date: Wed Jul 16 10:33:36 2014
New Revision: 212638
URL: https://gcc.gnu.org/viewcvs?rev=212638&root=gcc&view=rev
Log:
PR preprocessor/60723 - missing system-ness marks for macro tokens
When a system macro is expanded in a non-system file during
out-of-line preprocessing, it can happen that the preprocessor forgets
to emit line markers to express the system-ness status of tokens that
come after the expansion of the macro.
That can lead to situations where the entire non-system file can be
considered as being a system file and thus have its warnings be
discarded during the compilation of the resulting preprocessed file.
My understanding is that this is due to the preprocessor not
systematically detecting (and reporting) the change in system-ness of
tokens.
And this is what this patch does. Each time the system-ness of a
given token is different from the previous token that was emitted by
the preprocessor, it emits a line marker for the sole purpose of
marking the new system-ness of the subsequent tokens to come.
Bootstrapped and tested on x86_64-unknown-linux-gnu against trunk.
gcc/c-family/ChangeLog:
* c-ppoutput.c (struct print::prev_was_system_token): New data
member.
(init_pp_output): Initialize it.
(maybe_print_line_1, maybe_print_line, print_line_1, print_line)
(do_line_change): Return a flag saying if a line marker was
emitted or not.
(scan_translation_unit): Detect if the system-ness of the token we
are about to emit is different from the one of the previously
emitted token. If so, emit a line marker. Avoid emitting useless
adjacent line markers. Avoid emitting line markers for tokens
originating from the expansion of built-in macros.
(scan_translation_unit_directives_only): Adjust.
gcc/testsuite/ChangeLog:
* gcc.dg/cpp/syshdr{4,5}.{c,h}: New test files.
Signed-off-by: Dodji Seketeli
Signed-off-by: Dodji Seketeli
Added:
trunk/gcc/testsuite/gcc.dg/cpp/syshdr4.c
trunk/gcc/testsuite/gcc.dg/cpp/syshdr4.h
trunk/gcc/testsuite/gcc.dg/cpp/syshdr5.c
trunk/gcc/testsuite/gcc.dg/cpp/syshdr5.h
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-ppoutput.c
trunk/gcc/testsuite/ChangeLog
[Bug preprocessor/60723] Line directives with incorrect system header flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60723 --- Comment #20 from Dodji Seketeli --- > In a function-like macro expansion, regular tokens are line-marked as being > expanded at the opening parenthesis, while builtins are line-marked as being > expanded at the closing parenthesis (both of these choices are reasonable, > though the inconsistency is probably a design flaw). As noted in discussions we had on the mailing list at https://gcc.gnu.org/ml/gcc-patches/2014-07/msg01080.html, I think the fact that tokens resulting from the expansion of a built-in macro have their location set to the closing parenthesis of the invocation of the enclosing function-like macro is a separate issue that needs to be dealt with. I have thus filed PR61817 to track this. Thanks.
[Bug preprocessor/61817] Inconsistent location of tokens in the expansion list of a built-in macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61817 Dodji Seketeli changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-07-16 Assignee|unassigned at gcc dot gnu.org |dodji at gcc dot gnu.org Ever confirmed|0 |1
[Bug preprocessor/61817] New: Inconsistent location of tokens in the expansion list of a built-in macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61817
Bug ID: 61817
Summary: Inconsistent location of tokens in the expansion list
of a built-in macro
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: dodji at gcc dot gnu.org
Consider this function-like macro definition in the inc.h file
--->inc.h<---
#define F() const int line = __LINE__
--->8<---
Now consider its use in a file test.c:
-->cat -n test.c<
1 #include "inc.h"
2
3 void
4 foo()
5 {
6F
7 (
8 )
9 ;
10 }
--->8<-
Running test.c through cc1 -quiet -E yields:
->8<
# 1 "test.c"
# 1 ""
# 1 ""
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 1 "" 2
# 1 "test.c"
# 1 "inc.h" 1
# 2 "test.c" 2
void
foo()
{
const int line =
8
;
}
->8<--
Note how tokens "const", "int", "line" and "=" are all on the same line as the
expansion point of the function-like F() macro, but how the token "8",
resulting from the expansion of the built-in macro __FILE__ is on the same line
as the closing parenthesis of the invocation of F().
This is the problem. The result of the __FILE__ macro should be "6" and should
be on the same line (line 6) as the other tokens of the expansion-list of F().
This issue actually holds for the expansion of all built-in macros.
So more generelly, I would describe the issue as such:
When expanded in a function-like macro, the location of resulting tokens of a
built-in macro is set to the closing parenthesis of the enclosing function-like
macro invocation, rather than being set to the location of the expansion point
of the invocation the enclosing functin-like macro.
[Bug preprocessor/60723] Line directives with incorrect system header flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60723 --- Comment #18 from Dodji Seketeli --- Thanks Christophe, The attached patch above should hopefully fix the issue it was causing. Is there a chance that you test that it doesn't break your arm build before I try to commit it again? Thanks in advance.
[Bug preprocessor/60723] Line directives with incorrect system header flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60723 Dodji Seketeli changed: What|Removed |Added Attachment #33010|0 |1 is obsolete|| --- Comment #17 from Dodji Seketeli --- Created attachment 33045 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33045&action=edit Updated patch that avoid emitting new lines when it's prohibited
[Bug preprocessor/60723] Line directives with incorrect system header flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60723
--- Comment #13 from Dodji Seketeli ---
Author: dodji
Date: Tue Jul 1 09:17:14 2014
New Revision: 212194
URL: https://gcc.gnu.org/viewcvs?rev=212194&root=gcc&view=rev
Log:
PR preprocessor/60723 - missing system-ness marks for macro tokens
When a system macro is expanded in a non-system file during
out-of-line preprocessing, it can happen that the preprocessor forgets
to emit line markers to express the system-ness status of tokens that
come after the expansion of the macro.
That can lead to situations where the entire non-system file can be
considered as being a system file and thus have its warnings be
discarded during the compilation of the resulting preprocessed file.
My understanding is that this is due to the preprocessor not
systematically detecting (and reporting) the change in system-ness of
tokens.
And this is what this patch does. Each time the system-ness of a
given token is different from the previous token that was emitted by
the preprocessor, it emits a line marker for the sole purpose of
marking the new system-ness of the subsequent tokens to come.
Bootstrapped and tested on x86_64-unknown-linux-gnu against trunk.
gcc/c-family/ChangeLog:
* c-ppoutput.c (struct print::prev_was_system_token): New data
member.
(init_pp_output): Initialize it.
(maybe_print_line_1, maybe_print_line, print_line_1, print_line)
(do_line_change): Return a flag saying if a line marker was
emitted or not.
(scan_translation_unit): Detect if the system-ness of the token we
are about to emit is different from the one of the previously
emitted token. If so, emit a line marker. Avoid emitting
useless adjacent line markers.
(scan_translation_unit_directives_only): Adjust.
gcc/testsuite/ChangeLog:
* gcc.dg/cpp/syshdr{4,5}.{c,h}: New test files.
Signed-off-by: Dodji Seketeli
Added:
trunk/gcc/testsuite/gcc.dg/cpp/syshdr4.c
trunk/gcc/testsuite/gcc.dg/cpp/syshdr4.h
trunk/gcc/testsuite/gcc.dg/cpp/syshdr5.c
trunk/gcc/testsuite/gcc.dg/cpp/syshdr5.h
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-ppoutput.c
trunk/gcc/testsuite/ChangeLog
[Bug preprocessor/60723] Line directives with incorrect system header flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60723 --- Comment #12 from Dodji Seketeli --- Created attachment 33010 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33010&action=edit A patch candidate that I am currently testing This the patch I am running through bootstrap at the moment. The patch basically makes the pre-processor detects changes in system-ness of tokens and upon each of these change, emits a line marking directive so that the information about the system-ness change is not lost. I haven't commented the code yet. Nicholas, maybe you could test the patch and give me feedback until my (slow) machine completes the bootstrap? Thanks.
[Bug preprocessor/60723] Line directives with incorrect system header flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60723 Dodji Seketeli changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |dodji at gcc dot gnu.org --- Comment #11 from Dodji Seketeli --- I am taking this one.
[Bug preprocessor/58580] [4.8 Regression] preprocessor goes OOM with warning for zero literals
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58580 Dodji Seketeli changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #12 from Dodji Seketeli --- This fall-out seems fixed now on trunk by commit r207046. Sorry for the inconvenience.
[Bug preprocessor/58844] [4.8/4.9 Regression] ICE with invalid use of ##
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58844 --- Comment #4 from Dodji Seketeli --- yes, the patch looks good to me. Thank you for looking into that.
[Bug preprocessor/59935] [4.9 Regression] Firefox build fails with: : internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59935 --- Comment #9 from Dodji Seketeli --- Author: dodji Date: Tue Jan 28 15:03:19 2014 New Revision: 207195 URL: http://gcc.gnu.org/viewcvs?rev=207195&root=gcc&view=rev Log: PR preprocessor/59935 - caret diagnostics crashes on non-file locations gcc/ChangeLog * input.c (location_get_source_line): Bail out on when line number is zero, and test the return value of lookup_or_add_file_to_cache_tab. gcc/testsuite/ChangeLog * c-c++-common/cpp/warning-zero-location.c: New test. * c-c++-common/cpp/warning-zero-location-2.c: Likewise. Signed-off-by: Dodji Seketeli Added: trunk/gcc/testsuite/c-c++-common/cpp/warning-zero-location-2.c trunk/gcc/testsuite/c-c++-common/cpp/warning-zero-location.c Modified: trunk/gcc/ChangeLog trunk/gcc/input.c trunk/gcc/testsuite/ChangeLog
[Bug preprocessor/59935] [4.9 Regression] Firefox build fails with: : internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59935 Dodji Seketeli changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |dodji at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Dodji Seketeli --- I am looking into that.
[Bug preprocessor/58580] [4.8 Regression] preprocessor goes OOM with warning for zero literals
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58580 --- Comment #10 from Dodji Seketeli --- Author: dodji Date: Thu Jan 23 09:13:08 2014 New Revision: 206957 URL: http://gcc.gnu.org/viewcvs?rev=206957&root=gcc&view=rev Log: PR preprocessor/58580 - preprocessor goes OOM with warning for zero literals In this problem report, the compiler is fed a (bogus) translation unit in which some literals contain bytes whose value is zero. The preprocessor detects that and proceeds to emit diagnostics for that king of bogus literals. But then when the diagnostics machinery re-reads the input file again to display the bogus literals with a caret, it attempts to calculate the length of each of the lines it got using fgets. The line length calculation is done using strlen. But that doesn't work well when the content of the line can have several zero bytes. The result is that the read_line never sees the end of the line because strlen repeatedly reports that the line ends before the end-of-line character; so read_line thinks its buffer for reading the line is too small; it thus increases the buffer, leading to a huge memory consumption and disaster. Here is what this patch does. location_get_source_line is modified to return the length of a source line that can now contain bytes with zero value. diagnostic_show_locus() is then modified to consider that a line can have characters of value zero, and so just shows a white space when instructed to display one of these characters. Additionally location_get_source_line is modified to avoid re-reading each and every line from the beginning of the file until it reaches the line number N that it is instructed to get; this was leading to annoying quadratic behaviour when reading adjacent lines near the end of (big) files. So a cache is now associated to the file opened in text mode. When the content of the file is read, that content is stashed in the file cache. That file cache is searched for line delimiters. A number of line positions are saved in the cache and a number of file caches are kept in memory. That way when location_get_source_line is asked to read line N + 1, it just has to start reading from line N that it has already read. libcpp/ChangeLog: * include/line-map.h (linemap_get_file_highest_location): Declare new function. * line-map.c (linemap_get_file_highest_location): Define it. gcc/ChangeLog: * input.h (location_get_source_line): Take an additional line_size parameter. (void diagnostics_file_cache_fini): Declare new function. * input.c (struct fcache): New type. (fcache_tab_size, fcache_buffer_size, fcache_line_record_size): New static constants. (diagnostic_file_cache_init, total_lines_num) (lookup_file_in_cache_tab, evicted_cache_tab_entry) (add_file_to_cache_tab, lookup_or_add_file_to_cache_tab) (needs_read, needs_grow, maybe_grow, read_data, maybe_read_data) (get_next_line, read_next_line, goto_next_line, read_line_num): New static function definitions. (diagnostic_file_cache_fini): New function. (location_get_source_line): Take an additional output line_len parameter. Re-write using lookup_or_add_file_to_cache_tab and read_line_num. * diagnostic.c (diagnostic_finish): Call diagnostic_file_cache_fini. (adjust_line): Take an additional input parameter for the length of the line, rather than calculating it with strlen. (diagnostic_show_locus): Adjust the use of location_get_source_line and adjust_line with respect to their new signature. While displaying a line now, do not stop at the first null byte. Rather, display the zero byte as a space and keep going until we reach the size of the line. * Makefile.in: Add vec.o to OBJS-libcommon gcc/testsuite/ChangeLog: * c-c++-common/cpp/warning-zero-in-literals-1.c: New test file. Signed-off-by: Dodji Seketeli Added: trunk/gcc/testsuite/c-c++-common/cpp/warning-zero-in-literals-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in trunk/gcc/diagnostic.c trunk/gcc/diagnostic.h trunk/gcc/input.c trunk/gcc/input.h trunk/gcc/testsuite/ChangeLog trunk/libcpp/ChangeLog trunk/libcpp/include/line-map.h trunk/libcpp/line-map.c
[Bug preprocessor/58580] [4.8/4.9 Regression] preprocessor goes OOM with warning for zero literals
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58580 Dodji Seketeli changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Dodji Seketeli --- This should be fixed in trunk for 4.9 by commit http://gcc.gnu.org/git/?p=gcc.git;a=commit;h=fc3eff8854861fcd70d33d26095b17fe456fae31 I'll give it some testing time, and if it turns out to work OK, I'll consider backporting the change to 4.8. What do you think, Richi?
[Bug preprocessor/58580] [4.8/4.9 Regression] preprocessor goes OOM with warning for zero literals
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58580 --- Comment #6 from Dodji Seketeli --- A candidate patch was sent to http://gcc.gnu.org/ml/gcc-patches/2013-10/msg02676.html
[Bug preprocessor/58580] [4.8/4.9 Regression] preprocessor goes OOM with warning for zero literals
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58580 Dodji Seketeli changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-10-29 Assignee|unassigned at gcc dot gnu.org |dodji at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #5 from Dodji Seketeli --- I am looking into this.
[Bug c++/56782] [4.8/4.9 Regression] Regression with empty pack expansions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56782 Dodji Seketeli changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Dodji Seketeli --- This has been committed to trunk and 4.8.
[Bug c++/56782] [4.8/4.9 Regression] Regression with empty pack expansions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56782 --- Comment #3 from Dodji Seketeli --- A candidate patch was sent to http://gcc.gnu.org/ml/gcc-patches/2013-05/msg00841.html for this.
[Bug c++/56782] [4.8/4.9 Regression] Regression with empty pack expansions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56782 Dodji Seketeli changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |dodji at gcc dot gnu.org
[Bug sanitizer/56330] ICE: verify_gimple failed: gimple_bb (stmt) is set to a wrong basic block with -fsanitize=address
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56330 Dodji Seketeli changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #9 from Dodji Seketeli 2013-02-16 09:58:22 UTC --- This should now be fixed in trunk (4.8).
[Bug sanitizer/56330] ICE: verify_gimple failed: gimple_bb (stmt) is set to a wrong basic block with -fsanitize=address
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56330 --- Comment #8 from Dodji Seketeli 2013-02-16 09:33:01 UTC --- Author: dodji Date: Sat Feb 16 09:32:56 2013 New Revision: 196102 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196102 Log: [asan] Fix for PR asan/56330 gcc/ * asan.c (get_mem_refs_of_builtin_call): White space and style cleanup. (instrument_mem_region_access): Do not forget to always put instrumentation of the of 'base' and 'base + len' in a "if (len != 0) statement, even for cases where either 'base' or 'base + len' are not instrumented -- because they have been previously instrumented. Simplify the logic by putting all the statements instrument 'base + len' inside a sequence, and then insert that sequence right before the current insertion point. Then, to instrument 'base + len', just get an iterator on that statement. And do not forget to update the pointer to iterator the function received as argument. gcc/testsuite/ * c-c++-common/asan/no-redundant-instrumentation-4.c: New test file. * c-c++-common/asan/no-redundant-instrumentation-5.c: Likewise. * c-c++-common/asan/no-redundant-instrumentation-6.c: Likewise. * c-c++-common/asan/no-redundant-instrumentation-7.c: Likewise. * c-c++-common/asan/no-redundant-instrumentation-8.c: Likewise. * c-c++-common/asan/pr56330.c: Likewise. * c-c++-common/asan/no-redundant-instrumentation-1.c (test1): Ensure the size argument of __builtin_memcpy is a constant. Added: trunk/gcc/testsuite/c-c++-common/asan/no-redundant-instrumentation-4.c trunk/gcc/testsuite/c-c++-common/asan/no-redundant-instrumentation-5.c trunk/gcc/testsuite/c-c++-common/asan/no-redundant-instrumentation-6.c trunk/gcc/testsuite/c-c++-common/asan/no-redundant-instrumentation-7.c trunk/gcc/testsuite/c-c++-common/asan/no-redundant-instrumentation-8.c trunk/gcc/testsuite/c-c++-common/asan/pr56330.c Modified: trunk/gcc/ChangeLog trunk/gcc/asan.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/c-c++-common/asan/no-redundant-instrumentation-1.c
[Bug sanitizer/56330] ICE: verify_gimple failed: gimple_bb (stmt) is set to a wrong basic block with -fsanitize=address
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56330 --- Comment #7 from Dodji Seketeli 2013-02-16 09:30:10 UTC --- FWIW, I have posted the patch for this to http://gcc.gnu.org/ml/gcc-patches/2013-02/msg00795.html
[Bug sanitizer/56330] ICE: verify_gimple failed: gimple_bb (stmt) is set to a wrong basic block with -fsanitize=address
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56330 --- Comment #5 from Dodji Seketeli 2013-02-15 19:46:44 UTC --- Created attachment 29477 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29477 Updated patch with cleanups explained in the ChangeLog Thanks! I have updated the patch to simplify the logic in instrument_mem_region_access somewhat, especially the part that does the statement iterator decrementing dance. I have also added more regression tests. What do you think?
[Bug sanitizer/56330] ICE: verify_gimple failed: gimple_bb (stmt) is set to a wrong basic block with -fsanitize=address
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56330 Dodji Seketeli changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |dodji at gcc dot gnu.org |gnu.org |
[Bug sanitizer/55309] gcc's address-sanitizer 66% slower than clang's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309
Dodji Seketeli changed:
What|Removed |Added
Attachment #29366|0 |1
is obsolete||
--- Comment #22 from Dodji Seketeli 2013-02-06
15:02:44 UTC ---
Created attachment 29370
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29370
Candidate patch to avoid duplicated intra bb instrumentation
> Trying this patch:
> % cat inc.cc
> void foo(int *a) {
> (*a)++;
> }
> % gcc -fsanitize=address -O2 inc.cc -S -o - | grep __asan_report
> call__asan_report_load4
> call__asan_report_store4
> % clang -fsanitize=address -O2 inc.cc -S -o - | grep __asan_report
> callq __asan_report_load4
> %
>
> Is this test expected to work (have one __asan_error call) with this patch?
The patch indeed (naively) considers read and write accesses as being
different, you are right. I am attaching a patch that does not, and
that generates just one __asan_report call here.
I'd be nice to know if that makes any change to ...
> First results with the patch (c-only tests, train data):
> orig patched
>401.bzip2,89.60,90.10, 1.01
> 429.mcf,23.50,23.90, 1.02
>456.hmmer, 181.00, 145.00, 0.80
> 462.libquantum, 1.64, 1.64, 1.00
> 464.h264ref, 249.00, 249.00, 1.00
> 433.milc,20.10,20.00, 1.00
> 470.lbm,37.20,37.20, 1.00
> 482.sphinx3,17.50,17.50, 1.00
>
> significant speedup on 456.hmmer, no difference elsewhere.
... this. Hopefully, if subsequent intrumentations on same BB on
read/write are considered redundant now, we should see some speed
difference on more tests.
> 3 benchmarks fail to build:
> Error: 1x403.gcc 1x445.gobmk 1x458.sjeng
> resource.c:431:1: internal compiler error: in
> update_mem_ref_hash_table, at
> asan.c:460
The updated patch hopefully addresses that too.
Thank you for doing this!
[Bug sanitizer/55309] gcc's address-sanitizer 66% slower than clang's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309 --- Comment #16 from Dodji Seketeli 2013-02-06 10:55:38 UTC --- Created attachment 29366 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29366 Candidate patch to avoid duplicated intra bb instrumentation > As for Dodji's patch: can someone attach it here? Here is the attachment of what I currently have. > Let me benchmark it too, Thank you, that would be very appreciated. > although if that's just optimizing within one BB I don't expect more > than 5% difference (based on my experiments in llvm). That would be what I'd expect too, based on my experiments on GCC. But then I'd be very curious to hear about your findings.
[Bug c++/53609] Wrong variadic template pack expansion in alias template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53609 Dodji Seketeli changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from Dodji Seketeli 2013-01-30 11:44:49 UTC --- Fixed in trunk (4.8)
[Bug c++/53609] Wrong variadic template pack expansion in alias template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53609
--- Comment #3 from Dodji Seketeli 2013-01-22
10:05:13 UTC ---
Author: dodji
Date: Tue Jan 22 10:05:05 2013
New Revision: 195367
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195367
Log:
PR c++/53609 - Wrong variadic template pack expansion in alias template
Consider this example:
1template struct List {};
2template struct Z {static const int value = T;};
3template using LZ = List...>;
4
5template
6struct F
7{
8 using N = LZ; //#1 This should amount to
List...>
9}
10
11F, Z<2> >::N A; //#2
which G++ fails to compile, with this error message:
test-PR53609-3.cc: In instantiation of 'struct F, Z<2> >':
test-PR53609-3.cc:11:15: required from here
test-PR53609-3.cc:3:43: error: wrong number of template arguments (2, should be
1)
template using LZ = List...>;
^
test-PR53609-3.cc:2:24: error: provided for 'template struct Z'
template struct Z {static const int value = T;};
I think this is because in #1, when we substitute the argument pack
{U::value...} into the pack expansion Z..., tsubst_pack_expansion
yields Z, instead of Z..., so the instantiation
of LZ amounts to List >, instead of
List...>.
The idea of this patch is to make tsubst_pack_expansion support
substituting an argument pack (into a pack expansion) where one of the
arguments (let's call it the Ith argument) is itself a pack expansion
P. In that case, the Ith element resulting from the substituting
should be a pack expansion P'.
The pattern of P' is then the pattern of P into which the pattern of
the Ith argument of the argument pack has been substituted.
Tested on x86_64-unknown-linux-gnu against trunk.
gcc/cp/
* pt.c (argument_pack_element_is_expansion_p)
(make_argument_pack_select, use_pack_expansion_extra_args_p)
(gen_elem_of_pack_expansion_instantiation): New static functions.
(tsubst): When looking through an ARGUMENT_PACK_SELECT tree node,
look through the possibly resulting pack expansion as well.
(tsubst_pack_expansion): Use use_pack_expansion_extra_p to
generalize when to use the PACK_EXPANSION_EXTRA_ARGS mechanism.
Use gen_elem_of_pack_expansion_instantiation to build the
instantiation piece-wise. Don't use arg_from_parm_pack_p anymore,
as gen_elem_of_pack_expansion_instantiation and the change in
tsubst above generalize this particular case.
(arg_from_parm_pack_p): Remove this for it's not used by
tsubst_pack_expansion anymore.
gcc/testsuite/
* g++.dg/cpp0x/variadic139.C: New test.
* g++.dg/cpp0x/variadic140.C: Likewise.
* g++.dg/cpp0x/variadic141.C: Likewise.
Added:
trunk/gcc/testsuite/g++.dg/cpp0x/variadic139.C
trunk/gcc/testsuite/g++.dg/cpp0x/variadic140.C
trunk/gcc/testsuite/g++.dg/cpp0x/variadic141.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog
[Bug c++/55663] [C++11] Alias template combined with constexpr function is considered non-const
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55663 Dodji Seketeli changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #6 from Dodji Seketeli 2013-01-15 11:27:39 UTC --- Fixed in trunk for 4.8.
[Bug c++/55663] [C++11] Alias template combined with constexpr function is considered non-const
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55663
--- Comment #5 from Dodji Seketeli 2013-01-15
09:12:42 UTC ---
Author: dodji
Date: Tue Jan 15 09:12:30 2013
New Revision: 195189
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195189
Log:
PR c++/55663 - constexpr function templ instantiation
Consider the example of the problem report
1template
2constexpr bool the_truth () { return true; }
3
4template
5 struct Takes_bool { };
6
7template
8 using Alias = Takes_bool;
9
10template
11 struct test { using type = Alias()>; };
12
13int main () {
14 test a;
15
16 return 0;
17}
that yields the error:
test.cc: In substitution of ‘template using Alias = Takes_bool
[with bool B = the_truth()]’:
test.cc:11:51: required from ‘struct test’
test.cc:14:13: required from here
test.cc:11:51: error: integral expression ‘the_truth()’ is not
constant
struct test { using type = Alias()>; };
I think the issue happens in the course of instantiating test at
line 14, when we look into instantiating Alias()> (at
line 11) (using instantiate_alias_template) with T = int.
There, when we check the argument 'the_truth()' to see if it
actually is a constant expression, in check_instantiated_arg, we fail
to recognize it constexpr-ness b/c we just look at its TREE_CONSTANT.
At that point, the_truth should have been folded, and it's not,
because instantiate_alias_template forgets to call
coerce_template_parms on its arguments.
Fixed thus, bootstapped and tested on x86_64-unknown-linux-gnu against
trunk.
gcc/cp/
PR c++/55663
* pt.c (coerce_innermost_template_parms): New static function.
(instantiate_alias_template): Use it here.
gcc/testsuite/
PR c++/55663
* g++.dg/cpp0x/alias-decl-31.C: New test.
Added:
trunk/gcc/testsuite/g++.dg/cpp0x/alias-decl-31.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog
[Bug c++/55311] Cannot specialize template parameter of type 'const char *const' in 'using' alias
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55311 Dodji Seketeli changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #5 from Dodji Seketeli 2013-01-07 11:00:32 UTC --- This should be fixed in trunk (4.8).
[Bug c++/52343] [C++11] alias-definition dont work in `template` params type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52343 Dodji Seketeli changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #6 from Dodji Seketeli 2013-01-07 10:44:14 UTC --- This should be fixed in trunk (4.8)
[Bug c++/55311] Cannot specialize template parameter of type 'const char *const' in 'using' alias
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55311
--- Comment #4 from Dodji Seketeli 2013-01-07
08:06:52 UTC ---
Author: dodji
Date: Mon Jan 7 08:06:46 2013
New Revision: 194961
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=194961
Log:
PR c++/55311 - Cannot specialize alias template with arg of type array of char
Consider this test case:
1template
2struct A
3{};
4
5struct B {};
6
7extern constexpr char HELLO_WORLD[] = "hello world";
8
9A g; // <-- This works fine
10
11template
12using PartiallySpecialized = A; // <-- This fails
13
At line 12 G++ fails to instantiate the alias template that has a
string variable initialized with a string literal, with the error
message:
test.cc:12:46: error: ‘"hello world"’ is not a valid template argument of
type ‘const char*’ because ‘"hello world"’ is not a variable
using PartiallySpecialized = A; // <-- This fails
^
Note that instantiating the template A at line 9 with the same
arguments as in the problematic case above works.
This happens in the context of lookup_template_class_1, when it handles
the alias template instantiation A and thus passes the
VAR_DECL for HELLO_WORLD to convert_nontype_argument.
Note that from there decay_conversion replaces the the VAR_DECL with
its STRING_CST initializer[1]. Latter on, convert_nontype_argument
checks that the HELLO_WORLD constant it received as argument was
indeed a VAR_DECL:
else
{
tree decl;
decl = ((TREE_CODE (expr) == ADDR_EXPR)
? TREE_OPERAND (expr, 0) : expr);
if (TREE_CODE (decl) != VAR_DECL)
{
error ("%qE is not a valid template argument of type %qT "
"because %qE is not a variable",
expr, type, decl);
return NULL_TREE;
}
But the issue is, that VAR_DECL has been replaced by STRING_CST, so
the last 'if' above fails.
The fix is to teach decay_conversion to return the address of array,
rather than returning its initializer.
Bootstrapped and tested on x86_64-unknown-linux-gnu against trunk.
gcc/cp/
PR c++/55311
* pt.c (decay_conversion): Do not return the initializer of an array.
gcc/testsuite/
PR c++/55311
* g++.dg/cpp0x/alias-decl-30.C: New test.
* g++.dg/init/array21.C: New test.
Added:
trunk/gcc/testsuite/g++.dg/cpp0x/alias-decl-30.C
Modified:
trunk/gcc/cp/typeck.c
trunk/gcc/testsuite/g++.dg/init/array21.C
[Bug c++/52343] [C++11] alias-definition dont work in `template` params type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52343 --- Comment #5 from Dodji Seketeli 2013-01-07 08:03:39 UTC --- Author: dodji Date: Mon Jan 7 08:03:33 2013 New Revision: 194960 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=194960 Log: PR c++/52343 - error with alias template as template template argument In the example accompanying this patch, check_instantiated_arg tries to ensure that a non-type template argument should be a constant if it has integral or enumeration type. The problem is that an alias template which type-id is, e.g, an integer, looks like an argument that has integral/enumeration type: its TREE_TYPE is an integer type. So check_instantiated_arg mistenkaly barks that this integral non-type argument is not a constant. Bootstrapped and tested on x86_64-unknown-linux-gnu against trunk. gcc/cp/ PR c++/52343 * pt.c (check_instantiated_arg): Allow type template arguments. gcc/testsuite/ PR c++/52343 * g++.dg/cpp0x/alias-decl-29.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp0x/alias-decl-29.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog
[Bug c++/55663] [C++11] Alias template combined with constexpr function is considered non-const
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55663 --- Comment #4 from Dodji Seketeli 2012-12-23 17:18:27 UTC --- Created attachment 29037 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29037 Candidate patch that I have bootstrapped This is a candidate patch I'll send a little bit later once the discussion about my patch for PR c++/52343 at http://gcc.gnu.org/ml/gcc-patches/2012-12/msg01312.html settles a little bit. This is because both patches touch the same area, so there might be some kind of merging involved at some point.
[Bug c++/55663] [C++11] Alias template combined with constexpr function is considered non-const
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55663 Dodji Seketeli changed: What|Removed |Added Status|NEW |ASSIGNED CC||dodji at gcc dot gnu.org AssignedTo|unassigned at gcc dot |dodji at gcc dot gnu.org |gnu.org |
[Bug c++/55311] Cannot specialize template parameter of type 'const char *const' in 'using' alias
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55311 Dodji Seketeli changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-12-22 AssignedTo|unassigned at gcc dot |dodji at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1
[Bug c++/52343] [C++11] alias-definition dont work in `template` params type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52343 Dodji Seketeli changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |dodji at gcc dot gnu.org |gnu.org |
[Bug c++/54401] Missing diagnostics about type-alias at class scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54401 Dodji Seketeli changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Dodji Seketeli 2012-12-07 17:15:20 UTC --- This should be fixed in trunk (4.8)
[Bug c++/54401] Missing diagnostics about type-alias at class scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54401
--- Comment #2 from Dodji Seketeli 2012-12-07
17:05:40 UTC ---
Author: dodji
Date: Fri Dec 7 17:05:19 2012
New Revision: 194306
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=194306
Log:
PR c++/54401 - Confusing diagnostics about type-alias at class scope
Consider this invalid example given in the PR, where T is not defined:
1template
2struct X {
3using type = T;
4};
g++ yields the confusing diagnostics:
test.cc:3:10: error: expected nested-name-specifier before 'type'
using type = T;
^
test.cc:3:10: error: using-declaration for non-member at class scope
test.cc:3:15: error: expected ';' before '=' token
using type = T;
^
test.cc:3:15: error: expected unqualified-id before '=' token
I think this is because in cp_parser_member_declaration we tentatively
parse an alias declaration; we then have a somewhat meaningful
diagnostic which alas is not emitted because we are parsing
tentatively. As the parsing didn't succeed (because the input is
invalid) we try to parse a using declaration, which fails as well; but
then the diagnostic emitted is the one for the failed attempt at
parsing a using declaration, not an alias declaration. Oops.
The idea of this patch is to commit the tentative parse when we see
the '=' token in the alias-declaration. That way any error encounter
after that token is reported to the user.
We are now getting the following output:
test.cc:3:18: erreur: expected type-specifier before ‘T’
using type = T;
^
test.cc:3:18: erreur: ‘T’ does not name a type
I don't really like the "before 'T'" there, but I think we maybe could
revisit the format of what cp_parser_error emits in general, now that
we have caret diagnostics; We could maybe do away with the "before T"
altogether?
In the mean time, it seems to me that this patch brings an improvement
over what we already have in trunk, and the issue above could be
addressed separately.
Tested on x86_64-unknown-linux-gnu against trunk.
gcc/cp/
* parser.c (cp_parser_alias_declaration): Commit to tentative
parse when see the '=' token. Get out if the type-id is invalid.
Update function comment.
(cp_parser_member_declaration): Don't try to parse a using
declaration if we know that we expected an alias declaration; that
is, if we see the '=' token after the identifier.
gcc/testsuite/
* g++.dg/cpp0x/alias-decl-28.C: New test.
* g++.dg/cpp0x/alias-decl-16.C: Update.
Added:
trunk/gcc/testsuite/g++.dg/cpp0x/alias-decl-28.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/cpp0x/alias-decl-16.C
[Bug c++/54875] Forward declare enums cannot be used as a template argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54875 Dodji Seketeli changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #5 from Dodji Seketeli 2012-11-16 15:23:41 UTC --- Fixed in trunk (4.8)
[Bug c++/54875] Forward declare enums cannot be used as a template argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54875
--- Comment #4 from Dodji Seketeli 2012-11-16
15:20:11 UTC ---
Author: dodji
Date: Fri Nov 16 15:20:03 2012
New Revision: 193562
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193562
Log:
PR c++/54875 - Error with alias template that resolves to an enum
Consider this short example:
1template
2using AddConst = T const;
3
4enum FwdEnum : int;
5
6int main() {
7 AddConst *ptr = nullptr;
8}
At line 7, when we build the type for AddConst in
lookup_template_class_1, the resulting type is the enum FwdEnum. This
confuses lookup_template_class_1 near the if below, wrongly making it
taking the branch and thus calling tsubst_enum while it shouldn't:
if (TREE_CODE (t) == ENUMERAL_TYPE && !is_dependent_type)
/* Now that the type has been registered on the instantiations
list, we set up the enumerators. Because the enumeration
constants may involve the enumeration type itself, we make
sure to register the type first, and then create the
constants. That way, doing tsubst_expr for the enumeration
constants won't result in recursive calls here; we'll find
the instantiation and exit above. */
tsubst_enum (template_type, t, arglist);
Before the alias template feature, the only reason why TREE_CODE (t)
== ENUMERAL_TYPE would be true is when lookup_template_class_1 is
called for an enum that is a member of a class template. But that
condition can be also true for an alias template instantiation.
So I guess that condition should be changed to TREE_CODE
(template_type) == ENUMERAL_TYPE, to specifically detect the member
enum of a class template case. Note that for the alias template
instantiation case above, template_type points to a TEMPLATE_TYPE_PARM
which name is AddConst.
This is what the patchlet below does.
Bootstrapped and tested on x86_64-unknown-linux-gnu against trunk.
gcc/cp/
* pt.c (lookup_template_class_1): Look at the type of the
potential member enum of class template to determine if we are
actually substituting into a member enum of class template.
gcc/testsuite/
* g++.dg/cpp0x/alias-decl-27.C: New test.
Added:
trunk/gcc/testsuite/g++.dg/cpp0x/alias-decl-27.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog
[Bug c++/54466] [C++11] Recursive Type Alias, Member Function Pointer, Segmentation Fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54466 Dodji Seketeli changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #11 from Dodji Seketeli 2012-11-13 16:09:27 UTC --- Fixed in trunk (4.8).
[Bug c++/54466] [C++11] Recursive Type Alias, Member Function Pointer, Segmentation Fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54466
--- Comment #10 from Dodji Seketeli 2012-11-13
16:07:50 UTC ---
Author: dodji
Date: Tue Nov 13 16:07:39 2012
New Revision: 193479
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193479
Log:
PR c++/54466 - ICE with alias template which type-id is const qualified
Consider this short example:
template
struct X { };
template
using Y = const X;
using Z = Y;
G++ crashes in lookup_class_template_1 while trying to build the alias
template instantiation Y.
I think this is indirectly due to the fact that that
lookup_class_template_1 can now yield a const qualified type like
'const X'.
As a consequence, the code in lookup_template_class_1 that was trying
to access the TYPE_STUB_DECL field of the result of
lookup_template_class_1 should now be adjusted to access the
TYPE_STUB_DECL of the main variant of the resulting type instead (and
that is TYPE_MAIN_DECL); because qualified types (constructed with
build_qualified_type) have their TYPE_STUB_DECL set to NULL.
Fixed thus and tested on x86_64-unknown-linux-gnu against trunk.
gcc/cp
PR c++/54466
* pt.c (lookup_template_class_1): TYPE_STUB_DECL should be
accessed on the main variant of the type.
gcc/testsuite/
* g++.dg/cpp0x/alias-decl-26.C: New test file.
In the example of this patch, g++ crashes when trying to build the
alias template Y
[Bug c++/54955] alignas example in gcc 4.8 changes.html won't compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54955 Dodji Seketeli changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #7 from Dodji Seketeli 2012-10-31 09:01:49 UTC --- This should be fixed in trunk (4.8)
[Bug c++/54955] alignas example in gcc 4.8 changes.html won't compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54955 --- Comment #6 from Dodji Seketeli 2012-10-31 08:55:51 UTC --- Author: dodji Date: Wed Oct 31 08:55:43 2012 New Revision: 193029 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193029 Log: PR c++/54955 - Fail to parse alignas expr at the beginning of a declaration In this PR, g++ embarrassingly fails to parse the simple alignas expression below: alignas(double) int f; even though the simple-declaration production in Clause 7 suggests otherwise. Fixed thus and tested on x86_64-unknown-linux-gnu against trunk. gcc/cp PR c++/54955 * parser.c (cp_nth_tokens_can_be_std_attribute_p): Recognize the 'Alignas' keyword as the beginning of a c++11 attribute specifier. Update the comment of the function. (cp_next_tokens_can_be_gnu_attribute_p): Update the comment of the function. gcc/testsuite/ PR c++/54955 * g++.dg/cpp0x/gen-attrs-48-2.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp0x/gen-attrs-48-2.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog
[Bug c++/54875] Forward declare enums cannot be used as a template argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54875 Dodji Seketeli changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-10-26 AssignedTo|unassigned at gcc dot |dodji at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1
[Bug c++/54466] [C++11] Recursive Type Alias, Member Function Pointer, Segmentation Fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54466 Dodji Seketeli changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |dodji at gcc dot gnu.org |gnu.org |
[Bug c++/54955] alignas example in gcc 4.8 changes.html won't compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54955 Dodji Seketeli changed: What|Removed |Added Status|NEW |ASSIGNED
[Bug c++/53540] C++11: using fails to be equivalent to typedef
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53540 Dodji Seketeli changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #9 from Dodji Seketeli 2012-10-10 10:57:38 UTC --- Fixed in trunk (4.8)
[Bug c++/53540] C++11: using fails to be equivalent to typedef
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53540 --- Comment #8 from Dodji Seketeli 2012-10-10 10:44:02 UTC --- Author: dodji Date: Wed Oct 10 10:43:53 2012 New Revision: 192304 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=192304 Log: PR c++/53540 - using fails to be equivalent to typedef In the example of this problem report, during the substituting of int into 'function', tsubst_aggr_type fails for the alias ctxt1. This is because TYPE_TEMPLATE_INFO looks for the TEMPLATE_INFO of the ctxt1 alias at the wrong place and was wrongly finding it to be NULL. Namely, it was looking for it in the DECL_TEMPLATE_INFO of the declaration of the type -- as if ctxt1 was an alias template specialization -- rather than looking for it in its CLASSTYPE_TEMPLATE_INFO. Fixed thus. The other hunks of the patch are a cleanup to make a better use of alias_template_specialization_p. Bootstrapped and tested on x86_64-unknown-linux-gnu against trunk. gcc/cp * cp-tree.h (TYPE_TEMPLATE_INFO): For an alias that is not an instance of alias template, don't look for its TEMPLATE_INFO in its declaration. (alias_template_specialization_p): Take const_tree. * pt.c (alias_template_specialization_p): Take a const_tree. Don't call primary_template_instantiation_p. (primary_template_instantiation_p): Call alias_template_specialization_p. gcc/testsuite/ * g++.dg/cpp0x/alias-decl-24.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp0x/alias-decl-24.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/54860] [4.8 Regression]: build fails when configuring libgfortran due to recent "attribute" changes in core gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54860 --- Comment #18 from Dodji Seketeli 2012-10-10 10:25:13 UTC --- Author: dodji Date: Wed Oct 10 10:25:03 2012 New Revision: 192301 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=192301 Log: PR middle-end/54860 - Make sure attributes hash table is created On targets cris-elf, alpha and sparc (for instance) it can happen that the attribute_tables variable is empty for fortran. Thus register_scoped_attributes (called by init_attributes) won't call register_scoped_attributes, so the hash table member of scoped_attributes is not created. Later when we try to e.g, lookup an attribute by calling lookup_scoped_attribute_spec, that NULL member hash table comes to byte us as htab_find_with_hash crashes. This patch fixes this by ensuring in register_scoped_attributes that the hash table is created. Tested on cris-elf, x86_64-unknown-linux-gnu against trunk and some commenters on the bug bootstrapped it on alpha and sparc. gcc/ * attribs.c (register_scoped_attributes): Ensure the attribute hash table is created. Modified: trunk/gcc/ChangeLog trunk/gcc/attribs.c
[Bug middle-end/54860] [4.8 Regression]: build fails when configuring libgfortran due to recent "attribute" changes in core gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54860 --- Comment #9 from Dodji Seketeli 2012-10-09 14:52:24 UTC --- Created attachment 28400 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28400 Candidate fix patch Guys, could you please test this patch on your trees to see if it fixes the issue for you? I am testing it on my side. Thank you in advance, and sorry for the inconvenience.
[Bug middle-end/54860] [4.8 Regression]: build fails on cris-elf configuring libgfortran due to recent "attribute" changes in core gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54860 Dodji Seketeli changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-10-08 AssignedTo|unassigned at gcc dot |dodji at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #1 from Dodji Seketeli 2012-10-08 21:58:09 UTC --- I am looking at it.
[Bug c++/53528] Support C++11 generalized attributes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53528 Dodji Seketeli changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #8 from Dodji Seketeli 2012-10-08 12:10:26 UTC --- Applied to trunk (4.8).
[Bug c++/53528] Support C++11 generalized attributes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53528 --- Comment #6 from Dodji Seketeli 2012-10-08 09:29:13 UTC --- Author: dodji Date: Mon Oct 8 09:29:05 2012 New Revision: 192199 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=192199 Log: PR c++/53528 C++11 attribute support This patch implements the c++-11 generalized attributes, described in the N2761 paper[1]. The idea is to modify the front-end to accept the new attribute syntax (including alignas expressions) and to build an internal representation similar to the one we already have for GNU attributes. This lets us re-use our existing GNU attribute mechanisms to support the generalized c++11 attributes. The patch does change the existing internal representation to support scoped attribute (aka attributes with namespaces), which is a concept that doesn't exist in GNU attributes. I have thus put all existing GNU extension attributes into the "gnu" namespace. For instance, in C++-11, the "unused" attribute would be represented as "[[gnu::unused]]". Because there is no syntax for scoped attributes in C, writting "__attribute__((unused))" unconditionnally refers to the "unused" attribute in the "gnu" namespace. Note that this patch follows a conservative understanding of the specification by disallowing attributes appertaining to types, unless they apply to a type definition. Tested on x86_64-unknown-linux-gnu and powerpc64-unknown-linux-gnu. [1]: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2761.pdf gcc/ * plugin.h (register_scoped_attributes): Declare new function. * tree.h (enu attribute_flags::ATTR_FLAG_CXX_11): New flag. (lookup_scoped_attribute_spec, cxx_11_attribute_p) (get_attribute_name, get_attribute_namespace): Declare new functions. (struct attribute_spec): Remove const qualifier from the members. * tree.c (comp_type_attributes, private_lookup_attribute) (lookup_ident_attribute, remove_attribute, merge_attribute) (attribute_hash_list, attribute_list_contained): Use get_attribute_name. * attribs.c (decl_attributes): Don't crash on error_mark_node. Forbid c++11 attributes appertaining to type-specifiers. (attribute_hash): Remove global variable. (attributes_table): New global variable. (find_attribute_namespace, register_scoped_attribute): New static functions. (register_scoped_attributes, lookup_scoped_attribute_spec) (cxx11_attribute_p, get_attribute_name, get_attribute_namespace): New public functions. (init_attributes): Register all the GNU attributes into the "gnu" namespace. (register_attribute): Use register_scoped_attribute to register the attribute into the "gnu" namespace. (lookup_attribute_spec): Use lookup_scoped_attribute_spec to lookup the attribute in the "gnu" namespace. (decl_attributes): Use new get_attribute_namespace and lookup_scoped_attribute_spec to consider attribute namespaces when looking up attributes. When operating in c++-11 mode, pass flag ATTR_FLAG_CXX11 to the spec handler. gcc/c-family/ * c-common.h (bitfield_p, cxx_fundamental_alignment_p): Declare new functions. * c-common.c (check_cxx_fundamental_alignment_constraints): New static function. (handle_aligned_attribute): In choose strictest alignment among many. Use new check_cxx_fundamental_alignment_constraints. (handle_transparent_union_attribute): In c++11 attribute syntax, don't look through typedefs. gcc/cp/ * cp-tree.h (enum cpp0x_warn_str::CPP0X_ATTRIBUTES): New member. (enum cp_decl_spec::ds_std_attribute): New enumerator. (struct cp_decl_specifier_seq::std_attributes): New field. (cxx_alignas_expr, warn_misplaced_attr_for_class_type): Declare new functions. (check_tag_decl): Take an extra parameter for explicit instantiations. * decl.c (warn_misplaced_attr_for_class_type): Extract from ... (check_tag_decl): ... here. Add check for c++11 attributes being applied to an explicit instantiation. Take an extra parameter for explicit instantiations. (grokdeclarator): Make sure a c++11 attribute after an array declarator appertains to the array, an attribute after a function declarator appertains to the function type, an attribute after a declarator-id appertains to the entity being declared, and an attribute after a pointer declarator appertains to the pointer. * decl2.c (is_late_template_attribute): Use get_attribute_name. * error.c (maybe_warn_cpp0x): Support CPP0X_GENERALIZED_ATTRIBUTES. * parser.c (cp_next_tokens_can_be_attribute_p) (cp_next_tokens_can_be_gnu_attribute_p) (cp_next_tokens_can_be_std_attribute_p) (cp_nth_tokens_can_be_attribute_p) (cp_nth_tokens_can_be_gnu_attribute_p) (cp_nth_tokens_can_be_std_attribute_p) (cp_parser_gnu_attribute_list, cp_parser_std_a
[Bug c++/54372] __attribute__((unused)) doesn't work with unused local typedef in template function.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54372 Dodji Seketeli changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #8 from Dodji Seketeli 2012-09-28 13:35:49 UTC --- Fixed in trunk (4.8)
[Bug c++/54372] __attribute__((unused)) doesn't work with unused local typedef in template function.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54372 --- Comment #7 from Dodji Seketeli 2012-09-28 13:32:52 UTC --- Author: dodji Date: Fri Sep 28 13:32:41 2012 New Revision: 191830 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=191830 Log: PR c++/54372 - unused attribute inactive on dependant entities In the example of this patch, gcc/g++ invoked with -Wunused-local-typedefs warns on dependant entities even when those are decorated with the 'unused' attribute. This is because in cplus_decl_attributes, save_template_attributes makes so that the 'unused' attribute is applied to its appertaining entity only at instantiation time. But then at parsing time maybe_warn_unused_local_typedefs checks for TREE_USED before warning. This patch applies the 'unused' attribute at compilation time. Tested on x86_64-unknown-linux-gnu against trunk. gcc/cp/ * decl2.c (is_late_template_attribute): "unused" attribute is to be applied at compile time. gcc/testsuite/ * c-c++-common/Wunused-local-typedefs-2.c: New test. Added: trunk/gcc/testsuite/c-c++-common/Wunused-local-typedefs-2.c Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl2.c trunk/gcc/testsuite/ChangeLog
[Bug c++/29028] No warning about unused names introduced with using declarations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29028 Dodji Seketeli changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #5 from Dodji Seketeli 2012-09-28 13:01:56 UTC --- Fixed in trunk (4.8)
[Bug c++/29028] No warning about unused names introduced with using declarations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29028 --- Comment #4 from Dodji Seketeli 2012-09-28 12:51:42 UTC --- Author: dodji Date: Fri Sep 28 12:51:30 2012 New Revision: 191829 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=191829 Log: PR c++/29028 - Missed unused warning on using declaration In the example of the patch, g++ fails to warn that the variable N::i (introduced via a using declaration) is unused. This is because as we want to emit the warning in poplevel, when we walk the local bindings returned by getdecls, we forget that a VAR_DECL introduced by a using declaration is represented by a TREE_LIST which TREE_VALUE is the VAR_DECL, and we wrongly look for a bare VAR_DECL. Fixed thus and tested on x86_64-unknown-linux-gnu against trunk. gcc/cp/ * decl.c (poplevel): Do not forget that some local bindings are represented by a TREE_LIST. gcc/testsuite/ * g++.dg/warn/Wunused-var-18.C: New test. Added: trunk/gcc/testsuite/g++.dg/warn/Wunused-var-18.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog
[Bug c++/53551] -Wunused-local-typedefs misses uses
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53551 Dodji Seketeli changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #6 from Dodji Seketeli 2012-09-28 12:32:04 UTC --- Fixed in trunk (4.8)
[Bug c++/53551] -Wunused-local-typedefs misses uses
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53551 --- Comment #5 from Dodji Seketeli 2012-09-28 12:21:49 UTC --- Author: dodji Date: Fri Sep 28 12:21:33 2012 New Revision: 191828 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=191828 Log: PR c++/53551 - -Wunused-local-typedefs misses uses We don't record the use of a typedef when it's used through a typename. Fixed thus. Tested on x86_64-unknown-linux-gnu against trunk. gcc/cp/ * decl.c (make_typename_type): Record the use of typedefs. gcc/testsuite/ * g++.dg/warn/Wunused-local-typedefs-2.C: New test. Added: trunk/gcc/testsuite/g++.dg/warn/Wunused-local-typedefs-2.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog
[Bug bootstrap/54719] New: Bootstrap stuck in stage1 with message "checking for compiler with PCH support"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54719 Bug #: 54719 Summary: Bootstrap stuck in stage1 with message "checking for compiler with PCH support" Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: do...@gcc.gnu.org Bootstrap fails when running with MALLOC_CHECK_=3. The configure (actually config.log) of stage 1 in x86_64-unknown-linux-gnu/libstdc++-v3 says: configure:15104: checking for compiler with PCH support And it gets stuck there for ever. It seems like the PCH support is broken somehow. To reproduce: $ cat conftest.h: >8<-- extern int foo(); >8<-- $ cat conftest.cc: >8<-- #include "conftest.h" >8<-- $ export MALLOC_CHECK_=3 $ cc1plus -quiet conftest.h --output-pch=conftest.h.gch $ cc1plus -quiet conftest.cc The last command hangs for ever. gdb says: Program received signal SIGSEGV, Segmentation fault. 0x00306e07a30a in mem2chunk_check () from /lib64/libc.so.6 Missing separate debuginfos, use: debuginfo-install glibc-2.15-56.fc17.x86_64 gmp-5.0.2-6.fc17.x86_64 libgcc-4.7.0-5.fc17.x86_64 libmpc-0.9-2.fc17.2.x86_64 libstdc++-4.7.0-5.fc17.x86_64 mpfr-3.1.0-2.fc17.x86_64 (gdb) bt #0 0x00306e07a30a in mem2chunk_check () from /lib64/libc.so.6 #1 0x00306e07e276 in free_check () from /lib64/libc.so.6 #2 0x01238d31 in location_adhoc_data_fini (set=0x1000176000) at /home/dodji/devel/git/gcc/bootstrap/libcpp/line-map.c:164 #3 0x00bcc803 in toplev_main (argc=4, argv=0x7fffe398) at /home/dodji/devel/git/gcc/bootstrap/gcc/toplev.c:1949 #4 0x0120b348 in main (argc=4, argv=0x7fffe398) at /home/dodji/devel/git/gcc/bootstrap/gcc/main.c:36 (gdb) The issues is that after loading the pch file, toplev_main invokes location_adhoc_data_fini which tries to free stuff in the location_adhoc_data_map member of the instance of line_maps. But these pointers have been 're-set' by the loading the pch file, in c_common_write_pch, AFAIU. And that triggers a sigsev, and then the process hangs. If that data is to be saved to disk as part of the PCH, why isn't it allocated in GCC memory? The other issue I don't quite understand is, why is the process hanging instead of just exiting after the sigsev?
[Bug c++/54401] Missing diagnostics about type-alias at class scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54401 Dodji Seketeli changed: What|Removed |Added Status|NEW |ASSIGNED CC||dodji at gcc dot gnu.org AssignedTo|unassigned at gcc dot |dodji at gcc dot gnu.org |gnu.org |
[Bug c++/29028] No warning about unused names introduced with using declarations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29028 Dodji Seketeli changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |dodji at gcc dot gnu.org |gnu.org |
[Bug c++/53551] -Wunused-local-typedefs misses uses
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53551 --- Comment #4 from Dodji Seketeli 2012-09-20 20:23:35 UTC --- A candidate patch was sent to http://gcc.gnu.org/ml/gcc-patches/2012-09/msg01492.html
[Bug c++/53551] -Wunused-local-typedefs misses uses
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53551 Dodji Seketeli changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-09-20 AssignedTo|unassigned at gcc dot |dodji at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #3 from Dodji Seketeli 2012-09-20 13:46:59 UTC --- Yes, I am testing a patch for this.
[Bug c++/54372] __attribute__((unused)) doesn't work with unused local typedef in template function.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54372
Dodji Seketeli changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #3 from Dodji Seketeli 2012-09-20
11:27:19 UTC ---
The 'unused' attribute is applied to its appertaining entity only at
instantiation time. As a result, TREE_USED is not set on the entity before
instantiation.
But then maybe_warn_unused_local_typedefs checks for TREE_USED at compile time,
and wrongly emits the warning.
I am testing this patch that tests for the syntactic presence of the unused
attribute:
diff --git a/gcc/c-family/c-common.c b/gcc/c-family/c-common.c
index 6de2f1c..36c4aa6 100644
--- a/gcc/c-family/c-common.c
+++ b/gcc/c-family/c-common.c
@@ -10899,7 +10899,8 @@ maybe_warn_unused_local_typedefs (void)
&& errorcount == unused_local_typedefs_warn_count)
{
FOR_EACH_VEC_ELT (tree, l->local_typedefs, i, decl)
- if (!TREE_USED (decl))
+ if (!TREE_USED (decl)
+ && !lookup_attribute_spec (get_identifier ("unused")))
warning_at (DECL_SOURCE_LOCATION (decl),
OPT_Wunused_local_typedefs,
"typedef %qD locally defined but not used", decl);
[Bug preprocessor/53469] #pragma GCC diagnostic works, but using _Pragma doesn't for -Wunused-local-typedefs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53469 Dodji Seketeli changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Dodji Seketeli 2012-08-27 15:45:33 UTC --- Fixed in trunk (4.8).
[Bug preprocessor/53469] #pragma GCC diagnostic works, but using _Pragma doesn't for -Wunused-local-typedefs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53469
--- Comment #2 from Dodji Seketeli 2012-08-27
15:41:44 UTC ---
Author: dodji
Date: Mon Aug 27 15:41:38 2012
New Revision: 190714
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190714
Log:
PR preprocessor/53469 - argument tokens of _Pragma miss virtual location
Consider this short test snippet:
-8---
#define STRINGIFY(x) #x
#define TEST(x) \
_Pragma(STRINGIFY(GCC diagnostic ignored "-Wunused-local-typedefs")) \
typedef int myint;
void bar ()
{
TEST(myint)
}
-8---
The _Pragma is effectively ignored, and compiling with
-Wunused-local-typedefs warns on the local typedef, even though the
pragma should have prevented the warning to be emitted.
This is because when the preprocessor sees the _Pragma operator and
then goes to handle the first token ('GCC' here) that makes up its
operands, it retains the spelling location of that token, not its
virtual location.
Later when diagnostic_report_diagnostic is called to emit the warning
(or ignore it because of the pragma), it compares the location of the
first operand of the pragma with the location of the unused location,
(by calling linemap_location_before_p) and that comparison fails
because in this case, both locations should be virtual.
This patch fixes the issue by teaching the pragma handling to use
virtual locations.
Bootstrapped and tested on x86_64-unknown-linux-gnu against trunk.
libcpp/
PR preprocessor/53469
* directives.c (do_pragma): Use the virtual location for the
pragma token, instead of its spelling location.
gcc/testsuite/
PR preprocessor/53469
* gcc.dg/cpp/_Pragma7.c: New test case.
Added:
trunk/gcc/testsuite/gcc.dg/cpp/_Pragma7.c
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/libcpp/ChangeLog
trunk/libcpp/directives.c
[Bug c++/53609] Wrong variadic template pack expansion in alias template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53609 Dodji Seketeli changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |dodji at gcc dot gnu.org |gnu.org |
[Bug c++/53540] C++11: using fails to be equivalent to typedef
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53540 Dodji Seketeli changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |dodji at gcc dot gnu.org |gnu.org | --- Comment #3 from Dodji Seketeli 2012-08-16 19:09:39 UTC --- Sorry, I am getting to this just now.
[Bug c++/53528] Support C++11 generalized attributes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53528 --- Comment #4 from Dodji Seketeli 2012-07-26 15:27:17 UTC --- A candidate implementation patch for this has been posted to http://gcc.gnu.org/ml/gcc-patches/2012-07/msg01348.html @Joseph: Thank you for the note. I believe the patch handles this, unless I have forgotten things. @Michal Malecki / Jonathan Wakely The scoped attributes syntax [[gnu::priority(200)]] is now supported. The patch has put all the GNU attributes in the "gnu" namespace by default. So now whenever one writes __attribute__((priority(200))), the priority attribute is looked up from or put into the "gnu" namespace. We'll see what comes out of the discussion that arises from the patch submission.
[Bug preprocessor/53463] [4.8 Regression]: system header not recognized, yielding warnings about long long preprocessor constant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53463
--- Comment #6 from Dodji Seketeli 2012-06-04
19:20:16 UTC ---
Author: dodji
Date: Mon Jun 4 19:19:58 2012
New Revision: 188203
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188203
Log:
PR preprocessor/53463 - Fix system header detection for built-in macro tokens
The location for a built-in macro token is BUILTIN_LOCATION. When we
see that location value, we cannot know if that token was used in a
system header or not. And that can trigger some unwanted warnings on
e.g, the use of __LONG_LONG_MAX__ built-in macro in system headers
when we compile with -pedantic, like in the test case accompanying
this patch.
In that case, I think we ought to step-up to see where the built-in
macro has been expanded, until we see a location that is not for a
built-in macro. Then we can check if the resulting location is in a
system header or not.
Now that we step up to the location of first non-built-in-macro token,
it appeared that for
testsuite/c-c++-common/dfp/convert-int-saturate.c, G++ then fails to
emit the warning in:
volatile unsigned int usi;
int
main ()
{
usi = DEC32_MAX; /* { dg-warning "overflow in implicit constant
conversion" } */
...
}
Because DEC32_MAX is defined in the system header float.h as a
built-in macro:
#define DEC32_MAX__DEC32_MAX__
And during the parsing of the assignment expression that should have
led to the warning above, input_location is set to the location for
the DEC32_MAX, which is actually the location for the built-in
__DECL32_MAX_EXP.
A possible fix is to use the location of the "=" operator as the
default location for assignment expressions. This is what the patch
does.
I had to adjust a couple of tests to arrange for this.
Bootstrapped and tested on x86_64-unknown-linux-gnu against trunk.
libcpp/
PR preprocessor/53463
* line-map.c (linemap_location_in_system_header_p): For built-in
macro tokens, check the first expansion point location for that is
not for a token coming from a built-in macro.
gcc/cp/
PR preprocessor/53463
* parser.c (cp_parser_assignment_expression): Use the location
for the LHS as the default location for the expression.
gcc/testsuite/
PR preprocessor/53463
* g++.dg/cpp/limits.C: New test.
* g++.dg/parse/error19.C: Adjust.
* g++.dg/warn/Wconversion-real-integer2.C: Likewise.
* g++.dg/warn/pr35635.C: Likewise.
* g++.old-deja/g++.pt/assign1.C: Likewise.
Added:
trunk/gcc/testsuite/g++.dg/cpp/limits.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/parse/error19.C
trunk/gcc/testsuite/g++.dg/warn/Wconversion-real-integer2.C
trunk/gcc/testsuite/g++.dg/warn/pr35635.C
trunk/gcc/testsuite/g++.old-deja/g++.pt/assign1.C
trunk/libcpp/ChangeLog
trunk/libcpp/line-map.c
[Bug c++/53528] Support C++11 generalized attributes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53528 Dodji Seketeli changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-05-30 AssignedTo|unassigned at gcc dot |dodji at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1
[Bug c++/53528] New: Support C++11 generalized attributes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53528 Bug #: 53528 Summary: Support C++11 generalized attributes Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: do...@gcc.gnu.org G++ should support the generalized attributes feature presented in the N2761 paper at http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2761.pdf.
[Bug preprocessor/53469] #pragma GCC diagnostic works, but using _Pragma doesn't for -Wunused-local-typedefs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53469 --- Comment #1 from Dodji Seketeli 2012-05-29 10:20:52 UTC --- I candidate fix was proposed to http://gcc.gnu.org/ml/gcc-patches/2012-05/msg01899.html
[Bug preprocessor/53229] Fix diagnostics location when pasting tokens
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53229 Dodji Seketeli changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Dodji Seketeli 2012-05-29 10:03:03 UTC --- Fixed in trunk (4.8)
[Bug bootstrap/53459] ../../work/libcpp/lex.c:593:18: error: typedef 'check_count' locally defined but not used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53459 Dodji Seketeli changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #7 from Dodji Seketeli 2012-05-29 09:49:42 UTC --- Hopefully properly fixed for 4.8 now.
[Bug bootstrap/53459] ../../work/libcpp/lex.c:593:18: error: typedef 'check_count' locally defined but not used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53459 --- Comment #6 from Dodji Seketeli 2012-05-29 09:42:44 UTC --- Author: dodji Date: Tue May 29 09:42:39 2012 New Revision: 187947 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187947 Log: PR bootstrap/53459 - unused local typedef when building on altivec PR bootstrap/53459 * lex.c (search_line_fast): Avoid unused local typedefs to simulate a static assertion. Modified: trunk/libcpp/ChangeLog trunk/libcpp/lex.c
[Bug preprocessor/53229] Fix diagnostics location when pasting tokens
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53229
--- Comment #2 from Dodji Seketeli 2012-05-29
09:36:34 UTC ---
Author: dodji
Date: Tue May 29 09:36:29 2012
New Revision: 187945
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187945
Log:
PR preprocessor/53229 - Fix diagnostics location when pasting tokens
As stated in the audit trail of this problem report, consider this
test case:
$ cat test.c
1struct x {
2 int i;
3};
4struct x x;
5
6#define TEST(X) x.##X
7
8void foo (void)
9{
10 TEST(i) = 0;
11}
$
$ cc1 -quiet test.c
test.c: In function 'foo':
test.c:10:1: error: pasting "." and "i" does not give a valid preprocessing
token
TEST(i) = 0;
^
$
So, when pasting tokens, the error diagnostic uses the global and
imprecise input_location variable, leading to an imprecise output.
To properly fix this, I think libcpp should keep the token of the
pasting operator '##', instead of representing it with flag on the LHS
operand's token. That way, it could use its location. Doing that
would be quite intrusive though. So this patch just uses the location
of the LHS of the pasting operator, for now. It's IMHO better than
the current situation.
The patch makes paste_tokens take a location parameter that is used in
the diagnostics. This change can still be useful later when we can
use the location of the pasting operator, because paste_tokens will
just be passed the new, more precise location.
Incidentally, it appeared that when getting tokens from within
preprocessor directives (like what is done in gcc.dg/cpp/paste12.c),
with -ftrack-macro-expansion disabled, the location of the expansion
point of macros was being lost because
cpp_reader::set_invocation_location wasn't being properly set. It's
because when cpp_get_token_1 calls enter_macro_context, there is a
little period of time between the beginning of that later function and
when the macro is really pushed (and thus when the macro is really
expanded) where we wrongly consider that we are not expanding the
macro because macro_of_context is still NULL. In that period of time,
in the occurrences of indirect recursive calls to cpp_get_token_1,
this later function wrongly sets cpp_reader::invocation_location
because cpp_reader::set_invocation_location is not being properly set.
To avoid that confusion the patch does away with
cpp_reader::set_invocation_location and introduces a new flag
cpp_reader::about_to_expand_macro_p that is set in the small time
interval exposed earlier. A new in_macro_expansion_p is introduced as
well, so that cpp_get_token_1 can now accurately detect when we are in
the process of expanding a macro, and thus correctly collect the
location of the expansion point.
People seem to like screenshots.
Thus, after the patch, we now have:
$ cc1 -quiet test.c
test.c: In function 'foo':
test.c:6:18: error: pasting "." and "i" does not give a valid preprocessing
token
#define TEST(X) x.##X
^
test.c:10:3: note: in expansion of macro 'TEST'
TEST(i) = 0;
^
$
Bootstrapped and tested on x86_64-unknown-linux-gnu against trunk.
libcpp/
PR preprocessor/53229
* internal.h (cpp_reader::set_invocation_location): Remove.
(cpp_reader::about_to_expand_macro_p): New member flag.
* directives.c (do_pragma): Remove Kludge as
pfile->set_invocation_location is no more.
* macro.c (cpp_get_token_1): Do away with the use of
cpp_reader::set_invocation_location. Just collect the macro
expansion point when we are about to expand the top-most macro.
Do not override cpp_reader::about_to_expand_macro_p.
This fixes gcc.dg/cpp/paste12.c by making get_token_no_padding
properly handle locations of expansion points.
(cpp_get_token_with_location): Adjust, as
cpp_reader::set_invocation_location is no more.
(paste_tokens): Take a virtual location parameter for
the LHS of the pasting operator. Use it in diagnostics. Update
comments.
(paste_all_tokens): Tighten the assert. Propagate the location of
the expansion point when no virtual locations are available.
Pass the virtual location to paste_tokens.
(in_macro_expansion_p): New static function.
(enter_macro_context): Set the cpp_reader::about_to_expand_macro_p
flag until we really start expanding the macro.
gcc/testsuite/
PR preprocessor/53229
* gcc.dg/cpp/paste6.c: Force to run without
-ftrack-macro-expansion.
* gcc.dg/cpp/paste8.c: Likewise.
* gcc.dg/cpp/paste8-2.c: New test, like paste8.c but run with
-ftrack-macro-expansion.
* gcc.dg/cpp/paste12.c: Force to run without
-ftrack-macro-expansion.
* gcc.dg/cpp/paste12-2.c: New test, like paste12.c but run with
-ftrack-macro-expansion.
* gcc.dg/cpp/paste13.c: Likewise.
* gcc.dg/cpp/paste14.c: Likewise.
* gcc.dg/cpp/paste14-2.c: New test, like pas
[Bug c++/53469] #pragma GCC diagnostic works, but using _Pragma doesn't for -Wunused-local-typedefs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53469 Dodji Seketeli changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-05-25 AssignedTo|unassigned at gcc dot |dodji at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1
[Bug preprocessor/53463] [4.8 Regression]: system header not recognized, yielding warnings about long long preprocessor constant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53463 --- Comment #3 from Dodji Seketeli 2012-05-25 09:58:42 UTC --- It seems to me that this issue is dealt with by the patch I have proposed at http://gcc.gnu.org/ml/gcc-patches/2012-05/msg01389.html. The discussion on that patch is still going on. Could you please try that patch and reply to the discussion there to say if it address the issue on your target? Thanks.
[Bug preprocessor/53463] [4.8 Regression]: system header not recognized, yielding warnings about long long preprocessor constant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53463 Dodji Seketeli changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-05-25 AssignedTo|unassigned at gcc dot |dodji at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1
[Bug bootstrap/53459] ../../work/libcpp/lex.c:593:18: error: typedef 'check_count' locally defined but not used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53459 --- Comment #3 from Dodji Seketeli 2012-05-24 21:06:24 UTC --- Fixed in trunk (4.8).
[Bug bootstrap/53459] ../../work/libcpp/lex.c:593:18: error: typedef 'check_count' locally defined but not used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53459 --- Comment #2 from Dodji Seketeli 2012-05-24 21:05:55 UTC --- Author: dodji Date: Thu May 24 21:05:49 2012 New Revision: 187853 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187853 Log: PR bootstrap/53459 - unused local typedef when building on altivec libcpp/ PR bootstrap/53459 * lex.c (search_line_fast): Remove unused typedef check_count. Modified: trunk/libcpp/ChangeLog trunk/libcpp/lex.c --- Comment #3 from Dodji Seketeli 2012-05-24 21:06:24 UTC --- Fixed in trunk (4.8).
[Bug bootstrap/53459] ../../work/libcpp/lex.c:593:18: error: typedef 'check_count' locally defined but not used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53459 --- Comment #2 from Dodji Seketeli 2012-05-24 21:05:55 UTC --- Author: dodji Date: Thu May 24 21:05:49 2012 New Revision: 187853 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187853 Log: PR bootstrap/53459 - unused local typedef when building on altivec libcpp/ PR bootstrap/53459 * lex.c (search_line_fast): Remove unused typedef check_count. Modified: trunk/libcpp/ChangeLog trunk/libcpp/lex.c
[Bug bootstrap/53459] ../../work/libcpp/lex.c:593:18: error: typedef 'check_count' locally defined but not used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53459 Dodji Seketeli changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-05-24 AssignedTo|unassigned at gcc dot |dodji at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1
[Bug c++/53322] Wunused-local-typedefs is not enabled by Wall or Wunused
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53322 Dodji Seketeli changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Dodji Seketeli 2012-05-24 18:06:09 UTC --- Fixed in trunk (4.8).
