Re: [PATCH, v3] wwwdocs: e-mail subject lines for contributions

On Mon, 2 Mar 2020 at 14:31, Nathan Sidwell wrote: > > On 3/2/20 8:01 AM, Richard Earnshaw (lists) wrote: > > On 27/02/2020 13:37, Nathan Sidwell wrote: > >> On 2/3/20 6:41 AM, Richard Earnshaw (lists) wrote: > >>> On 22/01/2020 17:45, Richard Earnshaw (lists) wrote: > > [updated based o

Re: GCC 8.5 Status Report (2020-03-04)

On Wed, 4 Mar 2020 at 12:53, H.J. Lu wrote: > > On Wed, Mar 4, 2020 at 2:30 AM Jakub Jelinek wrote: > > > > Status > > == > > > > GCC 8.4 has been released and the branch is again open for regression > > and documentation fixes. History makes us expect a GCC 8.5 release > > in fall of this y

Re: GCC 8.5 Status Report (2020-03-04)

On Wed, 4 Mar 2020 at 13:02, Jakub Jelinek wrote: > The test says: > // nl_NL chosen because it has no thousands separator (at this time). > locale loc_it = locale(ISO_8859(15,nl_NL)); > so no wonder that it FAILs if nl_NL now has thousands separator. Drat. I thought we could rely on the Dutch

Re: GCC 9.3 Status Report (2020-03-05)

On Thu, 5 Mar 2020 at 20:23, Jakub Jelinek wrote: > > Status > == > > The GCC 9 branch is now frozen for blocking regressions and documentation > fixes only, all changes to the branch require a RM approval now. I'd like to backport https://gcc.gnu.org/ml/gcc-patches/2020-03/msg00361.html The

Re: GCC 9.3 Status Report (2020-03-05)

On Fri, 6 Mar 2020 at 12:18, Jakub Jelinek wrote: > > On Fri, Mar 06, 2020 at 12:12:09PM +, Jonathan Wakely wrote: > > On Thu, 5 Mar 2020 at 20:23, Jakub Jelinek wrote: > > > > > > Status > > > == > > > > > > The GCC 9 branch

Re: GCC 9.3 Status Report (2020-03-05)

On Thu, 5 Mar 2020 at 20:23, Jakub Jelinek wrote: > > Status > == > > The GCC 9 branch is now frozen for blocking regressions and documentation > fixes only, all changes to the branch require a RM approval now. I'd also like to backport this one: https://gcc.gnu.org/ml/gcc-patches/2020-03/msg0

Re: Changes in Mail-list to Web integration.

On Mon, 9 Mar 2020 at 09:45, Iain Sandoe via Gcc wrote: > The formatting is not (to me) so much of an issue, I frequently scanned down the right edge of the page looking for specific email addresses. That's harder to do when the addresses aren't right-aligned, but I guess I'll get used to it. >b

Re: Changes in Mail-list to Web integration.

On Mon, 9 Mar 2020 at 09:56, Jonathan Wakely wrote: > > On Mon, 9 Mar 2020 at 09:45, Iain Sandoe via Gcc wrote: > > The formatting is not (to me) so much of an issue, > > I frequently scanned down the right edge of the page looking for > specific email addresses. That&#x

Re: text/x-* attachments stripped (was: Re: gcc ML archive: text/x-patch attachments no longer shown inline (was:Re: Mailing list stripping off attachments))

On Mon, 9 Mar 2020 at 10:28, Jakub Jelinek wrote: > 1) the by date monthly list of mails used to be ordered newest to oldest > mails first, now it is oldest to newest, so when dealing with new stuff one > has to always scroll down You can use #end to jump to the bottom. > 6) there used to be a Ra

Re: gcc-10-20200308 is now available

On Sun, 8 Mar 2020 at 22:48, GCC Administrator wrote: > > Snapshot gcc-10-20200308 is now available on > https://gcc.gnu.org/pub/gcc/snapshots/10-20200308/ > and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. > > This snapshot has been generated from the GCC 10 git branch >

Re: text/x-* attachments stripped (was: Re: gcc ML archive: text/x-patch attachments no longer shown inline

On Mon, 9 Mar 2020 at 16:58, Nathan Sidwell wrote: > > On 3/9/20 9:57 AM, Thomas König wrote: > > Hi, > > > > I concur with what Jakub wrote. The new web interface is much less useful > > than the old one; a severe regression for developers, so to speak. > > OMG I've just looked. It's awful. Sor

Re: text/x-* attachments stripped (was: Re: gcc ML archive: text/x-patch attachments no longer shown inline (was:Re: Mailing list stripping off attachments))

On Mon, 9 Mar 2020 at 19:57, Thomas König wrote: > As far as the advantages go: A per-thread view is nice, but I don't > think having it outweighs the disadvantages above. We always had a threaded view: https://gcc.gnu.org/legacy-ml/gcc-bugs/2020-03/threads.html It just wasn't the default: https:/

Re: text/x-* attachments stripped (was: Re: gcc ML archive: text/x-patch attachments no longer shown inline (was:Re: Mailing list stripping off attachments))

On Mon, 9 Mar 2020 at 10:28, Jakub Jelinek wrote: > 6) there used to be a Raw text URL to grab the raw email, now there is nothing Based on info from #overseers ... While you can't download the raw text of an individual email now, you can get the entire month's mail in a compressed archive, from

Re: devbranches: ambigous characterisation of branches

On 7 June 2015 at 21:28, Wolfgang Hospital wrote: > in the repository contents description at > , numerous branch names are > listed as inactive, with some further comments. Right at the start there is > the longest list of such names, followed by "These

Re: Possible invalid code - GCC 4.8/5.1.

On 17 June 2015 at 09:16, Krzysztof Hałasa wrote: > Hi, > > I wonder if the following is a bug: > > #include > > int main(void) > { > struct str { > struct a { > int a1, a2; > } a; > }; > > struct str src = {.a = {.a1

Re: Possible range based 'for' bug

On 21 June 2015 at 16:56, Julian Klappenbach wrote: > Version info: > > Configured with: > --prefix=/Applications/Xcode.app/Contents/Developer/usr > --with-gxx-include-dir=/usr/include/c++/4.2.1 > Apple LLVM version 6.1.0 (clang-602.0.53) (based on LLVM 3.6.0svn) > Target: x86_64-apple-darwin14.3.0

Re: Possible range based 'for' bug

On 21 June 2015 at 19:16, Julian Klappenbach wrote: > The issue occurred to me after I sent the email. > > begin() / end() return iterators by value, not reference. > > So, you're correct in identifying the value / reference issue. But to > be precise: you can't return an abstract class type *by

Re: Possible range based 'for' bug

On 22 June 2015 at 10:18, Paulo Matos wrote: > > >> -Original Message- >> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf >> Of Julian Klappenbach >> Sent: 21 June 2015 16:56 >> To: gcc@gcc.gnu.org >> Subject: Re: Possible range based 'for' bug >> >> Version info: >> >>

Re: Version numbers question

On 22 June 2015 at 14:55, JohnT wrote: > I am wondering why it appears that GCC has started drastically raising its > major version number for minor changes, instead of spending several years > on version 3 and 4. 4.0.1, 4.1.1 and 4.12, 4.2.3, 4.3.2, 4.4.5, up through > 4.7.0, 4.7.1, 4.7.2, the 4.8

Re: Version numbers question

> Regarding what's a small vs large change, I'd say that building with C++ That's completely invisible to most users. > and newly generated C++ library Not sure what that means.

Re: C++ coding style inconsistencies

On 25 June 2015 at 19:28, Richard Sandiford wrote: > (2) Is there supposed to be a space before a template parameter list? > I.e. is it: > >foo > > or: > >foo > > ? Both are widely used. > > The current coding conventions don't say explicitly, but all the > exa

Re: C++ coding style inconsistencies

On 26 June 2015 at 10:40, Martin Jambor wrote: >> (1) Should inline member functions be implemented inside the class or outside >> the class? If inside, should they be formatted like this: > > https://gcc.gnu.org/codingconventions.html has a big section on C++ > (note that there is also a simi

Re: cannot find crti.o error, while building gcc cross compiler

On 24 July 2015 at 18:31, sindhu selvam wrote: > /usr/local/cross/x86_64-pc-linux-gnu/bin/ld: cannot find crti.o: No > such file or directory > /usr/local/cross/x86_64-pc-linux-gnu/bin/ld: cannot find -lc > /usr/local/cross/x86_64-pc-linux-gnu/bin/ld: cannot find crtn.o: No > such file or directory

Re: Debug assertion and constexpr

On 27/07/15 21:16 +0200, François Dumont wrote: Hello There are at the moment several failures in the libstdc++ testsuite when run in debug mode (_GLIBCXX_DEBUG). This is so because debug assertions are not const expressions. Several debug assertions have been removed because of this issue.

Re: [powerpc64le] seq_cst memory order possibly not honored

On 14 August 2015 at 01:37, Andrey Semashev wrote: > 1. Is my test valid or is there a flaw that I'm missing? The cppmem tool at http://svr-pes20-cppmem.cl.cam.ac.uk/cppmem/ shows that there are consistent executions where (x==0 && y==0) is true. I used this code: int main() { atomic_int a = 0;

Re: [powerpc64le] seq_cst memory order possibly not honored

On 14 August 2015 at 10:54, Andrey Semashev wrote: > On 14.08.2015 11:51, Jonathan Wakely wrote: >> >> On 14 August 2015 at 01:37, Andrey Semashev wrote: >>> >>> 1. Is my test valid or is there a flaw that I'm missing? >> >> >> The cppmem to

Re: ctype_members.cc Comparison Always True

On 19 August 2015 at 03:16, Martin Sebor wrote: > On 08/03/2015 12:35 PM, Joel Sherrill wrote: >> >> Hi >> >> Just noticed this building the head for arm-rtems4.11. Should >> the first comparison be eliminated and, maybe, a comment added? >> >> ctype_members.cc:216:14: warning: comparison of unsign

Re: Moving to git

On 20 August 2015 at 19:23, Jeff Law wrote: > On 08/20/2015 11:57 AM, Jason Merrill wrote: >> >> I hear that at Cauldron people were generally supportive of switching >> over to git as the primary GCC repository, and talked about me being >> involved in that transition. Does anyone have more infor

Re: Moving to git

On 20 August 2015 at 23:32, Jason Merrill wrote: > On 08/20/2015 04:33 PM, Joseph Myers wrote: >> * Make sure whatever process updates the github mirror is kept going after >> the conversion (actually it looks like it broke two weeks ago...). > > > I have no idea how this mirror is updated. Its gi

Re: Moving to git

On 21 August 2015 at 11:44, Ramana Radhakrishnan wrote: >> >> Absolutely, a non-fast-forward push is anathema for anything other people >> might be working on. The git repository already prohibits this; people that >> want to push-rebase-push their own branches need to delete the branch before >>

Re: Moving to git

On 21 August 2015 at 09:26, Richard Biener wrote: > > Btw, I've done this once now and it kind of works. You need to write your > tests in a way to support gits limited way of searching (the past has to be > always good, the future bad) - I've tried to find a change that was _fixing_ > a problem,

Re: Moving to git

On 21 August 2015 at 12:25, Richard Biener wrote: > On Fri, Aug 21, 2015 at 12:52 PM, Jonathan Wakely > wrote: >> On 21 August 2015 at 09:26, Richard Biener wrote: >>> >>> Btw, I've done this once now and it kind of works. You need to write your >>> t

Re: Moving to git

On 24 August 2015 at 09:17, Jakub Jelinek wrote: > The revision ids are also useful for bugzilla, r123456 > links in text pointing to http://gcc.gnu.org/r123456 is significantly > shorter The first six characters of the sha1 is usually enough to unambiguously identify a commit, so we could easily

Re: Moving to git

On 24 August 2015 at 11:42, Eric S. Raymond wrote: > Jonathan Wakely : >> On 24 August 2015 at 09:17, Jakub Jelinek wrote: >> > The revision ids are also useful for bugzilla, r123456 >> > links in text pointing to http://gcc.gnu.org/r123456 is significantly >&

Re: Identifying contributors

On 26 August 2015 at 16:52, Eric S. Raymond wrote: > I believe I'm down to only 34 unidentified contributors out of 290. > > Could someone send me a copy of the password file (or at least the > username and gecos fields) for the Subversion host? In some of the > remaining cases I could make guesse

Re: svn timeouts

On 27 August 2015 at 20:51, Frank Ch. Eigler wrote: > > pmatos wrote: > >> Am I the only one regularly getting svn timeouts lately? >> svn: E210002: Unable to connect to a repository at URL >> 'svn://gcc.gnu.org/svn/gcc/trunk' >> svn: E210002: Network connection closed unexpectedly > > Hard to be s

Re: Action stamps

On 1 September 2015 at 10:21, Eric S. Raymond wrote: > Jason Merrill : >> Given git aliases: >> >> >stamp = show -s --format='%cI!%ce' >> >scommit = "!f(){ d=${1%%!*}; a=${1##*!}; arg=\"--until=$d -1\"; if >> > [ $a != $1 ]; then arg=\"$arg --committer=$a\"; fi; shift; git rev-list

Re: incremental compiler project

On 4 September 2015 at 16:57, Manuel López-Ibáñez wrote: > Clang++ is much faster yet it is doing more and tracking more data > than cc1plus. How much faster these days? In my experience for optimized builds of large files the difference is not so impressive (for unoptimized builds clang is defini

Re: 30_threads/timed_mutex/try_lock_until/57641.cc

On 1 September 2015 at 10:12, Sebastian Huber wrote: > Hello, > > in this test case there are two bool test variables (global and local). Is > this intentional? You're much more likely to get an answer if you ask on the libstdc++ list. It doesn't look right, not sure what I meant to do there but

Re: Advertisement in the GCC mirrors list

Gerald, I think we've had similar issues with these mirrors in the past as well, shall we just remove them from the list? On 9 September 2015 at 17:28, niXman wrote: > > Hi, > > http://mirrors-ru.go-parts.com/gcc - Online Shop > ftp://mirrors-ru.go-parts.com/gcc - bad > rsync://mirrors-ru.go-part

Re: Git conversion: disposition of old branches and tags

On 16 September 2015 at 17:20, Manuel López-Ibáñez wrote: > My impression is that right now one can develop GCC with GIT or SVN (people > are submitting GIT patches all the time). After the conversion, only GIT > will be possible. Does this actually lower the entry barrier and will > attract contri

Re: C++ Dynamic Arrays

On 25 September 2015 at 23:14, David Kunsman wrote: > Hello, I was just wondering if anybody is currently working on the C++ > dynamic array library for c++1z? Which one? The dynarray type in http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3662.html was never meant to be part of C++17, i

Re: What is guaranteed with the new numbering scheme of GCC releases ?

On 6 October 2015 at 20:32, Toon Moene wrote: > All, > > One of my colleagues on the Fortran Standardization Committee asked me the > following question: > > "People are still not too familiar with the new GCC numbering scheme. My > impression is that 5.2 is just a maintenance update of 5.1. Howev

Re: Understand GCC test process

On 7 October 2015 at 12:38, Sabrina Souto wrote: > Hi, > I'm needing to analyze the execution flow of a test, but don't > understand how the test drivers, e.g., gcc-dg.exp or dg.exp, access > the source code of GCC. When a test starts, what is the first function > that is called? How can I know tha

Re: Understand GCC test process

On 7 October 2015 at 14:03, Sabrina Souto wrote: >>> Hi, >>> I'm needing to analyze the execution flow of a test, but don't >>> understand how the test drivers, e.g., gcc-dg.exp or dg.exp, access >>> the source code of GCC. When a test starts, what is the first function >>> that is called? How can

Re: Understand GCC test process

On 7 October 2015 at 14:57, Sabrina Souto wrote: > I was seeing these files but I could not put the puzzle pieces > together in my mind, and after you explained, all pieces make sense > now. Thanks for the explanation, Jonathan. You're doing better than I am then, noting about DejaGnu makes comple

Re: Understand GCC test process

On 7 October 2015 at 16:45, Sabrina Souto wrote: >> What exactly are you tracing, and how? > I'm proposing an approach for testing configurable system in my > research, and I'm trying to apply it to GCC. So, I instrumented the > GCC function calls (in the first level of ..gcc-version-x.x/gcc/ and

Re: Understand GCC test process

On 7 October 2015 at 19:43, Sabrina Souto wrote: > I ran > make RUNTESTFLAGS='dg.exp=c90-float-1.c -v -v' check-gcc > And I saw in the log: > ... > doing compile > Invoking the compiler as > ../gcc-r227092/objdir/gcc/testsuite/g++/../../xg++ -B/... > ... > > The test ../testsuite/gcc.dg/c90-float-1

Re: gcc-4.9.2: Assembly for i386 Target

On 12 October 2015 at 10:11, Abhishek Aggarwal wrote: > I was befuddled by the following 3 assembly instructions (generated > right in the beginning of 'main' function): >lea 0x4(%esp), %ecx >and 0xfff0, %esp >pushl -0x4(%ecx) > > I am not able to understand the purpose

Re: C++11 support page still says that support is experimental.

On 21 October 2015 at 00:22, Ilya Popov wrote: > Another question on SO: > http://stackoverflow.com/questions/33238856/official-status-of-c11-support-in-gcc > > If the wording is not changed, these questions will appear more and more, > and some users will hesitate to use new C++ standards and eve

Re: abi_tag questions

On 4 November 2015 at 14:37, Stephan Bergmann wrote: > I have two questions regarding the abi_tag attribute (as documented at > ): > > > 1 "The attribute can also be applied to an inline namespace, but does not > affect the mangled n

Re: abi_tag questions

On 4 November 2015 at 17:18, Jonathan Wakely wrote: > On 4 November 2015 at 14:37, Stephan Bergmann wrote: >> I have two questions regarding the abi_tag attribute (as documented at >> <https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Attributes.html>): >> >>

Re: Broken Link

On 20 November 2015 at 13:12, wrote: > Hey, > > I wanted to reach out and let you know about this link which isn’t working - > http://developer.apple.com/documentation/Cocoa/Conceptual/ObjectiveC/, I > found it on this page - > http://gd.tuwien.ac.at/.vhost/www.gnu.org/software/gcc/readings.html.

Re: C++11 support still experimental?

On 21 November 2015 at 10:35, Uros Bizjak wrote: > [1] still says in its third paragraph: > > --q-- > Important: GCC's support for C++11 is still experimental. Some > features were implemented based on early proposals, and no attempt > will be made to maintain backward compatibility when they are u

Re: C++ order of evaluation of operands, arguments

On 25 November 2015 at 19:38, wrote: > I'm really wondering about this proposal. It seems that it could affect > optimization. It also seems to be a precedent that may not be a good one to > set. Consider the dozen or so "undefined behavior" examples in > https://pdos.csail.mit.edu/papers/u

Re: GCC 5.3 Release Candidate available from gcc.gnu.org

On 1 December 2015 at 16:51, Marqin Marqin wrote: > On 11/30/2015 12:55:40, Richard Biener wrote: >> The first release candidate for GCC 5.3 is available from >> ftp://gcc.gnu.org/pub/gcc/snapshots/5.3.0-RC-20151130 > > I've built it and it has features from 5.3 branch, but when I run gcc There i

Re: GCC 5.3 Release Candidate available from gcc.gnu.org

On 1 December 2015 at 21:14, Marqin Marqin wrote: > 2015-12-01 18:12 GMT+01:00 Jonathan Wakely : >> That's expected, because you're not using the final 5.3.0 release, >> because there is no final 5.3.0 release. > > I thought I'm using 5.3.0-rc1 release, like

Re: building gcc with macro support for gdb?

On 3 December 2015 at 16:01, Martin Sebor wrote: > On 12/02/2015 06:48 PM, Peter Bergner wrote: >> >> On Wed, 2015-12-02 at 20:05 -0500, Ryan Burn wrote: >>> >>> Is there any way to easily build a stage1 gcc with macro support for >>> debugging? >>> >>> I tried setting CFLAGS, and CXXFLAGS to speci

Re: invalid conversion from typeX** to const typeX**

On 5 December 2015 at 11:26, Richard Baxter wrote: > Hi GCC dev team, Hi, this is the wrong mailing list for questions seeking help using GCC, please direct any follow-up to the gcc-help mailing list, thanks. > I have developed software to parse C(++) code and automatically add > const to functi

Removing "Severity" from New Bug form

I would really like to see the Severity field removed from the bug entry form. A few people use it correctly to mark their bugs as enhancements or trivial, but most users just set it to "blocker" because they think it means "how important is this to you?". Obviously everyone's bug is important to t

Re: Removing "Severity" from New Bug form

On 8 December 2015 at 12:42, Richard Biener wrote: > On Tue, Dec 8, 2015 at 1:04 PM, Jonathan Wakely wrote: >> I would really like to see the Severity field removed from the bug >> entry form. A few people use it correctly to mark their bugs as >> enhancements or trivial, bu

Re: Removing "Severity" from New Bug form

On 8 December 2015 at 13:16, Jonathan Wakely wrote: > On 8 December 2015 at 12:42, Richard Biener > wrote: >> People also get Component wrong but it would be inconvenient >> to have it dropped. Maybe have an advanced bug reporting form >> and a simple one? > > We

Re: doc maintainer questions

On 19 December 2015 at 19:52, David Wohlferd wrote: > 2) How do I get 'edit' access to the wiki? Someone who already has it adds your username to the EditorGroup page after you convince them you are not a spammer :-) It would be nice if that step wasn't needed and you could just sign up and start

Re: Strange C++ function pointer test

On 31 December 2015 at 09:57, Jakub Jelinek wrote: > On Thu, Dec 31, 2015 at 10:49:18AM +0100, Dominik Vogt wrote: >> This snippet ist from the Plumhall 2014 xvs test suite: >> >> #if CXX03 || CXX11 || CXX14 >> static float (*p1_)(float) = abs; >> ... >> checkthat(__LINE__, p1_ != 0); >>

Re: Strange C++ function pointer test

On 31 December 2015 at 09:57, Marc Glisse wrote: > On Thu, 31 Dec 2015, Dominik Vogt wrote: > >> This snippet ist from the Plumhall 2014 xvs test suite: >> >> #if CXX03 || CXX11 || CXX14 >> static float (*p1_)(float) = abs; >> ... >> checkthat(__LINE__, p1_ != 0); >> #endif >> >> (With the tes

Re: Strange C++ function pointer test

On 31 December 2015 at 11:34, Dominik Vogt wrote: > On Thu, Dec 31, 2015 at 10:11:55AM +0000, Jonathan Wakely wrote: >> is required to declare std::abs and it's unspecified whether >> it also declares it as ::abs. >> >> is required to declare ::abs and it&

Re: Strange C++ function pointer test

On 31 December 2015 at 11:37, Marc Glisse wrote: > That's what I called "bug" in my message (there are a few bugzilla PRs for > this). It would probably work on Solaris. Yes, the case is still a mess in the standard and in glibc. The "only in namespace std in the second case" part is what I meant

Re: Strange C++ function pointer test

On 31 December 2015 at 11:54, Dominik Vogt wrote: > Is there a requirement for a certain minimum Glibc version for > this to work? It doesn't work with any glibc, because it doesn't declare the C++ overloads. Libstdc++ has an include/c_compatibility/math.h header that would include (which declar

Re: Strange C++ function pointer test

On 31 December 2015 at 13:09, Dominik Vogt wrote: > On Thu, Dec 31, 2015 at 12:42:56PM +0000, Jonathan Wakely wrote: >> On 31 December 2015 at 11:54, Dominik Vogt wrote: >> > Is there a requirement for a certain minimum Glibc version for >> > this to work? >>

Re: Strange C++ function pointer test

On 31 December 2015 at 18:49, James Dennett wrote: > On Thu, Dec 31, 2015 at 4:42 AM, Jonathan Wakely > wrote: >> >> On 31 December 2015 at 11:54, Dominik Vogt wrote: >> > Is there a requirement for a certain minimum Glibc version for >> > this to work?

Re: getting bugzilla access for my account

On 2 January 2016 at 14:04, Mike Frysinger wrote: > i completely forgot i had that e-mail address :). i thought i remembered > seeing people make changes w/out @gcc.gnu.org accounts, but perhaps i'm > misremembering. Bug reporters can make certain changes to their own bugs without a gcc.gnu.org a

Re: Strange C++ function pointer test

On 2 January 2016 at 11:42, Jonathan Wakely wrote: > On 31 December 2015 at 18:49, James Dennett wrote: >> On Thu, Dec 31, 2015 at 4:42 AM, Jonathan Wakely >> wrote: >>> >>> On 31 December 2015 at 11:54, Dominik Vogt wrote: >>> > Is there a requir

Re: Strange C++ function pointer test

On 4 January 2016 at 09:32, Florian Weimer wrote: > On 12/31/2015 01:31 PM, Jonathan Wakely wrote: >> On 31 December 2015 at 11:37, Marc Glisse wrote: >>> That's what I called "bug" in my message (there are a few bugzilla PRs for >>> this). It would prob

Re: Strange C++ function pointer test

On 7 January 2016 at 13:14, Jonathan Wakely wrote: > On 6 January 2016 at 21:05, Jonathan Wakely wrote: >> I have been meaning to try solving it in libstdc++ with a new >> that includes the libc one and extends it, to see how well that works. >> I haven't had time t

Re: Strange C++ function pointer test

On 7 January 2016 at 13:36, Jonathan Wakely wrote: > On 7 January 2016 at 13:14, Jonathan Wakely wrote: >> On 6 January 2016 at 21:05, Jonathan Wakely wrote: >>> I have been meaning to try solving it in libstdc++ with a new >>> that includes the libc one and extends it,

Re: C++14 template code working in GCC 5.1 stops working in 5.2 and 5.3

On 10 January 2016 at 14:55, Yongwei Wu wrote: > Hi GCC gurus, > > I have an implementation of Y Combinator in C++, which works in GCC > 4.9 to 5.1 as well as Clang 3.5 (in C++14 mode). It stops working in > GCC 5.2 and 5.3. I cannot really whether it is a GCC bug or not, but > it looks like GCC is

Re: distro test rebuild using GCC 6

On 14 January 2016 at 17:15, James Greenhalgh wrote: > Hope this helps, if it is useless, let me know what would be a better way > for me to help out with the AArch64 stuff. It's useful for me to get pointers to some of the C++-related failures, thanks. > --- > -Wnarrowing > > This is a mismatch

Re: distro test rebuild using GCC 6

On 15 January 2016 at 17:52, James Greenhalgh wrote: > vbrfix_0.24-7 > > [ Source error, not sure how this ever worked! ] > > In file included from vbrfix.h:22:0, > from vbrfix.cpp:17: > wputil.h: In static member function 'static bool wfile::copyFile(const > cha

Re: libstdc++ and c library compatible issue when bootstrap GCC

On 28 January 2016 at 18:19, Bin.Cheng wrote: > Hi, > I ran into below error message at stage2 of bootstrap GCC: > > /work/obj/gcc-bootstrap/./prev-gcc/xg++ > -B/work/obj/gcc-bootstrap/./prev-gcc/ -B//aarch64-none-linux-gnu/bin/ > -nostdinc++ > -B/work/obj/gcc-bootstrap/prev-aarch64-none-linux-gn

Re: void* vs void *

On 29 January 2016 at 18:13, Magnus Fromreide wrote: > I just noticed that the C and C++ compiler output pointer types differently: > > Consider > > int i; > printf("%p", &i); > > When compiled as C that gives the warning > > format '%p' expects argument of type 'void *', but argument 2 has type 'i

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

On 8 February 2016 at 13:54, H.J. Lu wrote: > On Sun, Feb 7, 2016 at 12:52 PM, H.J. Lu wrote: > > The standard-layout POD is well defined: > > https://en.wikipedia.org/wiki/C%2B%2B11#Modification_to_the_definition_of_plain_old_data > > Here is the updated proposal for Intel386, x86-64 and IA MCU

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

On 8 February 2016 at 15:42, H.J. Lu wrote: > On Mon, Feb 8, 2016 at 7:02 AM, Jonathan Wakely wrote: >> On 8 February 2016 at 13:54, H.J. Lu wrote: >>> On Sun, Feb 7, 2016 at 12:52 PM, H.J. Lu wrote: >>> >>> The standard-layout POD is well defined: >&g

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

On 8 February 2016 at 16:05, H.J. Lu wrote: > My understanding is > > A type that is standard-layout means that it orders and packs its > members in a way that is compatible with C. > > What is the corresponding compatible type in C? An empty structure, such as struct A. One of the requirements f

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

On 8 February 2016 at 18:26, Jonathan Wakely wrote: > On 8 February 2016 at 17:58, H.J. Lu wrote: >> On Mon, Feb 8, 2016 at 7:59 AM, Jonathan Wakely >> wrote: >>>>> A type is a standard-layout type, or it isn't. >>>> >>>> How ab

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

On 8 February 2016 at 17:58, H.J. Lu wrote: > On Mon, Feb 8, 2016 at 7:59 AM, Jonathan Wakely wrote: >>>> A type is a standard-layout type, or it isn't. >>> >>> How about "An empty record is standard-layout Plain Old Data (POD) >>> type and ...&

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

On 8 February 2016 at 18:31, H.J. Lu wrote: > On Mon, Feb 8, 2016 at 10:30 AM, Jonathan Wakely > wrote: >> On 8 February 2016 at 18:26, Jonathan Wakely wrote: >>> On 8 February 2016 at 17:58, H.J. Lu wrote: >>>> On Mon, Feb 8, 2016 at 7:59 AM, Jonathan Wakely

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

On 8 February 2016 at 19:23, Richard Smith wrote: > "POD for the purpose of layout" is defined in the Itanium C++ ABI here: > > http://mentorembedded.github.io/cxx-abi/abi.html#definitions Thanks. So there's no problem using "POD for the purposes of layout", and the change to "POD for the purpos

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

On 11 February 2016 at 12:40, Matthijs van Duin wrote: > You never define "POD for the purposes of layout", and I can only > interpret it as being equivalent to "standard-layout". As Richard pointed out, it's defined in the C++ ABI.

Re: A link on your site is broken

On 17 February 2016 at 12:43, Tom Wilcox wrote: > Hi, > > I've been compiling resources to include in our C Developer resource guide > and I came across a link that isn't working on your site. > > It's on this page: > http://gd.tuwien.ac.at/.vhost/www.gnu.org/software/gcc/readings.html That's not

Re: A link on your site is broken

On 17 February 2016 at 13:28, Jonathan Wakely wrote: > On 17 February 2016 at 12:43, Tom Wilcox wrote: >> Hi, >> >> I've been compiling resources to include in our C Developer resource guide >> and I came across a link that isn't working on your s

Re: Committing via git

On 26 February 2016 at 17:25, Joel Sherrill wrote: > Hi > > Is there something special needed to commit via git? I got an odd error > pushing some minor RTEMS patches and wondered what the proper procedure was. > > I am using the same commands and process I use with newlib so was wondering. > > Th

Re: Committing via git

On 26 February 2016 at 20:34, Jeff Law wrote: > Yup. Many folks are successfully using git-svn. There' instructions > somewhere on the gcc.gnu.org site for setting that up. At https://gcc.gnu.org/wiki/GitMirror

Re: GCC GSOC 2016

On 3 March 2016 at 10:32, Manuel López-Ibáñez wrote: > It also seems we did not apply last year either (at least > https://gcc.gnu.org/wiki/SummerOfCode does not show any accepted projects > for 2015). We did participate last year, it just doesn't say so on that page.

Re: Is test case with 700k lines of code a valid test case?

On 18 March 2016 at 12:45, Paulo Matos wrote: > > > On 14/03/16 16:31, Andrey Tarasevich wrote: >> Hi, >> >> I have a source file with 700k lines of code 99% of which are printf() >> statements. Compiling this test case crashes GCC 5.3.0 with segmentation >> fault. >> Can such test case be consid

Re: regression in C++ parsing performance between 4.9.3 and 5.3.1

> There is a significant slow down and increase in ram usage Please report it to Bugzilla rather than this list, thanks.

Re: stray quotation marks warning enhancement or extension

On 31 March 2016 at 21:10, Daniel Gutson wrote: > Hi, > > many times we copy code snippets from sources that change the > Unicode quotation marks ( “ ” ) rather than " ". For example > > const std::string a_string(“Hello”); > > That line looks innocent but causes gcc to say > > x.cpp

Re: Q: (d = NAN) != NAN?

On 8 April 2016 at 11:09, Ulrich Windl wrote: > Hello! > > Probably I'm doing something wrong, but I have some problems comparing a > double with NAN: The value is NAN, but the test fails. Probably I should use > isnana(). This mailing list is for discussing development of GCC, not help using GC

Re: Adding a new thread model to GCC

On 13 April 2016 at 10:17, lh_mouse wrote: > Hi all, > > The 'win32' thread model of gcc has been there since long long ago, being > compatible with very old Windows versions, also having a number of drawbacks: > 0) its implementation is very inefficient, and > 1) its mutexes and condition var

Re: Problems installing GCC

On 15 April 2016 at 17:27, Hassan Haddouchi wrote: > Dear, > > > I'm new to the C world and I was looking for the GCC compiler. So far I > downloaded the .tar.gz from the website and unpacked it, but how can I > install the compiler in order to be able to compile C code? > > Kind regards, > Haddo

Re: Re: Adding a new thread model to GCC

On 17 April 2016 at 17:56, lh_mouse wrote: > A glance over gthr.h reminds me __gthread_time_t. There seem few requirements > documented in gthr.h. > I discussed this with Adrien Nader on mingw-w64's mailing list a few days ago. > > Specifically, here are the two questions: > 0) Should __gthread_t

<    1   2   3   4   5   6   7   8   9   10   >