https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430
Andrew Pinski changed:
What|Removed |Added
Target||x86_64-*-*
--- Comment #3 from Andrew Pi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79417
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79428
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430
--- Comment #4 from Jürgen Reuter ---
(In reply to Andrew Pinski from comment #3)
> (In reply to Jürgen Reuter from comment #2)
> > (In reply to Andrew Pinski from comment #1)
> > > What target is this on?
> >
> > We reproduced it under MAC OS X
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79428
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79428
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430
--- Comment #6 from Jürgen Reuter ---
(In reply to Dominique d'Humieres from comment #5)
> What does --with-precision=extended?
It sets the default precision of real and complex floats (kind type parameter)
to 80 bit instead of 64 bit (double) o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79428
Marek Polacek changed:
What|Removed |Added
Keywords||error-recovery,
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430
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=79432
David Malcolm changed:
What|Removed |Added
Keywords||ice-checking
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64081
--- Comment #56 from Segher Boessenkool ---
Yes, and a function that computes a "more permissive" version should
not have "simple_loop" in its name, it is very misleading. Reusing
existing functions to do something different may seem attractive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79433
Bug ID: 79433
Summary: __has_include reports wrong result headers that #error
on __cplusplus
Product: gcc
Version: 7.0.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79427
--- Comment #1 from Segher Boessenkool ---
I get the correct output on BE (gcc110). This is glibc 2.18, maybe
that is the difference?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79433
--- Comment #1 from Marc Mutz ---
And no, checking __cplusplus in addition is not an option, since many
compilers, GCC included (__cplusplus==1, remember?), do not necessarily bump
__cplusplus when they implement enough core features to make some
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79427
--- Comment #2 from seurer at gcc dot gnu.org ---
I checked and on the first system where I noticed this glibc is the distro
(Ubuntu 14.04) default 2.17. Other Be systems where it also failed are that or
older.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79433
--- Comment #2 from Marc Mutz ---
Ok, there is __cpp_lib_experimental_string_view, at least, but it's defined ...
wait for it ... in , which you can't include.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79301
--- Comment #6 from Martin Sebor ---
The (__has_cpp_attribute(fallthrough) >= __cplusplus) test doesn't help because
the built-in evaluates to 201603 (in all conformance modes) and __cplusplus to
at most 201500L (in C++ 17 mode), so it's as good
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79433
--- Comment #3 from Andrew Pinski ---
__has_include just says the include exists and not if the include file works.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79433
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430
--- Comment #8 from Jürgen Reuter ---
We are defining a real(default) which could be 4, 8, 10 or 16, as these are the
real kinds supported by gfortran. If default = 10, this happens, but this is
not per se forbidden, is it?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430
--- Comment #9 from Jürgen Reuter ---
(In reply to kargl from comment #7)
> (In reply to Jürgen Reuter from comment #6)
> > (In reply to Dominique d'Humieres from comment #5)
> > > What does --with-precision=extended?
> >
> > It sets the default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46639
--- Comment #20 from ctice at gcc dot gnu.org ---
Author: ctice
Date: Wed Feb 8 19:55:28 2017
New Revision: 245284
URL: https://gcc.gnu.org/viewcvs?rev=245284&root=gcc&view=rev
Log:
2017-02-08 Caroline Tice
Fix PR 46639
in gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430
--- Comment #10 from Steve Kargl ---
On Wed, Feb 08, 2017 at 07:32:53PM +, juergen.reuter at desy dot de wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430
>
> --- Comment #8 from Jürgen Reuter ---
> We are defining a real(default)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64081
--- Comment #57 from Aldy Hernandez ---
Created attachment 40697
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40697&action=edit
untested patch possibly solving AIX bootstrap
Taking in Jeff and Segher's suggestions, I propose something li
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79434
Bug ID: 79434
Summary: [submodules] separate module procedure breaks
encapsulation
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430
--- Comment #11 from Jürgen Reuter ---
(In reply to Steve Kargl from comment #10)
> On Wed, Feb 08, 2017 at 07:32:53PM +, juergen.reuter at desy dot de
> which may lead to conforming code suddening becoming nonconforming
> due to violation o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79433
--- Comment #5 from Marc Mutz ---
Andrew, you're taking the easy way out. It might be that it works as
implemented, but that behaviour is useless.
Please explain how one should detect, in a portable way, whether string_view
and experimental::str
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78604
--- Comment #8 from Pat Haugen ---
Author: pthaugen
Date: Wed Feb 8 20:49:14 2017
New Revision: 245285
URL: https://gcc.gnu.org/viewcvs?rev=245285&root=gcc&view=rev
Log:
PR target/78604
* config/rs6000/rs6000.c (rs6000_emit_vect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78604
Pat Haugen changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430
--- Comment #12 from Steve Kargl ---
On Wed, Feb 08, 2017 at 08:39:43PM +, juergen.reuter at desy dot de wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430
>
> --- Comment #11 from Jürgen Reuter ---
> (In reply to Steve Kargl from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79431
Martin Sebor changed:
What|Removed |Added
Keywords||ice-on-valid-code
Status|UNCO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39612
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
Target Mileston
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79429
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79258
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430
--- Comment #13 from Jürgen Reuter ---
(In reply to Steve Kargl from comment #12)
> On Wed, Feb 08, 2017 at 08:39:43PM +, juergen.reuter at desy dot de
> wrote:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430
> >
> > --- Comment #11 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79301
--- Comment #7 from Jason Merrill ---
(In reply to Jakub Jelinek from comment #4)
> That said, I think e.g. for maybe_unused or nodiscard attributes we don't
> complain with -pedantic about those attributes used in C++14 code, so either
> we shou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64081
--- Comment #58 from Segher Boessenkool ---
You can keep get_simple_loop_desc, find_simple_exit etc.; just make them
inline functions or similar.
I'm sceptical that this will not cause any more problems, we're deep into
stage 4 already :-/
7.0.1 20170208 (experimental) [trunk revision 245266] (GCC)
$
$ g++-trunk -c -w small.cpp
small.cpp:3:28: internal compiler error: Segmentation fault
template < int > int f = a.x;
^
0xe1439f crash_signal
../../gcc-source-trunk/gcc/toplev.c:333
0x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79183
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430
--- Comment #14 from Steve Kargl ---
On Wed, Feb 08, 2017 at 09:30:45PM +, juergen.reuter at desy dot de wrote:
> >
> > > Indeed, it looks as if kind=10 would be real128, but as you said this
> > > is wrong and was fixed by you (I guess it i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79397
--- Comment #3 from Segher Boessenkool ---
Author: segher
Date: Wed Feb 8 21:41:31 2017
New Revision: 245286
URL: https://gcc.gnu.org/viewcvs?rev=245286&root=gcc&view=rev
Log:
rs6000: Fix spelling of AltiVec in rs6000.opt (PR79397)
It was spel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79436
Bug ID: 79436
Summary: [ARM Cortex-M4F] VFMA used in place of subtraction
gives inexact results
Product: gcc
Version: 6.3.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79436
--- Comment #1 from Freddie Chopin ---
Created attachment 40700
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40700&action=edit
assembly dump of invalid version
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79436
--- Comment #2 from Freddie Chopin ---
Created attachment 40701
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40701&action=edit
assembly dump of valid version
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79397
--- Comment #4 from Segher Boessenkool ---
Author: segher
Date: Wed Feb 8 21:44:37 2017
New Revision: 245287
URL: https://gcc.gnu.org/viewcvs?rev=245287&root=gcc&view=rev
Log:
rs6000: Fix spelling of AltiVec in rs6000.opt (PR79397)
It was spel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79397
Segher Boessenkool changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64081
--- Comment #59 from Jeffrey A. Law ---
The work is still incredibly helpful. After the analysis work is done we can
still decide to defer to gcc-8 stage1 if we feel it's too risky to tackle right
now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79386
Jeffrey A. Law changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79110
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79183
Joseph S. Myers changed:
What|Removed |Added
Status|RESOLVED|NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79183
--- Comment #4 from Joseph S. Myers ---
See hr.po, ru.po, sr.po and uk.po for GCC translations involving more than just
singular and plural (look at the Plural-Forms line in the .po file).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79084
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79183
--- Comment #5 from Martin Sebor ---
I see, thanks for the pointer. Looks like warning_n() is used in
gcc/ipa-devirt.c and error_n() in gcc/cp/pt.c. gimple-ssa-sprintf.c contains
between 7 and 23 instances of these "%wu byte" vs "%wu bytes" for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79436
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79083
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79070
Martin Sebor changed:
What|Removed |Added
Keywords||diagnostic
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430
--- Comment #15 from Jürgen Reuter ---
With -fcheck=all nothing is flagged, but the test works as expected, as well
as if I (independently from the fcheck) compile everything with -fno-inline .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79110
John David Anglin changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66955
Austin Beer changed:
What|Removed |Added
CC||asbeer at gmail dot com
--- Comment #1 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79437
Bug ID: 79437
Summary: Redundant move instruction when getting sign bit of
double on 32-bit architecture
Product: gcc
Version: 6.3.1
Status: UNCONFIRMED
Severit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79437
--- Comment #1 from Matheus Izvekov ---
Forgot to mention above, all gcc versions including the unreleased 7.0 and
below as far as I could test (4.6) are affected by this.
For comparison, clang generates optimal code for all cases.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42065
Eric Gallager changed:
What|Removed |Added
CC||egall at gwmail dot gwu.edu
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79433
Eric Gallager changed:
What|Removed |Added
CC||egall at gwmail dot gwu.edu
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79433
--- Comment #7 from Jonathan Wakely ---
(In reply to Marc Mutz from comment #1)
> And no, checking __cplusplus in addition is not an option, since many
> compilers, GCC included (__cplusplus==1, remember?), do not necessarily bump
> __cplusplus w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79433
--- Comment #8 from Jonathan Wakely ---
I guess another, novel, option would be a __try_include directive:
#ifdef __try_include
# if __try_include()
// it was included without error
# else
// it wasn't found, or gave an error
# endif
#endif
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79435
Martin Sebor changed:
What|Removed |Added
Keywords||error-recovery,
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430
--- Comment #17 from Jürgen Reuter ---
(In reply to Jerry DeLisle from comment #16)
> (In reply to Jürgen Reuter from comment #15)
> > With -fcheck=all nothing is flagged, but the test works as expected, as well
> > as if I (independently from th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79438
Bug ID: 79438
Summary: [7 Regression] ICE during RA w/ -O3 (or -Ofast)
-funroll-loops for 32-bit BE powerpc target
Product: gcc
Version: 7.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79436
--- Comment #4 from Freddie Chopin ---
Hello Andrew and thanks for your answer.
Generally I don't care about the sequence of operations or the exact
instructions that get generated, but in this case this default behaviour
produces invalid result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79436
--- Comment #5 from Andrew Pinski ---
"this default behaviour produces invalid results."
No.
Read http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.22.6768
> The same code compiled at -O2 for x86-64 does not assert.
That because the defa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79433
Marc Mutz changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69823
--- Comment #9 from Richard Biener ---
Author: rguenth
Date: Thu Feb 9 07:47:07 2017
New Revision: 245295
URL: https://gcc.gnu.org/viewcvs?rev=245295&root=gcc&view=rev
Log:
2017-02-09 Richard Biener
PR tree-optimization/69823
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79433
Andrew Pinski changed:
What|Removed |Added
Component|c++ |libstdc++
--- Comment #10 from Andrew Pi
101 - 175 of 175 matches
Mail list logo
