http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46152
--- Comment #7 from Tobias Burnus 2010-10-24
07:01:14 UTC ---
(In reply to comment #6)
> Note that
> allocate (integer :: a)
> is really only useful once we have unlimited polymorphism
Well, it was motivated by:
character(len=:), allocatable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46156
Summary: ICE: in tsubst_copy, at cp/pt.c:11370 with
-frounding-math
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43018
--- Comment #5 from Tobias Burnus 2010-10-24
10:04:19 UTC ---
Actually, it does not have anything to do with PACK but rather with the
assignment -- which implicitly also happens if one uses
print *, pack(a2,[.true.])
The assignment works as fo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45827
--- Comment #22 from Hans-Werner Boschmann 2010-10-24 10:17:00 UTC ---
Yes, I still get the error with later revisions. I am using an amd64 machine
with open SuSE 11.2. Here are some updates of my statements:
* All means like renaming files or us
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46156
Yu Simin changed:
What|Removed |Added
CC||silver24k at gmail dot com
--- Comment #1 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46151
--- Comment #2 from Paolo Carlini 2010-10-24
10:37:00 UTC ---
Ah this one. Certainly we want to remember it. And I still believe that Jason's
idea of adding a global mechanism to at least warn the user if he tries to link
together objects built w
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28049
--- Comment #12 from Nicola Pero 2010-10-24
10:39:09 UTC ---
Author: nicola
Date: Sun Oct 24 10:39:05 2010
New Revision: 165898
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165898
Log:
In gcc/testsuite/:
2010-10-24 Nicola Pero
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24393
--- Comment #9 from Nicola Pero 2010-10-24 10:39:09
UTC ---
Author: nicola
Date: Sun Oct 24 10:39:05 2010
New Revision: 165898
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165898
Log:
In gcc/testsuite/:
2010-10-24 Nicola Pero
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24393
Nicola Pero changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28049
Nicola Pero changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45827
--- Comment #23 from Tobias Burnus 2010-10-24
11:10:18 UTC ---
(In reply to comment #22)
> Yes, I still get the error with later revisions.
:-(
> * Not putting use statements into "proper order" doesn't mean that the error
> shows up, it randoml
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45827
--- Comment #24 from Mikael Morin 2010-10-24
11:56:39 UTC ---
(In reply to comment #22)
> Still, this is not what I take to mean "works for me".
WORKSFORME means that it works for us. If it was working for you, I assume you
wouldn't have reported
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45827
--- Comment #25 from Mikael Morin 2010-10-24
12:02:34 UTC ---
Created attachment 22140
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22140
Version of the test that works for me.
Just to be clear. Can you check that with the just attached v
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46157
Summary: internal compiler error: Segmentation fault
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
AssignedTo: unassig...@
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46154
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46156
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46156
H.J. Lu changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
Target Milestone|-
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38846
--- Comment #7 from Dominique d'Humieres 2010-10-24
13:49:12 UTC ---
This pr looks like a duplicate of pr43359. Can you check that it has not been
fixed?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46155
--- Comment #5 from joseph at codesourcery dot com 2010-10-24 14:07:25 UTC ---
On Sun, 24 Oct 2010, david.kirkby at onetel dot net wrote:
> On an IBM server running AIX 5.3, 'fprnd_t' is clearly defined in the IBM
> system header file /usr/includ
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46155
--- Comment #6 from joseph at codesourcery dot com 2010-10-24 14:12:05 UTC ---
On Sun, 24 Oct 2010, david.kirkby at onetel dot net wrote:
> It looks to me that the GCC header file lacks several definitions that are in
> the IBM header file (DEC12
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46155
--- Comment #7 from Dr. David Kirkby
2010-10-24 15:05:50 UTC ---
(In reply to comment #5)
> On Sun, 24 Oct 2010, david.kirkby at onetel dot net wrote:
>
> > On an IBM server running AIX 5.3, 'fprnd_t' is clearly defined in the IBM
> > system hea
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45827
--- Comment #26 from Jerry DeLisle 2010-10-24
15:14:59 UTC ---
I did not see any reply to my comment #19. Isn't it obvious there is something
wromg at that point in the module.c ? Did I miss something in the thread here?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46155
--- Comment #8 from joseph at codesourcery dot com 2010-10-24 15:21:44 UTC ---
On Sun, 24 Oct 2010, david.kirkby at onetel dot net wrote:
> I don't have a copy of the C standard. Is there one publicly available? In
> your
> opinion, are IBM wron
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45827
--- Comment #27 from Mikael Morin 2010-10-24
15:48:27 UTC ---
(In reply to comment #26)
> I did not see any reply to my comment #19. Isn't it obvious there is
> something
> wromg at that point in the module.c ?
No, it's unreleased memory; it's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46146
Thomas Koenig changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46155
--- Comment #9 from Dr. David Kirkby
2010-10-24 16:10:30 UTC ---
(In reply to comment #8)
> On Sun, 24 Oct 2010, david.kirkby at onetel dot net wrote:
>
> > I don't have a copy of the C standard. Is there one publicly available? In
> > your
> >
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45735
--- Comment #1 from Nicola Pero 2010-10-24 16:48:59
UTC ---
Author: nicola
Date: Sun Oct 24 16:48:57 2010
New Revision: 165901
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165901
Log:
2010-10-24 Nicola Pero
PR objc/45735
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45735
Nicola Pero changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46155
--- Comment #10 from joseph at codesourcery dot com 2010-10-24 17:50:44 UTC ---
On Sun, 24 Oct 2010, david.kirkby at onetel dot net wrote:
> > > I don't have a copy of the C standard. Is there one publicly available?
> > > In your
> > > opinion,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45827
--- Comment #28 from Jerry DeLisle 2010-10-24
18:56:49 UTC ---
There is a quality of implementation issue going on here. Our goal has always
been "zero" leaks. The reason? These errors can and do mask other things
going on. This to me looks l
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43018
--- Comment #6 from Tobias Burnus 2010-10-24
19:10:10 UTC ---
The problem was that for copying the component, not the size of the element but
the size of the pointer was used.
Cf. http://gcc.gnu.org/ml/fortran/2010-10/msg00229.html for more deta
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38846
Tobias Burnus changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46155
--- Comment #11 from Kalle Olavi Niemitalo 2010-10-24
19:47:27 UTC ---
(In reply to comment #7)
> In your opinion, are IBM wrong to define fprnd_t in /usr/include/float.h?
IBM's definition of fprnd_t in is within #ifdef _ALL_SOURCE. I
presume
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46158
Summary: Spurious never executed warning
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45451
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #12
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45827
--- Comment #29 from Mikael Morin 2010-10-24
19:59:20 UTC ---
(In reply to comment #28)
> There is a quality of implementation issue going on here. Our goal has always
> been "zero" leaks. The reason? These errors can and do mask other things
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46158
--- Comment #1 from William K Foster 2010-10-24
19:59:23 UTC ---
Also, in a much more complicated test case (not provided) I get a much more
obtuse warning message that does not refer me to my file, but instead a header:
/usr/include/c++/4.2/bit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45451
--- Comment #13 from Tobias Burnus 2010-10-24
21:42:33 UTC ---
(In reply to comment #12)
> If one looks at the dump
Scratch that part. In one case one allocates the component (integr(4)*4) in the
other case the type, i.e. the array descriptor.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46159
Summary: [4.5/4.6 Regression] Bogus warning about lambdas
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Comp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46160
Summary: [4.5/4.6 Regression] ICE with volatile structure and
enum
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46161
Summary: [OOP] Invalid: Passing non-polymorphic to allocatable
polymorphic dummy
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45451
--- Comment #14 from Tobias Burnus 2010-10-24
22:31:19 UTC ---
(In reply to comment #13)
> The following works - though I am not sure whether it is the correct patch.
> Janus, what do you think?
I mean in particular gfc_expr_to_initialize (expr)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46152
--- Comment #8 from Steve Kargl
2010-10-25 00:25:04 UTC ---
On Sat, Oct 23, 2010 at 07:04:51PM +, dominiq at lps dot ens.fr wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46152
>
> --- Comment #1 from Dominique d'Humieres
> 2010-10-2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46152
--- Comment #9 from Steve Kargl
2010-10-25 00:33:49 UTC ---
On Sat, Oct 23, 2010 at 06:50:21PM +, burnus at gcc dot gnu.org wrote:
>
> Compiling the following program:
>
> implicit none ! << crucial
> integer, allocatable :: a
> allocate (
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46152
--- Comment #10 from Steve Kargl
2010-10-25 00:47:49 UTC ---
Investigating a little more. I could not understand
why this issue was not caught earlier. Afterall, I
use 'implicit none' in all the code I write, and I
wrote a testcase for a type-
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46160
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46162
Summary: Invalid SFINAE with static member function/variable
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46152
--- Comment #11 from Steve Kargl
2010-10-25 04:33:38 UTC ---
On Mon, Oct 25, 2010 at 12:48:10AM +, sgk at troutmask dot
apl.washington.edu wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46152
>
> --- Comment #10 from Steve Kargl
> 20
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46163
Summary: GCC Produces Invalid Assembly Code from Anonymous
Function Syntax
Product: gcc
Version: 4.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46010
--- Comment #7 from Jerry DeLisle 2010-10-25
05:47:58 UTC ---
Here is a patch.
Please try this if you can.
Index: list_read.c
===
--- list_read.c(revision 165900)
+++ list_read
50 matches
Mail list logo
