[Bug fortran/35830] New: ICE with PROCEDURE()
The following program gives an ICE w/ 4.3.0 and 4.4.0. ff.f90:9: internal compiler error: Segmentation fault ==29131== Invalid read of size 4 ==29131==at 0x4C0459: gfc_is_nodesc_array (trans-types.c:1031) ==29131==by 0x4C2DE5: gfc_sym_type (trans-types.c:1576) ==29131==by 0x4C2FD7: gfc_get_function_type (trans-types.c:2009) ==29131==by 0x4C3023: gfc_get_function_type (trans-types.c:2005) program test implicit none interface subroutine one(a) integer a(:) end subroutine one end interface contains subroutine foo(f) procedure(one) :: f end subroutine foo end program test -- Summary: ICE with PROCEDURE() Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35830
[Bug ada/35829] Please add support for mips and mipsel in gnat
--- Comment #4 from charlet at gcc dot gnu dot org 2008-04-05 08:15 --- closing -- charlet at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35829
[Bug libfortran/35471] libgfortran fails with nonstandard
--- Comment #9 from george at gcc dot gnu dot org 2008-04-05 08:19 --- Relevant info for libgfortran build prior to blizzard of duplicate symbol warnings. This was from a pristine build: ../gcc/configure MAKE=gmake --enable-languages=fortran LDFLAGS=-L/usr/local/lib ... Checking multilib configuration for libgfortran... mkdir -p -- i686-pc-linux-gnu/libgfortran Configuring in i686-pc-linux-gnu/libgfortran configure: creating cache ./config.cache checking build system type... i686-pc-linux-gnu checking for --enable-version-specific-runtime-libs... no checking for --enable-intermodule... checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether gmake sets $(MAKE)... yes checking whether to enable maintainer-specific portions of Makefiles... no checking for i686-pc-linux-gnu-gcc... /usr2/local/src/gcc-4.3-20080204/gcc-linux/./gcc/xgcc -B/usr2/local/src/gcc-4.3-20080204/gcc-linux/./gcc/ -B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/lib/ -isystem /usr/local/i686-pc-linux-gnu/include -isystem /usr/local/i686-pc-linux-gnu/sys-include checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether /usr2/local/src/gcc-4.3-20080204/gcc-linux/./gcc/xgcc -B/usr2/local/src/gcc-4.3-20080204/gcc-linux/./gcc/ -B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/lib/ -isystem /usr/local/i686-pc-linux-gnu/include -isystem /usr/local/i686-pc-linux-gnu/sys-include accepts -g... yes checking for /usr2/local/src/gcc-4.3-20080204/gcc-linux/./gcc/xgcc -B/usr2/local/src/gcc-4.3-20080204/gcc-linux/./gcc/ -B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/lib/ -isystem /usr/local/i686-pc-linux-gnu/include -isystem /usr/local/i686-pc-linux-gnu/sys-include option to accept ANSI C... none needed checking for style of include used by gmake... GNU checking dependency style of /usr2/local/src/gcc-4.3-20080204/gcc-linux/./gcc/xgcc -B/usr2/local/src/gcc-4.3-20080204/gcc-linux/./gcc/ -B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/lib/ -isystem /usr/local/i686-pc-linux-gnu/include -isystem /usr/local/i686-pc-linux-gnu/sys-include... gcc3 checking whether symbol versioning is supported... yes checking for i686-pc-linux-gnu-as... /usr2/local/src/gcc-4.3-20080204/gcc-linux/./gcc/as checking for i686-pc-linux-gnu-ar... ar checking for i686-pc-linux-gnu-ranlib... ranlib checking whether gmake sets $(MAKE)... (cached) yes checking for a BSD-compatible install... /usr/bin/install -c checking for a sed that does not truncate output... /bin/sed checking for egrep... grep -E checking for fgrep... grep -F checking for ld used by /usr2/local/src/gcc-4.3-20080204/gcc-linux/./gcc/xgcc -B/usr2/local/src/gcc-4.3-20080204/gcc-linux/./gcc/ -B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/lib/ -isystem /usr/local/i686-pc-linux-gnu/include -isystem /usr/local/i686-pc-linux-gnu/sys-include... /usr2/local/src/gcc-4.3-20080204/gcc-linux/./gcc/collect-ld checking if the linker (/usr2/local/src/gcc-4.3-20080204/gcc-linux/./gcc/collect-ld) is GNU ld... yes checking for BSD- or MS-compatible name lister (nm)... /usr2/local/src/gcc-4.3-20080204/gcc-linux/./gcc/nm checking the name lister (/usr2/local/src/gcc-4.3-20080204/gcc-linux/./gcc/nm) interface... BSD nm checking whether ln -s works... yes checking the maximum length of command line arguments... 98304 checking whether the shell understands some XSI constructs... yes checking whether the shell understands "+="... no checking for /usr2/local/src/gcc-4.3-20080204/gcc-linux/./gcc/collect-ld option to reload object files... -r checking how to recognize dependent libraries... pass_all checking for i686-pc-linux-gnu-ar... (cached) ar checking for i686-pc-linux-gnu-strip... strip checking for i686-pc-linux-gnu-ranlib... (cached) ranlib checking command to parse /usr2/local/src/gcc-4.3-20080204/gcc-linux/./gcc/nm output from /usr2/local/src/gcc-4.3-20080204/gcc-linux/./gcc/xgcc -B/usr2/local/src/gcc-4.3-20080204/gcc-linux/./gcc/ -B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/lib/ -isystem /usr/local/i686-pc-linux-gnu/include -isystem /usr/local/i686-pc-linux-gnu/sys-include object... ok checking how to run the C preprocessor... /usr2/local/src/gcc-4.3-20080204/gcc-linux/./gcc/xgcc -B/usr2/local/src/gcc-4.3-20080204/gcc-linux/./gcc/ -B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/lib/ -isystem /usr/local/i686-pc-linux-gnu/include -isystem /usr/local/i686-pc-linux-gnu/sys-include -E checking for ANSI C header files... yes checking for sys/types.h... yes checking
[Bug fortran/35831] New: Type-mismatch check missing for dummy procedure argument
In the following program, the interface of the dummy procedure is explicit.
Fortran 2003's "12.4.1.3 Actual arguments associated with dummy procedure
entities" has about this:
"If the interface of the dummy argument is explicit, the characteristics listed
in 12.2 shall be the same for the associated actual argument and the
corresponding dummy argument, except that a pure actual argument may be
associated with a dummy argument that is not pure and an elemental intrinsic
actual procedure may be associated with a dummy procedure (which is prohibited
from being elemental)."
"If an external procedure name or a dummy procedure name is used as an actual
argument, its interface shall be explicit or it shall be explicitly declared to
have the EXTERNAL attribute."
gfortran does not seem to check whether the array arguments of dummy procedures
match. One reason could be that passing a "a(2)" array ("call foo(a)") to an
array "a(:)" is valid, but this does not apply here.
For some reason, gfortran checks this for
PROCEDURE() :: dummy
but not for
INTERFACE; subroutine dummy() ...
in principle I had expected that both is handled identically. Remove the "!!"
to test the PROCEDURE version.
Found at
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/330df81363912681
Please also check the version given there (incl. the PROCEDURE version) when
fixing this PR.
program test
implicit none
interface
subroutine one(a)
integer a(:)
end subroutine one
subroutine two(a)
integer a(2)
end subroutine two
end interface
! PROCEDURE dummy, gives error:
!! call foo(two)! OK: "Type/rank mismatch in argument 'f'"
! Interface dummy, is accepted:
call bar(two) ! Invalid, not diagnosed
contains
! Valid, but gives an ICE in trans-*.c, see PR 35830
!! subroutine foo(f)
!!procedure(one) :: f
!! end subroutine foo
subroutine bar(f)
interface
subroutine f(a)
integer a(:)
end subroutine f
end interface
end subroutine bar
end program test
--
Summary: Type-mismatch check missing for dummy procedure argument
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35831
[Bug bootstrap/32161] stage1 libgcc is being built unoptimized
--- Comment #7 from bonzini at gnu dot org 2008-04-05 08:53 --- this was fixed -- bonzini at gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32161
[Bug libfortran/35471] libgfortran fails with nonstandard
--- Comment #10 from fxcoudert at gcc dot gnu dot org 2008-04-05 09:26 --- Can you tell us what you binutils version is (the version of ld and as)? According to http://gcc.gnu.org/install/specific.html#ix86-x-linux, "As of GCC 3.3, binutils 2.13.1 or later is required for this platform.". -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35471
[Bug ada/35284] Branch to 0x0 from Ada run-time
--- Comment #38 from laurent at guerby dot net 2008-04-05 09:51 --- It's usually best to develop a patch against trunk and then port it if interest for other branches. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35284
[Bug fortran/35832] New: Better error message for wrong arguments to I/O statements
The diagnostics for the options of OPEN, INQUIRE, WRITE, READ and potentially also CLOSE could be improved. Currently, gfortran only prints "SYNTAX ERROR" for: inquire(99, pad=3) ! wrong, need CHARACTER variable not INTEGER literal inquire(99, pad='aaa') ! wrong, need variable end NAG f95 has a better message: Error: aa.f90, line 1: Expected a CHARACTER item for i/o keyword PAD Error: aa.f90, line 2: Item for i/o keyword PAD is not a variable As had ifort: fortcom: Error: aa.f90, line 1: A scalar default-character variable is required in this context. [3] inquire(99, pad=3) ! wrong, need CHARACTER not INTEGER ^ fortcom: Error: aa.f90, line 2: A scalar default-character variable is required in this context. ['aaa'] inquire(99, pad='aaa') ! wrong, need Variable ^ -- Summary: Better error message for wrong arguments to I/O statements Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35832
[Bug preprocessor/35326] [4.2/4.3/4.4 regression] ICE with stray digraph token
--- Comment #4 from tromey at gcc dot gnu dot org 2008-04-05 13:30 --- With trunk I still can't reproduce this. I ran valgrind on cc1 and cc1plus, and see no reports. Here's the command line I'm using: valgrind /home/tromey/gnu/Trunk/install/libexec/gcc/i686-pc-linux-gnu/4.4.0/cc1plus -quiet -v -D_GNU_SOURCE pr35326.c -quiet -dumpbase pr35326.c -mtune=generic -auxbase pr35326 -version -o /tmp/out.s -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35326
[Bug tree-optimization/35833] New: Wrong code generated with -ftree-vrp
This is not vanilla 4.3.0 but gcc-4_3-branch from
2008-03-13.
Here is a source:
struct S {struct S *field;};
extern struct S True, False, Z;
static inline int f(void) {return 1;}
static inline int g(struct S **obj) {
return f() && *obj == &Z;
}
struct S **h(struct S **x) {
if (x)
return g(x) ? &True.field : &False.field;
else
return &True.field;
}
"gcc -S -O -ftree-vrp bug.c" produces the following code for h:
h:
pushl %ebp
movl$True, %eax
movl%esp, %ebp
leave
ret
This is obviously wrong: there are condidions when it should return
&False.field.
The bug is not triggered without -ftree-vrp, or after minor modifications like
manually inlining f() or g(). A correct code:
h:
pushl %ebp
movl$True, %eax
movl%esp, %ebp
movl8(%ebp), %edx
testl %edx, %edx
je .L3
cmpl$Z, (%edx)
movl$True, %eax
je .L3
movl$False, %eax
.L3:
leave
ret
--
Summary: Wrong code generated with -ftree-vrp
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: qrczak at knm dot org dot pl
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35833
[Bug fortran/35830] ICE with PROCEDURE() containing array formal arguments
--- Comment #1 from burnus at gcc dot gnu dot org 2008-04-05 14:56 ---
(Problem was found when creating PR 35831.)
Janus, do you have time to look at it?
The invalid read happens for in gfc_is_nodesc_array. The problem is that
sym->attr.dimension == 1, sym->dummy == 1 but sym->as == NULL. This of cause
fails for:
if (sym->as->type != AS_ASSUMED_SHAPE)
Hereby, sym->name is the dummy argument "a".
First attempt of solving. This gets past the ICE, but the produced code which
gives wrong results.
--
--- symbol.c(revision 133937)
+++ symbol.c(working copy)
@@ -3626,5 +3643,6 @@ add_proc_interface (gfc_symbol *sym, ifs
args based on the args of a given named interface. */
-void copy_formal_args (gfc_symbol *dest, gfc_symbol *src)
+void
+copy_formal_args (gfc_symbol *dest, gfc_symbol *src)
{
gfc_formal_arglist *head = NULL;
@@ -3649,4 +3667,5 @@ void copy_formal_args (gfc_symbol *dest,
formal_arg->sym->attr = curr_arg->sym->attr;
formal_arg->sym->ts = curr_arg->sym->ts;
+ formal_arg->sym->as = curr_arg->sym->as;
/* If this isn't the first arg, set up the next ptr. For the
--
That the result is wrong can be seen with the following program. ubound of the
array is 32 instead of 3:
--
module m
contains
subroutine one(a)
integer a(:)
print *, lbound(a), ubound(a), size(a)
if ((lbound(a,dim=1) /= 1) .or. (ubound(a,dim=1) /= 3)) &
call abort()
print *, a
if (any(a /= [1,2,3])) call abort()
end subroutine one
end module m
program test
use m
implicit none
call foo(one)
contains
subroutine foo(f)
! The following interface block is needed
! for NAG f95 as it wrongly does not like
! use-associated interfaces for PROCEDURE
! (It is not needed for gfortran)
interface
subroutine one(a)
integer a(:)
end subroutine
end interface
procedure(one) :: f
call f([1,2,3])
end subroutine foo
end program test
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
CC||jaydub66 at gmail dot com
Keywords||wrong-code
Summary|ICE with|ICE with
|PROCEDURE() |PROCEDURE()
||containing array formal
||arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35830
[Bug tree-optimization/35834] New: building libiberty fails in build2_stat for -mcpu=m32c as of r133403
$ ./cc1 -fpreprocessed /tmp/cplus-dem.i -quiet -dumpbase cplus-dem.c -mcpu=m32cm -auxbase-strip cplus-dem.o -g -O2 -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic -o cplus-dem.s ../../../../gcc/libiberty/cplus-dem.c: In function 'cplus_demangle_name_to_style': ../../../../gcc/libiberty/cplus-dem.c:807: internal compiler error: in build2_stat, at tree.c:3107 -- Summary: building libiberty fails in build2_stat for -mcpu=m32c as of r133403 Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dj at redhat dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: m32c-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35834
[Bug tree-optimization/35834] building libiberty fails in build2_stat for -mcpu=m32c as of r133403
--- Comment #1 from dj at redhat dot com 2008-04-05 15:36 --- Created an attachment (id=15433) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15433&action=view) preprocessed cplus-dem.i -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35834
[Bug tree-optimization/35834] building libiberty fails in build2_stat for -mcpu=m32c as of r133403
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-04-05 15:56 ---
This will eventually fix it (and not break sth else):
Index: tree-ssa-address.c
===
--- tree-ssa-address.c (revision 133937)
+++ tree-ssa-address.c (working copy)
@@ -639,9 +639,9 @@ create_mem_ref (block_stmt_iterator *bsi
{
atype = TREE_TYPE (parts.base);
parts.base = force_gimple_operand_bsi (bsi,
- fold_build2 (PLUS_EXPR, atype,
+ fold_build2 (POINTER_PLUS_EXPR, atype,
parts.base,
-fold_convert (atype, parts.index)),
+parts.index),
true, NULL_TREE, true, BSI_SAME_STMT);
}
else
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35834
[Bug tree-optimization/35834] building libiberty fails in build2_stat for -mcpu=m32c as of r133403
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-04-05 16:08 --- I am testing it on x86_64-linux, can you do m32c testing? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-04-05 16:08:44 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35834
[Bug tree-optimization/35833] Wrong code generated with -ftree-vrp
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-04-05 16:17 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||wrong-code Last reconfirmed|-00-00 00:00:00 |2008-04-05 16:17:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35833
[Bug tree-optimization/35833] Wrong code generated with -ftree-vrp
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2008-04-05 16:17:17 |2008-04-05 16:17:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35833
[Bug tree-optimization/35833] Wrong code generated with -ftree-vrp
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-04-05 16:38 --- On the mailine this fixed it: 2008-03-27 Richard Guenther <[EMAIL PROTECTED]> * fold-const.c (target.h): Include. (fold_comparison): Fold comparison of addresses of decls that bind locally or of constants. Consolidate address folding code. * tree-vrp.c (operand_less_p): Deal with non-INTEGER_CST results from fold_binary_to_constant. (compare_values_warnv): Likewise. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35833
[Bug tree-optimization/35833] [4.3 Regression] Wrong code generated with -ftree-vrp
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |major Known to fail||4.3.0 Known to work||4.4.0 4.0.0 Summary|Wrong code generated with - |[4.3 Regression] Wrong code |ftree-vrp |generated with -ftree-vrp Target Milestone|--- |4.3.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35833
[Bug tree-optimization/35833] [4.3 Regression] Wrong code generated with -ftree-vrp
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-04-05 18:01 --- Subject: Bug 35833 Author: rguenth Date: Sat Apr 5 18:01:14 2008 New Revision: 133940 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133940 Log: 2008-04-05 Richard Guenther <[EMAIL PROTECTED]> PR tree-optimization/35833 * tree-vrp.c (operand_less_p): Deal with non-INTEGER_CST results from fold_binary_to_constant. (compare_values_warnv): Likewise. * gcc.dg/torture/pr35833.c: New testcase. Added: branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/torture/pr35833.c Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/testsuite/ChangeLog branches/gcc-4_3-branch/gcc/tree-vrp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35833
[Bug fortran/35830] ICE with PROCEDURE() containing array formal arguments
--- Comment #2 from jaydub66 at gmail dot com 2008-04-05 18:03 --- (In reply to comment #1) > @@ -3649,4 +3667,5 @@ void copy_formal_args (gfc_symbol *dest, >formal_arg->sym->attr = curr_arg->sym->attr; >formal_arg->sym->ts = curr_arg->sym->ts; > + formal_arg->sym->as = curr_arg->sym->as; I guess one should rather use: formal_arg->sym->as = gfc_copy_array_spec (curr_arg->sym->as); With this addition your test case works at least with an explicit-size array: integer a(1:3) With an assumed-size "integer a(:)" it still fails. Will try to find out more tomorrow. > module m > contains > subroutine one(a) > integer a(:) > print *, lbound(a), ubound(a), size(a) > if ((lbound(a,dim=1) /= 1) .or. (ubound(a,dim=1) /= 3)) & > call abort() > print *, a > if (any(a /= [1,2,3])) call abort() > end subroutine one > end module m > > program test > use m > implicit none > call foo(one) > contains > subroutine foo(f) > ! The following interface block is needed > ! for NAG f95 as it wrongly does not like > ! use-associated interfaces for PROCEDURE > ! (It is not needed for gfortran) > interface > subroutine one(a) > integer a(:) > end subroutine > end interface > procedure(one) :: f > call f([1,2,3]) > end subroutine foo > end program test > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35830
[Bug tree-optimization/35833] [4.3 Regression] Wrong code generated with -ftree-vrp
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-04-05 18:04 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work|4.4.0 4.0.0 |4.4.0 4.2.3 4.0.0 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35833
[Bug tree-optimization/35833] [4.3 Regression] Wrong code generated with -ftree-vrp
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-04-05 18:04 --- Subject: Bug 35833 Author: rguenth Date: Sat Apr 5 18:04:07 2008 New Revision: 133941 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133941 Log: 2008-04-05 Richard Guenther <[EMAIL PROTECTED]> PR tree-optimization/35833 * gcc.dg/torture/pr35833.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr35833.c Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35833
[Bug c++/35835] New: Compiler fails to recognize match of local "extern" declarations
Consider following program
=== begin of test.cpp
#include
static inline void SetValue(int i)
{
extern int g_iValue;
g_iValue = i;
}
static inline int GetValue()
{
extern int g_iValue;
return g_iValue;
}
int g_iValue = 0;
int main()
{
int iValueSave = GetValue();
SetValue(1);
printf("%d\n", GetValue());
SetValue(iValueSave);
return 0;
}
=== end of test.cpp
I use this apptoach to only publish get/set global variable accessors in header
while keeping variable itself hidden in cpp.
If compiled with optimizations turned on, compiler fails identify two local
"extern" declarations as a single memory object and uses initial value
retrieved for iValueSafe in call to printf as well (as if SetValue() was
unrelated to g_iValue).
If compiled and run, program outputs 0 instead of 1.
osx-leopard:build oder$ g++ -O3 -o test test.cpp
osx-leopard:build oder$ ./test
0
Output of "g++ -v" is:
Using built-in specs.
Target: powerpc-apple-darwin9
Configured with: /var/tmp/gcc/gcc-5478~1/src/configure --disable-checking
-enable-werror --prefix=/usr --mandir=/share/man
--enable-languages=c,objc,c++,obj-c++
--program-transform-name=/^[cg][^.-]*$/s/$/-4.0/
--with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib
--build=powerpc-apple-darwin9 --host=powerpc-apple-darwin9
--target=powerpc-apple-darwin9
Thread model: posix
gcc version 4.0.1 (Apple Inc. build 5478)
--
Summary: Compiler fails to recognize match of local "extern"
declarations
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: oder at eleks dot lviv dot ua
GCC build triplet: ppc
GCC host triplet: ppc
GCC target triplet: ppc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35835
[Bug c++/35836] New: Wrong instruction generated for comparison with zero on PPC 64 bit
MacOS 10.5
= begin of test.cpp =
#include
#include
typedef int32_t atomicord32;
static inline atomicord32 __attribute__((always_inline))
/*atomicord32 */AtomicIncrement(volatile atomicord32 *paoDestination)
{
return OSAtomicIncrement32Barrier(paoDestination);
}
bool TestAtomic_Increment()
{
bool bResult = false;
do
{
volatile atomicord32 aoStorage = (atomicord32)(-1);
if (AtomicIncrement(&aoStorage) != (atomicord32)0 || aoStorage
!= (atomicord32)0)
{
break;
}
if (AtomicIncrement(&aoStorage) != (atomicord32)1 || aoStorage
!= (atomicord32)1)
{
break;
}
bResult = true;
}
while (false);
return bResult;
}
int main()
{
bool bTestResult = TestAtomic_Increment();
printf("%d\n", (int)(bTestResult ? 1 : 0));
return 0;
}
= end of test.cpp =
with "-m64" TestAtomic_Increment compiles to
0x000126e0 <_Z20TestAtomic_Incrementv+0>: mflrr0
0x000126e4 <_Z20TestAtomic_Incrementv+4>: std r30,-16(r1)
0x000126e8 <_Z20TestAtomic_Incrementv+8>: std r0,16(r1)
0x000126ec <_Z20TestAtomic_Incrementv+12>: stdur1,-160(r1)
0x000126f0 <_Z20TestAtomic_Incrementv+16>: mr r30,r1
0x000126f4 <_Z20TestAtomic_Incrementv+20>: li r0,0
0x000126f8 <_Z20TestAtomic_Incrementv+24>: stb r0,112(r30)
0x000126fc <_Z20TestAtomic_Incrementv+28>: li r0,-1
0x00012700 <_Z20TestAtomic_Incrementv+32>: stw r0,116(r30)
0x00012704 <_Z20TestAtomic_Incrementv+36>: addir0,r30,116
0x00012708 <_Z20TestAtomic_Incrementv+40>: mr r3,r0
0x0001270c <_Z20TestAtomic_Incrementv+44>: bl 0x117c4
0x00012710 <_Z20TestAtomic_Incrementv+48>: mr r0,r3
0x00012714 <_Z20TestAtomic_Incrementv+52>: cmpdi cr7,r0,0
0x00012718 <_Z20TestAtomic_Incrementv+56>: bne-cr7,0x1272c
<_Z20TestAtomic_Incrementv+76>
0x0001271c <_Z20TestAtomic_Incrementv+60>: lwz r0,116(r30)
0x00012720 <_Z20TestAtomic_Incrementv+64>: extsw r0,r0
0x00012724 <_Z20TestAtomic_Incrementv+68>: cmpdi cr7,r0,0
0x00012728 <_Z20TestAtomic_Incrementv+72>: beq-cr7,0x12738
<_Z20TestAtomic_Incrementv+88>
0x0001272c <_Z20TestAtomic_Incrementv+76>: li r0,1
0x00012730 <_Z20TestAtomic_Incrementv+80>: std r0,136(r30)
0x00012734 <_Z20TestAtomic_Incrementv+84>: b 0x12740
<_Z20TestAtomic_Incrementv+96>
0x00012738 <_Z20TestAtomic_Incrementv+88>: li r0,0
0x0001273c <_Z20TestAtomic_Incrementv+92>: std r0,136(r30)
0x00012740 <_Z20TestAtomic_Incrementv+96>: ld r0,136(r30)
0x00012744 <_Z20TestAtomic_Incrementv+100>: cmpdi cr7,r0,0
0x00012748 <_Z20TestAtomic_Incrementv+104>: bne-cr7,0x1279c
<_Z20TestAtomic_Incrementv+188>
0x0001274c <_Z20TestAtomic_Incrementv+108>: addir0,r30,116
0x00012750 <_Z20TestAtomic_Incrementv+112>: mr r3,r0
0x00012754 <_Z20TestAtomic_Incrementv+116>: bl 0x117c4
0x00012758 <_Z20TestAtomic_Incrementv+120>: mr r0,r3
0x0001275c <_Z20TestAtomic_Incrementv+124>: cmpwi cr7,r0,1
0x00012760 <_Z20TestAtomic_Incrementv+128>: bne-cr7,0x12774
<_Z20TestAtomic_Incrementv+148>
0x00012764 <_Z20TestAtomic_Incrementv+132>: lwz r0,116(r30)
0x00012768 <_Z20TestAtomic_Incrementv+136>: extsw r0,r0
0x0001276c <_Z20TestAtomic_Incrementv+140>: cmpwi cr7,r0,1
0x00012770 <_Z20TestAtomic_Incrementv+144>: beq-cr7,0x12780
<_Z20TestAtomic_Incrementv+160>
0x00012774 <_Z20TestAtomic_Incrementv+148>: li r0,1
0x00012778 <_Z20TestAtomic_Incrementv+152>: std r0,128(r30)
0x0001277c <_Z20TestAtomic_Incrementv+156>: b 0x12788
<_Z20TestAtomic_Incrementv+168>
0x00012780 <_Z20TestAtomic_Incrementv+160>: li r0,0
0x00012784 <_Z20TestAtomic_Incrementv+164>: std r0,128(r30)
0x00012788 <_Z20TestAtomic_Incrementv+168>: ld r0,128(r30)
0x0001278c <_Z20TestAtomic_Incrementv+172>: cmpdi cr7,r0,0
0x00012790 <_Z20TestAtomic_Incrementv+176>: bne-cr7,0x1279c
<_Z20TestAtomic_Incrementv+188>
0x00012794 <_Z20TestAtomic_Incrementv+180>: li r0,1
0x00012798 <_Z20TestAtomic_Incrementv+184>: stb r0,112(r30)
0x0001279c <_Z20TestAtomic_Incrementv+188>: lbz r0,112(r30)
0x000127a0 <_Z20TestAtomic_Incrementv+192>: clrldi r0,r0,56
0x00
[Bug c++/35835] Compiler fails to recognize match of local "extern" declarations
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-04-05 19:56 --- First, this bug should be filed with Apple as you are using Apple's modified compiler. Second 4.0.x is no longer being maintained, so please try 4.1.x. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35835
[Bug c++/35835] Compiler fails to recognize match of local "extern" declarations
--- Comment #2 from oder at eleks dot lviv dot ua 2008-04-05 20:02 --- (In reply to comment #1) > First, this bug should be filed with Apple as you are using Apple's modified > compiler. Second 4.0.x is no longer being maintained, so please try 4.1.x. I don't have root access to the build machine and I can only use the version of compiler which is installed there. Also, I don't think the problem is related to target platform. It should be reproduceable on all the platforms. If you can't try it yourself, I can run the test on SunOS or Linux tomorrow. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35835
[Bug middle-end/35835] Compiler fails to recognize match of local "extern" declarations
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-04-05 20:05 ---
(In reply to comment #2)
> I don't have root access to the build machine and I can only use the version
> of
> compiler which is installed there.
You don't need root access to install a newer version of GCC. You can
configure GCC with --prefix=${HOME}/gcc-4.3 if you wanted.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Component|c++ |middle-end
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35835
[Bug middle-end/35835] Compiler fails to recognize match of local "extern" declarations
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-04-05 20:58 ---
(works with the C frontend)
We don't share the decls of g_iValue properly, but doesn't this program
violate the ODR anyway?
void SetValue(int) (iD.2309)
{
:
g_iValueD.2312 ={v} iD.2309_1(D);
return;
}
int GetValue() ()
{
intD.2 D.2316;
:
D.2316_1 = g_iValueD.2315;
return D.2316_1;
}
int main() ()
{
intD.2 D.2333;
intD.2 D.2333;
intD.2 iValueSaveD.2320;
:
iValueSaveD.2320_6 = g_iValueD.2315;
g_iValueD.2312 ={v} 1;
D.2333_7 = g_iValueD.2315;
printf (&"%d\n"[0], D.2333_7);
g_iValueD.2312 ={v} iValueSaveD.2320_6;
return 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35835
[Bug target/35713] [4.4 Regression] invalid type for va_arg with _Decimal128
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-04-05 21:06 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35713
[Bug c++/35836] Wrong instruction generated for comparison with zero on PPC 64 bit
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-04-05 21:13 --- You need to report this with apple or at least try a still maintained gcc version and provide a testcase without Mac specific headers. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35836
[Bug c++/35835] Compiler fails to recognize match of local "extern" declarations
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-04-05 21:16 --- (In reply to comment #4) > (works with the C frontend) > We don't share the decls of g_iValue properly, but doesn't this program > violate the ODR anyway? No it does not as there is only one g_iValue variable. The reasoning behind using extern int g_iValue; is so it does not get into the global scope. The reason why the C front-end works is because we have a non TU scope which we add decls to and then look up global decls that way and get that decl instead of creating a new one. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||wrong-code Last reconfirmed|-00-00 00:00:00 |2008-04-05 21:16:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35835
[Bug libfortran/35471] libgfortran fails with nonstandard
--- Comment #11 from george at gcc dot gnu dot org 2008-04-05 21:49 --- rpm -q binutils binutils-2.9.5.0.22-6 BUT ... the configure output seems to indicate that the build as and ld used here are NOT the system's (unless something devious that I am missing is going on) ... AND the bug report cited (10877) seems to indicate that a runtime error results, not the linker error seen here. vide infra -- checking for i686-pc-linux-gnu-as... /usr2/local/src/gcc-4.3-20080204/gcc-linux/./gcc/as ... checking for ld used by /usr2/local/src/gcc-4.3-20080204/gcc-linux/./gcc/xgcc -B/usr2/local/src/gcc-4.3-20080204/gcc-linux/./gcc/ -B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/lib/ -isystem /usr/local/i686-pc-linux-gnu/include -isystem /usr/local/i686-pc-linux-gnu/sys-include... /usr2/local/src/gcc-4.3-20080204/gcc-linux/./gcc/collect-ld checking if the linker (/usr2/local/src/gcc-4.3-20080204/gcc-linux/./gcc/collect-ld) is GNU ld... yes -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35471
[Bug fortran/35837] New: rej.valid: Host-associated SAVEd variable and PURE function
Found this at http://groups.google.com/group/gg95/browse_thread/thread/667fe259fb346773 I think the reporter is right that this program is valid. NAG f95 and ifort accept is without error. g95 and gfortran reject it with: Error: SAVE attribute at (1) cannot be specified in a PURE procedure module g95bug save integer :: i=20 contains pure function tell_i() result (answer) integer :: answer answer=i end function tell_i end module g95bug -- Summary: rej.valid: Host-associated SAVEd variable and PURE function Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35837
[Bug fortran/25829] [F2003] Asynchronous IO support
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2008-04-05 22:18 --- Subject: Bug 25829 Author: jvdelisle Date: Sat Apr 5 22:18:03 2008 New Revision: 133943 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133943 Log: 2008-04-05 Jerry DeLisle <[EMAIL PROTECTED]> PR fortran/25829 28655 * gfortran.map: Add new symbol, _gfortran_st_wait. * libgfortran.h (st_paramter_common): Add new I/O parameters. * open.c (st_option decimal_opt[], st_option encoding_opt[], st_option round_opt[], st_option sign_opt[], st_option async_opt[]): New parameter option arrays. (edit_modes): Add checks for new parameters. (new_unit): Likewise. (st_open): Likewise. * list_read.c (CASE_SEPERATORS): Add ';' as a valid separator. (eat_separator): Handle deimal comma. (read_logical): Fix whitespace. (parse_real): Handle decimal comma. (read_real): Handle decimal comma. * read.c (read_a): Use decimal status flag to allow comma in place of a decimal point. (read_f): Allow comma as acceptable character in float. According to decimal flag, substitute a period for a comma. (read_x): If decimal status flag is comma, disable the read_comma flag, not allowing comma as a delimiter, an extension otherwise. * io.h: (unit_decimal, unit_encoding, unit_round, unit_sign, unit_async): New enumerators. Add all new I/O parameters. * unix.c (unix_stream, int_stream): Add io_mode asychronous I/O control. (move_pos_offset, fd_alloc_w_at): Fix some whitespace. (fd_sfree): Use new enumerator. (fd_read): Likewise. (fd_write): Likewise. (fd_close): Fix whitespace. (fd_open): Use new enumertors. (tempfile, regular_file, open_external): Fix whitespace. (output_stream, error_stream): Set method. (stream_offset): Fix whitespace. * transfer.c: (st_option decimal_opt[], sign_opt[], blank_opt[]): New option arrays. (formatted_transfer_scalar): Set sf_read_comma flag based on new decimal_status flag. (data_transfer_init): Initialize new parameters. Add checks for decimal, sign, and blank. (st_wait): New stub. * format.c: (format_lex): Add format specifiers DP, DC, and D. (parse_format_list): Parse the new specifiers. * write.c (write_decimal): Use new sign enumerators to set the sign. (write_complex): Handle decimal comma and semi-colon separator. (nml_write_obj): Likewise. * write_float.def: Revise sign enumerators. (calculate_sign): Use new sign enumerators. (output_float): Likewise. Use new decimal_status flag to set the decimal character to a point or a comma. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/gfortran.map trunk/libgfortran/io/format.c trunk/libgfortran/io/io.h trunk/libgfortran/io/list_read.c trunk/libgfortran/io/open.c trunk/libgfortran/io/read.c trunk/libgfortran/io/transfer.c trunk/libgfortran/io/unit.c trunk/libgfortran/io/unix.c trunk/libgfortran/io/write.c trunk/libgfortran/io/write_float.def trunk/libgfortran/libgfortran.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25829
[Bug libfortran/35471] libgfortran fails with nonstandard
--- Comment #12 from fxcoudert at gcc dot gnu dot org 2008-04-05 22:20 --- (In reply to comment #11) > binutils-2.9.5.0.22-6 Too old. And, with the configure line you indicated (i.e. not specifying a special assembler and linker), it is going to be used. So, you need to use more recent binutils. (2.13.1 was released almost 6 years ago.) > BUT ... the configure output seems to indicate that the build as and ld used > here are NOT the system's (unless something devious that I am missing is going > on)... Are you talking about the use of /usr2/local/src/gcc-4.3-20080204/gcc-linux/./gcc/as? I think it's a symbol link to the system "as" (or a short script calling said system "as"). It's a bit misleading, but it's due to the way the build system works to be relocatable. > AND the bug report cited (10877) seems to indicate that a runtime error > results, not the linker error seen here. But PR10877 just mentions the first time a newer binutils was required. After that, once it we require binutils >= 2.13.1, we can use all the new features in that version without keeping track of them (because we're then garanteed to have it present, it's a build requirement). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35471
[Bug fortran/25829] [F2003] Asynchronous IO support
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2008-04-05 22:24 --- Subject: Bug 25829 Author: jvdelisle Date: Sat Apr 5 22:23:27 2008 New Revision: 133944 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133944 Log: 2008-04-05 Jerry DeLisle <[EMAIL PROTECTED]> Francois-Xavier Coudert <[EMAIL PROTECTED]> PR fortran/25829 28655 * dump-parse-tree.c (gfc_show_code_node): Show new I/O parameters. * gfortran.h (gfc_statement): Add ST_WAIT enumerator. (gfc_open): Add pointers for decimal, encoding, round, sign, asynchronous. (gfc_inquire): Add pointers for asynchronous, decimal, encoding, pending, round, sign, size, id. (gfc_wait): New typedef struct. (gfc_dt): Add pointers for id, pos, asynchronous, blank, decimal, delim, pad, round, sign. (gfc_exec_op): Add EXEC_WAIT enumerator. (gfc_code): Add pointer for wait. (gfc_free_wait), (gfc_resolve_wait): New function prototypes. * trans-stmt.h (gfc_trans_wait): New function prototype. * trans.c (gfc_trans_code): Add case for EXEC_WAIT. * io.c (io_tag): Add new tags for DECIMAL, ENCODING, ROUND, SIGN, ASYCHRONOUS, ID. (match_open_element): Add matchers for new tags. (gfc_free_open): Free new pointers. (gfc_resolve_open): Resolve new tags. (gfc_resolve_open): Remove comment around check for allowed values and ASYNCHRONOUS, update it. Likewise for DECIMAL, ENCODING, ROUND, and SIGN. (match_dt_element): Add matching for new tags. (gfc_free_wait): New function. (gfc_resolve_wait): New function. (match_wait_element): New function. (gfc_match_wait): New function. * resolve.c (gfc_resolve_blocks): Add case for EXEC_WAIT. (resolve_code): Add case for EXEC_WAIT. * st.c (gfc_free_statement): Add case for EXEC_WAIT. * trans-io.c (ioparam_type): Add IOPARM_ptype_wait. (gfc_st_parameter): Add "wait" entry. (iocall): Add IOCALL_WAIT enumerator. (gfc_build_io_library_fndecls): Add function declaration for st_wait. (gfc_trans_open): Add mask bits for new I/O tags. (gfc_trans_inquire): Add mask bits for new I/O tags. (gfc_trans_wait): New translation function. (build_dt): Add mask bits for new I/O tags. * match.c (gfc_match_if) Add matcher for "wait". * match.h (gfc_match_wait): Prototype for new function. * ioparm.def: Add new I/O parameter definitions. * parse.c (decode_statement): Add match for "wait" statement. (next_statement): Add case for ST_WAIT. (gfc_ascii_statement): Same. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/dump-parse-tree.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/io.c trunk/gcc/fortran/ioparm.def trunk/gcc/fortran/match.c trunk/gcc/fortran/match.h trunk/gcc/fortran/parse.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/st.c trunk/gcc/fortran/trans-io.c trunk/gcc/fortran/trans-stmt.h trunk/gcc/fortran/trans.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25829
[Bug fortran/25829] [F2003] Asynchronous IO support
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2008-04-05 22:34 --- Subject: Bug 25829 Author: jvdelisle Date: Sat Apr 5 22:33:14 2008 New Revision: 133945 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133945 Log: 2008-04-05 Jerry DeLisle <[EMAIL PROTECTED]> PR fortran/25829 28655 * gfortran.dg/f2003_io_1.f03: New test. * gfortran.dg/f2003_io_2.f03: New test. * gfortran.dg/f2003_io_3.f03: New test. * gfortran.dg/f2003_io_4.f03: New test. * gfortran.dg/f2003_io_5.f03: New test. * gfortran.dg/f2003_io_6.f03: New test. * gfortran.dg/f2003_io_7.f03: New test. Added: trunk/gcc/testsuite/gfortran.dg/f2003_io_1.f03 trunk/gcc/testsuite/gfortran.dg/f2003_io_2.f03 trunk/gcc/testsuite/gfortran.dg/f2003_io_3.f03 trunk/gcc/testsuite/gfortran.dg/f2003_io_4.f03 trunk/gcc/testsuite/gfortran.dg/f2003_io_5.f03 trunk/gcc/testsuite/gfortran.dg/f2003_io_6.f03 trunk/gcc/testsuite/gfortran.dg/f2003_io_7.f03 Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25829
[Bug fortran/35832] Better error message for wrong arguments to I/O statements
--- Comment #1 from tobi at gcc dot gnu dot org 2008-04-05 22:34 --- I think I know how to fix this, and I will do this as an exercise to keep me fluent in the parser code. -- tobi at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tobi at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-04-05 22:34:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35832
[Bug fortran/28655] [F2003] In/output: DECIMAL=/dp/dc; SIGN=/S/SP/SS BLANK=/PAD=; DELIM=; ENCODING=
--- Comment #1 from burnus at gcc dot gnu dot org 2008-04-05 22:47 --- Mostly fixed by the check in for PR 25829. Missing: Some clean up, INQUIRE, round=, and encoding=. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28655
[Bug fortran/35837] rej.valid: Host-associated SAVEd variable and PURE function
--- Comment #1 from dfranke at gcc dot gnu dot org 2008-04-05 22:57 --- F95, section 12.6 "Pure procedures": Constraint: In a pure subprogram any variable which is in common or accessed by host or use association, is a dummy argument to a pure function, is a dummy argument with INTENT (IN) to a pure subroutine, or an object that is storage associated with any such variable, shall not be used in the following contexts: (1)As the variable of an assignment-stmt; (2)As a DO variable or implied DO variable; (3)As an input-item in a read-stmt from an internal file; (4)As an internal-file-unit in a write-stmt; (5)As an IOSTAT= specifier in an input or output statement with an internal file; (6)As the pointer-object of a pointer-assignment-stmt; (7)As the target of a pointer-assignment-stmt; (8)As the expr of an assignment-stmt in which the variable is of a derived type if the derived type has a pointer component at any level of component selection; (9)As an allocate-object or stat-variable in an allocate-stmt or deallocate-stmt, or as a pointer-object in a nullify-stmt; or (10)As an actual argument associated with a dummy argument with INTENT (OUT) or INTENT (INOUT) or with the POINTER attribute. Thus, the case shown above should be valid. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-04-05 22:57:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35837
[Bug c++/35838] New: FAIL: 22_locale/num_get/get/char/16.cc execution test, and 76 others
Executing on host: /test/gnu/gcc/objdir/./gcc/g++ -shared-libgcc -B/test/gnu/gcc /objdir/./gcc -nostdinc++ -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++ -v3/src -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/src/.libs -B/o pt/gnu/gcc/gcc-4.4.0/hppa2.0w-hp-hpux11.11/bin/ -B/opt/gnu/gcc/gcc-4.4.0/hppa2.0 w-hp-hpux11.11/lib/ -isystem /opt/gnu/gcc/gcc-4.4.0/hppa2.0w-hp-hpux11.11/includ e -isystem /opt/gnu/gcc/gcc-4.4.0/hppa2.0w-hp-hpux11.11/sys-include -g -O2 -D_GL IBCXX_ASSERT -fmessage-length=0 -g -O2 -g -O2 -DLOCALEDIR="." -nostdinc++ -I/t est/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/hppa2.0w-hp-hpux11 .11 -I/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include -I/test/gn u/gcc/gcc/libstdc++-v3/libsupc++ -I/test/gnu/gcc/gcc/libstdc++-v3/include/backwa rd -I/test/gnu/gcc/gcc/libstdc++-v3/testsuite/util /test/gnu/gcc/gcc/libstdc++-v 3/testsuite/22_locale/num_get/get/char/16.cc-include bits/stdc++.h ./libtest c++.a -lm -o ./16.exe(timeout = 600) PASS: 22_locale/num_get/get/char/16.cc (test for excess errors) Setting LD_LIBRARY_PATH to :/test/gnu/gcc/objdir/gcc:/test/gnu/gcc/objdir/hppa2. 0w-hp-hpux11.11/./libstdc++-v3/src/.libs::/test/gnu/gcc/objdir/gcc:/test/gnu/gcc /objdir/hppa2.0w-hp-hpux11.11/./libstdc++-v3/src/.libs Assertion failed: err == ios_base::eofbit, file /test/gnu/gcc/gcc/libstdc++-v3/t estsuite/22_locale/num_get/get/char/16.cc, line 57 FAIL: 22_locale/num_get/get/char/16.cc execution test These failures were introduced between 133450 and 133543. -- Summary: FAIL: 22_locale/num_get/get/char/16.cc execution test, and 76 others Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa*-*-* GCC host triplet: hppa*-*-* GCC target triplet: hppa*-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35838
[Bug target/35768] gcc.c-torture/compile/20010226-1.c:22: ICE: in do_output_reload, at reload1.c:7331
--- Comment #7 from danglin at gcc dot gnu dot org 2008-04-05 23:30 --- Testing backend fix. -- danglin at gcc dot gnu dot org changed: What|Removed |Added Component|middle-end |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35768
[Bug preprocessor/35055] missing path to finclude directory when compiling .F90 files
--- Comment #1 from dfranke at gcc dot gnu dot org 2008-04-05 23:50 ---
> #include "omp_lib.h"
Question is, whether this should be supported or not.
OMP specs 2.5, section 3.1 "Runtime Library Definitions" state:
"Interface declarations for the OpenMP Fortran runtime library routines
described in this chapter shall be provided in the form of a Fortran include
file named omp_lib.h or a Fortran 90 module named omp_lib. It is implementation
defined whether the include file or the module file (or both) is provided."
Example A.2.1f then shows:
INCLUDE "omp_lib.h" ! or USE OMP_LIB
gfortran provides both versions. Further, it is possible to define additional
include paths at the command-line via -I, these are also passed to the
preprocessor.
IMO, either use the INCLUDE-statement, USE the module, or pass the path
manually. If one insists on adding this path to the default search path, one
could do it like this:
Index: gcc/fortran/lang-specs.h
===
--- gcc/fortran/lang-specs.h(revision 133799)
+++ gcc/fortran/lang-specs.h(working copy)
@@ -27,7 +27,7 @@
{".FPP", "@f77-cpp-input", 0, 0, 0},
{"@f77-cpp-input",
"cc1 -E -lang-fortran -traditional-cpp -D_LANGUAGE_FORTRAN %(cpp_options) \
- %{E|M|MM:%(cpp_debug_options)}\
+ %{E|M|MM:%(cpp_debug_options)} -I finclude%s\
%{!M:%{!MM:%{!E: -o %|.f |\n\
f951 %|.f %{!ffree-form:-ffixed-form} %(cc1_options) %{J*} %{I*}\
-fpreprocessed %{!nostdinc:-fintrinsic-modules-path finclude%s}
%{!fsyntax-only:%(invoke_as)", 0, 0, 0},
@@ -37,7 +37,7 @@
{".F08", "@f95-cpp-input", 0, 0, 0},
{"@f95-cpp-input",
"cc1 -E -lang-fortran -traditional-cpp -D_LANGUAGE_FORTRAN %(cpp_options) \
- %{E|M|MM:%(cpp_debug_options)}\
+ %{E|M|MM:%(cpp_debug_options)} -I finclude%s\
%{!M:%{!MM:%{!E: -o %|.f95 |\n\
f951 %|.f95 %{!ffixed-form:-ffree-form} %(cc1_options) %{J*} %{I*}\
-fpreprocessed %{!nostdinc:-fintrinsic-modules-path finclude%s}
%{!fsyntax-only:%(invoke_as)", 0, 0, 0},
Take your pick :)
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
CC||dfranke at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35055
[Bug fortran/35707] Search /usr/local/include and /usr/include for .mod files
--- Comment #2 from dfranke at gcc dot gnu dot org 2008-04-06 00:20 --- Related: PR35055 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35707
[Bug target/12329] x86: local function declared with attribute((regparm(3))) gets corrupted parent frame pointer
--- Comment #5 from uros at gcc dot gnu dot org 2008-04-06 06:41 --- Subject: Bug 12329 Author: uros Date: Sun Apr 6 06:40:47 2008 New Revision: 133954 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133954 Log: PR target/12329 * config/i386/i386.c (ix86_function_regparm): Error if regparm(3) attribute is used for nested functions. testsuite/ChangeLog: PR target/12329 * gcc.target/i386/pr12329.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr12329.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12329
[Bug target/12329] x86: local function declared with attribute((regparm(3))) gets corrupted parent frame pointer
--- Comment #6 from ubizjak at gmail dot com 2008-04-06 06:43 --- Fixed for 4.4.0. -- ubizjak at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12329
