[Bug libffi/33052] New: all libffi tests fail with -m64
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-snapshot-20070811/src/libffi/testsuite/libffi.special/unwindtest.cc -shared- libgcc -lstdc++ -O0 -W -Wall -I/scratch/packages/gcc/snap/gcc-snapshot-20070811/build/i486-linux-gnu/64/libffi/include -I/scrat ch/packages/gcc/snap/gcc-snapshot-20070811/src/libffi/testsuite/../include -I/scratch/packages/gcc/snap/gcc-snapshot-20070811/ build/i486-linux-gnu/64/libffi/include/.. -L/scratch/packages/gcc/snap/gcc-snapshot-20070811/build/i486-linux-gnu/64/libffi/.li bs -L/scratch/packages/gcc/snap/gcc-snapshot-20070811/build/i486-linux-gnu/64/libstdc++-v3/src/.libs -lffi -lm -m64 -o ./unw indtest.exe(timeout = 450) /scratch/packages/gcc/snap/gcc-snapshot-20070811/build/i486-linux-gnu/64/libffi/.libs/libffi.so: undefined reference to `ffi_pr ep_raw_closure_loc' /scratch/packages/gcc/snap/gcc-snapshot-20070811/build/i486-linux-gnu/64/libffi/.libs/libffi.so: undefined reference to `ffi_pr ep_cif_machdep' /scratch/packages/gcc/snap/gcc-snapshot-20070811/build/i486-linux-gnu/64/libffi/.libs/libffi.so: undefined reference to `ffi_pr ep_closure_loc' collect2: ld returned 1 exit status compiler exited with status 1 -- Summary: all libffi tests fail with -m64 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libffi AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: debian-gcc at lists dot debian dot org GCC target triplet: i486-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33052
[Bug c/33053] New: adopt accesses through a volatile-casted pointer as a GNU C extension
...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, PR22278, PR29753). I am not requesting that GCC implement any other semantics that people expect from volatile; only that GCC treat int x; ... *(volatile int *)&x ...; as if it read volatile int x; ... x ...; === Please consider, Segher -- Summary: adopt accesses through a volatile-casted pointer as a GNU C extension Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: segher at kernel dot crashing dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33053
[Bug fortran/33054] New: RANDOM_SEED is broken with -fdefault-integer-8
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 o.f90 -fdefault-integer-8 -fdump-tree-original && ./a.out 8 1556651063369256213 1358030301163568053 1969796612819413169 188203328504789242500 00 and the tree dump clearly shows that wrong type arguments are passed to _gfortran_random_seed, which would lead to worst things on big-endian platforms: int8 j[8]; int8 i; _gfortran_random_seed (&i, 0B, 0B); I think it would be not to hard to make two different library functions, one for int4 and the other one for int8. The int8 would then report a SIZE of the seed that is half the size for int4, and that should do the trick. Thomas, any opinion on that? -- Summary: RANDOM_SEED is broken with -fdefault-integer-8 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fxcoudert at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33054
[Bug fortran/33054] RANDOM_SEED is broken with -fdefault-integer-8
-- 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 |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-08-12 10:21:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33054
[Bug fortran/31009] Generate conditional code to assign arrays, depending on their stride
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-08-12 10:23:00 date|| Summary|Use memcpy when assigning |Generate conditional code to |whole arrays|assign arrays, depending on ||their stride http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31009
[Bug fortran/32707] Warn on mismatched character lengths in array
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Severity|enhancement |normal Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||accepts-invalid, diagnostic Last reconfirmed|-00-00 00:00:00 |2007-08-12 10:24:31 date|| Summary|mismatched character lengths|Warn on mismatched character |in array|lengths in array http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32707
[Bug fortran/32331] Better error message for variable bond of DATA implied do
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-08-12 10:25:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32331
[Bug fortran/31214] User-defined operator using entry leads to ICE
--- 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 Status|REOPENED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31214
[Bug fortran/29635] debug info of modules
--- 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
[Bug fortran/33054] RANDOM_SEED is broken with -fdefault-integer-8
--- 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 and kind=8 default integer, like you indicated. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33054
[Bug libfortran/32812] random_seed and date_and_time
--- 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 shuffling to get the most out of the millisecond-field in date_and_time. You'll have to watch for the real(kind=16) case, though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32812
[Bug fortran/32962] b = conjg(transpose(a)) is erroneous if b is an allocatable array
--- 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/show_bug.cgi?id=32962
[Bug fortran/32827] IMPORT fails for TYPE when also used in INTERFACE
--- 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/show_bug.cgi?id=32827
[Bug libfortran/33055] New: ignoring iostat= with -fdefault-integer-8
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 unit number in I/O statement
$ head -30 negative_unit.f.003t.original
MAIN__ ()
{
logical8 l;
int8 i;
static int4 options.0[7] = {68, 127, 0, 0, 0, 1, 0};
_gfortran_set_options (7, (void *) &options.0);
i = 0;
{
int4 iostat.2;
struct __st_parameter_dt dt_parm.1;
dt_parm.1.common.filename = &"negative_unit.f"[1]{lb: 1 sz: 1};
dt_parm.1.common.line = 12;
iostat.2 = 0;
dt_parm.1.common.iostat = &iostat.2;
dt_parm.1.common.flags = 160;
_gfortran_generate_error (&dt_parm.1, 5005, &"Negative unit number in I/O
statement"[1]{lb: 1 sz: 1});
dt_parm.1.common.unit = -1;
_gfortran_st_write (&dt_parm.1);
_gfortran_transfer_character (&dt_parm.1, &"Hello"[1]{lb: 1 sz: 1}, 5);
_gfortran_st_write_done (&dt_parm.1);
i = (int8) iostat.2;
}
if (i <= 0)
{
_gfortran_abort ();
}
i = 0;
{
--
Summary: ignoring iostat= with -fdefault-integer-8
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tkoenig at gcc dot gnu dot org
OtherBugsDependingO 32770
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33055
[Bug target/33042] [4.3 Regression] Bootstrap failure on ppc64
--- 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 Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33042
[Bug fortran/33054] RANDOM_SEED is broken with -fdefault-integer-8
--- 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 and > kind=8 default integer, like you indicated. Yep, that's what I meant to do. The restriction to default integer kind is already in the code, actually. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2007- ||08/msg00782.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33054
[Bug fortran/30964] optional arguments to random_seed
--- 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 URL||http://gcc.gnu.org/ml/gcc- ||patches/2007- ||08/msg00782.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30964
[Bug tree-optimization/18754] unrolling happens too late/SRA does not happen late enough
--- 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)
{
int j, sum = 0;
for (j = 0; j < 3; j ++)
sum += my_array [j];
if (15 != sum)
link_error ();
}
int f1 (int a [])
{
int j, sum = 0;
for (j = 0; j < 3; j ++)
sum += a [j] + my_array [j];
return sum;
}
/* { dg-final { scan-tree-dump-not "link_error" "final_cleanup" } } */
/* { dg-final { scan-tree-dump-not "my_array" "final_cleanup" } } */
/* { dg-final { cleanup-tree-dump "final_cleanup" } } */
--
belyshev at depni dot sinp dot msu dot ru changed:
What|Removed |Added
Last reconfirmed|2005-12-21 03:50:49 |2007-08-12 16:58:50
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18754
[Bug c++/30896] Broken diagnostic for complex template parameter
--- 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 gcc dot gnu |pcarlini at suse dot de |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30896
[Bug libfortran/33055] ignoring iostat= with -fdefault-integer-8
--- 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 AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-08-12 19:47:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33055
[Bug libfortran/32812] random_seed and date_and_time
--- 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 :( We have to draw the line somewhere. > You'll have > to watch for the real(kind=16) case, though. Yes, but since the KISS seeds are gathered together nicely, it shouldn't be too hard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32812
[Bug c/30427] ~ vector float is accepted
--- 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
[Bug fortran/29600] F2003 intrinsics with an optional KIND argument
--- 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_functions): Add KIND arguments to COUNT, IACHAR, ICHAR, INDEX, LBOUND, LEN, LEN_TRIM, SCAN, SIZE, UBOUND and VERIFY. * iresolve.c (gfc_resolve_count): Add kind argument. (gfc_resolve_iachar): New function. (gfc_resolve_ichar): Add kind argument. (gfc_resolve_index_func): Likewise. (gfc_resolve_lbound): Likewise. (gfc_resolve_len): Likewise. (gfc_resolve_len_trim): Likewise. (gfc_resolve_scan): Likewise. (gfc_resolve_size): New function. (gfc_resolve_ubound): Add kind argument. (gfc_resolve_verify): Likewise. * trans-decl.c (gfc_get_extern_function_decl): Allow specific intrinsics to have 4 arguments. * check.c (gfc_check_count): Add kind argument. (gfc_check_ichar_iachar): Likewise. (gfc_check_index): Likewise. (gfc_check_lbound): Likewise. (gfc_check_len_lentrim): New function. (gfc_check_scan): Add kind argument. (gfc_check_size): Likewise. (gfc_check_ubound): Likewise. (gfc_check_verify): Likewise. * intrinsic.texi: Update documentation for COUNT, IACHAR, ICHAR, INDEX, LBOUND, LEN, LEN_TRIM, SCAN, SIZE, UBOUND and VERIFY. * simplify.c (get_kind): Whitespace fix. (int_expr_with_kind): New function. (gfc_simplify_iachar): Add kind argument. (gfc_simplify_iachar): Likewise. (gfc_simplify_ichar): Likewise. (gfc_simplify_index): Likewise. (simplify_bound_dim): Likewise. (simplify_bound): Likewise. (gfc_simplify_lbound): Likewise. (gfc_simplify_len): Likewise. (gfc_simplify_len_trim): Likewise. (gfc_simplify_scan): Likewise. (gfc_simplify_shape): Pass NULL as kind argument to gfc_simplify_size. (gfc_simplify_size): Add kind argument. (gfc_simplify_ubound): Likewise. (gfc_simplify_verify): Likewise. * intrinsic.h: Update prototypes and add new ones. * trans-intrinsic.c (gfc_conv_intrinsic_index): Rename into gfc_conv_intrinsic_index_scan_verify. (gfc_conv_intrinsic_scan, gfc_conv_intrinsic_verify): Remove. (gfc_conv_intrinsic_function): Call gfc_conv_intrinsic_index_scan_verify to translate the INDEX, SCAN and VERIFY intrinsics. * gfortran.dg/intrinsics_kind_argument_1.f90: New test. * gfortran.dg/pure_dummy_length_1.f90: Adapt to new error wording. Added: trunk/gcc/testsuite/gfortran.dg/intrinsics_kind_argument_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/check.c trunk/gcc/fortran/intrinsic.c trunk/gcc/fortran/intrinsic.h trunk/gcc/fortran/intrinsic.texi trunk/gcc/fortran/iresolve.c trunk/gcc/fortran/simplify.c trunk/gcc/fortran/trans-decl.c trunk/gcc/fortran/trans-intrinsic.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/pure_dummy_length_1.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29600
[Bug fortran/33056] New: [Meta-bug] Data related bugs
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 AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tkoenig at gcc dot gnu dot org BugsThisDependsOn: 25096,31244,32315,32331,32928 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33056
[Bug fortran/33056] [Meta-bug] Data - statement related bugs
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-08-12 20:08:07 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33056
[Bug fortran/28154] SPREAD (and friends) on unallocated arrays
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-08-12 20:09:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28154
[Bug fortran/29471] Warn with -std=f95/f2003 when BOZ is used at invalid places
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-08-12 20:10:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29471
[Bug fortran/31189] Support backtracing for non-library errors
--- 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 Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31189
[Bug fortran/32594] substring simplification leads to ICE
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|fxcoudert at gcc dot gnu dot|unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32594
[Bug fortran/29458] Spurious -Wuninitialized warning for implied do-loop counter
--- 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 gcc dot gnu dot org changed: What|Removed |Added AssignedTo|fxcoudert at gcc dot gnu dot|unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29458
[Bug fortran/31629] option to make module entities PRIVATE by default
--- 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
[Bug fortran/31629] option to make module entities PRIVATE by default
--- 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-private): New option. * gfortran.h (gfc_option_t): Add flag_module_private member. * invoke.texi (-fmodule-private): Document the new option. * module.c (gfc_check_access): Allow the -fmodule-private option to modify the default behaviour. * options.c (gfc_init_options): Initialize flag_module_private. (gfc_handle_option): Handle -fmodule-private. * gfortran.dg/module_private_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/module_private_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/invoke.texi trunk/gcc/fortran/lang.opt trunk/gcc/fortran/module.c trunk/gcc/fortran/options.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31629
[Bug fortran/31629] option to make module entities PRIVATE by default
--- 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|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31629
[Bug fortran/32860] Support %ld (for "long") for gfc_warning
--- 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_uinteger): New function. (error_integer): Call error_uinteger. (error_print): Handle %u, %lu, %li and %ld format specifiers. * interface.c (compare_actual_formal): Use the new %lu specifier. * c-format.c (gcc_gfc_length_specs): New array. (gcc_gfc_char_table): Add unsigned specifier, and references to the l length modifier. (format_types_orig): Use the new gcc_gfc_length_specs. * gcc.dg/format/gcc_gfc-1.c: Updated with new formats. Modified: trunk/gcc/ChangeLog trunk/gcc/c-format.c trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/error.c trunk/gcc/fortran/interface.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/format/gcc_gfc-1.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32860
[Bug fortran/32860] Support %ld (for "long") for gfc_warning
--- 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|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32860
[Bug fortran/30964] optional arguments to random_seed
--- 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 * trans-expr.c (gfc_conv_function_call): When no formal argument list is available, we still substitute missing optional arguments. * check.c (gfc_check_random_seed): Correct the check on the number of arguments to RANDOM_SEED. * intrinsic.c (add_subroutines): Add a resolution function to RANDOM_SEED. * iresolve.c (gfc_resolve_random_seed): New function. * intrinsic.h (gfc_resolve_random_seed): New prototype. * intrinsics/random.c (random_seed): Rename into random_seed_i4. (random_seed_i8): New function. * gfortran.map (GFORTRAN_1.0): Remove _gfortran_random_seed, add _gfortran_random_seed_i4 and _gfortran_random_seed_i8. * libgfortran.h (iexport_proto): Replace random_seed by random_seed_i4 and random_seed_i8. * runtime/main.c (init): Call the new random_seed_i4. * gfortran.dg/random_4.f90: New test. * gfortran.dg/random_5.f90: New test. * gfortran.dg/random_6.f90: New test. * gfortran.dg/random_7.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/random_4.f90 trunk/gcc/testsuite/gfortran.dg/random_5.f90 trunk/gcc/testsuite/gfortran.dg/random_6.f90 trunk/gcc/testsuite/gfortran.dg/random_7.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/check.c trunk/gcc/fortran/intrinsic.c trunk/gcc/fortran/intrinsic.h trunk/gcc/fortran/iresolve.c trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog trunk/libgfortran/ChangeLog trunk/libgfortran/gfortran.map trunk/libgfortran/intrinsics/random.c trunk/libgfortran/libgfortran.h trunk/libgfortran/runtime/main.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30964
[Bug fortran/33054] RANDOM_SEED is broken with -fdefault-integer-8
--- 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 * trans-expr.c (gfc_conv_function_call): When no formal argument list is available, we still substitute missing optional arguments. * check.c (gfc_check_random_seed): Correct the check on the number of arguments to RANDOM_SEED. * intrinsic.c (add_subroutines): Add a resolution function to RANDOM_SEED. * iresolve.c (gfc_resolve_random_seed): New function. * intrinsic.h (gfc_resolve_random_seed): New prototype. * intrinsics/random.c (random_seed): Rename into random_seed_i4. (random_seed_i8): New function. * gfortran.map (GFORTRAN_1.0): Remove _gfortran_random_seed, add _gfortran_random_seed_i4 and _gfortran_random_seed_i8. * libgfortran.h (iexport_proto): Replace random_seed by random_seed_i4 and random_seed_i8. * runtime/main.c (init): Call the new random_seed_i4. * gfortran.dg/random_4.f90: New test. * gfortran.dg/random_5.f90: New test. * gfortran.dg/random_6.f90: New test. * gfortran.dg/random_7.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/random_4.f90 trunk/gcc/testsuite/gfortran.dg/random_5.f90 trunk/gcc/testsuite/gfortran.dg/random_6.f90 trunk/gcc/testsuite/gfortran.dg/random_7.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/check.c trunk/gcc/fortran/intrinsic.c trunk/gcc/fortran/intrinsic.h trunk/gcc/fortran/iresolve.c trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog trunk/libgfortran/ChangeLog trunk/libgfortran/gfortran.map trunk/libgfortran/intrinsics/random.c trunk/libgfortran/libgfortran.h trunk/libgfortran/runtime/main.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33054
[Bug fortran/33054] RANDOM_SEED is broken with -fdefault-integer-8
--- 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|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33054
[Bug fortran/30964] optional arguments to random_seed
--- 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|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30964
[Bug fortran/29600] F2003 intrinsics with an optional KIND argument
--- 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_functions): Add optional KIND argument to ACHAR. * iresolve.c (gfc_resolve_achar): Handle the KIND argument. * check.c (gfc_check_achar): Check for the optional KIND argument. * simplify.c (gfc_simplify_achar): Use KIND argument. * intrinsic.h (gfc_check_achar, gfc_simplify_achar, gfc_resolve_achar): Adjust prototypes. * gfortran.dg/intrinsics_kind_argument_1.f90: Add test for ACHAR intrinsic. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/check.c trunk/gcc/fortran/intrinsic.c trunk/gcc/fortran/intrinsic.h trunk/gcc/fortran/iresolve.c trunk/gcc/fortran/simplify.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/intrinsics_kind_argument_1.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29600
[Bug fortran/29600] MINLOC, MAXLOC and SHAPE take an optional KIND argument
--- 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 |Added AssignedTo|fxcoudert at gcc dot gnu dot|unassigned at gcc dot gnu |org |dot org URL|http://gcc.gnu.org/ml/gcc- | |patches/2007- | |08/msg00554.html| Status|ASSIGNED|NEW Keywords|patch | Summary|F2003 intrinsics with an|MINLOC, MAXLOC and SHAPE |optional KIND argument |take an optional KIND ||argument http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29600
[Bug web/33057] New: version-independent url for documentation
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, making cross-manual references from other GNU packages is highly problematic. As a suggestion, perhaps http://www.gnu.org/software/gcc/manual/ (the usual location) could map to the current docs, e.g., http://gcc.gnu.org/onlinedocs/gcc-4.2.1/, so that a url like http://www.gnu.org/software/gcc/manual/cpp/Variadic-Macros.html would map to http://gcc.gnu.org/onlinedocs/gcc-4.2.1/cpp/Variadic-Macros.html. (This particular node was/is the target of a cross-manual link in libc that a user noticed was broken. There are lots more, of course.) Thanks, Karl -- Summary: version-independent url for documentation Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: web AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: karl at freefriends dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33057
[Bug libfortran/32784] [win32] Using 'con' as assigned file generates Fortran runtime error: File 'con' does not exist
--- 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 important, you can always roll > up your sleeves and help fix the problem. I suppose, but I'm just using gcc 3.4.5 for the time being. I actually busy working on cleaning up the Getting Started instructions on the MinGW wiki because most of the people running this application seem to be using gcc 2.95! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32784
[Bug web/33057] version-independent url for documentation
--- 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/onlinedocs/cpp/ etc. I am going to close this bug report as won't fix as we already have documentation which does not have a version number in it for the top of the trunk and it is hard to have a version independent docuementation really. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33057
Re: [Bug libfortran/32784] [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 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. So this could go either as a regression or really a new feature. Also why does this program use con anyways, shouldn't it just use the default units which are connected to stdio/stdout anyways as they might not be connected to the console anyways? Thanks, Andrew Pinski
[Bug libfortran/32784] [win32] Using 'con' as assigned file generates Fortran runtime error: File 'con' does not exist
--- 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 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. So this could go either as a regression or really a new feature. Also why does this program use con anyways, shouldn't it just use the default units which are connected to stdio/stdout anyways as they might not be connected to the console anyways? Thanks, Andrew Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32784
[Bug libfortran/32784] [win32] Using 'con' as assigned file generates Fortran runtime error: File 'con' does not exist
--- 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.0. I haven't tested gfortran 4.2.1 or any other version yet. > Also why does this program use > con anyways, shouldn't it just use the default units which are > connected to stdio/stdout anyways as they might not be connected to > the console anyways? The program opens a large number of file units, some of them actual files, and one of them 'con'. I believe one of them is also 'nul'. These are defined at one place in the program that you can change (similar to the code in the sample program in the first comment), so that at compile time you can change the names of the files. That's just the way the program is written, and not being the author, I can't reasonably change it all around to use the default units instead. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32784
[Bug middle-end/32970] [4.3 Regression] C++ frontend can not handle vector pointer constant parameter
--- 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 Component|c++ |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32970
[Bug middle-end/32970] [4.3 Regression] C++ frontend can not handle vector pointer constant parameter
--- 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.orig/gcc/tree.c 2007-08-12 15:57:05.442520932 +0200 +++ toolchain/gcc/gcc/tree.c2007-08-12 16:07:42.516093968 +0200 @@ -6554,10 +6554,7 @@ reconstruct_complex_type (tree type, tre else return bottom; - TYPE_READONLY (outer) = TYPE_READONLY (type); - TYPE_VOLATILE (outer) = TYPE_VOLATILE (type); - - return outer; + return build_qualified_type (outer, TYPE_QUALS (type)); } /* Returns a vector tree node given a mode (integer, vector, or BLKmode) and -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32970
[Bug tree-optimization/18487] Warnings for pure and const functions that are not actually pure or const
--- 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 seeing the prototype. So, even if the compiler could recognize all pure and const functions when compiling them, that doesn't help when you need to mark the prototypes of those functions as pure/const to help the compiler compiling other programs using them. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18487
[Bug fortran/32962] b = conjg(transpose(a)) is erroneous if b is an allocatable array
--- 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/32962 * trans-array.c (gfc_conv_array_transpose): Set the offset of the destination to zero if the loop is zero based. 2007-08-13 Paul Thomas <[EMAIL PROTECTED]> PR fortran/32962 * gfortran.dg/transpose_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/transpose_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32962
[Bug fortran/32962] b = conjg(transpose(a)) is erroneous if b is an allocatable array
--- 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 Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32962
[Bug regression/32582] Bootstrap with vectorization enabled fails with ICE on PPC
--- 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 following config: ../gcc/configure --build=powerpc-suse-linux --with-cpu=default32 --prefix=/home/victork/mainline/usr.trunk.127373 --enable-languages=c,c++,fortran Unfortuantely, this bootstrap failed as shown below: . /home/victork/mainline/build.trunk.127373/./gcc/xgcc -B/home/victork/mainline/build.trunk.127373/./gcc/ -B/home/victork/mainline/usr.trunk.127373/powerpc-suse-linux/bin/ -B/home/victork/mainline/usr.trunk.127373/powerpc-suse-linux/lib/ -isystem /home/victork/mainline/usr.trunk.127373/powerpc-suse-linux/include -isystem /home/victork/mainline/usr.trunk.127373/powerpc-suse-linux/sys-include -g -O2 -ftree-vectorize -maltivec -msoft-float -fPIC -mstrict-align -O2 -O2 -g -O2 -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -mlong-double-128 -I. -I. -I../../.././gcc -I../../../../gcc/libgcc -I../../../../gcc/libgcc/. -I../../../../gcc/libgcc/../gcc -I../../../../gcc/libgcc/../include -I../../../../gcc/libgcc/../libdecnumber/dpd -I../../../../gcc/libgcc/../libdecnumber -I../../../libdecnumber -DHAVE_CC_TLS -o _ashldi3.o -MT _ashldi3.o -MD -MP -MF _ashldi3.dep -DL_ashldi3 -c ../../../../gcc/libgcc/../gcc/libgcc2.c \ -fvisibility=hidden -DHIDE_EXPORTS ../../../../gcc/libgcc/../gcc/libgcc2.c: In function '__negdi2': ../../../../gcc/libgcc/../gcc/libgcc2.c:80: internal compiler error: in push_reload, at reload.c:1288 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. make[5]: *** [_negdi2.o] Error 1 make[5]: *** Waiting for unfinished jobs Zdenek, David, did you try to test bootstrap with vectoriaztion enabled recently? Can you give me an access to ppc32 to try my hand at it? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32582
