https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88044
--- Comment #15 from Jakub Jelinek ---
Author: jakub
Date: Tue Jan 22 09:58:23 2019
New Revision: 268143
URL: https://gcc.gnu.org/viewcvs?rev=268143=gcc=rev
Log:
PR tree-optimization/88044
* tree-ssa-loop-niter.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88952
--- Comment #10 from Christopher Leonard
---
Getting contradictory statements now:
>reg:reg+1 maps to lo:hi on x86.
>On x86, we don't allow register pairs in asm at all.
Not allowing, or printing a warning, is much better behavior than what I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88952
--- Comment #9 from Christopher Leonard
---
(In reply to Andrew Pinski from comment #6)
> Yes the order is always hi:lo (reg:reg+1) on all targets I know of
This is definitely not the natural choice (on any platform: I agree, endianness
is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88952
--- Comment #8 from Andreas Schwab ---
reg:reg+1 maps to lo:hi on x86.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88963
--- Comment #6 from Andrew Pinski ---
Try using 128 (or 256) and you might see that aarch64 falls down similarly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88422
--- Comment #10 from Richard Biener ---
Author: rguenth
Date: Tue Jan 22 09:49:27 2019
New Revision: 268142
URL: https://gcc.gnu.org/viewcvs?rev=268142=gcc=rev
Log:
2019-01-22 Nidal Faour
PR lto/88422
* simple-object.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88422
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88422
--- Comment #8 from Richard Biener ---
Author: rguenth
Date: Tue Jan 22 09:47:52 2019
New Revision: 268141
URL: https://gcc.gnu.org/viewcvs?rev=268141=gcc=rev
Log:
2019-01-22 Nidal Faour
PR lto/88422
* simple-object.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88422
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88963
--- Comment #5 from Andrew Pinski ---
(In reply to Devin Hussey from comment #4)
> Strangely, this doesn't seem to affect the ARM or aarch64 backends, although
> I am on a December build (specifically Dec 29). 8.2 is also unaffected.
This is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88952
--- Comment #7 from Uroš Bizjak ---
(In reply to Christopher Leonard from comment #5)
> Is the order at least consistant with x86-32? i.e. if you give a 64-bit
> input operand to inline assembly the order is hi:lo? I'm worried this is a
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37222
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88963
Devin Hussey changed:
What|Removed |Added
CC||husseydevin at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88951
--- Comment #2 from Paolo Carlini ---
Also note, further clarifying what I said in the linked messages, that we only
temporarily, for few releases, accepted with -fpermissive such kind of broken
code: before gcc5, -fpermissive suppressed the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88919
--- Comment #2 from Richard Biener ---
Sandra posted a patch that will probably fix this (out-of-bound shift values).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88422
--- Comment #6 from Nidal Faour ---
Andrew Pinski is right, after chasing this bug with the help of Andrew Burgess
in the file simple-object.c, calling the creat
outfd = creat (dest, 00777);
the creat function wraps the open function but do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88713
--- Comment #23 from rguenther at suse dot de ---
On Tue, 22 Jan 2019, elrodc at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88713
>
> --- Comment #22 from Chris Elrod ---
> Okay. I did that, and the time went from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38113
Jürgen Reuter changed:
What|Removed |Added
CC||juergen.reuter at desy dot de
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37398
Jürgen Reuter changed:
What|Removed |Added
CC||juergen.reuter at desy dot de
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37222
Jürgen Reuter changed:
What|Removed |Added
CC||juergen.reuter at desy dot de
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88713
--- Comment #22 from Chris Elrod ---
Okay. I did that, and the time went from about 4.25 microseconds down to 4.0
microseconds. So that is an improvement, but accounts for only a small part of
the difference with the LLVM-compilers.
-O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88952
--- Comment #6 from Andrew Pinski ---
(In reply to Christopher Leonard from comment #5)
> Is the order at least consistant with x86-32? i.e. if you give a 64-bit
> input operand to inline assembly the order is hi:lo? I'm worried this is a
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88951
--- Comment #1 from Paolo Carlini ---
The rationale for the change is here:
https://gcc.gnu.org/ml/gcc-patches/2018-08/msg00623.html I my experience,
accepting such kind of code is really dangerous, because -fpermissive isn't
fine grained thus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88963
--- Comment #3 from Jakub Jelinek ---
Yeah, I've noticed that already when working on __builtin_convertvector, we
don't really do much TER for the oversized vector SSA_NAMEs and force them into
stack all the time. Wonder if we couldn't do kind
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88963
--- Comment #2 from Richard Biener ---
Created attachment 45489
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45489=edit
untested patch
forwprop patch I was playing with.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88963
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88952
--- Comment #5 from Christopher Leonard
---
Is the order at least consistant with x86-32? i.e. if you give a 64-bit input
operand to inline assembly the order is hi:lo? I'm worried this is a bizarre
convention imposed on high endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88905
Jakub Jelinek changed:
What|Removed |Added
Summary|[8/9 Regression] ICE: in|[8 Regression] ICE: in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88904
--- Comment #5 from Jakub Jelinek ---
Author: jakub
Date: Tue Jan 22 09:12:31 2019
New Revision: 268140
URL: https://gcc.gnu.org/viewcvs?rev=268140=gcc=rev
Log:
PR rtl-optimization/88904
* cfgcleanup.c (thread_jump): Verify
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88905
--- Comment #5 from Jakub Jelinek ---
Author: jakub
Date: Tue Jan 22 09:11:35 2019
New Revision: 268139
URL: https://gcc.gnu.org/viewcvs?rev=268139=gcc=rev
Log:
PR target/88905
* optabs.c (add_equal_note): Add op0_mode argument,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35718
--- Comment #6 from Jürgen Reuter ---
Still present in trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49454
--- Comment #9 from Jakub Jelinek ---
Author: jakub
Date: Tue Jan 22 09:10:25 2019
New Revision: 268138
URL: https://gcc.gnu.org/viewcvs?rev=268138=gcc=rev
Log:
PR rtl-optimization/49429
PR target/49454
PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88906
--- Comment #8 from Jakub Jelinek ---
Author: jakub
Date: Tue Jan 22 09:10:25 2019
New Revision: 268138
URL: https://gcc.gnu.org/viewcvs?rev=268138=gcc=rev
Log:
PR rtl-optimization/49429
PR target/49454
PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86334
--- Comment #4 from Jakub Jelinek ---
Author: jakub
Date: Tue Jan 22 09:10:25 2019
New Revision: 268138
URL: https://gcc.gnu.org/viewcvs?rev=268138=gcc=rev
Log:
PR rtl-optimization/49429
PR target/49454
PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49429
--- Comment #21 from Jakub Jelinek ---
Author: jakub
Date: Tue Jan 22 09:10:25 2019
New Revision: 268138
URL: https://gcc.gnu.org/viewcvs?rev=268138=gcc=rev
Log:
PR rtl-optimization/49429
PR target/49454
PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88913
--- Comment #2 from Yibiao Yang ---
(In reply to Martin Liška from comment #1)
> Fixed on trunk in r247374.
Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88969
Martin Liška changed:
What|Removed |Added
Status|WAITING |NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88913
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35779
Jürgen Reuter changed:
What|Removed |Added
CC||juergen.reuter at desy dot de
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88924
Martin Liška changed:
What|Removed |Added
Priority|P3 |P5
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35476
Jürgen Reuter changed:
What|Removed |Added
CC||juergen.reuter at desy dot de
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88969
--- Comment #2 from Arseny Solokha ---
I get what you see when I modify the testcase from comment 0 the following way:
--- mi9qy2yt.cpp2019-01-22 15:48:53.473604944 +0700
+++ r9d6mwt2.cpp2019-01-22 15:46:45.567008369 +0700
@@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88969
--- Comment #3 from Arseny Solokha ---
--- mi9qy2yt.cpp2019-01-22 15:51:33.410845340 +0700
+++ tbfkgb7c.cpp2019-01-22 15:51:28.620898102 +0700
@@ -7,7 +7,7 @@
namespace delete_selection {
struct B {
void operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88966
--- Comment #4 from Andrew Pinski ---
The same reason why:
#define mymacro 1
str(mymacro)
stringify(mymacro)
Gives different results.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88713
--- Comment #21 from rguenther at suse dot de ---
On Tue, 22 Jan 2019, elrodc at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88713
>
> --- Comment #19 from Chris Elrod ---
> To add a little more:
> I used inline asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88956
Martin Liška changed:
What|Removed |Added
Priority|P3 |P1
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88957
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88958
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88964
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88965
Jakub Jelinek changed:
What|Removed |Added
Status|WAITING |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88965
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88966
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88968
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88969
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88967
--- Comment #4 from Roman Lebedev ---
(In reply to Roman Lebedev from comment #3)
> While there, any advice on how that is supposed to be rewritten?
> Simply adding "shared(begin, len)" makes older gcc's unhappy
> https://godbolt.org/z/gyZBR-
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88970
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
201 - 256 of 256 matches
Mail list logo
