http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57900
Gabriel Dos Reis changed:
What|Removed |Added
CC||gdr at gcc dot gnu.org
--- Comment #4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58239
--- Comment #12 from Gabriel Dos Reis ---
(In reply to Iain Sandoe from comment #10)
> also the gcc driver silently ignores -static-libstdc++.
Isn't this the problem?
> certainly, the -B options are passed when other gcc components are built (o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58239
--- Comment #9 from Gabriel Dos Reis ---
(In reply to Iain Sandoe from comment #8)
> note that the patch at:
>
> http://gcc.gnu.org/ml/gcc-patches/2013-08/msg01460.html
>
> is not quite enough to fix this on Darwin - since we use :
>
> %{stati
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58239
--- Comment #7 from Gabriel Dos Reis ---
(In reply to Eric Botcazou from comment #4)
> > OK, I see the emitted reference to 'operator delete', and I suspect I
> > have an idea of why the compiler generated this reference even though
> > it isn't u
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58239
--- Comment #6 from Gabriel Dos Reis ---
(In reply to Eric Botcazou from comment #4)
> > OK, I see the emitted reference to 'operator delete', and I suspect I
> > have an idea of why the compiler generated this reference even though
> > it isn't u
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58239
--- Comment #5 from Gabriel Dos Reis ---
(In reply to Andrew Pinski from comment #3)
> (In reply to Gabriel Dos Reis from comment #2)
> > OK, I see the emitted reference to 'operator delete', and I suspect I
> > have an idea of why the compiler ge
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58239
--- Comment #2 from Gabriel Dos Reis ---
OK, I see the emitted reference to 'operator delete', and I suspect I
have an idea of why the compiler generated this reference even though
it isn't used anywhere in the input source code.
Why are we linki
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58239
--- Comment #1 from Gabriel Dos Reis ---
Here is the definition of pretty_printer::~pretty_printer ()
at the location indicated:
pretty_printer::~pretty_printer ()
{
buffer->~output_buffer ();
XDELETE (buffer);
}
The macro XDELETE is define
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57997
--- Comment #3 from Gabriel Dos Reis ---
Also, there might be some interactions with move semantics; I don't know.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57997
--- Comment #2 from Gabriel Dos Reis ---
(In reply to Paolo Carlini from comment #1)
> Gaby, can you help me with this?
I think this is typical confusion about what valarray expressions are.
f1() has some complicated return type that has essenti
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57974
--- Comment #11 from Gabriel Dos Reis ---
(In reply to Paolo Carlini from comment #10)
> Gaby, do you have an opinion on this? Irrespective of the long double issue,
> do you want me to re-enable (contra LWG 844) the pow(const complex<>&, int)
> o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49022
--- Comment #30 from Gabriel Dos Reis ---
(In reply to Paolo Carlini from comment #27)
> DR2058 is now WP, thus we are supposed to reassess this. Now, according to
> the resolution, additional 'begin' and 'end' overloads shall *not* be added,
> th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11582
--- Comment #10 from Gabriel Dos Reis 2013-04-23
03:45:56 UTC ---
(In reply to comment #9)
> (In reply to comment #8)
> > Printing int[] or int[size_t] would be confusing too.
>
> More confusing than int[(((sizetype)) + 1)] ?
>
> What about?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11582
--- Comment #8 from Gabriel Dos Reis 2013-04-22
10:10:36 UTC ---
(In reply to comment #7)
> The '[(((sizetype)) + 1)]' is just awful. If we don't know the
> actual type there, that is "int [size()]", then we should just print 'int []'
> o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54401
Gabriel Dos Reis changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54401
Bug #: 54401
Summary: Missing diagnostics about type-alias at class scope
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: major
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52863
Bug #: 52863
Summary: Enable -Wall by default
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Comp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200
Gabriel Dos Reis changed:
What|Removed |Added
CC||gdr at gcc dot gnu.org
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50880
--- Comment #18 from Gabriel Dos Reis 2011-11-02
12:48:47 UTC ---
(In reply to comment #16)
> Well, I guess this would be most of it:
>
> template
> std::complex<_Tp>
> __complex_acosh(const std::complex<_Tp>& __z)
> {
> retu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50880
--- Comment #17 from Gabriel Dos Reis 2011-11-02
12:48:23 UTC ---
(In reply to comment #16)
> Well, I guess this would be most of it:
>
> template
> std::complex<_Tp>
> __complex_acosh(const std::complex<_Tp>& __z)
> {
> retu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50880
--- Comment #14 from Gabriel Dos Reis 2011-11-02
12:27:20 UTC ---
(In reply to comment #9)
> Created attachment 25654 [details]
> BC2
Since we are talking about branch cut and prespectiving
since zeros, I think we should avoid the
the arithmeti
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50880
Gabriel Dos Reis changed:
What|Removed |Added
CC||gdr at gcc dot gnu.org
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48365
Gabriel Dos Reis changed:
What|Removed |Added
CC||gdr at gcc dot gnu.org
--- Comment #5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49022
--- Comment #25 from Gabriel Dos Reis 2011-06-14
14:01:30 UTC ---
(In reply to comment #23)
> Ok, now I see, it's the operator[] of _BinBase which returns by value, I
> overlooked that.
Yes, "val" in "valarray" stands for "value", e.g. a valarr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49022
--- Comment #24 from Gabriel Dos Reis 2011-06-14
13:54:13 UTC ---
(In reply to comment #18)
> It should be identical to
>
> auto&& range = v1 + v2;
> for (auto b = std::begin(range), e = std::end(range); b != e; ++b)
> { ... }
> (see 6.5.4 [s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49022
--- Comment #12 from Gabriel Dos Reis 2011-05-17
16:23:37 UTC ---
(In reply to comment #10)
> For sure that works.
>
> Gaby, just to make sure we are on the same page: did you send a message to the
> reflector about this issue already? Or do you
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49022
--- Comment #13 from Gabriel Dos Reis 2011-05-17
16:24:57 UTC ---
(In reply to comment #11)
> All in all, now that I understand the issue with the temporary, this seems
> really sort of a NAD, maybe the wording needs only clarifying that you don'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49022
--- Comment #7 from Gabriel Dos Reis 2011-05-17
15:14:04 UTC ---
(In reply to comment #6)
> Double Sigh! I was hoping very few overloads would be enough... If we are
> really talking about many I would be in favor of raising the issue, indeed.
T
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49022
Gabriel Dos Reis changed:
What|Removed |Added
CC||gdr at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48760
--- Comment #30 from Gabriel Dos Reis 2011-04-29
23:52:32 UTC ---
(In reply to comment #29)
> This is now fixed in 4_6-branch too in C++03 mode, not in C++0x mode, where we
> would need list-initialization of __complex__. If people believe we ca
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48760
--- Comment #14 from Gabriel Dos Reis 2011-04-26
14:12:35 UTC ---
(In reply to comment #12)
> (In reply to comment #9)
> > I guess, in the 4.6.1 time frame we can only workaround the issue in C++03
> > mode
> > by doing the piecewise work in the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48760
Gabriel Dos Reis changed:
What|Removed |Added
CC||jason at redhat dot com
--- Comment #1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48760
Gabriel Dos Reis changed:
What|Removed |Added
CC||gdr at gcc dot gnu.org
--- Comment #8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48101
Summary: obscure error message with std::set
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig.
||2010.12.16 23:22:09
CC||gdr at gcc dot gnu.org
Ever Confirmed|0 |1
--- Comment #1 from Gabriel Dos Reis 2010-12-16
23:22:09 UTC ---
I agree that we should diagnose this case.
35 matches
Mail list logo
