https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91733
--- Comment #7 from Akim Demaille ---
Personally the bug I reported was the one you fixed. I merely suggested to
drop \r, but I did asked for that. So AFAIC, you may close this issue.
Thanks a lot for the fix!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98899
--- Comment #2 from Akim Demaille ---
Created attachment 50094
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50094=edit
simple.ii
simple.cc preprocessed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98899
--- Comment #1 from Akim Demaille ---
Created attachment 50093
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50093=edit
simple.cc
The source that causes the crash.
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: akim.demaille at gmail dot com
Target Milestone: ---
G++ behaves randomly on this issue. Sometimes it gives me an error message
that does not seem to be meant fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98753
--- Comment #9 from Akim Demaille ---
Hi Martin,
Thanks for the detailed explanation.
(In reply to Martin Sebor from comment #5)
> Changing this message alone to say "free() may be called with non-heap
> object" wouldn't be appropriate without
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98753
--- Comment #8 from Akim Demaille ---
Hi Richard,
(In reply to Richard Biener from comment #3)
> The issue is that we isolate a path that is impossible to take but on that
> path we have p = free (p); and thus a "proved" mistake. But in
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98753
Akim Demaille changed:
What|Removed |Added
CC||akim.demaille at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92008
--- Comment #22 from Akim Demaille ---
FWIW, the version in the glibc was updated to use "%parse-params" and "%define
api.pure full" five years ago.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92008
--- Comment #18 from Akim Demaille ---
WRT to "pure-parser", there seems to be some misunderstanding. News of 3.4
says:
The %pure-parser directive is deprecated in favor of '%define api.pure'
since Bison 2.3b (2008-05-27), but no warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92008
--- Comment #17 from Akim Demaille ---
Hi Jakub,
I'm not claiming you should require 3.0, I'm claiming there's no reason to
target 1.35, there is no evidence there's a need for it. So there's no reason
to pay for "PARSE_PARAMS" support.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92008
--- Comment #15 from Akim Demaille ---
Sorry to insist, but I don't understand all these complications. Bison has
been supporting %parse-param for 17 years.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92008
Akim Demaille changed:
What|Removed |Added
CC||akim.demaille at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91733
--- Comment #3 from Akim Demaille ---
That you want to still support \r is one thing. That you discard my point
about the fact that as a consequence GCC fails to generate proper diagnostics
is something entirely different.
++
Assignee: unassigned at gcc dot gnu.org
Reporter: akim.demaille at gmail dot com
Target Milestone: ---
The documentation indexes the option with the leading `-`, contrary to the rest
of the documentation.
See
https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/Option-Index.html#Option
: c
Assignee: unassigned at gcc dot gnu.org
Reporter: akim.demaille at gmail dot com
Target Milestone: ---
Hi!
Long long ago, MacOS Classic used '\r' as end-of-line, and since then GCC
accepts \n, \r, and \r\n as means to denote end-of-line.
Today's tools that show line
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90034
Akim Demaille changed:
What|Removed |Added
CC||akim.demaille at gmail dot com
++
Assignee: unassigned at gcc dot gnu.org
Reporter: akim.demaille at gmail dot com
Target Milestone: ---
One would expect this to work:
$ cat /tmp/foo.cc
namespace a::b __attribute__ ((visibility ("protected")) {}
$ g++-mp-7 -std=c++17 /tmp/foo.cc
/tmp/foo.cc:1:16: error
++
Assignee: unassigned at gcc dot gnu.org
Reporter: akim.demaille at gmail dot com
Target Milestone: ---
Hi,
This seems to be different from #55874 and #60350, but I might be wrong. The
caret-display makes it particularly visible. This affects GCC 4.9, 5.4.0,
6.3.0
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: akim.demaille at gmail dot com
Target Milestone: ---
In the following piece of code GCC issues a spurious warning about an exception
that escapes a dtor, although it is actually caught.
Observed with GCC 6 and 7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47226
--- Comment #11 from Akim Demaille ---
The project I work on has this:
auto const f = std::bind(::operator (),
, std::ref(args)...);
instead of a simple lambda.
--- Comment #12 from Akim Demaille ---
The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47226
--- Comment #11 from Akim Demaille ---
The project I work on has this:
auto const f = std::bind(::operator (),
, std::ref(args)...);
instead of a simple lambda.
++
Assignee: unassigned at gcc dot gnu.org
Reporter: akim.demaille at gmail dot com
Target Milestone: ---
Hi!
When compiling C, -Wcpp can be controlled by the diagnostics pragmas, but not
in C++ mode.
$ cat bar.c
#pragma GCC diagnostic ignored "-Wcpp"
#warning Foo
int i;
$ gcc-mp-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79021
--- Comment #1 from Akim Demaille ---
Also observed with GCC 7.
$ g++-mp-7 -std=c++14 foo.cc -Wreturn-type
foo.cc: In lambda function:
foo.cc:21:38: warning: no return statement in function returning non-void
[-Wreturn-type]
auto g = [](auto
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: akim.demaille at gmail dot com
Target Milestone: ---
When a generic lambda calls a function templates declared noreturn, we still
get warnings about missing return values.
$ cat foo.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69481
Akim Demaille changed:
What|Removed |Added
CC||akim.demaille at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47226
--- Comment #8 from Akim Demaille ---
I'm hit too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54075
--- Comment #49 from Akim Demaille ---
It looks like this story is missing an end.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54075
Akim Demaille changed:
What|Removed |Added
CC||akim.demaille at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54430
Akim Demaille akim.demaille at gmail dot com changed:
What|Removed |Added
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54430
--- Comment #5 from Akim Demaille akim.demaille at gmail dot com ---
FWIW, it's on StackOverflow since May 2013.
http://stackoverflow.com/questions/16407212/identifier-with-the-same-name-in-both-expression-and-declaration-of-range-based
++
Assignee: unassigned at gcc dot gnu.org
Reporter: akim.demaille at gmail dot com
While tracking a spurious warning about at 0 instead of nullptr, I stumbled on
the following case, where g++ is spitting its warning too many times (4.9 and
5).
struct foo
{
foo(void* = 0) {}
void
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: akim.demaille at gmail dot com
template typename T
void fun(T, void* = 0) {}
int main()
{
fun(0);
}
g++-mp-5 -O3 -Wzero-as-null-pointer-constant foo.cc
foo.cc: In function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61386
--- Comment #2 from Akim Demaille akim.demaille at gmail dot com ---
Well, I never hacked in GCC. I can try, time permitting...
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: akim.demaille at gmail dot com
Hi,
I'm toying with templates and enable_if to try to enforce commutativity on some
operator. In the course of these experiments, I fell on the following
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58972
--- Comment #4 from Akim Demaille akim.demaille at gmail dot com ---
Could someone confirm this bug? The 4.9 I have does not ICEs and still refuses
both sources.
akim@erebus /tmp $ g++-mp-4.9 --version
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51253
--- Comment #15 from Akim Demaille akim.demaille at gmail dot com ---
(In reply to Jonathan Wakely from comment #13)
(In reply to Akim Demaille from comment #10)
auto t = std::make_tuple(incr(), incr());
That's not an initializer-list
: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: akim.demaille at gmail dot com
Hi,
This is cosmetic only, but the error message for missing headers provides a
location is past the error.
akim@erebus /tmp $ g++-mp-4.9 foo.cc
foo.cc:2:20: fatal error: stexcept
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51253
--- Comment #10 from Akim Demaille akim.demaille at gmail dot com ---
Well, I have finally found a simple workaround for some of the cases: GCC seems
to be right in the order of evaluation when initializing an array so:
templateint... IS
int f1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51253
--- Comment #7 from Akim Demaille akim.demaille at gmail dot com ---
Hi all,
I'd really love to have some feedback on this issue. It looks like nobody is
having a look at this.
Thanks for all the good work, and sorry for insisting.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51253
--- Comment #6 from Akim Demaille akim.demaille at gmail dot com ---
FWIW, because of this issue, I no longer use g++ for my project, which saddens
me. If there were a means to put money on some bugs, I'd be happy to drop say
$50. I do
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51253
--- Comment #5 from Akim Demaille akim.demaille at gmail dot com ---
Happy two-year birthday, bug! Sorry I'm (slightly more that) off-by-one.
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: akim.demaille at gmail dot com
Hi all,
Below, GCC forgets to check the accessibility of type, which
turns out to be private:
$ cat foo.cc
class foo
{
typedef int type;
};
template typename T
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: akim.demaille at gmail dot com
Hi,
Again, I have found no clear wording in the draft of the standard that I have,
however, consistency in the language would expect that using to import
constructors should provide them
++
Assignee: unassigned at gcc dot gnu.org
Reporter: akim.demaille at gmail dot com
Hi all,
Again, this problem report might be bogus. IANALL and reading the proposed
standard did not really help me understand if the problem is in the compiler,
or in the eye of the beholder.
Anyway, I
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: akim.demaille at gmail dot com
Hi friends,
I could not find an example of a use of the attributes for namespaces. It is
mentioned in the text body, but there is no example of the syntax (it appears
for the documentation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58724
--- Comment #2 from Akim Demaille akim.demaille at gmail dot com ---
Hi Paolo,
Sorry, I don't have a checked out version of the GCC. I'll
try to make one tomorrow.
Please, note that I was also mentioning the fact that the documentation
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: akim.demaille at gmail dot com
The following piece of code works with 4.8, clang 3.3 and 3.4, but not 4.9. I
expect the code to be right, and 4.9 to be wrong, but even if it were the
converse
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: akim.demaille at gmail dot com
Hi all,
It's a detail, agreed, but below the location for the error could use
improvement:
$ cat parameter-pack.cc
template typename... A, typename... B
struct foo
{};
With g++-mp-4.9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51253
Akim Demaille akim.demaille at gmail dot com changed:
What|Removed |Added
CC
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: akim.demaille at gmail dot com
The node about Options to Control Diagnostic Messages Formatting seems to be
named Language Independent Options (or something is wrong with the structure
++
Assignee: unassigned at gcc dot gnu.org
Reporter: akim.demaille at gmail dot com
Hi!
I meant to use [[noreturn]] instead of __attribute__((noreturn)) (as it is my
understanding from reading http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53528
that it was meant to be so (but maybe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57374
--- Comment #2 from Akim Demaille akim.demaille at gmail dot com ---
Hi Paolo,
I have tried to put it in about every possible place, and the one I used in the
attached example is the one from
http://www.open-std.org/jtc1/sc22/wg21/docs/papers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57374
--- Comment #3 from Akim Demaille akim.demaille at gmail dot com ---
Also, FWIW, libstdc++ headers use __attribute__((noreturn)), so there's no way
to get some inspiration from there :)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57374
--- Comment #5 from Akim Demaille akim.demaille at gmail dot com ---
Apologies :( I really thought my 4.9 was young enough.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41933
Akim Demaille akim.demaille at gmail dot com changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53631
Akim Demaille akim.demaille at gmail dot com changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53631
--- Comment #11 from Akim Demaille akim.demaille at gmail dot com ---
Sorry, I didn't mean to be harsh, and I did try to propose a solution. I can
easily guess that there is no reason for it to be easy or even possible, but
can't Boost people
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56976
--- Comment #2 from Akim Demaille akim.demaille at gmail dot com ---
Maybe I don't know, even after having read several times the section you
pointed me to. In particular I see nothing there which could explain why using
foo() instead of foo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57053
Bug #: 57053
Summary: inaccurate message for ambiguous calls when in fact
there is not valid candidate
Classification: Unclassified
Product: gcc
Version: 4.8.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56976
Bug #: 56976
Summary: using braces to initialize a reference forces copy
construction
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56922
Bug #: 56922
Summary: set: the default constructor should be explicit
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56922
--- Comment #1 from Akim Demaille akim.demaille at gmail dot com 2013-04-11
16:08:07 UTC ---
FWIW: http://cplusplus.github.io/LWG/lwg-active.html#2193
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56922
--- Comment #3 from Akim Demaille akim.demaille at gmail dot com 2013-04-11
16:23:57 UTC ---
Agreed. Sorry for the noise, I was not aware of this page.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56722
Bug #: 56722
Summary: C++11: syntax error in for loop ends in SEGV
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56373
Bug #: 56373
Summary: -Wzero-as-null-pointer-constant: does not catch issues
with smart pointers
Classification: Unclassified
Product: gcc
Version: 4.8.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56373
--- Comment #2 from Akim Demaille akim.demaille at gmail dot com 2013-02-18
12:52:46 UTC ---
Thanks a lot for the detailed answer.
The warning isn't issued when 0 converts to std::nullptr_t, only when it
converts to a pointer type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56373
--- Comment #4 from Akim Demaille akim.demaille at gmail dot com 2013-02-18
13:23:08 UTC ---
If you're smart enough to know the object isn't used then don't create it :)
:) :) :)
~shared_ptr() has non-trivial side-effects
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55962
Bug #: 55962
Summary: improper location for static_assert
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: minor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55222
Bug #: 55222
Summary: weird unstable array subscript is above array bounds
warning
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54164
Bug #: 54164
Summary: C++11: confusion error messages for spurious
typename
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53838
--- Comment #4 from Akim Demaille akim.demaille at gmail dot com 2012-07-19
13:16:23 UTC ---
Hi People,
I have therefore reported this to MacPorts, see
http://trac.macports.org/ticket/35070 . The outcome is that (i) with
--enable-fully-dynamic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53863
Bug #: 53863
Summary: misleading error message for redefinitions
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53838
Bug #: 53838
Summary: _GLIBCXX_DEBUG and empty ostringstream
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: normal
Priority:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53540
--- Comment #2 from Akim Demaille akim.demaille at gmail dot com 2012-06-11
17:27:13 UTC ---
(In reply to comment #1)
I think it's valid, CC'ing Dodji for confirmation.
Any news?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53610
Bug #: 53610
Summary: C++11: constructors accept silly initializers
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53551
Bug #: 53551
Summary: -Wunused-local-typedefs misses uses
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53551
--- Comment #1 from Akim Demaille akim.demaille at gmail dot com 2012-06-01
12:24:44 UTC ---
Created attachment 27539
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27539
Test case
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53553
Bug #: 53553
Summary: misleading locations for error in initializers
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53540
Bug #: 53540
Summary: C++11: using fails to be equivalent to typedef
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52949
Bug #: 52949
Summary: decltype too sensitive to order of declarations?
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52806
Bug #: 52806
Summary: bogus zero as null pointer constant warning
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52806
--- Comment #4 from Akim Demaille akim.demaille at gmail dot com 2012-03-31
14:12:00 UTC ---
(In reply to comment #1)
Oh well, changing this would be really trivial, but then people would have to
globally switch-on -std=c++11 (which may
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52806
--- Comment #5 from Akim Demaille akim.demaille at gmail dot com 2012-03-31
14:26:27 UTC ---
(In reply to comment #4)
I don't think this comment makes sense: with what would you want them
to replace these 0, since nullptr is not available
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52718
Bug #: 52718
Summary: -Wzero-as-null-pointer-constant: misleading location
for 0 as default argument
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52620
Bug #: 52620
Summary: using cannot import types in (non direct) base classes
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52620
--- Comment #2 from Akim Demaille akim.demaille at gmail dot com 2012-03-19
16:16:37 UTC ---
(I pasted the wrong bug report, I meant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21484)
(In reply to comment #1)
template typename T
struct bot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51971
Bug #: 51971
Summary: unclear/unverified restrictions on
attribute((const|pure))
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
87 matches
Mail list logo
