http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56671
Bug #: 56671
Summary: Gcc uses large amounts of memory and processor power
with large C++11 bitsets
Classification: Unclassified
Product: gcc
Version: 4.7.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54431
Bug #: 54431
Summary: [C++11] g++ crashes when compiling the following file
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54431
--- Comment #1 from m101010a at gmail dot com 2012-09-01 22:04:04 UTC ---
Gcc also doesn't crash if the lambda line is changed to
[this]{this->bar();}();
Although the resulting program does.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54080
Bug #: 54080
Summary: g++ crashes when compiling the following file
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: normal
Prio
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: m101010a at gmail dot com
CC: bangerth at apex68 dot ticam.utexas.edu,
gcc-bugs at gcc dot gnu.org, loewis at gcc dot gnu.org,
martin
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: m101010a at gmail dot com
Target Milestone: ---
$ cat x.cpp
void foo(int);
template void call(T t) {
t(0);
}
void bar() {
static int x=3;
call([](auto
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: m101010a at gmail dot com
Target Milestone: ---
$ cat x.cpp
namespace A { extern "C" int g; }
namespace B { extern "C" int g; }
using namespac
: 8.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: m101010a at gmail dot com
Target Milestone: ---
$ cat x.cpp
template struct A {
static void f();
void f(int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55319
m101010a at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
Assignee: unassigned at gcc dot gnu.org
Reporter: m101010a at gmail dot com
Target Milestone: ---
$ cat x.c
void f() { g(1); }
$ gcc -fsyntax-only -Wall -Wno-implicit x.c
$ gcc -fsyntax-only -Werror=all -Wno-error=implicit x.c
x.c: In function âfâ:
x.c:1:12: error: implicit
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: m101010a at gmail dot com
Target Milestone: ---
$ cat x.cpp
#include
template void b() {
constexpr std::initializer_list c{};
}
int main() { b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89051
--- Comment #2 from m101010a at gmail dot com ---
(In reply to Martin Sebor from comment #1)
> I don't think GCC has an internal representation of warning groups
It has to have some representation, because it can tell which warning group
: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: m101010a at gmail dot com
Target Milestone: ---
$ cat x.cpp
struct s {
#ifdef HAS_DESTRUCTOR
~s();
#endif
};
bool f();
int g()
{
s buf;
if
-optimization
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: m101010a at gmail dot com
Target Milestone: ---
Created attachment 42975
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: m101010a at gmail dot com
Target Milestone: ---
$ cat x.cpp
struct __attribute__((dllexport)) foo {
static constexpr int i = 3;
};
constexpr int foo::i;
$ cat y.cpp
struct
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: m101010a at gmail dot com
Target Milestone: ---
$ cat x.cpp
template struct s{};
void byval(s);
void byref(s&);
void bycref(const s&);
vo
Assignee: unassigned at gcc dot gnu.org
Reporter: m101010a at gmail dot com
Target Milestone: ---
gcc prints EL (\33[K) every time it changes the text color to erase the rest of
the line. If the cursor is at the end of the line, EL will clear the last
character on the line
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90411
--- Comment #2 from m101010a at gmail dot com ---
When I said to put spaces ELs at the end of lines, I meant the end of logical
lines (e.g. \n), not the end of screen lines. Sorry for the confusion.
You can't see this issue in gnome-ter
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: m101010a at gmail dot com
Target Milestone: ---
$ cat x.cpp
template struct a {
virtual b g() { return 0; }
};
template
void foo() {
a
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: m101010a at gmail dot com
Target Milestone: ---
$ cat x.cpp
template struct foo {
int x;
auto f1() -> decltype(x);
};
template auto
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: m101010a at gmail dot com
Target Milestone: ---
$ cat x.cpp
namespace foo { extern "C" void f(); }
extern &qu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55319
Bug #: 55319
Summary: Using -fwhole-program inhibits optimization
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55319
--- Comment #2 from m101010a at gmail dot com 2012-11-18 22:13:23 UTC ---
Actually, it does depend on IO; the optimizations aren't performed in either
case if I declare but don't define putchar, and if do something simple like
as
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: m101010a at gmail dot com
Target Milestone: ---
When compiling the following source file, gcc requires a definition for
bar::bar() but does not emit one, causing a linker error
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: m101010a at gmail dot com
Target Milestone: ---
When compiling with "-O1 -mlzcnt", __builtin_clz applied to an unsigned short
generates the lzcntw instruction instead of lzcntl. Given the following source
code:
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: m101010a at gmail dot com
Target Milestone: ---
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/lto-wrapper
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97720
--- Comment #2 from m101010a at gmail dot com ---
> when the compiler can see there is no matching handler for the exception,
> it doesn't perform stack unwinding
This is fine, it's implementation-defined whether the stack i
: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: m101010a at gmail dot com
Target Milestone: ---
If std::async is called with a noexcept function that throws an exception and
contains a catch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106395
m101010a at gmail dot com changed:
What|Removed |Added
CC||m101010a at gmail dot com
-valid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: m101010a at gmail dot com
Target Milestone: ---
When compiling the code
#include
struct c {
c(int);
~c();
};
struct d {
d(std
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108116
m101010a at gmail dot com changed:
What|Removed |Added
Attachment #54098|0 |1
is obsolete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55918
m101010a at gmail dot com changed:
What|Removed |Added
CC||m101010a at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97720
--- Comment #3 from m101010a at gmail dot com ---
After looking into this more, I have confirmed that this is definitely the
cause of bug 97339, and found a simpler reproduction in bug 55918 comment #4:
#include
class Foo
{
public:
Foo
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: m101010a at gmail dot com
Target Milestone: ---
When calling std::array::size on an uninitialized array, gcc emits a warning:
$ cat x.cpp
#include
int f() {
std::array a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97720
--- Comment #6 from m101010a at gmail dot com ---
> represent the second case in the action table as an empty exception
> specification like C++98 throw()
That will deal with this issue and PR88218, but won't solve PR55918 since
35 matches
Mail list logo
