Re: git conversion in progress

On Tue, 14 Jan 2020, Georg-Johann Lay wrote: > In order to set user.name and user.email, the doc is using --global. At least > for me, the latter is not what I want because I am using git in other contexts > than contributing to GCC (and am using different e-mail then). Using --global is the sim

Re: Whitespace at the start of first line of commit

On Tue, 14 Jan 2020, Jakub Jelinek wrote: > (untested), another, suggested by Richard on IRC, would be to reject > commits where the first line starts with whitespace. I'd suggest making the hooks reject whitespace at the start of the first line of the commit message. -- Joseph S. Myers jos...

Re: git conversion in progress

On Tue, 14 Jan 2020, Georg-Johann Lay wrote: > A branch called branchname can be checked out with the following command: > > git clone -b branchname ... > > Referring to this as "checking out" is confusing IMO, because it may be > confused with > git checkout -b branchname > > Whereas t

Re: git conversion in progress

On Tue, 14 Jan 2020, Richard Earnshaw wrote: > Well it's likely that the server would have to repack the objects on the > fly to supply just one branch; and it does that less well than the base > pack). So you'd probably end up with a much larger initial download > than just fetching the entire h

Re: Towards removal of gcc/DATESTAMP

On Tue, 14 Jan 2020, Jakub Jelinek wrote: > o=$(git config --get gcc-config.upstream); test -z "$o" && o=origin; r=$(cat > BASE-VER | cut -d. -f 1); b=; if git rev-parse --verify --quiet > $o/releases/gcc-$r >/dev/null; then b=origin/releases/gcc-$r; elif git > rev-parse --verify --quiet $o/rel

Re: Help with new GCC git workflow...

On Tue, 14 Jan 2020, Jason Merrill wrote: > I think we're prohibiting merges to master. We definitely don't want > merges of branches with commits that don't each satisfy the normal rules > for commits. Yes. The hooks prevent pushing a merge commit to master or a release branch. A branch can

Re: Help with new GCC git workflow...

On Tue, 14 Jan 2020, Jonathan Wakely wrote: > > ...and this is just for changes going to trunk. How does all this change > > when I want to push changes to a release or vendor branch? > > It's pretty similar. Create a branch from the release branch, merge it > back to the release branch. > > Pe

Re: git conversion in progress

On Tue, 14 Jan 2020, Jason Merrill wrote: > I notice that git.html on the website doesn't match what's currently in > wwwdocs git, is automatic updating broken? /www/gcc/wwwdocs-checkout/cgi-bin/gcc-gitref.cgi had local changes (committed, but not reverted in that checkout before they were commi

Re: gcc-cvs mails for personal/vendor branches for merge commits

On Wed, 15 Jan 2020, Jakub Jelinek wrote: > Hi! > > As I said on IRC, I have done on our vendor branch redhat/gcc-10-branch > a simple > git merge r10-5981-ga52d93219c63d38fa9a97d0eb727e7fcc935e9b3 > git push origin redhat/gcc-10-branch:refs/vendors/redhat/heads/gcc-10-branch > which merged in ju

Re: gcc-cvs mails for personal/vendor branches for merge commits

On Wed, 15 Jan 2020, Jakub Jelinek wrote: > On Wed, Jan 15, 2020 at 02:56:45PM +0000, Joseph Myers wrote: > > > As I said on IRC, I have done on our vendor branch redhat/gcc-10-branch > > > a simple > > > git merge r10-5981-ga52d93219c63d38fa9a97d0eb727e7fc

Re: gcc-cvs mails for personal/vendor branches for merge commits

On Wed, 15 Jan 2020, Jason Merrill wrote: > On 1/15/20 9:56 AM, Joseph Myers wrote: > > On Wed, 15 Jan 2020, Jakub Jelinek wrote: > > > > > Or, if that is not possible, disable gcc-cvs mail for vendor and private > > > branches altogether? > > I think

Re: Whitespace at the start of first line of commit

On Tue, 14 Jan 2020, Joseph Myers wrote: > On Tue, 14 Jan 2020, Jakub Jelinek wrote: > > > (untested), another, suggested by Richard on IRC, would be to reject > > commits where the first line starts with whitespace. > > I'd suggest making the hooks reject whitesp

Re: gcc-cvs mails for personal/vendor branches for merge commits

On Wed, 15 Jan 2020, Richard Earnshaw (lists) wrote: > How about separate email list(s) for the vendor and personal spaces? I do > think changes there should be visible, but perhaps fewer folk will be > interested in tracking them at the same level. That's currently documented as a feature not s

Re: gcc-cvs mails for personal/vendor branches for merge commits

On Thu, 16 Jan 2020, Joel Brobecker wrote: > emails are to be sent. This happens for instance when people used > development branches that they had silenced so as to avoid spamming > people. And because they have been rebasing their branch regularly, > the "merge" ended up being a fast-forward. An

Re: gcc-cvs mails for personal/vendor branches for merge commits

On Thu, 16 Jan 2020, Jakub Jelinek wrote: > Couldn't it be then per-branch setting, whether to mail even commits > that aren't new to the repository or not (like I understood it is already > possible to decide per-branch whether to send mails at all)? Feel free to add such suggestions to the issu

Re: gcc-cvs mails for personal/vendor branches for merge commits

On Fri, 17 Jan 2020, Joel Brobecker wrote: > Would it be sufficient to say that some branches would only > trigger a summary email, but not individual commit emails? Maybe that will end up being appropriate for users / vendors branches, if we can't effectively distinguish rebased commits from ne

Re: Whitespace at the start of first line of commit

On Fri, 17 Jan 2020, Joel Brobecker wrote: > Do open a GitHub issue if you'd like me to add this check to > the git-hooks. I will likely give it less priority because > you'll have a way to implement it on your on, but I will get to it > eventually. I think https://github.com/AdaCore/git-hooks/is

Re: gcc-cvs mails for personal/vendor branches for merge commits

On Fri, 17 Jan 2020, Joel Brobecker wrote: > Also, you guys have to understand that you are all coming to me from > multiple directions at the same time, and making requests that are > not always easy to reconcile. I do completely understand that getting The issues filed on GitHub are meant to he

Re: [wwwdocs] Generalize instructions and remove notes on repository mirroring via rsync.

On Sat, 18 Jan 2020, Gerald Pfeifer wrote: > Should gcc-cvs really be listed there still? Yes, it should. The CVS repository was useful for fixing up cvs2svn branchpoints in the conversion to git; no doubt it may be useful for further fixes in any future move to any version control system that

Re: Let's remove all (or the largest) diffs from gcc-cvs@

On Sat, 18 Jan 2020, Hans-Peter Nilsson wrote: > Why the diff? I don't remember the absence of a diff being a > problem in the svn era (or at least wasn't argued much on the > mailing lists). I think the diffs are nice to have there (as for binutils-gdb and glibc) for following the development

Re: fast_math_flags_set_p vs. set_fast_math_flags inconsistency?

On Mon, 20 Jan 2020, Ulrich Weigand wrote: > This has the effect that e.g. after > > -ffast-math -fno-finite-math-only > > the __FAST_MATH__ macro is no longer predefined, but after > > -ffast-math -fno-associative-math > > the __FAST_MATH__ macro still *is* predefined, even though both >

Re: fast_math_flags_set_p vs. set_fast_math_flags inconsistency?

On Tue, 21 Jan 2020, Ulrich Weigand wrote: > It looks like there's multiple cases here. For the two flags > -fassociative-math and -freciprocal-math, it seems to have happened just as > you describe: they were created (split out of -funsafe-math-optimizations) > in commit a1a826110720eda37c73f829

Re: What needs to be satisfied to become a type qualifier in standard?

On Wed, 22 Jan 2020, Akshat Garg wrote: > Hello everyone, > > I am trying to see how a new type qualifier only for pointer variables is > suitable to be in standard semantically. I have this thread ( > https://gcc.gnu.org/ml/gcc-patches/2019-08/msg02015.html ) where Joseph > discussed a bit about

Re: Question about git: merging to gccgo branch

On Wed, 22 Jan 2020, Ian Lance Taylor wrote: > I don't want to send 581 e-mails. I would be happy not sending any > e-mails at all. I would also be happy sending 1 e-mail. This is the issue we've discussed in and the messages linked from there.

Re: Question about git: merging to gccgo branch

On Wed, 22 Jan 2020, Ian Lance Taylor wrote: > Thanks. Should I go ahead and commit and generate 581 e-mail > messages, or should I wait? In order to keep up with the Go release > cycle I'd like to commit this merge soon if possible. I suggest going ahead and committing. -- Joseph S. Myers jo

Re: Merges from release branches to vendor tracking branches

On Thu, 23 Jan 2020, Jakub Jelinek wrote: > Just FYI if somebody needs to do something similar, I needed to do a merge > from origin/releases/gcc-9 to our vendor branch - > refs/vendors/redhat/heads/gcc-9-branch > This branch has some extra commits origin/releases/gcc-9 branch doesn't > have, so

Re: Wrong GCC PR2020 annotated for "[committed, libgomp,amdgcn] Fix plugin-gcn.c bug"

On Thu, 23 Jan 2020, Richard Earnshaw (lists) wrote: > Perhaps we should restrict that to a single line, ie only horizontal white > space. Our commit style isn't really that free-form when citing bugs. Or > perhaps require [:.]?\w after the number (ie an optional period or colon and > then some

Re: fast_math_flags_set_p vs. set_fast_math_flags inconsistency?

On Mon, 27 Jan 2020, Ulrich Weigand wrote: > I see. I guess that makes me wonder what -fno-fast-math *ever* does > (except canceling a -ffast-math earlier on the command line). Looking > at the current code, -fno-fast-math (just like -ffast-math) only ever > sets flags whose default is not overr

Re: fast_math_flags_set_p vs. set_fast_math_flags inconsistency?

On Tue, 28 Jan 2020, Ulrich Weigand wrote: > The following patch (not yet fully tested) implements the above changes. > Note that this now brings the set of flags set and reset by > set_fast_math_flags completely in sync with the set of flags > tested in fast_math_flags_set_p. > > Does this make

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

On Mon, 3 Feb 2020, Michael Matz wrote: > I understand that, but the subject line of this thread says "e-mail > subject lines", so I thought we were talking about, well, exactly that; > and I see no value of these tags in e-mails either. I agree that [PATCH] is not useful (and in general, anyth

Re: GCC GSoC 2020: Call for mentors and project ideas

On Thu, 13 Feb 2020, JeanHeyd Meneide wrote: > Dear GCC Team, > > A bit of a procedural question. Do applications/projects for glibc > apply here to GCC? There are a few core functions I would like to add to > the library, that I think would be beneficial. Would a proposal for that be > welc

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

On Mon, 9 Mar 2020, Jakub Jelinek via Overseers wrote: > 5) emails used to be sanitized against harvesters, now they aren't The pipermail munging feature was unusably bad (it messed up Texinfo diffs very badly, including in the mbox version of the archive, e.g. "+@node" at the start of a line w

Re: Compiling GCC using an older sysroot

On Mon, 9 Mar 2020, Paul Smith wrote: > I have a sysroot I've created (downloading RPMs from older systems and > unpacking them) which is sufficient to build GCC (and binutils etc.) I > need the GCC binaries I create to be compiled using this sysroot so > that they can run on older systems. > >

Re: GCC bugzilla: REST API

On Wed, 11 Mar 2020, Frank Ch. Eigler via Gcc wrote: > Hi - > > > I'm working on a script that will catch the missing email into > > Bugzilla that are triggered by git commits mentioning a PR. > > For that I would need the enablement of REST API that was enabled > > in previous bugzilla instance.

Re: Not usable email content encoding

On Wed, 18 Mar 2020, Jonathan Wakely via Gcc wrote: > > Some git based projects are using gerrit. > > Which I looked into previously and decided I didn't like it. If I > recall correctly, gerrit has to "own" the repo, and so it's only The glibc experiment with gerrit worked without it owning the

Re: -static-pie does not seem to work on alpha, hppa, m68k, sparc

On Thu, 26 Mar 2020, Sergei Trofimovich via Gcc wrote: > Hi all! > > Recently I attempted to build glibc-2.31 with --enable-static-pie (gcc-9.3.0). > Some targets work just fine, some don't. A few faulty ones so far are: See the relevant section at

Re: Question about git: merging to gccgo branch

On Mon, 30 Mar 2020, Martin Liška wrote: > Can you please disable email sending for user branch? Or does it make any > sense? Email sending for user branches makes perfect sense, to make visible the development going on. It's specifically email sending for merges of commits already present in

Re: Question about git: merging to gccgo branch

On Mon, 30 Mar 2020, Ian Lance Taylor via Gcc wrote: > On Mon, Mar 30, 2020 at 10:54 AM Joseph Myers wrote: > > > > On Mon, 30 Mar 2020, Martin Liška wrote: > > > > > Can you please disable email sending for user branch? Or does it make any > > > sense?

Re: Can we please have the old mailing list back

On Wed, 1 Apr 2020, Bernd Edlinger wrote: > PS: I have a discovered a very serious problem with the mailing lists > that must be fixed by our overseers. > > That is the scubbed attachments. > > As an example please look at this one: > https://marc.info/?l=gdb-patches&m=158571308379946&w=2 The c

Re: subversion status on gcc.gnu.org

On Mon, 6 Apr 2020, Andrew Pinski via Gcc wrote: > That is r105377 till r105390 was only ever done on a test SVN repo and > r105927 (hooks) was the first commit to SVN after the conversion from Actually r105926 (creating the hooks directory) was the first commit in the real SVN conversion. But

Re: Help, Where I can find proper libtool version?

On Wed, 15 Apr 2020, Maciej W. Rozycki via Gcc wrote: > > So after runing autoreconf and make , I get "libtool: > > Version mismatch error.".It is a curious version, the gnu > > mirrors have no such version. > > It is a repository snapshot, there has been no such release. For 1.3134 > you ne

Re: ChangeLog files - server and client scripts

On Wed, 13 May 2020, Martin Liška wrote: > I'm sending the gcc-changelog relates scripts which should be added to contrib > folder. The patch contains: > - git_check_commit.py - checking script that verifies git message format We need a documentation patch to contribute.html or gitwrite.html that

Re: ChangeLog files - server and client scripts

On Thu, 14 May 2020, Martin Liška wrote: > On 5/13/20 7:53 PM, Joseph Myers wrote: > > On Wed, 13 May 2020, Martin Liška wrote: > > > > > I'm sending the gcc-changelog relates scripts which should be added to > > > contrib > > > folder. The patch c

Re: New mklog script

On Tue, 19 May 2020, Martin Liška wrote: > On 5/19/20 10:11 AM, Martin Liška wrote: > > Can you please share how do you do it? It would be easy to add it. > > I added the feature via --fill-up-bug-titles option. It uses common > request and beatifulsoup packages. The REST interface is much bette

Re: install location of math-vector-fortran.h

On Mon, 8 Jun 2020, Matthias Klose wrote: > However the file is architecture specific, currently only having variants for > x86_64-*-gnu, x86_64-*-gnux32, and a generic variant. This creates problems > when the file is contained in a Debian package which is marked as Multi-Arch: > same, also it s

Re: Push to my private branches is disallowed

On Mon, 15 Jun 2020, Segher Boessenkool wrote: > It should never send email for things that are on master (or any release > branch) already. https://github.com/AdaCore/git-hooks/issues/9 https://github.com/AdaCore/git-hooks/pull/12 is marked "Approved". It certainly has fixes for some of the i

Re: Push to my private branches is disallowed

On Tue, 16 Jun 2020, Jonathan Wakely via Gcc wrote: > I see no harm in rebasing public branches as long as nobody expects > otherwise. And by design you *can* rebase user and vendor branches (but not those in other namespaces). The message about not being a fast-forward is just a warning, not

Re: RFC noipa sizeof function for record relayout at link time

On Mon, 29 Jun 2020, Erick Ochoa wrote: > We are not targeting C++ at the moment. What contexts exist in C where we > require constant expressions? On the top of my head I have array sizes and > initialization of static variables? In such cases, then yes we agree that we Bit-field widths, static

Re: New x86-64 micro-architecture levels

On Fri, 10 Jul 2020, Florian Weimer via Gcc wrote: > * Level A > > CMPXCHG16B, LAHF/SAHF, POPCNT, SSE3, SSE4.1, SSE4.2, SSSE3 > > This is one step above the K8 baseline and corresponds to a mainline CPU > model ca. 2008 to 2011. It is also implemented by recent-ish > generations of Intel Atom s

Re: Accessing result data of target options without Mask or Var properties

On Sat, 11 Jul 2020, The Other via Gcc wrote: > Hi, > How would I access the result data of target options that don't have Mask > or Var properties? For example, how would I access the result ISA string in > the -march option for the RISC-V target? If an option doesn't specify somewhere to store

Re: Separate commit mailing lists for trunk/branches possible?

On Fri, 17 Jul 2020, Maciej W. Rozycki wrote: > Would it be reasonable to have the mailing list split into more than one, > that is at least the original covering the trunk, and then one or more for > branches? https://github.com/AdaCore/git-hooks/issues/10 is the issue for that feature - imp

Re: Separate commit mailing lists for trunk/branches possible?

On Fri, 17 Jul 2020, Carlos O'Donell via Gcc wrote: > The IRC irker has a clear filter: refs/heads/master|refs/heads/release/*, > but the irker doesn't seem to be working either. I think irker is broken for a different reason (freenode not allowing #glibc access from accounts not authenticated w

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

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

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

Re: git hooks update

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

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: 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: 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: 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: 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: > > > 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: [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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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 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: 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 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: 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: 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: 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: 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: 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: 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: [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, 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: 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

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: 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. >

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: 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

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 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: 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: 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: 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 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: Builtin expansion versus headers optimization: Reductions

On Fri, 5 Jun 2015, Mikhail Maltsev wrote: > There are other issues with macros in glibc headers (well, not as > significant as performance-related concerns, but never the less). > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24016#c3 > > > #include > > int foo(void *x) { > > return strcm

Re: undefined behavior of signed left shifts (was Re: [PULL 00/40] ppc patch queue 2015-06-03)

On Fri, 5 Jun 2015, Paolo Bonzini wrote: > The GCC manual says "GCC does not use the latitude given in C99 and C11 > only to treat certain aspects of signed '<<' as undefined, but this is > subject to change". It would certainly be nice if they removed the > "this is subject to change" part. The

Re: [RFC] Formation of vector function name

On Mon, 15 Jun 2015, Andrew Pinski wrote: > > results in asm redirection for log to __log_finite and final vector > > function name becomes _ZGVbN2v___log_finite. > > > > With point of view from C Library side, it reflects in addition of asm > > redirections _ZGVbN2v___log_finite = _ZGVbN2v_log in

Re: Possible invalid code - GCC 4.8/5.1.

See bug 63944 and DR#413 regarding such cases. -- Joseph S. Myers jos...@codesourcery.com

  1   2   3   4   5   6   7   8   >