Hi Jeff,
On 14/01/19 17:43, Jeff Law wrote:
On 1/14/19 9:39 AM, Paolo Carlini wrote:
Hi,
On 14/01/19 17:28, Jakub Jelinek wrote:
I think several testcases check for duplicate error messages, the
regexp is
against the whole text, so you can just check if it occurs more than once
there.
This
Hi,
On 14/01/19 17:28, Jakub Jelinek wrote:
I think several testcases check for duplicate error messages, the regexp is
against the whole text, so you can just check if it occurs more than once
there.
This is essentially https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30612
Paolo.
Hi,
On 14/01/19 15:35, Jakub Jelinek wrote:
On Mon, Jan 14, 2019 at 03:15:05PM +0100, MCC CS wrote:
Thank you for the quick replies. I was inspired by
https://gcc.gnu.org/ml/gcc-help/2012-04/msg00223.html
but it seems, according to your comments, that was outdated.
So, I don't really see what
Hi,
On 09/10/18 15:33, Jonathan Wakely wrote:
On Tue, 9 Oct 2018 at 14:30, Paul Koning wrote:
I'm trying to build the current code on Linux with GCC 4.3.2 (stock compiler in
Fedora 10 which is my old test system). It fails like this:
In file included from
/mnt/hgfs/pkoning/Documents/svn/gc
Eh, eh,
the word pool can be a bit tricky with, say, memory allocators, but
spam-filtering out messages containing the word spa seems pretty safe to
me ;)
Paolo.
Hi,
On 13/06/2018 08:11, François Dumont wrote:
On 12/06/2018 23:26, Martin Sebor wrote:
Bootstrap fails in libstdc++ with the following error.
I haven't investigated it much except to take a peek
at recent libstdc++ commits where r261525 looks like it
introduced __glibcxx_check_can_increment_r
Hi,
On 24/03/2018 21:06, Volker Reichelt wrote:
Hi everybody,
while bug-hunting I noticed that we emit lots of erros in pairs in
check_final_overrider (cp/search.c), e.g.:
error ("invalid covariant return type for %q+#D", overrider);
error (" overriding %q+#D", basefn);
I would expect th
Hi,
On 16/08/2017 12:09, Daniel Langr wrote:
When compiling the following code:
int* ptr = nullptr;
delete ptr;
I didn't understand why we don't already handle the easy case:
constexpr int* ptr = nullptr;
delete ptr;
and the below tiny front-end tweak would take care of it. But I'm not
sure
Hi again,
On 26/04/2017 12:32, Paolo Carlini wrote:
Hi,
in 2013 (2013-09-16) Adam added two slightly obscure functions and I
can't find much around in terms of rationale, etc:
/* Returns true iff TYPE is a TEMPLATE_TYPE_PARM representing 'auto',
'decltype(auto)'
Hi,
in 2013 (2013-09-16) Adam added two slightly obscure functions and I
can't find much around in terms of rationale, etc:
/* Returns true iff TYPE is a TEMPLATE_TYPE_PARM representing 'auto',
'decltype(auto)' or a concept. */
bool
is_auto_or_concept (const_tree type)
{
return is_auto
Hi,
On 28/02/2016 00:29, David Mugnai wrote:
I was looking for an easy task to start contributing to gcc, so I
choose a "trivial" bug (69733) from this list (cited in an old message
of Manuel López-Ibáñez):
See:
https://gcc.gnu.org/ml/gcc-patches/2016-02/msg00720.html
Note that in any cas
Hi,
other bits. Tested x86_64-linux.
Thanks,
Paolo.
//
2015-07-28 Paolo Carlini
* call.c (build_op_delete_call, convert_like_real, build_over_call):
Use Use DECL_SOURCE_LOCATION and "%qD" in inform and pedwarn instead
Hi,
On 07/10/2015 03:42 PM, Jason Merrill wrote:
On 07/10/2015 07:26 AM, Paolo Carlini wrote:
I have an old question about an issue which I noticed a while ago, and
for example clearly shows up in c++/62085: in a few places in pt.c we
call complete_type from functions getting a tsubst_flags_t
Hi,
I have an old question about an issue which I noticed a while ago, and
for example clearly shows up in c++/62085: in a few places in pt.c we
call complete_type from functions getting a tsubst_flags_t. Clearly,
complete_type often calls instantiate_class_template_1, which, in turn,
often c
Hi,
On 03/26/2015 09:52 AM, Jakub Jelinek wrote:
On Thu, Mar 26, 2015 at 09:36:30AM +0100, Richard Biener wrote:
On Thu, Mar 26, 2015 at 1:10 AM, Paolo Carlini wrote:
sorry if I missed part of the discussion about the new numbering scheme and
the answer to my question is already clear from
Hi,
sorry if I missed part of the discussion about the new numbering scheme
and the answer to my question is already clear from that: why we do have
5.0 as Milestone in Bugzilla instead of 5.1?!?
Thanks,
Paolo.
Hi,
On 12/30/2014 11:59 PM, Francois-Xavier Le Bail wrote:
Hello,
in 'https://gcc.gnu.org/gcc-4.9/changes.html' there is a reference to
'-Wzerotrips'
Is this not '-Wzerotrip' without 's' ?
Thanks. Should be fixed now.
Paolo.
Hi,
On 11/10/2014 05:49 PM, Joel Sherrill wrote:
On 11/10/2014 10:32 AM, Joseph Myers wrote:
On Sat, 8 Nov 2014, Paolo Carlini wrote:
Good. Sorry, if I missed some relatively recent development: is now GCC
installing its own stdint.h on *all* the supported targets, thus we can safely
No; I
Hi,
On 11/08/2014 04:33 PM, Jonathan Wakely wrote:
On 8 November 2014 15:30, Joel Sherrill wrote:
This didn't compile. Ended with an error about requiring C++11 in a header
file. This code is in a c++98 subdirectory so it dues make sense. I can't cut
and paste it at home.
Yep, that makes sen
Hi,
On 11/07/2014 04:07 PM, Joel Sherrill wrote:
Hi
On m32c-rtems, we have a build error in C++ because size_t
is 16-bits and pointers are 24 bits. m32c-elf probably does not
enable __GTHREAD support like rtems does. Since this is code
shared across targets, what is the best way to fix this?
I
On 11/04/2014 04:46 PM, Paolo Carlini wrote:
Hi,
On 11/04/2014 04:32 PM, Jonathan Wakely wrote:
Not a big deal of course, but unfortunately today I'm seeing *two*
segfaults
for pb_ds:
performance/ext/pb_ds/multimap_text_insert_mem_large.cc
.../libstdc++-v3/scripts/check_performance: li
Hi,
On 11/04/2014 04:32 PM, Jonathan Wakely wrote:
Not a big deal of course, but unfortunately today I'm seeing *two* segfaults
for pb_ds:
performance/ext/pb_ds/multimap_text_insert_mem_large.cc
.../libstdc++-v3/scripts/check_performance: line 41: 16173 Segmentation
fault ./$EXE_NAME &>tmp
.. and also:
performance/ext/pb_ds/priority_queue_text_pop_mem.cc
.../libstdc++-v3/scripts/check_performance: line 41: 16905 Segmentation
fault ./$EXE_NAME &>tmp.$FILE_NAME
Paolo.
Hi again,
On 11/04/2014 05:34 AM, Jonathan Wakely wrote:
On 04/11/14 03:41 +, Jonathan Wakely wrote:
On 03/11/14 22:07 +, Jonathan Wakely wrote:
On 3 November 2014 17:51, Paolo Carlini
wrote:
.. other than the above issue, I see a segmentation fault for:
performance/ext/pb_ds
.. thanks a lot Jon! (after all this parallel mode is still useful for
something ;)
Paolo.
.. other than the above issue, I see a segmentation fault for:
performance/ext/pb_ds/multimap_text_insert_mem_large.cc
and a compile error for:
performance/ext/pb_ds/priority_queue_text_pop_mem.cc
which boils down to a an error at include/bits/stl_deque.h:519 (likely
pd_ds is misusing
Hi,
On 11/03/2014 03:55 PM, Rainer Emrich wrote:
Since the recent changes to the testsuites the folowing make targets in the
libstdc++ testsuite directory don't work anymore:
check-parallel
check-performance
check-performance-parallel
Any comments?
All I can see so far is a non-conforming use
Hi,
On 09/10/2014 04:39 PM, Hi-Angel wrote:
Below is a sample code to test. GCC with the option allegedly says
that the line «obj = {0};» isn't initializes «mystruct::b» member to
anything, although it really is.
struct mystruct{
int a;
int b[2];
};
int main(){
mystr
Hi,
On 08/06/2014 09:19 PM, David Gero wrote:
Wow. What an amazingly unintuitive widget. I looked all over the page
for a "Next 25 files" button. A "Go To" button that doesn't talk about
next 25 files meant nothing. ViewVC used to display all the files.
This is a giant leap backward in the Use
Hi,
On 08/06/2014 08:48 PM, paul_kon...@dell.com wrote:
On Aug 6, 2014, at 2:38 PM, David Gero wrote:
Accessing https://gcc.gnu.org/viewvc/gcc/trunk/
Says it is showing 38 files. But in fact, it shows only the first 25. As an
example, libstdc++-v3 is missing.
Same thing happens in other
Hi again,
On 08/01/2014 11:40 AM, Paolo Carlini wrote:
Hi,
is it known that the test is failing on many x86_64-linux targets?
FAIL: g++.dg/ipa/devirt-34.C -std=gnu++98 scan-ipa-dump devirt
"Targets that are not likely"
FAIL: g++.dg/ipa/devirt-34.C -std=gnu++11 scan-ipa-d
Hi,
is it known that the test is failing on many x86_64-linux targets?
FAIL: g++.dg/ipa/devirt-34.C -std=gnu++98 scan-ipa-dump devirt
"Targets that are not likely"
FAIL: g++.dg/ipa/devirt-34.C -std=gnu++11 scan-ipa-dump devirt
"Targets that are not likely"
FAIL: g++.dg/ipa/devirt-34.C -st
Hi,
is somebody already working on the regressions which appeared yesterday,
see:
https://gcc.gnu.org/ml/gcc-testresults/2014-05/msg01920.html
ie:
FAIL: g++.dg/ipa/devirt-15.C -std=gnu++98 scan-ipa-dump devirt "Speculatively
devirtualizing call"
FAIL: g++.dg/ipa/devirt-15.C -std=gnu++11
On 02/02/2014 05:18 PM, Iyer, Balaji V wrote:
Hi Paolo,
We are looking into this issue. Will let you know as soon as we find a
fix.
Ok, thanks a lot.
Paolo.
Hi,
today I'm seeing this testcase using a lot of cpu and eventually timing
out. Is it known?
Thanks,
Paolo.
On 01/30/2014 12:41 PM, Alangi Derick wrote:
GCC Version 4.9.0
email: alangider...@gmail.com
Index: gcc/README.Portability
===
--- gcc/README.Portability (revision 206579)
+++ gcc/README.Portability (working copy)
@@ -6,7
.. if you are willing to concretely help, please open a meta-bug with
"[meta-bug] thread_local" in the summary and blocked by all the issues
you mentioned.
Thanks,
Paolo.
Hi,
a couple of tsan tests:
c-c++-common/tsan/simple_race.c
g++.dg/tsan/default_options.C
relatively often fail for me at various optimization levels (eg, in my
last run the former at -O2: no WARNING: ThreadSanitizer... thus the test
failed).
Is this a known issue? The machine I'm t
On 12/07/2013 04:48 PM, H.J. Lu wrote:
Hi,
I have been seeing 3 libstdc++ tests:
FAIL: 17_intro/headers/c++200x/stdc+
+.cc (test for excess errors)
FAIL: 17_intro/headers/c++200x/stdc++_multiple_inclusion.cc (test for
excess errors)
FAIL: 30_threads/async/async.cc execution test
fail/pass at r
On 11/05/2013 01:36 PM, Florian Weimer wrote:
I've looked at optimizing dynamic_cast to final C++ class. In theory,
it should be possible to load the vtable pointer, compare it to the
expected value, and use the original pointer if it matches, or NULL
otherwise (for pointers, references are si
Hi,
these FAILs:
FAIL: g++.dg/guality/pr55665.C -O2 line 23 p == 40
FAIL: g++.dg/guality/pr55665.C -O3 -fomit-frame-pointer line 23 p == 40
FAIL: g++.dg/guality/pr55665.C -O3 -g line 23 p == 40
apparently are here to stay, at least on x86_64-linux... Seriusly, do we
know what's going on?
Hi
Gurvinder Singh ha scritto:
>Does gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-1ubuntu1) has the support
>for regex library ?
Nope, it doesn't. The implementation status page should be pretty clear about
that. 4.9.0 will, however, you are welcome to build snapshots/svn check outs
and give it a
On 10/06/2013 03:19 PM, Morwenn Ed wrote:
Ok, no problem then, here is the patch. And the changelog. I hope they
are ok, I have never properly submitted anything before.
Patch looks great to me, thanks. I'm applying it.
Thanks,
Paolo.
Hi,
Morwenn Ed ha scritto:
>Well, it never got to sign the copyright assignment.
Certainly you don't need an assignment for 3 lines of docs!
Paolo
Hi,
Morwenn Ed ha scritto:
>Three new papers were adopted at the Chicago meeting a few days ago:
>* [[deprecated]] attribute (N3760)
>* Sized deallocation (N3778)
>* Single-quotation-mark as a digit separator (N3481)
>
>Shouldn't the GCC C++1y/C++14 support page be modified to reflect these
>ad
.. patchlet worked for me. Thanks again!
Paolo.
On 10/02/2013 09:35 PM, Andrew MacLeod wrote:
ie, like this
And I'll check it in
Thanks. I'm bootstrapping while we speak. I'll let you know in a few
minutes.
Paolo.
Hi,
currently bootstrap is broken for me with errors of this kind:
/scratch/Gcc/svn-dirs/trunk/gcc/graphite-scop-detection.c: In function
‘void canonicalize_loop_closed_ssa(loop_p)’:
/scratch/Gcc/svn-dirs/trunk/gcc/graphite-scop-detection.c:1335:26:
error: ‘replace_exp’ was not declared in thi
Hi,
Jonathan Wakely ha scritto:
>On 1 October 2013 16:49, Paul Pluzhnikov wrote:
>>
>> Paolo, does attached patch look correct for trunk?
>
>There would need to be a corresponding _GLIBCXX_END_NAMESPACE_VERSION.
Indeed. Otherwise, if the patch passes testing (in the various configs) it's
cert
Hi,
On 09/06/2013 01:46 PM, Peter Bergner wrote:
On Fri, 2013-09-06 at 13:36 +0200, Paolo Carlini wrote:
. on x86_64-linux, this commit broke the build of that file:
http://gcc.gnu.org/ml/gcc-cvs/2013-09/msg00149.html
CC-ing Peter.
Can you try the patch that HJ suggested?
http
. on x86_64-linux, this commit broke the build of that file:
http://gcc.gnu.org/ml/gcc-cvs/2013-09/msg00149.html
CC-ing Peter.
Thanks,
Paolo.
.. looks like this is target/58269, which therefore affects
x86_64-linux too.
Paolo.
Hi
today the bootstrap is broken, some sort of infinite recursion. A quick
make gives the below.
Thanks,
Paolo.
/
libtool: compile: /home/paolo/Gcc/svn-dirs/trunk-build/./gcc/xgcc
-B/home/paolo/Gcc/svn-dirs/trunk-build/./gcc/
-B/home/paolo/Gcc/svn-dirs/trunk-install/x8
On 08/21/2013 05:00 PM, Paolo Carlini wrote:
... I went through the recent gcc-testresults posted by HJ, and the
only possible "culprit" seems this commit:
http://gcc.gnu.org/ml/gcc-cvs/2013-08/msg00492.html
Teresa, can you have a look?
I think it's just matter of removin
.. I went through the recent gcc-testresults posted by HJ, and the only
possible "culprit" seems this commit:
http://gcc.gnu.org/ml/gcc-cvs/2013-08/msg00492.html
Teresa, can you have a look?
Thanks,
Paolo.
On 08/21/2013 04:49 PM, Chung-Ju Wu wrote:
Looking into profopt.exp, 'dg-do' is not an expected dg- command. Is
there something wrong with your environment that some other testcases
with 'dg-do' inside are accidentally included in your tree-prof.exp
testing? :p
Maybe I'm simply not getting the
Hi,
and sorry for nitpicking, but lately when we run
g++.dg/tree-prof/tree-prof.exp we are all seeing a:
WARNING: profopt.exp does not support dg-do
(lots of examples in gcc-testresults). Any idea what's going wrong?
Thanks,
Paolo.
Hi,
On 08/20/2013 04:41 PM, David Malcolm wrote:
On Tue, 2013-08-20 at 14:03 +0200, Paolo Carlini wrote:
Hi,
sorry it the issue is by now well known but... I see many libstdc++-v3
regressions on at least x86_64-linux. When running the libstdc++-v3
testsuite (which uses PCHs) one gets tons of
Hi,
sorry it the issue is by now well known but... I see many libstdc++-v3
regressions on at least x86_64-linux. When running the libstdc++-v3
testsuite (which uses PCHs) one gets tons of new fails like the below.
That's annoying, a lot of confusing noise.
Thanks!
Paolo.
PS: CC-ing two "ran
Are you also a barman? I'm looking for a barman rather
On 06/13/2013 12:35 PM, Paolo Carlini wrote:
On 06/13/2013 12:28 PM, Paolo Carlini wrote:
Hi,
these FAILs are much more recent but frankly I'm also puzzled: is a
fix actively in the making? Do we have any sort of time for that?
This is PR57548 and a patch is approved but unapplied:
On 06/13/2013 12:28 PM, Paolo Carlini wrote:
Hi,
these FAILs are much more recent but frankly I'm also puzzled: is a
fix actively in the making? Do we have any sort of time for that?
This is PR57548 and a patch is approved but unapplied:
http://gcc.gnu.org/ml/gcc-patches/2013-06/msg
Hi,
these FAILs are much more recent but frankly I'm also puzzled: is a fix
actively in the making? Do we have any sort of time for that?
Thanks,
Paolo.
Hi,
I don't remember seeing this testcase pass and the FAILs clutter the
testsresults. Can we XFAIL it?
Thanks,
Paolo.
Oleg Smolsky ha scritto:
>Should I re-open the bug?
It's already fixed for 4.8.1 isn't it? As PR56834
Paolo
On 04/23/2013 11:26 PM, bd satish wrote:
Hi,
Here's a simple program:
#include
#include
int main()
{
std::vector vec;
count(vec.begin(), vec.end(), 0); // shouldn't this be std::count ?
}
The above compiles successfully, but I think it shouldn't. I expect a
message like "error: `co
Hi,
Jonathan Wakely ha scritto:
>But remember we no longer use __GXX_EXPERIMENTAL_CXX0X__ anyway, we
>check __cplusplus >= 201103L, and so within those chunks we could
>additionally check for some C++14 macro.
Right, forgot that. Great. The >= check we have got now makes things much
easier in
Hi again,
Paolo Carlini ha scritto:
>Hi,
>
>Gabriel Dos Reis ha scritto:
>
>>There appear to be two targets: C++14 and C++17. Personally, I am
>>inclined
>>to have CXX14 and CXX1Y, where CXX1Y is for the presumed C++17 target.
>
>This clarified - thanks -
Hi,
Gabriel Dos Reis ha scritto:
>There appear to be two targets: C++14 and C++17. Personally, I am
>inclined
>to have CXX14 and CXX1Y, where CXX1Y is for the presumed C++17 target.
This clarified - thanks - I'm wondering if it's safe to assume that the C++14
library is a superset of the C++1
Hi,
Jonathan Wakely ha scritto:
>We did, but at the time I was under the incorrect belief that C++14
>would be a TC like C++03. Dietmar and Alisdair both corrected me by
>pointing out it's going to be a new International Standard, not just a
>"bugfix" update to C++11.
Looks like you already ha
Hi,
Jonathan Wakely ha scritto:
>I'm starting to implement some new library features voted into C++14
>at the Bristol meeting and am wondering what feature check to use.
>
>Will there be a macro like _GXX_EXPERIMENTAL_CXX1Y__ to correspond to
>-std=c++1y?
Humm, I'm still traveling (and a bit ti
On 03/23/2013 03:44 AM, Joe Gottman wrote:
Does gcc 4.8 include the changes to decltype specified in N3276
(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3276.pdf)?
If not, can we expect these for 4.8.1?
Yes, in 4.8.1, Jason backported:
2013-03-22 Jason Merrill
N3276
PR
Alec Teal ha scritto:
>I'd like to know more about the bootstrapping phases in terms of why,
>how, why split it into the phases that exist, so forth but something
>detailed rather than a "how to" with some side-notes.
Just in case your are also curious about living Italian, often in such cases w
Hi,
I just noticed a broken link (in case the issue is trivial I may get
around to fixing it myself, but at the moment I don't know):
http://gcc.gnu.org/onlinedocs/gcc/X86-Built-in-Functions.html#X86-Built-in-Functions
(it appers twice)
Cheers,
Paolo.
Hi,
On 12/03/2012 04:54 PM, Nolen, Steven D wrote:
In the c++11 headers for the random number generation (random.h), the function
"discard" for the linear_congruential has been implemented in a very
inefficient manner.
As I mentioned when we optimized a while ago the discard member function
f
On 11/29/2012 06:30 PM, awarecons wrote:
FreeBSD 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:15:25 UTC
2012 r...@obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC
i386
chromium-23.0.1271.64_1 compiled perfectly.
But chromium-23.0.1271.91 fails:
Looks like you aren't building with cu
Hi,
>Thoughts?
Assuming that the new implementation will be available in time for 4.9, my
primary concern is that in the meanwhile running the libstdc++ testsuite will
be quite noticeably slower. Do you have some numbers?
Thanks,
Paolo
On 11/05/2012 02:09 PM, Ed Smith-Rowland wrote:
I sent this to the wrong list originally, apologies to those who get
it twice.
Actually, you originally sent it to the *right* list.
Paolo.
The problem is that with new costs and new code for inlining functions called
once
we end up inlining empty virutal function to itself hoping to kill it.
I am testing the following that makes us to give up in such a werid case.
Thanks!
Paolo.
Hi,
whoever a few days ago or so broke this test, can please either fix the
testcase, the compiler or just xfail for now the testcase itself, to
avoid everybody the waste of time?
If you want me to do go ahead with option 3 above, just let me know!
Thanks!
Paolo.
On 10/27/2012 10:58 PM, Sebastian Huber wrote:
On 27/10/12 15:16, Jonathan Wakely wrote:
On 27 October 2012 13:55, Peter A. Felvegi wrote:
I didn't find anything relevant in Bugzilla when searching for 'typedef
template'. Should I file a bug report?
If you've found what you think is a bug and
On 10/24/2012 03:42 PM, Andrew Sutton wrote:
.. right now I can't really check, but looks like 54912 & co
Hmm... is anybody actively working on this? It's breaking a lot of my
code. I'd take a stab at fixing this, but not for the next couple of
weeks.
It's a serious regression, thus will be defi
.. right now I can't really check, but looks like 54912 & co
Paolo
Hi,
Larry Evans ha scritto:
>The above was a private email I sent to Christopher. Since then,
>similar results were reported here:
>
> http://article.gmane.org/gmane.comp.compilers.clang.devel/24145
>
>So, I thought the g++ template implementors might be interested
>in figuring out why g++ is
.. let's add Jakub in CC, he knows those bits better than anyone else,
and I don't think they changed much lately anyway.
Paolo.
On 08/09/2012 12:00 AM, Johan Lundberg wrote:
The C++11 support page (http://gcc.gnu.org/gcc-4.7/cxx0x_status.html)
lists decltype support as 'Yes' but with reference only to the old
N3243.
Just a general clarification (maybe obvious, but who knows): when a
paper is listed on that page, it's jus
On 07/03/2012 10:10 PM, Daniel Krügler wrote:
Isn't there a similar problem with the long long related additions of
virtual function to IO/localization as in std::num_get and std::num_put?
Probably not, because, if I understand correctly what you are saying, we
have long long overloads in C++98
Hi,
On 07/03/2012 09:18 PM, Jason Merrill wrote:
2) Object layout changes to std::list and std::basic_string. For
these types, there is no way to both retain backward compatibility
with older C++98 code and conform to the C++11 standard. The best we
can hope for is to allow old code to coexi
Hi,
On 07/02/2012 07:24 PM, Richard Guenther wrote:
On Mon, Jul 2, 2012 at 7:00 PM, Jonathan Wakely wrote:
On 2 July 2012 17:43, Jeff Law wrote:
On 07/02/2012 10:26 AM, Michael Meeks wrote:
On Thu, 2012-06-14 at 15:14 +0200, Matthias Klose wrote:
While PR53646 claims that c++98 and c++11
Hi,
On 06/18/2012 06:01 PM, Michael Matz wrote:
Hi,
On Mon, 18 Jun 2012, Gabriel Dos Reis wrote:
Jeff, please note that the path that Michael took from what was said
ealier (in particular the quote he provided in his message) and the
conclusion of "enthusiasm for soname bump" is still a myste
Hi,
> Does this basically mean that compiling C++ code with GCC4.7 will be playing
> Russian roulette?
I don't know, I see pretty extreme statements around, which lately (maybe
because I'm getting older? ;) I do my best to avoid. In any case, 4.7.1 is
already out, whatever we do as regards to
Hi,
> On Fri, Jun 15, 2012 at 3:12 PM, James Y Knight wrote:
>
>> IMO, at the /very least/, libstdc++ should go ahead and change std::string
>> to be the new implementation. Once std::string is ABI-incompatible between
>> the modes, there's basically no chance that anyone would think that
>> lin
Hi,
It would be nice if there was a
-Wimplicit_bool
that was enabled in -Wall which complained about these sorts of
operations. In particular
it would warn any time a bool was implicitly promoted to an int.
first blush your message should be a Bugzilla PR, this way the request
doesn't ris
Hi,
On Mon, Mar 26, 2012 at 10:56 PM, Steven Bosscher wrote:
Hello,
This patch is one way to address PR44982. I see no good reason to
cgraph_finalize_compilation_unit if there were parse errors. As Richi
already pointed out, GCC traditionally has proceeded after parse
errors to preserve warnin
Hi,
On 03/19/2012 01:38 PM, Jonathan Wakely wrote:
2012/3/19 Jonathan Wakely:
2012/3/19 Paweł Sikora:
On Wednesday 14 of March 2012 12:22:41 Richard Guenther wrote:
GCC 4.7.0 Release Candidate available from gcc.gnu.org
A second release candidate for GCC 4.7.0 is available from
ftp://gcc.
On 03/02/2012 12:15 PM, Richard Guenther wrote:
The GCC 4.7 branch has been created and a first release candidate
is being prepared right now. The branch is closed for now.
Just be clear (I think the information could be useful in general):
mainline can be already considered open for Stage 1 co
On 12/24/2011 12:03 PM, Paolo Carlini wrote:
On 12/24/2011 11:59 AM, Jonathan Wakely wrote:
First of all I'd check http://gcc.gnu.org/gcc-4.7/changes.html#cxx
and see that I already added it ;-)
Oh indeed, now I remember it ;)
which reminds me, that probably, since we are mentionin
On 12/24/2011 11:59 AM, Jonathan Wakely wrote:
First of all I'd check http://gcc.gnu.org/gcc-4.7/changes.html#cxx and
see that I already added it ;-)
Oh indeed, now I remember it ;)
Paolo.
On 12/24/2011 03:04 AM, Miles Bader wrote:
What do people think... is this a better non-virtual-dtor warning?
In general this type of diagnostic issue isn't very difficult to work
on. First, I would recommend checking if we have a Bugzilla already open
about it, otherwise open one, clarifying w
On 12/06/2011 04:11 PM, Piotr Wyderski wrote:
Hello,
on gcc-4.6.2/x64/linux:
template inline string format(const string& fmt,
TA&&... args) {
string_formatter f;
f.format(fmt, std::forward(args)...);
return f.get_result();
}
results in:
error: no matchi
1 - 100 of 532 matches
Mail list logo
