https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89402
--- Comment #4 from Jakub Jelinek ---
Author: jakub
Date: Wed Feb 20 07:57:41 2019
New Revision: 269034
URL: https://gcc.gnu.org/viewcvs?rev=269034=gcc=rev
Log:
PR libstdc++/89402
* src/c++98/compatibility-ldbl.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89412
Bug ID: 89412
Summary: [8 Regression] bootstrap fails in libgfortran on
powerpc64le-linux-gnu
Product: gcc
Version: 8.2.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67064
--- Comment #33 from Sebastian Huber ---
(In reply to Eric Gallager from comment #32)
> (In reply to Martin Liška from comment #31)
> > Can the bug be marked as resolved?
>
> WAITING on a reply.
From my point of view it is fixed
I guess since
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89401
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Component|c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89170
--- Comment #1 from Ian Lance Taylor ---
I think this is due to an old bug in const_desc_htab. output_constant_def will
insert a value into const_desc_htab. If the hash table already has an entry
with the same hash value, this will cause the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89397
--- Comment #4 from H.J. Lu ---
(In reply to jos...@codesourcery.com from comment #3)
> On Tue, 19 Feb 2019, marxin at gcc dot gnu.org wrote:
>
> > Before the revision it was rejected with:
> >
> > atomic2.c: In function ‘func’:
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87513
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88100
--- Comment #4 from Li Jia He ---
Author: helijia
Date: Wed Feb 20 02:35:39 2019
New Revision: 269033
URL: https://gcc.gnu.org/viewcvs?rev=269033=gcc=rev
Log:
[rs6000] fix PR 88100, range check for vec_splat_{su}{8,16,32}
GCC revision 259524
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87921
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88380
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89285
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88368
Jason Merrill changed:
What|Removed |Added
Summary|[7/8/9 Regression] Improper |[7/8 Regression] Improper
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88368
--- Comment #4 from Jason Merrill ---
Author: jason
Date: Wed Feb 20 02:00:29 2019
New Revision: 269032
URL: https://gcc.gnu.org/viewcvs?rev=269032=gcc=rev
Log:
PR c++/88368 - wrong 'use of deleted function'
Since my patch for 81359
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89411
Bug ID: 89411
Summary: RISC-V backend will generate wrong instruction for
longlong type like lw a3,-2048(a5)
Product: gcc
Version: 7.3.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89410
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89409
--- Comment #3 from H.J. Lu ---
A patch is submitted for compiler-rt:
https://reviews.llvm.org/D58413
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89392
--- Comment #5 from ctice at gcc dot gnu.org ---
I have been unable to reproduce this error, using the latest GCC and building
with VTV enabled. What architecture are you using? How are you configuring
your GCC build?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89271
--- Comment #10 from Alan Modra ---
> NON_SPECIAL_REGS removal
The gcc docs say of register classes: "You should define a class for the union
of two classes whenever some instruction allows both classes."
So this would seem to be going in the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89409
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89397
--- Comment #3 from joseph at codesourcery dot com ---
On Tue, 19 Feb 2019, marxin at gcc dot gnu.org wrote:
> Before the revision it was rejected with:
>
> atomic2.c: In function ‘func’:
> atomic2.c:49:8: error: x87 register return with x87
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78314
--- Comment #24 from Steve Ellcey ---
See email strings at:
https://gcc.gnu.org/ml/fortran/2019-01/msg00276.html
https://gcc.gnu.org/ml/fortran/2019-02/msg00057.html
For more discussion.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89409
--- Comment #1 from Jakub Jelinek ---
So, what does it print? When it regressed?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89410
--- Comment #2 from Jonny Grant ---
Would be good if the original source line number was retained along with the
#line override number. eg the ICE error has the wrong line number (hehe) ...
The ICE could show the actual line number (unless there
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89410
--- Comment #1 from Jonny Grant ---
This was brought up by Martin Sebor on gcc-help BTW.
https://gcc.gnu.org/ml/gcc-help/2019-02/msg00084.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89410
Bug ID: 89410
Summary: internal compiler error: in calculate_line_spans, at
diagnostic-show-locus.c:1237 after #line
Product: gcc
Version: 9.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89409
Bug ID: 89409
Summary: [9 Regression] FAIL:
c-c++-common/ubsan/div-by-zero-[67].c
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89408
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89408
--- Comment #1 from Andrew Pinski ---
See PR 44094.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89408
Bug ID: 89408
Summary: No constant folding when dereferencing string literals
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89405
David Malcolm changed:
What|Removed |Added
CC||dmalcolm at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88326
Harald Anlauf changed:
What|Removed |Added
CC||anlauf at gmx dot de
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86248
Harald Anlauf changed:
What|Removed |Added
CC||anlauf at gmx dot de
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89365
Harald Anlauf changed:
What|Removed |Added
CC||anlauf at gmx dot de
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50928
Eric Gallager changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89402
--- Comment #3 from Jonathan Wakely ---
(In reply to Jakub Jelinek from comment #1)
> Created attachment 45766 [details]
> gcc9-pr89402.patch
>
> Untested fix.
This patch is OK for trunk if it passes tests.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77908
Janne Blomqvist changed:
What|Removed |Added
CC||jb at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80408
Janne Blomqvist changed:
What|Removed |Added
Status|WAITING |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82480
Janne Blomqvist changed:
What|Removed |Added
CC||jb at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89266
--- Comment #9 from Harald Anlauf ---
(In reply to Harald Anlauf from comment #8)
> I have a 'half-patch' that tries to change gfc_target_expr_size()
> to return a bool which is true for success and false for failure,
> and then deal with this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635
--- Comment #17 from Martin Sebor ---
The only way to avoid the warning in C (or std::optional) that I can think of
is to somehow obscure the access to the boolean flag. Using volatile works but
looks like it has a cost that users wouldn't be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88973
Bruce Korb changed:
What|Removed |Added
CC||bkorb at gnu dot org
--- Comment #5 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89407
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89407
Bug ID: 89407
Summary: [9 Regression] go bootstrap failure on s390x starting
with r268941
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89406
Bug ID: 89406
Summary: Go testing leaves many temporary directories in /tmp
around
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635
--- Comment #16 from Pedro Alves ---
(In reply to Martin Sebor from comment #15)
> Zero
> initializing A::i first and then setting it to the result of f() also avoids
> the warning and seems like more viable solution/workaround until GCC gets
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89169
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68771
--- Comment #4 from Iain Sandoe ---
(In reply to Eric Gallager from comment #3)
> Maybe Iain will know what's up.
Yes, that symbol is a problem (esp. with LTO) .. but I believe that I've
committed the changes to remove it to the 7 branch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89405
--- Comment #2 from Marek Polacek ---
Started with r241137 or something around that one.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50928
--- Comment #20 from Joel Sherrill ---
I filed this in 2011 and we dropped RTEMS support for the m32c last year for
our next release. If you all think it is fixed, please feel free to close it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89384
Thomas Koenig changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89405
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89384
--- Comment #4 from Thomas Koenig ---
Author: tkoenig
Date: Tue Feb 19 17:55:33 2019
New Revision: 269024
URL: https://gcc.gnu.org/viewcvs?rev=269024=gcc=rev
Log:
2019-02-19 Thomas Koenig
PR fortran/89384
* trans-expr.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89403
Marek Polacek changed:
What|Removed |Added
Target Milestone|--- |7.5
--- Comment #2 from Marek Polacek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67064
Eric Gallager changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #32 from Eric
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63633
Eric Gallager changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65657
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89403
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63633
--- Comment #8 from Eric Gallager ---
(In reply to Martin Liška from comment #7)
> Can the bug be marked as resolved?
It already was, but then it was reopened because a duplicate was found:
(In reply to Georg-Johann Lay from comment #5)
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635
--- Comment #15 from Martin Sebor ---
I think the following smaller test case independent of libstdc++ captures the
same issue as the bigger test case in comment #4. Again, declaring f()
noexcept avoids the warning (but it's not a solution in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61152
--- Comment #12 from Eric Gallager ---
(In reply to Martin Liška from comment #11)
> Can the bug be marked as resolved?
I don't think so:
(In reply to Georg-Johann Lay from comment #10)
> (In reply to Eric Gallager from comment #9)
> > There
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48562
Eric Gallager changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #13 from Eric
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50928
Eric Gallager changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89404
Marek Polacek changed:
What|Removed |Added
Target Milestone|--- |7.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89404
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66918
--- Comment #8 from pskocik at gmail dot com ---
I'd also very much welcome a way to silence this (like with
-Wno-undefined-inline on clang).
My reason for wanting it is I'd like to prototype a non-static inline function
in one header (a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66918
pskocik at gmail dot com changed:
What|Removed |Added
CC||pskocik at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89405
Bug ID: 89405
Summary: [8/9 Regression] ICE in import_export_decl, at
cp/decl2.c:2959
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68771
Eric Gallager changed:
What|Removed |Added
CC||iains at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89404
Bug ID: 89404
Summary: [7/8/9 Regression] ICE in build_value_init_noctor, at
cp/init.c:467
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34721
Eric Gallager changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80529
--- Comment #8 from Eric Gallager ---
My previous arguments for having a flag for this have been in the positive
form, i.e., so that it can be enabled separately, but I'd also like to state it
in its negative form, i.e., so that one can do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89403
Bug ID: 89403
Summary: [7/8/9 Regression] ICE in maybe_clone_body, at
cp/optimize.c:693
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89393
--- Comment #2 from dave.anglin at bell dot net ---
On 2019-02-19 9:28 a.m., jakub at gcc dot gnu.org wrote:
> --- Comment #1 from Jakub Jelinek ---
> Would adding
> // { dg-require-weak "" }
> to the testcase help?
I will test.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89392
ctice at gcc dot gnu.org changed:
What|Removed |Added
CC||ctice at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89338
pc at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |9.0
--- Comment #1 from pc at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89339
pc at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |9.0
--- Comment #1 from pc at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78314
Wilco changed:
What|Removed |Added
CC||wilco at gcc dot gnu.org
--- Comment #23 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89271
--- Comment #9 from Segher Boessenkool ---
Erm. No new ICEs, I mean. Various tests expect different generated code
then you get with that. Some of it is an improvement.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89271
--- Comment #8 from Segher Boessenkool ---
I currently have the two previous patches in my stack, and I see no
regressions (on powerpc64-linux -m32/-m64).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89271
--- Comment #7 from Segher Boessenkool ---
Created attachment 45768
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45768=edit
NON_SPECIAL_REGS removal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89271
--- Comment #6 from Segher Boessenkool ---
Created attachment 45767
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45767=edit
reg_move_cost patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87924
--- Comment #3 from Thomas Schwinge ---
Author: tschwinge
Date: Tue Feb 19 16:04:17 2019
New Revision: 269020
URL: https://gcc.gnu.org/viewcvs?rev=269020=gcc=rev
Log:
[PR87924] OpenACC wait clauses without async-arguments: remove XFAILs
...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53991
pc at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|NEW
--- Comment #13 from pc at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89169
--- Comment #1 from ian at gcc dot gnu.org ---
Author: ian
Date: Tue Feb 19 15:42:09 2019
New Revision: 269019
URL: https://gcc.gnu.org/viewcvs?rev=269019=gcc=rev
Log:
PR go/89169
internal/cpu: do not require POWER8
Although
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89399
--- Comment #4 from Jakub Jelinek ---
At least from the comments, get_sub_rtx is like single_set, except that it
doesn't allow insns with two sets where one of them is dead. If we initially
checked with single_set and then use get_sub_rtx, it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89339
pc at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89338
pc at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53991
pc at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89399
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89402
--- Comment #2 from Jakub Jelinek ---
BUILDSTDERR: ../../../../libstdc++-v3/src/c++98/compatibility-ldbl.cc:77:17:
warning: 'void _ZNKSt4hashIeEclEe()' specifies less restrictive attribute than
its target 'std::size_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89402
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89399
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89402
Uroš Bizjak changed:
What|Removed |Added
Target||alphaev68-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89402
Bug ID: 89402
Summary: warning: ‘void _ZNKSt4hashIeEclEe()’ specifies less
restrictive attribute than its target
Product: gcc
Version: unknown
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82864
Thomas Schwinge changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89401
--- Comment #1 from syscall ---
gcc -v:
Using built-in specs.
COLLECT_GCC=gcc64
COLLECT_LTO_WRAPPER=D:/Program\ Files\
(x86)/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/8.1.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89393
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89401
Bug ID: 89401
Summary: The generated object file does not automatically
relocate the address using the cl link
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89393
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89397
--- Comment #2 from hjl at gcc dot gnu.org ---
Author: hjl
Date: Tue Feb 19 14:19:33 2019
New Revision: 269017
URL: https://gcc.gnu.org/viewcvs?rev=269017=gcc=rev
Log:
i386: Set ix86_fpmath to FPMATH_387 without SSE
ix86_fpmath should be set
1 - 100 of 145 matches
Mail list logo
