[Bug preprocessor/97498] #pragma GCC diagnostic ignored "-Wunused-function" inconsistent

[lhyatt at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97498

Lewis Hyatt  changed:

   What|Removed |Added

 CC||lhyatt at gmail dot com

--- Comment #8 from Lewis Hyatt  ---
(In reply to Martin Liška from comment #7)

> We actually speak about 2 modified lines, so can we backport it, please?

It will work fine for any of 10, 11, 12. I'll ask for approval for that on
gcc-patches then.

[Bug libstdc++/54185] [4.7/4.8 Regression] condition_variable not properly destructed

[lhyatt at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54185

Lewis Hyatt  changed:

   What|Removed |Added

 CC||lhyatt at gmail dot com

--- Comment #14 from Lewis Hyatt  ---
Created attachment 49061
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49061&action=edit
Fix for random pthread_create() failures

Hello-

I have problems with the test case for this bug
(libstdc++-v3/testsuite/30_threads/condition_variable/54185.cc) failing
randomly. It happens more often with parallel make, and especially if running
the testsuite as a whole more than once in parallel. On my system at least
(x86-64, Ubuntu 18), it seems that pthread_create() will return EAGAIN
sometimes in any loop like the one this testcase uses:

for(int i = 0; i != 1000; ++i) {pthread_create(...); pthread_join(...);}

If such a loop is running in 3 or more processes in parallel it happens more
than 50% of the time. I am not sure what global resource gets used up, it
happens even if ulimit -a shows nothing being limited like processes or memory.

The attached patch fixes the failures for me; if thread creation fails, it just
gives up and moves on to the next iteration instead. I had to convert the
cond->wait() to the predicate form since it becomes possible for the notify to
take place prior to all threads calling wait.

I can submit this to gcc-patches if it makes sense to you? Thanks...

-Lewis

[Bug other/86904] Column numbers ignore tab characters

[lhyatt at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86904

Lewis Hyatt  changed:

   What|Removed |Added

 CC||lhyatt at gmail dot com

--- Comment #5 from Lewis Hyatt  ---
Fixed for GCC 11, may I ask someone please to close the PR?

[Bug preprocessor/49973] Column numbers count multibyte characters as multiple columns

[lhyatt at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49973

--- Comment #23 from Lewis Hyatt  ---
Fixed for GCC 11, may I ask someone please to close the PR?

[Bug c/67224] UTF-8 support for identifier names in GCC

[lhyatt at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67224

--- Comment #35 from Lewis Hyatt  ---
(In reply to Lewis Hyatt from comment #34)
> (In reply to Eric Gallager from comment #33)
> > This is a big enough feature that it should probably get an entry in
> > gcc-10/changes.html
> 
> I emailed a suggested patch to that effect here:
> https://gcc.gnu.org/ml/gcc-patches/2020-01/msg01667.html. I can commit if it
> looks OK. Thanks!

With GCC 10 release imminent, would anyone be able to confirm it's OK to push
this to changes.html please? Thanks so much.
https://gcc.gnu.org/pipermail/gcc-patches/2020-April/544343.html

[Bug preprocessor/94168] [10 Regression] error: extended character § is not valid in an identifier since r10-3309-g7d112d6670a0e0e6

[lhyatt at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94168

--- Comment #2 from Lewis Hyatt  ---
(In reply to Martin Liška from comment #0)
> I see the following regression:
> 
> $ cat red.cc
> #ifdef WINDOWS
> §
> #endif
> 
> $ g++-9 red.cc -c
> $ g++ red.cc -c
> red.cc:2:1: error: extended character § is not valid in an identifier
> 2 | ��
>   | ^

The corrupted colorization in the diagnostics is a bug that I submitted a patch
for already. David prefers that fix to wait for GCC 11.

Regarding the behavior, if you replace the § with the equivalent UCN:

#ifdef WINDOWS
\u00A7
#endif

then you will get the same behavior with older GCC before my patch too. My
patch causes the UTF-8 to be interpreted as an identifier rather than a stray
token, hence it ends up with the same error.

As it happens, if you compile your test in C mode, it will succeed, because the
UTF-8 logic for C mode treats the invalid character as a stray token rather
than part of an identifier, then it gets compiled out fine. In C++, it is
rather a syntax error by design so it triggers this error. When switching to
UCN syntax, it is an error for both C and C++ so fails either way.

Looking at the relevant code in charset.c (_cpp_valid_ucn and _cpp_valid_utf8)
... I think it is probably just a matter of checking pfile->state.skipping in
more places. I made _cpp_valid_utf8 so as to preserve all the analogous
behavior of the existing _cpp_valid_ucn. It seems that _cpp_valid_ucn checks
pfile->state.skipping in some cases, like for $ in identifiers, but not for
others, such as the invalid character case.

I am happy to submit a patch to fix this, but I am not sure in what all cases
it is correct to skip the error. For instance, this code can be made to trigger
an error too, in C90 mode:

$ cat t.c
#ifdef WINDOWS
int \u00E4;
#endif

$ gcc-8 -c t.c -std=c90 -fextended-identifiers
t.c:2:5: warning: universal character names are only valid in C++ and C99
 int \u00E4;
 ^

That is because _cpp_valid_ucn doesn't check pfile->state.skipping for this
case either. I think, especially in C++, there are probably at least some cases
where an error should be triggered even in conditionally compiled code, but I
don't know enough off hand to say for sure.

FWIW, the below patch fixes the present issue, but it doesn't tackle equivalent
UCN behavior or fix the related issues... I just need some guidance as to the
expected behavior to do that.

-Lewis

diff --git a/libcpp/charset.c b/libcpp/charset.c
index d9281c5fb97..129f234349e 100644
--- a/libcpp/charset.c
+++ b/libcpp/charset.c
@@ -1260,7 +1260,7 @@ _cpp_valid_utf8 (cpp_reader *pfile,
 way).  In C, this byte rather becomes grammatically a separate
 token.  */

- if (CPP_OPTION (pfile, cplusplus))
+ if (!pfile->state.skipping && CPP_OPTION (pfile, cplusplus))
cpp_error (pfile, CPP_DL_ERROR,
   "extended character %.*s is not valid in an identifier",
   (int) (*pstr - base), base);
@@ -1273,7 +1273,7 @@ _cpp_valid_utf8 (cpp_reader *pfile,
  break;

case 2:
- if (identifier_pos == 1)
+ if (!pfile->state.skipping && identifier_pos == 1)
{
  /* This is treated the same way in C++ or C99 -- lexed as an
 identifier which is then invalid because an identifier is

[Bug c/67224] UTF-8 support for identifier names in GCC

[lhyatt at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67224

--- Comment #34 from Lewis Hyatt  ---
(In reply to Eric Gallager from comment #33)
> This is a big enough feature that it should probably get an entry in
> gcc-10/changes.html

I emailed a suggested patch to that effect here:
https://gcc.gnu.org/ml/gcc-patches/2020-01/msg01667.html. I can commit if it
looks OK. Thanks!

[Bug other/93067] diagnostics are not aware of -finput-charset

[lhyatt at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93067

--- Comment #1 from Lewis Hyatt  ---
Created attachment 47548
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47548&action=edit
testcases

[Bug other/93067] New: diagnostics are not aware of -finput-charset

[lhyatt at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93067

Bug ID: 93067
   Summary: diagnostics are not aware of -finput-charset
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lhyatt at gmail dot com
  Target Milestone: ---

Created attachment 47547
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47547&action=edit
Candidate patch

Hello-

When source lines are needed for diagnostics output, they are retrieved from
the source file by the fcache infrastructure in input.c, since libcpp has
generally already forgotten them already (plus not all front ends are using
libcpp). This infrastructure does not read the files in the same way as libcpp
does; in particular, it does not translate the encoding as requested by
-finput-charset, and it does not strip a UTF-8 BOM if present. The attached
patch adds this ability. My thinking in deciding how to do it was the
following:

- Use of -finput-charset is rare, and use of UTF-8 BOMs must be rarer still, so
this patch should try hard not to introduce any worse performance unless these
features are being used.

- It is desirable to reuse libcpp's encoding infrastructure from charset.c
rather than repeat it in input.c. (Notably, libcpp uses iconv but it also has
hand-coded routines for certain charsets to make sure they are available.)

- There is a performance degradation required in order to make use of libcpp
directly, because the input.c infrastructure only reads as much of the source
file as necessary, whereas libcpp interfaces require to read the entire file
into memory.

- It can't be quite as simple as just "only delegate to libcpp if
-finput-charset was specified", because the stripping of the UTF-8 BOM has to
happen with or without this option.

- So it seemed a reasonable compromise to me, if -finput-charset is specified,
then use libcpp to convert the file, otherwise, strip the BOM in input.c and
then process the file the same way it is done now. There's a little bit of
leakage of charset logic from libcpp this way, but it seems worthwhile, since
otherwise, diagnostics would always be reading the entire file into memory,
which is not a cost paid currently.

Hope that makes some sense. One thing I wasn't sure of, is what's the right way
to communicate to input.c that libcpp is being used to process the source
files. I added a global variable for this because I didn't see any other way to
do it without making drastic changes. This requires C-family and Fortran
front-ends, and any future libcpp users, to set the variable; basically it
makes explicit the fact that there's a single global cpp_reader object in use.
If there's a less-bad way to do it, please let me know... If the global
cpp_reader variable doesn't get set, then the behavior is the same as current.

Separate from the attached patch are two testcases that both fail before this
patch and pass after. I attached them gzipped because they use non-standard
encodings.

If this overall approach seems OK, please let me know and I can prepare it for
gcc-patches. bootstrap + reg test look good on x86-64 linux. Thanks!

-Lewis

[Bug preprocessor/92987] -finput-charset is only usable with encodings that are supersets of ASCII

[lhyatt at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92987

--- Comment #2 from Lewis Hyatt  ---
(In reply to jos...@codesourcery.com from comment #1)
> I think -finput-charset may only be usable for character sets that are 
> valid locale character sets (we don't implement the POSIX rule of 
> interpreting source files in the locale encoding), which does mean 
> supersets of ASCII.  And headers provided by one project for use by 
> another indeed do practically need to be ASCII to be maximally portable.

OK thanks. I guess I am confused why charset.c implements conversion functions
for UTF-16 and UTF-32, that can never actually be used without an error, but
sounds like this use case is not important in any case?

[Bug preprocessor/92987] New: -finput-charset is only usable with encodings that are supersets of ASCII

[lhyatt at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92987

Bug ID: 92987
   Summary: -finput-charset is only usable with encodings that are
supersets of ASCII
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lhyatt at gmail dot com
  Target Milestone: ---

-finput-charset supports converting all encodings supported by iconv, and also
UTF-32 and UTF-16 are supported directly with routines in libcpp/charset.c.
However, -finput-charset does not seem to actually be usable unless the chosen
encoding is a superset of ASCII, because it applies to all header files
included from the source as well. Even an empty source file implicitly includes
/usr/include/stdc-predef.h, and so there is nothing that can be compiled with
say -finput-charset=UTF-32LE:

$ echo -n > t.c
$ gcc -S -finput-charset=UTF-32LE t.c
cc1: error: failure to convert UTF-32LE to UTF-8

The error comes while processing stdc-predef.h.

I was about to work on adding support for -finput-charset into diagnostics
infrastructure (it currently ignores it), however it seems like this issue
should probably be dealt with first, since it may entail adding the notion that
different source files have a different input encoding. I am not sure what
would be the desired way to address it. Are there use cases where it is
desirable that -finput-charset applies to the #includes too (I guess systems
could exist where the system headers are not ASCII)? Would it make sense to add
a new option that changed the charset only for source files, and not the
#includes? Or maybe it should be kept for "..." includes and not for <...> or
something like this?

-Lewis

[Bug c/91843] pretty printer mangles extended characters

[lhyatt at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91843

Lewis Hyatt  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Lewis Hyatt  ---
Fixed for GCC 10.
https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=279226

[Bug ipa/91853] [10 Regression] ICE in gimplify_modify_expr, at gimplify.c:5902 since r275982

[lhyatt at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91853

Lewis Hyatt  changed:

   What|Removed |Added

 CC||lhyatt at gmail dot com

--- Comment #8 from Lewis Hyatt  ---
Ugh, my apologies, this commit relates to PR 91843 rather.

[Bug c/91843] pretty printer mangles extended characters

[lhyatt at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91843

--- Comment #2 from Lewis Hyatt  ---
Patch was sent for review:

https://gcc.gnu.org/ml/gcc-patches/2019-10/msg00766.html

Thanks!

[Bug preprocessor/49973] Column numbers count multibyte characters as multiple columns

[lhyatt at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49973

--- Comment #18 from Lewis Hyatt  ---
(In reply to jos...@codesourcery.com from comment #17)
> On Tue, 17 Sep 2019, lhyatt at gmail dot com wrote:
> 
> > In any case, the underlying source of wcwidth() could easily be changed as a
> > drop-in replacement so I guess it can also be decided later. The use of
> > mbrtowc() is the bigger problem, since this converts from the user's locale 
> > and
> > it needs to convert from what -finput-charset asked for (or else UTF-8)
> > instead.
> 
> If __STDC_ISO_10646__ is defined, wchar_t is Unicode and so local code 
> converting from UTF-8 to wchar_t can be used (together with wcwidth from 
> libc if available).
> 
> If __STDC_ISO_10646__ is not defined, the encoding of wchar_t is unknown.  
> Maybe in that case it's best to avoid libc's wcwidth (if any) and just use 
> a local implementation of wcwidth on the results of converting UTF-8 to 
> Unicode code points.

It seems to erase a lot of complexity just to always use an internal wcwidth(),
so that's what I ended up doing. Patch was posted to
https://gcc.gnu.org/ml/gcc-patches/2019-09/msg01558.html for your
consideration. This one just addresses diagnostics, not the input-charset or
user locale conversion stuff. I will submit those separately after this one is
reviewed. Thanks!

[Bug c/91843] pretty printer mangles extended characters

[lhyatt at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91843

--- Comment #1 from Lewis Hyatt  ---
Created attachment 46905
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46905&action=edit
Patch to implement the 3rd option

The last option from my previous message seems, at least, unlikely to break
anything. Attached patch resolves this issue.

It also fixes a small unrelated bug that prevents the first byte prior to any
hex-escaped byte from being output, which was revealed by new self-test cases
that I have added.

[Bug c/91843] New: pretty printer mangles extended characters

[lhyatt at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91843

Bug ID: 91843
   Summary: pretty printer mangles extended characters
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lhyatt at gmail dot com
  Target Milestone: ---

There seem to be some issues with identifiers containing extended characters
going through pretty-printer.c. For example, this test:

=
int int_π = 3;
int π() {
return itn_π;
}
=

(note: if testing older trunk that doesn't have extended identifier support,
the same behavior is seen using UCNs).

In either C or C++ mode, the output is wrong:

t8.cpp: In function ‘int\xcf\x80()’:
t8.cpp:3:12: error: ‘itn_π’ was not declared in this scope; did you mean
‘int\xcf\x80’?
3 | return itn_π;
  |^
  |int_π

(in C it's the same except for minor changes in the text.)

So extended characters are printed 5 times, and 2 of them get mangled with hex
escape codes and 3 come out OK. Of the 3 that work, 2 from
diagnostic-show-locus.c are just output directly from the source, and the other
one (the error: 'itn_π') is printed using %qD, which ends up in
pp_c_identifier, which ends up calling pp_identifier in pretty-print.h, which
calls pp_string, which does not do any hex escaping.

For the two wrong ones, the code path is different for C and C++, but they end
up in pretty-printer.c being processed as a %qs directive either way.

(BTW, incidental to this bug report, the "did you mean" part is missing a call
to identifier_to_locale(). But that isn't the reason it gets misprinted.)

It seems there are lots of code paths that may end up printing an identifier
via %qs, so I tried to look at this common element, and the situation seems
straightforward enough, but I don't understand why it is the way it is, so I'm
not sure what's the correct fix. The source of the issue is that the %qs seems
to apply quoting in two unrelated senses... It surrounds the string with
quotation marks, and it also prints the string with pp_quoted_string() instead
of pp_string(). The pp_quoted_string() then applies the hex escape to all
non-printable bytes it comes across. Seems there would be a few options:

-Change %qs to only surround with quotes, not also do hex escapes. This is a
simple one-line fix but I am not sure why it does this hex escaping or if it's
still necessary for other use cases.

-Maybe there is some alternative to %qs that is already there that's supposed
to be used for this, and needs to be added in various places? This test case
reveals two of them, but there must be others among 2000 different uses of %qs,
so not sure about this...

-Change pp_quoted_string() to check if the bytes it would escape form a valid
UTF-8 sequence, in which case, don't escape them. That also seems relatively
simple and would handle all uses cases of %qs wherever they may be.


I am happy to work on it but not sure how to decide on the best path. Thanks!

-Lewis

[Bug preprocessor/49973] Column numbers count multibyte characters as multiple columns

[lhyatt at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49973

--- Comment #16 from Lewis Hyatt  ---
Thank you both for the feedback so far. Regarding the use of wcwidth(), one
thing I noticed is that glibc has a much different result than gnulib does, say
for instance emojis return width 2 in the former rather than 1. (Which seems
better based on what I can tell.) It seems that glibc has undergone a fair
amount of tweaking to match what applications expect and so what it provides is
not coming directly from parsing the Unicode specs, although that's probably
the bulk of it. But I wonder, perhaps this is a sign that it might be better to
just make use of glibc and not try to add in a third implementation to the mix?

In any case, the underlying source of wcwidth() could easily be changed as a
drop-in replacement so I guess it can also be decided later. The use of
mbrtowc() is the bigger problem, since this converts from the user's locale and
it needs to convert from what -finput-charset asked for (or else UTF-8)
instead.

I have a more or less fully-baked patch at this point, that fixes up all
diagnostics that I am aware of (changes mostly in diagnostic.c and
diagnostic-show-locus.c) to be multi-byte aware. That includes column numbers,
carets, annotations, notes, fixit hints, etc. The patch still ignores the
input-charset issue and uses mbrtowc(), so that is the last thing for me to add
before I think it is worth sharing. I was wondering if I could get some advice
as to where to start here please?

It seems that basically location_get_source_line() in input.c needs to return
the lines converted to UTF-8, since all parsing has been working with the lines
in this form, and all the byte offsets they populated rich_locations with, etc,
are relative to the converted data too. I am not sure what's the correct way
though for location_get_source_line() to know the value of the -finput-charset
option. Typically this is inspected from a cpp_reader object, but none is
available in the context where this runs, that I understand anyway. It seems
that in order to make use of the existing conversion machinery in
libcpp/charset.c, I need to have a cpp_reader instance available too.
Appreciate any suggestions here. Thanks!

-Lewis

[Bug preprocessor/49973] Column numbers count multibyte characters as multiple columns

[lhyatt at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49973

Lewis Hyatt  changed:

   What|Removed |Added

 CC||lhyatt at gmail dot com

--- Comment #13 from Lewis Hyatt  ---
Created attachment 46882
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46882&action=edit
partial patch illustrating the intended approach

Hello-

I would like to help fix this up. I have another patch, hopefully being
approved soon, that will implement support for extended characters in
identifiers. If that sees some use, then this problem will become more
noticeable, so it would be nice to address the column numbering issue at the
same time.

It's worth noting that there is a related problem not specifically mentioned so
far in this bug report -- in addition to the column number, the caret output in
diagnostic-show-locus.c also goes to the same wrong column.

Attached for comment is a preliminary patch (no tests yet) that fixes the
column number only (not the caret). If the overall approach seems sound, I am
happy to flesh it out to handle all the fancy diagnostics too. I have a couple
questions about the implementation, though, which I thought worthwhile to clear
up before proceeding further.

Here is a useful test case for this:

===
const char* smile = ""; int x = y;
===

Currently it outputs:

t.cpp:1:65: error: ‘y’ was not declared in this scope
 const char* smile = ""; int x = y;
 ^

And indeed the column number and caret are both incorrect (but consistent with
each other). Not visible here is that the 'y' is properly colorized in the
source line. That works as-is because the ANSI color escapes should be inserted
at the proper byte, not the proper display column. So the machinery in
diagnostic-show-locus.c requires both the byte count and the logical column
count in order to both colorize the source line and put the caret at the right
place. 

Therefore the approach I chose was to keep most things exactly as they are --
all locations are tracked via byte counts just as now. Then all that's
necessary is to compute the logical display column just when it's needed, at
the time the diagnostic is output. This seems tenable because
location_get_source_line() already lets us retrieve the line and work with it
efficiently. That's the idea I went with here to adjust the column number;
happy to hear any feedback before diving in to applying the same idea
throughout diagnostic-show-locus.c.

I have one other question though. This quick attempt uses wchar.h, namely the
mbrtowc() and wcwidth() functions. Firstly, it seems unfortunate to introduce a
dependency on those, which may be problematic for Windows, etc. (I borrowed the
same configure checks used in intl.c for that.) But also, this will always
convert multibyte input files using the user's locale, whereas GCC doesn't work
like this when lexing files -- it ignores the locale and rather defaults to
UTF-8 unless overridden by -finput-charset. It seems that in a perfect world
diagnostics parsing of the source should work the same way.

I feel like the most portable solution is just to use directly the necessary
code (from glibc or gnulib or from scratch or wherever) to handle the wcwidth()
functionality, and tweak it for this purpose. It's in essence just a binary
search in a table. Basically I would convert the source line from the input
charset to UTF-8 the same way the file is read on original input (using the
facilities in libcpp/charset.c), and then I would just need a variant of
wcwidth() that, rather than dealing with wchar_t and locales, simply takes
UTF-8 input and returns the necessary width. Does this seem like a good
approach? Otherwise, if I keep the use of wchar APIs, I think it would be
necessary to make a temporary change to the locale when computing the display
column, as dictated by the input charset.

Note that this also brings up an unrelated question with -finput-charset. Say
right now, I have a file in latin1 encoding and it is processed with
-finput-charset=latin1, and then I compile it from a UTF-8 locale. If a source
line is output in diagnostics, currently it gets output in the latin1 encoding
and produces unreadable characters on the terminal. With changes along the
lines I propose in the previous paragraph, the diagnostics would end up being
output in UTF-8 (or whatever the current locale demands), which I think is
maybe an improvement as well.

Thanks for any suggestions.

-Lewis

[Bug c++/91755] New: C++ handling of extended characters is not 100% correct

[lhyatt at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91755

Bug ID: 91755
   Summary: C++ handling of extended characters is not 100%
correct
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lhyatt at gmail dot com
  Target Milestone: ---

In C++, technically extended characters (e.g. UTF-8) in the source are supposed
to be converted to UCN escapes during translation phase 1. Thereafter it should
not be detectable whether a UCN or the character itself was used (except in raw
string literals where the conversion is reverted). GCC does not do this
transformation. The distinction is not visible in too many places, but one such
is in preprocessor stringizing.

For instance:

==
#define stringize(x) #x
static_assert(sizeof(stringize("π")) == sizeof(stringize("\U03C0")),
"oops");
==

The above assert should not fire per the letter of the standard, but it does.

I am not sure if it is necessarily desirable to fix this since the existing
behavior seems more intuitive and matches other compilers. But the issue may
become a little more prevalent soon -- as discussed in this thread:
https://gcc.gnu.org/ml/gcc-patches/2019-09/msg00822.html, a patch will be
applied in the near future that enables extended characters in identifiers too.
Similar to the above case, stringizing such an identifier twice will also make
visible the distinction between UCN- and direct-specified extended characters.

In the new tests being added for this patch
(gcc/testsuite/g++.dg/cpp/ucnid-2-utf8.C and
gcc/testsuite/g++.dg/cpp/ucnid-3-utf8.C), we test that stringizing works for
identifiers containing extended characters, but we test the existing behavior,
which is technically not standard-conforming. So in order to memorialize the
state of things, I am filing this bug report so that I can add a reference to
the situation in the new test cases. If GCC behavior changes in the future,
these new tests will fail and should be adapted to match.

[Bug c/67224] UTF-8 support for identifier names in GCC

[lhyatt at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67224

--- Comment #29 from Lewis Hyatt  ---
(In reply to jos...@codesourcery.com from comment #28)

> Thanks for working on this!  I encourage sending this to gcc-patches once 
> a few fixes have been made and you've done the legal paperwork, see 
> .
> 


Thank you very much for taking a look and for the feedback. I will incorporate
all this and send to gcc-patches. Regarding the copyright assignment, I
couldn't quite discern from this link what I need to do next... it seems like I
need someone to email me the necessary form, is that correct? 

I will also file additional bug reports for the diagnostics-related stuff; I 
believe I can construct test cases that do not depend on this patch for those.

[Bug c/67224] UTF-8 support for identifier names in GCC

[lhyatt at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67224

--- Comment #27 from Lewis Hyatt  ---
Created attachment 46620
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46620&action=edit
second attempt at posting the patch

Sorry, the previous patch I sent doesn't seem to show correctly in Bugzilla. I
think probably because the test cases include invalid UTF-8 and also
latin1-encoded characters, it may have caused the whole file to be
misinterpreted as the wrong encoding? It only affects the test cases but I am
sending it here as binary and hoping that it is easier to read then. Thanks!

[Bug c/67224] UTF-8 support for identifier names in GCC

[lhyatt at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67224

Lewis Hyatt  changed:

   What|Removed |Added

 CC||lhyatt at gmail dot com

--- Comment #26 from Lewis Hyatt  ---
Created attachment 46618
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46618&action=edit
Patch with test cases that implements extended chars in identifiers

Hi All-

I am interested in helping out with this if there is still interest to support
this feature. (Full disclosure, I don't have any experience with the gcc
codebase, but I do have a lot of experience developing with gcc.)

I took a crack at implementing it based on Joseph's outline in Comment #21 and
the rest of the discussion in this thread. The patch is attached, including
test cases. (I more or less took all the existing ucnid* test cases and adapted
them for this, plus added a couple extra ones.) It seems to work fine, as far
as interpreting the identifiers and bootstrapping clean, and test cases also
pass except for one that I'll mention below, but I have many comments +
questions as well:

1. The number of changes to libcpp is actually pretty small. All the work to
recognize UTF-8 happens in forms_identifier_p(), so that the existing fast
paths for regular characters are not affected, and that extended chars end up
getting treated just like UCNs for the most part. forms_identifier_p() makes
use of a new utility _cpp_valid_utf8_in_identifier() in charset.c that is
similar to the existing _cpp_valid_ucn() and handles the UTF8 details.

2. otherwise _cpp_interpret_identifier() and lex_identifier() didn't need any
changes. The former could be optimized a bit, it always allocates a temporary
buffer, even though the buffer is only needed if UCNs appear. (This is the case
already in the case of dollar signs that end up in this code path too.) 
Probably it's not a big deal though.

3. Invalid UTF-8 is left alone and parsed as stray tokens, the same as now.

4. Regarding the case of codepoints not allowed to appear in an identifier. In
C, I did as Joseph suggested, or at least I tried to. The grammar specifies
that an identifier ends once an illegal character is encountered, so this is
how it works now, and then the disallowed UTF-8 forms a stray token next. It
was not clear to me though whether this stray token should consist of just the
next 1 byte of the input, or the entire disallowed UTF-8 character. Currently
it's just the next byte because that's how things worked out of the box.
Changing it wouldn't be too hard, just means the default case of
_cpp_lex_direct()'s main switch statement would need to try to read a UTF char
rather than a byte.

  In C++, I think UCNs or UTF-8 in identifiers should be treated identically in
all respects, unless I misunderstand things (because technically the UTF-8 was
supposed to be converted to UCNs in translation phase 1), so in that case a
disallowed codepoint does not end the token but rather triggers an invalid
character error.

5. There is a problem with diagnostics output when the source contains UTF-8
characters. The locator caret ends up in the wrong place, I assume just because
this code is not aware of the multibyte encoding. That much is not specific to
my patch, it exists already now e.g. with:

$ cat t.cpp
const char* x = "ππ"; int y = z;

$ g++ -c t.cpp
t.cpp:1:57: error: ‘z’ was not declared in this scope
 const char* x = "ππ"; int y = z;
 ^

The bigger problem though is in layout::print_source_line() which colorizes the
source lines. It seems to end up attempting to colorize just the first byte,
even for UTF-8, which makes the output no longer valid. I tried to look into it
but I wasn't sure what are the implications, e.g. would it require some much
larger overhaul of diagnostics infrastructure anyway to get this right, and
would it perhaps be better just to disable colorization in the presence of
UTF-8 input or something like this, for the meantime.

As an example of what I mean, from preprocessing this (in c99 mode):


int ٩;


I get:
t3.c:1:5: error: universal character ٩ is not valid at the start of an
identifier
1 | int ٩;

But if color is enabled, the output gets corrupted because ANSI escapes are
inserted between the two bytes of the multibyte character on the 2nd line of
diagnostics.

6. There is also a problem with formatting the output of some diagnostics, e.g.
when I compile this:

---
int π = 3;
int x = π2;
---

I get:
t2.cpp:2:9: error: ‘π2’ was not declared in this scope; did you mean
‘\xcf\x80’? This is also not specific to this patch and occurs the same if UCN
is used:

$ cat t.cpp
int \u03C0 = 3;
int x = \u03C02;

$ g++ -c t.cpp
t.cpp:2:9: error: ‘π2’ was 

[Bug c++/77347] New: [6 Regression] Incorrect auto deduction failure in template class member function

[lhyatt at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77347

Bug ID: 77347
   Summary: [6 Regression] Incorrect auto deduction failure in
template class member function
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lhyatt at gmail dot com
  Target Milestone: ---

The following valid test case fails to compile starting with gcc 6:

t.cpp
===
template auto f() {return 0U;}
template
struct B {
unsigned g() {
auto i = 0U, j = f();
return i+j;
}
};
auto i = B<>{}.g();
===

$ g++ -std=c++14 -c t.cpp
t.cpp: In member function 'unsigned int B<  >::g()':
t.cpp:5:9: error: inconsistent deduction for 'auto': 'unsigned int' and then
'auto'
 auto i = 0U, j = f();
 ^~~~
===

here is output of g++ -v:
Using built-in specs.
COLLECT_GCC=g++
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-6.2.0/configure --prefix=/usr/local/gcc-6.2.0
--with-tune=native
Thread model: posix
gcc version 6.2.0 (GCC)
COLLECT_GCC_OPTIONS='-v' '-c' '-shared-libgcc' '-mtune=native' '-march=x86-64'
 /usr/local/gcc-6.2.0/libexec/gcc/x86_64-pc-linux-gnu/6.2.0/cc1plus -quiet -v
-imultiarch x86_64-linux-gnu -D_GNU_SOURCE t.cpp --param l1-cache-size=32
--param l1-cache-line-size=64 --param l2-cache-size=20480 -mtune=sandybridge
-quiet -dumpbase t.cpp -march=x86-64 -auxbase t -version -o /tmp/ccXuYkVf.s
GNU C++14 (GCC) version 6.2.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 6.2.0, GMP version 5.1.3, MPFR version
3.1.2-p3, MPC version 1.0.1, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/usr/local/gcc-6.2.0/lib/gcc/x86_64-pc-linux-gnu/6.2.0/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:

/usr/local/gcc-6.2.0/lib/gcc/x86_64-pc-linux-gnu/6.2.0/../../../../include/c++/6.2.0

/usr/local/gcc-6.2.0/lib/gcc/x86_64-pc-linux-gnu/6.2.0/../../../../include/c++/6.2.0/x86_64-pc-linux-gnu

/usr/local/gcc-6.2.0/lib/gcc/x86_64-pc-linux-gnu/6.2.0/../../../../include/c++/6.2.0/backward
 /usr/local/gcc-6.2.0/lib/gcc/x86_64-pc-linux-gnu/6.2.0/include
 /usr/local/include
 /usr/local/gcc-6.2.0/include
 /usr/local/gcc-6.2.0/lib/gcc/x86_64-pc-linux-gnu/6.2.0/include-fixed
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
GNU C++14 (GCC) version 6.2.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 6.2.0, GMP version 5.1.3, MPFR version
3.1.2-p3, MPC version 1.0.1, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 0e0cf061fe2036427948ceefe0c946f5
===

The issue seems to require that both the global function f and the class B in
which the member function g() lives should be templates.

The issue is still present on the current mainline, it started with r231349:

b34f7e66cb96f137d5283d6285ffa1d333756e52 is the first bad commit
commit b34f7e66cb96f137d5283d6285ffa1d333756e52
Author: jason 
Date:   Mon Dec 7 04:34:43 2015 +

PR c++/68597, fix auto9.C and auto-neg1.C with -std=c++1z.

* decl.c (check_tag_decl): Use ds_type_spec in auto diagnostic.
* typeck.c (check_return_expr): Check for inconsistent deduction.
* parser.c (class type_id_in_expr_sentinel): New.
(cp_parser_primary_expression) [RID_VA_ARG]: Use it.
(cp_parser_new_expression): Use it.
(cp_parser_trait_expr): Use it.
(cp_parser_type_id_1): Complain about auto if in_type_id_in_expr_p.
(cp_parser_default_type_template_argument): Check for auto.
(cp_parser_type_id_list): Likewise.
(cp_parser_simple_type_specifier): Allow auto parms if flag_concepts.
* pt.c (do_auto_deduction): Handle erroneous type.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@231349
138bc75d-0d04-0410-961f-82ee72b054a4

Thanks...

-lewis

[Bug c++/71461] New: missed optimization in conditional assignment

[lhyatt at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71461

Bug ID: 71461
   Summary: missed optimization in conditional assignment
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lhyatt at gmail dot com
  Target Milestone: ---

=
int i, j;
void f1(bool b, int x) {
(b ? i : j) = x;
}
void f2(bool b, int x) {
*(b ? &i : &j) = x;
}
==

On x86-64 at -O3, gcc outputs different code for f1() vs f2(), using a branch
for f1() and a cmove for f2(). Is it something that can/should be optimized?

gcc (version 5, 6, or current trunk) outputs:
==
f1(bool, int):
testb   %dil, %dil
jne .L6
movl%esi, j(%rip)
ret
.L6:
movl%esi, i(%rip)
ret

f2(bool, int):
testb   %dil, %dil
movl$j, %edx
movl$i, %eax
cmove   %rdx, %rax
movl%esi, (%rax)
ret
==

vs clang:

==
f1(bool, int):# @f1(bool, int)
movl$i, %eax
movl$j, %ecx
testb   %dil, %dil
cmovneq %rax, %rcx
movl%esi, (%rcx)
retq

f2(bool, int):# @f2(bool, int)
movl$i, %eax
movl$j, %ecx
testb   %dil, %dil
cmovneq %rax, %rcx
movl%esi, (%rcx)
retq
==

In my tests, the branch version of f1() is about 2x-3x slower than f2() if the
branch is 50% predicted, and only about 1% faster than f2() if it is 100%
predicted.

FWIW, this version:

==
void f3(bool b, int x) {
if(b) i = x; else j = x;
}
==

ends up using a branch on both gcc and clang.

Thanks...

-Lewis

[Bug c++/65966] "sorry, unimplemented: unexpected AST of kind try_block" when initializing a 2D array

[lhyatt at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65966

--- Comment #3 from Lewis Hyatt  ---
Hello-

I thought it would make sense to ping this one again a month later, I am afraid
I may have confused matters by mixing two separate issues in one report...
Definitely the second issue is already covered in other bug reports, but I
believe the main one is a new regression in 5.1 vs 4.9, so it ought to be
marked as such rather than "unconfirmed", no?

Just to recap, here is the testcase:


struct A {
A();
~A();
};

struct B {
A a{};
};

struct C {
B array[100][100];
} c;
=

and it breaks starting at rev 220544:
https://gcc.gnu.org/viewcvs?rev=220544&root=gcc&view=rev

I just confirmed it is still broken on the current mainline.

Thanks!

-Lewis

[Bug c++/62212] ICE compiling template function with array reference parameter whose size depends on a template parameter

[lhyatt at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62212

--- Comment #2 from Lewis Hyatt  ---
Hello-

FYI, I have located the commit which broke this testcase, it is this one:

==
Author: jason
Date: Fri Oct 15 21:15:13 2010
New Revision: 165521

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165521
Log:
PR c++/45983
* tree.c (cp_build_qualified_type_real): Don't reuse a variant
with a different typedef variant of the element type.

Added:
trunk/gcc/testsuite/g++.dg/lto/pr45983_0.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/tree.c
trunk/gcc/testsuite/ChangeLog
==

Thanks...

-Lewis

[Bug c++/65966] "sorry, unimplemented: unexpected AST of kind try_block" when initializing a 2D array

[lhyatt at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65966

--- Comment #1 from Lewis Hyatt  ---
Hello-

I have some additional information that I hope is helpful to look into this.

A. Regarding the first testcase, a regression from 4.9, which produces the
"sorry, unimplemented" error in 5.1:

1. I forgot to mention explicitly, this does require -std=c++14; with
-std=c++11 it works fine.

2. The issue started at the following revision:

==
Author: jason
Date: Mon Feb  9 19:15:55 2015
New Revision: 220544

URL: https://gcc.gnu.org/viewcvs?rev=220544&root=gcc&view=rev
Log:
PR c++/64899
* init.c (build_vec_init): Handle default-initialized array with
constexpr default constructor.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-array10.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/init.c
==

B. Regarding the second testcase, which compiles in 5.1, but produces
unexpected output (for an array of N elements total, there are N calls to the
constructor output in the code, no matter how large N may be):

This seems to be an unrelated issue. It did not start failing at the above
revision, rather it ICEs in that revision and the few prior to it that I
checked. It also happens whether you have -std=c++11 or -std=c++14, and I see
the same behavior in gcc 4.7, 4.8 and 4.9 as well (in those releases, it works,
does not ICE, but does output the huge number of instructions). So it seems
that over time, it has changed several times whether it ICEs or compiles, but
it has always generated this unexpected code.

Should I file this as a separate bug? It seems like it must not be intentional,
as it basically makes it impossible to brace-initialize large arrays (e.g. in
an object that is meant to be allocated dynamically, where the stack size is
not an issue, one might reasonably use an array with very many elements and not
expect the code size to be O(N) for N elements). Here is a simplified testcase,
it doesn't depend on NSDMI, just on brace initialization, and it's the same for
even 1D arrays:

==
struct A {
A();
};

#define N 1
struct B {
A array[N];
B() : array{} {}
} b;
==

And the issue is that this has had O(N) compile time and O(N) code size, since,
as far as I can tell, brace initialization was ever supported. Changing array{}
to array() works fine, as does omitting the initializer entirely.

Thanks...

-Lewis

[Bug c++/65966] New: "sorry, unimplemented: unexpected AST of kind try_block" when initializing a 2D array

[lhyatt at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65966

Bug ID: 65966
   Summary: "sorry, unimplemented: unexpected AST of kind
try_block" when initializing a 2D array
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lhyatt at gmail dot com
  Target Milestone: ---

This fails to compile with gcc 5.1, is fine with 4.9:


struct A {
A();
~A();
};

struct B {
A a{};
};

struct C {
B array[100][100];
} c;
=

$ g++ -v -c -std=c++14 t.cpp
Using built-in specs.
COLLECT_GCC=g++
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-5.1.0/configure --prefix=/usr/local/gcc-5.1.0
--with-tune=westmere --with-arch=nehalem
Thread model: posix
gcc version 5.1.0 (GCC)
COLLECT_GCC_OPTIONS='-v' '-c' '-std=c++14' '-shared-libgcc' '-mtune=westmere'
'-march=nehalem'
 /usr/local/gcc-5.1.0/libexec/gcc/x86_64-unknown-linux-gnu/5.1.0/cc1plus -quiet
-v -D_GNU_SOURCE t.cpp -quiet -dumpbase t.cpp -mtune=westmere -march=nehalem
-auxbase t -std=c++14 -version -o /tmp/ccmhY1ZH.s
GNU C++14 (GCC) version 5.1.0 (x86_64-unknown-linux-gnu)
compiled by GNU C version 5.1.0, GMP version 4.3.2, MPFR version
2.4.2-p1, MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory
"/usr/local/gcc-5.1.0/lib/gcc/x86_64-unknown-linux-gnu/5.1.0/../../../../x86_64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:

/usr/local/gcc-5.1.0/lib/gcc/x86_64-unknown-linux-gnu/5.1.0/../../../../include/c++/5.1.0

/usr/local/gcc-5.1.0/lib/gcc/x86_64-unknown-linux-gnu/5.1.0/../../../../include/c++/5.1.0/x86_64-unknown-linux-gnu

/usr/local/gcc-5.1.0/lib/gcc/x86_64-unknown-linux-gnu/5.1.0/../../../../include/c++/5.1.0/backward
 /usr/local/gcc-5.1.0/lib/gcc/x86_64-unknown-linux-gnu/5.1.0/include
 /usr/local/include
 /usr/local/gcc-5.1.0/include
 /usr/local/gcc-5.1.0/lib/gcc/x86_64-unknown-linux-gnu/5.1.0/include-fixed
 /usr/include
End of search list.
GNU C++14 (GCC) version 5.1.0 (x86_64-unknown-linux-gnu)
compiled by GNU C version 5.1.0, GMP version 4.3.2, MPFR version
2.4.2-p1, MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 2a9de20833bb0c7b695acd3b2e90df62
t.cpp: In constructor 'constexpr C::C()':
t.cpp:10:8: sorry, unimplemented: unexpected AST of kind try_block
 struct C {
^
t.cpp:10: confused by earlier errors, bailing out


Generally all the features in the testcase must be present (need a 2d array,
not 1d; need to explicitly put the constructor + destructor for class A; need
class B to have the NSDMI for its "a" subobject) for the error to occur.

If I make the following small change to explicitly initialize the array in
class C:


struct A {
A();
~A();
};

struct B {
A a{};
};

struct C {
B array[100][100] = {};
} c;
=

then it compiles OK. However, in this case there seems to be some sort of other
issue, instead of a loop, it outputs 1 individual instructions to
initialize the array:

.LEHB0:
call_ZN1AC1Ev
.LEHE0:
leaq1(%rbx), %rax
movq%rax, %rdi
.LEHB1:
call_ZN1AC1Ev
.LEHE1:
leaq2(%rbx), %rax
movq%rax, %rdi
.LEHB2:
call_ZN1AC1Ev
.LEHE2:
leaq3(%rbx), %rax
movq%rax, %rdi
.LEHB3:
call_ZN1AC1Ev
.LEHE3:
leaq4(%rbx), %rax
movq%rax, %rdi


... etc 1 times.

We have a use case where we have a 100x100x100 3d array, and the compiler
spends hours generating these 1 millions instructions, whereas gcc 4.9 just
generated a reasonable loop right away.

Thank you...

-Lewis

[Bug c++/62212] ICE compiling template function with array reference parameter whose size depends on a template parameter

[lhyatt at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62212

--- Comment #1 from Lewis Hyatt  ---
Hello-

FYI this problem still exists on the mainline. I see the bug remains
unconfirmed, please let me know if more information would be useful, the
testcase was pretty simple so I just pasted it inline in the first report.
Thanks!

-Lewis

[Bug c++/62212] New: ICE compiling template function with array reference parameter whose size depends on a template parameter

[lhyatt at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62212

Bug ID: 62212
   Summary: ICE compiling template function with array reference
parameter whose size depends on a template parameter
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lhyatt at gmail dot com

I get an ICE in gcc 4.8.1 and also on 4.9 when compiling the code below.
Doesn't matter the optimization level or what -std=:



typedef int my_int;

template
struct X {
enum {value = 1};
};

template
void f(const my_int(&)[X::value]);

int main() {
const my_int a[1] = {};
f(a);
}



$ g++ -v -c t.cpp
Using built-in specs.
COLLECT_GCC=/usr/local/gcc48/bin/g++
Target: x86_64-unknown-linux-gnu
Configured with: ./configure --enable-threads=posix --enable-__cxa_atexit
--prefix=/usr/local/gcc-4.8.1
Thread model: posix
gcc version 4.8.1 (GCC)
COLLECT_GCC_OPTIONS='-v' '-c' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /usr/local/gcc-4.8.1/libexec/gcc/x86_64-unknown-linux-gnu/4.8.1/cc1plus -quiet
-v -D_GNU_SOURCE t.cpp -quiet -dumpbase t.cpp -mtune=generic -march=x86-64
-auxbase t -version -o /tmp/ccbr6RST.s
GNU C++ (GCC) version 4.8.1 (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.8.1, GMP version 4.3.2, MPFR version 2.4.2-p1,
MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory
"/usr/local/gcc-4.8.1/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/../../../../x86_64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:

/usr/local/gcc-4.8.1/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/../../../../include/c++/4.8.1

/usr/local/gcc-4.8.1/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/../../../../include/c++/4.8.1/x86_64-unknown-linux-gnu

/usr/local/gcc-4.8.1/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/../../../../include/c++/4.8.1/backward
 /usr/local/gcc-4.8.1/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/include
 /usr/local/include
 /usr/local/gcc-4.8.1/include
 /usr/local/gcc-4.8.1/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/include-fixed
 /usr/include
End of search list.
GNU C++ (GCC) version 4.8.1 (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.8.1, GMP version 4.3.2, MPFR version 2.4.2-p1,
MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 9381368e685e312c931bb6a2db2d568c
t.cpp: In instantiation of 'void f(const my_int (&)[X::value]) [with T =
void; my_int = int]':
t.cpp:13:15:   required from here
t.cpp:9:6: internal compiler error: Segmentation fault
 void f(const my_int(&)[X::value]);
  ^
0x89ffef crash_signal
../.././gcc/toplev.c:332
0x72a8c7 fold_convert_loc(unsigned int, tree_node*, tree_node*)
../.././gcc/fold-const.c:1879
0x72e648 associate_trees
../.././gcc/fold-const.c:891
0x71d534 fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
../.././gcc/fold-const.c:10589
0x72768a fold_build2_stat_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
../.././gcc/fold-const.c:14877
0x7195ce fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
../.././gcc/fold-const.c:9934
0x72768a fold_build2_stat_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
../.././gcc/fold-const.c:14877
0x89ac30 layout_type(tree_node*)
../.././gcc/stor-layout.c:2230
0xa0aaa3 build_array_type_1
../.././gcc/tree.c:7490
0x5add1f build_cplus_array_type(tree_node*, tree_node*)
../.././gcc/cp/tree.c:811
0x5af08e cp_build_qualified_type_real(tree_node*, int, int)
../.././gcc/cp/tree.c:1000
0x5bd2a0 canonicalize_for_substitution
../.././gcc/cp/mangle.c:364
0x5bd2a0 write_type
../.././gcc/cp/mangle.c:1886
0x5bd61d write_type
../.././gcc/cp/mangle.c:2052
0x5be6ff write_method_parms
../.././gcc/cp/mangle.c:2496
0x5be7fd write_bare_function_type
../.././gcc/cp/mangle.c:2438
0x5bbaff write_mangled_name
../.././gcc/cp/mangle.c:689
0x5c145d mangle_decl_string
../.././gcc/cp/mangle.c:3431
0x5c15d8 get_mangled_id
../.././gcc/cp/mangle.c:3453
0x5c15d8 mangle_decl(tree_node*)
../.././gcc/cp/mangle.c:3476
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.



It seems to be related to "my_int" being a typedef... if you change it to
#define my_int int

then it works fine.

Also, if I intentionally give it the wrong sort of array, then it gives the
correct error message and does not ICE, e.g. if I change the type to &quo

[Bug c++/58829] New: non-static member initializer in nested template class produces incorrect compile error

[lhyatt at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58829

Bug ID: 58829
   Summary: non-static member initializer in nested template class
produces incorrect compile error
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lhyatt at gmail dot com

==
struct A {
int f() {return 0;}
} a;

struct B {
template struct C {
int i = a.f();
};
};
B::C<> c;


Above snippet is valid C++11, fails to compile with the following error:

t.cpp: In constructor 'constexpr B::C<>::C()':
t.cpp:7:21: error: no matching function for call to 'A::f(A*)'
 int i = a.f();
 ^
t.cpp:7:21: note: candidate is:
t.cpp:2:9: note: int A::f()
 int f() {return 0;}
 ^
t.cpp:2:9: note:   candidate expects 0 arguments, 1 provided
t.cpp: At global scope:
t.cpp:10:8: note: synthesized method 'constexpr B::C<>::C()' first required
here
 B::C<> c;

If you make C a non-template, or remove the outer class B in which C is nested,
then it works OK. clang compiles it OK. I see it on 4.8.1 and on the current
svn mainline.

$ g++ -v -std=c++11 -o t.o -c t.cpp
Using built-in specs.
COLLECT_GCC=/usr/local/gcc48/bin/g++
Target: x86_64-unknown-linux-gnu
Configured with: ./configure --enable-threads=posix --enable-__cxa_atexit
--prefix=/usr/local/gcc-4.8.1
Thread model: posix
gcc version 4.8.1 (GCC)
COLLECT_GCC_OPTIONS='-v' '-std=c++11' '-o' 't.o' '-c' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
 /usr/local/gcc-4.8.1/libexec/gcc/x86_64-unknown-linux-gnu/4.8.1/cc1plus -quiet
-v -D_GNU_SOURCE t.cpp -quiet -dumpbase t.cpp -mtune=generic -march=x86-64
-auxbase-strip t.o -std=c++11 -version -o /tmp/ccxl7AbU.s
GNU C++ (GCC) version 4.8.1 (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.8.1, GMP version 4.3.2, MPFR version 2.4.2-p1,
MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory
"/usr/local/gcc-4.8.1/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/../../../../x86_64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:

/usr/local/gcc-4.8.1/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/../../../../include/c++/4.8.1

/usr/local/gcc-4.8.1/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/../../../../include/c++/4.8.1/x86_64-unknown-linux-gnu

/usr/local/gcc-4.8.1/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/../../../../include/c++/4.8.1/backward
 /usr/local/gcc-4.8.1/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/include
 /usr/local/include
 /usr/local/gcc-4.8.1/include
 /usr/local/gcc-4.8.1/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/include-fixed
 /usr/include
End of search list.
GNU C++ (GCC) version 4.8.1 (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.8.1, GMP version 4.3.2, MPFR version 2.4.2-p1,
MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 9381368e685e312c931bb6a2db2d568c
t.cpp: In constructor 'constexpr B::C<>::C()':
t.cpp:7:21: error: no matching function for call to 'A::f(A*)'
 int i = a.f();
 ^
t.cpp:7:21: note: candidate is:
t.cpp:2:9: note: int A::f()
 int f() {return 0;}
 ^
t.cpp:2:9: note:   candidate expects 0 arguments, 1 provided
t.cpp: At global scope:
t.cpp:10:8: note: synthesized method 'constexpr B::C<>::C()' first required
here
 B::C<> c;
^

[Bug c++/58725] g++ segfault with non-static member initializer in a nested struct

[lhyatt at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58725

Lewis Hyatt  changed:

   What|Removed |Added

   Severity|major   |normal

[Bug c++/58725] g++ segfault with non-static member initializer in a nested struct

[lhyatt at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58725

--- Comment #1 from Lewis Hyatt  ---
Created attachment 31001
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31001&action=edit
pre-processed source

[Bug c++/58725] New: g++ segfault with non-static member initializer in a nested struct

[lhyatt at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58725

Bug ID: 58725
   Summary: g++ segfault with non-static member initializer in a
nested struct
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lhyatt at gmail dot com

The short code below that involves a non-static member initializer in a class
nested in a template class nested in another class causes g++ to segfault.
Seems to require this particular combination of features. It crashes with or
without -std=c++11. (Without -std=c++11 it notes the error, but then crashes
after.) and independent of optimization level. Output below is with -std=c++11.

t.cpp
-
struct A { //only happens if B is wrapped in another struct
template //only happens if B is a template
struct B {
struct C {
int x = 0;
double y = x; //this line must be present to produce the problem
} c; //only happens if B contains a C object
};
};
int main() {
A::B<>();
}
--

$ g++ -v -save-temps -std=c++11 t.cpp
Using built-in specs.
COLLECT_GCC=/usr/local/gcc48/bin/g++
COLLECT_LTO_WRAPPER=/usr/local/gcc-4.8.1/libexec/gcc/x86_64-unknown-linux-gnu/4.8.1/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ./configure --enable-threads=posix --enable-__cxa_atexit
--prefix=/usr/local/gcc-4.8.1
Thread model: posix
gcc version 4.8.1 (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++11' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
 /usr/local/gcc-4.8.1/libexec/gcc/x86_64-unknown-linux-gnu/4.8.1/cc1plus -E
-quiet -v -D_GNU_SOURCE t.cpp -mtune=generic -march=x86-64 -std=c++11
-fpch-preprocess -o t.ii
ignoring nonexistent directory
"/usr/local/gcc-4.8.1/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/../../../../x86_64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:

/usr/local/gcc-4.8.1/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/../../../../include/c++/4.8.1

/usr/local/gcc-4.8.1/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/../../../../include/c++/4.8.1/x86_64-unknown-linux-gnu

/usr/local/gcc-4.8.1/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/../../../../include/c++/4.8.1/backward
 /usr/local/gcc-4.8.1/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/include
 /usr/local/include
 /usr/local/gcc-4.8.1/include
 /usr/local/gcc-4.8.1/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++11' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
 /usr/local/gcc-4.8.1/libexec/gcc/x86_64-unknown-linux-gnu/4.8.1/cc1plus
-fpreprocessed t.ii -quiet -dumpbase t.cpp -mtune=generic -march=x86-64
-auxbase t -std=c++11 -version -o t.s
GNU C++ (GCC) version 4.8.1 (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.8.1, GMP version 4.3.2, MPFR version 2.4.2-p1,
MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++ (GCC) version 4.8.1 (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.8.1, GMP version 4.3.2, MPFR version 2.4.2-p1,
MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 9381368e685e312c931bb6a2db2d568c
t.cpp: In constructor 'constexpr A::B<>::C::C()':
t.cpp:4:16: internal compiler error: Segmentation fault
 struct C {
^
0x89ffef crash_signal
../.././gcc/toplev.c:332
0x7276e5 size_binop_loc(unsigned int, tree_code, tree_node*, tree_node*)
../.././gcc/fold-const.c:1431
0x765476 gimplify_compound_lval
../.././gcc/gimplify.c:2267
0x761ad4 gimplify_expr(tree_node**, gimple_statement_d**, gimple_statement_d**,
bool (*)(tree_node*), int)
../.././gcc/gimplify.c:7145
0x7631c6 gimplify_expr(tree_node**, gimple_statement_d**, gimple_statement_d**,
bool (*)(tree_node*), int)
../.././gcc/gimplify.c:7804
0x76774f gimplify_modify_expr
../.././gcc/gimplify.c:4902
0x761fc9 gimplify_expr(tree_node**, gimple_statement_d**, gimple_statement_d**,
bool (*)(tree_node*), int)
../.././gcc/gimplify.c:7193
0x763da6 gimplify_stmt(tree_node**, gimple_statement_d**)
../.././gcc/gimplify.c:5725
0x76181d gimplify_cleanup_point_expr
../.././gcc/gimplify.c:5501
0x76181d gimplify_expr(tree_node**, gimple_statement_d**, gimple_statement_d**,
bool (*)(tree_node*), int)
../.././gcc/gimplify.c:7530
0x763da6 gimplify_stmt(tree_node**, gimple_statement_d**)
../.././gcc/gimplify.c:5725
0x761bdb gimplify_statement_list
../.././gcc/gimplify.c:1561
0x761bdb gimplify_expr(tree_node**, gimple_statement_d**, gimple_statement_d**,
bool (*)(tree_node*), int)
../.././gcc/gimplify.c:7582
0x763da6 gimpl

[Bug c++/36193] ICE when accessing static integer constant in template class

[lhyatt at gmail dot com]

--- Comment #6 from lhyatt at gmail dot com  2008-05-09 19:26 ---
Subject: Re:  ICE when accessing static integer constant in
 template class

OK thanks for the quick reply; I'll see if we can get updated over here.

-lewis


pinskia at gcc dot gnu dot org wrote:
> --- Comment #5 from pinskia at gcc dot gnu dot org  2008-05-09 19:25 
> ---
>> g++ (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
> 
> That is a prelease and not a full release.  The fix went into the 4.1 branch
> after that date :).
> 
> 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36193

[Bug c++/36193] ICE when accessing static integer constant in template class

[lhyatt at gmail dot com]

--- Comment #4 from lhyatt at gmail dot com  2008-05-09 19:22 ---
thanks for looking into it, but I wanted to point out that it does not work on
4.1.2, at least not my build:

g++ (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)

that is where I am testing it and getting the ICE.

but anyway it seems like it's probably fixed in more recent versions.


-- 

lhyatt at gmail dot com changed:

   What|Removed |Added

   Severity|normal  |critical


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36193

[Bug c++/36193] ICE when accessing static integer constant in template class

[lhyatt at gmail dot com]

--- Comment #1 from lhyatt at gmail dot com  2008-05-09 18:46 ---
Created an attachment (id=15623)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15623&action=view)
file producing the ICE


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36193

[Bug c++/36193] New: ICE when accessing static integer constant in template class

[lhyatt at gmail dot com]

t.cpp
---
template
struct B : T {
enum {N};
static const int num = N;
void f() {num;}
};

---

$ g++ -v -c t.cpp
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-mpfr --enable-checking=release
x86_64-linux-gnu
Thread model: posix
gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
 /usr/lib/gcc/x86_64-linux-gnu/4.1.2/cc1plus -quiet -v -D_GNU_SOURCE t.cpp
-quiet -dumpbase t.cpp -mtune=k8 -auxbase t -version -o /tmp/ccnVMPxv.s
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-linux-gnu/4.1.2/../../../../x86_64-linux-gnu/include"
ignoring nonexistent directory "/usr/include/x86_64-linux-gnu"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-linux-gnu/4.1.2/../../../../include/c++/4.1.2

/usr/lib/gcc/x86_64-linux-gnu/4.1.2/../../../../include/c++/4.1.2/x86_64-linux-gnu
 /usr/lib/gcc/x86_64-linux-gnu/4.1.2/../../../../include/c++/4.1.2/backward
 /usr/local/include
 /usr/lib/gcc/x86_64-linux-gnu/4.1.2/include
 /usr/include
End of search list.
GNU C++ version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
(x86_64-linux-gnu)
compiled by GNU C version 4.1.2 20061115 (prerelease) (Debian
4.1.1-21).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 632603bce5ef3f84603416b58939d0f7
t.cpp: In member function 'void B::f()':
t.cpp:5: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
For Debian GNU/Linux specific bug reporting instructions,
see .
Preprocessed source stored into /tmp/ccci8hrp.out file, please attach this to
your bugreport.


-- 
   Summary: ICE when accessing static integer constant in template
class
   Product: gcc
   Version: 4.1.2
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: lhyatt at gmail dot com
 GCC build triplet: x86_64-linux-gnu
  GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36193