[Bug target/38306] [4.4/4.5 Regression] 15% slowdown w.r.t. 4.3 of computational kernel on some architectures

[jv244 at cam dot ac dot uk]

--- Comment #14 from jv244 at cam dot ac dot uk  2009-09-01 06:56 ---
I wanted to try Vladimir Makarov's new patch for this testcase, but on an
unpatched trunk I notice a serious runtime regression with '-fschedule-insns'
with respect to 4.3.3

Using as base options (for the attached testcase)

gfortran -O3 -march=native -funroll-loops  -ffast-math test.f90

4.3.3 w   -fschedule-insns : 3.372s
4.3.3 w/o -fschedule-insns : 4.384s

4.4.2 w   -fschedule-insns : 4.748s
4.4.2 w/o -fschedule-insns : 4.408s

4.5.0 w   -fschedule-insns : 4.712s
4.5.0 w/o -fschedule-insns : 4.408s

so 4.3 against 4.5 'w -fschedule-insns' is about 40% faster.

I guess this is pretty target specific, I'm running this on an Opteron, this is
what -v reports:

Target: x86_64-unknown-linux-gnu
Configured with: /data03/vondele/gcc_trunk/gcc/configure --disable-bootstrap
--prefix=/data03/vondele/gcc_trunk/build --enable-languages=c,c++,fortran
--disable-multilib --with-ppl=/data03/vondele/gcc_trunk/build/
--with-cloog=/data03/vondele/gcc_trunk/build/
Thread model: posix
gcc version 4.5.0 20090830 (experimental) [trunk revision 151229] (GCC)
COLLECT_GCC_OPTIONS='-O3'  '-funroll-loops' '-ffast-math' '-fschedule-insns'
'-v' '-shared-libgcc'

/data03/vondele/gcc_trunk/build/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/f951
test.f90 -march=k8-sse3 -mcx16 -msahf --param l1-cache-size=64 --param
l1-cache-line-size=64 --param l2-cache-size=1024 -mtune=k8 -quiet -dumpbase
test.f90 -auxbase test -O3 -version -funroll-loops -ffast-math -fschedule-insns
-fintrinsic-modules-path
/data03/vondele/gcc_trunk/build/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/finclude
-o /tmp/ccvGq2CO.s


-- 

jv244 at cam dot ac dot uk changed:

   What|Removed |Added

 CC||vmakarov at redhat dot com


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

[Bug bootstrap/41180] can not build gcc 4.4.1 on Snow Leopard Mac OS X 10.6

[howarth at nitro dot med dot uc dot edu]

--- Comment #20 from howarth at nitro dot med dot uc dot edu  2009-09-01 
04:23 ---
This appears to do what we want on Snow Leopard in combination with the
config.guess patch...

Index: configure.ac
===
--- configure.ac(revision 151258)
+++ configure.ac(working copy)
@@ -1119,6 +1119,14 @@
   rs6000-*-aix*)
 host_makefile_frag="config/mh-ppc-aix"
 ;;
+  x86_64-*-darwin*)
+case "${target}" in
+# avoid default x86_64 code generation
+  i[3456789]86-*-darwin*)
+ CC="${CC-gcc} -m32"
+ ;; 
+esac 
+;;
   *-*-lynxos*)
 # /bin/cc is less than useful for our purposes.  Always use GCC
 tentative_cc="/bin/gcc"


-- 


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

[Bug bootstrap/41180] can not build gcc 4.4.1 on Snow Leopard Mac OS X 10.6

[howarth at nitro dot med dot uc dot edu]

--- Comment #19 from howarth at nitro dot med dot uc dot edu  2009-09-01 
04:00 ---
Actually comment 14 has it backwards. If we implement the config.guess
correction so that the host reports the default code generation and execution
as x86_64-apple-darwin*, we would need something like...

Index: configure.ac
===
--- configure.ac(revision 151196)
+++ configure.ac(working copy)
@@ -1015,6 +1015,12 @@
   i[[3456789]]86-*-sysv5*)
 host_makefile_frag="config/mh-sysv5"
 ;;
+  x86_64-*-darwin*)
+# gcc can default to x86_64 code generation, avoid that  
+if test "${build}" != "${host}"; then
+   tentative_cc="${CC-gcc} -m32"
+fi
+;;
   i[[3456789]]86-*-dgux*)
 tentative_cc="gcc -Wall -ansi -D__using_DGUX"
 host_makefile_frag="config/mh-dgux386"

instead. However this wouldn't be robust enough since if you only passed
--target=x86_64-apple-darwin10, it would trigger the -m32 usage since the
default triplet gets picked up as x86_64-apple-darwin10.0.0.


-- 


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

[Bug c/41206] Segmentation fault from two "#pragma GCC optimize" lines

[benhoyt+gccbugzilla at gmail dot com]

--- Comment #3 from benhoyt+gccbugzilla at gmail dot com  2009-09-01 03:25 
---
(In reply to comment #2)
> It only shows [your email address] on the web interface.
> The mail that goes out is mangled.

Isn't that the opposite of what it should be? The web interface is public,
visible by spammers and email address harvesters, whereas the email only goes
to gcc-bugs@gcc.gnu.org or private individuals.


-- 


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

[Bug c/41206] Segmentation fault from two "#pragma GCC optimize" lines

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2009-09-01 03:21 ---
(In reply to comment #1)
> Just an off-topic comment from a first-time bug reporter ... With spam the
> problem that it is, why does GCC Bugzilla show my email address in the clear
> and unmunged when I report a bug?

It only shows it on the web interface.  The mail that goes out is mangled.


-- 


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

[Bug fortran/39229] No warning of truncated lines if a continuation line follows

[jvdelisle at gcc dot gnu dot org]

--- Comment #6 from jvdelisle at gcc dot gnu dot org  2009-09-01 03:02 
---
Subject: Bug 39229

Author: jvdelisle
Date: Tue Sep  1 03:02:07 2009
New Revision: 151258

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151258
Log:
2009-08-31  Jerry DeLisle  

PR fortran/39229
* scanner.c (next_char): Fix typo in comment.
(gfc_get_char_literal): Warn if truncate flag is set for both fixed and
free form source, adjusting error locus as needed.
* parse.c (next_fixed): Clear the truncate flag.
(next_statement): Remove truncate warning.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/parse.c
trunk/gcc/fortran/scanner.c


-- 


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

[Bug c/41206] Segmentation fault from two "#pragma GCC optimize" lines

[benhoyt+gccbugzilla at gmail dot com]

--- Comment #1 from benhoyt+gccbugzilla at gmail dot com  2009-09-01 02:04 
---
Just an off-topic comment from a first-time bug reporter ... With spam the
problem that it is, why does GCC Bugzilla show my email address in the clear
and unmunged when I report a bug?


-- 


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

[Bug c/41206] New: Segmentation fault from two "#pragma GCC optimize" lines

[benhoyt at gmail dot com]

gcc 4.4.0 has a segfault ("t.c:5: internal compiler error: Segmentation fault")
when compiling the following source file, which has no includes or preprocessor
directives:

- t.c -
#pragma GCC optimize ("O0")
int main(void) {
myfunc(0);
}
#pragma GCC optimize ("O2")
- t.c -

Compile command line: gcc -c -O2 t.c

Output of "gcc -v":

Using built-in specs.
Target: mingw32
Configured with: ../gcc-4.4.0/configure
--enable-languages=c,ada,c++,fortran,java,objc,obj-c++
--disable-sjlj-exceptions --enable-shared --enable-libg
cj --enable-libgomp --with-dwarf2 --disable-win32-registry
--enable-libstdcxx-debug --enable-version-specific-runtime-libs --prefix=/mingw
--with-gmp=
/mingw/src/gmp/root --with-mpfr=/mingw/src/mpfr/root --build=mingw32
Thread model: win32
gcc version 4.4.0 (GCC)


-- 
   Summary: Segmentation fault from two "#pragma GCC optimize" lines
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: benhoyt at gmail dot com


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

[Bug bootstrap/41205] [4.5 Regression] Bootstrap broken on i686-apple-darwin9 by revision 151249

[dominiq at lps dot ens dot fr]

--- Comment #1 from dominiq at lps dot ens dot fr  2009-09-01 01:09 ---
>From http://linux.die.net/man/3/strnlen:

...
Conforming to

This function is a GNU extension.
...


-- 


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

[Bug bootstrap/41205] New: [4.5 Regression] Bootstrap broken on i686-apple-darwin9 by revision 151249

[dominiq at lps dot ens dot fr]

Revision 151249 broke bootstrap on i686-apple-darwin9:

gcc  -g -fkeep-inline-functions -DIN_GCC   -W -Wall -Wwrite-strings -Wcast-qual
-Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute
-Wold-style-definition -fno-common  -DHAVE_CONFIG_H  -o cc1-dummy c-lang.o
stub-objc.o attribs.o c-errors.o c-lex.o c-pragma.o c-decl.o c-typeck.o
c-convert.o c-aux-info.o c-common.o c-opts.o c-format.o c-semantics.o
c-ppoutput.o c-cppbuiltin.o c-objc-common.o c-dump.o c-pch.o c-parser.o
i386-c.o darwin-c.o c-gimplify.o tree-mudflap.o c-pretty-print.o c-omp.o \
  dummy-checksum.o main.o tree-browser.o libbackend.a
../libcpp/libcpp.a ../libdecnumber/libdecnumber.a ../libcpp/libcpp.a
./../intl/libintl.a /usr/lib/libiconv.dylib  ../libiberty/libiberty.a
../libdecnumber/libdecnumber.a  -L/sw/lib -lcloog -L/sw/lib -lppl_c -lppl
-lgmpxx -L/opt/mpc/build/lib -lmpc -L/sw/lib -lmpfr -lgmp  
Undefined symbols:
  "_strnlen", referenced from:
  _make_ith_pack_parameter_name in libbackend.a(dwarf2out.o)


-- 
   Summary: [4.5 Regression] Bootstrap broken on i686-apple-darwin9
by revision 151249
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
 GCC build triplet: i686-apple-darwin9
  GCC host triplet: i686-apple-darwin9
GCC target triplet: i686-apple-darwin9


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

[Bug c/41204] New: GCC 4.4.[0/1/2] generates worse code compared to GCC 4.3.2

[ami_stuff at o2 dot pl]

Hi,

When I compile this C code:

#include 

inline int mid_pred(int a, int b, int c)
{
int t= (a-b)&((a-b)>>31);
a-=t;
b+=t;
b-= (b-c)&((b-c)>>31);
b+= (a-b)&((a-b)>>31);

return b;
}

I get this asm output from GCC 4.3.2 (-m68060 -fomit-frame-pointer -O[2/3]):

#NO_APP
.text
.even
.globl  _mid_pred
_mid_pred:
movem.l #14336,-(sp)
move.l 16(sp),d2
move.l 20(sp),d1
move.l d2,d0
sub.l d1,d0
move.l d0,d4
add.l d4,d4
subx.l d4,d4
and.l d0,d4
add.l d4,d1
move.l d1,d3
sub.l 24(sp),d3
move.l d3,d0
add.l d0,d0
subx.l d0,d0
and.l d3,d0
sub.l d0,d1
sub.l d4,d2
sub.l d1,d2
move.l d2,d0
add.l d0,d0
subx.l d0,d0
and.l d2,d0
add.l d1,d0
movem.l (sp)+,#28
rts


When I use GCC 4.4.[0/1/2] with -O2/-O3 option I get worse asm output (2
additional move.ls):

#NO_APP
.text
.even
.globl  _mid_pred
_mid_pred:
movem.l #14336,-(sp)
move.l 16(sp),d1
move.l 20(sp),d0
move.l d1,d3
sub.l d0,d3
move.l d3,d2
add.l d2,d2
subx.l d2,d2
and.l d3,d2
add.l d2,d0
move.l d0,d4
sub.l 24(sp),d4
move.l d4,d3
add.l d3,d3
subx.l d3,d3
and.l d4,d3
sub.l d3,d0
move.l d0,d3
sub.l d2,d1
sub.l d0,d1
move.l d1,d2
add.l d2,d2
subx.l d2,d2
and.l d1,d2
move.l d2,d0
add.l d3,d0
movem.l (sp)+,#28
rts

The problematic optimization is -fregmove (-m68060 -fomit-frame-pointer -O[2/3]
-fno-regmove):

#NO_APP
.text
.even
.globl  _mid_pred
_mid_pred:
movem.l #14336,-(sp)
move.l 16(sp),d0
move.l 20(sp),d1
move.l d0,d2
sub.l d1,d2
move.l d2,d3
add.l d3,d3
subx.l d3,d3
and.l d3,d2
add.l d2,d1
move.l d1,d3
sub.l 24(sp),d3
move.l d3,d4
add.l d4,d4
subx.l d4,d4
and.l d4,d3
sub.l d3,d1
sub.l d2,d0
sub.l d1,d0
move.l d0,d2
add.l d2,d2
subx.l d2,d2
and.l d2,d0
add.l d1,d0
movem.l (sp)+,#28
rts


-- 
   Summary: GCC 4.4.[0/1/2] generates worse code compared to GCC
4.3.2
   Product: gcc
   Version: 4.4.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ami_stuff at o2 dot pl
  GCC host triplet: i686-cygwin
GCC target triplet: m68k-amigaos


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

[Bug c++/41153] [4.4 Regression] ICE in building Qt4 src/core

[hjl dot tools at gmail dot com]

--- Comment #10 from hjl dot tools at gmail dot com  2009-09-01 00:35 
---
Target optimization has many issues. See PR 37565.


-- 


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

[Bug middle-end/40106] Time increase for the Polyhedron test air.f90 due to bad optimization

[dominiq at lps dot ens dot fr]

--- Comment #28 from dominiq at lps dot ens dot fr  2009-08-31 23:59 ---
Following Richard Guenther's suggestion on IRC, I have tested the following
patch:

--- ../_gcc_clean/gcc/builtins.c2009-08-31 15:07:18.0 +0200
+++ gcc/builtins.c  2009-09-01 01:28:09.0 +0200
@@ -3012,7 +3012,7 @@
   real_from_integer (&cint, VOIDmode, n, n < 0 ? -1 : 0, 0);
   if (real_identical (&c2, &cint)
  && ((flag_unsafe_math_optimizations
-  && optimize_insn_for_speed_p ()
+  /* && optimize_insn_for_speed_p () */
   && powi_cost (n/2) <= POWI_MAX_MULTS)
  || n == 1))
{

With it I get:

[ibook-dhum] test/dbg_air% gfc -m64 -O2 -funsafe-math-optimizations air_db.f90
[ibook-dhum] test/dbg_air% time a.out > /dev/null
4.490u 0.018s 0:04.51 99.7% 0+0k 0+3io 0pf+0w

compared to

[ibook-dhum] test/dbg_air% gfc -m64 -O2 -funsafe-math-optimizations
-fno-strict-overflow air_db.f90
[ibook-dhum] test/dbg_air% time a.out > /dev/null
4.320u 0.015s 0:04.34 99.7% 0+0k 0+0io 0pf+0w

and there is no call to pow in the assembly. I think the difference is
significant; so it seems that optimize_insn_for_speed_p () is playing some role
elsewhere in the code. Note that if I replace lines 322 and 427

mu = mu0*(T(i,j)/t02)**1.5*(t02+110.56)/(T(i,j)+110.56)

with

mu = mu0*sqrt((T(i,j)/t02)**3)*(t02+110.56)/(T(i,j)+110.56)

or

mu =
mu0*sqrt((T(i,j)/t02))*(T(i,j)/t02)*(t02+110.56)/(T(i,j)+110.56)

there is no call to pow and the code is slightly faster with
-fno-strict-overflow

[ibook-dhum] test/dbg_air% gfc -m64 -O2 -funsafe-math-optimizations
-fno-strict-overflow air_db_1.f90
[ibook-dhum] test/dbg_air% time a.out > /dev/null
4.323u 0.015s 0:04.34 99.7% 0+0k 0+0io 0pf+0w
[ibook-dhum] test/dbg_air% gfc -m64 -O2 -funsafe-math-optimizations
air_db_1.f90
[ibook-dhum] test/dbg_air% time a.out > /dev/null
4.527u 0.016s 0:04.55 99.5% 0+0k 0+0io 0pf+0w

The original air.f90 compiled with -fwhole-file gives

[ibook-dhum] lin/test% gfc -m64 -O3 -ffast-math -funroll-loops
-ftree-loop-linear -fomit-frame-pointer -finline-limit=600 --param
min-vect-loop-bound=2 -fwhole-file air.f90
[ibook-dhum] lin/test% time a.out > /dev/null
8.358u 0.049s 0:08.42 99.6% 0+0k 0+8io 0pf+0w

compared to

[ibook-dhum] lin/test% gfc -m64 -O3 -ffast-math -funroll-loops
-ftree-loop-linear -fomit-frame-pointer -finline-limit=600 --param
min-vect-loop-bound=2 air.f90
[[ibook-dhum] lin/test% time a.out > /dev/null
8.273u 0.046s 0:08.32 99.8% 0+0k 0+0io 0pf+0w


-- 


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

[Bug libstdc++/41058] FAIL: ext/pb_ds/regression/hash_data_map_rand.cc

[hjl dot tools at gmail dot com]

--- Comment #28 from hjl dot tools at gmail dot com  2009-08-31 23:09 
---
This may be related to PR 37144.


-- 


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

[Bug c/41203] New: -mtune=pentium2 structure related tree-outof-ssa internal compiler error

[dps at simpson dot demon dot co dot uk]

There seems to be a tree-ssa related structure member assignment problem that
affects  gcc -m32  -{O,O2,O3,Os} -mtune=pentium2  but apparently nothing else.

Removing the if statement out of the set_foo function also avoids the bug.

Screen shot:
$ gcc --version
gcc (GCC) 4.5.0 20090809 (experimental)
<... all the rest eldided...>
$ gcc -Os -m32 -march=i686 -mtune=pentium2 -c -o block/blk-settings.o
/tmp/blk-settings2.c
/tmp/blk-settings2.c: In function 'set_foo':
/tmp/blk-settings2.c:9:6: internal compiler error: in
insert_value_copy_on_edge, at tree-outof-ssa.c:223
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Code:
/* insert_value_copy_on_edge, at tree-outof-ssa.c:223
 * gcc (GCC) 4.5.0 20090809 (experimental)
 * platform x86_64-unknown-linux-gnu */
struct foo
{
unsigned short foo;
};

void set_foo(struct foo *p, unsigned short bar)
{
if (!bar)
bar = 1;
p->foo = bar;
}


-- 
   Summary: -mtune=pentium2 structure related tree-outof-ssa
internal compiler error
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dps at simpson dot demon dot co dot uk
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: i686-unknown-linux-gnu


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

[Bug c++/7932] Emit debug information about non-type template parameters

[bangerth at gmail dot com]

--- Comment #5 from bangerth at gmail dot com  2009-08-31 22:49 ---
(In reply to comment #4)
> > What does GDB currently say for the testcase shown in the initial report?
> 
> I think GDB doesn't know about the new type debug information added by gcc
> yet. So it won't say anything.

I just tried with GDB 6.6, and you are right: it doesn't know about "dim".


> But I haven't test GDB HEAD. My reasoning
> was that maybe we could open a GDB bug to track this there now that we
> generate debug info for this case ? Or is there a GDB bug opened for this
> already ?

I didn't open a GDB bug back then, and I don't have any experience with GDB
bugs in the first place. Would you mind opening a bug with their bugzilla
(or whatever they use)?

Either way, yes, we can close this PR now.

Thanks
 W.


-- 

bangerth at gmail dot com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug target/41156] [4.4/4.5 Regression] zlib segfault in inflate_table() compiled w/ -O -msse2 ftree-vectorize

[hjl dot tools at gmail dot com]

--- Comment #5 from hjl dot tools at gmail dot com  2009-08-31 22:25 ---
(In reply to comment #4)
> HJ, this doesn't make sense.  
> 
> Either we can assume 16-byte stack alignment, or we can't.  Which is it?
> 

On ia32, except for MacOS, we don't enforce 16-byte stack alignment.
We get 4-byte incoming stack alignment via object files:

1. Compiled with older gcc.
2. Compiled with gcc 3.x and earlier 4.x using -Os.
3. Compiled with gcc using -mpreferred-stack-boundary=2
4. From assembly code with 4 byte stack alignment.
5. Compiled with other compilers, which generate 4 byte stack
alignment.

It usually won't cause segfault until vectorizer is enabled.


-- 


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

[Bug c++/7932] Emit debug information about non-type template parameters

[dodji at redhat dot com]

--- Comment #4 from dodji at gcc dot gnu dot org  2009-08-31 22:14 ---
Subject: Re:  Emit debug information about non-type template
 parameters

Le 01/09/2009 00:05, bangerth at gmail dot com a écrit :

> What does GDB currently say for the testcase shown in the initial report?

I think GDB doesn't know about the new type debug information added by gcc
yet. So it won't say anything. But I haven't test GDB HEAD. My reasoning
was that maybe we could open a GDB bug to track this there now that we
generate debug info for this case ? Or is there a GDB bug opened for this
already ?


-- 


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

Re: [Bug c++/7932] Emit debug information about non-type template parameters

[Dodji Seketeli]

Le 01/09/2009 00:05, bangerth at gmail dot com a écrit :

> What does GDB currently say for the testcase shown in the initial report?

I think GDB doesn't know about the new type debug information added by gcc
yet. So it won't say anything. But I haven't test GDB HEAD. My reasoning
was that maybe we could open a GDB bug to track this there now that we
generate debug info for this case ? Or is there a GDB bug opened for this
already ?

[Bug c++/7932] Emit debug information about non-type template parameters

[bangerth at gmail dot com]

--- Comment #3 from bangerth at gmail dot com  2009-08-31 22:05 ---
(In reply to comment #2)
> I think this bug should be fixed in trunk (4.5) by the patch for PR
> debug/30161.
> Can we close this bug or should we wait for GDB ?

What does GDB currently say for the testcase shown in the initial report?

W.


-- 


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

[Bug c++/7932] Emit debug information about non-type template parameters

[dodji at gcc dot gnu dot org]

--- Comment #2 from dodji at gcc dot gnu dot org  2009-08-31 21:59 ---
I think this bug should be fixed in trunk (4.5) by the patch for PR
debug/30161.
Can we close this bug or should we wait for GDB ?


-- 

dodji at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||dodji at gcc dot gnu dot org


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

[Bug debug/30161] GCC should generate dwarf info about template parameters

[dodji at gcc dot gnu dot org]

--- Comment #9 from dodji at gcc dot gnu dot org  2009-08-31 21:55 ---
Fixed in trunk.

This patch implements some GNU extensions to represent template parameter packs
and template template parameters. The extension is documented at
http://gcc.gnu.org/wiki/TemplateParmsDwarf .

Now I guess some discussions should happen at the DWARF level to know see how
the GNU extension can evolve and turn into a proper DWARF proposal. So this
patch might see some modifications in a near future.

I will open other bugs for that in due time.


-- 

dodji at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c++/41153] [4.4 Regression] ICE in building Qt4 src/core

[mmitchel at gcc dot gnu dot org]

-- 

mmitchel at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P1


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

[Bug c++/41038] [4.4/4.5 regression] Parsing error related to qualified name id

[mmitchel at gcc dot gnu dot org]

-- 

mmitchel at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P1


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

[Bug c++/40808] [4.4/4.5 regression] member template specialization causes ICE

[mmitchel at gcc dot gnu dot org]

-- 

mmitchel at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P2


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

[Bug bootstrap/37739] [4.4 Regression] bootstrap broken with core gcc > gcc-4.2.x

[mmitchel at gcc dot gnu dot org]

--- Comment #32 from mmitchel at gcc dot gnu dot org  2009-08-31 21:48 
---
Can anyone confirm that this is fixed?


-- 

mmitchel at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P1


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

[Bug debug/30161] GCC should generate dwarf info about template parameters

[dodji at gcc dot gnu dot org]

--- Comment #8 from dodji at gcc dot gnu dot org  2009-08-31 21:48 ---
Subject: Bug 30161

Author: dodji
Date: Mon Aug 31 21:48:04 2009
New Revision: 151249

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151249
Log:
Emit DWARF for template parameters (PR debug/30161)

ChangeLog:
PR debug/30161
* include/dwarf2.h (enum dwarf_tag): Added
DW_TAG_GNU_template_template_param
(enum dwarf_attribute): Added DW_AT_GNU_template_name.

gcc/ChangeLog:
PR debug/30161
* cgraph.h (cgraph_get_node): Declare ...
* cgraph.c (cgraph_get_node): ... new function.
* dwarf2out.c (gen_generic_params_dies,
generic_parameter_die, tree_add_const_value_attribute_for_decl,
make_ith_pack_parameter_name,
append_entry_to_tmpl_value_parm_die_table,
gen_remaining_tmpl_value_param_die_attribute): New functions.
(gen_subprogram_die): Generate debug info for template parameters
if debug info level is higher than DINFO_LEVEL_TERSE.
Use tree_add_const_value_attribute_for_decl instead of
tree_add_const_value_attribute.
(gen_const_die): Use tree_add_const_value_attribute_for_decl
instead of tree_add_const_value_attribute.
(gen_struct_or_union_type_die): Generate debug
info for template parameters if debug info level is higher than
DINFO_LEVEL_TERSE.
(tree_add_const_value_attribute): Handle integral and pointer
constants. Update comment.
(dwarf_tag_name): Support DW_TAG_GNU_template_template_param.
(dwarf_attr_name): Support DW_AT_GNU_template_name.
(reference_to_unused): Fix thinko. Remove redundant predicates from
tests.
(tree_add_const_value_attribute): Make this work for constant
expressions only.
tree_add_const_value_attribute_for_decl is to be used for variable
DECLs now.
(add_location_or_const_value_attribute): Use
tree_add_const_value_attribute_for_decl now.
(dwarf2out_finish): Emit the DW_AT_const_value attribute of
DW_TAG_template_value_param DIEs after function DIEs have been
emitted.
* langhooks.h (lang_hooks_for_types): Add
get_argument_pack_elems.
(lang_hooks_for_decls): Add generic_generic_parameter_decl_p.
(lang_hooks): Added get_innermost_generic_parms,
get_innermost_generic_args.
* langhooks-def.h (LANG_HOOKS_GET_INNERMOST_GENERIC_PARMS,
LANG_HOOKS_GET_INNERMOST_GENERIC_ARGS,
LANG_HOOKS_GET_ARGUMENT_PACK_ELEMS,
LANG_HOOKS_GENERIC_GENERIC_PARAMETER_DECL_P): New language hooks.

gcc/cp/ChangeLog:
PR debug/30161
* cp-tree.h (get_template_info): Parameter should be const.
(CLASSTYPE_SPECIALIZATION_OF_PRIMARY_TEMPLATE_P): Fix typo.
(get_template_argument_pack_elems,
get_primary_template_innermost_parameters,
get_template_innermost_arguments, template_template_parameter_p):
Declare ...
* pt.c (get_template_argument_pack_elems,
get_template_innermost_parameters, get_template_innermost_arguments,
template_template_parameter_p):
... New C++ front end implementation of new language hooks.
(primary_template_instantiation_p): New private helper.
(make_ith_pack_parameter_name): Use snprintf and strnlen instead of
printf and strlen.
(get_template_info): Const-ify parameter.
* cp-lang.c (LANG_HOOKS_GET_INNERMOST_GENERIC_PARMS,
LANG_HOOKS_GET_INNERMOST_GENERIC_ARGS,
LANG_HOOKS_GET_ARGUMENT_PACK_ELEMS,
LANG_HOOKS_GENERIC_TYPE_PARAMETER_DECL_P): Initialize these
interfaces for the C++ front-end.

gcc/testsuite/ChangeLog:
PR debug/30161
* g++.dg/debug/dwarf2/template-params-1.C: New test.
* g++.dg/debug/dwarf2/template-params-2.C: Likewise.
* g++.dg/debug/dwarf2/template-params-3.C: Likewise.
* g++.dg/debug/dwarf2/template-params-4.C: Likewise.
* g++.dg/debug/dwarf2/template-params-5.C: Likewise.
* g++.dg/debug/dwarf2/template-params-6.C: Likewise.
* g++.dg/debug/dwarf2/template-func-params-1.C: Likewise.
* g++.dg/debug/dwarf2/template-func-params-2.C: Likewise.
* g++.dg/debug/dwarf2/template-func-params-3.C: Likewise.
* g++.dg/debug/dwarf2/template-func-params-4.C: Likewise.
* g++.dg/debug/dwarf2/template-func-params-5.C: Likewise.
* g++.dg/debug/dwarf2/template-func-params-6.C: Likewise.
* g++.dg/debug/dwarf2/template-func-params-7.C: Likewise.

Added:
trunk/gcc/testsuite/g++.dg/debug/dwarf2/template-func-params-1.C
trunk/gcc/testsuite/g++.dg/debug/dwarf2/template-func-params-2.C
trunk/gcc/testsuite/g++.dg/debug/dwarf2/template-func-params-3.C
trunk/gcc/testsuite/g++.dg/debug/dwarf2/template-func-params-4.C
trunk/gcc/testsuite/g++.dg/debug/dwarf2/template-func-params-5.C
trunk/gcc/test

[Bug target/41156] [4.4/4.5 Regression] zlib segfault in inflate_table() compiled w/ -O -msse2 ftree-vectorize

[mmitchel at gcc dot gnu dot org]

--- Comment #4 from mmitchel at gcc dot gnu dot org  2009-08-31 21:47 
---
HJ, this doesn't make sense.  

Either we can assume 16-byte stack alignment, or we can't.  Which is it?


-- 


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

[Bug ada/40775] [4.4/4.5 Regression] Ada on ARM ICE in find_valid_class, at reload.c:701

[mmitchel at gcc dot gnu dot org]

-- 

mmitchel at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P5


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

[Bug c++/41127] [4.4/4.5 regression] unnamed bitfield declaration parser regression

[jason at gcc dot gnu dot org]

--- Comment #5 from jason at gcc dot gnu dot org  2009-08-31 21:21 ---
Fixed.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c++/41127] [4.4/4.5 regression] unnamed bitfield declaration parser regression

[jason at gcc dot gnu dot org]

--- Comment #4 from jason at gcc dot gnu dot org  2009-08-31 21:20 ---
Subject: Bug 41127

Author: jason
Date: Mon Aug 31 21:20:07 2009
New Revision: 151247

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151247
Log:
PR c++/41127
* parser.c (cp_parser_enum_specifier): Make sure the : is followed by a
type-specifier-seq before we commit.


Added:
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/parse/enum5.C
  - copied unchanged from r151246, trunk/gcc/testsuite/g++.dg/parse/enum5.C
Modified:
branches/gcc-4_4-branch/gcc/cp/ChangeLog
branches/gcc-4_4-branch/gcc/cp/parser.c
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/cpp0x/enum1.C


-- 


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

[Bug c++/41127] [4.4/4.5 regression] unnamed bitfield declaration parser regression

[jason at gcc dot gnu dot org]

--- Comment #3 from jason at gcc dot gnu dot org  2009-08-31 21:08 ---
Subject: Bug 41127

Author: jason
Date: Mon Aug 31 21:08:33 2009
New Revision: 151246

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151246
Log:
PR c++/41127
* parser.c (cp_parser_enum_specifier): Make sure the : is followed by a
type-specifier-seq before we commit.

Added:
trunk/gcc/testsuite/g++.dg/parse/enum5.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/cpp0x/enum1.C


-- 


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

[Bug target/41202] New: -mno-mmx doesn't turn off sse*

[dbaron at dbaron dot org]

In general, it seems that the -m{,no-}{mmx,sse,sse2,sse3,ssse3} (etc.) options
also turn on any options that the option being turned on "depends on", or turn
off any options that "depend on" the option being turned off.  (I'm not sure
what the definition of "depend on" is exactly, but I'd note that, e.g.,
emmintrin.h (SSE2) #includes xmmintrin.h (SSE) which includes mmintrin.h
(MMX).)

However, this general rule doesn't seem to apply to -mno-mmx turning off any of
the other SSE* options (even though turning on those options turns on MMX). 
That is, the following behaviors all seem sensible:

$ /usr/local/gcc-4.4.1/bin/gcc -m32 -E -dM -x c /dev/null | grep
"\(MMX\|SSE\)"$ /usr/local/gcc-4.4.1/bin/gcc -m32 -msse -E -dM -x c /dev/null |
grep "\(MMX\|SSE\)"
#define __MMX__ 1
#define __SSE__ 1
$ /usr/local/gcc-4.4.1/bin/gcc -m32 -msse2 -E -dM -x c /dev/null | grep
"\(MMX\|SSE\)"
#define __MMX__ 1
#define __SSE2__ 1
#define __SSE__ 1
$ /usr/local/gcc-4.4.1/bin/gcc -m32 -march=core2 -E -dM -x c /dev/null | grep
"\(MMX\|SSE\)"
#define __MMX__ 1
#define __SSE2__ 1
#define __SSSE3__ 1
#define __SSE__ 1
#define __SSE3__ 1
$ /usr/local/gcc-4.4.1/bin/gcc -m32 -march=core2 -mno-sse2 -E -dM -x c
/dev/null | grep "\(MMX\|SSE\)"
#define __MMX__ 1
#define __SSE__ 1
$ /usr/local/gcc-4.4.1/bin/gcc -m32 -march=core2 -mno-sse -E -dM -x c /dev/null
| grep "\(MMX\|SSE\)"
#define __MMX__ 1

But this last one doesn't seem sensible:

$ /usr/local/gcc-4.4.1/bin/gcc -m32 -march=core2 -mno-mmx -E -dM -x c /dev/null
| grep "\(MMX\|SSE\)"
#define __SSE2__ 1
#define __SSSE3__ 1
#define __SSE__ 1
#define __SSE3__ 1

I can repeat these last few tests using the default 64-bit configuration:

$ /usr/local/gcc-4.4.1/bin/gcc -E -dM -x c /dev/null | grep
"\(MMX\|SSE\)"#define __MMX__ 1
#define __SSE2_MATH__ 1
#define __SSE_MATH__ 1
#define __SSE2__ 1
#define __SSE__ 1
$ /usr/local/gcc-4.4.1/bin/gcc -mno-sse2 -E -dM -x c /dev/null | grep
"\(MMX\|SSE\)"
#define __MMX__ 1
#define __SSE_MATH__ 1
#define __SSE__ 1
$ /usr/local/gcc-4.4.1/bin/gcc -mno-sse -E -dM -x c /dev/null | grep
"\(MMX\|SSE\)"
#define __MMX__ 1

And again the last one seems odd, given that turning on SSE or SSE2 turns on
MMX:

$ /usr/local/gcc-4.4.1/bin/gcc -mno-mmx -E -dM -x c /dev/null | grep
"\(MMX\|SSE\)"
#define __SSE2_MATH__ 1
#define __SSE_MATH__ 1
#define __SSE2__ 1
#define __SSE__ 1


-- 
   Summary: -mno-mmx doesn't turn off sse*
   Product: gcc
   Version: 4.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dbaron at dbaron dot org


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

[Bug c++/41127] [4.4/4.5 regression] unnamed bitfield declaration parser regression

[jason at gcc dot gnu dot org]

-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jason at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2009-08-25 13:43:14 |2009-08-31 20:41:06
   date||


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

[Bug bootstrap/41180] can not build gcc 4.4.1 on Snow Leopard Mac OS X 10.6

[mrs at apple dot com]

--- Comment #18 from mrs at apple dot com  2009-08-31 20:37 ---
That file just has:

# APPLE LOCAL file dynamic-no-pic
# The -mdynamic-no-pic ensures that the compiler executable is built without
# position-independent-code -- the usual default on Darwin.

BOOT_CFLAGS=-g -O2 -mdynamic-no-pic

in it.  This just results in a faster compiler, otherwise, there should be no
real change.


-- 


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

[Bug c++/41201] New: #pragma GCC target ("sse2") doesn't alter __SSE2__ in C++ (as it does in C)

[dbaron at dbaron dot org]

I'm really not sure what component this goes in; apologies if it's wrong.

The following testcase:

=== BEGIN pragma.c ===
#ifdef __SSE2__
#error "SSE2 should not be defined"
#endif 

#pragma GCC push_options

#pragma GCC target ("sse2")

#ifndef __SSE2__
#error "SSE2 should be defined"
#endif 

#pragma GCC pop_options

#ifdef __SSE2__
#error "SSE2 should not be defined"
#endif 
=== END pragma.c ===

hits the middle #error in C++, but compiles correctly in C.  I'm using GCC
4.4.1 with -mno-sse2:

$ /usr/local/gcc-4.4.1/bin/gcc -x c -c -mno-sse2 pragma.c
[returns 0]
$ /usr/local/gcc-4.4.1/bin/gcc -x c++ -c -mno-sse2 pragma.c
pragma.c:10:2: error: #error "SSE2 should be defined"
[returns 1]

This matters because the real case I'm worried about (for
https://bugzilla.mozilla.org/show_bug.cgi?id=513422 ) is an example that
replaces the middle #ifdef-#error-#endif in the testcase with a #include of
, and emmintrin.h has an #error in exactly that case.

I think C++ should behave the same as C does (a behavior that it looks like a
number of C testcases already in the GCC testsuite depend on: sse-22.c sse-23.c
funcspec-9.c in gcc/testsuite/gcc.target/i386)


-- 
   Summary: #pragma GCC target ("sse2") doesn't alter __SSE2__ in
C++ (as it does in C)
   Product: gcc
   Version: 4.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dbaron at dbaron dot org
 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=41201

[Bug target/39787] ICE with #pragma GCC target

[dbaron at dbaron dot org]

--- Comment #3 from dbaron at dbaron dot org  2009-08-31 20:01 ---
Created an attachment (id=18458)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18458&action=view)
another testcase

Here's another testcase that I just simplified from my attempts to use, in
Mozilla, some SSE2 code with runtime detection using CPUID.  (See
https://bugzilla.mozilla.org/show_bug.cgi?id=506430 and
https://bugzilla.mozilla.org/show_bug.cgi?id=513422 .)

I'd simplified this testcase before discovering the existing bug report.

When I compile this testcase with:
/usr/local/gcc-4.4.1/bin/gcc -mno-sse2 ice.c
I get:
ice.c: In function ‘Convert_ascii_run’:
ice.c:11: internal compiler error: in emit_move_insn, at expr.c:3405


-- 


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

[Bug target/38294] Enable multilib support for mingw

[ktietz at gcc dot gnu dot org]

--- Comment #13 from ktietz at gcc dot gnu dot org  2009-08-31 19:52 ---
As the change is already applied to head, I close this.


-- 

ktietz at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug target/38294] Enable multilib support for mingw

[ktietz at gcc dot gnu dot org]

--- Comment #12 from ktietz at gcc dot gnu dot org  2009-08-31 19:49 ---
(In reply to comment #11)
> Created an attachment (id=17259)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17259&action=view) [edit]
> Kai's attempt
> 
> This patch has a few caveats:
> 
> You can't use the winsup link hack to work around the issue that Corinna
> injected, so you can't build libstdc++, so you can't build g++

Why that? winsup has to point in our case always to sysroot.

> Also, the lib directories are all fubared because of ld not allowing custom
> default lib paths (it's hard coded to use /root/target/lib):
> 1) x86_64-pc-mingw32/lib remains the place for 64-bit mingw objects
> and libraries
And this library remains for ld's sake here.

> 2) x86_64-pc-mingw32/lib64 is a link to x86_64-pc-mingw32/lib
For cross-compiler with unix environment no issue, for native a junction point
is necessary. We need not to link mingw to x86_64-pc-mingw32 folder, it can be
a physical folder. Then headers and libraries can go also directly into
mingw/include and mingw/(lib/lib32).
> 3) x86_64-pc-mingw32/lib32 is the place for 32-bit mingw
And?


-- 


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

[Bug tree-optimization/36385] Assume that long is scalar size of a pointer

[ktietz at gcc dot gnu dot org]

--- Comment #6 from ktietz at gcc dot gnu dot org  2009-08-31 19:29 ---
Created an attachment (id=18457)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18457&action=view)
Remove cast warnings for target with sizeof (void *)>sizeof(long)

If define __INTPTR_TYPE__ is present, this patch uses it to cast from pointer
to long, and from long to pointer.

Tested for i686-pc-mingw32 and for x86_64-pc-mingw32.

Ok, for apply?


-- 


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

[Bug fortran/40940] [F03] CLASS statement

[janus at gcc dot gnu dot org]

--- Comment #6 from janus at gcc dot gnu dot org  2009-08-31 19:19 ---
r151244 fixes comment #3 and #4. The items in comment #2 have to wait for a
full implementation of polymorphism. Closing.


-- 

janus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug fortran/40940] [F03] CLASS statement

[janus at gcc dot gnu dot org]

--- Comment #5 from janus at gcc dot gnu dot org  2009-08-31 19:08 ---
Subject: Bug 40940

Author: janus
Date: Mon Aug 31 19:08:03 2009
New Revision: 151244

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151244
Log:
2009-08-31  Janus Weil  
Paul Thomas  

PR fortran/40940
* array.c (gfc_match_array_constructor): Rename gfc_match_type_spec.
* decl.c (gfc_match_type_spec): Rename to gfc_match_decl_type_spec,
and reject CLASS with -std=f95.
(gfc_match_implicit, gfc_match_data_decl,gfc_match_prefix,
match_procedure_interface): Rename gfc_match_type_spec.
* gfortran.h (gfc_type_compatible): Add prototype.
* match.h (gfc_match_type_spec): Rename to gfc_match_decl_type_spec.
* match.c (match_intrinsic_typespec): Rename to match_type_spec, and
add handling of derived types.
(gfc_match_allocate): Rename match_intrinsic_typespec and check
type compatibility of derived types.
* symbol.c (gfc_type_compatible): New function to check if two types
are compatible.

2009-08-31  Janus Weil  

PR fortran/40940
* gfortran.dg/allocate_derived_1.f90: New.
* gfortran.dg/class_3.f03: New.


Added:
trunk/gcc/testsuite/gfortran.dg/allocate_derived_1.f90
trunk/gcc/testsuite/gfortran.dg/class_3.f03
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/array.c
trunk/gcc/fortran/decl.c
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/match.c
trunk/gcc/fortran/match.h
trunk/gcc/fortran/symbol.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug libstdc++/41058] FAIL: ext/pb_ds/regression/hash_data_map_rand.cc

[ubizjak at gmail dot com]

--- Comment #27 from ubizjak at gmail dot com  2009-08-31 19:01 ---
(In reply to comment #26)

> The line that will fail to link to correct LSDA is marked with >>>.

This issue is reported in binutils bugzilla as Bug 10579 [1].

[1] http://sourceware.org/bugzilla/show_bug.cgi?id=10579


-- 


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

[Bug fortran/41198] gfortran 4.5 does not produce "Warning: Deleted feature: GOTO at (1) jumps to END of construct at (2)"

[kargl at gcc dot gnu dot org]

--- Comment #4 from kargl at gcc dot gnu dot org  2009-08-31 18:58 ---
(In reply to comment #2)
> If I move "GOTO 50" outside of the block, gfortran 4.5 correctly gives the
> message "Warning: Label at (1) is not in the same block as the GOTO statement
> at (2)", but gfortran 4.3 and 4.4 give no message.
> 

As I said, 4.3 and 4.4 had/have a bug.  The PR that fixed this problem
is http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38507
The patch was committed to trunk on 2009-03-29.  Judging from the release
date of 4.4.0, it was deemed too close to release to do a backport.

A search of fortran@ finds the first analysis of the problem here:

http://gcc.gnu.org/ml/fortran/2008-12/msg00355.html

Here's my first attempt at fixing the problem before Tobias Schlueter
took over the PR.


-- 


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

[Bug libstdc++/41058] FAIL: ext/pb_ds/regression/hash_data_map_rand.cc

[ubizjak at gmail dot com]

--- Comment #26 from ubizjak at gmail dot com  2009-08-31 18:44 ---
Created an attachment (id=18456)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18456&action=view)
alpha dump

This is the dump. Please look for $LSFDE285:

$LSFDE285:
.4byte  $LEFDE285-$LASFDE285
$LASFDE285:
.4byte  $LASFDE285-$Lframe1
.4byte  $LFB5858-.
.4byte  $LFE5858-$LFB5858
.uleb128 0x4
>>> .4byte  $LLSDA5858-.
.byte   0x4
.4byte  $LCFI1142-$LFB5858
.byte   0xe

The line that will fail to link to correct LSDA is marked with >>>.


-- 


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

[Bug fortran/41198] gfortran 4.5 does not produce "Warning: Deleted feature: GOTO at (1) jumps to END of construct at (2)"

[mikael at gcc dot gnu dot org]

--- Comment #3 from mikael at gcc dot gnu dot org  2009-08-31 18:41 ---
(In reply to comment #1)
> I believe that 4.3 and 4.4 had a bug. 
bug #38507 probably


-- 


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

[Bug libstdc++/41058] FAIL: ext/pb_ds/regression/hash_data_map_rand.cc

[ubizjak at gmail dot com]

--- Comment #25 from ubizjak at gmail dot com  2009-08-31 18:23 ---
(In reply to comment #24)
> If you think it is a linker bug, try to see if the LSDA pointer in readelf -wf
> dump is correct when you link with --traditional-format.  And, file a binutils

No, with --traditional-format, it fails the same way. In this case, LSDA is
parsed from __gcc_personality_v0 and without --traditional-format, LSDA is
parsed from uw_frame_state_for. The target is always 0x11 off.


-- 


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

[Bug bootstrap/41180] can not build gcc 4.4.1 on Snow Leopard Mac OS X 10.6

[howarth at nitro dot med dot uc dot edu]

--- Comment #17 from howarth at nitro dot med dot uc dot edu  2009-08-31 
18:04 ---
Mike,
   No, there isn't any host cases for i[[3456789]]86-*-darwin* in that section
of configure.ac only...

 powerpc-*-darwin*)
   host_makefile_frag="config/mh-ppc-darwin"
   ;;

Interestingly, while Apple's gcc 4.2.1 has a mh-x86-darwin in this construct, a
mh-x86-darwin file was never submitted for FSF gcc, FYI. I'll test this code
later this week after I get my hands on the necessary fink autoconf 2.64
package to regenerate the topl-evel configure. FYI, we had that in fink but
regressed it out for 2.63 because it was breaking too many other packages.


-- 


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

[Bug fortran/41198] gfortran 4.5 does not produce "Warning: Deleted feature: GOTO at (1) jumps to END of construct at (2)"

[michael dot a dot richmond at nasa dot gov]

--- Comment #2 from michael dot a dot richmond at nasa dot gov  2009-08-31 
18:00 ---
If I move "GOTO 50" outside of the block, gfortran 4.5 correctly gives the
message "Warning: Label at (1) is not in the same block as the GOTO statement
at (2)", but gfortran 4.3 and 4.4 give no message.


-- 


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

[Bug bootstrap/41180] can not build gcc 4.4.1 on Snow Leopard Mac OS X 10.6

[mrs at apple dot com]

--- Comment #16 from mrs at apple dot com  2009-08-31 17:37 ---
Oops, I mean #12 and #13.  For #13, make sure there isn't an existing entry
already.  If there is, the code should be added to it.


-- 


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

[Bug bootstrap/41180] can not build gcc 4.4.1 on Snow Leopard Mac OS X 10.6

[mrs at apple dot com]

--- Comment #15 from mrs at apple dot com  2009-08-31 17:35 ---
#13 looks fine.  #14 needs a build to confirm it works.  I've tested the style
of #14 in the gcc-4.2.1 tree and it works as expected.


-- 


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

[Bug libstdc++/41058] FAIL: ext/pb_ds/regression/hash_data_map_rand.cc

[jakub at gcc dot gnu dot org]

--- Comment #24 from jakub at gcc dot gnu dot org  2009-08-31 17:17 ---
If you think it is a linker bug, try to see if the LSDA pointer in readelf -wf
dump is correct when you link with --traditional-format.  And, file a binutils
bugreport and attach everything needed to reproduce it there.  I don't have
access to alpha, so would need something reproduceable with cross-binutils.


-- 


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

[Bug libstdc++/41058] FAIL: ext/pb_ds/regression/hash_data_map_rand.cc

[ubizjak at gmail dot com]

--- Comment #23 from ubizjak at gmail dot com  2009-08-31 17:11 ---
Perhaps Jakub can help from here...


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu dot org


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

[Bug libstdc++/41058] FAIL: ext/pb_ds/regression/hash_data_map_rand.cc

[ubizjak at gmail dot com]

--- Comment #22 from ubizjak at gmail dot com  2009-08-31 16:56 ---
Digging deeper, it smells like a linker error, at least on alpha (please note
that I used -static for final linking to ease debugging a bit):

FDE that corresponds to
_ZN10__gnu_pbds6detail15gp_ht_map_data_INS_4test10basic_typeES3_NS2_4hashESt8equal_toIS3_EN9__gnu_cxx15throw_allocatorIS3_EELb0ENS2_27direct_mod_range_hashing_t_IS9_EENS2_21quadratic_probe_fn_t_IS3_S9_EENS_27hash_standard_resize_policyINS2_25hash_prime_size_policy_t_ENS2_33hash_load_check_resize_trigger_t_IS9_Lm1ELm8ELm1ELm2ELb1EEELb1EmEEEC2ERKSJ_

is defined as:

$LSFDE1017:
.4byte  $LEFDE1017-$LASFDE1017
$LASFDE1017:
.4byte  $LASFDE1017-$Lframe1
.4byte  $LFB5855-.
.4byte  $LFE5855-$LFB5855
.uleb128 0x4
>>  .4byte  $LLSDA5855-.
.byte   0x4
.4byte  $LCFI1142-$LFB5855
.byte   0xe
.uleb128 0x40
.byte   0x4

and corresponding LSDA:

$LLSDA5855:
.byte   0xff
.byte   0x9b
.uleb128 $LLSDATT5855-$LLSDATTD5855
$LLSDATTD5855:
.byte   0x1
.uleb128 $LLSDACSE5855-$LLSDACSB5855
$LLSDACSB5855:
.uleb128 $LEHB373-$LFB5855
.uleb128 $LEHE373-$LEHB373
.uleb128 $L2169-$LFB5855
.uleb128 0x0

Now, liker links LSDA into FDE as:

(gdb) x/32cx fde
0x12019e770:0x340x000x000x000xf40x1a0x000x00
0x12019e778:0xc80x110xe70xff0x880x020x000x00
0x12019e780:0x040x840xcc0x010x000x500x0e0x40
0x12019e788:0x580x8e0x020x8b0x050x890x070x58

So, linker puts 0x0001cc84 at PC 0x12019e781.

Adding both together (as marked by ">>" above), we get 0x1201bb405.

This value is wrong, LSDA is located at 0x1201bb3f4 (see comment #21).

So, linker is perhaps creating address, relative to start of FDE instead of
current address.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |


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

[Bug rtl-optimization/25742] Internal compiler error in gen_rtx_SUBREG

[eric dot weddington at atmel dot com]

--- Comment #7 from eric dot weddington at atmel dot com  2009-08-31 16:55 
---
Closing bug as WORKSFORME, as it now know to work on four different release
branches of version 4.


-- 

eric dot weddington at atmel dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Known to work|4.1.2 4.2.0 |4.1.2 4.2.0 4.3.2 4.4.0
 Resolution||WORKSFORME


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

[Bug fortran/41200] allocate: improve a compiler error message for an invalid Fortran code

[kargl at gcc dot gnu dot org]

--- Comment #1 from kargl at gcc dot gnu dot org  2009-08-31 16:54 ---


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


-- 

kargl at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug fortran/41197] ICE with ALLOCATE and nonscalar STAT= variable

[kargl at gcc dot gnu dot org]

--- Comment #1 from kargl at gcc dot gnu dot org  2009-08-31 16:54 ---
*** Bug 41200 has been marked as a duplicate of this bug. ***


-- 

kargl at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jdelia at intec dot unl dot
   ||edu dot ar


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

[Bug middle-end/41193] [4.5 Regression] slow compilation with graphite

[spop at gcc dot gnu dot org]

-- 

spop at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |spop at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-08-31 16:47:18
   date||


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

[Bug c++/41131] [4.3 Regression] non-lvalue in unary `&' wrongly accepted

[jakub at gcc dot gnu dot org]

--- Comment #11 from jakub at gcc dot gnu dot org  2009-08-31 16:45 ---
*** Bug 40224 has been marked as a duplicate of this bug. ***


-- 


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

[Bug c++/40224] [4.3/4.4/4.5 regression] g++ Accepting invalid code

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2009-08-31 16:45 ---


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


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE


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

[Bug fortran/41200] New: allocate: improve a compiler error message for an invalid Fortran code

[jdelia at intec dot unl dot edu dot ar]

The following sample is an invalid Fortran code although the compiler gives an
ICE error message. 

Perhaps, the compiler error message in this case could be improved, e.g. tell
what we are doing wrong. 

Regards,
Jorge.
--
CIMEC-INTEC, http://www.cimec.org.ar/
UNL-CONICET, Guemes 3450, 3000-Santa Fe, ARGENTINA
ph: +54-342-451.15.94, extension 1018

--

! $ cat /proc/version
!   Linux version 2.6.27.30-170.2.82.fc10.i686
!   (mockbu...@xenbuilder4.fedora.phx.redhat.com)
!   (gcc version 4.3.2 20081105 (Red Hat 4.3.2-7) (GCC) )
!   #1 SMP Mon Aug 17 08:38:59 EDT 2009
!
! $ which gfortran
!   /usr/local/gfortran/bin/gfortran
!
! $ gfortran --version
!   GNU Fortran (GCC) 4.3.2 20081105 (Red Hat 4.3.2-7)
!   Copyright (C) 2008 Free Software Foundation, Inc.
!
! $ gfortran -o is_an_ice.exe is_an_ice.f90
!   is_an_ice.f90: In function 'is_an_ice':
!   is_an_ice.f90:21: internal compiler error: Segmentation fault
!   Please submit a full bug report,
!   with preprocessed source if appropriate.
!   See  for instructions.
!
program is_an_ice
  integer, dimension (4) :: ier = 0
  integer, dimension (:), allocatable :: a
  integer :: n = 16
 !allocate (a (n), stat = ier (1)) ! A  valid Fortran line
  allocate (a (n), stat = ier) ! and an invalid Fortran one
  print *, "allocated (a) : ", allocated (a)
end program is_an_ice


-- 
   Summary: allocate: improve a compiler error message for an
invalid Fortran code
   Product: gcc
   Version: 4.3.2
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jdelia at intec dot unl dot edu dot ar


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

[Bug ada/41100] [4.4 regression] Unchecked_Deallocation causes double-free errors

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P4


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

[Bug c++/41127] [4.4/4.5 regression] unnamed bitfield declaration parser regression

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2009-08-31 16:33 ---
Yeah, I'm afraid we can't parse definitely when we see : after enum identifier,
if : isn't followed by type-specifier-seq, we should return NULL.


-- 


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

[Bug fortran/41198] gfortran 4.5 does not produce "Warning: Deleted feature: GOTO at (1) jumps to END of construct at (2)"

[kargl at gcc dot gnu dot org]

--- Comment #1 from kargl at gcc dot gnu dot org  2009-08-31 15:43 ---
(In reply to comment #0)
> The following program produces a warning message in gfortran 4.3 and 4.4, but
> not 4.5. I believe it produced a warning message in early versions of 4.5.
> 
> PROGRAM test
> IF(.TRUE.) THEN
>   GOTO 50
> 50 ENDIF
> END PROGRAM test
> 

I believe that 4.3 and 4.4 had a bug.  Gfortran 4.5 is doing the right
thing.  The deleted feature is 

  (2) Branching to an END IF statement from outside its block.
  In Fortran 77, and for consistency also in Fortran 90, it was
  possible to branch to an END IF statement from outside the IF
  construct; this has been deleted.  A similar result can be
  achieved by branching to a CONTINUE statement that is immediately
  after the END IF statement.

Your GOTO 50 is inside the its block.  I also believe that there was
a long thread in fort...@gcc about this (non)feature.  I'll see if 
I can find it.


-- 


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

[Bug middle-end/40106] Time increase for the Polyhedron test air.f90 due to bad optimization

[rguenther at suse dot de]

--- Comment #27 from rguenther at suse dot de  2009-08-31 15:23 ---
Subject: Re:  Time increase for the Polyhedron test
 air.f90 due to bad optimization

On Mon, 31 Aug 2009, jv244 at cam dot ac dot uk wrote:

> --- Comment #26 from jv244 at cam dot ac dot uk  2009-08-31 15:20 ---
> (In reply to comment #25)
> > -  if (npx[(integer(kind=8)) i + -1] + 
> > 1 >
> > j)
> > +  if (NON_LVALUE_EXPR
> >  >= j)> where NON_LVALUE_EXPR appear when 
> > the test is compiled without
> > -fno-strict-overflow.
> 
> I wonder if this is a case where the optimizers would benefit from exploiting
> the fact that in Fortran integers can never overflow in a valid program ?

In fact it does with -fstrict-overflow.

Richard.


-- 


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

[Bug middle-end/40106] Time increase for the Polyhedron test air.f90 due to bad optimization

[jv244 at cam dot ac dot uk]

--- Comment #26 from jv244 at cam dot ac dot uk  2009-08-31 15:20 ---
(In reply to comment #25)
> -  if (npx[(integer(kind=8)) i + -1] + 1 >
> j)
> +  if (NON_LVALUE_EXPR
>  >= j)> where NON_LVALUE_EXPR appear when the 
> test is compiled without
> -fno-strict-overflow.

I wonder if this is a case where the optimizers would benefit from exploiting
the fact that in Fortran integers can never overflow in a valid program ?


-- 


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

[Bug middle-end/40106] Time increase for the Polyhedron test air.f90 due to bad optimization

[dominiq at lps dot ens dot fr]

--- Comment #25 from dominiq at lps dot ens dot fr  2009-08-31 15:04 ---
If I compare the results of -fdump-tree-original for the first 2 cases of
comment #21 I get:

[ibook-dhum] test/dbg_air% gfc -m64 -O2 -funsafe-math-optimizations
-fdump-tree-original air_db.f90
[ibook-dhum] test/dbg_air% mv air_db.f90.003t.original
air_db.f90.003t.original-no
[ibook-dhum] test/dbg_air% gfc -m64 -O2 -funsafe-math-optimizations
-fno-strict-overflow -fdump-tree-original air_db.f90
[ibook-dhum] test/dbg_air% diff -u air_db.f90.003t.original
air_db.f90.003t.original-no
--- air_db.f90.003t.original2009-08-31 17:01:34.0 +0200
+++ air_db.f90.003t.original-no 2009-08-31 17:00:39.0 +0200
@@ -548,7 +548,7 @@
   logical(kind=4) D.1668;

   ict = (integer(kind=4)) (ict + 1);
-  if (npx[(integer(kind=8)) i + -1] + 1 >
j)
+  if (NON_LVALUE_EXPR
 >= j)
 {
   ddx[((integer(kind=8)) ict +
(integer(kind=8)) k * 150) + -151] = xp1[((integer(kind=8)) (ict + 1) +
(integer(kind=8)) k * 150) + -151] - xp1[((integer(kind=8)) ict +
(integer(kind=8)) k * 150) + -151];
 }
@@ -621,7 +621,7 @@
   logical(kind=4) D.1680;

   ict = (integer(kind=4)) (ict + 1);
-  if (npy[(integer(kind=8)) i + -1] + 1 >
j)
+  if (NON_LVALUE_EXPR
 >= j)
 {
   ddy[((integer(kind=8)) k +
(integer(kind=8)) ict * 150) + -151] = yp1[((integer(kind=8)) k +
((integer(kind=8)) ict + 1) * 150) + -151] - yp1[((integer(kind=8)) k +
(integer(kind=8)) ict * 150) + -151];
 }

where NON_LVALUE_EXPR appear when the test is compiled without
-fno-strict-overflow.


-- 


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

[Bug testsuite/41199] New: gcc.dg/20081223-1.c should be in gcc.dg/lto/

[rguenth at gcc dot gnu dot org]

Without LTO support the testcase fails like

FAIL: gcc.dg/20081223-1.c  (test for errors, line 5)
FAIL: gcc.dg/20081223-1.c (test for excess errors)


-- 
   Summary: gcc.dg/20081223-1.c should be in gcc.dg/lto/
   Product: gcc
   Version: lto
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org


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

[Bug c++/41153] [4.4 Regression] ICE in building Qt4 src/core

[jakub at gcc dot gnu dot org]

--- Comment #9 from jakub at gcc dot gnu dot org  2009-08-31 14:32 ---
The problem is that the optimization saving/restoring infrastructure seems to
ignore OVERRIDE_OPTIONS.  i386 OPTIMIZATION_OPTIONS sets flag_pcc_struct_return
to 2 and expects OVERRIDE_OPTIONS to set it to 0 resp. 1 if it is still 2, but
as OVERRIDE_OPTIONS isn't called, it remains set to 2, which is treated as if
it was 1.


-- 


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

[Bug fortran/41198] New: gfortran 4.5 does not produce "Warning: Deleted feature: GOTO at (1) jumps to END of construct at (2)"

[michael dot a dot richmond at nasa dot gov]

The following program produces a warning message in gfortran 4.3 and 4.4, but
not 4.5. I believe it produced a warning message in early versions of 4.5.

PROGRAM test
IF(.TRUE.) THEN
  GOTO 50
50 ENDIF
END PROGRAM test


-- 
   Summary: gfortran 4.5 does not produce "Warning: Deleted feature:
GOTO at (1) jumps to END of construct at (2)"
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: michael dot a dot richmond at nasa dot gov


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

[Bug fortran/41197] New: ICE with ALLOCATE and nonscalar STAT= variable

[burnus at gcc dot gnu dot org]

Reported by Jorge at http://gcc.gnu.org/ml/fortran/2009-08/msg00474.html

integer, dimension (4) :: ier = 0
integer, dimension (:), allocatable :: a
allocate (a (16), stat = ier)
end

Gives a segfault with GCC 4.1 to 4.5. With the current trunk, valgrind shows:

==26026== Invalid read of size 4
==26026==at 0x533591: gfc_conv_scalarized_array_ref (trans-array.c:2477)
==26026==by 0x533CA4: gfc_conv_array_ref (trans-array.c:2527)
==26026==  Address 0x188 is not stack'd, malloc'd or (recently) free'd
test.f90: In function 'MAIN__':
test.f90:1:0: internal compiler error: Segmentation fault


-- 
   Summary: ICE with ALLOCATE and nonscalar STAT= variable
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org


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

[Bug target/41156] [4.4/4.5 Regression] zlib segfault in inflate_table() compiled w/ -O -msse2 ftree-vectorize

[hjl dot tools at gmail dot com]

--- Comment #3 from hjl dot tools at gmail dot com  2009-08-31 13:51 ---
(In reply to comment #2)
> Why is this considered a regression?
> 

It is a regression for PR 32893, which was fixed by disabling
vectorizer on local variables requiring > 4byte alignment since
we couldn't realign the stack at the time to support 4byte
incoming stack. With automatic stack alignment, this restricting
was removed. But since we assume incoming stack is 16byte, we
don't realign the stack. When incoming stack is 4 byte aligned,
we get segfault.


-- 


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

[Bug middle-end/40106] Time increase for the Polyhedron test air.f90 due to bad optimization

[dominiq at lps dot ens dot fr]

--- Comment #24 from dominiq at lps dot ens dot fr  2009-08-31 13:06 ---
(In reply to comment #23)
> Aren't these compile lines identical?
Apparently no, -funsafe-math-optimizations turns on optimization(s) that cannot
be undone by

-fno-signed-zeros -fno-trapping-math -fno-associative-math -fno-reciprocal-math

> I meant that you should use...
>
> -fno-signed-zeros -fno-trapping-math -fassociative-math -freciprocal-math
>

with commented write:

ibook-dhum] lin/test% gfc -m64 -O2 -fno-signed-zeros -fno-trapping-math
-fassociative-math -freciprocal-math air_db.f90
[ibook-dhum] lin/test% time a.out > /dev/null
6.194u 0.017s 0:06.21 99.8% 0+0k 0+1io 0pf+0w

with write:

[ibook-dhum] lin/test% gfc -m64 -O2 -fsigned-zeros -ftrapping-math
-fassociative-math -freciprocal-math air_db.f90
f951: warning: -fassociative-math disabled; other options take precedence
[ibook-dhum] lin/test% time a.out > /dev/null
6.306u 0.018s 0:06.33 99.6% 0+0k 0+2io 0pf+0w

> instead and work through all of the possible combinations with the inverse
> forms -fsigned-zeros, -ftrapping-math, -fno-associative-math and
> -fno-reciprocal-math which is 16 combinations.

I had no intention to try the 16 combinations as they are ineffective, the key
optimization being hidden behind funsafe-math-optimization with all the
explicit optimization disabled.  As said in comment #21 the other key option is
-fstrict-overflow. 

I know that all these facts do not make sense, but if you have doubts you can
redo the tests yourself.
As a side comment it would be nice for debugging purpose that the options
combinations of sub-options do not have hidden optimizations (yes I know there
a sentence about that in the manual).


-- 


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

[Bug c++/41153] [4.4 Regression] ICE in building Qt4 src/core

[rguenth at gcc dot gnu dot org]

--- Comment #8 from rguenth at gcc dot gnu dot org  2009-08-31 12:45 ---
Confirmed.

class QString { };
QString fixString(QString string);
static QString fixPathToLocalOS(const QString &in) 
{ 
  return fixString(in);
}
void __attribute__((__optimize__ ("0")))
foo(void) { }
void runQMake(QString pfile)
{ 
  fixPathToLocalOS(pfile);
}


triggered by __attribute__((__optimize__ ("0"))) on the unrelated function foo.

Mike, this is yours.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||gnu at the-meissners dot org
   Keywords||ice-on-valid-code
  Known to fail||4.4.1
  Known to work||4.3.4 4.5.0
Summary|ICE in building Qt4 src/core|[4.4 Regression] ICE in
   ||building Qt4 src/core
   Target Milestone|--- |4.4.2


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

[Bug c/41196] New: The use of ARM NEON vshll_n_u8 intrinsic results in compile error on valid code

[siarhei dot siamashka at gmail dot com]

When using vshll_n_u8 intrinsic, gcc 4.4.1 incorrectly rejects shift operand
having value >= 8, claiming that it is out of range.

When using the following test code
/*/
#include 
uint16x8_t test_vshll_n_u8 (uint8x8_t a)
{
return vshll_n_u8(a, 8);
}
/*/



Test with gcc 4.4.1:
# gcc -c -O2 -mcpu=cortex-a8 -mfpu=neon -mfloat-abi=softfp -fomit-frame-pointer
test.c
test.c: In function ‘test_vshll_n_u8’:
test.c:6: error: constant out of range



It used to work fine with cs2007q3:
# gcc -c -O2 -mcpu=cortex-a8 -mfpu=neon -mfloat-abi=softfp -fomit-frame-pointer
test.c
# objdump -d test.o

test.o: file format elf32-littlearm

Disassembly of section .text:

 :
   0:   ec410b17vmovd7, r0, r1
   4:   f3b26307vshll.i8q3, d7, #8
   8:   ec510b16vmovr0, r1, d6
   c:   ec532b17vmovr2, r3, d7
  10:   e12fff1ebx  lr


-- 
   Summary: The use of ARM NEON vshll_n_u8 intrinsic results in
compile error on valid code
   Product: gcc
   Version: 4.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: siarhei dot siamashka at gmail dot com
 GCC build triplet: armv4tl-softfloat-linux-gnueabi
  GCC host triplet: armv4tl-softfloat-linux-gnueabi
GCC target triplet: armv4tl-softfloat-linux-gnueabi


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

[Bug c++/41153] ICE in building Qt4 src/core

[rguenth at gcc dot gnu dot org]

--- Comment #7 from rguenth at gcc dot gnu dot org  2009-08-31 12:06 ---
Reducing (seems to work with 4.5).


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |NEW
 Ever Confirmed|0   |1
 GCC target triplet||x86_64-*-*
   Last reconfirmed|-00-00 00:00:00 |2009-08-31 12:06:57
   date||


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

[Bug c++/41153] ICE in building Qt4 src/core

[t66667 at gmail dot com]

--- Comment #6 from t7 at gmail dot com  2009-08-31 11:16 ---
Created an attachment (id=18455)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18455&action=view)
saves


-- 


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

[Bug c++/41153] ICE in building Qt4 src/core

[t66667 at gmail dot com]

--- Comment #5 from t7 at gmail dot com  2009-08-31 11:15 ---
Created an attachment (id=18454)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18454&action=view)
Preprocessed test case.


-- 


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

[Bug c++/41153] ICE in building Qt4 src/core

[t66667 at gmail dot com]

--- Comment #4 from t7 at gmail dot com  2009-08-31 11:08 ---
g++ --save-temps -c -omain.o -O -I. -Igenerators -Igenerators/unix
-Igenerators/win32 -Igenerators/mac
-IE:\msys\1.0\qt-all-opensource-src-4.5.2/include
-IE:\msys\1.0\qt-all-opensource-src-4.5.2/include/QtCore
-IE:\msys\1.0\qt-all-opensource-src-4.5.2/include
-IE:\msys\1.0\qt-all-opensource-src-4.5.2/include/QtCore
-IE:\msys\1.0\qt-all-opensource-src-4.5.2/src/corelib/global
-IE:\msys\1.0\qt-all-opensource-src-4.5.2/include/QtScript
-IE:\msys\1.0\qt-all-opensource-src-4.5.2/mkspecs/win32-g++ -DQT_NO_TEXTCODEC
-DQT_NO_UNICODETABLES -DQT_LITE_COMPONENT -DQT_NO_PCRE -DQT_NODLL -DQT_NO_STL
-DQT_NO_COMPRESS -DUNICODE -DHAVE_QCONFIG_CPP -DQT_BUILD_QMAKE -DQT_NO_THREAD
-DQT_NO_QOBJECT -DQT_NO_GEOM_VARIANT -DQT_NO_DATASTREAM
-DQMAKE_OPENSOURCE_EDITION main.cpp
In file included from
E:\msys\1.0\qt-all-opensource-src-4.5.2/include/QtCore/qstring.h:2,
 from
E:\msys\1.0\qt-all-opensource-src-4.5.2/include/QtCore/../../src/corelib/io/qiodevice.h:51,
 from
E:\msys\1.0\qt-all-opensource-src-4.5.2/include/QtCore/qiodevice.h:2,
 from
E:\msys\1.0\qt-all-opensource-src-4.5.2/include/QtCore/../../src/corelib/io/qdatastream.h:46,
 from
E:\msys\1.0\qt-all-opensource-src-4.5.2/include/QtCore/qdatastream.h:2,
 from
E:\msys\1.0\qt-all-opensource-src-4.5.2/include/QtCore/../../src/corelib/tools/qstringlist.h:47,
 from
E:\msys\1.0\qt-all-opensource-src-4.5.2/include/QtCore/qstringlist.h:2,
 from project.h:46,
 from main.cpp:43:
E:\msys\1.0\qt-all-opensource-src-4.5.2/include/QtCore/../../src/corelib/tools/qstring.h:
In member function 'QCharRef::operator QChar() const':
E:\msys\1.0\qt-all-opensource-src-4.5.2/include/QtCore/../../src/corelib/tools/qstring.h:782:
internal compiler error: in tree_nrv, at tree-nrv.c:143
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make: *** [main.o] Error 1


-- 


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

[Bug middle-end/41193] [4.5 Regression] slow compilation with graphite

[jv244 at cam dot ac dot uk]

--- Comment #4 from jv244 at cam dot ac dot uk  2009-08-31 10:50 ---
(In reply to comment #3)
> On the 4.4 branch with -fgraphite?  

yes, that is correct, i.e. with the 4.4 branch the 

gfortran -fgraphite -c -O2 -ffast-math -funroll-loops -ftree-vectorize
-march=native -ftime-report tmp.f90

command (thus including -fgraphite) takes about 4s seconds, while the same
command line takes about 371s with 4.5.

as explained by Sebastian in PR40965, this might be due to the fact that
graphite recognizes now more loop constructs.


-- 


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

[Bug fortran/40996] [F03] ALLOCATABLE scalars

[janus at gcc dot gnu dot org]

--- Comment #6 from janus at gcc dot gnu dot org  2009-08-31 10:36 ---
r151240 implements basic allocatable scalars. Allocatable scalar components are
still missing.


-- 


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

[Bug fortran/40996] [F03] ALLOCATABLE scalars

[janus at gcc dot gnu dot org]

--- Comment #5 from janus at gcc dot gnu dot org  2009-08-31 10:22 ---
Subject: Bug 40996

Author: janus
Date: Mon Aug 31 10:22:32 2009
New Revision: 151240

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151240
Log:
2009-08-31  Janus Weil  

PR fortran/40996
* check.c (gfc_check_allocated): Implement allocatable scalars.
* resolve.c (resolve_allocate_expr,resolve_fl_var_and_proc): Ditto.
* trans-intrinsic.c (gfc_conv_allocated): Ditto.

2009-08-31  Janus Weil  

PR fortran/40996
* gfortran.dg/allocatable_scalar_1.f90: New.
* gfortran.dg/allocatable_scalar_2.f90: Renamed from finalize_9.f03.
* gfortran.dg/finalize_9.f03: Renamed to allocatable_scalar_2.f90.
* gfortran.dg/proc_ptr_comp_pass_4.f90: Modified.


Added:
trunk/gcc/testsuite/gfortran.dg/allocatable_scalar_1.f90
trunk/gcc/testsuite/gfortran.dg/allocatable_scalar_2.f90   (contents, props
changed)
  - copied, changed from r151238,
trunk/gcc/testsuite/gfortran.dg/finalize_9.f03
Removed:
trunk/gcc/testsuite/gfortran.dg/finalize_9.f03
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/check.c
trunk/gcc/fortran/resolve.c
trunk/gcc/fortran/trans-intrinsic.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/proc_ptr_comp_pass_4.f90

Propchange: trunk/gcc/testsuite/gfortran.dg/allocatable_scalar_2.f90
('svn:mergeinfo' added)


-- 


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

[Bug middle-end/41193] [4.5 Regression] slow compilation with graphite

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2009-08-31 10:12 ---
On the 4.4 branch with -fgraphite?  Or are you complaining about the 4s vs. 8s
without -fgraphite?  In which case the bug summary is misleading (also you
didn't build trunk with --enable-checking=release, so that number is
meaningless
anyway)


-- 


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

[Bug tree-optimization/41089] [4.5 Regression] r147980 (New SRA) breaks stdargs

[jamborm at gcc dot gnu dot org]

--- Comment #3 from jamborm at gcc dot gnu dot org  2009-08-31 09:03 ---
I'm back from vacation and aware of this problem.  I will look at it once I am
through all the mail and similar stuff (provided I don't find anything more
urgent) which will take a while.


-- 


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

[Bug driver/39356] assembler isn't called

[rainer at emrich-ebersheim dot de]

--- Comment #18 from rainer at emrich-ebersheim dot de  2009-08-31 08:11 
---
Subject: Re:  assembler isn't called

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

ktietz at gcc dot gnu dot org schrieb:
> --- Comment #17 from ktietz at gcc dot gnu dot org  2009-08-30 08:35 
> ---
> (In reply to comment #16)
>> (In reply to comment #15)
>>> Is there a chance that we get this fixed soon?
>>>
>>> Rainer
>>>
>> Well, I would like to fix this. Better now then later. But I couldn't find 
>> the
>> real reason for this issue. The patch above solved the problem on 4.4.0 
>> branch
>> some time ago, but now it seems to be a different issue. But AFAICT is is
>> related to chkstk/alloca here.
>>
>> Cheers,
>> Kai
>>
> 
> Could you please test if issue still exist for trunk and current 4.4 branch. 
> It
> could be a duplicate of PR/41184.
> 
> Cheers,
> Kai
> 
> 
I will try, but probably not before Wednesday.

Cheers,
Rainer

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkqbhZMACgkQoUhjsh59BL5I8gCgiofn0d3yJ1v7DnkIH9hGr3y8
DzAAn1aDUGlbuS64F44c/p7woSY5J5oI
=f36P
-END PGP SIGNATURE-


-- 


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

[Bug target/41156] [4.4/4.5 Regression] zlib segfault in inflate_table() compiled w/ -O -msse2 ftree-vectorize

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2009-08-31 08:10 ---
Why is this considered a regression?


-- 


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

[Bug c++/41194] __attribute__ ((__gnu_inline__)) yields undefined reference when compiled with -O0, but not with -O1

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2009-08-31 08:05 ---
That's correct.  In C++ gnu_inline attribute always means the GNU C extern
inline function, i.e. it is inlined if deemed desirable and otherwise you must
provide an external definition of the function.
If you don't do this, don't use gnu_inline attribute...


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug middle-end/41193] [4.5 Regression] slow compilation with graphite

[jv244 at cam dot ac dot uk]

--- Comment #2 from jv244 at cam dot ac dot uk  2009-08-31 07:37 ---
Compile time is about 4s with the 4.4 branch, so I'll mark it as a regression.


-- 

jv244 at cam dot ac dot uk changed:

   What|Removed |Added

  Known to fail||4.5.0
  Known to work||4.4.2
Summary|slow compilation with   |[4.5 Regression] slow
   |graphite|compilation with graphite
   Target Milestone|--- |4.5.0


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