2007ß811, seen with a compiler configured with --enable-targets=all, all tests
for the 64/multilib dir fail:
Matthias
Executing on host:
/scratch/packages/gcc/snap/gcc-snapshot-20070811/build/gcc/xgcc
-B/scratch/packages/gcc/snap/gcc-snapshot-20
070811/build/gcc/
/scratch/packages/gcc/snap/gcc-
...with the semantics that such accesses should work as-if the underlying
object
had a volatile-qualified type.
Some GCC users (notably the Linux kernel) already depend on this behaviour;
however since GCC never actually supported it their expectations keep breaking
(see for example PR21568, PR222
The code generated to call RANDOM_SEED doesn't take into account the existence
of a possible default integer kind other than 4. For example:
$ cat o.f90
integer :: i, j(8)
call random_seed (size=i)
print *, i
call random_seed (get=j)
print *, j
call random_seed (put=j)
end
$ gfortran
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot
|dot org
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last recon
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Severity|enhancement |normal
Status|UNCONFIRMED |NEW
Eve
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last recon
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2007-08-12 10:27
---
Fixed by Paul.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Sta
--- Comment #4 from stevenb dot gcc at gmail dot com 2007-08-12 10:36
---
Subject: Re: debug info of modules
This is still on my TODO-list, but not for GCC 4.3.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29635
--- Comment #1 from tkoenig at gcc dot gnu dot org 2007-08-12 11:05 ---
> Thomas, any opinion on that?
The arguments to random_seed are restricted to default
integer, at least up to F 2003, so we should just reject anything else.
We'd then need two versions of random_seed for kind=4 an
--- Comment #7 from tkoenig at gcc dot gnu dot org 2007-08-12 11:19 ---
> So, since it's just shuffling bytes (and it's a bijective operation, of
> course), I don't think I'm messing with any of the properties of the
> generator.
I concur. It might even be better to do bit-wise shuff
--- Comment #12 from patchapp at dberlin dot org 2007-08-12 11:45 ---
Subject: Bug number PR32962
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/msg00774.html
--
http://gcc.gnu.org/bugzilla/s
--- Comment #3 from patchapp at dberlin dot org 2007-08-12 11:50 ---
Subject: Bug number PR32827
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/msg00775.html
--
http://gcc.gnu.org/bugzilla/sh
This is strange.
gfortran.dg/negative_unit.f fails with -fdefault-integer-8. A
call to generate_error() is issued, which doesn't really make sense:
$ gfortran -fdump-tree-original -fdefault-integer-8 negative_unit.f
$ ./a.out
At line 19 of file negative_unit.f
Fortran runtime error: Negative un
--- Comment #2 from victork at il dot ibm dot com 2007-08-12 14:40 ---
I tested the fix at it worked OK for me.
--
victork at il dot ibm dot com changed:
What|Removed |Added
--
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-08-12 16:40
---
(In reply to comment #1)
> The arguments to random_seed are restricted to default
> integer, at least up to F 2003, so we should just reject anything else.
> We'd then need two versions of random_seed for kind=4 a
--- Comment #10 from fxcoudert at gcc dot gnu dot org 2007-08-12 16:41
---
Complete patch submitted:
http://gcc.gnu.org/ml/gcc-patches/2007-08/msg00782.html
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #18 from belyshev at depni dot sinp dot msu dot ru 2007-08-12
16:58 ---
Another test for this bug:
/* { dg-do compile } */
/* { dg-options "-O2 -fdump-tree-final_cleanup" } */
extern void link_error (void);
static const int my_array [3] = { 4, 5, 6 };
void f0 (void)
{
i
--- Comment #2 from pcarlini at suse dot de 2007-08-12 19:11 ---
Working on it.
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at g
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2007-08-12 19:47
---
I will give this a shot.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2007-08-12 19:50
---
(In reply to comment #7)
> It might even be better to do bit-wise shuffling to get
> the most out of the millisecond-field in date_and_time.
I thought about that at the beginning, but then it really gets messy :(
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-08-12 19:51 ---
I am testing this patch right now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30427
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-08-12 19:57
---
Subject: Bug 29600
Author: fxcoudert
Date: Sun Aug 12 19:57:01 2007
New Revision: 127380
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127380
Log:
PR fortran/29600
* intrinsic.c (add_fun
Just a meta-bug to keep track of DATA-related bugs.
--
Summary: [Meta-bug] Data related bugs
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: meta-bug
Severity: normal
Priority: P3
Component: fortran
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last recon
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last recon
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last recon
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-08-12 20:13
---
Fixed, thanks Tobias for the first version of the patch.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
---
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|fxcoudert at gcc dot gnu dot|unassigned at gcc dot gnu
|org
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-08-12 20:15
---
(In reply to comment #2)
> Why not create a new i for the inner loop instead of saving it off?
This is indeed what we should do; however, I can't find a way to work it out.
Unassigning myself.
--
fxcoudert at
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-08-12 20:16
---
(In reply to comment #5)
> Note that a test case would be welcome.
There is one in the patch I submitted (and which was approved).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31629
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2007-08-12 20:20
---
Subject: Bug 31629
Author: fxcoudert
Date: Sun Aug 12 20:19:59 2007
New Revision: 127381
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127381
Log:
PR fortran/31629
* lang.opt (-fmodule-p
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2007-08-12 20:20
---
Fixed.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSI
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-08-12 20:39
---
Subject: Bug 32860
Author: fxcoudert
Date: Sun Aug 12 20:39:18 2007
New Revision: 127382
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127382
Log:
PR fortran/32860
* error.c (error_uinte
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-08-12 20:42
---
Fixed.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSI
--- Comment #11 from fxcoudert at gcc dot gnu dot org 2007-08-12 20:45
---
Subject: Bug 30964
Author: fxcoudert
Date: Sun Aug 12 20:45:29 2007
New Revision: 127383
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127383
Log:
PR fortran/30964
PR fortran/33054
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-08-12 20:45
---
Subject: Bug 33054
Author: fxcoudert
Date: Sun Aug 12 20:45:29 2007
New Revision: 127383
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127383
Log:
PR fortran/30964
PR fortran/33054
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-08-12 20:46
---
Fixed.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSI
--- Comment #12 from fxcoudert at gcc dot gnu dot org 2007-08-12 20:46
---
Fixed.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASS
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-08-12 21:21
---
Subject: Bug 29600
Author: fxcoudert
Date: Sun Aug 12 21:21:08 2007
New Revision: 127385
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127385
Log:
PR fortran/29600
* intrinsic.c (add_fun
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-08-12 21:26
---
Updated summary to reflect current state: only MINLOC, MAXLOC and SHAPE needs
to be done. I'm not working on it any more.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed
I could not find a generic url by which to get to the current version of the
GCC documentation -- all the paths I found under http://gcc.gnu.org/onlinedocs/
had a version number (e.g., 4.2.1) embedded.
Is there such a generic url? If not, I'd like to request that one be set up.
Without one, makin
--- Comment #25 from steven dot chapel at sbcglobal dot net 2007-08-12
22:45 ---
> A regression with respect to what version of gfortran? A scan of the
> audit trail did not reveal the working version.
The code above works with gcc 3.4.5.
> If the important application is that import
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-12 22:57 ---
There will never be any version independent documentation, as that is too hard
to maintain.
There is how ever a top of the trunk documentation located at:
http://gcc.gnu.org/onlinedocs/gcc/
http://gcc.gnu.org/online
On 12 Aug 2007 22:45:07 -, steven dot chapel at sbcglobal dot net
<[EMAIL PROTECTED]> wrote:
> The code above works with gcc 3.4.5.
Which means it worked in g77 and not in gfortran (which is new for
4.0.0). Now we have this weird thing about how gfortran is a new
front-end and g77 was removed
--- Comment #26 from pinskia at gmail dot com 2007-08-12 23:07 ---
Subject: Re: [win32] Using 'con' as assigned file generates Fortran runtime
error: File 'con' does not exist
On 12 Aug 2007 22:45:07 -, steven dot chapel at sbcglobal dot net
<[EMAIL PROTECTED]> wrote:
> The code ab
--- Comment #27 from steven dot chapel at sbcglobal dot net 2007-08-12
23:23 ---
(In reply to comment #26)
> Which means it worked in g77 and not in gfortran.
I don't know if it never worked in gfortran. Until a few days ago, the only
MinGW build of gfortran was a trunk version of 4.3.
--- Comment #6 from uweigand at gcc dot gnu dot org 2007-08-12 23:35
---
Changing component to middle-end as the problem is not actually in the C++
front-end.
--
uweigand at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from uweigand at gcc dot gnu dot org 2007-08-12 23:43
---
Sa's patch isn't quite correct as it ignores the result of
the build_qualified_type call. The following patch should
fix that:
diff -urNp toolchain/gcc.orig/gcc/tree.c toolchain/gcc/gcc/tree.c
--- toolchain/gcc.o
--- Comment #5 from gnu at behdad dot org 2007-08-13 05:40 ---
(In reply to comment #2)
> If the compiler could tell whether you were right or not in all cases, you
> wouldn't need the attributes in the first place.
This is not completely true though: the compiler cannot tell by just s
--- Comment #13 from pault at gcc dot gnu dot org 2007-08-13 06:16 ---
Subject: Bug 32962
Author: pault
Date: Mon Aug 13 06:16:03 2007
New Revision: 127391
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127391
Log:
2007-08-13 Paul Thomas <[EMAIL PROTECTED]>
PR fortran
--- Comment #14 from pault at gcc dot gnu dot org 2007-08-13 06:18 ---
Fixed on trunk
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
Statu
--- Comment #25 from victork at il dot ibm dot com 2007-08-13 06:42 ---
Yesterday, I've tried to check if mainline passes boostrap with vectorization
enabled on ppc32 using latest mainline. Since I don't have the access to ppc32
machine, I've tried to imitate in on ppc64 using the follo
53 matches
Mail list logo
