https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117981
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59389
--- Comment #9 from Sergey Fedorov ---
(In reply to Andrew Pinski from comment #7)
> (In reply to Sergey Fedorov from comment #6)
> > I am getting a similar-looking error with gcc-13.2.0 now:
> > https://github.com/NGSolve/ngsolve/issues/68
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117765
Sam James changed:
What|Removed |Added
Target Milestone|--- |15.0
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117820
Sam James changed:
What|Removed |Added
Target Milestone|--- |14.3
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117974
--- Comment #7 from JuzheZhong ---
(In reply to Vineet Gupta from comment #4)
> (In reply to JuzheZhong from comment #2)
> > We need to split all insns since some of them are not the ultimate RVV
> > instruction pattern that depend on VL/VTYPE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59389
--- Comment #10 from Sam James ---
If in doubt, in general, it's better to file it separately.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117991
Sam James changed:
What|Removed |Added
Summary|[15] RISC-V:|[15 regression] RISC-V:
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117990
--- Comment #4 from Li Pan ---
Another example to reproduce this.
1 │ #define STEP 10
2 │
3 │ char d[225];
4 │ int e[STEP];
5 │
6 │ int main() {
7 │ for (long h = 0; h < STEP; ++h)
8 │ d[h * STEP] =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117992
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117992
Andrew Pinski changed:
What|Removed |Added
Depends on||117739
--- Comment #3 from Andrew Pinsk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117974
--- Comment #8 from Vineet Gupta ---
(In reply to JuzheZhong from comment #7)
> I think Phase 3 early fusion should handle this scenario.
It is handling this, except that it fusing the 2nd into 1st which happens to be
before the BEQ, hence this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117990
--- Comment #5 from Li Pan ---
The tree optimized looks right up to a point.
5 │ int main ()
6 │ {
7 │ vector(8) int vect__4.8;
8 │ vector(8) char vect__3.7;
9 │ vector(8) char D.2823;
10 │ int _5;
11 │
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117983
Richard Biener changed:
What|Removed |Added
Keywords||diagnostic
Summary|[13.2 re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109517
--- Comment #3 from Jonathan Wakely ---
Patch to solve this in the library as a workaround for the FE bug:
https://gcc.gnu.org/pipermail/gcc-patches/2024-December/671343.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109976
--- Comment #3 from Jonathan Wakely ---
Patch to solve this in the library as a workaround for the FE bug:
https://gcc.gnu.org/pipermail/gcc-patches/2024-December/671343.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117985
Bug ID: 117985
Summary: ICE in gimplify_var_or_parm_decl, at gimplify.cc:3308
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117984
Bug ID: 117984
Summary: missed IPA constant propagation
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
As
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87604
Jonathan Wakely changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103827
--- Comment #17 from Jason Merrill ---
(In reply to Jan Hubicka from comment #16)
> We are not too good on using const on automatic variables and static
> ones with constructors since they become effectively const only when
> they are constructe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117987
Bug ID: 117987
Summary: Function multiversioning does not respect decl asms
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117956
Eric Botcazou changed:
What|Removed |Added
Summary|Assert failure in |assertion failure in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117880
--- Comment #2 from GCC Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:d26c166001d6a5bdfd94be6e6d17135669ed340b
commit r15-6089-gd26c166001d6a5bdfd94be6e6d17135669ed340b
Author: Marek Polacek
Date: Mo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117880
Marek Polacek changed:
What|Removed |Added
Summary|[14/15 Regression] ICE with |[14 Regression] ICE with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117819
--- Comment #3 from GCC Commits ---
The master branch has been updated by Jerry DeLisle :
https://gcc.gnu.org/g:cf406a6c79ce404c45f99bcf2df3293269dbb462
commit r15-6090-gcf406a6c79ce404c45f99bcf2df3293269dbb462
Author: Jerry DeLisle
Date: M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117988
Bug ID: 117988
Summary: Logical locations for sarif-replay errors
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117989
Bug ID: 117989
Summary: aarch64: FMV attaches symvers to the wrong decl
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117985
--- Comment #3 from Marek Polacek ---
Also add this (making ~_Vector_base constexpr): it seems to have some effect
(g++12 crashes with this but not with #c2):
```
// PR c++/117985
struct _Vector_impl {
constexpr _Vector_impl() {}
};
struct _
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117980
--- Comment #7 from Marek Polacek ---
Candidate fix:
--- a/gcc/cp/cp-gimplify.cc
+++ b/gcc/cp/cp-gimplify.cc
@@ -1477,7 +1477,7 @@ cp_fold_r (tree *stmt_p, int *walk_subtrees, void *data_)
*walk_subtrees = 0;
if (!flag_no_inline)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117120
Gaius Mulley changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117120
--- Comment #2 from GCC Commits ---
The master branch has been updated by Gaius Mulley :
https://gcc.gnu.org/g:e0ab8816ea53e2a343f7e945f4718172bff5ce95
commit r15-6093-ge0ab8816ea53e2a343f7e945f4718172bff5ce95
Author: Gaius Mulley
Date: Tue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117990
--- Comment #1 from Patrick O'Neill ---
-flto can be replaced with -fwhole-program:
-march=rv64gcv_zvl256b -fwhole-program -O3 -mrvv-vector-bits=zvl test.c -o
user-config.out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117974
--- Comment #4 from Vineet Gupta ---
(In reply to JuzheZhong from comment #2)
> We need to split all insns since some of them are not the ultimate RVV
> instruction pattern that depend on VL/VTYPE.
> And I don't think the vsetvli should be keep
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117643
kargls at comcast dot net changed:
What|Removed |Added
Attachment #59617|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117248
--- Comment #20 from John David Anglin ---
It appears I again forgot to add -mlra to the compile command.
The problem is clear in the generated assembly code:
extrs %r5,31,16,%r26
extrs %r24,31,16,%r7
copy %r7,%r25
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117722
--- Comment #14 from Vineet Gupta ---
(In reply to Li Pan from comment #7)
> Created attachment 59661 [details]
> with usad pattern
Can you please post the patch, lest we duplicate your effort.
It would be nice to test it on real hardware.
@Ro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117974
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117888
--- Comment #5 from GCC Commits ---
The master branch has been updated by hongtao Liu :
https://gcc.gnu.org/g:ee2f19b0937b5efc0b23c4319cbd4a38b27eac6e
commit r15-6097-gee2f19b0937b5efc0b23c4319cbd4a38b27eac6e
Author: liuhongt
Date: Mon Dec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117888
Hongtao Liu changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117874
--- Comment #11 from Hongtao Liu ---
(In reply to Richard Biener from comment #10)
> The mult_su3_an part is now resolved. See PR117888 for the rest.
Fixed by r15-6097-gee2f19b0937b5efc0b23c4319cbd4a38b27eac6e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117914
Georg-Johann Lay changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117944
--- Comment #1 from GCC Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:f102b82d3da6dd4d5f9af1cd622fce93d0c494eb
commit r15-6095-gf102b82d3da6dd4d5f9af1cd622fce93d0c494eb
Author: David Malcolm
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117944
David Malcolm changed:
What|Removed |Added
Version|unknown |15.0
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117980
--- Comment #8 from Jonathan Wakely ---
Thanks, that seems to fix the library failures in debug mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117992
Bug ID: 117992
Summary: gcc -flto -fharden leads to warning
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: driver
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117992
--- Comment #1 from Icenowy Zheng ---
BTW adding `-Wno-hardened` cannot suppress this warning.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117248
--- Comment #21 from John David Anglin ---
Created attachment 59829
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59829&action=edit
Reload RTL dump
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117722
--- Comment #15 from Robin Dapp ---
(In reply to Vineet Gupta from comment #14)
> (In reply to Li Pan from comment #7)
> > Created attachment 59661 [details]
> > with usad pattern
>
> Can you please post the patch, lest we duplicate your effort
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112092
--- Comment #16 from Maciej W. Rozycki ---
As I say GCC doesn't know the inline asm makes use of the vector unit, so
the compiler is free to make any optimisations that it can see fit based
on vector code it has produced itself. Actually in thi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117983
Andrew Pinski changed:
What|Removed |Added
Known to work|15.0|
--- Comment #1 from Andrew Pinski ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117982
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-12-11
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117991
Bug ID: 117991
Summary: [15] RISC-V:
g++/template/builtin-speculation-overloads[14].C
assertion error
Product: gcc
Version: 15.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117722
--- Comment #17 from Li Pan ---
(In reply to Vineet Gupta from comment #14)
> (In reply to Li Pan from comment #7)
> > Created attachment 59661 [details]
> > with usad pattern
>
> Can you please post the patch, lest we duplicate your effort.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117974
--- Comment #6 from Vineet Gupta ---
(In reply to Jeffrey A. Law from comment #5)
> What's starting to rattle around in my brain is the for a loop, if the count
> is unknown, then we probably don't want to unroll as that's much more likely
> to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117722
--- Comment #16 from Vineet Gupta ---
(In reply to Robin Dapp from comment #15)
> (In reply to Vineet Gupta from comment #14)
> > @Robin, it seems the current codegen generates 2 widening ops, which might
> > not be as efficient. We have done s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117820
Jerry DeLisle changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117765
Jerry DeLisle changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117993
--- Comment #4 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #3)
> I suspect for some reason we think the current instantiation does not have a
> dependent base for some reason.
That is any_dependent_bases_p is returning false
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117993
--- Comment #3 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #2)
> Confirmed. Fails with 20240727 but worked with 20240710 .
I suspect r15-2117-g313afcfdabeab3 (which is in the time frame).
```
and
qualified look
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117993
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-12-11
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117964
--- Comment #7 from Segher Boessenkool ---
When maybe_duplicate_computed_goto is asked to duplicate a block with 9189
successors, it damn well should! If that is a bad idea for the case at hand,
just do not call maybe_duplicate_computed_goto on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117983
Bug ID: 117983
Summary: [13.2 regression] -Wstringop-overflow false positive
for __builtin_memmove from vector::insert
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117978
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117965
--- Comment #12 from Richard Biener ---
In fact I wonder how the code would support any case where the VUSE on the
later load isn't the same as the VUSE on the first load.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103827
--- Comment #15 from Jason Merrill ---
(In reply to Jason Merrill from comment #14)
> Note that this is the same for non-parameter local variables
Just want to emphasize this point: this property is in no way specific to
parameters, it applies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117970
Richard Biener changed:
What|Removed |Added
Target||riscv
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117973
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |15.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117980
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117961
--- Comment #8 from Georg-Johann Lay ---
(In reply to ak from comment #7)
> i suppose scan-assembler could just ignore lines starting with #
I don't think that's the correct solution. Better ignore lines with
ASM_COMMENT_START, which may or ma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117980
--- Comment #5 from Jonathan Wakely ---
Testing with RUNTESTFLAGS=--target_board=unix/-D_GLIBCXX_DEBUG shows some new
fails due to this ICE:
FAIL: 25_algorithms/lexicographical_compare/95578.cc -std=gnu++20 (test for
excess errors)
FAIL: 25_al
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103827
--- Comment #16 from Jan Hubicka ---
> > Note that this is the same for non-parameter local variables
>
> Just want to emphasize this point: this property is in no way specific to
> parameters, it applies to any object created as const. If som
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117985
Marek Polacek changed:
What|Removed |Added
Keywords|needs-reduction |
--- Comment #2 from Marek Polacek ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86590
--- Comment #40 from Jan Hubicka ---
As discussed with Jason, problem with _M_create not seen by middle-end is
actually due to C++ standard. Explicit instantiations prevents implicit ones
for non-inline functions, see discussion in PR39242. With
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80331
--- Comment #13 from Jan Hubicka ---
As discussed with Jason, problem with _M_create not seen by middle-end is
actually due to C++ standard. Explicit instantiations prevents implicit ones
for non-inline functions, see discussion in PR39242. With
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117875
--- Comment #12 from Jan Hubicka ---
I tried final_value_replacement_loop on simplified testcase where second loop
has known number of iterations:
void foo(int *a, int *b, int n)
{
if (n > 3 && n < 10)
for (int i = 0; i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117675
--- Comment #5 from GCC Commits ---
The master branch has been updated by Wilco Dijkstra :
https://gcc.gnu.org/g:21fbfae2e55e1a153820acc6fbd922e66f67e65b
commit r15-6088-g21fbfae2e55e1a153820acc6fbd922e66f67e65b
Author: Wilco Dijkstra
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117985
Marek Polacek changed:
What|Removed |Added
Target Milestone|--- |12.5
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117986
Bug ID: 117986
Summary: templated auto parameter with lambda as default value
can result in duplicate symbols
Product: gcc
Version: 11.4.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117961
ak at gcc dot gnu.org changed:
What|Removed |Added
CC||ak at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88545
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117981
--- Comment #2 from Joseph S. Myers ---
The use of standard versions in the option names is deliberate. An option to
warn about any version incompatibilities would become like -Wtraditional, less
and less useful over time. If your code is known
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117981
Sam James changed:
What|Removed |Added
CC||sjames at gcc dot gnu.org
--- Comment #3 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103827
--- Comment #11 from Jan Hubicka ---
I see, I misread Jonathan's answer. If const is relevant only on definition,
what about this one:
#include
struct foo
{
int a;
void bar() const;
~foo()
{
if (a != 42)
printf ("optimize me
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80331
--- Comment #14 from Jan Hubicka ---
Declaring _S_create and _M_create inline indeed helps a little:
diff --git a/libstdc++-v3/include/bits/basic_string.h
b/libstdc++-v3/include/bits/basic_string.h
index 17b973c8b45..d73a61abe5b 100644
--- a/lib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117946
--- Comment #12 from GCC Commits ---
The master branch has been updated by Vladimir Makarov :
https://gcc.gnu.org/g:6fc3da8fa2af1d4ee154ea803636eabde358b553
commit r15-6091-g6fc3da8fa2af1d4ee154ea803636eabde358b553
Author: Vladimir N. Makarov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82469
--- Comment #6 from Heiko Eißfeldt ---
Still ICEs on ARM64 11.1.0 - trunk.
https://godbolt.org/z/bKEeqz613
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117965
--- Comment #9 from Richard Biener ---
(In reply to Andrew Pinski from comment #8)
> I am suspecting this comes from a benchmark, do you have the name of the
> benchmark?
Nope, it got reported to me with just exactly this testcase ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117964
--- Comment #6 from Richard Biener ---
In principle I'd place the duplication at a point in the pass pipeline where we
do _not_ need the outgoing edges at all (we're already adding a BARRIER!).
Which likely means no accurate dataflow. Possibly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117961
--- Comment #6 from Georg-Johann Lay ---
So how do you get the absolute path into the assembly?
Via .file there is the name of the test case, but as far as I can see, .file
doesn't show the whole absolute path to the test case.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117788
--- Comment #5 from GCC Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:c628def52c87b40b6270618252488bcd731e1843
commit r15-6083-gc628def52c87b40b6270618252488bcd731e1843
Author: Marek Polacek
Date: We
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117973
--- Comment #2 from Hans-Peter Nilsson ---
I forgot to mark r15-6081-g0703e7491e06c0 with this PR: it's an xfailed test
that compiles gcc.dg/tree-ssa/pr111456-1.c with --param
logical-op-non-short-circuit=0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117788
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110338
Bug 110338 depends on bug 117788, which changed state.
Bug 117788 Summary: [C++26] P2865R5 - Removing deprecated array comparisons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117788
What|Removed |Added
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103827
Jason Merrill changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117248
--- Comment #18 from Vladimir Makarov ---
(In reply to John David Anglin from comment #16)
> Things are improved but a similar error occurs in the second umod:SI
> call in /testsuite/gcc.c-torture/execute/arith-rand-ll.c:
>
>
> (insn 341 339 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117965
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117248
--- Comment #19 from John David Anglin ---
Created attachment 59828
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59828&action=edit
Preprocessed source for arith-rand-ll.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117643
--- Comment #3 from kargls at comcast dot net ---
Created attachment 59827
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59827&action=edit
Testcase for f_c_string
The attached testcase has a number of tests currently commented out.
Those
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117970
--- Comment #4 from Edwin Lu ---
(In reply to Lewis Hyatt from comment #2)
> Thanks, I will see what I can find. Did you, by any chance, run the tests
> before/after r15-6016 in the same build directory? I think this error would
> make sense to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66892
Jonathan Wakely changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |3y3p4tch at protonmail
dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103827
--- Comment #12 from Jonathan Wakely ---
Yes, that object is defined const so can't be changed. But is this something we
care about? Is it important to apply this optimization to noinline functions?
1 - 100 of 130 matches
Mail list logo
