Re: Review for gcc-15/changes.html

Hi Heiko, Thanks for the patch! I've pushed everything except for: Heiko Eißfeldt writes: > @@ -832,8 +832,8 @@ > (aarch64-w64-mingw32). At present, this target > supports C and C++ for base Armv8-A, but with some caveats: > > - Although most variadic functions work, the i

Re: Review for gcc-15/changes.html

Thanks for the reminder! I have now adapted the patch. Greetings, Heiko --- "GCC 15 Release Series — Changes, New Features, and Fixes - GNU Project.html.org" 2025-04-30 15:09:45.736597984 +0200 +++ "GCC 15 Release Series — Changes, New Features, and Fixes - GNU Project.html" 2025-05-27 19:43:47.

Re: Review for gcc-15/changes.html

Heiko Eißfeldt writes: > Hi, > > here is a patch for some mostly minor typos in > https://gcc.gnu.org/gcc-15/changes.html. > My fixes might be wrong of course, so they are just suggestions. > > Also, the linked page https://gcc.gnu.org/gcc-15/porting_to.html > contains the now outdated > "Note: G

Re: Review for gcc-15/changes.html

"Richard Earnshaw (lists) via Gcc" writes: > On 30/04/2025 18:34, Heiko Eißfeldt wrote: >>> -  FEAT_LRCPC2 (+rcpc2), enabled by default for >>> +  FEAT_RCPC2 (+rcpc2), enabled by default for >>> >>> and >>> >>> -    FEAT_LRCPC3 instructions, when support for the instructions is >>> +    FE

Re: Review for gcc-15/changes.html

Hi Heiko, Thanks for doing this... > On 30 Apr 2025, at 18:53, Richard Earnshaw (lists) via Gcc > wrote: > > On 30/04/2025 17:23, Heiko Eißfeldt wrote: >> Hi, >> >> here is a patch for some mostly minor typos in >> https://gcc.gnu.org/gcc-15/changes.html. >> My fixes might be wrong of course

Re: Review for gcc-15/changes.html

On 30/04/2025 18:34, Heiko Eißfeldt wrote: >> -  FEAT_LRCPC2 (+rcpc2), enabled by default for >> +  FEAT_RCPC2 (+rcpc2), enabled by default for >> >> and >> >> -    FEAT_LRCPC3 instructions, when support for the instructions is >> +    FEAT_RCPC3 instructions, when support for the instructi

Re: Review for gcc-15/changes.html

- FEAT_LRCPC2 (+rcpc2), enabled by default for + FEAT_RCPC2 (+rcpc2), enabled by default for and -FEAT_LRCPC3 instructions, when support for the instructions is +FEAT_RCPC3 instructions, when support for the instructions is These are incorrect. The features really are FEAT_LR

Re: Review for gcc-15/changes.html

On 30/04/2025 17:23, Heiko Eißfeldt wrote: > Hi, > > here is a patch for some mostly minor typos in > https://gcc.gnu.org/gcc-15/changes.html. > My fixes might be wrong of course, so they are just suggestions. > > Also, the linked page https://gcc.gnu.org/gcc-15/porting_to.html contains the > n

Review for gcc-15/changes.html

Hi, here is a patch for some mostly minor typos in https://gcc.gnu.org/gcc-15/changes.html. My fixes might be wrong of course, so they are just suggestions. Also, the linked page https://gcc.gnu.org/gcc-15/porting_to.html contains the now outdated "Note: GCC 15 has not been released yet, so t

Gsoc: Do Concurrent Request for Review

Hi, I'm sorry about the delay in sharing my proposal, submitting my proposal for review. https://docs.google.com/document/d/1Ffaqcm37d6W9IPAoYvg1jYShNjw-YNgaGVEeBW1B8oY/edit?usp=sharing

Re: GSoC "Nothrow detection" proposal review

Hello, On Fri, Apr 05 2024, PRANIL DEY wrote: > Hello GCC Community, > I am Pranil Dey and I had submitted a proposal for the project "Improve > nothrow detection in GCC", but as the deadline period was a holiday time I > wanted to ask you to review my proposal now.

GSoC "Nothrow detection" proposal review

Hello GCC Community, I am Pranil Dey and I had submitted a proposal for the project "Improve nothrow detection in GCC", but as the deadline period was a holiday time I wanted to ask you to review my proposal now. I am already getting familiar with the code but I wanted some pointers fo

Re: GSoC Timeline Review

does Format String > Checking. > > - > > > > Implement these checks in the plugin. > > - > > > >Week 12 > >- > > > > Writing the GSoC wrapping-up document. > > > > > > ‫في الأربعاء، 27 مارس 20

Re: GSoC Timeline Review

checking for usage of the >> CPython API" project. First of all, I built the library, and now I am >> trying to debug it. Then, I also used Cpython in 3 demos to understand how >> it works. Finally, I read the uploaded patch comments to understand the >> c

Re: GSoC Timeline Review

On Tue, 2024-04-02 at 10:06 -0400, David Malcolm wrote: > What timezone are you in?  (I'm in EDT, UTC+4) Sorry, that should be UTC-4 (on the east coast of the US) Dave

Re: GSoC Timeline Review

also used Cpython in 3 demos to > > understand how > > it works. Finally, I read the uploaded patch comments to understand > > the > > codebase and file structure. As I mentioned above, please send me the demo code you wrote. What timezone are you in? (I'm

Re: GSoC Timeline Review

e uploaded patch comments to understand the > codebase and file structure. > > I was wondering if you could review my suggested timeline? > suggested Timeline: > >- > >May 1-26: >- > > Explore Cython modules, emphasizing entry-points and bug >

GSoC Timeline Review

I read the uploaded patch comments to understand the codebase and file structure. I was wondering if you could review my suggested timeline? suggested Timeline: - May 1-26: - Explore Cython modules, emphasizing entry-points and bug identification. - Study

RISC-V: Public review for Non-ISA Specification: psABI

We are delighted to announce the start of the public review period for psABI. The review period begins today, 2022/07/14, and ends on 2022/08/29 (inclusive). This Non-ISA specification is described in the PDF available at: https://github.com/riscv-non-isa/riscv-elf-psabi-doc/releases/tag/v1.0

OpenMP patch review and work in progress

Hi Jakub, hello all, let's start with a list of smaller patches, which are pending review but each of them should be relatively quickly approvable. Some are really tiny and obvious bug fixes - others are a bit larger but still smallish: * [Patch] OpenMP: Fix use_device_{addr,ptr} with in

OpenMP patch review and work in progress

Hi! Now that GCC 12 branched, can I ask you for: 1) pings for OpenMP patches that are ready and you'd like to get reviewed for GCC 13 2) what OpenMP 5.0/5.1/5.2 features people are already working on and plan to post patches later during stage1 Thanks Jakub

Public review for RISC-V psABI v1.0-rc1

Hi all: It’s Kito Cheng from the RISC-V community, Jessica Clarke and I are working on releasing a stable version of the psABI, and are seeking feedback from the open source community. The goal of this stable release is having a stable version to let people use as a reference point. We are tryin

Re: [patch, doc] Update people who can review gfortran patches

On 9/25/20 8:02 AM, Thomas Koenig via Fortran wrote: for review of its patches, gfortran relies on a group of people who can approve patches.  Unfortuntately, many of them are not active. Others, who have the capability and who have acted as de facto approvers (without anybody minding) are

Re: [patch, doc] Update people who can review gfortran patches

On 9/25/20 8:02 AM, Thomas Koenig via Fortran wrote: Hello world, for review of its patches, gfortran relies on a group of people who can approve patches.  Unfortuntately, many of them are not active. Others, who have the capability and who have acted as de facto approvers (without anybody

[patch, doc] Update people who can review gfortran patches

Hello world, for review of its patches, gfortran relies on a group of people who can approve patches. Unfortuntately, many of them are not active. Others, who have the capability and who have acted as de facto approvers (without anybody minding) are missing. This (somewhat overdue) patch

Your Account is under review

Your Account will be disabled Account gcc@gcc.gnu.org will be disabled. It looks like it was being used in a way that violated our policies. We understand your account is important to you. So if you think this was a mistake, sign in to the disabled account and submit

Re: RISC-V maintainer review of glibc patch needed (was: Re: [PATCH] riscv: Remove support for variable page sizes)

LGTM; I believe you are right on both counts that this was borrowed from MIPS and that we do not need this for RISC-V. On Mon, Oct 7, 2019 at 6:21 PM Florian Weimer wrote: > > Ping. I need a review of this glibc patch from a RISC-V architecture > maintainer: > > <https:/

Re: RISC-V maintainer review of glibc patch needed (was: Re: [PATCH] riscv: Remove support for variable page sizes)

LGTM; I believe you are right on both counts that this was borrowed from MIPS and that we do not need this for RISC-V. On Mon, Oct 7, 2019 at 5:21 PM Florian Weimer wrote: > Ping. I need a review of this glibc patch from a RISC-V architecture > maintainer: > > <https://sourcew

RISC-V maintainer review of glibc patch needed (was: Re: [PATCH] riscv: Remove support for variable page sizes)

Ping. I need a review of this glibc patch from a RISC-V architecture maintainer: <https://sourceware.org/ml/libc-alpha/2019-09/msg00506.html> I believe this is another artifact needlessly copied over from the MIPS port of glibc, but this one we can fix easily. Thanks, Florian * F

RE: Ping: Some MIPS patch need review and approval.

> Ping ? Hi Paul, I am very sorry to have missed your whole series and pings. I'm sorry to say it has been an email mess on my side, I was a little surprised by just how few MIPS issues were being raised. I know how frustrating it is when you get no response on submissions. I am no longer workin

Ping: Some MIPS patch need review and approval.

Ping ? On Wed, Oct 31, 2018 at 8:30 PM Paul Hua wrote: > > Hi, GCC steering committee: > > There are some MIPS patches that need to be reviewed and approved. > > [PATCH v3 0/6] [MIPS] Reorganize the loongson march and extensions > instructions set. [1] > [PATCH v3 1/6] [MIPS] Split Loongson (MMI

Some MIPS patch need review and approval.

Hi, GCC steering committee: There are some MIPS patches that need to be reviewed and approved. [PATCH v3 0/6] [MIPS] Reorganize the loongson march and extensions instructions set. [1] [PATCH v3 1/6] [MIPS] Split Loongson (MMI) from loongson3a. [2] [PATCH v3 2/6] [MIPS] Split Loongson EXTensions

Re: would you review the srcy programming language?

Somewhat like assembly meets c99 /javascript with maybe an extended preprocessor macro system (#declr? ) pointers rarely contain a single value, they either reference an array, or a group of values. In the case of the latter, the pointerVarName.FieldName pair specifies to get the value, and then a

would you review the srcy programming language?

hi! i'm the dotre, and i am designing a programming language, you may be interested at, it is general purpose, structured, imperative, data-driven and autonomous; i have already its syntax and very brief introduction as documentation. it is documented with google docs, but it can be downloaded wit

Re: Please review writeup for fixing PR 78809 (inline strcmp for small constant strings)

> On Nov 17, 2017, at 7:39 PM, Jeff Law wrote: > >>> >> >> thanks for the info, Martin. >> >> In my case, it’s the size of “100” cannot be collected in the >> MINMAXLEN[1] for the string “s”. >> >> I need to make sure that the size of variable string s is larger than >> the size of constant

Re: Please review writeup for fixing PR 78809 (inline strcmp for small constant strings)

> On Nov 17, 2017, at 7:32 PM, Jeff Law wrote: > > On 11/17/2017 03:45 PM, Qing Zhao wrote: do you think using this routine is good? or do you have other suggestions (since I am still not very familiar with the internals of GCC, might not find the best available one now…) >>> The

Re: Please review writeup for fixing PR 78809 (inline strcmp for small constant strings)

> On Nov 17, 2017, at 5:54 PM, Martin Sebor wrote: > >> >> for the safety checking purpose, when we try to convert >> >> __builtin_strcmp(s, "abc") != 0 >> >> to >> >> __builtin_memcmp (s, “abc”, 4) != 0 >> >> we have to make sure that the size of variable “s” is larger than “4”. > > Presu

Re: Please review writeup for fixing PR 78809 (inline strcmp for small constant strings)

On November 17, 2017 11:20:45 PM GMT+01:00, Qing Zhao wrote: > >> On Nov 16, 2017, at 6:24 PM, Martin Sebor wrote: >>> >>> In my current local implementation, I used the following routine to >get the range info: (and use the MINMAXLEN[1]+1 for the length of the >non-constant string) >>> >>> /

Re: Please review writeup for fixing PR 78809 (inline strcmp for small constant strings)

On 11/17/2017 03:20 PM, Qing Zhao wrote: > >> On Nov 16, 2017, at 6:24 PM, Martin Sebor > > wrote: >>> >>> In my current local implementation, I used the following routine to >>> get the range info:  (and use the MINMAXLEN[1]+1 for the length of >>> the non-constant string

Re: Please review writeup for fixing PR 78809 (inline strcmp for small constant strings)

On 11/17/2017 03:50 PM, Qing Zhao wrote: >> >> The difficulty is tracking when exposure leads to these secondary >> opportunities. I often end up looking for this kind of stuff by first >> identifying many source files where the transformation applies. Then I >> generate dumps & assembly code fo

Re: Please review writeup for fixing PR 78809 (inline strcmp for small constant strings)

On 11/17/2017 03:45 PM, Qing Zhao wrote: >>> do you think using this routine is good? or do you have other >>> suggestions (since I am still not very familiar with the internals of >>> GCC, might not find the best available one now…) >> The range information attached to an SSA_NAME is global data.

Re: Please review writeup for fixing PR 78809 (inline strcmp for small constant strings)

On 11/17/2017 04:08 PM, Qing Zhao wrote: On Nov 17, 2017, at 1:50 AM, Jakub Jelinek wrote: On Thu, Nov 16, 2017 at 06:14:35PM -0700, Jeff Law wrote: However, this routine currently miss a very obvious case as the following: char s[100] = {'a','b','c','d’}; __builtin_strcmp(s, "abc") != 0

Re: Please review writeup for fixing PR 78809 (inline strcmp for small constant strings)

> On Nov 17, 2017, at 1:50 AM, Jakub Jelinek wrote: > > On Thu, Nov 16, 2017 at 06:14:35PM -0700, Jeff Law wrote: >>> However, this routine currently miss a very obvious case as the following: >>> >>> char s[100] = {'a','b','c','d’}; >>> >>> __builtin_strcmp(s, "abc") != 0 >>> >>> So, I have

Re: Please review writeup for fixing PR 78809 (inline strcmp for small constant strings)

A would like to be put in gimple fold phase (in routine "gimple_fold_builtin_string_compare" of gimple-fold.c >> OK. Note that various optimizations can expose N or one of the strings >>> to be a constant. So having it as part of the folders makes a lot of >>> sense . >>

Re: Please review writeup for fixing PR 78809 (inline strcmp for small constant strings)

Hi, Jeff, > On Nov 16, 2017, at 7:14 PM, Jeff Law wrote: >> >> In my current local implementation, I used the following routine to get >> the range info: (and use the MINMAXLEN[1]+1 for the length of the >> non-constant string) >> >> /* Determine the minimum and maximum value or string length

Re: Please review writeup for fixing PR 78809 (inline strcmp for small constant strings)

> On Nov 16, 2017, at 6:24 PM, Martin Sebor wrote: >> >> In my current local implementation, I used the following routine to get the >> range info: (and use the MINMAXLEN[1]+1 for the length of the non-constant >> string) >> >> /* Determine the minimum and maximum value or string length that

Re: Please review writeup for fixing PR 78809 (inline strcmp for small constant strings)

> On Nov 16, 2017, at 5:55 PM, Martin Sebor wrote: >> >> A. for strncmp (s1, s2, n) >> if one of "s1" or "s2" is a constant string, "n" is a constant, and >> larger than the length of the constant string: >> change strncmp (s1, s2, n) to strcmp (s1, s2); > > Here and I think in som

Re: Please review writeup for fixing PR 78809 (inline strcmp for small constant strings)

On Thu, Nov 16, 2017 at 06:14:35PM -0700, Jeff Law wrote: > > However, this routine currently miss a very obvious case as the following: > > > > char s[100] = {'a','b','c','d’}; > > > > __builtin_strcmp(s, "abc") != 0 > > > > So, I have to change this routine to include such common case.   > >

Re: Please review writeup for fixing PR 78809 (inline strcmp for small constant strings)

On 11/16/2017 03:39 PM, Qing Zhao wrote: > Hi, Jeff,  > thanks a lot for your comments. please see my reply in below: > > >> On Nov 16, 2017, at 12:47 PM, Jeff Law > > wrote: >> >>> >>>   B. for strncmp (s1, s2, n) (!)= 0 or strcmp (s1, s2) (!)= 0 >>>      if the result is

Re: Please review writeup for fixing PR 78809 (inline strcmp for small constant strings)

On 11/16/2017 03:39 PM, Qing Zhao wrote: Hi, Jeff, thanks a lot for your comments. please see my reply in below: On Nov 16, 2017, at 12:47 PM, Jeff Law wrote: B. for strncmp (s1, s2, n) (!)= 0 or strcmp (s1, s2) (!)= 0 if the result is ONLY used to do a simple equality test against

Re: Please review writeup for fixing PR 78809 (inline strcmp for small constant strings)

On 11/03/2017 08:59 AM, Qing Zhao wrote: Hi, This is the first time I am asking for a design review for fixing a GCC enhancement request, Let me know if I need to send this email to other mailing list as well. I have been studying PR 78809 for some time https://gcc.gnu.org/bugzilla

Re: Please review writeup for fixing PR 78809 (inline strcmp for small constant strings)

Hi, Jeff, thanks a lot for your comments. please see my reply in below: > On Nov 16, 2017, at 12:47 PM, Jeff Law wrote: > >> >> B. for strncmp (s1, s2, n) (!)= 0 or strcmp (s1, s2) (!)= 0 >> if the result is ONLY used to do a simple equality test against zero, >> one of "s1" or "s2" i

Re: Please review writeup for fixing PR 78809 (inline strcmp for small constant strings)

On 11/03/2017 08:59 AM, Qing Zhao wrote: > Hi, > > This is the first time I am asking for a design review for fixing a GCC > enhancement request, Let me know if I need to send this email to other > mailing list as well. > > I have been studying PR 78809 for some time

Please review writeup for fixing PR 78809 (inline strcmp for small constant strings)

Hi, This is the first time I am asking for a design review for fixing a GCC enhancement request, Let me know if I need to send this email to other mailing list as well. I have been studying PR 78809 for some time https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809 <https://gcc.gnu.

DWARF Version 5 Public Review Draft Released

DWARF Version 5 Public Review Draft Released October 14, 2016 The DWARF Debugging Information Format Committee has released the public review draft of Version 5 of the DWARF Debugging Information Format standard. The DWARF debugging format is used to communicate debugging information between a

Re: OpenACC (gomp-4_0-branch) patch review (was: Merge from gomp-4_1-branch to trunk)

On Fri, Oct 16, 2015 at 11:44:17AM +0200, Thomas Schwinge wrote: > But: working on getting our changes into trunk, for example, when we make > an effort to extract from gomp-4_0-branch self-contained, individual > patches, but it then takes weeks to get commit approval or review >

Re: OpenACC (gomp-4_0-branch) patch review

On 10/16/2015 11:44 AM, Thomas Schwinge wrote: Lately, Bernd has stepped up a few times to review OMP patches (many thanks, Bernd!), but also he sometimes stated that even though a patch appears fine to him, he'd like "Jakub to have a look". I'll just comment on this brie

OpenACC (gomp-4_0-branch) patch review (was: Merge from gomp-4_1-branch to trunk)

m gomp-4_0-branch self-contained, individual patches, but it then takes weeks to get commit approval or review comments, I don't see how that's going to work for the thousands of lines patches that we're still to submit? I mean, GCC development stage 1 is going to end in just a few

[GSoC] the last code review

Dear gcc contributors, The removing of CLooG library installation dependency is almost finished. The code review of these patches (https://gcc.gnu.org/ml/gcc-patches/2014-08/msg01564.html) is the only thing, which prevents it. Could you please review them? My mentor’s already accepted them, but

Re: GSoC :Project Idea(Before final Submission) for review and feedback

Thank You David for your suggestion and feedback. I'll let you know my final proposal (after the modification based on your feedback and my latest study) as early as possible. I would like to request everyone in this community to kindly enrich me with more suggestions and guidance to prepare my fi

Re: GSoC :Project Idea(Before final Submission) for review and feedback

On 25/03/2012 11:55, Oleg Endo wrote: Please reply in CC to the GCC mailing list, so others can follow the discussion. On Sun, 2012-03-25 at 09:21 +0530, Subrata Biswas wrote: On 25 March 2012 03:59, Oleg Endo wrote: I might be misunderstanding the idea... Let's assume you've got a program t

Re: GSoC :Project Idea(Before final Submission) for review and feedback

, 2012 12:22 PM > To: Oleg Endo > Cc: gcc > Subject: Re: GSoC :Project Idea(Before final Submission) for review and > feedback > > Thank you sir for your excellent example. > > On 25 March 2012 15:25, Oleg Endo wrote: >> Please reply in CC to the GCC mailing list, so

RE: GSoC :Project Idea(Before final Submission) for review and feedback

-Original Message- From: Subrata Biswas [mailto:subrata.i...@gmail.com] Sent: Sunday, March 25, 2012 12:22 PM To: Oleg Endo Cc: gcc Subject: Re: GSoC :Project Idea(Before final Submission) for review and feedback Thank you sir for your excellent example. On 25 March 2012 15:25, Oleg

Re: GSoC :Project Idea(Before final Submission) for review and feedback

Thank you sir for your excellent example. On 25 March 2012 15:25, Oleg Endo wrote: > Please reply in CC to the GCC mailing list, so others can follow the > discussion. > > On Sun, 2012-03-25 at 09:21 +0530, Subrata Biswas wrote: >> On 25 March 2012 03:59, Oleg Endo wrote: >> > >> > I might be mi

Re: GSoC :Project Idea(Before final Submission) for review and feedback

Please reply in CC to the GCC mailing list, so others can follow the discussion. On Sun, 2012-03-25 at 09:21 +0530, Subrata Biswas wrote: > On 25 March 2012 03:59, Oleg Endo wrote: > > > > I might be misunderstanding the idea... > > Let's assume you've got a program that doesn't compile, and you

Re: GSoC :Project Idea(Before final Submission) for review and feedback

On Sat, 2012-03-24 at 11:45 +0530, Subrata Biswas wrote: > Dear All, > I am a MTech student at Indain Institute of Technology, Roorkee. I > want to do my GSoC12 project under your guidance. I am writing this > mail for a basic review and feedback on my project idea before formal

Re: VIS2 pattern review

> Right and as Richard said I can munge the modes during expansion of > existing builtins when needed. OK, but you precisely shouldn't need to do it since the type is fixed. -- Eric Botcazou

Re: VIS2 pattern review

From: Eric Botcazou Date: Fri, 14 Oct 2011 00:41:42 +0200 >> Unfortunately, that would involve some ABI changes for the VIS >> builtins. I'm trending towards considering just changing things >> anyways since the VIS intrinsics were next to unusable beforehand. > > Could you elaborate? The call

Re: VIS2 pattern review

> Unfortunately, that would involve some ABI changes for the VIS > builtins. I'm trending towards considering just changing things > anyways since the VIS intrinsics were next to unusable beforehand. Could you elaborate? The calling conventions for vectors (like for the other classes) shouldn't

Re: VIS2 pattern review

From: Richard Henderson Date: Thu, 13 Oct 2011 13:06:19 -0700 > On 10/13/2011 12:55 PM, David Miller wrote: >> -(define_insn "_vis" >> +(define_insn "" > > Missing a "3" on the end. Otherwise these look ok. Thanks for finding that. >> Unfortunately, that would involve some ABI changes for the

Re: VIS2 pattern review

On 10/13/2011 12:55 PM, David Miller wrote: > -(define_insn "_vis" > +(define_insn "" Missing a "3" on the end. Otherwise these look ok. > Unfortunately, that would involve some ABI changes for the VIS > builtins. I'm trending towards considering just changing things > anyways since the VIS int

Re: VIS2 pattern review

From: Richard Henderson Date: Wed, 12 Oct 2011 17:49:19 -0700 > The comment for fpmerge_vis is not correct. > I believe that the operation is representable with > > (vec_select:V8QI > (vec_concat:V8QI > (match_operand:V4QI 1 ...) > (match_operand:V4QI 2 ...) > (parallel [ >

Re: VIS2 pattern review

On 10/13/2011 11:26 AM, David Miller wrote: > Therefore, I think this "16 x 16 multiply" operation isn't the kind > you think it is, and it's therefore not appropriate to use this in the > compiler for vector multiplies. Ah, I see the magic word in the docs now: "fixed point". I.e. class MODE_ACCU

Re: VIS2 pattern review

From: David Miller Date: Thu, 13 Oct 2011 14:26:36 -0400 (EDT) > product = src1 * src2; > > scaled = (product & 0x0000) >> 8; > if (product & 0x80) > scaled++; In fact, all of the partitioned multiply instructions scale the result by 8 bits with rounding towa

Re: VIS2 pattern review

From: Richard Henderson Date: Wed, 12 Oct 2011 17:49:19 -0700 > There's a code sample 7-1 that illustrates a 16x16 multiply: > > fmul8sux16 %f0, %f1, %f2 > fmul8ulx16 %f0, %f1, %f3 > fpadd16%f2, %f3, %f4 Be wary of code examples that don't even assemble (even numbered floa

VIS2 pattern review

[ Using the UltraSparc Architecture, Draft D0.9.4, 27 Sep 2010. I believe this is the most recent public manual. It covers VIS1 and VIS2 but not VIS3. ] The comment for fpmerge_vis is not correct. I believe that the operation is representable with (vec_select:V8QI (vec_concat:V8QI

Re: Proposal: Improving patch tracking and review using Rietveld

I have addressed some of the requests brought up in this thread by modifying Rietveld's upload.py script. The new version of the upload script is called upload-gcc-patch.py and it's available at http://gcc.gnu.org/wiki/rietveld. It adds a couple of new features: 1- It takes a patch file to deter

Re: Proposal: Improving patch tracking and review using Rietveld

seful to do in the plane. You'll have the review as soon as get back on line, some 16 hours from now. Last call, gotta board now. [16 hours later...] Hi, Diego, Sorry, but I couldn't review the patch; the e-mail only had the URL. I'll be at conferences all day till the end of th

Re: Proposal: Improving patch tracking and review using Rietveld

On Fri, Jan 28, 2011 at 08:25, Joseph S. Myers wrote: > If a patch (over 400kB) is being excluded from the message because of size > (and somewhat larger patches could still be included as gzipped I have not looked into upload.py's source code, so I don't know if the limits are set in the upload

Re: Proposal: Improving patch tracking and review using Rietveld

On Fri, 28 Jan 2011, Diego Novillo wrote: > On Thu, Jan 27, 2011 at 19:44, Joseph S. Myers > wrote: > > On Wed, 26 Jan 2011, Diego Novillo wrote: > > > >> 1- Rietveld always send the patch sent to it to gcc-patches@ (provided > >> the submitter added gcc-patches to the CC list). > > > >

Re: Proposal: Improving patch tracking and review using Rietveld

On Thu, Jan 27, 2011 at 19:44, Joseph S. Myers wrote: > On Wed, 26 Jan 2011, Diego Novillo wrote: > >> 1- Rietveld always send the patch sent to it to gcc-patches@ (provided >> the submitter added gcc-patches to the CC list). > > appears to

Re: Proposal: Improving patch tracking and review using Rietveld

On Wed, 26 Jan 2011, Diego Novillo wrote: > 1- Rietveld always send the patch sent to it to gcc-patches@ (provided > the submitter added gcc-patches to the CC list). appears to be a patch sent using this system where it failed to include

Re: Proposal: Improving patch tracking and review using Rietveld

em, which is that it is much easier to review a patch in Reitveld than via e-mail (assuming you have a fast Internet connection). You can see as much context as you want in the file, it's easy to comment on specific lines. We use Reitveld for Go patches and it is a huge time saver. In Go we al

Re: Proposal: Improving patch tracking and review using Rietveld

On Thu, Jan 27, 2011 at 6:53 AM, Diego Novillo wrote: > On Thu, Jan 27, 2011 at 09:49, Richard Guenther > wrote: > >> Sure, as it is non-invasive trying it is ok.  I just wanted to see if it >> fixes any existing problem - it does not seem to (apart from >> maybe e-mail is so hard, a minor proble

Re: Proposal: Improving patch tracking and review using Rietveld

On Thu, Jan 27, 2011 at 09:55, Richard Guenther wrote: > It's of course more useful if it is integrated with bugzilla, SVN and > possibly a patch tester doing bootstrap & regtest (you probably > have all that internally). Yes. Internally, it has bug fields and it detects commits. Diego.

Re: Proposal: Improving patch tracking and review using Rietveld

On Thu, Jan 27, 2011 at 3:53 PM, Diego Novillo wrote: > On Thu, Jan 27, 2011 at 09:49, Richard Guenther > wrote: > >> Sure, as it is non-invasive trying it is ok.  I just wanted to see if it >> fixes any existing problem - it does not seem to (apart from >> maybe e-mail is so hard, a minor proble

Re: Proposal: Improving patch tracking and review using Rietveld

On Thu, Jan 27, 2011 at 09:49, Richard Guenther wrote: > Sure, as it is non-invasive trying it is ok.  I just wanted to see if it > fixes any existing problem - it does not seem to (apart from > maybe e-mail is so hard, a minor problem compared to > programming GCC is so hard ;)) For it to be a

Re: Proposal: Improving patch tracking and review using Rietveld

On Thu, Jan 27, 2011 at 3:46 PM, Diego Novillo wrote: > On Thu, Jan 27, 2011 at 05:25, Richard Guenther > wrote: > >> Does the tool know when a patch is approved or rejected based on >> review e-mail content? > > I don't think so (the internal version we use doe

Re: Proposal: Improving patch tracking and review using Rietveld

On Thu, Jan 27, 2011 at 05:25, Richard Guenther wrote: > Does the tool know when a patch is approved or rejected based on > review e-mail content? I don't think so (the internal version we use does, but I haven't seen this one implement the same scoring system). An issue i

Re: Proposal: Improving patch tracking and review using Rietveld

On Thu, Jan 27, 2011 at 05:24, Paolo Bonzini wrote: > How does this work WRT multiple versions of the same patch? It supports refreshening the patch. See for instance the phony review I've set up with some random changes I've made to the pph branch (http://codereview.appspo

Re: Proposal: Improving patch tracking and review using Rietveld

On 01/26/2011 08:56 PM, Diego Novillo wrote: At Google we use a code review tool which was open sourced a couple of years ago: Rietveld (http://code.google.com/appengine/articles/rietveld.html). The best way of thinking about it is "bugzilla for patches". The system creates an entry

Re: Proposal: Improving patch tracking and review using Rietveld

On Wed, Jan 26, 2011 at 8:56 PM, Diego Novillo wrote: > At Google we use a code review tool which was open sourced a couple of > years ago: Rietveld > (http://code.google.com/appengine/articles/rietveld.html). > > The best way of thinking about it is "bugzilla for patches&quo

Re: Proposal: Improving patch tracking and review using Rietveld

On 01/26/2011 08:56 PM, Diego Novillo wrote: At Google we use a code review tool which was open sourced a couple of years ago: Rietveld (http://code.google.com/appengine/articles/rietveld.html). The best way of thinking about it is "bugzilla for patches". The system creates an entry

Proposal: Improving patch tracking and review using Rietveld

At Google we use a code review tool which was open sourced a couple of years ago: Rietveld (http://code.google.com/appengine/articles/rietveld.html). The best way of thinking about it is "bugzilla for patches". The system creates an entry for every patch submitted, provides a we

Re: who can & want to review gengtype patches?

On 09/07/2010 10:41 AM, Basile Starynkevitch wrote: The words gengtype, GTY, garbage do not seem to appear the MAINTAINERS file, so it seems that gengtype& GTY don't have any specialized reviewers. And gengtype is not a very well written and easy to maintain piece of code, at least in our opini

who can & want to review gengtype patches?

also added some other improvements into gengtype. Laurynas Beveinis kindly took time to review our first set of patches. http://gcc.gnu.org/ml/gcc-patches/2010-09/msg00421.html http://gcc.gnu.org/ml/gcc-patches/2010-09/msg00420.html etc. Some other people, in particular Paolo Bonzini &a

Re: Request for code review - (ZEE patch : Redundant Zero extension elimination)

Hi Jan, Can you take a look at this patch when you find the time ? This is being blocked needing an approval from a x86 backend maintainer and you are the only one listed in the MAINTAINERS file. Thanks, -Sriraman. On Tue, Oct 6, 2009 at 2:56 PM, Paolo Bonzini wrote: > On 10/01/2009 11:37 P

review of dwarf2out.c changes?

Do we have any maintainers outside of the global reviewers and the dwarf debugging code reviewer who can review changes to dwarf2out.c? We have two outstanding patches that eliminate crashes in dsymutil on darwin so that gcc trunk can generate complete debug code again on that target. This does

Re: Request for code review - (ZEE patch : Redundant Zero extension elimination)

On 10/01/2009 11:37 PM, Sriraman Tallam wrote: Hi, I moved implicit-zee.c to config/i386. Can you please take another look ? I think this patch is best reviewed by an x86 backend maintainer now. Thanks for doing the adjustments, BTW. Paolo

Re: Request for code review - (ZEE patch : Redundant Zero extension elimination)

Hi Richard, I was wondering if you got a chance to see if this new patch is alright ?. Thanks, -Sriraman. On Thu, Oct 1, 2009 at 2:37 PM, Sriraman Tallam wrote: > Hi, > >      I moved implicit-zee.c to config/i386. Can you please take another look ? > >        * tree-pass.h (pass_implicit_z

  1   2   >