[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[jv244 at cam dot ac dot uk]

--- Comment #148 from jv244 at cam dot ac dot uk  2008-02-18 08:10 ---
(In reply to comment #147)
> (In reply to comment #146)
> > (In reply to comment #145)
> > > current gfortran trunk seems to fail on CVS sources of CP2K with:
> > PR34946
> 
> Joost - can this be closed again?

Done, but I hope that the open dependency PR32580 can be tackled with high
priority in 4.4 (also because it is a prerequisite to call the iso_c_binding
'complete').


-- 

jv244 at cam dot ac dot uk changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED


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

[Bug c++/35247] New: Usage of openmp pragmas causes internal compiler error

[ttsiod at softlab dot ntua dot gr]

I tried compiling my open source application with GCC. My application uses
OpenMP to make use of available CPU cores and run faster. I got an internal
compiler error from GCC, even though the same code compiles and runs fine
(using both cores) under Intel's ICC. It also compiles and runs fine with GCC
when I don't use the -fopenmp option (but then it only uses one core).

My GCC -v output: 

Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ./configure --enable-languages=c,c++ --prefix=/opt/gcc-4.2.3
--exec_prefix=/opt/gcc-4.2.3
Thread model: posix
Version gcc 4.2.3

My system: (uname -a)
Linux home 2.6.23 #2 SMP PREEMPT Sun Nov 11 11:44:34 EET 2007 i686 Intel(R)
Core(TM)2 Duo CPU E4500  @ 2.20GHz GenuineIntel GNU/Linux

The command line that triggers the bug is simple:

g++ -c -fopenmp Scene.ii

It reports:
src/Scene.cc: In member function 'void Scene::renderPhong(const Camera&,
Screen&)':
src/Scene.cc:165: åóùôåñéêü óöÜëìá ìåôáãëùôôéóôÞ: in create_tmp_var, at
gimplify.c:487
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.

Scene.ii (the preprocessed output), is available here:
http://users.softlab.ntua.gr/~ttsiod/Scene.ii.bz2

If you remove the -fopenmp, the code compiles fine.

In case you want to see what the code is used for, the open source project and
its full code is available here:

http://users.softlab.ntua.gr/~ttsiod/renderer.html


-- 
   Summary: Usage of openmp pragmas causes internal compiler error
   Product: gcc
   Version: 4.2.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ttsiod at softlab dot ntua dot gr
 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=35247

[Bug fortran/35203] OPTIONAL, VALUE actual argument cannot be an INTEGER 0

[toon at moene dot indiv dot nluug dot nl]

--- Comment #9 from toon at moene dot indiv dot nluug dot nl  2008-02-18 
08:32 ---
> What will happen now? Will anyone send an interpretation request, which will
> bring it up on the table again?

No, as it isn't *impossible* to implement it (with a hidden argument), an
interp won't stand a chance.

> I intent to submit the following patch:

Yep, it's *much* better to say outright that we do not support it.  We will
hear from people who actually need it :-)

Thanks.


-- 


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

[Bug driver/35248] New: --enable-version-specific-runtime-libs broken

[Ralf dot Wildenhues at gmx dot de]

$ echo 'int main() { return 0; }' > a.c
$ gcc -o a a.c -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc/configure -C --prefix=/home/ralf/gcc-test
--enable-version-specific-runtime-libs --enable-languages=c,c++
--disable-bootstrap --disable-multilib --with-gmp=/home/ralf/local
--with-mpfr=/home/ralf/local
Thread model: posix
gcc version 4.3.0 20080218 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-o' 'a' '-v' '-mtune=generic'
 /home/ralf/gcc-test/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.3.0/cc1
-quiet -v -iprefix
/home/ralf/gcc-test/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.3.0/ a.c -quiet
-dumpbase a.c -mtune=generic -auxbase a -version -o /tmp/cc6oMFbI.s
ignoring nonexistent directory
"/home/ralf/gcc-test/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.3.0/../../../../x86_64-unknown-linux-gnu/include"
ignoring duplicate directory
"/home/ralf/gcc-test/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-linux-gnu/4.3.0/include"
ignoring duplicate directory
"/home/ralf/gcc-test/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-linux-gnu/4.3.0/include-fixed"
ignoring nonexistent directory
"/home/ralf/gcc-test/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-linux-gnu/4.3.0/../../../../x86_64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /home/ralf/gcc-test/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.3.0/include

/home/ralf/gcc-test/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.3.0/include-fixed
 /usr/local/include
 /home/ralf/gcc-test/bin/../lib/gcc/../../include
 /usr/include
End of search list.
GNU C (GCC) version 4.3.0 20080218 (experimental) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.0.3 (Ubuntu 4.0.3-1ubuntu5), GMP version
4.2.1, MPFR version 2.2.1.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: f7cc2c1b2fd21e5ef094efa68990cd25
COLLECT_GCC_OPTIONS='-o' 'a' '-v' '-mtune=generic'
 as -V -Qy -o /tmp/ccUzmcgh.o /tmp/cc6oMFbI.s
GNU assembler version 2.16.91 (x86_64-linux-gnu) using BFD version 2.16.91
20060118 Debian GNU/Linux
COMPILER_PATH=/home/ralf/gcc-test/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.3.0/:/home/ralf/gcc-test/bin/../libexec/gcc/
LIBRARY_PATH=/home/ralf/gcc-test/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.3.0/:/home/ralf/gcc-test/bin/../lib/gcc/:/home/ralf/gcc-test/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.3.0/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/home/ralf/gcc-test/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.3.0/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-o' 'a' '-v' '-mtune=generic'
 /home/ralf/gcc-test/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.3.0/collect2
--eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o a
/usr/lib/../lib64/crt1.o /usr/lib/../lib64/crti.o
/home/ralf/gcc-test/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.3.0/crtbegin.o
-L/home/ralf/gcc-test/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.3.0
-L/home/ralf/gcc-test/bin/../lib/gcc
-L/home/ralf/gcc-test/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.3.0/../../../../lib64
-L/lib/../lib64 -L/usr/lib/../lib64
-L/home/ralf/gcc-test/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.3.0/../../..
/tmp/ccUzmcgh.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed
-lgcc_s --no-as-needed
/home/ralf/gcc-test/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.3.0/crtend.o
/usr/lib/../lib64/crtn.o
/usr/bin/ld: cannot find -lgcc_s
collect2: ld returned 1 exit status

Problem is, libgcc_s lives in
/home/ralf/gcc-test/lib/gcc/x86_64-unknown-linux-gnu/lib64/

I don't think this is related to PR #35197.


-- 
   Summary: --enable-version-specific-runtime-libs broken
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: driver
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Ralf dot Wildenhues at gmx dot de
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug c++/35247] Usage of openmp pragmas causes internal compiler error

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-02-18 09:41 ---


*** This bug has been marked as a duplicate of 35185 ***


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug middle-end/35185] ICE using openmp with g++-4.2

[rguenth at gcc dot gnu dot org]

--- Comment #7 from rguenth at gcc dot gnu dot org  2008-02-18 09:41 ---
*** Bug 35247 has been marked as a duplicate of this bug. ***


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ttsiod at softlab dot ntua
   ||dot gr


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

[Bug target/33555] x86 missed opportunity for sbb

[ubizjak at gmail dot com]

--- Comment #1 from ubizjak at gmail dot com  2008-02-18 09:58 ---
Created an attachment (id=15183)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15183&action=view)
Patch to implement missed optimization.

2008-02-18  Uros Bizjak  <[EMAIL PROTECTED]>

PR target/33555
* config/i386/i386.md (*x86_movsicc_0_m1_se): New insn pattern.
(*x86_movdicc_0_m1_se): Ditto.

testsuite/ChangeLog:

2008-02-18  Uros Bizjak  <[EMAIL PROTECTED]>

PR target/33555
* gcc.target/i386/pr33555.c: New test.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |ubizjak at gmail dot com
   |dot org |
 Status|UNCONFIRMED |ASSIGNED


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

[Bug driver/35248] --enable-version-specific-runtime-libs broken

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-02-18 10:07 ---
libgcc_s goes into slibdir which is set as

AC_ARG_WITH(slibdir,
[  --with-slibdir=DIR  shared libraries in DIR [[LIBDIR]]],
slibdir="$with_slibdir",
if test "${enable_version_specific_runtime_libs+set}" = set; then
  slibdir='$(libsubdir)'
elif test "$host" != "$target"; then
  slibdir='$(build_tooldir)/lib'
else
  slibdir='$(libdir)'
fi)
AC_SUBST(slibdir)

and libsubdir is (should be)

libsubdir = $(libdir)/gcc/$(target_noncanonical)/$(version)

but indeed, the (shared and .so link) libs end up in
$(libdir)/gcc/$(target_noncanonical)/lib{,64} instead.

Possibly the install-shared rule of libgcc is bogus, but who knows.
CCing a build system maintainer.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||bonzini at gnu dot org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-02-18 10:07:19
   date||


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

[Bug c++/35078] ICE with reference in parallel for loop

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
   |dot org |
URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2008-
   ||02/msg00687.html
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-02-04 14:27:31 |2008-02-18 10:19:41
   date||


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

[Bug c/32511] GCC inlines weak function

[rguenth at gcc dot gnu dot org]

-- 

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-02-17 21:05:49 |2008-02-18 10:44:02
   date||


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

[Bug target/35179] execs crash in shared lib destructor = do_global_dtors_aux

[lakshmivaraganm at hcl dot in]

--- Comment #4 from lakshmivaraganm at hcl dot in  2008-02-18 12:08 ---
This "Crash on exit" problem is there if we call exit(0) or call return 0.
If _exit(0) is used, there is no crash.


-- 


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

[Bug c++/34964] ICE with broken variable in #pragma omp threadprivate

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
   |dot org |
URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2008-
   ||02/msg00689.html
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-01-25 09:59:52 |2008-02-18 13:49:43
   date||


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

[Bug c++/35244] Broken diagnostic: 'type_decl' not supported by dump_expr

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
   |dot org |
URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2008-
   ||02/msg00689.html
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-02-17 23:14:42 |2008-02-18 13:50:00
   date||


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

[Bug c++/35028] ICE with strange ctor and firstprivate

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
   |dot org |
URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2008-
   ||02/msg00691.html
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-01-30 10:02:10 |2008-02-18 13:50:26
   date||


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

[Bug target/35193] [4.3 Regression] can't find a register in class 'R1_REGS' while reloading 'asm'

[danglin at gcc dot gnu dot org]

--- Comment #6 from danglin at gcc dot gnu dot org  2008-02-18 15:23 ---
The testcase compiles with -fno-gcse.  However, the result from the gcse1
pass using the 4.2 branch is similar to that with 4.3.

In the greg dump with 4.3, we have:

(insn 957 956 958 132
../ports/sysdeps/unix/sysv/linux/hppa/nptl/lowlevellock.h:220 (set (reg/f:SI
735)
(high:SI (symbol_ref:SI ("lock.8450") [flags 0x2] ))) 49 {*pa.md:3017} (expr_list:REG_EQUIV (high:SI (symbol_ref:SI
("lock.8450") [flags 0x2] ))
(nil)))

(insn 958 957 1588 132
../ports/sysdeps/unix/sysv/linux/hppa/nptl/lowlevellock.h:220 (set (reg/f:SI
743)
(lo_sum:SI (reg/f:SI 735)
(symbol_ref:SI ("lock.8450") [flags 0x2] ))) 52 {*pa.md:3097} (expr_list:REG_EQUIV (symbol_ref:SI ("lock.8450")
[flags 0x2] )
(nil)))

In the 4.2 dump, we have:

(insn 1097 1096 1764 125 (set (reg:SI 1 %r1)
(high:SI (symbol_ref:SI ("lock___8727") [flags 0x2] ))) 49 {*pa.md:2959} (nil)
(expr_list:REG_EQUIV (high:SI (symbol_ref:SI ("lock___8727") [flags 0x2]
))
(nil)))

(insn 1764 1097 1102 125 (set (reg/f:SI 18 %r18 [692])
(reg:SI 1 %r1)) 37 {*pa.md:2484} (nil)
(nil))

(insn 1102 1764 1098 125 (set (reg:SI 19 %r19 [574])
(const_int 1 [0x1])) 37 {*pa.md:2484} (nil)
(expr_list:REG_EQUIV (const_int 1 [0x1])
(nil)))

(insn 1098 1102 1103 125 (set (reg/f:SI 10 %r10 [694])
(lo_sum:SI (reg/f:SI 18 %r18 [692])
(symbol_ref:SI ("lock___8727") [flags 0x2] ))) 52 {*pa.md:3039} (nil)
(expr_list:REG_EQUIV (symbol_ref:SI ("lock___8727") [flags 0x2] )
(nil)))

Also, there is:

Reloads for insn # 1097
Reload 0: reload_out (SI) = (reg/f:SI 18 %r18 [692])
R1_REGS, RELOAD_FOR_OUTPUT (opnum = 0)
reload_out_reg: (reg/f:SI 18 %r18 [692])
reload_reg_rtx: (reg:SI 1 %r1)

It seems like 4.3 is no longer doing the output reload.


-- 


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

[Bug c/35249] New: gcc miscompiles emacs' src/intervals.c when using optimisation on solaris 8

[simon dot marshall at misys dot com]

I seem to have found a problem where gcc-4.1.2 and gcc-4.2.3 miscompile Emacs'
src/intervals.c when using optimisation on solaris 8.  

$ gcc -v
Using built-in specs.
Target: sparc-sun-solaris2.8
Configured with: ../configure --enable-languages=c,c++
Thread model: posix
gcc version 4.2.3

I discovered it when investigating a problem whereby Emacs periodically
determined that some internal state was inconsistent.  Unfortunately, even
though I managed to find a scenario that reliably reproduced it, other people
were unable to reproduce it on other platforms.  So, at someone else's
suggestion, I investigated it as something specific to my environment.

Here's how to reproduce the problem.  Untar emacs-22.1, do a minimal configure
and build it on a solaris 2.8 box:

$ ./configure --with-x-toolkit=lucid --without-xaw3d --without-xpm
--without-jpeg --without-tiff --without-gif --without-png
--without-toolkit-scroll-bars
$ make

This builds everything with "-g -O2 -Wno-pointer-sign", giving the executable
src/emacs.

$ gdb src/emacs
GNU gdb 6.7.1
Copyright (C) 2007 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "sparc-sun-solaris2.8"...

Now put a breakpoint on the place where emacs is about to report that some
internal state is inconsistent.

(gdb) b intervals.c:794
Breakpoint 1 at 0x190db4: file intervals.c, line 794.
(gdb) r -Q
Starting program:
/homedev/marshals/ftp/emacs-22.2-pretests/gcc-4.2.3-g-O2/src/emacs -Q
warning: Temporarily disabling breakpoints for unloaded shared library
"/usr/lib/ld.so.1"

At this point, type C-x C-f src/intervals.c RET into the Emacs window.

Breakpoint 1, update_interval (i=0x81b6f4, pos=1771) at intervals.c:794
794 error ("Point before start of properties");
(gdb) 

The breakpoint it hit, as emacs is about to report that some internal state is
inconsistent.  Now exit gdb and rebuild just intervals.c:

$ rm -f src/intervals.o
$ make CFLAGS=-g

This builds just intervals.o with "-g".  Repeat the above gdb session and you
will find that emacs does not hit the breakpoint, ie, the executable code is
functionally different.

I have reproduced this with gcc-4.1.2 and gcc-4.2.3.  I cannot reproduce it
using Sun Studio CC-5.7.  I also could not reproduce it on RHEL-5 with its
gcc-4.1.2, nor could a couple of other people who tried it on non-sparc
platforms.

I have also found that if I build everything else with "-g", but intervals.c
with "-g -O2", then I can reproduce this problem.  So, it seems specific to the
optimisation of intervals.c and specific to Solaris.  How could that be?

I appreciate that Emacs is not the smallest of test cases and I apologise in
advance for this crime.  Anything I can do to help determine the cause?


-- 
   Summary: gcc miscompiles emacs' src/intervals.c when using
optimisation on solaris 8
   Product: gcc
   Version: 4.2.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: simon dot marshall at misys dot com
 GCC build triplet: sparc-sun-solaris2.8
  GCC host triplet: sparc-sun-solaris2.8
GCC target triplet: sparc-sun-solaris2.8


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

[Bug c/35249] gcc miscompiles emacs' src/intervals.c when using optimisation on solaris 8

[simon dot marshall at misys dot com]

--- Comment #2 from simon dot marshall at misys dot com  2008-02-18 18:06 
---
> > I appreciate that Emacs is not the smallest of test cases and I apologise in
> > advance for this crime.  Anything I can do to help determine the cause?
> 
> Are you familiar with src/intervals.c?  If so, you could try to narrow down
> the problem to a single function, if possible.  Try first to compile it at
> -O1 only, then add -fno-unit-at-a-time.  What happens?

Thanks for the quick response.  Unfortunately, I'm not familiar with
src/intervals.c and I doubt if it is easy to split it up...

But, to answer your suggestion, I forgot to mention that I could reproduce the
problem with "-g -O" and "-g -O1".  Following your suggestion, I also tried "-g
-O1 -fno-unit-at-a-time" on src/intervals.c and the problem remains (the
breakpoint is hit).  The breakpoint is not hit with "-g -fno-unit-at-a-time"
(or with "-g", as I originally reported).  Does this help?


-- 


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

[Bug c/35249] gcc miscompiles emacs' src/intervals.c when using optimisation on solaris 8

[ebotcazou at gcc dot gnu dot org]

--- Comment #1 from ebotcazou at gcc dot gnu dot org  2008-02-18 17:51 
---
> I have reproduced this with gcc-4.1.2 and gcc-4.2.3.  I cannot reproduce it
> using Sun Studio CC-5.7.  I also could not reproduce it on RHEL-5 with its
> gcc-4.1.2, nor could a couple of other people who tried it on non-sparc
> platforms.

Thanks for the detailed report.

> I have also found that if I build everything else with "-g", but intervals.c
> with "-g -O2", then I can reproduce this problem.  So, it seems specific to
> the optimisation of intervals.c and specific to Solaris.  How could that be?

Some optimizations are target-dependent, so it's not uncommon.

> I appreciate that Emacs is not the smallest of test cases and I apologise in
> advance for this crime.  Anything I can do to help determine the cause?

Are you familiar with src/intervals.c?  If so, you could try to narrow down
the problem to a single function, if possible.  Try first to compile it at
-O1 only, then add -fno-unit-at-a-time.  What happens?


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu dot
   ||org


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

[Bug c/35249] gcc miscompiles emacs' src/intervals.c when using optimisation on solaris 8

[ebotcazou at gcc dot gnu dot org]

--- Comment #3 from ebotcazou at gcc dot gnu dot org  2008-02-18 18:21 
---
> Thanks for the quick response.  Unfortunately, I'm not familiar with
> src/intervals.c and I doubt if it is easy to split it up...

Is it possible to guess in what function things go awry?

> But, to answer your suggestion, I forgot to mention that I could reproduce
> the problem with "-g -O" and "-g -O1".  Following your suggestion, I also
> tried "-g -O1 -fno-unit-at-a-time" on src/intervals.c and the problem
> remains (the breakpoint is hit).

That the problem is present with -g -O1 -fno-unit-at-a-time means that it's
easier to pinpoint the bug, since there is no under the hood inlining at this
level.  So it presumably should be possible to find out which function is
miscompiled using source level debugging.


-- 


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

[Bug middle-end/34921] Misalign stack variable referenced by nested function

[hjl at gcc dot gnu dot org]

--- Comment #8 from hjl at gcc dot gnu dot org  2008-02-18 23:44 ---
Subject: Bug 34921

Author: hjl
Date: Mon Feb 18 23:43:23 2008
New Revision: 132396

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132396
Log:
gcc/

2008-02-18  Joey Ye  <[EMAIL PROTECTED]>

PR middle-end/34921
* tree-nested.c (insert_field_into_struct): Set type alignment
to field alignment if the former is less than the latter.

gcc/testsuite/

2008-02-18  Joey Ye  <[EMAIL PROTECTED]>
H.J. Lu  <[EMAIL PROTECTED]>

PR middle-end/34921
* gcc.c-torture/execute/nest-align-1.c: New test case.

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/nest-align-1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-nested.c


-- 


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

[Bug c++/32089] Winline reports bogus warning

[mckelvey at maskull dot com]

--- Comment #7 from mckelvey at maskull dot com  2008-02-19 00:58 ---
How can GCC conclude that a call is going to be infrequent? Doesn't that
amount to predicting the future? Also, if an object is constructed, then it
will
be destroyed. So there is almost a 100% chance of calling the destructor if the
class is used at all. Maybe I'm missing something.

It would be best for the message to say the REAL reason for not inlining,
whatever that may be.

If that is not feasible, I would be OK with just saying "inlining call
determined to be unprofitable". That is vague, but not confusing.


-- 


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

[Bug target/35189] -mno-sse4.2 turns off SSE4a

[hjl at gcc dot gnu dot org]

--- Comment #6 from hjl at gcc dot gnu dot org  2008-02-19 01:21 ---
Subject: Bug 35189

Author: hjl
Date: Tue Feb 19 01:21:03 2008
New Revision: 132403

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132403
Log:
gcc/

2008-02-18  H.J. Lu  <[EMAIL PROTECTED]>

PR target/35189
* config/i386/i386.c (OPTION_MASK_ISA_MMX_SET): New.
(OPTION_MASK_ISA_3DNOW_SET): Likewise.
(OPTION_MASK_ISA_SSE_SET): Likewise.
(OPTION_MASK_ISA_SSE2_SET): Likewise.
(OPTION_MASK_ISA_SSE3_SET): Likewise.
(OPTION_MASK_ISA_SSSE3_SET): Likewise.
(OPTION_MASK_ISA_SSE4_1_SET): Likewise.
(OPTION_MASK_ISA_SSE4_2_SET): Likewise.
(OPTION_MASK_ISA_SSE4_SET): Likewise.
(OPTION_MASK_ISA_SSE4A_SET): Likewise.
(OPTION_MASK_ISA_SSE5_SET): Likewise.
(OPTION_MASK_ISA_3DNOW_A_UNSET): Likewise.
(OPTION_MASK_ISA_MMX_UNSET): Updated.
(OPTION_MASK_ISA_3DNOW_UNSET): Updated.
(OPTION_MASK_ISA_SSE_UNSET): Likewise.
(OPTION_MASK_ISA_SSE3_UNSET): Likewise.
(OPTION_MASK_ISA_SSSE3_UNSET): Likewise.
(OPTION_MASK_ISA_SSE4_1_UNSET): Likewise.
(OPTION_MASK_ISA_SSE4_2_UNSET): Likewise.
(OPTION_MASK_ISA_SSE4A_UNSET): Likewise.
(OPTION_MASK_ISA_SSE5_UNSET): Likewise.
(OPTION_MASK_ISA_SSE4): Removed.
(ix86_handle_option): Turn on bits in ix86_isa_flags and
ix86_isa_flags_explicit with OPTION_MASK_ISA_XXX_SET for
-mXXX.
(override_options): Don't turn on implied SSE/MMX bits in
ix86_isa_flags.

gcc/testsuite/

2008-02-18  H.J. Lu  <[EMAIL PROTECTED]>

PR target/35189
* gcc.target/i386/isa-1.c: New.
* gcc.target/i386/isa-2.c: Likewise.
* gcc.target/i386/isa-3.c: Likewise.
* gcc.target/i386/isa-4.c: Likewise.
* gcc.target/i386/isa-5.c: Likewise.
* gcc.target/i386/isa-6.c: Likewise.
* gcc.target/i386/isa-7.c: Likewise.
* gcc.target/i386/isa-8.c: Likewise.
* gcc.target/i386/isa-9.c: Likewise.
* gcc.target/i386/isa-10.c: Likewise.
* gcc.target/i386/isa-11.c: Likewise.
* gcc.target/i386/isa-12.c: Likewise.
* gcc.target/i386/isa-13.c: Likewise.
* gcc.target/i386/isa-14.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.target/i386/isa-1.c
trunk/gcc/testsuite/gcc.target/i386/isa-10.c
trunk/gcc/testsuite/gcc.target/i386/isa-11.c
trunk/gcc/testsuite/gcc.target/i386/isa-12.c
trunk/gcc/testsuite/gcc.target/i386/isa-13.c
trunk/gcc/testsuite/gcc.target/i386/isa-14.c
trunk/gcc/testsuite/gcc.target/i386/isa-2.c
trunk/gcc/testsuite/gcc.target/i386/isa-3.c
trunk/gcc/testsuite/gcc.target/i386/isa-4.c
trunk/gcc/testsuite/gcc.target/i386/isa-5.c
trunk/gcc/testsuite/gcc.target/i386/isa-6.c
trunk/gcc/testsuite/gcc.target/i386/isa-7.c
trunk/gcc/testsuite/gcc.target/i386/isa-8.c
trunk/gcc/testsuite/gcc.target/i386/isa-9.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug target/35071] bad instruction `do_itt eq'

[pbrook at gcc dot gnu dot org]

--- Comment #9 from pbrook at gcc dot gnu dot org  2008-02-19 01:30 ---
Fixed


-- 

pbrook at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug target/35071] bad instruction `do_itt eq'

[pbrook at gcc dot gnu dot org]

--- Comment #8 from pbrook at gcc dot gnu dot org  2008-02-19 01:29 ---
Subject: Bug 35071

Author: pbrook
Date: Tue Feb 19 01:29:09 2008
New Revision: 132404

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132404
Log:
2008-02-19  Paul Brook  <[EMAIL PROTECTED]>

PR target/35071
* config/arm/ieee754-df.S: Fix do_it typo.
* config/arm/ieee754-sf.S: Fix do_it typo.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/ieee754-df.S
trunk/gcc/config/arm/ieee754-sf.S


-- 


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

[Bug target/32871] [avr] Bad optimisation - gcc is pushing too many registers

[eric dot weddington at atmel dot com]

--- Comment #2 from eric dot weddington at atmel dot com  2008-02-19 02:45 
---
Confirmed. 4.2.2 produces unnecessary pushes and pops. 4.3.0 causes worse code
than 4.2.x and adds unnecessary moves. Adding const or pure function attributes
do not seem to help in 4.3.0.


-- 

eric dot weddington at atmel dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||missed-optimization
  Known to fail||4.2.1 4.2.2 4.3.0
   Last reconfirmed|-00-00 00:00:00 |2008-02-19 02:45:07
   date||
Summary|Bad optimisation - Gcc is   |[avr] Bad optimisation - gcc
   |pushing too many registers  |is pushing too many
   ||registers


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

[Bug target/11180] [avr-gcc] Optimization decrease performance of struct assignment.

[eric dot weddington at atmel dot com]

--- Comment #29 from eric dot weddington at atmel dot com  2008-02-19 02:47 
---
Rask's patch (gcc-4.3-bug-11180-experimental.patch) causes worse code for the
test case in bug #32871, than without the patch.


-- 


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

[Bug driver/34904] -march=native doesn't work with multiple input files

[hjl dot tools at gmail dot com]

--- Comment #6 from hjl dot tools at gmail dot com  2008-02-19 02:29 ---
Won't fix 4.2:

http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00715.html


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX


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

[Bug target/35071] bad instruction `do_itt eq'

[manu at gcc dot gnu dot org]

--- Comment #10 from manu at gcc dot gnu dot org  2008-02-19 02:20 ---
Paul,

notice that you fixed this *after* GCC 4.3 branched, so if your intention was
to fix it also for GCC 4.3, you would need to commit the fix to the branch (and
get a RM to approve it).


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.4.0


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

[Bug other/12618] core not cleaned up by 'make distclean'

[bje at gcc dot gnu dot org]

--- Comment #4 from bje at gcc dot gnu dot org  2008-02-19 03:23 ---
Subject: Bug 12618

Author: bje
Date: Tue Feb 19 03:23:15 2008
New Revision: 132405

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132405
Log:
PR other/12618
* testsuite/Makefile.in (mostlyclean): Remove any core file.

Modified:
trunk/libiberty/ChangeLog
trunk/libiberty/testsuite/Makefile.in


-- 


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

[Bug other/12618] core not cleaned up by 'make distclean'

[bje at gcc dot gnu dot org]

--- Comment #5 from bje at gcc dot gnu dot org  2008-02-19 04:12 ---
Fixed in trunk.


-- 

bje at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug middle-end/35193] [4.3 Regression] can't find a register in class 'R1_REGS' while reloading 'asm'

[danglin at gcc dot gnu dot org]

--- Comment #7 from danglin at gcc dot gnu dot org  2008-02-19 04:28 ---
It appears this regressions was introduced in revision 130297.


-- 

danglin at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|target  |middle-end


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

[Bug target/35071] bad instruction `do_itt eq'

[pbrook at gcc dot gnu dot org]

--- Comment #11 from pbrook at gcc dot gnu dot org  2008-02-19 04:33 ---
Subject: Bug 35071

Author: pbrook
Date: Tue Feb 19 04:32:15 2008
New Revision: 132408

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132408
Log:
2008-02-19  Paul Brook  <[EMAIL PROTECTED]>

PR target/35071
* config/arm/ieee754-df.S: Fix do_it typo.
* config/arm/ieee754-sf.S: Fix do_it typo.


Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/config/arm/ieee754-df.S
branches/gcc-4_3-branch/gcc/config/arm/ieee754-sf.S


-- 


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

[Bug target/35088] ICE: in def_cfa_1, at dwarf2out.c:804

[mmitchel at gcc dot gnu dot org]

--- Comment #4 from mmitchel at gcc dot gnu dot org  2008-02-19 04:37 
---
Can this issue now be closed?


-- 


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

[Bug other/35250] gmp and mpfr are erroneously configured with --target

[nightstrike at gmail dot com]

--- Comment #1 from nightstrike at gmail dot com  2008-02-19 05:32 ---
Here is the email thread that started it all:

http://gcc.gnu.org/ml/gcc-help/2008-02/msg00197.html


-- 


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

[Bug other/35250] New: gmp and mpfr are erroneously configured with --target

[nightstrike at gmail dot com]

When gmp and mpfr are in the build tree of gcc, they will be automatically
configured and build.  However, some of the options passed to configure are
incorrect according to the GMP manual:

[Begin quote] "Note that the `--target' option is not appropriate for
GMP. It's for use when building compiler tools, with `--host' being
where they will run, and `--target' what they'll produce code for.
Ordinary programs or libraries like GMP are only interested in the
`--host' part, being where they'll run. (Some past versions of GMP
used `--target' incorrectly.)" [End quote]


"--target" should be removed from both configure lines.  Here is the
Makefile.def that I was looking at:

host_modules= { module= gmp; lib_path=.libs; bootstrap=true;
   extra_configure_flags='--disable-shared';
   no_install= true;
   host="none-${host_vendor}-${host_os}";
   target="none-${host_vendor}-${host_os}"; };
host_modules= { module= mpfr; lib_path=.libs; bootstrap=true;
   extra_configure_flags='--disable-shared
--with-gmp-build=$$r/$(HOST_SUBDIR)/gmp';
   no_install= true;
   host="none-${host_vendor}-${host_os}";
   target="none-${host_vendor}-${host_os}"; };


Here is a patch:

Index: Makefile.def
===
--- Makefile.def(revision 132380)
+++ Makefile.def(working copy)
@@ -61,13 +61,11 @@ host_modules= { module= gettext; };
 host_modules= { module= gmp; lib_path=.libs; bootstrap=true;
extra_configure_flags='--disable-shared';
no_install= true;
-   host="none-${host_vendor}-${host_os}";
-   target="none-${host_vendor}-${host_os}"; };
+   host="none-${host_vendor}-${host_os}"; };
 host_modules= { module= mpfr; lib_path=.libs; bootstrap=true;
extra_configure_flags='--disable-shared
--with-gmp-build=$$r/$(HOST_SUBDIR)/gmp';
no_install= true;
-   host="none-${host_vendor}-${host_os}";
-   target="none-${host_vendor}-${host_os}"; };
+   host="none-${host_vendor}-${host_os}"; };
 host_modules= { module= gnuserv; };
 host_modules= { module= gprof; };
 host_modules= { module= gzip; };


-- 
   Summary: gmp and mpfr are erroneously configured with --target
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: trivial
  Priority: P3
 Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: nightstrike at gmail dot com


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

[Bug c++/34950] [4.2/4.3 Regression] ICE in svn boost math toolkit

[mark at codesourcery dot com]

--- Comment #15 from mark at codesourcery dot com  2008-02-19 06:15 ---
Subject: Re:  [4.2/4.3 Regression] ICE in svn boost math toolkit

rguenth at gcc dot gnu dot org wrote:
> --- Comment #14 from rguenth at gcc dot gnu dot org  2008-02-12 23:19 
> ---
> It looks like simply deleting from dependent_type_p:
> 
>   /* If there are no template parameters in scope, then there can't be
>  any dependent types.  */
>   if (!processing_template_decl)
> {
>   /* If we are not processing a template, then nobody should be
>  providing us with a dependent type.  */
>   gcc_assert (type);
>   gcc_assert (TREE_CODE (type) != TEMPLATE_TYPE_PARM);
>   return false;
> }
> 
> fixes the testcase - so we are probably not setting processing_template_decl
> correctly(?).  Or is it even correct and the check in the context of
> the caller make_typename_type is simply bogus?

We definitely don't want to delete that from dependent_type_p; it's a 
vital optimization.  I think the usage in make_typename_type is correct; 
when CONTEXT is a dependent type, we have to make a real TYPENAME_TYPE; 
when it's not, we can figure out what's being referenced immediately.

What does the stack trace look like at the point we're crashing?  What 
typename type are trying to simplify?


-- 


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

[Bug middle-end/27986] [4.0/4.1/4.2/4.3 Regression] jump to middle of loop on entry with using old version of an variable

[xinliangli at gmail dot com]

--- Comment #10 from xinliangli at gmail dot com  2008-02-19 06:00 ---
(In reply to comment #0)
> in the following code gcc choses the registers in such a way that it causes
> itself an extra copy for every loop iteration and has to jump past the copy to
> start the loop... it's probably easiest to describe just by looking at the
> code:
> 
> % cat jmp-over.c
> void foo(int *v, int *d, int g)
> {
>   int s = v[1];
>   int s0;
>   do {
> s0 = s;
> s += *d;
> ++d;
>   } while (s < g);
>   v[0] = s0;
> }
> 
> % gcc -g -O3 -Wall   -c -o jmp-over.o jmp-over.c
> % objdump -dr jmp-over.o
> 
> jmp-over.o: file format elf64-x86-64
> 
> Disassembly of section .text:
> 
>  :
>0:   8b 4f 04mov0x4(%rdi),%ecx
>3:   eb 02   jmp7 
>5:   89 c1   mov%eax,%ecx
>7:   89 c8   mov%ecx,%eax
>9:   03 06   add(%rsi),%eax
>b:   48 83 c6 04 add$0x4,%rsi
>f:   39 d0   cmp%edx,%eax
>   11:   7c f2   jl 5 
>   13:   89 0f   mov%ecx,(%rdi)
>   15:   c3  retq
> 
> the jump-over is unnecessary...
> 
> mov0x4(%rdi),%ecx
> 1:  mov%ecx,%eax
> add(%rsi),%ecx
> add$0x4,%rsi
> cmp%edx,%ecx
> jl 1b
> mov%eax,(%rdi)
> retq
> 
> -dean
> 
> % gcc -v
> Using built-in specs.
> Target: x86_64-linux-gnu
> Configured with: ../gcc/configure --prefix=/home/odo/gcc
> --host=x86_64-linux-gnu --disable-multilib --enable-languages=c,c++
> --disable-bootstrap
> Thread model: posix
> gcc version 4.2.0 20060603 (experimental)
> 


// David Li

Note that assignment of s0 = s in the loop is mostly dead except for the last
occurence. So it should be optimized into:

do {
   s += *d;
   ++d;
} while (s < g);
v[0] = (s-*(d-1));


-- 

xinliangli at gmail dot com changed:

   What|Removed |Added

 CC||xinliangli at gmail dot com


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

[Bug middle-end/35251] internal compiler error: verify_stmts failed

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2008-02-19 06:42 ---
> gcc version 4.2.0 20060713 (experimental)

That is an old version of 4.2.0, can you try a new version of gcc 4.2.x.


-- 


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

[Bug fortran/35251] New: internal compiler error: verify_stmts failed

[kendrick dot killian at colostate dot edu]

during compile, received the following output
bug.f: In function 'master.0.mnthweek':
bug.f:82: error: invalid operand to binary operator
__result_master.0.mnthweekD.911

bug.f:82: internal compiler error: verify_stmts failed
Please submit a full bug report,
with preprocessed source if appropriate.


Gfortran version
Using built-in specs.
Target: powerpc-apple-darwin8
Configured with: ../gcc/configure --prefix=/usr/local/gfortran
--enable-languages=c,fortran --with-gmp=/tmp/gfortran-20060713/gfortran_libs
--enable-bootstrap --build=powerpc-apple-darwin8 --host=powerpc-apple-darwin8
--target=powerpc-apple-darwin8 : (reconfigured) ../gcc/configure
--prefix=/usr/local/gfortran --enable-languages=c,fortran
--with-gmp=/tmp/gfortran-20060713/gfortran_libs --enable-bootstrap
--build=powerpc-apple-darwin8 --host=powerpc-apple-darwin8
--target=powerpc-apple-darwin8 --disable-multilib
Thread model: posix
gcc version 4.2.0 20060713 (experimental)

The same code compiles with
gcc version 4.1.0 20060304 (Red Hat 4.1.0-3)



Compile command:
gfortran -fno-backslash -implicit-none -O3 -m32 -c bug.f

code:
c===
  integer function mnthweek(month, event)
integer month
character*(*) event
c   convert monthly values to a week based on the event
c  Events 'GRAZ', 'TREM', 'FIRE', 'HARV' and 'THRV' occur after plant 

integer MONTHS
parameter (MONTHS = 12)

integer wtomonth, wkprmn, winmonth, m


integer frstwk(MONTHS), lastwk(MONTHS)
data frstwk /1,  5,  9, 14, 18, 22, 27, 31, 35, 40, 44, 48/
data lastwk /4,  8, 13, 17, 21, 26, 30, 34, 39, 43, 47, 52/


c   Make sure that we are asking about a valid month
m = mod(month-1,12)+1

c   by default assume the event will occur on the first week

c   The special case of every week in the month
mnthweek = frstwk(m)
if(event .eq. 'IRRI' .or. event .eq. 'GRAZ') then
  mnthweek = (lastwk(m)-frstwk(m))*1000 + mnthweek


c   the following events occur after growth in Century 4. Place these
c   events in the last week

c   removal and harvest
else if (event .eq. 'TREM' .or. event .eq. 'FIRE' .or.
 &  event .eq. 'HARV' .or.  event .eq. 'THRV') then
  mnthweek = lastwk(m)
endif

write(*,*) mnthweek,' = mnthweek(',month, event,')'
  return

c convert the week number to month
  entry wtomonth(month)
 wtomonth = mod(int(mod(month+43,52)*3./13.)+2,12)+1
  return
  end
c===


NOTE:
code compiles if the write
write(*,*) mnthweek,' = mnthweek(',month, event,')'
or the entry block is removed.

I did not try a newer build.


-- 
   Summary: internal compiler error: verify_stmts failed
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kendrick dot killian at colostate dot edu


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

[Bug target/35088] ICE: in def_cfa_1, at dwarf2out.c:804

[corsepiu at gcc dot gnu dot org]

--- Comment #5 from corsepiu at gcc dot gnu dot org  2008-02-19 06:34 
---
(In reply to comment #4)
> Can this issue now be closed?
IMO, yes. But I prefer to leave closing this PR to an m68k-specialist.


-- 


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

[Bug target/33555] x86 missed opportunity for sbb

[uros at gcc dot gnu dot org]

--- Comment #2 from uros at gcc dot gnu dot org  2008-02-19 07:24 ---
Subject: Bug 33555

Author: uros
Date: Tue Feb 19 07:23:30 2008
New Revision: 132414

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132414
Log:
PR target/33555
* config/i386/i386.md (*x86_movsicc_0_m1_se): New insn pattern.
(*x86_movdicc_0_m1_se): Ditto.

testsuite/ChangeLog:

PR target/33555
* gcc.target/i386/pr33555.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr33555.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.md
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug target/33555] x86 missed opportunity for sbb

[ubizjak at gmail dot com]

--- Comment #3 from ubizjak at gmail dot com  2008-02-19 07:41 ---
Fixed.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug tree-optimization/35178] Misaligned Accesses on arrays of packed stucts

[chrbr at gcc dot gnu dot org]

--- Comment #4 from chrbr at gcc dot gnu dot org  2008-02-19 07:53 ---
fixed in mainline


-- 

chrbr at gcc dot gnu dot org changed:

   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2008-
   ||02/msg00690.html
 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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