https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68522
--- Comment #4 from Jeffrey A. Law ---
And just to be clear, I'm actually referring to myself...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68522
Jeffrey A. Law changed:
What|Removed |Added
Priority|P3 |P1
--- Comment #3 from Jeffrey A. Law
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69075
Mikhail Maltsev changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67081
Mikhail Maltsev changed:
What|Removed |Added
CC||miyuki at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69077
--- Comment #7 from Andrew Pinski ---
Created attachment 37191
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37191&action=edit
tar file with simplified testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69077
--- Comment #6 from Andrew Pinski ---
Here is the simplified testcase:
t.h:
struct cStdDev
{
long ns;
virtual double mean() const { return ns; }
};
t1.cc:
#include "t.h"
struct cWeightedStdDev : public cStdDev {
virtual int netPack();
};
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69082
PeteVine changed:
What|Removed |Added
URL||http://ufoai.org/wiki/Getti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69082
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69077
--- Comment #5 from Andrew Pinski ---
Down to two files (netpack.ii and EtherAppSrv.ii). Reducing it further too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69077
--- Comment #4 from Andrew Pinski ---
Down to 12 files now and still removing them.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67081
John David Anglin changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68356
--- Comment #10 from dave.anglin at bell dot net ---
On 2015-12-29, at 5:25 PM, dave.anglin at bell dot net wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68356
>
> --- Comment #9 from dave.anglin at bell dot net ---
> On 2015-12-29, at 5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67779
--- Comment #18 from paul.richard.thomas at gmail dot com ---
It works for me - a mystery for tomorrow :-)
Paul
On 29 December 2015 at 23:10, dominiq at lps dot ens.fr
wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67779
>
> --- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69080
--- Comment #6 from Dominique d'Humieres ---
> However, I don't think this is a solution. If you, for example, think
> of a string class as the derived type instead of "dummy", there could
> be a function returning an allocatable string_class der
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68356
--- Comment #9 from dave.anglin at bell dot net ---
On 2015-12-29, at 5:05 PM, dominiq at lps dot ens.fr wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68356
>
> --- Comment #8 from Dominique d'Humieres ---
>> You might want to double ch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69080
kargl at gcc dot gnu.org changed:
What|Removed |Added
Status|WAITING |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67779
--- Comment #17 from Dominique d'Humieres ---
> Now sorting the right-hand part of the array fails:
Confirmed, starting with
2 9 8 7 6 5
4 3 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69080
--- Comment #4 from sv.muel...@tu-braunschweig.de ---
Addendum to my last post: I refered to scalar allocatables, not arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69080
--- Comment #3 from sv.muel...@tu-braunschweig.de ---
Thanks for testing this out!
Indeed there aren't any leaks with your changes. Actually, leaving the module
save statement uncommented produces the same positive result for me.
However, I don'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68356
--- Comment #8 from Dominique d'Humieres ---
> You might want to double check that it's not a bug in the HP-UX libm.
AFAIU Joseph (comment 2) the test should be skipped on platforms defaulting to
-fno-math-errno as Darwin. Is it the case for HP-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68356
Eric Botcazou changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69077
--- Comment #3 from Andrew Pinski ---
I Have it down to 42 files down from 83 files. One file was taking longer so I
moved it to the end of the list. Should be down to a few files by the end of
the day.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67779
--- Comment #16 from Thomas Koenig ---
Created attachment 37190
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37190&action=edit
Test case that still fails
Hi Paul,
> (i) To fix the ICE in trans.c. This is fixed by the change to trans-stm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68356
John David Anglin changed:
What|Removed |Added
Target|x86_64-apple-darwin1* |x86_64-apple-darwin1*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69080
--- Comment #2 from Dominique d'Humieres ---
The leak seems gone with
module dummy_module
implicit none
! save
type, public :: dummy_class
contains
procedure, public :: trigger => dummy_trigger
end type
contains
function dummy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69080
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69082
PeteVine changed:
What|Removed |Added
CC||tulipawn at gmail dot com
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69082
Bug ID: 69082
Summary: Final link fails on ARM using lto
Product: gcc
Version: 4.9.3
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69075
--- Comment #2 from Charles ---
Created attachment 37188
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37188&action=edit
2/2 the preprocessed file (*.i*) that triggers the bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69075
--- Comment #1 from Charles ---
Created attachment 37187
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37187&action=edit
1/2 the preprocessed file (*.i*) that triggers the bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69081
Bug ID: 69081
Summary: forward_list::splice_after does not handle the case of
first<=last properly
Product: gcc
Version: 5.3.1
Status: UNCONFIRMED
Severity: nor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69080
Bug ID: 69080
Summary: No automatic deallocation of allocatable function
results
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66521
--- Comment #18 from Eric Gallager ---
(In reply to Andrew Pinski from comment #17)
> Is this working now?
Uh... essentially. As originally reported, yes. I should probably open a
different bug for the other issue(s) that have arisen since fixin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67710
--- Comment #8 from mrs at gcc dot gnu.org ---
Ok.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67779
Paul Thomas changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69079
--- Comment #9 from Denis Sherstennikov ---
Perhaps, this was a distro compilation inaccuracy of ubuntu package maintainer.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69079
--- Comment #8 from Denis Sherstennikov ---
I doubt that ccache changes g++ flags somehow: without it the discussed
behavior still was present - under g++ 5.2.1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69079
--- Comment #7 from Denis Sherstennikov ---
I used default bundled g++ update from ubuntu 14.04.02 repo, however it works
through ccache.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69079
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69079
--- Comment #5 from Andrew Pinski ---
Did you compile GCC yourself or using different distro's compilers?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69079
--- Comment #4 from Denis Sherstennikov ---
Yes, it does. That clearly ain't an obvious fix. If you hadn't told me, I don't
know how I would figure this out in short time.
I'd appreciate a compiler warning on this issue with direct designation o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69079
--- Comment #3 from Andrew Pinski ---
Can see if adding -Wl,--no-as-needed fixes the problem? If so then there is
no bug here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69079
--- Comment #2 from Denis Sherstennikov ---
Problem does not occure under:
g++ 5.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69079
--- Comment #1 from Denis Sherstennikov ---
Problem confirmed under:
g++ 5.3.0 20151204
g++ 5.2.1 20151031
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67779
--- Comment #14 from Thomas Koenig ---
The error occurs for class arrays only.
Changing
class(myclass), dimension(:) :: array
to
type(mysortable), dimension(:) :: array
in the more simplified test case results in correct
behavior.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68698
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69079
Bug ID: 69079
Summary: shared library does not load for variable
initializations with important code
Product: gcc
Version: 5.3.0
Status: UNCONFIRMED
Severity: n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60585
Andris Pavenis changed:
What|Removed |Added
Known to fail|4.8.2, 4.9.0|4.8.5, 4.9.3
--- Comment #2 from Andris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67710
Iain Sandoe changed:
What|Removed |Added
Attachment #37060|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67779
--- Comment #13 from Paul Thomas ---
(In reply to Thomas Koenig from comment #11)
> Created attachment 37182 [details]
> More simplified test case
>
> This illustrates the problem - the array is passed wrong on
> the first call to the subroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69070
Jakub Jelinek changed:
What|Removed |Added
CC||ssaraswati at gcc dot gnu.org
Target M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69070
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69011
--- Comment #10 from vehre at gcc dot gnu.org ---
Author: vehre
Date: Tue Dec 29 13:20:37 2015
New Revision: 231992
URL: https://gcc.gnu.org/viewcvs?rev=231992&root=gcc&view=rev
Log:
gcc/testsuite/ChangeLog:
2015-12-29 Andre Vehreschild
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69078
Bug ID: 69078
Summary: [C++14] function local static not initialized when
only used in a generic/variadic lambda
Product: gcc
Version: 6.0
Status: UNCONFIRMED
S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67779
--- Comment #12 from vehre at gcc dot gnu.org ---
That rings a bell. I feel like already have done some work on a similar issue.
I will take a look, when I have some time left.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67779
--- Comment #11 from Thomas Koenig ---
Created attachment 37182
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37182&action=edit
More simplified test case
This illustrates the problem - the array is passed wrong on
the first call to the su
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60465
--- Comment #37 from Sergei Trofimovich ---
The patch also fixes this old bug:
https://bugzilla.redhat.com/show_bug.cgi?id=33354
Despite being marked as fixed it fails on modern toolchain with slight
overflow.
Address of local constant was d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61203
--- Comment #10 from Zdenek Sojka ---
(In reply to Zdenek Sojka from comment #9)
> (In reply to Andrew Pinski from comment #8)
> > This does not fail on the trunk or 5.3 on aarch64-linux-gnu.
>
> It is failing for me on 4.7 and newer for all tes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61203
--- Comment #9 from Zdenek Sojka ---
(In reply to Andrew Pinski from comment #8)
> This does not fail on the trunk or 5.3 on aarch64-linux-gnu.
It is failing for me on 4.7 and newer for all tested targets, that is:
for 4.9, 5, trunk:
aarch64-un
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67781
--- Comment #10 from Mikael Pettersson ---
(In reply to Thomas Preud'homme from comment #9)
> I have a patch that seems to be working. Running regression testing and
> bootstrap now.
Is there any progress on that patch?
60 matches
Mail list logo
