https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88181
Bug ID: 88181
Summary: ICE: verify_type failed (error: type variant differs
by TYPE_PACKED)
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: ice-checking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88180
Bug ID: 88180
Summary: ICE in vec::quick_push(tree_node* const&)
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39385
Arseny Solokha changed:
What|Removed |Added
CC||asolokha at gmx dot com
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87011
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #3 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88179
Bug ID: 88179
Summary: [9 regression][MIPS] pr84941.c ICE in
lra_eliminate_reg_if_possible at
lra-eliminations.c:1393 start with r266385
Product: gcc
Version: 9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87468
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87468
--- Comment #7 from Jeffrey A. Law ---
Author: law
Date: Sat Nov 24 06:51:26 2018
New Revision: 266426
URL: https://gcc.gnu.org/viewcvs?rev=266426&root=gcc&view=rev
Log:
PR rtl-optimization/87468
* tree-ssa-threadupdate.c (create
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88178
Bug ID: 88178
Summary: [9 Regression] ICE in dbx_reg_number, at
dwarf2out.c:13659
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88141
--- Comment #4 from Joshua Morrison ---
The issue's also occurring for me with the latest revision of the GCC 8 branch.
Is there a step that I'm missing during the build?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85569
--- Comment #7 from Alexandre Oliva ---
I realized the preprocessed testcase was the work-around rather than the base
failure mode. What confused me was that even the work-around was failing, and
that's what my patch is for.
https://gcc.gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86397
--- Comment #3 from Alexandre Oliva ---
https://gcc.gnu.org/ml/gcc-patches/2018-11/msg01970.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79996
--- Comment #7 from Jonathan Wakely ---
(In reply to Eric Gallager from comment #6)
> Well, I guess it's probably too late to go back on it now, but I thought
> warnings enabled by default weren't supposed to have any false positives,
> and this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88175
--- Comment #7 from Jonathan Wakely ---
(In reply to Andrew Pinski from comment #3)
> > string dummy; // for some reason this is needed to force the error to be
> > shown as header.h:8:16:
>
> causes the struct to be a non-POD and the copy con
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88175
--- Comment #6 from Jonathan Wakely ---
i.e. this would be wrong, because there is not 'copy' in test(info_t).
> So would be better if it was as follows:
> ===
>
> $ g++ -O2 -Werror=uninitialized -o h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88175
--- Comment #5 from Jonathan Wakely ---
(In reply to Jonny Grant from comment #4)
> Also, it is "copy" that is unused uninitialized? (not "temp")
Yes, in the test(info_t) function, which is what GCC says:
header.h: In function ‘void test(info_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85930
Jonathan Wakely changed:
What|Removed |Added
CC||semi1 at posteo dot de
--- Comment #11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88177
--- Comment #2 from Jonathan Wakely ---
Oops I marked it as a dup of the wrong bug number.
*** This bug has been marked as a duplicate of bug 85930 ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87520
Jonathan Wakely changed:
What|Removed |Added
CC||semi1 at posteo dot de
--- Comment #9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88177
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88177
Bug ID: 88177
Summary: Calng detectes undefined behavior in shared_ptr_base.h
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16615
--- Comment #8 from sandra at gcc dot gnu.org ---
Right, I was expecting there would be a few of them that grep/sed would miss
because of line breaks. I can hand-patch the ones I can find, but it's not the
end of the world if a few escape -- it's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54265
--- Comment #3 from sandra at gcc dot gnu.org ---
OK, if there is an actual rationale for the preferred position and it wasn't
just an accidental extrapolation, I will change the examples to conform to that
instead. Maybe also include the rationa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59075
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88176
Bug ID: 88176
Summary: Overload resolution chooses template non-member
operator over non-template member operator
Product: gcc
Version: 9.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79996
--- Comment #6 from Eric Gallager ---
(In reply to Martin Liška from comment #5)
> (In reply to Eric Gallager from comment #4)
> > (In reply to Eric Gallager from comment #3)
> > > Might want to revisit this now that -Wreturn-type is on by defaul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88175
--- Comment #4 from Jonny Grant ---
Also, it is "copy" that is unused uninitialized? (not "temp")
The line carat is also incorrect I believe, it should be header.cpp:10:12 ?
So would be better if it was as follows:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88175
--- Comment #3 from Andrew Pinski ---
> string dummy; // for some reason this is needed to force the error to be
> shown as header.h:8:16:
causes the struct to be a non-POD and the copy constructor to be created
differently.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87902
--- Comment #7 from Ilya Leoshkevich ---
Apparently, for this specific case doing more of hard register copy
propagation is enough. I've just tried running pass_cprop_hardreg
before pass_thread_prologue_and_epilogue, and it helped.
So, would ru
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88175
--- Comment #2 from Jonny Grant ---
Created attachment 45077
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45077&action=edit
testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88175
--- Comment #1 from Jonny Grant ---
Edit header.h to comment out this line, and the issue disapears.
string dummy; // for some reason this is needed to force the error to be
shown as header.h:8:16:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88175
Bug ID: 88175
Summary: Showing header file instead of source code line in
error
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87106
--- Comment #14 from Marc Glisse ---
(In reply to Arthur O'Dwyer from comment #13)
> Re https://gcc.gnu.org/viewcvs?rev=266386&root=gcc&view=rev — awesome, but
> I'm curious: Why `deque` before `vector`?
> I mean are you planning eventually to ad
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88157
--- Comment #6 from Vladimir Makarov ---
Author: vmakarov
Date: Fri Nov 23 22:00:43 2018
New Revision: 266422
URL: https://gcc.gnu.org/viewcvs?rev=266422&root=gcc&view=rev
Log:
2018-11-23 Vladimir Makarov
PR bootstrap/88157
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87106
--- Comment #13 from Arthur O'Dwyer ---
Re https://gcc.gnu.org/viewcvs?rev=266386&root=gcc&view=rev — awesome, but I'm
curious: Why `deque` before `vector`?
I mean are you planning eventually to add the specializations of
`__is_trivially_relocata
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87756
--- Comment #5 from Jakub Jelinek ---
Author: jakub
Date: Fri Nov 23 21:13:44 2018
New Revision: 266420
URL: https://gcc.gnu.org/viewcvs?rev=266420&root=gcc&view=rev
Log:
PR tree-optimization/87756
* gcc.dg/builtin-memchr-2.c: Sc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88047
--- Comment #3 from janus at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #2)
> The following patch restores the errors
It doesn't seem to cause any regressions in the testsuite either. Feel free to
commit this fix, Dominiqu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54265
--- Comment #2 from joseph at codesourcery dot com ---
The earlier position is preferred because logically at the closing brace
the type should be fully defined and it should no longer be possible to
change properties of it through attributes c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88173
--- Comment #4 from joseph at codesourcery dot com ---
An ordered comparison (< <= > >=) with qNaN raises the "invalid"
exception. An equality comparison (== !=) does not, and nor do
__builtin_isless etc.
I don't know how C++ constexpr rules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86832
Moritz Bunkus changed:
What|Removed |Added
CC||moritz at bunkus dot org
--- Comment #13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88155
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88174
--- Comment #1 from Marc Glisse ---
(In reply to emsr from comment #0)
> While updating libstdc++ for constexpr operators I came across this:
> __real__ _M_value += __z.real();
> is not constexpr even though
> __real__ _M_value = __z.real
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54265
sandra at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86900
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86917
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88169
--- Comment #6 from kargl at gcc dot gnu.org ---
(In reply to Neil Carlson from comment #5)
> Stated a bit more clearly, the question is, whether in
>
> The namelist-group-name shall not be a name accessed by use association.
>
> the name (in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87756
Martin Sebor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87756
--- Comment #3 from Martin Sebor ---
Author: msebor
Date: Fri Nov 23 18:45:45 2018
New Revision: 266418
URL: https://gcc.gnu.org/viewcvs?rev=266418&root=gcc&view=rev
Log:
PR tree-optimization/87756 - missing unterminated argument warning using
a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88174
Bug ID: 88174
Summary: Make __real__ += __val usable in constexpr context.
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88173
--- Comment #3 from Marc Glisse ---
-fno-trapping-math is relevant. Gcc believes that comparing QNaN to something
requires setting a flag in fenv, which can only be done at runtime. I expect
that's wrong, or almost any operation on double would n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88169
--- Comment #5 from Neil Carlson ---
Stated a bit more clearly, the question is, whether in
The namelist-group-name shall not be a name accessed by use association.
the name (in the scope of the declaration) is accessed by use association,
or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86905
--- Comment #4 from Jakub Jelinek ---
extern "C" inline void foo () {}
static void bar () __attribute__((__weakref__("foo")));
void baz () { bar (); }
I've tried to:
--- cgraph.h.jj 2018-11-09 21:16:44.792168407 +0100
+++ cgraph.h2018-11-23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88098
Martin Sebor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88098
--- Comment #3 from Martin Sebor ---
Author: msebor
Date: Fri Nov 23 18:23:31 2018
New Revision: 266417
URL: https://gcc.gnu.org/viewcvs?rev=266417&root=gcc&view=rev
Log:
PR testsuite/88098 - FAIL: gcc.dg/Wbuiltin-declaration-mismatch-4.c
gcc/c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88098
Martin Sebor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88169
--- Comment #4 from Neil Carlson ---
I think the intent of
C8102 (R868) The namelist-group-name shall not be a name accessed by use
association.
is to say you can't define a namelist with a name accessed by use association.
That seems to fit be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88173
--- Comment #2 from Christoph Conrads ---
Created attachment 45076
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45076&action=edit
Code pre-processed with GCC 6.3.0 on Raspbian 9.4
The file was created with
$ g++ -Wextra -Wall -std=c++11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86905
Jakub Jelinek changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88173
--- Comment #1 from Christoph Conrads ---
Created attachment 45075
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45075&action=edit
Code pre-processed with GCC 7.3.0 on Ubuntu 18.04 LTS
This file was created with
$ g++ -Wextra -Wall -std=c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88171
Ian Lance Taylor changed:
What|Removed |Added
CC||bergner at vnet dot ibm.com,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88173
Bug ID: 88173
Summary: `std::numeric_limits::quiet_NaN()` is not
constexpr
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88172
Martin Sebor changed:
What|Removed |Added
Keywords||accepts-invalid
--- Comment #1 from Marti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87296
--- Comment #5 from Jakub Jelinek ---
The MEM_REF type is significant only when actually accessing that memory, for
&MEM_REF[...]; it is insignificant and you really shouldn't assume anything
from it except for the address computation (like if it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88172
Bug ID: 88172
Summary: attribute aligned of zero silently accepted but
ignored
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87308
--- Comment #3 from Jeff Garrett ---
That's such a good point about the local types in general.
Considering that the gdb python API seems to prefer readable names, e.g. for
lookup, and those are not standard nor unique, might it be perhaps prefe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86943
--- Comment #9 from Jonathan Wakely ---
See the glambda example in
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3649.html
Core 1937 seems relevant here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86943
--- Comment #8 from Jonathan Wakely ---
The non-normative note in [expr.prim.lambda.closure] p8 does seem to support
GCC's semantics. It suggests the returned function pointer is to an invoker
function not the operator() itself. The {} initialize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88169
--- Comment #3 from kargl at gcc dot gnu.org ---
(In reply to kargl from comment #1)
> Fortran 95 contains
>
> NOTE 11.8
>
> The constraints in sections 5.5.1, 5.5.2, and 5.4 prohibit the local-name
> from appearing as a common-block-object in a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85861
--- Comment #11 from Jonathan Wakely ---
My guess is that we don't want to warn about conversions that are well-defined
and the original value can be obtained by a round-trip. Converting a size_t to
an int is lossy, i.e. converting back to size_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87296
--- Comment #4 from Martin Sebor ---
The MEM_REF type must mean something, otherwise why have it at all? (If it's
completely meaningless it could/should just be null or void or error_mark_node
instead to prevent using it.) Is it just that array
20181123, r266404:
during RTL pass: reload
../../../../src/libgo/go/encoding/gob/decode.go: In function
'gob.decodeSlice..1encoding/gob.Decoder':
../../../../src/libgo/go/encoding/gob/decode.go:613:1: internal compiler error:
Maximum number of LRA assignment passes is achieved (30)
613 |
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86943
--- Comment #7 from Jakub Jelinek ---
--- gcc/cp/cp-gimplify.c.jj 2018-11-17 00:16:41.924381941 +0100
+++ gcc/cp/cp-gimplify.c2018-11-23 17:29:24.764459373 +0100
@@ -1108,6 +1108,18 @@ cp_genericize_r (tree *stmt_p, int *walk
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86943
--- Comment #6 from Jonathan Wakely ---
I might be wrong about the C++14 rules ... maybe the {} initializer should
directly initialize the parameter, without any move.
I don't know if we need to fix the incorrect argument to the move constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86943
Jonathan Wakely changed:
What|Removed |Added
Summary|[8/9 Regression] Wrong code |[7/8/9 Regression] Wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86943
--- Comment #4 from Jonathan Wakely ---
I haven't analyzed the code to say what it should do, but EDG agrees with
Clang.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86943
--- Comment #3 from Jakub Jelinek ---
And, note that clang 5/6 don't call the move ctor at all and only one dtor.
What is correct?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86943
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65229
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65229
--- Comment #2 from Jonathan Wakely ---
Author: redi
Date: Fri Nov 23 16:12:03 2018
New Revision: 266409
URL: https://gcc.gnu.org/viewcvs?rev=266409&root=gcc&view=rev
Log:
PR libstdc++/65229 fix pretty printer for std::bitset<0>
2018-11-23 Mar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85861
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comment #10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88169
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88166
--- Comment #5 from Jonathan Wakely ---
Author: redi
Date: Fri Nov 23 15:48:56 2018
New Revision: 266408
URL: https://gcc.gnu.org/viewcvs?rev=266408&root=gcc&view=rev
Log:
PR libstdc++/87308 adjust regex used in std::any pretty printer
The pret
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87308
--- Comment #2 from Jonathan Wakely ---
Author: redi
Date: Fri Nov 23 15:48:56 2018
New Revision: 266408
URL: https://gcc.gnu.org/viewcvs?rev=266408&root=gcc&view=rev
Log:
PR libstdc++/87308 adjust regex used in std::any pretty printer
The pret
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88169
kargl at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86832
--- Comment #12 from John Warburton ---
On Fri, Nov 23, 2018 at 11:26 AM John Warburton wrote:
>
> On Thu, Nov 22, 2018 at 10:09 AM jakub at gcc dot gnu.org
> wrote:
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86832
> >
> > --- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87645
Martin Liška changed:
What|Removed |Added
Keywords|needs-bisection |
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88170
Bug ID: 88170
Summary: pretty printer FAILs
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88167
Thomas Preud'homme changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86952
Martin Liška changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #8 from Martin Liška
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86952
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88169
Bug ID: 88169
Summary: Rejects USE rename of namelist group
Product: gcc
Version: 8.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87296
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83372
Martin Liška changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86952
--- Comment #6 from Martin Liška ---
(In reply to H.J. Lu from comment #5)
> (In reply to Martin Liška from comment #4)
> > (In reply to H.J. Lu from comment #3)
> > > (In reply to Martin Liška from comment #2)
> > > > H.J. I can write a patch fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87305
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87304
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86952
--- Comment #5 from H.J. Lu ---
(In reply to Martin Liška from comment #4)
> (In reply to H.J. Lu from comment #3)
> > (In reply to Martin Liška from comment #2)
> > > H.J. I can write a patch for it. Do you expect more expensive costs when
> > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87836
--- Comment #19 from Gary Mills ---
The reason that OI-SPARC uses the native assembler is the same as in Fiddler
on the Roof: tradition. Actually, there are some kernel files written in SPARC
assembly language. These only compile with the nativ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87727
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87788
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
Target Milest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88166
Jonathan Wakely changed:
What|Removed |Added
Resolution|INVALID |FIXED
--- Comment #4 from Jonathan Wak
1 - 100 of 194 matches
Mail list logo
