[Bug middle-end/38868] r143152 breaks output routines in xplor-nih

[howarth at nitro dot med dot uc dot edu]

--- Comment #7 from howarth at nitro dot med dot uc dot edu  2009-01-16 
07:21 ---
This problem is also suppressed on i686-apple-darwin9 if I compile with...

gfortran -O3 -fno-PIC testcase.f

...since Darwin defaults to -fPIC, this may be why I wasn't seeing the failure
on Linux.


-- 


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

[Bug bootstrap/37660] [4.4 Regression] Error Building libssp, recent update

[dannysmith at users dot sourceforge dot net]

--- Comment #5 from dannysmith at users dot sourceforge dot net  2009-01-16 
07:14 ---
(In reply to comment #4)
>   I've just run into this problem too.
>   In earlier versions of Aaron's shared libgcc patch, we extracted ctors.o and
> chkstk.o and placed them whole into the import lib.  I'm not sure why he 
> didn't
> do this in the committed version, but it has the effect that you have to link
> against the static libgcc as well as the shared one in order to let it fill 
> out
> any missing references.  I'm not sure I'm entirely comfortable with that,
> although I can't think of any obvious problem, but it seems wrong to link
> against such a duplicated body of code to me, and I think I'd prefer the 
> import
> lib solution for cygwin's compiler. 


If you look at the (static) libgcc.a,  when shared libs are enabled, it
contains only symbols that are not exported from the shared dll. Only the
'API-stable' symbols are exported.  That is a good thing.  So the libgcc.a code
 does not duplicate any code in libgcc_s.[a|dll].


-- 

dannysmith at users dot sourceforge dot net changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-01-16 07:14:38
   date||


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

[Bug middle-end/38868] r143152 breaks output routines in xplor-nih

[howarth at nitro dot med dot uc dot edu]

--- Comment #6 from howarth at nitro dot med dot uc dot edu  2009-01-16 
07:14 ---
I haven't had any luck reproducing this under Linux but since the problem is
suppressed by adding write statements it may be a bad memory access that only
darwin is triggering.


-- 


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

[Bug middle-end/38868] r143152 breaks output routines in xplor-nih

[howarth at nitro dot med dot uc dot edu]

--- Comment #5 from howarth at nitro dot med dot uc dot edu  2009-01-16 
07:12 ---
Created an attachment (id=17116)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17116&action=view)
diff of assembly from testcase.f under r143140 and r143152 on
i686-apple-darwin9


-- 


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

[Bug middle-end/38868] r143152 breaks output routines in xplor-nih

[howarth at nitro dot med dot uc dot edu]

--- Comment #4 from howarth at nitro dot med dot uc dot edu  2009-01-16 
07:11 ---
Created an attachment (id=17115)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17115&action=view)
assembly file from testcase.f under r143152 on i686-apple-darwin9


-- 


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

[Bug middle-end/38868] r143152 breaks output routines in xplor-nih

[howarth at nitro dot med dot uc dot edu]

--- Comment #3 from howarth at nitro dot med dot uc dot edu  2009-01-16 
07:10 ---
Created an attachment (id=17114)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17114&action=view)
assembly file from testcase.f under r143140 on i686-apple-darwin9


-- 


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

[Bug middle-end/38868] r143152 breaks output routines in xplor-nih

[howarth at nitro dot med dot uc dot edu]

--- Comment #2 from howarth at nitro dot med dot uc dot edu  2009-01-16 
07:08 ---
The problem exists in r143152 but not r143140.


-- 


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

[Bug middle-end/38868] r143152 breaks output routines in xplor-nih

[howarth at nitro dot med dot uc dot edu]

--- Comment #1 from howarth at nitro dot med dot uc dot edu  2009-01-16 
07:07 ---
Created an attachment (id=17113)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17113&action=view)
testcase extracted from xplor-nih


-- 


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

[Bug middle-end/38868] New: r143152 breaks output routines in xplor-nih

[howarth at nitro dot med dot uc dot edu]

The change

Author: rguenth
Date: Wed Jan  7 10:53:30 2009
New Revision: 143152

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143152
Log:
2009-01-07  Richard Guenther  

PR middle-end/38751
* fold-const.c (extract_muldiv): Remove obsolete comment.
(fold_plusminus_mult_expr): Undo MINUS_EXPR
to PLUS_EXPR canonicalization for the canonicalization.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c

causes broken code in xplor-nih when compiled with -O2 or higher. Specifically,
the output
routine in xplor-nih losses the final character of a line. For example...

 | Etotal =-0.012 grad(E)=0.005  E(BOND)=0.000  E(ANGL)=0.000 
|
 | E(DIHE)=0.000  E(IMPR)=0.000  E(VDW )=-0.012 E(ELEC)=0.000 
|

becomes...

 | Etotal =-0.012 grad(E)=0.005  E(BOND)=0.000  E(ANGL)=0.000 
|
 | E(DIHE)=0.000  E(IMPR)=0.000  E(VDW )=-0.012 E(ELEC)=0.000   

The problem doesn't occur at -O0 or -O1 and doesn't occur if I use
-funroll-loops or
-funroll-all-loops. I also can also suppress the problem by adding a final
write(6,*) statement
to the test program.


-- 
   Summary: r143152 breaks output routines in xplor-nih
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: howarth at nitro dot med dot uc dot edu
 GCC build triplet: i686-apple-darwin9
  GCC host triplet: i686-apple-darwin9
GCC target triplet: i686-apple-darwin9


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

[Bug bootstrap/38867] New: [Regression] gcc 4.4.0 20090114 - libjava/configure sets "NONE/share/python", need "${prefix}/share/python"

[rob1weld at aol dot com]

# gcc/xgcc -v
Using built-in specs.
Target: i386-pc-solaris2.11
Configured with: ../gcc_trunk/configure
--enable-languages=ada,c,c++,fortran,java,objc,obj-c++ --enable-shared
--disable-static --enable-decimal-float --with-long-double-128 --enable-nls
--with-included-gettext --enable-gather-detailed-mem-stats --with-stabs
--enable-debug --enable-largefile --enable-symvers --without-system-zlib
--enable-gtk-cairo --enable-gconf-peer --enable-gstreamer-peer --enable-xmlj
--enable-gtk-peer --enable-qt-peer --enable-plugin --enable-tool-wrappers
--enable-local-sockets --enable-gjdoc --enable-java-awt=gtk,xlib,qt,x
--enable-gc-debug --enable-libgcj-debug --enable-objc-gc
--enable-libstdcxx-debug --disable-stage1-checking --enable-checking=release
--without-system-libunwind --with-gnu-as --with-as=/usr/local/bin/as
--with-gnu-ld --with-ld=/usr/local/bin/ld
Thread model: posix
gcc version 4.4.0 20090114 (experimental) [trunk revision 143401] (GCC) 


# ls -l /usr/local/share/python/
total 45
-rw-r--r--   1 root root   14326 Jan 11 18:05 aotcompile.py
-rw-r--r--   1 root root7400 Jan 11 18:05 classfile.py


# gmake
...
Adding multilib support to Makefile in ../../../gcc_trunk/libjava
multidirs=amd64
with_multisubdir=
Running configure in multilib subdirs amd64
pwd: /usr/share/src/gcc_build/i386-pc-solaris2.11/libjava
Running configure in multilib subdir amd64
pwd: /usr/share/src/gcc_build/i386-pc-solaris2.11
...
checking whether the target supports thread-local storage... yes
checking whether ld supports anonymous version scripts... yes
Python modules dir: NONE/share/python
updating cache ./config.cache
configure: creating ./config.status
config.status: creating Makefile
config.status: creating libgcj.pc
config.status: creating libgcj.spec
...


Notice that "gcc_trunk/libjava/configure" sets "Python modules dir: 
NONE/share/python" and my "--prefix" is "/usr/local/" (default).

This Bug occurs in lines 28052 - 28071 where "prefix" is kept at the
default initialized value of "NONE" instead of using "--prefix"'s value.

Rob


-- 
   Summary: [Regression] gcc 4.4.0 20090114 - libjava/configure sets
"NONE/share/python", need "${prefix}/share/python"
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rob1weld at aol dot com


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

[Bug fortran/38152] [4.4 Regression] procedure pointers as module variables

[burnus at gcc dot gnu dot org]

--- Comment #9 from burnus at gcc dot gnu dot org  2009-01-16 06:50 ---
> Can we still get this into 4.4? In a way the ICE is a regression, since 4.3
> just gave an error message (stating that procedure pointers are not
> implemented) but no ICE.

I think one could; the patch only affects proc pointer and thus even if it
breaks, it would not be that bad. Note: There are currently only 102 serious
regressions left (6 P1 regressions; goal < 100 P1-P3 regressions, 0 P1
regressions) thus branching will be relatively soon.


-- 


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

[Bug c++/38579] [4.2/4.3/4.4 Regression] Template: Wrong inherited copy-ctor visibility

[jason at gcc dot gnu dot org]

-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jason at gcc dot gnu dot org
   |dot org |
 Status|REOPENED|ASSIGNED
   Last reconfirmed|2008-12-21 23:10:28 |2009-01-16 06:42:05
   date||


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

[Bug c++/38579] [4.2/4.3/4.4 Regression] Template: Wrong inherited copy-ctor visibility

[jason at gcc dot gnu dot org]

--- Comment #6 from jason at gcc dot gnu dot org  2009-01-16 06:41 ---
This bug was introduced by the fix for PR 10990.


-- 


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

[Bug c++/38579] [4.2/4.3/4.4 Regression] Template: Wrong inherited copy-ctor visibility

[jason at gcc dot gnu dot org]

--- Comment #5 from jason at gcc dot gnu dot org  2009-01-16 06:17 ---
Ah yes, I see.  The bug is not with the visibility of the copy ctor, but with
the conversion from B to P in order to call it.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to fail|4.3.0 4.0.0 4.4.0   |3.4.6 4.3.0 4.0.0 4.4.0


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

[Bug c++/38850] [4.4 Regression] Cannot find inline friend function in template class when called from within a template function

[jason at gcc dot gnu dot org]

--- Comment #11 from jason at gcc dot gnu dot org  2009-01-16 06:08 ---
Fixed.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c++/38850] [4.4 Regression] Cannot find inline friend function in template class when called from within a template function

[jason at gcc dot gnu dot org]

--- Comment #10 from jason at gcc dot gnu dot org  2009-01-16 06:08 ---
Subject: Bug 38850

Author: jason
Date: Fri Jan 16 06:08:20 2009
New Revision: 143424

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143424
Log:
PR c++/38850
* pt.c (tsubst_copy_and_build): Tell finish_call_expr to
accept hidden friends.

Added:
branches/gcc-4_3-branch/gcc/testsuite/g++.dg/template/koenig6.C
  - copied unchanged from r143422,
trunk/gcc/testsuite/g++.dg/template/koenig6.C
Modified:
branches/gcc-4_3-branch/gcc/cp/ChangeLog
branches/gcc-4_3-branch/gcc/cp/pt.c
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/38850] [4.4 Regression] Cannot find inline friend function in template class when called from within a template function

[jason at gcc dot gnu dot org]

--- Comment #9 from jason at gcc dot gnu dot org  2009-01-16 06:08 ---
Subject: Bug 38850

Author: jason
Date: Fri Jan 16 06:08:09 2009
New Revision: 143423

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143423
Log:
PR c++/38850
* pt.c (tsubst_copy_and_build): Tell finish_call_expr to
accept hidden friends.

Added:
branches/gcc-4_2-branch/gcc/testsuite/g++.dg/template/koenig6.C
  - copied unchanged from r143422,
trunk/gcc/testsuite/g++.dg/template/koenig6.C
Modified:
branches/gcc-4_2-branch/gcc/cp/ChangeLog
branches/gcc-4_2-branch/gcc/cp/pt.c
branches/gcc-4_2-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug bootstrap/38866] New: [Regression] --enable-gstreamer-peer + multilib + 32 bit boot = broken build

[rob1weld at aol dot com]

I'm compiling "gcc version 4.4.0 20090114 (experimental) [trunk revision
143401]" on "i386-pc-solaris2.11" (OpenSolaris 2008.11) and ./configured 
using: --enable-gstreamer-peer


# gcc/xgcc -v
Using built-in specs.
Target: i386-pc-solaris2.11
Configured with: ../gcc_trunk/configure
--enable-languages=ada,c,c++,fortran,java,objc,obj-c++ --enable-shared
--disable-static --enable-decimal-float --with-long-double-128 --enable-nls
--with-included-gettext --enable-gather-detailed-mem-stats --with-stabs
--enable-debug --enable-largefile --enable-symvers --without-system-zlib
--enable-gtk-cairo --enable-gconf-peer --enable-gstreamer-peer --enable-xmlj
--enable-gtk-peer --enable-qt-peer --enable-plugin --enable-tool-wrappers
--enable-local-sockets --enable-gjdoc --enable-java-awt=gtk,xlib,qt,x
--enable-gc-debug --enable-libgcj-debug --enable-objc-gc
--enable-libstdcxx-debug --disable-stage1-checking --enable-checking=release
--without-system-libunwind --with-gnu-as --with-as=/usr/local/bin/as
--with-gnu-ld --with-ld=/usr/local/bin/ld
Thread model: posix
gcc version 4.4.0 20090114 (experimental) [trunk revision 143401] (GCC) 


Most OSes capable of booting 64-bit will also have 32-bit libraries available
but many ONLY have the 32-bit library, no 64-bit version compiled, and the
program's ./configure script does not use --enable-multilib .

When you are booted in 32-bit mode and want to build 64-bit libraries you
can _sometimes_ simply type 'export set CC="gcc -m64"', ./configure and then
build normally with the correct result. 

On some occasions there are many structures to be converted (and correctly
aligned) as the code was not ever intended to be compiled 64-bit on a 32-bit
machine - thus porting is harder and frequently not done.

That means the OS will only have 32-bit _binaries_ installed and to compile
the 64-bit binaries you need to resolve all the dependencies (including this
same issue re-occurring in the dependencies) and build your own.


The "Bug" reported here is:

When you can only boot into 32-bit mode (either due to your processor or
if using VirtualBox it supports 32/32 host/guest on WinXP) and want to
compile gcc 'multilib' (either to distribute gcc or your own libs/execs)
if you choose the ./configure option --enable-gstreamer-peer it only
checks if part of gstreamer is working and then gives an odd message:

/bin/sh ../../../libtool --tag=CC --mode=link
/usr/share/src/gcc_build/./gcc/xgcc -B/usr/share/src/gcc_build/./gcc/
-B/usr/local/i386-pc-solaris2.11/bin/ -B/usr/local/i386-pc-solaris2.11/lib/
-isystem /usr/local/i386-pc-solaris2.11/include -isystem
/usr/local/i386-pc-solaris2.11/sys-include  -m64 -W -Wall
-Wmissing-declarations -Wwrite-strings -Wmissing-prototypes -Wno-long-long
-Wno-write-strings -Wno-missing-field-initializers -Wno-unused-parameter
-D_REENTRANT -D_PTHREADS -I/usr/include/gstreamer-0.10 -I/usr/include/glib-2.0
-I/usr/lib/glib-2.0/include -I/usr/include/libxml2 -D_REENTRANT
-D_POSIX_PTHREAD_SEMANTICS -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include
-I/usr/include/pango-1.0 -I/usr/X11/include -I/usr/include/glib-2.0
-I/usr/lib/glib-2.0/include -I/usr/include/cairo -I/usr/include/freetype2
-I/usr/include/libpng12   -D_REENTRANT -D_PTHREADS
-I/usr/include/gstreamer-0.10 -I/usr/include/glib-2.0
-I/usr/lib/glib-2.0/include -I/usr/include/libxml2   -D_REENTRANT -D_PTHREADS
-I/usr/include/gstreamer-0.10 -I/usr/include/glib-2.0
-I/usr/lib/glib-2.0/include -I/usr/include/libxml2 -fexceptions
-fasynchronous-unwind-tables -g -O2-m64 -module -version-info 0:0:0
-no-undefined -lgstreamer-0.10 -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0
-lpthread -lthread -lxml2 -lglib-2.0   -lgstbase-0.10 -lgstreamer-0.10
-lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lpthread -lthread -lxml2 -lglib-2.0
-lgstreamer-0.10 -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lpthread -lthread
-lxml2 -lglib-2.0   -R/usr/X11/lib -L/usr/X11/lib -lgdk-x11-2.0 -lXi -lXext
-lX11 -lgdk_pixbuf-2.0 -lm -lmlib -lpangocairo-1.0 -lgio-2.0 -lfontconfig
-lXrandr -lXcursor -lXcomposite -lXdamage -lpango-1.0 -lcairo -lgobject-2.0
-lgmodule-2.0 -lglib-2.0 -lXfixes   -m64 -o libgstreamerpeer.la -rpath
/usr/local/lib/amd64/gcj-4.4.0-10 -module -version-info 0:0:0 -no-undefined
-lgstreamer-0.10 -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lpthread -lthread
-lxml2 -lglib-2.0   -lgstbase-0.10 -lgstreamer-0.10 -lgobject-2.0 -lgmodule-2.0
-lgthread-2.0 -lpthread -lthread -lxml2 -lglib-2.0 -lgstreamer-0.10
-lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lpthread -lthread -lxml2 -lglib-2.0 
 -R/usr/X11/lib -L/usr/X11/lib -lgdk-x11-2.0 -lXi -lXext -lX11 -lgdk_pixbuf-2.0
-lm -lmlib -lpangocairo-1.0 -lgio-2.0 -lfontconfig -lXrandr -lXcursor
-lXcomposite -lXdamage -lpango-1.0 -lcairo -lgobject-2.0 -lgmodule-2.0
-lglib-2.0 -lXfixes   -module -avoid-version -Wno-unused-parameter
-no-undefined -avoid-version gst_peer.lo gstreamer_io_peer.lo
gst_native_data_line.lo gst_input_stream.lo gst_native_pipeline.lo
gst_classpath_src.lo ../../../native/jni/classpat

[Bug fortran/38822] Compile-time simplification of x**(real) / ICE in in gfc_target_encode_expr

[kargl at gcc dot gnu dot org]

--- Comment #6 from kargl at gcc dot gnu dot org  2009-01-16 05:26 ---
(In reply to comment #5)
> ifort (IFORT) 10.1 20080801
> Copyright (C) 1985-2008 Intel Corporation.  All rights reserved.
> 
> $ ./a.out 
>  T F
> 
> I want to get my head around this too. :)

Note, there are 2 separate programs.  Both should
give 'T F' according to James.  He had a bug in the
first program that gives the 'correct' answer with
several compilers.  His corrected program shows that
Intel gets the wrong answer 'T T'.

The gist of his argument is that in F95 a REAL exponent
is not permitted in an initialization expression.  This 
then means that the array 'z(0*transfer(2.d0**2.)+2)'
is an automatic array.  An automatic array is not saved
with a blank SAVE statement, and so it can't retain its
values when the routine returns.

There may be some processor-dependent behavior here.  A
Fortran processor does not have to evaluate the transfer()
and its arguments because the multiplication by 0 will 
always result in zero.  See 7.1.8.1.


-- 


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

[Bug c++/38850] [4.4 Regression] Cannot find inline friend function in template class when called from within a template function

[jason at gcc dot gnu dot org]

--- Comment #8 from jason at gcc dot gnu dot org  2009-01-16 05:04 ---
Subject: Bug 38850

Author: jason
Date: Fri Jan 16 05:04:26 2009
New Revision: 143422

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143422
Log:
PR c++/38850
* pt.c (tsubst_copy_and_build): Tell finish_call_expr to
accept hidden friends.

Added:
trunk/gcc/testsuite/g++.dg/template/koenig6.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/38850] [4.4 Regression] Cannot find inline friend function in template class when called from within a template function

[jason at gcc dot gnu dot org]

--- Comment #7 from jason at gcc dot gnu dot org  2009-01-16 04:55 ---
4.2 and 4.3 handle this fine, I don't know why it was marked as a 4.2/4.3
regression.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to fail|4.2.4 4.3.2 4.4.0   |4.4.0
Summary|[4.2/4.3/4.4 Regression]|[4.4 Regression] Cannot find
   |Cannot find inline friend   |inline friend function in
   |function in template class  |template class when called
   |when called from within a   |from within a template
   |template function   |function


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

[Bug c++/34870] argument-dependent lookup wrongly finds friend declaration

[jason at gcc dot gnu dot org]

--- Comment #7 from jason at gcc dot gnu dot org  2009-01-16 04:54 ---
Actually, this is still an accepts-invalid bug when weird is uncommented.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |
Summary|argument-dependent lookup   |argument-dependent lookup
   |wronly finds friend |wrongly finds friend
   |declaration |declaration


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

[Bug c++/37775] Templated private class visible through friend declaration

[jason at gcc dot gnu dot org]

--- Comment #1 from jason at gcc dot gnu dot org  2009-01-16 03:50 ---
11.4: A name nominated by a friend declaration shall be accessible in the scope
of the class containing the friend declaration.

Confirmed.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-01-16 03:50:16
   date||


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

[Bug fortran/38822] Compile-time simplification of x**(real) / ICE in in gfc_target_encode_expr

[jvdelisle at gcc dot gnu dot org]

--- Comment #5 from jvdelisle at gcc dot gnu dot org  2009-01-16 02:57 
---
ifort (IFORT) 10.1 20080801
Copyright (C) 1985-2008 Intel Corporation.  All rights reserved.

$ ./a.out 
 T F

I want to get my head around this too. :)


-- 


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

[Bug fortran/38822] Compile-time simplification of x**(real) / ICE in in gfc_target_encode_expr

[kargl at gcc dot gnu dot org]

--- Comment #4 from kargl at gcc dot gnu dot org  2009-01-16 02:47 ---
I think I know how to fix this.  I'll note that James' clever
programs may be invoking processor defined behavior due to
the multiplication by 0 in his specification statements.
See 7.1.8.1.


-- 


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

[Bug tree-optimization/38865] missing FRE with VIEW_CONVERT_EXPR

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2009-01-16 02:33 ---
Mine. Simple patch which implements it in vn_reference_lookup, Since VCE is
both a reference and really a bit-wise cast, we can do the normal lookup and
then do a lookup if the VCE was not there.  I have not seen if this improves
any testcases yet though but I thought I remembering seeing code like this in
the benchmark we have internally.


Index: tree-ssa-sccvn.c
===
--- tree-ssa-sccvn.c(revision 143413)
+++ tree-ssa-sccvn.c(working copy)
@@ -1041,6 +1041,19 @@ vn_reference_lookup (tree op, VEC (tree,
   vr1.operands = valueize_refs (shared_reference_ops_from_ref (op));
   vr1.hashcode = vn_reference_compute_hash (&vr1);
   result = vn_reference_lookup_1 (&vr1, vnresult);
+  
+  /* If we don't get the result right away for a VIEW_CONVERT_EXPR, try again
+ with the original expression.  */
+  if (!result && TREE_CODE (op) == VIEW_CONVERT_EXPR)
+{
+  vr1.vuses = valueize_vuses (vuses);
+  vr1.operands = valueize_refs (shared_reference_ops_from_ref
(TREE_OPERAND (op, 0)));
+  vr1.hashcode = vn_reference_compute_hash (&vr1);
+  result = vn_reference_lookup_1 (&vr1, vnresult);
+  /* Convert it back to the original type */
+  if (result)
+   fold_build1 (VIEW_CONVERT_EXPR, TREE_TYPE (op), result);
+}

   /* If there is a single defining statement for all virtual uses, we can
  use that, following virtual use-def chains.  */


-- 

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 |2009-01-16 02:33:46
   date||


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

[Bug libstdc++/32666] FAIL: abi_check hppa

[bkoz at gcc dot gnu dot org]

--- Comment #14 from bkoz at gcc dot gnu dot org  2009-01-16 02:26 ---
Created an attachment (id=17112)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17112&action=view)
add in stubs.c for long double only


-- 


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

[Bug libstdc++/32666] FAIL: abi_check hppa

[bkoz at gcc dot gnu dot org]

--- Comment #13 from bkoz at gcc dot gnu dot org  2009-01-16 02:26 ---

Ouch. I see this also on arm-elf crosses, whoops.

Here's a patch that I'm currently testing on cross. If it fixes it, then I'll
check it in and then please try on hpux.


-- 

bkoz at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|FAIL: abi_check |FAIL: abi_check hppa


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

[Bug tree-optimization/38745] [4.4 Regression] ICE: statement makes a memory store, but has no VDEFS

[pinskia at gcc dot gnu dot org]

--- Comment #9 from pinskia at gcc dot gnu dot org  2009-01-16 02:11 ---
Index: tree-ssa-forwprop.c
===
--- tree-ssa-forwprop.c (revision 143415)
+++ tree-ssa-forwprop.c (working copy)
@@ -775,29 +775,43 @@ forward_propagate_addr_expr_1 (tree name
   && !TYPE_VOLATILE (TREE_TYPE (rhs))
   && !TYPE_VOLATILE (TREE_TYPE (TREE_OPERAND (def_rhs, 0)))
   && operand_equal_p (TYPE_SIZE (TREE_TYPE (rhs)),
- TYPE_SIZE (TREE_TYPE (TREE_OPERAND (def_rhs, 0))),
0)) 
+ TYPE_SIZE (TREE_TYPE (TREE_OPERAND (def_rhs, 0))), 0)
+  /* Don't create a VCE inside an ADDR_EXPR which be used on the LHS later
+ on.  */
+  && gimple_assign_rhs_code (use_stmt) != ADDR_EXPR) 


-- 


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

[Bug tree-optimization/38745] [4.4 Regression] ICE: statement makes a memory store, but has no VDEFS

[pinskia at gcc dot gnu dot org]

--- Comment #8 from pinskia at gcc dot gnu dot org  2009-01-16 02:01 ---
So the problem here is that we should not forward prop *(struct a*)&f into an
expression which is taking the address ...


-- 


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

[Bug fortran/38822] Compile-time simplification of x**(real) / ICE in in gfc_target_encode_expr

[kargl at gcc dot gnu dot org]

--- Comment #3 from kargl at gcc dot gnu dot org  2009-01-16 00:55 ---
(In reply to comment #2)
> Before closing, please also check the two longer cases:
> http://groups.google.com/group/comp.lang.fortran/msg/97c3ce6e98432ae9
> and the older (partially incorrect?) one at
> http://groups.google.com/group/comp.lang.fortran/msg/c71f697c3e21e3f2
> 

Well, both programs compile with my patch that allows
2.e0**2.e0 to compile.

troutmask:sgk[220] gfc4x -o z j2.f90
troutmask:sgk[221] ./z
 T T
troutmask:sgk[222] gfc4x -o z -std=f95 j1.f90
troutmask:sgk[223] ./z
 T T

I haven't unraveled James' argument that the correct
answer is T F.


-- 


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

[Bug fortran/38823] Diagnose and treat (-2.0)**2.0 properly

[kargl at gcc dot gnu dot org]

--- Comment #13 from kargl at gcc dot gnu dot org  2009-01-16 00:40 ---
I have a patch for this problem.  I'll clean it up on Saturday and
submit it.


-- 

kargl at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |kargl at gcc dot gnu dot org
   |dot org |


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

[Bug libstdc++/32666] FAIL: abi_check

[dave at hiauly1 dot hia dot nrc dot ca]

--- Comment #12 from dave at hiauly1 dot hia dot nrc dot ca  2009-01-16 
00:24 ---
Subject: Re:  FAIL: abi_check

> --- Comment #9 from bkoz at gcc dot gnu dot org  2009-01-13 10:02 ---
> Created an attachment (id=17084)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17084&action=view)
>  --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17084&action=view)
> shiny

I applied to above on hppa2.0w-hp-hpux11.11.  With respect to the
previous build, there are a number of new fails:

Executing on host: /test/gnu/gcc/objdir/./gcc/g++ -shared-libgcc
-B/test/gnu/gcc
/objdir/./gcc -nostdinc++
-L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++
-v3/src -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/src/.libs
-B/o
pt/gnu/gcc/gcc-4.4.0/hppa2.0w-hp-hpux11.11/bin/
-B/opt/gnu/gcc/gcc-4.4.0/hppa2.0
w-hp-hpux11.11/lib/ -isystem
/opt/gnu/gcc/gcc-4.4.0/hppa2.0w-hp-hpux11.11/includ
e -isystem /opt/gnu/gcc/gcc-4.4.0/hppa2.0w-hp-hpux11.11/sys-include -g -O2
-D_GL
IBCXX_ASSERT -fmessage-length=0 -g -O2 -g -O2   -DLOCALEDIR="." -nostdinc++
-I/t
est/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/hppa2.0w-hp-hpux11
.11 -I/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include
-I/test/gn
u/gcc/gcc/libstdc++-v3/libsupc++
-I/test/gnu/gcc/gcc/libstdc++-v3/include/backwa
rd -I/test/gnu/gcc/gcc/libstdc++-v3/testsuite/util
/test/gnu/gcc/gcc/libstdc++-v
3/testsuite/26_numerics/complex/13450.cc-include bits/stdc++.h
./libtestc++.
a  -lm   -o ./13450.exe(timeout = 600)
/usr/ccs/bin/ld: Unsatisfied symbols:
   logl (first referenced in /var/tmp//ccQdgBMy.o) (code)
   sinl (first referenced in /var/tmp//ccQdgBMy.o) (code)
   expl (first referenced in /var/tmp//ccQdgBMy.o) (code)
   powl (first referenced in /var/tmp//ccQdgBMy.o) (code)
   atan2l (first referenced in /var/tmp//ccQdgBMy.o) (code)
   sqrtl (first referenced in /var/tmp//ccQdgBMy.o) (code)
   cosl (first referenced in /var/tmp//ccQdgBMy.o) (code)
   collect2: ld returned 1 exit status

Dave


-- 


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

[Bug tree-optimization/38844] [4.3/4.4 Regression] deadlock with __attribute__((always_inline)) at -O1 and above

[hjl dot tools at gmail dot com]

--- Comment #7 from hjl dot tools at gmail dot com  2009-01-15 23:57 ---
Revision 121570 is:

http://gcc.gnu.org/ml/gcc-patches/2007-02/msg00319.html


-- 


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

[Bug tree-optimization/31496] FAIL: gcc.dg/builtins-20.c (test for excess errors)

[sje at cup dot hp dot com]

--- Comment #8 from sje at cup dot hp dot com  2009-01-15 23:45 ---
Fixed with change to test.


-- 

sje at cup dot hp dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug tree-optimization/31496] FAIL: gcc.dg/builtins-20.c (test for excess errors)

[dave at hiauly1 dot hia dot nrc dot ca]

--- Comment #7 from dave at hiauly1 dot hia dot nrc dot ca  2009-01-15 
23:40 ---
Subject: Re:  FAIL: gcc.dg/builtins-20.c (test for excess errors)

> I think we can close it.  Any objections?

No.

Dave


-- 


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

[Bug tree-optimization/38865] missing FRE with VIEW_CONVERT_EXPR

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2009-01-15 23:40 ---
Note with the disabling of VCE creation for *(float*)&sv->i after this bug has
been fixed, there is a possibility that -O2 -fno-strict-aliasing could get
slightly better code than -O2 :).


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |enhancement


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

[Bug tree-optimization/38865] New: missing FRE with VIEW_CONVERT_EXPR

[pinskia at gcc dot gnu dot org]

Take:
struct s { int i; };
float a (struct s *sv)
{
  sv->i = 0;
  int d = sv->i;
  return *(float*)&d;
}


float a1 (struct s *sv)
{
  sv->i = 0;
  return *(float*)&sv->i;
}

We miss that we could constant prop 0 into the VIEW_CONVERT_EXPR.
Likewise for non aliasing issues but with vectors:
#define vector __attribute__((vector_size(16) ))
struct s { vector int i; };
vector float a (struct s *sv)
{
  sv->i = (vector int){0,0,0};
  vector int d = sv->i;
  return (vector float)(d);
}


vector float a1 (struct s *sv)
{
  sv->i = (vector int){0,0,0};
  return (vector float)sv->i;
}


-- 
   Summary: missing FRE with VIEW_CONVERT_EXPR
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  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=38865

[Bug tree-optimization/38748] [4.4 Regression] Missed FRE because of VIEW_CONVERT_EXPR

[pinskia at gcc dot gnu dot org]

--- Comment #7 from pinskia at gcc dot gnu dot org  2009-01-15 23:30 ---
PR 38747 has the best patch which allows most optimizations still but only
disabling it for the invalid cases when the aliasing sets are not equal.
Take:
struct S { unsigned f; };
int __attribute__((noinline))
foo ( struct S *p)
{
  int *q = (int *)&p->f;
  int i = *q;
  return i + p->f;
}

We should be able to optimize this to just "tmp = p->f; return (int)(tmp +
tmp);" which we do with my patch unlike the one in comment #2 which disables
too many optimizations.


-- 


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

[Bug tree-optimization/38747] [4.4 Regression] Wrong code due to VIEW_CONVERT_EXPR

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2009-01-15 23:26 ---
Created an attachment (id=17111)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17111&action=view)
Patch which should fix this and PR 38748

This patch still creates VCE for INDIRECT_REF based but only if the aliasing
sets are the same.  
This is to allow for the following to be optimized:
struct S { unsigned f; };
int __attribute__((noinline))
foo (float *r, struct S *p)
{
  int *q = (int *)&p->f;
  int i = *q;
  *r = 0.0;
  return i + *q;
}

Without a need for &p->f in the IR.


-- 


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

[Bug middle-end/24827] FAIL: gcc.dg/attr-weakref-1.c

[sje at cup dot hp dot com]

--- Comment #13 from sje at cup dot hp dot com  2009-01-15 23:23 ---
It looks like the test was changed to fix this failure.  Marking as fixed.


-- 

sje at cup dot hp dot com changed:

   What|Removed |Added

 CC||sje at cup dot hp dot com
 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug tree-optimization/38748] [4.4 Regression] Missed FRE because of VIEW_CONVERT_EXPR

[pinskia at gcc dot gnu dot org]

--- Comment #6 from pinskia at gcc dot gnu dot org  2009-01-15 23:16 ---
The CSE of the load is only valid at -O2 and above (strict aliasing turned on).


-- 


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

[Bug c++/38850] [4.2/4.3/4.4 Regression] Cannot find inline friend function in template class when called from within a template function

[jason at gcc dot gnu dot org]

-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jason at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2009-01-14 21:46:06 |2009-01-15 23:13:59
   date||


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

[Bug c++/34870] argument-dependent lookup wronly finds friend declaration

[jason at gcc dot gnu dot org]

--- Comment #6 from jason at gcc dot gnu dot org  2009-01-15 23:12 ---
3.4.2 begins "When an unqualified name is used as the postfix-expression in a
function call"  The call func(x) does not get argument-dependent
lookup because func is not an unqualified name, it's a template-id.  The
testcase should be rejected with or without the declaration of weird.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID


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

[Bug target/32894] Segmentation fault bootstrapping on HP-UX 11.11

[sje at cup dot hp dot com]

--- Comment #7 from sje at cup dot hp dot com  2009-01-15 23:09 ---
I think this should be closed as WONTFIX.  There may or may not be a 3.3.6 GCC
bug that was causing a bootstrap failure but it isn't going to be fixed so we
may as well close this defect.  If anyone objects they can reopen it.


-- 

sje at cup dot hp dot com changed:

   What|Removed |Added

 CC||sje at cup dot hp dot com
 Status|UNCONFIRMED |RESOLVED
 Resolution||WONTFIX


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

[Bug c++/37804] friend declaration leaks into global scope at template instantiation

[jason at gcc dot gnu dot org]

--- Comment #5 from jason at gcc dot gnu dot org  2009-01-15 23:07 ---
7.3.1.2: If a friend declaration in a non-local class first declares a class or
function the friend class or function is a member of the innermost enclosing
namespace. The name of the friend is not found by unqualified lookup (3.4.1) or
by qualified lookup (3.4.3) until a matching declaration is provided in that
namespace scope (either before or after the class definition granting
friendship).


-- 


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

[Bug middle-end/29478] [4.2 Regression] optimization generates warning for casts

[sje at cup dot hp dot com]

--- Comment #32 from sje at cup dot hp dot com  2009-01-15 23:03 ---
*** Bug 30183 has been marked as a duplicate of this bug. ***


-- 

sje at cup dot hp dot com changed:

   What|Removed |Added

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


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

[Bug c/30183] FAIL: gcc.dg/noncompile/pr16876.c -O0 (test for errors, line 10)

[sje at cup dot hp dot com]

--- Comment #3 from sje at cup dot hp dot com  2009-01-15 23:03 ---
I agree that this is a duplicate of pr29478 so I am going to close it as such.

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


-- 

sje at cup dot hp dot com changed:

   What|Removed |Added

 CC||sje at cup dot hp dot com
 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug libgcj/38861] gcjwebplugin.cc doesn't compile against latest xulrunner 1.9.1 sdk

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2009-01-15 22:58 ---
That's not enough, as the typedef names also changed :(.
So, for npupp.h:
NewNPP_XXXProc (YYY)
or
(NPP_XXXUPP) (YYY)
works, for npfunctions.h:
(NPP_XXXProcPtr) (YYY)

And, jref isn't typedefed for new xulrunner (but the question stands, why is
that function defined at all when nothing references it).


-- 


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

[Bug tree-optimization/31496] FAIL: gcc.dg/builtins-20.c (test for excess errors)

[sje at cup dot hp dot com]

--- Comment #6 from sje at cup dot hp dot com  2009-01-15 22:58 ---
It looks like this test is passing since the test was changed to include
the #ifdef HAVE_C99_RUNTIME.  It looks OK on the 4.3 branch and trunk so
I think we can close it.  Any objections?


-- 

sje at cup dot hp dot com changed:

   What|Removed |Added

 CC||sje at cup dot hp dot com


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

[Bug c++/37646] [4.2 regression] ICE with function vs. member function

[jason at gcc dot gnu dot org]

--- Comment #4 from jason at gcc dot gnu dot org  2009-01-15 22:57 ---
Fixed for 4.3 and 4.4, not fixing for 4.2.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
Summary|[4.2/4.3 regression] ICE|[4.2 regression] ICE with
   |with function vs. member|function vs. member function
   |function|


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

[Bug c++/36334] [4.2 Regression] typedef to function type leads to problems

[jason at gcc dot gnu dot org]

--- Comment #6 from jason at gcc dot gnu dot org  2009-01-15 22:56 ---
Fixed for 4.3 and 4.4.  Not fixing for 4.2.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work|4.1.3 4.4.0 |4.1.3 4.3.3 4.4.0
 Resolution||FIXED
Summary|[4.2/4.3 Regression] typedef|[4.2 Regression] typedef to
   |to function type leads to   |function type leads to
   |problems|problems


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

[Bug fortran/38152] ICE for procedure pointer assignment

[janus at gcc dot gnu dot org]

--- Comment #8 from janus at gcc dot gnu dot org  2009-01-15 22:56 ---
Created an attachment (id=17110)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17110&action=view)
patch

Here is a patch which fixes the testcases in comment #0, #1 and #7.

Dominique: Maybe you could check whether the problems from comment #4 and #5
still persist.

Can we still get this into 4.4? In a way the ICE is a regression, since 4.3
just gave an error message (stating that procedure pointers are not
implemented) but no ICE.


-- 

janus at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug c++/31488] [4.3/4.4 Regression] va_list considered non-POD

[jason at gcc dot gnu dot org]

--- Comment #15 from jason at gcc dot gnu dot org  2009-01-15 22:54 ---
Fixed.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug tree-optimization/38844] [4.3/4.4 Regression] deadlock with __attribute__((always_inline)) at -O1 and above

[hjl dot tools at gmail dot com]

--- Comment #6 from hjl dot tools at gmail dot com  2009-01-15 22:38 ---
This patch:

--- ./ipa-inline.c.foo  2009-01-02 11:06:18.0 -0800
+++ ./ipa-inline.c  2009-01-15 14:35:28.0 -0800
@@ -1412,7 +1412,8 @@ cgraph_decide_inlining_incrementally (st
}
  continue;
}
-  inlined |= try_inline (e, mode, depth);
+  if (e->inline_failed)
+   inlined |= try_inline (e, mode, depth);
 }

   /* Now do the automatic inlining.  */

works for me. But I don't know if it is correct.


-- 


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

[Bug c++/31488] [4.3/4.4 Regression] va_list considered non-POD

[jason at gcc dot gnu dot org]

--- Comment #14 from jason at gcc dot gnu dot org  2009-01-15 22:34 ---
Subject: Bug 31488

Author: jason
Date: Thu Jan 15 22:34:20 2009
New Revision: 143413

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143413
Log:
PR c++/36334
PR c++/37646
* tree.c (lvalue_p_1): Handle BASELINK.  A COMPONENT_REF to
a function isn't necessarily an lvalue. Take tree, not const_tree.
(lvalue_p, real_lvalue_p): Take tree, not const_tree.
* typeck.c (lvalue_or_else): Likewise.
* cp-tree.h: Adjust prototypes.

PR c++/31488
* tree.c (pod_type_p): Return 1 for structs created by the back end.

Added:
branches/gcc-4_3-branch/gcc/testsuite/g++.dg/conversion/memfn1.C
  - copied unchanged from r143404,
trunk/gcc/testsuite/g++.dg/conversion/memfn1.C
branches/gcc-4_3-branch/gcc/testsuite/g++.dg/conversion/memfn2.C
  - copied unchanged from r143404,
trunk/gcc/testsuite/g++.dg/conversion/memfn2.C
branches/gcc-4_3-branch/gcc/testsuite/g++.dg/other/vararg-3.C
  - copied unchanged from r143308,
trunk/gcc/testsuite/g++.dg/other/vararg-3.C
Modified:
branches/gcc-4_3-branch/gcc/cp/ChangeLog
branches/gcc-4_3-branch/gcc/cp/cp-tree.h
branches/gcc-4_3-branch/gcc/cp/tree.c
branches/gcc-4_3-branch/gcc/cp/typeck.c
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/36334] [4.2/4.3 Regression] typedef to function type leads to problems

[jason at gcc dot gnu dot org]

--- Comment #5 from jason at gcc dot gnu dot org  2009-01-15 22:34 ---
Subject: Bug 36334

Author: jason
Date: Thu Jan 15 22:34:20 2009
New Revision: 143413

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143413
Log:
PR c++/36334
PR c++/37646
* tree.c (lvalue_p_1): Handle BASELINK.  A COMPONENT_REF to
a function isn't necessarily an lvalue. Take tree, not const_tree.
(lvalue_p, real_lvalue_p): Take tree, not const_tree.
* typeck.c (lvalue_or_else): Likewise.
* cp-tree.h: Adjust prototypes.

PR c++/31488
* tree.c (pod_type_p): Return 1 for structs created by the back end.

Added:
branches/gcc-4_3-branch/gcc/testsuite/g++.dg/conversion/memfn1.C
  - copied unchanged from r143404,
trunk/gcc/testsuite/g++.dg/conversion/memfn1.C
branches/gcc-4_3-branch/gcc/testsuite/g++.dg/conversion/memfn2.C
  - copied unchanged from r143404,
trunk/gcc/testsuite/g++.dg/conversion/memfn2.C
branches/gcc-4_3-branch/gcc/testsuite/g++.dg/other/vararg-3.C
  - copied unchanged from r143308,
trunk/gcc/testsuite/g++.dg/other/vararg-3.C
Modified:
branches/gcc-4_3-branch/gcc/cp/ChangeLog
branches/gcc-4_3-branch/gcc/cp/cp-tree.h
branches/gcc-4_3-branch/gcc/cp/tree.c
branches/gcc-4_3-branch/gcc/cp/typeck.c
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/37646] [4.2/4.3 regression] ICE with function vs. member function

[jason at gcc dot gnu dot org]

--- Comment #3 from jason at gcc dot gnu dot org  2009-01-15 22:34 ---
Subject: Bug 37646

Author: jason
Date: Thu Jan 15 22:34:20 2009
New Revision: 143413

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143413
Log:
PR c++/36334
PR c++/37646
* tree.c (lvalue_p_1): Handle BASELINK.  A COMPONENT_REF to
a function isn't necessarily an lvalue. Take tree, not const_tree.
(lvalue_p, real_lvalue_p): Take tree, not const_tree.
* typeck.c (lvalue_or_else): Likewise.
* cp-tree.h: Adjust prototypes.

PR c++/31488
* tree.c (pod_type_p): Return 1 for structs created by the back end.

Added:
branches/gcc-4_3-branch/gcc/testsuite/g++.dg/conversion/memfn1.C
  - copied unchanged from r143404,
trunk/gcc/testsuite/g++.dg/conversion/memfn1.C
branches/gcc-4_3-branch/gcc/testsuite/g++.dg/conversion/memfn2.C
  - copied unchanged from r143404,
trunk/gcc/testsuite/g++.dg/conversion/memfn2.C
branches/gcc-4_3-branch/gcc/testsuite/g++.dg/other/vararg-3.C
  - copied unchanged from r143308,
trunk/gcc/testsuite/g++.dg/other/vararg-3.C
Modified:
branches/gcc-4_3-branch/gcc/cp/ChangeLog
branches/gcc-4_3-branch/gcc/cp/cp-tree.h
branches/gcc-4_3-branch/gcc/cp/tree.c
branches/gcc-4_3-branch/gcc/cp/typeck.c
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug libgcj/38804] libgcj multilib fails if not able to exec "non" native programs

[pinskia at gcc dot gnu dot org]

--- Comment #10 from pinskia at gcc dot gnu dot org  2009-01-15 22:16 
---
>Broken : gcc_build/i386-pc-solaris2.11/libgomp/config.log :

No, it is not broken at all.  __sync_val_compare_and_swap_4 cannot be used with
x86 explicit -march=i686 is used as the default really is to compile for i486
really.  


-- 


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

[Bug gcov-profile/30397] FAIL: gcc.misc-tests/gcov-2.c ICE

[sje at cup dot hp dot com]

--- Comment #4 from sje at cup dot hp dot com  2009-01-15 22:16 ---
Bug was fixed before 4.3.0 was released.  Closing as fixed.


-- 

sje at cup dot hp dot com changed:

   What|Removed |Added

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


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

[Bug gcov-profile/30397] FAIL: gcc.misc-tests/gcov-2.c ICE

[dave at hiauly1 dot hia dot nrc dot ca]

--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca  2009-01-15 
22:14 ---
Subject: Re:  FAIL: gcc.misc-tests/gcov-2.c ICE

> --- Comment #2 from sje at cup dot hp dot com  2009-01-15 22:09 ---
> David, can we close this out?  I don't see the failure with 4.3.0 or on ToT.

Yes.

Thanks,
Dave


-- 


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

[Bug c++/29388] [4.2/4.3 regression] ICE with invalid nested name specifier

[pinskia at gcc dot gnu dot org]

--- Comment #11 from pinskia at gcc dot gnu dot org  2009-01-15 22:11 
---
Fixed on the trunk.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to work|3.4.6   |3.4.6 4.4.0
Summary|[4.2/4.3/4.4 regression] ICE|[4.2/4.3 regression] ICE
   |with invalid nested name|with invalid nested name
   |specifier   |specifier


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

[Bug driver/38864] New: Incorrect interaction between --with-arch=native and -mARCH

[daney at gcc dot gnu dot org]

LAST_UPDATED: Fri Jan  9 01:21:29 UTC 2009 (revision 143198)

$ ../trunk/configure --with-arch=native --disable-java-awt --without-x
--enable-__cxa_atexit --disable-libgomp --disable-static
--enable-languages=c,c++,java --disable-fixed-point --enable-checking=release
--with-gmp=/home/daney/mp --with-mpfr=/home/daney/mp --disable-libmudflap
--disable-multilib

As noted in these test results:

http://gcc.gnu.org/ml/gcc-testresults/2009-01/msg01307.html

We have FAIL: gcc.target/mips/dpaq_sa_l_w.c (test for excess errors)

Here is the log of the failure:
Executing on host: /home/daney/gccsvn/trunk-build/gcc/xgcc
-B/home/daney/gccsvn/trunk-build/gcc/ /home/daney/gccsvn/trunk/gcc/testsuite/\
gcc.target/mips/dpaq_sa_l_w.c   -DNOMIPS16=__attribute__((nomips16)) -mabi=32
-mips32r2 -mgp32 -O2 -mdsp -S  -o dpaq_sa_l_w.s(timeou\
t = 300)
/home/daney/gccsvn/trunk/gcc/testsuite/gcc.target/mips/dpaq_sa_l_w.c:5: error:
fixed-point types not supported for this target
/home/daney/gccsvn/trunk/gcc/testsuite/gcc.target/mips/dpaq_sa_l_w.c:6: error:
fixed-point types not supported for this target
.
.
.

The native CPU is an R5000

My untested hypothesis is that configuring with --with-arch=native has
incorrect interaction with -m* from the gcc command line.


-- 
   Summary: Incorrect interaction between --with-arch=native and -
mARCH
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: daney at gcc dot gnu dot org
 GCC build triplet: mips64-unknown-linux-gnu
  GCC host triplet: mips64-unknown-linux-gnu
GCC target triplet: mips64-unknown-linux-gnu


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

[Bug c++/29388] [4.2/4.3/4.4 regression] ICE with invalid nested name specifier

[pinskia at gcc dot gnu dot org]

--- Comment #10 from pinskia at gcc dot gnu dot org  2009-01-15 22:10 
---
Subject: Bug 29388

Author: pinskia
Date: Thu Jan 15 22:10:24 2009
New Revision: 143411

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

2009-01-15  Andrew Pinski  

PR C++/29388
* decl.c (grokdeclarator): Check for a non namespace/class context.


2009-01-15  Andrew Pinski  

PR C++/29388
* g++.dg/template/error37.C: New testcase.



Added:
trunk/gcc/testsuite/g++.dg/template/error37.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug gcov-profile/30397] FAIL: gcc.misc-tests/gcov-2.c ICE

[sje at cup dot hp dot com]

--- Comment #2 from sje at cup dot hp dot com  2009-01-15 22:09 ---
David, can we close this out?  I don't see the failure with 4.3.0 or on ToT.

I am guessing this was fixed with the following change to pa.c:



r123733 | danglin | 2007-04-11 17:46:13 -0700 (Wed, 11 Apr 2007) | 4 lines

* pa.c (pa_som_asm_init_sections): Ensure that cfun->machine is not
null before emitting a .nsubspa directive.


-- 

sje at cup dot hp dot com changed:

   What|Removed |Added

 CC||sje at cup dot hp dot com


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

[Bug libgcj/38804] libgcj multilib fails if not able to exec "non" native programs

[rob1weld at aol dot com]

--- Comment #9 from rob1weld at aol dot com  2009-01-15 22:03 ---
(In reply to comment #4)
> Hmm, automake should have done the correct thing ...

(In reply to comment #5)
> # Even if the default multilib is not a cross compilation,
> # it may be that some of the other multilibs are.
> if test $cross_compiling = no && test $multilib = yes \
>&& test "x${with_multisubdir}" != x ; then
>cross_compiling=maybe
> fi

Along the same lineage of problems (do you want a new report) we have
trouble checking for features in libgomp (and probably elsewhere). The 
logic is actually 'backward'; 64 bit is available and 32 bit is not
available (on a 32 bit boot):


OK : gcc_build/i386-pc-solaris2.11/amd64/libgomp/config.log :

configure:18855: checking whether the target supports __sync_*_compare_and_swap
configure:18877: /usr/share/src/gcc_build/./gcc/xgcc
-B/usr/share/src/gcc_build/./gcc/ -B/usr/local/i386-pc-solaris2.11/bin/
-B/usr/local/i386-pc-solaris2.11/lib/ -isystem
/usr/local/i386-pc-solaris2.11/include -isystem
/usr/local/i386-pc-solaris2.11/sys-include  -m64 -o conftest -g -O2   -pthread
-pthread  -Wall -Werror   conftest.c  >&5
configure:18883: $? = 0
configure:18887: test -z 
 || test ! -s conftest.err
configure:18890: $? = 0
configure:18893: test -s conftest
configure:18896: $? = 0
configure:18908: result: yes


Broken : gcc_build/i386-pc-solaris2.11/libgomp/config.log :

configure:18855: checking whether the target supports __sync_*_compare_and_swap
configure:18877: /usr/share/src/gcc_build/./gcc/xgcc
-B/usr/share/src/gcc_build/./gcc/ -B/usr/local/i386-pc-solaris2.11/bin/
-B/usr/local/i386-pc-solaris2.11/lib/ -isystem
/usr/local/i386-pc-solaris2.11/include -isystem
/usr/local/i386-pc-solaris2.11/sys-include -o conftest -g -O2   -pthread  -Wall
-Werror   conftest.c  >&5
/var/tmp//cc80a43R.o: In function `main':
/usr/share/src/gcc_build/i386-pc-solaris2.11/libgomp/conftest.c:43: undefined
reference to `__sync_val_compare_and_swap_4'
collect2: ld returned 1 exit status
configure:18883: $? = 1
configure: failed program was:
| /* confdefs.h.  */
| 
| #define PACKAGE_NAME "GNU OpenMP Runtime Library"
| #define PACKAGE_TARNAME "libgomp"
| #define PACKAGE_VERSION "1.0"
| #define PACKAGE_STRING "GNU OpenMP Runtime Library 1.0"
...
| #define LIBGOMP_GNU_SYMBOL_VERSIONING 1
| /* end confdefs.h.  */
| 
| int
| main ()
| {
| int foo, bar; bar = __sync_val_compare_and_swap(&foo, 0, 1);
|   ;
|   return 0;
| }
configure:18908: result: no


So ./configure will set us to use compare_and_swap() in 64 bit mode 
(when I or someone else boot to that mode) but in 32 bit mode (which I 
am currently in) the compare_and_swap() is not available - hmmm ... 
I'll bet configure never _tested_ that the 64 bit code links. hehe

Rob


-- 


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

[Bug target/38781] PR38151: valgrind finds problem

[dcb314 at hotmail dot com]

--- Comment #4 from dcb314 at hotmail dot com  2009-01-15 21:51 ---
(In reply to comment #3)
> An updated patch is at
> 
> http://gcc.gnu.org/ml/gcc-patches/2009-01/msg00747.html

I have a couple of minor questions about the coding style
of this patch.

1. Why is the "/ 8 / 8" a good idea ? 

Presumably "/ 64" doesn't do it right ?

2. On the middle condition of the for-loop, could it
be micro-optimised to compute the upper limit of the
for loop before the loop starts ?

For example, instead of

; (i < A) && (i + pos) < B; ++i

replace with 

const int limit = min( A, B - pos);

...

; i < limit; ++i


Just an idea.


-- 

dcb314 at hotmail dot com changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com


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

[Bug fortran/38863] New: WHERE with multiple elemental defined assignments gives wrong answer

[dick dot hendrickson at gmail dot com]

The following program gives the wrong answers from the WHERE block.  The
expected answers are in the tda2l array.  The problem seems to be an
interaction between the dimension statements, the defined logical assignment
and the defined integer assignment statement in the WHERE block.  

The defined assignment to the logical component of TLA2L is correct (it's
effectively a do nothing assignment, since the left and right hand sides are
the same elements).  The defined assignment to the integer component is wrong. 
Changing the dimension of TDA2L from (3,2) to (nf3,nf2) gives a different
incorrect answer.  (TDA2L is not used in any of the computations, it's just a
handy way to keep track of the expected answer).  Changing the dimension of
TLA2L from (nf3,nf2) to (3,2) fixes the problem.  Commenting out the assignment
to TLA2L%L in the WHERE gives the correct answer.

Dick Hendrickson


  module rg0045_stuff

! fails on Windows XP
! gcc version 4.4.0 20081219 (experimental) [trunk revision 142842] (GCC)


  TYPE UNSEQ

INTEGER   ::  I
LOGICAL   ::  L

  END TYPE UNSEQ   

  INTERFACE ASSIGNMENT(=)
MODULE PROCEDURE L_TO_T,   I_TO_T
  END INTERFACE ASSIGNMENT(=)

  contains

PURE ELEMENTAL SUBROUTINE Z_TO_T(OUT,ZIN)
COMPLEX,INTENT(IN)  ::  ZIN
INTEGER,INTENT(IN)  ::  IIN
LOGICAL,INTENT(IN)  ::  LIN
TYPE (UNSEQ), INTENT(INOUT) ::  OUT

OUT%i = -99
RETURN

ENTRY I_TO_T(OUT,IIN)
OUT%I = IIN
RETURN

ENTRY L_TO_T(OUT,LIN)
OUT%L = LIN
RETURN

END SUBROUTINE


  SUBROUTINE RG0045(nf1,nf2,nf3)

  TYPE(UNSEQ) TLA2L(nf3,nf2)   !changing dimension to (3,2) fixes problem
  TYPE(UNSEQ) TDA2L(3,2)   !changing dimension to (nf3,nf2) changes
output
  logical  lda(nf3,nf2)

!expected results
  tda2l(1:3,1)%l = (/.true.,.false.,.true./)
  tda2l(1:3,2)%l = (/.false.,.true.,.false./)
  tda2l(1:3,1)%i = (/1,-1,3/)
  tda2l(1:3,2)%i = (/-1,5,-1/)


  lda = tda2l%l

  tLa2l%l = lda
  tLa2l(1:3,1)%i = (/1,2,3/)
  tLa2l(1:3,2)%i = (/4,5,6/)


  WHERE(LDA)
TLA2L = TLA2L(1:3,1:2)%L !removing this line fixes problem
TLA2L = TLA2L(1:3,1:2)%I
  ELSEWHERE
TLA2L = -1
  ENDWHERE

  print *, tla2l%i
  print *, tda2l%i

  print *, tla2l%l
  print *, tda2l%l

  END SUBROUTINE
  end module rg0045_stuff

  program try_rg0045
  use rg0045_stuff

  call rg0045(1,2,3)

  end

from the above program
C:gfortran>gfortran try_rg0045.f
C:\gfortran>a
   3  -18192  -1   0  -1
   1  -1   3  -1   5  -1
 T F T F T F
 T F T F T F

with the tda2l array dimensioned (nf3,nf2)
C:gfortran>gfortran try_rg0045.f

C:\gfortran>a
   0  -1 4063608  -1  -1  -1
   1  -1   3  -1   5  -1
 T F T F T F
 T F T F T F

With the logical assignment commented out
C:gfortran>gfortran try_rg0045.f

C:\gfortran>a
   1  -1   3  -1   5  -1
   1  -1   3  -1   5  -1
 T F T F T F
 T F T F T F


with constant (3,2) array dimensions and the logical assignment left in
C:\gfortran>gfortran try_rg0045.f

C:\gfortran>a
   1  -1   3  -1   5  -1
   1  -1   3  -1   5  -1
 T F T F T F
 T F T F T F


-- 
   Summary: WHERE with multiple elemental defined assignments gives
wrong answer
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dick dot hendrickson at gmail dot com


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

[Bug tree-optimization/38844] [4.3/4.4 Regression] deadlock with __attribute__((always_inline)) at -O1 and above

[hjl dot tools at gmail dot com]

--- Comment #5 from hjl dot tools at gmail dot com  2009-01-15 21:35 ---
It is caused by revision 121570:

http://gcc.gnu.org/ml/gcc-cvs/2007-02/msg00126.html


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 CC||hjl dot tools at gmail dot
   ||com


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

[Bug fortran/38859] [4.3/4.4 Regression] ubound and lbound treat structure component references as whole arrays

[mikael at gcc dot gnu dot org]

--- Comment #3 from mikael at gcc dot gnu dot org  2009-01-15 21:30 ---
quick fix:

Index: simplify.c
===
--- simplify.c  (révision 143354)
+++ simplify.c  (copie de travail)
@@ -2253,7 +2253,8 @@ simplify_bound (gfc_expr *array, gfc_expr *dim, gf
case AR_FULL:
  /* We're done because 'as' has already been set in the
 previous iteration.  */
- goto done;
+ if (!ref->next)
+   goto done;

case AR_SECTION:
case AR_UNKNOWN:


-- 


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

[Bug bootstrap/38862] Bootstrap failure on HEAD with static linking vs. graphite

[dave dot korn dot cygwin at gmail dot com]

--- Comment #1 from dave dot korn dot cygwin at gmail dot com  2009-01-15 
21:18 ---
Created an attachment (id=17109)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17109&action=view)
Order BACKENDLIBS by dependencies.

I'd consider this fix obvious.  Verified that it resolves the link issues.


-- 


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

[Bug middle-end/38856] loop iv detection failure

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2009-01-15 21:17 ---
Here is a good testcase:
void
VecADD(
int *In1,
int *In2,
int *Out,
unsigned int samples
){
  int i;
  for (i = 0; i < samples; i++) {
Out[i] = In1[i];
  }
}

This testcase should be vectorized with -maltivec -O3 on PowerPC but is not
while it is with -m64.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-01-15 21:17:17
   date||


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

[Bug bootstrap/38862] New: Bootstrap failure on HEAD with static linking vs. graphite

[dave dot korn dot cygwin at gmail dot com]

[ ref: http://gcc.gnu.org/ml/gcc/2009-01/threads.html#00179, full details of
configuration etc. ]

  In gcc/Makefile.in, the current definition of BACKENDLIBS says:

BACKENDLIBS = $(GMPLIBS) $(CLOOGLIBS) $(PPLLIBS)

This is incorrect WRT dependency order.  Cloog and PPL depend on GMP/MPFR, and
so should be listed before it.  This doesn't cause a problem for shared
linking, as it just leaves undefined references to be resolved at runtime, but
it is fatal for static linking, causing many fatal errors:

--
ranlib  libbackend.a
gcc-4  -g -fkeep-inline-functions -DIN_GCC   -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition
-Wc++-compat -Wmissing-format-attribute -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H  -o
cc1-dummy.exe c-lang.o stub-objc.o attribs.o c-errors.o c-lex.o c-pragma.o
c-decl.o c-typeck.o c-convert.o c-aux-info.o c-common.o c-opts.o c-format.o
c-semantics.o c-ppoutput.o c-cppbuiltin.o c-objc-common.o c-dump.o c-pch.o
c-parser.o i386-c.o cygwin2.o msformat-c.o c-gimplify.o tree-mudflap.o
c-pretty-print.o c-omp.o dummy-checksum.o \
  main.o tree-browser.o libbackend.a ../libcpp/libcpp.a
../libdecnumber/libdecnumber.a ../libcpp/libcpp.a -lintl -liconv
../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -L/usr/lib -L/usr/lib
-lmpfr -lgmp -L/opt/gcc-tools/lib -lcloog -L/opt/gcc-tools/lib -lppl_c -lppl
-lgmpxx
/opt/gcc-tools/lib/libcloog.a(domain.o): In function `debug_value':
/gnu/gcc/prereq/cloog/source/ppl/domain.c:3579: multiple definition of
`_debug_value'
libbackend.a(graphite.o):/gnu/gcc/gcc/gcc/graphite.c:68: first defined here
/opt/gcc-tools/lib/libcloog.a(clast.o): In function `insert_modulo_guard':
/gnu/gcc/prereq/cloog/source/ppl/clast.c:1043: undefined reference to
`__impgmpz_fdiv_r'
/gnu/gcc/prereq/cloog/source/ppl/clast.c:1107: undefined reference to
`__impgmpz_fdiv_r'
/opt/gcc-tools/lib/libcloog.a(domain.o):domain.c:(.text+0x6d0c): undefined
reference to `__impgmpz_fdiv_r'
/opt/gcc-tools/lib/libcloog.a(matrix.o): In function `cloog_matrix_read':
/gnu/gcc/prereq/cloog/source/ppl/matrix.c:267: undefined reference to
`__impgmpz_set_str'
--

and many many more.  This can be fixed by a trivial patch which I will post as
an attachment.

  cheers,
DaveK


-- 
   Summary: Bootstrap failure on HEAD with static linking vs.
graphite
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dave dot korn dot cygwin at gmail dot com
 GCC build triplet: i686-pc-cygwin
  GCC host triplet: i686-pc-cygwin
GCC target triplet: i686-pc-cygwin


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

[Bug middle-end/38856] loop iv detection failure

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2009-01-15 21:13 ---
This bug is a bit funny, autoincrement is not the issue, just the detecting of
the induction variable's limits correctly.  For an example I noticed that if I
compile this on a LP64 target, the induction variable is found correctly.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|c   |middle-end
   Keywords||missed-optimization
Summary|loop iv detection failure,  |loop iv detection failure
   |SSA autoincrement   |


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

[Bug c/38856] loop iv detection failure, SSA autoincrement

[sergei_lus at yahoo dot com]

--- Comment #2 from sergei_lus at yahoo dot com  2009-01-15 21:03 ---
Andrew, thank you for the prompt reply. 

I have seen PR 31849 and used the patch suggested. Without it autoincrement
would not work at all for either case. But the patch seems to deal with the
case when iv _were_ detected and generally alters cost computation to take that
addressing mode into account, while in this case I see that ivs are _not_
detected in the first place.  This seems to be a more fundamental issue -
should SSA be made "minimal" at that point or should iv detection be improved
to "see" trough “aliased” PHI node – I lack better words to describe it.


-- 


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

[Bug libstdc++/38860] failbit not set when it should be

[paolo dot carlini at oracle dot com]

--- Comment #2 from paolo dot carlini at oracle dot com  2009-01-15 20:48 
---
Yeah, this is simply because we are implementing the resolution of DR596:

  http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#596

This is documented, both in the source code and in the docs.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug libgcj/38861] New: gcjwebplugin.cc doesn't compile against latest xulrunner 1.9.1 sdk

[jakub at gcc dot gnu dot org]

https://bugzilla.mozilla.org/show_bug.cgi?id=455458

xulrunner helpfully renamed npupp.h that gcjwebplugin.cc uses to npfunctions.h
and removed all the NewNPP_* macros (and jref is gone as well).

I'm trying now:
--- libjava/classpath/native/plugin/gcjwebplugin.cc.jj  2009-01-14
12:08:34.0 +0100
+++ libjava/classpath/native/plugin/gcjwebplugin.cc 2009-01-15
21:20:17.0 +0100
@@ -45,7 +45,7 @@ exception statement from your version. *

 // Netscape plugin API includes.
 #include 
-#include 
+#include 

 // GLib includes.
 #include 
@@ -827,7 +827,7 @@ GCJ_URLNotify (NPP instance, const char*
   PLUGIN_DEBUG ("GCJ_URLNotify return");
 }

-jref
+void *
 GCJ_GetJavaClass (void)
 {
   PLUGIN_DEBUG ("GCJ_GetJavaClass");
@@ -1669,17 +1669,17 @@ NP_Initialize (NPNetscapeFuncs* browserT
   // Return to the browser the plugin functions that we implement.
   pluginTable->version = (NP_VERSION_MAJOR << 8) + NP_VERSION_MINOR;
   pluginTable->size = sizeof (NPPluginFuncs);
-  pluginTable->newp = NewNPP_NewProc (GCJ_New);
-  pluginTable->destroy = NewNPP_DestroyProc (GCJ_Destroy);
-  pluginTable->setwindow = NewNPP_SetWindowProc (GCJ_SetWindow);
-  pluginTable->newstream = NewNPP_NewStreamProc (GCJ_NewStream);
-  pluginTable->destroystream = NewNPP_DestroyStreamProc (GCJ_DestroyStream);
-  pluginTable->asfile = NewNPP_StreamAsFileProc (GCJ_StreamAsFile);
-  pluginTable->writeready = NewNPP_WriteReadyProc (GCJ_WriteReady);
-  pluginTable->write = NewNPP_WriteProc (GCJ_Write);
-  pluginTable->print = NewNPP_PrintProc (GCJ_Print);
-  pluginTable->urlnotify = NewNPP_URLNotifyProc (GCJ_URLNotify);
-  pluginTable->getvalue = NewNPP_GetValueProc (GCJ_GetValue);
+  pluginTable->newp = (NPP_NewProc) (GCJ_New);
+  pluginTable->destroy = (NPP_DestroyProc) (GCJ_Destroy);
+  pluginTable->setwindow = (NPP_SetWindowProc) (GCJ_SetWindow);
+  pluginTable->newstream = (NPP_NewStreamProc) (GCJ_NewStream);
+  pluginTable->destroystream = (NPP_DestroyStreamProc) (GCJ_DestroyStream);
+  pluginTable->asfile = (NPP_StreamAsFileProc) (GCJ_StreamAsFile);
+  pluginTable->writeready = (NPP_WriteReadyProc) (GCJ_WriteReady);
+  pluginTable->write = (NPP_WriteProc) (GCJ_Write);
+  pluginTable->print = (NPP_PrintProc) (GCJ_Print);
+  pluginTable->urlnotify = (NPP_URLNotifyProc) (GCJ_URLNotify);
+  pluginTable->getvalue = (NPP_GetValueProc) (GCJ_GetValue);

   initialized = true;

just to see if it compiles.  I guess the removal of NewNPP_* macros shouldn't
hurt even with npupp.h and older xulrunner/firefox/mozilla etc., npupp.h vs
npfunctions.h probably needs configure to determine it and jref I have no idea
about why that function is defined at all, when it isn't referenced anywhere.

OT, the libjava/testsuite/libjava.lang/PR35020.java testcase doesn't compile
with ecj (tried eclipse-ecj 3.3.2 and 3.4.1):

gcj -C PR35020.java 
PR35020.java:20: warning: PrivilegedAction is a raw type. References to generic
type PrivilegedAction should be parameterized
System.out.println((new java.security.PrivilegedAction() 
^^
PR35020.java:28: error: outer$inner.inner cannot be resolved to a type
System.out.println(outer$inner.inner.class.getSimpleName());
   ^
2 problems (1 error, 1 warning)


-- 
   Summary: gcjwebplugin.cc doesn't compile against latest xulrunner
1.9.1 sdk
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org


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

[Bug fortran/38859] [4.3/4.4 Regression] ubound and lbound treat structure component references as whole arrays

[burnus at gcc dot gnu dot org]

--- Comment #2 from burnus at gcc dot gnu dot org  2009-01-15 20:10 ---
   ida = lbound(a%i)
   if (any(ida /= (/1,1/))) print *, 'lbound', ida

Here, gfortran prints:
   lbound  0  2
Correct would be
   lbound  1  1


   ida = ubound(a)
>>>^^^
Here a "%i" is missing otherwise the following line does not make sense:

   if (any(ida /= (/6,7/))) print *, 'ubound', ida

For ubound(a) the result should be "5 8" which is also gfortran's result.
For ubound(a%i):
  gfortran: 5 8
  correct:  6 7


-- 


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

[Bug c++/38860] failbit not set when it should be

[aczapran at hotmail dot com]

--- Comment #1 from aczapran at hotmail dot com  2009-01-15 20:09 ---
Created an attachment (id=17108)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17108&action=view)
preprocessed file attaced = "a.ii"


-- 


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

[Bug c++/38860] New: failbit not set when it should be

[aczapran at hotmail dot com]

C++ pgm attempts to verify rdstate of an ofstream opened as follows:
...
ostr.open(tn, std::ios_base::out | std::ios_base::in | std::ios_base::app);
  if(ostr.rdstate() == std::ios_base::failbit)
 printf( "good\n");
  else
 printf( "bad.. should be failbit\n" );
...

gcc version info

>gcc  a.cpp -lstdc++ -save-temps -v
Using built-in specs.
Target: powerpc64-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,objc,fortran,obj-c++,java --enable-checking=release
--with-gxx-include-dir=/usr/include/c++/4.3 --enable-ssp --disable-libssp
--with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux'
--disable-libgcj --disable-libmudflap --with-slibdir=/lib64 --with-system-zlib
--enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--enable-version-specific-runtime-libs --program-suffix=-4.3
--enable-linux-futex --without-system-libunwind --with-cpu=power4
--enable-secureplt --with-long-double-128 --build=powerpc64-suse-linux
Thread model: posix
gcc version 4.3.2 [gcc-4_3-branch revision 141291] (SUSE Linux)
COLLECT_GCC_OPTIONS='-save-temps' '-v' '-mcpu=power4'
 /usr/lib64/gcc/powerpc64-suse-linux/4.3/cc1plus -E -quiet -v -D_GNU_SOURCE
-D__unix__ -D__gnu_linux__ -D__linux__ -Dunix -D__unix -Dlinux -D__linux
-Asystem=linux -Asystem=unix -Asystem=posix a.cpp -msecure-plt -mcpu=power4
-fpch-preprocess -o a.ii
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/c++/4.3
 /usr/include/c++/4.3/powerpc64-suse-linux
 /usr/include/c++/4.3/backward
 /usr/local/include
 /usr/lib64/gcc/powerpc64-suse-linux/4.3/include
 /usr/lib64/gcc/powerpc64-suse-linux/4.3/include-fixed

/usr/lib64/gcc/powerpc64-suse-linux/4.3/../../../../powerpc64-suse-linux/include
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-save-temps' '-v' '-mcpu=power4'
 /usr/lib64/gcc/powerpc64-suse-linux/4.3/cc1plus -fpreprocessed a.ii
-msecure-plt -quiet -dumpbase a.cpp -mcpu=power4 -auxbase a -version -o a.s
GNU C++ (SUSE Linux) version 4.3.2 [gcc-4_3-branch revision 141291]
(powerpc64-suse-linux)
compiled by GNU C version 4.3.2 [gcc-4_3-branch revision 141291], GMP
version 4.2.3, MPFR version 2.3.2.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: f744d9b01512a1796d5a77d85bde8481
COLLECT_GCC_OPTIONS='-save-temps' '-v' '-mcpu=power4'

/usr/lib64/gcc/powerpc64-suse-linux/4.3/../../../../powerpc64-suse-linux/bin/as
-a64 -mpower4 -many -V -Qy -o a.o a.s
GNU assembler version 2.19 (powerpc64-suse-linux) using BFD version (GNU
Binutils; SUSE:Factory:Head) 2.19
COMPILER_PATH=/usr/lib64/gcc/powerpc64-suse-linux/4.3/:/usr/lib64/gcc/powerpc64-suse-linux/4.3/:/usr/lib64/gcc/powerpc64-suse-linux/:/usr/lib64/gcc/powerpc64-suse-linux/4.3/:/usr/lib64/gcc/powerpc64-suse-linux/:/usr/lib64/gcc/powerpc64-suse-linux/4.3/../../../../powerpc64-suse-linux/bin/
LIBRARY_PATH=/usr/lib64/gcc/powerpc64-suse-linux/4.3/:/usr/lib64/gcc/powerpc64-suse-linux/4.3/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/usr/lib64/gcc/powerpc64-suse-linux/4.3/../../../../powerpc64-suse-linux/lib/:/usr/lib64/gcc/powerpc64-suse-linux/4.3/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-save-temps' '-v' '-mcpu=power4'
 /usr/lib64/gcc/powerpc64-suse-linux/4.3/collect2 --build-id --eh-frame-hdr -V
-Qy -m elf64ppc -dynamic-linker /lib64/ld64.so.1
/usr/lib64/gcc/powerpc64-suse-linux/4.3/../../../../lib64/crt1.o
/usr/lib64/gcc/powerpc64-suse-linux/4.3/../../../../lib64/crti.o
/usr/lib64/gcc/powerpc64-suse-linux/4.3/crtbegin.o
-L/usr/lib64/gcc/powerpc64-suse-linux/4.3
-L/usr/lib64/gcc/powerpc64-suse-linux/4.3/../../../../lib64 -L/lib/../lib64
-L/usr/lib/../lib64
-L/usr/lib64/gcc/powerpc64-suse-linux/4.3/../../../../powerpc64-suse-linux/lib
-L/usr/lib64/gcc/powerpc64-suse-linux/4.3/../../.. a.o -lstdc++ -lgcc
--as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed
/usr/lib64/gcc/powerpc64-suse-linux/4.3/crtsavres.o
/usr/lib64/gcc/powerpc64-suse-linux/4.3/crtend.o
/usr/lib64/gcc/powerpc64-suse-linux/4.3/../../../../lib64/crtn.o
GNU ld (GNU Binutils; SUSE:Factory:Head) 2.19
  Supported emulations:
   elf64ppc
   elf32ppclinux
   elf32ppc
   elf32ppcsim
a.o:(.text+0x74): warning: the use of `tmpnam' is dangerous, better use
`mkstemp'

source file... before preprocessing...
>>
#include 
#include 

int main(int argc, char *argv[])
{
int adebug = 0;
char *Filename;
if (argc > 1 && argv[1] != 0)
adebug = 1;
Filename = (char*)"_2781_10Y31.cpp";

typedef std::char_traits It;
typedef std::basic_ofstream Ofs;
Ofs ostr;
const char *tn = std::tmpnam(0);
printf( "filename is:%s\n", tn );
ostr.open(tn, std::ios_base::out | std::ios_base::in |
std::ios_base::app);
int state = ostr.

[Bug fortran/38859] [4.3/4.4 Regression] ubound and lbound treat structure component references as whole arrays

[burnus at gcc dot gnu dot org]

--- Comment #1 from burnus at gcc dot gnu dot org  2009-01-15 20:04 ---
Confirm. This is a regression with regards to 4.2.1; it fails at least since
20071008 (my oldest 4.3 trunk version).

Thanks for the report!


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

OtherBugsDependingO||32834
  nThis||
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||wrong-code
  Known to fail||4.3.0 4.3.2 4.4.0
  Known to work||4.2.1 4.1.3
   Priority|P3  |P4
   Last reconfirmed|-00-00 00:00:00 |2009-01-15 20:04:20
   date||
Summary|ubound and lbound treat |[4.3/4.4 Regression] ubound
   |structure component |and lbound treat structure
   |references as whole arrays  |component references as
   ||whole arrays
   Target Milestone|--- |4.3.4


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

[Bug libstdc++/32666] FAIL: abi_check

[bkoz at gcc dot gnu dot org]

--- Comment #11 from bkoz at gcc dot gnu dot org  2009-01-15 20:02 ---
Subject: Bug 32666

Author: bkoz
Date: Thu Jan 15 20:02:11 2009
New Revision: 143406

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143406
Log:
2009-01-15  Benjamin Kosnik  

PR libstdc++/32666
* config/abi/post/hppa-linux-gnu/baseline_symbols.txt: Update.

2009-01-15  Benjamin Kosnik  

PR libstdc++/32666
* Makefile.am (hosted_source): Remove libmath directory.
* Makefile.in: Regenerate.
* linkage.m4 (GLIBCXX_CHECK_COMPLEX_MATH_SUPPORT): Remove.
(AC_REPLACE_MATHFUNCS): Remove.
(GLIBCXX_CHECK_MATH_SUPPORT): Remove copysign, copysignl checks as done
in GLIBCXX_CHECK_C99_TR1.
* acinclude.m4: Remove libmath, need_math.
* crossconfig.m4: Remove use of HAVE_COPYSIGN, HAVE_COPYSIGNL,
HAVE_COPYSIGNF, GLIBCXX_CHECK_COMPLEX_MATH_SUPPORT, need_libmath.
* configure.ac: Same.
* configure: Regenerate.
* fragment.am: Fix comment.
* config.h.in: Regenerate.
* src/Makefile.in: Regenerate.
* src/Makefile.am: Remove libmath references.
* doc/Makefile.in: Regenerate.
* po/Makefile.in: Regenerate.
* include/Makefile.in: Regenerate.
* libsupc++/Makefile.in: Regenerate.
* testsuite/Makefile.in: Regenerate.

* src/compatibility.cc: Also export long double versions of "C" math
library if hppa-linux.
* config/abi/pre/gnu.ver: Remove unused __signbit exports.
* doc/xml/manual/appendix_contributing.xml: Remove libmath reference.

* libmath: Remove.
* libmath/signbit.c: Same.
* libmath/stubs.c: Same.
* libmath/Makefile.in: Same.
* libmath/copysignf.c: Same.
* libmath/mathconf.h: Same.
* libmath/signbitf.c: Same.
* libmath/Makefile.am: Same.
* libmath/signbitl.c: Same.


Removed:
trunk/libstdc++-v3/libmath/
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/Makefile.am
trunk/libstdc++-v3/Makefile.in
trunk/libstdc++-v3/acinclude.m4
trunk/libstdc++-v3/config.h.in
trunk/libstdc++-v3/config/abi/post/hppa-linux-gnu/baseline_symbols.txt
trunk/libstdc++-v3/config/abi/pre/gnu.ver
trunk/libstdc++-v3/configure
trunk/libstdc++-v3/configure.ac
trunk/libstdc++-v3/crossconfig.m4
trunk/libstdc++-v3/doc/Makefile.in
trunk/libstdc++-v3/doc/xml/manual/appendix_contributing.xml
trunk/libstdc++-v3/fragment.am
trunk/libstdc++-v3/include/Makefile.in
trunk/libstdc++-v3/libsupc++/Makefile.in
trunk/libstdc++-v3/linkage.m4
trunk/libstdc++-v3/po/Makefile.in
trunk/libstdc++-v3/src/Makefile.am
trunk/libstdc++-v3/src/Makefile.in
trunk/libstdc++-v3/src/compatibility.cc
trunk/libstdc++-v3/testsuite/Makefile.in


-- 


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

[Bug target/17381] Unnecessary register move for float extend

[pinskia at gcc dot gnu dot org]

--- Comment #5 from pinskia at gcc dot gnu dot org  2009-01-15 19:58 ---
This is the patch which fixes the issue:Index: regrename.c
===
--- regrename.c (revision 3023)
+++ regrename.c (working copy)
@@ -1374,6 +1374,10 @@ maybe_mode_change (enum machine_mode ori
   enum machine_mode new_mode, unsigned int regno,
   unsigned int copy_regno ATTRIBUTE_UNUSED)
 {
+  if (GET_MODE_SIZE (copy_mode) == GET_MODE_SIZE (new_mode)
+  && hard_regno_nregs[copy_regno][copy_mode] ==
hard_regno_nregs[copy_regno][new_mode]
+  && hard_regno_nregs[regno][copy_mode] ==
hard_regno_nregs[copy_regno][new_mode])
+return gen_rtx_raw_REG (new_mode, regno);
   if (orig_mode == new_mode)
 return gen_rtx_raw_REG (new_mode, regno);
   else if (mode_change_ok (orig_mode, new_mode, regno))
Index: config/rs6000/rs6000.md
===
--- config/rs6000/rs6000.md (revision 3023)
+++ config/rs6000/rs6000.md (working copy)
@@ -5247,10 +5247,17 @@ (define_insn_and_split "*extendsfdf2_fpr
#
fmr %0,%1
lfs%U1%X1 %0,%1"
-  "&& reload_completed && REG_P (operands[1]) && REGNO (operands[0]) == REGNO
(operands[1])"
+  "&& reload_completed && REG_P (operands[1])"
   [(const_int 0)]
 {
-  emit_note (NOTE_INSN_DELETED);
+  if (REGNO (operands[0]) == REGNO (operands[1]))
+emit_note (NOTE_INSN_DELETED);
+  else
+{
+  rtx op0 = gen_rtx_REG (DFmode, REGNO (operands[0]));
+  rtx op1 = gen_rtx_REG (DFmode, REGNO (operands[1]));
+  emit_insn (gen_move_insn (op0, op1));
+}
   DONE;
 }
   [(set_attr "type" "fp,fp,fpload")])


The rs6000 part is to tell the compiler what is really going on after register
allocator.  The regrename part allows to do a hard register copy propagation
after reload.
So we have:
(set (reg:SF 1) ... )
(set (reg:DF 2) (reg:DF 1))
(use (reg:DF 2))
After the rs6000.md patch.  Since the copy, is using the register in the larger
mode (DF), the last instruction should be just (use (reg:DF 1)).  This patch
allows for that.  


-- 


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

[Bug fortran/38859] New: ubound and lbound treat structure component references as whole arrays

[dick dot hendrickson at gmail dot com]

The UBOUND and LBOUND intrinsics treat a reference to an array structure
component as if they were inquires on a whole array.  

Dick Hendrickson


   program try_jg_15_18

! fails on Windows XP
! gcc version 4.4.0 20081219 (experimental) [trunk revision 142842] (GCC)

   type x
 integer I
   end type x
   type (x) A(0:5, 2:8)
   integer ida(2)

   ida = lbound(a)
   if (any(ida /= (/0,2/))) print *, 'base array', ida

!note that a%i is neither a whole array nor an array structure component

   ida = lbound(a%i)
   if (any(ida /= (/1,1/))) print *, 'lbound', ida

   ida = ubound(a)
   if (any(ida /= (/6,7/))) print *, 'ubound', ida

   end


C:\gfortran>gfortran try_jg_15_18.f

C:\gfortran>a
 lbound   0   2
 ubound   5   8


-- 
   Summary: ubound and lbound treat structure component references
as whole arrays
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dick dot hendrickson at gmail dot com


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

[Bug regression/38858] 255.vortex benchmark segfaults

[raksit at google dot com]

--- Comment #4 from raksit at google dot com  2009-01-15 19:32 ---
Yes, this looks like the same problem as in PR 23449.
The benchmarks runs fine if I compile with "-O2 -fno-strict-aliasing". And I
see from PR 23449 that this is a source-code issue. Closing this as a
duplicate.

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

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


-- 

raksit at google dot com changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||DUPLICATE


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

[Bug tree-optimization/23449] vortex fails without -fno-strict-aliasing

[raksit at google dot com]

--- Comment #4 from raksit at google dot com  2009-01-15 19:32 ---
*** Bug 38858 has been marked as a duplicate of this bug. ***


-- 

raksit at google dot com changed:

   What|Removed |Added

 CC||raksit at google dot com


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

[Bug regression/38858] 255.vortex benchmark segfaults

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2009-01-15 19:30 ---
Can you try -O2 -fno-strict-aliasing.  If that works, then this is a dup of bug
23449 :).  bug 23449 has a nice explication of where and how vortex violates
C/C++ aliasing rules.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug regression/38858] 255.vortex benchmark segfaults

[raksit at google dot com]

--- Comment #2 from raksit at google dot com  2009-01-15 19:27 ---
I am compiling vortex with "-O2" (it builds and runs correctly with -O0).


-- 


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

[Bug regression/38858] 255.vortex benchmark segfaults

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2009-01-15 19:25 ---
Last time I looked into vortex, it had some aliasing issues, see PR 23449. 
What options are you compiling vortex with?


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org


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

[Bug regression/38858] New: 255.vortex benchmark segfaults

[raksit at google dot com]

The 4.4 trunk gcc (I have tried revisions 143386, 143405) builds this SPEC2000
benchmark fine. But on running this benchmark, it segfaults pretty much
immediately (using any of the test, train, or ref inputs).


-- 
   Summary: 255.vortex benchmark segfaults
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: regression
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: raksit at google dot com
 GCC build triplet: i686-linux
  GCC host triplet: i686-linux
GCC target triplet: x86_64-linux


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

[Bug middle-end/38857] [4.4 Regression] ICE in selective scheduler

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
   Target Milestone|--- |4.4.0


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

[Bug middle-end/38857] New: [4.4 Regression] ICE in selective scheduler

[sje at cup dot hp dot com]

With this test case the selective scheduler is hitting a gcc_assert in
sel-sched-ir.c  I see this on IA64 Linux or on IA64 HP-UX when in 64 bit mode. 

In both cases it happens when compiling with -O3.

x.c: In function 'dv_guess_qnos':
x.c:22: internal compiler error: in sel_move_insn, at sel-sched-ir.c:1395
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


Test case:


static const int vs_total_ac_bits = 2680;
typedef struct EncBlockInfo {
  short mb[64];
  unsigned char next[64];
} EncBlockInfo;
inline void dv_guess_qnos(EncBlockInfo* blks, int* qnos) {
  int size[5];
  int j, k, a, prev;
  EncBlockInfo* b;
  for(a=2; a==2 || vs_total_ac_bits < size[0]; a+=a){
 for (j=0; j<6*5; j++, b++) {
 for (k= b->next[prev]; k<64; k= b->next[k]) {
 if(b->mb[k] < a && b->mb[k] > -a){
 b->next[prev] = b->next[k];
 }
 else{
 prev = k;
 }
 }
 }
 }
}


-- 
   Summary: [4.4 Regression] ICE in selective scheduler
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sje at cup dot hp dot com
GCC target triplet: ia64-*-*


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

[Bug c/38856] loop iv detection failure, SSA autoincrement

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2009-01-15 18:41 ---
Well first off, iv-opts on the tree level should be the place where
autoincrement is helped out.  See PR 31849 which I think this is a duplicate
of.


-- 


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

[Bug bootstrap/37660] [4.4 Regression] Error Building libssp, recent update

[dave dot korn dot cygwin at gmail dot com]

--- Comment #4 from dave dot korn dot cygwin at gmail dot com  2009-01-15 
19:08 ---
  I've just run into this problem too.

  In earlier versions of Aaron's shared libgcc patch, we extracted ctors.o and
chkstk.o and placed them whole into the import lib.  I'm not sure why he didn't
do this in the committed version, but it has the effect that you have to link
against the static libgcc as well as the shared one in order to let it fill out
any missing references.  I'm not sure I'm entirely comfortable with that,
although I can't think of any obvious problem, but it seems wrong to link
against such a duplicated body of code to me, and I think I'd prefer the import
lib solution for cygwin's compiler.  (We want -shared-libgcc as the default,
for greater unixness).

  In a way, there's an impedance mismatch in the libgcc build system; you can
add new functions per-target to the static library, by listing them in the
target makefile fragment, but there's no similar target fragment to let you
define extra exports in the libgcc mapfile/version script.

  I'm going to prepare a patch that revises shared libgcc building.  I'll put
it in the cygwin-specific fragment as an override of the defaults from the
shared fragment, and it's probably going to do more than just fix chkstk/ctors,
so it won't be suitable for mingw, but the mingw team might or might not want
to consider doing the same.

  BTW someone who has admin powers should set confirm this bug, it's definitely
real! :)

  cheers,
DaveK


-- 


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

[Bug libstdc++/32666] FAIL: abi_check

[doko at ubuntu dot com]

--- Comment #10 from doko at ubuntu dot com  2009-01-15 18:38 ---
checked the patch with trunk 20090115:

=== libstdc++ tests ===


Running target unix
XPASS: 26_numerics/headers/cmath/c99_classification_macros_c.cc (test for
excess errors)

=== libstdc++ Summary ===

# of expected passes5775
# of unexpected successes   1
# of expected failures  79
# of unsupported tests  331


-- 


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

[Bug c++/38579] [4.2/4.3/4.4 Regression] Template: Wrong inherited copy-ctor visibility

[syntheticpp at gmx dot net]

--- Comment #4 from syntheticpp at gmx dot net  2009-01-15 18:56 ---
It has nothing to do with templates.

This code still compiles:

struct P 
{
protected:
P() {}
P(const P&) {}
};

struct B : protected P
{
B() {}
};

struct C : public P
{
C(const B& b) : P(b) {}
};

void foo()
{
B b;
C c(b);

//P p(b); // <-- compiler error
}

But I it should not, because only within the scope of B
B "is a" P. Globally B "is not a" P. Therefore you can't pass
a instance of B in a scope different to B to the constructor 
of P. 
Even when C inherits from P the struct B is still "not a" P
in the scope of C.


-- 


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

[Bug c/38856] New: loop iv detection failure, SSA autoincrement

[sergei_lus at yahoo dot com]

I apologize if it is a well disguised feature, but I am forced to consider this
being a performance regression/bug. 

In the following trivial example:
void
VecADD(
long long *In1,
long long *In2,
long long *Out,
unsigned int samples
){
  int i;
  for (i = 0; i < samples; i++) {
Out[i] = In1[i] + In2[i];
  }
}

there is an implicit imprecision in the way C is used - type of 'samples' is
unsigned, while type of 'i' is signed. 

The problem on the high level - induction variable analysis fails for this
loop, which impairs further tree level loop optimizations from functioning
properly (including autoincrement). In my port performance is off by 50% for
this loop. GCC 3.4.6 was able to handle this situation fine. 

What I believe to be the problem at the lowest level is a non-minimal (or
overly restrictive) SSA representation right before the iv detection:

VecADD (In1, In2, Out, samples)
{
  int i;
  long long int D.1857;
  long long int D.1856;
  long long int * D.1855;
  long long int D.1854;
  long long int * D.1853;
  long long int * D.1852;
  unsigned int D.1851;
  unsigned int i.0;

:

:
  # i_10 = PHI <0(2)>
  i.0_5 = (unsigned int) i_10;
  if (i.0_5 < samples_4(D))
goto ;
  else
goto ;

:
  # i.0_9 = PHI 
  # i_14 = PHI 
  D.1851_6 = i.0_9 * 8;
  D.1852_8 = Out_7(D) + D.1851_6;
  D.1853_12 = In1_11(D) + D.1851_6;
  D.1854_13 = *D.1853_12;
  D.1855_17 = In2_16(D) + D.1851_6;
  D.1856_18 = *D.1855_17;
  D.1857_19 = D.1854_13 + D.1856_18;
  *D.1852_8 = D.1857_19;
  i_20 = i_14 + 1;

:
  # i_1 = PHI 
  i.0_3 = (unsigned int) i_1;
  if (i.0_3 < samples_4(D))
goto ;
  else
goto ;

:
  return;
}

The two PHI nodes in the beginning of BB3 break the iv detection. Same example
when types of ‘i’ and ‘samples’ would match will be analyzed perfectly fine
with the SSA at the same point looking like this:

VecADD (In1, In2, Out, samples)
{
  int i;
  long long int D.1857;
  long long int D.1856;
  long long int * D.1855;
  long long int D.1854;
  long long int * D.1853;
  long long int * D.1852;
  unsigned int D.1851;
  unsigned int i.0;

:

:
  # i_9 = PHI <0(2)>
  if (i_9 < samples_3(D))
goto ;
  else
goto ;

:
  # i_13 = PHI 
  i.0_4 = (unsigned int) i_13;
  D.1851_5 = i.0_4 * 8;
  D.1852_7 = Out_6(D) + D.1851_5;
  D.1853_11 = In1_10(D) + D.1851_5;
  D.1854_12 = *D.1853_11;
  D.1855_16 = In2_15(D) + D.1851_5;
  D.1856_17 = *D.1855_16;
  D.1857_18 = D.1854_12 + D.1856_17;
  *D.1852_7 = D.1857_18;
  i_19 = i_13 + 1;

:
  # i_1 = PHI 
  if (i_1 < samples_3(D))
goto ;
  else
goto ;

:
  return;
}

On one hand I seem to understand that a danger of signed/unsigned overflow at
increment can force this kind of conservatism, but on the high level this
situation was handled fine by gcc 3.4.6 and is handled with no issues by
another SSA based compiler. If there is a way to relax this strict
interpretation of C rules by GCC 4.3.2, I would gladly learn about it, but my
brief flag mining exercise yielded no results. Thank you.


-- 
   Summary: loop iv detection failure, SSA autoincrement
   Product: gcc
   Version: 4.3.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sergei_lus at yahoo dot com


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

[Bug c++/37646] [4.2/4.3/4.4 regression] ICE with function vs. member function

[jason at gcc dot gnu dot org]

--- Comment #2 from jason at gcc dot gnu dot org  2009-01-15 18:14 ---
Subject: Bug 37646

Author: jason
Date: Thu Jan 15 18:14:32 2009
New Revision: 143404

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143404
Log:
PR c++/36334
PR c++/37646
* tree.c (lvalue_p_1): Handle BASELINK.  A COMPONENT_REF to
a function isn't necessarily an lvalue. Take tree, not const_tree.
(lvalue_p, real_lvalue_p): Take tree, not const_tree.
* typeck.c (lvalue_or_else): Likewise.
* cp-tree.h: Adjust prototypes.

Added:
trunk/gcc/testsuite/g++.dg/conversion/memfn1.C
trunk/gcc/testsuite/g++.dg/conversion/memfn2.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/tree.c
trunk/gcc/cp/typeck.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/36334] [4.2/4.3/4.4 Regression] typedef to function type leads to problems

[jason at gcc dot gnu dot org]

--- Comment #4 from jason at gcc dot gnu dot org  2009-01-15 18:14 ---
Subject: Bug 36334

Author: jason
Date: Thu Jan 15 18:14:32 2009
New Revision: 143404

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143404
Log:
PR c++/36334
PR c++/37646
* tree.c (lvalue_p_1): Handle BASELINK.  A COMPONENT_REF to
a function isn't necessarily an lvalue. Take tree, not const_tree.
(lvalue_p, real_lvalue_p): Take tree, not const_tree.
* typeck.c (lvalue_or_else): Likewise.
* cp-tree.h: Adjust prototypes.

Added:
trunk/gcc/testsuite/g++.dg/conversion/memfn1.C
trunk/gcc/testsuite/g++.dg/conversion/memfn2.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/tree.c
trunk/gcc/cp/typeck.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/38357] [4.2/4.3/4.4 Regression] ICE cc1plus (Segmentation fault)

[sje at gcc dot gnu dot org]

--- Comment #3 from sje at gcc dot gnu dot org  2009-01-15 18:09 ---
Subject: Bug 38357

Author: sje
Date: Thu Jan 15 18:09:04 2009
New Revision: 143403

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143403
Log:
PR c++/38357
* g++.dg/template/crash87.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/template/crash87.C
Modified:
trunk/gcc/testsuite/ChangeLog


-- 


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