[Bug bootstrap/38580] [4.4 Regression] Bootstrap broken on mingw32

2009-01-12 Thread dannysmith at users dot sourceforge dot net


--- Comment #8 from dannysmith at users dot sourceforge dot net  2009-01-13 
07:43 ---
Fixed on trunk.


-- 

dannysmith at users dot sourceforge dot net changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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



[Bug bootstrap/38580] [4.4 Regression] Bootstrap broken on mingw32

2009-01-12 Thread dannysmith at gcc dot gnu dot org


--- Comment #7 from dannysmith at gcc dot gnu dot org  2009-01-13 07:41 
---
Subject: Bug 38580

Author: dannysmith
Date: Tue Jan 13 07:40:51 2009
New Revision: 143330

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143330
Log:
PR bootstrap/38580
* gcc.c (process_command): Replace call to execvp with calls
to pex_one and exit.

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


-- 


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



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

2009-01-12 Thread rob1weld at aol dot com


--- Comment #6 from rob1weld at aol dot com  2009-01-13 07:16 ---
(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
> 
Yes, it's a little screwy.

If 64 bit code can not be executed on a 32 bit platform then you MUST be 
'cross compiling'. I think the term it is looking for is 'building multilib'.


Other circumstances include "co-processing". You want to compile for your
favorite hardware, Xbox or PSP, and you execute a portion of gcc's build
on the device, both for speed and accuracy of the values determined by the
configure scripts. The 'hardware' can also be "fake" like Qemu.


There is also the situation where you have the hardware you are compiling
for and could execute the program and libraries on the device. This helps
to get the real values for fixing scripts used to cross compile.

The gdb program can help run "make -i check" on your hardware remotely.


Maybe the Docs need this explanation:

What if you have a 486 and want to build 32/64 bit execs/libs for a 686.
That is cross compiling and multilib, regardless of boot mode. Up in family
or "cross" family is cross compiling.

What if you have a 686 and want to build 32/64 bit execs/libs for a 686.
That is building multilib, regardless of boot mode. Same family, no cross.

What if you have a 686 and want to build 32/64 bit execs/libs for a 486.
That is building multilib, regardless of boot mode. Down in family is not
cross compiling.


Building any of the above combinations with either only 32 bit _or_ only
64 bit execs/libs means you are not building multilib.

Building for a higher number in the family or "cross" to a different (and
non-compatible) family is cross compiling.


A quick mention for completeness that cross platform (or ABI) compiling is
not "cross compiling" in the usual sense though the same techniques can be
used to get gcc to run under Cygwin (a Linux Simulation for Windows (and
others)) or Wine (a Windows Simulation for Linux (and others)) by using
bootstrapping and cross compiling.

I don't know why this 32/64 bit issue comes up so often. We've had 64 bit
OSes for a few years now. It must be the VM that is new and confusing ;(o


Also, the dozen occurrences of the 'ac_link' variable is redundant.

Rob


-- 


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



[Bug libfortran/38772] r143102 reveals missed error checking on floating point reads

2009-01-12 Thread jvdelisle at gcc dot gnu dot org


--- Comment #21 from jvdelisle at gcc dot gnu dot org  2009-01-13 06:07 
---
Reply to comments 16 and 17 which I did not see before my commit.  Please make
sure the original r143102 is in place when you apply latest patch.  It does
seem bothersome that the xplor-nih is so sensitive.  It is largely due to
depending on error conditions.

I don't think we want to jump to Daniels patch until we understand what's wrong
here.

Regardless, I will need a reduced test case to go further.


-- 


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



[Bug libfortran/38772] r143102 reveals missed error checking on floating point reads

2009-01-12 Thread jvdelisle at gcc dot gnu dot org


--- Comment #20 from jvdelisle at gcc dot gnu dot org  2009-01-13 05:57 
---
Thanks for help Jack.  The patch committed does fix the test case you provided.
 Please double check with xplor-nih and if fixed as expected we can close this
PR.


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|r143102 breaks error|r143102 reveals missed error
   |checking on floating point  |checking on floating point
   |reads   |reads


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



[Bug libfortran/38772] r143102 breaks error checking on floating point reads

2009-01-12 Thread jvdelisle at gcc dot gnu dot org


--- Comment #19 from jvdelisle at gcc dot gnu dot org  2009-01-13 05:53 
---
Subject: Bug 38772

Author: jvdelisle
Date: Tue Jan 13 05:53:07 2009
New Revision: 143328

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143328
Log:
2009-01-12  Jerry DeLisle  

PR libfortran/38772
* gfortran.dg/fmt_bz_bn_err.f: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/fmt_bz_bn_err.f
Modified:
trunk/gcc/testsuite/ChangeLog


-- 


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



[Bug libfortran/38772] r143102 breaks error checking on floating point reads

2009-01-12 Thread jvdelisle at gcc dot gnu dot org


--- Comment #18 from jvdelisle at gcc dot gnu dot org  2009-01-13 05:40 
---
Subject: Bug 38772

Author: jvdelisle
Date: Tue Jan 13 05:40:36 2009
New Revision: 143327

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143327
Log:
2009-01-12  Jerry DeLisle  

PR libfortran/38772
* io/read.c (read_f): Clean up loop conditions for BZ/BN,
allowing proper digit testing. White space fix.

Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/read.c


-- 


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



[Bug libfortran/38772] r143102 breaks error checking on floating point reads

2009-01-12 Thread howarth at nitro dot med dot uc dot edu


--- Comment #17 from howarth at nitro dot med dot uc dot edu  2009-01-13 
05:31 ---
I'll do a fresh bootstrap with the proposed patch tomorrow. We may have a
separate regression that appeared since I last checked the full xplor-nih
testsuite. Basically, the following difference is appearing in output of half
of the testcases

@@ -264,8 +264,8 @@
  X-PLOR>energy end 
  --- cycle= 1
--
  | Etotal =236.279grad(E)=14.482 E(BOND)=41.209 E(ANGL)=122.157   
|
- | E(DIHE)=0.000  E(IMPR)=48.529 E(VDW )=18.932 E(ELEC)=0.000 
|
- | E(COUP)=5.453  
|
+ | E(DIHE)=0.000  E(IMPR)=48.529 E(VDW )=18.932 E(ELEC)=0.000  
+ | E(COUP)=5.453   
 
---
  X-PLOR> 
  X-PLOR>coup  print threshold=1.0 class phi end 

somehow we are losing the trailing | character in the output.


-- 


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



[Bug libfortran/38772] r143102 breaks error checking on floating point reads

2009-01-12 Thread howarth at nitro dot med dot uc dot edu


--- Comment #16 from howarth at nitro dot med dot uc dot edu  2009-01-13 
05:06 ---
Jerry,
While that eliminated the failure in the xtarget.inp testcase for
xplor-nih, it also increased the number of test case failures from 13 to 72 out
of 133 tests. I'll test Daniel's patch to see if it allows all of xplor-nih's
testcases to pass.


-- 


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



[Bug testsuite/38821] [4.4 Regression] Testsuite for libjava is truncated

2009-01-12 Thread pinskia at gcc dot gnu dot org


--- Comment #1 from pinskia at gcc dot gnu dot org  2009-01-13 05:02 ---
There is no java source compiler in 4.3 and above so the number of tests have
decreased.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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



[Bug testsuite/38821] New: [4.4 Regression] Testsuite for libjava is truncated

2009-01-12 Thread rob1weld at aol dot com
I built gcc version 4.4.0 20090104 (experimental) (GCC) and 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-qt-peer --enable-xmlj
--enable-gconf-peer --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


I ran "make -i check" and got this sort of result for libjava:

Using /usr/share/src/gcc_trunk/libjava/testsuite/config/default.exp as
tool-and-target-specific interface file.
Running /usr/share/src/gcc_trunk/libjava/testsuite/libjava.cni/cni.exp ...
Running /usr/share/src/gcc_trunk/libjava/testsuite/libjava.jar/jar.exp ...
Running /usr/share/src/gcc_trunk/libjava/testsuite/libjava.jni/jni.exp ...
Running
/usr/share/src/gcc_trunk/libjava/testsuite/libjava.jvmti/jvmti-interp.exp ...
Running /usr/share/src/gcc_trunk/libjava/testsuite/libjava.jvmti/jvmti.exp ...
Running /usr/share/src/gcc_trunk/libjava/testsuite/libjava.lang/lang.exp ...
Running /usr/share/src/gcc_trunk/libjava/testsuite/libjava.loader/loader.exp
...
Running /usr/share/src/gcc_trunk/libjava/testsuite/libjava.mauve/mauve.exp ...
Running /usr/share/src/gcc_trunk/libjava/testsuite/libjava.special/special.exp
...
Running /usr/share/src/gcc_trunk/libjava/testsuite/libjava.verify/verify.exp
...

=== libjava Summary ===

# of expected passes2468
# of unexpected failures55
# of untested testcases 55

--

I built gcc version 4.2.3 (release) and configured with:

../gcc_4.2.3/configure --prefix=/usr/gnu --libdir=/usr/gnu/lib
--libexecdir=/usr/gnu/lib --mandir=/usr/gnu/share/man --infodir=/usr/share/info
--with-as=/usr/gnu/bin/as --with-gnu-as --with-ld=/usr/ccs/bin/ld
--without-gnu-ld --enable-languages=ada,c,c++,fortran,java,objc,obj-c++
--enable-multilib --enable-shared --disable-static --enable-decimal-float
-disable-nls

I ran "make -i check" and got this sort of result for libjava:

Using /usr/share/src/gcc_4.2.3/libjava/testsuite/config/default.exp as
tool-and-target-specific interface file.
Running /usr/share/src/gcc_4.2.3/libjava/testsuite/libjava.cni/cni.exp ...
Running /usr/share/src/gcc_4.2.3/libjava/testsuite/libjava.compile/compile.exp
...
Running /usr/share/src/gcc_4.2.3/libjava/testsuite/libjava.jacks/jacks.exp ...
Running /usr/share/src/gcc_4.2.3/libjava/testsuite/libjava.jar/jar.exp ...
Running /usr/share/src/gcc_4.2.3/libjava/testsuite/libjava.jni/jni.exp ...
Running /usr/share/src/gcc_4.2.3/libjava/testsuite/libjava.jvmti/jvmti.exp ...
Running /usr/share/src/gcc_4.2.3/libjava/testsuite/libjava.lang/lang.exp ...
Running /usr/share/src/gcc_4.2.3/libjava/testsuite/libjava.loader/loader.exp
...
Running /usr/share/src/gcc_4.2.3/libjava/testsuite/libjava.mauve/mauve.exp ...
Running /usr/share/src/gcc_4.2.3/libjava/testsuite/libjava.special/special.exp
...
Running /usr/share/src/gcc_4.2.3/libjava/testsuite/libjava.verify/verify.exp
...

=== libjava Summary ===

# of expected passes6978
# of unexpected failures13
# of expected failures  12
# of untested testcases 18

--

When you compare gcc version 4.4.0 20090104 with gcc version 4.2.3 (release)
you notice that the trunk adds test
"libjava/testsuite/libjava.jvmti/jvmti-interp.exp"
and is missing both tests "libjava/testsuite/libjava.compile/compile.exp"
and "libjava/testsuite/libjava.jacks/jacks.exp". 


The 4.2.3 version passed 6978 tests (with a couple of dozen 'not-pass'
results).
The Trunk version passed 2468 tests (with four dozen 'not-pass' results).

The Trunk was compiled with a few more complicated java configuration yet
there were fewer tests for the Trunk compared with the 4.2.x series.


I have looked at some results from / to:
http://gcc.gnu.org/ml/gcc-testresults/2008-03/
http://gcc.gnu.org/ml/gcc-testresults/2009-01/

and it seems that 4.4 is with far fewer tests than prior versions.


Thanks,
Rob


-- 
   Summary: [4.4 Regression] Testsuite for libjava is truncated
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rob1weld at aol dot com


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



[Bug libfortran/38772] r143102 breaks error checking on floating point reads

2009-01-12 Thread jvdelisle at gcc dot gnu dot org


--- Comment #15 from jvdelisle at gcc dot gnu dot org  2009-01-13 04:36 
---
Here is a patch.  If the character is not a digit or a blank, we exit the loop
and skip the test for not a digit.  DUH!  (first part of patch is just an
indentation fix)

Index: read.c
===
--- read.c  (revision 143139)
+++ read.c  (working copy)
@@ -972,14 +972,14 @@ read_f (st_parameter_dt *dtp, const fnod
   while (w > 0)
 {
   if (*p != ' ')
- goto bad_float;
+   goto bad_float;
   p++;
   w--;
 }
 }
   else  /* BZ or BN status is enabled */
 {
-  while (w > 0 && (isdigit (*p) || *p == ' '))
+  while (w > 0)
 {
   if (*p == ' ')
 {


-- 


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



[Bug libfortran/38772] r143102 breaks error checking on floating point reads

2009-01-12 Thread jvdelisle at gcc dot gnu dot org


--- Comment #14 from jvdelisle at gcc dot gnu dot org  2009-01-13 04:14 
---
The problem is in read.c.  In reading floats we are not catching invalid
exponent characters.  The BN patch just revealed this bug that has been there
all along.

The string can be just about anything with an 'e' followed by at least one
character, including such things as 'ej' or 'ek  '.

Incidentally, Daniel's read float patch fixes this.  If any one is brave
enough, we could just commit his patch.  Otherwise I will band aid this one,
hopefully shortly.


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||wrong-code


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



[Bug libfortran/38772] r143102 breaks error checking on floating point reads

2009-01-12 Thread jvdelisle at gcc dot gnu dot org


--- Comment #13 from jvdelisle at gcc dot gnu dot org  2009-01-13 03:44 
---
Great work Jack.  Now we have a test case to work with.


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jvdelisle at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-01-13 03:44:53
   date||


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



[Bug testsuite/38820] New: [4.2/4.3/4.4 Regression] During "make -i check" we set GCC_EXEC_PREFIX="/usr/local/lib/gcc/"

2009-01-12 Thread rob1weld at aol dot com
+++ This bug was initially created as a clone of Bug #14435 +++

I built "gcc version 4.4.0 20090111 [trunk revision 143259]" and when I
run "make -i check" it sets 'GCC_EXEC_PREFIX="/usr/local/lib/gcc/"'.


It seems gcc may look for this directory:

# ls -lrtA /usr/local/lib/gcc/i386-pc-solaris2.11/4.4.0/
total 1327
drwxr-xr-x  13 root root  21 Jan 10 22:26 include-fixed
drwxr-xr-x   3 root root   7 Jan 11 17:57 install-tools
-rw-r--r--   1 root root  137434 Jan 11 17:58 libgcc_eh.a
-rw-r--r--   1 root root  236788 Jan 11 17:58 libgcc.a
-rw-r--r--   1 root root   95148 Jan 11 17:58 libgcov.a
-rw-r--r--   1 root root3888 Jan 11 17:58 gmon.o
-rw-r--r--   1 root root2032 Jan 11 17:58 crtbegin.o
-rw-r--r--   1 root root1300 Jan 11 17:58 crtend.o
-rwxr-xr-x   1 root root 924 Jan 11 17:59 libgfortranbegin.la
-rw-r--r--   1 root root4462 Jan 11 17:59 libgfortranbegin.a
drwxr-xr-x   2 root root 604 Jan 11 18:06 adalib
drwxr-xr-x   2 root root1087 Jan 11 18:06 adainclude
drwxr-xr-x   4 root root  12 Jan 11 18:06 amd64
drwxr-xr-x   2 root root   6 Jan 11 18:07 finclude
drwxr-xr-x   5 root root  41 Jan 11 18:07 include


# gmake -i check
...
gmake[2]: Entering directory `/usr/share/src/gcc_build/gcc'
test -d testsuite || mkdir testsuite
test -d testsuite/gcc || mkdir testsuite/gcc
(rootme=`${PWDCMD-pwd}`; export rootme; \
srcdir=`cd ../../gcc_trunk/gcc; ${PWDCMD-pwd}` ; export srcdir ; \
cd testsuite/gcc; \
rm -f tmp-site.exp; \
sed '/set tmpdir/ s|testsuite|testsuite/gcc|' \
< ../../site.exp > tmp-site.exp; \
/bin/sh ${srcdir}/../move-if-change tmp-site.exp site.exp; \
EXPECT=`if [ -f ${rootme}/../expect/expect ] ; then echo
${rootme}/../expect/expect ; else echo expect ; fi` ; export EXPECT ; \
if [ -f ${rootme}/../expect/expect ] ; then  \
   TCL_LIBRARY=`cd .. ; cd ${srcdir}/../tcl/library ; ${PWDCMD-pwd}` ;
\
export TCL_LIBRARY ; fi ; \
GCC_EXEC_PREFIX="/usr/local/lib/gcc/" ; export GCC_EXEC_PREFIX ; \
...


If you do NOT run "make install" _PRIOR_ to running "make -i check" then
how can we be thinking that "/usr/local/lib/gcc/" contains the _correct_
code to be used for the Testsuite ?

We should either require installation prior to checking (which is not
good but I do it to ensure I don't get hit) _or_ have "make -i check" do
a _partial_ installation to a temp directory and set the "GCC_EXEC_PREFIX"
environment variable to the temporary directory instead (preferred).

We need "GCC_EXEC_PREFIX" set to the code that was just compiled and not
to code that might have been installed weeks / months previously (or not
installed at all).

Rob


-- 
   Summary: [4.2/4.3/4.4 Regression] During "make -i check" we set
GCC_EXEC_PREFIX="/usr/local/lib/gcc/"
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rob1weld at aol dot com
 GCC build triplet: *-*-*
  GCC host triplet: *-*-*
GCC target triplet: *-*-*


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



[Bug bootstrap/26323] toplevel directories should be assocaited at the toplevel with a language being built instead of with a subdirectory of gcc

2009-01-12 Thread rob1weld at aol dot com


--- Comment #5 from rob1weld at aol dot com  2009-01-13 02:52 ---
(In reply to comment #4)
> >"Cannot build gnattools while gnatlib is out of date or unbuilt".
> That bug is a different issue than this bug.  Please don't confuse the two.

I searched before I posted to try to avoid a dupe.

As long as this _second_ manifestation of "Cannot build gnattools while ..."
is recorded as a bug _somewhere_ then that is OK. It would be a 'fix' in _my_
instance if typing "make" built gnatlib first (so it was not "out of date or
unbuilt") and then was able to build gnattools successfully.

Thanks for the info,
Rob


-- 


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



[Bug libstdc++/38384] fails to build cross gcc for target hppa64-hp-hpux11.00 in libstdc++/libmath

2009-01-12 Thread bkoz at gcc dot gnu dot org


--- Comment #19 from bkoz at gcc dot gnu dot org  2009-01-13 01:49 ---
Subject: Bug 38384

Author: bkoz
Date: Tue Jan 13 01:49:30 2009
New Revision: 143322

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

PR libstdc++/38384
* crossconfig.m4 (hpux): Update for 10.20, 11, 11.20.
* configure: Regenerate.

2009-01-12  Benjamin Kosnik  

* crossconfig.m4 (linux): Add GCC_CHECK_TLS to define
_GLIBCXX_HAVE_TLS.
Use GLIBCXX_CHECK_COMPILER_FEATURES to compute SECTION_FLAGS.


Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/configure
trunk/libstdc++-v3/crossconfig.m4


-- 


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



[Bug libstdc++/36647] configure scripts can not find out version of GNU ld 2.18

2009-01-12 Thread bkoz at gcc dot gnu dot org


--- Comment #6 from bkoz at gcc dot gnu dot org  2009-01-13 01:35 ---

on trunk (4.4.x):

1) ld --version
GNU ld (GNU Binutils) 2.19
checking for ld version... 21900

2) ld --version
GNU ld version 2.18.50.0.9-7.fc10 20080822
checking for ld version... 21850

3) ld --version
GNU ld (GNU Binutils) 2.18
checking for ld version... 21800


All have visibility/versioning support enabled. This seems fine.


On gcc-4_3-branch (will be 4.3.3) this is also ok. Thus, closing.


-- 

bkoz at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Known to work||4.4.0
 Resolution||WORKSFORME


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



[Bug c++/35109] [4.2/4.3/4.4 Regression] ICE in lookup_name_real, at cp/name-lookup.c:4056

2009-01-12 Thread jason at gcc dot gnu dot org


--- Comment #6 from jason at gcc dot gnu dot org  2009-01-13 01:23 ---
Subject: Bug 35109

Author: jason
Date: Tue Jan 13 01:23:34 2009
New Revision: 143320

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143320
Log:
PR c++/35109
* name-lookup.c (lookup_name_real): Keep looking past a hidden
binding.

Added:
trunk/gcc/testsuite/g++.dg/lookup/friend14.C
trunk/gcc/testsuite/g++.dg/lookup/friend15.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/name-lookup.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/lookup/friend11.C


-- 


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



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

2009-01-12 Thread pinskia at gcc dot gnu dot org


--- Comment #4 from pinskia at gcc dot gnu dot org  2009-01-13 01:09 ---
We should be able to fold:
VIEW_CONVERT_EXPR(D.919509.D.78313.D.78008)

Into just D.919509 .

The indirect issue is a different one which needs to be fixed anyways as it
causes aliasing issues which were not in the original code in some cases.


-- 

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-13 01:09:36
   date||


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



[Bug libgcj/38812] gcj-built executables don't run after strip (libgcj erroneously references _environ)

2009-01-12 Thread pinskia at gcc dot gnu dot org


--- Comment #3 from pinskia at gcc dot gnu dot org  2009-01-13 01:03 ---
Confirmed, though your patch is not portable really.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
  GCC build triplet|i386-apple-darwin9.5.0  |
   GCC host triplet|i386-apple-darwin9.5.0  |
 GCC target triplet|i386-apple-darwin9.5.0  |*-*-darwin*
   Last reconfirmed|-00-00 00:00:00 |2009-01-13 01:03:10
   date||


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



[Bug other/38805] sed Unterminated `s' command

2009-01-12 Thread pinskia at gcc dot gnu dot org


--- Comment #3 from pinskia at gcc dot gnu dot org  2009-01-13 01:01 ---
for ac_var in `(set) 2>&1 |
   sed -n 's/^ac_env_\([a-zA-Z_0-9]*\)_set=.*/\1/p'`; do


-- 


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



[Bug other/38805] sed Unterminated `s' command

2009-01-12 Thread pinskia at gcc dot gnu dot org


--- Comment #2 from pinskia at gcc dot gnu dot org  2009-01-13 00:59 ---
How did you invoke configure?  How did you invoke GNU make?


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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



[Bug libfortran/38772] r143102 breaks xplor-nih

2009-01-12 Thread howarth at nitro dot med dot uc dot edu


--- Comment #12 from howarth at nitro dot med dot uc dot edu  2009-01-13 
00:55 ---
The attached badread,f test program produces...

 F

...when attempting to read a float with...

  READ(TEMP,'(F20.0)',ERR=) R

from

  TEMP='END'

when run against the libgfortran prior to r143102. After r143102, the
libgfortran results
in the output of

 T

which is means that we aren't properly handling error conditions in the
floating point read routines now.


-- 


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



[Bug bootstrap/38728] gcc 4.4.0 20090104 - "make install" is relinking `libgij.la'

2009-01-12 Thread pinskia at gcc dot gnu dot org


--- Comment #1 from pinskia at gcc dot gnu dot org  2009-01-13 00:54 ---
I have no idea why this happens for you but it works for me.


-- 


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



[Bug libfortran/38772] r143102 breaks xplor-nih

2009-01-12 Thread howarth at nitro dot med dot uc dot edu


--- Comment #11 from howarth at nitro dot med dot uc dot edu  2009-01-13 
00:52 ---
Created an attachment (id=17081)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17081&action=view)
test program demonstrating missing error condition


-- 


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



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

2009-01-12 Thread pinskia at gcc dot gnu dot org


--- Comment #5 from pinskia at gcc dot gnu dot org  2009-01-13 00:45 ---
# 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


-- 


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



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

2009-01-12 Thread pinskia at gcc dot gnu dot org


--- Comment #4 from pinskia at gcc dot gnu dot org  2009-01-13 00:45 ---
Hmm, automake should have done the correct thing ...


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|major   |normal


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



[Bug bootstrap/38743] libgcc multilib fails if not able to exec "non" native programs

2009-01-12 Thread pinskia at gcc dot gnu dot org


--- Comment #6 from pinskia at gcc dot gnu dot org  2009-01-13 00:42 ---
a patch like http://gcc.gnu.org/ml/gcc-patches/2007-06/msg00474.html is needed
for libgcc.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|gcc 4.4.0 20090106 - The|libgcc multilib fails if not
   |configure for   |able to exec "non" native
   |$BUILD/amd64/libgcc checks  |programs
   |if 64 bit code can exec on  |
   |32 bit platform |


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



[Bug awt/38803] [4.4 regression] Configure with "--enable-java-awt=x" requires Escher

2009-01-12 Thread pinskia at gcc dot gnu dot org


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||bug-classpath at gnu dot org
   Severity|major   |normal


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



[Bug bootstrap/38792] RFE - Need Makefile to build using different strategy for "coverage" vs. "profiling"

2009-01-12 Thread pinskia at gcc dot gnu dot org


--- Comment #3 from pinskia at gcc dot gnu dot org  2009-01-13 00:38 ---
Coverage builds should not be bootstrapped.

Profiled bootstrap means build stage1 with no opts and then stage2 with
generating the profiling data and then build some target libraries (not all
though) and the build stage3 using that generated profile data.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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



[Bug bootstrap/3415] make distclean (in gcc subdirectory) does not clean up all the way

2009-01-12 Thread pinskia at gcc dot gnu dot org


--- Comment #6 from pinskia at gcc dot gnu dot org  2009-01-13 00:36 ---
*** Bug 38800 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rob1weld at aol dot com


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



[Bug bootstrap/38800] gcc 4.4.0 20090109 - "make -i -k distclean" does not remove amd64/*/* fixincludes/* and /gnattools/*

2009-01-12 Thread pinskia at gcc dot gnu dot org


--- Comment #1 from pinskia at gcc dot gnu dot org  2009-01-13 00:36 ---
fixincludes is already registered as PR 25470. 

And really PR 3415 is the original bug for it.

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


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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



[Bug bootstrap/38776] gcc 4.4.0 20090109 - Configure with "--enable-coverage=noopt" breaks build

2009-01-12 Thread pinskia at gcc dot gnu dot org


--- Comment #6 from pinskia at gcc dot gnu dot org  2009-01-13 00:32 ---
You should not be bootstrapping a --enable-coverage=noopt build, you should
only need to build stage1 gcc.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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



[Bug bootstrap/38788] gcc 4.4.0 20090109 - Configure with "--enable-intermodule" breaks build

2009-01-12 Thread pinskia at gcc dot gnu dot org


--- Comment #7 from pinskia at gcc dot gnu dot org  2009-01-13 00:31 ---
Nobody builds using --enable-intermodule, it uses too much memory in general
anyways so closing as won't fix.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WONTFIX


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



[Bug bootstrap/38775] gcc 4.4.0 20090109 - The Makefile displays "profile" when using "--enable-coverage" (and not profiling)

2009-01-12 Thread pinskia at gcc dot gnu dot org


--- Comment #1 from pinskia at gcc dot gnu dot org  2009-01-13 00:28 ---
Well you don't understand any of these options it seems.
First --enable-coverage=nopt does nothing except changes the CFLAGS really.
There is nothing in the toplevel makefile or configure which uses 
--enable-coverage=, only the gcc subdirectory.  Also you should not be
bootstrapping a compiler built with --enable-coverage= really.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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



[Bug middle-end/33443] Compiler warnings in gcc sources

2009-01-12 Thread pinskia at gcc dot gnu dot org


--- Comment #2 from pinskia at gcc dot gnu dot org  2009-01-13 00:21 ---
*** Bug 38746 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rob1weld at aol dot com


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



[Bug bootstrap/38746] gcc 4.4.0 20090104 - Warnings during bootstrap about poor coding

2009-01-12 Thread pinskia at gcc dot gnu dot org


--- Comment #4 from pinskia at gcc dot gnu dot org  2009-01-13 00:21 ---


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


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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



[Bug libmudflap/38738] libmudflap could be enabled for Solaris when using GNU ld

2009-01-12 Thread pinskia at gcc dot gnu dot org


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |enhancement
  GCC build triplet|i386-pc-solaris2.11 |
   GCC host triplet|i386-pc-solaris2.11 |
 GCC target triplet|i386-pc-solaris2.11 |*-*-solaris*
Summary|gcc 4.4.0 20090104 -|libmudflap could be enabled
   |OpenSolaris can enable  |for Solaris when using GNU
   |libmudflaps (if gcc is  |ld
   |configured to use GNU ld)   |


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



[Bug bootstrap/26323] toplevel directories should be assocaited at the toplevel with a language being built instead of with a subdirectory of gcc

2009-01-12 Thread pinskia at gcc dot gnu dot org


--- Comment #4 from pinskia at gcc dot gnu dot org  2009-01-13 00:18 ---
>"Cannot build gnattools while gnatlib is out of date or unbuilt".


That bug is a different issue than this bug.  Please don't confuse the two.


-- 


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



[Bug bootstrap/26323] toplevel directories should be assocaited at the toplevel with a language being built instead of with a subdirectory of gcc

2009-01-12 Thread rob1weld at aol dot com


--- Comment #3 from rob1weld at aol dot com  2009-01-13 00:14 ---
In gcc version 4.4.0 20090111 (experimental) [trunk revision 143259] we have
the: "Cannot build gnattools while gnatlib is out of date or unbuilt" Bug.


# gmake clean-gcc
...
# gmake
...
gmake[4]: Leaving directory
`/usr/share/src/gcc_build/i386-pc-solaris2.11/libgcc'
g
...
gmake[5]: Entering directory `/usr/share/src/gcc_build/gcc'
gmake[5]: `ada/s-oscons.ads' is up to date.
gmake[5]: Leaving directory `/usr/share/src/gcc_build/gcc'
test -f stamp-libada || \
gmake -C ../../.././gcc/ada "MAKEOVERRIDES=" "LDFLAGS=-m64" "LN_S=ln
-s" "SHELL=/bin/sh" "GNATLIBFLAGS=-W -Wall -gnatpg -m64" "GNATLIBCFLAGS=-g -O2
-m64" "TARGET_LIBGCC2_CFLAGS=-fPIC" "THREAD_KIND=native" "TRACE=no"
"MULTISUBDIR=/amd64"
"libsubdir=/usr/local/lib/gcc/i386-pc-solaris2.11/4.4.0/amd64" "objext=.o"
"prefix=/usr/local" "exeext=.exeext.should.not.be.used "
'CC=the.host.compiler.should.not.be.needed'
"GCC_FOR_TARGET=/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" "CFLAGS=-g -O0 -fprofile-arcs
-ftest-coverage-m64 -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes" gnatlib-shared \
&& touch stamp-libada
true  DO=all multi-do # gmake
gmake[4]: Leaving directory
`/usr/share/src/gcc_build/i386-pc-solaris2.11/amd64/libada'
gmake[3]: Leaving directory
`/usr/share/src/gcc_build/i386-pc-solaris2.11/libada'
gmake[2]: Leaving directory
`/usr/share/src/gcc_build/i386-pc-solaris2.11/libada'
gmake[2]: Entering directory `/usr/share/src/gcc_build/gnattools'
rm -rf ../gcc/ada/tools
mkdir -p ../gcc/ada/tools
(cd ../gcc/ada/tools; ln -s ../sdefault.adb .)
rm -f ../gcc/ada/tools/mlib-tgt-specific.adb; ln -s
/usr/share/src/gcc_trunk/gcc/ada/mlib-tgt-specific-solaris.adb
../gcc/ada/tools/mlib-tgt-specific.adb;
touch ../gcc/stamp-tools
Cannot build gnattools while gnatlib is out of date or unbuilt
gmake[2]: *** [../gcc/stamp-gnatlib-rts] Error 1
gmake[2]: Leaving directory `/usr/share/src/gcc_build/gnattools'
gmake[1]: *** [all-gnattools] Error 2
gmake[1]: Leaving directory `/usr/share/src/gcc_build'
gmake: *** [all] Error 2


You may get this message; if you type:
# cd gcc_build/gcc/..
# make clean-gcc
# make
...
"Cannot build gnattools while gnatlib is out of date or unbuilt".

Rob


-- 


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



[Bug libstdc++/38384] fails to build cross gcc for target hppa64-hp-hpux11.00 in libstdc++/libmath

2009-01-12 Thread bkoz at gcc dot gnu dot org


--- Comment #18 from bkoz at gcc dot gnu dot org  2009-01-12 23:59 ---

Thanks for your help Dave: this should be fixed now. (FWIW, the 10.20 config is
correct, or mostly correct.) Still, it's nice to confirm.

Ranier, this should be working now. Can you try to cross-compile as before, but
with updated gcc sources? 


-- 

bkoz at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|WAITING


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



[Bug fortran/38810] Floating point exception

2009-01-12 Thread pinskia at gcc dot gnu dot org


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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



[Bug bootstrap/36815] gnattools related error when building only c and fortran

2009-01-12 Thread rob1weld at aol dot com


--- Comment #2 from rob1weld at aol dot com  2009-01-12 23:35 ---
(In reply to comment #0)
> With --enable-languages=c,fortran, system trys to build gnattools and fails
> with this error:
> ...
> Cannot build gnattools while gnatlib is out of date or unbuilt
> ...

That may occur if you use "make clean-gcc" (clean only the gcc directory)
and then try to type "make" afterwards. It should not harass you if the
language Ada was not even on the list. There is some fixing needed here.

Rob


-- 


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



[Bug c++/36019] [4.2/4.3/4.4 Regression] template parameter does not hide class name

2009-01-12 Thread jakub at gcc dot gnu dot org


--- Comment #9 from jakub at gcc dot gnu dot org  2009-01-12 23:00 ---
The 4.3 version seems to be the old one, with is_* prefixes and macro, while
trunk/4.2 are the new ones.


-- 


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



[Bug c++/36019] [4.2/4.3/4.4 Regression] template parameter does not hide class name

2009-01-12 Thread dodji at gcc dot gnu dot org


--- Comment #8 from dodji at gcc dot gnu dot org  2009-01-12 22:50 ---
Fixed in trunk, gcc-4_3 and gcc-4_2.


-- 

dodji at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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



[Bug c++/36019] [4.2/4.3/4.4 Regression] template parameter does not hide class name

2009-01-12 Thread dodji at gcc dot gnu dot org


--- Comment #7 from dodji at gcc dot gnu dot org  2009-01-12 22:48 ---
Subject: Bug 36019

Author: dodji
Date: Mon Jan 12 22:47:49 2009
New Revision: 143315

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143315
Log:
gcc/cp/ChangeLog:
2009-01-12  Dodji Seketeli  

PR c++/36019
* pt.c (parameter_of_template_p): New function.
* cp-tree.h: Declare it.
* name-lookup.c (binding_to_template_parms_of_scope_p): New
function.
(outer_binding): Take template parameters in account when looking for
a name binding.

gcc/testsuite/ChangeLog:
2009-01-12  Dodji Seketeli  

PR c++/36019
* g++.dg/lookup/hidden-class12.C: New test.
* g++.dg/lookup/hidden-class13.C: New test.
* g++.dg/lookup/hidden-class14.C: New test.
* g++.dg/lookup/hidden-class15.C: New test.
* g++.dg/lookup/hidden-class16.C: New test.


Added:
trunk/gcc/testsuite/g++.dg/lookup/hidden-class12.C
trunk/gcc/testsuite/g++.dg/lookup/hidden-class13.C
trunk/gcc/testsuite/g++.dg/lookup/hidden-class14.C
trunk/gcc/testsuite/g++.dg/lookup/hidden-class15.C
trunk/gcc/testsuite/g++.dg/lookup/hidden-class16.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/name-lookup.c
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog


-- 


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



[Bug c++/36019] [4.2/4.3/4.4 Regression] template parameter does not hide class name

2009-01-12 Thread dodji at gcc dot gnu dot org


--- Comment #6 from dodji at gcc dot gnu dot org  2009-01-12 22:44 ---
Subject: Bug 36019

Author: dodji
Date: Mon Jan 12 22:44:13 2009
New Revision: 143314

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143314
Log:
gcc/cp/ChangeLog:
2009-01-12  Dodji Seketeli  

PR c++/36019
* pt.c (parameter_of_template_p): New function.
* cp-tree.h: Declare it.
* name-lookup.c (binding_to_template_parms_of_scope_p): New
function.
(outer_binding): Take template parameters in account when looking for
a name binding.

gcc/testsuite/ChangeLog:
2009-01-12  Dodji Seketeli  

PR c++/36019
* g++.dg/lookup/hidden-class12.C: New test.
* g++.dg/lookup/hidden-class13.C: New test.
* g++.dg/lookup/hidden-class14.C: New test.
* g++.dg/lookup/hidden-class15.C: New test.
* g++.dg/lookup/hidden-class16.C: New test.
* gcc/testsuite/g++.old-deja/g++.benjamin/tem03.C: Adjust testcase.


Added:
branches/gcc-4_3-branch/gcc/testsuite/g++.dg/lookup/hidden-class12.C
branches/gcc-4_3-branch/gcc/testsuite/g++.dg/lookup/hidden-class13.C
branches/gcc-4_3-branch/gcc/testsuite/g++.dg/lookup/hidden-class14.C
branches/gcc-4_3-branch/gcc/testsuite/g++.dg/lookup/hidden-class15.C
branches/gcc-4_3-branch/gcc/testsuite/g++.dg/lookup/hidden-class16.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/name-lookup.c
branches/gcc-4_3-branch/gcc/cp/pt.c
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog
branches/gcc-4_3-branch/gcc/testsuite/g++.old-deja/g++.benjamin/tem03.C


-- 


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



[Bug c++/36019] [4.2/4.3/4.4 Regression] template parameter does not hide class name

2009-01-12 Thread dodji at gcc dot gnu dot org


--- Comment #5 from dodji at gcc dot gnu dot org  2009-01-12 22:41 ---
Subject: Bug 36019

Author: dodji
Date: Mon Jan 12 22:41:19 2009
New Revision: 143313

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143313
Log:
gcc/cp/ChangeLog:
2009-01-12  Dodji Seketeli  

PR c++/36019
* pt.c (parameter_of_template_p): New function.
* pt.c (get_template_info): Ditto.
* cp-tree.h: Declare those.
* name-lookup.c (binding_to_template_parms_of_scope_p): New
function.
(outer_binding): Take template parameters in account when looking for
a name binding.

gcc/testsuite/ChangeLog:
2009-01-12  Dodji Seketeli  

PR c++/36019
* g++.dg/lookup/hidden-class12.C: New test.
* g++.dg/lookup/hidden-class13.C: New test.
* g++.dg/lookup/hidden-class14.C: New test.
* g++.dg/lookup/hidden-class15.C: New test.
* g++.dg/lookup/hidden-class16.C: New test.
* gcc/testsuite/g++.old-deja/g++.benjamin/tem03.C: Adjust testcase.


Added:
branches/gcc-4_2-branch/gcc/testsuite/g++.dg/lookup/hidden-class12.C
branches/gcc-4_2-branch/gcc/testsuite/g++.dg/lookup/hidden-class13.C
branches/gcc-4_2-branch/gcc/testsuite/g++.dg/lookup/hidden-class14.C
branches/gcc-4_2-branch/gcc/testsuite/g++.dg/lookup/hidden-class15.C
branches/gcc-4_2-branch/gcc/testsuite/g++.dg/lookup/hidden-class16.C
Modified:
branches/gcc-4_2-branch/gcc/cp/ChangeLog
branches/gcc-4_2-branch/gcc/cp/cp-tree.h
branches/gcc-4_2-branch/gcc/cp/name-lookup.c
branches/gcc-4_2-branch/gcc/cp/pt.c
branches/gcc-4_2-branch/gcc/testsuite/ChangeLog
branches/gcc-4_2-branch/gcc/testsuite/g++.old-deja/g++.benjamin/tem03.C


-- 


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



[Bug middle-end/38817] GCC wrongly optimize a modulo operation.

2009-01-12 Thread jlerouge at apple dot com


--- Comment #2 from jlerouge at apple dot com  2009-01-12 22:22 ---
Verified fixed with 4.3.3.


-- 

jlerouge at apple dot com changed:

   What|Removed |Added

 Status|RESOLVED|VERIFIED


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



[Bug c++/38818] C++ bitfield static initialisation problem

2009-01-12 Thread john dot spelis at 3dlabs dot com


--- Comment #2 from john dot spelis at 3dlabs dot com  2009-01-12 22:16 
---
Subject: Re:  C++ bitfield static initialisation problem


Thank you.
(I'm suitably humbled).
Cheers


On 12 Jan 2009, pinskia at gcc dot gnu dot org wrote:

> 
> 
> --- Comment #1 from pinskia at gcc dot gnu dot org  2009-01-12 21:37 
> ---
> *(unsigned long *)this=l;
> 
> You are violating C/C++ aliasing rules which invokes undefined behavior as you
> are accessing a giChannelTiming as a unsigned long.
> 
> Either use -fno-strict-aliasing or memcpy or unions or the attribute may_alias
> to fix your code
> 
> 
> -- 
> 
> pinskia at gcc dot gnu dot org changed:
> 
>What|Removed |Added
> 
>  Status|UNCONFIRMED |RESOLVED
>  Resolution||INVALID
> 
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38818
> 
> --- You are receiving this mail because: ---
> You reported the bug, or are watching the reporter.
> 


-- 


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



[Bug target/38811] [4.4 Regression] internal compiler error: in compensate_edge, at reg-stack.c:2754

2009-01-12 Thread vmakarov at redhat dot com


--- Comment #6 from vmakarov at redhat dot com  2009-01-12 22:12 ---
Yes, it is an IRA bug.  Code processing calls to functions can throw is
lost in IRA.

I'll submit a patch tomorrow.


-- 


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



[Bug middle-end/36548] [4.3 Regression] remainder gives the wrong result for wrapping case with unsigned types

2009-01-12 Thread pinskia at gcc dot gnu dot org


--- Comment #11 from pinskia at gcc dot gnu dot org  2009-01-12 21:56 
---
*** Bug 38817 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jlerouge at apple dot com


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



[Bug middle-end/38817] GCC wrongly optimize a modulo operation.

2009-01-12 Thread pinskia at gcc dot gnu dot org


--- Comment #1 from pinskia at gcc dot gnu dot org  2009-01-12 21:56 ---
This was fixed for 4.3.3 by the patch for PR 36548.

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


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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



[Bug tree-optimization/38515] Disabling PPL/CLOOG with configure does not work

2009-01-12 Thread spop at gcc dot gnu dot org


--- Comment #2 from spop at gcc dot gnu dot org  2009-01-12 21:38 ---
Fixed.


-- 

spop at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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



[Bug c++/38818] C++ bitfield static initialisation problem

2009-01-12 Thread pinskia at gcc dot gnu dot org


--- Comment #1 from pinskia at gcc dot gnu dot org  2009-01-12 21:37 ---
*(unsigned long *)this=l;

You are violating C/C++ aliasing rules which invokes undefined behavior as you
are accessing a giChannelTiming as a unsigned long.

Either use -fno-strict-aliasing or memcpy or unions or the attribute may_alias
to fix your code


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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



[Bug tree-optimization/38515] Disabling PPL/CLOOG with configure does not work

2009-01-12 Thread spop at gcc dot gnu dot org


--- Comment #1 from spop at gcc dot gnu dot org  2009-01-12 21:37 ---
Subject: Bug 38515

Author: spop
Date: Mon Jan 12 21:36:58 2009
New Revision: 143311

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143311
Log:
2009-01-12  Sebastian Pop 

PR tree-optimization/38515
* configure.ac (cloog-polylib): Removed.
(with_ppl, with_cloog): Test for "no".
* configure: Regenerated.


Modified:
trunk/ChangeLog
trunk/configure
trunk/configure.ac


-- 


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



[Bug libstdc++/36801] config/cpu/generic/atomicity_mutex/atomicity.h incorrectly relies on global constructor ordering

2009-01-12 Thread bkoz at gcc dot gnu dot org


--- Comment #18 from bkoz at gcc dot gnu dot org  2009-01-12 21:36 ---

fixed for 4.4.x/4.3.x


-- 

bkoz at gcc dot gnu dot org changed:

   What|Removed |Added

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


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



[Bug libstdc++/36801] config/cpu/generic/atomicity_mutex/atomicity.h incorrectly relies on global constructor ordering

2009-01-12 Thread bkoz at gcc dot gnu dot org


--- Comment #17 from bkoz at gcc dot gnu dot org  2009-01-12 21:32 ---
Subject: Bug 36801

Author: bkoz
Date: Mon Jan 12 21:32:19 2009
New Revision: 143310

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143310
Log:
2009-01-12  Benjamin Kosnik  
Jonathan Larmour  

PR libstdc++/36801
* config/cpu/generic/atomicity_mutex/atomicity.h (get_atomic_mutex):
New.
(__gnu_cxx::__exchange_and_add): Use it.
* src/debug.cc (get_safe_base_mutex): New.
* src/locale.cc (get_locale_cache_mutex): New.
* src/mt_allocator.cc (get_freelist): New.
(get_freelist_mutex): New.
* src/pool_allocator.cc (get_palloc_mutex): New.

2009-01-12  Jonathan Larmour  

* include/ext/concurrence.h: Fix __gthread_cond_t initialisation
function macro name.


Modified:
branches/gcc-4_3-branch/libstdc++-v3/ChangeLog
   
branches/gcc-4_3-branch/libstdc++-v3/config/cpu/generic/atomicity_mutex/atomicity.h
branches/gcc-4_3-branch/libstdc++-v3/include/ext/concurrence.h
branches/gcc-4_3-branch/libstdc++-v3/src/debug.cc
branches/gcc-4_3-branch/libstdc++-v3/src/locale.cc
branches/gcc-4_3-branch/libstdc++-v3/src/mt_allocator.cc
branches/gcc-4_3-branch/libstdc++-v3/src/pool_allocator.cc


-- 


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



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

2009-01-12 Thread jason at gcc dot gnu dot org


--- Comment #13 from jason at gcc dot gnu dot org  2009-01-12 21:07 ---
Subject: Bug 31488

Author: jason
Date: Mon Jan 12 21:07:46 2009
New Revision: 143308

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143308
Log:
PR c++/31488
* tree.c (pod_type_p): Return 1 for structs created by the back end.

Added:
trunk/gcc/testsuite/g++.dg/other/vararg-3.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/tree.c
trunk/gcc/testsuite/ChangeLog


-- 


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



[Bug libstdc++/36801] config/cpu/generic/atomicity_mutex/atomicity.h incorrectly relies on global constructor ordering

2009-01-12 Thread bkoz at gcc dot gnu dot org


--- Comment #16 from bkoz at gcc dot gnu dot org  2009-01-12 20:57 ---
Created an attachment (id=17080)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17080&action=view)
for gcc-4_3-branch


-- 


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



[Bug tree-optimization/38819] New: [4.2/4.3/4.4 Regression] trapping expression wrongly hoisted out of loop

2009-01-12 Thread jsm28 at gcc dot gnu dot org
The following test wrongly fails with a floating point exception (division
by integer 0) when built with -O2 for i686-pc-linux-gnu.  Based on an
example posted by Robert Seacord to the WG14 reflector.  It works with 3.4 and
earlier, fails with 4.0 and later.  The % operation may trap if it is % 0
(or INT_MIN % -1, cf bug 30484 and another recent reflector discussion
suggesting INT_MIN % -1 should in fact be undefined in ISO C), so cannot be
hoisted above the loop unless it is guaranteed to be executed at least once.

extern void exit (int);
extern void abort (void);

volatile int a = 1;
volatile int b = 0;
volatile int x = 2;
volatile signed int r = 8;

void __attribute__((noinline))
foo (void)
{
  exit (0);
}

int
main (void)
{
  int si1 = a;
  int si2 = b;
  int i;

  for (i = 0; i < 100; ++i) {
foo ();
if (x == 8)
  i++;
r += i + si1 % si2;
  }
  abort ();
}


-- 
   Summary: [4.2/4.3/4.4 Regression] trapping expression wrongly
hoisted out of loop
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jsm28 at gcc dot gnu dot org


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



[Bug c++/38818] New: C++ bitfield static initialisation problem

2009-01-12 Thread john dot spelis at 3dlabs dot com
The following program seems to show a
compiler bug on x86 using 4.3.2 compilers

The correct output should be;

  giChannelTiming0.Setup 0xff
  giChannelTiming0.Recover 0xff00

which occurs only when no optimiser or -O is used.

When -O2 or greater is used the mask's are incorrectly
computed and print as 0.

It is known also not to work on 4.1.2 compilers.

It works perfectly with all optimisation levels on 3.2.3
compilers.

/*  */

#include 
#include 

typedef struct giChannelTiming {
#if BYTE_ORDER == BIG_ENDIAN
  /* Bits 24..31 */ unsigned Recover : 8 ;
  /* Bits 16..23 */ unsigned Hold : 8 ;
  /* Bits  8..15 */ unsigned Pulse : 8 ;
  /* Bits  0.. 7 */ unsigned Setup : 8 ;
#else
  /* Bits  0.. 7 */ unsigned Setup : 8 ;
  /* Bits  8..15 */ unsigned Pulse : 8 ;
  /* Bits 16..23 */ unsigned Hold : 8 ;
  /* Bits 24..31 */ unsigned Recover : 8 ;
#endif

 giChannelTiming(long l = 0) { *(unsigned long *)this=l; }
 operator unsigned long *(void) { return((unsigned long *)this) ; }
 operator unsigned long (void) { return(*(unsigned long *)this) ; }
} t_giChannelTiming ;

#define FIO_LOCATED(n) 0
#define ID_GEN_giChannelTiming0Setup 0
#define ID_GEN_giChannelTiming0Recover 0

#define GI_REG_F(field,reg) { #reg "." #field, ID_GEN_##reg##field, \
   { FIO_LOCATED(reg), (gr.reg=0, gr.reg.field =~0, (unsigned long)gr.reg)}}

struct gen_registers {
 t_giChannelTiming giChannelTiming0;
} ;

static gen_registers gr ;

struct regs {
  const char *name ;
  int id ;
  struct masks {
  int locn ;
  unsigned long mask ;
  } s ;
} r[] = {
GI_REG_F(Setup, giChannelTiming0),
GI_REG_F(Recover, giChannelTiming0)
} ;

main() {
 printf("%s 0x%lx\n", r[0].name, r[0].s.mask);
 printf("%s 0x%lx\n", r[1].name, r[1].s.mask);
}

/* - */


-- 
   Summary: C++ bitfield static initialisation problem
   Product: gcc
   Version: 4.3.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: john dot spelis at 3dlabs dot com
 GCC build triplet: i386-redhat-linux
  GCC host triplet: i386-redhat-linux
GCC target triplet: i386-redhat-linux


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



[Bug target/29141] static constructors beyond 64k fail

2009-01-12 Thread aesok at gcc dot gnu dot org


--- Comment #5 from aesok at gcc dot gnu dot org  2009-01-12 20:42 ---
Subject: Bug 29141

Author: aesok
Date: Mon Jan 12 20:41:57 2009
New Revision: 143306

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143306
Log:
PR target/29141
* config/avr/t-avr (LIB1ASMFUNCS): Add _tablejump_elpm.
* config/avr/libgcc.S (__do_global_ctors, __do_global_dtors): Add
variant for devices with 3-byte PC.
(__tablejump_elpm__) : New.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/avr/libgcc.S
trunk/gcc/config/avr/t-avr


-- 


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



[Bug middle-end/38808] another warning from system headers.

2009-01-12 Thread pinskia at gcc dot gnu dot org


--- Comment #3 from pinskia at gcc dot gnu dot org  2009-01-12 20:28 ---
Well for -m32/-m64 case, it might be difference in 32bit vs 64bit conversions
:).


-- 


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



[Bug target/4605] [alpha-osf]mips-tfile & spaced directory names

2009-01-12 Thread markus dot schoepflin at comsoft dot de


--- Comment #14 from markus dot schoepflin at comsoft dot de  2009-01-12 
20:01 ---
Just to recap what I think the problem is:

1) cc1 compiles the C file and creates input for the system assembler. The
assembler source is placed into the /tmp directory.

2) The system assembler is called to create the object file "dir test/hello.o"
from the assembler source file in /tmp. The system assembler can't deal with
the space character in the location of the object file and instead creates an
object file called "dir" in the current directory.

3) mips-tfile is called to add debugging information to the object file in "dir
test/hello.o" but there is no such file, because the system assembler didn't
create it, and mips-tfile complains correctly that there is no such file.

Does that sound about right?


-- 


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



[Bug target/4605] [alpha-osf]mips-tfile & spaced directory names

2009-01-12 Thread markus dot schoepflin at comsoft dot de


--- Comment #13 from markus dot schoepflin at comsoft dot de  2009-01-12 
19:51 ---
Strange, I seem to get something different on Linux with gcc 4.3.2:

~/src/tests/gcc/PR4605$ gcc -v -c hello.c -o "./dir test/hello.o"
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.3.2-1ubuntu11'
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3
--program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug
--enable-objc-gc --enable-mpfr --enable-targets=all --enable-checking=release
--build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.3.2 (Ubuntu 4.3.2-1ubuntu11) 
COLLECT_GCC_OPTIONS='-v' '-c' '-o' './dir test/hello.o' '-mtune=generic'
 /usr/lib/gcc/i486-linux-gnu/4.3.2/cc1 -quiet -v hello.c -D_FORTIFY_SOURCE=2
-quiet -dumpbase hello.c -mtune=generic -auxbase-strip ./dir test/hello.o
-version -fstack-protector -o /tmp/cciLVmZP.s
ignoring nonexistent directory "/usr/local/include/i486-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/i486-linux-gnu/4.3.2/../../../../i486-linux-gnu/include"
ignoring nonexistent directory "/usr/include/i486-linux-gnu"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include
 /usr/lib/gcc/i486-linux-gnu/4.3.2/include
 /usr/lib/gcc/i486-linux-gnu/4.3.2/include-fixed
 /usr/include
End of search list.
GNU C (Ubuntu 4.3.2-1ubuntu11) version 4.3.2 (i486-linux-gnu)
compiled by GNU C version 4.3.2, GMP version 4.2.2, MPFR version 2.3.2.
GGC heuristics: --param ggc-min-expand=42 --param ggc-min-heapsize=23711
Compiler executable checksum: fbed29247d8ae538bfd0dd565a17225f
COLLECT_GCC_OPTIONS='-v' '-c' '-o' './dir test/hello.o' '-mtune=generic'
 as -V -Qy -o ./dir test/hello.o /tmp/cciLVmZP.s
GNU assembler version 2.18.93 (i486-linux-gnu) using BFD version (GNU Binutils
for Ubuntu) 2.18.93.20081009
COMPILER_PATH=/usr/lib/gcc/i486-linux-gnu/4.3.2/:/usr/lib/gcc/i486-linux-gnu/4.3.2/:/usr/lib/gcc/i486-linux-gnu/:/usr/lib/gcc/i486-linux-gnu/4.3.2/:/usr/lib/gcc/i486-linux-gnu/:/usr/lib/gcc/i486-linux-gnu/4.3.2/:/usr/lib/gcc/i486-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/i486-linux-gnu/4.3.2/:/usr/lib/gcc/i486-linux-gnu/4.3.2/:/usr/lib/gcc/i486-linux-gnu/4.3.2/../../../../lib/:/lib/../lib/:/usr/lib/../lib/:/usr/lib/gcc/i486-linux-gnu/4.3.2/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-c' '-o' './dir test/hello.o' '-mtune=generic'


-- 


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



[Bug c/32041] [4.3 Regression] offsetof buglet

2009-01-12 Thread jakub at gcc dot gnu dot org


--- Comment #5 from jakub at gcc dot gnu dot org  2009-01-12 19:45 ---
Fixed on the trunk so far.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to fail|4.0.1 4.3.0 4.4.0   |4.0.1 4.3.0
  Known to work|3.3 |3.3 4.4.0
Summary|[4.3/4.4 Regression]|[4.3 Regression] offsetof
   |offsetof buglet |buglet


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



[Bug c/32041] [4.3/4.4 Regression] offsetof buglet

2009-01-12 Thread jakub at gcc dot gnu dot org


--- Comment #4 from jakub at gcc dot gnu dot org  2009-01-12 19:44 ---
Subject: Bug 32041

Author: jakub
Date: Mon Jan 12 19:44:33 2009
New Revision: 143305

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143305
Log:
PR c/32041
* c-parser.c (c_parser_postfix_expression): Allow `->' in
offsetof member-designator, handle it as `[0].'.

* parser.c (cp_parser_builtin_offsetof): Allow `->' in
offsetof member-designator, handle it as `[0].'.

* gcc.dg/pr32041.c: New test.
* g++.dg/parse/offsetof9.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/parse/offsetof9.C
trunk/gcc/testsuite/gcc.dg/pr32041.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-parser.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog


-- 


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



[Bug gcov-profile/38784] gcc 4.4.0 20090109 - Naming xgcc.* gcc.* when configure with "--enable-coverage=noopt"

2009-01-12 Thread pinskia at gcc dot gnu dot org


--- Comment #4 from pinskia at gcc dot gnu dot org  2009-01-12 19:29 ---
(In reply to comment #3)
> That is what I am saying. There should be an exclusion for that one file only.

Why?  this is what should be done and how this has been implemented for a long
time.  

-fprofile-arcs does not enable gmon profiling,  It enables exact profiling of
basic block edges and nothing more.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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



[Bug tree-optimization/38816] New: [4.4 Regression] graphite undocumented

2009-01-12 Thread rob1weld at aol dot com
+++ This bug was initially created as a clone of Bug #38465 +++

For 4.4, "info -f /usr/local/info/gccint.info -n Passes" needs to document
the 'Graphite Pass' in the "Passes" section. At minimum a link to a Doc.


-- 
   Summary: [4.4 Regression] graphite undocumented
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rob1weld at aol dot com


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



[Bug c/38817] New: GCC wrongly optimize a modulo operation.

2009-01-12 Thread jlerouge at apple dot com
The following code seems to be wrongly optimized by GCC:

int main(int argc, char **argv) {
   unsigned int foo = 3;
   return ((838237499u * foo - 2137600414u) % 11u);
}

always return 0 on my machine, it should return 7. GCC seems to be optimizing
the modulo operation (even with -O0).

GCC version:
debian:~ $ gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr
--disable-libmudflap --enable-targets=all --enable-checking=release
--build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.2.3 (Debian 4.2.3-1)

Command line used:
debian:~ $ gcc -o t t.c

Thanks,
Julien


-- 
   Summary: GCC wrongly optimize a modulo operation.
   Product: gcc
   Version: 4.2.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jlerouge at apple dot com
 GCC build triplet: i486-linux-gnu
  GCC host triplet: i486-linux-gnu
GCC target triplet: i486-linux-gnu


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



[Bug tree-optimization/38401] TreeSSA-PRE load after store missed optimization

2009-01-12 Thread amylaar at gcc dot gnu dot org


--- Comment #18 from amylaar at gcc dot gnu dot org  2009-01-12 18:09 
---
(In reply to comment #17)
> I think enabling partial PRE to do it is appropriate (with at most inserting
> on one edge).

I think the abstraction with tree-ssa and cfglayout mode has gone too far.
We no longer have visibility of the costs of branches, or of opportunities
for conditional execution.
I suspect that the 35% speed regressions we see on EEMBC fbital at -O3 are
also to blame on overzealous tree-pre partial-partial redundancy eliminations.


-- 


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




[Bug inline-asm/38815] Taking the address of a __thread variable prevents the r0 register from being loaded

2009-01-12 Thread gilles dot chanteperdrix at xenomai dot org


--- Comment #1 from gilles dot chanteperdrix at xenomai dot org  2009-01-12 
18:03 ---
The following code:

__thread long tl = 42;

long f(void)
{
long *l = &tl;
register long r0 __asm__ ("r0");
register long *r1 __asm__ ("r1");
r0 = 23;
r1 = l;
__asm__ __volatile__ ("": "+r"(r0) : "r"(r1));
return r0;
}

When compiled with -O2, gives the followin assembly code:

f:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
ldr r1, .L3
str lr, [sp, #-4]!
bl  __aeabi_read_tp @ load_tp_soft
add r1, r0, r1
ldr pc, [sp], #4

Where we see that the r0 register is never loaded with 23 as it should.


-- 


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



[Bug rtl-optimization/38740] [4.4 Regression] Incorrect delayed branch optimization

2009-01-12 Thread dave at hiauly1 dot hia dot nrc dot ca


--- Comment #9 from dave at hiauly1 dot hia dot nrc dot ca  2009-01-12 
18:01 ---
Subject: Re:  [4.4 Regression] Incorrect delayed branch optimization

> I've been building parts of glibc's vfprintf code with -fno-delayed-branch for
> hppa because of bugs in DBR. I never filed a bug because it was almost
> impossible for me to reduce the vfprintf code (large file, large tables, long
> jumps).

I would guess that this particular regression has something to do with
the new register allocator.

The general problem mentioned by Richard Sandiford

  dbr_schedule is the only user of resource.c, which is based
  on this horrible hack of assuming that, although the basic block
  information is no longer up-to-date, we can still rely on the live
  register sets before BARRIERs.  We also assume that we can rely on
  REG_DEAD notes to some extent: if a register is marked dead by a
  REG_DEAD note, and isn't set again before the next label, we assume
  it really is dead at the label.

is more serious.  The delayed branch optimisation is run at all levels.
So, the generated code may be wrong if a user doesn't specify
-fno-delayed-branch.

As this problem affects more than the PA, possibly the priority of this
report should be increased.

Dave


-- 


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



[Bug inline-asm/38815] New: Taking the address of a __thread variable prevents the r0 register from being loaded

2009-01-12 Thread gilles dot chanteperdrix at xenomai dot org



-- 
   Summary: Taking the address of a __thread variable prevents the
r0 register from being loaded
   Product: gcc
   Version: 4.2.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: inline-asm
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gilles dot chanteperdrix at xenomai dot org
GCC target triplet: armeb-unknown-linux-gnueabi


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



[Bug middle-end/38814] valgrind returns Invalid write in reserve_phi_args_for_new_edge

2009-01-12 Thread jv244 at cam dot ac dot uk


--- Comment #1 from jv244 at cam dot ac dot uk  2009-01-12 17:39 ---
things really have a random flavor right now. I have a bt for a segfault from
gdb, within a couple of minutes now:

[ repeats about 4000 times]
#4011 0x0049267d in gt_ggc_mx_lang_tree_node (x_p=) at ./gt-fortran-f95-lang.h:213
#4012 0x004921bf in gt_ggc_mx_lang_tree_node (x_p=) at ./gt-fortran-f95-lang.h:315
#4013 0x004921b1 in gt_ggc_mx_lang_tree_node (x_p=) at ./gt-fortran-f95-lang.h:314
#4014 0x00491d51 in gt_ggc_mx_lang_tree_node (x_p=) at ./gt-fortran-f95-lang.h:471
#4015 0x004921bf in gt_ggc_mx_lang_tree_node (x_p=) at ./gt-fortran-f95-lang.h:315
#4016 0x004922f1 in gt_ggc_mx_lang_tree_node (x_p=) at ./gt-fortran-f95-lang.h:291
#4017 0x0065d145 in gt_ggc_mx_cgraph_node (x_p=)
at gtype-desc.c:171
#4018 0x0065d276 in gt_ggc_m_P11cgraph_node4htab (x_p=) at gtype-desc.c:2077
#4019 0x00628fbe in ggc_mark_roots () at
/data03/vondele/gcc_trunk/gcc/gcc/ggc-common.c:107
#4020 0x004dad48 in ggc_collect () at
/data03/vondele/gcc_trunk/gcc/gcc/ggc-page.c:1941

#4021 0x0069f115 in execute_todo (flags=34871) at
/data03/vondele/gcc_trunk/gcc/gcc/passes.c:1047
#4022 0x0069f385 in execute_one_pass (pass=0x10f4da0) at
/data03/vondele/gcc_trunk/gcc/gcc/passes.c:1302
#4023 0x0069f575 in execute_pass_list (pass=0x10f4da0) at
/data03/vondele/gcc_trunk/gcc/gcc/passes.c:1328
#4024 0x0069f58d in execute_pass_list (pass=0x10f4860) at
/data03/vondele/gcc_trunk/gcc/gcc/passes.c:1329
#4025 0x0069f895 in execute_ipa_pass_list (pass=0x10f4800) at
/data03/vondele/gcc_trunk/gcc/gcc/passes.c:892
#4026 0x00917ca6 in cgraph_optimize () at
/data03/vondele/gcc_trunk/gcc/gcc/cgraphunit.c:1239
#4027 0x00490855 in gfc_be_parse_file (set_yydebug=)
at /data03/vondele/gcc_trunk/gcc/gcc/fortran/f95-lang.c:240

#4028 0x00746605 in toplev_main (argc=,
argv=)
at /data03/vondele/gcc_trunk/gcc/gcc/toplev.c:970
#4029 0x7f7d53f33436 in __libc_start_main () from /lib64/libc.so.6
---Type  to continue, or q  to quit---
#4030 0x00405859 in _start ()
(gdb)

BTW, gcc from 2009-01-09 did not seem to display this issue.


-- 


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



[Bug libgcj/38396] [4.3 Regression] ecj1 linked against both -lgcj and -lgcj_bc

2009-01-12 Thread aph at gcc dot gnu dot org


--- Comment #24 from aph at gcc dot gnu dot org  2009-01-12 17:36 ---
Subject: Bug 38396

Author: aph
Date: Mon Jan 12 17:35:48 2009
New Revision: 143301

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143301
Log:
2009-01-12  Andrew Haley  

PR libgcj/38396:
* libgcj_bc.c: Sort lines.
*(_Jv_LookupInterfaceMethod, _Jv_MonitorExit,
_Jv_RegisterResource, _Jv_JNI_PopSystemFrame): Add.

* sun/misc/natUnsafe.cc (spinlock contructor): Call sched_yield().

Modified:
branches/gcc-4_3-branch/libjava/ChangeLog
branches/gcc-4_3-branch/libjava/libgcj_bc.c
branches/gcc-4_3-branch/libjava/sun/misc/natUnsafe.cc


-- 


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



[Bug target/38811] [4.4 Regression] internal compiler error: in compensate_edge, at reg-stack.c:2754

2009-01-12 Thread hjl dot tools at gmail dot com


--- Comment #5 from hjl dot tools at gmail dot com  2009-01-12 17:27 ---
Is this an IRA bug?


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 CC||vmakarov at redhat dot com


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



[Bug fortran/38813] ICE with C_LOC(array)

2009-01-12 Thread burnus at gcc dot gnu dot org


--- Comment #2 from burnus at gcc dot gnu dot org  2009-01-12 16:59 ---
For the diagnostics: I think it works, but we are checking in case of
C_LOC(Type%Comp)  the symbol Type instead of Comp. Assume that Type is a
pointer and Comp is not then "gfc_is_data_pointer()" returns true for Type%Comp
even though it is not a pointer (Type is a pointer, Type%Comp is the component
of the target to which Type points). But somehow also the is_scalar_expr_ptr
check and the args_sym->attr.dimension check point do something wrong.

For rejects valid: Make "Type" a pointer and Type%Comp an array.

The ICE itself is fixed by the following patch:

--- trans-expr.c(Revision 143289)
+++ trans-expr.c
@@ -2451 +2451 @@ gfc_conv_function_call (gfc_se * se, gfc
-   && fsym->as->type != AS_ASSUMED_SHAPE;
+   && fsym->as && fsym->as->type != AS_ASSUMED_SHAPE;


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||rejects-valid


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



[Bug fortran/38810] Floating point exception

2009-01-12 Thread burnus at gcc dot gnu dot org


--- Comment #2 from burnus at gcc dot gnu dot org  2009-01-12 16:39 ---
For quick reading, skip next part and continue below the * * *.
---
I think this applies still (at least partially) as libgfortran/config/fpu*.h's
set_cpu() still has the line. For GLIBC one finds:

/* glibc does never have a FE_DENORMAL.  */
  if (options.fpe & GFC_FPE_DENORMAL)
#ifdef FE_DENORMAL
feenableexcept (FE_DENORMAL);
#else
st_printf ("Fortran runtime warning: IEEE 'denormal number' "
   "exception not supported.\n");
#endif

NOTE: The FE_* are defined in the system's fenv.h file and POSIX (SUSv3) does
not specify FE_DENORMAL only: FE_DIVBYZERO, FE_INEXACT, FE_INVALID, FE_OVERFLOW
and FE_UNDERFLOW. And also on my system (glibc-devel-2.9-4.18) fenv.h does not
have FE_DENORMAL.

However, fpu-387.h has support for it:

  if (options.fpe & GFC_FPE_DENORMAL) cw &= ~_FPU_MASK_DM;
[...]
  if (has_sse())
[...]
  if (options.fpe & GFC_FPE_DENORMAL) cw_sse &= ~(_FPU_MASK_DM << 7);

Thus the question is whether for "linux (i686) release" the fpu-387.h should
have been applied instead?

 * * *

For the reported problem:

> gives the message "Fortran runtime warning: IEEE 'denormal number' exception 
> not supported" without the compiler option -ffpe-trap.

It does not make sense that the message is printed without -ffpe-trap=. I don't
see how this could happen (with the current code).

> The program directly crashed with a floating point exception

I some doubt that the FPE crash is related to denormal numbers as they are
usually handled gracefully and are not serious. Especially since the warning
explicitly states that they are not supported for trapping. For the crash it is
extremely unlikely that it happens while printing the warning message.

> I tried to find the error in the debugger kdbg, but before the first 
> executable statement was passed the program stopped with the floating point 
> error.

There is a serious lack of information here - for instance you are missing the
compiler options. Stab into the dark: You are not using by chance
-malign-double or -mno-align-double? If you do, please remove it! (If you
don't, don't use it.)

We need:
1. If possible a minimal program which shows the bug, seemingly something like
 print *, 'Hello World'
 end
   is enough if the crash happens before the actual program is executed
2. The exact command line used to compile the program
3. More information about the compiler, i.e. my 4.1 compiler shows:
 gcc version 4.1.3 20080612 (prerelease) (SUSE Linux)
 Target: x86_64-suse-linux
   What does yours show for "gfortran -v"?

And best is to update to a newer gfortran version. 4.1.x is pretty old and the
4.1.x series is no longer maintained. 4.3.x and the currently developed 4.4 are
maintained (and 4.2.x is still maintained for a couple of weeks). Thus it would
be best if you could update to 4.3.x or 4.4.

As Daniel mentioned: Build instruction and pre-build binaries are available at
http://gcc.gnu.org/wiki/GFortranBinaries


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |UNCONFIRMED


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



[Bug middle-end/38814] New: valgrind returns Invalid write in reserve_phi_args_for_new_edge

2009-01-12 Thread jv244 at cam dot ac dot uk
version used for testing:

GNU Fortran (GCC) version 4.4.0 20090112 (experimental) [trunk revision 143288]
(x86_64-unknown-linux-gnu)
compiled by GNU C version 4.4.0 20090112 (experimental) [trunk revision
143288], GMP version 4.2.2, MPFR version 2.3.1.


valgrind --tool=memcheck
/data03/vondele/gcc_trunk/build/libexec/gcc/x86_64-unknown-linux-gnu/4.4.0/f951
all.f90 -march=k8-sse3 -mcx16 -msahf --param l1-cache-size=64 --param
l1-cache-line-size=64 --param l2-cache-size=1024 -mtune=k8 -quiet -dumpbase
all.f90 -auxbase all -O3 -version -ffast-math -ftree-vectorize -ffree-form
-fintrinsic-modules-path
/data03/vondele/gcc_trunk/build/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/finclude
-o /tmp/ccIEjF0W.s

==22900==
==22900== Invalid write of size 8
==22900==at 0x7A028D: reserve_phi_args_for_new_edge
(tree-flow-inline.h:299)
==22900==by 0xAE0332: redirect_edge_succ_nodup (cfg.c:410)
==22900==by 0x751AC0: gimple_redirect_edge_and_branch (tree-cfg.c:4801)
==22900==by 0xAF0479: redirect_edge_and_branch (cfghooks.c:323)
==22900==by 0x75CFBC: cleanup_tree_cfg_bb (tree-cfgcleanup.c:413)
==22900==by 0x75D71C: cleanup_tree_cfg (tree-cfgcleanup.c:594)
==22900==by 0x69EE44: execute_function_todo (passes.c:923)
==22900==by 0x69F06E: execute_todo (passes.c:1025)
==22900==by 0x69F384: execute_one_pass (passes.c:1302)
==22900==by 0x69F574: execute_pass_list (passes.c:1328)
==22900==by 0x69F58C: execute_pass_list (passes.c:1329)
==22900==by 0x69F58C: execute_pass_list (passes.c:1329)
==22900==  Address 0x20008 is not stack'd, malloc'd or (recently) free'd
all.f90: In function ‘build_se_core_matrix’:
all.f90:364860: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

the testcase is all.f90 in
http://www.pci.unizh.ch/vandevondele/tmp/CP2K_gcc_2007_06.tgz (see also comment
#112 in PR29975). 

which unfortunately means it takes a couple of hours to reproduce through
valgrind. I started the valgrinded compilation after having a segfault with a
normal compilation that I couldn't reproduce in gdb. The latter really is a bit
strange, just testing it again, segfaults out of gdb, doesn't segfault within
gdb..


-- 
   Summary: valgrind returns Invalid write in
reserve_phi_args_for_new_edge
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk


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



[Bug fortran/34955] transfer_assumed_size_1.f90: Valgrind error: invalid read of size 3

2009-01-12 Thread pault at gcc dot gnu dot org


--- Comment #20 from pault at gcc dot gnu dot org  2009-01-12 16:20 ---
Created an attachment (id=17079)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17079&action=view)
A preliminary patch for the PR

A slightly earlier version of this regtested OK.  Will do it to this version
tonight and then will submit.

Cheers

Paul


-- 


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



[Bug rtl-optimization/38245] [4.4 Regression] stack corruption when a call is removed but not the outgoing argument pushes

2009-01-12 Thread jakub at gcc dot gnu dot org


--- Comment #21 from jakub at gcc dot gnu dot org  2009-01-12 16:18 ---
Created an attachment (id=17078)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17078&action=view)
gcc44-pr38245.patch

Patch I'm playing with.  I don't see why changing CALL_INSN_FUNCTION_USAGE
to have only at most word sized stores would simplify it much.  The patch
is still overly conservative, on the other side some stack arguments (e.g.
large struct by value) still aren't added to CALL_INSN_FUNCTION_USAGE.
If such an argument is first or last, this patch still won't catch it.


-- 


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



[Bug c++/38794] [4.2/4.3 regression] Function body accepted in typedef

2009-01-12 Thread jakub at gcc dot gnu dot org


--- Comment #4 from jakub at gcc dot gnu dot org  2009-01-12 15:45 ---
Fixed on the trunk so far.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|[4.2/4.3/4.4 regression]|[4.2/4.3 regression]
   |Function body accepted in   |Function body accepted in
   |typedef |typedef


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



[Bug c++/38794] [4.2/4.3/4.4 regression] Function body accepted in typedef

2009-01-12 Thread jakub at gcc dot gnu dot org


--- Comment #3 from jakub at gcc dot gnu dot org  2009-01-12 15:43 ---
Subject: Bug 38794

Author: jakub
Date: Mon Jan 12 15:43:22 2009
New Revision: 143292

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143292
Log:
PR c++/38794
* decl.c (start_function): If grokdeclarator hasn't returned
FUNCTION_DECL nor error_mark_node, issue diagnostics.

* g++.dg/parse/typedef9.C: New test.

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


-- 


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



[Bug tree-optimization/38385] ICE with -O2 -ftree-loop-distribution

2009-01-12 Thread tomby at gcc dot gnu dot org


--- Comment #6 from tomby at gcc dot gnu dot org  2009-01-12 15:37 ---
Subject: Bug 38385

Author: tomby
Date: Mon Jan 12 15:37:09 2009
New Revision: 143291

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143291
Log:
PR middlend/38385
* tree-loop-distribution.c (prop_phis): New function.
(generate_builtin): Call prop_phis.
* testsuite/gcc.dg/tree-ssa/pr38385.c: New file.


Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr38385.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-loop-distribution.c


-- 


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



[Bug middle-end/38503] [4.4 regression] warnings from -isystem headers strikes back.

2009-01-12 Thread rguenther at suse dot de


--- Comment #8 from rguenther at suse dot de  2009-01-12 15:16 ---
Subject: Re:  [4.4 regression] warnings from -isystem
 headers strikes back.

On Mon, 12 Jan 2009, pluto at agmk dot net wrote:

> 
> 
> --- Comment #7 from pluto at agmk dot net  2009-01-12 15:10 ---
> (In reply to comment #5)
> > I can't seem to compile the preprocessed source:
> 
> i've attached a new full archive.
> 
> $ make
> rm -f *.ii *.o *.s
> /local/devel/toolchain44/x86_64-gnu-linux/bin/x86_64-gnu-linux-g++ -c -Wall 
> -O2
> -g0 -fPIC --save-temps -isystem ./sys-headers bug.cpp
> bug.cpp: In function 'void foo()':
> bug.cpp:6: warning: dereferencing pointer '' does break
> strict-aliasing rules
> ./sys-headers/boost/optional/optional.hpp:315: note: initialized from here
> bug.cpp:6: warning: dereferencing pointer '' does break
> strict-aliasing rules
> ./sys-headers/boost/optional/optional.hpp:594: note: initialized from here
> 
> > Note that the warning is from bug.cpp:6, not a system header anyway
> 
> looks weird, because i can't see any dereferencing in bug.cpp:6
> there's only trivial cctor which copies an enum.
> 
> for me it looks like the  comes from boost::optional::
> ::aligned_storage::adress() manipulations inside boost system headers.
> 
> > (the _note_ is from a system header, do you want that to disappear?)
> 
> i want to disappear'em all :-)

Fair enough ;)  The compiler just warns that in a second it will remove
that dereference (ok, only on the alias-improvements branch).

Richard.


-- 


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



[Bug middle-end/38503] [4.4 regression] warnings from -isystem headers strikes back.

2009-01-12 Thread pluto at agmk dot net


--- Comment #7 from pluto at agmk dot net  2009-01-12 15:10 ---
(In reply to comment #5)
> I can't seem to compile the preprocessed source:

i've attached a new full archive.

$ make
rm -f *.ii *.o *.s
/local/devel/toolchain44/x86_64-gnu-linux/bin/x86_64-gnu-linux-g++ -c -Wall -O2
-g0 -fPIC --save-temps -isystem ./sys-headers bug.cpp
bug.cpp: In function 'void foo()':
bug.cpp:6: warning: dereferencing pointer '' does break
strict-aliasing rules
./sys-headers/boost/optional/optional.hpp:315: note: initialized from here
bug.cpp:6: warning: dereferencing pointer '' does break
strict-aliasing rules
./sys-headers/boost/optional/optional.hpp:594: note: initialized from here

> Note that the warning is from bug.cpp:6, not a system header anyway

looks weird, because i can't see any dereferencing in bug.cpp:6
there's only trivial cctor which copies an enum.

for me it looks like the  comes from boost::optional::
::aligned_storage::adress() manipulations inside boost system headers.

> (the _note_ is from a system header, do you want that to disappear?)

i want to disappear'em all :-)


-- 


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



[Bug target/38811] [4.4 Regression] internal compiler error: in compensate_edge, at reg-stack.c:2754

2009-01-12 Thread ubizjak at gmail dot com


--- Comment #4 from ubizjak at gmail dot com  2009-01-12 15:06 ---
-fno-ira fixes the failure.


-- 


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



[Bug rtl-optimization/38740] [4.4 Regression] Incorrect delayed branch optimization

2009-01-12 Thread carlos at systemhalted dot org


--- Comment #8 from carlos at systemhalted dot org  2009-01-12 15:02 ---
Dave,

I've been building parts of glibc's vfprintf code with -fno-delayed-branch for
hppa because of bugs in DBR. I never filed a bug because it was almost
impossible for me to reduce the vfprintf code (large file, large tables, long
jumps).


-- 


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



[Bug middle-end/38503] [4.4 regression] warnings from -isystem headers strikes back.

2009-01-12 Thread pluto at agmk dot net


--- Comment #6 from pluto at agmk dot net  2009-01-12 15:01 ---
Created an attachment (id=17077)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17077&action=view)
full testcase (src + .ii + mkefile)


-- 


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



[Bug target/4605] [alpha-osf]mips-tfile & spaced directory names

2009-01-12 Thread ubizjak at gmail dot com


--- Comment #12 from ubizjak at gmail dot com  2009-01-12 14:59 ---
Hm, on i686-pc-linux-gnu -v gives:

COLLECT_GCC_OPTIONS='-c' '-v' '-mtune=generic'
 /usr/local.uros/libexec/gcc/i686-pc-linux-gnu/4.4.0/cc1 -quiet -v dir
test/hello.c -quiet -dumpbase hello.c -mtune=generic -auxbase hello -version -o
/tmp/ccgcf4Ot.s

COLLECT_GCC_OPTIONS='-c' '-v' '-mtune=generic'
 as -V -Qy -o hello.o /tmp/ccgcf4Ot.s

Please note, that the output of as is created in current directory, not in
"dir\ test" subdirectory.

BTW: The error in comment #7 comes from mips-tfile executable.


-- 


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



[Bug libstdc++/38477] [strict-aliasing] warning message contains compiler-generated symbols

2009-01-12 Thread rguenth at gcc dot gnu dot org


--- Comment #14 from rguenth at gcc dot gnu dot org  2009-01-12 14:51 
---
Ok, how about -Wstrict-aliasing=3 warning only if both the dereference and the
declaration are not from system-headers (this is then the default for -Wall)
and with -Wstrict-aliasing=2 (or =1) warn if either of them is not from
system-headers?


-- 


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



[Bug libstdc++/38477] [strict-aliasing] warning message contains compiler-generated symbols

2009-01-12 Thread pluto at agmk dot net


--- Comment #13 from pluto at agmk dot net  2009-01-12 14:43 ---
(In reply to comment #12)
> This isn't really a warning from system headers:
> 
> test.cpp:14: warning: dereferencing pointer '__x.13' does break 
> strict-aliasing
> rules
> 
> the location for the dereference is in test.cpp (if that is correct or not
> is another issue).  There is at least a bug that we will emit the note: part
> even if the warning was suppressed - I am going to fix that.
> 
> I can omit the warning for pointers that are declared in system headers
> in addition to that.  Probably this is what is the better behavior - but
> I cannot easily report the dereference location even if it is in a system
> header but the pointer is _not_ from a system header -- which is probably
> what would be wanted here.
> 
> So,
> 
> t.h:
> #pragma GCC system_header
> 
> inline float deref_float (float *p) { return *p; }
> 
> t.C:
> #include "t.h"
> 
> float transform(int i)
> {
>   return deref_float ((float *)&i);
> }
> 
> _should_ emit a warning?  Even if it looks like
> 
> t.h: In function 'float transform(int)':
> t.h:3: warning:  dereferencing pointer 'i.0' does break strict-aliasing rules
> t.C:5: note: initialized from here
> 
> ?
> 
> IMHO we want to warn unless _both_, the declaration and the dereference is
> in a system header.
> 

this will be painfull for users, e.g. boost::optional uses so called
aligned_storage via mistic void*/casts/etc and now i'm getting these
warnings from boost-system-headers. in this way, the -isystem switch
is completely useless.


-- 

pluto at agmk dot net changed:

   What|Removed |Added

 CC||pluto at agmk dot net


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



[Bug testsuite/38809] gcc.dg/pr38616.c doesn't work on Linux/ia64

2009-01-12 Thread hjl dot tools at gmail dot com


--- Comment #2 from hjl dot tools at gmail dot com  2009-01-12 14:30 ---
Fixed.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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



[Bug libstdc++/38477] [strict-aliasing] warning message contains compiler-generated symbols

2009-01-12 Thread rguenth at gcc dot gnu dot org


--- Comment #12 from rguenth at gcc dot gnu dot org  2009-01-12 14:25 
---
This isn't really a warning from system headers:

test.cpp:14: warning: dereferencing pointer '__x.13' does break strict-aliasing
rules

the location for the dereference is in test.cpp (if that is correct or not
is another issue).  There is at least a bug that we will emit the note: part
even if the warning was suppressed - I am going to fix that.

I can omit the warning for pointers that are declared in system headers
in addition to that.  Probably this is what is the better behavior - but
I cannot easily report the dereference location even if it is in a system
header but the pointer is _not_ from a system header -- which is probably
what would be wanted here.

So,

t.h:
#pragma GCC system_header

inline float deref_float (float *p) { return *p; }

t.C:
#include "t.h"

float transform(int i)
{
  return deref_float ((float *)&i);
}

_should_ emit a warning?  Even if it looks like

t.h: In function 'float transform(int)':
t.h:3: warning:  dereferencing pointer 'i.0' does break strict-aliasing rules
t.C:5: note: initialized from here

?

IMHO we want to warn unless _both_, the declaration and the dereference is
in a system header.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-01-12 14:25:54
   date||


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



[Bug testsuite/38790] syntax error in target selector

2009-01-12 Thread joel at gcc dot gnu dot org


--- Comment #2 from joel at gcc dot gnu dot org  2009-01-12 14:23 ---
It is not appearing here:

(powerpc-aix) http://gcc.gnu.org/ml/gcc-testresults/2009-01/msg01087.html or
(powerpc-darwin) http://gcc.gnu.org/ml/gcc-testresults/2009-01/msg01077.html

so it is fixed.  Sorry for missed commit.


-- 

joel at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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



[Bug testsuite/38790] syntax error in target selector

2009-01-12 Thread joel at gcc dot gnu dot org


--- Comment #1 from joel at gcc dot gnu dot org  2009-01-12 14:20 ---
Is this still happening?   I accidentally did not commit the change to
lib/target-supports.exp and did it over the weekend (Saturday?).


-- 


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



[Bug target/4605] [alpha-osf]mips-tfile & spaced directory names

2009-01-12 Thread markus dot schoepflin at comsoft dot de


--- Comment #11 from markus dot schoepflin at comsoft dot de  2009-01-12 
14:17 ---
Here is the result of using -### instead of -v:

scho...@area51:~/local/src/tests/gcc/4605> /opt/gcc-4.3.2/bin/gcc -### -c
hello.c -o 'dir test/hello.o'Using built-in specs.
Target: alphaev56-dec-osf5.1b
Configured with: /net/homes/schoepf/local/src/gcc-4.3.2/configure
--prefix=/opt/gcc-4.3.2 --enable-languages=c,c++,ada
--with-mpfr=/opt/mpfr-2.3.1 --with-gmp=/opt/gmp-4.2.2 : (reconfigured)
/net/homes/schoepf/local/src/gcc-4.3.2/configure --prefix=/opt/gcc-4.3.2
--enable-languages=c,c++,ada --with-mpfr=/opt/mpfr-2.3.1
--with-gmp=/opt/gmp-4.2.2 --disable-nls
Thread model: posix
gcc version 4.3.2 (GCC) 
COLLECT_GCC_OPTIONS='-c' '-o' 'dir test/hello.o' '-mcpu=ev56'
 "/vol2/opt/gcc-4.3.2/bin/../libexec/gcc/alphaev56-dec-osf5.1b/4.3.2/cc1"
"-quiet" "-iprefix"
"/vol2/opt/gcc-4.3.2/bin/../lib/gcc/alphaev56-dec-osf5.1b/4.3.2/" "hello.c"
"-quiet" "-dumpbase" "hello.c" "-mcpu=ev56" "-auxbase-strip" "dir test/hello.o"
"-o" "/tmp//ccLLEdGT.s"
COLLECT_GCC_OPTIONS='-c' '-o' 'dir test/hello.o' '-mcpu=ev56'
 "as" "-g" "-oldas" "-c" "-nocpp" "-O0" "-o" "dir test/hello.o"
"/tmp//ccLLEdGT.s"
COLLECT_GCC_OPTIONS='-c' '-o' 'dir test/hello.o' '-mcpu=ev56'

"/vol2/opt/gcc-4.3.2/bin/../libexec/gcc/alphaev56-dec-osf5.1b/4.3.2/mips-tfile"
"-o" "dir test/hello.o" "/tmp//ccLLEdGT.s"
COMPILER_PATH=/vol2/opt/gcc-4.3.2/bin/../libexec/gcc/alphaev56-dec-osf5.1b/4.3.2/:/vol2/opt/gcc-4.3.2/bin/../libexec/gcc/
LIBRARY_PATH=/vol2/opt/gcc-4.3.2/bin/../lib/gcc/alphaev56-dec-osf5.1b/4.3.2/:/vol2/opt/gcc-4.3.2/bin/../lib/gcc/:/usr/lib/cmplrs/cc/:/vol2/opt/gcc-4.3.2/bin/../lib/gcc/alphaev56-dec-osf5.1b/4.3.2/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-c' '-o' 'dir test/hello.o' '-mcpu=ev56'


-- 


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



  1   2   >