On 22 October 2014 02:46, Chen Gang wrote:
>
>
> On 10/15/14 18:07, Chen Gang wrote:
>> On 10/13/14 21:18, Chen Gang wrote:
>>> On 10/13/14 18:53, Jason Merrill wrote:
On 10/12/2014 10:32 AM, Chen Gang wrote:
>[root@localhost qemu_cc]# cat test.cc
>const char n() { return 1; }
On 22 October 2014 16:15, Martin Liška wrote:
> Hello.
>
> I've been playing with following example:
>
> #include
>
> class Base
> {
> public:
> virtual ~Base() {}
> };
>
> class Derived: public Base
> {
> };
>
> #define N 1000
>
> int main()
> {
> Base **b = (Base **)malloc (sizeof(Base *) *
On 22 October 2014 17:16, Martin Liška wrote:
> On 10/22/2014 05:30 PM, Jonathan Wakely wrote:
>>
>> On 22 October 2014 16:15, Martin Liška wrote:
>>>
>>> Hello.
>>>
>>> I've been playing with following example:
>>>
>&g
On 27 October 2014 13:10, Joseph S. Myers wrote:
> On Sat, 25 Oct 2014, Martin Uecker wrote:
>
>> Strictly speaking the C standard considers such pointers to be
>> incompatible. This seems to be an unintentional consequence
>> of how qualifiers are always attached to the element type.
>> (I am tryi
On 28 October 2014 09:33, Alex Markin wrote:
> Hello, everyone.
>
> I have a question about "One definition rule" for classes in different
> translation units and gcc behaviour. Let us have the following
> program:
Your question is off topic on this mailing list, which is for
discussing developmen
On 28 October 2014 19:36, Toon Moene wrote:
> On the gcc-results archive, you'll see this:
>
> https://gcc.gnu.org/ml/gcc-testresults/2014-10/msg02983.html
>
> but that doesn't show you the real problem:
>
> mkdir -p -- /home/toon/compilers/install/share/gcc-5.0.0/python/libjava
> libtool: install:
On 31 October 2014 06:51, Phil Muldoon wrote:
> On 30/10/14 21:47, Gerald Pfeifer wrote:
>> Now the error is gone on my nightly FreeBSD test systems,
>> I am getting the following:
>>
>> In file included from /scratch2/tmp/gerald/gcc-HEAD/libcc1/plugin.cc:58:
>> In file included from /usr/include/
On 3 November 2014 09:18, Jakub Jelinek wrote:
> Status
> ==
>
> The trunk is scheduled to transition from Stage 1 to Stage 3 at the end
> of Saturday, November 15th (use your timezone to your advantage).
>
> We have been in Stage 1 for almost 7 months now with a fortnight
> still to go. Still
On 3 November 2014 17:51, Paolo Carlini wrote:
> .. 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 err
On 3 November 2014 17:51, Paolo Carlini wrote:
> .. 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 err
something else (too) in your terse message,
tough.
has the same problem, fixed with this patch.
commit 356183f393d2fce9beb5b2d4772b9f8ab83280cd
Author: Jonathan Wakely
Date: Tue Nov 4 03:33:07 2014 +
* include/parallel/numeric.h: Do not use default arguments in function
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/multimap_text_insert_mem_large.cc
and a compile error for:
performance/ext/pb_ds
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/multimap_text_insert_mem_large.cc
Fixed like so.
commit
On 4 November 2014 13:13, Paolo Carlini wrote:
> 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:
>>>>
&g
On 4 November 2014 16:34, Paolo Carlini wrote:
> Ah! The testsuite_allocator.h fix of yours is still unapplied, didn't know
> that, sorry ;)
My bad - I thought I'd committed it! Done now.
On 7 November 2014 16:56, Joel Sherrill wrote:
>
> On 11/7/2014 9:25 AM, Paolo Carlini wrote:
>> 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
>>> e
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 sense, I'd just stick with stdint.h
On 10 November 2014 16:49, Joel Sherrill wrote:
> I just submitted a patch using stdint.h and uintptr_t to gcc-patches.
libstdc++ patches must be CCd to the libstdc++ list.
Hi Frédéric,
At some point GCC's bugzilla started taking ages to load, because
every single .css and .js file gets a query appended to the URL:
skins/contrib/Dusk/global.css?1368269827
This causes Firefox to constantly re-fetch those pages again and
again, so it takes several seconds to load eve
On 11 November 2014 19:45, Frédéric Buclin wrote:
> Le 11. 11. 14 20:11, Jonathan Wakely a écrit :
>> At some point GCC's bugzilla started taking ages to load, because
>> every single .css and .js file gets a query appended to the URL:
>>
>> skins/contrib/Dusk/
On 13 November 2014 10:45, Richard Biener wrote:
>
> Hmm.
>
> struct assign;
> struct base {
> operator assign *() const { return (assign *)this; }
> };
> struct assign : base {
> };
>
> void foo (assign *);
> void bar (base *b)
> {
> foo (b);
> }
>
> doesn't work, but
>
> void bar (base &b)
>
On 16 November 2014 at 15:51, H.J. Lu wrote:
> Hi,
>
> Git tags are missing for GCC 4.9.1, 4.9.2, 4.8.3 and 4.7.4.
I can't create the tags but these are the release commits:
git tag gcc-4_9_2-release c1283af40b65f1ad862cf5b27e2d9ed10b2076b6
git tag gcc-4_9_1-release c6fa1b412663593960e6240eb66d82
On 30 November 2014 at 19:47, Ryan Nicholl wrote:
> I was not able to register on the bug tracker, so I am posting a
> couple feature requests here, I hope someone can repost them for me.
If you sent an email asking for the account to be created then it will
get done shortly.
If you didn't send a
On 12 December 2014 at 23:38, Kendrick Hamilton wrote:
> Hello,
>
> I had an idea of a warning g++ might be able to add. The purpose of the
> warning is to help prevent bugs. The warning is to occur when you might
> destroy an inherited class using the base classes pointer. To illustrate
> conside
On 25 December 2014 at 16:28, Olaf van der Spek wrote:
> Hi,
>
> https://gcc.gnu.org/ links to https://gcc.gnu.org/gcc-5/ (GCC 5 C++14
> language feature-complete [2014-12-23]) which doesn't exist.
It should probably be https://gcc.gnu.org/gcc-5/status.html
>> Important: Because the final ISO C++
On 27 December 2014 at 19:17, Jonathan Adamczewski wrote:
> On Thu, Dec 25, 2014 at 4:52 PM, Jonathan Wakely
> wrote:
>>
>> On 25 December 2014 at 16:28, Olaf van der Spek wrote:
>> > Hi,
>> >
>> > https://gcc.gnu.org/ links to https://gcc.gnu.
On 28 December 2014 at 00:08, Olaf van der Spek wrote:
> On 26-12-2014 1:52, Jonathan Wakely wrote:
>>
>> On 25 December 2014 at 16:28, Olaf van der Spek wrote:
>>>
>>> Hi,
>>>
>>> https://gcc.gnu.org/ links to https://gcc.gnu.org/gcc-5/ (GC
On 29 December 2014 at 15:34, Ed Smith-Rowland wrote:
> The note on C++14 conformance referred to is not the place for this but: is
> our C++11 support really less tested and more experimental than our C++03
> support at this point? One thing I can think of might be gcc bootstrap.
The main differ
On 30 December 2014 at 15:29, Ed Smith-Rowland wrote:
> On 12/30/2014 07:50 AM, Olaf van der Spek wrote:
>>
>> On 29-12-2014 16:34, Ed Smith-Rowland wrote:
>>>
>>> The note about C++14 conformance is great as it stands modulo link
>>> errors.
>>
>>
>> Why is it great to not mention the experimental
On 6 January 2015 at 09:34, wrote:
>
> Hello!
> There's a link to "GCC5" right on top of the News section on the home page of
> gcc.gnu.org that takes me to a 403 forbidden access page:
> https://gcc.gnu.org/gcc-5/ .
> I think it's a bug.
Yes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64469
On 19 January 2015 at 09:17, Richard Biener wrote:
>
> Status
> ==
>
> The trunk is now in "Stage 4" which means it is open for regression
> and documentation fixes only, like if it were a release branch.
>
> Please concentrate on getting P1 bugs fixed and provide help in
> confirming and analy
On 19 January 2015 at 18:05, Ulrich Drepper wrote:
>> https://gcc.gnu.org/ml/gcc-patches/2015-01/msg01694.html
>
> Just a nit. Why wouldn't you check the value of the variable after
> the assignment in the test case?
Umm, just because I'm dumb? :-)
I'll make that change to my local branch, thanks
On 22/01/15 16:07 -0600, Joel Sherrill wrote:
On 1/22/2015 3:44 PM, Marc Glisse wrote:
On Thu, 22 Jan 2015, Joel Sherrill wrote:
I think this is a glibc issue but since this method is defined in the C++
standards, I thought there were plenty of language lawyers here. :)
s/glibc/libstdc++/ an
On 23/01/15 10:53 -0600, Joel Sherrill wrote:
Is there a better way to automate a signature compliance? To tweak
what they have done?
Testing member function signatures for compliance is inherently
flawed, they just shouldn't do it.
I would say they should be testing that the function can be c
On 27 January 2015 at 16:02, H.J. Lu wrote:
> For the past couple days, gcc.gnu.org/sourceware.org is
> quite slow for me when accessing git and bugzilla. Am
> I the only one who has experienced it?
No, everyone sees it. Spammers are trying to write to the wiki or
something and are DOSing the ma
On 30 January 2015 at 07:23, Conrad S wrote:
> On 30 January 2015 at 16:58, James Dennett wrote:
>> It's hardly just a loophole: C++ doesn't specify the order of evaluation,
>> so the code is wrong (i.e., non-portable, as you've found).
>>
>> Arguably this is a design problem with IOStreams, given
On 30 January 2015 at 21:39, DJ Delorie wrote:
>
> pins...@gmail.com writes:
>> No because they are c++ code so capital C is correct.
>
> However, we should avoid relying on case-sensitive file systems
> (Windows) and use .cc or .cxx for C++ files ("+" is not a valid file
> name character on Window
On 30 January 2015 at 22:24, Kevin Ingwersen (Ingwie Phoenix) wrote:
> Apple’s HFS is, on a default OS X install, case insensitive.
Which doesn't matter, see my previous reply.
> But .c++ is valid. .cxx sounds pretty straight forward to me, since people
> also use the $CXX variable.
We already
On 2 February 2015 at 21:11, Jonny Grant wrote:
> Is this a consensus agreement to rename those .C -> .cc ?
No.
On 4 February 2015 at 00:22, Kevin Ingwersen (Ingwie Phoenix) wrote:
> How many hacks/workarounds can be avoided?
How many new hacks/workaround will be needed for exploring the files'
version control history, even with a VCS that supports renaming?
Renaming the files has downsides as well as upsi
On 6 February 2015 at 12:12, Victor wrote:
>
>
>
> --- the forwarded message follows ---
>
>
> -- Forwarded message --
> From: Victor
> To: gcc-h...@gcc.gnu.org
> Cc:
> Date: Wed, 04 Feb 2015 15:41:56 +0600
> Subject: Vararg templates. GCC vs Clang
> Code:
>
> #include
> #includ
On 7 February 2015 at 00:05, Jonathan Wakely wrote:
> This question would have been more appropriate on the gcc-help mailing list.
I should have said it *was* more appropriate on that list, and should
have remained there. You could have pinged the gcc-help list, or just
been patient, bef
On 13 February 2015 at 13:46, Paweł Tomulik wrote:
> Hi,
>
> the header file is missing return statement in the
> implementation of basic_regex::assign(basic_regex&&). This is about line
> 619. The minimal example to reproduce this bug is the following:
>
> #include
> int main()
> {
> std::reg
On 16 February 2015 at 17:45, Jonny Grant wrote:
> While I remember:
> Stroustrup lists C++ extensions as .cxx and .cpp
> http://www.stroustrup.com/glossary.html
>
> ISO sample sources use .cpp:
> http://standards.iso.org/ittf/PubliclyAvailableStandards/c043351_ISO_IEC_TR_18015_2006(E).zip
>
> .C i
On 17 February 2015 at 15:10, Paweł Tomulik wrote:
> Is this a bug? The original program compiles with clang.
Yes, please report it as described at https://gcc.gnu.org/bugs/
In any case, "is this a bug?" questions are inappropriate on this
mailing list, they belong on the gcc-help list.
On 20 February 2015 at 11:06, Florian Weimer wrote:
> On 02/19/2015 09:56 PM, Sandra Loosemore wrote:
>> H, Passing the additional option in user code would be one thing,
>> but what about library code? E.g., using memcpy (either explicitly or
>> implicitly for a structure copy)?
>
> The memc
On 9 March 2015 at 13:04, Conrad S wrote:
> The list of mirror sites seems to have a bug:
> https://gcc.gnu.org/mirrors.html
>
> The mirror for Australia is listed as:
> http://mirrors-au.go-parts.com/gcc | ..., thanks to Dan Derebenskiy
> (dderebens...@go-parts.com) at Go-Parts.
>
> Going to the a
On 9 March 2015 at 13:12, Conrad S wrote:
> Upon closer inspection there's actually more junk in the mirror list site:
>
> Australia: http://mirrors-au.go-parts.com/gcc
> Russia: http://mirrors-ru.go-parts.com/gcc
> UK: http://mirrors-uk.go-parts.com/gcc/
> US: http://mirrors-usa.go-parts.com/gcc
>
On 11 March 2015 at 16:11, Jakub Jelinek wrote:
> There is some PR about it in our bugzilla, and the conclusion is that
> it is both invalid (in C only one union member can be active at any time,
> we as extension allow type punning through unions etc.)
> and we really don't want to support it.
I
Are you sure your compare_variables functor is correct?
Subtracting the two values seems very strange for a strict weak ordering.
(Also "compare_variables" is a pretty poor name!)
On 16 March 2015 at 09:58, Jan Kratochvil wrote:
> I expected to learn GCC parser on this IMO-simpler case so one can later
> implement for example the '{TYPE} ADDR' GDB extension, dropping C++ class
> protections,
There's the -fno-access-control flag to disable access checking, so I
would have ex
On 16 March 2015 at 15:51, Aditya K wrote:
> I started looking at the steps to test gcc, (https://gcc.gnu.org/Testing_GCC):
>
> In the first step: to install prerequisites 'dejagnu', tcl and Expect
> - The link to dejagnu does not have any information. for tcl and expect
> there are no links.
On 16 March 2015 at 15:54, Jonathan Wakely wrote:
> "DejaGnu" is not meant to be a link, but the wiki automatically treats
> any MixedCase word as a link.
I've fixed that now.
On 22 March 2015 at 17:28, Jack Howarth wrote:
> Is this the policy going forward for the 6.0 release as well?
Yes, as it says on that webpage.
> If it is
> being done just to avoid the stigma of a .0 release, it really smacks
> of being too cute by half.
That's not the reason, there's a rationa
> On Mon, Mar 23, 2015 at 06:14:30PM -0500, David Kunsman wrote:
>> Hello, I was just reading through the current projects wiki page and I
>> noticed how out of date pretty much all of them are. So I was
>> planning on doing "spring cleaning" by going down the list tracking
>> down what has been a
On 24 March 2015 at 12:33, Martin Jambor wrote:
> This is exactly what I actually had in mind.
Ah gotcha - then that's two voices in favour :-)
I think as long as you don't actually rename pages then the wiki
preserves quite good history, so we will always be able to go back to
look at past versi
On 25 March 2015 at 05:34, Yury Gribov wrote:
> On 03/24/2015 03:20 PM, Jonathan Wakely wrote:
>> I don't see any need to move pages (that would break old links).
>
>
> So why not fix links as well?
I mean other sites that link to gcc.gnu.org/wiki ... so we don't control them.
On 25 March 2015 at 16:16, Jack Howarth wrote:
> Does anyone remember which FSF gcc release first added the
> -Wno-c++11-extensions option for g++? I know it exists in 4.6.3
Are you sure? It doesn't exist for 4.6.4 or anything later.
Are you thinking of -Wc++0x-compat ?
On 25 March 2015 at 18:53, Martin Sebor wrote:
> This was my mistake because specifying -ansi after -std=c11
> overrides the latter with -std=c90. (It would be nice if
> the driver warned about one option overriding another.)
In general that's useful, so you can add e.g. -O0 to the end of a
comman
On 29 March 2015 at 19:32, Godmar Back wrote:
> Why does assigning boolFunctionThatReturnsFalse to a variable f after
> the cast, instead of directly dereferencing it, silence the compiler's
> warnings?
Because the cast itself is OK, and the call that results in undefined
behaviour is separate fro
On 12 April 2015 at 21:10, Ricardo Telichevesky wrote:
> I don't
> need to debug the compiler or any of the libraries at all, but is there any
> danger in getting rid of the -g flags?
There's no danger, you just won't be able to debug anything.
Wouldn't it be easier to just run strip on the final
On 13 April 2015 at 10:14, Harald Servat wrote:
> Before we start, we'd like to know if there is someone else working
> on this direction. And if so, could we cooperate?
I have no idea about this part of your mail.
> If there's nobody working on that, how should we start? According to
> the G
On 14 April 2015 at 17:19, Harald Servat wrote:
> Should we file a PR to request to integrate this patch? Or should I
> better follow Peter's suggestion to build gcc from a separate build
> directory?
You should always build in a separate directory, that's what all the
installation docs and the FA
On 19 April 2015 at 03:06, Sandra Loosemore wrote:
> Is it one of the standard g++ or libstdc++ test cases that is failing? I
> could check what nios2-elf does with it if I knew what to look for.
Libstdc++ does not use the __sync built-ins in the 4.9 branch, it has
switched to the __atomic ones wh
On 25 April 2015 at 23:23, Shoham Peller wrote:
> Hi Guys,
>
> It's been 4 days. Can someone help me?
I have no idea what wpp is or why it is useful. Maybe that's true for
other people reading this list.
You shouldn't be very surprised that you don't get any useful
responses to a mail like "I wan
On 26 April 2015 at 18:47, Shoham Peller wrote:
> 1. Can you think of a way to achieve this with gcc?
Insert SystemTap probe points.
On 26 April 2015 at 22:52, Shoham Peller wrote:
> SystemTap does not give a solution for this, and is not really
> intended for this use:
>
> * It's no cross-platform, it's for Linux
> * It doesn't allow the developer to write the text he wants
> * It doesn't parse the tracing string
>
> The solut
On 5 May 2015 at 12:39, Aditya K wrote:
> There are however, other differences between class and struct
> (http://stackoverflow.com/a/999810/811335) i.e.,
>
> 1. In absence of an access-specifier for a base class, public is assumed when
> the derived class is declared struct and private is assume
On 7 May 2015 at 11:09, Mikhail Maltsev wrote:
> I tried to compile it with current trunk on x86_64-unknown-linux-gnu
> (CentOS7) with Python 2.7.5 (It's default in CentOS7), but unfortunately
> the build failed. The reason is that the plugin #include's
> before GCC's headers.
>
> gcc/system.h #de
On 27 May 2015 at 10:01, Markus Trippelsdorf wrote:
> And until C++ modules are implemented (unfortunately nobody is working
> on this AFAIK) pch is still the only option left. So deprecating them
> now seem premature.
I doubt anyone's going to implement them until they're specified, the
proposals
On 2 June 2015 at 06:28, wrote:
> Hi folks,
> the following C++ snippet used to compile, but doesn't anymore with current
> gcc trunk.
Bug reports belong in Bugzilla, not on this mailing list, and this is
already in Bugzilla
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66374)
On Mon, 27 Aug 2018 at 16:35, Shubham Narlawar wrote:
>
> Here is the file. I am getting some error in sending .sh file, so I send it
> as below.
>
> #!/bin/bash
> gcc -fgnu-tm testcase.c > out.txt 2>&1 &&\
> if
> grep 'internal compiler error' out.txt
> then
> exit 0
> else
> exit
On Wed, 22 Aug 2018 at 14:57, Rainer Emrich wrote:
> Here are the test results for 9.0.0 20180504 (experimental) [trunk
> revision 259948]
> https://gcc.gnu.org/ml/gcc-testresults/2018-05/msg00644.html
Thanks for these logs, they're very helpful. Trunk revision r263976
fixes a number of the libstd
On Thu, 30 Aug 2018 at 21:22, Rainer Emrich wrote:
>
> Am 30.08.2018 um 14:38 schrieb Jonathan Wakely:
> > Thanks for these logs, they're very helpful. Trunk revision r263976
> > fixes a number of the libstdc++ FAILs (compilation errors) and trunk
> > revision r263
On Fri, 7 Sep 2018 at 08:06, David Brown wrote:
>
> In C++ programming, it is sometimes helpful to have empty structs acting
> as tags. An example is "struct nothrow_t {}".
>
> When parameters of these types - such as "nothrow", are passed to
> functions the compiler passes them as a value 0. Sin
On Tue, 25 Sep 2018 at 22:15, Sheel Patel wrote:
>
> Should the page at https://www.gnu.org/software/gcc/projects/cxx-status.html,
> specifically the Technical Specifications section be updated to include the
> relevant tag for enabling the experimental support for modules, as is done
> for concept
Please don't cross-post to both gcc@gcc.gnu.org and
gcc-h...@gcc.gnu.org, it is almost never appropriate to send the same
email to both lists, because they are for discussing different topics.
You're looking for help, so use gcc-help not gcc. Please remove
gcc@gcc.gnulorg from further replies in t
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/gcc/gcc/tree-data-ref.h:27,
>
On Tue, 9 Oct 2018 at 14:48, Paolo Carlini wrote:
>
> 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 1
On Sun, 14 Oct 2018 at 20:46, Florian Weimer wrote:
>
> * Rasmus Villemoes:
>
> > This is something I've sometimes found myself wishing was supported. The
> > idea being that one can say
> >
> > unsigned a[] = { [0] = 1, [1] = 3, [0] |= 4, ...}
> >
> > which would end up initializing a[0] to 5. As
On Mon, 15 Oct 2018 at 20:08, Gabriel Paubert wrote:
>
> On Mon, Oct 15, 2018 at 08:11:42PM +0200, Florian Weimer wrote:
> > * Jonathan Wakely:
> >
> > > On Sun, 14 Oct 2018 at 20:46, Florian Weimer wrote:
> > >>
> > >> * Rasmus Villemoes:
>
On Fri, 19 Oct 2018 at 10:54, Jakub Jelinek wrote:
>
> Status
> ==
>
> The 6.5 branch is now frozen for the final GCC 6.5 release, the release
> candidate has been announced. All changes to the branch require RM
> approval.
Since the branch was frozen I was made aware of two libstdc++
regres
On Mon, 29 Oct 2018 at 09:49, Lukas Mosimann wrote:
>
> Hi all,
>
> I am trying to solve the afore-mentioned issue
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87663 and I need your help.
> Manuel kindly pointed me to the mailing list and adviced me to add the
> maintainers to CC.
His suggestio
Patches should be sent to the gcc-patches list, not this one, thanks.
On Mon, 29 Oct 2018 at 02:28, nick wrote:
>
> Greetings all,
>
> I am getting failing tests when running with:
> make bootstrap
> make -k check
>
> The only code I am running is the below patch:
> From 8c26b03c27912a367af52fd1e4
On Tue, 30 Oct 2018 at 09:18, Rasmus Villemoes wrote:
>
> On 2018-10-30 09:29, Martin Liška wrote:
> > On 10/30/18 3:56 AM, Alexander Oblovatniy wrote:
> >> Hello,
> >>
> >> I'd like to report a typo in description of
> >> «__builtin_expect_with_probability»:
> >> https://gcc.gnu.org/onlinedocs/gc
On Tue, 30 Oct 2018 at 09:54, Jonathan Wakely wrote:
>
> On Tue, 30 Oct 2018 at 09:18, Rasmus Villemoes
> wrote:
> >
> > On 2018-10-30 09:29, Martin Liška wrote:
> > > On 10/30/18 3:56 AM, Alexander Oblovatniy wrote:
> > >> Hello,
> > >&
On Tue, 30 Oct 2018 at 12:06, Martin Liška wrote:
>
> On 10/30/18 10:58 AM, Jonathan Wakely wrote:
> > On Tue, 30 Oct 2018 at 09:54, Jonathan Wakely wrote:
> >>
> >> On Tue, 30 Oct 2018 at 09:18, Rasmus Villemoes
> >> wrote:
> >>>
> >&g
On Thu, 15 Nov 2018 at 10:29, Richard Biener wrote:
>
> On Wed, Nov 14, 2018 at 10:47 PM Giuliano Augusto Faulin Belinassi
> wrote:
> > Additionally, I know that GCC must not
> > change the project layout, but from the software engineering perspective,
> > this may be a bad smell that indicates t
On Fri, 30 Nov 2018 at 05:59, nick wrote:
>
> Greetings All,
>
> I assume you get lots of these but I was wondering what's the
> areas where gcc needs help the most these days that are good
> for a new developer to gcc.
There's a relevant section on the wiki, see
https://gcc.gnu.org/wiki/#Getting_
On Fri, 30 Nov 2018 at 20:54, Nicholas Krause wrote:
>
> This adds the remainging noexcept causes required for this cause
> to meet the spec as dicussed last year and documented here:
> http://cplusplus.github.io/LWG/lwg-active.html#2899.
This isn't "the spec", it's a proposed (but incorrect) res
Sent offlist.
On Sun, 2 Dec 2018 at 20:06, nick wrote:
>
>
>
> On 2018-12-02 11:53 a.m., David Edelsohn wrote:
> > On Sat, Dec 1, 2018 at 11:46 PM nick wrote:
> >>
> >> On 2018-12-01 10:32 a.m., Jonathan Wakely wrote:
> >>> On F
On Sun, 2 Dec 2018 at 04:45, nick wrote:
> My other question is related to the noexcept parts and that either I or
> you should move and CC the other involed list i.e. the llibstdc++ list.
Oh I didn't realise this thread wasn't already on that list. Yes, we
should be discussing it there, not here.
On Tue, 4 Dec 2018 at 10:19, Jay K wrote:
> Seems like a bug?
Then it should be reported to Bugzilla, not this mailing list. See
https://gcc.gnu.org/bugs/
This is the wrong mailing list for this discussion, because it's not
related to development of GCC itself (and is not even specific to
GCC). Please see https://gcc.gnu.org/lists.html
Please continue this on the gcc-help mailing list instead.
On 12/12/18 15:05 -0500, nick wrote:
On 2018-12-12 10:24 a.m., Jonathan Wakely wrote:
On 12/12/18 17:17 +0200, Ville Voutilainen wrote:
On Wed, 12 Dec 2018 at 17:14, nick wrote:
> I think there's an attempt to ascertain that mostly constructors and
> assignment operators ne
On Mon, 17 Dec 2018 at 14:55, Nathan Sidwell wrote:
>
> On 12/14/18 10:55 AM, nick wrote:
> > Greetings All,
> > I was attempting to fix this bug:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88395#add_comment
> >
> > and managed to track it down to expand_concept in constraint.cc.
> >
> > See
On Mon, 17 Dec 2018 at 15:11, Jonathan Wakely wrote:
>
> On Mon, 17 Dec 2018 at 14:55, Nathan Sidwell wrote:
> >
> > On 12/14/18 10:55 AM, nick wrote:
> > > Greetings All,
> > > I was attempting to fix this bug:
> > > https://gcc.gnu.org/bugzilla/show
On Mon, 17 Dec 2018 at 15:24, Jakub Jelinek wrote:
>
> On Mon, Dec 17, 2018 at 03:11:03PM +, Jonathan Wakely wrote:
> > --- a/gcc/cp/constraint.cc
> > +++ b/gcc/cp/constraint.cc
> > @@ -563,7 +563,7 @@ expand_concept (tree decl, tree args)
> >++processing_tem
On Thu, 3 Jan 2019 at 15:40, David Malcolm wrote:
>
> On Thu, 2019-01-03 at 15:59 +0100, Daniel Marjamäki wrote:
> > Hello!
> >
> > I have used GCC for decades and would like to contribute a little. :-
> > )
>
> Hi, and welcome!
>
> > I would like to see if I can improve the syntax errors.
> >
> >
On Thu, 3 Jan 2019 at 17:03, Daniel Marjamäki
wrote:
>
> Thank you for the quick reply.
>
> > how about "stray %qs token"?
>
> I will change.
>
> > I wonder how much we want to special-case this. Are you thinking about
> > the case where there's a stray symbol in the code (perhaps due to a
> > str
301 - 400 of 2300 matches
Mail list logo
