https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80492
Bug ID: 80492
Summary: Wrong code when unrolling a loop with inline asm and
local regs
Product: gcc
Version: 6.3.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80477
--- Comment #8 from Stefano Zaghi ---
Dear Janus,
> No offense taken. Asking questions is not a crime ;)
Good, thank you for the clarification.
> I'm sorry to disappoint you, but there simply is no roadmap and I'm not able
> to provide one.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80489
--- Comment #2 from Vittorio Zecca ---
I did not know that one, my C++ knowledge is so limited.
This is a fragment I took from chromium web browser and I was fooled because
it is succesfully compiled by older g++, clang, and Intel icpc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80491
--- Comment #2 from Victor Khimenko ---
An interesting observation: -O1 actually produces perfect code:
$ gcc -S -O1 test.cc -o-
.file "test.cc"
.text
.p2align 4,,15
.globl _Z3addR4pairS0_
.type _Z3addR4pa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80484
Jerry DeLisle changed:
What|Removed |Added
Keywords||wrong-code
--- Comment #12 from Jerry De
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430
--- Comment #68 from Thomas Koenig ---
Created attachment 41247
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41247&action=edit
Patch to be able to run the test case
With this patch on top of the relevant version, it is actually
possible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80491
--- Comment #1 from Victor Khimenko ---
Actually even clang's version is not optimal ("addq 8(%rdi), %rdx" then "adcq
$0, %rdx" could be replaced with "adcq 8(%rdi), %rdx"). But at least both calng
and old version of gcc are smart enough to rem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80484
--- Comment #11 from Walt Brainerd ---
Looks good. Great work.
You have done more than your share today to make the Fortran world a better
place.
Thanks!
On Sat, Apr 22, 2017 at 2:32 PM, jvdelisle at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80489
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80484
--- Comment #10 from Jerry DeLisle ---
(In reply to Walt Brainerd from comment #9)
> Just FYI, Intel 2017 compiles 3DT'...', but it does not run correctly
> (response inspired by your comments about a similar possibility :-).
>
Seems to run OK
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80484
--- Comment #9 from Walt Brainerd ---
Just FYI, Intel 2017 compiles 3DT'...', but it does not run correctly
(response inspired by your comments about a similar possibility :-).
On Sat, Apr 22, 2017 at 12:35 PM, jvdelisle at gcc dot gnu.org <
gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80482
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80491
Bug ID: 80491
Summary: Compiler regression for long-add case.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-opti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80484
--- Comment #8 from Jerry DeLisle ---
Regarding:
use dt_write_mod, only: B_type, write (formatted)
This works:
use dt_write_mod, only: B_type
It seems to me that since write (formatted) is a special instance of an
interface defined by t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80484
--- Comment #7 from Jerry DeLisle ---
Created attachment 41246
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41246&action=edit
Preliminary patch for testing
This patch takes care of the rejected format with a repeat in front of the DT
and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80474
--- Comment #2 from Jan Smets ---
Created attachment 41245
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41245&action=edit
testcase pr80474
-O2 -fno-reorder-blocks -march=mips2 -fno-inline-small-functions
MIPS O32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430
--- Comment #67 from Jürgen Reuter ---
And furthermore, if you do only the single make check
TESTS=mlm_matching_isr.run in
tests/functional_test, also the unit tests modules are not compiled, which
saves more time.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80121
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|un
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430
--- Comment #66 from Jürgen Reuter ---
One more thing: you can speed up compilation of our code by using in the
configure step the flag --disable-static, then each module is only compiled
once with the -fPIC flag.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80490
--- Comment #1 from Jean-Michaël Celerier ---
Also:
* When compiling this way with GCC (with just -g instead of -ggdb) I am not
able to debug with lldb
* When compiling with the same arguments with clang++, I am able to debug with
lldb *and* se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80490
Bug ID: 80490
Summary: -gsplit-dwarf: top namespace info seems to be lost in
GDB
Product: gcc
Version: 6.2.1
Status: UNCONFIRMED
Severity: normal
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80484
--- Comment #6 from Walt Brainerd ---
I have added a complete program as an attachment to the bug report
(I think).
See comments in the program.
Pls let me know if there is something missing.
On Fri, Apr 21, 2017 at 7:27 PM, jvdelisle at gcc d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80484
Walt Brainerd changed:
What|Removed |Added
CC||walt.brainerd at gmail dot com
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80484
--- Comment #4 from Walt Brainerd ---
OK, but it will take me some time to cut the thing down from
the several hundred lines that do the formatting.
Not hard to do, just will take a bit to get a good example.
Thanks for looking at this.
On Fri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80477
--- Comment #7 from janus at gcc dot gnu.org ---
(In reply to Stefano Zaghi from comment #6)
> As I tried to clarify to Steve, mine was absolutely not a polemic question:
No offense taken. Asking questions is not a crime ;)
> What I meant was "
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79534
--- Comment #13 from Brian Rzycki ---
James, if you develop any new ifcvt any patches you'd like to test on my full
source base I'd be happy to help. The code is very branchy and in some cases
have up to 4 nested if/else pairs. There are a couple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80477
--- Comment #6 from Stefano Zaghi ---
Dear Janus,
thank you very much for your help, it is really appreciated.
> Note that most gfortran developers actually sacrifice their spare time to
> contribute, without receiving any kind of financial r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80489
Bug ID: 80489
Summary: Regression no matching function
Product: gcc
Version: 7.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Ass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68800
janus at gcc dot gnu.org changed:
What|Removed |Added
CC||janus at gcc dot gnu.org
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80121
--- Comment #8 from janus at gcc dot gnu.org ---
Btw, I think this is a duplicate of PR 63473.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63473
--- Comment #7 from janus at gcc dot gnu.org ---
(In reply to Mikael Morin from comment #6)
> Seems to work now. FIXED?
I still see it with all recent gfortran versions (5,6,7,trunk).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80440
Paul Thomas changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80477
--- Comment #5 from janus at gcc dot gnu.org ---
(In reply to Stefano Zaghi from comment #2)
> I read that the other bug report is dated 2014: can I conclude that such a
> bug will need a long time to be fixed?
Not necessarily. It just takes so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80477
--- Comment #4 from janus at gcc dot gnu.org ---
(In reply to janus from comment #3)
> Confirmed. Here is the most reduced test case I could construct from your
> original example:
-fdump-tree-original shows the following dump for this case:
po
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80440
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80477
janus at gcc dot gnu.org changed:
What|Removed |Added
Keywords||wrong-code
Status|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79062
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80487
--- Comment #1 from Marc Glisse ---
In tree-ssa-alias.c, stmt_kills_ref_p knows about memcpy but not about strncpy
(I had no idea until I read the man page just now that strncpy filled the
buffer with 0s). Since the 2 arguments of strncpy are not
38 matches
Mail list logo
