Hello,
May I confirm that this is the correct email address to reach you for a
proposal?
Farhan Faruqui
wonder how we want to more generally want to handle
>>>>> whether to use masking or not when iterating over modes. Currently
>>>>> we mostly rely on --param vect-partial-vector-usage. aarch64
>>>>> and riscv have both variable-length modes but also fi
over modes. Currently
we mostly rely on --param vect-partial-vector-usage. aarch64
and riscv have both variable-length modes but also fixed-size modes
where for the latter, like on x86, the target couldn't request
a mode specifically with or without masking. It seems both
aarch64 and riscv
On Mon, 19 May 2025, Tamar Christina wrote:
-Original Message-
From: Richard Biener
Sent: Friday, May 16, 2025 11:35 AM
To: gcc-patches@gcc.gnu.org
Cc: Richard Sandiford ; Tamar Christina
Subject: [PATCH][RFC] Allow the target to request a masked vector epilogue
Targets recently got
over modes. Currently
>> > we mostly rely on --param vect-partial-vector-usage. aarch64
>> > and riscv have both variable-length modes but also fixed-size modes
>> > where for the latter, like on x86, the target couldn't request
>> > a mode specifically with
> -Original Message-
> From: Richard Biener
> Sent: Friday, May 16, 2025 11:35 AM
> To: gcc-patches@gcc.gnu.org
> Cc: Richard Sandiford ; Tamar Christina
>
> Subject: [PATCH][RFC] Allow the target to request a masked vector epilogue
>
> Targets recently got
On Fri, 16 May 2025, Richard Sandiford wrote:
> Richard Biener writes:
> > Targets recently got the ability to request the vector mode to be
> > used for a vector epilogue (or the epilogue of a vector epilogue). The
> > following adds the ability for it to indicate th
I was thinking of adding a vectorization_mode class that would
encapsulate the mode and whether to allow masking or alternatively
to make the vector_modes array (and the m_suggested_epilogue_mode)
a std::pair of mode and mask flag?
Without having a very strong opinion (or the full background) on
Richard Biener writes:
> Targets recently got the ability to request the vector mode to be
> used for a vector epilogue (or the epilogue of a vector epilogue). The
> following adds the ability for it to indicate the epilogue should use
> loop masking, irrespective of the --param
Targets recently got the ability to request the vector mode to be
used for a vector epilogue (or the epilogue of a vector epilogue). The
following adds the ability for it to indicate the epilogue should use
loop masking, irrespective of the --param vect-partial-vector-usage
setting.
The simple
On Mon, 6 Jan 2025, Richard Sandiford wrote:
> > This was approved by Richard Sandiford in v1, so I'll commit it along with
> > 6/7, which relies on it.
>
> Still stands, but I didn't think of this before, so thought I'd ask:
Sure, it's never wrong to revisit things as new ideas pop in.
> Wou
"Maciej W. Rozycki" writes:
> The next change for Alpha will produce extra labels and branches in
> reload, which in turn requires basic blocks to be split at completion.
> We do this already for functions that can trap, so just extend the
> arrangement with a flag for the backend to use whenev
The next change for Alpha will produce extra labels and branches in
reload, which in turn requires basic blocks to be split at completion.
We do this already for functions that can trap, so just extend the
arrangement with a flag for the backend to use whenever it finds it
necessary.
g
On Mon, 18 Nov 2024, Richard Sandiford wrote:
> > gcc/
> > * function.h (struct function): Add
> > `split_basic_blocks_after_reload' member.
> > * lra.cc (lra): Handle it.
> > * reload1.cc (reload): Likewise.
>
> OK, thanks.
Thank you for your review. I'll commit the chang
"Maciej W. Rozycki" writes:
> The next change for Alpha will produce extra labels and branches in
> reload, which in turn requires basic blocks to be split at completion.
> We do this already for functions that can trap, so just extend the
> arrangement with a flag for the backend to use whenev
The next change for Alpha will produce extra labels and branches in
reload, which in turn requires basic blocks to be split at completion.
We do this already for functions that can trap, so just extend the
arrangement with a flag for the backend to use whenever it finds it
necessary.
g
On Wed, 23 Oct 2024, Jonathan Wakely wrote:
> This complements the existing .github/PULL_REQUEST_TEMPLATE.md file,
> which is used when somebody opens a pull request for an unofficial
> mirror/fork of GCC on Github. The text in the existing file is very
> specific to GitHub and doesn
This complements the existing .github/PULL_REQUEST_TEMPLATE.md file,
which is used when somebody opens a pull request for an unofficial
mirror/fork of GCC on Github. The text in the existing file is very
specific to GitHub and doesn't make much sense to include on every PR
creat
On Tue, Aug 13, 2024 at 01:34:58AM GMT, Alejandro Colomar wrote:
> Hi David,
I obviously meant Daniel. :-)
>
> I want to send an updated version of n2529. The original author didn't
> respond to my mail, so I'll take over. I've been preparing a GCC patch
> set for adding the feature to GCC, a
Hi David,
I want to send an updated version of n2529. The original author didn't
respond to my mail, so I'll take over. I've been preparing a GCC patch
set for adding the feature to GCC, and have informed Clang developers
about it too.
The title would be
_Lengthof - New pointer-proof keywo
on 2024/4/22 17:31, Alexandre Oliva wrote:
>
> From: Olivier Hainque
>
> Regstrapped on x86_64-linux-gnu and ppc64el-linux-gnu. Also tested with
> gcc-13 on ppc64-vx7r2 and ppc-vx7r2. Ok to install?
OK, thanks!
BR,
Kewen
>
> for gcc/testsuite/ChangeLog
>
> * gcc.target/powerpc/swap
From: Olivier Hainque
Regstrapped on x86_64-linux-gnu and ppc64el-linux-gnu. Also tested with
gcc-13 on ppc64-vx7r2 and ppc-vx7r2. Ok to install?
for gcc/testsuite/ChangeLog
* gcc.target/powerpc/swaps-p8-20.c: Change powerpc_altivec_ok
require-effective-target test into vmx
s there but since the code
> in the driver has been around since 1992, I request some folks to test it
> on AIX, Mac OS (Darwin) and solaris where the ld is not GNU bfd ld as I
> don't have access to those targets currently.
>
> Thanks,
> Andrew Pinski
>
.
>> I have tested it on x86_64-linux-gnu and it works there but since the code
>> in the driver has been around since 1992, I request some folks to test it
>> on AIX, Mac OS (Darwin) and solaris where the ld is not GNU bfd ld as I
>> don't have access to those targets
ode
> in the driver has been around since 1992, I request some folks to test it
> on AIX, Mac OS (Darwin) and solaris where the ld is not GNU bfd ld as I
> don't have access to those targets currently.
actually, you do: all of those are availble inside the cfarm.
I've also tested
7;t have a default search path.
This patch removes the special casing to fix FreeBSD building where lld is used
by default and also fix riscv-linux-gnu when used in combination with mold.
I have tested it on x86_64-linux-gnu and it works there but since the code in
the driver has been around s
On Thu, 11 Jan 2024, Frank Ch. Eigler wrote:
> diff --git a/htdocs/gitwrite.html b/htdocs/gitwrite.html
:
> -overse...@gcc.gnu.org to add access to the GCC repository.
> +admin-reque...@sourceware.org to add access to the GCC
> repository.
Thanks, Frank. I just pushed this.
(Sorry, I had though
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 acco
Paul Richard Thomas:
The interpretation request came in a long time ago but I only just got
around to implementing it.
The updated text from the standard is in the comment. Now I am writing
this, I think that I should perhaps use switch(op)/case rather than using
if/else if and depending on the
* gfortran.dg/interface_50.f90: New test.
On Wed, 1 Nov 2023 at 20:12, Harald Anlauf wrote:
> Hi Paul,
>
> Am 01.11.23 um 19:02 schrieb Paul Richard Thomas:
> > The interpretation request came in a long time ago but I only just got
> > around to implementing it.
> >
> > T
Hi Paul,
Am 01.11.23 um 19:02 schrieb Paul Richard Thomas:
The interpretation request came in a long time ago but I only just got
around to implementing it.
The updated text from the standard is in the comment. Now I am writing
this, I think that I should perhaps use switch(op)/case rather
The interpretation request came in a long time ago but I only just got
around to implementing it.
The updated text from the standard is in the comment. Now I am writing
this, I think that I should perhaps use switch(op)/case rather than using
if/else if and depending on the order of the
Iain Sandoe writes:
> Given that, currently, this value is not configurable per target the
> short-term solution is to avoid a bad request.
>
> Tested on x86_64-darwin21, OK for trunk?
> thanks
> Iain
Hi Iain,
yes this is fine. LGTM - thanks
regards,
Gaius
Given that, currently, this value is not configurable per target the
short-term solution is to avoid a bad request.
Tested on x86_64-darwin21, OK for trunk?
thanks
Iain
--- 8< ---
As noted in the PR, the problem is that we make a request for additional
stack that violates the constraints
On 12/28/22 05:30, Alexandre Oliva via Gcc-patches wrote:
In take_address_of, we may refrain from completing a decl_address
INSERT if gsi is NULL, so dnn't even ask for an INSERT in this case.
Regstrapped on x86_64-linux-gnu. Ok to install?
for gcc/ChangeLog
* tree-parloops.cc (
In take_address_of, we may refrain from completing a decl_address
INSERT if gsi is NULL, so dnn't even ask for an INSERT in this case.
Regstrapped on x86_64-linux-gnu. Ok to install?
for gcc/ChangeLog
* tree-parloops.cc (take_address_of): Skip INSERT if !gsi.
---
gcc/tree-parloops.
x86_64-linux-gnu. Ok to install?
for gcc/cp/ChangeLog
* constexpr.cc (cxx_eval_call_expression): Do not request an
INSERT that would not be completed.
OK.
Jeff
* constexpr.cc (cxx_eval_call_expression): Do not request an
INSERT that would not be completed.
---
gcc/cp/constexpr.cc |8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/gcc/cp/constexpr.cc b/gcc/cp/constexpr.cc
index d99c49bdbe282..6d20ffa2cdeb6 100644
Hi all!
Proposed patch to:
Bug 94104 - Request for diagnostic improvement
Patch tested only on x86_64-pc-linux-gnu.
Error message improvement. In Fortran 2008 actual arguments to
procedures having a pointer, with intent attribute in, formal argument
can also have the target attribute not
On Wed, Apr 21, 2021 at 3:42 PM Martin Liška wrote:
>
> On 4/21/21 6:03 PM, David Edelsohn via Gcc-patches wrote:
> > I am requesting a freeze on non-bug fix patches to trunk.
> >
> > In the GCC 12 announcement, Jakub stated:
> >
> > "The trunk has branched for the GCC 11 release and is now open
>
On 4/21/21 6:03 PM, David Edelsohn via Gcc-patches wrote:
> I am requesting a freeze on non-bug fix patches to trunk.
>
> In the GCC 12 announcement, Jakub stated:
>
> "The trunk has branched for the GCC 11 release and is now open
> again for general development, stage 1. Please consider not
> d
David Edelsohn via Gcc-patches wrote:
I am requesting a freeze on non-bug fix patches to trunk.
In the GCC 12 announcement, Jakub stated:
"The trunk has branched for the GCC 11 release and is now open
again for general development, stage 1. Please consider not
disrupting it too much during t
I am requesting a freeze on non-bug fix patches to trunk.
In the GCC 12 announcement, Jakub stated:
"The trunk has branched for the GCC 11 release and is now open
again for general development, stage 1. Please consider not
disrupting it too much during the RC phase of GCC 11 so it
is possible to
Hi,
Can we backport PR94230 patch (add a new diagnostic
flag -flarge-source-files) to GCC 10 ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94230
PR94230 backport will benefit people moving from
GCC 9 to GCC 10 who face issue while working with
large header/source files.
See example issue on Lina
, thanks, and sorry again for messing this up.
Pushed to master.
Richard
>
>
> Regards
> Vasee Vinayagamoorthy
>
> PS: I do not have commit rights, therefore could I request
> someone to commit it on my behalf if this patch is approved.
> Thanks in advance.
>
> [1]
&g
/ChangeLog:
2020-03-11 Vasee Vinayagamoorthy
* gcc.target/aarch64/advsimd-intrinsics/bfcvt-nosimd.c: Fix DejaGnu
typo.
Regards
Vasee Vinayagamoorthy
PS: I do not have commit rights, therefore could I request
someone to commit it on my behalf if this patch is approved.
Thanks in advance.
[1
Gaius Mulley writes:
> Hi Martin and Matthias,
>
> as requested here are the lang_register_spec_functions for brig,
> fortran, go and D:
ah correction here is the fortran lang_register_spec_functions patch:
12-patches
Description: fortran lang_register_spec_function
regards,
Gaius
Hi Martin and Matthias,
as requested here are the lang_register_spec_functions for brig,
fortran, go and D:
15-patches
Description: lang register for go
14-patches
Description: lang register for brig
13-patches
Description: lang register for D
13-patches
Description: lang register for fo
On 11/11/19 23:37, Janne Blomqvist wrote:
> On Mon, Nov 11, 2019 at 11:54 PM Harald Anlauf wrote:
>>
>> Dear all,
>>
>> the attached patch prints the fully qualified path if an error occurs
>> during module read. E.g., instead of a less helpful error message,
>>
>> pr81651.f90:2:6:
>>
>> 2 |
On Mon, Nov 11, 2019 at 11:54 PM Harald Anlauf wrote:
>
> Dear all,
>
> the attached patch prints the fully qualified path if an error occurs
> during module read. E.g., instead of a less helpful error message,
>
> pr81651.f90:2:6:
>
> 2 | use netcdf
> | 1
> Fatal Error: File 'ne
Dear all,
the attached patch prints the fully qualified path if an error occurs
during module read. E.g., instead of a less helpful error message,
pr81651.f90:2:6:
2 | use netcdf
| 1
Fatal Error: File 'netcdf.mod' opened at (1) is not a GNU Fortran module
file
gfortran will pr
Hi,
I would love to provide a guest contribution to your blog.
Let me know what you think. I'm excited to hear back from you!
Keep Up The Good Work.
Best,
Harsh
On 12/6/18 7:19 PM, Alexandre Oliva wrote:
tsubst_expr and tsubst_copy_and_build are not expected to handle
DEFERRED_NOEXCEPT exprs, but if tsubst_exception_specification takes a
DEFERRED_NOEXCEPT expr with !defer_ok, it just passes the expr on for
tsubst_copy_and_build to barf.
This patch arran
On Dec 6, 2018, Alexandre Oliva wrote:
> Regstrapped on x86_64- and i686-linux-gnu, mistakenly along with a patch
> with a known regression, and got only that known regression. Retesting
> without it. Ok to install?
Ping? That retesting confirmed no regressions.
https://gcc.gnu.org/ml/gcc-pa
tsubst_expr and tsubst_copy_and_build are not expected to handle
DEFERRED_NOEXCEPT exprs, but if tsubst_exception_specification takes a
DEFERRED_NOEXCEPT expr with !defer_ok, it just passes the expr on for
tsubst_copy_and_build to barf.
This patch arranges for tsubst_exception_specification to com
On May 20, 2018 7:02:40 PM GMT+02:00, Allan Sandfeld Jensen
wrote:
>On Sonntag, 20. Mai 2018 15:07:59 CEST Richard Biener wrote:
>> On May 20, 2018 11:01:54 AM GMT+02:00, Allan Sandfeld Jensen
> wrote:
>> >A little over a year back we had a regression in a point release of
>gcc
>> >
>> >because
On Sonntag, 20. Mai 2018 15:07:59 CEST Richard Biener wrote:
> On May 20, 2018 11:01:54 AM GMT+02:00, Allan Sandfeld Jensen
wrote:
> >A little over a year back we had a regression in a point release of gcc
> >
> >because the builtin __builtin_clzs got removed from i386, in part
> >because it
> >i
On May 20, 2018 11:01:54 AM GMT+02:00, Allan Sandfeld Jensen
wrote:
>A little over a year back we had a regression in a point release of gcc
>
>because the builtin __builtin_clzs got removed from i386, in part
>because it
>is was wrongly named for a target specific builtin, but we were using
>it
A little over a year back we had a regression in a point release of gcc
because the builtin __builtin_clzs got removed from i386, in part because it
is was wrongly named for a target specific builtin, but we were using it in Qt
since it existed in multiple compilers. I got the patch removing it
Hi,
I added some content to gccbrig.texi in r254820 as below. If you have something
that I could describe further there, please just let me know.
Index: gcc/brig/gccbrig.texi
===
--- gcc/brig/gccbrig.texi (revision 254819)
+++ gcc/br
Hi,
On Sun, Sep 17, 2017 at 02:13:34PM +0200, Thomas Schwinge wrote:
> Hi!
>
> On Tue, 24 Jan 2017 15:30:34 -0500, David Malcolm wrote:
> > On Tue, 2017-01-24 at 13:52 +0100, Martin Jambor wrote:
> > > [...] I have just
> > > committed the BRIG FE as revision 244867.
>
> In a build with that en
Hi!
On Tue, 24 Jan 2017 15:30:34 -0500, David Malcolm wrote:
> On Tue, 2017-01-24 at 13:52 +0100, Martin Jambor wrote:
> > [...] I have just
> > committed the BRIG FE as revision 244867.
In a build with that enabled, I just happened to "make html" in "gcc/",
and ran into:
[...]
makeinfo
Hi,
I have just committed the patch, as it is, except that a couple of
two-spaces-after Pekka's name in Changelogs had already been corrected
(sorry for that mistake) and I have also
On Fri, Jan 27, 2017 at 10:31:34AM +0200, Pekka Jääskeläinen wrote:
> --- a/gcc/brig/ChangeLog
> +++ b/gcc/brig/Ch
Hi Jakub and Matthias,
New overall patch attached. My commit access is pending so I'm relying on Martin
or someone else to get this committed for now.
Added replies inline:
On Thu, Jan 26, 2017 at 2:04 PM, Jakub Jelinek wrote:
> Hi!
>
> On Thu, Jan 26, 2017 at 01:30:21PM +0200, Pekka Jääskeläin
Hi!
On Thu, Jan 26, 2017 at 01:30:21PM +0200, Pekka Jääskeläinen wrote:
> diff --git a/ChangeLog b/ChangeLog
> index 9695f9d..6f4f256 100644
> --- a/ChangeLog
> +++ b/ChangeLog
> @@ -1,3 +1,9 @@
> +2017-01-26 Pekka Jskel??inen
> +
> + * configure.ac: Added i[3456789]86-*-linux* as a sup
Hi,
Here's a patch which I believe should address all the pointed out BRIG
FE related issues that
have not been committed yet.
I didn't introduce new fixed width int type nodes to tree.h as that
felt too intrusive at this point.
Also, changes.html is still to add.
OK for trunk?
BR,
Pekka
On
On Thu, Jan 26, 2017 at 09:38:23AM +0200, Pekka Jääskeläinen wrote:
> > I suppose that also contrib/update-copyright.py need to be updated? (I
> > never looked into that, so don't know.)
>
> Does it? The files are (c) FSF now. What should I do here exactly?
I took care of this and committed foll
On Wed, Jan 25, 2017 at 6:07 PM, Thomas Schwinge
wrote:
> Hi!
>
> On Wed, 25 Jan 2017 13:21:13 +0100, Jakub Jelinek wrote:
>> On Wed, Jan 25, 2017 at 11:00:50AM +0100, Thomas Schwinge wrote:
>> > On Tue, 24 Jan 2017 13:52:10 +0100, Martin Jambor wrote:
>> > > [BRIG front end]
>
> $ git grep
Hi!
On Wed, 25 Jan 2017 13:21:13 +0100, Jakub Jelinek wrote:
> On Wed, Jan 25, 2017 at 11:00:50AM +0100, Thomas Schwinge wrote:
> > On Tue, 24 Jan 2017 13:52:10 +0100, Martin Jambor wrote:
> > > [BRIG front end]
$ git grep --cached libbrig
gcc/brig/config-lang.in:target_libs="target-lib
On Wed, Jan 25, 2017 at 11:00:50AM +0100, Thomas Schwinge wrote:
> Hi!
>
> On Tue, 24 Jan 2017 13:52:10 +0100, Martin Jambor wrote:
> > [BRIG front end]
>
> "contrib/gcc_update" needs to be updated for "libhsail-rt".
>
>
> Here is a patch to fix some Autotools issues in libhsail-rt (currently
Hi!
On Tue, 24 Jan 2017 13:52:10 +0100, Martin Jambor wrote:
> [BRIG front end]
"contrib/gcc_update" needs to be updated for "libhsail-rt".
Here is a patch to fix some Autotools issues in libhsail-rt (currently
testing); OK for trunk?
commit 00d64708323f74191ce5a39b223bca92295fc606
Author: Th
On Tue, 2017-01-24 at 15:30 -0500, David Malcolm wrote:
> On Tue, 2017-01-24 at 13:52 +0100, Martin Jambor wrote:
> > Hi,
> >
> > On Mon, Jan 23, 2017 at 02:11:37PM +0100, Richard Biener wrote:
> > > On Mon, Jan 23, 2017 at 1:02 PM, Martin Jambor
> > > wrote:
> > > > Hi,
> > > >
> > > >
> > > >
On Tue, 2017-01-24 at 13:52 +0100, Martin Jambor wrote:
> Hi,
>
> On Mon, Jan 23, 2017 at 02:11:37PM +0100, Richard Biener wrote:
> > On Mon, Jan 23, 2017 at 1:02 PM, Martin Jambor
> > wrote:
> > > Hi,
> > >
> > >
> > > On Mon, Jan 23, 2017 at 12:56:13PM +0100, Richard Biener wrote:
> > > > On
Hi,
On Mon, Jan 23, 2017 at 02:11:37PM +0100, Richard Biener wrote:
> On Mon, Jan 23, 2017 at 1:02 PM, Martin Jambor wrote:
> > Hi,
> >
> >
> > On Mon, Jan 23, 2017 at 12:56:13PM +0100, Richard Biener wrote:
> >> On Fri, Jan 20, 2017 at 6:25 PM, Pekka Jääskeläinen
> >> wrote:
> >> > Hi Richard,
On Mon, Jan 23, 2017 at 1:02 PM, Martin Jambor wrote:
> Hi,
>
>
> On Mon, Jan 23, 2017 at 12:56:13PM +0100, Richard Biener wrote:
>> On Fri, Jan 20, 2017 at 6:25 PM, Pekka Jääskeläinen
>> wrote:
>> > Hi Richard,
>> >
>> > On Fri, Jan 20, 2017 at 10:26 AM, Richard Biener
>> > wrote:
>> >> So the
Hi,
On Mon, Jan 23, 2017 at 12:56:13PM +0100, Richard Biener wrote:
> On Fri, Jan 20, 2017 at 6:25 PM, Pekka Jääskeläinen
> wrote:
> > Hi Richard,
> >
> > On Fri, Jan 20, 2017 at 10:26 AM, Richard Biener
> > wrote:
> >> So the #ifdef ENABLE_BRIG_FE shouldn't be needed anymore (nor the
> >> con
On Fri, Jan 20, 2017 at 6:25 PM, Pekka Jääskeläinen wrote:
> Hi Richard,
>
> On Fri, Jan 20, 2017 at 10:26 AM, Richard Biener
> wrote:
>> So the #ifdef ENABLE_BRIG_FE shouldn't be needed anymore (nor the
>> configury for it).
>>
>> Otherwise this looks ok to me then.
>
> Attached is a patch set w
On Thu, Jan 19, 2017 at 6:46 PM, Pekka Jääskeläinen wrote:
> Hi Jakub and Richard,
>
> Attached is an updated BRIG FE patch which adds the HSAIL related
> builtins only internally in the BRIG FE. I didn't add LTO support as I
> believe it's not
> useful for BRIG FE due to it always inputting fully
Hi Jakub and Richard,
Attached is an updated BRIG FE patch which adds the HSAIL related
builtins only internally in the BRIG FE. I didn't add LTO support as I
believe it's not
useful for BRIG FE due to it always inputting fully linked BRIGs and
not mixing with
other frontends.
BR,
Pekka
On Mon
OK,
I'll see into adapting the Jakub's idea and also check if some of the
simplest builtins are better expanded
directly to tree nodes instead.
I'm not sure if lto support is needed though as the assumption now is
to have fully linked input to this FE
(all necessary BRIG modules fed in at build t
On Mon, Jan 16, 2017 at 09:46:43AM +0100, Richard Biener wrote:
> There are 187 of them (well, simple grep of DEF_HSAIL, so probably a bit
> less).
> They aren't really documented but I guess that __hsail_bitmask_u64 for example
> is really equivalent to sth like -1U >> n << m? So I'm not sure wh
On Fri, Jan 13, 2017 at 4:54 PM, Pekka Jääskeläinen wrote:
> On Fri, Jan 13, 2017 at 2:34 PM, Richard Biener
> wrote:
>> On Thu, Jan 12, 2017 at 3:55 PM, Pekka Jääskeläinen
>> wrote:
>>> Hi,
>>>
>>> A gentle ping...
>>
>> Looking at 002/
>>
>> What's the reason of having brig-builtins.def? I d
On Fri, Jan 13, 2017 at 11:36 PM, Richard Biener
wrote:
> Ah, with fibers fixed there's only the fp16.c part left. Presumably LGPL
> overall is OK as well (but I'm not a lawyer either).
Seems fp16.c has the GPL3 runtime exception in place, so I believe we
are good here license-wise:
"Under Sec
On January 13, 2017 4:43:30 PM GMT+01:00, "Pekka Jääskeläinen"
wrote:
>Hi Richard,
>
>Thanks for the review! Replies/questions inline.
>
>On Fri, Jan 13, 2017 at 2:28 PM, Richard Biener
> wrote:
>> On Thu, Jan 12, 2017 at 3:55 PM, Pekka Jääskeläinen
> wrote:
>>> Hi,
>>>
>>> A gentle ping...
>>
>>
On Fri, Jan 13, 2017 at 2:34 PM, Richard Biener
wrote:
> On Thu, Jan 12, 2017 at 3:55 PM, Pekka Jääskeläinen
> wrote:
>> Hi,
>>
>> A gentle ping...
>
> Looking at 002/
>
> What's the reason of having brig-builtins.def? I do not see any
> middle-end stuff using them
> and if you just emit calls
Hi Richard,
Thanks for the review! Replies/questions inline.
On Fri, Jan 13, 2017 at 2:28 PM, Richard Biener
wrote:
> On Thu, Jan 12, 2017 at 3:55 PM, Pekka Jääskeläinen
> wrote:
>> Hi,
>>
>> A gentle ping...
>
> diff --git a/gcc/configure.ac b/gcc/configure.ac
> index 140b9f9..06941c5 100644
Hi,
A gentle ping...
On Wed, Dec 14, 2016 at 7:15 PM, Pekka Jääskeläinen wrote:
> Hi,
>
> I'm calling for a global review for the BRIG frontend for inclusion in
> upstream.
> The copyright transfer has been taken care of.
>
> The patch set has been approved by Martin Jambor, the upcoming co-mai
Mon Mar 7 17:01:54 2016 +
PR tree-optimization/69740
* cfghooks.c (remove_edge): Request loop fixups if we delete
an edge that might turn an irreducible loop into a natural
loop.
* cfgloop.h (check_verify_loop_structure): Clear LOOPS_NEED_FIXUP.
Shorten the request for further news. Use global CSS, thus practically
also reducing font size when being served from gcc.gnu.org.
Applied
Gerald
Index: index.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/index.html,v
retrieving
On Tue, Dec 15, 2015 at 12:06 AM, Steve Ellcey wrote:
> On Mon, 2015-12-14 at 09:57 +0100, Richard Biener wrote:
>
>> I don't know enough to assess the effect of this but
>>
>> 1) not all archs can do auto-incdec so either the comment is misleading
>> or the test should probably be amended
>> 2)
On Mon, 2015-12-14 at 09:57 +0100, Richard Biener wrote:
> I don't know enough to assess the effect of this but
>
> 1) not all archs can do auto-incdec so either the comment is misleading
> or the test should probably be amended
> 2) I wonder why with the comment ("during the loop") you exclude
On Sat, Dec 12, 2015 at 12:48 AM, Steve Ellcey wrote:
> On Wed, 2015-12-09 at 11:24 +0100, Richard Biener wrote:
>
>> > This second case (without the preference for the original IV)
>> > generates better code on MIPS because the final assembly
>> > has the increment instructions between the loads
On Wed, 2015-12-09 at 11:24 +0100, Richard Biener wrote:
> > This second case (without the preference for the original IV)
> > generates better code on MIPS because the final assembly
> > has the increment instructions between the loads and the tests
> > of the values being loaded and so there is
On Fri, 2015-12-11 at 10:47 +0100, Richard Biener wrote:
> On Thu, Dec 10, 2015 at 8:33 PM, David Edelsohn wrote:
> > On Thu, Dec 10, 2015 at 2:23 PM, Bill Schmidt
> > wrote:
> >> Hi,
> >>
> >> The subject test case has been failing as follows:
> >>
> >> FAIL: gcc.dg/vect/costmodel/ppc/costmodel-
On Thu, Dec 10, 2015 at 8:33 PM, David Edelsohn wrote:
> On Thu, Dec 10, 2015 at 2:23 PM, Bill Schmidt
> wrote:
>> Hi,
>>
>> The subject test case has been failing as follows:
>>
>> FAIL: gcc.dg/vect/costmodel/ppc/costmodel-fast-math-vect-pr29925.c
>> scan-tree-dump-times vect "vectorization not
On Thu, Dec 10, 2015 at 2:23 PM, Bill Schmidt
wrote:
> Hi,
>
> The subject test case has been failing as follows:
>
> FAIL: gcc.dg/vect/costmodel/ppc/costmodel-fast-math-vect-pr29925.c
> scan-tree-dump-times vect "vectorization not profitable" 1
>
> The test has been failing since r223528, which
Hi,
The subject test case has been failing as follows:
FAIL: gcc.dg/vect/costmodel/ppc/costmodel-fast-math-vect-pr29925.c
scan-tree-dump-times vect "vectorization not profitable" 1
The test has been failing since r223528, which is:
2015-05-22 Richard Biener
PR tree-optimization/657
On Tue, Dec 8, 2015 at 7:56 PM, Steve Ellcey wrote:
> I have an ivopts optimization question/proposal. When compiling the
> attached program the ivopts pass prefers the original ivs over new ivs
> and that causes us to generate less efficient code on MIPS. It may
> affect other platforms too.
>
I have an ivopts optimization question/proposal. When compiling the
attached program the ivopts pass prefers the original ivs over new ivs
and that causes us to generate less efficient code on MIPS. It may
affect other platforms too.
The Source code is a C strcmp:
int strcmp (const char *p1, co
Hi,
the following patch adds a BRIG (binary representation of HSAIL)
representation description. It is within a single header file
describing the binary structures and constants of the format.
The file comes from the HSA Foundation (I have only added the
HSA_BRIG_FORMAT_H macro and check and rem
1 - 100 of 241 matches
Mail list logo
