[Bug fortran/30235] missing alternate return argument with explicit interface causes segfault

2006-12-17 Thread brooks at gcc dot gnu dot org


--- Comment #1 from brooks at gcc dot gnu dot org  2006-12-17 08:34 ---
I think this patch fixes this; I'm testing it now:

Index: interface.c
===
--- interface.c (revision 119980)
+++ interface.c (working copy)
@@ -1446,6 +1446,13 @@
 {
   if (new[i] != NULL)
continue;
+  if (f-sym == NULL)
+   {
+ if (where)
+   gfc_error (Missing alternate return spec in subroutine call at
%L,
+  where);
+ return 0;
+   }
   if (!f-sym-attr.optional)
{
  if (where)


-- 

brooks at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |brooks at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2006-12-17 08:34:15
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30235



[Bug bootstrap/30136] bootstrap fail for 4.3-20061209

2006-12-17 Thread dcb314 at hotmail dot com


--- Comment #3 from dcb314 at hotmail dot com  2006-12-17 09:05 ---
(In reply to comment #2)
 I expect to try out 4.3-20061216.

I tried it out and it is still broken.

Is that three snapshots in a row
that fail on x86_64 ?


-- 

dcb314 at hotmail dot com changed:

   What|Removed |Added

 Status|WAITING |UNCONFIRMED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30136



[Bug fortran/30237] New: Alternate return arguments in intrinsic subroutine calls are ignored

2006-12-17 Thread brooks at gcc dot gnu dot org
Alternate-return arguments in argument lists are represented by a null symbol
or expression pointer.  In intrinsic.c, remove_nullargs() simply removes
null-pointer symbols from the argument list handled by an intrinsic function or
subroutine.  Ergo, an alternate-return actual argument in an intrinsic
subroutine call will simply be skipped over and ignored.  The following code
demonstrates this:

---

debian-gfortran:~/test cat ar1.f90
program ar1
real t1
call cpu_time(*20, t1)
20  write(*,*) t1
end

debian-gfortran:~/test ../bin-trunk/bin/gfortran ar1.f90
debian-gfortran:~/test ./a.out
  1.2997000E-02
debian-gfortran:~/test ../bin-trunk/bin/gfortran --version
GNU Fortran 95 (GCC) 4.3.0 20061128 (experimental)
Copyright (C) 2006 Free Software Foundation, Inc.


-- 
   Summary: Alternate return arguments in intrinsic subroutine calls
are ignored
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: accepts-invalid
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: brooks at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30237



[Bug fortran/30238] New: associated(null-pointer, null-pointer) returns .true.

2006-12-17 Thread burnus at gcc dot gnu dot org
For non-array calls, the if is directly created in
trans-intrinsic.c's gfc_conv_associated.

As one can see below, gfortran currently only checks whether two pointers are
the same, it also should check whether they are NULL pointers.

Example:
integer, pointer :: a
nullify(a)
if(associated(a,a)) call abort()
end

and dump:
  int4 * a;
  _gfortran_set_std (70, 127, 0);
  a = 0B;
  if (a == a)
{
  _gfortran_abort ();
}


-- 
   Summary: associated(null-pointer, null-pointer) returns .true.
   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: burnus at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30238



[Bug libstdc++/11953] _REENTRANT defined when compiling non-threaded code.

2006-12-17 Thread doko at gcc dot gnu dot org


--- Comment #47 from doko at gcc dot gnu dot org  2006-12-17 13:47 ---
Subject: Bug 11953

Author: doko
Date: Sun Dec 17 13:46:58 2006
New Revision: 119986

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119986
Log:
2006-12-17  Matthias Klose  [EMAIL PROTECTED]

PR libstdc++/11953
* gcc/config/mips/linux.h (SUBTARGET_CPP_SPEC): Extend.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/mips/linux.h


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11953



[Bug libstdc++/11953] _REENTRANT defined when compiling non-threaded code.

2006-12-17 Thread doko at gcc dot gnu dot org


--- Comment #48 from doko at gcc dot gnu dot org  2006-12-17 13:53 ---
Subject: Bug 11953

Author: doko
Date: Sun Dec 17 13:53:07 2006
New Revision: 119987

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119987
Log:
2006-12-17  Matthias Klose  [EMAIL PROTECTED]

PR libstdc++/11953
* gcc/config/mips/linux.h (SUBTARGET_CPP_SPEC): Extend.

Modified:
branches/gcc-4_2-branch/gcc/ChangeLog
branches/gcc-4_2-branch/gcc/config/mips/linux.h


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11953



[Bug libstdc++/11953] _REENTRANT defined when compiling non-threaded code.

2006-12-17 Thread doko at gcc dot gnu dot org


--- Comment #49 from doko at gcc dot gnu dot org  2006-12-17 13:57 ---
Subject: Bug 11953

Author: doko
Date: Sun Dec 17 13:57:31 2006
New Revision: 119988

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119988
Log:
2006-12-17  Matthias Klose  [EMAIL PROTECTED]

PR libstdc++/11953
* gcc/config/mips/linux.h (SUBTARGET_CPP_SPEC): Extend.

Modified:
branches/gcc-4_1-branch/gcc/ChangeLog
branches/gcc-4_1-branch/gcc/config/mips/linux.h


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11953



[Bug tree-optimization/30233] internal compiler error: in vect_stmt_relevant_p, at tree-vect-analyze.c:1514

2006-12-17 Thread nickols_k at mail dot ru


--- Comment #2 from nickols_k at mail dot ru  2006-12-17 14:18 ---
Created an attachment (id=12820)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12820action=view)
preprocessed source file as requires bugs.html

gcc's output on -v:

gcc4: warning: -pipe ignored because -save-temps specified
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ./configure --prefix=/usr/local --with-gnu-as --enable-shared
--with-gnu-ld --enable-threads=posix --disable-nls
--enable-serial-all-configure
Thread model: posix
gcc version 4.1.1
 /usr/local/libexec/gcc/i686-pc-linux-gnu/4.1.1/cc1 -E -quiet -v -I. -I.
-I../.. -I../.. -I/opt/gtk/include/gtk-2.0 -I/opt/gtk/lib/gtk-2.0/include
-I/opt/gtk/include/atk-1.0 -I/opt/gtk/include/pango-1.0
-I/opt/gtk/include/glib-2.0 -I/opt/gtk/lib/glib-2.0/include
-I/usr/X11R6/include/cairo -I/usr/local/include -MD maze.d -MF .deps/maze.Tpo
-MP -MT maze.o -MQ maze.o -DHAVE_CONFIG_H -DGIMP_DISABLE_DEPRECATED
-DGDK_MULTIHEAD_SAFE -DGTK_MULTIHEAD_SAFE maze.c -m32 -mmmx -msse -m3dnow -msse
-mfpmath=387,sse -mfancy-math-387 -march=athlon-xp -Wall -funroll-all-loops
-floop-optimize2 -ftree-ccp -ftree-ch -ftree-combine-temps -ftree-copy-prop
-ftree-copyrename -ftree-dce -ftree-dominator-opts -ftree-dse -ftree-fre
-ftree-loop-im -ftree-loop-ivcanon -ftree-loop-linear -ftree-loop-optimize
-ftree-lrs -ftree-pre -ftree-salias -ftree-sink -ftree-sra -ftree-store-ccp
-ftree-store-copy-prop -ftree-ter -ftree-vect-loop-version -ftree-vrp
-fbranch-target-load-optimize2 -ftree-vectorize -ffast-math
-fomit-frame-pointer -O3 -fpch-preprocess -o maze.i
ignoring nonexistent directory
/usr/local/lib/gcc/i686-pc-linux-gnu/4.1.1/../../../../i686-pc-linux-gnu/include
ignoring duplicate directory .
ignoring duplicate directory ../..
ignoring duplicate directory /usr/local/include
  as it is a non-system directory that duplicates a system directory
#include ... search starts here:
#include ... search starts here:
 .
 ../..
 /opt/gtk/include/gtk-2.0
 /opt/gtk/lib/gtk-2.0/include
 /opt/gtk/include/atk-1.0
 /opt/gtk/include/pango-1.0
 /opt/gtk/include/glib-2.0
 /opt/gtk/lib/glib-2.0/include
 /usr/X11R6/include/cairo
 /usr/local/include
 /usr/local/lib/gcc/i686-pc-linux-gnu/4.1.1/include
 /usr/include
End of search list.
 /usr/local/libexec/gcc/i686-pc-linux-gnu/4.1.1/cc1 -fpreprocessed maze.i
-quiet -dumpbase maze.c -m32 -mmmx -msse -m3dnow -msse -mfpmath=387,sse
-mfancy-math-387 -march=athlon-xp -auxbase-strip maze.o -O3 -Wall -version
-funroll-all-loops -floop-optimize2 -ftree-ccp -ftree-ch -ftree-combine-temps
-ftree-copy-prop -ftree-copyrename -ftree-dce -ftree-dominator-opts -ftree-dse
-ftree-fre -ftree-loop-im -ftree-loop-ivcanon -ftree-loop-linear
-ftree-loop-optimize -ftree-lrs -ftree-pre -ftree-salias -ftree-sink -ftree-sra
-ftree-store-ccp -ftree-store-copy-prop -ftree-ter -ftree-vect-loop-version
-ftree-vrp -fbranch-target-load-optimize2 -ftree-vectorize -ffast-math
-fomit-frame-pointer -o maze.s
GNU C version 4.1.1 (i686-pc-linux-gnu)
compiled by GNU C version 3.4.6.
GGC heuristics: --param ggc-min-expand=99 --param ggc-min-heapsize=129532
Compiler executable checksum: e9d1412e4a46dfa64960e03d3f09c035
maze.c: In function 'run':
maze.c:179: internal compiler error: in vect_stmt_relevant_p, at
tree-vect-analyze.c:1514
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
make: *** [maze.o] Îøèáêà 1


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30233



[Bug fortran/30236] alternate-return subroutine in generic interface causes ice/segfault

2006-12-17 Thread pault at gcc dot gnu dot org


--- Comment #1 from pault at gcc dot gnu dot org  2006-12-17 14:23 ---
Brooks,

The standard has no problem with this, as you surmise.

The first segfault is in count_types_test, where an attempt is made to use the
non-existent formal symbol. This should be asy to fix - it's a matter of
perspiration rather than inspiration.  I'll give it a go tonight, since I am
into an INTERFACE bee

Thanks

Paul


-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2006-12-17 14:23:03
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30236



[Bug fortran/30235] missing alternate return argument with explicit interface causes segfault

2006-12-17 Thread pault at gcc dot gnu dot org


--- Comment #2 from pault at gcc dot gnu dot org  2006-12-17 14:27 ---
(In reply to comment #1)
 I think this patch fixes this; I'm testing it now:

If it doesn't work, I'll eat my protective cranial wear...

Good one!

Paul


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30235



[Bug rtl-optimization/20211] autoincrement generation is poor

2006-12-17 Thread steven at gcc dot gnu dot org


--- Comment #35 from steven at gcc dot gnu dot org  2006-12-17 14:47 ---
This should be fixed when the dataflow branch is merged.  There is a new pass
there dedicated to generating auto-inc/dec insns.  If the pass in
auto-inc-dec.c on the dataflow branch does not fix this issue, a proper fix for
this bug will have to be implemented there instead of in regmove.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20211



[Bug rtl-optimization/18995] delete_trivially_dead_insns fails to update the liveness information

2006-12-17 Thread steven at gcc dot gnu dot org


--- Comment #4 from steven at gcc dot gnu dot org  2006-12-17 14:48 ---
There will be no more delete_trivially_dead_insns when the dataflow branch is
merged.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18995



[Bug rtl-optimization/29858] regmove has been silently disabled

2006-12-17 Thread steven at gcc dot gnu dot org


--- Comment #4 from steven at gcc dot gnu dot org  2006-12-17 14:57 ---
That patch was already approved:
http://gcc.gnu.org/ml/gcc-patches/2005-05/msg01982.html


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29858



[Bug fortran/30236] alternate-return subroutine in generic interface causes ice/segfault

2006-12-17 Thread pault at gcc dot gnu dot org


--- Comment #2 from pault at gcc dot gnu dot org  2006-12-17 15:46 ---
Created an attachment (id=12821)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12821action=view)
Patch for PR

This produces code that works correctly and is halfway through a regtest.

I'll do the submit tonight.

Paul


-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |pault at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30236



[Bug fortran/30239] New: duplicate data type assignment not detected

2006-12-17 Thread dfranke at gcc dot gnu dot org
The Intel Fortan Compiler issues an error on the code below

INTEGER FUNCTION foo()
  INTEGER :: foo
  foo = 0
END FUNCTION

gfortran takes it without further notice. Letting INTEGER :: foo be REAL ::
foo gives Error: Symbol 'foo' at (1) already has basic type of INTEGER on
gfortran as well.

$ gfortran-svn -v
gcc version 4.3.0 20061128 (experimental)


-- 
   Summary: duplicate data type assignment not detected
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dfranke at gcc dot gnu dot org
  GCC host triplet: i686-pc-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30239



[Bug other/30240] New: -fno-inline-functions does not work, and doc bugs

2006-12-17 Thread h dot b dot furuseth at usit dot uio dot no
The -f(no-)inline-functions option does not work.  Its documented
effect is controlled by -f(no-)inline, both in gcc and g++.
(Don't ask me how that jibes with Bug #27881:-)

The doc says -finline-functions is only invoked by -O3.  I suggest
you preserve -O's current functionality: Move -finline-functions
from -O3 to -O and document that (under -fno-inline-functions).


The two first compile commands below work with gcc-3.4.4, but the
third does not:
  -fno-inline -finline-functions
does not inline foo().

That's possibly a doc bug:  (gcc)Optimize Options says
 `-fno-inline'
 Don't pay attention to the `inline' keyword.  Normally this option
 is used to keep the compiler from expanding any functions inline.
 (...)
One of these sentences is wrong.  Does -fno-inline only mean ignore
the inline keyword, or does it mean inline nothing, regardless of
other inlining options or keywords/attributes, or something else?


Doc bugs in Info node (gcc)Inline:

  (If you are writing a header file to be included in ISO C programs,
  write `__inline__' instead of `inline'...)
Should now be ISO C90 programs.

  Some calls cannot be integrated for various reasons (in particular,
  calls that precede the function's definition cannot be integrated,...
Except with -funit-at-a-time.  Which is also turned on by -O even though
it's documented as an -O2 option.


$ cat bug.c
static int foo(void){ return 9; }
int bar(void)   { return foo(); }

$ gcc -O -fno-inline-functions -S bug.c -o-
.file   bug.c
.text
.globl bar
.type   bar, @function
bar:
pushl   %ebp
movl%esp, %ebp
movl$9, %eax
popl%ebp
ret
.size   bar, .-bar
.ident  GCC: (GNU) 4.1.1
.section.note.GNU-stack,,@progbits

$ gcc -O -fno-inline -S bug.c -o-
.file   bug.c
.text
.type   foo, @function
foo:
pushl   %ebp
movl%esp, %ebp
movl$9, %eax
popl%ebp
ret
.size   foo, .-foo
.globl bar
.type   bar, @function
bar:
pushl   %ebp
movl%esp, %ebp
callfoo
popl%ebp
ret
.size   bar, .-bar
.ident  GCC: (GNU) 4.1.1
.section.note.GNU-stack,,@progbits

$ gcc -O -fno-inline -finline-functions -S bug.c -o-
same output as from -O -fno-inline


-- 
   Summary: -fno-inline-functions does not work, and doc bugs
   Product: gcc
   Version: 4.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: h dot b dot furuseth at usit dot uio dot no
 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=30240



[Bug other/30241] New: __libc_stack_end is not portable between PPC distributions

2006-12-17 Thread hanwen at xs4all dot nl
Hello,

i'm not sure this is the right place to report this. Please direct me elsewhere
if it's not.

I'm trying to build generic binaries for lilypond (lilypond.org), using a x86
pc targetting linux/ppc. I'm building a cross-compiler against the
Debian/stable libs/headers. 

My problem is that libgcc_s.so links in the __libc_stack_end symbol
(ppc_linux_aux_vector ()  in config/rs6000/linux-unwind.h )
This symbol has differing versions across platforms (GLIB_2.1 on Fedora Core,
Yellow Dog Linux and GLIBC_PRIVATE on Debian/stable), so it's not possible to
build PPC binaries that run on all linux/ppc distributions.  

I could try patching GCC sources, to simulate a stupid PPC CPU, but it would be
nice if this worked out of the box, ie. if ppc_fallback_frame_state() could
determine CPU characteristics without looking at __libc_stack_end.


-- 
   Summary: __libc_stack_end is not portable between PPC
distributions
   Product: gcc
   Version: 4.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hanwen at xs4all dot nl
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: powerpc-linux
GCC target triplet: powerpc-linux


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30241



[Bug fortran/19292] [meta-bug] g77 features lacking in gfortran

2006-12-17 Thread pertusus at free dot fr


--- Comment #29 from pertusus at free dot fr  2006-12-17 18:21 ---
getarg intrinsic which was in g77 also seems to be unimplemented?


-- 

pertusus at free dot fr changed:

   What|Removed |Added

 CC||pertusus at free dot fr


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19292



[Bug fortran/30207] [4.2/4.3 Regression] ICE in gfc_dep_resolver with where (a 0) a(:) = 1

2006-12-17 Thread sayle at gcc dot gnu dot org


--- Comment #6 from sayle at gcc dot gnu dot org  2006-12-17 18:28 ---
Subject: Bug 30207

Author: sayle
Date: Sun Dec 17 18:28:07 2006
New Revision: 119990

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119990
Log:
2006-12-17  Roger Sayle  [EMAIL PROTECTED]
Steven G. Kargl  [EMAIL PROTECTED]

PR fortran/30207
* dependency.c (gfc_full_array_ref_p): New function to test whether
the given array ref specifies the entire array.
(gfc_dep_resolver): Use gfc_full_array_ref_p to analyze AR_FULL
array refs against AR_SECTION array refs, and vice versa.
* dependency.h (gfc_full_array_ref_p): Prototype here.
* trans-array.c (gfc_conv_expr_descriptor): Use gfc_full_array_ref_p.

* gfortran.fortran-torture/execute/where21.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.fortran-torture/execute/where21.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/dependency.c
trunk/gcc/fortran/dependency.h
trunk/gcc/fortran/trans-array.c
trunk/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30207



[Bug other/30240] -fno-inline-functions does not work, and doc bugs

2006-12-17 Thread pinskia at gcc dot gnu dot org


--- Comment #1 from pinskia at gcc dot gnu dot org  2006-12-17 19:02 ---
You want -fno-inline-functions-called-once which was added in 4.2.0 IIRC (it is
in 4.3.0 for sure).
http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#Optimize-Options


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30240



[Bug other/30241] __libc_stack_end is not portable between PPC distributions

2006-12-17 Thread pinskia at gcc dot gnu dot org


--- Comment #1 from pinskia at gcc dot gnu dot org  2006-12-17 19:04 ---
This symbol has differing versions across platforms (GLIB_2.1 on Fedora Core,
Yellow Dog Linux and GLIBC_PRIVATE on Debian/stable)

And this is not a GCC bug really because glibc changed so really either this is
a glibc bug or really a distro bug.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30241



[Bug fortran/30238] associated(null-pointer, null-pointer) returns .true.

2006-12-17 Thread patchapp at dberlin dot org


--- Comment #1 from patchapp at dberlin dot org  2006-12-17 19:10 ---
Subject: Bug number PR30238

A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-12/msg01228.html


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30238



[Bug fortran/30238] associated(null-pointer, null-pointer) returns .true.

2006-12-17 Thread burnus at gcc dot gnu dot org


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |burnus at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2006-12-17 19:11:53
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30238



[Bug fortran/30239] duplicate data type assignment not detected

2006-12-17 Thread burnus at gcc dot gnu dot org


--- Comment #1 from burnus at gcc dot gnu dot org  2006-12-17 20:15 ---
This is because in symbol.c's gfc_add_type there is

  const char *msg = Symbol '%s' at %L already has basic type of %s;
  if (!(sym-ts.type == ts-typesym-ts.type == ts-type
  (sym-attr.flavor == FL_PROCEDURE || sym-attr.result))
   || gfc_notification_std (GFC_STD_GNU) == ERROR
   || pedantic)
{
  gfc_error (msg, sym-name, where, gfc_basic_typename (sym-ts.type));
  return FAILURE;
}

The !(sym-ts.type == ts-type) prevents the error message. Removing this check
should all what is needed for this bug.
But this might break other cases were it is allowed. (I didn't check/though
about those, however).


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2006-12-17 20:15:55
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30239



[Bug fortran/30237] Alternate return arguments in intrinsic subroutine calls are ignored

2006-12-17 Thread tobi at gcc dot gnu dot org


--- Comment #1 from tobi at gcc dot gnu dot org  2006-12-17 20:22 ---
From the comment preceding remove_nullargs() I wonder why it's called in the
beginning of sort_actual().


-- 

tobi at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||tobi at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30237



[Bug fortran/30228] ICE: build_int_cst_wide, at tree.c:912 / invalid deallocate

2006-12-17 Thread tobi at gcc dot gnu dot org


--- Comment #1 from tobi at gcc dot gnu dot org  2006-12-17 20:34 ---
I couldn't reproduce this, and Tobias Burnus thinks it coudl be an issue in his
tree.
tobias-schluters-computer:~/src/pr/30228 tobi$ cat t.f90
type pt
   integer, pointer :: p(:)
end type pt
type(pt), pointer :: t(:)
integer i
i = 1
allocate (t(1))
allocate (t(1)%p(0))
deallocate(t(1)%p(0))
end
tobias-schluters-computer:~/src/pr/30228 tobi$ ~/src/trunk2/build/gcc/f951
t.f90
t.f90:9.12:

deallocate(t(1)%p(0))
   1
Error: Expression in DEALLOCATE statement at (1) must be ALLOCATABLE or a
POINTER

Execution times (seconds)
 parser:   0.01 (100%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall  
  111 kB (14%) ggc
 TOTAL :   0.01 0.01 0.01  
 822 kB
Extra diagnostic checks enabled; compiler may run slowly.
Configure with --disable-checking to disable checks.
tobias-schluters-computer:~/src/pr/30228 tobi$ 


-- 

tobi at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||tobi at gcc dot gnu dot org
 Status|UNCONFIRMED |RESOLVED
 Resolution||WORKSFORME


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30228



[Bug fortran/30235] missing alternate return argument with explicit interface causes segfault

2006-12-17 Thread tobi at gcc dot gnu dot org


--- Comment #3 from tobi at gcc dot gnu dot org  2006-12-17 20:37 ---
Maybe we should add a new expression type EXPR_LABEL_REF or whatever better
name you might come up with for the label references? This seems much less
error-prone than checking for magic NULLs all over the compiler.


-- 

tobi at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||tobi at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30235



[Bug fortran/30146] Redefining do-variable in excecution cycle

2006-12-17 Thread tobi at gcc dot gnu dot org


--- Comment #1 from tobi at gcc dot gnu dot org  2006-12-17 20:56 ---
As long as the callee doesn't change the value it's probably valid, so this
would need some kind of interprocedural analysis to give a correct error. A
warning may be in place, though. This shouldn't be to hard, we check that LHS'
are not DO variables, so similar code is already there.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30146



[Bug fortran/30207] [4.2/4.3 Regression] ICE in gfc_dep_resolver with where (a 0) a(:) = 1

2006-12-17 Thread deji_aking at yahoo dot ca


--- Comment #7 from deji_aking at yahoo dot ca  2006-12-17 21:10 ---
Thanks Rogers and Steve for the resolution of this bug. I hope you'll not
forget to commit it to the gcc-4.2 branch.

PS: I've applied the patch cleanly to the 4.2 branch but have not got the
opportunity to build and test it.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30207



[Bug fortran/30146] Redefining do-variable in excecution cycle

2006-12-17 Thread burnus at gcc dot gnu dot org


--- Comment #2 from burnus at gcc dot gnu dot org  2006-12-17 21:20 ---
 As long as the callee doesn't change the value it's probably valid, so this
 would need some kind of interprocedural analysis to give a correct error.

I think it is formally seen invalid as you have INTENT([IN]OUT) set.

Actually, I just retested with NAG f95 and it gives:
Error: test.f90, line 5: Active DO variable I passed to INTENT(OUT) argument I
number 1 of MYSUB

We could nontheless consider of giving a warning only, if you think the case of
INTENT(OUT) with no assignment is much more common than a wrongly used
do-variable.

By the way, if no value is assigned to an INTENT(OUT) variable, gfortran should
follow the other compilers and issue a warning:
INTENT(OUT) dummy argument I never set
INTENT(OUT) variable 'i' at (1) is never set
A dummy argument with an explicit INTENT(OUT) declaration is not given an
explicit value.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30146



[Bug tree-optimization/30038] Call to sin(x), cos(x) should be transformed to sincos(x)

2006-12-17 Thread burnus at gcc dot gnu dot org


--- Comment #17 from burnus at gcc dot gnu dot org  2006-12-17 23:19 ---
Using the patch of PR 30223 (add cbrt, cexpi and sincos to Fortran), I don't
get any speed up (21.95s for fatigue).

Using additionally http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00958.html
(folding of cexp ()) I get 20% speedup: 21.95s -- 17.851s

This is much less than the 28.3s - 18.3s change at
http://www.suse.de/~gcctest/c++bench/polyhedron/polyhedron-summary.txt-2-0.html
which presumably means I miss at least one patch.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30038



[Bug libgomp/29949] implement argument checking for user accessable runtime routines

2006-12-17 Thread dfranke at gcc dot gnu dot org


--- Comment #5 from dfranke at gcc dot gnu dot org  2006-12-17 23:27 ---
Subject: Bug 29949

Author: dfranke
Date: Sun Dec 17 23:27:47 2006
New Revision: 119995

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119995
Log:
2006-12-18  Daniel Franke  [EMAIL PROTECTED]

Backport from mainline:
2006-12-04  Daniel Franke  [EMAIL PROTECTED]

PR libgomp/29949
* env.c (omp_set_num_threads): Set illegal thread count to 1.

Backport from mainline:
2006-11-09  Uros Bizjak  [EMAIL PROTECTED]

* env.c (parse_schedule): Reject out of range values.
(parse_unsigned_long): Reject out of range, negative
or zero values.


Modified:
branches/gcc-4_2-branch/libgomp/ChangeLog
branches/gcc-4_2-branch/libgomp/env.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29949



[Bug tree-optimization/30233] internal compiler error: in vect_stmt_relevant_p, at tree-vect-analyze.c:1514 with -O3 -msse -ftree-loop-linear -ftree-vectorize

2006-12-17 Thread pinskia at gcc dot gnu dot org


--- Comment #3 from pinskia at gcc dot gnu dot org  2006-12-18 00:05 ---
Fixed for 4.1.2, this is a bug with -ftree-loop-linear which was known to be
broken for 4.1.1.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||FIXED
Summary|internal compiler error: in |internal compiler error: in
   |vect_stmt_relevant_p, at|vect_stmt_relevant_p, at
   |tree-vect-analyze.c:1514|tree-vect-analyze.c:1514
   ||with -O3 -msse -ftree-loop-
   ||linear -ftree-vectorize
   Target Milestone|--- |4.1.2


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30233



[Bug middle-end/7651] Define -Wextra strictly in terms of other warning flags

2006-12-17 Thread patchapp at dberlin dot org


--- Comment #8 from patchapp at dberlin dot org  2006-12-18 00:20 ---
Subject: Bug number PR7651

A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-12/msg01244.html


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7651



[Bug rtl-optimization/30213] Wrong code with optimized memset() (possible bug in RTL bbro optimizer)

2006-12-17 Thread hubicka at gcc dot gnu dot org


--- Comment #2 from hubicka at gcc dot gnu dot org  2006-12-18 02:54 ---
Mine, working on fix.

Honza


-- 

hubicka at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |hubicka at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2006-12-18 02:54:56
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30213



[Bug c/30242] New: internal error in gcc break compilation

2006-12-17 Thread sherpya at netfarm dot it
gcc 4.3 current svn branch revision 120001

it's not possible to have -save-temps since the compiler
bombs while assembling cygwin.asm using gcc (uh?)

/d/Download/Devel/MinGW/gcc-source/build/./gcc/xgcc
-B/d/Download/Devel/MinGW/gcc-source/build/./gcc/
-L/d/Download/Devel/MinGW/gcc-source/build/mingw32/w
insup/mingw
-L/d/Download/Devel/MinGW/gcc-source/build/mingw32/winsup/w32api/lib -isystem
/d/Download/Devel/MinGW/gcc-source/gcc/winsup/mingw/include -isyst
em /d/Download/Devel/MinGW/gcc-source/gcc/winsup/w32api/include
-B/mingw/mingw32/bin/ -B/mingw/mingw32/lib/ -isystem /mingw/mingw32/include
-isystem /mingw/
mingw32/sys-include -O2 -I../../gcc/gcc/../winsup/w32api/include -O2 -g -O2 
-DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -
Wold-style-definition  -isystem ./include   -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2
-D__GCC_FLOAT_NOT_NEEDED  -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../
gcc/gcc/../include -I../../gcc/gcc/../libcpp/include 
-I../../gcc/gcc/../libdecnumber -I../libdecnumber -DL_chkstk
-xassembler-with-cpp -c ../../gcc/gcc/con
fig/i386/cygwin.asm -o libgcc/./_chkstk.o -save-temps


-- 
   Summary: internal error in gcc break compilation
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sherpya at netfarm dot it
 GCC build triplet: i386-pc-mingw32
  GCC host triplet: i386-pc-mingw32
GCC target triplet: i386-pc-mingw32


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30242



[Bug preprocessor/30242] internal error in gcc break compilation

2006-12-17 Thread sherpya at netfarm dot it


--- Comment #1 from sherpya at netfarm dot it  2006-12-18 03:31 ---
I forgot to attach the error:
cc1.exe: internal compiler error: in add_standard_paths, at c-incpath.c:173

so it's not in gcc but the preprocessor

I've bootstrapped from 4.1.1


-- 

sherpya at netfarm dot it changed:

   What|Removed |Added

  Component|c   |preprocessor


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30242



[Bug target/30243] New: avr-gcc 4.1.1: signbit() causes an internal compiler error

2006-12-17 Thread dmixm at marine dot febras dot ru
avr-gcc (GCC) 4.1.1
Compilation of next program (-W -Wall -Os -S):

extern int signbit (double);
int foo (double x)
{
return signbit (x);
}

causes an compilation abort with message:
internal compiler error: in gen_lowpart_general, at rtlhooks.c:51

Older versions are work:
3.3.5, 3.4.4  - call of external signbit() function
4.0.2- inline-code


-- 
   Summary: avr-gcc 4.1.1: signbit() causes an internal compiler
error
   Product: gcc
   Version: 4.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dmixm at marine dot febras dot ru


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30243



[Bug fortran/30239] duplicate data type assignment not detected

2006-12-17 Thread pault at gcc dot gnu dot org


--- Comment #2 from pault at gcc dot gnu dot org  2006-12-18 06:01 ---
This was a fix for a PR about a year ago - the std=gnu is meant, obviously, to
enforce all versions of the standard on this.  However, a number of other
compilers did/do permit this wrinkle on the standard and it even appears in one
of Meissner's examples.

 should all what is needed for this bug.
 But this might break other cases were it is allowed. (I didn't check/though
 about those, however).
 

Paul


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30239



[Bug bootstrap/29102] mudflap's configure tries to link a binary and fails because I don

2006-12-17 Thread pinskia at gcc dot gnu dot org


--- Comment #5 from pinskia at gcc dot gnu dot org  2006-12-18 06:28 ---
Use --disable-libmudflap while building the stage1 gcc for the cross
compiler.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29102



[Bug bootstrap/21544] xgcc fails (1rst stage) if binutils is not installed into --prefix directory

2006-12-17 Thread pinskia at gcc dot gnu dot org


--- Comment #2 from pinskia at gcc dot gnu dot org  2006-12-18 06:29 ---
No feedback in 3 months so closing.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21544



[Bug fortran/30236] alternate-return subroutine in generic interface causes ice/segfault

2006-12-17 Thread patchapp at dberlin dot org


--- Comment #3 from patchapp at dberlin dot org  2006-12-18 07:10 ---
Subject: Bug number PR30236

A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-12/msg01254.html


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30236



[Bug fortran/30239] duplicate data type assignment not detected

2006-12-17 Thread burnus at gcc dot gnu dot org


--- Comment #3 from burnus at gcc dot gnu dot org  2006-12-18 07:49 ---
 This was a fix for a PR about a year ago - the std=gnu is meant, obviously, to
 enforce all versions of the standard on this.  However, a number of other
 compilers did/do permit this wrinkle on the standard and it even appears in 
 one
 of Meissner's examples.

Thus: Should we warn? Give an error (as ifort, NAG f95 and g95 do)? Or keep the
status quo where an error is given only for -pedantic and -std=f95/f2003 ?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30239