[Bug libstdc++/43259] ext/profile/all.cc fails on Solaris

[rus at google dot com]

--- Comment #8 from rus at google dot com  2010-03-21 04:52 ---
Good point. I don't think that setenv should be there in the first place
actually.  I'll try to fix that as well.

Just FYI, I'm planning to fix all the reported libstdc++ profile issues around
second week of April.


-- 


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

[Bug target/43440] Overwriting neon quad register does not clobber all included single registers

[siarhei dot siamashka at gmail dot com]

--- Comment #6 from siarhei dot siamashka at gmail dot com  2010-03-21 
03:56 ---
(In reply to comment #4)
> IMO the reasons as described in my email  is another motivation for Neon
> programmers to be using intrinsics rather than inline assembler and to improve
> in general Neon intrinsics.

The problem is that today neon intrinsics have a lot more issues in practice.
The resulting code is way too slow to be usable, especially when gcc thinks
that it is running out of registers and starts spilling variables to memory.
Bug 43118 and bug 43364 are just some very basic examples of performance issues
without looking any deeper. Not having many bugs in bugzilla for NEON
intrinsics means that either they work good enough or nobody seriously uses
them. At least for me it is the latter case.

Autovectorization is even worse than intrinsics.

Inline assembly has a few bugs, but they can be easily workarounded.

Sorry for this rant/offtopic. Just thought that you might be somewhat
interested the opinion of someone from the other side of the fence :-)


-- 

siarhei dot siamashka at gmail dot com changed:

   What|Removed |Added

 CC||siarhei dot siamashka at
   ||gmail dot com


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

[Bug fortran/43463] New: large compile time regressions for Polyhedron 2005 benchmarks

[howarth at nitro dot med dot uc dot edu]

Comparing the Polyhedron 2005 benchmarks from current gcc 4.4 branch (r157587)
with those of gcc trunk (r157600) on x86_64-apple-darwin10 shows significant
regressions in the compile time compared to the previous release. The results
for gcc 4.4 branch are...


Date & Time : 20 Mar 2010 20:47:42
Test Name   : gfortran_lin_O3
Compile Command : gfortran -ffast-math -funroll-loops -msse3 -O3 %n.f90 -o %n
Benchmarks  : ac aermod air capacita channel doduc fatigue gas_dyn induct
linpk mdbx nf protein rnflow test_fpu tfft
Maximum Times   : 2000.0
Target Error %  :  0.100
Minimum Repeats :10
Maximum Repeats :   100

   Benchmark   Compile  Executable   Ave Run  Number   Estim
Name(secs) (bytes)(secs) Repeats   Err %
   -   ---  --   --- ---  --
  ac  0.88   1 11.24  10  0.0070
  aermod 36.51   1 21.49  10  0.0117
 air  2.10   1  5.69  15  0.0463
capacita  1.41   1 35.28  10  0.0351
 channel  0.74   1  1.75  10  0.0255
   doduc  4.31   1 27.49  10  0.0062
 fatigue  1.64   1  8.45  12  0.0358
 gas_dyn  2.38   1  5.07  14  0.0926
  induct  3.46   1 12.81  10  0.0055
   linpk  0.73   1 15.43  10  0.0633
mdbx  1.39   1 11.27  10  0.0052
  nf  2.99   1 29.19  16  0.0987
 protein  3.42   1 35.32  10  0.0253
  rnflow  4.45   1 23.38  10  0.0106
test_fpu  4.13   1  8.74  10  0.0136
tfft  0.45   1  1.90  10  0.0170

Geometric Mean Execution Time =  11.46 seconds



whereas the results for gcc trunk are...


Date & Time : 20 Mar 2010 22:44:44
Test Name   : gfortran_lin_O3
Compile Command : gfortran -ffast-math -funroll-loops -msse3 -O3 %n.f90 -o %n
Benchmarks  : ac aermod air capacita channel doduc fatigue gas_dyn induct
linpk mdbx nf protein rnflow test_fpu tfft
Maximum Times   : 2000.0
Target Error %  :  0.100
Minimum Repeats :10
Maximum Repeats :   100

   Benchmark   Compile  Executable   Ave Run  Number   Estim
Name(secs) (bytes)(secs) Repeats   Err %
   -   ---  --   --- ---  --
  ac  1.84   1 10.59  10  0.0061
  aermod 60.90   1 20.96  10  0.0076
 air  4.13   1  5.68  10  0.0880
capacita  2.76   1 33.16  10  0.0113
 channel  0.98   1  1.83  12  0.0089
   doduc  8.23   1 27.75  10  0.0085
 fatigue  3.09   1  8.05  10  0.0934
 gas_dyn  5.39   1  4.38  15  0.0621
  induct  6.96   1 12.65  10  0.0073
   linpk  1.03   1 15.40  10  0.0651
mdbx  2.41   1 11.33  10  0.0059
  nf  3.38   1 27.76  13  0.0973
 protein  7.79   1 37.02  10  0.0041
  rnflow  9.70   1 23.64  10  0.0224
test_fpu  7.25   1  8.67  12  0.0331
tfft  0.75   1  1.88  10  0.0514

Geometric Mean Execution Time =  11.25 seconds



The compile times have almost doubled which seem excessive for the optimization
improvements obtained.


-- 
   Summary: large compile time regressions for Polyhedron 2005
benchmarks
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: howarth at nitro dot med dot uc dot edu
 GCC build triplet: x86_64-apple-darwin10
  GCC host triplet: x86_64-apple-darwin10
GCC target triplet: x86_64-apple-darwin10


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

[Bug target/43440] Overwriting neon quad register does not clobber all included single registers

[siarhei dot siamashka at gmail dot com]

--- Comment #5 from siarhei dot siamashka at gmail dot com  2010-03-21 
03:33 ---
I don't quite understand what's the problem: "This patch has the unhappy side
effect of clobbering s0, s1 and s2 if s3 is used because that's the only way we
can indicate that q0 is clobbered by the write to s0."

The proper solution seems to be extremely simple to me and it should do exactly
the same what an application programmer would do to workaround the bug. Just
when initially parsing clobber list do a simple text substitution "q0" -> "d0",
"d1". Same for all the other "q" registers.


-- 


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

[Bug target/43462] Suboptimal switch table jump generation

[mirq-gccboogs at rere dot qmqm dot pl]

--- Comment #1 from mirq-gccboogs at rere dot qmqm dot pl  2010-03-21 03:28 
---
This is output from:
gcc -mcpu=cortex-m3 -mthumb -O3 -S a.c


-- 


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

[Bug target/43462] New: Suboptimal switch table jump generation

[mirq-gccboogs at rere dot qmqm dot pl]

code:

extern int a;
void b();
main()
{
switch (a & 7) {
case 0: b(); break;
case 1: b(); break;
case 2: b(); break;
case 3: b(); break;
case 4: b(); break;
case 5: b(); break;
case 6: b(); break;
case 7: b(); break;
}
}

generates:
[...]
and r3, r3, #7
subsr3, r3, #1
cmp r3, #6
bhi .L9
tbb [pc, r3]
.L10:  
.byte   (.L9-.L10)/2
.byte   (.L9-.L10)/2
.byte   (.L9-.L10)/2
.byte   (.L9-.L10)/2
.byte   (.L9-.L10)/2
.byte   (.L9-.L10)/2
.byte   (.L9-.L10)/2
.align  1
.L9:
[...]

This could be better implemented as:

and r3, r3, #7
tbb [pc, r3]
(jump table with 8 entries)
[...]

Please ignore that all branches are the same in this example.


-- 
   Summary: Suboptimal switch table jump generation
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mirq-gccboogs at rere dot qmqm dot pl
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: arm-none-eabi


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

[Bug target/43461] unsigned int var; (var & 0xFF) not translated to uxtb insn in Thumb mode

[mirq-gccboogs at rere dot qmqm dot pl]

--- Comment #1 from mirq-gccboogs at rere dot qmqm dot pl  2010-03-21 02:45 
---
$ gcc -v
Using built-in specs.
COLLECT_GCC=/usr/src/gcc-armtest/bin/arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/usr/src/gcc-armtest/libexec/gcc/arm-none-eabi/4.5.0/lto-wrapper
Target: arm-none-eabi
Configured with: ../gcc-combined/configure --with-newlib
--prefix=/usr/src/gcc-armtest --target arm-none-eabi --enable-languages=c
--disable-libssp
Thread model: single
gcc version 4.5.0 20100319 (experimental) (GCC) 

$ LANG=C svn info
Path: .
URL: svn://gcc.gnu.org/svn/gcc/trunk
Repository Root: svn://gcc.gnu.org/svn/gcc
Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4
Revision: 157582
Node Kind: directory
Schedule: normal
Last Changed Author: bernds
Last Changed Rev: 157582
Last Changed Date: 2010-03-19 19:41:22 +0100 (Fri, 19 Mar 2010)


-- 


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

[Bug target/43461] New: unsigned int var; (var & 0xFF) not translated to uxtb insn in Thumb mode

[mirq-gccboogs at rere dot qmqm dot pl]

Truncation of unsigned to byte is not translated to uxtb insn, but truncation
to short is translated to uxth.

invocation:

gcc -mcpu=cortex-m3 -mthumb -O3 -S a.c

code (a.c):

unsigned a();
extern unsigned b;
main()
{
b = a() & 0xFF;
b = (unsigned char)a();
b = a() & 0x;
b = (unsigned short)a();
}

resulting asm fragment (a.s):
[...]
bl  a
and r0, r0, #255
str r0, [r4, #0]

bl  a
uxtbr0, r0
str r0, [r4, #0]

bl  a
uxthr0, r0
str r0, [r4, #0]

bl  a
uxthr0, r0
str r0, [r4, #0]
[...]


-- 
   Summary: unsigned int var; (var & 0xFF) not translated to uxtb
insn in Thumb mode
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mirq-gccboogs at rere dot qmqm dot pl
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: arm-none-eabi


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

[Bug target/43460] internal compiler error: Segmentation fault on __builtin_unreachable() after asm goto()

[mirq-gccboogs at rere dot qmqm dot pl]

--- Comment #1 from mirq-gccboogs at rere dot qmqm dot pl  2010-03-21 02:24 
---
In case it's relevant, the version from sources not combined with newlib (0.18)
crashed in same way.


-- 


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

[Bug target/43460] New: internal compiler error: Segmentation fault on __builtin_unreachable() after asm goto()

[mirq-gccboogs at rere dot qmqm dot pl]

$ LANG=C /usr/src/gcc-armtest/bin/arm-none-eabi-gcc -c a.c 
a.c: In function 'main':
a.c:7:1: internal compiler error: Segmentation fault
[...]

$ cat a.c 
main()
{
asm goto(""  test);
__builtin_unreachable();
test:
;
}

It's the same with valid jump inside asm goto().

$ gcc -v
Using built-in specs.
COLLECT_GCC=/usr/src/gcc-armtest/bin/arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/usr/src/gcc-armtest/libexec/gcc/arm-none-eabi/4.5.0/lto-wrapper
Target: arm-none-eabi
Configured with: ../gcc-combined/configure --with-newlib
--prefix=/usr/src/gcc-armtest --target arm-none-eabi --enable-languages=c
--disable-libssp
Thread model: single
gcc version 4.5.0 20100319 (experimental) (GCC) 

$ LANG=C svn info
Path: .
URL: svn://gcc.gnu.org/svn/gcc/trunk
Repository Root: svn://gcc.gnu.org/svn/gcc
Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4
Revision: 157582
Node Kind: directory
Schedule: normal
Last Changed Author: bernds
Last Changed Rev: 157582
Last Changed Date: 2010-03-19 19:41:22 +0100 (Fri, 19 Mar 2010)

(Sources cut down to gcc-core equivalent.)


-- 
   Summary: internal compiler error: Segmentation fault on
__builtin_unreachable() after asm goto()
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mirq-gccboogs at rere dot qmqm dot pl
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: arm-none-eabi


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

[Bug regression/43459] New: Invalid "may be used uninitialized in this function" warning with -Os

[rwahl at gmx dot de]

Simple testcase:

--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--

#include 
#include 

int testfunc(void)
{
int ret;

while (1) {
const unsigned int MY_BUF_SIZE = 20;
char buf[MY_BUF_SIZE];

if (read(0, buf, sizeof(buf)) < 0) {
ret = errno;
goto bail;
}

}

 bail:
return ret;
}

--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--

With gcc 4.4.3 I get:

$ gcc -Wextra -Wall -Os -c test.c 
test.c: In function ‘testfunc’:
test.c:6: warning: ‘ret’ may be used uninitialized in this function
$ gcc -Wextra -Wall -c test.c 
$ gcc -Wextra -Wall -O -c test.c 
$ gcc -Wextra -Wall -O2 -c test.c 

gcc 4.3.2 did not show this issue.


-- 
   Summary: Invalid "may be used uninitialized in this function"
warning with -Os
   Product: gcc
   Version: 4.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: regression
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rwahl at gmx dot de


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

[Bug libstdc++/43259] ext/profile/all.cc fails on Solaris

[paolo dot carlini at oracle dot com]

--- Comment #7 from paolo dot carlini at oracle dot com  2010-03-21 01:59 
---
Silvius, when you will go through the various roblems on non-linux systems for
this test, also remember that setenv, as used in profiler_trace.h for example,
isn't always available, must be wrapped in #ifdef _GLIBCXX_HAVE_SETENV 


-- 


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

[Bug target/43458] c99_classification_macros_c.cc fails on hppa*-*-hpux*

[paolo dot carlini at oracle dot com]

--- Comment #1 from paolo dot carlini at oracle dot com  2010-03-21 01:50 
---
This is expected, given our implementation and the current status vs C99
macros. For now just tweak the dg- lines, include hppa*-*-hpux*. At some point
we'll want to clean-up the whole thing.


-- 


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

[Bug libstdc++/43259] ext/profile/all.cc fails on Solaris

[paolo dot carlini at oracle dot com]

--- Comment #6 from paolo dot carlini at oracle dot com  2010-03-21 01:44 
---
*** Bug 43457 has been marked as a duplicate of this bug. ***


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 CC||danglin at gcc dot gnu dot
   ||org


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

[Bug libstdc++/43457] FAIL: ext/profile/all.cc (test for excess errors)

[paolo dot carlini at oracle dot com]

--- Comment #1 from paolo dot carlini at oracle dot com  2010-03-21 01:44 
---


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


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug target/43458] New: c99_classification_macros_c.cc fails on hppa*-*-hpux*

[danglin at gcc dot gnu dot org]

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.5.0/hppa2.0w-hp-hpux11.11/bin/
-B/opt/gnu/gcc/gcc-4.5.0/hppa2.0
w-hp-hpux11.11/lib/ -isystem
/opt/gnu/gcc/gcc-4.5.0/hppa2.0w-hp-hpux11.11/includ
e -isystem /opt/gnu/gcc/gcc-4.5.0/hppa2.0w-hp-hpux11.11/sys-include
-B/test/gnu/
gcc/objdir/hppa2.0w-hp-hpux11.11/./libstdc++-v3/src/.libs -g -O2
-D_GLIBCXX_ASSE
RT -fmessage-length=0 -g -O2 -g -O2 -DLOCALEDIR="." -nostdinc++
-I/test/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/gnu/gcc/gcc/li
bstdc++-v3/libsupc++ -I/test/gnu/gcc/gcc/libstdc++-v3/include/backward
-I/test/g
nu/gcc/gcc/libstdc++-v3/testsuite/util
/test/gnu/gcc/gcc/libstdc++-v3/testsuite/
26_numerics/headers/cmath/c99_classification_macros_c.cc  
-D__GLIBCXX__=999
9 -S  -o c99_classification_macros_c.s(timeout = 600)
/test/gnu/gcc/gcc/libstdc++-v3/testsuite/26_numerics/headers/cmath/c99_classific
ation_macros_c.cc:40:16: error: macro "isgreater" requires 2 arguments, but
only
 1 given
/test/gnu/gcc/gcc/libstdc++-v3/testsuite/26_numerics/headers/cmath/c99_classific
ation_macros_c.cc:42:21: error: macro "isgreaterequal" requires 2 arguments,
but
 only 1 given
/test/gnu/gcc/gcc/libstdc++-v3/testsuite/26_numerics/headers/cmath/c99_classific
ation_macros_c.cc:44:13: error: macro "isless" requires 2 arguments, but only 1 
given
/test/gnu/gcc/gcc/libstdc++-v3/testsuite/26_numerics/headers/cmath/c99_classific
ation_macros_c.cc:46:18: error: macro "islessequal" requires 2 arguments, but
on
ly 1 given
/test/gnu/gcc/gcc/libstdc++-v3/testsuite/26_numerics/headers/cmath/c99_classific
ation_macros_c.cc:48:20: error: macro "islessgreater" requires 2 arguments, but 
only 1 given
/test/gnu/gcc/gcc/libstdc++-v3/testsuite/26_numerics/headers/cmath/c99_classific
ation_macros_c.cc:50:18: error: macro "isunordered" requires 2 arguments, but
on
ly 1 given
/test/gnu/gcc/gcc/libstdc++-v3/testsuite/26_numerics/headers/cmath/c99_classific
ation_macros_c.cc:28:6: error: expected unqualified-id before 'sizeof'
/test/gnu/gcc/gcc/libstdc++-v3/testsuite/26_numerics/headers/cmath/c99_classific
ation_macros_c.cc:28:6: error: expected ')' before 'sizeof'
/test/gnu/gcc/gcc/libstdc++-v3/testsuite/26_numerics/headers/cmath/c99_classific
ation_macros_c.cc:28:6: error: expected ')' before 'sizeof'
/test/gnu/gcc/gcc/libstdc++-v3/testsuite/26_numerics/headers/cmath/c99_classific
ation_macros_c.cc:30:6: error: expected unqualified-id before 'sizeof'
/test/gnu/gcc/gcc/libstdc++-v3/testsuite/26_numerics/headers/cmath/c99_classific
ation_macros_c.cc:30:6: error: expected ')' before 'sizeof'
/test/gnu/gcc/gcc/libstdc++-v3/testsuite/26_numerics/headers/cmath/c99_classific
ation_macros_c.cc:30:6: error: expected ')' before 'sizeof'
/test/gnu/gcc/gcc/libstdc++-v3/testsuite/26_numerics/headers/cmath/c99_classific
ation_macros_c.cc:32:6: error: expected unqualified-id before 'sizeof'
/test/gnu/gcc/gcc/libstdc++-v3/testsuite/26_numerics/headers/cmath/c99_classific
ation_macros_c.cc:32:6: error: expected ')' before 'sizeof'
/test/gnu/gcc/gcc/libstdc++-v3/testsuite/26_numerics/headers/cmath/c99_classific
ation_macros_c.cc:32:6: error: expected ')' before 'sizeof'
/test/gnu/gcc/gcc/libstdc++-v3/testsuite/26_numerics/headers/cmath/c99_classific
ation_macros_c.cc:34:6: error: expected unqualified-id before 'sizeof'
/test/gnu/gcc/gcc/libstdc++-v3/testsuite/26_numerics/headers/cmath/c99_classific
ation_macros_c.cc:34:6: error: expected ')' before 'sizeof'
/test/gnu/gcc/gcc/libstdc++-v3/testsuite/26_numerics/headers/cmath/c99_classific
ation_macros_c.cc:34:6: error: expected ')' before 'sizeof'
/test/gnu/gcc/gcc/libstdc++-v3/testsuite/26_numerics/headers/cmath/c99_classific
ation_macros_c.cc:36:6: error: expected unqualified-id before 'sizeof'
/test/gnu/gcc/gcc/libstdc++-v3/testsuite/26_numerics/headers/cmath/c99_classific
ation_macros_c.cc:36:6: error: expected ')' before 'sizeof'
/test/gnu/gcc/gcc/libstdc++-v3/testsuite/26_numerics/headers/cmath/c99_classific
ation_macros_c.cc:36:6: error: expected ')' before 'sizeof'
/test/gnu/gcc/gcc/libstdc++-v3/testsuite/26_numerics/headers/cmath/c99_classific
ation_macros_c.cc:38:6: error: expected unqualified-id before 'sizeof'
/test/gnu/gcc/gcc/libstdc++-v3/testsuite/26_numerics/headers/cmath/c99_classific
ation_macros_c.cc:38:6: error: expected ')' before 'sizeof'
/test/gnu/gcc/gcc/libstdc++-v3/testsuite/26_numerics/headers/cmath/c99_classific
ation_macros_c.cc:38:6: error: expected ')' before 'sizeof'
/test/gnu/gcc/gcc/libstdc++-v3/testsuite/26_numerics/headers/cmath/c99_classific
ation_macros_c.cc:40:6: error: variable or field 'isgreater' declared void
/test/gnu/gcc/gcc/libstdc++-v3/testsuite/26_numerics/headers/cmath/c99_classific
ation_macro

[Bug libstdc++/43457] New: FAIL: ext/profile/all.cc (test for excess errors)

[danglin at gcc dot gnu dot org]

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.5.0/hppa2.0w-hp-hpux11.11/bin/
-B/opt/gnu/gcc/gcc-4.5.0/hppa2.0
w-hp-hpux11.11/lib/ -isystem
/opt/gnu/gcc/gcc-4.5.0/hppa2.0w-hp-hpux11.11/includ
e -isystem /opt/gnu/gcc/gcc-4.5.0/hppa2.0w-hp-hpux11.11/sys-include
-B/test/gnu/
gcc/objdir/hppa2.0w-hp-hpux11.11/./libstdc++-v3/src/.libs -g -O2
-D_GLIBCXX_ASSE
RT -fmessage-length=0 -g -O2 -g -O2 -DLOCALEDIR="." -nostdinc++
-I/test/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/gnu/gcc/gcc/li
bstdc++-v3/libsupc++ -I/test/gnu/gcc/gcc/libstdc++-v3/include/backward
-I/test/g
nu/gcc/gcc/libstdc++-v3/testsuite/util
/test/gnu/gcc/gcc/libstdc++-v3/testsuite/
ext/profile/all.cc   -std=gnu++0x -O0 -D_GLIBCXX_PROFILE
-D_GLIBCXX_PROFILE_NO_T
HREADS -S  -o all.s(timeout = 600)
In file included from
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/in
clude/profile/impl/profiler_hash_func.h:51:0,
 from
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/in
clude/profile/impl/profiler.h:400,
 from
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/in
clude/profile/base.h:44,
 from
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/in
clude/profile/map.h:38,
 from
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/in
clude/profile/map:38,
 from
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/in
clude/map:69,
 from
/test/gnu/gcc/gcc/libstdc++-v3/testsuite/ext/profile/all.c
c:24:
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/profile/impl/pro
filer_trace.h: In function 'void __gnu_profile::__read_cost_factors()':
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/profile/impl/pro
filer_trace.h:559:62: error: 'setenv' was not declared in this scope
compiler exited with status 1


-- 
   Summary: FAIL: ext/profile/all.cc (test for excess errors)
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: danglin at gcc dot gnu dot org
 GCC build triplet: hppa*-*-hpux*
  GCC host triplet: hppa*-*-hpux*
GCC target triplet: hppa*-*-hpux*


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

[Bug middle-end/40078] passing label to inline asm "i" constraint generates bad code

[mirq-gccboogs at rere dot qmqm dot pl]

--- Comment #3 from mirq-gccboogs at rere dot qmqm dot pl  2010-03-21 01:08 
---
In case you're still interested, there is 'asm goto' coming in gcc 4.5.


-- 


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

[Bug bootstrap/42529] Stage 1 compiler cannot compile

[davek at gcc dot gnu dot org]

--- Comment #9 from davek at gcc dot gnu dot org  2010-03-21 00:04 ---
No activity since the start of the year, no response to request for information
in a month.  Probably was just a glitch; suspending in the absence of any
further information.


-- 

davek at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug c/43456] gcc -O code generation error

[joseph at codesourcery dot com]

--- Comment #11 from joseph at codesourcery dot com  2010-03-20 23:46 
---
Subject: Re:  gcc -O code generation error

I advise referring to
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1252.htm
which is what has been integrated in C1X.


-- 


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

[Bug c/43456] gcc -O code generation error

[pinskia at gcc dot gnu dot org]

--- Comment #10 from pinskia at gcc dot gnu dot org  2010-03-20 23:19 
---
Oh yes the partial vs full order issue.
There is a nice paper about this:
http://www.open-std.org/JTC1/SC22/wg14/www/docs/n926.htm
12.3 is the part which I think explains it all.


-- 


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

[Bug c/43456] gcc -O code generation error

[gccbug at dworkin dot nl]

--- Comment #9 from gccbug at dworkin dot nl  2010-03-20 23:14 ---
Subject: Re:  gcc -O code generation error

> No, we have a | b.  There is an order inside a and b but no order between a 
> and
> b. 

That's depressing.  C99 says in 5.1.2.3:

Evaluation of an expression may produce side effects. At certain
specified points in the execution sequence called sequence points,
all side effects of previous evaluations shall be complete and no
side effects of subsequent evaluations shall have taken place.

I had taken this to mean a full ordering, not a partial one.


-- 


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

[Bug libgcj/40860] [4.4/4.5 regression] regressions in libjava testsuite on arm-linux

[mikpe at it dot uu dot se]

--- Comment #26 from mikpe at it dot uu dot se  2010-03-20 22:36 ---
Created an attachment (id=20147)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20147&action=view)
test program to take a stack trace using _Unwind_ API

I'm attaching a test program which sets up a predictable call chain, and then
uses _Unwind_Backtrace() and _Unwind_GetRegionStart() to get the entry points
of the functions in the call chain into an array. It prints the corresponding
function names and verifies that the function entry points are correct.

With gcc-4.4.3 and binutils-2.19.1 on armv5tel-unknown-linux-gnueabi this works
fine:

> gcc -funwind-tables -fno-unit-at-a-time -O -o stacktrace-2.19.1 stacktrace.c
> ./stacktrace-2.19.1 
bar
f2
main

With the same gcc binary but binutils-20100316 the program fails:

> PATH=/tmp/binutils-2.20.51-install/bin:$PATH gcc -funwind-tables 
> -fno-unit-at-a-time -O stacktrace.c -o stacktrace-2.20.51
> ./stacktrace-2.20.51 
bar
f1
f1
Abort

The reason for the failure is that ld merged the .ARM.exidx entries for f2 and
main with the one for f1, which breaks _Unwind_GetRegionStart(). First we see
that f1, f2, and main are adjacent in memory:

> nm -v stacktrace-2.20.51
...
8588 T tracefn
85bc T bar
865c T f1
866c T f2
867c T main
8698 T __libc_csu_fini
...

With binutils-2.19.1 they each get their own .ARM.exidx entry:

> /tmp/binutils-2.20.51-install/bin/readelf --unwind stacktrace-2.19.1 

Unwind table index '.ARM.exidx' at offset 0x778 contains 7 entries:

0x845c <_start>: 0x1 [cantunwind]

0x8508 : 0x80a8b0b0
  Compact model 0
  0xa8  pop {r4r14}
  0xb0  finish
  0xb0  finish

0x8588 : 0x80aab0b0
  Compact model 0
  0xaa  pop {r4, r5, r6r14}
  0xb0  finish
  0xb0  finish

0x85bc : 0x8003a8b0
  Compact model 0
  0x03  vsp = vsp + 16
  0xa8  pop {r4r14}
  0xb0  finish

0x865c : 0x80a8b0b0
  Compact model 0
  0xa8  pop {r4r14}
  0xb0  finish
  0xb0  finish

0x866c : 0x80a8b0b0
  Compact model 0
  0xa8  pop {r4r14}
  0xb0  finish
  0xb0  finish

0x867c : 0x80a8b0b0
  Compact model 0
  0xa8  pop {r4r14}
  0xb0  finish
  0xb0  finish

But with binutils-20100316 f2 and main don't have their own entries, so PCs in
them are reported as belonging to f1 instead:

> /tmp/binutils-2.20.51-install/bin/readelf --unwind stacktrace-2.20.51 

Unwind table index '.ARM.exidx' at offset 0x778 contains 6 entries:

0x845c <_start>: 0x1 [cantunwind]

0x8508 : 0x80a8b0b0
  Compact model 0
  0xa8  pop {r4r14}
  0xb0  finish
  0xb0  finish

0x8588 : 0x80aab0b0
  Compact model 0
  0xaa  pop {r4, r5, r6r14}
  0xb0  finish
  0xb0  finish

0x85bc : 0x8003a8b0
  Compact model 0
  0x03  vsp = vsp + 16
  0xa8  pop {r4r14}
  0xb0  finish

0x865c : 0x80a8b0b0
  Compact model 0
  0xa8  pop {r4r14}
  0xb0  finish
  0xb0  finish

0x8698 <__libc_csu_fini>: 0x1 [cantunwind]

This test program also works on i686-linux, sparc64-linux -m32/-m64, and
powerpc64-linux -m32.

I understand the benefits of shrinking .ARM.exidx tables, but it does break
parts of gcc's  implementation (and thus libjava), so should be
opt-in via an explicit option and not done by default.


-- 


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

[Bug lto/43455] Compiler hang with -O2 -flto

[marbacz at gmail dot com]

--- Comment #2 from marbacz at gmail dot com  2010-03-20 22:25 ---
Passing -m32 make the hang disappear.

Below is slightly less reduced version of previous test case. It comes from gnu
bc.

It causes ICE. Uncommenting declarations changes ICE into hang. ICE doesn't go
away with -m32.

gcc -O2 -flto numeric.c eval.c 
===
In file included from eval.c:28:0,
 from numeric.c:19,
 from :0:
eval.c: In function 'dc_evalstr':
eval.c:30:10: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
lto-wrapper: /usr/x86_64-pc-linux-gnu/gcc-bin/4.5.0-alpha20100318/gcc returned
1 exit status
collect2: lto-wrapper returned 1 exit status
===

eval.c:

typedef enum {DC_UNINITIALIZED, DC_NUMBER, DC_STRING} dc_value_type;
typedef struct dc_number *dc_num;
typedef struct dc_string *dc_str;
typedef struct {
dc_value_type dc_type;
union { dc_num number; dc_str string; } v;
} dc_data;

const char *progname;

int main()
{
return 0;
}
/*
int dc_func(int a, int b, int c);
void dc_push(dc_data);
dc_data dc_getnum(int a, int b, int c);
*/
static const char *input_str_string;

int
dc_evalstr (dc_data *string)
{
const char *s;
int peekc;
switch (dc_func(0, 0, 0)){
case 0:
input_str_string = s - 1;
dc_push(dc_getnum(0, 0, 0));
s = input_str_string;
if (peekc != -1)
--s;
break;
}
return 0;
}
===

numeric.c 
===
typedef enum {DC_UNINITIALIZED, DC_NUMBER, DC_STRING} dc_value_type;
typedef struct bc_struct *dc_num;
typedef struct dc_string *dc_str;
typedef struct {
dc_value_type dc_type;
union {
dc_num number;
dc_str string;
} v;
} dc_data;

dc_data dc_getnum(int input, int ibase, int readahead)
{
dc_data x;
return x;
}

int dc_func(int a, int b, int c){return 0;}
void dc_push(dc_data a){}


-- 


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

[Bug libgcj/40860] [4.4/4.5 regression] regressions in libjava testsuite on arm-linux

[mikpe at it dot uu dot se]

--- Comment #25 from mikpe at it dot uu dot se  2010-03-20 22:10 ---
(In reply to comment #24)
> This rings a bell and the comment in 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29206#c8
> is probably related. 

I don't think this is at all the same as PR29206. PR29206 is very old now, so I
don't think the one comment about EABI is accurate now, and people have been
using EABI java builds succesfully. The test case given (gcj-dbtool -n) works
for me. If anything, I suspect that maybe the ARM unwinder loops at end of
stack bug is at play; for java at least there's a patch in Debian to work
around that (I use it in my toolchain too).


-- 


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

[Bug c/43456] gcc -O code generation error

[pinskia at gcc dot gnu dot org]

--- Comment #8 from pinskia at gcc dot gnu dot org  2010-03-20 21:54 ---
(In reply to comment #7)
> Subject: Re:  gcc -O code generation error
> 
> To clarify even further, we have
> 
> (..., (f->sp++)->u.number [SEQUENCE POINT] ? 1 : 0) |
> (..., (f->sp++)->u.number [SEQUENCE POINT] ? 4 : 0)
> 
> So the modifications of f->sp are before the sequence point.  If
> gcc -W -Wall warns about this part of the expression, that warning is
> wrong, as well.

No, we have a | b.  There is an order inside a and b but no order between a and
b. 


-- 


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

[Bug c/43456] gcc -O code generation error

[gccbug at dworkin dot nl]

--- Comment #7 from gccbug at dworkin dot nl  2010-03-20 21:51 ---
Subject: Re:  gcc -O code generation error

To clarify even further, we have

(..., (f->sp++)->u.number [SEQUENCE POINT] ? 1 : 0) |
(..., (f->sp++)->u.number [SEQUENCE POINT] ? 4 : 0)

So the modifications of f->sp are before the sequence point.  If
gcc -W -Wall warns about this part of the expression, that warning is
wrong, as well.

Regards,
Felix Croes


-- 


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

[Bug c/43456] gcc -O code generation error

[pinskia at gcc dot gnu dot org]

--- Comment #6 from pinskia at gcc dot gnu dot org  2010-03-20 21:18 ---
Just to clarify we have:
((i_push_value(f, (f->fp - 1)),
(--f->sp)->type = 0x01, f->sp->u.number = ((Int) 0x1L), i_index(f),
(--f->sp)->type = 0x01, f->sp->u.number = ((Int) 0x8L), kf_and(f),

(f->sp++)->u.number) ? ((Int) 0x1L) : ((Int) 0x0L))

Followed by:
(((--f->sp)->type = 0x01, f->sp->u.number = ivar10, (f->argp + 3)->u.number =
ivar3, i_funcall(f, (object *) ((void *)0), (array *) ((void *)0), 0, 5 , 1),
(f->sp++)->u.number) ? ((Int) 0x4L) : ((Int) 0x0L))

And those are combined with a | so we don't have a sequence point between those
expressions so the warning is correct and GCC is correct for -O0 and -O1
because of the missing sequence point.


-- 


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

[Bug c/43456] gcc -O code generation error

[pinskia at gcc dot gnu dot org]

--- Comment #5 from pinskia at gcc dot gnu dot org  2010-03-20 21:16 ---
I cannot follow the () correctly.  There is no sequence point here because it
is a | separating the modifications of f->sp.  So this is not a bug in GCC but
a bug in your code.


-- 

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=43456

[Bug c/43456] gcc -O code generation error

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2010-03-20 21:01 ---
Seems to be the simple-minded CSE that gimplification performs, of f->sp.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||wrong-code
  Known to fail||4.5.0


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

[Bug c/43456] gcc -O code generation error

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2010-03-20 20:59 ---
>There's a sequence point after evaluating the first operand.

With -W -Wall, I get:
t.c:79:58: warning: operation on ‘f->sp’ may be undefined

Looks like that is the issue.
So there might be still an missing sequence point.  I am going to reformat that
line to see if there is one missing.


-- 


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

[Bug c/43456] gcc -O code generation error

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2010-03-20 20:53 ---
(In reply to comment #1)
> (f->sp++)->u.number) ? ((Int) 0x1L) : ((Int) 0x0L)) | (((--f->sp)->type = 
> 0x01,
> f->sp->u.number = ivar10,
> (f->argp + 3)->u.number = ivar3,
> i_funcall(f, (object *) ((void *)0), (array *) ((void *)0), 0, 5 , 1),
> (f->sp++)->u.number) ? ((Int) 0x4L) : ((Int) 0x0L;
> 
> 
> I almost want to say there is no sequence point between the modifications of
> f->sp in the above code. I cannot remember the rules for ?: and sequence 
> points
> right now.  If there is none, then this code is undefined and the bug is
> invalid.  Otherwise we are missing that point of the sequence point.

There's a sequence point after evaluating the first operand.


-- 


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

[Bug c/43456] gcc -O code generation error

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2010-03-20 20:40 ---
(f->sp++)->u.number) ? ((Int) 0x1L) : ((Int) 0x0L)) | (((--f->sp)->type = 0x01,
f->sp->u.number = ivar10,
(f->argp + 3)->u.number = ivar3,
i_funcall(f, (object *) ((void *)0), (array *) ((void *)0), 0, 5 , 1),
(f->sp++)->u.number) ? ((Int) 0x4L) : ((Int) 0x0L;


I almost want to say there is no sequence point between the modifications of
f->sp in the above code. I cannot remember the rules for ?: and sequence points
right now.  If there is none, then this code is undefined and the bug is
invalid.  Otherwise we are missing that point of the sequence point.


-- 


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

[Bug java/42811] [4.5 regression] java.lang.ExceptionInInitializerError in ecj1

[davek at gcc dot gnu dot org]

--- Comment #9 from davek at gcc dot gnu dot org  2010-03-20 20:33 ---
Right you are.  I'll just have to hope it gets approved quickly while those
remaining P1s gradually tick away... :)


-- 


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

[Bug c/43456] New: gcc -O code generation error

[gccbug at dworkin dot nl]

gcc configuration:

Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.4.3-3ubuntu3'
--with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--enable-multiarch --enable-linker-build-id --with-system-zlib
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls
--enable-clocale=gnu --enable-libstdcxx-debug --enable-plugin --enable-objc-gc
--enable-targets=all --disable-werror --with-arch-32=i486 --with-tune=generic
--enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu
--target=i486-linux-gnu
Thread model: posix
gcc version 4.4.3 (Ubuntu 4.4.3-3ubuntu3) 

The bug occurs with all gcc 4.x versions I tried (4.0.1 on OS X, 4.2.1 on OS X,
4.3.3 on OpenSolaris,
4.4.1 on Ubuntu 9.10) but NOT with gcc 3.4.3 on Solaris 10. I have reproduced
it on i386 and PPC platforms.

To reproduce, compile the code below.  The bug occurs in generating the code
for foo(). Without -O, the begin and end values are identical; with -O, they
are not.  I'm sorry if the code is a bit hard to read, it was compiled to C
from a different language.

Regards,
Felix Croes


# include 

typedef int Int;
typedef unsigned int Uint;

typedef char bool;
typedef struct _string_ string;
typedef struct _array_ array;
typedef struct _object_ object;
typedef struct _value_ value;
typedef struct _control_ control;
typedef struct _dataplane_ dataplane;
typedef struct _dataspace_ dataspace;
typedef struct _frame_ frame;
typedef unsigned short uindex;
typedef uindex sector;
typedef unsigned short ssizet;
typedef char eindex;

typedef struct _rlinfo_ {
Int maxdepth;
Int ticks;
bool nodepth;
bool noticks;
struct _rlinfo_ *next;
} rlinfo;
struct _frame_ {
frame *prev;
uindex oindex;
array *lwobj;
control *ctrl;
dataspace *data;
control *p_ctrl;
unsigned short p_index;
unsigned short nargs;
bool external;
bool sos;
uindex foffset;
struct _dfuncdef_ *func;
char *prog;
char *pc;
value *stack;
value *sp;
value *lip;
value *argp;
value *fp;
Int depth;
rlinfo *rlim;
Int level;
bool atomic;
};
struct _value_ {
char type;
bool modified;
uindex oindex;
union {
 Int number;
 Uint objcnt;
 string *string;
 array *array;
 value *lval;
} u;
};

extern void i_push_value (frame*, value*);
extern void i_index (frame*);
extern void i_funcall (frame*, object*, array*, int, int, int);

void foo(f)
register frame *f;
{
register Int ivar3 = 0;
register Int ivar10 = 1;
register Int ivar11 = 2;

(ivar11 |= (((i_push_value(f, (f->fp - 1)),
(--f->sp)->type = 0x01, f->sp->u.number = ((Int) 0x1L), i_index(f),
(--f->sp)->type = 0x01, f->sp->u.number = ((Int) 0x8L), kf_and(f),
(f->sp++)->u.number) ? ((Int) 0x1L) : ((Int) 0x0L)) | (((--f->sp)->type = 0x01,
f->sp->u.number = ivar10,
(f->argp + 3)->u.number = ivar3,
i_funcall(f, (object *) ((void *)0), (array *) ((void *)0), 0, 5 , 1),
(f->sp++)->u.number) ? ((Int) 0x4L) : ((Int) 0x0L;
}

void i_push_value(f, v)
frame *f;
value *v;
{
--f->sp;
}

void i_index(f)
frame *f;
{
f->sp++;
}

int kf_and(f)
frame *f;
{
f->sp++;
}

void i_funcall(f, obj, arr, a, b, c)
frame *f;
object *obj;
array *arr;
int a, b, c;
{
}

main()
{
frame f;
value stack[100];

f.sp = f.argp = stack + 50;
printf("begin %08x\n", f.sp);
foo(&f);
printf("end %08x\n", f.sp);
}


-- 
   Summary: gcc -O code generation error
   Product: gcc
   Version: 4.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gccbug at dworkin dot nl
 GCC build triplet: Linux ubuntu 2.6.32-16-generic #25-Ubuntu SMP Tue Mar 9
16:33:52
  GCC host triplet: Linux ubuntu 2.6.32-16-generic #25-Ubuntu SMP Tue Mar 9
16:33:52
GCC target triplet: Linux ubuntu 2.6.32-16-generic #25-Ubuntu SMP Tue Mar 9
16:33:52


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

[Bug java/42811] [4.5 regression] java.lang.ExceptionInInitializerError in ecj1

[rguenth at gcc dot gnu dot org]

--- Comment #8 from rguenth at gcc dot gnu dot org  2010-03-20 20:21 ---
Java is not release critical.  If it doesn't make 4.5.0 it can easily make
4.5.1.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P4


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

[Bug fortran/43210] Initializer of huge static arrays should be improved

[jvdelisle at gcc dot gnu dot org]

--- Comment #2 from jvdelisle at gcc dot gnu dot org  2010-03-20 20:19 
---
See fortran-exp branch where we are working these issues.  Once the splay-tree
structure is in place we can then focus on setting a limit and not "simplify"
the constructor.


-- 


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

[Bug lto/43455] Compiler hang with -O2 -flto

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2010-03-20 20:15 ---
Works for me on i?86-linux.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu dot
   ||org
   Keywords||lto


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

[Bug java/42811] [4.5 regression] java.lang.ExceptionInInitializerError in ecj1

[davek at gcc dot gnu dot org]

--- Comment #7 from davek at gcc dot gnu dot org  2010-03-20 20:02 ---
Raising priority P4 -> P3 and Cc'ing RM.

I didn't want to ask to block the release for a bug in a long-neglected
language on a secondary target before I was sure I'd be able to come up with a
fix in time, but now that I have a good fix that has been tested, addresses all
the comments raised in initial reviews, accepted upstream in the relevant
parts, and is just waiting approval, I'd like to make sure it goes in before
you branch; I see we're down to about half-a-dozen P1s now.

Final version of the patch posted at:

http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00931.html


-- 

davek at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu dot
   ||org
   Priority|P4  |P3


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

[Bug libstdc++/24196] Using string instances to pass arguments to dlls fails

[davek at gcc dot gnu dot org]

--- Comment #25 from davek at gcc dot gnu dot org  2010-03-20 19:46 ---
This was fixed on 2009-11-30 by r.154853, which enabled libstdc++ as a DLL on
windows platforms.


-- 

davek at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug middle-end/38696] gcc.dg/torture/pr37868.c wrong code at -O2 and above for 4.3 and trunk / bit packing

[ramana at gcc dot gnu dot org]

--- Comment #7 from ramana at gcc dot gnu dot org  2010-03-20 19:33 ---
As per the last comment.


-- 

ramana at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||WONTFIX


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

[Bug target/40697] inefficient code to extract least bits from an integer value

[ramana at gcc dot gnu dot org]

--- Comment #6 from ramana at gcc dot gnu dot org  2010-03-20 19:32 ---
Now Fixed . Yay. 


-- 

ramana at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
   Keywords||missed-optimization
  Known to fail||4.5.0
 Resolution||FIXED
   Target Milestone|--- |4.5.0


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

[Bug rtl-optimization/40615] unnecessary CSE

[ramana at gcc dot gnu dot org]

-- 

ramana at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |enhancement


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

[Bug target/40603] unnecessary conversion from unsigned byte load to signed byte load

[ramana at gcc dot gnu dot org]

-- 

ramana at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |enhancement
   Keywords||missed-optimization


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

[Bug target/40523] GCC generates invalid instructions when building for Thumb-2 on armel

[ramana at gcc dot gnu dot org]

-- 

ramana at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||wrong-code
   Target Milestone|--- |4.3.5


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

[Bug target/40499] [missed optimization] branch to return not threaded on thumb

[ramana at gcc dot gnu dot org]

-- 

ramana at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |enhancement
   Keywords||missed-optimization
  Known to fail||4.5.0


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

[Bug rtl-optimization/40314] inefficient address calculation of fields of large struct

[ramana at gcc dot gnu dot org]

-- 

ramana at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |enhancement
   Keywords||missed-optimization
  Known to fail||4.5.0


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

[Bug middle-end/38696] gcc.dg/torture/pr37868.c wrong code at -O2 and above for 4.3 and trunk / bit packing

[laurent at guerby dot net]

--- Comment #6 from laurent at guerby dot net  2010-03-20 19:26 ---
I haven't built 4.3 in a while, if this is fixed in 4.4 and 4.5 it's good
enough for me so feel free to close as WONTFIX for 4.3.


-- 


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

[Bug target/39244] Various cleanup tests fail

[ramana at gcc dot gnu dot org]

--- Comment #4 from ramana at gcc dot gnu dot org  2010-03-20 19:22 ---
Ah - hang on a minute . What binutils are you building with ? Can you try with
a more recent binutils ? 

cheers
Ramana


-- 


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

[Bug middle-end/38696] gcc.dg/torture/pr37868.c wrong code at -O2 and above for 4.3 and trunk / bit packing

[ramana at gcc dot gnu dot org]

--- Comment #5 from ramana at gcc dot gnu dot org  2010-03-20 19:16 ---
Laurent,

Is this still a problem on 4.3 branch ? 

Ramana


-- 


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

[Bug lto/43455] New: Compiler hang with -O2 -flto

[marbacz at gmail dot com]

gcc -O2 -flto 1.c 2.c hangs.
-O1 or without -flto compiles and links just fine.

1.c:
struct bar {int x;};
extern struct bar foo(void);
int main()
{
struct bar x=foo();
return 0;
}

2.c:
typedef struct{int x;} bar;
bar foo (void)
{
bar x;
return x;
}

gcc -v:
Using built-in specs.
COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/4.5.0-alpha20100318/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.5.0-alpha20100318/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-4.5.0_alpha20100318/work/gcc-4.5-20100318/configure
--prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.5.0-alpha20100318
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.0-alpha20100318/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.5.0-alpha20100318
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.5.0-alpha20100318/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.5.0-alpha20100318/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.0-alpha20100318/include/g++-v4
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec
--disable-fixed-point --with-ppl --with-cloog --enable-nls
--without-included-gettext --with-system-zlib --disable-checking
--disable-werror --enable-secureplt --enable-multilib --enable-libmudflap
--disable-libssp --enable-libgomp --enable-cld
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.5.0-alpha20100318/python
--disable-libgcj --enable-languages=c,c++ --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
--with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo
4.5.0_alpha20100318' --enable-lto
Thread model: posix
gcc version 4.5.0-alpha20100318 20100318 (experimental) (Gentoo
4.5.0_alpha20100318)


-- 
   Summary: Compiler hang with -O2 -flto
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: marbacz at gmail dot com


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

[Bug libgcj/35552] GCJ ARM compiled programs give segmentation fault

[ramana at gcc dot gnu dot org]

--- Comment #3 from ramana at gcc dot gnu dot org  2010-03-20 19:02 ---
(In reply to comment #2)
> Could this be a problem with boehm-gc ?
> 

It's hard to say if this is a problem with Boehm GC or not . The OP hasn't
given any more information and nor has he given a testcase to look at .

No feedback in over 6 months . Hence WONTFIX.


-- 

ramana at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||WONTFIX


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

[Bug libgcj/40860] [4.4/4.5 regression] regressions in libjava testsuite on arm-linux

[ramana at gcc dot gnu dot org]

--- Comment #24 from ramana at gcc dot gnu dot org  2010-03-20 18:54 ---

This rings a bell and the comment in 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29206#c8
is probably related. 

If so, this is essentially a dup of PR29206 and I'm not sure what more we can
do with this.

cheers
Ramana


-- 


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

[Bug target/40722] [4.5 Regression] ia32intrin.h defines of _rotl, _rotr conflict with target stdlib.h decls

[hjl dot tools at gmail dot com]

--- Comment #7 from hjl dot tools at gmail dot com  2010-03-20 18:09 ---
An updated patch is at

http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00937.html


-- 


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

[Bug c++/43081] [4.3/4.4 regression] ICE with invalid in-class initializer

[simartin at gcc dot gnu dot org]

--- Comment #6 from simartin at gcc dot gnu dot org  2010-03-20 18:04 
---
Fixed in 4.5 (I've merged the two test cases into one, and have improved it
with parts from Michael's)


-- 

simartin at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to fail|4.0.4 4.4.1 4.5.0   |4.0.4 4.4.1
  Known to work|3.4.6   |3.4.6 4.5.0
   Last reconfirmed|2010-03-19 16:18:21 |2010-03-20 18:04:25
   date||
Summary|[4.3/4.4/4.5 regression] ICE|[4.3/4.4 regression] ICE
   |with invalid in-class   |with invalid in-class
   |initializer |initializer


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

[Bug target/40722] [4.5 Regression] ia32intrin.h defines of _rotl, _rotr conflict with target stdlib.h decls

[hjl dot tools at gmail dot com]

--- Comment #6 from hjl dot tools at gmail dot com  2010-03-20 18:01 ---
A patch is posted at

http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00936.html


-- 


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

[Bug c++/43081] [4.3/4.4/4.5 regression] ICE with invalid in-class initializer

[simartin at gcc dot gnu dot org]

--- Comment #5 from simartin at gcc dot gnu dot org  2010-03-20 18:01 
---
Subject: Bug 43081

Author: simartin
Date: Sat Mar 20 18:01:18 2010
New Revision: 157597

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

2010-03-20  Simon Martin  

PR c++/43081:
* decl2.c (grokfield): Handle invalid initializers for member
functions.

gcc/testsuite/

2010-03-20  Simon Martin  
Michael Matz  

PR c++/43081
* g++.dg/parse/crash56.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/parse/crash56.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl2.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug target/43156] [4.5 Regression] SPU-elf ICEs on simple programs

[pinskia at gcc dot gnu dot org]

--- Comment #8 from pinskia at gcc dot gnu dot org  2010-03-20 17:46 ---
Subject: Bug 43156

Author: pinskia
Date: Sat Mar 20 17:45:37 2010
New Revision: 157596

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157596
Log:
2010-03-20  Andrew Pinski  

PR target/43156
* config/spu/spu.c (spu_expand_prologue): Don't emit NOTE_INSN_DELETED
at the begining or end.
(spu_expand_epilogue): Likewise.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/spu/spu.c


-- 


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

[Bug target/43156] [4.5 Regression] SPU-elf ICEs on simple programs

[pinskia at gcc dot gnu dot org]

--- Comment #7 from pinskia at gcc dot gnu dot org  2010-03-20 17:45 ---
Fixed.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug fortran/43078] gfortran: spurious warning of line truncation at col 72

[jvdelisle at gcc dot gnu dot org]

--- Comment #9 from jvdelisle at gcc dot gnu dot org  2010-03-20 17:34 
---
Closing, this was fixed some time ago.


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug c++/43081] [4.3/4.4/4.5 regression] ICE with invalid in-class initializer

[matz at gcc dot gnu dot org]

--- Comment #4 from matz at gcc dot gnu dot org  2010-03-20 17:00 ---
But Simons patch was accepted.  Simon: can you simply combine the two
testcases into one?  No need to artificially lengthen the time for make check.


-- 

matz at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||matz at gcc dot gnu dot org
 AssignedTo|matz at gcc dot gnu dot org |simartin at gcc dot gnu dot
   ||org


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

[Bug fortran/43450] -fwhole-file: ICE in gfc_create_module_variable, at fortran/trans-decl.c:3386

[pault at gcc dot gnu dot org]

--- Comment #3 from pault at gcc dot gnu dot org  2010-03-20 16:02 ---
Fixed on trunk

Thanks for the report.

Paul


-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug fortran/43450] -fwhole-file: ICE in gfc_create_module_variable, at fortran/trans-decl.c:3386

[pault at gcc dot gnu dot org]

--- Comment #2 from pault at gcc dot gnu dot org  2010-03-20 16:01 ---
Subject: Bug 43450

Author: pault
Date: Sat Mar 20 16:01:17 2010
New Revision: 157595

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157595
Log:
2010-03-20  Paul Thomas  

PR fortran/43450
* trans-decl.c (gfc_create_module_variable): With -fwhole-file
do not assert the context of derived types.

2010-03-20  Paul Thomas  

PR fortran/43450
* gfortran.dg/whole_file_15.f90 : New test.

Added:
trunk/gcc/testsuite/gfortran.dg/whole_file_15.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-decl.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug debug/43442] .debug_loc is unnecessarily large

[jakub at gcc dot gnu dot org]

--- Comment #5 from jakub at gcc dot gnu dot org  2010-03-20 15:33 ---
That hoisting/sinking is usually marked with that BLOCK from which it has been
sunk or hoisted.  And even if not, no debug info consumer I'm aware of will
tell you anything about the variables that are not in the scope of the current
instructions.  It will simply tell you the variable doesn't exist, or, if there
is a variable with different name in outer or global scope, that variable.


-- 


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

[Bug middle-end/43390] [4.5 Regression] ICE: integral result type precision does not match field size of BIT_FIELD_REF

[rguenth at gcc dot gnu dot org]

--- Comment #6 from rguenth at gcc dot gnu dot org  2010-03-20 15:20 ---
Well.  I'll just implement that given the silence.


-- 

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|2010-03-16 14:57:28 |2010-03-20 15:20:35
   date||


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

[Bug middle-end/40106] [4.4/4.5 Regression] Weird interaction between optimize_insn_for_speed_p and -funsafe-math-optimizations

[rguenth at gcc dot gnu dot org]

--- Comment #55 from rguenth at gcc dot gnu dot org  2010-03-20 15:12 
---
(In reply to comment #54)
> (In reply to comment #53)
> > > optimize_function_for_size_p (cfun) is true if attribute(cold) is set
> > > on it or we are optimizing for size.
> > 
> > It is what is presently implemented. As a consequence (illustrated by this 
> > pr),
> > optimize for speed is not obeyed if attribute(cold) is set on. I don't see 
> > the
> > interest of that: If I want optimization for speed, I just want it.
> > 
> > From comment #47, I got the impression that the intended behavior is the
> > following:
> > if optimized for size is on (-Os) then it is overridden if the block is 
> > marked
> > as "hot" (it is not clear for me that it is !attribute(cold)). From this
> > impression the truth table I expect is the following for
> > optimize_function_for_size_p:
> > 
> > "hot"0  1
> > -Os 1  0
> > -O[1-3]  0 0
> > 
> > and not
> > 
> > "cold"   01
> > -Os  11
> > -O[1-3]  01
> > 
> > as presently implemented.
> 
> The intent is
> 
>"hot" "cold" nothing
>   -Os0  1 1
>   -O[1-3]0  1 0
> 
> implemented is as far as I see
> 
>"hot" "cold" nothing
>   -Os1  1 1
>   -O[1-3]0  1 0
> 
> thus optimize_function_for_{size,speed}_p fully correct for -O[1-3].

The issue is the || !crtl->maybe_hot_insn_p in optimize_insn_for_size_p
which boils down to !maybe_hot_frequency_p (bb->freq) which has at the
end

  if (freq < BB_FREQ_MAX / PARAM_VALUE (HOT_BB_FREQUENCY_FRACTION))
return false;
  return true;

thus it really only tells if a frequency is hot or not, its negation
doesn't autmatically means its frequency is cold.

Thus, maybe_hot_bb_p should properly honor [!]optimize_size for the
default case where a bb is neither hot nor cold.

In the end this won't save us from the underlying issue in this PR
where frequency scaling makes blocks appear as cold when they are not,
simply due to the loop depth predictors (they should maybe be limited
to a loop depth of 3 or so).  And this is really Honza's area of
expertise (well, at least its all his code).


-- 


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

[Bug middle-end/40106] [4.4/4.5 Regression] Weird interaction between optimize_insn_for_speed_p and -funsafe-math-optimizations

[rguenth at gcc dot gnu dot org]

--- Comment #54 from rguenth at gcc dot gnu dot org  2010-03-20 14:59 
---
(In reply to comment #53)
> > optimize_function_for_size_p (cfun) is true if attribute(cold) is set
> > on it or we are optimizing for size.
> 
> It is what is presently implemented. As a consequence (illustrated by this 
> pr),
> optimize for speed is not obeyed if attribute(cold) is set on. I don't see the
> interest of that: If I want optimization for speed, I just want it.
> 
> From comment #47, I got the impression that the intended behavior is the
> following:
> if optimized for size is on (-Os) then it is overridden if the block is marked
> as "hot" (it is not clear for me that it is !attribute(cold)). From this
> impression the truth table I expect is the following for
> optimize_function_for_size_p:
> 
> "hot"0  1
> -Os 1  0
> -O[1-3]  0 0
> 
> and not
> 
> "cold"   01
> -Os  11
> -O[1-3]  01
> 
> as presently implemented.

The intent is

   "hot" "cold" nothing
  -Os0  1 1
  -O[1-3]0  1 0

implemented is as far as I see

   "hot" "cold" nothing
  -Os1  1 1
  -O[1-3]0  1 0

thus optimize_function_for_{size,speed}_p fully correct for -O[1-3].


-- 


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

[Bug target/43118] vld4 and vst4 intrinsics are not handled correctly

[ramana at gcc dot gnu dot org]

-- 

ramana at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |enhancement
   Keywords||missed-optimization


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

[Bug fortran/43409] I/O: INQUIRE for SIZE does not work.

[jvdelisle at gcc dot gnu dot org]

--- Comment #8 from jvdelisle at gcc dot gnu dot org  2010-03-20 14:42 
---
Subject: Bug 43409

Author: jvdelisle
Date: Sat Mar 20 14:42:04 2010
New Revision: 157594

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157594
Log:
2010-03-20  Jerry DeLisle  

PR fortran/43409
* gfortran.dg/inquire_size.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/inquire_size.f90
Modified:
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug middle-end/40106] [4.4/4.5 Regression] Weird interaction between optimize_insn_for_speed_p and -funsafe-math-optimizations

[dominiq at lps dot ens dot fr]

--- Comment #53 from dominiq at lps dot ens dot fr  2010-03-20 14:40 ---
> optimize_function_for_size_p (cfun) is true if attribute(cold) is set
> on it or we are optimizing for size.

It is what is presently implemented. As a consequence (illustrated by this pr),
optimize for speed is not obeyed if attribute(cold) is set on. I don't see the
interest of that: If I want optimization for speed, I just want it.

>From comment #47, I got the impression that the intended behavior is the
following:
if optimized for size is on (-Os) then it is overridden if the block is marked
as "hot" (it is not clear for me that it is !attribute(cold)). From this
impression the truth table I expect is the following for
optimize_function_for_size_p:

"hot"0  1
-Os 1  0
-O[1-3]  0 0

and not

"cold"   01
-Os  11
-O[1-3]  01

as presently implemented.


-- 


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

[Bug fortran/43409] I/O: INQUIRE for SIZE does not work.

[jvdelisle at gcc dot gnu dot org]

--- Comment #7 from jvdelisle at gcc dot gnu dot org  2010-03-20 14:39 
---
Subject: Bug 43409

Author: jvdelisle
Date: Sat Mar 20 14:39:00 2010
New Revision: 157593

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157593
Log:
2010-03-20  Jerry DeLisle  

PR fortran/43409
* ioparm.def: Change inquire size variable to type pointer to
GFC_IO_INT type.

2010-03-20  Jerry DeLisle  

PR fortran/43409
* io/unix.h: Add prototype for new function to return file size.
* io/unix.c (file_size): New function.
* io/inquire.c (inquire_via_unit): Use new function.
(inquire_via_filename): Use new function.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/ioparm.def
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/inquire.c
trunk/libgfortran/io/unix.c
trunk/libgfortran/io/unix.h


-- 


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

[Bug target/40722] [4.5 Regression] ia32intrin.h defines of _rotl, _rotr conflict with target stdlib.h decls

[hjl dot tools at gmail dot com]

--- Comment #5 from hjl dot tools at gmail dot com  2010-03-20 14:34 ---
I saw

_CRTIMP unsigned int __cdecl __MINGW_NOTHROW _rotl(unsigned int, int)
__MINGW_ATTRIB_CONST;
_CRTIMP unsigned int __cdecl __MINGW_NOTHROW _rotr(unsigned int, int)
__MINGW_ATTRIB_CONST;
_CRTIMP unsigned long __cdecl __MINGW_NOTHROW _lrotl(unsigned long, int)
__MINGW_ATTRIB_CONST;
_CRTIMP unsigned long __cdecl __MINGW_NOTHROW _lrotr(unsigned long, int)
__MINGW_ATTRIB_CONST;

There is no easy way to check it. I think they should be fixed by
fixinclude.


-- 


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

[Bug middle-end/40106] [4.4/4.5 Regression] Weird interaction between optimize_insn_for_speed_p and -funsafe-math-optimizations

[rguenther at suse dot de]

--- Comment #52 from rguenther at suse dot de  2010-03-20 14:19 ---
Subject: Re:  [4.4/4.5 Regression] Weird interaction
 between optimize_insn_for_speed_p and -funsafe-math-optimizations

On Sat, 20 Mar 2010, dominiq at lps dot ens dot fr wrote:

> --- Comment #51 from dominiq at lps dot ens dot fr  2010-03-20 13:21 
> ---
> The following patch fixes this pr:
> 
> --- ../_clean/gcc/predict.c 2009-11-25 18:20:33.0 +0100
> +++ gcc/predict.c   2010-03-20 14:03:33.0 +0100
> @@ -251,7 +251,7 @@ optimize_edge_for_speed_p (edge e)
>  bool
>  optimize_insn_for_size_p (void)
>  {
> -  return optimize_function_for_size_p (cfun) || !crtl->maybe_hot_insn_p;
> +  return optimize_function_for_size_p (cfun) && !crtl->maybe_hot_insn_p;
>  }
> 
>  /* Return TRUE when BB should be optimized for speed.  */
> 
> If the optimize_*_p procs are intended to allow optimization for speed with 
> -Os
> and "hot" part of codes, it seems that the logic of the implementation should
> be checked carefully.

optimize_function_for_size_p (cfun) is true if attribute(cold) is set
on it or we are optimizing for size.

The only issue that exists with the predicates is that they are
implemented symmetrically (optimize_*_for_speed_p is 
!optimize_*_for_size_p) but the low-level implementations check
for extremes like FUNCTION_FREQUENCY_UNLIKELY_EXECUTED where
negation would be FUNCTION_FREQUENCY_HOT, not
FUNCTION_FREQUENCY_HOT || FUNCTION_FREQUENCY_NORMAL.

Thus, for example optimize_function_for_size_p would better read

  if (fun && fun->function_frequency == 
FUNCTION_FREQUENCY_UNLIKELY_EXECUTED)
   return true;
 else if (fun && fun->function_frequency == FUNCTION_FREQUENCY_HOT)
   return false
 return optimize_size;

thus optimize_size should be the default that applies when the
(guessed) profile doesn't give a strong hint.

Likewise optimize_bb_for_size_p needs to disregard the case where
optimize_function_for_size_p returns optimize_size and only then
ask maybe_hot_bb_p.  Thus there should be low-level fns that
return a tri-state, true, false and "default".

But that's all too much change for 4.5.  Eventually you can
play with adjusting just optimize_function_for_size_p as indicated
above.

Richard.


-- 


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

[Bug fortran/43450] -fwhole-file: ICE in gfc_create_module_variable, at fortran/trans-decl.c:3386

[pault at gcc dot gnu dot org]

--- Comment #1 from pault at gcc dot gnu dot org  2010-03-20 14:06 ---
Created an attachment (id=20146)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20146&action=view)
A fix for the PR

This bootstraps and regtests on FC9/x86_64

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|UNCONFIRMED |ASSIGNED


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

[Bug debug/43442] .debug_loc is unnecessarily large

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2010-03-20 14:04 ---
But we can end up hoisting/sinking scalar code outside of the lexical block
of variable uses.  I think a better approach would be to limit the locations
to regions that overlap lexical block + life range.


-- 


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

[Bug target/41074] Invalid code generation on ARM when using '-fno-omit-frame-pointer' option

[siarhei dot siamashka at gmail dot com]

--- Comment #7 from siarhei dot siamashka at gmail dot com  2010-03-20 
13:58 ---
Resolved, as now it WORKSFORME.


-- 

siarhei dot siamashka at gmail dot com changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||WORKSFORME


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

[Bug target/41074] Invalid code generation on ARM when using '-fno-omit-frame-pointer' option

[siarhei dot siamashka at gmail dot com]

--- Comment #6 from siarhei dot siamashka at gmail dot com  2010-03-20 
13:55 ---
The crash disappeared when recompiling libXft-2.1.13 library with gcc 4.4.3.
Either it was fixed, or something else changed and it is not getting triggered
anymore. I guess this bug can be closed.


-- 


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

[Bug rtl-optimization/43438] [4.3/4.4 Regression] possible wrong code bug

[rguenth at gcc dot gnu dot org]

--- Comment #9 from rguenth at gcc dot gnu dot org  2010-03-20 13:44 ---
Fixed for 4.5 sofar.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to fail|4.3.4 4.4.3 4.5.0   |4.3.4 4.4.3
  Known to work|4.1.2   |4.1.2 4.5.0
Summary|[4.3/4.4/4.5 Regression]|[4.3/4.4 Regression]
   |possible wrong code bug |possible wrong code bug


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

[Bug rtl-optimization/43438] [4.3/4.4/4.5 Regression] possible wrong code bug

[rguenth at gcc dot gnu dot org]

--- Comment #8 from rguenth at gcc dot gnu dot org  2010-03-20 13:44 ---
Subject: Bug 43438

Author: rguenth
Date: Sat Mar 20 13:44:18 2010
New Revision: 157592

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157592
Log:
2010-03-20  Richard Guenther  

PR rtl-optimization/43438
* combine.c (make_extraction): Properly zero-/sign-extend an
extraction of the low part of a CONST_INT.  Also handle
CONST_DOUBLE.

* gcc.c-torture/execute/pr43438.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr43438.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/combine.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/43454] warning with -Wall despite __attribute__ ((__unused__))

[bruno at clisp dot org]

--- Comment #1 from bruno at clisp dot org  2010-03-20 13:39 ---
Created an attachment (id=20145)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20145&action=view)
test case


-- 


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

[Bug c++/43454] New: warning with -Wall despite __attribute__ ((__unused__))

[bruno at clisp dot org]

The attached program gives a warning about 'check_moo' being unused,
despite the variable being declared with __attribute__ ((__unused__)).

= bug.cc ==
extern "C" int c_foo (void);
namespace gnulib { static int (*foo) (void) = ::c_foo; }
static int (* __attribute__ ((__unused__)) check_foo) (void) = gnulib::foo;

extern "C" int c_moo (void);
namespace gnulib { static int (*const moo) (void) = ::c_moo; }
static int (* __attribute__ ((__unused__)) check_moo) (void) = gnulib::moo;
===
$ g++ -Wall -S bug.cc
bug.cc:7: warning: 'check_moo' defined but not used

The warning is present in all g++ version of 3.x and 4.x that I tested,
except in g++ 4.0.2. I.e. "Known to work" = 4.0.2, "Known to fail" =
4.0.4, 4.1.2, 4.2.4, 4.3.4, 4.4.3.

The only difference between check_foo (which does not elicit a warning)
and check_moo is the 'const'ness of the initializer.


-- 
   Summary: warning with -Wall despite __attribute__ ((__unused__))
   Product: gcc
   Version: 4.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bruno at clisp dot org
 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=43454

[Bug middle-end/40106] [4.4/4.5 Regression] Weird interaction between optimize_insn_for_speed_p and -funsafe-math-optimizations

[dominiq at lps dot ens dot fr]

--- Comment #51 from dominiq at lps dot ens dot fr  2010-03-20 13:21 ---
The following patch fixes this pr:

--- ../_clean/gcc/predict.c 2009-11-25 18:20:33.0 +0100
+++ gcc/predict.c   2010-03-20 14:03:33.0 +0100
@@ -251,7 +251,7 @@ optimize_edge_for_speed_p (edge e)
 bool
 optimize_insn_for_size_p (void)
 {
-  return optimize_function_for_size_p (cfun) || !crtl->maybe_hot_insn_p;
+  return optimize_function_for_size_p (cfun) && !crtl->maybe_hot_insn_p;
 }

 /* Return TRUE when BB should be optimized for speed.  */

If the optimize_*_p procs are intended to allow optimization for speed with -Os
and "hot" part of codes, it seems that the logic of the implementation should
be checked carefully.


-- 


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

[Bug target/42536] [4.4/4.5 regression] ICE in spill_failure, at reload1.c:2141

[steven at gcc dot gnu dot org]

-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-03-20 13:03:43
   date||


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

[Bug debug/42648] [4.5 Regression] gcc.dg/guality/pr41353-1.c FAILs at -On, n > 0

[steven at gcc dot gnu dot org]

-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-03-20 13:03:11
   date||


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

[Bug target/42886] [4.5 Regression] GCC is not relocatable anymore on Windows (mingw32)

[steven at gcc dot gnu dot org]

--- Comment #2 from steven at gcc dot gnu dot org  2010-03-20 13:02 ---
Waiting for OP to try suggestion of comment #1.


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug middle-end/40106] [4.4/4.5 Regression] Weird interaction between optimize_insn_for_speed_p and -funsafe-math-optimizations

[dominiq at lps dot ens dot fr]

--- Comment #50 from dominiq at lps dot ens dot fr  2010-03-20 13:02 ---
> optimize_insn_for_speed_p is more precise in that it allows hot functions
> to be optimized for speed even with -Os.  This is quite important for
> embedded targets where you generally want to optimize for size but want
> performance sensitive parts to be optimized for speed.

If so, should not 

  return optimize_function_for_size_p (cfun) || !crtl->maybe_hot_insn_p;

be

  return optimize_function_for_size_p (cfun) && !crtl->maybe_hot_insn_p;

i.e., true only if optimize_function_for_size_p is true AND
crtl->maybe_hot_insn_p false?

In the same line, should not

bool
optimize_function_for_size_p (struct function *fun)
{
  return (optimize_size
  || (fun && (fun->function_frequency
  == FUNCTION_FREQUENCY_UNLIKELY_EXECUTED)));
}

be

bool
optimize_function_for_size_p (struct function *fun)
{
  return (optimize_size
  && (fun && (fun->function_frequency
  == FUNCTION_FREQUENCY_UNLIKELY_EXECUTED)));
}

?


-- 


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

[Bug middle-end/42961] [4.5 regression] IRA register preferencing bug

[steven at gcc dot gnu dot org]

-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-03-20 13:01:50
   date||


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

[Bug target/41653] not optimal result for multiplication with constant when -Os is specified

[steven at gcc dot gnu dot org]

--- Comment #8 from steven at gcc dot gnu dot org  2010-03-20 12:59 ---
Carrot, re. your comment #7: Time for that thoroughly testing.


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |WAITING


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

[Bug rtl-optimization/42258] [4.5 Regression] redundant register move around mul instruction

[steven at gcc dot gnu dot org]

--- Comment #8 from steven at gcc dot gnu dot org  2010-03-20 12:58 ---
Shouldeth be fixedeth by aforementionedeth patcheth (comment #7). Yay!


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2010-
   ||03/msg00905.html
 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug target/43446] libiberty for target failing to build with error: Link tests are not allowed after GCC_NO_EXECUTABLES

[mirq-gccboogs at rere dot qmqm dot pl]

--- Comment #13 from mirq-gccboogs at rere dot qmqm dot pl  2010-03-20 
12:47 ---
Just to verify, I rebuilt gcc in a gcc+newlib combined tree and indeed it
builds correctly.

Configure line:
../gcc-combined/configure --with-newlib --prefix=/usr/src/gcc-armtest --target
arm-none-eabi --enable-languages=c --disable-libssp


-- 


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

[Bug target/43440] Overwriting neon quad register does not clobber all included single registers

[ramana at gcc dot gnu dot org]

--- Comment #4 from ramana at gcc dot gnu dot org  2010-03-20 12:42 ---
Patch submitted here for comments.

http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00925.html

IMO the reasons as described in my email  is another motivation for Neon
programmers to be using intrinsics rather than inline assembler and to improve
in general Neon intrinsics. 

cheers
Ramana


-- 


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

[Bug target/43440] Overwriting neon quad register does not clobber all included single registers

[batuzovk at ispras dot ru]

--- Comment #3 from batuzovk at ispras dot ru  2010-03-20 12:35 ---
(In reply to comment #2)
>  Does that look any better to you ? 
Yes, definitely better. Thank you for quick response.


-- 


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

[Bug fortran/43039] [lto/-fwhole-file] fortran-dev - ICE in gfc_conv_component_ref dynamic_dispatch_5.f03

[pault at gcc dot gnu dot org]

--- Comment #6 from pault at gcc dot gnu dot org  2010-03-20 11:29 ---
Problem is slightly different on fortran-dev, as Dominique says in comment #5.

Paul


-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

   Last reconfirmed|2010-02-14 12:39:00 |2010-03-20 11:29:21
   date||
Summary|[lto/-fwhole-file] ICE in   |[lto/-fwhole-file] fortran-
   |gfc_conv_component_ref  |dev - ICE in
   |dynamic_dispatch_5.f03  |gfc_conv_component_ref
   ||dynamic_dispatch_5.f03


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

[Bug c++/43452] Array delete causes error on incomplete type

[bangerth at gmail dot com]

--- Comment #3 from bangerth at gmail dot com  2010-03-20 11:26 ---
(In reply to comment #2)
> class Foo;
> Foo* f();
> int main() {
>Foo* p = f();
>delete [] p;
> }

I can't see how the compiler could possibly do anything useful in this case
if Foo is incomplete. I can't find any statement that would say that the code
is ill-formed, however.

If there really is no such statement, I still don't think we should make it a
priority to compile this code without an error.

W.


-- 

bangerth at gmail dot com changed:

   What|Removed |Added

 CC||bangerth at gmail dot com


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

[Bug fortran/43039] [lto/-fwhole-file] ICE in gfc_conv_component_ref dynamic_dispatch_5.f03

[dominiq at lps dot ens dot fr]

--- Comment #5 from dominiq at lps dot ens dot fr  2010-03-20 11:22 ---
Revision 157552 does not fix the ICE for gfortran.dg/dynamic_dispatch_5.f03
with -fwhole-file on the fortran-dev branch:

/opt/gcc/work/gcc/testsuite/gfortran.dg/dynamic_dispatch_5.f03:32:0: internal
compiler error: in gfc_create_module_variable, at fortran/trans-decl.c:3393


-- 


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

[Bug target/43440] Overwriting neon quad register does not clobber all included single registers

[ramana at gcc dot gnu dot org]

--- Comment #2 from ramana at gcc dot gnu dot org  2010-03-20 10:51 ---
TARGET_MD_ASSEMBLE_CLOBBERS might just be the help we need on this one - I
think I have a patch which generates the following code. Does that look any
better to you ? 


foo:
@ args = 0, pretend = 0, frame = 8
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
fmsrs13, r0
fmsrs14, r0
fmacs   s13, s14, s14
fstmfdd sp!, {d8, d9, d10, d11, d12, d13, d14, d15}
movwr3, #:lower16:y
sub sp, sp, #8
movtr3, #:upper16:y
fstss13, [sp, #4]
fstss13, [r3, #0]
@ 5 "/tmp/fail.c" 1
vmov.i8 q0, #0
@ 6 "/tmp/fail.c" 1
vmov.i8 q1, #0
@ 7 "/tmp/fail.c" 1
vmov.i8 q2, #0
@ 8 "/tmp/fail.c" 1
vmov.i8 q3, #0
@ 9 "/tmp/fail.c" 1
vmov.i8 q4, #0
@ 10 "/tmp/fail.c" 1
vmov.i8 q5, #0
@ 11 "/tmp/fail.c" 1
vmov.i8 q6, #0
@ 12 "/tmp/fail.c" 1
vmov.i8 q7, #0
ldr r0, [sp, #4]@ float
add sp, sp, #8
fldmfdd sp!, {d8, d9, d10, d11, d12, d13, d14, d15}
bx  lr
.size   foo, .-foo
.comm   y,4,4
.ident  "GCC: (GNU) 4.5.0 20100319 (experimental)"


-- 


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

[Bug middle-end/42181] [4.5 Regression][graphite] -fgraphite-identity miscompiles air.f90

[dominiq at lps dot ens dot fr]

--- Comment #25 from dominiq at lps dot ens dot fr  2010-03-20 10:45 ---
> We are executing the range [scat_1+1, T_10-2] before executing the
> range [0, scat_1-1].

Do you understand why graphite does not detect that the loop for [scat_1+1,
T_10-2] depends on the one for  [0, scat_1-1]?

Second question why does graphite exchange the order of the split loops?

Note also that in the original loop handling the loop for [0, scat_1-1] is
tricky when scat_1==1 (fctr = fctr1*fctr2 and fctr2 = -o*fctr2 must be handled
correctly).


-- 


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

[Bug c++/43375] [4.5 Regression] ICE during compiling SSE code

[burnus at gcc dot gnu dot org]

--- Comment #8 from burnus at gcc dot gnu dot org  2010-03-20 09:52 ---
(In reply to comment #7)
> Fixed in 4.5

But not marked as FIXED. I did so now, I hope that's OK.


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug fortran/40998] Source with routine in CONTAINS section and a local variable: No symbol "nerr" in current context

[toon at moene dot org]

--- Comment #7 from toon at moene dot org  2010-03-20 09:39 ---
Works when using Debian's version of gfortran 4.4.3 and their gdb (version
7.0.1).


-- 

toon at moene dot org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||WORKSFORME


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

[Bug target/43417] SH: 4.4 ICE in final_scan_insn, at final.c:2604

[kkojima at gcc dot gnu dot org]

--- Comment #4 from kkojima at gcc dot gnu dot org  2010-03-20 09:08 ---
I'm able to reproduce it with -O2 -fno-schedule-insns on 4.4.
Perhaps debian uses the local patch to make -fno-schedule-insns default.
I'll backport the patch referred in #2 to 4.4 branch if it passes
the usual tests on that branch.


-- 

kkojima at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |NEW
 Ever Confirmed|0   |1
  Known to fail||4.4.3
  Known to work||4.3.4 4.5.0
   Last reconfirmed|-00-00 00:00:00 |2010-03-20 09:08:58
   date||


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