https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83150
--- Comment #4 from Segher Boessenkool ---
(In reply to Ben Longbons from comment #3)
> (In reply to Andrew Pinski from comment #2)
> > Plugins are not well defined in GCC.
>
> That excuse is getting *really* old.
No matter how often you hear
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83149
--- Comment #3 from Neil Carlson ---
Unlike comment 0 code, comment 2 code also gives an ICE with 7.2.1 and 6.4.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83149
--- Comment #2 from Neil Carlson ---
Here's another example. The ICE is coming at the same place, toplev.c:325, so
I think it may be the same underlying problem. Like the original example, the
ICE occurs only when the main program is in a separ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83150
--- Comment #3 from Ben Longbons ---
(In reply to Andrew Pinski from comment #1)
> The signal handler will always be sync unless someone decides to do a kill
> from the command line.
You're assuming that no library ever calls abort(). Glibc cert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83150
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83150
--- Comment #1 from Andrew Pinski ---
>2. if the real `abort` is used, GCC installs a signal handler, which calls
>async-signal-unsafe functions, such as malloc.
The signal handler will always be sync unless someone decides to do a kill from
t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83150
Bug ID: 83150
Summary: GCC's internal use of `abort`is unsafe in several ways
Product: gcc
Version: 6.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83143
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83149
Dominique d'Humieres changed:
What|Removed |Added
Priority|P3 |P4
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83149
Bug ID: 83149
Summary: ICE on SELECT CASE: crash_signal in toplev.c:325
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79929
--- Comment #26 from Dominique d'Humieres ---
Another variant without warning:
subroutine gfcbug138 (yerrmsg)
character(kind=1,len=*) :: yerrmsg
yerrmsg = 1_"bug: " // yerrmsg(1:len(yerrmsg)-5)
end subroutine gfcbug138
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79929
--- Comment #25 from Marc Glisse ---
(In reply to Dominique d'Humieres from comment #24)
> The following variant does not give the warning
That's because the code has become obfuscated enough that we don't have the
simplification l-(l+5) anymore
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81304
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|8.0 |6.5
Summary|[6/7/8 Regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79929
--- Comment #24 from Dominique d'Humieres ---
The following variant does not give the warning
subroutine gfcbug138 (yerrmsg)
character(kind=1,len=*) :: yerrmsg
character(kind=1,len=len(yerrmsg)+5) :: tmp
tmp = 1_"bug: " // yerrmsg
yerrms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83148
Dominique d'Humieres changed:
What|Removed |Added
Priority|P3 |P4
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79929
--- Comment #23 from Marc Glisse ---
(In reply to Harald Anlauf from comment #3)
> subroutine gfcbug138 (yerrmsg)
> character(kind=1,len=*) :: yerrmsg
> yerrmsg = 1_"bug: " // yerrmsg
> end subroutine gfcbug138
[...]
> gfcbug138 (character(ki
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79392
Giulio Paci changed:
What|Removed |Added
CC||giuliopaci at gmail dot com
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81304
--- Comment #5 from Jakub Jelinek ---
Author: jakub
Date: Fri Nov 24 21:40:21 2017
New Revision: 255144
URL: https://gcc.gnu.org/viewcvs?rev=255144&root=gcc&view=rev
Log:
PR fortran/81304
* trans-openmp.c (gfc_trans_omp_array_red
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83100
--- Comment #7 from James Clarke ---
(In reply to Jakub Jelinek from comment #4)
> That change looks wrong to me.
> Previously the variable was common and thus if you e.g. mixed it with some
> other TU that has const int a = 5; then you could lin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79929
Neil Carlson changed:
What|Removed |Added
CC||neil.n.carlson at gmail dot com
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83100
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83100
--- Comment #5 from Jakub Jelinek ---
I'll test:
--- gcc/varasm.c.jj 2017-11-21 20:23:02.0 +0100
+++ gcc/varasm.c2017-11-24 21:43:55.616951823 +0100
@@ -986,9 +986,9 @@ decode_reg_name (const char *name)
bool
bss_initializer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83100
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83148
Bug ID: 83148
Summary: [7.2 regression] ICE: crash_signal from toplev.c:325
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83133
--- Comment #19 from Marc Glisse ---
(In reply to Uroš Bizjak from comment #17)
> (In reply to Marc Glisse from comment #15)
> > Gcc's RTL internal representation sees the same thing for your code and for
> >
> > int diff = (unsigned)a - (unsi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81875
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49213
--- Comment #25 from Neil Carlson ---
Here's another example similar to those above but even simpler IMHO and
involving a CLASS(*) pointer component
type box
class(*), pointer :: uptr => null()
end type
integer, target :: n
call sub(box(n))
co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83135
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83146
Dominique d'Humieres changed:
What|Removed |Added
Priority|P3 |P4
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83147
Andreas Krebbel changed:
What|Removed |Added
Keywords||wrong-code
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83147
--- Comment #1 from Andreas Krebbel ---
Created attachment 42714
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42714&action=edit
Experimental patch
This patch appears to fix the problem for me. However, it isn't really tested
yet.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83147
Bug ID: 83147
Summary: LRA inheritance undo on multiple sets problem
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83133
--- Comment #18 from joseph at codesourcery dot com ---
On Fri, 24 Nov 2017, ubizjak at gmail dot com wrote:
> In the testcase, there is nothing that violates ABI. It all happens in "g"
> that
> passes calculated result to a function. Selected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83133
--- Comment #17 from Uroš Bizjak ---
(In reply to Marc Glisse from comment #15)
> Gcc's RTL internal representation sees the same thing for your code and for
>
> int diff = (unsigned)a - (unsigned)b;
>
> llvm represents both differently and g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83133
--- Comment #16 from joseph at codesourcery dot com ---
On Fri, 24 Nov 2017, maxim.yegorushkin at gmail dot com wrote:
> > It's valid to call a function in another file compiled with another
> > compiler that follows the ABI, or compiled with -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83133
--- Comment #15 from Marc Glisse ---
Gcc's RTL internal representation sees the same thing for your code and for
int diff = (unsigned)a - (unsigned)b;
llvm represents both differently and generates different code for the two.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83133
--- Comment #14 from Uroš Bizjak ---
(In reply to Maxim Egorushkin from comment #13)
> It looks like -fstrict-overflow flag is there to enable exactly this kind of
> optimization.
Yes, and it is set by default. Meaning that ALL code has to be r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49213
--- Comment #24 from Neil Carlson ---
Ping. This bug has been around for over 6 years now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83133
--- Comment #13 from Maxim Egorushkin ---
(In reply to Uroš Bizjak from comment #9)
> (In reply to Maxim Egorushkin from comment #6)
>
> > This code underflows a signed integer, which is undefined behaviour, if I am
> > not mistaken. So, this wo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83133
--- Comment #11 from Maxim Egorushkin ---
(In reply to jos...@codesourcery.com from comment #7)
> On Fri, 24 Nov 2017, maxim.yegorushkin at gmail dot com wrote:
>
> > This code underflows a signed integer, which is undefined behaviour, if I am
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83133
--- Comment #12 from Maxim Egorushkin ---
(In reply to jos...@codesourcery.com from comment #7)
> On Fri, 24 Nov 2017, maxim.yegorushkin at gmail dot com wrote:
>
> > This code underflows a signed integer, which is undefined behaviour, if I am
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81288
Segher Boessenkool changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83133
--- Comment #9 from Uroš Bizjak ---
(In reply to Maxim Egorushkin from comment #6)
> This code underflows a signed integer, which is undefined behaviour, if I am
> not mistaken. So, this would not be a valid example, would it?
An example of "da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83133
--- Comment #10 from Maxim Egorushkin ---
(In reply to Uroš Bizjak from comment #8)
> (In reply to jos...@codesourcery.com from comment #5)
> > Both 32-bit and 64-bit ABIs make the values of flags in EFLAGS (other than
> > DF) undefined on funct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81307
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83146
--- Comment #2 from Neil Carlson ---
Turns out you don't need anything at all in the associate block to get an ICE:
type foo
integer n
end type
type bar
type(foo) array(2)
end type
type(bar) b
associate (n_array => b%array%n)
end associate
e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83133
--- Comment #8 from Uroš Bizjak ---
(In reply to jos...@codesourcery.com from comment #5)
> Both 32-bit and 64-bit ABIs make the values of flags in EFLAGS (other than
> DF) undefined on function entry and return. Thus, a function can never
> a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83133
--- Comment #7 from joseph at codesourcery dot com ---
On Fri, 24 Nov 2017, maxim.yegorushkin at gmail dot com wrote:
> This code underflows a signed integer, which is undefined behaviour, if I am
> not mistaken. So, this would not be a valid ex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82621
Segher Boessenkool changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82621
--- Comment #9 from Segher Boessenkool ---
Author: segher
Date: Fri Nov 24 17:03:04 2017
New Revision: 255143
URL: https://gcc.gnu.org/viewcvs?rev=255143&root=gcc&view=rev
Log:
combine: Don't split insns if half is unused (PR82621)
If we have a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82621
--- Comment #8 from Segher Boessenkool ---
Author: segher
Date: Fri Nov 24 17:00:57 2017
New Revision: 255142
URL: https://gcc.gnu.org/viewcvs?rev=255142&root=gcc&view=rev
Log:
combine: Don't split insns if half is unused (PR82621)
If we have a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83133
--- Comment #6 from Maxim Egorushkin ---
(In reply to Uroš Bizjak from comment #3)
> (In reply to Maxim Egorushkin from comment #2)
>
> > Could you provide an example where that "dangerous optimization" would break
> > well-formed code please?
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83146
--- Comment #1 from Neil Carlson ---
I thought that assigning the select case expression to a temporary integer and
using that variable in the select case statement would be a workaround, but no.
You can put anything unrelated to the associate na
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83133
--- Comment #5 from joseph at codesourcery dot com ---
Both 32-bit and 64-bit ABIs make the values of flags in EFLAGS (other than
DF) undefined on function entry and return. Thus, a function can never
assume anything about the value of OF unle
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83133
--- Comment #4 from Uroš Bizjak ---
$ gcc --version
gcc (GCC) 7.2.1 20170915 (Red Hat 7.2.1-2)
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MER
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83133
--- Comment #3 from Uroš Bizjak ---
(In reply to Maxim Egorushkin from comment #2)
> Could you provide an example where that "dangerous optimization" would break
> well-formed code please?
--cut here--
#include
void positive (int a) { printf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83133
--- Comment #2 from Maxim Egorushkin ---
(In reply to Uroš Bizjak from comment #1)
> (In reply to Maxim Egorushkin from comment #0)
> > g function assembly contains a superflous test instruction. It should not
> > generate that instruction, since
) b
associate (n_array => b%array%n)
select case (n_array(1))
case default
end select
end associate
end
Here's the traceback
$ gfortran -c gfortran-20171124.f90
gfortran-20171124.f90:9:0:
select case (n_array(1))
internal compiler error: in gfc_get_element_type, at fortran/trans
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32306
--- Comment #36 from Jeffrey A. Law ---
Just a couple notes. I'm not currently looking at this, but this is probably
the best bug to track thoughts around how to try and capture secondary effects
of jump threading without re-running all of DOM.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71026
--- Comment #10 from Wilco ---
Author: wilco
Date: Fri Nov 24 16:03:13 2017
New Revision: 255141
URL: https://gcc.gnu.org/viewcvs?rev=255141&root=gcc&view=rev
Log:
Factor out division by squares
This patch implements the some of the division op
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83133
--- Comment #1 from Uroš Bizjak ---
(In reply to Maxim Egorushkin from comment #0)
> g function assembly contains a superflous test instruction. It should not
> generate that instruction, since sub instruction already sets all the
> required flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83143
Oleg Endo changed:
What|Removed |Added
CC||segher at kernel dot
crashing.org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83136
Jonathan Wakely changed:
What|Removed |Added
Keywords||rejects-valid
Status|UNCON
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83145
--- Comment #2 from Jonathan Wakely ---
The new rule was introduced by
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0522r0.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83145
--- Comment #1 from Jonathan Wakely ---
This is affected by the -fnew-ttp-matching option, which is enabled by default
for C++17 and disabled otherwise. You get the same error with C++14 if you use
-fnew-tpp-matching, and it compiles with C++17 a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82248
--- Comment #5 from rguenther at suse dot de ---
On Thu, 23 Nov 2017, ramana at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82248
>
> --- Comment #3 from Ramana Radhakrishnan ---
> (In reply to Richard Biener from com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80792
--- Comment #3 from Marc Glisse ---
It seems that clang have fixed their ABI to generate code similar to gcc. Any
objection to closing this?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83145
Bug ID: 83145
Summary: Ambiguous overload with templates, only GCC7 C++17
mode (regression?)
Product: gcc
Version: 7.1.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81363
Jakub Jelinek changed:
What|Removed |Added
CC||carll at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81304
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83143
--- Comment #5 from John Paul Adrian Glaubitz ---
It's fixed by adding "-freorder-blocks-algorithm=simple" which overrides
"-freorder-blocks-algorithm=stc" from "-O2".
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83015
Jan Hubicka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81360
Jan Hubicka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82802
--- Comment #3 from Marc Glisse ---
This seems fixed on trunk, and impossible to backport.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81465
Jan Hubicka changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83143
--- Comment #4 from John Paul Adrian Glaubitz ---
Building with "-O0" instead of "-O2" resolves the issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83143
--- Comment #3 from John Paul Adrian Glaubitz ---
Created attachment 42710
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42710&action=edit
Generated object for nir_lower_int64.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83141
--- Comment #2 from Richard Biener ---
https://gcc.gnu.org/ml/gcc-patches/2017-11/msg02199.html regresses
gfortran.dg/pr45636.f90 because Jakubs pattern matching in
tree-ssa-forwprop.c:simplify_builtin_call no longer applies ... (we fold more
mem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83144
Bug ID: 83144
Summary: ICE using trailing return type and constexpr with GCC
7.X
Product: gcc
Version: 7.2.0
Status: UNCONFIRMED
Severity: normal
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83143
--- Comment #2 from John Paul Adrian Glaubitz ---
Created attachment 42708
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42708&action=edit
Generated assembly for nir_lower_int64.c (gzipped)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83143
--- Comment #1 from John Paul Adrian Glaubitz ---
Created attachment 42707
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42707&action=edit
Intermediate source for nir_lower_int64.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83143
Bug ID: 83143
Summary: [SH]: Assembler messages: invalid operands (*UND* and
.text sections) for `-'
Product: gcc
Version: 7.2.0
Status: UNCONFIRMED
Severity: n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83142
Bug ID: 83142
Summary: Missed tail-call opportunity
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82991
Richard Biener changed:
What|Removed |Added
Depends on||83142
--- Comment #5 from Richard Biene
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82991
--- Comment #4 from Richard Biener ---
Created attachment 42705
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42705&action=edit
patch
Things got stuck on _b_o_s fallout. See
https://gcc.gnu.org/ml/gcc-patches/2017-11/msg02113.html and fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82402
--- Comment #9 from Richard Biener ---
Author: rguenth
Date: Fri Nov 24 12:34:23 2017
New Revision: 255140
URL: https://gcc.gnu.org/viewcvs?rev=255140&root=gcc&view=rev
Log:
2017-11-24 Richard Biener
PR tree-optimization/82402
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79008
Eric Gallager changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|2017-08-22 00:00:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82402
Richard Biener changed:
What|Removed |Added
Known to work||8.0
Summary|[6/7/8 Regressio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81406
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81470
--- Comment #3 from Rainer Emrich ---
(In reply to Jakub Jelinek from comment #2)
> Is this still a problem? At least on x86_64-linux many people have done
> many successful bootstraps with ada since then.
I will test next week, when I find the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81456
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81535
--- Comment #6 from Yury Gribov ---
(In reply to Jakub Jelinek from comment #5)
> Any progress with this?
I filed patch back then
(https://gcc.gnu.org/ml/gcc-patches/2017-07/msg01873.html) and missed reply
from Segher. I'll reply to his comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83141
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81465
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81470
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81535
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83015
--- Comment #19 from Jan Hubicka ---
Author: hubicka
Date: Fri Nov 24 11:24:55 2017
New Revision: 255138
URL: https://gcc.gnu.org/viewcvs?rev=255138&root=gcc&view=rev
Log:
PR bootstrap/83015
* ipa-inline.c (inline_small_function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83141
Bug ID: 83141
Summary: SRA and memcpy folding interact badly generating
wrong-code
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Keywords: wrong-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81553
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81675
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
1 - 100 of 121 matches
Mail list logo
