I have tested this code on "gcc version 4.3.0 20070202 (experimental)" as well
as "gcc version 3.4.4 (cygming special)".
f1, f2, d1 and d2 declare functions with the same types but one has default
parameters.
It appears that the standard requires that all default args should not
propagate to the
Compiling and running the code below produces the following output:
$ g++ -Wall -DT=long -g3 union-bug.C && ./a.out
&array= 0x7fff11782ef0
&a= 0x7fff11782f20
B={1,3,5}
A={-1719443200,4196007,-1719451616}
A and B should contain the same values, but A contains garbage ins
--- Comment #5 from sebor at roguewave dot com 2007-08-05 00:31 ---
There are third party tools that track these types of problems. Some of them
have started to make their way into compilers. For example, the HP static
analysis tool called Code Adviser is integrated into the HP aCC compi
bash-3.2$ svn proplist config/alpha/constraints.md
Properties on 'config/alpha/constraints.md':
svn:mime-type
bash-3.2$
It shouldn't be marked with any property since it is a text file.
--
Summary: config/alpha/constraints.md is marked as mime-type
Product: gcc
When debugging code produced by g++-4.3.0-20070716 the debugger regularly
outputs the following error message when stopping at breakpoints or examining
stack frames:
error: warning: (Internal error: pc 0x419e59 in read in psymtab, but not in
symtab.)
Compiling the same code with g++-4.1.2 and ru
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |tkoenig at gcc dot gnu dot
|dot org
--- Comment #10 from pault at gcc dot gnu dot org 2007-08-04 22:13 ---
The problem occurs whenever the destination array is described by and array
descriptor; eg.
complex(kind=8) :: a(2,2), b(2,2)
call testcase (a, b)
contains
subroutine testcase (a, b)
complex(kind=8) :: a(:,
--- Comment #4 from gdr at cs dot tamu dot edu 2007-08-04 22:09 ---
Subject: Re: add checking for array new & delete
"dcb314 at hotmail dot com" <[EMAIL PROTECTED]> writes:
| (In reply to comment #1)
| > Special, dedicated tools exist for that task.
|
| Would you be willing to name
--- Comment #3 from gdr at cs dot tamu dot edu 2007-08-04 22:06 ---
Subject: Re: add checking for array new & delete
"dcb314 at hotmail dot com" <[EMAIL PROTECTED]> writes:
| The compiler can generate a whole bunch of warnings
| already.
Which fall in different mindset that the one y
"dcb314 at hotmail dot com" <[EMAIL PROTECTED]> writes:
| The compiler can generate a whole bunch of warnings
| already.
Which fall in different mindset that the one you would like.
-- Gaby
--- Comment #10 from samuel dot thibault at ens-lyon dot org 2007-08-04
22:02 ---
It got fixed in CVS.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21821
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
URL||http://gcc.gnu.org/ml/gcc-
|
--- Comment #8 from pault at gcc dot gnu dot org 2007-08-04 20:58 ---
Subject: Bug 31214
Author: pault
Date: Sat Aug 4 20:58:11 2007
New Revision: 127214
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127214
Log:
2007-08-04 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #7 from pault at gcc dot gnu dot org 2007-08-04 20:46 ---
Subject: Bug 31214
Author: pault
Date: Sat Aug 4 20:46:11 2007
New Revision: 127213
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127213
Log:
2007-08-04 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #28 from tkoenig at gcc dot gnu dot org 2007-08-04 20:14
---
Subject: Bug 32770
Author: tkoenig
Date: Sat Aug 4 20:14:26 2007
New Revision: 127212
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127212
Log:
2007-08-04 Thomas Koenig <[EMAIL PROTECTED]>
PR
--- Comment #9 from pault at gcc dot gnu dot org 2007-08-04 20:13 ---
(In reply to comment #4)
> Confirmed.
>
> Paul, I'm putting you on the CC list because you fixed
> PR 31994, the original conjg(transpose()) bug. Maybe
> you can do something about this one :-)
>
Nice try but I thi
Compiling the testsuite program:
$ gfortran -fdefault-integer-8 getarg_1.f90
getarg_1.f90:6.14:
CALL GETARG(I,ARGS)
1
Error: Type of argument 'count' in call to 'getarg' at (1) should be
INTEGER(8), not INTEGER(4)
getarg_1.f90:12.14:
CALL GETARG(I,ARGS)
1
Error: Ty
--- Comment #2 from dcb314 at hotmail dot com 2007-08-04 19:52 ---
(In reply to comment #1)
> Special, dedicated tools exist for that task.
Would you be willing to name three of them ?
> The above should not be the business of the *compiler*.
Why not ?
The compiler can generate a w
--- Comment #2 from burnus at gcc dot gnu dot org 2007-08-04 19:32 ---
> Aren't they included in the current F2008, by any chance?
Yes and no. The Fortran 2008 draft has the following functions, but they are
not necessarily called the same as the typical vendor extensions.
http://j3-fort
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-08-04 18:49
---
Thanks Tobias for the patch, here's an updated version that I intend to submit
for review...
Index: runtime/backtrace.c
===
--- runtime/backtrace.c
--- Comment #27 from tkoenig at gcc dot gnu dot org 2007-08-04 18:21
---
Subject: Bug 32770
Author: tkoenig
Date: Sat Aug 4 18:20:54 2007
New Revision: 127210
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127210
Log:
2007-08-04 Thomas Koenig <[EMAIL PROTECTED]>
PR
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-08-04 17:53
---
Aren't they included in the current F2008, by any chance?
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #7 from patchapp at dberlin dot org 2007-08-04 17:40 ---
Subject: Bug number PR32987
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/2007-08/msg00246.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #6 from burnus at gcc dot gnu dot org 2007-08-04 17:37 ---
> > - Silently accept the tab in libgfortran
> I disagree on this point.
Discussion -> [EMAIL PROTECTED] list; starts here:
http://gcc.gnu.org/ml/fortran/2007-08/msg00097.html
> > - Give a warning or an error with -
--- Comment #5 from sgk at troutmask dot apl dot washington dot edu
2007-08-04 17:00 ---
Subject: Re: TAB in FORMAT: accept extension, warn with -std=f*
On Sat, Aug 04, 2007 at 04:53:33PM -, burnus at gcc dot gnu dot org wrote:
>
>
> I therefore suggest:
> - Silently accept the
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32969
--- Comment #14 from kargl at gcc dot gnu dot org 2007-08-04 16:53 ---
Should be fixed on trunk. No back port.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #4 from burnus at gcc dot gnu dot org 2007-08-04 16:53 ---
I just checked: ifort, sunf95, openf95, g95 and even the picky NAG f95 accept
it. None of the compilers gives a warning except of "ifort" when passing the
option "-stand 95":
fortcom: Warning: format_with_tab.f, line
--- Comment #3 from kargl at gcc dot gnu dot org 2007-08-04 16:53 ---
Should be fixed on trunk. No back port.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from kargl at gcc dot gnu dot org 2007-08-04 16:49 ---
Subject: Bug 32969
Author: kargl
Date: Sat Aug 4 16:48:50 2007
New Revision: 127205
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127205
Log:
2008-08-04 Steven G. Kargl <[EMAIL PROTECTED]>
PR fort
--- Comment #13 from kargl at gcc dot gnu dot org 2007-08-04 16:49 ---
Subject: Bug 32968
Author: kargl
Date: Sat Aug 4 16:48:50 2007
New Revision: 127205
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127205
Log:
2008-08-04 Steven G. Kargl <[EMAIL PROTECTED]>
PR for
--- Comment #3 from kargl at gcc dot gnu dot org 2007-08-04 16:26 ---
Here's a patch that permits gfortran to accept your INVALID code.
Your code should be fixed, and I will activity oppose application
of this patch by others.
Index: format.c
===
--- Comment #3 from michelin60 at gmail dot com 2007-08-04 16:11 ---
Created an attachment (id=14024)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14024&action=view)
Failing *.s
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32988
--- Comment #2 from michelin60 at gmail dot com 2007-08-04 16:10 ---
Created an attachment (id=14023)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14023&action=view)
OK *.I
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32988
--- Comment #6 from jdgressett at amli-denton dot com 2007-08-04 16:10
---
Ada compiler in gcc-4.2.1 still fails C380004. Built on Fedora 7.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31174
--- Comment #1 from michelin60 at gmail dot com 2007-08-04 16:09 ---
Created an attachment (id=14022)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14022&action=view)
failing *.i
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32988
-cpu=G4 --enable-clocale=gnu
--with-system-zlib
Thread model: posix
gcc version 4.3.0 20070804 (experimental)
/usr/libexec/gcc/powerpc-unknown-linux-gnu/4.3.0/cc1 -E -quiet -nostdinc -v
-Iinclude -Iarch/powerpc -Iarch/powerpc/include -Iarch/powerpc -D__unix__
-D__gnu_linux__ -D__linux__ -Dunix
--- Comment #2 from kargl at gcc dot gnu dot org 2007-08-04 15:56 ---
Fix your code. A tab is not a legal substitution for a space
character.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rask at sygehus dot dk 2007-08-04 15:37 ---
This appears to intentional. On systems without a prefix on labels, registers
are always prefixed with %. This is so that you can have global variables named
.e.g. edx.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=294
--- Comment #1 from satyaakam at yahoo dot co dot in 2007-08-04 13:56
---
Created an attachment (id=14021)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14021&action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32987
GFortarn has runtime error when FORMAT has TAB char between parameters (see
testcase)
10 format ('Hello ','bug!')
^^^
> ./a.out
At line 2 of file format_with_tab.f
Fortran runtime error: Unexpected element in format
('Hello ', 'bug!')
^
This b
--- Comment #1 from burnus at gcc dot gnu dot org 2007-08-04 13:36 ---
"C588 (R558) A common-block-object shall not be a dummy argument, an
allocatable variable, a derived-type object with an ultimate component that is
allocatable, an automatic object, a function name, an entry name, a v
--- Comment #2 from burnus at gcc dot gnu dot org 2007-08-04 13:18 ---
And the following valid program is rejected:
use iso_c_binding
implicit none
type, bind(C):: a
integer(c_int) :: i
end type a
type(a) :: t
common /c/ t
end
--
http://gcc.gnu.org/bugzilla/show_bug
--- Comment #1 from burnus at gcc dot gnu dot org 2007-08-04 13:17 ---
Interestingly, the following gives an error:
type a
integer :: i
end type a
type(a) :: t
common /c/ t
end
Related, the following is accepted but invalid (for different reasons):
"C588 (R558) A common-b
--- Comment #9 from patchapp at dberlin dot org 2007-08-04 13:10 ---
Subject: Bug number PR target/30315
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/2007-08/msg00242.html
--
http://gcc.gnu.org/bug
The following is invalid, but the error message does not help much:
function a(n)
real :: x(n)
common /c/ x
end function
Error: Variable 'n' at (1) in this context must be constant
Sunf95:
real :: x(n)
^
ERROR: "X" is a common-block-object, therefore it must not be declared as an
"C589 (R558) If a common-block-object is of a derived type, it shall be a
sequence type (4.5.1) or a type with the BIND attribute and it shall have no
default initialization."
A default initializer is also accepted.
Testcase based on the invalid gfortran.dg/namelist_14.f90:
!{ dg-do compile }
mo
--- Comment #1 from gdr at cs dot tamu dot edu 2007-08-04 13:01 ---
Subject: Re: New: add checking for array new & delete
"dcb314 at hotmail dot com" <[EMAIL PROTECTED]> writes:
| Given the following C++ code
|
| class K
| {
| public:
| void f();
| void g();
|
| pri
"dcb314 at hotmail dot com" <[EMAIL PROTECTED]> writes:
| Given the following C++ code
|
| class K
| {
| public:
| void f();
| void g();
|
| private:
| int * a;
| double * b;
| float * c;
| unsigned int * d;
| };
|
| void K :: f()
| {
| a
Given the following C++ code
class K
{
public:
void f();
void g();
private:
int * a;
double * b;
float * c;
unsigned int * d;
};
void K :: f()
{
a = new int;
b = new double [ 10];
delete c;
delete [] d;
}
void K ::
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-08-04 12:06 ---
I think this is exactly the same as PR 32032, the inliner not setting
has_volatile_ops correctly.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #6 from burnus at gcc dot gnu dot org 2007-08-04 11:57 ---
Created an attachment (id=14020)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14020&action=view)
Patch for invoke.texi
> I'd go for implementing isnan as an extension, and only isnan. (until we get
> the IEEE
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-08-04 11:54 ---
Mine.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned
--- Comment #6 from patchapp at dberlin dot org 2007-08-04 11:50 ---
Subject: Bug number PR31214
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/2007-08/msg00239.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #17 from axel at freakout dot de 2007-08-04 10:45 ---
Subject: Re: gcc 4.2.0 compiled vanilla kernel
2.4.34.5 crashes when VIA C3 optimized -march=c3
According to pluto at agmk dot net:
> > but who's bug is it?
>
> it's a kernel bug exposed by recent gcc.
>
i'm still co
55 matches
Mail list logo
