Re: Weird behaviour (bug?) of __builtin_nans()

On Fri, 31 Dec 2021, FX via Gcc wrote: > The reason I ended up in this rabbit hole is that I am implementing some > handling of signalling NaNs in libgfortran. Could someone either confirm > that the behavior observed above is a bug, or if not, kindly explain to > me why it happens? 1. You sho

Re: Need for __builtin_issignaling()

On Wed, 29 Dec 2021, FX via Gcc wrote: > Is it particularly hard to do? I came across a post in the list archives > from Joseph, who said it would be good to have. I’d be willing to try > and put something together, unless you think it’s a big project. Any > pointers as to how to start would be

Re: _Float16-related failures on x86_64-apple-darwin

On Fri, 24 Dec 2021, Hongtao Liu via Gcc wrote: > gcc define __FLT_EVAL_METHOD__ according to > > builtin_define_with_int_value ("__FLT_EVAL_METHOD__", > c_flt_eval_method (true)); > > and guess we need to handle things like: > >/* GCC only supports one interchange type right now, _Float1

Re: gccadmin hooks: make it a public git repo

On Mon, 13 Dec 2021, Martin Liška wrote: > I would like to ping this as Joel wrote that we'll be switching > to Python3. I know there are some scripts that are definitely in Python 2 > and I would like to port it. Scripts in hooks-bin are executed in separate processes, not imported into the sam

Re: ISO C3X proposal: nonnull qualifier

On Thu, 2 Dec 2021, Alejandro Colomar (man-pages) via Gcc wrote: > So, now this can be made non-flow-sensitive, which was a big concern. And now > the biggest concern I can see is that this qualifier works opposite to const > (here discarding is allowed but not adding it), and that is contrary to

Re: ISO C3X proposal: nonnull qualifier

On Mon, 15 Nov 2021, Alejandro Colomar (man-pages) via Gcc wrote: > Hi Joseph, > > On 11/15/21 23:17, Joseph Myers wrote: > > On Mon, 15 Nov 2021, Alejandro Colomar (man-pages) via Gcc wrote: > > > > > How is restrict handling that problem of lvalue-to-rvalue

Re: ISO C3X proposal: nonnull qualifier

On Mon, 15 Nov 2021, Alejandro Colomar (man-pages) via Gcc wrote: > How is restrict handling that problem of lvalue-to-rvalue already? restrict has tricky rules about "based on" (6.7.3.1). -- Joseph S. Myers jos...@codesourcery.com

Re: ISO C3X proposal: nonnull qualifier

lvalue-to-rvalue conversion loses qualifiers, which makes any rules based on whether the RHS of an assignment was nonnull-qualified very problematic. (The specification of restrict is exceedingly tricky and very unlikely to be a good basis for specifying any other feature.) I don't think a man

Re: New attribute proposal: [[gnu::no_int_promotion]]

On Wed, 10 Nov 2021, Alejandro Colomar (man-pages) via Gcc wrote: > I'm proposing an attribute that would apply a new set of rules, specifically > designed for fixed width operations, but which also try to be sane defaults > for any other scenario. Let's call it [[gnu::no_int_promotion]]). C23 _

Re: [PATCH] Add GNU_PROPERTY_1_GLIBC_2_NEEDED

On Wed, 27 Oct 2021, H.J. Lu via Libc-alpha wrote: > Linker adds glibc versions in GNU_PROPERTY_1_GLIBC_2_NEEDED to the > .gnu.version_r section and removes GNU_PROPERTY_1_GLIBC_2_NEEDED note > when generating shared libraries and executables. Note that there is no guarantee that a new glibc vers

-Waggressive-loop-optimizations errors building glibc tests (32-bit only)

My build-many-glibcs.py bot is showing new -Waggressive-loop-optimizations errors building the glibc testsuite for 32-bit architectures with GCC mainline: In function 'dynarray_long_noscratch_resize', inlined from 'test_long_overflow' at tst-dynarray.c:489:5, inlined from 'do_test' at ts

Re: Old installation docs

On Wed, 20 Oct 2021, Jonathan Wakely via Gcc wrote: > https://gcc.gnu.org/install/ says: > > "There are also some old installation instructions > , which are mostly obsolete but still > contain some information which has not yet been merged into the main part

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

On Fri, 15 Oct 2021, Bill Schmidt via Gcc wrote: > Beyond ABI and compiler support, glibc would also need to support IEEE > QP for these other targets. Currently we only have support for > powerpc64le. And that would involve new syntax in glibc Versions files, as discussed in

Re: environment register / ABI

On Wed, 13 Oct 2021, Martin Uecker wrote: > There is currently no standard way to set or query > the static chain from C although this is used by > many other languages. Also function pointers in C > usually can not store the static chain. I am going > to propose to WG14 to add some kind of wide f

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

On Fri, 8 Oct 2021, Segher Boessenkool wrote: > But many CPUs do not have hardware floating point in any variant, and > their ABIs / calling conventions do not mention floating point at all. > Still, this works with GCC just fine: it passes floats and doubles the > same as 32-bit resp. 64-bit inte

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

On Wed, 6 Oct 2021, Segher Boessenkool wrote: > With "not in any" I mean: not for other architectures either! All archs > that do not say anything about floating point in their machine > description get a working sofware floating point (for binary32 and > binary64 currently). Any architecture th

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

On Wed, 6 Oct 2021, Segher Boessenkool wrote: > > There's still some code in the compiler for a very old soft-float ABI for > > binary128 long double (passing by reference, using _q_* libcall names). I > > don't really think it makes much sense to use that for future _Float128 > > support for

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

On Wed, 6 Oct 2021, Segher Boessenkool wrote: > Soft float is not described in any formal ABI btw (well, except the > Power 32-bit embedded ABI :-) ) -- it is an compiler-internal affair. It's fully documented in the unified 32-bit ABI document (under ATR-SOFT-FLOAT conditionals). There's still

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

On Wed, 6 Oct 2021, Jakub Jelinek via Gcc wrote: > On Wed, Oct 06, 2021 at 11:07:30AM -0500, Segher Boessenkool wrote: > > We can emulate it everywhere (using libquadmath for example). This can > > magically make -msoft-float work as well everywhere, btw. > > Emulation is one thing, but another

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

On Mon, 4 Oct 2021, Segher Boessenkool wrote: > Some current Power GCC targets support neither. Some support only > double-double. Making IEEE QP float work on those (that is, those that > are < power8) will require some work still: it should use libquadmath or > similar, but that needs to be pu

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

On Mon, 4 Oct 2021, Jakub Jelinek via Gcc wrote: > One problem with that is that I think IEEE quad long double support relies > on glibc 2.32 or later, so not sure what exactly would be done if gcc is > built against older glibc when it needs to call libm routines. Perhaps > convert to __ibm128,

Re: [libc-coord] Add new ABI '__memcmpeq()' to libc

On Fri, 17 Sep 2021, Richard Biener via Gcc wrote: > when the libc version targeted does not provide __memcmpeq? Or would > glibc through magically communicate the availability of the new ABI > without actually declaring the function? > (I'm not sure whether a GCC build-time decision via configu

Re: [libc-coord] Add new ABI '__memcmpeq()' to libc

On Thu, 16 Sep 2021, Chris Kennelly wrote: > The mem* functions are extremely sensitive to instruction cache effects, so > having 3 unique implementations (__memcmpeq, bcmp, memcmp) that do similar, I don't think anyone is suggesting 3 unique implementations. The obsolescent name bcmp would be

Re: [libc-coord] Add new ABI '__memcmpeq()' to libc

On Thu, 16 Sep 2021, James Y Knight wrote: > Wouldn't it be far simpler to just un-deprecate bcmp? The aim is to have something to which calls can be generated in all standards modes. bcmp has never been part of ISO C; there's nothing to undeprecate there. -- Joseph S. Myers jos...@codesourc

Re: [libc-coord] Add new ABI '__memcmpeq()' to libc

On Thu, 16 Sep 2021, Chris Kennelly wrote: > In terms of relying on the feature: If __memcmpeq is ever exposed as an a > simple alias for memcmp (since the notes mention that it's a valid > implementation), does that open up the possibility of depending on the > bcmp-like behavior that we were tr

Re: Developer branches

On Wed, 15 Sep 2021, Paul Koning via Gcc wrote: > Some questions about developer branches: > > 1. Who may create one? Who may write to them? > 2. Are they required to be listed in https://gcc.gnu.org/git.html ? I > notice it mentioned a whole pile of them, most of which don't seem to > exist.

Re: post-commit hook failure

On Wed, 25 Aug 2021, Lewis Hyatt via Gcc wrote: > I think the commit has pushed fine, however some expected things did > not happen such as updating Bugzilla. The error makes some sense > because this commit added tests with non-standard encodings, while > python3 wants everything it reads to be u

Re: Usage of EBCDIC (IBM 1047)

On Mon, 23 Aug 2021, Jesus Diaz via Gcc wrote: > However i've noticed that on functions with the printf-style formatting > attribute the EBCDIC strings tend to generate spurious errors - to my surprise > the "%" character seems to cause these issues. This may be due to the ASCII > host mis-represe

Re: gcc_assert() and inhibit_libc

On Mon, 16 Aug 2021, Sebastian Huber wrote: > Ok, good. I will try to figure out what can be done. One problem is that > tsystem.h is included before tm.h. Independent of this Joseph S. Myers said > in the recent patch review with respect to the gcov_type size that removing > tm.h from the target

Re: Suboptimal code generated for __buitlin_trunc on AMD64 without SS4_4.1

On Sat, 7 Aug 2021, Stefan Kanthak wrote: > Joseph Myers wrote: > > You should be looking at TS 18661-3 / C2x Annex F for sNaN handling; > > I'll do so as soon as GCC drops support for all C dialects before C2x! > > Unless you use a time machine and fix the POSIX and

Re: Suboptimal code generated for __buitlin_trunc on AMD64 without SS4_4.1

On Fri, 6 Aug 2021, Stefan Kanthak wrote: > > I don't know what the standard says about NaNs in this case, I seem to > > remember that arithmetic instructions typically produce QNaN when one of > > the inputs is a NaN, whether signaling or not. > >

Re: Failures building glibc with mainline GCC

On Tue, 3 Aug 2021, Segher Boessenkool wrote: > On Tue, Aug 03, 2021 at 10:20:49AM -0600, Martin Sebor via Gcc wrote: > > On 8/3/21 9:54 AM, Joseph Myers wrote: > > >As discussed, this is a bug indicating that the code generating that > >

Re: Hooks fixed to treat trunk the same as master

On Tue, 3 Aug 2021, Martin Liška wrote: > On 8/2/21 7:22 PM, Joseph Myers wrote: > > Hey. > > > Some time ago, someone added a git symbolic-ref for refs/heads/trunk > > pointing to refs/heads/master. > > Great you found out what caused that. We were aware of

Re: Failures building glibc with mainline GCC

On Mon, 2 Aug 2021, Martin Sebor via Gcc wrote: > On 7/30/21 2:52 PM, Joseph Myers wrote: > > On Fri, 30 Jul 2021, Aldy Hernandez via Gcc wrote: > > > > > There's a new jump threader in GCC which is much more aggressive, and > > > may trigger latent problems

Hooks fixed to treat trunk the same as master

Some time ago, someone added a git symbolic-ref for refs/heads/trunk pointing to refs/heads/master. A side effect of this was to introduce a loophole in the checks run via commit hooks, some of which are configured to apply only to master and release branches and didn't apply if commits were pu

Re: Failures building glibc with mainline GCC

On Fri, 30 Jul 2021, Aldy Hernandez via Gcc wrote: > There's a new jump threader in GCC which is much more aggressive, and > may trigger latent problems with other warning passes, especially > -Warray-bounds, -Woverflow, and -Wuninitialized. > > Do your problems go away if you take out commit 2e9

Re: Are some builtin functions (for example log() vs. sqrt()) more equal than others?

On Fri, 30 Jul 2021, Stefan Kanthak wrote: > Joseph Myers wrote: > > > None of these are valid constant expressions as defined by the standard > > (constant expressions cannot involve evaluated function calls). > > That's why I ask specifically why GCC bugs on lo

Re: Failures building glibc with mainline GCC

In addition to failures building glibc, for those configurations for which glibc builds there's a failure building the testsuite: tst-thread_local1.cc:177:5: error: variable 'std::array >, 2> do_thread_X' has initializer but incomplete type 177 | do_thread_X | ^~~ -- Jo

Re: Are some builtin functions (for example log() vs. sqrt()) more equal than others?

None of these are valid constant expressions as defined by the standard (constant expressions cannot involve evaluated function calls). Some might be accepted as an extension, but I expect that since the optimization for constant arguments is intended for valid calls that would otherwise be ex

Failures building glibc with mainline GCC

There are a lot of failures building glibc with mainline GCC right now (previously, there were ICEs building glibc on various architectures, so these might be hard to bisect): * x86_64-linux-gnu: "error: array subscript 0 i

Re: Named address spaces on x86 GNU/Linux

On Thu, 29 Jul 2021, Florian Weimer via Gcc wrote: > On GNU/Linux, SEGFS is used to implement the thread pointer, to avoid > dedicating a general-purpose register to it. At address zero with the > SEGFS prefix, the offset itself is stored so that userspace can read it > without having to call int

Re: Atomic operations on floating-point data types

On Mon, 5 Jul 2021, Thomas Schwinge wrote: > But: why, what's the rationale? Are potential floating point exceptions > the problem, maybe? "Simply, because nobody bothered implementing it __atomic_* more or less correspond to some of the atomic_* operations in , which only include atomic_fetch

Re: [PATCH] Port GCC documentation to Sphinx

Are formatted manuals (HTML, PDF, man, info) corresponding to this patch version also available for review? -- Joseph S. Myers jos...@codesourcery.com

Re: GCC documentation: porting to Sphinx

On Wed, 23 Jun 2021, Martin Liška wrote: > @Joseph: Can you share your thoughts about the used Makefile integration? What > do you suggest for 2) > (note that explicit listing of all .rst file would be crazy)? You can write dependencies on e.g. doc/gcc/*.rst (which might be more files than actua

Re: git gcc-commit-mklog doesn't extract PR number to ChangeLog

On Thu, 17 Jun 2021, Richard Earnshaw via Gcc wrote: > It seems a bit dangerous to me to rely on just extracting PR numbers from > tests. What if the patch is just adjusting a test to make it compatible with > the remainder of the change? Also, that a test is added for a PR, or a commit is relev

Re: GCC documentation: porting to Sphinx

On Fri, 11 Jun 2021, Martin Liška wrote: > > Where languages have their own manuals, I think it's more appropriate for > > those to go under the language-specific directories. > > So it will require the following folder structure: > > $gccroot/gcc/doc/gcc - for GCC documentation > $gccroot/gcc/d

Re: git gcc-commit-mklog doesn't extract PR number to ChangeLog

On Fri, 11 Jun 2021, Jonathan Wakely via Gcc wrote: > If you're not already doing a brief "subject" line in your git > commits, you're Doing It Wrong! If you don't have a subject line which is more than one word, and does not look like a ChangeLog header line, and which is followed by a blank li

Re: GCC documentation: porting to Sphinx

On Thu, 10 Jun 2021, Martin Liška wrote: > 1) Can we organize the new documentation in $gccroot/doc folder > similarly to what I have in texi2rst-generated repo? Would be beneficial > as we can have a single Makefile and shared content will be in a same > depth to the individual manuals. Where

Re: GCC documentation: porting to Sphinx

On Thu, 3 Jun 2021, Martin Liška wrote: > On 6/2/21 6:44 PM, Joseph Myers wrote: > > On Wed, 2 Jun 2021, Joel Sherrill wrote: > > > > > For RTEMS, we switched from texinfo to Sphinx and the dependency > > > on Python3 for Sphinx has caused a bit of hassle. Is th

Re: GCC documentation: porting to Sphinx

On Mon, 31 May 2021, Martin Liška wrote: > https://splichal.eu/scripts/sphinx/ Looking at some examples there: https://splichal.eu/scripts/sphinx/gcc/_build/html/c-implementation-defined-behavior/preprocessing-directives.html has some conversion problems: * "See Implementation-defined behavio

Re: GCC documentation: porting to Sphinx

On Wed, 2 Jun 2021, Joel Sherrill wrote: > For RTEMS, we switched from texinfo to Sphinx and the dependency > on Python3 for Sphinx has caused a bit of hassle. Is this going to be > an issue for GCC? What Sphinx (and, thus, Python) versions does the GCC manual build work with? Can it work with

Re: Update to GCC copyright assignment policy

On Tue, 1 Jun 2021, David Edelsohn via Gcc wrote: > The copyright author will be listed as "Free Software Foundation, > Inc." and/or "The GNU Toolchain Authors", as appropriate. And copyright notices naming "The GNU Toolchain Authors" should not include a date - that's following the recommendati

Re: GCC Rust git branch

On Mon, 24 May 2021, Philip Herron wrote: > remote: error: hook declined to update refs/heads/gccrs refs/heads/gccrs doesn't match the branch naming conventions as documented at https://gcc.gnu.org/git.html (where you'd use refs/heads/devel/* for shared development branches), so if you hadn't h

Re: [RFC] Implementing detection of saturation and rounding arithmetic

On Tue, 11 May 2021, David Brown wrote: > It is also worth noting that gcc already has support for saturating > types on some targets: > > > > My testing of these (quite a long time ago) left me with a feeling that > it was not a feature anyo

Re: State of AutoFDO in GCC

On Mon, 10 May 2021, Andi Kleen via Gcc wrote: > It's difficult to find now because it was a branch in the old SVN that wasn't > converted. Sadly the great git conversion was quite lossy. All branches and tags, including deleted ones, were converted (under not-fetched-by-default refs in some cas

Re: gcc-11-20210425 is now available

On Mon, 26 Apr 2021, Arseny Solokha via Gcc wrote: > Hi, > > > Snapshot gcc-11-20210425 is now available on > > https://gcc.gnu.org/pub/gcc/snapshots/11-20210425/ > > and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. > > > > This snapshot has been generated from the GCC 1

Re: removing toxic emailers

On Fri, 16 Apr 2021, Frosku wrote: > Right now, the ultimate oversight of GCC sits with GNU & > FSF -- both institutions with a mandate to represent the ecosystem based > on level of membership and time spent fighting for free software. I think the oversight of glibc by development working throug

Re: removing toxic emailers

On Fri, 16 Apr 2021, Frosku wrote: > There is a colossal difference between commercial use and commercial > entities buying control of projects currently governed by entities > which are answerable to the grassroots (GNU) and then toppling that RMS's notion of GNU is as something under his person

Re: removing toxic emailers

On Wed, 14 Apr 2021, Eric S. Raymond wrote: > I'm not judging RMS's behavior (or anyone else's) one way or > another. I am simply pointing out that there is a Schelling point in > possible community norms that is well expressed as "you shall judge by > the code alone". This list is not full of co

Re: My 2nd attempt to devel for gcc

On Wed, 14 Apr 2021, pawel k. via Gcc wrote: > My best guess is if we could hookify all target code everything callable > either from frontends or midend, we could try to severly cut this estimate. That's a 700-patch series (there are about 700 target macros). For every target macro, it's neces

Re: Remove RMS from the GCC Steering Committee

On Thu, 1 Apr 2021, Ian Lance Taylor via Gcc wrote: > > 2) Last year, I asked for libcody to be added as a subcomponent, with > > its Apachev2 license intact. AFAICT RMS was involved in that licensing > > discussion, /for which I never received a response/. He was not at the > > FSF then, so he

Re: Remove RMS from the GCC Steering Committee

ance with the terms of the standard assignment agreements. The standard assignment agreements also prevent the FSF from distributing the code under proprietary terms.) > On Tue, 30 Mar 2021 17:45:24 + Joseph Myers wrote: > > One of the key functions of the SC is actually saying no to RMS.

Re: Remove RMS from the GCC Steering Committee

On Tue, 30 Mar 2021, JeanHeyd Meneide via Gcc wrote: > So, it boils down to this for me: either GCC is a place where all > contributions are welcome, or GCC is a place of hypocrisy, where > contributions are welcome except when Stallman (or someone else in a > position of power) lobbies a non

Re: Remove RMS from the GCC Steering Committee

On Sun, 28 Mar 2021, Mark Wielaard wrote: > He does indeed show up randomly claiming authority even if the GNU > community has told him no. And it is important to say upfront he has > no authority and that his attempts to cancel the work of hardworking > GNU contributors is unwelcome. IMHO for the

Re: My 2nd attempt to devel for gcc

On Sun, 28 Mar 2021, pawel k. via Gcc wrote: > Hello, > I would like to ask whether there would be interest in the project to be > able to build a single binary of gcc where target would be selectable with > option flags ie more than one target could be included and aimed for by > single binary. >

The old designated initializer syntax

GCC supports an old, pre-C99 designated initializer syntax in C, where array designators need not be followed by '=' and members may use 'member_name :' rather than '.member_name ='. I hoped to obsolete that syntax more forcefully (making the pedwarns for it unconditional) back in 2000 as menti

Re: IEEE Interchange floating point and extended floating point for C++

On Fri, 12 Mar 2021, Jonathan Wakely via Gcc wrote: > I see less value in adding additional distinct types that don't add > anything you can't already do. _Float16 gives you access to an entirely new > data type. _Float32 just complicates overloading of it's a new type with So would you then supp

Re: IEEE Interchange floating point and extended floating point for C++

On Fri, 12 Mar 2021, Joseph Myers wrote: > On Fri, 12 Mar 2021, Jonathan Wakely wrote: > > > On Fri, 12 Mar 2021 at 12:26, Sjoerd Meijer via Gcc wrote: > > > So here's finally my concrete question: what do we think about making > > > _Float16 available in C+

Re: [RFC] Appropriate portable data type for IEEE half-precision on C/C++

On Fri, 12 Mar 2021, Jonathan Wakely via Gcc wrote: > Why not just make _Float16 available in C++ as a GCC extension? There may be questions about promotions from _Float16 to wider formats for arithmetic. For C, there are no such promotions at the level of types (adding two _Float16 values pro

Re: IEEE Interchange floating point and extended floating point for C++

On Fri, 12 Mar 2021, Jonathan Wakely wrote: > On Fri, 12 Mar 2021 at 12:26, Sjoerd Meijer via Gcc wrote: > > So here's finally my concrete question: what do we think about making > > _Float16 available in C++ mode? > > I think GCC should do it. What about types with the same format as an exist

Re: IEEE Interchange floating point and extended floating point for C++

On Thu, 11 Mar 2021, Kito Cheng wrote: > I've read the note about C++ support from the initial commit log[1], > so I know there is some concern about C++ support for that, is it > possible to enable that for C++ like a language extension for C++? I don't know if C++ has reached any conclusions ab

Re: gccadmin hooks: make it a public git repo

I'm fine with having it set up with a public repository. If you have a public (bare) repository that would of course need to have its own hooks to update the (non-bare) hooks-bin checkout after a push. -- Joseph S. Myers jos...@codesourcery.com

Re: gcc/DATESTAMP not updated any longer

On Mon, 14 Dec 2020, Martin Liška wrote: > On 12/11/20 7:26 PM, Jakub Jelinek wrote: > > When running it manually it just completed without problems. > > So, no idea what happened. > > Morning. > > Unfortunately, today we have similar problem. Master was bumped, but > not any of the release bran

Re: gcc/DATESTAMP not updated any longer

On Fri, 11 Dec 2020, Martin Liška wrote: > On 12/11/20 2:17 PM, Rainer Orth wrote: > > Rainer Orth writes: > > > > > I noticed that gcc/DATESTAMP isn't updated any longer after this > > > Friday. I doubt this is intentional... > > > > This has happened again tonight... > > > > Rainer > >

Re: Pytest usage in DejaGNU?

On Mon, 14 Dec 2020, Martin Liška wrote: > +spawn -noecho pytest -rA -s --tb=no $script "pytest" might not be the right command everywhere. If I install python3-pytest on Ubuntu 20.04 I only get /usr/bin/pytest-3 not /usr/bin/pytest. There is a clear advantage to any usage of Python only

Re: unnormal Intel 80-bit long doubles and isnanl

On Fri, 27 Nov 2020, Florian Weimer via Gcc wrote: > The nature of these non-normal numbers is that the CPU does not produce > them. I think we should make sure that glibc doesn't, either, with > obvious exceptions such as memcpy. But beyond that, I don't know. Exceptions probably also include

Re: Reassociation and trapping operations

On Wed, 25 Nov 2020, Richard Biener via Gcc wrote: > > Hello, > > > > let me just mention the old > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53805 > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53806 > > > > There has been some debate about the exact meaning of -ftrapping-math, but > > don

Re: unnormal Intel 80-bit long doubles and isnanl

On Wed, 25 Nov 2020, Siddhesh Poyarekar wrote: > Would you agree to treating unnormals as NaNs and consequently have glibc > provide that guarantee in the library instead of either declaring it undefined > or maintaining the status quo, i.e. keeping it unspecified? I think it would be a pain to m

Re: Cron sh /home/gccadmin/scripts/update_version_git

On Wed, 25 Nov 2020, (Cron Daemon) via Gccadmin wrote: > === Working on: master === > branch pulled and checked out > 61 revisions since last Daily bump > Traceback (most recent call last): > File "../gcc-changelog/git_update_version.py", line 143, in > update_current_branch() > File "../

Re: unnormal Intel 80-bit long doubles and isnanl

On Tue, 24 Nov 2020, Siddhesh Poyarekar wrote: > The third alternative (which seems like a step back to me, but will concede > that it is a valid resolution) is to state that unnormal input to isnanl would > result in undefined behaviour and hence it is the responsibility of the > application to e

Re: broken check: You should edit tm.texi.in rather than tm.texi

On Mon, 23 Nov 2020, Martin Sebor via Gcc wrote: > I'd expect the best way to ensure the two copies of the contributed > text are in sync is to copy it automatically. If the only point of > asking the author to do it by hand each time they change the file > is to "Verify that they have permission

Re: broken check: You should edit tm.texi.in rather than tm.texi

On Mon, 23 Nov 2020, Martin Sebor via Gcc wrote: > I never did understand what it was complaining about, or the point > of making us jump through these hoops for updates to the internals > manual when the (arguably far more impactful) changes to GCC source > code or the user-visible manual aren't

Re: Ping(3): [PATCH v4] : Add nitems()

On Tue, 17 Nov 2020, Alejandro Colomar via Libc-alpha wrote: > Nice! > Please update me on any feedback you receive. Apparently the author is planning new versions of those papers so WG14 discussion is waiting for those. > So glibc will basically hold this patch > at least until the WG answers

Re: Ping(3): [PATCH v4] : Add nitems()

I've asked the WG14 reflector why N2529 (and N2530, though that one's not relevant to this feature) doesn't seem to have made it onto a meeting agenda yet, when there have been two WG14 meetings since that proposal was made and a third one coming up. -- Joseph S. Myers jos...@codesourcery.com

Re: The encoding of GCC's stderr

On Tue, 17 Nov 2020, Lewis Hyatt via Gcc wrote: > I also just wanted to ask... in case we have a general system to > always convert diagnostics output to the current locale, would this > make identifier_to_locale() no longer necessary in most cases? That Format strings come from the message catal

Re: The encoding of GCC's stderr

On Tue, 17 Nov 2020, David Malcolm via Gcc wrote: > What is the intended encoding of GCC's stderr? The locale encoding. > - blithely accept and emit filenames as bytes (I don't think we make > any attempt to enforce that they're any particular encoding) File names that aren't in the locale enco

Re: Git commit "Author: [...] via Gcc-patches " (was: [gcc r11-5068] Update documentation for spec files)

On Tue, 17 Nov 2020, Thomas Schwinge wrote: > Should we have a Git commit hook to catch that (and similar variants)? I've added a check for gcc-patc...@gcc.gnu.org (or libstd...@gcc.gnu.org or fort...@gcc.gnu.org) as author email address in our commit_checker hook (in ~gccadmin/hooks-bin). (Ch

Re: gcc/DATESTAMP not updated any longer

On Mon, 2 Nov 2020, Jakub Jelinek via Gcc wrote: > It isn't that easy (because update_version_git checks the gcc trunk and > so I had to insert a sh invocation in which I've tweaked it), but it worked, > thanks. But something is really wrong with the hooks, as the gcc-cvs mail > for the trunk dai

Re: GCC's Git update_hook doesn't support deleting branches

On Thu, 1 Oct 2020, Jonathan Wakely via Gcc wrote: > The problem is that the script doesn't check whether the new_object is > 0. > > I think we want something like this: > > --- update_hook 2020-09-02 23:30:25.074884982 + > +++ /tmp/update_hook2020-10-01 13:57:14.681656258 +

Re: [RFC] man7/system_data_types.7: Document [unsigned] __int128

On Thu, 1 Oct 2020, Alejandro Colomar via Gcc wrote: > Because 'intmax_t' has a bug > (actually I know GCC rejected the bug report, > but the problem is still there and users should be informed about this) > which is related to __int128. __int128 is not an integer type as defined by any existing

Re: Git rejecting branch merge

On Tue, 29 Sep 2020, Joel Brobecker wrote: > > > That's correct. The commit-extra-checker is called using the same list > > > of "added commits" as the other checks implemented in the hooks, and > > > that list excludes all commits accessible from existing references > > > in the repository. > >

Re: First set of patches to allow changing the long double default were posted:

On Tue, 29 Sep 2020, Jonathan Wakely via Gcc wrote: > I imagine C++ will want to support _Float128 at some point, with > similar semantics to C. Unless it chooses a class-based approach like that used for std::decimal::decimal128. -- Joseph S. Myers jos...@codesourcery.com

Re: Git rejecting branch merge

On Tue, 29 Sep 2020, Joel Brobecker wrote: > > > The problem is that the push fails witih: > > > > > > remote: *** The following commit was rejected by your > > > hooks.commit-extra-checker script (status: 1) > > > remote: *** commit: 03e87724864a17e22c9b692cc0caa014e9dba6b1 > > > remote: *** Th

Re: Git rejecting branch merge

On Tue, 29 Sep 2020, Jan Hubicka wrote: > Hello, > I am trying to update me/honza-gcc-benchmark-branch to current trunk > which I do by deleting it, recreating locally and pushing out. > > The problem is that the push fails witih: > > remote: *** The following commit was rejected by your > hook

Re: First set of patches to allow changing the long double default were posted:

On Mon, 28 Sep 2020, Michael Meissner via Gcc wrote: > > I'm not sure which patch in the series is supposed to be implementing > > that, but C requires that long double and _Float128 are distinct types (so > > you can use _Generic to choose between them, for example) even if they > > have the s

Re: First set of patches to allow changing the long double default were posted:

On Thu, 24 Sep 2020, Michael Meissner wrote: > As per the discussion in this thread, I did decide to keep things to two types > within the compiler. This means that an explicit __float128 or _Float128 will > use the same type node and TFmode as long double uses if the default for long > double is

Re: git hooks update

The new version of the hooks is now in use for the production repository. -- Joseph S. Myers jos...@codesourcery.com

git hooks update

I've updated the gcc-reposurgeon-8 test repository (git+ssh://gcc.gnu.org/home/gccadmin/gcc-reposurgeon-8.git) to use the same copy of the git hooks as used by binutils-gdb, glibc and other repositories on sourceware. All the features from local hook changes are now handled, with this new vers

OpenACC maintainer

The SC has approved Tobias Burnus as an additional OpenACC maintainer. Tobias, please add yourself as OpenACC maintainer to the MAINTAINERS file. -- Joseph S. Myers jos...@codesourcery.com

Re: Ellipsis in varadic macro definitions

On Mon, 3 Aug 2020, Florian Weimer via Gcc wrote: > It was introduced with: > > commit 1c5dd43ff7c78bbdba5e89a6cb16a3e50e1abff9 > Author: Zack Weinberg > Date: Fri Jun 15 17:57:48 2001 + > > cpp.texi: Formatting corrections. > > * doc/cpp.texi: Formatting corrections. > C

<    1   2   3   4   5   6   7   8   >