https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62044
Paul Thomas changed:
What|Removed |Added
Status|REOPENED|RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62044
--- Comment #16 from Paul Thomas ---
Author: pault
Date: Tue Jan 27 20:54:49 2015
New Revision: 220191
URL: https://gcc.gnu.org/viewcvs?rev=220191&root=gcc&view=rev
Log:
2015-01-27 Paul Thomas
PR fortran/62044
* resolve.c (resolve_al
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62044
--- Comment #15 from Paul Thomas ---
Author: pault
Date: Mon Jan 26 21:58:42 2015
New Revision: 220140
URL: https://gcc.gnu.org/viewcvs?rev=220140&root=gcc&view=rev
Log:
2015-01-26 Paul Thomas
PR fortran/62044
* resolve.c (resolve_al
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62044
--- Comment #14 from Damian Rouson ---
Correction: the backport I was discussing with Andre was for a different bug.
Nonetheless, I'm reasonably certain that the fix for this bug would benefit the
aforementioned project (pFUnit) so I'm still int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62044
--- Comment #13 from Damian Rouson ---
Paul,
In case it matters, I reported a duplicate of this bug that I isolated from
code in an open-source NASA project (http://sourceforge.net/projects/pfunit/).
NASA has expressed a desire for the fix to b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62044
--- Comment #12 from paul.richard.thomas at gmail dot com ---
Dear All,
As I just said on #gfortran, the previous explanation is wrong. The
problem is that, for the mold= case with no default initializer, the
code->expr winds up being NULL. This
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62044
--- Comment #11 from paul.richard.thomas at gmail dot com ---
Dear Dominique,
For some reason, the hash values are different in the vtable and the
TYPE IS. I had always worried that that we would have different names
giving the same hash sometim
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62044
--- Comment #10 from paul.richard.thomas at gmail dot com ---
Hi Mikael,
Yes, you will see from my comment on the PR that I had come to the
same conclusion. However, rather than take PR62044 as a place holder,
I will open a new PR. Thanks for th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62044
--- Comment #9 from Mikael Morin ---
Created attachment 34571
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34571&action=edit
segregate derived type namespaces from regular namespaces
To convince yourself that sym_root fields are never us
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62044
Mikael Morin changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62044
--- Comment #7 from Dominique d'Humieres ---
> The following, which works OK with another brand, selects the "wrong type"
> with trunk. 4.9 still segfaults. Without the use rename, 4.9 runs and gives
> the wrong result.
The following test withou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62044
paul.richard.thomas at gmail dot com
changed:
What|Removed |Added
CC||paul.richard.thom
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62044
Mikael Morin changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
13 matches
Mail list logo
