https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80662
David Edelsohn changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80662
Bug ID: 80662
Summary: libstdc++ basic_string casting oddity
Product: gcc
Version: 7.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80655
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|2017-05-06 00:00:0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80648
--- Comment #8 from Keith Thompson ---
That's a surprising interpretation of the word "amendment".
Searching isocpp.org and other sites, I haven't found any official reference
to an "amendment" to the C++ standard. The nearest thing I've found,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80648
--- Comment #7 from Andrew Pinski ---
(In reply to Keith Thompson from comment #6)
> Shall I submit a separate ticket against the documentation?
>
> "info gcc" for gcc-7.1.0 has the following description for -std=c=+98 and
> std=++03:
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80648
--- Comment #6 from Keith Thompson ---
Shall I submit a separate ticket against the documentation?
"info gcc" for gcc-7.1.0 has the following description for -std=c=+98 and
std=++03:
'c++98'
'c++03'
The 1998 ISO C++ standard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80648
--- Comment #5 from Jonathan Wakely ---
Whether or not it's part of the standard has no bearing on whether it's a bug
in GCC, because we don't claim to implement just the original published
standard. GCC's policy is to implement the standard plus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80280
--- Comment #4 from Volker Reichelt ---
Author: reichelt
Date: Sun May 7 19:41:09 2017
New Revision: 247728
URL: https://gcc.gnu.org/viewcvs?rev=247728&root=gcc&view=rev
Log:
PR translation/80280
* call.c (print_z_candidate): Fi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79311
--- Comment #7 from janus at gcc dot gnu.org ---
(In reply to janus from comment #6)
> The regtest went pretty well, although I'm seeing these three failures:
>
> FAIL: gfortran.dg/coarray_lock_7.f90 -O scan-tree-dump-times original
> FAIL:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79664
Volker Reichelt changed:
What|Removed |Added
Known to work||6.3.1, 7.1.0
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79681
Volker Reichelt changed:
What|Removed |Added
Status|NEW |RESOLVED
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79311
--- Comment #6 from janus at gcc dot gnu.org ---
(In reply to janus from comment #5)
> This draft patch fixes the ICE on comment 0 and comment 4:
>
> [..]
>
> Regtesting now ...
The regtest went pretty well, although I'm seeing these three failu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79639
Volker Reichelt changed:
What|Removed |Added
Status|NEW |RESOLVED
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79311
janus at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |8.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79311
janus at gcc dot gnu.org changed:
What|Removed |Added
Keywords||ice-on-valid-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66153
--- Comment #7 from Peter Boyle ---
Signature of fail in 8.0.0 (head) is:
^~~~
prog.cc: In substitution of 'template Container(arg.data[0]))> function(const Container&) [with int N = 1;
obj = ]':
prog.cc:43:101: recur
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66153
--- Comment #6 from Peter Boyle ---
Just an update:
Still fails in G++ 7.1.0 and in 8.0.0 (head) on Wandbox.
Still passes in Clang 4.0.0 and 5.0.0(head).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80657
--- Comment #2 from Vittorio Zecca ---
You do not get line numbers but offset in f951.
Need rebuild with -g option or addr2line usage?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80645
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78496
--- Comment #11 from Jeffrey A. Law ---
Author: law
Date: Sun May 7 15:10:55 2017
New Revision: 247727
URL: https://gcc.gnu.org/viewcvs?rev=247727&root=gcc&view=rev
Log:
2017-05-07 Jeff Law
Revert:
2017-05-06 Jeff Law
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80657
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79072
--- Comment #7 from Dominique d'Humieres ---
> Comment 5 code example gives incorrect results with the 7.1.0 release,
> but correct results with 6.3 and 5.2 -- a regression.
Likely caused by revision r241439. AFAICT this could be two different P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80661
Bug ID: 80661
Summary: make check-gcc RUNTESTFLAGS="dg.exp=g*" runs all the
tests in gcc.dg
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80660
Bug ID: 80660
Summary: Member function pointer optimization affected by
incompatible virtual function
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79027
--- Comment #8 from John David Anglin ---
The error on the trunk is caused by the middle end trying to do a mode change
between SImode and BLKmode. Tweaking pa_cannot_change_mode_class() to reject
changes to/modes with zero size appears to fix t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79072
neil.n.carlson at gmail dot com changed:
What|Removed |Added
Known to fail||7.1.0
--- Comment #6 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78379
--- Comment #30 from Thomas Koenig ---
I think there still is one thing to do.
Apparently, AMD CPUs (which use only vanilla at
the moment) are slightly faster with -mprefer-avx128,
and they should be much faster if they have FMA3.
Unless I miss
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68600
Thomas Koenig changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #15 from Thomas Koen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80658
--- Comment #1 from Marc Glisse ---
I am not sure what you expect from this PR exactly. If you have issues about
glibc's implementation of malloc, please see about it with glibc (here is for
gcc only). They already know about the performance issu
29 matches
Mail list logo