Re: Commits not appearing in bugzilla

Am 16.02.25 um 17:59 schrieb Thomas Koenig: Am 16.02.25 um 16:29 schrieb Mark Wielaard: For now I replaced Thomas last name with just "Koenig". Hope that resolve the issue. Thanks! We'll see with the next commit. ... which worked, so the non-ASCII letters in the name seems to have been the

Re: Commits not appearing in bugzilla

Am 16.02.25 um 16:29 schrieb Mark Wielaard: For now I replaced Thomas last name with just "Koenig". Hope that resolve the issue. Thanks! We'll see with the next commit. Best regards Thomas

Re: Commits not appearing in bugzilla

Hi Thomas, Hi Arsen, On Sun, Feb 16, 2025 at 01:35:05PM +0100, Arsen Arsenović via Gcc wrote: > Thomas Koenig via Gcc writes: > > > (Incidentally, the mailing system messes up the UTF-8 represntation > > of my last name, König, maybe that is somehing to do with it). > > IIRC my commits were fai

Re: Commits not appearing in bugzilla

Thomas Koenig via Gcc writes: > (Incidentally, the mailing system messes up the UTF-8 represntation > of my last name, König, maybe that is somehing to do with it). IIRC my commits were failing to go through due to the presence of a "ć" in my /etc/passwd entry on Sourceware. This might be the s

Commits not appearing in bugzilla

My commits have not been appearing in bugzilla for quite some time now. Some recent examples have been https://gcc.gnu.org/pipermail/gcc-cvs/2025-February/417177.html https://gcc.gnu.org/pipermail/gcc-cvs/2025-February/417426.html Is this a misconfiguration somewhere? Should I be doing

Re: RFC: Bugzilla keyword "interp" where it is not clear if a program is standard-conforming or not

Am 10.02.25 um 23:44 schrieb Thomas Schwinge: Indeed 'need-language-lawyering' (or similar) would've been my suggestion for the new keyword, but I resisted the color-of-bike-shed opportunity. My fear would be that people would misspell laywer :-) I've added needs-stdcheck and will go through a

Re: RFC: Bugzilla keyword "interp" where it is not clear if a program is standard-conforming or not

Thomas Koenig via Gcc writes: > Hello world, > > looking at a few Fortran bug reports, I found some cases where > it was not clear if the program in question was standard-conforming > or not. I would propose to add a keyword for that, tentatively > called "interp". > > Comments? Suggestions for

Re: RFC: Bugzilla keyword "interp" where it is not clear if a program is standard-conforming or not

Hi! On 2025-02-10T20:59:43+0100, Thomas Koenig wrote: > Am 10.02.25 um 08:43 schrieb Richard Biener: >> We have need-bisection and other need-, so iff then maybe a need-stdchk for >> cases compliance is unclear? > > That sounds very good to me; if there are no objections, I will create > this in

Re: RFC: Bugzilla keyword "interp" where it is not clear if a program is standard-conforming or not

On Mon, 2025-02-10 at 09:29 +, Jonathan Wakely via Gcc wrote: > On Sun, 9 Feb 2025, 09:08 Thomas Koenig via Gcc, > wrote: > > > Hello world, > > > > looking at a few Fortran bug reports, I found some cases where > > it was not clear if the program in question was standard-conforming > > or n

Re: RFC: Bugzilla keyword "interp" where it is not clear if a program is standard-conforming or not

Am 10.02.25 um 21:05 schrieb David Malcolm: FWIW my first thought for "interp" was that we gaining an interpreter (there are some in the libgccjit test suite). It was motivated by Fortran interps, which are interpretation requrests. But I think that Richard's suggestion, neeeds-stdcheck, makes

Re: RFC: Bugzilla keyword "interp" where it is not clear if a program is standard-conforming or not

Am 10.02.25 um 08:43 schrieb Richard Biener: We have need-bisection and other need-, so iff then maybe a need-stdchk for cases compliance is unclear? That sounds very good to me; if there are no objections, I will create this in a day or so. The fact that a testcase is (non-)compliant is also

Re: RFC: Bugzilla keyword "interp" where it is not clear if a program is standard-conforming or not

On Sun, 9 Feb 2025, 09:08 Thomas Koenig via Gcc, wrote: > Hello world, > > looking at a few Fortran bug reports, I found some cases where > it was not clear if the program in question was standard-conforming > or not. I would propose to add a keyword for that, tentatively > called "interp". > >

Re: RFC: Bugzilla keyword "interp" where it is not clear if a program is standard-conforming or not

On Mon, Feb 10, 2025 at 8:19 AM Andre Vehreschild wrote: > > Hi all, > > I don't like the new keyword. Could we do "stdcomp" (for "standard compliant") > or something like that? When a keyword allows a question mark, I would even > add > that, i.e.. like "stdcomp?". Or when we like to go with int

Re: RFC: Bugzilla keyword "interp" where it is not clear if a program is standard-conforming or not

Hi all, I don't like the new keyword. Could we do "stdcomp" (for "standard compliant") or something like that? When a keyword allows a question mark, I would even add that, i.e.. like "stdcomp?". Or when we like to go with interp then at least add "std", i.e. "stdinterp". "interp" alone to me is t

Re: RFC: Bugzilla keyword "interp" where it is not clear if a program is standard-conforming or not

On 2/9/25 1:07 AM, Thomas Koenig wrote: Hello world, looking at a few Fortran bug reports, I found some cases where it was not clear if the program in question was standard-conforming or not.  I would propose to add a keyword for that, tentatively called "interp". Comments? Suggestions for a di

RFC: Bugzilla keyword "interp" where it is not clear if a program is standard-conforming or not

Hello world, looking at a few Fortran bug reports, I found some cases where it was not clear if the program in question was standard-conforming or not. I would propose to add a keyword for that, tentatively called "interp". Comments? Suggestions for a different name? Should I just go ahead and

Re: commits and bugzilla

Hi Martin, On Sat, Nov 16, 2024 at 10:03:41AM +0100, Martin Uecker via Gcc wrote: > I just commited a bug fix and noticed that bugzilla was > not automatically updated. > > https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=d8af6c203f18b4fd736df9567926589d96f8e0b3 > > Did someth

commits and bugzilla

I just commited a bug fix and noticed that bugzilla was not automatically updated. https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=d8af6c203f18b4fd736df9567926589d96f8e0b3 Did something change / break or did I do something wrong? Martin

Re: Commit missing from gcc-cvs and bugzilla

ut that doesn't seem to be the case here. Also it does look like your commit today for PR target/85624 did generate an gcc-cvs email and bugzilla update. So hopefully it is a one time thing. Did you get any unusual output on that commit? Cheers, Mark Hi Mark, no, no unusual output on that

Re: Commit missing from gcc-cvs and bugzilla

d non-ascii characters. But that doesn't seem to be the case here. Also it does look like your commit today for PR target/85624 did generate an gcc-cvs email and bugzilla update. So hopefully it is a one time thing. Did you get any unusual output on that commit? Cheers, Mark

Commit missing from gcc-cvs and bugzilla

I just noticed that one of my commits, https://gcc.gnu.org/r15-2865 is missing from https://gcc.gnu.org/pipermail/gcc-cvs/2024-August/date.html Even though it has the tag "PR target/113934" the respective PR didn't get a pointer to the commit: https://gcc.gnu.org/PR113934 Did I do something

Re: RFC: Changing Bugzilla updates at release time

On Fri, 2 Aug 2024 at 17:25, Arsen Arsenović wrote: > > Jonathan Wakely via Overseers writes: > > > I don't care which account does the changes but I'd prefer to keep the > > emails. There's always at least one that reminds me a bug is actually fixed > > and should be closed, or the target milest

Re: RFC: Changing Bugzilla updates at release time

Jonathan Wakely via Overseers writes: > I don't care which account does the changes but I'd prefer to keep the > emails. There's always at least one that reminds me a bug is actually fixed > and should be closed, or the target milestone should be removed because it > isn't going to be fixed on th

Re: RFC: Changing Bugzilla updates at release time

On Fri, 2 Aug 2024, 00:29 Sam James via Gcc, wrote: > Hi! > > This came out of some discussion with Arsen and prompted by some other > comments on IRC. > > At the moment, during release time, maintainer-scripts/branch_changer.py > is run by release managers and causes a large amount of bugmail to

Re: RFC: Changing Bugzilla updates at release time

> (I'm familiar enough with BZ to say it should be trivially doable, with > the exception of suppressing *sending* the mail to begin with, which I'd > have to investigate.) I think it would be better to suppress e-mails for these updates - I'm not sure that's easil

RFC: Changing Bugzilla updates at release time

Hi! This came out of some discussion with Arsen and prompted by some other comments on IRC. At the moment, during release time, maintainer-scripts/branch_changer.py is run by release managers and causes a large amount of bugmail to be sent both to CCs/assignees but also to the gcc-bugs ML. The ac

Re: Reporitng libstdc++ bug without account to Bugzilla

On Mon, 20 Nov 2023 at 14:23, Palmu, Miro M wrote: > > Hi > > I think I found libstdc++ bug and I tried to report to Bugzilla but "user > account creation has been restricted". > > So I'm going to report it here in hope that someone with a account could >

Reporitng libstdc++ bug without account to Bugzilla

Hi I think I found libstdc++ bug and I tried to report to Bugzilla but "user account creation has been restricted". So I'm going to report it here in hope that someone with a account could report it to Bugzilla if they seem it fit. Using gcc 13.2 with -std=c++23 co

Question about https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94138

Hey I’m Olive and I run a file sharing service called SendBig.com where you can send files up to 30GB for Free with amazing features available. I stumbled upon your website https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94138 , and I just have to say: WOW! I had a quick proposal, I was

Re: Labelling of regressions in Bugzilla

t; > >>> Iain pointed out a drawback of not having the regression info in the > >>> Summary. Currently it does draw your attention when looking at the > >>> results of a bugzilla search. Andrew noted that bug aliases are > >>> automatically added to the s

Re: Labelling of regressions in Bugzilla

>> Summary. Currently it does draw your attention when looking at the >>> results of a bugzilla search. Andrew noted that bug aliases are >>> automatically added to the summary, e.g. https://gcc.gnu.org/PR94404 >>> shows its alias "(c++core-issues)". >>

Re: Labelling of regressions in Bugzilla

On Wed, 15 Dec 2021 at 12:22, Tobias Burnus wrote: > > On 15.12.21 12:39, Jonathan Wakely via Gcc wrote: > > > Iain pointed out a drawback of not having the regression info in the > > Summary. Currently it does draw your attention when looking at the > > results of a bu

Re: Labelling of regressions in Bugzilla

On Wed, 15 Dec 2021 at 12:15, Richard Earnshaw wrote: > > > > On 15/12/2021 11:39, Jonathan Wakely via Gcc wrote: > > On IRC we've been discussing some changes to Bugzilla that would give > > a bit more structure to how we label and process regressions. > > >

Re: Labelling of regressions in Bugzilla

On 15.12.21 12:39, Jonathan Wakely via Gcc wrote: Iain pointed out a drawback of not having the regression info in the Summary. Currently it does draw your attention when looking at the results of a bugzilla search. Andrew noted that bug aliases are automatically added to the summary, e.g

Re: Labelling of regressions in Bugzilla

On 15/12/2021 11:39, Jonathan Wakely via Gcc wrote: On IRC we've been discussing some changes to Bugzilla that would give a bit more structure to how we label and process regressions. Currently we add something like "[9/10/11/12 Regression]" to the start of the summary, and

Labelling of regressions in Bugzilla

On IRC we've been discussing some changes to Bugzilla that would give a bit more structure to how we label and process regressions. Currently we add something like "[9/10/11/12 Regression]" to the start of the summary, and then edit that when it's fixed on a branch, when f

Re: [FYI] bugzilla cleanup

On Thu, Sep 16, 2021 at 11:45 AM Martin Sebor via Gcc wrote: > > On 9/14/21 2:10 AM, Andrew Pinski via Gcc wrote: > > Hi all, > > I am doing some bugzilla cleanup. This includes disabling some > > components and some versions for new bugs. > > So far I have

Re: [FYI] bugzilla cleanup

On September 17, 2021 6:30:21 PM GMT+02:00, Martin Sebor wrote: >On 9/17/21 8:54 AM, Richard Earnshaw wrote: >> >> >> On 16/09/2021 16:44, Martin Sebor via Gcc wrote: >>> On 9/14/21 2:10 AM, Andrew Pinski via Gcc wrote: >>>> Hi all, >>>&g

Re: [FYI] bugzilla cleanup

On 9/17/21 8:54 AM, Richard Earnshaw wrote: On 16/09/2021 16:44, Martin Sebor via Gcc wrote: On 9/14/21 2:10 AM, Andrew Pinski via Gcc wrote: Hi all,    I am doing some bugzilla cleanup.  This includes disabling some components and some versions for new bugs. So far I have disabled versions

Re: [FYI] bugzilla cleanup

On 16/09/2021 16:44, Martin Sebor via Gcc wrote: On 9/14/21 2:10 AM, Andrew Pinski via Gcc wrote: Hi all,    I am doing some bugzilla cleanup.  This includes disabling some components and some versions for new bugs. So far I have disabled versions before GCC 4 because we have not had a

Re: [FYI] bugzilla cleanup

On Thu, Sep 16, 2021 at 11:45 AM Martin Sebor via Gcc wrote: > ice-on-invalid-code: ICE on code that is not syntactically valid. > ice-on-valid-code: ICE on code that is syntactically valid. Presumably, the distinction is there because more attention would get paid to the latter over the former.

Re: [FYI] bugzilla cleanup

On 9/14/21 2:10 AM, Andrew Pinski via Gcc wrote: Hi all, I am doing some bugzilla cleanup. This includes disabling some components and some versions for new bugs. So far I have disabled versions before GCC 4 because we have not had a report from someone for those versions in over 7 years. I

Re: [FYI] bugzilla cleanup

Hi, On Tue, Sep 14 2021, Andrew Pinski via Gcc wrote: > Hi all, > I am doing some bugzilla cleanup. This includes disabling some > components and some versions for new bugs. Thanks a lot! > So far I have disabled versions before GCC 4 because we have not had a > report from so

[FYI] bugzilla cleanup

Hi all, I am doing some bugzilla cleanup. This includes disabling some components and some versions for new bugs. So far I have disabled versions before GCC 4 because we have not had a report from someone for those versions in over 7 years. I disabled some versions which are about

Re: PR numbers from Changelogs do not arrive in bugzilla

On 2/1/21 9:00 AM, Florian Weimer via Gcc wrote: * Thomas Koenig via Gcc: I had this problem previously, then it was thought that the messed-up spellling of my name caused this. That has been fixed by now. Any ideas what could be going wrong? On the glibc side, only bug references in the co

Re: PR numbers from Changelogs do not arrive in bugzilla

* Thomas Koenig via Gcc: > I had this problem previously, then it was thought that the > messed-up spellling of my name caused this. That has been > fixed by now. > > Any ideas what could be going wrong? On the glibc side, only bug references in the commit body, not the commit subject are picked

Re: PR numbers from Changelogs do not arrive in bugzilla

On 1/28/21 9:55 PM, Thomas Koenig via Gcc wrote: Hi, I committed a test case for https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67539 with https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=80198c701a7fc09e736ccffe470ee5033ca59a69 but that commit did not make it into the PR, I put it in by hand

PR numbers from Changelogs do not arrive in bugzilla

Hi, I committed a test case for https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67539 with https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=80198c701a7fc09e736ccffe470ee5033ca59a69 but that commit did not make it into the PR, I put it in by hand. I had this problem previously, then it was thought

Re: git commits no longer visible on bugzilla?

verseers via IRC or email overseers@ (b) Non-ASCII should probably be accepted in the flow; it looks as if the bugzilla email script mishandles/rejects this email even though it contains valid Hindi letters. Currently, the name comes from /hooks/updates/emails.py:

Re: git commits no longer visible on bugzilla?

Hi Thomas, On 06.12.20 10:22, Thomas Koenig via Gcc wrote: it seems that git commits are no longer automatically transferred to the relevant PRs. In principle, that still works. See "cvs-commit" at https://gcc.gnu.org/pipermail/gcc-bugs/2020-December/date.html#end Recently, there were issues

git commits no longer visible on bugzilla?

Hi, it seems that git commits are no longer automatically transferred to the relevant PRs. Recent example: I don't see https://gcc.gnu.org/pipermail/gcc-cvs/2020-December/338684.html in PR98156, although the ChangeLog was Upper cobound is determined by num_images(), not this_image().

Re: [RFC] Closing of all remaining Bugzilla PRs against powerpcspe

Hi Arseny, On Mon, Jun 01, 2020 at 10:38:16AM +0700, Arseny Solokha wrote: > > PRs from the second group were filed by me, so if there's consensus to > > close all > > of them, the ones from this second group I can close myself. I don't > > have the > > right permissions to m

Re: [RFC] Closing of all remaining Bugzilla PRs against powerpcspe

> Hi, > > > PRs from the second group were filed by me, so if there's consensus to > close all > of them, the ones from this second group I can close myself. I don't have > the > right permissions to modify PRs reported by someone else, so I'd like to > ask a > volunt

Re: [RFC] Closing of all remaining Bugzilla PRs against powerpcspe

On 5/25/20, Arseny Solokha wrote: > Hi, > > >>> >> PRs from the second group were filed by me, so if there's consensus to >>> >> close all >>> >> of them, the ones from this second group I can close myself. I don't >>> >> have the >>> >> right permissions to modify PRs reported by someone else, so

Re: [RFC] Closing of all remaining Bugzilla PRs against powerpcspe

Hi, >> >> PRs from the second group were filed by me, so if there's consensus to >> >> close all >> >> of them, the ones from this second group I can close myself. I don't have >> >> the >> >> right permissions to modify PRs reported by someone else, so I'd like to >> >> ask a >> >> volunteer

Re: [RFC] Closing of all remaining Bugzilla PRs against powerpcspe

On Wed, 13 May 2020, Segher Boessenkool wrote: > > > I think that the e200 support was never contributed upstream. > > > > Or rather, it wasn't accepted. Cf. > > , > >

Re: [RFC] Closing of all remaining Bugzilla PRs against powerpcspe

On Wed, May 13, 2020 at 01:42:37AM +0100, Maciej W. Rozycki wrote: > On Sat, 9 May 2020, Eric Botcazou wrote: > > > > Strangely, I failed to find any PR for e200, so maybe some unnoticed ones > > > are still lying around. > > > > I think that the e200 support was never contributed upstream. > >

Re: [RFC] Closing of all remaining Bugzilla PRs against powerpcspe

On Sat, 9 May 2020, Eric Botcazou wrote: > > Strangely, I failed to find any PR for e200, so maybe some unnoticed ones > > are still lying around. > > I think that the e200 support was never contributed upstream. Or rather, it wasn't accepted. Cf.

Re: [RFC] Closing of all remaining Bugzilla PRs against powerpcspe

On Sat, May 09, 2020 at 09:31:55AM +0100, Jonathan Wakely wrote: > If the bug is still present in supported versions (like gcc-8 or > gcc-9) but will never be fixed (like SPE ones) they might as well be > closed now as WONTFIX. Suggesting anything else will happen to them is > misleading. Yeah, I

Re: [RFC] Closing of all remaining Bugzilla PRs against powerpcspe

Hi! On Sat, May 09, 2020 at 01:45:20PM +0700, Arseny Solokha wrote: > > LRA has been supported by the rs6000 port since 2013 (01b1efaa1439), > > and made the default (and only!) option in 2017 (7a5cbf29beb2). Ah, the > > latter was slightly after the split, I see. Did powerpcspe never work > > w

Re: [RFC] Closing of all remaining Bugzilla PRs against powerpcspe

* Segher Boessenkool: > I can't speak for Arseny of course, but the reason *I* want this is to > no longer see all those powerpcspe BZs in my powerpc queries -- nothing > ever changes to them, so it's just pointless distraction. Keeping them open might also lead to some users believing that there

Re: [RFC] Closing of all remaining Bugzilla PRs against powerpcspe

Hi, On Sat, May 09, 2020 at 08:39:36PM +0200, John Paul Adrian Glaubitz wrote: > On 5/9/20 12:31 PM, Arseny Solokha wrote: > > I'd also like to nominate the following two: > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52927 > > https://gcc.gnu.or

Re: [RFC] Closing of all remaining Bugzilla PRs against powerpcspe

On Sat, 9 May 2020 at 09:56, John Paul Adrian Glaubitz wrote: > > On 5/9/20 10:31 AM, Jonathan Wakely wrote: > > If you mean for PR reasons or good apeparances, no. But it's wrong to > > have bugs left open that only refer to unsupported versions of GCC. If > > none of the supported releases has t

Re: [RFC] Closing of all remaining Bugzilla PRs against powerpcspe

On Sat, 9 May 2020 at 19:56, John Paul Adrian Glaubitz wrote: > > On 5/9/20 12:31 PM, Arseny Solokha wrote: > > I'd also like to nominate the following two: > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52927 > > https://gcc.gnu.org/bugzilla/show_bu

Re: [RFC] Closing of all remaining Bugzilla PRs against powerpcspe

On 5/9/20 12:31 PM, Arseny Solokha wrote: > I'd also like to nominate the following two: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52927 > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60158 > > which I also cannot close myself. There won't be any further re

Re: [RFC] Closing of all remaining Bugzilla PRs against powerpcspe

> Otherwise, I'm proposing to finally close all open PRs filed against > powerpcspe. I've been able to identify the following ones: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19490 > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30259 > https://gcc.gnu.org/bu

Re: [RFC] Closing of all remaining Bugzilla PRs against powerpcspe

> Strangely, I failed to find any PR for e200, so maybe some unnoticed ones > are still lying around. I think that the e200 support was never contributed upstream. -- Eric Botcazou

Re: [RFC] Closing of all remaining Bugzilla PRs against powerpcspe

On 5/9/20 10:31 AM, Jonathan Wakely wrote: > If you mean for PR reasons or good apeparances, no. But it's wrong to > have bugs left open that only refer to unsupported versions of GCC. If > none of the supported releases has the bug (either because it's been > fixed, or the relevant code has been r

Re: [RFC] Closing of all remaining Bugzilla PRs against powerpcspe

On Sat, 9 May 2020 at 08:15, John Paul Adrian Glaubitz wrote: > > Hi! > > On 5/9/20 12:15 AM, Segher Boessenkool wrote: > > I can do both, if you want, or just the first group? Your choice. > > > > But let's hear other opinions first. > > These bugs document the current issues with the backend as

Re: [RFC] Closing of all remaining Bugzilla PRs against powerpcspe

Hi! On 5/9/20 12:15 AM, Segher Boessenkool wrote: > I can do both, if you want, or just the first group? Your choice. > > But let's hear other opinions first. These bugs document the current issues with the backend as it existed in gcc-8 (or was it -9)? The bugs are still in the removed code, s

Re: [RFC] Closing of all remaining Bugzilla PRs against powerpcspe

> Hi! >> But it is clearly obvious that the powerpcspe backend won't be revived. After >> two years of development, rs6000 has diverged too much from the split point, >> including LRA adoption. > > LRA has been supported by the rs6000 port since 2013 (01b1efaa1439), > and made the default (and on

Re: [RFC] Closing of all remaining Bugzilla PRs against powerpcspe

ediate closing of Bugzilla PRs > against that target[1,2]. IIRC, Andrew has been contemplating a revival of the > backend during gcc 9 development cycle, and I was willing to wait for another > full cycle. > > But it is clearly obvious that the powerpcspe backend won't be revi

[RFC] Closing of all remaining Bugzilla PRs against powerpcspe

Hi, over the course of two years that had passed since the deprecation of the powerpcspe backend, and a year and a half since its removal from gcc, I've still been speaking out several times against immediate closing of Bugzilla PRs against that target[1,2]. IIRC, Andrew has been contemplat

Re: commits in Bugzilla attributed to others?

On 3/13/20 5:03 PM, Marek Polacek wrote: On Fri, Mar 13, 2020 at 09:56:58AM -0600, Martin Sebor wrote: On 3/13/20 9:50 AM, Marek Polacek wrote: On Fri, Mar 13, 2020 at 09:46:40AM -0600, Martin Sebor via Gcc wrote: It looks as though commits with bug fixes appear in Bugzilla comments made by

Re: commits in Bugzilla attributed to others?

On Fri, Mar 13, 2020 at 09:56:58AM -0600, Martin Sebor wrote: > On 3/13/20 9:50 AM, Marek Polacek wrote: > > On Fri, Mar 13, 2020 at 09:46:40AM -0600, Martin Sebor via Gcc wrote: > > > It looks as though commits with bug fixes appear in Bugzilla comments > > > made

Re: commits in Bugzilla attributed to others?

On 3/13/20 9:50 AM, Marek Polacek wrote: On Fri, Mar 13, 2020 at 09:46:40AM -0600, Martin Sebor via Gcc wrote: It looks as though commits with bug fixes appear in Bugzilla comments made by others(*). Fox instance, commit r10-7151 for PR 92071 shows in comment #16 on the bug under Martin

Re: commits in Bugzilla attributed to others?

On Fri, Mar 13, 2020 at 09:46:40AM -0600, Martin Sebor via Gcc wrote: > It looks as though commits with bug fixes appear in Bugzilla comments > made by others(*). Fox instance, commit r10-7151 for PR 92071 shows > in comment #16 on the bug under Martin Liška's name. > >

commits in Bugzilla attributed to others?

It looks as though commits with bug fixes appear in Bugzilla comments made by others(*). Fox instance, commit r10-7151 for PR 92071 shows in comment #16 on the bug under Martin Liška's name. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92071#c16 Similarly, commits r9-8372, r10-7152, a

Re: GCC bugzilla: REST API

On 3/12/20 12:15 AM, Frank Ch. Eigler 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. I believe this s

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

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 >

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? H

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. Thank you, Martin

Re: GCC Bugzilla (and other) timeouts

On Wed, 26 Feb 2020 at 14:42, Jason Merrill wrote: > > On Wed, Feb 26, 2020 at 3:39 AM Jonathan Wakely wrote: >> >> On Tue, 25 Feb 2020 at 18:25, Martin Sebor wrote: >> > >> > Bugzilla has been slow lately, and today to the point of timing out >> > (

Re: GCC Bugzilla (and other) timeouts

On 2/26/20 1:32 AM, Jonathan Wakely wrote: On Tue, 25 Feb 2020 at 18:25, Martin Sebor wrote: Bugzilla has been slow lately, and today to the point of timing out (I see the same problem with Git). This seems to be a recurring theme around the time of a GCC release. Is anyone else experiencing

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 l

Re: GCC Bugzilla (and other) timeouts

On Wed, Feb 26, 2020 at 3:39 AM Jonathan Wakely wrote: > On Tue, 25 Feb 2020 at 18:25, Martin Sebor wrote: > > > > Bugzilla has been slow lately, and today to the point of timing out > > (I see the same problem with Git). This seems to be a recurring theme > > aroun

Re: GCC Bugzilla (and other) timeouts

On Tue, 25 Feb 2020 at 18:25, Martin Sebor wrote: > > Bugzilla has been slow lately, and today to the point of timing out > (I see the same problem with Git). This seems to be a recurring theme > around the time of a GCC release. Is anyone else experiencing this > problem and if

GCC Bugzilla (and other) timeouts

Bugzilla has been slow lately, and today to the point of timing out (I see the same problem with Git). This seems to be a recurring theme around the time of a GCC release. Is anyone else experiencing this problem and if so, does anyone know what the cause it and an ETA for a solution? Is the

Re: How to modify Bugzilla tracker

It works. Thanks, Feng From: gcc-ow...@gcc.gnu.org on behalf of Feng Xue OS Sent: Friday, December 13, 2019 10:13 AM To: Jonathan Wakely; Andreas Schwab Cc: Thomas Schwinge; gcc@gcc.gnu.org; overse...@sourceware.org Subject: Re: How to modify Bugzilla

Re: How to modify Bugzilla tracker

in there; CCing the Overseers. >> >> >> >> On 2019-12-12T01:58:46+, Feng Xue OS >> >> wrote: >> >> > I have a sourceware.org account, but can not correlate the account with >> >> > Bugzilla login. >> >> >> >> Yes: &

Re: How to modify Bugzilla tracker

; >> On 2019-12-12T01:58:46+, Feng Xue OS > >> wrote: > >> > I have a sourceware.org account, but can not correlate the account with > >> > Bugzilla login. > >> > >> Yes: 'gcc.gnu.org' is a separate Bugzilla instance. > &g

Re: How to modify Bugzilla tracker

e.org account, but can not correlate the account with >> > Bugzilla login. >> >> Yes: 'gcc.gnu.org' is a separate Bugzilla instance. >> >> > Just want to assign a tracker to someone. >> >> To be able to do that, as far as I know, you'll need

Re: How to modify Bugzilla tracker

On Thu, 12 Dec 2019 at 09:19, Thomas Schwinge wrote: > > Hi! > > I'm not an admin there; CCing the Overseers. > > On 2019-12-12T01:58:46+, Feng Xue OS wrote: > > I have a sourceware.org account, but can not correlate the account with > > Bugzilla login. &

Re: How to modify Bugzilla tracker

Hi! I'm not an admin there; CCing the Overseers. On 2019-12-12T01:58:46+, Feng Xue OS wrote: > I have a sourceware.org account, but can not correlate the account with > Bugzilla login. Yes: 'gcc.gnu.org' is a separate Bugzilla instance. > Just want to assign a tr

Re: How to modify Bugzilla tracker

I have a sourceware.org account, but can not correlate the account with Bugzilla login. Just want to assign a tracker to someone. Thanks, Feng From: Jonathan Wakely Sent: Wednesday, December 11, 2019 7:07 PM To: Feng Xue OS Cc: gcc@gcc.gnu.org Subject

Re: How to modify Bugzilla tracker

On Wed, 11 Dec 2019 at 02:25, Feng Xue OS wrote: > > Hi, > > I want to alter some information of an existing Bugzilla tracker, such as > assignee, but found there is no entrance in page of the Bugzilla tracker to > do this. How can I get it? Usually that's restricted t

How to modify Bugzilla tracker

Hi, I want to alter some information of an existing Bugzilla tracker, such as assignee, but found there is no entrance in page of the Bugzilla tracker to do this. How can I get it? Thanks, Feng

Regarding Bug 85539 - x86_64: loads are not always narrowed [https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85539]

Hi All, I am looking https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85539 bug and did some analysis. please help me on the below query. For the below testcase, $cat test.c int foo(long *p) { return *p; } when compile with clang -O2 $clang test.c -O2 -S $cat test.s foo

regarding https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89924

Hi devs, I am looking into subjected issue. consider below testcase. $test.cpp class A { public: virtual int value() { return 1; } }; class B final : public A { public: int value(){ return 2; } }; int test(A* b) { return b->value() + 11; } void foo_test(B*b) { test(b); } Here gcc is u

  1   2   3   4   5   6   >