--- Comment #6 from burnus at gcc dot gnu dot org 2006-12-03 08:32 ---
For
READ(1,ERR=10) J ! Read beyond EOF
there are two possible implementations one finds:
ifort: forrtl: severe (24): end-of-file during read
gfortran: Fortran runtime error: End of file
g95: Internal Erro
--- Comment #8 from reichelt at gcc dot gnu dot org 2006-12-03 10:20
---
Subject: Bug 28284
Author: reichelt
Date: Sun Dec 3 10:19:59 2006
New Revision: 119462
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119462
Log:
Backport:
2006-08-27 Simon Martin <[EMAI
--- Comment #14 from fxcoudert at gcc dot gnu dot org 2006-12-03 11:39
---
I'll fix it.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Assigned
--- Comment #5 from pault at gcc dot gnu dot org 2006-12-03 12:45 ---
Fixed in 4.3
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
Status|A
--- Comment #10 from lmillward at gcc dot gnu dot org 2006-12-03 13:12
---
Subject: Bug 29022
Author: lmillward
Date: Sun Dec 3 13:11:51 2006
New Revision: 119463
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119463
Log:
PR c++/29022
PR c++/27316
PR c+
--- Comment #5 from lmillward at gcc dot gnu dot org 2006-12-03 13:12
---
Subject: Bug 27316
Author: lmillward
Date: Sun Dec 3 13:11:51 2006
New Revision: 119463
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119463
Log:
PR c++/29022
PR c++/27316
PR c++
--- Comment #3 from lmillward at gcc dot gnu dot org 2006-12-03 13:12
---
Subject: Bug 28740
Author: lmillward
Date: Sun Dec 3 13:11:51 2006
New Revision: 119463
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119463
Log:
PR c++/29022
PR c++/27316
PR c++
--- Comment #11 from lmillward at gcc dot gnu dot org 2006-12-03 13:12
---
Now fixed in 4.0.4.
--
lmillward at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from lmillward at gcc dot gnu dot org 2006-12-03 13:13
---
Fixed in 4.0.4 as well.
--
lmillward at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from lmillward at gcc dot gnu dot org 2006-12-03 13:13
---
Fixed in 4.0.4 as well.
--
lmillward at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #16 from pault at gcc dot gnu dot org 2006-12-03 13:38 ---
Created an attachment (id=12730)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12730&action=view)
This fixes the INTERFACE part of the problem.
I have not regtested the full suite yet; just gfortran.dg/i*
The
--- Comment #1 from tkoenig at gcc dot gnu dot org 2006-12-03 13:59 ---
I forgot to assign this to myself. I'll do this
together with PR 30009.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from tkoenig at gcc dot gnu dot org 2006-12-03 14:06 ---
(In reply to comment #6)
> For
>READ(1,ERR=10) J ! Read beyond EOF
> there are two possible implementations one finds:
> ifort: forrtl: severe (24): end-of-file during read
Really? With ifort 8.1, I get
--- Comment #8 from burnus at gcc dot gnu dot org 2006-12-03 14:17 ---
> >READ(1,ERR=10) J ! Read beyond EOF
> > ifort: forrtl: severe (24): end-of-file during read
>
> Really?
Yes, really. Note: END /= ERR in the two examples.
> With ifort 8.1, I get
>READ(1,END=10)
--- Comment #17 from burnus at gcc dot gnu dot org 2006-12-03 14:44 ---
> This fixes the INTERFACE part of the problem.
> I have not regtested the full suite yet; just gfortran.dg/i*
I just regression tested it on x86_64-unknown-linux-gnu.
I also tried to compile all_cp2k_gfortran.f90 -
Building libgfortran there dies, probably due to the extern inline patch:
.libs/signal.o(.text+0x0): In function `__sigaddset14':
: multiple definition of `__sigaddset14'
.libs/kill.o(.text+0x0): first defined here
.libs/signal.o(.text+0x75): In function `__sigdelset14':
: multiple definition of `
--- Comment #2 from h dot b dot furuseth at usit dot uio dot no 2006-12-03
15:49 ---
Subject: Re: [4.0/4.1 Regression] while(__builtin_expect()) pessimizes loop
pinskia at gcc dot gnu dot org writes:
> Fixed for 4.2.0:
> (...)
> Status|UNCONFIRMED |RESOLVE
--- Comment #15 from fxcoudert at gcc dot gnu dot org 2006-12-03 16:14
---
Created an attachment (id=12731)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12731&action=view)
Tentative patch
Would the attached patch work? I'm in no position to try it out right now.
--
http://g
The attached program should print
void func(int &, int &)
void func(int &, int &)
Instead it prints
void func(T&, T&) [with T = int]
void func(int&, int&)
This causes efficiency bugs that are very difficult to detect.
--
Summary: Wrong function selected
Product: gcc
--- Comment #1 from bagnara at cs dot unipr dot it 2006-12-03 16:39 ---
Created an attachment (id=12732)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12732&action=view)
Program exhibiting the described behavior
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30059
--- Comment #2 from paolo at gcc dot gnu dot org 2006-12-03 17:16 ---
Subject: Bug 29989
Author: paolo
Date: Sun Dec 3 17:15:46 2006
New Revision: 119467
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119467
Log:
2006-12-03 Paolo Carlini <[EMAIL PROTECTED]>
PR libstd
--- Comment #3 from pcarlini at suse dot de 2006-12-03 17:16 ---
Done.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-12-03 17:34 ---
No GCC, is finally correct to what the standard mentions is right.
*** This bug has been marked as a duplicate of 2922 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #26 from pinskia at gcc dot gnu dot org 2006-12-03 17:34
---
*** Bug 30059 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #18 from paulthomas2 at wanadoo dot fr 2006-12-03 17:42 ---
Subject: Re: [meta-bugs] ICEs with CP2K
Tobias,
>
> The patch looks good -- and the test cases as well.
>
Great!
> Just for completeness, the relevant part of the standard is:
> "C1209 (R1206) A procedure-name s
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |blocker
Component|bootstrap |target
Tar
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-12-03 17:51 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|REOPENED
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-12-03 17:53 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
enum crap {
foo = 1
};
class foo {
};
int main(int argc, char **argv)
{
foo *a=new foo;
}
results in
test.cpp: In function 'int main(int, char**)':
test.cpp:10: error: 'a' was not declared in this scope
test.cpp:10: error: expected type-specifier before 'foo'
test.cpp:10: err
--- Comment #9 from tkoenig at gcc dot gnu dot org 2006-12-03 18:56 ---
I've looked at the F 2003 standard, and at least there
the wording is clear:
9.10:
# An end-of-file condition occurs in the following cases:
#
# (1) When an endfile record is encountered during reading of a file
#
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-03 18:56 ---
Actually I think the error is clear once you remember * is also multiplication.
so we have
foo * a = new foo;
Also I doubt we can improve the error message here.
Cameau online gives basically the same error messag
--- Comment #2 from bero at arklinux dot org 2006-12-03 19:05 ---
True, but the warning bit (test.cpp:2: warning: declaration of enum value 'foo'
shadows class 'foo') should be doable (and would make the rest much easier to
spot).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30060
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-12-03 19:34 ---
> Is this related to the standard requirement that a source file must end with a
> newline character? (and thus cannot be empty?)
Not really.
Confirmed:
==17881== Invalid read of size 1
==17881==at 0x87F2933: _c
--- Comment #4 from uros at gcc dot gnu dot org 2006-12-03 19:40 ---
Subject: Bug 30041
Author: uros
Date: Sun Dec 3 19:40:06 2006
New Revision: 119468
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119468
Log:
PR target/30041
* config/i386/sse.md ("*sse3_movddu
--- Comment #19 from paulthomas2 at wanadoo dot fr 2006-12-03 19:41 ---
Subject: Re: [meta-bugs] ICEs with CP2K
Tobias,
> Note that this does not fix everything as gfortran rejects also
> interface_y.f90
> if I comment the "call bl_copy(1.0, chr)"; if I understand the standard
> corre
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2006-12-03 20:16
---
I have a patch for this testing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30005
--- Comment #20 from pault at gcc dot gnu dot org 2006-12-03 21:01 ---
Created an attachment (id=12733)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12733&action=view)
A further development of the patch
This version now behaves in the same way as other compilers; the testcase
int
--- Comment #6 from manu at gcc dot gnu dot org 2006-12-03 21:02 ---
(In reply to comment #3)
> Hi Manual,
Manuel (or Manu) http://en.wikipedia.org/wiki/Manuel
not manual: http://en.wikipedia.org/wiki/Manual
:-)
> The real issue is that OPT_Wdiv_by_zero needs to be enabled by -pedant
--- Comment #10 from tkoenig at gcc dot gnu dot org 2006-12-03 21:02
---
Created an attachment (id=12734)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12734&action=view)
first attempt at a patch
This should fix this PR, and PR 30056 as well.
--
http://gcc.gnu.org/bugzilla/s
--- Comment #7 from joseph at codesourcery dot com 2006-12-03 21:05 ---
Subject: Re: integer division by zero in subexpression should
be overflow
On Sun, 3 Dec 2006, manu at gcc dot gnu dot org wrote:
> > The real issue is that OPT_Wdiv_by_zero needs to be enabled by -pedantic
> > in
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-12-03 21:08 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #3 from manu at gcc dot gnu dot org 2006-12-03 21:12 ---
(In reply to comment #2)
> The problem is that we believe we can handle all errno checking/setting via
> the expand_errno_check() routine which is not true for overflow/underflow but
> only for invalid arguments that re
--- Comment #4 from hjl at lucon dot org 2006-12-03 21:13 ---
Gcc 4.2 has the same problem. The backported patch is at
http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00127.html
--
hjl at lucon dot org changed:
What|Removed |Added
---
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-12-03 21:19 ---
(In reply to comment #4)
> Gcc 4.2 has the same problem.
So this is not a regression.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-12-03 21:32 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRM
--- Comment #6 from hjl at lucon dot org 2006-12-03 21:39 ---
I never said it was a regression and I opened it against gcc 4.2.0 if you
take a look.
--
hjl at lucon dot org changed:
What|Removed |Added
--
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-12-03 21:41 ---
Someone else is going to have to look into this as this works just fine on
spu-elf.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-12-03 21:43 ---
(In reply to comment #6)
> I never said it was a regression and I opened it against gcc 4.2.0 if you
> take a look.
So what if you opened it against 4.2. It is not a regression and by own normal
policy if it has bee
--- Comment #21 from burnus at gcc dot gnu dot org 2006-12-03 21:50 ---
> Do you think that the error in gfortran.dg/interface_1.f90 is correct?
> I have fix for the above that also stops the doubling of the error
> message. However, it breaks interface_1.f90 because there is no
> r
--- Comment #19 from r dot schwebel at pengutronix dot de 2006-12-03 21:57
---
(In reply to comment #18)
> The patch is also needed on gcc-4_1-branch.
Doesn't work: this happens when I add the patch to 4.1.1:
[EMAIL
PROTECTED]:/media/rscusb1_plain/svn/oselas/toolchain/trunks/OSELAS.T
--- Comment #16 from ebotcazou at gcc dot gnu dot org 2006-12-03 22:02
---
> Would the attached patch work? I'm in no position to try it out right now.
Thanks. Compilable version to be attached, tested on all Solaris versions for
the 3 branches, results are as expected again.
Why doe
--- Comment #17 from ebotcazou at gcc dot gnu dot org 2006-12-03 22:03
---
Created an attachment (id=12735)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12735&action=view)
Compilable version of previous patch.
--
ebotcazou at gcc dot gnu dot org changed:
What|
--- Comment #22 from burnus at gcc dot gnu dot org 2006-12-03 22:07 ---
And here is the relevant part of the standard Fortran 2003, Section 11.2.1
("USE") [cf. also F95, Sec 11.3.2]:
"Two or more accessible entities, other than generic interfaces or defined
operators, may have the same
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2006-12-03 22:45
---
Created an attachment (id=12736)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12736&action=view)
Preliminary patch
This patch adds a few checks for types of errors on opening a file to give a
more use frie
--- Comment #20 from pbrook at gcc dot gnu dot org 2006-12-03 22:48 ---
As mentioned in the original patch submission mail you need a newer gas.
http://gcc.gnu.org/ml/gcc-patches/2006-09/msg00805.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28516
--- Comment #23 from burnus at gcc dot gnu dot org 2006-12-03 22:49 ---
(In reply to comment #20)
> now gives a warning in interface_1.f90, rather than an error.
I think one can live with this - Lahey also gives only a warning. (ifort a
warning; Richard says it is invalid.)
However, on
--- Comment #23 from mkoeppe at gmx dot de 2006-12-04 00:17 ---
(In reply to comment #22)
> Shell script issue:
> While building in builddir/gcc there are 3 scripts generated:
> as, nm, collect-ld. These have a wrong header. When gmake fails, you need to
> modify the first line "#!sh" ->
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-04 00:25 ---
This:
In file included from /usr/include/sys/signal.h:34,
from /usr/include/signal.h:26,
from ../../../libiberty/pex-unix.c:28:
/usr/include/sys/siginfo.h:259: error: parse error bef
--- Comment #8 from dave at hiauly1 dot hia dot nrc dot ca 2006-12-04
01:29 ---
Subject: Re: Shared libstdc++ fails to link
> > > This problem was introduced by this change:
> > That makes less sense really, because this just changes how to deal with
> > TREE_NOTHROW. This sounds lik
--- Comment #3 from echristo at gcc dot gnu dot org 2006-12-04 02:10
---
Subject: Bug 24598
Author: echristo
Date: Mon Dec 4 02:10:10 2006
New Revision: 119477
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119477
Log:
2006-12-03 Eric Christopher <[EMAIL PROTECTED]>
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2006-12-04 02:18
---
Patch reviewed and tested. Looks good to go. I assume you tested the part of
the corrupted file somehow. I suppose we could right a test case uses stream
I/O to build a bogus file and then try to read it and c
--- Comment #18 from pinskia at gcc dot gnu dot org 2006-12-04 02:24
---
Subject: Bug 14329
Author: pinskia
Date: Mon Dec 4 02:24:42 2006
New Revision: 119478
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119478
Log:
2006-12-03 Richard Henderson <[EMAIL PROTECTED]>
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail||4.1.1
Known to work||4.3.0
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com
|dot org
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com
|dot org
--- Comment #3 from patchapp at dberlin dot org 2006-12-04 05:20 ---
Subject: Bug number PR30005
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00181.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #3 from patchapp at dberlin dot org 2006-12-04 07:30 ---
Subject: Bug number PR target/29682
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00187.html
--
http://gcc.gnu.org/bug
67 matches
Mail list logo
