Hi Alexandre,
on 2023/5/24 13:51, Alexandre Oliva wrote:
>
> Codegen changes caused add instruction count mismatches on
> ppc-*-linux-gnu and other 32-bit ppc targets. At some point the
> expected counts were adjusted for lp64, but ilp32 differences
> remained, and published test results
On 24 May 2023 16:09:21 CEST, Qing Zhao wrote:
>Bernhard,
>
>Thanks a lot for your comments.
>
>> On May 19, 2023, at 7:11 PM, Bernhard Reutner-Fischer
>> wrote:
>>
>> On Fri, 19 May 2023 20:49:47 +
>> Qing Zhao via Gcc-patches wrote:
>>
>>> GCC extension accepts the case when a struct
NANs don't have bounds, so there's no need to stream them out.
gcc/ChangeLog:
* data-streamer-in.cc (streamer_read_value_range): Handle NANs.
* data-streamer-out.cc (streamer_write_vrange): Same.
* value-range.h (class vrange): Make streamer_write_vrange a friend.
---
frange::set() is confusing in that we can set a NAN by specifying a
bound of +-NAN, even though we tecnically disallow NANs in the setter
because the kind can never be VR_NAN. This is a wart for
get_tree_range(), which builds a range out of a tree from the source,
to work correctly. It's ugly,
We're ICEing when trying to hash a known NAN. This is unnoticeable
because the only user would be IPA, and even so, it currently doesn't
handle floats. However, handling floats is a flip of a switch, so
it's best to handle them already.
gcc/ChangeLog:
* value-range.cc (add_vrange):
Generalize frange::set_nan() to take a nan_state and make current
set_nan() methods syntactic sugar.
This is in preparation for better streaming of NANs for LTO/IPA.
gcc/ChangeLog:
* value-range.h (frange::set_nan): New.
---
gcc/value-range.h | 32 +---
1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109956
--- Comment #10 from Andrew Pinski ---
(In reply to Alexander Monakov from comment #8)
> I think the following testcase indicates that GCC assumes that tail padding
> is accessible:
Well it aligned accesses are always accessable
the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109956
--- Comment #9 from Martin Uecker ---
Clang as well, but that would be only padding inside the first part without
taking into account extra element in the FAM.
I am more concert about programmers using the formula sizeof(.) + n * sizeof
for
on 2023/5/24 23:20, Carl Love wrote:
> On Wed, 2023-05-24 at 13:32 +0800, Kewen.Lin wrote:
>> on 2023/5/24 06:30, Peter Bergner wrote:
>>> On 5/23/23 12:24 AM, Kewen.Lin wrote:
on 2023/5/23 01:31, Carl Love wrote:
> The builtins were requested for use in GLibC. As of version
> 2.31
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109956
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90504
--- Comment #2 from Janne Blomqvist ---
(In reply to anlauf from comment #1)
> (In reply to Janne Blomqvist from comment #0)
> > Hanson, Hopkins, Remark on Algorithm 539: A Modern Fortran Reference
> > Implementation for Carefully Computing the
>> It's highly unlikely we'll switch from the mechanisms we're using.
>>They're pretty deeply embedded into how all the ports are developed and
>>work.
We just take a look at the build file. It seems that the functions generated by
define_insn
are so many. Do we have the chance optimize it?
I
Yeah, JoJo still working on toolchain stuff, but just not active on upstream GCC
cc. jojo
On Thu, May 25, 2023 at 12:06 PM Jeff Law wrote:
>
>
>
> On 5/24/23 21:53, Kito Cheng wrote:
> > Jojo has a patch to try to split those things that should help this,
> > but seems not landed.
> >
> >
On 5/24/23 21:54, juzhe.zh...@rivai.ai wrote:
>> IIRC LLVM is using the table driven mechanism, so it's less impact
on the
compilation time when the instruction becomes more and more.
Oh, I see. Could you share more details ?
Maybe we can support this in GCC.
It's highly unlikely we'll
On 5/24/23 21:53, Kito Cheng wrote:
Jojo has a patch to try to split those things that should help this,
but seems not landed.
https://patchwork.ozlabs.org/project/gcc/patch/20201104015315.81416-1-jiejie_r...@c-sky.com/
Is JoJo still active? I haven't heard from JoJo in many months, perhaps
LGTM, thanks :)
On Wed, May 24, 2023 at 7:26 PM wrote:
>
> From: Juzhe-Zhong
>
> According to RVV ISA:
> The conversions use the dynamic rounding mode in frm, except for the rtz
> variants, which round towards zero.
>
> So rtz conversion patterns should not have FRM dependency.
>
> We can't
>> IIRC LLVM is using the table driven mechanism, so it's less impact on the
>> compilation time when the instruction becomes more and more.
Oh, I see. Could you share more details ?
Maybe we can support this in GCC.
juzhe.zh...@rivai.ai
From: Kito Cheng
Date: 2023-05-25 11:53
To:
Jojo has a patch to try to split those things that should help this,
but seems not landed.
https://patchwork.ozlabs.org/project/gcc/patch/20201104015315.81416-1-jiejie_r...@c-sky.com/
> How about LLVM? Can kito help with this issue?
> LLVM has already supported full intrinsics for a long time
Besides, we don't have compilation issues in crossing-compiling (with segment
intrinsics).
But I do agree we need to address such issue.
As far as I known, GCC compile insn-emit in single thread single core.
Can we multi-thread && multi-core to compile it to speed up the compilation?
Thanks.
segment intrinsics are really huge amount.
Even though I have tried to optimized them, still we have the issues..
How about LLVM? Can kito help with this issue?
LLVM has already support full intrinsics for a long time and no issues.
Thanks.
juzhe.zh...@rivai.ai
From: Jeff Law
Date:
On 5/24/23 17:13, Palmer Dabbelt wrote:
On Wed, 24 May 2023 16:12:20 PDT (-0700), Vineet Gupta wrote:
[ ... big snip ... ]
Never mind. Looks like I found the issue - with just trial and error and
no idea of how this stuff works.
The torture-{init,finish} needs to be in riscv.exp not
在 2023/5/25 上午10:52, WANG Xuerui 写道:
On 2023/5/25 10:46, Lulu Cheng wrote:
在 2023/5/25 上午4:15, Jason Merrill 写道:
On Wed, May 24, 2023 at 5:00 AM Jonathan Wakely via Gcc-patches
mailto:gcc-patches@gcc.gnu.org>> wrote:
On Wed, 24 May 2023 at 09:41, Xi Ruoyao wrote:
> Wang Lei
On Thu, May 25, 2023 at 10:55 AM Hu, Lin1 via Gcc-patches
wrote:
>
> Hi all,
>
> This patch aims to fix incorrect intrinsic signature for
> _mm{512|256|}_s{lli|rai|rli}_epi*. And it has been tested on
> x86_64-pc-linux-gnu. OK for trunk?
>
> BRs,
> Lin
>
> gcc/ChangeLog:
>
> PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109959
--- Comment #4 from Andrew Pinski ---
Note the underlaying issue with VRP is similar to PR 109959 but it is about a
slightly different optimization though.
Oops, forget to remove it in previous version, will wait a while and update
them together.
Pan
From: juzhe.zh...@rivai.ai
Sent: Thursday, May 25, 2023 11:14 AM
To: Li, Pan2 ; gcc-patches
Cc: Kito.cheng ; Li, Pan2 ; Wang,
Yanzhang
Subject: Re: [PATCH v6] RISC-V: Using merge approach to
* machmode.h (VECTOR_BOOL_MODE_P): New macro.
--- a/gcc/machmode.h
+++ b/gcc/machmode.h
@@ -134,6 +134,10 @@ extern const unsigned char mode_class[NUM_MACHINE_MODES];
|| GET_MODE_CLASS (MODE) == MODE_VECTOR_ACCUM \
|| GET_MODE_CLASS (MODE) == MODE_VECTOR_UACCUM)
+/* Nonzero if MODE
Hi Kito,
Update the PATCH v6 with refactored framework as below, thanks for comments.
https://gcc.gnu.org/pipermail/gcc-patches/2023-May/619536.html
Pan
-Original Message-
From: Gcc-patches On Behalf
Of Kito Cheng via Gcc-patches
Sent: Wednesday, May 17, 2023 11:52 AM
To:
From: Pan Li
This patch would like to optimize the VLS vector initialization like
repeating sequence. From the vslide1down to the vmerge with a simple
cost model, aka every instruction only has 1 cost.
Given code with -march=rv64gcv_zvl256b --param
riscv-autovec-preference=fixed-vlmax
typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109948
--- Comment #5 from Rimvydas (RJ) ---
(In reply to anlauf from comment #4)
> Can you check if this works for you?
This patch allows to avoid issue on all other associate use cases (tried on
gcc-13 branch).
However it is a bit suspicious that
Hi, Richard.
After several tries with your testcases (I already added into V15 patch).
I think "using a new IV" would be better than "multiplication"
Now:
loop_len_34 = MIN_EXPR ;
_74 = MIN_EXPR ; --> multiplication approach will changed
into _74 = loop_len_34 * 2;
loop_len_48 =
From: Ju-Zhe Zhong
This patch is supporting decrement IV by following the flow designed by Richard:
(1) In vect_set_loop_condition_partial_vectors, for the first iteration of:
call vect_set_loop_controls_directly.
(2) vect_set_loop_controls_directly calculates "step" as in your patch.
If
Hi all,
This patch aims to fix incorrect intrinsic signature for
_mm{512|256|}_s{lli|rai|rli}_epi*. And it has been tested on
x86_64-pc-linux-gnu. OK for trunk?
BRs,
Lin
gcc/ChangeLog:
PR target/109173
PR target/109174
* config/i386/avx512bwintrin.h
On 2023/5/25 10:46, Lulu Cheng wrote:
在 2023/5/25 上午4:15, Jason Merrill 写道:
On Wed, May 24, 2023 at 5:00 AM Jonathan Wakely via Gcc-patches
mailto:gcc-patches@gcc.gnu.org>> wrote:
On Wed, 24 May 2023 at 09:41, Xi Ruoyao wrote:
> Wang Lei raised some concerns about Itanium C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109960
--- Comment #4 from Andrew Pinski ---
I happened to notice this because I am working on a match patch that transform
`a ? 1 : b` into `a | b`.
In the case of stmt_can_terminate_bb_p, I noticed we had:
[local count: 330920071]:
_48 =
在 2023/5/25 上午4:15, Jason Merrill 写道:
On Wed, May 24, 2023 at 5:00 AM Jonathan Wakely via Gcc-patches
mailto:gcc-patches@gcc.gnu.org>> wrote:
On Wed, 24 May 2023 at 09:41, Xi Ruoyao wrote:
> Wang Lei raised some concerns about Itanium C++ ABI, so let's
ask a C++
> expert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100106
--- Comment #10 from CVS Commits ---
The master branch has been updated by Alexandre Oliva :
https://gcc.gnu.org/g:d6b756447cd58bcca20e6892790582308b869817
commit r14-1187-gd6b756447cd58bcca20e6892790582308b869817
Author: Alexandre Oliva
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109933
--- Comment #9 from Rory Bolt ---
Created attachment 55153
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55153=edit
patch
Tested fix for big endian, NOT tested on little endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109960
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|1 |0
Status|ASSIGNED
Hi,
This is the 8th version of the patch, which rebased on the latest trunk.
This is an important patch needed by Linux Kernel security project.
compared to the 7th version, the major change are:
1. update the documentation wordings based on Joseph's suggestions.
2. change the name of the new
on a structure with a C99 flexible array member being nested in
another structure.
"The GCC extension accepts a structure containing an ISO C99 "flexible array
member", or a union containing such a structure (possibly recursively)
to be a member of a structure.
There are two situations:
* A
GCC extension accepts the case when a struct with a C99 flexible array member
is embedded into another struct or union (possibly recursively) as the last
field.
__builtin_object_size should treat such struct as flexible size.
gcc/c/ChangeLog:
PR tree-optimization/101832
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109961
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Summary|storage size of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109960
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-05-25
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109961
Bug ID: 109961
Summary: storage size of 'variable name' isn't known
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109960
--- Comment #1 from Andrew Pinski ---
We could have a pattern that does:
`(a & CST) != 0 ? 1: (bool)a` -> `a & (CST|1) != 0` to fix this I think.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109960
Andrew Pinski changed:
What|Removed |Added
Known to work||8.5.0
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109960
Bug ID: 109960
Summary: [10/11/12/13/14 Regression] missing combining of
`(a&1) != 0 || (a&2)!=0` into `(a&3)!=0`
Product: gcc
Version: 14.0
Status: UNCONFIRMED
> > +rewrite_expr_tree_parallel (gassign *stmt, int width, bool has_fma,
> > +const vec
> > +)
> > {
> >enum tree_code opcode = gimple_assign_rhs_code (stmt);
> >int op_num = ops.length ();
> > @@ -5483,10 +5494,11 @@ rewrite_expr_tree_parallel
From: Lili Cui
Make some changes in reassoc pass to make it more friendly to fma pass later.
Using FMA instead of mult + add reduces register pressure and insruction
retired.
There are mainly two changes
1. Put no-mult ops and mult ops alternately at the end of the queue, which is
conducive to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109927
--- Comment #18 from Stan Johnson ---
$ git clone git://gcc.gnu.org/git/gcc.git
$ cd gcc
$ git checkout master
I'm testing a manual bootstrap of "gcc version 14.0.0 20230524 (experimental)
(GCC)" now, accessed via git as s
On 5/24/23 17:12, Vineet Gupta wrote:
On 5/24/23 15:13, Vineet Gupta wrote:
PASS: gcc.target/riscv/zmmul-2.c -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects (test for excess errors)
PASS: gcc.target/riscv/zmmul-2.c -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects
`This patch tries to prevent generating unnecessary sign extension
after *w instructions like "addiw" or "divw".
The main idea of it is to add SUBREG_PROMOTED fields during expanding.
I have tested on SPEC2017 there is no regression.
Only gcc.dg/pr30957-1.c test failed.
To solve that I did some
On Wed, 24 May 2023 16:12:20 PDT (-0700), Vineet Gupta wrote:
On 5/24/23 15:13, Vineet Gupta wrote:
PASS: gcc.target/riscv/zmmul-2.c -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects (test for excess errors)
PASS: gcc.target/riscv/zmmul-2.c -O2 -flto -fuse-linker-plugin
On 5/24/23 15:13, Vineet Gupta wrote:
PASS: gcc.target/riscv/zmmul-2.c -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects (test for excess errors)
PASS: gcc.target/riscv/zmmul-2.c -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects scan-assembler-times mul\t 1
PASS:
Snapshot gcc-10-20230524 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/10-20230524/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 10 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109959
--- Comment #3 from Andrew Pinski ---
here is another related testcase but this was the exactly reduced one from
bitmap_single_bit_set_p :
```
_Bool f(unsigned a, int t)
{
void g(void);
if (t)
return 0;
g();
if (a > 1)
return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109959
--- Comment #2 from Andrew Pinski ---
I should note I found this while looking at code generation of
bitmap_single_bit_set_p after a match pattern addition.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109959
Andrew Pinski changed:
What|Removed |Added
Summary|`(a > 1) ? 0 : (a == 1)` is |`(a > 1) ? 0 : (a == 1)` is
On 5/24/23 13:34, Thomas Schwinge wrote:
Yeah, at this point I'm not sure whether my recent changes really are
related/relevant here.
Apparently in addition to Kito's patch below, If I comment out the
additional torture options, failures go down drastically.
Meaning that *all* those ERRORs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109959
Bug ID: 109959
Summary: `(a > 1) ? 0 : (a == 1)` is not optimized when spelled
out
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109956
--- Comment #7 from joseph at codesourcery dot com ---
I suppose the question is how to interpret "the longest array (with the
same element type) that would not make the structure larger than the
object being accessed". The difficulty of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109956
--- Comment #6 from joseph at codesourcery dot com ---
For the standard, dynamically allocated case, you should only need to
allocate enough memory to contain the initial part of the struct and the
array members being accessed - not any
By having an ssa_cache inherit from a range_query, and then providing a
range_of_expr routine which returns the current global value, we open up
the possibility of folding statements and doing other interesting things
with an ssa-cache.
In particular, you can now call fold_range() with an
This patch provide the framework for a gimple-range phi analyzer.
Currently, the primary purpose is to give better initial values for
members of a "phi group"
a PHI group is defined as a a group of PHI nodes whose arguments are all
either members of the same PHI group, or one of 2 other
This tweaks someof the fold_stmt routines and helpers.. in particular
the ones which you provide a vector of ranges to to satisfy any ssa-names.
Previously, once the vector was depleted, any remaining values were
picked up from the default get_global_range_query() query. It is useful
to be
I originally implemented the lazy ssa cache by inheriting from an
ssa_cache in protected mode and providing the required routines. This
makes it a little awkward to do various things, and they also become not
quite as interchangeable as I'd like. Making the routines virtual and
using proper
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107986
--- Comment #9 from CVS Commits ---
The master branch has been updated by Andrew Macleod :
https://gcc.gnu.org/g:1cd5bc387c453126fdb4c9400096180484ecddee
commit r14-1179-g1cd5bc387c453126fdb4c9400096180484ecddee
Author: Andrew MacLeod
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107822
--- Comment #6 from CVS Commits ---
The master branch has been updated by Andrew Macleod :
https://gcc.gnu.org/g:1cd5bc387c453126fdb4c9400096180484ecddee
commit r14-1179-g1cd5bc387c453126fdb4c9400096180484ecddee
Author: Andrew MacLeod
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109947
Martin Seemann changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
On Tue, 2023-05-23 at 09:34 +, Christophe Lyon wrote:
> The gcc.dg/analyzer/data-model-4.c and
> gcc.dg/analyzer/torture/conftest-1.c fail with recent glibc headers
> and succeed with older headers.
>
> The new error message is:
> warning: use of possibly-NULL 'f' where non-null expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90504
--- Comment #1 from anlauf at gcc dot gnu.org ---
(In reply to Janne Blomqvist from comment #0)
> Hanson, Hopkins, Remark on Algorithm 539: A Modern Fortran Reference
> Implementation for Carefully Computing the Euclidean Norm,
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87270
--- Comment #6 from anlauf at gcc dot gnu.org ---
All current compilers seem to give the same, apparently correct result,
even with different optimization level.
So can we close this finally?
Hi!
On 2023-05-24T11:18:35-0700, Vineet Gupta wrote:
> On 5/22/23 20:52, Vineet Gupta wrote:
>> On 5/22/23 02:17, Kito Cheng wrote:
>>> Ooops, seems still some issue around here,
>>
>> Yep still 5000 fails :-(
>>
>>> but I found something might
>>> related this issue:
>>>
>>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109876
--- Comment #9 from Jason Merrill ---
(In reply to Marek Polacek from comment #8)
> > Instead, we should probably treat num as value-dependent even though it
> > actually isn't.
>
> An attempt to implement that:
>
> --- a/gcc/cp/pt.cc
> +++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109956
--- Comment #5 from Martin Uecker ---
Clang bug:
https://github.com/llvm/llvm-project/issues/62929
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109947
--- Comment #4 from Jonathan Wakely ---
(In reply to Martin Seemann from comment #3)
> So it comes down to how to interpret the "Effects:" clause: Does "Equivalent
> to " mean that all restrictions of
> `value()` apply transitively or is it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109876
--- Comment #8 from Marek Polacek ---
> Instead, we should probably treat num as value-dependent even though it
> actually isn't.
An attempt to implement that:
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -27969,6 +27969,12 @@
On Wed, May 24, 2023 at 5:00 AM Jonathan Wakely via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:
> On Wed, 24 May 2023 at 09:41, Xi Ruoyao wrote:
>
> > Wang Lei raised some concerns about Itanium C++ ABI, so let's ask a C++
> > expert here...
> >
> > Jonathan: AFAIK the standard and the Itanium
I'll look at the samples tomorrow, but just to address one thing:
钟居哲 writes:
>>> What gives the best code in these cases? Is emitting a multiplication
>>> better? Or is using a new IV better?
> Could you give me more detail information about "new refresh IV" approach.
> I'd like to try that.
Prathamesh Kulkarni writes:
> On Wed, 24 May 2023 at 15:40, Richard Sandiford
> wrote:
>>
>> Prathamesh Kulkarni writes:
>> > On Mon, 22 May 2023 at 14:18, Richard Sandiford
>> > wrote:
>> >>
>> >> Prathamesh Kulkarni writes:
>> >> > Hi Richard,
>> >> > Thanks for the suggestions. Does the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104350
--- Comment #4 from CVS Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:ec2e86274427a402d2de2199ba550f7295ea9b5f
commit r14-1175-gec2e86274427a402d2de2199ba550f7295ea9b5f
Author: Harald Anlauf
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103794
--- Comment #3 from CVS Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:5fd5d8fb744fd9251d04e4b17d04f2340e6a283b
commit r14-1174-g5fd5d8fb744fd9251d04e4b17d04f2340e6a283b
Author: Harald Anlauf
Date:
On Wed, 24 May 2023 at 15:40, Richard Sandiford
wrote:
>
> Prathamesh Kulkarni writes:
> > On Mon, 22 May 2023 at 14:18, Richard Sandiford
> > wrote:
> >>
> >> Prathamesh Kulkarni writes:
> >> > Hi Richard,
> >> > Thanks for the suggestions. Does the attached patch look OK ?
> >> >
Le 21/05/2023 à 22:48, Harald Anlauf via Fortran a écrit :
Dear all,
checking and simplification of the RESHAPE intrinsic could fail in
various ways for sufficiently complicated arguments, like array
constructors. Debugging revealed that in these cases we determined
that the array arguments
Le 24/05/2023 à 21:16, Harald Anlauf via Fortran a écrit :
Dear all,
the attached almost obvious patch fixes an ICE on invalid that may
occur when we attempt to simplify an initialization expression with
SIZE for an out-of-range DIM argument. Returning gfc_bad_expr
allows for a more graceful
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109261
--- Comment #13 from CVS Commits ---
The releases/gcc-12 branch has been updated by Matthias Kretz
:
https://gcc.gnu.org/g:2b502c3119c91fe3ba2313f0842a3bedd395bc91
commit r12-9651-g2b502c3119c91fe3ba2313f0842a3bedd395bc91
Author: Matthias
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109949
--- Comment #10 from CVS Commits ---
The releases/gcc-12 branch has been updated by Matthias Kretz
:
https://gcc.gnu.org/g:ff7360dafe209b960535eaaa3efcfbaaa44daff9
commit r12-9652-gff7360dafe209b960535eaaa3efcfbaaa44daff9
Author: Matthias
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109261
--- Comment #12 from CVS Commits ---
The releases/gcc-12 branch has been updated by Matthias Kretz
:
https://gcc.gnu.org/g:8be71168f7bbafa04f592a7524432351ffea71ba
commit r12-9650-g8be71168f7bbafa04f592a7524432351ffea71ba
Author: Matthias
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109949
--- Comment #9 from CVS Commits ---
The master branch has been updated by Matthias Kretz :
https://gcc.gnu.org/g:efd2b55d8562c6e80cb7ee8b9b1f9418f0c00cd9
commit r14-1173-gefd2b55d8562c6e80cb7ee8b9b1f9418f0c00cd9
Author: Matthias Kretz
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109947
--- Comment #3 from Martin Seemann ---
Thanks for pointing me to the LWG issue. It makes sense that the error type
must be copyable for the `value()` overloads due to potentially throwing a
`bad_expected_access` with the embedded error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109956
--- Comment #4 from Martin Uecker ---
The concern would be that a program relying on the size of an object being
larger may then have out of bounds accesses. But rereading the standard, I am
also not not seeing that this is required. (for the
Hi Lipeng,
May I know any comment or concern on this patch, thanks for your time
Thanks for your patience in getting this reviewed.
A few remarks / questions.
Which strategy is used in this implementation, read-preferring or
write-preferring? And if read-preferring is used, is there
a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104350
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Dear all,
the attached almost obvious patch fixes an ICE on invalid that may
occur when we attempt to simplify an initialization expression with
SIZE for an out-of-range DIM argument. Returning gfc_bad_expr
allows for a more graceful error recovery.
Regtested on x86_64-pc-linux-gnu. OK for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101188
--- Comment #6 from Georg-Johann Lay ---
Created attachment 55152
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55152=edit
diff testcase by v4.9.2 vs v5.2.1
Code from v4.9.2 is correct, but from v5.2.1 is bogus:
--- fail1-4.9.2.sx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109958
Marek Polacek changed:
What|Removed |Added
Keywords||ice-on-valid-code
Middle-end folks: any thoughts about how best to make the change described in
the last paragraph below?
Library folks: any thoughts on the changes to __cxa_call_terminate?
-- 8< --
[except.handle]/7 says that when we enter std::terminate due to a throw,
that is considered an active handler. We
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109958
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109958
Bug ID: 109958
Summary: ICE: in build_ptrmem_type, at cp/decl.cc:11066 taking
the address of bound static member function brought
into derived class by using-declaration
gcc/ChangeLog:
* value-range.h (vrange::kind): Remove.
---
gcc/value-range.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/gcc/value-range.h b/gcc/value-range.h
index 936eb175062..b8cc2a0e76a 100644
--- a/gcc/value-range.h
+++ b/gcc/value-range.h
@@ -100,9 +100,6 @@ public:
1 - 100 of 330 matches
Mail list logo
