date:20070525

[Bug target/31975] [4.3 Regression] segfault in try_split on mips during bootstrap

2007-05-25 Thread daney at gcc dot gnu dot org



--- Comment #13 from daney at gcc dot gnu dot org  2007-05-25 08:16 ---
Created an attachment (id=13610)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13610&action=view)
Proposed patch.

I will bootstrap and test the attached patch.  It allows my cross build to
complete.


-- 

daney at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug target/31975] [4.3 Regression] segfault in try_split on mips during bootstrap

2007-05-25 Thread pinskia at gcc dot gnu dot org



--- Comment #14 from pinskia at gcc dot gnu dot org  2007-05-25 08:32 
---
RS6000, ia64, and sh does this:
  /* Mark the end of the (empty) prologue.  */
  emit_note (NOTE_INSN_PROLOGUE_END);


You might want to use that note also for MIPS.


-- 


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

[Bug middle-end/32050] [4.3 Regression] ICE(segfault) with -m32 -ftree-vectorize in vrp_evaluate_conditional_warnv

2007-05-25 Thread burnus at gcc dot gnu dot org



--- Comment #1 from burnus at gcc dot gnu dot org  2007-05-25 09:31 ---
Works for me since today.


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WORKSFORME


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

[Bug middle-end/32077] New: [Regression 4.3] Profile-use: ICE: Segmentation fault

2007-05-25 Thread burnus at gcc dot gnu dot org

$ gfortran -fprofile-generate -march=opteron -ffast-math -funroll-loops
-ftree-vectorize -msse3 -O3 gas_dyn.f90
$ ./a.out
[...]
$ gfortran -fprofile-use -march=opteron -ffast-math -funroll-loops
-ftree-vectorize -msse3 -O3 gas_dyn.f90
gas_dyn.f90: In function 'eos':
gas_dyn.f90:360: internal compiler error: Segmentation fault

This is with http://www.polyhedron.co.uk/pb05/polyhedron_benchmark_suite.html

This is on x86_64-unknown-linux-gnu with gcc-Version 4.3.0 20070525.

Working with: 2007-05-17
Failing since: 2007-05-18


-- 
   Summary: [Regression 4.3] Profile-use: ICE: Segmentation fault
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: middle-end
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=32077

[Bug other/32078] New: Make FAILURE in 4.3.0 - `CXXFLAGS' has changed error causes "libltdl: No such file or directory"

2007-05-25 Thread rob1weld at aol dot com

Two problems - the second one is months old and affects 4.2.0 4.2.1 4.3.0


1) Make breaks due to "configure: error: `CXXFLAGS' has changed since the
previous run:"
   This did not happen yesterday, or the day before, ...


2) When make breaks (for _any_ reason, including the prior one) while building
   libjava any attempt to simply re-run make will fail since the Makefile
   does not fix the absence of the "libltdl" directory. It simply trys to
   change to "libltdl" without testing for it's existance and the dies.



# make 2>&1 | tee make_6b_log.txt

3 hours later


# grep -n Checking\ multilib\ configuration\ for\ libjava make_6a_log.txt
16963:Checking multilib configuration for libjava...


Screen output:

Checking multilib configuration for libjava...
mkdir -p -- i686-pc-linux-gnu/libjava
Configuring in i686-pc-linux-gnu/libjava
configure: creating cache ./config.cache
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking target system type... i686-pc-linux-gnu
...(Quite a few lines)
configure: configuring in classpath
configure: running /bin/sh
'/root/downloads/gcc-4_3-trunk/libjava/classpath/configure' --prefix=/usr 
'--cache-file=./config.cache' '--verbose' '--with-tune=athlon-xp'
'--prefix=/usr' '--enable-objc-gc' '--enable-concept-checks'
'--disable-multilib' '--with-gxx-include-dir=/usr/include/c++/4.3'
'--enable-libstdcxx-debug' '--enable-static' '--enable-shared'
'--enable-initfini-array' '--enable-__cxa_atexit' '--enable-threads=posix'
'--enable-version-specific-runtime-libs' '--enable-libssp'
'--enable-libmudflap' '--enable-libgomp' '--disable-werror' '--enable-nls'
'--with-included-gettext' '--enable-decimal-float' '--with-long-double-128'
'--enable-debug' '--enable-java-gc=boehm' '--with-x'
'--x-includes=/usr/X11R6/include' '--x-libraries=/usr/X11R6/lib'
'--enable-java-awt=gtk,xlib' '--enable-gtk-cairo' '--enable-qt-peer'
'--enable-xmlj' '--enable-gconf-peer' '--enable-tool-wrappers' '--with-gjdoc'
'--enable-portable-native-sync' '--enable-libgcj-multifile' '--with-stabs'
'--enable-hash-synchronization' '--enable-gc-debug' '--enable-interpreter'
'--with-system-zlib' '--enable-libada' '--with-tls' '--with-cpu=athlon-xp'
'--with-arch=athlon-xp'
'--enable-stage1-checking=assert,gc,misc,rtl,rtlflag,runtime'
'--enable-languages=c,ada,c++,fortran,java,objc,obj-c++'
'--program-transform-name=s,y,y,' '--with-target-subdir=i686-pc-linux-gnu'
'--build=i686-pc-linux-gnu' '--host=i686-pc-linux-gnu'
'--target=i686-pc-linux-gnu' '--srcdir=/root/downloads/gcc-4_3-trunk/libjava'
'CPPFLAGS=' 'CXXFLAGS=-g -O2 -D_GNU_SOURCE' 'CXX= /opt/gcc-4_3-build/./gcc/xgcc
-shared-libgcc -B/opt/gcc-4_3-build/./gcc -nostdinc++
-L/opt/gcc-4_3-build/i686-pc-linux-gnu/libstdc++-v3/src
-L/opt/gcc-4_3-build/i686-pc-linux-gnu/libstdc++-v3/src/.libs
-B/usr/i686-pc-linux-gnu/bin/ -B/usr/i686-pc-linux-gnu/lib/ -isystem
/usr/i686-pc-linux-gnu/include -isystem /usr/i686-pc-linux-gnu/sys-include'
'LDFLAGS=' 'build_alias=i686-pc-linux-gnu' 'host_alias=i686-pc-linux-gnu'
'target_alias=i686-pc-linux-gnu' --with-fastjar=jar --disable-tool-wrappers
--disable-load-library --disable-debug
--enable-default-toolkit=gnu.java.awt.peer.gtk.GtkToolkit
--with-vm-classes=/root/downloads/gcc-4_3-trunk/libjava:/opt/gcc-4_3-build/i686-pc-linux-gnu/libjava
--disable-core-jni --disable-examples --with-glibj=build --disable-plugin
--disable-qt-peer --without-escher --disable-Werror --enable-ltdl-convenience
--with-auxdir=/root/downloads/gcc-4_3-trunk --cache-file=.././config.cache
--srcdir=/root/downloads/gcc-4_3-trunk/libjava/classpath
configure: loading cache .././config.cache
configure: error: `CXXFLAGS' has changed since the previous run:
configure:   former value:  -g -O2  -D_GNU_SOURCE
configure:   current value: -g -O2 -D_GNU_SOURCE
configure: error: changes in the environment can compromise the build
configure: error: run `make distclean' and/or `rm .././config.cache' and start
over
configure: error: /bin/sh
'/root/downloads/gcc-4_3-trunk/libjava/classpath/configure' failed for
classpath
make[1]: *** [configure-target-libjava] Error 1
make[1]: Leaving directory `/opt/gcc-4_3-build'
make: *** [all] Error 2
# 


# grep -n CXXFLAGS make_6_log.txt
1468:true "AR_FLAGS=rc" "CC_FOR_BUILD=gcc" "CFLAGS=-g -fkeep-inline-functions"
"CXXFLAGS=-g -O2" "CFLAGS_FOR_$
4703:true "AR_FLAGS=rc" "CC_FOR_BUILD=/opt/gcc-4_3-build/./prev-gcc/xgcc
-B/opt/gcc-4_3-build/./prev-gcc/ -B/$
7969:true "AR_FLAGS=rc" "CC_FOR_BUILD=/opt/gcc-4_3-build/./prev-gcc/xgcc
-B/opt/gcc-4_3-build/./prev-gcc/ -B/$
10278:make "DESTDIR=" "RPATH_ENVVAR=LD_LIBRARY_PATH"
"TARGET_SUBDIR=i686-pc-linux-gnu" "bindir=/usr/bin" "dat$
12901:make "AR_FLAGS=rc" "CC_FOR_BUILD=gcc"
"CC_FOR_TARGET=/opt/gcc-4_3-build/./gcc/xgcc -B/opt/gcc-4_3-build$
13229:(cd debug && make CXXFLAGS='-g3 -O0' all)
13431:true "AR_FLAGS=rc" "CC_FOR_BUILD=gcc"
"CC_FOR_TARGET=/opt/gcc-4_3-build/./gcc/xgcc -B/opt/gcc-4_3-build$
13634:make "AR_FLAGS=rc" "CC_FOR_BUILD=gcc" "CFLAGS=

[Bug middle-end/32077] [Regression 4.3] Profile-use: ICE: Segmentation fault

2007-05-25 Thread burnus at gcc dot gnu dot org



--- Comment #1 from burnus at gcc dot gnu dot org  2007-05-25 09:53 ---
Zdenek, I think your patch caused the ICE, could you have a look?
http://gcc.gnu.org/ml/gcc-cvs/2007-05/msg00485.html

(Maybe I'm wrong about the patch, there were some other issues around that
time, which caused gas_dyn.f90 failures (e.g. with "-m32"), which were fixed
only yesterday.)

Working with: 2007-05-17, r124781
Failing since: 2007-05-18, r124816


Valgrind:

==28129== Conditional jump or move depends on uninitialised value(s)
==28129==at 0x7A3708: vrp_evaluate_conditional_warnv (tree-vrp.c:4814)
==28129==by 0x7A3DA9: vrp_evaluate_conditional (tree-vrp.c:4946)
==28129==by 0x77ED85: thread_across_edge (tree-ssa-threadedge.c:443)
==28129==by 0x79F3A3: vrp_finalize (tree-vrp.c:5860)
==28129==by 0x7A05CA: execute_vrp (tree-vrp.c:6011)
==28129==by 0x609FC0: execute_one_pass (passes.c:1067)
==28129==by 0x60A17B: execute_pass_list (passes.c:1119)
==28129==by 0x60A18D: execute_pass_list (passes.c:1120)
==28129==by 0x6D3E07: tree_rest_of_compilation (tree-optimize.c:406)
==28129==by 0x812AAF: cgraph_expand_function (cgraphunit.c:1086)
==28129==by 0x814F51: cgraph_optimize (cgraphunit.c:1155)
==28129==by 0x46708C: gfc_be_parse_file (f95-lang.c:307)


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rakdver at gcc dot gnu dot
   ||org


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

[Bug libgcj/32028] Make fails at gjdoc - gnu.classpath.tools.gjdoc.ParseException: unmatched input in line 1: @Retention(SOURCE) @Target(METHOD)

2007-05-25 Thread rob1weld at aol dot com



--- Comment #3 from rob1weld at aol dot com  2007-05-25 09:55 ---
Ran accros this interesting post, seems we've had this a while ...

gjdoc in libgcj
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19612


After some messing with trying to access the gjdoc SVN according to the above
advice from those links (without a password); I went elsehere.


Here are some programs I had already (from gcc 4.2.0 install);

# gcj --version
gcj (GCC) 4.2.0 20070501 (prerelease)
# gij --version
java version "1.4.2"
gij (GNU libgcj) version 4.2.0 20070501 (prerelease)


Here is what worked and what it looked like:


# wget ftp://ftp.gnu.org/gnu/classpath/gjdoc-0.7.8.tar.gz
# gunzip -d gjdoc-0.7.8.tar.gz
# tar -xf gjdoc-0.7.8.tar.gz
# cd gjdoc-0.7.8
# ./configure
...
checking if gij works... yes
checking for gcj... gcj -C
checking if gcj -C works... yes
configure: WARNING:
The build seems to be using gcj for bytecode generation.  Some
versions of gcj are known to produce bad bytecode.  See here for a
list of bugs that may be relevant:

http://gcc.gnu.org/bugzilla/buglist.cgi?component=java&keywords=wrong-code&order=default

At least bug 19921 is known to affect gjdoc (in Feb 2005).

You may want to set the environment variable JAVAC to an alternate
compiler, such as jikes, to make sure that you end up with valid
bytecode.
...
checking for antlr 2.7.1 or better... 2.7.6
checking for java.util.regex.Pattern class... yes
configure: creating ./config.status
config.status: creating gjdoc.sh
config.status: WARNING:  gjdoc.sh.in seems to ignore the --datarootdir setting
# make
# make install

works OK despite warnings.



Now getting this screen output:

make[4]: Leaving directory
`/opt/gcc-4_3-build/i686-pc-linux-gnu/libjava/classpath/lib'
Making all in doc
make[4]: Entering directory
`/opt/gcc-4_3-build/i686-pc-linux-gnu/libjava/classpath/doc'
Making all in api
make[5]: Entering directory
`/opt/gcc-4_3-build/i686-pc-linux-gnu/libjava/classpath/doc/api'
/bin/mkdir html > /dev/null 2>&1
/usr/local/bin/gjdoc \
-use \
-sourcepath
"../..:/root/downloads/gcc-4_3-trunk/libjava/classpath:/root/downloads/gcc-4_3-trunk/libjava/classpath/vm/reference:/root/downloads/gcc-4_3-trunk/libjava/classpath/external/w3c_dom:/root/downloads/gcc-4_3-trunk/libjava/classpath/external/sax"
\
-encoding UTF-8 \
-breakiterator \
-licensetext \
-linksource \
-splitindex \
-validhtml \
-d html \
-doctitle "GNU Classpath 0.94-pre" \
-windowtitle "GNU Classpath 0.94-pre Documentation" \
-header "GNU Classpath
(0.94-pre)" -footer "GNU Classpath
(0.94-pre)" \
-subpackages java:javax:org
WARNING: unknown modifier '@Retention(SOURCE)'
WARNING: unknown modifier '@Target(METHOD)'
WARNING: unknown modifier '@Retention(SOURCE)'
WARNING: unknown modifier '@Target({TYPE, FIELD, METHOD, PARAMETER,
CONSTRUCTOR, LOCAL_VARIABLE})'
WARNING: unknown modifier '@Documented'
WARNING: unknown modifier '@Retention(RUNTIME)'
ARGH! public
ARGH! static
ARGH! >
ARGH! S
ARGH! valueOf(Class
ARGH! String
ARGH! s)
Loading classes for package java.sql...
Loading classes for package java.lang...
Loading classes for package java.lang.reflect...
Loading classes for package java.lang.instrument...
Loading classes for package java.lang.ref...
Loading classes for package java.lang.annotation...
WARNING: unknown modifier '@Documented'
WARNING: unknown modifier '@Retention(RUNTIME)'
WARNING: unknown modifier '@Target(ANNOTATION_TYPE)'
WARNING: unknown modifier '@Documented'
WARNING: unknown modifier '@Retention(RUNTIME)'
WARNING: unknown modifier '@Documented'
WARNING: unknown modifier '@Retention(RUNTIME)'
WARNING: unknown modifier '@Target(ANNOTATION_TYPE)'
WARNING: unknown modifier '@Documented'
WARNING: unknown modifier '@Retention(RUNTIME)'
WARNING: unknown modifier '@Target(ANNOTATION_TYPE)'
Loading classes for package java.lang.management...
Loading classes for package java.text...
Loading classes for package java.applet...
Loading classes for package java.nio...
Loading classes for package java.nio.charset...


According to some web pages those errors are to be expected.

Which version _should_ we use so that we don't get any warnings or errors?


The "fix" for this bug is that gcc 4.2.0 and 4.2.1 main configure MUST test for
gjdoc version 0.7.7 _minimum_ and gcc 4.3.0 main configure MUST test for gjdoc
0.7.8 _minimum (a newer version, it easily available would be better).

A version that worked properly in directory ftp://ftp.gnu.org/gnu/classpath/
would be a good idea. Would you be allowed to do that Tom?

Thanks


-- 


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

[Bug c++/32080] New: Can goto a function try-block

2007-05-25 Thread andrew dot stubbs at st dot com

It should not be possible to jump into a function try-block.

The example from the standard, clause 15/2, is rejected properly:

void f() {
  goto l1;  // Ill-formed
  goto l2;  // Ill-formed
  try {
goto l1;// OK
goto l2;// Ill-formed
l1: ;
  } catch (...) {
l2: ;
goto l1;// Ill-formed
goto l2;// OK
  }
}

t.cxx: In function void f():
t.cxx:7: error: jump to label l1
t.cxx:2: error:   from here
t.cxx:7: error:   enters try block
t.cxx:9: error: jump to label l2
t.cxx:6: error:   from here
t.cxx:9: error:   enters catch block
t.cxx:9: error: jump to label l2
t.cxx:3: error:   from here
t.cxx:9: error:   enters catch block
t.cxx:7: error: jump to label l1
t.cxx:10: error:   from here
t.cxx:10: error:   enters try block

But, if the example is adjusted to use a *function* try-block, then it's a
different story:

void f()
try {
  goto l1;  // OK
  goto l2;  // Ill-formed
  l1: ;
} catch (...) {
  l2: ;
  goto l1;  // Ill-formed
  goto l2;  // OK
}

t.cxx: In function void f():
t.cxx:7: error: jump to label l2
t.cxx:4: error:   from here
t.cxx:7: error:   enters catch block

The jump into the catch block has been caught, but the jump into the try-block
has been missed.

I know that the standard does not explicitly say that you can't jump into a
_function_ try-block, but it does say you can't jump into a try-block, and this
is merely a variant. Certainly the motivation would be the same in both cases.


-- 
   Summary: Can goto a function try-block
   Product: gcc
   Version: 4.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: andrew dot stubbs at st dot com


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

[Bug testsuite/32076] "gcc.dg/tree-ssa/pr17141-1.c scan-tree-dump locp.*->i =" is the same name twice

2007-05-25 Thread rguenth at gcc dot gnu dot org



--- Comment #1 from rguenth at gcc dot gnu dot org  2007-05-25 10:36 ---
Confirmed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||janis at gcc dot gnu dot org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-05-25 10:36:46
   date||


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

[Bug c++/32081] New: Conflicting exception specifications not rejected in template specialization

2007-05-25 Thread andrew dot stubbs at st dot com

The following C++ code should not compile:

template 
void foo(T) throw (int);

template<>
void
foo (short) throw (short)
{
}

The change in exception specification, the throw, is not been detected. A
simple example without templates is rejected correctly.

The C++ standard discusses this in clause 15.4/2.


-- 
   Summary: Conflicting exception specifications not rejected in
template specialization
   Product: gcc
   Version: 4.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: andrew dot stubbs at st dot com


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

[Bug c/32079] [4.2 Regression] there seems to be a gcc optimization problem.

2007-05-25 Thread rguenth at gcc dot gnu dot org



--- Comment #1 from rguenth at gcc dot gnu dot org  2007-05-25 10:39 ---
This is undefined.  You dereference *pp before checking if it is a NULL
pointer.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug tree-optimization/31982] Missed forw prop with indirect ref and addr. (and char types or sizeof(type) == 1)

2007-05-25 Thread rguenth at gcc dot gnu dot org



--- Comment #3 from rguenth at gcc dot gnu dot org  2007-05-25 10:07 ---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.3.0


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

[Bug tree-optimization/31982] Missed forw prop with indirect ref and addr. (and char types or sizeof(type) == 1)

2007-05-25 Thread rguenth at gcc dot gnu dot org



--- Comment #3 from rguenth at gcc dot gnu dot org  2007-05-25 10:07 ---
Fixed.


--- Comment #4 from rguenth at gcc dot gnu dot org  2007-05-25 10:07 ---
Subject: Bug 31982

Author: rguenth
Date: Fri May 25 09:07:29 2007
New Revision: 125058

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125058
Log:
2007-05-24  Richard Guenther  <[EMAIL PROTECTED]>
Andrew Pinski  <[EMAIL PROTECTED]>

PR tree-optimization/31982
* tree-ssa-forwprop.c
(forward_propagate_addr_into_variable_array_index): Handle arrays
with element size one.

* gcc.dg/tree-ssa/forwprop-2.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/forwprop-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-forwprop.c


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.3.0


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

[Bug c/32079] New: [4.2 Regression] there seems to be a gcc optimization problem.

2007-05-25 Thread liqin at gcc dot gnu dot org

below c code will get "false" at -O0, -O1, -O3,
and get "true" at -O2, -Os.

#include 

typedef struct {
int aa;
int bb;
} test;

//test t1;

void foo (test **pp) 
{ 
if (((*pp)->bb != 0) && (*pp)) 
printf ("true\n");
else 
printf ("false\n");

printf ("finished.\n");
}

int main (void)
{
test *p;
p = NULL;
foo (&p);
return 0; 
}


-- 
   Summary: [4.2 Regression] there seems to be a gcc optimization
problem.
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: liqin at gcc dot gnu dot org
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: arm-elf


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

[Bug bootstrap/15212] [4.0/4.1/4.2/4.3 Regression] bootstrap fails on interix3

2007-05-25 Thread markus dot duft at salomon dot at



--- Comment #27 from markus dot duft at salomon dot at  2007-05-25 10:30 
---
(In reply to comment #25)
> Created an attachment (id=12808)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12808&action=view) [edit]
> patch (part 2 of 2) to fix this bug
> This patch (mh-interix.diff) and the previous one (interix-winnt.diff) let me
> successfully "make bootstrap" gcc-4.2-20061212 on Win2K/Interix3.5, without
> manual intervention, with the following configuration and no environment
> variables such as CFLAGS set:
> ...

Have you managed to build libstdc++v3? it gives me *lots* of errors. i managed
fixing a few (copying host_headers next to c++config.h for example, otherwise
it wont find those files...), but now i'm stuck...


-- 


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

[Bug other/32078] Make FAILURE in 4.3.0 - `CXXFLAGS' has changed error causes "libltdl: No such file or directory"

2007-05-25 Thread rob1weld at aol dot com



--- Comment #1 from rob1weld at aol dot com  2007-05-25 10:49 ---
Found an additional problem.

After all the stages are done and we are building the libraries in the "target
name directory" (EG: in _my_ case the directory is called "i686-pc-linux-gnu")
we must _always_ use "xgcc" and NOT "gcc" (the OS's compiler).

Correct?


Here is a bit of screen output:


make[2]: Leaving directory `/opt/gcc-4_3-build/i686-pc-linux-gnu/boehm-gc'
make[2]: Entering directory `/opt/gcc-4_3-build/i686-pc-linux-gnu/libobjc'
: make ; exec true "AR=ar" "AR_FLAGS=rc" "CC=/opt/gcc-4_3-build/./gcc/xgcc
-B/opt/gcc-4_3-build/./gcc/ -B/usr/i686-pc-linux-gnu/bin/
-B/usr/i686-pc-linux-gnu/lib/ -isystem /usr/i686-pc-linux-gnu/include -isystem
/usr/i686-pc-linux-gnu/sys-include" "CFLAGS=-O2 -g -O2 " "DESTDIR="
"LIBCFLAGS=-O2 -g -O2 " "EXTRA_OFILES=" 


That is OK.


Here is some more (from the build log):

# grep -A 4
/opt/gcc-4_3-build/i686-pc-linux-gnu/libjava/classpath/native/fdlibm
gcc-4_3-build/make_6*

gcc-4_3-build/make_6b_log.txt:make[5]: Entering directory
`/opt/gcc-4_3-build/i686-pc-linux-gnu/libjava/classpath/native/fdlibm'
gcc-4_3-build/make_6b_log.txt-if /bin/sh ../../libtool --mode=compile gcc
-DHAVE_CONFIG_H -I.
-I/root/downloads/gcc-4_3-trunk/libjava/classpath/native/fdlibm -I../../include
-O2 -g -O2  -MT dtoa.lo -MD -MP -MF ".deps/dtoa.Tpo" -c -o dtoa.lo
/root/downloads/gcc-4_3-trunk/libjava/classpath/native/fdlibm/dtoa.c; \
gcc-4_3-build/make_6b_log.txt-  then mv -f ".deps/dtoa.Tpo" ".deps/dtoa.Plo";
else rm -f ".deps/dtoa.Tpo"; exit 1; fi
gcc-4_3-build/make_6b_log.txt-mkdir .libs
gcc-4_3-build/make_6b_log.txt-gcc -DHAVE_CONFIG_H -I.
-I/root/downloads/gcc-4_3-trunk/libjava/classpath/native/fdlibm -I../../include
-O2 -g -O2 -MT dtoa.lo -MD -MP -MF .deps/dtoa.Tpo -c
/root/downloads/gcc-4_3-trunk/libjava/classpath/native/fdlibm/dtoa.c  -fPIC
-DPIC -o .libs/dtoa.o



Notice that is uses "gcc" to build dtoa ...

When I compiled gcc previously it didn't do that:


# grep -A 4
/opt/gcc-4_3-build/i686-pc-linux-gnu/libjava/classpath/native/fdlibm make_5*

make_5c_log.txt:make[5]: Entering directory
`/opt/gcc-4_3-build/i686-pc-linux-gnu/libjava/classpath/native/fdlibm'
make_5c_log.txt-if /bin/sh ../../libtool --mode=compile
/opt/gcc-4_3-build/./gcc/xgcc -B/opt/gcc-4_3-build/./gcc/
-B/usr/i686-pc-linux-gnu/bin/ -B/usr/i686-pc-linux-gnu/lib/ -isystem
/usr/i686-pc-linux-gnu/include -isystem /usr/i686-pc-linux-gnu/sys-include
-DHAVE_CONFIG_H -I.
-I/root/downloads/gcc-4_3-trunk/libjava/classpath/native/fdlibm -I../../include
-O2 -g -O2  -MT dtoa.lo -MD -MP -MF ".deps/dtoa.Tpo" -c -o dtoa.lo
/root/downloads/gcc-4_3-trunk/libjava/classpath/native/fdlibm/dtoa.c; \
make_5c_log.txt-then mv -f ".deps/dtoa.Tpo" ".deps/dtoa.Plo"; else rm
-f ".deps/dtoa.Tpo"; exit 1; fi
make_5c_log.txt-mkdir .libs
make_5c_log.txt-/opt/gcc-4_3-build/./gcc/xgcc -B/opt/gcc-4_3-build/./gcc/
-B/usr/i686-pc-linux-gnu/bin/ -B/usr/i686-pc-linux-gnu/lib/ -isystem
/usr/i686-pc-linux-gnu/include -isystem /usr/i686-pc-linux-gnu/sys-include
-DHAVE_CONFIG_H -I.
-I/root/downloads/gcc-4_3-trunk/libjava/classpath/native/fdlibm -I../../include
-O2 -g -O2 -MT dtoa.lo -MD -MP -MF .deps/dtoa.Tpo -c
/root/downloads/gcc-4_3-trunk/libjava/classpath/native/fdlibm/dtoa.c  -fPIC
-DPIC -o .libs/dtoa.o


That is not the only library where this occurs. The tests will be invalid if
gcc is used instead of xgcc. The gcc-bugs scripts will be sending out false
e-mails about breakages.


-- 


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

[Bug java/31853] ICE in bootstrap compiling gnu.CORBA.ObjectCreator

2007-05-25 Thread deknuydt at esat dot kuleuven dot be



--- Comment #4 from deknuydt at esat dot kuleuven dot be  2007-05-25 11:12 
---
(In reply to comment #3)
> Unless you need 4.1 and plan to work on this bug, I would like to close it.
> What do you think?

Just close it. 4.2.0 seems okay to me.


-- 


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

[Bug fortran/32083] New: bug in transfer integer->real->integer

2007-05-25 Thread kloedej at knmi dot nl

Hi,

It seems the current gfortran version has a bug when the transfer() function is
called on a parameter holding the bitpattern corresponding to the -Infinite
value.

If a variable with this pattern is transferred from integer->real->integer the
result is just the input. However, when a parameter is transferred in this way,
the sign gets reversed, and the bitpattern for -Infinite is changed into the
bit pattern for +Infinite.

I used the following sample code to test this:

PROGRAM TestInfinite

  IMPLICIT NONE
  integer, parameter :: i8_ = Selected_Int_Kind(18)  ! = integer*8
  integer, parameter :: r8_ = Selected_Real_Kind(15,307)  ! = real*8

  integer(i8_), parameter :: bit_pattern_PosInf_i8_p = 9218868437227405312_i8_
  integer(i8_), parameter :: bit_pattern_NegInf_i8_p = -4503599627370496_i8_

  integer(i8_) :: bit_pattern_PosInf_i8 = 9218868437227405312_i8_
  integer(i8_) :: bit_pattern_NegInf_i8 = -4503599627370496_i8_

  integer(i8_) :: bit_pattern_PosInf_i8_hex
  integer(i8_) :: bit_pattern_NegInf_i8_hex

  integer(i8_) :: i
  real(r8_):: r

  data bit_pattern_PosInf_i8_hex /z'7FF0'/
  !data bit_pattern_NegInf_i8_hex /z'FFF0'/
  ! not portable, replaced by:
  bit_pattern_NegInf_i8_hex = ibset(bit_pattern_PosInf_i8_hex,63)

  print *,"testing the values"

  print *,"bit_pattern_NegInf_i8_hex = ",bit_pattern_NegInf_i8_hex
  print *,"bit pattern NegInf_i8 = ",bit_pattern_NegInf_i8
  print *,"bit_pattern_PosInf_i8_hex = ",bit_pattern_PosInf_i8_hex
  print *,"bit pattern PosInf_i8 = ",bit_pattern_PosInf_i8

  print *,"testing the variable transfers"

  print *,"i = ",bit_pattern_PosInf_i8
  r = transfer(bit_pattern_PosInf_i8,r)
  print *,"r = ",r
  i = transfer(r,i)
  print *,"i = ",i

  print *,"i = ",bit_pattern_NegInf_i8
  r = transfer(bit_pattern_NegInf_i8,r)
  print *,"r = ",r
  i = transfer(r,i)
  print *,"i = ",i


  print *,"testing the parameter transfers"

  print *,"i = ",bit_pattern_PosInf_i8_p
  r = transfer(bit_pattern_PosInf_i8_p,r)
  print *,"r = ",r
  i = transfer(r,i)
  print *,"i = ",i

  print *,"i = ",bit_pattern_NegInf_i8_p
  r = transfer(bit_pattern_NegInf_i8_p,r)
  print *,"r = ",r
  i = transfer(r,i)
  print *,"i = ",i

END PROGRAM TestInfinite

This program generates the following output on my machine:

12:11pm bhw034 72 >TestInf
 testing the values
 bit_pattern_NegInf_i8_hex = -4503599627370496
 bit pattern NegInf_i8 = -4503599627370496
 bit_pattern_PosInf_i8_hex =   9218868437227405312
 bit pattern PosInf_i8 =   9218868437227405312
 testing the variable transfers
 i =   9218868437227405312
 r =+Infinity
 i =   9218868437227405312
 i = -4503599627370496
 r =-Infinity
 i = -4503599627370496
 testing the parameter transfers
 i =   9218868437227405312
 r =+Infinity
 i =   9218868437227405312
 i = -4503599627370496
 r =+Infinity
 i =   9218868437227405312
12:11pm bhw034 73 >


The gfortran version used for testing was:
gfortran -v
Using built-in specs.
Target: i386-pc-linux-gnu
Configured with: /home/fxcoudert/gfortran_nightbuild/trunk/configure
--prefix=/home/fxcoudert/gfortran_nightbuild/irun-20070525
--enable-languages=c,fortran --build=i386-pc-linux-gnu
--enable-checking=release
--with-gmp=/home/fxcoudert/gfortran_nightbuild/software
Thread model: posix
gcc version 4.3.0 20070525 (experimental)



best regards,

Jos de Kloe


-- 
   Summary: bug in transfer integer->real->integer
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kloedej at knmi dot nl


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

[Bug tree-optimization/31981] Missed forw prop with indirect ref and addr. due to CCP

2007-05-25 Thread rguenth at gcc dot gnu dot org



--- Comment #3 from rguenth at gcc dot gnu dot org  2007-05-25 11:21 ---
Indeed with -fno-tree-ccp the testcase is optimized by forwprop1 to

:
  D.2000_3 = i_2(D) * 4;
  D.2001_4 = (int *) D.2000_3;
  D.2002_5 = &b.t[i_2(D)];
  *D.2002_5 = 1;
  return;

and then by forwprop2 to

:
  D.2002_5 = &b.t[i_2(D)];
  b.t[i_2(D)] = 1;
  return;

so the right fix is to eventually teach CCP to do the first transformation,
or rather teach fold_stmt to do a little tree combining in this case.  Ugh.
Or avoid this particular type of CCP.  Ugh.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|Missed forw prop with   |Missed forw prop with
   |indirect ref and addr.  |indirect ref and addr. due
   ||to CCP


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

[Bug c++/32081] Conflicting exception specifications not rejected in template specialization

2007-05-25 Thread andrew dot stubbs at st dot com



--- Comment #1 from andrew dot stubbs at st dot com  2007-05-25 11:21 
---
This problem may also be observed in explicit instantiation:

template 
void
foo (T) throw (int)
{
}

template
void foo (short) throw (short);


There are also similar issues with declarations of pointers to functions, and
pointers to member functions:

extern void (*foo)() throw (int);
extern void (*foo)() throw (short);

class C;
extern void (C::*bar)() throw (int);
extern void (C::*bar)() throw (short);

All these examples are silently accepted.

The function pointer issues may be related to PR12255

Perhaps somebody who can should change the title of this bug to include
function pointers.


-- 


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

[Bug fortran/32083] bug in transfer integer->real->integer

2007-05-25 Thread dfranke at gcc dot gnu dot org



--- Comment #1 from dfranke at gcc dot gnu dot org  2007-05-25 11:45 ---
Shortened testcase to compare variable vs. parameter in tree dump:

$> cat pr32083.f90
PROGRAM TestInfinite
  integer(8), parameter :: bit_pattern_NegInf_i8_p = -4503599627370496_8
  integer(8) :: bit_pattern_NegInf_i8 = -4503599627370496_8

  integer(8) :: i
  real(8):: r

  r = transfer(bit_pattern_NegInf_i8,r)
  i = transfer(r,i)

  r = transfer(bit_pattern_NegInf_i8_p,r)
  i = transfer(r,i)
END PROGRAM TestInfinite

$> gfortran-svn -Wall -std=f95 -fdump-tree-original pr32083.f90
$> cat pr32083.f90.003t.original
MAIN__ ()
{
  static int8 bit_pattern_neginf_i8 = -0x10;
  real8 r;
  int8 i;

  _gfortran_set_std (2, 11, 0, 0, 0);
  {
real8 transfer.0;

__builtin_memcpy ((void *) &transfer.0, (void *) &bit_pattern_neginf_i8,
8);
r = transfer.0;
  }
  {
int8 transfer.1;

__builtin_memcpy ((void *) &transfer.1, (void *) &r, 8);
i = transfer.1;
  }
  r =  Inf;
  {
int8 transfer.2;

__builtin_memcpy ((void *) &transfer.2, (void *) &r, 8);
i = transfer.2;
  }
}

While the first two transfer operations are translated into corresponding
blocks, the third is not. Observe the line
  r =  Inf;


-- 

dfranke at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||dfranke at gcc dot gnu dot
   ||org
OtherBugsDependingO||31237
  nThis||
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-05-25 11:45:00
   date||


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

[Bug libgcj/24403] --enable-java-awt=qt fails to build

2007-05-25 Thread bero at arklinux dot org



--- Comment #13 from bero at arklinux dot org  2007-05-25 12:24 ---
yes, assignment is in place, and yes, the peers are somewhat buggy. But I think
that's in part because nobody (at least in the gcj community) is testing/fixing
them because they don't build without trickery.


-- 


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

[Bug fortran/32083] [Regression 4.3] bug in transfer integer->real->integer

2007-05-25 Thread burnus at gcc dot gnu dot org



--- Comment #2 from burnus at gcc dot gnu dot org  2007-05-25 12:37 ---
This is a regression with regard to 4.2.0.
Brooks, you were looking for transfer regressions, weren't you?

(Just for completeness, 2007-05-15 r124736 is working, 2007-05-16 r124759 is
failing.)


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||brooks at gcc dot gnu dot
   ||org, burnus at gcc dot gnu
   ||dot org
   Keywords||wrong-code
  Known to fail||4.3.0 4.1.2
  Known to work||4.1.3 4.2.0
Summary|bug in transfer integer-|[Regression 4.3] bug in
   |>real->integer  |transfer integer->real-
   ||>integer
   Target Milestone|--- |4.3.0


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

[Bug c++/31809] [4.1/4.2/4.3 Regression] sometimes TREE_READONLY is still set for non read only variables causing wrong code

2007-05-25 Thread jakub at gcc dot gnu dot org



--- Comment #2 from jakub at gcc dot gnu dot org  2007-05-25 12:39 ---
I'm not sure we want to work around here though.  Static const variable
initialized during __static_initialization_and_destruction shouldn't have
TREE_READONLY set, because the variable isn't really unchanging.
This is similar to PR20073, but as the var's type doesn't need constructing,
we don't know in cp_apply_type_quals_to_decl that the initialization needs to
be done at runtime.  We won't know that I think until cp_finish_decl.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||mark at codesourcery dot com


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

[Bug c++/9278] Illegal use of typedef to "void"

2007-05-25 Thread paul_m_doc at hotmail dot com



--- Comment #27 from paul_m_doc at hotmail dot com  2007-05-25 13:11 ---
(In reply to comment #26)
> *** Bug 32058 has been marked as a duplicate of this bug. ***

Sigh :(. The response at the October 2006 to DR 577 is enough to make any
template meta-programmer bang their head against the wall in despair.

This is the language that, according to its creator as a design goal should
'trust the programmer', right?

I certainly have a formal position on this and many other similar issues that
affect TMP.

This should have been at most a warning with the option to turn it off.

The Visual C++ compilers may be less fussy than gcc but at least they tend to
do the sensible thing.


-- 


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

[Bug other/32078] Make FAILURE in 4.3.0 - `CXXFLAGS' has changed error causes "libltdl: No such file or directory"

2007-05-25 Thread hjl at lucon dot org



--- Comment #2 from hjl at lucon dot org  2007-05-25 13:31 ---
I saw it with revision 125032 on a quad-core Linux/x86-64 with "make -j4".


-- 

hjl at lucon dot org changed:

   What|Removed |Added

 CC||hjl at lucon dot org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
  GCC build triplet|i686-pc-linux-gnu   |
   GCC host triplet|i686-pc-linux-gnu   |
 GCC target triplet|i686-pc-linux-gnu   |
   Last reconfirmed|-00-00 00:00:00 |2007-05-25 13:31:30
   date||


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

[Bug other/22368] [meta-bug] mis-match types in GCC

2007-05-25 Thread fxcoudert at gcc dot gnu dot org



--- Comment #14 from fxcoudert at gcc dot gnu dot org  2007-05-25 13:55 
---
Rev. 124497 of mainline fails to bootstrap with these patches on i686-linux:

[during stage2]
../../../trunk3/gcc/df-scan.c: In function df_ref_record:
../../../trunk3/gcc/df-scan.c:1057: error: types mismatch in comparsion
long unsigned int

int

shifttmp.1580_150 == 0;

../../../trunk3/gcc/df-scan.c:1057: internal compiler error: verify_stmts
failed

Debugging this error yields:

Breakpoint 5, verify_expr (tp=0xb70f1b5c, walk_subtrees=0xbfa475f0, data=0x0)
at ../../../trunk3/gcc/tree-cfg.c:3298
3298error ("types mismatch in comparsion");
(gdb) p debug_tree(lhs)
 
unit size 
align 32 symtab -1211504504 alias set -1 canonical type 0xb7bf1438
precision 32 min  max 
pointer_to_this >
var  def_stmt 
version 150>
$1 = void
(gdb) p debug_tree(rhs)
  constant invariant
0>
$2 = void


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||fxcoudert at gcc dot gnu dot
   ||org


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

[Bug target/31975] [4.3 Regression] segfault in try_split on mips during bootstrap

2007-05-25 Thread richard at codesourcery dot com

--- Comment #15 from richard at codesourcery dot com  2007-05-25 14:13 
---
Subject: Re:  [4.3 Regression] segfault in try_split on mips during bootstrap

David, msny thanks for looking at this.

"pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
> RS6000, ia64, and sh does this:
>   /* Mark the end of the (empty) prologue.  */
>   emit_note (NOTE_INSN_PROLOGUE_END);
>
> You might want to use that note also for MIPS.

Agreed.  I suppose it's slightly more self-documenting than
NOTE_INSN_DELETED, and it's good to be consistent with other ports.

David, FWIW, a patch to add those two lines is pre-approved.  If you've
already tested the NOTE_INSN_DELETED version, don't feel you need to test
the whole thing again with the other note; as long as cc1 compiles,
that's fine.

Richard

-- 

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

[Bug fortran/32084] New: gfortran 4.3 13%-18% slower for induct.f90 than gcc 4.0-based competitor

2007-05-25 Thread burnus at gcc dot gnu dot org

gfortran seemingly generates an significatly inferior internal TREE
representation than g95 as for Polyhedron's induct.f90 gfortran is 18% slower
than g95, which is based on GCC 4.0.3. (Compared with other compilers the
difference is even larger.)

(GCC 4.3 is in general faster than GCC 4.1; for induct one does not see any
runtime change with the gfortran frontend during the last 1.5 years, though
GCC/gfortran 4.1.2 was seemingly slightly faster:
http://www.suse.de/~gcctest/c++bench/polyhedron/polyhedron-summary.txt-induct-19.png
)

If one looks at -ftree-vectorizer-verbose, GCC 4.3 is able to vectorize 3 loops
with gfortran whereas GCC 4.0 vectorizes 0 loops with g95.


For reduced-size example (395 instead of 6635 lines), gfortran is still 13%
slower:

$ fortran -march=opteron -ffast-math -funroll-loops -ftree-vectorize
-ftree-loop-linear -msse3 -O3  test2.f90
$ time a.out
real0m4.632s  user0m4.624s  sys 0m0.004s

$ g95 -march=opteron -ffast-math -funroll-loops -ftree-vectorize -msse3 -O3
test2.f90
$ time a.out
real0m4.030s  user0m4.024s  sys 0m0.004s

$ ifort test2.f90
$ time a.out
real0m3.859s  user0m3.856s  sys 0m0.000s

# NAG f95 + system gcc 4.1.3
$ f95 -O4 -ieee=full -Bstatic -march=opteron -ffast-math -funroll-loops
-ftree-vectorize -msse3 test2.f90
$ time a.out
real0m3.381s  user0m3.380s  sys 0m0.004s

$ sunf95 -w4 -fast -xarch=amd64a -xipo=0 test2.f90
$ time a.out
real0m3.741s  user0m3.736s  sys 0m0.000s




For induct (on x86_64-unknown-linux-gnu):
51.65 [100%]  gfortran -m64 as above
51.90 [100%]  gfortran with -fprofile-use
61.41 [118%]  gfortran 32bit, x87
46.12 [ 89%]  gfortran 32bit, SSE
43.33 [ 83%]  ifort 9.1
40.73 [ 78%]  ifort 10beta
42.53 [ 82%]  sunf95
30.16 [ 58%]  pathscale
38.86 [ 75%]  NAG f95 using system gcc 4.1
42.65 [ 82%]  g95/gcc 4.0.3 (g95 0.91!)


-- 
   Summary: gfortran 4.3 13%-18% slower for induct.f90 than gcc 4.0-
based competitor
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  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=32084

[Bug fortran/32084] gfortran 4.3 13%-18% slower for induct.f90 than gcc 4.0-based competitor

2007-05-25 Thread burnus at gcc dot gnu dot org



--- Comment #1 from burnus at gcc dot gnu dot org  2007-05-25 14:25 ---
Created an attachment (id=13611)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13611&action=view)
test case, 395 lines; based on Polyhedron's induct.f90


-- 


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

[Bug c++/31444] [4.3 regression] ICE with invalid use of parameter pack in member template

2007-05-25 Thread dgregor at gcc dot gnu dot org

--- Comment #1 from dgregor at gcc dot gnu dot org  2007-05-25 14:16 ---
Subject: Bug 31444

Author: dgregor
Date: Fri May 25 13:15:04 2007
New Revision: 125062

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125062
Log:
2007-05-25  Douglas Gregor <[EMAIL PROTECTED]>

PR c++/31431
PR c++/31432
PR c++/31434
PR c++/31435
PR c++/31437
PR c++/31438
PR c++/31442
PR c++/31443
PR c++/31444
PR c++/31445
* error.c (dump_type): Dump TYPE_ARGUMENT_PACK nodes.
* cp-tree.h (check_for_bare_parameter_packs): Returns bool.
* pt.c (check_for_bare_parameter_packs): Return bool indicated
whether everything was okay. Fix indentation.
(push_template_decl_real): Check for bare parameter packs in
function parameters; where errors occur, mark the parameter types
with ERROR_MARK_NODEs to avert ICEs.
(coerce_template_parameter_pack): New.
(coerce_template_parms): Moved parameter pack coercion into
coerce_template_parameter_pack, and permit it anywhere in the
template parameter list (not just at the end). Parameter and
argument indices can vary (somewhat) separately now, so add
PARM_IDX and ARG_IDX.
(fn_type_unification): Don't set an argument pack as incomplete if
no argument pack was deduced.
(type_unification_real): If a type parameter is a parameter pack
and has not otherwise been deduced, it will be deduced to an empty
parameter pack.
(more_specialized_fn): Use the actual lengths of the argument
lists when comparing against expansions.
* semantics.c (finish_member_declaration): If a field's type has
bare parameter packs, error and set its type to ERROR_MARK_NODE.

2007-05-25  Douglas Gregor <[EMAIL PROTECTED]>

PR c++/31431
PR c++/31432
PR c++/31434
PR c++/31435
PR c++/31437
PR c++/31438
PR c++/31442
PR c++/31443
PR c++/31444
PR c++/31445
* g++.dg/cpp0x/pr31431.C: New.
* g++.dg/cpp0x/pr31437.C: New.
* g++.dg/cpp0x/pr31442.C: New.
* g++.dg/cpp0x/pr31444.C: New.
* g++.dg/cpp0x/pr31431-2.C: New.
* g++.dg/cpp0x/pr31432.C: New.
* g++.dg/cpp0x/pr31434.C: New.
* g++.dg/cpp0x/pr31438.C: New.
* g++.dg/cpp0x/pr31443.C: New.
* g++.dg/cpp0x/pr31445.C: New.
* g++.dg/cpp0x/variadic-crash1.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/pr31431-2.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr31431.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr31432.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr31434.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr31437.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr31438.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr31442.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr31443.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr31444.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr31445.C
trunk/gcc/testsuite/g++.dg/cpp0x/variadic-crash1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/error.c
trunk/gcc/cp/pt.c
trunk/gcc/cp/semantics.c
trunk/gcc/testsuite/ChangeLog

-- 

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

[Bug c++/31445] [4.3 regression] type_argument_pack not supported by dump_type

2007-05-25 Thread dgregor at gcc dot gnu dot org

--- Comment #2 from dgregor at gcc dot gnu dot org  2007-05-25 14:16 ---
Subject: Bug 31445

Author: dgregor
Date: Fri May 25 13:15:04 2007
New Revision: 125062

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125062
Log:
2007-05-25  Douglas Gregor <[EMAIL PROTECTED]>

PR c++/31431
PR c++/31432
PR c++/31434
PR c++/31435
PR c++/31437
PR c++/31438
PR c++/31442
PR c++/31443
PR c++/31444
PR c++/31445
* error.c (dump_type): Dump TYPE_ARGUMENT_PACK nodes.
* cp-tree.h (check_for_bare_parameter_packs): Returns bool.
* pt.c (check_for_bare_parameter_packs): Return bool indicated
whether everything was okay. Fix indentation.
(push_template_decl_real): Check for bare parameter packs in
function parameters; where errors occur, mark the parameter types
with ERROR_MARK_NODEs to avert ICEs.
(coerce_template_parameter_pack): New.
(coerce_template_parms): Moved parameter pack coercion into
coerce_template_parameter_pack, and permit it anywhere in the
template parameter list (not just at the end). Parameter and
argument indices can vary (somewhat) separately now, so add
PARM_IDX and ARG_IDX.
(fn_type_unification): Don't set an argument pack as incomplete if
no argument pack was deduced.
(type_unification_real): If a type parameter is a parameter pack
and has not otherwise been deduced, it will be deduced to an empty
parameter pack.
(more_specialized_fn): Use the actual lengths of the argument
lists when comparing against expansions.
* semantics.c (finish_member_declaration): If a field's type has
bare parameter packs, error and set its type to ERROR_MARK_NODE.

2007-05-25  Douglas Gregor <[EMAIL PROTECTED]>

PR c++/31431
PR c++/31432
PR c++/31434
PR c++/31435
PR c++/31437
PR c++/31438
PR c++/31442
PR c++/31443
PR c++/31444
PR c++/31445
* g++.dg/cpp0x/pr31431.C: New.
* g++.dg/cpp0x/pr31437.C: New.
* g++.dg/cpp0x/pr31442.C: New.
* g++.dg/cpp0x/pr31444.C: New.
* g++.dg/cpp0x/pr31431-2.C: New.
* g++.dg/cpp0x/pr31432.C: New.
* g++.dg/cpp0x/pr31434.C: New.
* g++.dg/cpp0x/pr31438.C: New.
* g++.dg/cpp0x/pr31443.C: New.
* g++.dg/cpp0x/pr31445.C: New.
* g++.dg/cpp0x/variadic-crash1.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/pr31431-2.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr31431.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr31432.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr31434.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr31437.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr31438.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr31442.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr31443.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr31444.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr31445.C
trunk/gcc/testsuite/g++.dg/cpp0x/variadic-crash1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/error.c
trunk/gcc/cp/pt.c
trunk/gcc/cp/semantics.c
trunk/gcc/testsuite/ChangeLog

-- 

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

[Bug c++/31442] [4.3 regression] ICE with variadic template and default argument

2007-05-25 Thread dgregor at gcc dot gnu dot org

--- Comment #1 from dgregor at gcc dot gnu dot org  2007-05-25 14:15 ---
Subject: Bug 31442

Author: dgregor
Date: Fri May 25 13:15:04 2007
New Revision: 125062

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125062
Log:
2007-05-25  Douglas Gregor <[EMAIL PROTECTED]>

PR c++/31431
PR c++/31432
PR c++/31434
PR c++/31435
PR c++/31437
PR c++/31438
PR c++/31442
PR c++/31443
PR c++/31444
PR c++/31445
* error.c (dump_type): Dump TYPE_ARGUMENT_PACK nodes.
* cp-tree.h (check_for_bare_parameter_packs): Returns bool.
* pt.c (check_for_bare_parameter_packs): Return bool indicated
whether everything was okay. Fix indentation.
(push_template_decl_real): Check for bare parameter packs in
function parameters; where errors occur, mark the parameter types
with ERROR_MARK_NODEs to avert ICEs.
(coerce_template_parameter_pack): New.
(coerce_template_parms): Moved parameter pack coercion into
coerce_template_parameter_pack, and permit it anywhere in the
template parameter list (not just at the end). Parameter and
argument indices can vary (somewhat) separately now, so add
PARM_IDX and ARG_IDX.
(fn_type_unification): Don't set an argument pack as incomplete if
no argument pack was deduced.
(type_unification_real): If a type parameter is a parameter pack
and has not otherwise been deduced, it will be deduced to an empty
parameter pack.
(more_specialized_fn): Use the actual lengths of the argument
lists when comparing against expansions.
* semantics.c (finish_member_declaration): If a field's type has
bare parameter packs, error and set its type to ERROR_MARK_NODE.

2007-05-25  Douglas Gregor <[EMAIL PROTECTED]>

PR c++/31431
PR c++/31432
PR c++/31434
PR c++/31435
PR c++/31437
PR c++/31438
PR c++/31442
PR c++/31443
PR c++/31444
PR c++/31445
* g++.dg/cpp0x/pr31431.C: New.
* g++.dg/cpp0x/pr31437.C: New.
* g++.dg/cpp0x/pr31442.C: New.
* g++.dg/cpp0x/pr31444.C: New.
* g++.dg/cpp0x/pr31431-2.C: New.
* g++.dg/cpp0x/pr31432.C: New.
* g++.dg/cpp0x/pr31434.C: New.
* g++.dg/cpp0x/pr31438.C: New.
* g++.dg/cpp0x/pr31443.C: New.
* g++.dg/cpp0x/pr31445.C: New.
* g++.dg/cpp0x/variadic-crash1.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/pr31431-2.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr31431.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr31432.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr31434.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr31437.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr31438.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr31442.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr31443.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr31444.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr31445.C
trunk/gcc/testsuite/g++.dg/cpp0x/variadic-crash1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/error.c
trunk/gcc/cp/pt.c
trunk/gcc/cp/semantics.c
trunk/gcc/testsuite/ChangeLog

-- 

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

[Bug c++/31434] [4.3 regression] ICE with invalid use of parameter pack in function arg

2007-05-25 Thread dgregor at gcc dot gnu dot org

--- Comment #1 from dgregor at gcc dot gnu dot org  2007-05-25 14:15 ---
Subject: Bug 31434

Author: dgregor
Date: Fri May 25 13:15:04 2007
New Revision: 125062

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125062
Log:
2007-05-25  Douglas Gregor <[EMAIL PROTECTED]>

PR c++/31431
PR c++/31432
PR c++/31434
PR c++/31435
PR c++/31437
PR c++/31438
PR c++/31442
PR c++/31443
PR c++/31444
PR c++/31445
* error.c (dump_type): Dump TYPE_ARGUMENT_PACK nodes.
* cp-tree.h (check_for_bare_parameter_packs): Returns bool.
* pt.c (check_for_bare_parameter_packs): Return bool indicated
whether everything was okay. Fix indentation.
(push_template_decl_real): Check for bare parameter packs in
function parameters; where errors occur, mark the parameter types
with ERROR_MARK_NODEs to avert ICEs.
(coerce_template_parameter_pack): New.
(coerce_template_parms): Moved parameter pack coercion into
coerce_template_parameter_pack, and permit it anywhere in the
template parameter list (not just at the end). Parameter and
argument indices can vary (somewhat) separately now, so add
PARM_IDX and ARG_IDX.
(fn_type_unification): Don't set an argument pack as incomplete if
no argument pack was deduced.
(type_unification_real): If a type parameter is a parameter pack
and has not otherwise been deduced, it will be deduced to an empty
parameter pack.
(more_specialized_fn): Use the actual lengths of the argument
lists when comparing against expansions.
* semantics.c (finish_member_declaration): If a field's type has
bare parameter packs, error and set its type to ERROR_MARK_NODE.

2007-05-25  Douglas Gregor <[EMAIL PROTECTED]>

PR c++/31431
PR c++/31432
PR c++/31434
PR c++/31435
PR c++/31437
PR c++/31438
PR c++/31442
PR c++/31443
PR c++/31444
PR c++/31445
* g++.dg/cpp0x/pr31431.C: New.
* g++.dg/cpp0x/pr31437.C: New.
* g++.dg/cpp0x/pr31442.C: New.
* g++.dg/cpp0x/pr31444.C: New.
* g++.dg/cpp0x/pr31431-2.C: New.
* g++.dg/cpp0x/pr31432.C: New.
* g++.dg/cpp0x/pr31434.C: New.
* g++.dg/cpp0x/pr31438.C: New.
* g++.dg/cpp0x/pr31443.C: New.
* g++.dg/cpp0x/pr31445.C: New.
* g++.dg/cpp0x/variadic-crash1.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/pr31431-2.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr31431.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr31432.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr31434.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr31437.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr31438.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr31442.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr31443.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr31444.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr31445.C
trunk/gcc/testsuite/g++.dg/cpp0x/variadic-crash1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/error.c
trunk/gcc/cp/pt.c
trunk/gcc/cp/semantics.c
trunk/gcc/testsuite/ChangeLog

-- 

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

[Bug c++/31432] [4.3 regression] ICE with invalid parameter pack for template struct

2007-05-25 Thread dgregor at gcc dot gnu dot org

--- Comment #1 from dgregor at gcc dot gnu dot org  2007-05-25 14:15 ---
Subject: Bug 31432

Author: dgregor
Date: Fri May 25 13:15:04 2007
New Revision: 125062

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125062
Log:
2007-05-25  Douglas Gregor <[EMAIL PROTECTED]>

PR c++/31431
PR c++/31432
PR c++/31434
PR c++/31435
PR c++/31437
PR c++/31438
PR c++/31442
PR c++/31443
PR c++/31444
PR c++/31445
* error.c (dump_type): Dump TYPE_ARGUMENT_PACK nodes.
* cp-tree.h (check_for_bare_parameter_packs): Returns bool.
* pt.c (check_for_bare_parameter_packs): Return bool indicated
whether everything was okay. Fix indentation.
(push_template_decl_real): Check for bare parameter packs in
function parameters; where errors occur, mark the parameter types
with ERROR_MARK_NODEs to avert ICEs.
(coerce_template_parameter_pack): New.
(coerce_template_parms): Moved parameter pack coercion into
coerce_template_parameter_pack, and permit it anywhere in the
template parameter list (not just at the end). Parameter and
argument indices can vary (somewhat) separately now, so add
PARM_IDX and ARG_IDX.
(fn_type_unification): Don't set an argument pack as incomplete if
no argument pack was deduced.
(type_unification_real): If a type parameter is a parameter pack
and has not otherwise been deduced, it will be deduced to an empty
parameter pack.
(more_specialized_fn): Use the actual lengths of the argument
lists when comparing against expansions.
* semantics.c (finish_member_declaration): If a field's type has
bare parameter packs, error and set its type to ERROR_MARK_NODE.

2007-05-25  Douglas Gregor <[EMAIL PROTECTED]>

PR c++/31431
PR c++/31432
PR c++/31434
PR c++/31435
PR c++/31437
PR c++/31438
PR c++/31442
PR c++/31443
PR c++/31444
PR c++/31445
* g++.dg/cpp0x/pr31431.C: New.
* g++.dg/cpp0x/pr31437.C: New.
* g++.dg/cpp0x/pr31442.C: New.
* g++.dg/cpp0x/pr31444.C: New.
* g++.dg/cpp0x/pr31431-2.C: New.
* g++.dg/cpp0x/pr31432.C: New.
* g++.dg/cpp0x/pr31434.C: New.
* g++.dg/cpp0x/pr31438.C: New.
* g++.dg/cpp0x/pr31443.C: New.
* g++.dg/cpp0x/pr31445.C: New.
* g++.dg/cpp0x/variadic-crash1.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/pr31431-2.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr31431.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr31432.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr31434.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr31437.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr31438.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr31442.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr31443.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr31444.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr31445.C
trunk/gcc/testsuite/g++.dg/cpp0x/variadic-crash1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/error.c
trunk/gcc/cp/pt.c
trunk/gcc/cp/semantics.c
trunk/gcc/testsuite/ChangeLog

-- 

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

[Bug c++/31431] [4.3 regression] ICE with invalid parameter pack

2007-05-25 Thread dgregor at gcc dot gnu dot org

--- Comment #1 from dgregor at gcc dot gnu dot org  2007-05-25 14:15 ---
Subject: Bug 31431

Author: dgregor
Date: Fri May 25 13:15:04 2007
New Revision: 125062

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125062
Log:
2007-05-25  Douglas Gregor <[EMAIL PROTECTED]>

PR c++/31431
PR c++/31432
PR c++/31434
PR c++/31435
PR c++/31437
PR c++/31438
PR c++/31442
PR c++/31443
PR c++/31444
PR c++/31445
* error.c (dump_type): Dump TYPE_ARGUMENT_PACK nodes.
* cp-tree.h (check_for_bare_parameter_packs): Returns bool.
* pt.c (check_for_bare_parameter_packs): Return bool indicated
whether everything was okay. Fix indentation.
(push_template_decl_real): Check for bare parameter packs in
function parameters; where errors occur, mark the parameter types
with ERROR_MARK_NODEs to avert ICEs.
(coerce_template_parameter_pack): New.
(coerce_template_parms): Moved parameter pack coercion into
coerce_template_parameter_pack, and permit it anywhere in the
template parameter list (not just at the end). Parameter and
argument indices can vary (somewhat) separately now, so add
PARM_IDX and ARG_IDX.
(fn_type_unification): Don't set an argument pack as incomplete if
no argument pack was deduced.
(type_unification_real): If a type parameter is a parameter pack
and has not otherwise been deduced, it will be deduced to an empty
parameter pack.
(more_specialized_fn): Use the actual lengths of the argument
lists when comparing against expansions.
* semantics.c (finish_member_declaration): If a field's type has
bare parameter packs, error and set its type to ERROR_MARK_NODE.

2007-05-25  Douglas Gregor <[EMAIL PROTECTED]>

PR c++/31431
PR c++/31432
PR c++/31434
PR c++/31435
PR c++/31437
PR c++/31438
PR c++/31442
PR c++/31443
PR c++/31444
PR c++/31445
* g++.dg/cpp0x/pr31431.C: New.
* g++.dg/cpp0x/pr31437.C: New.
* g++.dg/cpp0x/pr31442.C: New.
* g++.dg/cpp0x/pr31444.C: New.
* g++.dg/cpp0x/pr31431-2.C: New.
* g++.dg/cpp0x/pr31432.C: New.
* g++.dg/cpp0x/pr31434.C: New.
* g++.dg/cpp0x/pr31438.C: New.
* g++.dg/cpp0x/pr31443.C: New.
* g++.dg/cpp0x/pr31445.C: New.
* g++.dg/cpp0x/variadic-crash1.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/pr31431-2.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr31431.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr31432.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr31434.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr31437.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr31438.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr31442.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr31443.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr31444.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr31445.C
trunk/gcc/testsuite/g++.dg/cpp0x/variadic-crash1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/error.c
trunk/gcc/cp/pt.c
trunk/gcc/cp/semantics.c
trunk/gcc/testsuite/ChangeLog

-- 

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

[Bug testsuite/32063] "contrib/test_summary" script could output results more neatly

2007-05-25 Thread manu at gcc dot gnu dot org



--- Comment #2 from manu at gcc dot gnu dot org  2007-05-25 14:05 ---
(In reply to comment #0)
> While this is "trivial" we should have pride in our great compiler and the
> usually great results. Even if there are failures we should still present them
> neatly.

If it is trivial, then just prepare a patch for it, test it and send it to
gcc-patches. Opening a PR for this was a waste of electricity.


-- 


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

[Bug c++/31437] [4.3 regression] ICE with invalid use of parameter pack in member function arg

2007-05-25 Thread dgregor at gcc dot gnu dot org

--- Comment #1 from dgregor at gcc dot gnu dot org  2007-05-25 14:15 ---
Subject: Bug 31437

Author: dgregor
Date: Fri May 25 13:15:04 2007
New Revision: 125062

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125062
Log:
2007-05-25  Douglas Gregor <[EMAIL PROTECTED]>

PR c++/31431
PR c++/31432
PR c++/31434
PR c++/31435
PR c++/31437
PR c++/31438
PR c++/31442
PR c++/31443
PR c++/31444
PR c++/31445
* error.c (dump_type): Dump TYPE_ARGUMENT_PACK nodes.
* cp-tree.h (check_for_bare_parameter_packs): Returns bool.
* pt.c (check_for_bare_parameter_packs): Return bool indicated
whether everything was okay. Fix indentation.
(push_template_decl_real): Check for bare parameter packs in
function parameters; where errors occur, mark the parameter types
with ERROR_MARK_NODEs to avert ICEs.
(coerce_template_parameter_pack): New.
(coerce_template_parms): Moved parameter pack coercion into
coerce_template_parameter_pack, and permit it anywhere in the
template parameter list (not just at the end). Parameter and
argument indices can vary (somewhat) separately now, so add
PARM_IDX and ARG_IDX.
(fn_type_unification): Don't set an argument pack as incomplete if
no argument pack was deduced.
(type_unification_real): If a type parameter is a parameter pack
and has not otherwise been deduced, it will be deduced to an empty
parameter pack.
(more_specialized_fn): Use the actual lengths of the argument
lists when comparing against expansions.
* semantics.c (finish_member_declaration): If a field's type has
bare parameter packs, error and set its type to ERROR_MARK_NODE.

2007-05-25  Douglas Gregor <[EMAIL PROTECTED]>

PR c++/31431
PR c++/31432
PR c++/31434
PR c++/31435
PR c++/31437
PR c++/31438
PR c++/31442
PR c++/31443
PR c++/31444
PR c++/31445
* g++.dg/cpp0x/pr31431.C: New.
* g++.dg/cpp0x/pr31437.C: New.
* g++.dg/cpp0x/pr31442.C: New.
* g++.dg/cpp0x/pr31444.C: New.
* g++.dg/cpp0x/pr31431-2.C: New.
* g++.dg/cpp0x/pr31432.C: New.
* g++.dg/cpp0x/pr31434.C: New.
* g++.dg/cpp0x/pr31438.C: New.
* g++.dg/cpp0x/pr31443.C: New.
* g++.dg/cpp0x/pr31445.C: New.
* g++.dg/cpp0x/variadic-crash1.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/pr31431-2.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr31431.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr31432.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr31434.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr31437.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr31438.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr31442.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr31443.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr31444.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr31445.C
trunk/gcc/testsuite/g++.dg/cpp0x/variadic-crash1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/error.c
trunk/gcc/cp/pt.c
trunk/gcc/cp/semantics.c
trunk/gcc/testsuite/ChangeLog

-- 

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

[Bug c++/31438] [4.3 regression] ICE with invalid use of parameter pack in specialization

2007-05-25 Thread dgregor at gcc dot gnu dot org

--- Comment #1 from dgregor at gcc dot gnu dot org  2007-05-25 14:15 ---
Subject: Bug 31438

Author: dgregor
Date: Fri May 25 13:15:04 2007
New Revision: 125062

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125062
Log:
2007-05-25  Douglas Gregor <[EMAIL PROTECTED]>

PR c++/31431
PR c++/31432
PR c++/31434
PR c++/31435
PR c++/31437
PR c++/31438
PR c++/31442
PR c++/31443
PR c++/31444
PR c++/31445
* error.c (dump_type): Dump TYPE_ARGUMENT_PACK nodes.
* cp-tree.h (check_for_bare_parameter_packs): Returns bool.
* pt.c (check_for_bare_parameter_packs): Return bool indicated
whether everything was okay. Fix indentation.
(push_template_decl_real): Check for bare parameter packs in
function parameters; where errors occur, mark the parameter types
with ERROR_MARK_NODEs to avert ICEs.
(coerce_template_parameter_pack): New.
(coerce_template_parms): Moved parameter pack coercion into
coerce_template_parameter_pack, and permit it anywhere in the
template parameter list (not just at the end). Parameter and
argument indices can vary (somewhat) separately now, so add
PARM_IDX and ARG_IDX.
(fn_type_unification): Don't set an argument pack as incomplete if
no argument pack was deduced.
(type_unification_real): If a type parameter is a parameter pack
and has not otherwise been deduced, it will be deduced to an empty
parameter pack.
(more_specialized_fn): Use the actual lengths of the argument
lists when comparing against expansions.
* semantics.c (finish_member_declaration): If a field's type has
bare parameter packs, error and set its type to ERROR_MARK_NODE.

2007-05-25  Douglas Gregor <[EMAIL PROTECTED]>

PR c++/31431
PR c++/31432
PR c++/31434
PR c++/31435
PR c++/31437
PR c++/31438
PR c++/31442
PR c++/31443
PR c++/31444
PR c++/31445
* g++.dg/cpp0x/pr31431.C: New.
* g++.dg/cpp0x/pr31437.C: New.
* g++.dg/cpp0x/pr31442.C: New.
* g++.dg/cpp0x/pr31444.C: New.
* g++.dg/cpp0x/pr31431-2.C: New.
* g++.dg/cpp0x/pr31432.C: New.
* g++.dg/cpp0x/pr31434.C: New.
* g++.dg/cpp0x/pr31438.C: New.
* g++.dg/cpp0x/pr31443.C: New.
* g++.dg/cpp0x/pr31445.C: New.
* g++.dg/cpp0x/variadic-crash1.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/pr31431-2.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr31431.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr31432.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr31434.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr31437.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr31438.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr31442.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr31443.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr31444.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr31445.C
trunk/gcc/testsuite/g++.dg/cpp0x/variadic-crash1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/error.c
trunk/gcc/cp/pt.c
trunk/gcc/cp/semantics.c
trunk/gcc/testsuite/ChangeLog

-- 

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

[Bug c++/31435] [4.3 regression] ICE with invalid use of parameter pack in function arg

2007-05-25 Thread dgregor at gcc dot gnu dot org

--- Comment #1 from dgregor at gcc dot gnu dot org  2007-05-25 14:15 ---
Subject: Bug 31435

Author: dgregor
Date: Fri May 25 13:15:04 2007
New Revision: 125062

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125062
Log:
2007-05-25  Douglas Gregor <[EMAIL PROTECTED]>

PR c++/31431
PR c++/31432
PR c++/31434
PR c++/31435
PR c++/31437
PR c++/31438
PR c++/31442
PR c++/31443
PR c++/31444
PR c++/31445
* error.c (dump_type): Dump TYPE_ARGUMENT_PACK nodes.
* cp-tree.h (check_for_bare_parameter_packs): Returns bool.
* pt.c (check_for_bare_parameter_packs): Return bool indicated
whether everything was okay. Fix indentation.
(push_template_decl_real): Check for bare parameter packs in
function parameters; where errors occur, mark the parameter types
with ERROR_MARK_NODEs to avert ICEs.
(coerce_template_parameter_pack): New.
(coerce_template_parms): Moved parameter pack coercion into
coerce_template_parameter_pack, and permit it anywhere in the
template parameter list (not just at the end). Parameter and
argument indices can vary (somewhat) separately now, so add
PARM_IDX and ARG_IDX.
(fn_type_unification): Don't set an argument pack as incomplete if
no argument pack was deduced.
(type_unification_real): If a type parameter is a parameter pack
and has not otherwise been deduced, it will be deduced to an empty
parameter pack.
(more_specialized_fn): Use the actual lengths of the argument
lists when comparing against expansions.
* semantics.c (finish_member_declaration): If a field's type has
bare parameter packs, error and set its type to ERROR_MARK_NODE.

2007-05-25  Douglas Gregor <[EMAIL PROTECTED]>

PR c++/31431
PR c++/31432
PR c++/31434
PR c++/31435
PR c++/31437
PR c++/31438
PR c++/31442
PR c++/31443
PR c++/31444
PR c++/31445
* g++.dg/cpp0x/pr31431.C: New.
* g++.dg/cpp0x/pr31437.C: New.
* g++.dg/cpp0x/pr31442.C: New.
* g++.dg/cpp0x/pr31444.C: New.
* g++.dg/cpp0x/pr31431-2.C: New.
* g++.dg/cpp0x/pr31432.C: New.
* g++.dg/cpp0x/pr31434.C: New.
* g++.dg/cpp0x/pr31438.C: New.
* g++.dg/cpp0x/pr31443.C: New.
* g++.dg/cpp0x/pr31445.C: New.
* g++.dg/cpp0x/variadic-crash1.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/pr31431-2.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr31431.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr31432.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr31434.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr31437.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr31438.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr31442.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr31443.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr31444.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr31445.C
trunk/gcc/testsuite/g++.dg/cpp0x/variadic-crash1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/error.c
trunk/gcc/cp/pt.c
trunk/gcc/cp/semantics.c
trunk/gcc/testsuite/ChangeLog

-- 

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

[Bug c++/31443] [4.3 regression] ICE with invalid use of parameter pack in member template

2007-05-25 Thread dgregor at gcc dot gnu dot org

--- Comment #1 from dgregor at gcc dot gnu dot org  2007-05-25 14:15 ---
Subject: Bug 31443

Author: dgregor
Date: Fri May 25 13:15:04 2007
New Revision: 125062

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125062
Log:
2007-05-25  Douglas Gregor <[EMAIL PROTECTED]>

PR c++/31431
PR c++/31432
PR c++/31434
PR c++/31435
PR c++/31437
PR c++/31438
PR c++/31442
PR c++/31443
PR c++/31444
PR c++/31445
* error.c (dump_type): Dump TYPE_ARGUMENT_PACK nodes.
* cp-tree.h (check_for_bare_parameter_packs): Returns bool.
* pt.c (check_for_bare_parameter_packs): Return bool indicated
whether everything was okay. Fix indentation.
(push_template_decl_real): Check for bare parameter packs in
function parameters; where errors occur, mark the parameter types
with ERROR_MARK_NODEs to avert ICEs.
(coerce_template_parameter_pack): New.
(coerce_template_parms): Moved parameter pack coercion into
coerce_template_parameter_pack, and permit it anywhere in the
template parameter list (not just at the end). Parameter and
argument indices can vary (somewhat) separately now, so add
PARM_IDX and ARG_IDX.
(fn_type_unification): Don't set an argument pack as incomplete if
no argument pack was deduced.
(type_unification_real): If a type parameter is a parameter pack
and has not otherwise been deduced, it will be deduced to an empty
parameter pack.
(more_specialized_fn): Use the actual lengths of the argument
lists when comparing against expansions.
* semantics.c (finish_member_declaration): If a field's type has
bare parameter packs, error and set its type to ERROR_MARK_NODE.

2007-05-25  Douglas Gregor <[EMAIL PROTECTED]>

PR c++/31431
PR c++/31432
PR c++/31434
PR c++/31435
PR c++/31437
PR c++/31438
PR c++/31442
PR c++/31443
PR c++/31444
PR c++/31445
* g++.dg/cpp0x/pr31431.C: New.
* g++.dg/cpp0x/pr31437.C: New.
* g++.dg/cpp0x/pr31442.C: New.
* g++.dg/cpp0x/pr31444.C: New.
* g++.dg/cpp0x/pr31431-2.C: New.
* g++.dg/cpp0x/pr31432.C: New.
* g++.dg/cpp0x/pr31434.C: New.
* g++.dg/cpp0x/pr31438.C: New.
* g++.dg/cpp0x/pr31443.C: New.
* g++.dg/cpp0x/pr31445.C: New.
* g++.dg/cpp0x/variadic-crash1.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/pr31431-2.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr31431.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr31432.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr31434.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr31437.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr31438.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr31442.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr31443.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr31444.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr31445.C
trunk/gcc/testsuite/g++.dg/cpp0x/variadic-crash1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/error.c
trunk/gcc/cp/pt.c
trunk/gcc/cp/semantics.c
trunk/gcc/testsuite/ChangeLog

-- 

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

[Bug c++/32085] New: "warning: deleting void* is undefined" sometimes bogus

2007-05-25 Thread andrew dot stubbs at st dot com

void
operator delete(void *p)
{
}

void
foo ()
{
  void *p = new int;
  delete p;
}

t.cxx: In function int main():
t.cxx:13: warning: deleting void* is undefined

Oh yes it - I just defined it!

It might be nice if the compiler checked before warning :)


-- 
   Summary: "warning: deleting void* is undefined" sometimes bogus
   Product: gcc
   Version: 4.1.1
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: andrew dot stubbs at st dot com


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

[Bug target/32065] Many dfp testsuite failures for -msse targets

2007-05-25 Thread ubizjak at gmail dot com



--- Comment #2 from ubizjak at gmail dot com  2007-05-25 14:53 ---
Patch at http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01716.html


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2007-
   ||05/msg01716.html
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||ice-on-valid-code, patch
   Last reconfirmed|-00-00 00:00:00 |2007-05-25 14:53:07
   date||


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

[Bug fortran/32084] gfortran 4.3 13%-18% slower for induct.f90 than gcc 4.0-based competitor

2007-05-25 Thread burnus at gcc dot gnu dot org



--- Comment #2 from burnus at gcc dot gnu dot org  2007-05-25 14:54 ---
Using the GCC 4.1.3 20070430 which comes with openSUSE Factory and contains
some patches from 4.2/4.3, I get the following timings:

$ gfortran-4.1 -march=opteron -ffast-math -funroll-loops -ftree-vectorize
-ftree-loop-linear -msse3 -O3 induct.f90
$ time a.out
real0m47.043s  user0m46.911s  sys 0m0.020s

which means that gcc/gfortran 4.1.3 was 10% faster for induct than 4.3's
gfortran, but still almost 10% slower than gcc/g95 4.0.3.


For the testcase (without "volatile"):
   real0m4.194s  user0m4.192s  sys 0m0.000s
which is timewise also between gfortran 4.3 and g95.


-- 


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

[Bug other/32078] Make FAILURE in 4.3.0 - `CXXFLAGS' has changed error causes "libltdl: No such file or directory"

2007-05-25 Thread pinskia at gcc dot gnu dot org



--- Comment #3 from pinskia at gcc dot gnu dot org  2007-05-25 15:17 ---
 Do either of you read the list?
http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01665.html


-- 


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

[Bug c++/32085] "warning: deleting void* is undefined" sometimes bogus

2007-05-25 Thread pinskia at gcc dot gnu dot org



--- Comment #1 from pinskia at gcc dot gnu dot org  2007-05-25 15:37 ---
No, even then it is still undefined because you don't call the deconstructor
for non-PODs.


-- 


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

[Bug other/32078] Make FAILURE in 4.3.0 - `CXXFLAGS' has changed error causes "libltdl: No such file or directory"

2007-05-25 Thread rob1weld at aol dot com



--- Comment #4 from rob1weld at aol dot com  2007-05-25 15:39 ---
>> Andrew Pinski 2007-05-25 15:17 
>> Do either of you read the list?

I search the Internet and use the search page at http://gcc.gnu.org/bugzilla
before I post a bug. I try to avoid dupes and look for fixes.

There may well be some wait time before http://gcc.gnu.org/ml/gcc-patches shows
up on Google. Is there a wait time before http://gcc.gnu.org/ml/gcc-patches
shows up on http://gcc.gnu.org/bugzilla ?


Bug two is not addressed in the thread you mentioned (and has been present for
months) - I do avoid complaining when I can.

Thanks for working on bug one.


-- 


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

[Bug other/32078] Make FAILURE in 4.3.0 - `CXXFLAGS' has changed error causes "libltdl: No such file or directory"

2007-05-25 Thread nathan at gcc dot gnu dot org



--- Comment #5 from nathan at gcc dot gnu dot org  2007-05-25 15:40 ---
This looks like it might be the same as this one
http://sourceware.org/ml/newlib/2007/msg00425.html

Anyone able to try that patch?


-- 


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

[Bug other/32078] Make FAILURE in 4.3.0 - `CXXFLAGS' has changed error causes "libltdl: No such file or directory"

2007-05-25 Thread rob1weld at aol dot com



--- Comment #6 from rob1weld at aol dot com  2007-05-25 15:59 ---
After winding up and down, back and forth through what seems to be a couple of
forks of discussion, I found a couple of different answers ...

The above comment means that the "References:" section at the bottom of the
posts changes on some posts and leads to other posts with different lists of
references - instead of simply being able to click-next.


The gist of it seems to be that the SVN was updated for all to obtain without
first testing amounst the maintainers (or other designated group):
http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01654.html


One person says it is fixed already:
http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01672.html

In another post they might have it fixed on the WEEKEND:
http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01692.html


-- 


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

[Bug c++/32085] "warning: deleting void* is undefined" sometimes bogus

2007-05-25 Thread andrew dot stubbs at st dot com



--- Comment #2 from andrew dot stubbs at st dot com  2007-05-25 16:16 
---
I'm confused.

It might be the case that there is a type for which this warning is valid - I
don't know C++ well enough to confirm or deny that - but in *this* example, and
perhaps others like it, the warning is mis-leading. I've tested the code, and
the delete operator does exactly what I would expect (or maybe that's what's
wrong?)

Is it not possible to distinguish cases where the warning is warranted and
cases where it is not?


-- 


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

[Bug c++/32085] "warning: deleting void* is undefined" sometimes bogus

2007-05-25 Thread pinskia at gcc dot gnu dot org



--- Comment #3 from pinskia at gcc dot gnu dot org  2007-05-25 16:51 ---
First the operator delete you created is overriding the normal operator delete
(which is valid).
Second you don't know the real type when deleting void* so it is hard to figure
out if we should warn or not.


-- 


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

[Bug libstdc++/31426] TR1 includes do not work with -std=c++0x

2007-05-25 Thread pcarlini at suse dot de



--- Comment #5 from pcarlini at suse dot de  2007-05-25 17:12 ---
(In reply to comment #2)
> I don't think support for C++0x precludes support for TR1. They coexist very
> well, especially because TR1 was designed to be compatible with C++0x. For
> example, C++0x-conforming implementations of the TR1 facilities also meet the
> requirements of TR1.

Hi Doug. Upon Benjamin' invitation, I'm working on this issue, with the initial
goal of making progress on the C++0x version of type_traits (for example, it
will exploit more front-end builtins).

Now, however, I do not agree completely with your statement above: certainly,
for example, a C++0x-conforming type_traits doesn't meet the requirements of
TR1. That, in turn, sheds doubts to the very point that TR1 facilities must be
available in C++0x mode: if the user does an using from namespace tr1 to
namespace std of a tr1 facility which finds a same-named, but incompatible
facility (i.e., implementing different semantics) in namespace std, which one
is supposed to "survive"?


-- 

pcarlini at suse dot de changed:

   What|Removed |Added

 CC||pcarlini at suse dot de


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

[Bug target/32086] New: 10% to 20% Performance Regression Between 4.1.3 and 4.3

2007-05-25 Thread burnus at gcc dot gnu dot org

The program induct.f90 of the Polyhedron testsuite,
http://www.polyhedron.co.uk/pb05/polyhedron_benchmark_suite.html, runs about
10% slower under 4.3 than under 4.1.3 (20070430 prerelease SUSE Linux).

A cut-down testcase "test2.f90 (attachment 13611 of PR 32084) shows the same
result. At least for the testcase, the original tree is almost identical for
4.3 and 4.1.3 which means that the difference must be the middle or backend.

Timings (w/o "volatile"):

a) gfortran -march=opteron -ffast-math -funroll-loops -ftree-vectorize
-ftree-loop-linear -msse3 -O3

induct.f90: 51.65 [100%] vs 46.94 [ 90%] for gfortran 4.3 vs. 4.1.3
test2.f90:   4.60 [100%] vs  4.18 [ 91%]

b) gfortran -m32 -march=opteron -ffast-math -funroll-loops -ftree-vectorize
-ftree-loop-linear -O3

induct.f90: 61.41 [100%] vs 46.94 [ 76%]
test2.f90:   5.45 [100%] vs  4.54 [ 83%]

c) gfortran -m32 -march=opteron -ffast-math -funroll-loops -ftree-vectorize
-ftree-loop-linear -msse3 -mfpmath=sse -O3

induct.f90: 46.12 [100%] vs 46.94 [102%]  (4.3 is better :-)
test2.f90:   4.14 [100%] vs  3.96 [ 96%]

(For the other polyhedron test cases, the performance loss is less: tfft 4%
slower, protein 3%, doduc 3%, channel 2%; in total 4.3 is faster, for fatigue
4.1.3 takes twice as long as 4.3. See:
http://physik.fu-berlin.de/~tburnus/gcc-trunk/benchmark/#rt)


-- 
   Summary: 10% to 20% Performance Regression Between 4.1.3 and 4.3
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
GCC target triplet: x86_64-unknown-linux-gnu
OtherBugsDependingO 32084
 nThis:


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

[Bug libfortran/31933] Uninitialized memory when writing real(10) as unformatted

2007-05-25 Thread jvdelisle at gcc dot gnu dot org



--- Comment #8 from jvdelisle at gcc dot gnu dot org  2007-05-25 17:43 
---
Closing.  Added the following comment to transfer.c:

/* Master function for unformatted writes.  NOTE: For kind=10 the size is 16
   bytes on 64 bit machines.  The unused bytes are not initialized and never
   used, which can show an error with memory checking analyzers like
   valgrind.  */


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||WONTFIX


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

[Bug c++/31445] [4.3 regression] type_argument_pack not supported by dump_type

2007-05-25 Thread dgregor at gcc dot gnu dot org



--- Comment #3 from dgregor at gcc dot gnu dot org  2007-05-25 17:53 ---
Fixed on mainline.


-- 

dgregor at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c++/31443] [4.3 regression] ICE with invalid use of parameter pack in member template

2007-05-25 Thread dgregor at gcc dot gnu dot org



--- Comment #2 from dgregor at gcc dot gnu dot org  2007-05-25 17:53 ---
Fixed on mainline.


-- 

dgregor at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c++/31437] [4.3 regression] ICE with invalid use of parameter pack in member function arg

2007-05-25 Thread dgregor at gcc dot gnu dot org



--- Comment #2 from dgregor at gcc dot gnu dot org  2007-05-25 17:54 ---
Fixed on mainline.


-- 

dgregor at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c++/31431] [4.3 regression] ICE with invalid parameter pack

2007-05-25 Thread dgregor at gcc dot gnu dot org



--- Comment #2 from dgregor at gcc dot gnu dot org  2007-05-25 17:54 ---
Fixed on mainline.


-- 

dgregor at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c++/31442] [4.3 regression] ICE with variadic template and default argument

2007-05-25 Thread dgregor at gcc dot gnu dot org



--- Comment #2 from dgregor at gcc dot gnu dot org  2007-05-25 17:54 ---
Fixed on mainline.


-- 

dgregor at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c++/31432] [4.3 regression] ICE with invalid parameter pack for template struct

2007-05-25 Thread dgregor at gcc dot gnu dot org



--- Comment #2 from dgregor at gcc dot gnu dot org  2007-05-25 17:55 ---
Fixed on mainline.


-- 

dgregor at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c++/31438] [4.3 regression] ICE with invalid use of parameter pack in specialization

2007-05-25 Thread dgregor at gcc dot gnu dot org



--- Comment #2 from dgregor at gcc dot gnu dot org  2007-05-25 17:55 ---
Fixed on mainline.


-- 

dgregor at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c++/31434] [4.3 regression] ICE with invalid use of parameter pack in function arg

2007-05-25 Thread dgregor at gcc dot gnu dot org



--- Comment #2 from dgregor at gcc dot gnu dot org  2007-05-25 17:54 ---
Fixed on mainline.


-- 

dgregor at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug libstdc++/31426] TR1 includes do not work with -std=c++0x

2007-05-25 Thread pcarlini at suse dot de



--- Comment #6 from pcarlini at suse dot de  2007-05-25 17:39 ---
Nevermind: that scenerio is illegal anyway, of course. I think I will just try
to implement what you suggested on libstdc++ some time ago...


-- 

pcarlini at suse dot de changed:

   What|Removed |Added

 AssignedTo|bkoz at gcc dot gnu dot org |pcarlini at suse dot de


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

[Bug libgcj/32028] Make fails at gjdoc - gnu.classpath.tools.gjdoc.ParseException: unmatched input in line 1: @Retention(SOURCE) @Target(METHOD)

2007-05-25 Thread rob1weld at aol dot com



--- Comment #4 from rob1weld at aol dot com  2007-05-25 19:12 ---
Tom, here are the results you requested:


...
touch resources
make[4]: Leaving directory
`/opt/gcc-4_3-build/i686-pc-linux-gnu/libjava/classpath/lib'
Making all in doc
make[4]: Entering directory
`/opt/gcc-4_3-build/i686-pc-linux-gnu/libjava/classpath/doc'
Making all in api
make[5]: Entering directory
`/opt/gcc-4_3-build/i686-pc-linux-gnu/libjava/classpath/doc/api'
/bin/mkdir html > /dev/null 2>&1
/usr/local/bin/gjdoc \
-use \
-sourcepath
"../..:/root/downloads/gcc-4_3-trunk/libjava/classpath:/root/downloads/gcc-4_3-trunk/libjava/classpath/vm/reference:/root/downloads/gcc-4_3-trunk/libjava/classpath/external/w3c_dom:/root/downloads/gcc-4_3-trunk/libjava/classpath/external/sax"
\
-encoding UTF-8 \
-breakiterator \
-licensetext \
-linksource \
-splitindex \
-validhtml \
-d html \
-doctitle "GNU Classpath 0.94-pre" \
-windowtitle "GNU Classpath 0.94-pre Documentation" \
-header "GNU Classpath
(0.94-pre)" -footer "GNU Classpath
(0.94-pre)" \
-subpackages java:javax:org
WARNING: unknown modifier '@Retention(SOURCE)'
WARNING: unknown modifier '@Target(METHOD)'
WARNING: unknown modifier '@Retention(SOURCE)'
WARNING: unknown modifier '@Target({TYPE, FIELD, METHOD, PARAMETER,
CONSTRUCTOR, LOCAL_VARIABLE})'
WARNING: unknown modifier '@Documented'
WARNING: unknown modifier '@Retention(RUNTIME)'
ARGH! public
ARGH! static
ARGH! >
ARGH! S
ARGH! valueOf(Class
ARGH! String
ARGH! s)
Loading classes for package java.sql...
Loading classes for package java.lang...
Loading classes for package java.lang.reflect...
Loading classes for package java.lang.instrument...
Loading classes for package java.lang.ref...
Loading classes for package java.lang.annotation...
WARNING: unknown modifier '@Documented'
WARNING: unknown modifier '@Retention(RUNTIME)'
WARNING: unknown modifier '@Target(ANNOTATION_TYPE)'
WARNING: unknown modifier '@Documented'
WARNING: unknown modifier '@Retention(RUNTIME)'
WARNING: unknown modifier '@Documented'
WARNING: unknown modifier '@Retention(RUNTIME)'
WARNING: unknown modifier '@Target(ANNOTATION_TYPE)'
WARNING: unknown modifier '@Documented'
WARNING: unknown modifier '@Retention(RUNTIME)'
WARNING: unknown modifier '@Target(ANNOTATION_TYPE)'
Loading classes for package java.lang.management...
Loading classes for package java.text...
Loading classes for package java.applet...
Loading classes for package java.nio...
Loading classes for package java.nio.charset...
Loading classes for package java.nio.charset.spi...
Loading classes for package java.nio.channels...
Loading classes for package java.nio.channels.spi...
Loading classes for package java.net...
Loading classes for package java.io...
Loading classes for package java.rmi...
Loading classes for package java.rmi.dgc...
Loading classes for package java.rmi.activation...
Loading classes for package java.rmi.server...
Loading classes for package java.rmi.registry...
Loading classes for package java.security...
Loading classes for package java.security.interfaces...
Loading classes for package java.security.cert...
Loading classes for package java.security.acl...
Loading classes for package java.security.spec...
Loading classes for package java.beans...
Loading classes for package java.beans.beancontext...
Loading classes for package java.math...
Loading classes for package java.awt...
Loading classes for package java.awt.image...
Loading classes for package java.awt.image.renderable...
Loading classes for package java.awt.peer...
Loading classes for package java.awt.color...
Loading classes for package java.awt.datatransfer...
Loading classes for package java.awt.event...
Loading classes for package java.awt.geom...
Loading classes for package java.awt.print...
Loading classes for package java.awt.dnd...
Loading classes for package java.awt.dnd.peer...
Loading classes for package java.awt.im...
Loading classes for package java.awt.im.spi...
Loading classes for package java.awt.font...
Loading classes for package java.util...
Loading classes for package java.util.concurrent...
Loading classes for package java.util.regex...
Loading classes for package java.util.jar...
Loading classes for package java.util.prefs...
Loading classes for package java.util.logging...
Loading classes for package java.util.zip...
Loading classes for package javax.sql...
Loading classes for package javax.crypto...
Loading classes for package javax.crypto.interfaces...
Loading classes for package javax.crypto.spec...
Loading classes for package javax.xml...
Loading classes for package javax.xml.parsers...
Loading classes for package javax.xml.xpath...
Loading classes for package javax.xml.validation...
Loading classes for package javax.xml.datatype...
Loading classes for package javax.xml.stream...
Loading classes for package javax.xml.stream.events...
Loading classes for package javax.xml.stream.util...
Lo

[Bug libfortran/24685] real(16) formatted input is broken for huge values

2007-05-25 Thread jvdelisle at gcc dot gnu dot org



--- Comment #22 from jvdelisle at gcc dot gnu dot org  2007-05-25 19:50 
---
Is this still broken or can we close?  I would like to fix this if possible.


-- 


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

[Bug c++/31745] [4.3 regression] ICE on invalid use of namespace

2007-05-25 Thread simartin at gcc dot gnu dot org

--- Comment #2 from simartin at gcc dot gnu dot org  2007-05-25 20:27 
---
Subject: Bug 31745

Author: simartin
Date: Fri May 25 20:26:36 2007
New Revision: 125070

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125070
Log:
2007-05-25  Simon Martin  <[EMAIL PROTECTED]>
Manuel Lopez-Ibanez  <[EMAIL PROTECTED]>

PR c++/31745
* parser.c (cp_parser_skip_to_closing_brace): Return true if the next
token is a closing brace, false if there are no tokens left.
(cp_parser_namespace_alias_definition): Only consume the next token if
it is a closing brace.

* parser.c (cp_parser_class_specifier): Likewise.

Added:
trunk/gcc/testsuite/g++.dg/parse/crash34.C
trunk/gcc/testsuite/g++.dg/parse/crash35.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog

-- 

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

[Bug rtl-optimization/17387] Redundant instructions in loop optimization

2007-05-25 Thread steven at gcc dot gnu dot org



--- Comment #22 from steven at gcc dot gnu dot org  2007-05-25 20:32 ---
With the current implementation of SEE it is almost impossible to make it work
on x86.  You have to take into account the liveness of the flags register, and
there currently is no way to include that in the dataflow equations.  Maybe
someone else knows how to do this...


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug other/19180] How to Add New GCC option

2007-05-25 Thread steven at gcc dot gnu dot org



-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug other/3386] Undocumented target macros in 3.0

2007-05-25 Thread steven at gcc dot gnu dot org



-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug c++/31745] [4.3 regression] ICE on invalid use of namespace

2007-05-25 Thread simartin at gcc dot gnu dot org



--- Comment #3 from simartin at gcc dot gnu dot org  2007-05-25 20:33 
---
Fixed on the mainline.


-- 

simartin at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug rtl-optimization/30287] -fregmove produces slow code

2007-05-25 Thread steven at gcc dot gnu dot org



--- Comment #4 from steven at gcc dot gnu dot org  2007-05-25 20:35 ---
Something in the backward pass increases the register pressure, inducing extra
spills.  Not much can be done about this except for tuning the transformations
involved.


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug fortran/32048] max / min and NaN

2007-05-25 Thread tkoenig at gcc dot gnu dot org



--- Comment #6 from tkoenig at gcc dot gnu dot org  2007-05-25 20:36 ---
(In reply to comment #5)
> Of course people are complaining that min/max as of IEEE does not propagate
> NaNs
> as other operations do.

We could add flags like -fpropagate-nan, -fno-propagate-nan
and -fdontcare-propagate-nan (no, I'm not serious
about the last option).


-- 


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

[Bug java/31853] ICE in bootstrap compiling gnu.CORBA.ObjectCreator

2007-05-25 Thread tromey at gcc dot gnu dot org



--- Comment #5 from tromey at gcc dot gnu dot org  2007-05-25 21:05 ---
Thanks for your response.
Closing as fixed in 4.2.


-- 

tromey at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.2.0


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

[Bug c++/31745] [4.3 regression] ICE on invalid use of namespace

2007-05-25 Thread pinskia at gcc dot gnu dot org



--- Comment #4 from pinskia at gcc dot gnu dot org  2007-05-25 21:11 ---
Fixed.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug tree-optimization/32087] New: ICE with FORTRAN and -fprefetch-loop-arrays

2007-05-25 Thread sje at cup dot hp dot com

The following program will ICE when compiled with -O2 -fprefetch-loop-arrays on
a x86_64 box or on IA64 box (Linux and/or HP-UX in 64 bit mode). 
scale_bbs_frequencies_int is called with nbbs=1, num=0, and den=0.  Since we do
a division by den, the compiler aborts during the division.  If we give X a
size of 2 instead of 1, the ICE does not happen.


$ cat x.f
  SUBROUTINE TFHF(HINT,NVAR,NCOORD,LDI)
  IMPLICIT DOUBLE PRECISION(A-H,O-Z)
  DIMENSION HINT(LDI,NVAR)
  COMMON /FMCOM / X(1)
  LHI   = 1 + LOADFM + (NCOORD*NVAR) + (NCOORD*NCOORD+NCOORD)/2
  LOC = LHI-1
  DO 160 I = 1,NVAR
 DO 150 J = 1,I
LOC = LOC + 1
HINT(I,J) = X(LOC)
HINT(J,I) = X(LOC)
  150CONTINUE
  160 CONTINUE
  RETURN
  END

$ gfortran -O2 -fprefetch-loop-arrays -c x.f

x.f: In function 'tfhf':
x.f:1: internal compiler error: Floating point exception
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.


-- 
   Summary: ICE with FORTRAN and -fprefetch-loop-arrays
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sje at cup dot hp dot com
GCC target triplet: x86_64-*-* ia64-*-*


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

[Bug fortran/32088] New: ICE (doesn't occur if given function standalone instead on internal)

2007-05-25 Thread awgreynolds at earthlink dot net

C:\mingw\bugs>type bug.f90
subroutine dummy
contains
  function quadric(a,b) result(c)
  intent(in) a,b; dimension a(0:3),b(0:3),c(0:9)
c(0)=a(0)*b(0); c(1:3)=a(1:)*b(0)+a(0)*b(1:); c(4:6)=a(1:)*b(1:)
c(7:9)=(/a(1)*b(2)+b(1)*a(2),a(1)*b(3)+b(1)*a(3),a(2)*b(3)+b(2)*a(3)/)
  end function
end
C:\mingw\bugs>gfortran -c -v bug.f90
Using built-in specs.
Target: i386-pc-mingw32
Configured with: ../trunk/configure --prefix=/mingw
--enable-languages=c,fortran --with-gmp=/hom
Thread model: win32
gcc version 4.3.0 20070522 (experimental)
 c:/program files/gfortran/bin/../libexec/gcc/i386-pc-mingw32/4.3.0/f951.exe
bug.f90 -quiet -dum
GNU F95 version 4.3.0 20070522 (experimental) (i386-pc-mingw32)
compiled by GNU C version 4.3.0 20070522 (experimental), GMP version
4.2.1, MPFR version
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
bug.f90: In function 'quadric':
bug.f90:3: internal compiler error: in gfc_trans_dummy_array_bias, at
fortran/trans-array.c:4006


-- 
   Summary: ICE (doesn't occur if given function standalone instead
on internal)
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: awgreynolds at earthlink dot net


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

[Bug fortran/32088] ICE (doesn't occur if given function standalone instead on internal)

2007-05-25 Thread pinskia at gcc dot gnu dot org



-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|critical|normal


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

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

2007-05-25 Thread mckelvey at maskull dot com

CircularlyReferenceable.cc:76: error: called from here
/usr/local/lib/gcc/alphaev56-unknown-linux-gnu/4.3.0/../../../../
include/c++/4.3.0/bits/stl_multiset.h:91: error: 
inlining failed in call to 'std::multiset, 
std::allocator >::
~multiset()': call is unlikely
CircularlyReferenceable.cc:76: error: called from here
gmake: *** [CircularlyReferenceable.o] Error 1

This error (actually a warning) makes no sense: how can a destructor call be 
unlikely? What does that mean? I suspect that the warning is badly worded. What
is intended here?

Also, multiset is in the STL, and Winline should not be reporting against it.

alpha1:gcc>uname -a
Linux alpha1 2.4.9-40 #1 Mon Sep 23 08:14:02 EDT 2002 alpha unknown

alpha1:gcc>g++ -v
Using built-in specs.
Target: alphaev56-unknown-linux-gnu
Configured with: ../gcc/configure --verbose --enable-languages=c++
--disable-linux-futex --disable-nls --disable-tls
Thread model: posix
gcc version 4.3.0 20070519 (experimental)

alpha1:gcc>alias CONFIGURECVS
alias CONFIGURECVS='../gcc/configure --verbose --enable-languages=c++
--disable-linux-futex --disable-nls --disable-tls >clog 2>&1 &'
alpha1:gcc>alias BUILD
alias BUILD='nice gmake CFLAGS='\'''\'' BOOT_CFLAGS='\'''\''
LIBCFLAGS='\''-g'\'' LIBCXXFLAGS='\''-g'\'' bootstrap >log 2>&1 &'


-- 
   Summary: Winline reports bogus warning
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mckelvey at maskull dot com
 GCC build triplet: alphaev56-unknown-linux-gnu
  GCC host triplet: alphaev56-unknown-linux-gnu
GCC target triplet: alphaev56-unknown-linux-gnu


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

[Bug tree-optimization/32090] New: ICE in forwprop with zero sized array

2007-05-25 Thread pinskia at gcc dot gnu dot org

C++ testcase:
struct JArray
{
  int data[0];
};
int copyIntoByteArray (struct JArray *dest, int offset)
{
  void *pdest = dest->data + offset;
}
- cut ---
backtrace:
#0  0x08d6a47c in integer_onep (expr=0x0) at
/home/apinski/src/gcc-fsf/bugfixes/gcc/gcc/tree.c:1311
#1  0x08b69fea in forward_propagate_addr_into_variable_array_index
(offset=0xb7c5c444, lhs=0xb7c5c4ac, def_rhs=0xb7cd7da0,
use_stmt=0xb7d2178c) at
/home/apinski/src/gcc-fsf/bugfixes/gcc/gcc/tree-ssa-forwprop.c:519
#2  0x08b6bcd0 in forward_propagate_addr_expr_1 (name=0xb7c5c3a8,
def_rhs=0xb7cd7da0, use_stmt=0xb7d2178c, single_use_p=1 '\001')
at /home/apinski/src/gcc-fsf/bugfixes/gcc/gcc/tree-ssa-forwprop.c:682
#3  0x08b6c1e3 in forward_propagate_addr_expr (name=0xb7c5c3a8, rhs=0xb7cd7da0)
at /home/apinski/src/gcc-fsf/bugfixes/gcc/gcc/tree-ssa-forwprop.c:750
#4  0x08b6ecbf in tree_ssa_forward_propagate_single_use_vars () at
/home/apinski/src/gcc-fsf/bugfixes/gcc/gcc/tree-ssa-forwprop.c:999


-- 
   Summary: ICE in forwprop with zero sized array
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code, build
  Severity: blocker
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org


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

[Bug tree-optimization/32090] ICE in forwprop with zero sized array

2007-05-25 Thread pinskia at gcc dot gnu dot org



-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.3.0


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

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

2007-05-25 Thread pinskia at gcc dot gnu dot org



--- Comment #1 from pinskia at gcc dot gnu dot org  2007-05-25 22:30 ---
First the deconstructor was either defaulted to inline or marked as such.
Second what are the full options do you use?

If the call is unlikely (which it says in your case), then there is no reason
to inline it.  I bet this comes from exceptions.


-- 


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

[Bug tree-optimization/32090] [4.3 Regression] ICE in forwprop with zero sized array

2007-05-25 Thread pinskia at gcc dot gnu dot org



--- Comment #1 from pinskia at gcc dot gnu dot org  2007-05-25 22:32 ---
This is obviously caused by:
2007-05-25  Richard Guenther  <[EMAIL PROTECTED]>

PR tree-optimization/31982
* tree-ssa-forwprop.c
(forward_propagate_addr_into_variable_array_index): Handle arrays
with element size one.


Note this causes a bootstrap failure once libjava's configure issue is fixed.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|ICE in forwprop with zero   |[4.3 Regression] ICE in
   |sized array |forwprop with zero sized
   ||array


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

[Bug target/32065] Many dfp testsuite failures for -msse targets

2007-05-25 Thread uros at gcc dot gnu dot org

--- Comment #3 from uros at gcc dot gnu dot org  2007-05-25 22:36 ---
Subject: Bug 32065

Author: uros
Date: Fri May 25 22:36:10 2007
New Revision: 125077

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125077
Log:
PR target/32065
* target/i386/i386.c (ix86_expand_vector_move): Force SUBREGs of
constants into memory.  Expand unaligned memory references for
SSE modes via x86_expand_vector_move_misalign() function.

testsuite/ChangeLog:

PR target/32065
* gcc.target/i386/pr32065.c: New test.

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

-- 

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

[Bug target/32065] Many dfp testsuite failures for -msse targets

2007-05-25 Thread ubizjak at gmail dot com



--- Comment #4 from ubizjak at gmail dot com  2007-05-25 22:39 ---
Fixed on mainline.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.3.0


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

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

2007-05-25 Thread mckelvey at maskull dot com



--- Comment #2 from mckelvey at maskull dot com  2007-05-25 23:03 ---
Here is how I compile it:

/usr/local/bin/g++ -c -O3 -DNDEBUG -Wuninitialized -pedantic-errors -Werror 
-Winline -ansi -fno-common -Wall -Wold-style-cast -Wsign-promo -Wpointer-arith 
-Wundef -Wwrite-strings -Winvalid-pch -Woverloaded-virtual -Wcast-qual -Wextra 
-Wredundant-decls -Wshadow -Wcast-align -Wcomment -fstrict-aliasing 
-Winit-self -Wmissing-include-dirs -Wswitch-default -Wswitch-enum -Wlogical-op 
-Wunused -fvisibility-inlines-hidden -MMD  
-fimplicit-templates -o CircularlyReferenceable.o CircularlyReferenceable.cc

"froms" is the multiset. The destructor will be called in the normal case.
There
is an exception, but it is thrown before the multiset is even created.

SeenMultiset froms;

if (from != PDNULL)
{
froms.insert(from);
}

// Record we've been seen
seen_map.insert(std::make_pair(this, froms));

return true;

The warning points at the seen_map.insert and the return.

Whole member function:

bool CircularlyReferenceable::

_accumulate_delete_candidates(
const CircularlyReferenceable * const from,
SeenMap&  seen_map) const
{
if (! _is_allocated())
{
if (! get_strict())
{
return false;
}

throw InternalException(_message(_msgtext("Inconsistent reference "
  "count: %s(0)::%s(1)"),
 name(),
 "_accumulate_delete_candidates"),
__FILE__,
__LINE__);
}

// Get our entry (if there is one)
const SeenMap::iterator it(seen_map.find(this));

if (it == seen_map.end())
{
// We haven't been seen before; make an entry

SeenMultiset froms;

if (from != PDNULL)
{
froms.insert(from);
}

// Record we've been seen
seen_map.insert(std::make_pair(this, froms));

return true;
}

// We have been seen before, update the set of pointers to us

if (from != PDNULL)
{
it->second.insert(from);
}

return false;
}


-- 


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

[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should

2007-05-25 Thread ian at airs dot com



--- Comment #159 from ian at airs dot com  2007-05-25 23:21 ---
Created an attachment (id=13613)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13613&action=view)
Patch

This version of the patch is based on some code from Daniel Berlin.  Here we
determine which pointers can potentially be associated with a placement new. 
We disable TBAA specifically for those pointers.

I'm not 100% confident that this patch always does the right thing.  But it
does work for the test cases I tried.

Richi, I'd be interested in results you get from your performance tests.


-- 

ian at airs dot com changed:

   What|Removed |Added

  Attachment #13553|0   |1
is obsolete||


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

[Bug fortran/32088] ICE (doesn't occur if given function standalone instead on internal)

2007-05-25 Thread jvdelisle at gcc dot gnu dot org



--- Comment #1 from jvdelisle at gcc dot gnu dot org  2007-05-25 23:36 
---
Further reduced case:

subroutine dummy
contains
  function quadric(a,b) result(c)
  dimension a(0:3),b(0:3),c(0:9)
c(0)=1.1
  end function
end


-- 


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

[Bug tree-optimization/32090] [4.3 Regression] ICE in forwprop with zero sized array

2007-05-25 Thread pinskia at gcc dot gnu dot org



--- Comment #2 from pinskia at gcc dot gnu dot org  2007-05-25 23:38 ---
I have a fix.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |pinskia at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-05-25 23:38:15
   date||


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

[Bug fortran/32088] [4.3 Regression] ICE (doesn't occur if given function standalone instead on internal)

2007-05-25 Thread jvdelisle at gcc dot gnu dot org



--- Comment #2 from jvdelisle at gcc dot gnu dot org  2007-05-25 23:39 
---
This does not ice with 4.1 or 4.2


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-05-25 23:39:45
   date||
Summary|ICE (doesn't occur if given |[4.3 Regression] ICE
   |function standalone instead |(doesn't occur if given
   |on internal)|function standalone instead
   ||on internal)


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

[Bug fortran/32088] [4.3 Regression] ICE (doesn't occur if given function standalone instead on internal)

2007-05-25 Thread burnus at gcc dot gnu dot org



--- Comment #3 from burnus at gcc dot gnu dot org  2007-05-26 00:35 ---
Failure was introduced between 2007-04-04-r123491 and 2007-04-11-r123712

My guess would be that it is the following patch:
r123641 | pault | 2007-04-07 22:13:52 +0200 (Sa, 07 Apr 2007) | 14 lines

2007-04-07  Paul Thomas  <[EMAIL PROTECTED]>

PR fortran/31293
* symbol.c (gfc_check_function_type): New function. [...]

This function looks as follows:
+/* This function is called from parse.c(parse_progunit) to check the
+   type of the function is not implicitly typed in the host namespace
+   and to implicitly type the function result, if necessary.  */
+gfc_check_function_type (gfc_namespace *ns)
+  gfc_symbol *proc = ns->proc_name;
+  if (!proc->attr.contained || proc->result->attr.implicit_type)
+return;
+  if (proc->result->ts.type == BT_UNKNOWN)

Here, proc->attr.contained = 1 and for some reason:
proc->result->attr.implicit_type = 0 (shouldn't this be 1? ts.type =
BT_UNKNOWN)

In any case, if I simply return in this function, the ICE is gone. The question
is now, why is proc->result->attr.implicit_type not set?


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pault at gcc dot gnu dot
   ||org, burnus at gcc dot gnu
   ||dot org
   Keywords||ice-on-valid-code
  Known to fail||4.3.0
  Known to work||4.2.0 4.1.3
   Target Milestone|--- |4.3.0


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

(g77) internal compiler error: Segmentation fault

2007-05-25 Thread Roland Winkler

The (shortened) fortran-77 subroutine attached below causes a
segmentation fault of g77 when I execute

$ g77 -O3 -c -funroll-loops  foo.f

No problems occur without optimization.

$ g77 --version
GNU Fortran (GCC) 3.3.5 20050117 (prerelease) (SUSE Linux)
Copyright (C) 2002 Free Software Foundation, Inc.

(I have SUSE Linux 10.2)

Let me know if you need to know anything else.

Roland



  SUBROUTINE FOO
C
  IMPLICIT NONE
  INTEGER   ngroup, nirred
  PARAMETER(ngroup = 1, nirred = 24)
  INTEGER   mgroup, melmnt, mirred
  INTEGER   nfull, okanal
  PARAMETER(nfull  = 3)
  INTEGER   lirred,i, j, k, js, Jsmax (2), lwert, jwert,
 $  Isubcp (nirred, 2, 0:nfull, 0:1)
  DOUBLE PRECISION  eps, fak1
  DOUBLE COMPLEXSubcmp (nirred, 2)
  CHARACTER Csign (2) *1, C_sa (2) *1
  DATA  Csign  / '+', '-' /, C_sa / 's', 'a' /
C **
  DO mgroup = 1, ngroup
   DO js = 0, 1
DO lwert = 0, nfull
 jwert = 2 * lwert + js
 DO k = 1, 2
  j = 0
  DO lirred = 1, mirred
   IF ( ABS (DIMAG (Subcmp (lirred,k))) .GT. eps
 $ .OR. ABS (DBLE (i) - fak1) .GT. eps)
 $  WRITE (0, *) 'UG2:', jwert, k, lirred,
 $Subcmp (lirred,k)
  END DO
 END DO
END DO
   END DO
  999  CONTINUE
  END DO
C ==
  WRITE (okanal, 1220) (((Csign (j), C_sa (k), jwert, k = 1, 2),
 $  j = 1, 2), jwert = 0, nfull/2)
 1220 FORMAT (/ 11X, 100 (4 (2A, I1, 1X), 1X))
C
  STOP
  END

[Bug fortran/31813] Warn about deleted feature: H edit descriptor

2007-05-25 Thread jvdelisle at gcc dot gnu dot org



--- Comment #1 from jvdelisle at gcc dot gnu dot org  2007-05-26 01:05 
---
I will see if i cna do something here.


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jvdelisle at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-05-26 01:05:14
   date||


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

Re: (g77) internal compiler error: Segmentation fault

2007-05-25 Thread Jerry DeLisle


Roland Winkler wrote:

The (shortened) fortran-77 subroutine attached below causes a
segmentation fault of g77 when I execute

$ g77 -O3 -c -funroll-loops  foo.f

No problems occur without optimization.

$ g77 --version
GNU Fortran (GCC) 3.3.5 20050117 (prerelease) (SUSE Linux)
Copyright (C) 2002 Free Software Foundation, Inc.

(I have SUSE Linux 10.2)

Let me know if you need to know anything else.

G77 is no longer maintained.  The new fortran compiler is gfortran and it 
supports f77 code.  I will test to see if gfortran handles your test case.


Also, please correspond with the gfortran list on this so we fortraners can help 
you here.  There are gfortran binaries available.  Let me know if you need help 
with this.  Also helps to know what hardware platform you are on and what OS you 
are using.


Regards,

Jerry

[Bug other/32078] Make FAILURE in 4.3.0 - `CXXFLAGS' has changed error causes "libltdl: No such file or directory"

2007-05-25 Thread howarth at nitro dot med dot uc dot edu



--- Comment #7 from howarth at nitro dot med dot uc dot edu  2007-05-26 
02:43 ---
>From http://gcc.gnu.org/viewcvs?view=rev&revision=125032, it appears that
libjava/libltdl was omitted from the regeneration as well.


-- 


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

[Bug fortran/32047] ICE (segfault) for pure function without argument

2007-05-25 Thread pinskia at gcc dot gnu dot org



-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.3.0


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

[Bug fortran/18769] ICE in gfc_conv_array_initializer with array initialization with transfer

2007-05-25 Thread pinskia at gcc dot gnu dot org



-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.3.0


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

[Bug fortran/30881] Select case of case(transfer(...)) wrongly rejected

2007-05-25 Thread pinskia at gcc dot gnu dot org



-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.3.0


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

[Bug fortran/31194] NaN transfer - internal compiler error: in gfc_conv_constant

2007-05-25 Thread pinskia at gcc dot gnu dot org



-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.3.0


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

[Bug fortran/31216] TRANSFER in CASE leads to ICE

2007-05-25 Thread pinskia at gcc dot gnu dot org



-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.3.0


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

[Bug fortran/31427] TRANSFER with mold kind /= lval kind: ICE on ia64, i686; no warning

2007-05-25 Thread pinskia at gcc dot gnu dot org



-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.3.0


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

1 2 >

1 - 100 of 120 matches

Mail list logo