https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66089
--- Comment #14 from Mikael Morin ---
Created attachment 37613
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37613=edit
Fix for comment #10
This is sufficient to fix comment #10.
It removes the optional attribute on c(1) if c is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69711
Bug ID: 69711
Summary: Wrong suggestion for -ftree-ivopts
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: enhancement
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69712
Bug ID: 69712
Summary: Storing and reusing a method pointer as compile time
value
Product: gcc
Version: 5.2.1
Status: UNCONFIRMED
Keywords: rejects-valid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69607
--- Comment #14 from vries at gcc dot gnu.org ---
Created attachment 37616
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37616=edit
further updated tentative patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69710
--- Comment #1 from Doug Gilmore ---
Created attachment 37615
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37615=edit
daxpy for DP (previous was for SP)
Compilation example:
arm-linux-gnueabihf-gcc -O3 -save-temps daxpy.c saxpy.c -c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69710
--- Comment #3 from Andrew Pinski ---
For the double one, in .optimized on the trunk for aarch64
(--with-cpu=thunderx) I get:
:
# ivtmp.22_60 = PHI <0(10), ivtmp.22_59(11)>
# ivtmp.25_75 = PHI <0(10), ivtmp.25_79(11)>
vect__12.14_86 =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69607
--- Comment #15 from vries at gcc dot gnu.org ---
(In reply to vries from comment #14)
> Created attachment 37616 [details]
> further updated tentative patch
Fixes -fno-use-linker-plugin failures, apart from:
- PR69707
- PR69705
- PR67709
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67260
--- Comment #4 from Oleg Endo ---
(In reply to Alexander Monakov from comment #1)
>
> So it wants to pick a scratch register in SIBCALL_REGS ("k", r0-r7), but in
> the circumstances r4-r7 are already used for argument passing, and r0-r3 are
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69700
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69712
Ville Voutilainen changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69710
--- Comment #2 from Andrew Pinski ---
IV-opts runs after the vectorizer so if that does not optimize it to where you
want it to be the problem is there.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69710
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69712
--- Comment #1 from realloc at outlook dot de ---
Created attachment 37618
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37618=edit
testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69710
--- Comment #5 from Doug Gilmore ---
Thanks for checking on AArch64 Andrew.
BTW, I made my (incorrect) hunch by running a test on gcc113, where
the installed 4.8 compile showed problems for both DP and SP. (I
assumed that the problem was
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69331
John David Anglin changed:
What|Removed |Added
Component|libstdc++ |target
--- Comment #2 from John
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69111
Ville Voutilainen changed:
What|Removed |Added
Keywords||rejects-valid
--with-pkgversion='Ubuntu 6-20160206-0ubuntu2'
--with-bugurl='file:///usr/share/doc/gccgo-6/README.Bugs'
--enable-languages=c,c++,go
--prefix=/usr
--program-suffix=-6
--enable-shared
--enable-linker-build-id
--libexecdir=/usr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69710
Bug ID: 69710
Summary: performance issue with SP Linpack with
Autovectorization
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69699
--- Comment #2 from Jonathan Wakely ---
That macro is fairly useless.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67260
Oleg Endo changed:
What|Removed |Added
Target||sh*-*-*
--- Comment #3 from Oleg Endo ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67709
--- Comment #5 from vries at gcc dot gnu.org ---
The scenario is the following:
During pass_omp_simd_clone, we call simd_clone_create for foo, and execute the
!old_node->definition part:
...
tree old_decl = old_node->decl;
tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69331
--- Comment #1 from John David Anglin ---
Also see:
*** Error in `./default_weaktoshared.exe': double free or corruption (fasttop):
0x0001d858 ***
*** Error in `./default_weaktoshared.exe': double free or corruption (fasttop):
0x0001d880
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69687
--- Comment #5 from Marcel Böhme ---
Created attachment 37612
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37612=edit
Debug This
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69706
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52085
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67260
--- Comment #2 from Alexander Monakov ---
(added SH maintainers, Oleg Endo and Kaz Kojima to Cc)
In response to the last sentence in my analysis, on IRC Rich pointed out that
using r1/r2/r3 should be better that r0 because some instruction can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69550
--- Comment #18 from Milan Bouchet-Valat ---
FWIW, Debian has identified a few packages failing to build with the "flexible
array member in otherwise empty struct" error under GCC 6:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812023
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69703
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69693
--- Comment #6 from H.J. Lu ---
(In reply to Uroš Bizjak from comment #5)
> (In reply to H.J. Lu from comment #4)
>
> > It looks that it is done on purpose.
>
> In this case, our planned transition to generic unaligned SSE loads should
> "fix"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66643
--- Comment #4 from Jerry DeLisle ---
Created attachment 37610
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37610=edit
A preliminary patch
Attached patch gives a diagnostic. Interestingly I found three test cases in
the test suite that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69707
--- Comment #1 from vries at gcc dot gnu.org ---
Created attachment 37611
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37611=edit
tentative patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69708
Bug ID: 69708
Summary: ipa inline not working for function reference in
static const struct
Product: gcc
Version: 5.3.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69687
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69713
Bug ID: 69713
Summary: Invalid code of optimization in SH
Product: gcc
Version: 5.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67260
--- Comment #6 from Oleg Endo ---
(In reply to Rich Felker from comment #5)
>
> 1. that the "k" constraint that's currently used is not working to
> automatically assign a scratch register because r4-r7 are all live as
> argument registers and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67260
--- Comment #7 from Alexander Monakov ---
Oleg, Rich, there's some confusion in comments 4-6. Please unwind all the way
back to comment #1, and let me explain the issue once again. I now see that my
phrasing back then was insufficiently
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67260
--- Comment #5 from Rich Felker ---
Oleg, thanks for the tip. I think what Alexander is saying about r0-r3 is:
1. that the "k" constraint that's currently used is not working to
automatically assign a scratch register because r4-r7 are all live
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69687
--- Comment #7 from Marcel Böhme ---
Created attachment 37620
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37620=edit
Valgrind This
$ cat compileme.c
#include
#include
const char*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67260
--- Comment #8 from Alexander Monakov ---
Hm, if GCC won't accept clobbering a hardreg that overlaps the output hardregs
holding the return value (operands[0]), then it's less obvious. r0 is always
suitable then and does not require mentioning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69634
--- Comment #6 from Uroš Bizjak ---
+/* { dg-additional-options "-Wno-psabi -mno-sse" { target i?86-*-* x86_64-*-*
} } */
+/* { dg-additional-options "-m32" { target x86_64-*-* } } */
Please don't use explicit -m32. If the test is valid only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67709
--- Comment #6 from vries at gcc dot gnu.org ---
a.
I'm not sure if we still should be update inline_summaries at the point that we
do pass_omp_simd_clone. AFAICT, it's the last ipa pass. Simply cloning
pass_ipa_free_inline_summary in front of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67709
vries at gcc dot gnu.org changed:
What|Removed |Added
Keywords||lto, openmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68404
--- Comment #13 from rsandifo at gcc dot gnu.org
---
(In reply to Bill Schmidt from comment #10)
> Looking at scan_rtx_address () in regrename.c, it indeed looks like a PLUS
> nested inside a PLUS isn't handled. I'm not sure if this is a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69658
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69705
Bug ID: 69705
Summary: segfault in libgomp.fortran/task1.f90 with -flto
-fno-use-linker-plugin -fno-toplevel-reorder -O1 -g
Product: gcc
Version: 6.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56665
Markus Trippelsdorf changed:
What|Removed |Added
CC||trippels at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69693
--- Comment #5 from Uroš Bizjak ---
(In reply to H.J. Lu from comment #4)
> It looks that it is done on purpose.
In this case, our planned transition to generic unaligned SSE loads should
"fix" this issue. The realignment will be necessary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67709
--- Comment #3 from vries at gcc dot gnu.org ---
libgomp.fortran/declare-simd-3.f90:
...
subroutine bar
use declare_simd_2_mod
real :: b(128)
integer :: i
!$omp simd
do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67709
--- Comment #4 from vries at gcc dot gnu.org ---
ICE backtrace:
...
src/libgomp/testsuite/libgomp.fortran/declare-simd-3.f90: At top level:
src/libgomp/testsuite/libgomp.fortran/declare-simd-3.f90:7:0: internal compiler
error: in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67709
--- Comment #7 from vries at gcc dot gnu.org ---
Created attachment 37609
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37609=edit
tentative patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69707
Bug ID: 69707
Summary: FAIL: parallel-dims.c test for excess errors with
-flto -fno-use-linker-plugin
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69706
Bug ID: 69706
Summary: internal compiler error: in extract_constrain_insn, at
recog.c:2246
Product: gcc
Version: 5.3.1
Status: UNCONFIRMED
Severity: normal
52 matches
Mail list logo
