> Am 25.09.2023 um 04:53 schrieb Hanke Zhang via Gcc :
>
> Hi, I have recently been working on loops in gcc, and I have some
> questions about the loop traversal.
>
> I use loops_list(cfun, LI_ONLY_INNERMOST) to traverse the loops in my
> pass to obtain the loop.
>
> I found that the order
> Am 24.09.2023 um 17:24 schrieb Andrew Pinski :
>
> The issue here is that when backprop tries to go
> and strip sign ops, it skips over ABSU_EXPR but
> ABSU_EXPR not only does an ABS, it also changes the
> type to unsigned.
> Since strip_sign_op_1 is only supposed to strip off
> sign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111366
--- Comment #19 from CVS Commits ---
The master branch has been updated by Kewen Lin :
https://gcc.gnu.org/g:a65b38e361320e0aa45adbc969c704385ab1f45b
commit r14-4247-ga65b38e361320e0aa45adbc969c704385ab1f45b
Author: Kewen Lin
Date: Mon Sep
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111380
--- Comment #1 from CVS Commits ---
The master branch has been updated by Kewen Lin :
https://gcc.gnu.org/g:266dfed68b881702e9660889f63408054b7fa9c0
commit r14-4246-g266dfed68b881702e9660889f63408054b7fa9c0
Author: Kewen Lin
Date: Mon Sep
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111581
Bug ID: 111581
Summary: [arm-none-eabi-gcc] / suboptimal optimization /
Product: gcc
Version: 9.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111580
Bug ID: 111580
Summary: [arm-none-eabi-gcc] / suboptimal optimization / b.n to
bx lr
Product: gcc
Version: 9.3.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111500
--- Comment #4 from Luke ---
the a.i file for example #1a is:
# 1 "a.c"
# 1 "/tmp//"
# 1 ""
# 1 ""
# 1 "a.c"
void artiSUBS() {
for (int i=100; i>0; i--)
*(volatile int*)0xE000E014 = i;
}
the command-line was:
> arm-none-eabi-gcc -save-temps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111500
--- Comment #3 from Luke ---
maybe i should also say the "-v" output?
> arm-none-eabi-gcc -v
Using built-in specs.
COLLECT_GCC=arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-none-eabi/9.3.0/lto-wrapper
Target: arm-none-eabi
Configured
Hi, I have recently been working on loops in gcc, and I have some
questions about the loop traversal.
I use loops_list(cfun, LI_ONLY_INNERMOST) to traverse the loops in my
pass to obtain the loop.
I found that the order of traversal and the order of actual
instruction execution will be
Thanks for your advice! I will check it out and submit a new version of
patch.
On Sun, 2023-09-24 at 18:05 +0800, Xi Ruoyao wrote:
> On Wed, 2023-09-20 at 09:15 +0800, Chenghui Pan wrote:
> > LoongArch failed to pass gcc.dg/pr104992.c with -mlsx and -mlasx.
> > This test uses
> > different
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111579
Bug ID: 111579
Summary: gnatpp error at start
Product: gcc
Version: 11.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
Assignee:
Pushed to r14-4245.
在 2023/9/21 上午9:19, Guo Jie 写道:
gcc/ChangeLog:
* config/loongarch/lasx.md (lasx_vecinit_merge_): New
pattern for vector construction.
(vec_set_internal): Ditto.
(lasx_xvinsgr2vr__internal): Ditto.
(lasx_xvilvl__internal): Ditto.
Hi,
This patch implements 32bit inline lrint by "fctiw". It depends on
the patch1 to do SImode move from FP registers on P7.
Compared to last version, the main change is to add some test cases.
https://gcc.gnu.org/pipermail/gcc-patches/2023-September/629187.html
Bootstrapped and tested on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111578
Bug ID: 111578
Summary: GNAT ada.textio.setline gives incorrect result
Product: gcc
Version: 11.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
On Fri, Sep 22, 2023 at 6:56 PM Hongyu Wang wrote:
>
> Hi,
>
> This is a v2 patch for APX support which follows-up previous discussion in
> https://gcc.gnu.org/pipermail/gcc-patches/2023-August/628904.html
>
> As discussed in previous thread, the inverse approach to extend base/index reg
>
Hi Kewen,
在 2023/9/18 15:34, Kewen.Lin 写道:
> hanks for checking! So for P7, this patch looks neutral, but for P8 and
> later, it may cause some few differences in code gen. I'm curious that how
> many total object files and different object files were checked and found
> on P8?
P8 with -O2,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111533
xuli1 at eswincomputing dot com changed:
What|Removed |Added
CC||xuli1 at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111576
--- Comment #5 from Paul Eggert ---
(In reply to Andrew Pinski from comment #4)
> >111715
>
> That is not a valid bug # either.
Sorry, I meant Bug 111575.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111577
--- Comment #2 from Andrew Pinski ---
I suspect you forgot to count the other functions which get emitted here. And
you are just counting the size of main but that is wrong really.
Anyways the overall size of the executable's text section is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111577
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111577
Bug ID: 111577
Summary: -Os gives significantly bigger code than -O0
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111285
--- Comment #3 from Andrew Pinski ---
Created attachment 55985
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55985=edit
Patch which fixes the issue
I am not sure this is the best patch but we don't pass down 2 inner types into
do_unop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110386
Andrew Pinski changed:
What|Removed |Added
Keywords||patch
URL|
Snapshot gcc-14-20230924 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/14-20230924/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 14 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111576
--- Comment #4 from Andrew Pinski ---
>111715
That is not a valid bug # either.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79045
Andrew Pinski changed:
What|Removed |Added
CC||eggert at cs dot ucla.edu
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111576
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111576
Andrew Pinski changed:
What|Removed |Added
Component|tree-optimization |middle-end
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111434
Eric Botcazou changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111576
--- Comment #1 from Paul Eggert ---
Created attachment 55984
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55984=edit
Generated assembly language for the program
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111576
Bug ID: 111576
Summary: gcc generates conditional branch for bitwise "&"
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111434
Eric Botcazou changed:
What|Removed |Added
Last reconfirmed||2023-09-24
Summary|Infinite
gcc/ChangeLog:
* config.gcc: add loongarch-d.o to d_target_objs for LoongArch
architecture.
gcc/config/ChangeLog:
* loongarch/loongarch-d.cc
(loongarch_d_target_versions): add interface function to define builtin
D versions for LoongArch architecture.
This patch adds the LoongArch64 support for GCC D frontend.
The runtime support is submitted as a separate patch here:
https://github.com/dlang/dmd/pull/15628.
You can find more information about the LoongArch architecture on this
website:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111433
Eric Botcazou changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
Ever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111528
--- Comment #3 from Richard Sandiford ---
This was the problem that g:10d59b802a7db9ae908291fb20627c1493cfa26c fixed. I
wasn't sure it was worth backporting because it only triggers for out-of-bounds
array accesses, or uninitialised Fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111575
Bug ID: 111575
Summary: -Wbool-operation mistakenly warns about an int
operation
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111569
Hans-Jürgen Herbert changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Comment #3 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111556
--- Comment #3 from Silvio Traversaro ---
Thanks for the quick reply! I imagined something like that, but I preferred
anyhow to have a clear bug on the libgomp so that I can refer to it and for
other people that could encounter this behavior.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111574
--- Comment #6 from Andrew Pinski ---
What is happening is:
```
if (_1 != 0)
goto ; [INV]
else
goto ; [INV]
:
_28 = (uint8_t) _1;
// predicted unlikely by early return (on trees) predictor.
goto ; [INV]
:
_7 =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111469
Andrew Pinski changed:
What|Removed |Added
CC||19373742 at buaa dot edu.cn
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111574
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111574
Andrew Pinski changed:
What|Removed |Added
CC||pinskia at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99631
--- Comment #14 from danakj at orodu dot net ---
Thank you =)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88610
Eric Botcazou changed:
What|Removed |Added
Status|SUSPENDED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491
Bug 67491 depends on bug 108736, which changed state.
Bug 108736 Summary: [concepts] multidimensional subscript operator inside
requires with variable template arguments is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108736
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108736
Patrick Palka changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111493
Patrick Palka changed:
What|Removed |Added
CC||ldalessandro at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111493
Patrick Palka changed:
What|Removed |Added
Target Milestone|--- |13.3
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99631
Patrick Palka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111493
--- Comment #4 from CVS Commits ---
The releases/gcc-13 branch has been updated by Patrick Palka
:
https://gcc.gnu.org/g:40d2dec34b58c3c31b1c731049a914204ec252c3
commit r13-7837-g40d2dec34b58c3c31b1c731049a914204ec252c3
Author: Patrick Palka
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111485
--- Comment #3 from CVS Commits ---
The releases/gcc-13 branch has been updated by Patrick Palka
:
https://gcc.gnu.org/g:59f5786c20a42be13ac6fec567ffe840045012ad
commit r13-7836-g59f5786c20a42be13ac6fec567ffe840045012ad
Author: Patrick Palka
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99631
--- Comment #12 from CVS Commits ---
The releases/gcc-13 branch has been updated by Patrick Palka
:
https://gcc.gnu.org/g:b9e02590f7d35f1f8e8e95ab1f2e30f24113f551
commit r13-7835-gb9e02590f7d35f1f8e8e95ab1f2e30f24113f551
Author: Patrick Palka
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111574
--- Comment #3 from CTC <19373742 at buaa dot edu.cn> ---
Created attachment 55982
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55982=edit
The compiler output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111574
--- Comment #2 from CTC <19373742 at buaa dot edu.cn> ---
Created attachment 55981
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55981=edit
The preprocessed file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111574
--- Comment #1 from CTC <19373742 at buaa dot edu.cn> ---
***
OS and Platform:
Ubuntu 20.04.4 LTS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111574
Bug ID: 111574
Summary: Illegal instruction with
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111569
--- Comment #2 from Andrew Pinski ---
You would have caught the bad code if in your compile.sh script you added:
```
set -e
```
As that would error out if one of the programs exit with a non-zero return code
which gcc does on an error.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111571
Andrew Pinski changed:
What|Removed |Added
Keywords||ice-on-valid-code
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111572
--- Comment #3 from Andrew Pinski ---
Self contained testcase:
```
void gg(void)
{
static int t = 0;
if (t != 0) __builtin_abort();
t++;
}
int a, b = -8, e, f, h;
char c, d, g;
static int i(long k) {
e = 8;
for (;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111572
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-09-24
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111572
--- Comment #1 from Andrew Pinski ---
__builtin_printf ("%u\n", _79);
__builtin_unreachable ();
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111563
--- Comment #4 from Yi <652023330028 at smail dot nju.edu.cn> ---
(In reply to Andrew Pinski from comment #3)
> (In reply to Yi from comment #2)
> > (In reply to Andrew Pinski from comment #1)
> > > _5 = var_0_16(D) + var_6_18(D);
> > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111563
--- Comment #3 from Andrew Pinski ---
(In reply to Yi from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > _5 = var_0_16(D) + var_6_18(D);
> > invariant up to level 1, cost 1.
> >
> > Basically because the cost is not high
The issue here is that when backprop tries to go
and strip sign ops, it skips over ABSU_EXPR but
ABSU_EXPR not only does an ABS, it also changes the
type to unsigned.
Since strip_sign_op_1 is only supposed to strip off
sign changing operands and not ones that change types,
removing ABSU_EXPR here
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111563
--- Comment #2 from Yi <652023330028 at smail dot nju.edu.cn> ---
(In reply to Andrew Pinski from comment #1)
> _5 = var_0_16(D) + var_6_18(D);
> invariant up to level 1, cost 1.
>
> Basically because the cost is not high enough ...
>
> If
On Sun, 24 Sept 2023 at 12:41, Alexander Monakov wrote:
>
>
> On Sun, 24 Sep 2023, Joern Rennecke wrote:
>
> > It is a stated goal of coremark to test performance for CRC.
>
> I would expect a good CRC benchmark to print CRC throughput in
> bytes per cycle or megabytes per second.
>
> I don't see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80757
Paul Thomas changed:
What|Removed |Added
CC||pault at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19276
Bug 19276 depends on bug 92586, which changed state.
Bug 92586 Summary: ICE in gimplify_expr, at gimplify.c:13479 with nested
allocatable derived types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92586
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92586
Paul Thomas changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92586
--- Comment #14 from CVS Commits ---
The releases/gcc-13 branch has been updated by Paul Thomas :
https://gcc.gnu.org/g:9eb2f102d38697011d3069fac759b7c6e149bed4
commit r13-7834-g9eb2f102d38697011d3069fac759b7c6e149bed4
Author: Paul Thomas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68155
Paul Thomas changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19276
Bug 19276 depends on bug 68155, which changed state.
Bug 68155 Summary: ICE on initializing character array in type (len_lhs <>
len_rhs)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68155
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68155
--- Comment #14 from CVS Commits ---
The releases/gcc-13 branch has been updated by Paul Thomas :
https://gcc.gnu.org/g:8c1925ece0193058120e94614e99360e9600777e
commit r13-7833-g8c1925ece0193058120e94614e99360e9600777e
Author: Paul Thomas
Hi all,
Sorry for sending the ping here, but gcc-patches seems to be completely
overwhelmed and my patch keeps getting buried
Cheers,
https://gcc.gnu.org/pipermail/gcc-patches/2023-August/627913.html
best regards,
Julian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108575
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111573
Bug ID: 111573
Summary: lambda functions often not inlined and optimized out
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111572
Bug ID: 111572
Summary: Wrong code at -O2 on x86_64-linux-gnu since
r14-301-gf2d6beb7a4d
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111571
Martin Jambor changed:
What|Removed |Added
Last reconfirmed||2023-09-24
Am Mittwoch, dem 26.07.2023 um 18:06 +0200 schrieb Martin Uecker:
>
> C programmers increasingly use static to indicate that
> pointer parameters are non-null. Clang can exploit this
> for warnings and optimizations. GCC has some warnings
> but not all warnings it has for nonnull. Below is a
>
This is a request for feedback and a proof-of-concept, not something I
intend to merge as-is. It would be nice if gcc, maybe just under some
circumstances, always generated an else-block for coverage purposes.
I am working on the MC/DC support by CFG analysis for a while
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104940
--- Comment #6 from David Malcolm ---
https://github.com/kristerw/pysmtgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111571
Bug ID: 111571
Summary: [13/14 Regression] ICE in modify_call, at
ipa-param-manipulation.cc:656
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104940
--- Comment #5 from David Malcolm ---
See also:
https://kristerw.github.io/2022/11/01/verifying-optimizations/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108575
--- Comment #8 from Nikos Tosis ---
We found the problem, the bug was in Embedded Ecoder from Mathworks.
So the Coder has generated wrong C Code.
Thank you all.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111569
Xi Ruoyao changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111570
Bug ID: 111570
Summary: -march=generic prints error
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: demangler
On Sun, 24 Sep 2023, Joern Rennecke wrote:
> It is a stated goal of coremark to test performance for CRC.
I would expect a good CRC benchmark to print CRC throughput in
bytes per cycle or megabytes per second.
I don't see where Coremark states that goal. In the readme at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111569
Bug ID: 111569
Summary: Problem finding in Library functions with parametres:
32, 8 , 32 Bits
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111550
--- Comment #3 from 康桓瑋 ---
Let me report another issue I observed on this PR.
According to [range.adaptor.object], adaptor(args...) uses
std::forward(args).. . to forward arguments into the call
wrapper's decayed member, whereas libstdc++
On Wed, 2023-09-20 at 09:15 +0800, Chenghui Pan wrote:
> LoongArch failed to pass gcc.dg/pr104992.c with -mlsx and -mlasx. This test
> uses
> different dg-final directives depending on the vect_int_mod result, LoongArch
> SX/ASX supports this operations but corresponding description is not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111568
Bug ID: 111568
Summary: std::not_fn can accept non-movable function
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111544
--- Comment #13 from Jonathan Wakely ---
But the code is "ill-formed, no diagnostic required" and GCC is now being more
helpful by diagnosing it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111544
--- Comment #12 from Jonathan Wakely ---
(In reply to Andrew Pinski from comment #10)
> So clang most likely thinks b.t and c->t are still type depedent even though
> they don't need to be ...
Which is fine. It's QoI whether non-dependent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111550
--- Comment #2 from 康桓瑋 ---
(In reply to Jonathan Wakely from comment #1)
> I think all four bugs related to adaptor closures are very similar and could
> be a single bug report.
Perhaps. Maybe I should collect them all. Sorry for bringing up
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111550
--- Comment #1 from Jonathan Wakely ---
I think all four bugs related to adaptor closures are very similar and could be
a single bug report.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111567
--- Comment #1 from David Malcolm ---
This PR tracks adding support for the attribute to -fanalyzer (which I can take
a look at).
Adding the attribute itself is tracked by PR 108896.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111559
Franz Sirl changed:
What|Removed |Added
CC||sirl at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111567
Bug ID: 111567
Summary: RFE: support counted_by in analyzer
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Committed, thanks Juzhe.
Pan
From: 钟居哲
Sent: Sunday, September 24, 2023 2:06 PM
To: Li, Pan2 ; gcc-patches
Cc: Li, Pan2 ; Wang, Yanzhang ;
kito.cheng ; patrick
Subject: Re: [PATCH v2] RISC-V: Fix fortran ICE/PR111546 when RV32 vec_init
LGTM
1 - 100 of 119 matches
Mail list logo
