https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89802
Bug ID: 89802
Summary: [9 Regresssion] ICE: verify_gimple failed (error: dead
STMT in EH table)
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: ice-chec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85528
Arseny Solokha changed:
What|Removed |Added
Target|powerpc-*-linux-gnu*, |powerpc-*-linux-gnu*,
: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: qrzhang at gatech dot edu
Target Milestone: ---
It affects gcc-6 to gcc-trunk. gcc-5 works fine.
Bisect points to r222305.
$ gcc-trunk -v
gcc version 9.0.1 20190322 (experimental) [trunk revision 269869] (GCC)
$ gdb -v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80472
--- Comment #13 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #12)
> Improving the warning in comment 4 is irrelevant to this bug.
I've created Bug 89800 for improving that warning, please move that discussion
there.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89800
Bug ID: 89800
Summary: -Waggressive-loop-optimization warning doesn't have
useful location
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89799
Bug ID: 89799
Summary: no warning declaring an misaligned array of
overaligned structs
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43167
--- Comment #20 from Jonathan Wakely ---
(In reply to Manuel López-Ibáñez from comment #19)
> I wonder what happens if you used something that actually has a
> location, like an expression, for the first test case using emplace().
It doesn't mak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80472
--- Comment #12 from Jonathan Wakely ---
And as I've already said, the quality of the particular
-Waggressive-loop-optimizations warning is a separate issue, and should be
dealt with in a separate PR.
PR 58876 (mentioned in comment 0 as the reas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89794
Andrew Pinski changed:
What|Removed |Added
Component|rtl-optimization|target
--- Comment #1 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89795
--- Comment #1 from Andrew Pinski ---
Most likely related to PR 89434.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84868
--- Comment #6 from Harald Anlauf ---
(In reply to Harald Anlauf from comment #5)
> With the following patch len_trim is accepted in a specification expression:
Just forget that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80472
--- Comment #11 from Manuel López-Ibáñez ---
I'm not being pedantic for the sake of being pedantic. It is trivial to fix
the #pragma as I explained above. However, that won't give the user any
idea about which user code is triggering the warning.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84868
Harald Anlauf changed:
What|Removed |Added
CC||anlauf at gmx dot de
--- Comment #5 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80472
--- Comment #10 from Jonathan Wakely ---
(In reply to Manuel López-Ibáñez from comment #8)
> There is no negative n__ in user code.
If you want to be pedantic, there's no __n at all in user code. Because it's a
function parameter of std::advance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80472
--- Comment #9 from Jonathan Wakely ---
There is though. std::prev(it, n) is specified as std::advance(it, -n). Calling
prev means advancing a negative amount.
But I'm not sure what your point is. Currently there's no warning by default
even tho
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89797
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89798
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80472
--- Comment #8 from Manuel López-Ibáñez ---
There is no negative n__ in user code.
On Fri, 22 Mar 2019, 21:21 redi at gcc dot gnu.org, <
gcc-bugzi...@gcc.gnu.org> wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80472
>
> --- Comment #7 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86277
--- Comment #3 from Harald Anlauf ---
(In reply to Harald Anlauf from comment #2)
> Actually, the problem is not related to zero length arrays, but to the
> constructor [integer::]. I think this is related to several other PRs.
Looking at the d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80472
--- Comment #7 from Jonathan Wakely ---
A comment added to the code would make the caret diagnostic self-explanatory:
--- a/libstdc++-v3/include/bits/stl_iterator_base_funcs.h
+++ b/libstdc++-v3/include/bits/stl_iterator_base_funcs.h
@@ -149,7 +
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80472
--- Comment #6 from Jonathan Wakely ---
Is it better to silently generate code with undefined behaviour, or issue a
flawed warning about that undefined behaviour?
If the warning doesn't show the template instantiation context that's a
separate i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84661
Paolo Carlini changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85013
Paolo Carlini changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80472
--- Comment #5 from Manuel López-Ibáñez ---
This warning will be incomprehensible to users because the warning never
mentions any code that the user can modify. What should the user do
according to the warning?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43167
--- Comment #19 from Manuel López-Ibáñez ---
I think the solution is to have more locations. If the diagnostic code knew
where the user value came from then it will know to not suppress the
diagnostic. I wonder what happens if you used something
t; { target
> tls_native } } }
>
> #include "thread_local11.h"
^^ works for me, results below.
I guess we could do something more clever to detect that the __tls_init calls
are present for !tls_native. c.f. PR84497 where we don't generate the call
(not had a chance to analyse that yet).
===
Running /src/gcc-trunk/gcc/testsuite/g++.dg/tls/tls.exp ...
=== g++ Summary for unix/-m64 ===
# of expected passes307
# of expected failures 2
# of unsupported tests 55
Running target unix/-m32
Running /src/gcc-trunk/gcc/testsuite/g++.dg/tls/tls.exp ...
=== g++ Summary for unix/-m32 ===
# of expected passes307
# of expected failures 2
# of unsupported tests 55
=== g++ Summary ===
# of expected passes614
# of expected failures 4
# of unsupported tests 110
/scratch/10-12-sie/gcc-trunk-unpatched/gcc/testsuite/g++/../../xg++ version
9.0.1 20190322 (experimental) [trunk revision 269875] (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89797
--- Comment #2 from Andrew Pinski ---
Related to PR 69973 (which was fixed).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89781
--- Comment #3 from Mathias Stearn ---
Yeah, my point wasn't that this code should be accepted, it was that the error
messages should be improved. Ideally there would even be fixits suggesting
adding constexpr where it would be valid, otherwise s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87761
--- Comment #17 from Jeffrey A. Law ---
Author: law
Date: Fri Mar 22 18:14:56 2019
New Revision: 269880
URL: https://gcc.gnu.org/viewcvs?rev=269880&root=gcc&view=rev
Log:
PR rtl-optimization/87761
* config/mips/mips-protos.h (mip
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #33 from Bernd Edlinger ---
(In reply to Ramana Radhakrishnan from comment #32)
>
> Either I drop the warning or I keep the hunk in eh_personality.cc - any
> preferences / thoughts ?
It would feel safer, if only the functions that n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89798
Martin Sebor changed:
What|Removed |Added
Keywords||accepts-invalid
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89798
Bug ID: 89798
Summary: excessive vector_size silently accepted and truncated
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89797
Martin Sebor changed:
What|Removed |Added
Keywords||ice-on-invalid-code
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89797
Bug ID: 89797
Summary: ICE on a vector_size (1LU << 33) int variable
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89676
--- Comment #8 from Vladimir Makarov ---
Author: vmakarov
Date: Fri Mar 22 16:59:21 2019
New Revision: 269878
URL: https://gcc.gnu.org/viewcvs?rev=269878&root=gcc&view=rev
Log:
2019-03-22 Vladimir Makarov
PR rtl-optimization/89676
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
Ramana Radhakrishnan changed:
What|Removed |Added
Attachment #45552|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87481
Jakub Jelinek changed:
What|Removed |Added
Summary|[7/8/9 Regression] Endless |[7/8 Regression] Endless
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89796
Bug ID: 89796
Summary: Incorrect warning generated with OpenMP atomic capture
Product: gcc
Version: 8.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78830
--- Comment #12 from Jonathan Wakely ---
Finally, with -Waggressive-loop-optimizations -Wsystem-headers -O1 it does
terminate translation:
/usr/include/c++/8/bits/stl_iterator_base_funcs.h: In function ‘int main()’:
/usr/include/c++/8/bits/stl_i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78830
--- Comment #11 from Jonathan Wakely ---
As I already said:
(In reply to Jonathan Wakely from comment #8)
> One day I hope to be able to enhance those assertions to warn at
> compile-time if the compiler can tell the assertion will fail, but tha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43167
--- Comment #18 from Jonathan Wakely ---
From Matthias Kretz on IRC:
GCC needs to make a difference between warnings that apply when reading the
system headers and warnings that only manifest on a template instantiation or
constprop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43167
--- Comment #17 from Jonathan Wakely ---
And Bug 87614 is a simpler form of Ian's original example in comment 0:
#include
int main() {
std::vector a;
a.emplace_back(7);
}
With -Wsystem-header -Wconversion:
[...]
87614.cc:5:25:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78830
--- Comment #10 from Andrzej Krzemienski ---
For `std::prev()` it is UB, but by my reading of UB
(http://eel.is/c++draft/intro.defs#defns.undefined) it is legal for the
implementation to respond with "terminating a translation" "with the issuance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43167
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed|2017-01-24 00:00:00 |2019-3-22
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80472
--- Comment #4 from Jonathan Wakely ---
Another place where I'd like to selectively enable warnings is for this code
(from PR 78830):
#include
#include
int main()
{
std::forward_list il = {1, 2, 3, 4, 5, 6, 7};
auto iter = std::prev(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60702
--- Comment #13 from Jakub Jelinek ---
(In reply to Iain Sandoe from comment #11)
> (In reply to Jakub Jelinek from comment #10)
> > Created attachment 45976 [details]
> > gcc9-pr60702.patch
> >
> > Untested fix.
>
> For emulated TLS on x86_64-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78830
--- Comment #9 from Jonathan Wakely ---
P.S. in C++2a std::ranges::prev does make it ill-formed to pass arguments that
don't satisfy the BidirectionalIterator concept. But std::prev doesn't.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89785
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78830
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60702
--- Comment #12 from Jakub Jelinek ---
Author: jakub
Date: Fri Mar 22 14:42:57 2019
New Revision: 269875
URL: https://gcc.gnu.org/viewcvs?rev=269875&root=gcc&view=rev
Log:
PR c++/60702
* cp-tree.h (get_tls_wrapper_fn): Remove dec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87481
--- Comment #9 from Jakub Jelinek ---
Author: jakub
Date: Fri Mar 22 14:40:59 2019
New Revision: 269874
URL: https://gcc.gnu.org/viewcvs?rev=269874&root=gcc&view=rev
Log:
PR c++/87481
* doc/invoke.texi (-fconstexpr-ops-limit=): D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89583
--- Comment #1 from pmderodat at gcc dot gnu.org ---
Author: pmderodat
Date: Fri Mar 22 13:59:02 2019
New Revision: 269873
URL: https://gcc.gnu.org/viewcvs?rev=269873&root=gcc&view=rev
Log:
[Ada] GNAT.Sockets: fix recent regressions
The support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78830
--- Comment #7 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #6)
> (In reply to Piotr Nycz from comment #5)
> > CLANG with its std-lib correctly (IMO) does not compile it.
>
> As explained above, GCC is already correct here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89785
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78830
--- Comment #6 from Jonathan Wakely ---
(In reply to Piotr Nycz from comment #5)
> CLANG with its std-lib correctly (IMO) does not compile it.
As explained above, GCC is already correct here.
> I understand this is UB - but implementation might
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89793
Jonathan Wakely changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78830
Piotr Nycz changed:
What|Removed |Added
CC||piotrwn1 at gmail dot com
--- Comment #5 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89793
--- Comment #6 from Harald van Dijk ---
(In reply to Jonathan Wakely from comment #4)
> (In reply to Harald van Dijk from comment #1)
> > This appears to work the same way in GCC 8 as it does in GCC 7, although it
> > is possible that for whateve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89793
--- Comment #5 from Jonathan Wakely ---
Minimal testcase:
struct allocator { };
struct string {
string(const string&);
string(const allocator&);
};
struct NotString : allocator { };
struct String {
operator string() const;
operator No
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89793
--- Comment #4 from Jonathan Wakely ---
(In reply to Harald van Dijk from comment #1)
> Your StringType provides a conversion operator to HTTPResponse, which
> indirectly has std::allocator as a private base class. Overload
> resolution happens b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89793
--- Comment #3 from Jonathan Wakely ---
I haven't analysed whether it's valid yet, but it started to fail with r258755
PR c++/81311 - wrong C++17 overload resolution.
* call.c (build_user_type_conversion_1): Remove C++17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89780
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #31 from Jakub Jelinek ---
(In reply to Ramana Radhakrishnan from comment #30)
> (In reply to Jakub Jelinek from comment #29)
> > Ramana, any progress on this?
>
> I'm still trying to get the various spec files and the t-multilib bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89795
Bug ID: 89795
Summary: wrong code with -O2 -fno-dce -fno-forward-propagate
-fno-sched-pressure
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: wrong-cod
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89794
Bug ID: 89794
Summary: wrong code with -Og -fno-forward-propagate
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89781
--- Comment #2 from Jonathan Wakely ---
Yeah I guess the diagnostics could be improved for C++17 and up to say that
using 'inline' would make it valid.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89789
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89784
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88918
Bug 88918 depends on bug 89784, which changed state.
Bug 89784 Summary: Missing AVX512 intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89784
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89781
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89512
Jakub Jelinek changed:
What|Removed |Added
Summary|[7/8/9 Regression] ICE in |[7/8 Regression] ICE in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89512
Paolo Carlini changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|jakub at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80559
Paolo Carlini changed:
What|Removed |Added
Keywords|error-recovery, |diagnostic
|ice-on-inv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89793
--- Comment #2 from du yang ---
Created attachment 46009
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46009&action=edit
GCC 7.3.1 source file dump
GCC version:
gcc version 7.3.1 20180303 (Red Hat 7.3.1-5) (GCC)
System Type:
CentOS Linu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89784
--- Comment #8 from Jakub Jelinek ---
Author: jakub
Date: Fri Mar 22 10:08:40 2019
New Revision: 269868
URL: https://gcc.gnu.org/viewcvs?rev=269868&root=gcc&view=rev
Log:
PR target/89784
* config/i386/i386.c (enum ix86_builtins):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60702
Iain Sandoe changed:
What|Removed |Added
CC||iains at gcc dot gnu.org
--- Comment #11 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89793
Harald van Dijk changed:
What|Removed |Added
CC||harald at gigawatt dot nl
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89790
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89784
Hongtao.liu changed:
What|Removed |Added
Attachment #46007|0 |1
is obsolete|
79 matches
Mail list logo
