https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102941
--- Comment #2 from Andrew Pinski ---
Here is a testcase which fails at all optimization levels (not DCEing out
stuff):
int test_cmpu_x;
long
test_cmpu_y() {
long le;
f(&le);
__asm__("cmp %"
"[x], %"
"[y]"
:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102941
Andrew Pinski changed:
What|Removed |Added
Summary|ICE in extract_insn, at |ICE in extract_insn with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102940
Martin Liška changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102857
Aldy Hernandez changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102941
Andrew Pinski changed:
What|Removed |Added
Target Milestone|12.0|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102941
Martin Liška changed:
What|Removed |Added
Target Milestone|--- |12.0
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102941
Bug ID: 102941
Summary: ICE in extract_insn, at recog.c:2769 with
-ftrivial-auto-var-init=pattern
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: ice-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101324
--- Comment #10 from Martin Liška ---
(In reply to Peter Bergner from comment #8)
> FYI, here's a smaller test case that still shows the issue with today's
> trunk:
>
> extern void foo (void);
> long int
> __attribute__ ((__optimize__ ("-fno-tr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102857
--- Comment #13 from CVS Commits ---
The master branch has been updated by Aldy Hernandez :
https://gcc.gnu.org/g:4e417eea8f3f14131f7370f9bd5dd568611d11df
commit r12-4701-g4e417eea8f3f14131f7370f9bd5dd568611d11df
Author: Aldy Hernandez
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102940
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |12.0
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102940
Bug ID: 102940
Summary: ICE: Segmentation fault (in gimple_bb)
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, openacc
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101324
Martin Liška changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #9 from Martin Lišk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102789
Kewen Lin changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102789
Kewen Lin changed:
What|Removed |Added
Component|target |tree-optimization
Status|ASSIGN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102789
--- Comment #7 from CVS Commits ---
The master branch has been updated by Kewen Lin :
https://gcc.gnu.org/g:f3dbd3f36d55178d0a9e4431043cbc950524969a
commit r12-4697-gf3dbd3f36d55178d0a9e4431043cbc950524969a
Author: Kewen Lin
Date: Mon Oct 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102930
--- Comment #4 from joseph at codesourcery dot com ---
On Mon, 25 Oct 2021, vincent-gcc at vinc17 dot net via Gcc-bugs wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102930
>
> --- Comment #3 from Vincent Lefèvre ---
> (In reply to Jak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102471
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102477
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |12.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102939
--- Comment #1 from Andrew Pinski ---
So if you place the variable inside a function, then both the C and C++
front-end take a long time to compile
Maybe we should cache variably_modified_type_p somewhere.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102939
Bug ID: 102939
Summary: Ridiculously long compilation times on (admittedly
ridiculous) pointer declaration
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
Sev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102929
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
Severity|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102494
--- Comment #11 from Peter Cordes ---
Also, horizontal byte sums are generally best done with VPSADBW against a zero
vector, even if that means some fiddling to flip to unsigned first and then
undo the bias.
simde_vaddlv_s8:
vpxorxmm0, xm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102937
Andrew Pinski changed:
What|Removed |Added
Resolution|FIXED |INVALID
--- Comment #4 from Andrew Pins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102937
David Rohr changed:
What|Removed |Added
Resolution|INVALID |FIXED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102494
Peter Cordes changed:
What|Removed |Added
CC||peter at cordes dot ca
--- Comment #10 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102837
ibuclaw at gcc dot gnu.org changed:
What|Removed |Added
CC||ibuclaw at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102923
--- Comment #8 from Segher Boessenkool ---
Created attachment 51664
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51664&action=edit
proposed patch
This is the patcgh I am currently testing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102938
--- Comment #1 from Andrew Pinski ---
Related to PR 102860 (or really the same issue).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102938
Bug ID: 102938
Summary: [12 regression] ICE in fortran test cases after
r12-4240
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102937
--- Comment #2 from Andrew Pinski ---
That is the following is undefined:
char *a = NULL;
size_t &t = reinterpret_cast(a);
t = 0x8;
printf("%p\n", a);
GCC does give a warning in the above case too:
: In function 'int main()':
:69:39: warning:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102876
--- Comment #9 from Jason Merrill ---
(In reply to Jakub Jelinek from comment #8)
> But I'm worried about larger TUs where not all dynamic initialization can be
> optimized into constants. E.g. if there remain any function calls where the
> ali
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102937
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102440
--- Comment #7 from Segher Boessenkool ---
The documentation for UInteger also says
Positive values of the argument in
excess of @code{INT_MAX} wrap around zero.
so C "unsigned" types are natural for it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102900
--- Comment #5 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #4)
> The ICE is resolved by Jose's patch to PR100136, which was just accepted.
... but not for proc_ptr_52.f90 with -fcheck=pointer
I've stared at the logic and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102937
Bug ID: 102937
Summary: Miscompilation with -O3 and aliasing of char* and
size_t
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102440
--- Comment #6 from Segher Boessenkool ---
(In reply to Martin Liška from comment #5)
> All right, so the meaning of the UInteger type is actually that users can't
> set the flag/param to a negative value:
>
> $ gcc -fabi-version=-3 a.c
> gcc:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101324
--- Comment #8 from Peter Bergner ---
FYI, here's a smaller test case that still shows the issue with today's trunk:
extern void foo (void);
long int
__attribute__ ((__optimize__ ("-fno-tree-loop-distribute-patterns")))
__memmove_ppc (long int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101324
--- Comment #7 from Peter Bergner ---
(In reply to Martin Liška from comment #6)
> Heh, another example of __attribute__((optimize("..."))) problem:
>
> __attribute__ ((__optimize__ ("-fno-tree-loop-distribute-patterns")))
> __memmove_ppc ( voi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102936
--- Comment #1 from Andreas Schwab ---
In varargs context no implicit type conversions are performed. A pointer to
void may have a different representation than a pointer to char.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102910
--- Comment #12 from CVS Commits ---
The master branch has been updated by Tobias Burnus :
https://gcc.gnu.org/g:72dc270be793f159a3a038bef41542d85550b331
commit r12-4691-g72dc270be793f159a3a038bef41542d85550b331
Author: Tobias Burnus
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102910
--- Comment #11 from sandra at gcc dot gnu.org ---
Patch posted: https://gcc.gnu.org/pipermail/fortran/2021-October/056807.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49745
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
--- Comment #22
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102936
Bug ID: 102936
Summary: Excessive warnings about passing NULL for an "%s"
specifier
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102914
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100354
Alex Coplan changed:
What|Removed |Added
CC||ardb at kernel dot org
--- Comment #3 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102914
Alex Coplan changed:
What|Removed |Added
CC||acoplan at gcc dot gnu.org
Resolu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102935
Bug ID: 102935
Summary: [12 regression] new test case
gcc.target/powerpc/pr101384-1.c fails
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102932
--- Comment #4 from Andrew Pinski ---
(In reply to Rajpal Singh from comment #3)
> Thanks ! Yes, it's signed integer overflow, is there any way to catch it
> statically at compile time ?
Not really because there would so many false positives, i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102910
--- Comment #10 from Steve Kargl ---
On Mon, Oct 25, 2021 at 05:05:26PM +, sandra at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102910
>
> --- Comment #9 from sandra at gcc dot gnu.org ---
> I will rewrite this te
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55227
--- Comment #10 from Will Wray ---
Note that the initialization of 'c0' takes a different codepath:
struct C {char a[2];};
C c0{.a="a"}; // [dcl.init.aggr]
C c1{.a=""};
C c2{.a={"a"}};
C c3{.a={""}};
c1, c2 and c3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102934
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102934
Bug ID: 102934
Summary: missing warning passing address of first member to
free()
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102923
H.J. Lu changed:
What|Removed |Added
CC||amodra at gmail dot com
--- Comment #7 from H
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102933
Bug ID: 102933
Summary: Can't use CTAD in template argument
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102923
H.J. Lu changed:
What|Removed |Added
See Also||https://github.com/libffi/l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55227
--- Comment #9 from Will Wray ---
Adding a reshape_iter, and checking has_designator_problem,
for a brace-enclosed string-literal fixes this secondary issue
+ reshape_iter e {CONSTRUCTOR_ELT (stripped_a_init, 0), e.cur + 1};
+ if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102910
--- Comment #9 from sandra at gcc dot gnu.org ---
I will rewrite this testcase not to use alloca.
This particular case was originally XFAIL'ed at runtime because the
functionality it was supposed to test (assumed-length character
interoperabilit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18907
--- Comment #5 from H.J. Lu ---
New list:
libatomic/Makefile.am: $(MULTIDO) $(AM_MAKEFLAGS) DO=all multi-do # $(MAKE)
libffi/Makefile.am:AM_MAKEFLAGS = \
libffi/Makefile.am:FLAGS_TO_PASS = $(AM_MAKEFLAGS)
libgo/Makefile.am:AM_MAKEFLAGS = \
libg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54720
--- Comment #7 from Eric Gallager ---
The GNU Coding Standards contain an example of a simple way to do this:
https://www.gnu.org/prep/standards/html_node/Standard-Targets.html#Standard-Targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18907
Eric Gallager changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102657
--- Comment #4 from Eric Gallager ---
The GNU Coding Standards has a list of targets all Makefiles should have:
https://www.gnu.org/prep/standards/html_node/Standard-Targets.html#Standard-Targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101324
Martin Liška changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|marxin at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102932
--- Comment #3 from Rajpal Singh ---
(In reply to Tee KOBAYASHI from comment #1)
> Signed integer overflow. You can use -fwrapv.
Thanks ! Yes, it's signed integer overflow, is there any way to catch it
statically at compile time ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102932
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102932
Tee KOBAYASHI changed:
What|Removed |Added
CC||xtkoba at gmail dot com
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102932
Bug ID: 102932
Summary: Wrong implementation of abs with O3
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102931
Bug ID: 102931
Summary: ICE explicit lambda call operator without template
keyword
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102923
--- Comment #5 from Jakub Jelinek ---
(In reply to Segher Boessenkool from comment #4)
> > At least in linux64_closure.S, perhaps guarding it with #ifdef __VEC__ might
> > be ok, because the C code will not use that code if __VEC__ isn't defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102923
--- Comment #4 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #1)
> The stvx stuff is guarded by #ifdef __VEC__, so perhaps the lvx stuff should
> be too, or there should be .machine push; .machine power7; ... .machine pop;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102926
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102925
--- Comment #2 from qingzhe huang ---
I suspect this is related to template-specialization-related issue because if I
use original implementation of "std::convertible_to" to declare my concept
(https://en.cppreference.com/w/cpp/concepts/converti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102440
Martin Liška changed:
What|Removed |Added
Assignee|marxin at gcc dot gnu.org |unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102281
--- Comment #16 from qinzhao at gcc dot gnu.org ---
Created attachment 51662
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51662&action=edit
proposed patch to gcc12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102926
--- Comment #5 from Ard Biesheuvel ---
Actually, I can reproduce the same behavior without the TLS register, where the
result of a MOVW/MOVT immediate assignment is also spilled to the stack.
int ll[2];
int foo(int);
int bar(void)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102851
--- Comment #2 from hasse.christoph at cern dot ch ---
Created attachment 51661
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51661&action=edit
Preprocessed source
Compile with g++ -O3 -DNDEBUG -g -o tmp.o -c preprocessed.cpp
objdump -d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102907
Tamar Christina changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102907
--- Comment #2 from CVS Commits ---
The master branch has been updated by Tamar Christina :
https://gcc.gnu.org/g:2cbfaba60661ebbdfcffe725ab55fbb323e2a187
commit r12-4663-g2cbfaba60661ebbdfcffe725ab55fbb323e2a187
Author: Tamar Christina
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102834
Rainer Orth changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ro at gcc dot gnu.org
Ever con
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102930
--- Comment #3 from Vincent Lefèvre ---
(In reply to Jakub Jelinek from comment #2)
> I think there is nothing that can be done about this, and something like
> this has been there since forever. While perhaps some double routines in
> glibc us
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102930
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102835
Rainer Orth changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
URL|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102930
--- Comment #1 from Vincent Lefèvre ---
I forgot some information: Debian unstable currently has libc6 2.32-4, where
IBM's code for correct rounding was disabled some time ago. This bug might be
unreproducible with other glibc versions (or other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102836
Rainer Orth changed:
What|Removed |Added
Last reconfirmed||2021-10-25
URL|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102930
Bug ID: 102930
Summary: equal values appear to be different due to missing
correct rounding in libc
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102916
--- Comment #11 from Darrell Wright ---
(In reply to Jonathan Wakely from comment #7)
> C++23 is making these constexpr anyway so I'm not very inclined to change
> this now.
That is good to hear, I thought I had read/heard that there was a lot o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102886
Martin Jambor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102505
--- Comment #7 from CVS Commits ---
The master branch has been updated by Martin Jambor :
https://gcc.gnu.org/g:f217e87972a2a207e793101fc05cfc9dd095c678
commit r12-4662-gf217e87972a2a207e793101fc05cfc9dd095c678
Author: Martin Jambor
Date: M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102886
--- Comment #3 from CVS Commits ---
The master branch has been updated by Martin Jambor :
https://gcc.gnu.org/g:f217e87972a2a207e793101fc05cfc9dd095c678
commit r12-4662-gf217e87972a2a207e793101fc05cfc9dd095c678
Author: Martin Jambor
Date: M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102923
--- Comment #3 from H.J. Lu ---
powerpc64-unknown-linux-gnu works with libffi upstream on
gcc110.fsffrance.org.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102929
Bug ID: 102929
Summary: [missed optimization] two ways to
rounddown-to-next-multiple
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40748
--- Comment #7 from Martin Liška ---
> {
> if (i == 0) return 0;
> if (i == 1) return 1;
> if (i == 2) return 2;
> if (i == 3) return 3;
> if (i == 4) return 4;
> if (i == 5) return 4;
> if (i == 6) retur
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102925
Andrew Pinski changed:
What|Removed |Added
Depends on||102728
--- Comment #1 from Andrew Pinsk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40748
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102928
Bug ID: 102928
Summary: Template argument deduction when mixing variadic
template with C-style variadic function
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40748
Andrew Pinski changed:
What|Removed |Added
CC||gabravier at gmail dot com
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102927
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102927
--- Comment #7 from Martin Liška ---
(In reply to Gabriel Ravier from comment #5)
> Um, what ? How is this invalid, exactly ? Are you saying foo is faster than
> baz (in which case it seems the opposite optimization should be implemented
> for b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102927
Andrew Pinski changed:
What|Removed |Added
Resolution|INVALID |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102927
--- Comment #5 from Gabriel Ravier ---
Um, what ? How is this invalid, exactly ? Are you saying foo is faster than baz
(in which case it seems the opposite optimization should be implemented for baz
and bar), or that this optimization just won't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102926
--- Comment #4 from Andrew Pinski ---
If anything it is a cost model issue in the back-end.
1 - 100 of 158 matches
Mail list logo
