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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58725
--- Comment #1 from Lewis Hyatt lhyatt at gmail dot com ---
Created attachment 31001
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31001action=edit
pre-processed source
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58725
Lewis Hyatt lhyatt at gmail dot com changed:
What|Removed |Added
Severity|major |normal
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 {
templateint=0 struct C {
int i = a.f();
};
};
B::C c
: 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
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
--- 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=15623action=view)
file producing the ICE
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36193
--- 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
--- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62212
--- Comment #1 from Lewis Hyatt lhyatt at gmail dot com ---
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62212
--- Comment #2 from Lewis Hyatt lhyatt at gmail dot com ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65966
--- Comment #1 from Lewis Hyatt lhyatt at gmail dot com ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65966
--- Comment #3 from Lewis Hyatt lhyatt at gmail dot com ---
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
++
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 ? : ) = x;
}
==
On x86-64 at -O3, gcc outputs
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49973
Lewis Hyatt changed:
What|Removed |Added
CC||lhyatt at gmail dot com
--- Comment #13
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
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
>
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=edit
second attempt at posting the patch
Sorry, the previous patch I sent doesn't seem to show correctly in Bugzilla. I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67224
Lewis Hyatt changed:
What|Removed |Added
CC||lhyatt at gmail dot com
--- Comment #26
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=edit
Patch to implement the 3rd option
The last option from my previous message seems, at least, unlikely to break
anything.
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 a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91843
Lewis Hyatt changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91853
Lewis Hyatt changed:
What|Removed |Added
CC||lhyatt at gmail dot com
--- Comment #8
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!
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_π
: 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
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
>
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/bugzilla/show_bug.cgi?id=93067
--- Comment #1 from Lewis Hyatt ---
Created attachment 47548
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47548=edit
testcases
: 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=edit
Candidate patch
Hello-
When source lines are needed for diagnostics out
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 §
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54185
Lewis Hyatt changed:
What|Removed |Added
CC||lhyatt at gmail dot com
--- Comment #14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86904
Lewis Hyatt changed:
What|Removed |Added
CC||lhyatt at gmail dot com
--- Comment #5
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?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97498
Lewis Hyatt changed:
What|Removed |Added
CC||lhyatt at gmail dot com
--- Comment #8
39 matches
Mail list logo
