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&action=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&action=edit
simple.cc
The source that causes the crash.
tus: UNCONFIRMED
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 doe
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 = &foo; 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://sourceware.org/git/?p=glibc.git;a=blob_plain;f=intl/plural.y;hb=6d248857845aee307440a770
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 wa
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.
"%requ
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
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, and
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(&Rpc::operator (),
&rpc, std::ref(args)...);
instead of a simple lambda.
--- Comment #12 from Akim Demaille ---
T
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(&Rpc::operator (),
&rpc, 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
--- Comment #5 from Akim Demaille ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54430
Akim Demaille changed:
What|Removed |Added
CC||akim.demaille at gmail dot com
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: akim.demaille at gmail dot com
template
void fun(T, void* = 0) {}
int main()
{
fun(0);
}
g++-mp-5 -O3 -Wzero-as-null-pointer-constant foo.cc
foo.cc: In function 'void
++
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61386
--- Comment #2 from Akim Demaille ---
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 foll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58972
--- Comment #4 from Akim Demaille ---
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
13:12:11
g++-mp-4.9 (MacPor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51253
--- Comment #15 from Akim Demaille ---
(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, it's a function call, so the
: 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: No such
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51253
--- Comment #10 from Akim Demaille ---
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:
template
int f1()
{
int i = 0;
swallow{ i = 10 * i +
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51253
--- Comment #7 from Akim Demaille ---
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 ---
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 not pretend that should suffice, but may
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51253
--- Comment #5 from Akim Demaille ---
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
: 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
nt: c++
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.
Anyw
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58724
--- Comment #2 from Akim Demaille ---
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
is not sufficiently clear, IMHO.
: 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 of
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
struct foo
{};
With g++-mp-4.9:
parameter-pack.cc:2:8:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51253
Akim Demaille changed:
What|Removed |Added
CC||akim.demaille at gmail dot com
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 wron
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57374
--- Comment #5 from Akim Demaille ---
Apologies :( I really thought my 4.9 was young enough.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57374
--- Comment #3 from Akim Demaille ---
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 #2 from Akim Demaille ---
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/2008/n2761.pdf which is
cited in h
++
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=53631
--- Comment #11 from Akim Demaille ---
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 be asked if they'd contribute?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53631
Akim Demaille changed:
What|Removed |Added
CC||akim.demaille at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41933
Akim Demaille changed:
What|Removed |Added
CC||akim.demaille at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56976
--- Comment #2 from Akim Demaille ---
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{} would give different results.
FW
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
Statu
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: UNCON
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56922
--- Comment #3 from Akim Demaille 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=56922
--- Comment #1 from Akim Demaille 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
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=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
--- Comment #4 from Akim Demaille 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, the compiler isn't smart enough to
> d
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56373
--- Comment #2 from Akim Demaille 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.
And shouldn't it?
>> It's
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
St
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
Prio
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: UNCONF
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
S
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53838
--- Comment #4 from Akim Demaille 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-string fails to build on MacPor
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
Pr
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: P
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53540
--- Comment #2 from Akim Demaille 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
Prio
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
Pri
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53551
--- Comment #1 from Akim Demaille 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=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=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
Pri
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
P
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52806
--- Comment #5 from Akim Demaille 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?
This does not read like I meant,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52806
--- Comment #4 from Akim Demaille 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 not be otherwise appropriate) while
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
Prio
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
--- Comment #2 from Akim Demaille 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
> struct bot: med
> {
> using top::type;
>
> This is
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=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