date:20080807

2008-08-07 Thread howarth at nitro dot med dot uc dot edu



--- Comment #1 from hjl dot tools at gmail dot com  2008-08-08 05:13 ---
bash-3.2$ cat /tmp/x.i
unsigned
foo (double d)
{
  return d;
}
bash-3.2$ ./xgcc -B./   -msse2 -mfpmath=sse -S  /tmp/x.i -Os  -m32
/tmp/x.i: In function foo:
/tmp/x.i:3: internal compiler error: in emit_unop_insn, at optabs.c:3806
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
bash-3.2$ 


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

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

[Bug c/37055] New: internal compiler error: in emit_unop_insn, at optabs.c:3806

The following test cases now fail on i686-apple-datwin9...

FAIL: gcc.c-torture/compile/20020930-1.c  -Os  (internal compiler error)
FAIL: gcc.c-torture/compile/20020930-1.c  -Os  (test for excess errors)
FAIL: gcc.c-torture/compile/930506-1.c  -Os  (internal compiler error)
FAIL: gcc.c-torture/compile/930506-1.c  -Os  (test for excess errors)
FAIL: gcc.c-torture/compile/fix-trunc-mem-1.c  -Os  (internal compiler error)
FAIL: gcc.c-torture/compile/fix-trunc-mem-1.c  -Os  (test for excess errors)
FAIL: gcc.c-torture/execute/conversion.c compilation,  -Os  (internal compiler
error)
FAIL: gcc.c-torture/execute/gofast.c compilation,  -Os  (internal compiler
error)
FAIL: gcc.c-torture/unsorted/BUG11.c,  -Os   (internal compiler error)
FAIL: gcc.c-torture/unsorted/conv.c,  -Os   (internal compiler error)
FAIL: gcc.c-torture/unsorted/conv_tst.c,  -Os   (internal compiler error)
FAIL: gcc.dg/torture/fp-int-convert-double.c  -Os  (internal compiler error)
FAIL: gcc.dg/torture/fp-int-convert-double.c  -Os  (test for excess errors)
WARNING: gcc.dg/torture/fp-int-convert-double.c  -Os  compilation failed to
produce executable
FAIL: gcc.dg/torture/fp-int-convert-float.c  -Os  (internal compiler error)
FAIL: gcc.dg/torture/fp-int-convert-float.c  -Os  (test for excess errors)
WARNING: gcc.dg/torture/fp-int-convert-float.c  -Os  compilation failed to
produce executable
FAIL: gcc.dg/torture/fp-int-convert-timode.c  -Os  (internal compiler error)
FAIL: gcc.dg/torture/fp-int-convert-timode.c  -Os  (test for excess errors)
WARNING: gcc.dg/torture/fp-int-convert-timode.c  -Os  compilation failed to
produce executable

These all fail with errors of the form...

Executing on host:
/sw/src/fink.build/gcc44-4.3.999-20080807/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc44-4.3.999-20080807/darwin_objdir/gcc/  -w  -Os  
-fno-show-column -c  -o /sw/src/fink.build/gcc44-4.3.999
-20080807/darwin_objdir/gcc/testsuite/gcc/BUG11.o
/sw/src/fink.build/gcc44-4.3.999-20080807/gcc-4.4-20080807/gcc/testsuite/gcc.c-torture/unsorted/BUG11.c
   (timeout = 300)
/sw/src/fink.build/gcc44-4.3.999-20080807/gcc-4.4-20080807/gcc/testsuite/gcc.c-torture/unsorted/BUG11.c:
In function 'foo':
/sw/src/fink.build/gcc44-4.3.999-20080807/gcc-4.4-20080807/gcc/testsuite/gcc.c-torture/unsorted/BUG11.c:6:
internal compiler error: in emit_unop_insn, at optabs.c:3806
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
compiler exited with status 1
output is:
/sw/src/fink.build/gcc44-4.3.999-20080807/gcc-4.4-20080807/gcc/testsuite/gcc.c-torture/unsorted/BUG11.c:
In function 'foo':
/sw/src/fink.build/gcc44-4.3.999-20080807/gcc-4.4-20080807/gcc/testsuite/gcc.c-torture/unsorted/BUG11.c:6:
internal compiler error: in emit_unop_insn, at optabs.c:3806
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

FAIL: gcc.c-torture/unsorted/BUG11.c,  -Os   (internal compiler error)

This failure did not occur in gcc trunk on 20080805. The suspect checkin
appears to be...

http://gcc.gnu.org/ml/gcc-patches/2008-08/msg00355.html

Unfortunately this patch doesn't cleanly regress out so I can't confirm that.
This issue
is also reported to happen on Linux with SSE fpmath.


-- 
   Summary: internal compiler error: in emit_unop_insn, at
optabs.c:3806
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
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=37055

[Bug c/37044] Heisenbug: SVN of gcc throws internal compiler error on PPC

2008-08-07 Thread contact at multimedia dot cx



--- Comment #3 from contact at multimedia dot cx  2008-08-08 03:25 ---
Created an attachment (id=16042)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16042&action=view)
Preprocessor output for file that is crashing compiler

As requested, this is the preprocessed output when adding -save-temps to the
command line in the original bug post.


-- 


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

[Bug libobjc/37054] New: undefined reference to `objc_exception_throw'

2008-08-07 Thread jcarthew at gmail dot com

When I try to build gnustep-base I get undefined reference to
`objc_exception_throw'
apparently it is missing in libobjc.def


-- 
   Summary: undefined reference to `objc_exception_throw'
   Product: gcc
   Version: 4.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libobjc
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jcarthew at gmail dot com


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

[Bug c/37053] ICE in reload_cse_simplify_operands, at postreload.c:395



--- Comment #2 from stephen at marenka dot net  2008-08-08 01:02 ---
Created an attachment (id=16041)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16041&action=view)
reduced source from r-base


-- 


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

[Bug c/37053] ICE in reload_cse_simplify_operands, at postreload.c:395



--- Comment #1 from stephen at marenka dot net  2008-08-08 01:02 ---
Created an attachment (id=16040)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16040&action=view)
Preprocessed file


-- 


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

[Bug c/37053] New: ICE in reload_cse_simplify_operands, at postreload.c:395

gcc -fpic -O1 -c postreload.c

Dropping optimization from -O1 to -O0 or dropping -fpic allows this to succeed.

Using built-in specs.
Target: m68k-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.1-8'
--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 --disable-libssp --disable-werror
--enable-checking=release --build=m68k-linux-gnu --host=m68k-linux-gnu
--target=m68k-linux-gnu
Thread model: posix
gcc version 4.3.1 (Debian 4.3.1-8)
COLLECT_GCC_OPTIONS='-save-temps' '-v' '-fpic' '-O1' '-c' '-m68020'
 /usr/lib/gcc/m68k-linux-gnu/4.3.1/cc1 -E -quiet -v postreload.c -m68020 -fpic
-O1 -fpch-preprocess -o postreload.i
ignoring nonexistent directory "/usr/local/include/m68k-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/m68k-linux-gnu/4.3.1/../../../../m68k-linux-gnu/include"
ignoring nonexistent directory "/usr/include/m68k-linux-gnu"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include
 /usr/lib/gcc/m68k-linux-gnu/4.3.1/include
 /usr/lib/gcc/m68k-linux-gnu/4.3.1/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-save-temps' '-v' '-fpic' '-O1' '-c' '-m68020'
 /usr/lib/gcc/m68k-linux-gnu/4.3.1/cc1 -fpreprocessed postreload.i -quiet
-dumpbase postreload.c -m68020 -auxbase postreload -O1 -version -fpic -o
postreload.s
GNU C (Debian 4.3.1-8) version 4.3.1 (m68k-linux-gnu)
compiled by GNU C version 4.3.1, GMP version 4.2.2, MPFR version 2.3.1.
GGC heuristics: --param ggc-min-expand=82 --param ggc-min-heapsize=98603
Compiler executable checksum: 941413abde0b2d7fe947ae106f766200
postreload.c: In function 'do_termsform':
postreload.c:745: warning: assignment makes pointer from integer without a cast
postreload.c:806: warning: initialization makes pointer from integer without a
cast
postreload.c:842: warning: passing argument 1 of 'Rf_install' makes pointer
from integer without a cast
postreload.c:845: warning: passing argument 1 of 'Rf_install' makes pointer
from integer without a cast
postreload.c:845: warning: assignment makes pointer from integer without a cast
postreload.c: At top level:
postreload.c:488: warning: 'EncodeVars' used but never defined
postreload.c:533: warning: 'ExpandDots' used but never defined
postreload.c: In function 'do_termsform':
postreload.c:886: error: insn does not satisfy its constraints:
(insn 309 2675 2677 36 postreload.c:446 (set (reg:SI 0 %d0)
(plus:SI (mem/f:SI (reg:SI 8 %a0) [0 S4 A16])
(reg:SI 0 %d0))) 132 {*addsi3_internal} (nil))
postreload.c:886: internal compiler error: in reload_cse_simplify_operands, at
postreload.c:395
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 
   Summary: ICE in reload_cse_simplify_operands, at postreload.c:395
   Product: gcc
   Version: 4.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: stephen at marenka dot net
 GCC build triplet: m68k-linux-gnu
  GCC host triplet: m68k-linux-gnu
GCC target triplet: m68k-linux-gnu


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

[Bug c/37052] ICE in find_reloads, at reload.c:3744



--- Comment #2 from stephen at marenka dot net  2008-08-08 00:47 ---
Created an attachment (id=16039)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16039&action=view)
reduced source from hdf5


-- 


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

[Bug c/37052] ICE in find_reloads, at reload.c:3744



--- Comment #1 from stephen at marenka dot net  2008-08-08 00:46 ---
Created an attachment (id=16038)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16038&action=view)
Preprocessed file


-- 


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

[Bug c/37052] New: ICE in find_reloads, at reload.c:3744

2008-08-07 Thread Jay dot St dot Pierre at Colorado dot EDU

gcc -save-temps -v -O2 -fomit-frame-pointer -c testreloads.c

Dropping optimization from -O2 to -O1 or dropping -fomit-frame-pointer allows
this to succeed.

Using built-in specs.
Target: m68k-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.1-8'
--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 --disable-libssp --disable-werror
--enable-checking=release --build=m68k-linux-gnu --host=m68k-linux-gnu
--target=m68k-linux-gnu
Thread model: posix
gcc version 4.3.1 (Debian 4.3.1-8)
COLLECT_GCC_OPTIONS='-save-temps' '-v' '-O2' '-fomit-frame-pointer' '-c'
'-m68020'
 /usr/lib/gcc/m68k-linux-gnu/4.3.1/cc1 -E -quiet -v testreloads.c -m68020
-fomit-frame-pointer -O2 -fpch-preprocess -o testreloads.i
ignoring nonexistent directory "/usr/local/include/m68k-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/m68k-linux-gnu/4.3.1/../../../../m68k-linux-gnu/include"
ignoring nonexistent directory "/usr/include/m68k-linux-gnu"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include
 /usr/lib/gcc/m68k-linux-gnu/4.3.1/include
 /usr/lib/gcc/m68k-linux-gnu/4.3.1/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-save-temps' '-v' '-O2' '-fomit-frame-pointer' '-c'
'-m68020'
 /usr/lib/gcc/m68k-linux-gnu/4.3.1/cc1 -fpreprocessed testreloads.i -quiet
-dumpbase testreloads.c -m68020 -auxbase testreloads -O2 -version
-fomit-frame-pointer -o testreloads.s
GNU C (Debian 4.3.1-8) version 4.3.1 (m68k-linux-gnu)
compiled by GNU C version 4.3.1, GMP version 4.2.2, MPFR version 2.3.1.
GGC heuristics: --param ggc-min-expand=82 --param ggc-min-heapsize=98603
Compiler executable checksum: 941413abde0b2d7fe947ae106f766200
testreloads.c: In function 'dataset_readInd':
testreloads.c:123: warning: assignment makes pointer from integer without a
cast
testreloads.c:125: warning: incompatible implicit declaration of built-in
function 'printf'
testreloads.c:205: warning: incompatible implicit declaration of built-in
function 'free'
testreloads.c:207: error: unable to generate reloads for:
(insn:QI 631 629 632 41 testreloads.c:94 (parallel [
(set (cc0)
(compare (reg/v:DI 0 %d0 [orig:117 j ] [117])
(reg:DI 4 %d4 [orig:115 pretmp.69 ] [115])))
(clobber (reg:DI 273))
]) 12 {*m68k.md:521} (expr_list:REG_UNUSED (reg:DI 273)
(nil)))
testreloads.c:207: internal compiler error: in find_reloads, at reload.c:3744
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 
   Summary: ICE in find_reloads, at reload.c:3744
   Product: gcc
   Version: 4.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: stephen at marenka dot net
 GCC build triplet: m68k-linux-gnu
  GCC host triplet: m68k-linux-gnu
GCC target triplet: m68k-linux-gnu


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

[Bug java/37051] New: Random failures running ECJ 3.4 (threading problem?)

2008-08-07 Thread chewi at aura-online dot co dot uk

I have been encountering random failures when running ECJ 3.4. ECJ 3.3 works
fine and I did also encounter random failures with Sun's VM so I initially
filed a bug at eclipse.org. However, further tests have indicated that there
are two different issues here, one affecting GCJ and one affecting Sun, hence I
am filing this bug report now.

The failures only occur when ECJ is run with multiple threads. They do not
occur when -Djdt.compiler.useSingleThread=true is specified and they also do
not occur on single core machines. I have only seen the failures on the x86_64
platform but it could possibly affect others too. The frequency of the failures
varies but they usually occur around once every 10 tries. The error messages
also vary but they usually look like this.

java.lang.NullPointerException
at org.eclipse.jdt.internal.compiler.ReadManager.run(ReadManager.java:160)
at java.lang.Thread.run(libgcj.so.90)

java.lang.NullPointerException
at
org.eclipse.jdt.internal.compiler.util.Util.getFileCharContent(Util.java:226)
at
org.eclipse.jdt.internal.compiler.batch.CompilationUnit.getContents(CompilationUnit.java:71)
at org.eclipse.jdt.internal.compiler.ReadManager.run(ReadManager.java:160)
at java.lang.Thread.run(libgcj.so.90)

I have reproduced this on my usual Gentoo Linux system but also managed to
reproduce it on a fresh installation of Ubuntu Intrepid Ibex Alpha 3 under KVM.
So far, I have only tried GCC 4.3.1. For more details, see the original bug
report at...

https://bugs.eclipse.org/bugs/show_bug.cgi?id=241225

--
Summary: Random failures running ECJ 3.4 (threading problem?)
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: chewi at aura-online dot co dot uk
GCC build triplet: x86_64-pc-linux-gnu
GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64-pc-linux-gnu

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

[Bug fortran/37011] F2003, type extension: multiple inheritence not rejected

2008-08-07 Thread dfranke at gcc dot gnu dot org



--- Comment #2 from dfranke at gcc dot gnu dot org  2008-08-07 21:40 ---
> Could you please CC me next time?

Thought I did, I Surely wanted to?!
Please excuse the oversight :)


-- 


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

[Bug debug/20403] dwarf-3: DW_MACINFO_define - wrong lineno fields for predefined macros

2008-08-07 Thread tromey at gcc dot gnu dot org



--- Comment #2 from tromey at gcc dot gnu dot org  2008-08-07 21:33 ---
This works in 4.3, probably due to the switch to mapped locations.
I didn't try anything earlier.


-- 

tromey at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||tromey at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-08-07 21:33:45
   date||


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

[Bug fortran/37011] F2003, type extension: multiple inheritence not rejected

2008-08-07 Thread pault at gcc dot gnu dot org



--- Comment #1 from pault at gcc dot gnu dot org  2008-08-07 21:23 ---
Daniel,

By golly, I never even thought of that possibility. Thanks!

I'll fix it as obvious as soon as I can.

Paul

PS Could you please CC me next time?  I do not have ove much time for hacking
right now.  I either do the business or follow Bugzilla:-(


-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |pault at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-08-07 21:23:14
   date||


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

[Bug c/21759] Implement warning for codes at the intersection of C and C++

2008-08-07 Thread tromey at gcc dot gnu dot org



--- Comment #9 from tromey at gcc dot gnu dot org  2008-08-07 20:28 ---
See this note for some details on the semantics of this warning,
with respect to keywords:

http://gcc.gnu.org/ml/gcc-patches/2008-07/msg00808.html


-- 


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

[Bug debug/37033] [4.4 Regression] Revision 138733 breaks PCH

2008-08-07 Thread rth at gcc dot gnu dot org



--- Comment #4 from rth at gcc dot gnu dot org  2008-08-07 20:11 ---
Fixed.


-- 

rth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug debug/37033] [4.4 Regression] Revision 138733 breaks PCH

2008-08-07 Thread rth at gcc dot gnu dot org

--- Comment #3 from rth at gcc dot gnu dot org  2008-08-07 20:07 ---
Subject: Bug 37033

Author: rth
Date: Thu Aug  7 20:06:36 2008
New Revision: 138850

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=138850
Log:
PR debug/37033
* gcc.c (cpp_options): Pass along -g*.

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

-- 

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

[Bug libfortran/18985] opening unit 6 messes up print

2008-08-07 Thread burnus at gcc dot gnu dot org



--- Comment #7 from burnus at gcc dot gnu dot org  2008-08-07 19:48 ---
> The print*, (or write(*,*)) statement certainly _IS_ standard Fortran 77 and
> its ubiquitousness should make fixing this bug a priority.

The * is standard Fortran 66 to 2008, however, its interpretation was not
well-defined before Fortran 2003. You rely on an implementation choice of a
certain compiler and not on the standard. Even worse: With Fortran 2003 your
interpretation is opposite to what is written in the standard, which means that
gfortran will not change.

 * * *

May I quote from the Fortran 2003 standard (9.4 File connection):

"An asterisk identifies particular processor-dependent external units that are
preconnected for formatted sequential access (9.5.3.2). These units are also
identified by unit numbers defined by the named constants INPUT_UNIT and
OUTPUT_UNIT of the ISO_FORTRAN_ENV module (13.8.2)."

That is what gfortran does: INPUT_UNIT is 5, OUTPUT_UNIT is 6 and ERROR_UNIT is
0, the numbers are extremely popular choices though not defined in any Fortran
standard. Note especially the word "PRE-CONNECTED". The connection of these
units can be changed via

"9.4.5 The OPEN statement
"An OPEN statement initiates or modifies the connection between an external
file and a specified unit. [...] If a unit is connected to a file that exists,
execution of an OPEN statement for that unit is permitted."

Thus if one does
  open(6,file="foo.dat")
one changes the connection of unit 6 to point to "foo.dat" instead of to
standard out. Since OUTPUT_UNIT now points to "foo.dat", also unit=* (for
PRINT/WRITE) points to "foo.dat"

 * * *

It might be annoying that your old program does not work, but it was never
standard conform (at least not to the ISO Fortran 77/90/95/2003/2008 standard)
but it relied on a particular implementation choice which is incompatible with
the Fortran 2003 standard.

Once compiler which treated UNIT=* and UNIT=6 differently was the Intel Fortran
compiler, ifort alias ifc. But newer versions follow the Fortran 2003 standard,
even though they offer the option:

-assume old_unit_star  The READs or WRITEs  to  UNIT=*  go  to
   stdin  or  stdout, respectively, even if
   UNIT=5  or  6  has  been  connected   to
   another file.

(Older version connected * to negative units, if I recall correctly, thus "*"
was something like -2 (guessed number) and thus 6 and '*' could be connected to
different files - both were preconnected to stdout.)

Intel introduced that option to be compatible with older version of ifort,
which have behaviours which clash with newer Fortran standard. As gfortran (and
not even its predecessor g77) had never implement it in a F2003 incompatible
way, there is no reason to implement such option, especially as most of the
time such programs are not really broken, only the output goes to the "wrong"
place.

 * * *

As a general advice: For file I/O one should use UNITs > 10 to make
(relatively) sure they do not clash with the INPUT/OUTPUT/ERROR_UNIT of a given
compiler; with Fortran 2008 one can let OPEN do the job to assign a free unit
[not yet implemented in gfortran].


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu dot
   ||org


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

[Bug c/37050] New: gcc-4.3.1 bootstrap failure on sparc Solaris 10

Since I am unable to bootstrap gcc-4.3.1 using the Sun cc compiler (see bug
Bug#: 33304), I attempted to compile using Sun's version of gcc
(http://cooltools.sunsource.net/gcc/).  This does not work either.  The
configure fails in the sparc-sun-solaris2.10/libgcc directory.

The version of gcc being used is:
/gcc -v
Using built-in specs.
Target: sparc-sun-solaris2.10
Configured with:
/net/clpt-v490-1/export/data/bldmstr/20080102_phobos_gcc42/src/configure
--prefix=/usr/sfw --enable-shared --with-system-zlib --enable-checking=release
--disable-libmudflap --enable-languages=c,c++
--enable-version-specific-runtime-libs --with-cpu=v9 --with-ld=/usr/ccs/bin/ld
--without-gnu-ld --disable-gnattools --with-mpfr=/ws/gccfss/tools
--with-gmp=/ws/gccfss/tools
Thread model: posix
gcc version 4.2.0 (gccfss)

The configure command is:
/bin/ksh
/appl/local_sde_dev/src/gcc/gcc-4.3.1/sparc-SunOS-5.10/gcc-4.3.1-obj/../gcc-4.3.1/configure
--prefix=/usr/local/sde/gcc-4.3.1 --with-gmp=/usr/local/sde
--with-mpfr=/usr/local/sde --disable-nls

Note that gmp and mpfr are compiled into static libraries only, and I set
ABI=32 for gmp.

The "make bootstrap" terminates with:

checking for suffix of object files... configure: error: cannot compute suffix
of object files: cannot compile
See `config.log' for more details.

The following is an extract from the config.log (from the
sparc-sun-solaris2.10/libgcc directory) that has the following error message:

Reading specs from
/appl/local_sde_dev/src/gcc/gcc-4.3.1/sparc-SunOS-5.10/gcc-4.3.1-obj/./gcc/specs
Target: sparc-sun-solaris2.10
Configured with:
/appl/local_sde_dev/src/gcc/gcc-4.3.1/sparc-SunOS-5.10/gcc-4.3.1-obj/../gcc-4.3.1/configure
--prefix=/usr/local/sde/gcc-4.3.1 --with-gmp=/usr/local/sde
--with-mpfr=/usr/local/sde --disable-nls
Thread model: posix
gcc version 4.3.1 (GCC)
configure:2374: $? = 0
configure:2376:
/appl/local_sde_dev/src/gcc/gcc-4.3.1/sparc-SunOS-5.10/gcc-4.3.1-obj/./gcc/xgcc
-B/appl/local_sde_dev/src/gcc/gcc-4.3.1/sparc-SunOS-5.10/gcc-4.3.1-obj/./gcc/
-B/usr/local/sde/gcc-4.3.1/sparc-sun-solaris2.10/bin/
-B/usr/local/sde/gcc-4.3.1/sparc-sun-solaris2.10/lib/ -isystem
/usr/local/sde/gcc-4.3.1/sparc-sun-solaris2.10/include -isystem
/usr/local/sde/gcc-4.3.1/sparc-sun-solaris2.10/sys-include -V &5
xgcc: '-V' must come at the start of the command line
configure:2379: $? = 1
configure:2398:
/appl/local_sde_dev/src/gcc/gcc-4.3.1/sparc-SunOS-5.10/gcc-4.3.1-obj/./gcc/xgcc
-B/appl/local_sde_dev/src/gcc/gcc-4.3.1/sparc-SunOS-5.10/gcc-4.3.1-obj/./gcc/
-B/usr/local/sde/gcc-4.3.1/sparc-sun-solaris2.10/bin/
-B/usr/local/sde/gcc-4.3.1/sparc-sun-solaris2.10/lib/ -isystem
/usr/local/sde/gcc-4.3.1/sparc-sun-solaris2.10/include -isystem
/usr/local/sde/gcc-4.3.1/sparc-sun-solaris2.10/sys-include -o conftest -g
-fkeep-inline-functions   conftest.c  >&5
conftest.c:1: internal compiler error: Segmentation Fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Please let me know what more information you would like.


-- 
   Summary: gcc-4.3.1 bootstrap failure on sparc Solaris 10
   Product: gcc
   Version: 4.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Jay dot St dot Pierre at Colorado dot EDU
 GCC build triplet: sparc-sun-solaris2.10
  GCC host triplet: sparc-sun-solaris2.10
GCC target triplet: sparc-sun-solaris2.10


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

[Bug debug/37033] [4.4 Regression] Revision 138733 breaks PCH



--- Comment #2 from hjl dot tools at gmail dot com  2008-08-07 19:09 ---
The problem is -E never generates any debug info. So __GCC_HAVE_DWARF2_CFI_ASM
won't be defined for -E and PCH gets a mismatch.


-- 


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

[Bug libfortran/18985] opening unit 6 messes up print

2008-08-07 Thread schilds at sun dot ac dot za



--- Comment #6 from schilds at sun dot ac dot za  2008-08-07 19:07 ---
This is a serious bug, make no mistake. It causes existing Fortran 77 code to
fail. It's wasted a lot of my time and, no doubt, a lot of other, good peoples'
too. 

The print*, (or write(*,*)) statement certainly _IS_ standard Fortran 77 and
its ubiquitousness should make fixing this bug a priority.


-- 


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

[Bug debug/37033] [4.4 Regression] Revision 138733 breaks PCH



--- Comment #1 from hjl dot tools at gmail dot com  2008-08-07 18:58 ---
Created an attachment (id=16037)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16037&action=view)
A testcase

/export/build/gnu/gcc-work/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-work/build-x86_64-linux/gcc/ -S  -m32 -O0 -g -I.
-save-temps -Winvalid-pch -o save-temps-1.s save-temps-1.c
save-temps-1.c:2:26: warning: save-temps-1.h.gch: not used because
`__GCC_HAVE_DWARF2_CFI_ASM' not defined
save-temps-1.c:2:26: warning: ./save-temps-1.h.gch: not used because
`__GCC_HAVE_DWARF2_CFI_ASM' not defined
save-temps-1.c:2:26: error: save-temps-1.h: No such file or directory
save-temps-1.c:2:26: error: one or more PCH files were found, but they were
invalid
save-temps-1.c:4:2: error: #error T not defined
make: *** [save-temps-1.s] Error 1
[EMAIL PROTECTED] pch-1]$ 

The key here is -save-temps. Without it, it works.


-- 


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

[Bug target/37048] [4.4 Regression] Revision 138835 breaks bootstrap

2008-08-07 Thread dave at hiauly1 dot hia dot nrc dot ca



--- Comment #7 from hjl dot tools at gmail dot com  2008-08-07 17:23 ---
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=37048

[Bug ada/37034] /bin/sh: line 1: 26087 Aborted (core dumped) ./xsinfo ../../sinfo.h



--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca  2008-08-07 
17:12 ---
Subject: Re:  /bin/sh: line 1: 26087 Aborted  (core dumped) ./xsinfo
../../sinfo.h

> Right, and xeinfo is built with your base compiler. I'd try with an older
> or more recent base GNAT version. It's more likely a latent bug in
> GCC 4.3.1 only showing now because xeinfo dependencies have changed.
> 
> > > chatr xeinfo
> > 
> > This is debian linux.  I will try debug xeinfo when the current build
> > completes.
> 
> Ooops, what about "ldd xeinfo" then ?

[EMAIL PROTECTED]:~/gcc-4.4/objdir/gcc/ada/bldtools/sinfo$ ldd xsinfo
libgcc_s.so.4 => /lib/libgcc_s.so.4 (0x40215000)
libc.so.6 => /lib/libc.so.6 (0x40545000)
/lib/ld.so.1 (0x40248000)

The backtrace isn't very informative but indicates an abort:

This GDB was configured as "hppa-linux"...
Reading symbols from /home/dave/gcc-4.4/objdir/prev-gcc/libgcc_s.so.4...done.
Loaded symbols for /home/dave/gcc-4.4/objdir/./prev-gcc/libgcc_s.so.4
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld.so.1...done.
Loaded symbols for /lib/ld.so.1
Core was generated by `./xsinfo ../../sinfo.h'.
Program terminated with signal 6, Aborted.
[New process 24437]
#0  0x405e23ac in getpid () from /lib/libc.so.6
(gdb) bt
#0  0x405e23ac in getpid () from /lib/libc.so.6
#1  0x4057d390 in abort () from /lib/libc.so.6
#2  0x in ?? ()

I think I need to try a build with debug libraries.  The program doesn't
fail when run it from the command line.  I have now seen this problem
with two build compilers: a personal build of 4.2.1 and debian 4.3.1.

Dave


-- 


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

[Bug debug/37020] [4.4 Regression] FAIL: gcc.dg/debug/dwarf2/dwarf-die3.c scan-assembler-not DW_AT_inline

2008-08-07 Thread aesok at gcc dot gnu dot org



--- Comment #1 from aesok at gcc dot gnu dot org  2008-08-07 16:53 ---
The gcc.dg/debug/dwarf2/dwarf-die3.c testcase FALL on x86_64-unknown-linux-gnu
also.

Anatoliy


-- 

aesok at gcc dot gnu dot org changed:

   What|Removed |Added

 GCC target triplet|avr-*-* |x86_64-unknown-linux-gnu
   ||avr-*-*
Summary|[4.4 Regression] [AVR] FAIL:|[4.4 Regression] FAIL:
   |gcc.dg/debug/dwarf2/dwarf-  |gcc.dg/debug/dwarf2/dwarf-
   |die3.c scan-assembler-not   |die3.c scan-assembler-not
   |DW_AT_inline|DW_AT_inline


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

[Bug target/37049] Unaligned move used on aligned destination of push insn



--- Comment #1 from hjl dot tools at gmail dot com  2008-08-07 16:38 ---
A patch is posted at

http://gcc.gnu.org/ml/gcc-patches/2008-08/msg00204.html


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2008-
   ||08/msg00204.html


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

[Bug target/37049] New: Unaligned move used on aligned destination of push insn

[EMAIL PROTECTED] gcc]$ cat /tmp/push-1.c 
/* { dg-do compile { target { { i?86-*-* x86_64-*-* } && ilp32 } } } */
/* { dg-options "-w -msse2 -Os" } */

typedef float __m128 __attribute__ ((__vector_size__ (16), __may_alias__));

extern void foo (__m128 x, __m128 y ,__m128 z ,__m128 a, int size);

void
bar (void)
{
  __m128 x = { 1.0 };
  foo (x, x, x, x, 5);
}

/* { dg-final { scan-assembler-not "movups" } } */
[EMAIL PROTECTED] gcc]$ ./xgcc -B./ -Os -m32 -msse2 -S /tmp/push-1.c
[EMAIL PROTECTED] gcc]$ cat push-1.s 
.file   "push-1.c"
.text
.globl bar
.type   bar, @function
bar:
pushl   %ebp
movl%esp, %ebp
subl$20, %esp
movss   .LC0, %xmm0
pushl   $5
subl$16, %esp
movups  %xmm0, (%esp)
movaps  %xmm0, %xmm2
movaps  %xmm0, %xmm1
callfoo
addl$32, %esp
leave
ret

-mno-accumulate-outgoing-args will push argument onto stack.
Since there is no push insn for __m128, ix86_expand_push is
called to emulate push __m128. But it doesn't set proper
alignment. As the result, unaligned move insn is generated
even though memory is aligned.  Since ix86_expand_push is
used to push a value onto an aligned location on the stack,
the alignment of destination should be at least aligned to
function argument boundary, which is the minimum alignment
of push destination.


-- 
   Summary: Unaligned move used on aligned  destination of push insn
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
GCC target triplet: i686-pc-linux-gnu


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

[Bug middle-end/37046] Inlining produces calls which gimple_call_fndecl cannot handle correctly



--- Comment #4 from rguenth at gcc dot gnu dot org  2008-08-07 16:00 ---
Interesting.  I may have a look into the CCP problem.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug middle-end/37046] Inlining produces calls which gimple_call_fndecl cannot handle correctly

2008-08-07 Thread jamborm at gcc dot gnu dot org



--- Comment #3 from jamborm at gcc dot gnu dot org  2008-08-07 15:49 ---
Unfortunately, I got a fortran regression:

/abuild/mjambor/iinln/gcc/testsuite/gfortran.dg/char_cast_1.f90:24: internal
com
piler error: in expand_call_inline, at tree-inline.c:3117

The assert is gcc_assert (dest->needed); so I think I might have
uncovered some unrelated hidden problem.  We will see.

I will try to investigate but may not be able to go all the way
because I'm, leaving for vacation tomorrow.

Richi, that applies, to your question too.  I will try but I may not
make it.


-- 


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

[Bug tree-optimization/36631] [4.3/4.4 Regression] attribute always_inline -> sorry, unimplemented: recursive inlining



--- Comment #3 from rguenth at gcc dot gnu dot org  2008-08-07 15:25 ---
Mine.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-07-10 14:23:16 |2008-08-07 15:25:00
   date||


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

[Bug java/32247] -Wall enables -Wunused enables -Wunused-parameter



--- Comment #13 from manu at gcc dot gnu dot org  2008-08-07 15:22 ---
Unsubscribing: not sure what is to fix here.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 CC|manu at gcc dot gnu dot org |


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

[Bug c++/37043] fails to find operator match when constructing object on the fly

2008-08-07 Thread schwab at suse dot de



--- Comment #4 from schwab at suse dot de  2008-08-07 15:19 ---
Because the result of FooBar("two") is an rvalue, but test1 is an lvalue.


-- 

schwab at suse dot de changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug target/37048] [4.4 Regression] Revision 138835 breaks bootstrap

2008-08-07 Thread hubicka at gcc dot gnu dot org

--- Comment #6 from hubicka at gcc dot gnu dot org  2008-08-07 14:56 ---
Subject: Bug 37048

Author: hubicka
Date: Thu Aug  7 14:55:32 2008
New Revision: 138841

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=138841
Log:
PR target/37048
* i386.md (single stringop patterns): Enable unconditionally. 

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.md

-- 

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

[Bug target/37048] [4.4 Regression] Revision 138835 breaks bootstrap



--- Comment #5 from hjl dot tools at gmail dot com  2008-08-07 14:52 ---
(In reply to comment #4)
> Subject: Re:  [4.4 Regression] Revision 138835 breaks bootstrap
> 
> Hi,
> thanks for testcase, for some reason it does not reproduce on our
> testing setup, probably due to ancient glibc that still has
> memcpy/memset inlines.
> 
> This patch should fix it, I am testing it right now but I am not sure I
> will be able to commit before tomorro wunforutnately.
> The problem is that we now use single stringops on optimize_size
> regions, but the patterns are disabled. It is not problem to enable
> them; we never produce them directly, only via the stringop expanders.
> (at least I am convinced combine won't produce this)
> 

I am testing it now. I will commit it for you if it works and no one
beats me on it.  Thanks.


-- 


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

[Bug c++/36999] Erroneous "declaration 'class ...' does not declare anything" warnings possible

2008-08-07 Thread simon_baldwin at yahoo dot com



--- Comment #6 from simon_baldwin at yahoo dot com  2008-08-07 14:42 ---
Fixed for mainline and 4.3 branch -- resolving as FIXED.


-- 

simon_baldwin at yahoo dot com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug target/37048] [4.4 Regression] Revision 138835 breaks bootstrap

2008-08-07 Thread jh at suse dot cz



--- Comment #4 from jh at suse dot cz  2008-08-07 14:30 ---
Subject: Re:  [4.4 Regression] Revision 138835 breaks bootstrap

Hi,
thanks for testcase, for some reason it does not reproduce on our
testing setup, probably due to ancient glibc that still has
memcpy/memset inlines.

This patch should fix it, I am testing it right now but I am not sure I
will be able to commit before tomorro wunforutnately.
The problem is that we now use single stringops on optimize_size
regions, but the patterns are disabled. It is not problem to enable
them; we never produce them directly, only via the stringop expanders.
(at least I am convinced combine won't produce this)

Honza

* i386.md (single stringop patterns): Enable unconditionally.
Index: config/i386/i386.md
===
*** config/i386/i386.md (revision 138835)
--- config/i386/i386.md (working copy)
***
*** 18652,18658 
 (set (match_operand:DI 1 "register_operand" "=S")
(plus:DI (match_dup 3)
 (const_int 8)))]
!   "TARGET_64BIT && TARGET_SINGLE_STRINGOP"
"movsq"
[(set_attr "type" "str")
 (set_attr "mode" "DI")
--- 18652,18658 
 (set (match_operand:DI 1 "register_operand" "=S")
(plus:DI (match_dup 3)
 (const_int 8)))]
!   "TARGET_64BIT"
"movsq"
[(set_attr "type" "str")
 (set_attr "mode" "DI")
***
*** 18667,18673 
 (set (match_operand:SI 1 "register_operand" "=S")
(plus:SI (match_dup 3)
 (const_int 4)))]
!   "!TARGET_64BIT && TARGET_SINGLE_STRINGOP"
"movs{l|d}"
[(set_attr "type" "str")
 (set_attr "mode" "SI")
--- 18667,18673 
 (set (match_operand:SI 1 "register_operand" "=S")
(plus:SI (match_dup 3)
 (const_int 4)))]
!   "!TARGET_64BIT"
"movs{l|d}"
[(set_attr "type" "str")
 (set_attr "mode" "SI")
***
*** 18682,18688 
 (set (match_operand:DI 1 "register_operand" "=S")
(plus:DI (match_dup 3)
 (const_int 4)))]
!   "TARGET_64BIT && TARGET_SINGLE_STRINGOP"
"movs{l|d}"
[(set_attr "type" "str")
 (set_attr "mode" "SI")
--- 18682,18688 
 (set (match_operand:DI 1 "register_operand" "=S")
(plus:DI (match_dup 3)
 (const_int 4)))]
!   "TARGET_64BIT"
"movs{l|d}"
[(set_attr "type" "str")
 (set_attr "mode" "SI")
***
*** 18697,18703 
 (set (match_operand:SI 1 "register_operand" "=S")
(plus:SI (match_dup 3)
 (const_int 2)))]
!   "!TARGET_64BIT && TARGET_SINGLE_STRINGOP"
"movsw"
[(set_attr "type" "str")
 (set_attr "memory" "both")
--- 18697,18703 
 (set (match_operand:SI 1 "register_operand" "=S")
(plus:SI (match_dup 3)
 (const_int 2)))]
!   "!TARGET_64BIT"
"movsw"
[(set_attr "type" "str")
 (set_attr "memory" "both")
***
*** 18712,18718 
 (set (match_operand:DI 1 "register_operand" "=S")
(plus:DI (match_dup 3)
 (const_int 2)))]
!   "TARGET_64BIT && TARGET_SINGLE_STRINGOP"
"movsw"
[(set_attr "type" "str")
 (set_attr "memory" "both")
--- 18712,18718 
 (set (match_operand:DI 1 "register_operand" "=S")
(plus:DI (match_dup 3)
 (const_int 2)))]
!   "TARGET_64BIT"
"movsw"
[(set_attr "type" "str")
 (set_attr "memory" "both")
***
*** 18727,18733 
 (set (match_operand:SI 1 "register_operand" "=S")
(plus:SI (match_dup 3)
 (const_int 1)))]
!   "!TARGET_64BIT && TARGET_SINGLE_STRINGOP"
"movsb"
[(set_attr "type" "str")
 (set_attr "memory" "both")
--- 18727,18733 
 (set (match_operand:SI 1 "register_operand" "=S")
(plus:SI (match_dup 3)
 (const_int 1)))]
!   "!TARGET_64BIT"
"movsb"
[(set_attr "type" "str")
 (set_attr "memory" "both")
***
*** 18742,18748 
 (set (match_operand:DI 1 "register_operand" "=S")
(plus:DI (match_dup 3)
 (const_int 1)))]
!   "TARGET_64BIT && TARGET_SINGLE_STRINGOP"
"movsb"
[(set_attr "type" "str")
 (set_attr "memory" "both")
--- 18742,18748 
 (set (match_operand:DI 1 "register_operand" "=S")
(plus:DI (match_dup 3)
 (const_int 1)))]
!   "TARGET_64BIT"
"movsb"
[(set_attr "type" "str")
 (set_attr "memory" "both")
***
*** 18917,18923 
   (match_operand 2 "register_operand" ""))
  (set (match_operand 0 "register_operand" "")
   (match_operand 3 "" ""))])]
!   "TARGET_SINGLE_STRINGOP"
"ix86_current_function_needs_cld = 1;")

  (define_insn "*strsetdi_rex_1"
--- 18917,18923 
   (match_operand 2 "register_operand" ""))
  (set (match_operand 0 "register_operand" "")
   (match_operand 3 "" ""))])]
!   ""
"ix86_curre

[Bug c++/37043] fails to find operator match when constructing object on the fly

2008-08-07 Thread scott at stg dot net



--- Comment #3 from scott at stg dot net  2008-08-07 13:53 ---
For clarification, this code compiles & runs in gcc & msvc:
FooBar test1("one");
"A">>test1;

And this code compiles & runs fine in msvc, but gives compile error in gcc:
"B">>FooBar("two");

Since it's the same class, why should there be any difference in matching
operator>> depending on how it's instantiated?

The sample code is a distillation (demonstration) from a larger code base for
convenience of exploring this issue.


-- 


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

[Bug target/37048] [4.4 Regression] Revision 138835 breaks bootstrap



--- Comment #3 from hjl dot tools at gmail dot com  2008-08-07 13:47 ---
[EMAIL PROTECTED] prev-gcc]$ cat ../zlib/x.c
typedef struct gz_stream {
char *inbuf;
long offset;
} gz_stream;


void *malloc(__SIZE_TYPE__ size);

long
foo (void * file, long offset)
{
gz_stream *s = (gz_stream*)file;
if (s->inbuf == 0) {
s->inbuf = malloc (2000);
if (s->inbuf == 0) return -1L;
__builtin_memset (s->inbuf, 0, 2000);
}
while (offset > 0)  {
  unsigned int size = 2000;
offset -= size;
}
return s->offset;
}
[EMAIL PROTECTED] prev-gcc]$ ./xgcc -B./ -O2 -S ../zlib/x.c
../zlib/x.c: In function âfooâ:
../zlib/x.c:23: error: unrecognizable insn:
(insn 33 84 34 8 ../zlib/x.c:16 (parallel [
(set (mem:QI (reg:SI 67) [0 S1 A8])
(subreg:QI (reg:SI 69) 0))
(set (reg:SI 67)
(plus:SI (reg:SI 67)
(const_int 1 [0x1])))
]) -1 (nil))
../zlib/x.c:23: internal compiler error: in extract_insn, at recog.c:1988
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
[EMAIL PROTECTED] prev-gcc]$


-- 


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

[Bug c++/37043] fails to find operator match when constructing object on the fly

2008-08-07 Thread scott at stg dot net



--- Comment #2 from scott at stg dot net  2008-08-07 13:31 ---
Okay, so if I change:

FooBar& operator>> (const char *s,FooBar& dest)

to

FooBar operator>> (const char *s,FooBar dest)

It now compiles on both msvc and g++, but required functionality (operation
affecting existing object, not making new copy of it) is lost.

Is there some reason that using a reference to rvalue in operator>> is
disallowed in gcc and not msvc?  If so, why doesn't it fail in the A>>object;
instance where the object has already been instantiated separately?


-- 


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

[Bug target/37048] [4.4 Regression] Revision 138835 breaks bootstrap



--- Comment #2 from hjl dot tools at gmail dot com  2008-08-07 13:21 ---
It also happens on Linux/ia32.


-- 


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

[Bug target/37048] [4.4 Regression] Revision 138835 breaks bootstrap



--- Comment #1 from hjl dot tools at gmail dot com  2008-08-07 13:20 ---
*** Bug 37045 has been marked as a duplicate of this bug. ***


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 CC||jv244 at cam dot ac dot uk


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

[Bug bootstrap/37045] bootstrap fails: dwarf2out.c:13496: error: unrecognizable insn



--- Comment #2 from hjl dot tools at gmail dot com  2008-08-07 13:20 ---


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


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug target/36992] Very stange code for _mm_move_epi64



--- Comment #22 from hjl dot tools at gmail dot com  2008-08-07 13:18 
---
Fixed.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED


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

[Bug target/36992] Very stange code for _mm_move_epi64

2008-08-07 Thread hjl at gcc dot gnu dot org



--- Comment #21 from hjl at gcc dot gnu dot org  2008-08-07 13:17 ---
Subject: Bug 36992

Author: hjl
Date: Thu Aug  7 13:16:23 2008
New Revision: 138839

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

2008-08-07  H.J. Lu  <[EMAIL PROTECTED]>

PR target/36992
* config/i386/emmintrin.h (_mm_move_epi64): Use
__builtin_ia32_movq128.

* config/i386/i386.c (ix86_builtins): Add IX86_BUILTIN_MOVQ128.
(bdesc_args): Add IX86_BUILTIN_MOVQ128.

* config/i386/sse.md (sse2_movq128): New.

* doc/extend.texi: Document __builtin_ia32_movq128.

gcc/testsuite/

2008-08-07  H.J. Lu  <[EMAIL PROTECTED]>

PR target/36992
* gcc.target/i386/pr36992-1.c: Scan movq.
* gcc.target/i386/pr36992-2.c: Use "-O2 -msse4" instead of
"-O0 -msse2".  Scan movq.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/emmintrin.h
trunk/gcc/config/i386/i386.c
trunk/gcc/config/i386/sse.md
trunk/gcc/doc/extend.texi
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/pr36992-1.c
trunk/gcc/testsuite/gcc.target/i386/pr36992-2.c


-- 


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

[Bug middle-end/37046] Inlining produces calls which gimple_call_fndecl cannot handle correctly



--- Comment #2 from rguenth at gcc dot gnu dot org  2008-08-07 13:14 ---
Looks good.  Similar things may happen with CCP propagation for like

void foo(void) {}

void bar(void)
{
  void (*fn)(void) = foo;
  fn();
}

can you verify this as well?  Thanks.


-- 


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

[Bug c++/12242] g++ should warn about out-of-range int->enum conversions

2008-08-07 Thread bangerth at dealii dot org



--- Comment #17 from bangerth at dealii dot org  2008-08-07 13:13 ---
(In reply to comment #16)
> The expression cannot be very complicated because it needs to be a 
> INTEGER_CST.

Sure, but it can be of the form
   ~SOME_PREPROCESSOR_MACRO | (MACRO2 ^ MACRO3)
What I meant to say is that the value of the expression may not be
obvious to the author of the code.


> On the other hand, I agree that it is best to give users as much information 
> as
> reasonable. I think it is better if you comment in gcc-patches so reviewers 
> can
> see your proposal.

Will do next time, I guess for this time we're stuck here :-)


> I would prefer to not repeat twice %T, though. Also, I think
> users are going to have trouble to understand that the range of the enumeral 
> is
> larger than the number of enumerators it contains. Perhaps we should print the
> range of %T?
> 
> "the result of % is unspecified because %qE is outside the range
> [%d,%d] of type %qT."

That would be an excellent idea as well.

Thanks
 Wolfgang


-- 


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

[Bug target/16894] far/section attributes on function parameters, typedefs, and literals



--- Comment #3 from manu at gcc dot gnu dot org  2008-08-07 13:11 ---
4 years old, no activity, unconfirmed. Please fill bugs for specific targets
with testcases so the target maintainers are aware of this issue.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WONTFIX


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

[Bug target/37048] New: [4.4 Regression] Revision 138835 breaks bootstrap

2008-08-07 Thread gcc-bugzilla at contacts dot eelis dot net

Revision 138835 breaks bootstrap on Linux/x86-64:

[EMAIL PROTECTED] zlib]$ /export/gnu/import/svn/gcc-test/bld/./prev-gcc/xgcc
-B/export/gnu/import/svn/gcc-test/bld/./prev-gcc/
-B/usr/local/x86_64-unknown-linux-gnu/bin/ -DPACKAGE_NAME=\"\"
-DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\"
-DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"zlib\" -DVERSION=\"1.1.4\"
-DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1
-DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1
-DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\"
-DHAVE_STDLIB_H=1 -DHAVE_UNISTD_H=1 -DHAVE_GETPAGESIZE=1 -DHAVE_MMAP=1
-DHAVE_MEMCPY=1 -DHAVE_STRERROR=1 -DHAVE_UNISTD_H=1  -I. -I../../src/zlib
-g -O2 -c -o libz_a-gzio.o `test -f 'gzio.c' || echo '../../src/zlib/'`gzio.c
../../src/zlib/gzio.c: In function âgzseekâ:
../../src/zlib/gzio.c:852: error: unrecognizable insn:
(insn 53 248 54 15 ../../src/zlib/gzio.c:792 (parallel [
(set (mem:QI (reg:DI 77) [0 S1 A8])
(subreg:QI (reg:SI 79) 0))
(set (reg:DI 77)
(plus:DI (reg:DI 77)
(const_int 1 [0x1])))
]) -1 (nil))
../../src/zlib/gzio.c:852: internal compiler error: in extract_insn, at
recog.c:1988
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
[EMAIL PROTECTED] zlib]$

Gcc was configured with  --enable-checking=assert --enable-clocale=gnu
--with-sy
stem-zlib --enable-shared --with-demangler-in-ld.


-- 
   Summary: [4.4 Regression] Revision 138835 breaks bootstrap
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com


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

[Bug c++/37047] New: Missing warning for deprecated use of static

In 7.3.1.1p2, the standard states "The use of the static keyword is deprecated
when declaring objects in a namespace scope", yet g++ does not warn about such
uses. Compiling the following snippet:

  static int i;
  int g() { return i; }

results in no diagnostics of any kind, not even with -std=c++98 -Wall -Wextra
-pedantic.


-- 
   Summary: Missing warning for deprecated use of static
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc-bugzilla at contacts dot eelis dot net


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

[Bug c++/36999] Erroneous "declaration 'class ...' does not declare anything" warnings possible

2008-08-07 Thread simonb at gcc dot gnu dot org



--- Comment #5 from simonb at gcc dot gnu dot org  2008-08-07 12:29 ---
Subject: Bug 36999

Author: simonb
Date: Thu Aug  7 12:27:48 2008
New Revision: 138838

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=138838
Log:
gcc/cp/ChangeLog:
Backport from mainline:
2008-08-04  Simon Baldwin  <[EMAIL PROTECTED]>

PR c++/36999
* parser.c (cp_parser_elaborated_type_specifier): Warn only when
the declaration's id is followed by a semicolon.

gcc/testsuite/ChangeLog:
Backport from mainline:
2008-08-04  Simon Baldwin  <[EMAIL PROTECTED]>

PR c++/36999
* g++.dg/warn/pr36999.C: New.



Added:
branches/gcc-4_3-branch/gcc/testsuite/g++.dg/warn/pr36999.C
Modified:
branches/gcc-4_3-branch/gcc/cp/ChangeLog
branches/gcc-4_3-branch/gcc/cp/parser.c
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug bootstrap/37045] bootstrap fails: dwarf2out.c:13496: error: unrecognizable insn

2008-08-07 Thread jv244 at cam dot ac dot uk



--- Comment #1 from jv244 at cam dot ac dot uk  2008-08-07 12:21 ---
Just in case this is useful, this is the corresponding command line:

/data/vondele/gcc_bench/gcc_trunk/obj/./prev-gcc/xgcc
-B/data/vondele/gcc_bench/gcc_trunk/obj/./prev-gcc/
-B/data/vondele/gcc_bench/gcc_trunk/build/x86_64-unknown-linux-gnu/bin/ -c  -g
-O2 -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 -Werror -fno-common  -DHAVE_CONFIG_H -I. -I.
-I/data/vondele/gcc_bench/gcc_trunk/gcc/gcc
-I/data/vondele/gcc_bench/gcc_trunk/gcc/gcc/.
-I/data/vondele/gcc_bench/gcc_trunk/gcc/gcc/../include
-I/data/vondele/gcc_bench/gcc_trunk/gcc/gcc/../libcpp/include
-I/data/vondele/gcc_bench/gcc_trunk/obj/./gmp
-I/data/vondele/gcc_bench/gcc_trunk/gcc/gmp
-I/data/vondele/gcc_bench/gcc_trunk/obj/./mpfr
-I/data/vondele/gcc_bench/gcc_trunk/gcc/mpfr 
-I/data/vondele/gcc_bench/gcc_trunk/gcc/gcc/../libdecnumber
-I/data/vondele/gcc_bench/gcc_trunk/gcc/gcc/../libdecnumber/bid
-I../libdecnumber  /data/vondele/gcc_bench/gcc_trunk/gcc/gcc/dwarf2out.c -o
dwarf2out.o


-- 


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

[Bug c/37041] -Wc++-compat refinements

2008-08-07 Thread joseph at codesourcery dot com

--- Comment #2 from joseph at codesourcery dot com  2008-08-07 12:04 ---
Subject: Re:  -Wc++-compat refinements

On Thu, 7 Aug 2008, manu at gcc dot gnu dot org wrote:

> To clarify how to implement this, I have some questions:
> 
> (In reply to comment #0)
> > -Wc++-compat should allow bool, wchar_t, char16_t and char32_t as typedefs
> > defined in system headers, while warning if they are used other than as 
> > types
> > or the typedefs are defined other than in system headers.
> 
> This will require:
> 
> * a check in CPP when defining new macros. It should probably allow also to be
> used as macro name if defined in system header (#define bool _Bool).

I see no need for macro checks for these type names; the check should be 
for when they reach the C parser as identifiers, just like the checks for 
other C++ keywords both with the restriction on context.  Because they are 
keywords in C++, C++ programs could also define them as macros.

> > -Wc++-compat should warn for asm and inline when used in a C mode where they
> > are identifiers not keywords, but not in a mode when they are keywords and
> > not for the __ variants in any case.
> 
> I think that not checking the __ variants is given. I don't understand what 
> you
> mean by "not in a mode when they are keywords". My understanding is that we
> should warn always that they are used as names (type names, identifiers, macro
> names, macro parameters) and never when they are keywords (independently of 
> the
> C mode).

With -std=c89 -Wc++-compat, both are identifiers and both should be warned 
for when they reach the C parser as identifiers.  No warnings for 
preprocessor uses are needed.

With -std=gnu89 -Wc++-compat, both are keywords and neither should be 
warned for.

With -std=c99 -Wc++-compat, inline is a keyword and should not be warned 
for, but asm is an identifier and should be warned for.

> > -Wc++-compat should warn for uses of the alternative representations for
> > operators and punctuators such as "and", including uses as macro names 
> > (except
> > when defined in system headers, because of iso646.h) and macro parameter 
> > names.
> 
> Hence:
> 
> * a check in CPP when defining new macros.
> 
> * various checks in c-parser.c or c-decl.c to check for names. Any use here is
> wrong. (CPP would have already replaced 'and' if it is a macro).

That seems right.  If they reach the parser they can probably be handled 
just like the existing -Wc++-compat warnings (put in the keyword table for 
warning, but never actually handled as keywords), but additional 
preprocessor checks are needed as well.  (The relevant preprocessor cases 
give errors in C++.)

-- 

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

[Bug c/37041] -Wc++-compat refinements



--- Comment #1 from manu at gcc dot gnu dot org  2008-08-07 11:54 ---
Confirmed as enhancement.

To clarify how to implement this, I have some questions:

(In reply to comment #0)
> -Wc++-compat should allow bool, wchar_t, char16_t and char32_t as typedefs
> defined in system headers, while warning if they are used other than as types
> or the typedefs are defined other than in system headers.

This will require:

* a check in CPP when defining new macros. It should probably allow also to be
used as macro name if defined in system header (#define bool _Bool).

* various checks in c-parser.c or c-decl.c to check for
   a) typedefs outside system headers.
   b) Names except for types.

> -Wc++-compat should warn for asm and inline when used in a C mode where they
> are identifiers not keywords, but not in a mode when they are keywords and
> not for the __ variants in any case.

I think that not checking the __ variants is given. I don't understand what you
mean by "not in a mode when they are keywords". My understanding is that we
should warn always that they are used as names (type names, identifiers, macro
names, macro parameters) and never when they are keywords (independently of the
C mode).

> -Wc++-compat should warn for uses of the alternative representations for
> operators and punctuators such as "and", including uses as macro names (except
> when defined in system headers, because of iso646.h) and macro parameter 
> names.

Hence:

* a check in CPP when defining new macros.

* various checks in c-parser.c or c-decl.c to check for names. Any use here is
wrong. (CPP would have already replaced 'and' if it is a macro).


Am I missing something?

Cheers,

Manuel.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||manu at gcc dot gnu dot org
   Severity|normal  |enhancement
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-08-07 11:54:54
   date||


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

[Bug c++/36999] Erroneous "declaration 'class ...' does not declare anything" warnings possible



--- Comment #4 from manu at gcc dot gnu dot org  2008-08-07 11:22 ---
Then this is confirmed and it works in GCC 4.4.0


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
  Known to fail|4.4.0 4.3.1 4.3.0   |4.3.1 4.3.0
  Known to work||4.4.0
   Last reconfirmed|-00-00 00:00:00 |2008-08-07 11:22:47
   date||


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

[Bug middle-end/37046] Inlining produces calls which gimple_call_fndecl cannot handle correctly

2008-08-07 Thread jamborm at gcc dot gnu dot org



--- Comment #1 from jamborm at gcc dot gnu dot org  2008-08-07 10:11 ---
I am testing the patch below which should fix the problem:

2008-08-07  Martin Jambor  <[EMAIL PROTECTED]>

* tree-inline.c (remap_gimple_stmt): Remove extraneous addr_expr
from call statements.

Index: iinln/gcc/tree-inline.c
===
--- iinln.orig/gcc/tree-inline.c
+++ iinln/gcc/tree-inline.c
@@ -1209,6 +1209,14 @@ remap_gimple_stmt (gimple stmt, copy_bod
   wi.info = id;
   walk_gimple_op (copy, remap_gimple_op_r, &wi); 

+  /* When a parameter is propagated into a call destination, it is in the form
+ of call> which gimple_call_fndecl does not understand.
+ Therefore we need to take the extra addr_expr out here. */
+  if (is_gimple_call (copy)
+  && TREE_CODE (gimple_call_fn (copy)) == ADDR_EXPR
+  && TREE_CODE (TREE_OPERAND (gimple_call_fn (copy), 0)) == FUNCTION_DECL)
+gimple_call_set_fn (copy, TREE_OPERAND (gimple_call_fn (copy), 0));
+
   /* We have to handle EH region remapping of GIMPLE_RESX specially because
  the region number is not an operand.  */
   if (gimple_code (stmt) == GIMPLE_RESX && id->eh_region_offset)


-- 

jamborm at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-08-07 10:11:37
   date||


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

[Bug middle-end/37046] New: Inlining produces calls which gimple_call_fndecl cannot handle correctly

2008-08-07 Thread jamborm at gcc dot gnu dot org

In the following example, the  fucntion hooray() does not get inlined,
even though it could.

#include 
#include 


static __attribute__((always_inline)) void hooray ()
{
  printf ("hooray\n");
}

static __attribute__((always_inline)) void hiphip (void (*f)())
{
  printf ("hip hip\n");
  f ();
}


int main (int argc, int *argv[])
{
  hiphip (hooray);
  return 0;
}

int d()
{
  hiphip (hooray);
  return 86;
}


The reasons  are I believe  a bit more  grave than the fact  that this
(mis)use of anlways_inline does not work.  When tree-inline.c produces
an inlined copy of hiphip() it remaps the destination of the call to f
in  remap_gimple_stmt()  to  call   hooray.   However,  the  new  call
statement has this form:

  call> 

which  is a  form  that gimple_call_fndecl()  cannot  cope with.   The
consequence  is  that  rebuild_cgraph_edges()  sees  a  call  with  an
unretrievable declaration and does not build a call graph edge for it.

Therefore, when early inlining  inlines hiphip into its callers, there
is no  call graph  edge for main->hooray  (or d->hooray) and  so these
call sites  are not even  considered when doing regular  inlining, let
alone always_inlining.


-- 
   Summary: Inlining produces calls which gimple_call_fndecl cannot
handle correctly
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: jamborm at gcc dot gnu dot org
ReportedBy: jamborm at gcc dot gnu dot org


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

[Bug middle-end/37042] Strict-aliasing warnings are printed for _mm_load_si128, even though m128i is attribute((may_alias__)).



--- Comment #5 from rguenth at gcc dot gnu dot org  2008-08-07 10:03 ---
Subject: Bug 37042

Author: rguenth
Date: Thu Aug  7 10:01:48 2008
New Revision: 138837

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=138837
Log:
2008-08-07  Richard Guenther  <[EMAIL PROTECTED]>

PR middle-end/37042
* tree-ssa-alias-warnings.c (nonstandard_alias_p): Ref-all
pointers can access anything.

* gcc.dg/Wstrict-aliasing-bogus-ref-all-2.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/Wstrict-aliasing-bogus-ref-all-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-alias-warnings.c


-- 


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

[Bug middle-end/37042] Strict-aliasing warnings are printed for _mm_load_si128, even though m128i is attribute((may_alias__)).



--- Comment #4 from rguenth at gcc dot gnu dot org  2008-08-07 10:02 ---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug middle-end/37042] Strict-aliasing warnings are printed for _mm_load_si128, even though m128i is attribute((may_alias__)).



--- Comment #3 from rguenth at gcc dot gnu dot org  2008-08-07 10:01 ---
Subject: Bug 37042

Author: rguenth
Date: Thu Aug  7 09:59:58 2008
New Revision: 138836

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=138836
Log:
2008-08-07  Richard Guenther  <[EMAIL PROTECTED]>

PR middle-end/37042
* tree-ssa-alias-warnings.c (nonstandard_alias_p): Ref-all
pointers can access anything.

* gcc.dg/Wstrict-aliasing-bogus-ref-all-2.c: New testcase.

Added:
   
branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/Wstrict-aliasing-bogus-ref-all-2.c
Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog
branches/gcc-4_3-branch/gcc/tree-ssa-alias-warnings.c


-- 


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

[Bug bootstrap/37045] New: bootstrap fails: dwarf2out.c:13496: error: unrecognizable insn

2008-08-07 Thread jv244 at cam dot ac dot uk

At revision 138835

/data/vondele/gcc_bench/gcc_trunk/gcc/gcc/dwarf2out.c: In function
gen_subprogram_die:
/data/vondele/gcc_bench/gcc_trunk/gcc/gcc/dwarf2out.c:13496: error:
unrecognizable insn:
(insn 1465 2398 1466 235
/data/vondele/gcc_bench/gcc_trunk/gcc/gcc/dwarf2out.c:8357 (parallel [
(set (mem:QI (reg:DI 400) [0 S1 A8])
(subreg:QI (reg:SI 402) 0))
(set (reg:DI 400)
(plus:DI (reg:DI 400)
(const_int 1 [0x1])))
]) -1 (nil))
/data/vondele/gcc_bench/gcc_trunk/gcc/gcc/dwarf2out.c:13496: internal compiler
error: in extract_insn, at recog.c:1988
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[3]: *** [dwarf2out.o] Error 1
make[3]: *** Waiting for unfinished jobs


-- 
   Summary: bootstrap fails: dwarf2out.c:13496: error:
unrecognizable insn
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk
  GCC host triplet: x86_64-unknown-linux-gnu


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

[Bug middle-end/37042] Strict-aliasing warnings are printed for _mm_load_si128, even though m128i is attribute((may_alias__)).



--- Comment #2 from rguenth at gcc dot gnu dot org  2008-08-07 08:51 ---
Mine.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-08-07 08:50:50 |2008-08-07 08:51:06
   date||


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

[Bug middle-end/37042] Strict-aliasing warnings are printed for _mm_load_si128, even though m128i is attribute((may_alias__)).



--- Comment #1 from rguenth at gcc dot gnu dot org  2008-08-07 08:50 ---
Confirmed.  This is the other machinery.

typedef long long __m128i __attribute__ ((__vector_size__ (16),
__may_alias__));

extern __inline __m128i __attribute__((__gnu_inline__, __always_inline__,
__artificial__))
_mm_load_si128 (__m128i const *__P)
{
  return *__P;
}

static const short __attribute__((__aligned__(16))) tbl[8] =
{ 1, 2, 3, 4, 5, 6, 7, 8};


__m128i get_vec(void)
{
  __m128i ret;

  ret = _mm_load_si128((__m128i *)tbl);

  return ret;
}


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||diagnostic
   Last reconfirmed|-00-00 00:00:00 |2008-08-07 08:50:50
   date||


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

[Bug middle-end/36983] Trunk 138207 miscompiles 172.mgrid on x86-64

2008-08-07 Thread Joey dot ye at intel dot com



--- Comment #3 from Joey dot ye at intel dot com  2008-08-07 07:55 ---
Although 138318 fixes the compiler ICE, it miscompile with -O3 -ffast-math on
x86-64:
  Running 172.mgrid ref base o3 default
*** Miscompare of mgrid.out, see
/home/jye2/cpu2000/benchspec/CFP2000/172.mgrid/run/0003/mgrid.out.mis

No small case available yet


-- 

Joey dot ye at intel dot com changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|FIXED   |


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

[Bug c/17336] AVRGCC ignores "volatile" keyword for "register" variables

2008-08-07 Thread urjaman at gmail dot com



--- Comment #7 from urjaman at gmail dot com  2008-08-07 07:51 ---
I did a simple test on my avr-gcc 4.2.2 and it seems that this bug (i dont
think it should be Resolution: INVALID but...) is fixed in 4.2.2 atleast. I
changed the register used in the example to r2 to see if the AVR's incapability
to do andi (AND immediate) on r0-r15 would cause any problems, but even this
didnt cause the bug. Here's the objdump output:

while(1)
{
if ( flags & 0x02 ) // Some event detected
   8:   21 fe   sbrsr2, 1
   a:   fe cf   rjmp.-4 ; 0x8 
{
flags &= (0xFF-0x02);   // Clear flag
   c:   8d ef   ldi r24, 0xFD   ; 253
   e:   28 22   and r2, r24
  10:   21 fe   sbrsr2, 1
  12:   fa cf   rjmp.-12; 0x8 
  14:   fb cf   rjmp.-10; 0xc 


-- 


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

[Bug c++/12242] g++ should warn about out-of-range int->enum conversions