Re: diagnostics: %<%s%> vs. %qs

On Fri, 10 Mar 2017, Manuel López-Ibáñez wrote: > On 07/03/17 20:38, Roland Illig wrote: > > Hi, > > > > in the diagnostics the %qs specifier is used in most of the cases. But > > there are some cases left where the more complicated %<%s%> is used. Is > > there a good reason to prefer the complic

Re: Target maintainers: doc/install.texi love and care

On Sun, 12 Mar 2017, Gerald Pfeifer wrote: > References to dependencies on really, really old versions of > binutils (talking 10+ years here) which I think we can remove. > Let me follow-up with some of you with concrete suggestions > around that. I think we should set a global minimum binutils

Re: terminology: zero character vs. null character

On Sun, 12 Mar 2017, Gerald Pfeifer wrote: > On Fri, 10 Mar 2017, Manuel López-Ibáñez wrote: > >> I am currently translating GCC into German. During that, I noticed that > >> in some places the term "zero character" means '\0'. The official term > >> though is "null character", as per the C standa

Re: PATCH for Re: Release notes for GCC 7?

On Mon, 27 Mar 2017, carl hansen wrote: > suggested additions: > > get and insert the latest libtool, which includes files: > libtool.m4 ltgcc.m4 lt~obsolete.m4 ltoptions.m4 ltsugar.m4 ltversion.m4, > all way-old currently in gcc-7 libtool and auto* updates are only reasonable in developmen

Re: Plugin development under windows

On Mon, 27 Mar 2017, David Malcolm wrote: > > Substantially I'm writing just to ask: > > Can GCC plugins run on a windows build of GCC compiler (MinGW) ? > > I suspect the answer is "you're the first person to try this in a > while; some things may need fixing" - but that's a guess :) If it's Wi

Re: R: Plugin development under windows

On Mon, 27 Mar 2017, Davide Piombo wrote: > Sorry but it is not clear to me if the point is that the plugin > development must include some windows-related code that I'm actually > missing or if the problem is on the GCC side, that is inside GCC the > code section that loads the dll, or part of

Re: Who broke options.h?

On Tue, 25 Apr 2017, David Malcolm wrote: > >From what I can tell, the n_opts and opts in that file come direct from > opt-read.awk, which gets them from opt-gather.awk, which appears to > sort them (but my awk skills are weak). Maybe the opt-gather.awk call in Makefile.in needs to set LC_ALL=C.

Re: Who broke options.h?

On Tue, 25 Apr 2017, Jakub Jelinek wrote: > On Tue, Apr 25, 2017 at 09:54:04AM -0700, Steve Kargl wrote: > > On Tue, Apr 25, 2017 at 05:46:15PM +0200, Andreas Schwab wrote: > > > On Apr 25 2017, Steve Kargl wrote: > > > > > > > Someone (other than Richard who seems to have fixed his > > > > boot

Re: LCOV of current GCC

On Fri, 28 Apr 2017, Jeff Law wrote: > I did some similar work a few years back. Martin's results are comparable to > mine. Interestingly enough the 70-80% coverage we see for GCC is a "sweet > spot" in that several of the ancillary tools I tested were in the same overall > range. My observat

Re: PowerPC SPE maintainership (was Re: Obsolete powerpc*-*-*spe*)

On Sat, 29 Apr 2017, Segher Boessenkool wrote: > We also still have to agree on the target triples for the new port. > If you have any thoughts on this, I'd love to hear them. It seems fairly obvious that the powerpc-*-eabispe* and powerpc*-*-linux*spe* triples should continue to work while bein

Re: PowerPC SPE maintainership (was Re: Obsolete powerpc*-*-*spe*)

On Mon, 1 May 2017, Segher Boessenkool wrote: > My current patches have powerpc*-*-*spe* for the powerpcspe port. > Maybe it should also allow powerpcspe-*-*? If people are willing > to change the target triple they use. In that case, either config.sub or config.gcc could handle the mapping. >

Re: Support Library Requirements for GCC 7.1

On Wed, 3 May 2017, Joel Sherrill wrote: > My conclusion is that INSTALL/prerequisites.html is wrong on two > of the support libraries. Someone more knowledgeable will have > to narrow down the real minimum. I am just reporting what builds. The listed minima are for the scenario that you have a v

Re: [RFC] GCC 8 Project proposal: Extensions supporting C Metaprogramming, pseudo-templates

On Thu, 11 May 2017, Jonathan Wakely wrote: > On 10 May 2017 at 23:14, Daniel Santos wrote: > > Well my primary goal is programming with values that are constant in the > > compiler. There is no language in any C specification (that I'm aware of) > > for a "compile-time constant", but the concept

Re: [RFC] GCC 8 Project proposal: Extensions supporting C Metaprogramming, pseudo-templates

On Fri, 12 May 2017, Daniel Santos wrote: > > Note that while "other forms" might be accepted in initializers, they > > would still not be integer constant expressions (see DR#312). > > What is DR#312? http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_312.htm (but cf the older http://www.open

Re: [PATCH] Recognize '-' as special -MF argument (write to stdout)

Thanks, I've tested this patch for x86_64-pc-linux-gnu and committed it to trunk. As a new feature it doesn't seem appropriate for release branches. -- Joseph S. Myers jos...@codesourcery.com

Re: onlinedocs: How to link to external HTML documents?

On Tue, 11 Jul 2017, Georg-Johann Lay wrote: > Hi, in a recent change I added a pointer to some > Binutils documentation in doc/extend.texi: > > see the GNU Binutils > @w{@uref{https://sourceware.org/binutils/docs/as/AVR_002dDependent.html,AVR > assembler manual}}. For other manuals in the Texin

Re: onlinedocs: How to link to external HTML documents?

On Tue, 11 Jul 2017, Georg-Johann Lay wrote: > Joseph Myers schrieb: > > On Tue, 11 Jul 2017, Georg-Johann Lay wrote: > > > > > Hi, in a recent change I added a pointer to some > > > Binutils documentation in doc/extend.texi: > > > >

Re: Overwhelmed by GCC frustration

On Tue, 1 Aug 2017, Oleg Endo wrote: > To improve the situation, we'd need a lot more target specific tests > which test for those regressions that you have mentioned.  Then of > course somebody has to run all those tests on all those various > targets.  I think that's the biggest problem.  But st

Re: RFC: C extension to support variable-length vector types

On Wed, 2 Aug 2017, Richard Sandiford wrote: > (1) Does the approach seem reasonable? > > (2) Would it be acceptable in principle to add this extension to the > GCC C frontend (only enabled where necessary)? > > (3) Should we submit this to the standards committee? I think this only

Re: default function alignment

On Wed, 2 Aug 2017, Martin Sebor wrote: > If there is no way, would enhancing target-supports.exp to > include a header that defines the macro? (I assume that would > be gcc/target.h for FUNCTION_BOUNDARY). target.h is for target hooks, not target macros, and we want to move away from target mac

Re: An internal GCC compiler error when compiling GCC 7.x with GCC 6.x and 4.x

On Mon, 7 Aug 2017, Martin Liška wrote: > On 07/30/2017 05:08 AM, Ethin Probst wrote: > > --enable-checking=all --disable-nls --enable-fixed-point > > In file included from ../../../gcc-7.1.0/libgcc/fixed-bit.c:55:0: > > ../../../gcc-7.1.0/libgcc/fixed-bit.h:64:1: error: unable to emulate 'QQ'

Re: Future of libquadmath and glibc 2.26 (Re: statically compile in libquadmath)

On Tue, 8 Aug 2017, Janne Blomqvist wrote: > On a semi-related note, it seems the recently released glibc 2.26 > contains quad math functions. Does that mean we should change to use > those in preference to libquadmath when available? I suppose > libquadmath cannot be deprecated either, since it's

Re: Future of libquadmath and glibc 2.26 (Re: statically compile in libquadmath)

On Tue, 8 Aug 2017, Joel Sherrill wrote: > This may be a stupid question but with the focus of this > discussionon glibc, what does this all mean for non-glibc > targets? Well, Jakub recently updated parts of libquadmath from glibc (only the functions coming from the ldbl-128 directory, and excl

Re: [PATCH] Write dependency information (-M*) even if there are errors

On Wed, 9 Aug 2017, Jeff Law wrote: > This directly reverts part of Joseph's changes from 2009. I'd like to > hear from him on this change. The point of those changes was to make cpplib diagnostics use the compiler's diagnostic machinery rather than a separate set of diagnostic machinery in c

Re: [Bug web/?????] New: Fwd: failure notice: Bugzilla down.

On Tue, 15 Aug 2017, Martin Sebor wrote: > It looks like the data loss extends beyond 8/14. Bug 81840 > was created Sunday afternoon but is not in the database: > > https://gcc.gnu.org/ml/gcc-bugs/2017-08/msg01303.html > > (Strangely, 81841 is there, as is 81839.) That's another 81839 replac

Re: [Bug web/?????] New: Fwd: failure notice: Bugzilla down.

On Tue, 15 Aug 2017, Martin Sebor wrote: > On 08/15/2017 10:27 AM, Joseph Myers wrote: > > On Tue, 15 Aug 2017, Martin Sebor wrote: > > > > > It looks like the data loss extends beyond 8/14. Bug 81840 > > > was created Sunday afternoon but is not in t

Re: [Bug web/?????] New: Fwd: failure notice: Bugzilla down.

On Wed, 16 Aug 2017, Eric Gallager wrote: > I see Richi redid all his 7.2 release changes; does that imply that > the server restore is now complete? No, there's still a search process ongoing to identify corrupted or missing files by comparison with the last backup. My expectation is that all

Re: [Bug web/?????] New: Fwd: failure notice: Bugzilla down.

On Wed, 16 Aug 2017, NightStrike wrote: > On Mon, Aug 14, 2017 at 11:10 PM, Martin Sebor wrote: > > On 08/14/2017 04:22 PM, Eric Gallager wrote: > >> > >> I'm emailing this manually to the list because Bugzilla is down and I > >> can't file a bug on Bugzilla about Bugzilla being down. The error >

Re: RFC: Improving GCC8 default option settings

On Tue, 12 Sep 2017, Wilco Dijkstra wrote: > * Make -fno-trapping-math the default - another obvious one. From the docs: > "Compile code assuming that floating-point operations cannot generate >user-visible traps." > There isn't a lot of code that actually uses user-visible traps (if any

Re: RFC: Improving GCC8 default option settings

On Tue, 12 Sep 2017, Wilco Dijkstra wrote: > * Make -fno-math-errno the default - this mostly affects the code generated > for > sqrt, which should be treated just like floating point division and not set > errno by default (unless you explicitly select C89 mode). > > * Make -fno-trapping-ma

Re: RFC: Improving GCC8 default option settings

On Tue, 12 Sep 2017, Alexander Monakov wrote: > > * Make -fno-trapping-math the default - another obvious one. From the docs: > > "Compile code assuming that floating-point operations cannot generate > >user-visible traps." > > There isn't a lot of code that actually uses user-visible tra

Re: Byte swapping support

On Wed, 13 Sep 2017, Jim Wilson wrote: > Intel has support for this in icc. It took about 5 years for a small team to And allegedly has patents in this area. -- Joseph S. Myers jos...@codesourcery.com

Re: [RFC] type promotion pass

On Fri, 15 Sep 2017, Richard Biener wrote: > IIRC the last time we went over this patch I concluded a better first > step would be to expose call ABI details on GIMPLE much earlier. But I > may misremember here. Some call details are exposed in the front ends (see targetm.calls.promote_prototy

Re: Infering that the condition of a for loop is initially true?

On Mon, 18 Sep 2017, Niels Möller wrote: > Andreas Schwab writes: > > > The problem is that assert is not allowed to evaluate the expression > > with -DNDEBUG, and side effects must not be carried out. > > I'm suggesting that with -DNDEBUG, assert(x) should let the compiler > assume that x is t

Re: GCC Buildbot

On Wed, 20 Sep 2017, Paulo Matos wrote: > - buildbot can notify people if the build fails or if there's a test > regression. Notification can be sent to IRC and email for example. What > would people prefer to have as the settings for notifications? It's very useful if someone reviews regressions

Re: GCC Buildbot

On Wed, 20 Sep 2017, Segher Boessenkool wrote: > > - buildbot can notify people if the build fails or if there's a test > > regression. Notification can be sent to IRC and email for example. What > > would people prefer to have as the settings for notifications? > > Just try it! IRC is most usef

Re: GCC Buildbot

On Thu, 21 Sep 2017, Markus Trippelsdorf wrote: > And it has the basic problem of all automatic testing: that in the long > run everyone simply ignores it. Hence, see my comments about the value of having someone who monitors the results and files bugs / notifies patch authors / fixes issues. I

Re: GCC Buildbot

On Thu, 21 Sep 2017, Paulo Matos wrote: > I totally agree that only if people get involved in checking if there > were regressions and keeping an eye on what's going on are things going > to improve. The framework can help a lot here by notifying the right > people and the mailing list if somethin

Re: GCC Buildbot

On Thu, 21 Sep 2017, Paulo Matos wrote: > Interesting suggestion. I haven't had the opportunity to look at the > compile farm. However, it could be interesting to have a mix of workers: > native compile farm ones and some x86_64 doing cross compilation and > testing. Note that even without a simu

Re: GCC Buildbot

On Fri, 22 Sep 2017, Paulo Matos wrote: > > Note that even without a simulator (but with target libc), you can test > > just the compilation parts of the testsuite using a board file with a > > dummy _load implementation. > > > > I was not aware of that. I will keep that in mind once I try to

Re: strlen optimizations based on whether stpcpy is declared?

On Mon, 2 Oct 2017, Martin Sebor wrote: > IMO, a reasonable question a GCC user might ask is: when I make > a call to a standard library function via __builtin_foo() in > a language conformance mode where foo is not a standard function, > can I expect GCC to transform it to some equivalent call to

Re: Exhaustive Instructions for Toolchain Generation

There are over 25000 words of GCC installation documentation in install.texi, and that's not even including e.g. libstdc++ configure options documented elsewhere. Other toolchain components also have such documentation. It's true that, as a consequence of the toolchain being made up of multip

Re: Exhaustive Instructions for Toolchain Generation

On Wed, 4 Oct 2017, Jeffrey Walton wrote: > Of the thousands of hits when searching for the information on a task > like compiling GCC, there's probably a handful of good sources. > Everything else is just crap on the web that someone decided to blog > about. (This is speaking from experience). T

Re: RFC: Update top level libtool files

On Tue, 10 Oct 2017, Nick Clifton wrote: > Hi Guys, > > I would like to update the top level libtool files (libtool.m4, > ltoptions.m4, ltsugar.m4, ltversion.m4 and lt~obsolete.m4) used by > gcc, gdb and binutils. Currently we have version 2.2.7a installed in > the source trees and I wou

Re: RFC: Update top level libtool files

On Tue, 10 Oct 2017, Nick Clifton wrote: > > I do not know > > if there are other local libtool changes that are not in version 2.4.6; it > > would be necessary to check all differences from 2.2.7a to determine > > whether any need to be re-applied to 2.4.6. > > *sigh* It seems that 2.2.7a wa

Re: GCC Buildbot Update - Definition of regression

On Tue, 10 Oct 2017, Paulo Matos wrote: > ANY -> no test ; Test disappears No, that's not a regression. Simply adding a line to a testcase will change the line number that appears in the PASS / FAIL line for an individual assertion therein. Or the names will change when e.g. -std=c++2a

Re: GCC Buildbot Update - Definition of regression

On Wed, 11 Oct 2017, Paulo Matos wrote: > On 10/10/17 23:25, Joseph Myers wrote: > > On Tue, 10 Oct 2017, Paulo Matos wrote: > > > >> new test -> FAIL; New test starts as fail > > > > No, that's not a regression, but you might want to tr

Re: GCC Buildbot Update - Definition of regression

On Wed, 11 Oct 2017, Christophe Lyon wrote: > * {PASS,UNSUPPORTED,UNTESTED,UNRESOLVED}-> XPASS I don't think any of these should be considered regressions. It's good if someone manually checks anything that's *consistently* XPASSing, to see if the XFAIL should be removed or restricted to narro

Re: GCC Buildbot Update - Definition of regression

On Wed, 11 Oct 2017, Martin Sebor wrote: > I don't have a strong opinion on the definition of a Regression > in this context but I would very much like to see status changes > highlighted in the test results to indicate that something that There are lots of things that are useful *if* you have so

Re: GNU Tools Cauldron 2017 follow up: "Reviewed-by" etc.

On Thu, 19 Oct 2017, Thomas Schwinge wrote: > Hi! > > Still waiting for any kind of reaction -- general process-change inertia, > chicken-and-egg problem, I suppose. ;-/ > > I have now put the proposed text onto a wiki page, so that those > interested have a convenient handle to use, >

Re: LLVM disagrees with GCC on bitfield handling

There is a line of C90 DRs and associated textual history (compare the relevant text in C90 and C99, or see my comparison of it in WG14 reflector message 11100 (18 Apr 2006)) to the effect of bit-fields acting like they have a type with the given number of bits; that line is what's followed by

Re: bitfield types

On Tue, 14 Nov 2017, Mike Stump wrote: > The testsuite/gcc.c-torture/execute/pr34971.c seems wrong to me. The > type of the expression x.b << 8 has size 8, a size 8 integral type is a > 64-bit type. If the result is a 64-bit type, then it's argument (x.b) > was a 64-bit type. In C++, we obse

Re: glue file built with compiler in PATH in out of tree testing

On Wed, 6 Dec 2017, Thomas Preudhomme wrote: > == problem == > > I'm not sure where is the proper place to fix this. Obviously setting > CC_FOR_TARGET in contrib/test_installed or when calling runtest manually would > work but I wonder if this would not be better fixed somewhere else? The rest >

Re: glue file built with compiler in PATH in out of tree testing

On Thu, 7 Dec 2017, Thomas Preudhomme wrote: > That seems to go counter to the --prefix option of contrib/test_installed > which is meant to test a compiler at an arbitrary path. This suggest the > compiler is not expected to be in PATH or in any dejagnu configuration file. > Seems most of the tes

Re: Finishing the repository conversion

On Sun, 10 Dec 2017, Jason Merrill wrote: > > I'm mirroring the repo now. It would helpful if I could get an > > up-to-date copy of the repository's attribution map (usernames to full > > names and email addresses). > > I've pushed to the thyrsus gcc-conversion repository the rest of my > work f

Re: Finishing the repository conversion

On Mon, 11 Dec 2017, Jason Merrill wrote: > > What do your repo load times look like, and how much RAM is in your > > surgery machine? My loads are currently hanging in D state after 13 hours > > on > > a 64GiB hexacore Xeon 3 running at nominally 3.50GHz. I'm beginning > > to wonder if I have

Re: Finishing the repository conversion

On Sat, 9 Dec 2017, Eric S. Raymond wrote: > 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. Observations from the code for doing this, w

Re: nexttoward/nextafter attribute question

On Mon, 11 Dec 2017, Steve Ellcey wrote: > the attribute.  The other is why the function would be pure with > -fno-math-errno but const otherwise.  I would think that the -fno-math-errno > version would be const (stricter than pure) since it is not setting > errno.  Finally, how can I check if -fr

Re: nexttoward/nextafter attribute question

On Tue, 12 Dec 2017, Jakub Jelinek wrote: > Any other functions that are using ATTR_MATHFN_FPROUNDING_ERRNO or > ATTR_MATHFN_FPROUNDING and aren't affected by fesetround? drem, fmod, frexp, ilogb, modf, remainder, remquo, significand should all be independent of the rounding mode. -- Joseph S.

Re: Conversion progress report

On Thu, 14 Dec 2017, Eric S. Raymond wrote: > There's a fair amount of surgery to be done still. You have 151 > mid-branch deletealls. This usually indicates that a Subversion tag or > branch was created by mistake, and someone later tried to undo the Some may be mistakes - I think some are del

Re: Successful full conversion

On Sat, 16 Dec 2017, Eric S. Raymond wrote: > Successful full conversion to a live git repo achieved. Conversion > stuff pushed. Does it pass comparison (of both file content and permissions) of branch tips / tags, as an important test of whether there are any further bugs to resolve that show

Re: How far should we trust ChangeLog attribution dates?

On Thu, 21 Dec 2017, Eric S. Raymond wrote: > Jeff Law : > > I think we've routinely made the ChangeLog date the commit date. > > Ah, so you modify patches as they come in? Yes. It's explicitly documented at https://gcc.gnu.org/svnwrite.html#checkin - "Use the current date/time for the Change

Re: Dropping ChangeLogs

On Fri, 22 Dec 2017, Eric S. Raymond wrote: > Janne Blomqvist : > > My secret desire is that once we get this done we would drop these > > silly ChangeLogs. Although I'm not a kernel developer, I kind of like > > the Linux kernel style, where the commit msg contains a reasonably > > in-depth motiv

Re: Implementing p0515 - spaceship operator

On Thu, 11 Jan 2018, David Brown wrote: > Maybe it is easier to say "gcc supports <=> in C++2a, and as an > extension also supports it in C and C++ of any standard" ? I don't > believe there is any way for it to conflict with existing valid code, so > it would do no harm as a gcc extension like t

Re: Unstable build/host qsorts causing differing generated target code

On Fri, 12 Jan 2018, Alexander Monakov wrote: > No. The qsort_chk effort was limited to catching instances where comparators > are invalid, i.e. lack anti-commutativity (may indicate A < B < A) or > transitivity property (may indicate A < B < C < A). Fixing them doesn't > imply making correspondin

Re: Status of m32c target?

On Fri, 12 Jan 2018, Jeff Law wrote: > I was going to suggest deprecation for gcc-8 given how badly it was > broken in gcc-7 and the lack of maintenance on the target. While we're considering deprecations, what happened to the idea of setting a timescale by which cc0 targets need to be converted

Re: Status of m32c target?

On Mon, 15 Jan 2018, Sebastian Huber wrote: > On 13/01/18 00:16, Jeff Law wrote: > > On 01/12/2018 04:07 PM, Joseph Myers wrote: > > > On Fri, 12 Jan 2018, Jeff Law wrote: > > > > > > > I was going to suggest deprecation for gcc-8 given how badly it was

Re: Bugzilla timing out

On Mon, 15 Jan 2018, Martin Sebor wrote: > I'm having trouble bringing up bugs or updating them. Has > anyone else noticed Bugzilla (and/or other services running > on gcc.gnu.org) being very slow or timing out? I'm presuming this comes from the read errors on sdi that I just reported to overse

Re: GCC 8.0.0 Status Report (2018-01-15), Trunk in Regression and Documentation fixes only mode

On Tue, 16 Jan 2018, Segher Boessenkool wrote: > On Mon, Jan 15, 2018 at 09:21:07AM +0100, Richard Biener wrote: > > We're still in pretty bad shape regression-wise. Please also take > > the opportunity to check the state of your favorite host/target > > combination to make sure building and test

Re: Copyright assignment form

On Tue, 16 Jan 2018, Jim Wilson wrote: > You should contact ass...@gnu.org directly. The standard forms contain > language about patents that Qualcomm lawyers are unlikely to be comfortable > with, and may require negotiating a non-standard agreement. As best as I can > tell, the FSF has never re

Re: Copyright assignment form

On Tue, 16 Jan 2018, Jim Wilson wrote: > You can file an assignment that covers a single patch, or a single > project, or multiple patches, or multiple projects, or even all > patches for all projects. Though of course the lawyers will have a > say in this, as they may not be comfortable with a b

Re: Google Summer of Code 2018: Call for mentors and ideas

On Wed, 17 Jan 2018, Martin Jambor wrote: > 3?) Joseph Myers brought up idea to do "built-in functions for TS 18661 > floating-point functions - which has the feature that there are a > lot of similar built-in functions for C99/C11 functions to serve as > a guide for

Re: Google Summer of Code 2018: Call for mentors and ideas

On Thu, 18 Jan 2018, Eric Gallager wrote: > Would it make sense to recycle old GSoC projects that never got > completed? I'm wondering about the "replace libiberty with gnulib" one I'd like to see that finished, but I'm not convinced it makes a good GSoC project, given how it involves tricky por

Re: Google Summer of Code 2018: Call for mentors and ideas

On Fri, 19 Jan 2018, Martin Jambor wrote: > Hi Joseph, > > On Wed, Jan 17 2018, Joseph Myers wrote: > > On Wed, 17 Jan 2018, Martin Jambor wrote: > > > >> 3?) Joseph Myers brought up idea to do "built-in functions for TS 18661 > >> floating-point

Re: Bugzilla timing out

On Fri, 26 Jan 2018, Frank Ch. Eigler wrote: > Hi - > > > Thanks for looking into it. I'm still (or again) seeing very > > poor responsiveness. Right now, bringing up an existing bug > > takes an entire minute. > > There has been quite a burst in activity on sourceware.org over the > last few

Re: GCC 8.0.0 Status Report (2018-01-15), Trunk in Regression and Documentation fixes only mode

On Tue, 6 Feb 2018, Vincent Lefevre wrote: > The issues were also present on 64-bit platforms and were due to > a bug in mpfr_div_ui, which has always been present, since 1999. > With MPFR 4.0.0, they are also visible with mpfr_div just because > mpfr_div now uses mpfr_div_ui in some simple cases.

Re: GCC 8.0.0 Status Report (2018-01-15), Trunk in Regression and Documentation fixes only mode

On Tue, 6 Feb 2018, Vincent Lefevre wrote: > Well, if I add -std=c99 or -std=c11, the failure disappears. The > reason is that GCC generates a FMA (indeed, this new machine has > a FMA), but this occurs across different C statements. So, maybe > not a bug, but a bad feature, IMHO. Use -ffp-contra

Re: $target.h vs $target-protos.h

On Sun, 18 Feb 2018, Sandra Loosemore wrote: > So what is the purpose of having a separate $target-protos.h? It looks like the original explanation was , "Because tm_p.h needs to be included after tree.h and rtl.h.". It's certainly sti

Re: $target.h vs $target-protos.h

On Sun, 18 Feb 2018, Sandra Loosemore wrote: > Thanks, this makes sense. I think I could produce a documentation patch that > explains that the difference is early vs late inclusion, and explains that any > declarations involving tree or rtx types must go in $target-protos.h because > those types

Re: $target.h vs $target-protos.h

On Mon, 19 Feb 2018, Sandra Loosemore wrote: > On 02/19/2018 09:45 AM, Joseph Myers wrote: > > On Sun, 18 Feb 2018, Sandra Loosemore wrote: > > > > > Thanks, this makes sense. I think I could produce a documentation patch > > > that > > > explains that

Re: GSoC

On Thu, 1 Mar 2018, Tejas Joshi wrote: > "GCC supports built-in functions for math.h and complex.h functions in > the C99/C11 standards (both folding calls for constant arguments, and > expanding inline when the processor supports appropriate > functionality). More such functions have been added i

Re: Further for GSoC.

On Fri, 2 Mar 2018, Tejas Joshi wrote: > I have some university level experience of working and programming assembly > language under Intel 80386DX architecture. I think it may help for > implementing supports for other architectures. Just for start, you > mentioned roundeven function as a guide f

Re: About the Idea Presented by GCC for Google Summer of Code

; arguments and expanding inline,Which would be mentored by Joseph Myers. >I found this idea interesting and really possible for me. But > I'm finding difficulty in proposing the the project as i never worked for > Open source soft wares.Would you Please help me with more descr

Re: GSoC 2018 - Adding functions in math.h

On Mon, 12 Mar 2018, Tejas Joshi wrote: > Hello, > Thanks to all for your inputs to get me through. As mentioned above, I > have added the function roundeven in match.pd > and its declaration in builtins.def for the testcase 0. Following is > the patch for the same. The existing rounding function

Re: Another libmvect question (vectorizing sincos calls)

On Tue, 27 Mar 2018, Steve Ellcey wrote: > Here is another libmvec question.  While testing on x86 I could easily make > a loop with calls to sin, cos, log, exp, or pow and see them vectorized when > I compile with -Ofast.  But if I try making a loop with sincos, it does not > get vectorized.  Is

Re: Google Summer of Code 2018: Call for mentors and ideas

Now the student application deadline has, I understand, passed, how do we go about collectively deciding which are the best proposals to request slots for? -- Joseph S. Myers jos...@codesourcery.com

Re: Google Summer of Code 2018: Call for mentors and ideas

... looking at the actually submitted proposals, I see most of the people who contacted the mailing list have not actually submitted anything in the end, so the selection of proposals to get slots should be straightforward after all. -- Joseph S. Myers jos...@codesourcery.com

Re: "file name" vs "filename"

On Sun, 1 Apr 2018, Gerald Pfeifer wrote: > And now to the most important question of all. ;-) Should we use > "file name" or "filename" when referring to the name of a file? See the GNU Coding Standards: Please do not use the term ``pathname'' that is used in Unix documentation; use ``file

RE: Introducing a nanoMIPS port for GCC

On Wed, 2 May 2018, Matthew Fortune wrote: > qemu > > http://lists.nongnu.org/archive/html/qemu-devel/2018-05/msg00081.html That answers one thing I was wondering, by saying you're using the generic Linux kernel syscall interface rather than any of the existing MIPS syscall interfaces. Is

Re: fminnm/fmaxnm generation in aarch64

On Mon, 7 May 2018, Indu Bhagat wrote: > Q2. If one wants the compiler to generate fminnm/fmaxnm instructions, while > conforming with IEEE standard, the way to do that will be to use math > builtins fmin()/fmax(). Is this correct understanding? For IEEE 754-2008 minNum / maxNum operation

Re: Unused __builtin_ia32_* builtins

On Thu, 10 May 2018, Jakub Jelinek wrote: > __builtin_ia32_fldenv > __builtin_ia32_fnclex > __builtin_ia32_fnstenv > __builtin_ia32_fnstsw Calls to these are generated by ix86_atomic_assign_expand_fenv. -- Joseph S. Myers jos...@codesourcery.com

Re: Auto-generated .rodata contents and __attribute__((section))

This has been listed as a desirable feature for a long time: https://gcc.gnu.org/projects/optimize.html#putting_constants_in_special_sections -- Joseph S. Myers jos...@codesourcery.com

Re: So what's the status of the Git migration?

On Thu, 17 May 2018, Richard Earnshaw (lists) wrote: > Another year; another release; and still no sign of progress on the git > migration. > > Any ideas on how much longer this is going to take? See git://thyrsus.com/repositories/gcc-conversion.git for the current version of the conversion mac

Re: DF mangling

On Tue, 22 May 2018, Segher Boessenkool wrote: > Hi! > > The Itanium C++ ABI defines > https://itanium-cxx-abi.github.io/cxx-abi/abi.html#mangling-builtin > DF_ as the mangling for the bit IEEE binary float type, > i.e. _Float. > > But the libiberty unwinders decode DF as fixed point type, see

Re: not computable at load time

On Tue, 29 May 2018, Richard Biener wrote: > The testcase dates back to some repository creation rev. (egcs?) and > I'm not sure we may compute the difference of addresses of structure > members. So that GCC accepts this is probably not required. Joseph > may have a definitive answer here. My m

Re: Adding a libgcc file

On Tue, 29 May 2018, Paul Koning wrote: > Question about proper target maintainer procedures... > > The pdp11 target needs udivhi3 in libgcc. There's udivsi3, and it's > really easy to tweak those files for HImode. And that works. > > Should I add the HI files to the libgcc directory, or unde

Re: aarch64-none-elf build broken

On Fri, 8 Jun 2018, Jonathan Wakely wrote: > > The root cause is PR66203 which I reported quite some time ago, which > > points to a newlib problem: on aarch64 there is no default rom > > monitor, one has to explicitly use a --specs flag for the link to > > succeed. > > I have no idea why this ca

Re: How to get GCC on par with ICC?

On Fri, 15 Jun 2018, Jeff Law wrote: > And resolution on -fno-math-errno as the default. Setting errno can be > more expensive than people realize. I don't think I saw any version of the -fno-math-errno patch proposal that included the testsuite updates I'd expect. Certainly gcc.dg/torture/pr

Re: libmvec in gcc to have vector math in fortran

On Fri, 15 Jun 2018, Thomas Koenig wrote: > Hi Richard, > > > First and foremost we need a syntax that actually works for the > > Fortran frontend and a way to automatically include this special > > header / module. > > I can imagine parsing the relevant headers while compiling gfortran > and ge

Re: libmvec in gcc to have vector math in fortran

On Mon, 18 Jun 2018, Richard Biener wrote: > I'm thinking of sth like the C stdc-predef.h header which is always included > by the compiler. So it needs to be sth parseable by gfortran which means > it needs to be a module or sth equivalent to a fortran include file. To me that suggests somethin

<    1   2   3   4   5   6   7   8   >