Re: GCC 6 symbol poisoning and c++ header usage is fragile

On Thu, Apr 21, 2016 at 12:47 PM, Jason Merrill wrote: > On Thu, Apr 21, 2016 at 11:57 AM, Jonathan Wakely > wrote: >> >> I once tried to write a gcc plugin that would check all names defined >> by libstdc++ and ensure they were either in the reserved namespace, or &

Re: CppCoreGuidelines warnings

ome prerequisites to > contributing significant changes to GCC. > > I don't know the status of the static analysis tool the Microsoft were > planning to release, which would do a lot of the checking. To > incorporate the checks into GCC would probably involve changes to both > the C++ front-end and the C++ library, but I would welcome such > changes. As would I. You can coordinate with me about front end changes. Thanks, Jason

Re: CppCoreGuidelines warnings

be better to discuss all possibilities with your employer to avoid > wasteful back and forth. It might work better to put your employer in touch with the FSF so you don't have to mediate in a game of telephone; I believe ass...@gnu.org is the right address to use. Jason

Re: Please, take '-Wmisleading-indentation' out of -Wall

readily than -Wmisleading-indentation does. We certainly don't want -Woverlength-strings in -Wall; that's a pedantic portability warning, not a warning about code that is probably incorrect. There's an open BZ about -Wempty-body, bug 52961. Jason

Re: CppCoreGuidelines warnings

in your opinion, we (mostly me) should contribute to > one of those projects instead, or are they just cool projects to watch? They might be interesting to look at, but we'd definitely like to have support for this in GCC. Jason

Re: How to improve the location of a gcc diagnostic

Why not checkin using git-svn? I have no svn checkout. Jason

Re: Deprecating basic asm in a function - What now?

std argument in the CXX variable rather than CXXFLAGS. Jason

Re: style convention: /*foo_p=*/ to annotate bool arguments

more often than the declaration in the header, the latter of which typically has neither comments nor parameter names. Jason

Re: style convention: /*foo_p=*/ to annotate bool arguments

On Wed, Oct 5, 2016 at 12:18 PM, wrote: >> On Oct 5, 2016, at 12:12 PM, Jeff Law wrote: >> On 10/04/2016 03:08 PM, Jason Merrill wrote: >>> On Tue, Oct 4, 2016 at 4:29 PM, Zan Lynx wrote: >>> ... >>> In GCC sources, I think users look at the func

Re: Repository for the conversion machinery

t; The conversion got stalled (I'm not sure why; maybe just Jason being busy >> with other things) but is still intended (I'm not sure for when), so yes >> the repository is still needed. > > I was unaware of this. I thought Jason had gotten the bit in his teeth > and

Re: Repository for the conversion machinery

On Thu, Oct 6, 2016 at 4:31 PM, Joseph Myers wrote: > On Thu, 6 Oct 2016, Jason Merrill wrote: > >> After I ran into a couple of reposurgeon bugs and didn't hear back >> from you, I started investigating rewriting the existing git svn >> mirror with git filter-b

Re: Repository for the conversion machinery

geLog entry (note that we have >> very strict formatting requirement for the authors there). > > Particularly since the ChangeLog entry gives the Author, which is > often not the same as the Committer. Yes, very often they will be different. This processing can, and probably should, be done with git filter-branch after the initial conversion. Jason

Re: style convention: /*foo_p=*/ to annotate bool arguments

d be preferred by most people who responded. > > With that I don't have the sense that there is consensus to adopt > either style as conventions for GCC code. > > Jason and Jeff (and other reviewers), what does this mean for those > of us submitting patches? Do we discontinue us

small testcase gcc6 + boost optional + Wmaybe-uninit

uto x = make_optional(0, ...);.  Something about the loop + conditional + O1/O2/O3 optimization triggers the false positive. Thanks! -Jason //== // g++ -c sample.cc -O2 -Wall -Werror // gcc 6.1/6.2 and boost 1.61/1.62 #in

Re: PowerPC IEEE 128-bit floating point: Language standards

this type long double, or is another type being proprosed (such as __float128)? C++ doesn't require any particular value representation for arithmetic types. But std::numeric_limits::is_iec559 will let you know whether it conforms or not. Jason

Re: GCC version bikeshedding

On 07/20/2014 06:01 PM, Jakub Jelinek wrote: On Sun, Jul 20, 2014 at 05:59:08PM +0100, Richard Biener wrote: I understood we agreed on 5.0 and further 5.1, 5.2 releases from the branch and 6.0 a year later. With unspecified uses for the patch level number (so leave it at zero). Ian/Jason, is

Re: GNU Tools Cauldron 2014 - Slides for presentations

Ludovic Courtès said: > Agreed. I would recommend making them available from > (people behind webmas...@gnu.org > should be able to help.) > > Thanks, > Ludo’. Actually, audio-vi...@gnu.org. :) signature.asc Description: PGP signature

Re: Issue with sub-object __builtin_object_size

more than taking the address of a data member? Jason

Re: Issue with sub-object __builtin_object_size

since the least significant bit is set, it seems to me that GCC is correctly returning the size of that subobject. Jason

Re: Issue with sub-object __builtin_object_size

ther: __builtin_object_size ((struct pollfd *)myfd, 1); or even __builtin_object_size (&myfd->x, 1); That strikes me as a bug, especially the second one. Jason

Re: Issue with sub-object __builtin_object_size

On 09/16/2014 08:27 AM, Jason Merrill wrote: On 09/16/2014 06:23 AM, Ulrich Weigand wrote: Note that with a somewhat equivalent C construct: struct pollfd { int fd; short int events; short int revents; }; struct Pollfd { struct pollfd x; }; struct Pollfd myfd

Re: [PATCH] gcc parallel make check

en running into this with my rgt shell function: rgt () { ( cd ~/m/$CANON/gcc/gcc; make check-c++ ${1:+RUNTESTFLAGS="$*"} ) } If I say 'rgt dg.exp=var-templ1.C' the actual test results are lost in the explosion of shell verbosity. Could we add some '@'s to more of the rules, perhaps? Jason

Re: [PATCH] gcc parallel make check

On 09/22/2014 11:26 AM, Jakub Jelinek wrote: On Mon, Sep 22, 2014 at 11:21:14AM -0400, Jason Merrill wrote: If I say 'rgt dg.exp=var-templ1.C' the actual test results are lost in the explosion of shell verbosity. Could we add some '@'s to more of the rules, perhaps? I

Re: [PATCH] gcc parallel make check

-parallel-gcc goal would print the command, but check-parallel-gcc-1 or check-parallel-gcc-112 would not). So, like this? commit c750897381a3f936e27cabd825cfa85ce936a6a9 Author: Jason Merrill Date: Mon Sep 22 11:44:00 2014 -0400 gcc/ * Makefile.in (check-parallel-%): Add @. libstdc

Re: Towards GNU11

On 10/09/2014 08:45 AM, Matthias Klose wrote: What happened to the plans to stabilize the libstdc++ c++11 ABI? Is this still a target for GCC 5? Yes. Jason

Re: [Consult] g++: About "-Wunused-variable" for constant variable initialized by function

test.cc:2:12: warning: 'c' defined but not used [-Wunused-variable] const char c = n(); ^ The warning is correct (and new). Please submit bug reports via the website; see https://gcc.gnu.org/bugs/ Jason

Re: Account creation disabled on GCC Bugzilla

What should I tell a user who wants to create an account? Jason

Re: Enabling -fextended-identifiers by default

been thinking that we should do that. Jason

Re: C++ FE relying on not folding stuff for constexprs?

On 11/04/2014 09:11 AM, Richard Biener wrote: I have no idea how I can keep the testcase working - to me it seems it works by accident. So I am inclined to XFAIL it (it's an accept-invalid then). OK. Jason

Re: GCC 5.0 Status Report (2014-11-03), Stage 1 ends Nov 15th

On 11/03/2014 04:18 AM, Jakub Jelinek wrote: What larger merges are still planned for GCC 5? I'm planning to merge the concepts branch. Jason

Re: Query about the TREE_TYPE field

should be after the if instead of in front of it? Probably. Strange that the 35315 patch fixed the testcase with that change being a placebo... Jason

Re: Query about the TREE_TYPE field

On 11/18/2014 02:32 PM, Andrew MacLeod wrote: So it effectively does nothing. Unless Jason can think of a good reason for it, we probably ought to turf it. Its effectively a NOP. Yeah, go ahead. Jason

Re: [RFC] Dealing with ODR violations in GCC

On 02/16/2015 07:27 PM, Jan Hubicka wrote: Jason, I wonder if there is more informative way to print destructor during LTO than as __comp_dtor? You could print the mangled name, and possibly run it through __cxa_demangle if it starts with _Z. Laos for named types, perhaps printing just

Re: [debug-early] emitting early debug for external variables

If you move the call to rest_of_decl_compilation we could go through and prune the debug info for unused decls at dwarf2out_finish time, the way we do with unused types. Jason

Atomic operations and unaligned memory

still has size 3 and alignment 1. Did the design change, or is this a bug? Jason

Change to C++11 by default?

I think it's time to switch to C++11 as the default C++ dialect for GCC 6. Any thoughts? Jason

Re: Passsing unfinished types to gen_type_die_with_usage

dn't complain about that, but it doesn't seem necessary. I don't think you want to check TYPE_BINFO if !COMPLETE_TYPE_P. Jason

EH frame parsing tool

Hi All, As part of a project at the University of Virginia, I had the opportunity to create a parser for the exception handling information stored in ELF binaries. I got permission to open source the project, as I couldn't find anything else out there in the community that did this type of thing

Re: warning: conversion from ‘int’ to ‘char’ may change value

st of its operand types, but on the other hand that duplicates things that other parts of the compiler already deal with, so there's a question of how to share these rules between front and middle end, like we're doing more of with constant folding. Perhaps we could use the folder somehow. Jason

Re: warning: conversion from ‘int’ to ‘char’ may change value

value is known (i.e., when it's const > and with -O2) and fits in char, and when n's type is the char > (or under a bunch of other conditions), the function returns > the type char. Comments in the code indicate it's > an optimization. That may be fine as far as code correctness > goes but it doesn't seem quite right or robust to me because > it makes the warning appear inconsistent, both between > languages, and in C, between optimization levels. Lots of warnings vary between optimization levels, because optimizations make more information available. I don't think that's avoidable in general unless we want to more frequently enable some optimization passes when certain warnings are enabled. Jason

Re: Implementing p0515 - spaceship operator

ack as vdeurzen, if you want to contact me on another platform. Are > there other platforms for GCC development that are well suited to discussing > this topic? Many GCC developers hang out on the #gcc channel on irc.oftc.net. Jason

Re: Implementing p0515 - spaceship operator

On Wed, Sep 26, 2018 at 11:00 AM Jason Merrill wrote: > > On Mon, Sep 3, 2018 at 5:04 PM, Tim van Deurzen wrote: > > I must confess that in the last months I've not been able to find much time > > (I do this in my spare time) to work on this. Part of the problem is also &

Re: Implementing p0515 - spaceship operator

the git mirror is fine, I haven't touched the svn client in quite a while either. Jason

Re: GCC GSoC project idea to make C/C++ not promote memory_order_consume to memory_order_acquire

in the middle/back-end. There's some previous discussion of these issues at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448 So I'd suggest pinging Andrew Macleod. Jason > Anybody else interested in getting involved? > > Any other suggestions/comments? > > Thank

Re: GCC 8.3 Status Report (2019-02-08)

egression > > - PR88995. Nathan (or Jason), do you think it can be fixed soon? I think it was fixed by the patch for 88761 I just checked in. Jason > b) perhaps we shouldn't be sending non-dependent expressions through the > capture machinery, but instead wrapping them in

Re: [PATCH] Deprecate ia64*-*-*

I volunteer to be maintainer for ia64. Jason

if (x > ((2^x)-1)) optimization

x > ((1 << z) -1)) { ...} as if ( x >> z ) { ... } This does not appear to currently be a gcc optimization. What is involved in adding it? Jason

Re: [PATCH] Deprecate -frepo option.

gt;>>> removed in a later GCC version). > >>>>> > >>>>> Agree with you. I'm sending updated version of the patch. > >>>>> Patch can bootstrap on x86_64-linux-gnu and survives regression tests. > >>>> > >>>&

Re: Doubts regarding the _Dependent_ptr keyword

ized code that breaks the > > dependency. But applying -O1, i.e., allowing all the optimizations does so. > > As passes are applied in a certain order, we need to figure out up to what > > passes, the code remains same and after what pass the dependency does not > > holds. So, we need to check the translated code after every pass. > > > > Does this sounds like a workable plan for ? Let me know your thoughts. If > > this sounds good then, we can do this for all the optimizations that may > > kill the dependencies at somepoint. > > I don't know of a better plan. > > My usual question... Is there some way to script the checking of the > translated code at the end of each pass? The usual way to check the output of an optimization pass is by dumping the intermediate code at that point and matching the dump against a regexp, as in the tree-ssa directories in the testsuite. -fdump-tree-all will dump after all the gimple optimization passes, and you can look through them until you find the breakage. Jason

Re: [PATCH] Deprecate -frepo option.

GCC 10 but then I would start noting it is obsolete on the GCC 9 branch at least. I concur.  frepo's serial reinvocation of the compiler is not compatible with modern C++ code bases. Great. Then I'm sending patch that does the functionality removal. Ready to be installed after prop

Re: [PATCH] Deprecate -frepo on gcc-9 branch (PR c++/91125).

; if (value) flag_implicit_templates = 0; + warning (0, "%<-frepo%> is deprecated and will be removed " + "in a future release"); break; Is there a reason not to condition this on OPT_Wdeprecated (which defaults to on)? Jason

Re: [PATCH] Deprecate -frepo on gcc-9 branch (PR c++/91125).

On 7/12/19 8:44 AM, Martin Liška wrote: On 7/11/19 7:25 PM, Jason Merrill wrote: On 7/11/19 3:02 AM, Jakub Jelinek wrote: On Thu, Jul 11, 2019 at 08:48:52AM +0200, Martin Liška wrote: --- a/gcc/c-family/c-opts.c +++ b/gcc/c-family/c-opts.c @@ -501,6 +501,8 @@ c_common_handle_option (size_t

Re: GIMPLE clobber statement

The clobber means that 'a' no longer has a value, presumably because it has gone out of scope. On Tue, Jul 16, 2019, 2:07 PM navya deepika Garakapati < navyadeepika.garakap...@gmail.com> wrote: > Hi everyone, > > We are investigating the optimization issue with GCC trunk code and we have > the be

Re: LTO+profiled enabled builds

.sh should probably modified not to release the "stale" locks > based > on a fixed timeout value. How? > > While the "no-output" problem can be fixed in the lock script as well > (attached), this doesn't apply to third party apps. Having unbuffered output > and/or

GCC Git hooks

rg Pretty short...but the last line relies on Daniel's custom bugzilla/svnmailer integration (attached below), and it looks like Joel's hooks don't have anything comparable. Any thoughts about adjusting Daniel's bugzilla.py vs. pulling in something like http://www.the

Re: Adding -Wshadow=local to gcc build rules

On Fri, Sep 20, 2019, 2:21 PM Bernd Edlinger wrote: > On 9/19/19 12:19 PM, Richard Biener wrote: > > On Wed, Sep 18, 2019 at 3:09 PM Bernd Edlinger > > wrote: > >> > >> Hi, > >> > >> I'm currently trying to add -Wshadow=local to the gcc build rules. > >> I started with -Wshadow, but gave up that

Re: taking OpenCL C as a built-in lang of GCC?

On Fri, Sep 20, 2019, 1:10 PM Jeff Law wrote: > On 9/12/19 8:48 AM, Jianbin Fang wrote: > > Hello Guys, > > > > > > > > I am working on OpenCL for a couple of years, and would like to ask, > > as for GCC, why not taking OpenCL C as a built-in language in its > > front-end? > There's no inherent r

Re: Atomics in C++11

en wondering if it's time to move to C++11 in general, since we've had compilers with C++11 support for more than 5 years at this point. Jason

Re: LTO+profiled enabled builds

Have you had a chance to try this? On Sat, Sep 14, 2019 at 2:39 PM Jason Merrill wrote: > > How does this do for you? > > On Thu, Jul 4, 2019 at 7:15 AM Matthias Klose wrote: > > > > I'm running into some issues building LTO+profiled enabled configurations

Re: git conversion of GCC wwwdocs repository

is no ChangeLog in > wwwdocs, more sophisticated systems for identifying the relevant email > address for each commit from the ChangeLog aren't practical the same way > they are for the main GCC repository.) That would be my preference. Jason

Re: Moving to C++11

it would make it easier to > > > > > > allow multithreading support due to having a memory model > > > > > > alongside other features. Jason Merill mentioned due to it > > > > > > being so common it may be a good time to. > > > > > > Movin

Re: Commit messages and the move to git

in the subject line because I see patch mail interleaved with other mail in my inbox. > My mail to the libstdc++ list should have noted that [PATCH] tags in > the email subject should be omitted from the summary in the first line > of the commit log. And git format-patch/git am automatically add and remove [PATCH] appropriately. I tend to put the PR number at the beginning of the line, but I don't object to putting it at the end instead. Jason

Re: Feedback request on how best to handle recursion in concept satisfaction

te instantiations in the process. A parallel > -fsatisfaction-depth= limit and associated diagnostics seems like a > better way to resolve this issue. We track other substitution cases as part of the template instantiation depth limit, notably instantiating the noexcept-specifier. This seems like a similar situation. Jason

Re: Commit messages and the move to git

lines of the > form: > > > > > > I already said I would prefer things like > Patch related to PR323 > as the patch subject lines. No one argues that the current state of > affairs is good. I argue that replacing this with often wrong and > irrelevant information isn't the best we can do. > How about using the first line that isn't a ChangeLog date/author line, without trying to rewrite/augment it? Jason

Re: Commit messages and the move to git

On Mon, Nov 18, 2019 at 4:38 PM Richard Earnshaw (lists) < richard.earns...@arm.com> wrote: > On 18/11/2019 20:53, Jason Merrill wrote: > > On Mon, Nov 18, 2019 at 2:51 PM Segher Boessenkool < > > seg...@kernel.crashing.org> wrote: > > > >> On Mon,

Re: Commit messages and the move to git

On Tue, Nov 19, 2019 at 11:31 AM Segher Boessenkool < seg...@kernel.crashing.org> wrote: > On Tue, Nov 19, 2019 at 09:56:50AM -0500, Jason Merrill wrote: > > Yep. I don't think we need to worry about getting optimal one-line > > summaries for ancient commits; something r

Re: Commit messages and the move to git

e whole message. Jason

Re: [RFC] Characters per line: from punch card (80) to line printer (132) (was: [Patch][OpenMP/OpenACC/Fortran] Fix mapping of optional (present|absent) arguments)

e re emails, for > instance > > So, at least for me, that my terminals are 80 wide (but not x24) has > multiple reasons, and the _least_ of it is because that's what punch cards > had. > Agreed. I work with two side-by-side terminals, one 80x50 and the other as wide as fits in the rest of the screen, which currently happens to be 111x50. Jason

Re: [PATCH] Re: Minimal GCC version to compile the trunk

On 12/7/19 3:50 AM, Jakub Jelinek wrote: On Fri, Dec 06, 2019 at 06:43:35PM -0800, Andrew Pinski wrote: Hi all, Right now the trunk does not compile with GCC 4.4.7 (the GCC that comes with CentOS 6; yes I know old) after revision 277200 (October 19). AFAIK we haven't switched to requiring C

Re: Status of C++11 support

>From the earlier email thread, I think the plan is to switch to C++11 for GCC 11. Jason On Mon, Dec 9, 2019 at 1:43 PM Nicholas Krause wrote: > > > On 12/9/19 1:31 PM, Paul Smith wrote: > > On Mon, 2019-12-09 at 18:09 +, Andrew Haley wrote: > >> On 12/9/19 5:0

Re: Test GCC conversion with reposurgeon available

og file, do we wish to use the existing author map or do people > prefer using names from that map but with @gcc.gnu.org addresses (and > @gnu.org for usernames that only committed in the gcc2 period)? > I lean toward the latter. Jason

Re: Test GCC conversion with reposurgeon available

On Wed, Dec 18, 2019 at 1:17 PM Joseph Myers wrote: > On Wed, 18 Dec 2019, Jason Merrill wrote: > > > On Tue, Dec 17, 2019 at 4:39 PM Joseph Myers > > wrote: > > > > > Points for consideration: > > > > > > 1. Do we want some kind of rearran

Re: GIT: Monotonically increasing trunk and release branch ids

fter it) pointing to the gitweb using the git undescr and let > bugzilla turn those rNN- strings in the comments into URLs? > > Yet another thing are git hashes. For those, I'd be afraid that turning > [0-9a-f]{7,} > into URLs might trigger too often, do we want to use some prefix, like > g12345ab to > be https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=12345ab ? If we'd add an > prefix, > then we should also adjust the gcc-cvs mail content to use those prefixes in > there. At https://gcc.gnu.org/ml/gcc-patches/2019-09/msg01211.html I suggested the prefix "g:". Jason

Re: GIT: Monotonically increasing trunk and release branch ids

aps limit X to hashes here, i.e. 7-40 hex digits) > - gitweb with X > Why complicate this with the added 'g'? Jason

Re: 1-800-GIT-HELP

I'm also happy to help. On Mon, Jan 13, 2020 at 6:40 AM Jonathan Wakely wrote: > I imagine a lot of people are going to feel lost in the first few > weeks of using Git. > > If you are stuck or confused about using Git for GCC development and > too embarrassed to ask in public, feel free to conta

Re: 1-800-GIT-HELP

e command? > > git COMMAND ../../error/src SOMETHING > ... now ../../error/src has a checked out /users/nathan/error branch > created from master? > git worktree add -b error ../../error/src master Jason

Re: Rebasing local git branches on the new repo

On 1/13/20 6:00 AM, Jonathan Wakely wrote: On Sun, 12 Jan 2020 at 18:08, Jonathan Wakely wrote: Now that I've switched my local git tree to the new repo (by changing the URL for the 'origin' remote, and adding the old one as a 'gcc-old' remote) I've been experimenting with these commands to sw

Re: Doc question: is "templatized" a word?

shouldn't be turned into a hard error, the warning > complains about valid code, such as: > > template struct A { > friend int foo(T); > }; > > int main() { > A a; > } > > I think it warns because the meaning of that code changed, a *long* > time ago, so it's saying "if you wrote this code in the 1990s it might > do something different to what you expect." > > I'm not sure how useful that warning is now, although EDG warns for it > too (with a fix-it hint that I think is bogus): > > "fr.cc", line 2: warning: "int foo(T)" declares a non-template function -- add > <> to refer to a template instance > friend int foo(T); >^ That fix-it looks fine to me; it does seem odd for a template to declare as friend an open-ended family of overloaded functions. But I also am unsure how much of a problem this is for real code nowadays. Jason

Re: Doc question: is "templatized" a word?

On Wed, Feb 15, 2017 at 1:57 PM, Jonathan Wakely wrote: > On 15 February 2017 at 15:53, Jason Merrill wrote: >> On Sat, Feb 11, 2017 at 4:19 PM, Jonathan Wakely >> wrote: >>> On 11 February 2017 at 20:36, Sandra Loosemore wrote: >>>> On 02/11/2017 06:21 AM, J

Re: [C++ Patch] Remove is_auto_or_concept, etc (Was: Re: [C++, concepts] Two slightly obscure pt.c functions?)

OK. On Thu, Apr 27, 2017 at 2:02 PM, Paolo Carlini wrote: > 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 TEMPLA

Re: git-svn error due to out-of-sync changes?

ous, delayed updates. My guess is that Git-svn pull > requests are based on updates from SVN that happen only every > few minutes, but pushes happen in real time. So when we pull, > we're likely to get outdated sources (changes committed since > the last Git update are not included). But when we push, we're > likely to run into (at a minimum) ChangeLog conflicts with those > already committed changes that Git-svn hasn't been updated with. > This is just a wild guess based on the errors I've seen and > their increased incidence since 7 has been released. Yes, the git mirror can lag the SVN repo by a few minutes, that's why you need to 'git svn rebase' to pull directly from SVN before a commit. Jason

Re: git-svn error due to out-of-sync changes?

On Sun, May 21, 2017 at 7:34 PM, Martin Sebor wrote: > On 05/19/2017 03:46 PM, Jason Merrill wrote: >> >> On Thu, May 18, 2017 at 3:42 PM, Martin Sebor wrote: >>> >>> On 05/18/2017 12:55 PM, Markus Trippelsdorf wrote: >>>> >>>> On 2017.05

Re: Building on gcc112 is stuck in msgfmt

Been doing stability testing on my x86_64 Ryzen cpu using openSUSE's (Tumbleweed) "gcc7.1.1 20170802" + compiling Linux kernel source. Every so often, the build curiously stalls on a futex between cc1 and as. cc1 is on the futex. as is waiting to read. Could that hang be related to what's be

targetm.calls.promote_prototypes parameter

pass the individual parameter type instead. SH seems to be the only target that cares about the parameter; is this inconsistency causing trouble there? Jason

Re: targetm.calls.promote_prototypes parameter

while C++ FE seems to pass > the type of the param. I'm inclined to change the C++ FE to pass NULL_TREE instead until such time as someone cares. Jason

Re: targetm.calls.promote_prototypes parameter

On Wed, Dec 6, 2017 at 2:31 PM, DJ Delorie wrote: > > Jason Merrill writes: >> I'm inclined to change the C++ FE to pass NULL_TREE instead until such >> time as someone cares. > > The sh backend will at least not choke on that ;-) Thus. commit 301b543f38b687fe5d

Re: Finishing the repository conversion

try to nail down everyone's current address. But using the address from the ChangeLog sounds better. > One thing my software can do now that it couldn't do six months ago > is mine Author fields from ChangeLog histories. So you'll get a > better-quality conversion than if I had been able to finish this then. Excellent. Jason

Re: Finishing the repository conversion

On Mon, Dec 11, 2017 at 1:20 PM, Eric S. Raymond wrote: > Jason Merrill : >> I've pushed to the thyrsus gcc-conversion repository the rest of my >> work from last year, including a few changes to the attribution map >> and a post-processing script. > > Got it.

Re: How far should we trust ChangeLog attribution dates?

mber. If > the filter fails use the committer YMD. (This is what reposurgeon does now.) > > I think (iii) wins here, if the figure of merit is "lowest cumulative > authorship-time error over the whole history". YMD in the ChangeLog is typically commit date rather than authorship date anyway, so (i) and (iii) shouldn't differ much at all, and (i) seems simpler. Jason

Re: Implementing p0515 - spaceship operator

ort of question (without a patch). I tend to miss a lot that goes by on the mailing list, so CCing me directly about C++ changes is also helpful. Jason

Re: Implementing p0515 - spaceship operator

On Mon, Jan 8, 2018 at 5:13 PM, Jonathan Wakely wrote: > On 8 January 2018 at 22:07, Jason Merrill wrote: >> On Mon, Jan 8, 2018 at 4:07 PM, Tim van Deurzen wrote: >>> I've been spending some time the past few weeks implementing p0515r2, >>> i.e. the proposal

Re: gdb 8.x - g++ 7.x compatibility

e source > language. > > > So having the mangled symbol in DW_AT_name seems backwards and not the > point of it. If we add the mangled name, which seems reasonable, it should be in DW_AT_linkage_name. Jason

Re: why C++ cannot alias an inline function, C can ?

On Sun, Apr 1, 2018 at 7:34 AM, Jason Vas Dias wrote: > And even worse, the obvious workaround does not work: > > static inline __attribute__((always_inline)) > void foo(void) {} > > // static inline __attribute__((always_inline, alias("foo"))) > // void b

Re: where should C++ options be documented?

On Mon, Apr 2, 2018 at 9:33 PM, Martin Sebor wrote: > Jason, > > The manual mentions some C++-only options in the language > independent section 3.8 Options to Request or Suppress > Warnings and others in 3.5 Options Controlling C++ Dialect. > > For example, -Wcatch-v

Re: where should C++ options be documented?

On Tue, Apr 3, 2018 at 7:05 PM, Martin Sebor wrote: > On 04/03/2018 08:08 AM, Jason Merrill wrote: >> On Mon, Apr 2, 2018 at 9:33 PM, Martin Sebor wrote: >>> >>> Jason, >>> >>> The manual mentions some C++-only options in the language >>>

Re: where should C++ options be documented?

On Wed, Apr 4, 2018 at 2:18 PM, Martin Sebor wrote: > On 04/04/2018 07:05 AM, Jason Merrill wrote: >> >> On Tue, Apr 3, 2018 at 7:05 PM, Martin Sebor wrote: >>> >>> On 04/03/2018 08:08 AM, Jason Merrill wrote: >>>> >>>> On Mon, Apr 2, 2018

Re: [RFC] Deprecate "implicit int" for main() in C++

t; was confusing. > > N4659, Section 6.6.1 Para 5: > > If control flows off the end of the compound-statement of main, the > effect is equivalent to a return with operand 0 (see also 18.3). Indeed, so that optimization doesn't affect main, because there is no undefined behavior. The warning by default seems sufficient to me. Jason

Re: [RFC] Deprecate "implicit int" for main() in C++

concretely, deprecating it for a few releases would allow us to > apply the attached patch at some point in the future, so that instead > of: > > rt.c:1:6: warning: ISO C++ forbids declaration of ‘main’ with no type > [-Wreturn-type] > main() { return 0; } > ^ > > We'd get: > > rt.c:1:6: error: ISO C++ forbids declaration of 'main' with no type > [-fpermissive] > main() { return 0; } > ^ I'm still not sure what the advantage is of changing the warning to an error, but I suppose I wouldn't object either. Jason

Re: Apparent deeply-nested missing error bug with gcc 7.3

k to check uninstantiated templates with arbitrarily > complex expressions in them. And specifically, & might use an overloaded operator& that returns a reference, so it might be possible to have a valid instantiation, so the compiler must not reject the template. Jason

Re: -Wclass-memaccess warning should be in -Wextra, not -Wall

ing benchmarked the alternatives memcpy/memmove/memset definitely >>> makes a difference in various scenarios. >> >> Please open bugs with small test cases showing >> the inefficiencies so the optimizers can be improved. > > Some already exist (PR 86024 seems related, there are probably some closer > matches), but indeed more would be helpful. 86024 does seem relevant to the vector resize example. Jason

<    1   2   3   4   5   6   >