On Thu, 6 Jul 2023, Jan Hubicka wrote:
> Hi,
> original scale_loop_profile was implemented to only handle very simple loops
> produced by vectorizer at that time (basically loops with only one exit and no
> subloops). It also has not been updated to new profile-count API very
> carefully.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110574
--- Comment #5 from keithp at keithp dot com ---
Seems like using fseeko would be a reasonable choice here -- while it's not in
ISO C, it is in POSIX 2017.
> Am 06.07.2023 um 19:50 schrieb Richard Sandiford :
>
> Richard Biener via Gcc-patches writes:
>>> On Wed, Jul 5, 2023 at 8:44 AM Hao Liu OS via Gcc-patches
>>> wrote:
>>>
>>> Hi,
>>>
>>> If a loop is unrolled by n times during vectoriation, two steps are used to
>>> calculate the
> Please split the above pattern into two, one emitting UNSPEC_IEEE_MAX
> and the other emitting UNSPEC_IEEE_MIN.
Splitted.
> The test involves blendv instruction, which is SSE4.1, so it is
> pointless to test it without -msse4.1. Please add -msse4.1 instead of
> -march=x86_64 and use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104914
--- Comment #12 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #11)
> But I don't have any other notes on my change (nor a testcase).
So I found some notes and it is similar but still different.
We were expanding:
;;
on 2023/7/7 07:00, Peter Bergner wrote:
> On 7/6/23 5:54 PM, Peter Bergner wrote:
>> On 6/30/23 7:58 PM, Carl Love via Gcc-patches wrote:
>>> +++ b/gcc/testsuite/gcc.target/powerpc/test_fpscr_rn_builtin_2.c
>>> @@ -0,0 +1,153 @@
>>> +/* { dg-do run { target { powerpc*-*-* } } } */
>>
>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104914
--- Comment #11 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #10)
> Created attachment 55496 [details]
> old patch against GCC 4.7
>
> I am trying to find my notes on this old patch but our internal bug system
> has moved a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104914
--- Comment #10 from Andrew Pinski ---
Created attachment 55496
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55496=edit
old patch against GCC 4.7
I am trying to find my notes on this old patch but our internal bug system has
moved a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67736
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |5.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104914
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104914
--- Comment #8 from YunQiang Su ---
(In reply to Andrew Pinski from comment #7)
> The initial RTL has a signed extend in there:
>
>
> (insn 20 19 23 2 (set (reg/v:DI 200 [ val+-4 ])
> (sign_extend:DI (subreg:SI (reg/v:DI 200 [ val+-4
Hi Carl,
Some more minor comments are inline below on top of Peter's insightful
review comments.
on 2023/7/1 08:58, Carl Love wrote:
>
> GCC maintainers:
>
> Ver 2, Went back thru the requirements and emails. Not sure where I
> came up with the requirement for an overloaded version with
From: Ju-Zhe Zhong
Hi, Richard and Richi.
This patch is adding cond_len_* operations pattern for target support loop
control with length.
These patterns will be used in these following case:
1. Integer division:
void
f (int32_t *restrict a, int32_t *restrict b, int32_t *restrict c, int
Hi Jeff,
Thanks for your help.
Actually I have write access as I was added to the "contributor list". Anyway,
that's very kind of you to help committing the patch.
Thanks,
-Hao
From: Jeff Law
Sent: Friday, July 7, 2023 0:06
To: Richard Biener; Hao Liu
Hi Carl,
on 2023/7/6 23:33, Carl Love wrote:
> GCC maintainers:
>
> Ver 4. Fixed a few typos. Redid the tests to create separate run and
> compile tests.
Thanks! This new version looks good, excepting that we need vsx_hw
for run and two nits, see below.
>
> Ver 3. Added __attribute__
Committed, thanks Robin and Kito.
Pan
-Original Message-
From: Robin Dapp
Sent: Thursday, July 6, 2023 11:30 PM
To: Li, Pan2 ; gcc-patches@gcc.gnu.org
Cc: rdapp@gmail.com; juzhe.zh...@rivai.ai; jeffreya...@gmail.com; Wang,
Yanzhang ; kito.ch...@gmail.com; Robin Dapp
Subject: Re:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110538
--- Comment #2 from Andrew Pinski ---
So dom3 was able to optimize that via a jump threading before in GCC 13 but no
longer on the trunk (I don't understand why though).
Anyways the only pass which is able to optimize:
```
int f123(int a, int
On 7/5/23 12:43, Joern Rennecke wrote:
I haven't worked with these targets in years and can't really do sensible
maintenance or reviews of patches for them.
I am currently working on optimizations for other ports like RISC-V.
ARC has still an active maintainer in Claudiu Zissulescu, so is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110538
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
Stepping down as maintainer for ARC and Epiphany
* MAINTAINERS (CPU Port Maintainers): Remove myself as ARC end
epiphany maintainer.
(Write After Approval): Add myself.commit b3f20dd75e9255fc9d56d4f020972469dd671a3a
Author: Joern Rennecke
Date: Fri Jul 7 01:02:28 2023
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106895
--- Comment #11 from Nicholas Piggin ---
(In reply to Segher Boessenkool from comment #10)
> (In reply to Nicholas Piggin from comment #9)
> > I don't know why constraint is wrong and mode is right
>
> Simple: you would need O(2**T*N)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110573
--- Comment #6 from Andrew Pinski ---
(In reply to Luke Geeson from comment #4)
> I understand treating atomics as volatile has historical precedent but a
> case can be made, at least on modern architectures and with improved
> understanding of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110573
--- Comment #5 from Luke Geeson ---
For the record the %registers are symbolic - simply replace them with concrete
ones containing the location x,y,etc...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110573
--- Comment #4 from Luke Geeson ---
Ah so since atomics are treated as volatile (like LLVM) instructions that
access them cannot inhabit a delay slot. Is it still valid to treat atomics as
volatile?
Consider the following MIPS litmus test:
```
On Thu, Jul 06, 2023 at 02:48:19PM -0500, Peter Bergner wrote:
> On 7/6/23 12:33 PM, Segher Boessenkool wrote:
> > On Wed, Jul 05, 2023 at 05:21:18PM +0530, P Jeevitha wrote:
> >> --- a/gcc/config/rs6000/rs6000.cc
> >> +++ b/gcc/config/rs6000/rs6000.cc
> >> @@ -9894,6 +9894,8 @@
I have implemented support for uninitialized memory in my translation
validator. But I am not sure how well this corresponds to the GIMPLE
semantics, so I have some questions...
My implementation tracks uninitialized bits. Use of uninitialized bits is
in general treated as UB (for example, `x
On 7/6/23 5:54 PM, Peter Bergner wrote:
> On 6/30/23 7:58 PM, Carl Love via Gcc-patches wrote:
>> +++ b/gcc/testsuite/gcc.target/powerpc/test_fpscr_rn_builtin_2.c
>> @@ -0,0 +1,153 @@
>> +/* { dg-do run { target { powerpc*-*-* } } } */
>
> powerpc*-*-* is the default for this test directory, so
Hi!
On Mon, 2023-06-19 16:29:53 +0800, Jie Mei wrote:
> There are shortened bitwise instructions in the mips16e2 ASE,
> for instance, ANDI, ORI/XORI, EXT, INS etc. .
>
> This patch adds these instrutions with corresponding tests.
[...]
Starting with this patch, I see some new warning:
[all
On 6/30/23 7:58 PM, Carl Love via Gcc-patches wrote:
> rs6000, __builtin_set_fpscr_rn add retrun value
s/retrun/return/
Maybe better written as:
rs6000: Add return value to __builtin_set_fpscr_rn
> Change the return value from void to double. The return value consists of
> the FPSCR fields
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110539
--- Comment #5 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #4)
> yes adding:
> /* (convert)(zeroone != 0) into (convert)zeroone */
> /* (convert)(zeroone == 0) into ((convert)zeroone)^1 */
> (for neeq (ne eq)
> (simplify
>
Snapshot gcc-11-20230706 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/11-20230706/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 11 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
What if the user chooses in own ABI, say specifying a config file like
My abi
" Parameters = pushed in stack"
say
gcc -abi "My abi" some.c -o some
what would be the problems of specifying an ABI?? would that improve the
usage of user? less complex / more
simpler for user (say user is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110539
--- Comment #4 from Andrew Pinski ---
yes adding:
/* (convert)(zeroone != 0) into (convert)zeroone */
/* (convert)(zeroone == 0) into ((convert)zeroone)^1 */
(for neeq (ne eq)
(simplify
(convert (neeq zero_one_valued_p@0 integer_zerop))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81880
Timothee Besset changed:
What|Removed |Added
CC||ttimo at valvesoftware dot com
---
I get the following warning which prevents gcc from bootstrapping due to
-Werror:
/home/meissner/fsf-src/work124-sfsplat/gcc/config/rs6000/rs6000-p10sfopt.cc: In
function ‘void {anonymous}::process_chain_from_load(gimple*)’:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110580
Bug ID: 110580
Summary: [14 Regression] gcc fails to typecheck nix-2.16.1
source: error: invalid initialization of reference of
type
Product: gcc
Version: 14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110539
--- Comment #3 from Andrew Pinski ---
Here is a testcase for the missing optimization (at -O1) which is optimized at
the RTL level (for some targets but not all):
```
int f(int a)
{
int b = a & 1;
int c = b != 0;
return
On Thu, 6 Jul 2023, 22:20 André Albergaria Coelho via Gcc,
wrote:
> Could gcc have an option to specify ABI?
>
> say
>
>
> gcc something.c -g -abi 1 -o something
>
Sure, it could do, but what would it do? What would "-abi 1" mean? Which
ABI would it relate to?
What are you actually asking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110539
--- Comment #2 from Andrew Pinski ---
So the difference comes from the order. Before in phiopt we had:
- /* Defer boolean x ? 0 : {1,-1} or x ? {1,-1} : 0 to
- match_simplify_replacement. */
- if (TREE_CODE (TREE_TYPE (lhs)) ==
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #48 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #47)
> However, when I use -O2 together with an -march= flag, the code works.
> I've tested -march=sandybridge, -march=haswell, -march=skylake,
> -march=native.
The pr97428.c test assumes support for vectors of doubles, but some
targets only support vectors of floats, causing this test to fail with
such targets. Limit this test to targets that support vectors of
doubles then.
gcc/testsuite/
* gcc.dg/vect/pr97428.c: Limit to
The bb-slp-pr95839.c test assumes quad-single float vector support, but
some targets only support pairs of floats, causing this test to fail
with such targets. Limit this test to targets that support at least
128-bit vectors then, and add a complementing test that can be run with
targets that
Similarly to checks for vectors of 32 bits and 64 bits being supported
add one for vectors of 128 bits.
gcc/testsuite/
* lib/target-supports.exp (check_effective_target_vect128): New
procedure.
---
gcc/testsuite/lib/target-supports.exp |6 ++
1 file changed, 6
Hi,
In the course of verifying an out-of-tree RISC-V target that has a vendor
extension providing hardware support for vector operations on pairs of
single floating-point values (similar to MIPS paired-single or Power SPE
vector types) I have come across a couple of tests that fail just
It does, for machine architectures that have multiple ABIs. MIPS is an example
where GCC has supported this for at least 20 years.
paul
> On Jul 6, 2023, at 5:19 PM, André Albergaria Coelho via Gcc
> wrote:
>
> Could gcc have an option to specify ABI?
>
> say
>
>
> gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110539
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
Could gcc have an option to specify ABI?
say
gcc something.c -g -abi 1 -o something
thanks
andre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #47 from anlauf at gcc dot gnu.org ---
(In reply to Jürgen Reuter from comment #46)
> The issue goes away with -O0, with -O1 and with -O2 -fno-tree-vectorize.
> I might want to find the offending commit in the week of June 12-19 in
Hello,
My name is Daria Shatalinska and I am a Project Manager at Freelancer. I am
contacting you to see if you might be interested in collaborating with us
on a project for NASA's Open Innovation Services program (NOIS2). As an
awardee of the $175 million NOIS2 contract
Am Donnerstag, dem 06.07.2023 um 18:56 + schrieb Qing Zhao:
> Hi, Kees,
>
> I have updated my V1 patch with the following changes:
> A. changed the name to "counted_by"
> B. changed the argument from a string to an identifier
> C. updated the documentation and testing cases accordingly.
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110540
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-07-06
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110579
--- Comment #5 from Gabriel ---
I see. That makes sense.
Our research project has a dataset with tar 1.14. Our plan is to compare our
work with existing work in the dataset and to be consistent, use tar 1.14. We
noticed our binary compiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110501
--- Comment #6 from Cheyenne Wills ---
Just another bit of information.
Specifying just -Werror=use-after-free appears to be not not enough to trigger
the problem. Using -Wall however does trigger the problem.
(tried on gcc-12 and gcc-13)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110579
--- Comment #4 from Andrew Pinski ---
All of these FORTIFY issues have been fixed for a long time now (over 10
years).
Why are you trying to use an old version of gnu tar?
e.g. https://lists.gnu.org/archive/html/bug-tar/2010-02/msg00010.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443
Bug 88443 depends on bug 110579, which changed state.
Bug 110579 Summary: O2, O1 opmtimizations cause a buffer overflow panic during
a strcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110579
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110579
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110579
--- Comment #2 from Sam James ---
Could you give us a backtrace with -ggdb3 when it aborts at runtime?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110579
--- Comment #1 from Gabriel ---
Created attachment 55494
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55494=edit
Processed *.i files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110579
Bug ID: 110579
Summary: O2, O1 opmtimizations cause a buffer overflow panic
during a strcpy
Product: gcc
Version: 11.3.0
Status: UNCONFIRMED
Severity: normal
On Thu, Jul 06, 2023 at 03:00:28PM +0200, Richard Biener via Gcc-patches wrote:
> > + (if (types_match (type, @1))
> > + (bit_not (bit_and @1 (convert @0)))
> > + (if (types_match (type, @0))
> > +(bit_not (bit_and (convert @1) @0))
> > +(convert (bit_not (bit_and @0 (convert
On 7/6/23 12:33 PM, Segher Boessenkool wrote:
> On Wed, Jul 05, 2023 at 05:21:18PM +0530, P Jeevitha wrote:
>> --- a/gcc/config/rs6000/rs6000.cc
>> +++ b/gcc/config/rs6000/rs6000.cc
>> @@ -9894,6 +9894,8 @@ rs6000_legitimate_address_p (machine_mode mode, rtx x,
>> bool reg_ok_strict)
>>
>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #46 from Jürgen Reuter ---
(In reply to Jürgen Reuter from comment #45)
> Created attachment 55492 [details]
> Smaller stand-alone reproducer
>
> I will give more information in a comment, this contains 3 files and a
> Makefile.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #45 from Jürgen Reuter ---
Created attachment 55492
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55492=edit
Smaller stand-alone reproducer
I will give more information in a comment, this contains 3 files and a
Makefile.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110578
Bug ID: 110578
Summary: Support dynamic_cast within the analyzer
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104914
Andrew Pinski changed:
What|Removed |Added
Component|target |rtl-optimization
Ever confirmed|0
Hi, Kees,
I have updated my V1 patch with the following changes:
A. changed the name to "counted_by"
B. changed the argument from a string to an identifier
C. updated the documentation and testing cases accordingly.
And then used this new gcc to test
Hi!
On 2014-09-01T21:56:28-0400, tsaund...@mozilla.com wrote:
> [...] this part [...]
... became commit b086d5308de0d25444243f482f2f3d1dfd3a9a62
(Subversion r214834), which added GGC support to 'hash_map', 'hash_set',
and converted to those a number of 'htab' instances.
It doesn't really
On 6/28/23 3:07 AM, Kewen.Lin wrote:
> I think the reason why we need to check common_deferred_options is at this
> time
> we can't distinguish the fixed_regs[2] is from the initialization or command
> line
> user explicit specification. But could we just update the FIXED_REGISTERS
> without
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110577
Bug ID: 110577
Summary: s390x: Some tests fail with -march=z13
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110574
Jonathan Wakely changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
Richard Biener via Gcc-patches writes:
> On Wed, Jul 5, 2023 at 8:44 AM Hao Liu OS via Gcc-patches
> wrote:
>>
>> Hi,
>>
>> If a loop is unrolled by n times during vectoriation, two steps are used to
>> calculate the induction variable:
>> - The small step for the unrolled ith-copy: vec_1 =
A retry build has been detected on builder gccrust-gentoo-sparc while building
gccrust.
Full details are available at:
https://builder.sourceware.org/buildbot/#builders/241/builds/791
Build state: retry lost connection compile (retry)
Revision: b9566fddf2915f68f050844df699389474c49ac4
Hi!
On Wed, Jul 05, 2023 at 05:21:18PM +0530, P Jeevitha wrote:
> The following patch has been bootstrapped and regtested on powerpc64le-linux.
>
> while generating vector pairs of load & store instruction, the src address
> was treated as an altivec type and that type of address is invalid for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110573
--- Comment #3 from Andrew Pinski ---
See
https://inbox.sourceware.org/gcc/d7787b3f-9450-5642-ffac-21cf36176...@redhat.com/
also.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110573
--- Comment #2 from Andrew Pinski ---
volatile (atomics) stores are not considered for branch delay slots.
https://inbox.sourceware.org/gcc/3077458.gu9dx72...@arcturus.home/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110575
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22401
--- Comment #5 from Jan Hubicka ---
This is now threaded by threadfull2:
Checking profitability of path (backwards): bb:3 (2 insns) bb:2
Control statement insns: 2
Overall: 0 insns
path: 2->3->xx REJECTED
Checking profitability of path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25623
--- Comment #12 from CVS Commits ---
The master branch has been updated by Jan Hubicka :
https://gcc.gnu.org/g:3a61ca1b9256535e1bfb19b2d46cde21f3908a5d
commit r14-2369-g3a61ca1b9256535e1bfb19b2d46cde21f3908a5d
Author: Jan Hubicka
Date: Thu
Hi Christophe,
> -Original Message-
> From: Christophe Lyon
> Sent: Thursday, July 6, 2023 4:21 PM
> To: Kyrylo Tkachov
> Cc: gcc-patches@gcc.gnu.org; Richard Sandiford
>
> Subject: Re: [PATCH] arm: Fix MVE intrinsics support with LTO (PR
> target/110268)
>
>
>
> On Wed, 5 Jul 2023
On Tue, 04 Jul 2023, Alan Stern wrote:
> On Tue, Jul 04, 2023 at 01:19:23PM -0400, Olivier Dion wrote:
>> On Mon, 03 Jul 2023, Alan Stern wrote:
>> > On Mon, Jul 03, 2023 at 03:20:31PM -0400, Olivier Dion wrote:
[...]
> Oh, is that it? Then I misunderstood entirely; I thought you were
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110576
Bug ID: 110576
Summary: ICE on compilation
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110557
--- Comment #6 from Xi Ruoyao ---
(In reply to avieira from comment #5)
> Hi Xi,
>
> Feel free to test your patch and submit it to the list for review. I had a
> look over and it looks correct to me.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110574
--- Comment #3 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #0)
> Using --enable-cstdio=stdio_pure on x86_64-pc-linux-gnu results in test
> failures:
>
> FAIL: 27_io/basic_filebuf/imbue/char/13171-2.cc execution test
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110557
Xi Ruoyao changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
If a bit-field is signed and it's wider than the output type, we must
ensure the extracted result sign-extended. But this was not handled
correctly.
For example:
int x : 8;
long y : 55;
bool z : 1;
The vectorized extraction of y was:
vect__ifc__49.29_110 =
MEM [(struct
On 7/6/23 06:44, Richard Biener via Gcc-patches wrote:
On Wed, Jul 5, 2023 at 8:44 AM Hao Liu OS via Gcc-patches
wrote:
Hi,
If a loop is unrolled by n times during vectoriation, two steps are used to
calculate the induction variable:
- The small step for the unrolled ith-copy: vec_1 =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110449
--- Comment #3 from CVS Commits ---
The master branch has been updated by Jeff Law :
https://gcc.gnu.org/g:224fd59b2dc8a5fa78a309a09863afe9b3cf2111
commit r14-2367-g224fd59b2dc8a5fa78a309a09863afe9b3cf2111
Author: Hao Liu OS
Date: Thu Jul
This patch allows 'declare mapper' mappers to be used on 'omp target
data', 'omp target enter data' and 'omp target exit data' directives.
For each of these, only explicit mappings are supported, unlike for
'omp target' directives where implicit uses of variables inside an
offload region might
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110555
Marek Polacek changed:
What|Removed |Added
Last reconfirmed||2023-07-06
Ever confirmed|0
+; False dependency happens on destination register which is not really
+; used when moving all ones to vector register
+(define_split
+ [(set (match_operand:VMOVE 0 "register_operand")
+ (match_operand:VMOVE 1 "int_float_vector_all_ones_operand"))]
+ "TARGET_AVX512F && reload_completed
+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104299
--- Comment #4 from CVS Commits ---
The releases/gcc-12 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:67bda4331dc4f548820ed2f3138aa7f64fd4c77d
commit r12-9757-g67bda4331dc4f548820ed2f3138aa7f64fd4c77d
Author: Jonathan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104299
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |11.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104299
--- Comment #3 from Jonathan Wakely ---
Fixed on trunk and gcc-13 so far.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104299
--- Comment #2 from CVS Commits ---
The releases/gcc-13 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:94d24f1af684d37b9e1c6ad9b54c98609140eb1f
commit r13-7537-g94d24f1af684d37b9e1c6ad9b54c98609140eb1f
Author: Jonathan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110574
--- Comment #2 from Jonathan Wakely ---
Doh, I put the wrong PR number in that commit, it's meant to be for PR 104299
Pushed to trunk. Backports to 11, 12 and 13 will follow.
-- >8 --
libstdc++-v3/ChangeLog:
PR libstdc++/110574
* doc/xml/manual/configure.xml: Describe stdio_pure argument to
--enable-cstdio.
* doc/html/manual/configure.html: Regenerate.
---
GCC maintainers:
Ver 4. Fixed a few typos. Redid the tests to create separate run and
compile tests.
Ver 3. Added __attribute__ ((noipa)) to the test files. Changed some
of the scan-assembler-times checks to cover multiple similar
instructions. Change the function check macro to a macro to
Kewen:
On Tue, 2023-07-04 at 10:49 +0800, Kewen.Lin wrote:
>
> >
> > The tests are broken up into a seriers of files for related
> > tests. The
>
> s/seriers/series/
Fixed
>
> > new tests are runnable tests to verify the builtin argument types
> > and the
> > functional correctness of
Hi Pan,
thanks, I think that works for me as I'm expecting these
parts to change a bit anyway in the near future.
There is no functional change to the last revision that
Kito already OK'ed so I think you can go ahead.
Regards
Robin
On 7/6/23 00:48, Christoph Müllner wrote:
Thanks for this!
Of course I was "lucky" and ran into the issue that the patterns did not match,
because of unexpected MULT insns where ASHIFTs were expected.
But after reading enough of combiner.cc I understood that this is on purpose
(for
1 - 100 of 208 matches
Mail list logo
