https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42328
--- Comment #11 from paolo at gcc dot gnu.org ---
Author: paolo
Date: Sat Mar 28 10:28:14 2015
New Revision: 221751
URL: https://gcc.gnu.org/viewcvs?rev=221751&root=gcc&view=rev
Log:
2015-03-28 Paolo Carlini
PR c++/42328
* g++.dg/tem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42328
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65610
--- Comment #3 from Jakub Jelinek ---
Perhaps one possibility would be even for -g0 preserve those specific BLOCKs
(those satisfying
if (BLOCK_ABSTRACT_ORIGIN (block)
&& TREE_CODE (BLOCK_ABSTRACT_ORIGIN (block)) == FUNCTION_DECL)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65429
--- Comment #2 from Dominique d'Humieres ---
I wonder if the patches in comment 1 or at
https://gcc.gnu.org/ml/fortran/2015-03/msg00143.html are not papering over the
real issue. I have modified the FX' test as
CHARACTER(*, kind = 4), PARAMETE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65540
Eric Botcazou changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65540
Eric Botcazou changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65429
--- Comment #3 from drikosev at otenet dot gr ---
With the patch one can avoid a segmentation fault but I don't know very well
the internals of gfortran.
So, I've no idea if and how one can obtain the length without array elements;
some debugging
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65615
Jonathan Wakely changed:
What|Removed |Added
Keywords||rejects-valid
Status|UNCON
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65596
--- Comment #5 from Jerry DeLisle ---
Author: jvdelisle
Date: Sat Mar 28 13:27:58 2015
New Revision: 221753
URL: https://gcc.gnu.org/viewcvs?rev=221753&root=gcc&view=rev
Log:
2015-03-28 Jerry DeLisle
PR libgfortran/65596
* io/transfer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65596
--- Comment #6 from Jerry DeLisle ---
Author: jvdelisle
Date: Sat Mar 28 14:08:18 2015
New Revision: 221754
URL: https://gcc.gnu.org/viewcvs?rev=221754&root=gcc&view=rev
Log:
2015-03-28 Jerry DeLisle
PR libgfortran/65596
* io/transfer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65596
--- Comment #7 from Jerry DeLisle ---
Author: jvdelisle
Date: Sat Mar 28 14:22:53 2015
New Revision: 221755
URL: https://gcc.gnu.org/viewcvs?rev=221755&root=gcc&view=rev
Log:
2015-03-28 Jerry DeLisle
PR libgfortran/65596
* gfortran.dg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65596
--- Comment #8 from Jerry DeLisle ---
Author: jvdelisle
Date: Sat Mar 28 14:25:29 2015
New Revision: 221756
URL: https://gcc.gnu.org/viewcvs?rev=221756&root=gcc&view=rev
Log:
2015-03-28 Jerry DeLisle
PR libgfortran/65596
* gfortran.dg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65052
--- Comment #7 from Bernd Schmidt ---
I committed a different one.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64983
--- Comment #6 from howarth at bromo dot med.uc.edu ---
This same bug has also been reported on dejagnu mailing list at...
http://lists.gnu.org/archive/html/dejagnu/2015-02/msg0.html
and claimed to be pinpointed to /usr/share/dejagnu/remote.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65509
--- Comment #14 from Mitsuru Kariya ---
The rev.221737 seems to be able to compile the sample code above, but cannot
compile another sample code like below.
= sample code =
constexpr char s1[] = "s1";
constexpr ch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65509
Mitsuru Kariya changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65500
--- Comment #4 from John David Anglin ---
Author: danglin
Date: Sat Mar 28 17:27:22 2015
New Revision: 221757
URL: https://gcc.gnu.org/viewcvs?rev=221757&root=gcc&view=rev
Log:
PR libstdc++/65500
* inclhack.def (hpux11_lwp_rwlock_valid):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65596
Jerry DeLisle changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65563
Jerry DeLisle changed:
What|Removed |Added
Assignee|jvdelisle at gcc dot gnu.org |unassigned at gcc dot
gnu.org
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65567
--- Comment #1 from John David Anglin ---
Patch here:
https://gcc.gnu.org/ml/gcc-patches/2015-03/msg01490.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65441
--- Comment #1 from John David Anglin ---
Although there is support for long doubles on this target, it lacks the
long double math functions added in c99. So, it doesn't have fabsl.
There is a libcall implementation of abs for long double and t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65610
--- Comment #4 from Jan Hubicka ---
> Perhaps one possibility would be even for -g0 preserve those specific BLOCKs
> (those satisfying
Yep, we should do that. Who is removing them?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64983
--- Comment #7 from howarth at bromo dot med.uc.edu ---
A regression hunt of dejagnu master revealed that the offending commit causing
this bug was...
http://git.savannah.gnu.org/cgit/dejagnu.git/commit/?id=6d2e2d3791bcea70131a6cf64a0a522a7b8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65441
--- Comment #2 from John David Anglin ---
Patch here:
https://gcc.gnu.org/ml/gcc-patches/2015-03/msg01492.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65076
--- Comment #27 from Jan Hubicka ---
Unfortunately from me it wend down from about 18% to 15%, so still a
regression. One quantiative parameter I can measure is increase of number of
functions in the resulting binary from 1030 to 1140. I will try
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65563
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65563
--- Comment #6 from Mikael Morin ---
(In reply to Jerry DeLisle from comment #3)
> I cannot reproduce this on trunk (5.0) and I get nothing with
> -fsanitize=address
> accept the error message. This is on x86-64-linux.
>
Same here. I do get a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65610
--- Comment #5 from Jakub Jelinek ---
Haven't debugged that part yet.
Looking at decl_maybe_in_construction_p, we'd probably need to treat functions
with DECL_ABSTRACT_ORIGIN being ctor or dtor.
I can look into this on Monday...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64983
Jack Howarth changed:
What|Removed |Added
CC||howarthjw at gmail dot com
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52962
Manuel López-Ibáñez changed:
What|Removed |Added
Keywords||diagnostic, easyhack
S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17729
Manuel López-Ibáñez changed:
What|Removed |Added
Keywords||patch
Assignee|unassigne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65445
Manuel López-Ibáñez changed:
What|Removed |Added
Keywords||easyhack
--- Comment #2 from Manue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64181
--- Comment #1 from Roger Orr ---
The optimization is also broken in the 5.0 head (5.0.0.20150328)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63444
Manuel López-Ibáñez changed:
What|Removed |Added
Last reconfirmed|2014-10-05 00:00:00 |2015-3-29
Summary|Compi
34 matches
Mail list logo
