https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109853
Richard Biener changed:
What|Removed |Added
Target||mingw-w64
--- Comment #1 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2023-05-15
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48701
--- Comment #4 from Andrew Pinski ---
Better testcase without inline-asm (because sometimes inline-asm gets in the
way of other optimizations):
```
#include
__m256i blackhole;
void testStore(__m128i xmm0, __m128i xmm1)
{
__m256i ymm;
_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109845
--- Comment #3 from Richard Biener ---
Yup, bad luck for later RTL optimization. It might help to perform jump
expansions decision to go for jump or straight-line code earlier on GIMPLE (and
stick to that).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109828
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |13.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68855
--- Comment #3 from Richard Biener ---
(In reply to Andrew Pinski from comment #2)
> Maybe:
> (simplify
> (paren (complex_expr @0 @1))
> (complex_expr (paren @0) (paren @1))
That makes the tree larger though ...
But yes, if we have (complex (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109805
Richard Biener changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14753
--- Comment #12 from Andrew Pinski ---
Summary of the ones still need to be done:
comment #0:
* foo
comment #3:
* rshift_gt
* rshift_eq
* mask_gt
* neg_eq_cst
* neg_eq_var
comment #4:
* minus_cst
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109848
Richard Biener changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109852
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #3 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46284
Andrew Pinski changed:
What|Removed |Added
Known to work||10.1.0, 11.3.0, 12.1.0,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712
--- Comment #7 from Richard Biener ---
(In reply to Carlos Galvez from comment #6)
> Hi again!
>
> I realized there is still one more problem missing, so I suspect the linker
> was not the only culprit. It does not segfault, but it gets stuck i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15792
Andrew Pinski changed:
What|Removed |Added
Known to fail||
--- Comment #12 from Andrew Pinski ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46975
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46127
Andrew Pinski changed:
What|Removed |Added
Severity|minor |enhancement
Last reconfirmed|2010-10-2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45980
--- Comment #2 from Andrew Pinski ---
For the original testcase on the trunk we get:
ldr r3, .L2
str r3, [r0]
add r3, r3, #-2004318072
str r3, [r0, #4]
add r3, r3, #-1459617792
s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45252
Andrew Pinski changed:
What|Removed |Added
Keywords||needs-bisection
--- Comment #1 from Andr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36539
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |4.8.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39052
--- Comment #3 from Andrew Pinski ---
even for:
void foo(char *a, int n)
{
int i;
for (i=0; i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33716
--- Comment #1 from Andrew Pinski ---
32bit x86 is not as important any more.
With -msse2 these days, GCC produces:
movq4(%esp), %xmm0
psrlq $4, %xmm0
movd%xmm0, %eax
psrlq $32, %xmm0
movd%x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51781
Andrew Pinski changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|pinskia at gcc do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109858
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109858
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
Target Milestone|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109858
Bug ID: 109858
Summary: r14-172 caused some SPEC2017 bmk to degrade on Power
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64700
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40730
--- Comment #15 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #14)
> Fixed for GCC 12 by r12-897-gde56f95afaaa22 (and r11-408-g84935c9822183c).
The first redundant load was fixed by r11-408-g84935c9822183c.
The extra store was
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40730
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |12.0
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89332
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed|2019-02-18 00:00:00 |2023-5-14
Severity|normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68855
--- Comment #2 from Andrew Pinski ---
Maybe:
(simplify
(paren (complex_expr @0 @1))
(complex_expr (paren @0) (paren @1))
(simplify
(paren (real_expr @0))
(real_expr (paren @0))
(simplify
(paren (imag_expr @0))
(real_expr (paren @0))
Is eno
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64450
--- Comment #3 from Andrew Pinski ---
(for cmp (tcc_comparison)
(simplify
(cmp (pointer_diff @0 @1) integer_zero_p)
(cmp @0 @1)))
Maybe
But we might also need handle the match patterns for too:
A CMP B ? A - B : -(A - B)
A CMP B ? A -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109829
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109829
--- Comment #10 from CVS Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:82502b5c3463bde98d4b7ffb9ecef9b123799ed1
commit r14-813-g82502b5c3463bde98d4b7ffb9ecef9b123799ed1
Author: Andrew Pinski
Date: Sa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90259
Andrew Pinski changed:
What|Removed |Added
CC||zsojka at seznam dot cz
--- Comment #10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105686
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105686
Andrew Pinski changed:
What|Removed |Added
Known to fail|13.0|
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97551
Andrew Pinski changed:
What|Removed |Added
Summary|ICE: verify_cgraph_node |[11 Regression] ICE:
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94675
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed|2020-04-21 00:00:00 |2023-5-14
--- Comment #25 from Andrew Pi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109857
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2023-05-14
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109857
Bug ID: 109857
Summary: tzdata 2021a has bad data that cannot be parsed by
libstdc++
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85614
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-05-14
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109846
--- Comment #5 from anlauf at gcc dot gnu.org ---
Submitted: https://gcc.gnu.org/pipermail/fortran/2023-May/059297.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109818
--- Comment #29 from Jonathan Wakely ---
(In reply to Janez Zemva from comment #27)
> forcing glibcxx_cv_c99_math_tr1=yes solved this issue for me. The C99
> compliance test is really strict, even openlibm fails the test (it fails to
> define fl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109807
Uroš Bizjak changed:
What|Removed |Added
CC||jamborm at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109825
Uroš Bizjak changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109807
Uroš Bizjak changed:
What|Removed |Added
CC||slyfox at gcc dot gnu.org
--- Comment #14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109838
--- Comment #2 from Uroš Bizjak ---
*** This bug has been marked as a duplicate of bug 109807 ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109818
--- Comment #28 from Jonathan Wakely ---
(In reply to Janez Zemva from comment #26)
> I am a c++ user, so I don't like using c header files if at all possible.
is a C++ header file, if you doubt that, you can check the path where
it's included
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109807
Uroš Bizjak changed:
What|Removed |Added
Resolution|DUPLICATE |FIXED
--- Comment #13 from Uroš Bizjak -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109807
--- Comment #12 from CVS Commits ---
The master branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:aed51e2051b24a6a2127c6626f451641557a571a
commit r14-812-gaed51e2051b24a6a2127c6626f451641557a571a
Author: Uros Bizjak
Date: Sun M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105719
--- Comment #4 from Iain Sandoe ---
Created attachment 55084
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55084&action=edit
Implement the use of fixed framework headers
this was a proof-of-principle exercise while looking into issues ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109846
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109846
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109852
--- Comment #2 from Andrew Pinski ---
I cannot reproduce this with "../configure --with-build-config=bootstrap-O3" .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109840
Roger Sayle changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109856
Bug ID: 109856
Summary: -Wnull-dereference false positive in Emacs itree.c
(regression from GCC 12)
Product: gcc
Version: 13.1.1
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109855
--- Comment #1 from Andrew Pinski ---
Most likely caused by r14-473-g93c26deab98fc8 .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109855
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.0
Host|x86_64-pc-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109848
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.0
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98577
Thomas Koenig changed:
What|Removed |Added
Resolution|WONTFIX |INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98577
Chinoune changed:
What|Removed |Added
Resolution|INVALID |WONTFIX
nary-trunk-r14-810-20230514170325-g1871740c780-checking-yes-rtl-df-extra-aarch64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20230514 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69388
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109854
Bug ID: 109854
Summary: Error: junk `(%rip)' after expression when using -flto
on files compiled with and without -masm=intel
Product: gcc
Version: 13.1.1
Status: UNCONF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109852
Andrew Pinski changed:
What|Removed |Added
Component|libgcc |tree-optimization
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109818
--- Comment #27 from Janez Zemva ---
forcing glibcxx_cv_c99_math_tr1=yes solved this issue for me. The C99
compliance test is really strict, even openlibm fails the test (it fails to
define float_t and double_t, but this can be hacked around).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109853
Bug ID: 109853
Summary: WIN64 is a predefined constant on GCC MinGW-w64
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108250
--- Comment #13 from Arsen Arsenović ---
as an update, we've recently gotten valgrind working on a ppc32 machine, and we
get the following:
==2738== Conditional jump or move depends on uninitialised value(s)
==2738==at 0x17E55C: __eq (tuple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88088
Martin Uecker changed:
What|Removed |Added
CC||muecker at gwdg dot de
--- Comment #26 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109852
Bug ID: 109852
Summary: Making of gcc13 stops at libcpp/charset.cc with Error
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849
--- Comment #5 from Jan Hubicka ---
> Actually why didn't we copy the loop header in the first place?
Because it is considered to be do-while loop already (thanks to
the in-loop conitional, do_while_loop_p is happy).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849
--- Comment #4 from Jan Hubicka ---
> Rather, because store-motion out of a loop that might iterate zero times would
> create a data race.
Good point. If we did copy loop headers all the way to the store the
problem will go away. Also I assume
71 matches
Mail list logo
