https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86575
--- Comment #8 from Eric Gallager ---
(In reply to Michael Matz from comment #7)
> As I stated, it's only fixed in trunk, so it's still a regression in 7 and 8,
> as marked in the summary.
But you also said you weren't planning on backporting th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91593
--- Comment #8 from Eric Gallager ---
(In reply to Jerry DeLisle from comment #7)
> Author: jvdelisle
> Date: Wed Oct 2 02:35:14 2019
> New Revision: 276439
>
> URL: https://gcc.gnu.org/viewcvs?rev=276439&root=gcc&view=rev
> Log:
> 2019-10-01
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60591
--- Comment #5 from Eric Gallager ---
(In reply to Eric Gallager from comment #2)
> There are several other bugs open like this one, such as bug 78736
This is fixed now. It's probably still worth checking some of the other bugs
under its "See Al
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52763
Eric Gallager changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78736
Eric Gallager changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403
Bug 87403 depends on bug 78736, which changed state.
Bug 78736 Summary: enum warnings in GCC (request for -Wenum-conversion to be
added)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78736
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=7654
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77404
Eric Gallager changed:
What|Removed |Added
CC||mikestump at comcast dot net
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82240
Eric Gallager changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86518
--- Comment #12 from Eric Gallager ---
(In reply to Jonathan Wakely from comment #11)
> (In reply to Eric Gallager from comment #10)
> > If this is becoming the meta-bug for all warnings that affect codegen, then
> > I'd like to add bug 61579 (-W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888
--- Comment #42 from Eric Gallager ---
(In reply to Rich Felker from comment #41)
> > Josef Wolf mentioned that he ran into this on the gcc-help mailing list
> > here: https://gcc.gnu.org/ml/gcc-help/2019-10/msg00079.html
>
> I don't think that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60540
Oleg Endo changed:
What|Removed |Added
Target|sh*-*-* |
--- Comment #12 from Oleg Endo ---
(In rep
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92157
Martin Sebor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83819
Bug 83819 depends on bug 92157, which changed state.
Bug 92157 Summary: [10 Regression] incorrect strcmp() == 0 result for unknown
strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92157
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92155
--- Comment #4 from Martin Sebor ---
Author: msebor
Date: Fri Oct 18 22:26:39 2019
New Revision: 277194
URL: https://gcc.gnu.org/viewcvs?rev=277194&root=gcc&view=rev
Log:
PR tree-optimization/92157 - incorrect strcmp() == 0 result for unknown st
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92157
--- Comment #2 from Martin Sebor ---
Author: msebor
Date: Fri Oct 18 22:26:39 2019
New Revision: 277194
URL: https://gcc.gnu.org/viewcvs?rev=277194&root=gcc&view=rev
Log:
PR tree-optimization/92157 - incorrect strcmp() == 0 result for unknown st
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92140
--- Comment #25 from Jakub Jelinek ---
The define_insn part of define_insn_and_split needs constraints if it is meant
to match during or after reload, the patterns are just written with the
assumption that they are split before reload. At least
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92140
--- Comment #24 from Segher Boessenkool ---
A dumb question I'm sure, but I don't see it: if the rest of your
define_insn doesn't need constraints, why would the match_scratch
need some? (A define_split never uses constraints).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92155
--- Comment #3 from Martin Sebor ---
Actually, the memcpy is transformed to MEM_REF and the strlen pass knows how to
deal with a subset of those (small powers of 2). What it doesn't know how to
do yet is deal with other sizes like in the test ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92155
--- Comment #2 from Martin Sebor ---
The inequality (__builtin_strlen (a4) != 0) is folded into (a4[0] != 0) very
early on during Gimplification so the strlen pass never sees it.
What the strlen pass should be able to do is fold strlen(a4) below
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92155
prathamesh3492 at gcc dot gnu.org changed:
What|Removed |Added
CC||prathamesh3492 at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92157
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92157
Bug ID: 92157
Summary: incorrect strcmp() == 0 result for unknown strings
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92140
--- Comment #23 from Jakub Jelinek ---
(In reply to Segher Boessenkool from comment #22)
> Hrm, I don't see how this is nicer than just adding a scratch in the
> pattern? What makes that a worse option?
Most of the patterns don't have constrain
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92156
Bug ID: 92156
Summary: Cannot in-place construct std::any with std::any
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92140
--- Comment #22 from Segher Boessenkool ---
Hrm, I don't see how this is nicer than just adding a scratch in the
pattern? What makes that a worse option?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92155
Bug ID: 92155
Summary: strlen(a) not folded after memset(a, 0, sizeof a)
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91929
Dmitry G. Dyachenko changed:
What|Removed |Added
CC||dimhen at gmail dot com
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69455
kargl at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69455
--- Comment #19 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Fri Oct 18 19:26:22 2019
New Revision: 277193
URL: https://gcc.gnu.org/viewcvs?rev=277193&root=gcc&view=rev
Log:
2019-10-18 Steven G. Kargl
PR fortran/69455
The following C code:
unsigned int wrong(unsigned int n){
return (n%2) ? 0 : 42;
}
should return 42 when n is odd and 0 when n is even.
But ARM gcc 8.2 with -O3 produces following assembly:
tst r0, #1
moveq r0, #42
movne r0, #0
bx lr
tst r0,#1 sets Z=1 iff r0 is even, and moveq r0,#42 executes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92056
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60540
--- Comment #11 from Harald van Dijk ---
(In reply to Rich Felker from comment #10)
> On this particular target, and on every target of any modern
> relevance, (float)16777217 has well-defined behavior.
That was exactly the point of my original
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60540
--- Comment #10 from Rich Felker ---
GCC can choose the behavior for any undefined behavior it wants, and GCC
absolutely can make transformations based on behaviors it guarantees or that
Annex F guarantees on targets for which it implements the r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60540
--- Comment #9 from Harald van Dijk ---
(In reply to Rich Felker from comment #8)
> So arguments about generality to non-Annex-F C
> environments are not relevant to the topic here.
The comment it was a reply to suggested (possibly unintentional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69455
--- Comment #18 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Fri Oct 18 18:18:34 2019
New Revision: 277161
URL: https://gcc.gnu.org/viewcvs?rev=277161&root=gcc&view=rev
Log:
2019-10-18 Steven G. Kargl
PR fortran/69455
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60540
--- Comment #8 from Rich Felker ---
> Floating point types are not guaranteed to support infinity by the C standard
Annex F (IEEE 754 alignment) does guarantee it, and GCC aims to implement this.
This issue report is specific to target sh*-*-* w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60540
--- Comment #7 from Harald van Dijk ---
(In reply to Rich Felker from comment #6)
> > Only if the int is out of float's range.
>
> float's range is [-INF,INF] (endpoints included). There is no such thing as
> "out of float's range".
Floating po
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69455
--- Comment #17 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Fri Oct 18 17:59:32 2019
New Revision: 277160
URL: https://gcc.gnu.org/viewcvs?rev=277160&root=gcc&view=rev
Log:
2019-10-18 Steven G. Kargl
PR fortran/69455
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69455
--- Comment #16 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Fri Oct 18 17:27:06 2019
New Revision: 277158
URL: https://gcc.gnu.org/viewcvs?rev=277158&root=gcc&view=rev
Log:
2019-10-18 Steven G. Kargl
PR fortran/69455
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92149
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92153
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92153
--- Comment #1 from Jakub Jelinek ---
Author: jakub
Date: Fri Oct 18 17:18:21 2019
New Revision: 277157
URL: https://gcc.gnu.org/viewcvs?rev=277157&root=gcc&view=rev
Log:
PR middle-end/92153
* ggc-page.c (release_pages): Read g->
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888
--- Comment #41 from Rich Felker ---
> Josef Wolf mentioned that he ran into this on the gcc-help mailing list here:
> https://gcc.gnu.org/ml/gcc-help/2019-10/msg00079.html
I don't think that's an instance of this issue. It's normal/expected th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92153
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
Target Milest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92154
--- Comment #1 from Jakub Jelinek ---
If it has landed upstream already, please post the backport of it to
gcc-patches.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888
--- Comment #40 from Eric Gallager ---
Josef Wolf mentioned that he ran into this on the gcc-help mailing list here:
https://gcc.gnu.org/ml/gcc-help/2019-10/msg00079.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92140
--- Comment #21 from Jakub Jelinek ---
Created attachment 47069
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47069&action=edit
gcc10-prereload-splitters.patch
Ah, apparently we already have for ~ 2 years a property to handle this safely.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92140
--- Comment #20 from Segher Boessenkool ---
Ah, okay. So it is either one or two insns (zero can not be handled, but you
can do a noop, a move of a reg to itself, and that will be optimised away just
fine). Three insns is not something combine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90231
--- Comment #19 from Jakub Jelinek ---
Created attachment 47068
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47068&action=edit
gcc10-pr90231.patch
Untested implementation of what I wrote above.
The difference on the testcase at -O2 -g is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60540
Rich Felker changed:
What|Removed |Added
CC||bugdal at aerifal dot cx
--- Comment #6 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12306
Rich Felker changed:
What|Removed |Added
CC||bugdal at aerifal dot cx
--- Comment #8 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92154
Bug ID: 92154
Summary: new glibc breaks arm bootstrap due to libsanitizer
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92140
--- Comment #19 from Uroš Bizjak ---
(In reply to Segher Boessenkool from comment #18)
> (In reply to Uroš Bizjak from comment #15)
> > Is it possible to lift the limitation from the combine pass, where the
> > combine tries to split the insn, bu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92153
Bug ID: 92153
Summary: [10 Regression] ICE / segmentation fault,
use-after-free at gcc/ggc-page.c:1159
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92140
--- Comment #18 from Segher Boessenkool ---
(In reply to Uroš Bizjak from comment #15)
> Is it possible to lift the limitation from the combine pass, where the
> combine tries to split the insn, but expects exactly two new insn patterns
> to be g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92152
--- Comment #1 from Georg-Johann Lay ---
configure:
Target: avr
Configured with: ../../gcc.gnu.org/trunk/configure --target=avr
--prefix=/local/gnu/install/gcc-10 --disable-shared --disable-nls --with-dwarf2
--enable-target-optspace=yes --with-g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92152
Bug ID: 92152
Summary: [10 Regression] Wring code (Resurrection of PR53663)
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92140
--- Comment #17 from Jakub Jelinek ---
I've tried to change the patch to use define_split instead of
define_insn_and_split, with all of them changed, it creates worse code for
f8/f12/f15 (the last one is expected, because we split into 3 instruct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91941
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92140
--- Comment #16 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #13)
> Created attachment 47067 [details]
> gcc10-pr92140.patch
>
> So what about this version then? I've changed back a couple of
> to nonimmediate_operand and remov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91941
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92136
--- Comment #3 from Marek Polacek ---
Same issue with an explicit deduction guide:
template
class Base {};
template
class Test1 : public Base>
{
public:
Test1() = default;
template typename T>
Test1(Base> const &) {}
};
template typ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92140
--- Comment #15 from Uroš Bizjak ---
(In reply to Segher Boessenkool from comment #12)
> (In reply to Uroš Bizjak from comment #10)
> > Regarding reliability of pre-reload splitters, IIRC they should be safe, but
> > I'll leave the final verdict
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92140
--- Comment #14 from Jakub Jelinek ---
And as for the define_insn_and_split without constraints that don't expect to
be matched post split1, I think we can try to figure out something
incrementally and change all of them at once, e.g. a property
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92140
--- Comment #13 from Jakub Jelinek ---
Created attachment 47067
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47067&action=edit
gcc10-pr92140.patch
So what about this version then? I've changed back a couple of
to nonimmediate_operand a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92140
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92140
--- Comment #11 from Segher Boessenkool ---
If an insn condition uses can_create_pseudo_p, the insn will suddenly stop
to match after reload --> kaboom.
If your insn always splits ("&& 1"), this means that if any of these:
NEXT_PASS (pass_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92151
Bug ID: 92151
Summary: Spurious register copying
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: inline-asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92140
--- Comment #10 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #9)
> Created attachment 47065 [details]
> gcc10-pr92140-wip.patch
>
> If pre-reload splitters are reliable, my patch can be greatly simplified and
> using the formatti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92140
--- Comment #9 from Jakub Jelinek ---
Created attachment 47065
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47065&action=edit
gcc10-pr92140-wip.patch
If pre-reload splitters are reliable, my patch can be greatly simplified and
using the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91586
Tobias Burnus changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91586
--- Comment #2 from Tobias Burnus ---
Author: burnus
Date: Fri Oct 18 12:38:26 2019
New Revision: 277154
URL: https://gcc.gnu.org/viewcvs?rev=277154&root=gcc&view=rev
Log:
Fortran] PR91586 Fix ICE on invalid code with CLASS
gcc/fortran/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92140
--- Comment #8 from Jakub Jelinek ---
Comparing the two patches, your patch handles f1-f4 in
/* PR target/92140 */
char c;
int v;
__attribute__((noipa)) void f1 (void) { v += c != 0; }
__attribute__((noipa)) void f2 (void) { v -= c != 0; }
__at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92150
Bug ID: 92150
Summary: Partial specializations of class templates with class
NTTP fails
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92140
--- Comment #7 from Uroš Bizjak ---
Created attachment 47064
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47064&action=edit
Proposed patch with pre-reload splitters
Maybe we should use pre-reload splitters as with the attached patch that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91586
--- Comment #1 from Tobias Burnus ---
Author: burnus
Date: Fri Oct 18 12:04:31 2019
New Revision: 277153
URL: https://gcc.gnu.org/viewcvs?rev=277153&root=gcc&view=rev
Log:
Fortran] PR91586 Fix ICE on invalid code with CLASS
gcc/fortran/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92143
--- Comment #6 from Jonathan Wakely ---
Author: redi
Date: Fri Oct 18 11:27:31 2019
New Revision: 277151
URL: https://gcc.gnu.org/viewcvs?rev=277151&root=gcc&view=rev
Log:
PR libstdc++/92143 adjust for OS X aligned_alloc behaviour
OS X 10.15 ad
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92143
--- Comment #7 from Jonathan Wakely ---
Fixed on trunk so far, but I'll backport it too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92149
--- Comment #3 from Maxim Egorushkin ---
System V ABI doesn't seem to require unused bytes to contain any specific
value.
There is a specific note for _Bool: When a value of type _Bool is returned or
passed in a register or on the stack, bit 0 c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92140
Jakub Jelinek changed:
What|Removed |Added
Attachment #47062|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92149
--- Comment #2 from Maxim Egorushkin ---
I notice that g++ always zeros out unused high-order bits. Clang++ never does.
Both follow the same System V ABI.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92149
Andrew Pinski changed:
What|Removed |Added
Keywords||ABI, missed-optimization
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92149
Bug ID: 92149
Summary: Enefficient x86_64 code
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92148
Bug ID: 92148
Summary: gm2: race condition building gm2 on trunk
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: modula2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92140
--- Comment #5 from Jakub Jelinek ---
The patch adds 144 define_insn and 144 define_split to tmp-mddump.md though, to
total 6217 define_insn and 733 define_split.
Maybe a better way to deal with it would be to have x86_ne_0_operator and
x86_eq_0_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92147
Bug ID: 92147
Summary: gm2: modula-2 fails to build on powerpc-linux-gnu
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92140
--- Comment #4 from Jakub Jelinek ---
Created attachment 47062
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47062&action=edit
gcc10-pr92140-wip.patch
Slightly extended untested patch, which handles all the cases in the testcase
at the st
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92146
Bug ID: 92146
Summary: gm2: the brig, fortran, go and D frontends are missing
lang_register_spec_functions
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92143
Jonathan Wakely changed:
What|Removed |Added
Status|WAITING |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92071
--- Comment #2 from David Binderman ---
Here is some reduced C code which demonstrates the problem:
a;
union b {
double c;
char d[8]
} e() {
union b b;
memcpy(b.d, a, 8);
f(b);
}
Flag -O2 required.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86040
Georg-Johann Lay changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86040
--- Comment #10 from Georg-Johann Lay ---
Author: gjl
Date: Fri Oct 18 09:16:16 2019
New Revision: 277149
URL: https://gcc.gnu.org/viewcvs?rev=277149&root=gcc&view=rev
Log:
Backport from 2019-10-18 trunk r277143.
PR target/86040
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86040
--- Comment #9 from Georg-Johann Lay ---
Author: gjl
Date: Fri Oct 18 09:12:34 2019
New Revision: 277148
URL: https://gcc.gnu.org/viewcvs?rev=277148&root=gcc&view=rev
Log:
Backport from 2019-10-18 trunk r277143.
PR target/86040
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86040
--- Comment #8 from Georg-Johann Lay ---
Author: gjl
Date: Fri Oct 18 09:10:20 2019
New Revision: 277147
URL: https://gcc.gnu.org/viewcvs?rev=277147&root=gcc&view=rev
Log:
Backport from 2019-10-18 trunk r277143.
PR target/86040
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91165
--- Comment #2 from David Binderman ---
Three months later, still broken.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59888
--- Comment #20 from Iain Sandoe ---
Author: iains
Date: Fri Oct 18 08:42:41 2019
New Revision: 277145
URL: https://gcc.gnu.org/viewcvs?rev=277145&root=gcc&view=rev
Log:
[Darwin] Amend section for constants with relocations.
Darwin's linker doe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91532
--- Comment #3 from rsandifo at gcc dot gnu.org
---
I think it'd be good to add a testcase for this, assuming that
it's now fixed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86753
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolutio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92131
Eric Botcazou changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
1 - 100 of 104 matches
Mail list logo
