Re: Updated Sourceware infrastructure plans

Hi - > Would it be possible for gitsigur to support signing commits with ssh > keys as well as gpg? Git supports this, and it's much easier for > everybody than having to set up gpg. [...] It would save some effort, but OTOH plenty of people have gpg keys too, and the common desktop key agents

Re: adacore git-hooks - daemon-mode email vs. systemd-logind linger

Hi, Joel - > [...] Thinking more long term, I think there are talks about using > a more comprehensive system for source and contribution management, > similar to products such as GitLab or GitHub. [...] (Yeah, but I wouldn't count on any of that in the medium term.) > [...] That's why I tend

Re: Updated Sourceware infrastructure plans

Hi - > [...] I suggest that a basic principle for such a system is that it > should be *easy* to obtain and maintain a local copy of the history > of all pull requests. That includes all versions of a pull request, > if it gets rebased, and all versions of comments, if the system > allows

adacore git-hooks - daemon-mode email vs. systemd-logind linger

Hi, Joel - As a part of more security review on sourceware, I had recently experimented with systemd logind's KillUserProcesses=yes option. It turns out that this nuked one aspect adacore hooks' post-receive processing, which create a background process to slowly dribble out emails. I restored

Re: Sourceware mitigating and preventing the next xz-backdoor

Hi - >This is very true, however a few words of caution: IME this is a >maintainability nightmare. Fixing patches that forgot to regenerate, >regenerating on rebase, confirming everything is up-to-date before >merge, etc etc. It can be handled, I have, but it was painful and >

Re: Sourceware mitigating and preventing the next xz-backdoor

Hi - > In Autotools, `make dist` produces a tarball that contains many > files not present in the source respoitory, it includes build system > core files and this fact was used for the xz attack. In contrast, > for newer build systems the "release tarball" is purely a snapshot > of the source

[wwwdocs] tweak for sourceware account request alias

diff --git a/htdocs/gitwrite.html b/htdocs/gitwrite.html index 0c146aba44d2..c89cdb8fb2ef 100644 --- a/htdocs/gitwrite.html +++ b/htdocs/gitwrite.html @@ -36,7 +36,7 @@ be sponsored by an existing maintainer (someone with "write after approval" is not sufficient). If you already have an

Re: Checks that autotools generated files were re-generated correctly

Martin Jambor writes: > [...] I have inherited Martin Liška's buildbot script that checks > that all sorts of autotools generated files, mainly configure scripts, > were re-generated correctly when appropriate. [...] The gccadmin account on sourceware already does some daily routine git

Re: Hundreds of gcc.dg/guality failures on both 14 and 13.1 branches

Hi - Hi - > (CC Frank, the fedrawhide builder doesn't seem to include guality.exp, > do you know why?) Good question. The gcc.log testsuite file appears to be truncated as it arrived into bunsen. The test does appear to be running on the bot. Maybe the gcc's own dg* log processing scripts

Re: urgent - Google Cloud public subnet blacklisted by gcc.org

Federico Iezzi via Gcc writes: > [...] > It seems like the GCC frontend/WAF have blacklisted the entire subnet > used by Google Cloud for Internet access. > [...] > $ curl ifconfig.me > 35.234.162.99 This has been unblocked. We sometimes must block large subnets when abusive traffic comes from

Re: Toolchain Infrastructure project statement of support

Hi - > [...] To be specific, gcc steering committee and glibc FSF stewards > have announced the decision for their projects [...] I may be missing something. All I've seen so far were some of the leaders of some of the projects being joint signatories to a letter on overseers@. As far as I'm

Re: Toolchain Infrastructure project statement of support

Hi - > [...] Given that the current sourceware admins have decided to > block migration of all sourceware assets to the LF IT [...] If you're trying to say that projects have not unanimously shown interest in moving infrastructure to LF IT, just say that. Don't blame overseers. If you're

Re: The GNU Toolchain Infrastructure Project

Hi - > [...] Where was a statement from key members of the GNU Toolchain > projects -- the people who actually use the services and > infrastructure on a day to day basis for their participation in the > GNU Toolchain projects -- asking for an alternative proposal? When > were they allowed to

Re: The GNU Toolchain Infrastructure Project

Hi - > [...] As for the rest, it really is a question on whether all of > sourceware will in the end be migrated over to LF, it's for the > remaining projects to decide. If we indeed have all projects on > board [...] "we" do not. That option was taken off the table weeks ago. For that

Re: The GNU Toolchain Infrastructure Project

Hi - > [...] so that we continue to have them involved in the technical > direction of GNU toolchain infrastructure? [...] "continue"? If the nature & degree of involvement we had so far in the LF/GTI process is representative of the future, I'm not sure I can in good faith ask anyone to fund

Re: The GNU Toolchain Infrastructure Project

Hi - > [...] Or alternatively, "sourceware overseers" could become a body > that maintains sourceware and is able to get funding through SFC for > its activities? Great idea -- and this is roughly what's happening. This "body" consisting of key individuals has invited other folks interested in

Re: The GNU Toolchain Infrastructure Project

Hi - > > I'm afraid I don't understand then what the point of comparing to LLVM > > with respect to competitiveness or freedom was. AIUI, infrastructure > > is an enabler, not really a competitive differentiator. > > I suppose that's a difference in our perception then. I think of >

Re: The GNU Toolchain Infrastructure Project

Hi - > > > I don't see a risk to freedom. The GNU toolchain is quite underfunded > > > compared to llvm/clang and IMO it's a major risk to maintain status quo on > > > that front. The GTI opens new avenues for funding aspects of the GNU > > > toolchain without affecting its core governance. > >

Re: The GNU Toolchain Infrastructure Project

Hi - > > > [...] I think the LF proposal is the best long term way forward for > > > the GNU toolchain projects to remain competitive *and* Free. [...] > > > > Can you elaborate what risks in terms of competitiveness or freedom > > you foresee with the status quo? This is the first I recall

Re: The GNU Toolchain Infrastructure Project

Hi - > [...] I think the LF proposal is the best long term way forward for > the GNU toolchain projects to remain competitive *and* Free. [...] Can you elaborate what risks in terms of competitiveness or freedom you foresee with the status quo? This is the first I recall hearing of this

Re: Rust frontend patches v2

Hi - > 12K 0004-gccrs-Add-link-cases-testsuite.patch > 356K0005-gccrs-Add-general-compilation-test-cases.patch > 132K0006-gccrs-Add-execution-test-cases.patch > 4.0K0007-gccrs-Add-gcc-check-target-check-rust.patch > 656K

Re: Rust frontend patches v2

Hi - > 12K 0004-gccrs-Add-link-cases-testsuite.patch > 356K0005-gccrs-Add-general-compilation-test-cases.patch > 132K0006-gccrs-Add-execution-test-cases.patch > 4.0K0007-gccrs-Add-gcc-check-target-check-rust.patch > 656K

Re: [PATCH] contrib: use sphinx-build from a venv

Hi - > > The gccadmin team can do this kind of thing without overseer/root > > privileges, or indeed so can any local shell-privileged user. > > Yeah, I said I didn't want to install it that way without overseer > approval, as pip won't keep the packages up to date the way dnf > installations

Re: [PATCH] contrib: use sphinx-build from a venv

Hi - > CCing overseers and Frank. > Can you please help me with that? > > Can please a maintainer install the package from pip? > > Something like: > > virtualenv /home/gcc/venv && /home/gcc/venv/bin/pip install Sphinx > > or a similar location? The gccadmin team can do this kind of thing

Mailing list reconfiguration: VERP Sender: header affected

Hi - I made an experimental configuration change on sourceware/gcc.gnu.org yesterday that had unforeseen effects on some mailing list subscribers. We turned on VERP (variable envelope return paths) on outgoing mail from mailman, in order to assist tracking mail delivery problems. This changes

Re: Security vulnerabilities affects core API authorization of gnu.org

Hi - > Does gnu.org has a bug bounty program or reporting bugs reward policy? You are not talking to gnu.org, you are talking to gcc.gnu.org admins. Maybe see webmast...@gnu.org. I am not aware of any sort of bug bounty in either site. - FChE

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

Hi - > Not the issue of wasted resources including the list server processing > and sending the messages intended to my address, bandwidth and all the > network equipment involved on the way, and finally the local mail server > receiving and dispatching the message to `procmail'. It all does

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

Hi - > I think irker is broken for a different reason (freenode not allowing > #glibc access from accounts not authenticated with NickServ; not sure if > that's global configuration or specific to #glibc). That's probably the +r mode flag on the channel. Nuke that. - FChE

Re: List user branches on git web

Hi - > > https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;a=heads;h=refs/users/marxin/heads > > Apparently such page does not list user branches. I believe this is because of unusual gcc git conventions, where the refs/heads/ and refs/users/heads/ directories are distinct. I believe have gitweb

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

Hi - > 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? [...] (This matter is for the gcc community to decide. Overseers do not control git/mailing list traffic policy.) - FChE

Re: sign_and_send_pubkey: signing failed: agent refused operation

Hi - > ~/.ssh/known_hosts exists and ~/.ssh is rwx only by the owner. > Everything works fine if I add my key by running ssh-add. What's > not so great is the errors I get when I forget to do that: "agent > refused operation?" Yeah, there is something odd on your side. Maybe your ssh client is

Re: sign_and_send_pubkey: signing failed: agent refused operation

Hi - > git pull from the GCC and Glibc repos is failing for me with the error > below. It worked fine last week and I haven't made any changes to my > ssh keys. And are you logging in from the same workstation with access to the same set of ssh private keys? > Is this a transient glitch or has

Re: rsync access to mailing list archives

Hi - > Would it be possible to provide this feature for the current archives, > too? [...] rsync now makes available the master .mbox files for every mailing list hosted on sourceware: rsync gcc.gnu.org::gcc-mbox This includes historical ezmlm era files as well as the new. - FChE

Re: Stability of pipermail ml archive URLs

Hi - > >I was thinking we might be able to trick pipermail (the web archiver > >component) to simply name the message web urls after some function of > >the message-id instead of the sequence number. Will give this a try > >very shortly. > > I just want to go on record as saying that I think

Re: Stability of pipermail ml archive URLs

Hi - > Such a service is not currently available on sourceware, but it'd be > possible to implement: as messages come in, you'd build a database > mapping from the Message-ID header to "current Mailman's Pipermail URL". I was thinking we might be able to trick pipermail (the web archiver

Re: Stability of pipermail ml archive URLs

Hi - > https://gcc.gnu.org/pipermail/gcc/2020-February/232205.html > Looking around, the last two months of gcc now have very small > numbers, but e.g. on gcc-patches the mails have very high numbers like > 545238.html. Can pipermail provide stable URLs at all? We really > need those, we

Re: Not usable email content encoding

Hi - > *Nothing* should touch changelog files :-) They should be generated from the > VCS. IMHO of course. IMHO: the VCS should be the changelog. - FChE

Re: blacklisted after announce on GNU cauldron ?

Hi - > > A re-subscription attempt to the gcc mailing list just > > failed, expectedly I guess. I see no sign in the logs of Olivier being banned in any form. Please resubscribe online and forward complete failure symptoms if you believe this is still happening. - FChE

Re: Not usable email content encoding

Hi - > > A number of lists I'm on switched to our current style of minging a > > year or two ago, because gmail users were not receiving mail, because > > gmail was rejecting the mail. > > I find that unconvincing, because even googlegroup email lists don't > mangle From: from sender domains

Re: subversion status on gcc.gnu.org

Hi - > There's update SVN to GIT map file: > https://drive.google.com/file/d/1DMuFDu476stLdMxKSaDzv4c81rhMAGEI/view?usp=sharing Updated. - FChE

Re: Not usable email content encoding

Hi - > [...] > I am fairly sure it breaks `git am' too, requiring a `From' override in > the change description for author attribution in patch application to work > reliably (I tend to work on my outbox when applying my own patches, so I > avoid this issue, but I am sure the issue will hit

Re: subversion status on gcc.gnu.org

Hi - Courtesy of a lovely httpd RewriteMap-basd hack courtesy of Martin, we have all the svn r# redirects working, and faster than before. - FChE

Re: subversion status on gcc.gnu.org

Hi - > > > https://gcc.gnu.org/r2000 > > > maps to a search and you get thousands of hits for SVN: r2000** > > > > The gcc git svn-rev alias handles that (and also handles release and other > > branches) using approx. > > git log --all --grep="From-SVN: r$rev\b" | head -n 1 | awk '{print $2}' >

Re: mailman customization

Hi - > I believe we can quite easily customize mailman 2.1 to match our needs. > The biggest challenge I see is a proper testing as I don't see it easy > to set up a local mailman instance. I've got a patch that changes: I suppose we can do some local RPM respins - as long as these changes are

Re: subversion status on gcc.gnu.org

Hi - > [...] > On a related note, contribute.html has a link to > https://gcc.gnu.org/viewcvs/gcc/trunk/contrib/check_GNU_style.sh?view=markup > and gcc-4.8/changes.html has a linkto > https://gcc.gnu.org/viewcvs/trunk/libgfortran/libgfortran.h?content-type=text%2Fplainview=co > which are broken

Re: subversion status on gcc.gnu.org

Hi - > Thanks for working on this!!! However, I still see at least one issue > in the following bugzilla entry: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94123#c4 > > The first two git style links work, but the last one which points > to the SVN revision doesn't. Is that a bug in

Re: Spam, bounces and gcc list removal

Hi - > > since the change to the new list management, there has been > > an uptick of spam getting through. Spam is bounced by my ISP, > > and this just resulted in a warning that there were too many > > bounces and that I would get removed from the list unless I > > confirmed it (which I then

subversion status on gcc.gnu.org

Hi - Both svn: and ssh+svn: now work for your archeological needs. Further, URLs such as https://gcc.gnu.org/viewcvs?rev=279160=gcc=rev https://gcc.gnu.org/r123456 are mapped to gitweb searches that try to locate the matching From-SVN: rABCDEF commit. This way, historical URLs from bugzilla

Re: Not usable email content encoding

Hi - > N.B. the CC list has got too big and is causing posts to this thread > to be held for moderator approval. Ah, can cycle through the lists and raise that limit. The default 10 is too low. - FChE

Re: Not usable email content encoding

Hi, Jim - > [gerrit etc.] Good points. > [...] We need to think about setting up easier ways for people to > submit patches, rather than trying to fix all of the MUAs and MTAs > in the world. Another related point. We are comingling email as a communication medium AND a commit transport

Re: Not usable email content encoding

Hi - > > The From: header rewriting for DMARC participants is something sourceware > > is doing now. > > Out of curiousity, is this rewriting you are talking about the cause for a > lot of mails showing up as "From: GCC List" rather than their real senders? > This has become very annoying

Re: Not usable email content encoding

Hi - > [...] You're talking about rewriting or adding headers (where the > former is Real Bad, no matter what DMARC wants to impose), but the > suggestion is based on not rewriting the body. If the body > (including attachtments) is rewritten any way then that simply is a > bug. [...] We're

Re: Not usable email content encoding

Hi - > > The key here is to realize that the raw message is not what you get > > back from the mailing list reflector, and also not the raw message > > that was sent by the sender. In this day of mta intermediaries, > > proxies, reflectors, it may be time to revisit that suggestion. > > But

Re: Not usable email content encoding

Hi - > > Are you trying to copy from the raw message representation? > > Everyone trying to work with a patch (instead of just the email) always > is working with the raw message. Just patch < mbox or git-am mbox > for example. > > https://gcc.gnu.org/contribute.html says > It is strongly

Re: Not usable email content encoding

Hi - > I noticed some emails reaching gcc-patc...@gcc.gnu.org use the following > quoting: > It's probably related to the following email tag: > Content-Transfer-Encoding: quoted-printable This is not something that the mailing list system does. This content-transfer-encoding comes from the

Re: GCC bugzilla: REST API

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. I believe this should work now. Thanks to Joseph Myers for

Re: GCC bugzilla: REST API

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. Just for clarity, which REST API was this? Have a test URL we

Re: text/x-* attachments strippe

Hi - Thanks for the kind words. > Could this have gone a bit smoother? Yes. More collaborative? Maybe. We tried: the plan to migrate to mailman was included by reference from the systemwide announcement blast two weeks ago: https://sourceware.org/sourceware-wiki/MigrationStatus/ We continue

Re: gcc-10-20200308 is now available

Hi - > Is it expected that > https://gcc.gnu.org/pub/gcc/snapshots/10-20200308/sha512.sum is not > present? > There is a sha512.sum file in previous snapshot dirs. system & per-user cron job items have not been brought forward en masse. Copied a relevant one over now

Re: gcc mailing list is not being archived

Hi - > one more point: The gcc mailing list including this discussion is > currently not being archived, the last message is from 2020-03-06. Found & fixed a permission problem with the mailmnan archives. Let's see if this one makes it in now. - FChE

Re: GCC Bugzilla (and other) timeouts

Hi - > > Bugzilla and httpd are very slow, but I haven't had any git timeouts. > > If you're using anonymous access that gets throttled more aggressively > > than authenticated access (using git+ssh:// for the protocol). Yeah, we're aware of reduced performance lately. Suspecting one disk is on

Re: GCC wwwdocs move to git done

Hi - Thanks - good job with moving this to git! > Note 1: someone with the right access needs to create the symlink > /sourceware/git/gcc-wwwdocs.git -> > /sourceware/projects/gcc-home/wwwdocs.git (and anything else needed for > anonymous git access to that repository). Done. - FChE

Re: GCC wwwdocs move to git done

Hi - Thanks - good job with moving this to git! > Note 1: someone with the right access needs to create the symlink > /sourceware/git/gcc-wwwdocs.git -> > /sourceware/projects/gcc-home/wwwdocs.git (and anything else needed for > anonymous git access to that repository). Done. - FChE

Re: ChangeLog's: do we have to?

siddhesh wrote: > [...] We had discussed making addition of ChangeLog entries into the > commit message mandatory but the issue there is that commit logs > cannot be (or more precisely, should not be) modified after they're > pushed so errors in ChangeLog entries will remain. [...] In such a

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

esr wrote: > [...] >> Another year; another release; and still no sign of progress on the git >> migration. > [...] > The current issue - and, I think, the last major one - is that there are > over 150 nid-branch deletes to be resolved. Is there a mandate that this conversion be Perfect? How

Re: Bugzilla timing out

Hi - > Many copies of a 5 MB message have apparently been timing out in > sourceware's spam processing, resulting in sourceware repeatedly accepting > the message while the sender's mail server also times out (sooner) and > keeps resending it. [...] Thanks for the pointer. I tightened up

Re: Bugzilla timing out

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 hours. Will look further into why, but quite a bit of it may

Re: Bugzilla timing out

Hi - On Tue, Jan 23, 2018 at 11:26:42AM +0100, Richard Biener wrote: > [...] > > OK, we reworked some of the database routine maintenance workload, > > e.g., a nightly cleanup pass that was quite likely excessive, and > > will keep monitoring. > > With all such administrative workloads keep in

Re: Bugzilla timing out

Hi - > Problems are still occurring for me; Bugzilla gives me 504 Gateway > Time-outs when I try to access it tonight... OK, we reworked some of the database routine maintenance workload, e.g., a nightly cleanup pass that was quite likely excessive, and will keep monitoring. - FChE

Re: Bugzilla timing out

msebor 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? One failed disk in the server has been replaced yesterday. Please let us know if problems persist or

Re: Call for volunteers: GCC Bugzilla account approval

David Edelsohn writes: > [...] > Because of SPAM, the GCC Community had to disable the creation of new > accounts. We need a few dedicated, reliable individuals who can > review account requests and manage the process of authorizing Bugzilla > accounts. [...] It would to

Re: using C++ STL containers in GCC/gfortran source code

Pedro Alves writes: > [...] > malloc will fail, new will throw bad_alloc, and GCC will abort and > maybe generate a core dump, instead of gracefully printing > something like: >cc1: out of memory allocating bytes ... > and existing with error status. Consider

Re: git server is stuck

The cron-based svn-to-git script running under bernie's account on gcc.gnu.org is still stuck/spinning, even after a restart. I am planning to suspend it later tonight, until y'all can figure out what's going on. - FChE

Re: Who played with the GCC Bugzilla git repo?

Frédéric Buclin writes: > Someone played with the GCC Bugzilla git repo last week with no real reason: > Author: root > Date: Fri Oct 7 15:28:43 2016 + > snap-data > [...] That was little old me, with the reason being to conserve local changes with

Re: Repository for the conversion machinery

joseph wrote: > Thanks, here are further authors map additions for new committers. > [...] > avieira = Andre Vieira > [...] FWIW, I thought at one point the consensus was that the mailmap would expand only to $use...@gcc.gnu.org rather than

Re: Repository for the conversion machinery

Jason Merrill writes: > [...] gcc.gnu.org already refuses git connections fairly frequently > due to overloading [...] With the corresponding reduction in cpu load from svn users, plus the ready adjustability of those xinetd thresholds, please don't let that hold you back. -

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

jwakely.gcc wrote: > [...] (When we switched Fedora to using GCC 6, with C++14 enabled by > default, dozens and dozens of C++ packages failed to compile, > because even in 2016 nobody had ever tried to compile them with > C++11 features enabled.) And one shouldn't blame those that choose to

Re: gnu-gabi group

mark wrote: > [...] >> [...] >> >> Having a local gnu-gabi group on sourceware.org would be better IMHO. >> > +1 >> +1 > > Great. I'll ask overseers to create a mailinglist. [...] Done [1] [2]. If y'all need a wiki too, just ask. [1] gnu-g...@sourceware.org [2]

Re: http access to ftp://gcc.gnu.org

Hi - > > [...] Please see http://gcc.gnu.org/ftp/ . > Got 403: Thanks, fixed. - FChE

http access to ftp://gcc.gnu.org

Hi - At the request of tbsaunders, we're experimenting with provinding http[s] access to parts of the ftp://gcc.gnu.org/ contents. Please see http://gcc.gnu.org/ftp/ . - FChE

Re: Repository for the conversion machinery

Hi - > [...] > >- rewrite history - use some totally arbitrary, and quickly outdated, > >internet identity > I think this is main reason why @gnu.org or @gmail.com style addresses > are preferred over employer addresses when there's > 1 address on file. That makes sense, but how many people

Re: Repository for the conversion machinery

>> cagney = Andrew Cagney > cag...@gnu.org? Good point. The email identities of people change over time; forcing a single arbitrary one to label all contributions is at best imprecise and at worse a miscrediting. (This is one way in which the impersonal use...@gcc.gnu.org

Re: svn timeouts

pmatos wrote: Am I the only one regularly getting svn timeouts lately? svn: E210002: Unable to connect to a repository at URL 'svn://gcc.gnu.org/svn/gcc/trunk' svn: E210002: Network connection closed unexpectedly Hard to be sure unless you can supply a timestamp so we can go log hunting.

Re: Offer of help with move to git

Joseph Myers jos...@codesourcery.com writes: [...] FWIW, Jason's own trial conversion with reposurgeon got up to at least 45GB memory consumption on a 32GB repository. (The host sourceware.org box has 72GB.) - FChE

Re: [website, changes] (was: Re: warning about const multidimensional array as function parameter)

Hi - thank you, I tried creating an account, but it said: Unknown action newaccount. Frank, do you know what the problem might be? Yes, this facility was temporarily disabled, as a load-shedding measure. I'll turn it back on for a few hours. - FChE

ssl support for https://gcc.gnu.org/

Hi - Thanks to help from Lisa Marie Maginnis li...@fsf.org, we now have a valid ssl/tls certificate for gcc.gnu.org, so the web server now makes https://gcc.gnu.org/* files available. Please let me/overseers know if you see any problems. One complication is the use of literal link

Re: GCC Wiki, struggling to make a new user

Hi - I'm trying to create a new account for the GCC wiki using the account creation page at: http://gcc.gnu.org/wiki/HomePage?action=newaccount but things are not going well. I fill in the form and click create account. After thinking for a while the page returns a Gateway Error. [...]

Re: git mirror hasn't been updated for 8 hours

Hi - There appears to have been a problem with bernie's cron-based git-svn-fetch job, due to a corrupted (emptied) .git/svn/.cache/XXX.db file. With that file removed, the cron job is running again. A little bit extra logging was added to help pinpoint the cause next time. - FChE

Re: Report on the bounded pointers work

Yury Gribov y.gri...@samsung.com writes: [...] [mudflap] never reached a point where interoperability across objects with and without mudflap instrumentation worked Could you add more details? E.g. I don't see how mudflap interoperability is different from AdressSanitizer which seems to be

Re: Warning about __DATE__ and __TIME__

Gerald Pfeifer ger...@pfeifer.com writes: To make it easier to reproduce builds of software and entire GNU/Linux distributions, RMS had the idea of adding a warning to GCC that warns about the use of __DATE__ and __TIME__. [...] How about instead adding a --time=X option to gcc (cpp?)

Re: Vandalised wiki page

Hi - Looking at http://gcc.gnu.org/wiki/RecentChanges shows that the GCC wiki is being spammed a lot. Somebody should employ some kind of spam protection. Several other sourceware-hosted moin wikis have adopted a group-ACL-based protection, which has eliminated the problem. This involves

Re: Vandalised wiki page

Hi - On Fri, Aug 23, 2013 at 04:06:22PM +0100, Jonathan Wakely wrote: [...] (Assuming we want to go down the ACL route.) Done! :-) Is there an easy way to revert a spam change to a page? I don't see one. Doh, found it in the more actions dropdown. (It's only accessible there to admin moin

Re: Could we start accepting rich-text postings on the gcc lists?

Hi - On Sat, Nov 24, 2012 at 12:58:33PM -0500, Daniel Berlin wrote: [...] I'd love to see data on this. As others have pointed out, almost every other open source project accepts html email. [...] Do you have reason to believe our existing spam detection solution will start to fail

Re: GCC 4.7.2: Mudflap linker errors

bd satish bdsat...@gmail.com writes: [...] The following piece of code, gives undefined references to __real_malloc, __real_free, etc.: Compiled with: g++ -fmudflap references.cc -lmudflap /lib64/libmudflap.a(mf-runtime.o): In function `__mfu_check': ../libmudflap/mf-runtime.c:912:

Re: GCC stack backtraces

Basile Starynkevitch bas...@starynkevitch.net writes: [...] If Ian's DWARF reader is simple enough (since suited for a single purpose), it might be helpful to avoid yet another external library dependency for GCC. [...] OTOH, DWARF is not a stationary target, so one should consider the

Re: New GCC takes 19x as long to compile my program (compared to old GCC), plus void** patch suggestion

Elmar Krieger el...@cmbi.ru.nl writes: [...] I really didn't expect that RedHat and Google both mess up GCC with their modifications, so I'll report it to them instead ;-) That's not a fair characterization of the features' costs/benefits. - FChE

Re: The Extension to ELF

Ian Lance Taylor i...@google.com writes: [...] ELF is designed to permit fast program loading at runtime, and to permit fast linking. Changing symbol and relocation values to take general expressions works against that goal. [...] It may interest you to know that, for an older Cygnus

Re: The Extension to ELF

Hi - On Wed, Aug 08, 2012 at 06:23:52AM -0700, Ian Lance Taylor wrote: [...] This has been merged into gnu binutils some time ago, though is not widely known, and only used by a single cgen-based gas port. See the OBJ_COMPLEX_RELC conditionals in gas/*, the BSF_*RELC/STT_RELC logic in

Re: The Extension to ELF

Fumiaki Isoya iso...@gmail.com writes: It may interest you to know that, for an older Cygnus project (mep), we implemented a facility called computed/complex relocations, as an ELF extension. This is a way of encoding general symbol/arithmetic expressions to be evaluated at link time and

Re: Function parameter debug info at -O0

Senthil Kumar Selvaraj senthil_kumar.selva...@atmel.com writes: [...] The following program, when compiled with -O0 -g3 (x86_64 target, but doesn't seem to matter), shows wrong values for p (function parameter) when debugging. [...] This sounds like

  1   2   >