https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78017
Ben Longbons changed:
What|Removed |Added
CC||b.r.longbons at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83150
--- Comment #3 from Ben Longbons ---
(In reply to Andrew Pinski from comment #1)
> The signal handler will always be sync unless someone decides to do a kill
> from the command line.
You're assuming that no library ever calls abort(). Glibc cert
y: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: b.r.longbons at gmail dot com
Target Milestone: ---
1. if the `fancy_abort` redefinition is used, exit() is called (and thus atexit
handlers), violating the assumptions of both plugins and later system he
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82554
--- Comment #3 from Ben Longbons ---
There is DR2524 for the [0, 1) case. Otherwise, filing bugs there looks really
complicated.
I've given you a reproducer. That's as much as I'm capable of.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82542
--- Comment #9 from Ben Longbons ---
The ones I've filed are: #54533, #58150, #80466
But there are quite a few more at
https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=__open__&component=debug&list_id=190134&product=gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82542
--- Comment #7 from Ben Longbons ---
I saw that mailing list post, but it only explains *what*, not *why*.
I never really gave consideration to DWARF, since in my little experience it is
very unportable for a "standard". I suppose I could invest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82554
--- Comment #1 from Ben Longbons ---
Ugh, part of my explanation was wrong: it's not the difference of exponents,
it's the number of common bits between the min and the (inclusive) max. That
just happens to both be 1 bit when the (exclusive) max
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: b.r.longbons at gmail dot com
Target Milestone: ---
This is related to #64351 and #63176, for which a totally-bogus fix was
applied.
There is actually a defect in the standard: it requires
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71996
--- Comment #2 from Ben Longbons ---
It's now called -fdump-lang-raw, and for some reason it's only active in C++
mode (filed bug #82542).
But this bug is still present with those changes made.
: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: b.r.longbons at gmail dot com
Target Milestone: ---
With the refactoring to (sensibly I guess?) make it somehow language-specific,
it got dropped from the C FE, via which
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: b.r.longbons at gmail dot com
Target Milestone: ---
This worked with 4.7, but fails with 4.8 through 7.1.
Original reports on StackOverflow:
https://stackov
ty: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: b.r.longbons at gmail dot com
Target Milestone: ---
// BAD: g++-6 -std=c++0x -gusing-template.cpp -o using-template -gdwarf-4
// BAD: g++-6 -std=c++0x -gusing-template.cpp -o using-template -gd
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: b.r.longbons at gmail dot com
Target Milestone: ---
$ cat dump.c
#include
#include
char string1[] = "1string";
wchar_t string2[] = L"2string&quo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71334
--- Comment #3 from Ben Longbons ---
What I'm trying to do is:
* parse some source code from a new language I'm developing.
* Emit that to machine code via some backend (C, GCCJIT, LLVM, firm, etc.)
* Also emit a header file so that the library
ormal
Priority: P3
Component: jit
Assignee: dmalcolm at gcc dot gnu.org
Reporter: b.r.longbons at gmail dot com
Target Milestone: ---
Created attachment 38594
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38594&action=edit
Utility to print unde
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67941
Ben Longbons changed:
What|Removed |Added
CC||b.r.longbons at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64826
--- Comment #1 from Ben Longbons ---
Created attachment 34597
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34597&action=edit
test set 2, regressions on namespace merging (I don't understand this)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64826
--- Comment #2 from Ben Longbons ---
Created attachment 34598
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34598&action=edit
test set 3, regressions on namespace splitting
ormal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: b.r.longbons at gmail dot com
Created attachment 34596
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34596&action=edit
test set 1, regressions on namespace splitting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64626
--- Comment #1 from Ben Longbons ---
Demostration that gcc correctly preprocesses the other tokens:
#define JOIN(a, b) a##b
JOIN(.., .)
// error about pasting . and .
#define JOIN3(a, b, c) a##b##c
JOIN3(%:%, :, %:)
// successfully results in %
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: b.r.longbons at gmail dot com
Created attachment 34459
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34459&action=edit
informative testcase
During preprocessing, single quote (&#
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: b.r.longbons at gmail dot com
Created attachment 34429
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34429&action=edit
reduced testcase
The attached C++ code is illegal
: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: b.r.longbons at gmail dot com
good: Debian 4.6.4-7
bad: Debian 4.7.4-3
bad: Debian 4.8.3-11
bad: Debian 4.9.1-15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61038
--- Comment #8 from Ben Longbons ---
(In reply to Ed Smith-Rowland from comment #7)
> Note to self: you DO need to take care of char...
What about multi-char constants, or are they not permitted in C++ UDLs?
Normally they get converted to int, s
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: b.r.longbons at gmail dot com
The following valid program ICEs with g++ 4.9.0.
Previous versions (4.6.4, 4.7.3, 4.8.2) compile it just fine.
Older versions did not implement
++
Assignee: unassigned at gcc dot gnu.org
Reporter: b.r.longbons at gmail dot com
The following program is legal and compiles correctly. However, if preprocessed
only, the .ii file in invalid because it fails to escape the ""s
gcc 4.7, 4.8, and 4.9 all fail. Earlier versio
: enhancement
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: b.r.longbons at gmail dot com
It would be nice if GCC could remember if an "opaque" class contains a format
string.
The logical extension of this is that a fun
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58150
--- Comment #1 from Ben Longbons ---
Still present in gcc 4.9 as of 2014-03-22
Currently I'm hacking around this by using a gdb pretty printer that hard-codes
the enum values and turns them into strings, but that only works for printing,
not call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49604
--- Comment #2 from Ben Longbons ---
Still an issue with 4.9 as of 2014-03-22
: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: b.r.longbons at gmail dot com
Created attachment 30649
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30649&action=edit
minimal testcase
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: b.r.longbons at gmail dot com
Created attachment 30321
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30321&action=edit
minimal testcase
The attached reduced testcase
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54533
Bug #: 54533
Summary: breakpoint on C-style variadic function not hit at -O0
on amd64
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54433
Bug #: 54433
Summary: bogus -Wmissing-format-attribute warnings when "first
to check" is wrong
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONF
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53247
Bug #: 53247
Summary: [regression, c++11] can't use a function from a base
class of the same name in a different namespace
Classification: Unclassified
Product: gcc
Version: 4.7.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52114
--- Comment #5 from Ben Longbons 2012-02-04
22:36:54 UTC ---
(In reply to comment #2)
> Yesterday I was wondering: is there something in C++11 saying explicitly that
> these tricks are allowed,
In N3242, 14.8.2/{7,8}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52116
--- Comment #2 from Ben Longbons 2012-02-04
18:30:46 UTC ---
ah, got home where I have a bunch of versions ...
GCC < 4.6 fail with error: #pragma GCC diagnostic not allowed inside functions
GCC 4.6.{0,1,2}, branch-4.6 r183147, and trunk r182496
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52116
Bug #: 52116
Summary: pragma GCC diagnostic only acts on some lines
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Prio
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52114
Bug #: 52114
Summary: SFINAE out the rvalue iostream operators to give
better error messages
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51956
Bug #: 51956
Summary: [patch] improve shared_ptr and weak_ptr
pretty-printers for gdb
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51878
--- Comment #1 from Ben Longbons 2012-01-17
08:48:12 UTC ---
Created attachment 26348
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26348
variant of the testcase that compiles with gcc 4.6.{1,2}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51878
Bug #: 51878
Summary: ICE or OOM with decltype + variadic templates +
"indirect" function call
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONF
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51676
--- Comment #3 from Ben Longbons 2012-01-02
20:27:41 UTC ---
I'm not familiar with GCC internals, but would it be as easy as adding and
using a second field for "first declaration"?
If the first (possibly only) declaration is the definition, the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51706
Bug #: 51706
Summary: default copy assignment incorrectly deleted
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priori
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51677
Bug #: 51677
Summary: don't suggest giving main() __attribute__((const))
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51676
Bug #: 51676
Summary: -Wsuggest-attribute={pure,const} should give line
number of declaration, not definition
Classification: Unclassified
Product: gcc
Version: 4.7.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50593
Bug #: 50593
Summary: improve __attribute__((format(printf)))
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: enhancement
Prior
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50459
Bug #: 50459
Summary: alignof doesn't work on plain old constant, works with
expressions containing it
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50248
Bug #: 50248
Summary: gcc confused, tries to use variadic template to copy
itself when it should use default constructor
Classification: Unclassified
Product: gcc
Version: 4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45923
Ben Longbons changed:
What|Removed |Added
CC||b.r.longbons at gmail dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49604
Summary: forward-declared enum in class scope is private in
context of constexpr
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49571
Summary: -flto -Wl,--as-needed drops needed libraries
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
AssignedTo: unassig
51 matches
Mail list logo
