[Bug target/36806] [4.4 Regression] I/Os hang at rev. 137631 on darwin9

[dominiq at lps dot ens dot fr]

--- Comment #19 from dominiq at lps dot ens dot fr  2008-07-25 06:56 ---
> I confirm that i686-apple-darwin on tuples branch does _not_ hang in these 
> test cases

Is this a real fix, i.e., the cause(s) of the hanging has(ve) been understood
and fixed? or does it just happen that the hanging is no longer there?


-- 


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

[Bug fortran/36928] New: array temporary for interleaving assignment

[tkoenig at gcc dot gnu dot org]

The temporary is not needed in this case.

$ cat foo.f90
program main
  real, dimension(10) :: a
  read (10) a
  a(2:10:2) = a (1:9:2)
end program main
$ gfortran -Warray-temporaries foo.f90
foo.f90:4.14:

  a(2:10:2) = a (1:9:2)
 1
Warning: Creating array temporary at (1)


-- 
   Summary: array temporary for interleaving assignment
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tkoenig at gcc dot gnu dot org


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

[Bug c++/36767] [4.3/4.4 Regression] Segmentation fault with -fprofile-arcs -O2

[jason at gcc dot gnu dot org]

--- Comment #9 from jason at gcc dot gnu dot org  2008-07-25 02:32 ---
I accidentally checked in the demangler patch with my defaulted/deleted
functions work today, so you don't need to worry about that.  :)

As for the patch itself, does it work to scan for DECL_EXPRs instead of the
decls themselves?  I'm a bit concerned about the current patch touching decls
that it shouldn't.


-- 


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

[Bug tree-optimization/36926] [4.4 Regression] Revision 138092 breaks building of xalancbmk

[hjl dot tools at gmail dot com]

--- Comment #5 from hjl dot tools at gmail dot com  2008-07-25 01:05 ---
Created an attachment (id=15958)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15958&action=view)
A testcase

[EMAIL PROTECTED] XSLT]$ /export/gnu/import/rrs/138092/usr/bin/g++ -O2 -S x.ii
x.cc: In member function ‘void
xalanc_1_10::NamespacesHandler::processExcludeResultPrefixes(xalanc_1_10::StylesheetConstructionContext&,
const xalanc_1_10::XalanDOMChar*, const
xalanc_1_10::XalanDeque >,
xalanc_1_10::ConstructWithMemoryManagerTraits > > >&)’:
x.cc:60: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
[EMAIL PROTECTED] XSLT]$ 


-- 


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

[Bug tree-optimization/36926] [4.4 Regression] Revision 138092 breaks building of xalancbmk

[hjl dot tools at gmail dot com]

--- Comment #4 from hjl dot tools at gmail dot com  2008-07-25 00:12 ---
(gdb) call debug_tree (def)
 
unsigned DI
size 
unit size 
align 64 symtab 0 alias set -1 canonical type 0x2a9ac8a3c0>
var  def_stmt 
version 46>
arg 
constant
arg 0 
addressable used nothrow public static weak inline no-static-chain
decl_5 QI defer-output file NamespacesHandler.hpp line 92 col 15
align 16 context  initial
 arguments  result

pending-inline-info 0x2a9a503e80
saved-insns 0x2a9a501510 chain >>
arg 
var  def_stmt

version 42>>
(gdb) 


-- 


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

[Bug tree-optimization/36926] [4.4 Regression] Revision 138092 breaks building of xalancbmk

[hjl dot tools at gmail dot com]

--- Comment #3 from hjl dot tools at gmail dot com  2008-07-25 00:11 ---
(gdb) f 1
#1  0x008e3619 in ipa_analyze_call_uses (info=0x2a9bed6998, 
call=0x2a9bb25690, stmt=0x2a9bb285a0) at ../../src/gcc/ipa-prop.c:749
749   if ((rec = ipa_get_stmt_member_ptr_load_param (d1)))
(gdb) call debug_tree (n1)
 
type_6 QI
size 
unit size 
align 8 symtab 0 alias set 0 canonical type 0x2a9a30b0c0 method
basetype 
arg-types 
chain >>
pointer_to_this >
unsigned DI
size 
unit size 
align 64 symtab 0 alias set -1 canonical type 0x2a9ac8a3c0>
constant
arg 0 
addressable used nothrow public static weak inline no-static-chain
decl_5 QI defer-output file NamespacesHandler.hpp line 92 col 15
align 16 context  initial 
arguments 
readonly used unsigned DI file NamespacesHandler.hpp line 92 col 15
size  unit size 
align 64 context  initial
 arg-type >
result 
readonly unsigned ignored DI file NamespacesHandler.hpp line 93 col
3 size  unit size 
align 64 context >
pending-inline-info 0x2a9a503e80
saved-insns 0x2a9a501510
chain 
nothrow public static external weak inline no-static-chain decl_5
QI defer-output file NamespacesHandler.hpp line 105 col 42
align 16 context  initial
 arguments  result

pending-inline-info 0x2a9a509300 chain >>>
(gdb) p d1
$1 = (tree) 0x0
(gdb) 


-- 


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

[Bug c++/36767] [4.3/4.4 Regression] Segmentation fault with -fprofile-arcs -O2

[dodji at gcc dot gnu dot org]

--- Comment #8 from dodji at gcc dot gnu dot org  2008-07-25 00:04 ---
By the way, I can reproduce the problem on trunk. I think I was lacking sleep
when I first said I could not reproduce it on trunk. Sorry.


-- 


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

[Bug c++/36767] [4.3/4.4 Regression] Segmentation fault with -fprofile-arcs -O2

[dodji at gcc dot gnu dot org]

--- Comment #7 from dodji at gcc dot gnu dot org  2008-07-25 00:03 ---
Created an attachment (id=15957)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15957&action=view)
fixes DECL_CONTEXT() of the temporary variables in the initialiser

So this patch seems to make the crash go away for me.

I still need to add add some asserts in the mangler to prevent it from
recursing ad infinitum when a VAR_DECL has a NULL name.


-- 


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

[Bug tree-optimization/36926] [4.4 Regression] Revision 138092 breaks building of xalancbmk

[hjl dot tools at gmail dot com]

--- Comment #2 from hjl dot tools at gmail dot com  2008-07-24 23:55 ---
Program received signal SIGSEGV, Segmentation fault.
ipa_get_stmt_member_ptr_load_param (stmt=0x0) at ../../src/gcc/ipa-prop.c:611
611   if (TREE_CODE (stmt) != GIMPLE_MODIFY_STMT)
(gdb) bt
#0  ipa_get_stmt_member_ptr_load_param (stmt=0x0)
at ../../src/gcc/ipa-prop.c:611
#1  0x007fbf57 in ipa_analyze_params_uses (node=)
at ../../src/gcc/ipa-prop.c:749
#2  0x007fa8ed in inline_generate_summary ()
at ../../src/gcc/ipa-inline.c:1665
#3  0x0061f1e8 in execute_ipa_pass_list (pass=0xe5c280)
at ../../src/gcc/passes.c:1184
#4  0x007f5c57 in cgraph_optimize () at ../../src/gcc/cgraphunit.c:1356
#5  0x0044bf0a in cp_write_global_declarations ()
at ../../src/gcc/cp/decl2.c:3546
#6  0x006930dd in toplev_main (argc=, 
argv=) at ../../src/gcc/toplev.c:971
#7  0x002a95b013fb in __libc_start_main () from /lib64/tls/libc.so.6
#8  0x0040432a in _start ()
(gdb) 

Joey, can you find a small testcase?


-- 


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

[Bug tree-optimization/36926] [4.4 Regression] Revision 138092 breaks building of xalancbmk

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2008-07-24 23:50 ---
please attach the preprocessed source and maybe even the backtrace.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
Summary|[4.4 Regression] Revision   |[4.4 Regression] Revision
   |138092 breaks C++   |138092 breaks building of
   ||xalancbmk


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

[Bug target/36927] New: Altivec #pragma's can be implemented now

[pinskia at gcc dot gnu dot org]

With the addition of the function specific attributes support, the #pragma that
the Altivec PIM describes can be implemented.
#pragma altivec_codegen on | off 
When this pragma is on, the compiler may use AltiVec instructions. When you set
this 
pragma off, the altivec_model pragma is also set to off. 
#pragma altivec_model on | off 
When this pragma is on, the compiler accepts the syntax specified in this
document, and the 
altivec_codegen pragma is also set to on. 
#pragma altivec_vrsave on | off | allon 
When this pragma is on, the compiler maintains the VRSAVE register. With allon 
selected, the compiler changes the VRSAVE register to have all bits set. It is
combined with 
#pragma altivec_vrsave off by having a parent function do the work once of
setting 
the value of the VRSAVE register with #pragma altivec_vrsave allon and the
function 
it calls uses the setting #pragma altivec_vrsave off.


-- 
   Summary: Altivec #pragma's can be implemented now
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org


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

[Bug tree-optimization/36926] New: [4.4 Regression] Revision 138092 breaks C++

[hjl dot tools at gmail dot com]

While compiling 483.xalancbmk in SPEC CPU 2006, revision 138092
caused:

[EMAIL PROTECTED] build_base_o2.]$ 
/export/gnu/import/rrs/138092/usr/bin/g++ -c
-o NamespacesHandler.o -DSPEC_CPU -DNDEBUG  -DAPP_NO_THREADS
-DXALAN_INMEM_MSG_LOADER -I. -Ixercesc -Ixercesc/dom -Ixercesc/dom/impl
-Ixercesc/sax -Ixercesc/util/MsgLoaders/InMemory
-Ixercesc/util/Transcoders/Iconv -Ixalanc/include -DPROJ_XMLPARSER
-DPROJ_XMLUTIL -DPROJ_PARSERS -DPROJ_SAX4C -DPROJ_SAX2 -DPROJ_DOM
-DPROJ_VALIDATORS -DXML_USE_NATIVE_TRANSCODER -DXML_USE_INMEM_MESSAGELOADER
-DXML_USE_PTHREADS  -O2 -ffast-math   -DSPEC_CPU_LP64  -DSPEC_CPU_LINUX
NamespacesHandler.cpp
NamespacesHandler.cpp: In function ‘bool
xalanc_1_8::addOrUpdateByPrefix(xalanc_1_8::StylesheetConstructionContext&,
VectorType&, const xalanc_1_8::XalanDOMString&, const
xalanc_1_8::XalanDOMString&) [with VectorType =
std::vector >]’:
NamespacesHandler.cpp:910: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
[EMAIL PROTECTED] build_base_o2.]$


-- 
   Summary: [4.4 Regression] Revision 138092 breaks C++
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
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=36926

[Bug libstdc++/36924] mt_allocator/deallocate_local_thread-5.cc and ext/mt_allocator/deallocate_local_thread-7.cc fail sometimes

[paolo dot carlini at oracle dot com]

--- Comment #5 from paolo dot carlini at oracle dot com  2008-07-24 23:20 
---
(In reply to comment #4)

> librt will make stack limit very small. It is a known issue.

Ah, Ok, that is useful to know. 


-- 


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

[Bug target/36925] New: "3.5 malloc(), vec_malloc(), and new" part of the Alivec PIM is not implemented

[pinskia at gcc dot gnu dot org]

When I was looking up something in the Altivec PIM if "vector bool a;" was
valid, I 
noticed a section which I had never read before, most likely because it is part
of the ABI 
section of the Altivec PIM.

The specific section says:
3.5  malloc(), vec_malloc(), and new 
In the interest of saving space, malloc(), calloc(),  and realloc() are not
required to return 
a 16-byte aligned address. Instead, a new set of memory management functions is 
introduced that return a 16-byte aligned address. The new functions are named 
vec_malloc(), vec_calloc(), vec_realloc(), and vec_free(). The two sets of
memory 
management functions may not be interchanged: memory allocated with malloc(), 
calloc(), or realloc() may only be freed with free() and reallocated with
realloc(); memory 
allocated with vec_alloc(), vec_calloc(), or vec_realloc() may only be freed
with vec_free() 
and reallocated with vec_realloc(). The user must use the appropriate set of
functions 
based on the alignment requirement of the type involved. In the case of the C++ 
operator new, the implementation of new is required to use the appropriate set
of 
functions based on the alignment requirement of the type.


-- 
   Summary: "3.5  malloc(), vec_malloc(), and new" part of the
Alivec PIM is not implemented
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
GCC target triplet: powerpc*-*-*


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

[Bug libstdc++/36924] mt_allocator/deallocate_local_thread-5.cc and ext/mt_allocator/deallocate_local_thread-7.cc fail sometimes

[hjl dot tools at gmail dot com]

--- Comment #4 from hjl dot tools at gmail dot com  2008-07-24 23:17 ---
(In reply to comment #1)
> I suppose you can believe me if I tell you that I care about libstdc++-v3.
> 
> Then, commit 138087 cannot have anything to do with these failures, really,
> believe me. Actually, I suspect 138092 is ""at fault"". Are you 101% sure 
> about
> 138087? Can you double check, please?
> 
>

I am 100% sure. The difference is

[EMAIL PROTECTED] rrs]$ ldd ./138087/usr/lib64/libstdc++.so.6
librt.so.1 => /lib64/tls/librt.so.1 (0x002a95884000)
libm.so.6 => /lib64/tls/libm.so.6 (0x002a9599e000)
libc.so.6 => /lib64/tls/libc.so.6 (0x002a95b24000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x002a95d5a000)
libpthread.so.0 => /lib64/tls/libpthread.so.0 (0x002a95e67000)
/lib64/ld-linux-x86-64.so.2 (0x00552000)

librt will make stack limit very small. It is a known issue.


-- 


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

[Bug libstdc++/36924] mt_allocator/deallocate_local_thread-5.cc and ext/mt_allocator/deallocate_local_thread-7.cc fail sometimes

[paolo dot carlini at oracle dot com]

--- Comment #3 from paolo dot carlini at oracle dot com  2008-07-24 22:49 
---
Reverted the commit because anyway we want to pursue a completely different
strategy. Really, my previous comment stays. Anyway.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug libstdc++/36924] mt_allocator/deallocate_local_thread-5.cc and ext/mt_allocator/deallocate_local_thread-7.cc fail sometimes

[paolo at gcc dot gnu dot org]

--- Comment #2 from paolo at gcc dot gnu dot org  2008-07-24 22:48 ---
Subject: Bug 36924

Author: paolo
Date: Thu Jul 24 22:47:26 2008
New Revision: 138127

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=138127
Log:
2008-07-24  Paolo Carlini  <[EMAIL PROTECTED]>

PR libstdc++/36924
Revert:
2008-07-23  Chris Fairles <[EMAIL PROTECTED]>

* acinclude.m4 ([GLIBCXX_CHECK_CLOCK_GETTIME]): Define GLIBCXX_LIBS.
Holds the lib that defines clock_gettime (-lrt or -lposix4).
* src/Makefile.am: Use it.
* configure: Regenerate.
* configure.in: Likewise.
* Makefile.in: Likewise.
* src/Makefile.in: Likewise.
* libsup++/Makefile.in: Likewise.
* po/Makefile.in: Likewise.
* doc/Makefile.in: Likewise.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/Makefile.in
trunk/libstdc++-v3/acinclude.m4
trunk/libstdc++-v3/configure
trunk/libstdc++-v3/doc/Makefile.in
trunk/libstdc++-v3/include/Makefile.in
trunk/libstdc++-v3/include/std/chrono
trunk/libstdc++-v3/libmath/Makefile.in
trunk/libstdc++-v3/libsupc++/Makefile.in
trunk/libstdc++-v3/po/Makefile.in
trunk/libstdc++-v3/src/Makefile.am
trunk/libstdc++-v3/src/Makefile.in
trunk/libstdc++-v3/testsuite/Makefile.in


-- 


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

[Bug tree-optimization/36861] [4.3 Regression] boost's compressed avl confuses GCC

[drow at gcc dot gnu dot org]

--- Comment #18 from drow at gcc dot gnu dot org  2008-07-24 22:18 ---
Putting the regression marker back.  The code doesn't matter; if it's a
regression, then it's regression.


-- 

drow at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|boost's compressed avl  |[4.3 Regression] boost's
   |confuses GCC|compressed avl confuses GCC


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

[Bug libstdc++/36924] [4.4 Regression] Revision 138087 breaks libstdc++

[paolo dot carlini at oracle dot com]

--- Comment #1 from paolo dot carlini at oracle dot com  2008-07-24 22:06 
---
I suppose you can believe me if I tell you that I care about libstdc++-v3.

Then, commit 138087 cannot have anything to do with these failures, really,
believe me. Actually, I suspect 138092 is ""at fault"". Are you 101% sure about
138087? Can you double check, please?

Then, libstdc++ is currently not broken at all. These two testcases, involving
an optional, extension allocator, in an optional mode, are known to be very
brittle, already failed on and off on various targets, many times in the past.


-- 


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

[Bug libstdc++/36924] New: [4.4 Regression] Revision 138087 breaks libstdc++

[hjl dot tools at gmail dot com]

On Linux/x86, revision 138087 caused

FAIL: ext/mt_allocator/deallocate_local_thread-5.cc execution test
FAIL: ext/mt_allocator/deallocate_local_thread-7.cc execution test


-- 
   Summary: [4.4 Regression] Revision 138087 breaks libstdc++
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
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=36924

[Bug bootstrap/36330] i386-pc-solaris2.10 configure: error: C compiler cannot create executables

[andry at inbox dot ru]

--- Comment #13 from andry at inbox dot ru  2008-07-24 21:35 ---
I found which part of Makefile broken: "$CC -print-prog-name=ld".
This is means that mingw build already broken, if root mingw directory differs
from "mingw32" folder.


-- 


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

[Bug bootstrap/36330] i386-pc-solaris2.10 configure: error: C compiler cannot create executables

[andry at inbox dot ru]

--- Comment #12 from andry at inbox dot ru  2008-07-24 21:14 ---
I have the same issue on i686-pc-mingw32.
It is slightly different issue, is about: "ld: no such file or directory".
I take a look in to generated Makefile and found this:
"LD = c:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../mingw32/bin/ld.exe"
This is of cause incorrect and should be fixed to:
"LD = c:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../mingw/bin/ld.exe""


-- 


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

[Bug inline-asm/36923] New: Crashes with FPU inline-assembly

[tobias dot doerffel at gmail dot com]

Trying to compile the following (already pre-processed) code causes ICE:

# 1 "gcc-ice.cpp"
# 1 ""
# 1 ""
# 1 "gcc-ice.cpp"
static float fraction( float _x )
{
 int tmp;

 asm ( "fld  %0\n"
  "fld  %%st(0)\n"
  "fisttp %1\n"
  "fild %1\n"
  "fxch\n"
  "fsub %%st(1),%%st(0)\n"
 : "=&t"( _x ), "=m"( tmp )
 : "f"( _x )
 : );
 return( _x );
}

int main( void )
{
 float x = fraction( 2.34634 );
}


Command-line:

g++ -O2 gcc-ice.cpp -save-temps 


Output:

Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.3.1-7ubuntu1'
--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.1 (Ubuntu 4.3.1-7ubuntu1)
COLLECT_GCC_OPTIONS='-v' '-O2' '-save-temps' '-msse3' '-mtune=generic'
 /usr/lib/gcc/i486-linux-gnu/4.3.1/cc1plus -E -quiet -v -D_GNU_SOURCE
gcc-ice.cpp -D_FORTIFY_SOURCE=2 -msse3 -mtune=generic -O2 -fpch-preprocess -o
gcc-ice.ii
ignoring nonexistent directory "/usr/local/include/i486-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/i486-linux-gnu/4.3.1/../../../../i486-linux-gnu/include"
ignoring nonexistent directory "/usr/include/i486-linux-gnu"
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/c++/4.3
 /usr/include/c++/4.3/i486-linux-gnu
 /usr/include/c++/4.3/backward
 /usr/local/include
 /usr/lib/gcc/i486-linux-gnu/4.3.1/include
 /usr/lib/gcc/i486-linux-gnu/4.3.1/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-O2' '-save-temps' '-msse3' '-mtune=generic'
 /usr/lib/gcc/i486-linux-gnu/4.3.1/cc1plus -fpreprocessed gcc-ice.ii -quiet
-dumpbase gcc-ice.cpp -msse3 -mtune=generic -auxbase gcc-ice -O2 -version
-fstack-protector -o gcc-ice.s
GNU C++ (Ubuntu 4.3.1-7ubuntu1) version 4.3.1 (i486-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=98 --param ggc-min-heapsize=129034
Compiler executable checksum: 8789ae6462ba1c03375bc751bf9f310c
gcc-ice.cpp: In function ‘int main()’:
gcc-ice.cpp:20: error: unrecognizable insn:
(insn:TI 7 6 41 gcc-ice.cpp:13 (parallel [
(set (reg:SF 8 st)
(asm_operands:SF ("fld  %0
fld %%st(0)
fisttp %1
fild%1
fxch
fsub%%st(1),%%st(0)
") ("=&t") 0 [
(reg:SF 8 st)
]
 [
(asm_input:SF ("f") 0)
] 2058))
(set (mem/c/i:SI (plus:SI (reg/f:SI 6 bp)
(const_int -8 [0xfff8])) [2 tmp+0 S4 A32])
(asm_operands:SI ("fld  %0
fld %%st(0)
fisttp %1
fild%1
fxch
fsub%%st(1),%%st(0)
") ("=m") 1 [
(reg:SF 8 st)
]
 [
(asm_input:SF ("f") 0)
] 2058))
(clobber (reg:QI 18 fpsr))
(clobber (reg:QI 17 flags))
]) -1 (expr_list:REG_DEAD (reg:SF 8 st)
(expr_list:REG_UNUSED (reg:QI 18 fpsr)
(expr_list:REG_UNUSED (reg:QI 17 flags)
(expr_list:REG_UNUSED (reg:SF 8 st)
(nil))
gcc-ice.cpp:20: internal compiler error: in extract_constrain_insn_cached, at
recog.c:1907
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 
   Summary: Crashes with FPU inline-assembly
   Product: gcc
   Version: 4.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: inline-asm
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tobias dot doerffel at gmail 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=36923

[Bug tree-optimization/36922] New: ICE in tree-data-ref.c with -ftree-loop-linear

[pthaugen at gcc dot gnu dot org]

Current trunk is ICE'ing when trying to build CPU2006 benchmark 416.gamess with
-ftree-loop-linear.

run/build_base_gcc_64.0001> cat junk.f
  SUBROUTINE GETCOF2(NP,FLM,ZLL,COEFF)
C
  IMPLICIT DOUBLE PRECISION(A-H,O-Z)
  PARAMETER (MAXCOF=23821)
  DIMENSION COEFF(MAXCOF),
 *  ZLL(0:2*NP+1),FLM(0:2*NP)
C
  LENG=0
  DO L=0,NP
 DO M=0,L
DO LK=M,L
   LENG=LENG+1
   COEFF(LENG)=FLM(L+M)*FLM(L-M)*ZLL(L-LK)/(FLM(LK+M)*
 * FLM(LK-M)*FLM(L-LK)*FLM(L-LK))
ENDDO
 ENDDO
  ENDDO
C
  RETURN
  END

run/build_base_gcc_64.0001> /home/pthaugen/install/gcc/trunk/bin/gfortran -c
-O2 -ftree-loop-linear junk.f
junk.f: In function 'getcof2':
junk.f:1: internal compiler error: in initialize_matrix_A, at
tree-data-ref.c:1885
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 
   Summary: ICE in tree-data-ref.c with -ftree-loop-linear
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pthaugen at gcc dot gnu dot org
 GCC build triplet: powerpc64-linux
  GCC host triplet: powerpc64-linux
GCC target triplet: powerpc64-linux


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

[Bug c++/36921] comparsion does not have mathematical meaning is not correct

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2008-07-24 20:30 ---
Example?


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|comparsion does not have|comparsion does not have
   |mathematical meaning is not |mathematical meaning is not
   |correct |correct


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

[Bug bootstrap/36907] [4.4 Regression]: Gcc failed to bootstrap

[hjl dot tools at gmail dot com]

--- Comment #21 from hjl dot tools at gmail dot com  2008-07-24 20:29 
---
(In reply to comment #18)
>
> 
> +#ifdef SECONDARY_OVERRIDE_OPTIONS
> +  /* Some machines may reject certain combinations of options.  */
> +  if (! first_time_p)
> +SECONDARY_OVERRIDE_OPTIONS;
> +#endif
> +
>  #ifdef OPTIMIZATION_OPTIONS
>/* Allow default optimizations to be specified on a per-machine basis.  */
>OPTIMIZATION_OPTIONS (optimize, optimize_size);
> Index: gcc/config/ia64/ia64.h
> ===
> --- gcc/config/ia64/ia64.h  (revision 138117)
> +++ gcc/config/ia64/ia64.h  (working copy)
> @@ -121,6 +121,11 @@ extern enum processor_type ia64_tune;
> 
>  #define OVERRIDE_OPTIONS ia64_override_options ()
> 
> +/* Like OVERRIDE_OPTIONS, but run after the optimize, hot, or cold attributes
> +   are processed.  */
> +
> +#define SECONDARY_OVERRIDE_OPTIONS ia64_override_options ()
> +

I think we should just do

#ifdef SECONDARY_OVERRIDE_OPTIONS
  /* Some machines may reject certain combinations of options.  */
  SECONDARY_OVERRIDE_OPTIONS;
#endif

#define SECONDARY_OVERRIDE_OPTIONS ia64_secondary_override_options ()



void
ia64_override_options (void)
{
  if (TARGET_AUTO_PIC)
target_flags |= MASK_CONST_GP;

  if (TARGET_INLINE_SQRT == INL_MIN_LAT)
{
  warning (0, "not yet implemented: latency-optimized inline square root");
  TARGET_INLINE_SQRT = INL_MAX_THR;
}  

   ia64_section_threshold = g_switch_set ? g_switch_value :
IA64_DEFAULT_GVALUE;

  init_machine_status = ia64_init_machine_status;
}

void
ia64_secondary_override_options ()
{
  ia64_flag_schedule_insns2 = flag_schedule_insns_after_reload;
  flag_schedule_insns_after_reload = 0;
}


-- 


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

[Bug c++/36921] New: comparsion does not have mathematical meaning is not correct

[deba at inf dot elte dot hu]

In c++ the operators could be overloaded, therefore in special cases it could
have real and correct mathematical meaning. In my opinion, the bool-numeric
comparisons should be warned instead of the current solution.


-- 
   Summary: comparsion does not have mathematical meaning is not
correct
   Product: gcc
   Version: 4.3.1
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: deba at inf dot elte dot hu
 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=36921

[Bug target/36806] [4.4 Regression] I/Os hang at rev. 137631 on darwin9

[andreast at gcc dot gnu dot org]

--- Comment #18 from andreast at gcc dot gnu dot org  2008-07-24 20:23 
---
I confirm that i686-apple-darwin on tuples branch does _not_ hang in these test
cases

Proposal, I know about plans to merge tuples in the next few days to trunk, so
we wait until this merge happened and see how things go, ok?


-- 


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

[Bug bootstrap/36907] [4.4 Regression]: Gcc failed to bootstrap

[gnu at the-meissners dot org]

--- Comment #20 from gnu at the-meissners dot org  2008-07-24 20:21 ---
Subject: Re:  [4.4 Regression]: Gcc failed to bootstrap

On Thu, Jul 24, 2008 at 08:14:35PM -, hjl dot tools at gmail dot com wrote:
> 
> 
> --- Comment #19 from hjl dot tools at gmail dot com  2008-07-24 20:14 
> ---
> (In reply to comment #18)
> > Subject: Re:  [4.4 Regression]: Gcc failed to bootstrap
> > 
> > Yes, I came to the same conclusion when trying a bootstrap.  This patch 
> > adds a
> > new SECONDARY_OVERRIDE_OPTION to be run in the recursive case, and defined 
> > it
> > in the ia64.
> > 
> 
> Don't we also need it for i386 to handle
> 
>   /* When scheduling description is not available, disable scheduler pass
>  so it won't slow down the compilation and make x87 code slower.  */
>   if (!TARGET_SCHEDULE)
> flag_schedule_insns_after_reload = flag_schedule_insns = 0;

You are right those should be added.


-- 


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

[Bug bootstrap/36907] [4.4 Regression]: Gcc failed to bootstrap

[hjl dot tools at gmail dot com]

--- Comment #19 from hjl dot tools at gmail dot com  2008-07-24 20:14 
---
(In reply to comment #18)
> Subject: Re:  [4.4 Regression]: Gcc failed to bootstrap
> 
> Yes, I came to the same conclusion when trying a bootstrap.  This patch adds a
> new SECONDARY_OVERRIDE_OPTION to be run in the recursive case, and defined it
> in the ia64.
> 

Don't we also need it for i386 to handle

  /* When scheduling description is not available, disable scheduler pass
 so it won't slow down the compilation and make x87 code slower.  */
  if (!TARGET_SCHEDULE)
flag_schedule_insns_after_reload = flag_schedule_insns = 0;


-- 


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

[Bug bootstrap/36907] [4.4 Regression]: Gcc failed to bootstrap

[gnu at the-meissners dot org]

--- Comment #18 from gnu at the-meissners dot org  2008-07-24 20:11 ---
Subject: Re:  [4.4 Regression]: Gcc failed to bootstrap

On Thu, Jul 24, 2008 at 07:33:01PM -, hjl dot tools at gmail dot com wrote:
> 
> 
> --- Comment #17 from hjl dot tools at gmail dot com  2008-07-24 19:32 
> ---
> (In reply to comment #16)
> > I haven't done a bootstrap built yet, but could you try this patch on the
> > ia-64?  When I try it via a cross compiler, it works fine, but I wonder 
> > whether
> > random ports will do weird things (like leak memory) if OVERRIDE_OPTIONS is 
> > run
> > a second time.  I suspect we may need a macro that says whether it is safe 
> > to
> > run OVERRIDE_OPTIONS a second time.
> > 
> > 2008-07-24  Michael Meissner  <[EMAIL PROTECTED]>
> > 
> > * opts.c (decode_options): Rerun OVERRIDE_OPTIONS when being run a
> > second time to allow the backend to override the default options.
> > 
> 
> Taking a look at override_options in i386.c, I am not sure
> running it more than once is a good idea.

Yes, I came to the same conclusion when trying a bootstrap.  This patch adds a
new SECONDARY_OVERRIDE_OPTION to be run in the recursive case, and defined it
in the ia64.

2008-07-24  Michael Meissner  <[EMAIL PROTECTED]>

* opts.c (decode_options): Run SECONDARY_OVERRIDE_OPTIONS if it is
defined when being run a second time to allow the backend to
override the default options.

* config/ia64/ia64.h (SECONDARY_OVERRIDE_OPTIONS): Define to be
the same as OVERRIDE_OPTIONS.

* doc/tm.texi (SECONDARY_OVERRIDE_OPTIONS): Document.

Index: gcc/doc/tm.texi
===
--- gcc/doc/tm.texi (revision 138117)
+++ gcc/doc/tm.texi (working copy)
@@ -814,6 +814,12 @@ Don't use this macro to turn on various 
 @option{-O}.  That is what @code{OPTIMIZATION_OPTIONS} is for.
 @end defmac

[EMAIL PROTECTED] SECONDARY_OVERRIDE_OPTIONS
+This is similar to @code{OVERRIDE_OPTIONS} but it is run after the
+compiler processes the @code{optimize}, @code{hot}, or @code{cold}
+attributes to change the optimization options.
[EMAIL PROTECTED] defmac
+
 @defmac C_COMMON_OVERRIDE_OPTIONS
 This is similar to @code{OVERRIDE_OPTIONS} but is only used in the C
 language frontends (C, Objective-C, C++, Objective-C++) and so can be
Index: gcc/opts.c
===
--- gcc/opts.c  (revision 138117)
+++ gcc/opts.c  (working copy)
@@ -1066,6 +1066,12 @@ decode_options (unsigned int argc, const
   flag_unwind_tables = targetm.unwind_tables_default;
 }

+#ifdef SECONDARY_OVERRIDE_OPTIONS
+  /* Some machines may reject certain combinations of options.  */
+  if (! first_time_p)
+SECONDARY_OVERRIDE_OPTIONS;
+#endif
+
 #ifdef OPTIMIZATION_OPTIONS
   /* Allow default optimizations to be specified on a per-machine basis.  */
   OPTIMIZATION_OPTIONS (optimize, optimize_size);
Index: gcc/config/ia64/ia64.h
===
--- gcc/config/ia64/ia64.h  (revision 138117)
+++ gcc/config/ia64/ia64.h  (working copy)
@@ -121,6 +121,11 @@ extern enum processor_type ia64_tune;

 #define OVERRIDE_OPTIONS ia64_override_options ()

+/* Like OVERRIDE_OPTIONS, but run after the optimize, hot, or cold attributes
+   are processed.  */
+
+#define SECONDARY_OVERRIDE_OPTIONS ia64_override_options ()
+
 /* Some machines may desire to change what optimizations are performed for
various optimization levels.  This macro, if defined, is executed once just
after the optimization level is determined and before the remainder of the


-- 


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

[Bug target/36920] internal compiler error building libicu package

[john dot spelis at 3dlabs dot com]

--- Comment #3 from john dot spelis at 3dlabs dot com  2008-07-24 20:02 
---
Created an attachment (id=15956)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15956&action=view)
output file from save-temp


-- 


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

[Bug target/36920] internal compiler error building libicu package

[john dot spelis at 3dlabs dot com]

--- Comment #2 from john dot spelis at 3dlabs dot com  2008-07-24 20:01 
---
Created an attachment (id=15955)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15955&action=view)
save-temps output


-- 


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

[Bug c++/36920] internal compiler error building libicu package

[john dot spelis at 3dlabs dot com]

--- Comment #1 from john dot spelis at 3dlabs dot com  2008-07-24 20:01 
---
Created an attachment (id=15954)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15954&action=view)
save-temps file


-- 


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

[Bug c++/36920] New: internal compiler error building libicu package

[john dot spelis at 3dlabs dot com]

Building libicu from

 http://packages.ubuntu.com/hardy/libicu38

using

   configure --build=i686-pc-linux-gnu --host=arm-3d-linux-gnueabi
   make

Configured and built without issue for a while then blew up;

 arm-3d-linux-gnueabi-g++ -D_REENTRANT \
   -I../common -I/tmp/icu/icu-3.8/icu/source/i18n \
   -I/tmp/icu/icu-3.8/icu/source/common   \
   -DU_I18N_IMPLEMENTATION -g -O2  -fvisibility=hidden \
   -c -DPIC -fPIC -o rematch.o \
   /tmp/icu/icu-3.8/icu/source/i18n/rematch.cpp

/tmp/icu/icu-3.8/icu/source/i18n/rematch.cpp: In member function
   void icu_3_8::RegexMatcher::MatchAt(int32_t, UErrorCode&):
/tmp/icu/icu-3.8/icu/source/i18n/rematch.cpp:2290:
error: unrecognizable insn:
(insn 4205 1393 1395 183 /tmp/icu/icu-3.8/icu/source/i18n/rematch.cpp:1462
(set (reg:SI 8 r8)
(plus:SI (reg:SI 3 r3 [971])
(mult:SI (reg/v:SI 14 lr [orig:254 opValue.2027 ] [254])
(const_int 32 [0x20] -1 (nil))
/tmp/icu/icu-3.8/icu/source/i18n/rematch.cpp:2290:
   internal compiler error: in extract_insn, at recog.c:1990
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[1]: *** [rematch.o] Error 1
make[1]: Leaving directory `/tmp/icu/icu-3.8/icu/work/i18n'
make: *** [all-recursive] Error 2

Workaround:
  Avoid using "-O2" on the compile line for the rematch.cpp source.
  This can be done in the pre-configured source by patching;

 icu-3.8/icu/source/i18n/Makefile.in

 after the entry

  "all-local: $(ALL_TARGETS)"

 add

  rematch.o: $(srcdir)/rematch.cpp
$(CXX) $(CPPFLAGS) $(DEFS) -c -o $@ $<


-- 
   Summary: internal compiler error building libicu package
   Product: gcc
   Version: 4.3.0
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: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: arm-3d-linux-gnueabi


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

[Bug bootstrap/36918] [4.4 regression] Bootstrap failure on sparc: assertion failure in options.c

[andreast at gcc dot gnu dot org]

--- Comment #6 from andreast at gcc dot gnu dot org  2008-07-24 19:50 
---
Patch:
http://gcc.gnu.org/ml/gcc-patches/2008-07/msg01916.html


-- 


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

[Bug target/36047] -pg does not work on large binaries and m68k

[gcc at breakpoint dot cc]

--- Comment #1 from gcc at breakpoint dot cc  2008-07-24 19:48 ---
Does anybody care about this bug?


-- 


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

[Bug bootstrap/36907] [4.4 Regression]: Gcc failed to bootstrap

[hjl dot tools at gmail dot com]

--- Comment #17 from hjl dot tools at gmail dot com  2008-07-24 19:32 
---
(In reply to comment #16)
> I haven't done a bootstrap built yet, but could you try this patch on the
> ia-64?  When I try it via a cross compiler, it works fine, but I wonder 
> whether
> random ports will do weird things (like leak memory) if OVERRIDE_OPTIONS is 
> run
> a second time.  I suspect we may need a macro that says whether it is safe to
> run OVERRIDE_OPTIONS a second time.
> 
> 2008-07-24  Michael Meissner  <[EMAIL PROTECTED]>
> 
> * opts.c (decode_options): Rerun OVERRIDE_OPTIONS when being run a
> second time to allow the backend to override the default options.
> 

Taking a look at override_options in i386.c, I am not sure
running it more than once is a good idea.


-- 


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

[Bug bootstrap/36907] [4.4 Regression]: Gcc failed to bootstrap

[gnu at the-meissners dot org]

--- Comment #16 from gnu at the-meissners dot org  2008-07-24 19:19 ---
Subject: Re:  [4.4 Regression]: Gcc failed to bootstrap

On Thu, Jul 24, 2008 at 05:49:02PM -, hjl dot tools at gmail dot com wrote:
> 
> 
> --- Comment #15 from hjl dot tools at gmail dot com  2008-07-24 17:49 
> ---
> I don't think the middle-end should change optimization options
> which have been overridden by the backend.
> 
> 
> -- 
> 
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36907
> 
> --- You are receiving this mail because: ---
> You are on the CC list for the bug, or are watching someone who is.

I haven't done a bootstrap built yet, but could you try this patch on the
ia-64?  When I try it via a cross compiler, it works fine, but I wonder whether
random ports will do weird things (like leak memory) if OVERRIDE_OPTIONS is run
a second time.  I suspect we may need a macro that says whether it is safe to
run OVERRIDE_OPTIONS a second time.

2008-07-24  Michael Meissner  <[EMAIL PROTECTED]>

* opts.c (decode_options): Rerun OVERRIDE_OPTIONS when being run a
second time to allow the backend to override the default options.

Index: gcc/opts.c
===
--- gcc/opts.c  (revision 138117)
+++ gcc/opts.c  (working copy)
@@ -1066,6 +1066,12 @@ decode_options (unsigned int argc, const
   flag_unwind_tables = targetm.unwind_tables_default;
 }

+#ifdef OVERRIDE_OPTIONS
+  /* Some machines may reject certain combinations of options.  */
+  if (! first_time_p)
+OVERRIDE_OPTIONS;
+#endif
+
 #ifdef OPTIMIZATION_OPTIONS
   /* Allow default optimizations to be specified on a per-machine basis.  */
   OPTIMIZATION_OPTIONS (optimize, optimize_size);


-- 


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

[Bug fortran/33141] Intrinsic procedures: Improve warning/error with -std=*

[domob at gcc dot gnu dot org]

--- Comment #9 from domob at gcc dot gnu dot org  2008-07-24 19:16 ---
Resolving fixed, discussion on better option names and minor changes welcome :)


-- 

domob at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug target/35936] Cannot compile libgcc.S on avr

[eric dot weddington at atmel dot com]

--- Comment #1 from eric dot weddington at atmel dot com  2008-07-24 19:13 
---
What 4.4 snapshot did you use to build?

I'm getting something very similar, but it's for avr5, not avr3:

../../../../gcc-4.4-20080718/libgcc/../gcc/config/avr/libgcc.S: Assembler
messages:
../../../../gcc-4.4-20080718/libgcc/../gcc/config/avr/libgcc.S:718: Error:
illegal opcode elpm for mcu avr5
make[4]: *** [_copy_data.o] Error 1
make[4]: Leaving directory `/usr/local/avrdev/gcc/build/avr/avr51/libgcc'
make[3]: *** [multi-do] Error 1
make[3]: Leaving directory `/usr/local/avrdev/gcc/build/avr/libgcc'
make[2]: *** [all-multi] Error 2
make[2]: Leaving directory `/usr/local/avrdev/gcc/build/avr/libgcc'
make[1]: *** [all-target-libgcc] Error 2
make[1]: Leaving directory `/usr/local/avrdev/gcc/build'
make: *** [all] Error 2


-- 


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

[Bug target/36806] [4.4 Regression] I/Os hang at rev. 137631 on darwin9

[andreast at gcc dot gnu dot org]

--- Comment #17 from andreast at gcc dot gnu dot org  2008-07-24 19:03 
---
Just a comment, on the tuples branch, merged from main on 2008-07-23, the hangs
do not happen anymore. At least on x86_64-apple-darwin. i686-apple-darwin build
in progress.


-- 


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

[Bug bootstrap/36919] New: [4.4 regression] Bootstrap failure on IRIX 6.5: unrecognizable insn in errors.c

[ro at gcc dot gnu dot org]

As of 20080724, mainline fails to bootstrap on IRIX 6.5:

/vol/gccsrc/obj/gcc-4.4.0-20080724/6.5-gcc/./prev-gcc/xgcc
-B/vol/gccsrc/obj/gcc-4.4.0-20080724/6.5-gcc/./prev-gcc/
-B/vol/gcc/mips-sgi-irix6.5/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 -DGENERATOR_FILE -I. -Ibuild
-I/vol/gcc/src/gcc-dist/gcc -I/vol/gcc/src/gcc-dist/gcc/build
-I/vol/gcc/src/gcc-dist/gcc/../include
-I/vol/gcc/src/gcc-dist/gcc/../libcpp/include -I/vol/gcc/include
-I/vol/gcc/include -I/vol/gcc/src/gcc-dist/gcc/../libdecnumber
-I/vol/gcc/src/gcc-dist/gcc/../libdecnumber/dpd -I../libdecnumber  -o
build/errors.o /vol/gcc/src/gcc-dist/gcc/errors.c
/vol/gcc/src/gcc-dist/gcc/errors.c: In function 'trim_filename':
/vol/gcc/src/gcc-dist/gcc/errors.c:124: error: unrecognizable insn:
(insn 154 139 49 /vol/gcc/src/gcc-dist/gcc/errors.c:116 (sequence [
(jump_insn 43 139 45 /vol/gcc/src/gcc-dist/gcc/errors.c:116 (set
(pc
)
(if_then_else (ne (reg:SI 3 $3 [235])
(reg:SI 2 $2 [236]))
(label_ref:SI 90)
(pc))) 423 {*branch_equalitysi} (expr_list:REG_BR_PRED
(const_int 49 [0x31])
(expr_list:REG_DEAD (reg:SI 3 $3 [235])
(expr_list:REG_DEAD (reg:SI 2 $2 [236])
(expr_list:REG_EQUAL (if_then_else (ne (reg:SI 3 $3
[235])
(const_int 47 [0x2f]))
(label_ref:SI 90)
(pc))
(expr_list:REG_BR_PROB (const_int 300 [0x12c])
(nil)))
(insn 45 43 49 (set (reg/v/f:SI 5 $5 [orig:231 p ] [231])
(reg/v/f:SI 4 $4 [orig:234 name ] [234])) 252
{*movsi_internal} (nil))
]) -1 (nil))
/vol/gcc/src/gcc-dist/gcc/errors.c:124: internal compiler error: in
num_delay_slots, at config/mips/mips.md:863

I've last bootstrapped successfully on 20080613.


-- 
   Summary: [4.4 regression] Bootstrap failure on IRIX 6.5:
unrecognizable insn in errors.c
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ro at gcc dot gnu dot org
GCC target triplet: mips-sgi-irix6.5


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

[Bug middle-end/36885] [TUPLES] tuples branch bootstrap failure in libstdc++-v3

[andreast at gcc dot gnu dot org]

--- Comment #14 from andreast at gcc dot gnu dot org  2008-07-24 18:58 
---
Bootstrap passed. Tests will start soon.
Thanks.


-- 

andreast at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug fortran/33141] Intrinsic procedures: Improve warning/error with -std=*

[domob at gcc dot gnu dot org]

--- Comment #8 from domob at gcc dot gnu dot org  2008-07-24 18:53 ---
Subject: Bug 33141

Author: domob
Date: Thu Jul 24 18:52:51 2008
New Revision: 138122

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=138122
Log:
2008-07-24  Daniel Kraft  <[EMAIL PROTECTED]>

PR fortran/33141
* lang.opt (Wnonstd-intrinsics):  Removed option.
(Wintrinsics-std), (Wintrinsic-shadow):  New options.
* invoke.texi (Option Summary):  Removed -Wnonstd-intrinsics
from the list and added -Wintrinsics-std and -Wintrinsic-shadow.
(Error and Warning Options):  Documented the new options and removed
the documentation for -Wnonstd-intrinsics.
* gfortran.h (gfc_option_t):  New members warn_intrinsic_shadow and
warn_intrinsics_std, removed warn_nonstd_intrinsics.
(gfc_is_intrinsic):  Renamed from gfc_intrinsic_name.
(gfc_warn_intrinsic_shadow), (gfc_check_intrinsic_standard):  New.
* decl.c (match_procedure_decl):  Replaced gfc_intrinsic_name by
the new name gfc_is_intrinsic.
(warn_intrinsic_shadow):  New helper method.
(gfc_match_function_decl), (gfc_match_subroutine):  Call the new method
warn_intrinsic_shadow to check the just-parsed procedure.
* expr.c (check_init_expr):  Call new gfc_is_intrinsic to check whether
the function called is really an intrinsic in the selected standard.
* intrinsic.c (gfc_is_intrinsic):  Renamed from gfc_intrinsic_name and
extended to take into account the selected standard settings when
trying
to find out whether a symbol is an intrinsic or not.
(gfc_check_intrinsic_standard):  Made public and extended.
(gfc_intrinsic_func_interface), (gfc_intrinsic_sub_interface):  Removed
the calls to check_intrinsic_standard, this check now happens inside
gfc_is_intrinsic.
(gfc_warn_intrinsic_shadow):  New method defined.
* options.c (gfc_init_options):  Initialize new warning flags to false
and removed intialization of Wnonstd-intrinsics flag.
(gfc_post_options):  Removed logic for Wnonstd-intrinsics flag.
(set_Wall):  Set new warning flags and removed Wnonstd-intrinsics flag.
(gfc_handle_option):  Handle the new flags and removed handling of the
old Wnonstd-intrinsics flag.
* primary.c (gfc_match_rvalue):  Replaced call to gfc_intrinsic_name by
the new name gfc_is_intrinsic.
* resolve.c (resolve_actual_arglist):  Ditto.
(resolve_generic_f), (resolve_unknown_f):  Ditto.
(is_external_proc):  Ditto.
(resolve_generic_s), (resolve_unknown_s):  Ditto.
(resolve_symbol):  Ditto and ensure for symbols declared INTRINSIC that
they are really available in the selected standard setting.

2008-07-24  Daniel Kraft  <[EMAIL PROTECTED]>

PR fortran/33141
* gfortran.dg/intrinsic_shadow_1.f03:  New test for -Wintrinsic-shadow.
* gfortran.dg/intrinsic_shadow_2.f03:  Ditto.
* gfortran.dg/intrinsic_shadow_3.f03:  Ditto.
* gfortran.dg/intrinsic_std_1.f90:  New test for -Wintrinsics-std.
* gfortran.dg/intrinsic_std_2.f90:  Ditto.
* gfortran.dg/intrinsic_std_3.f90:  Ditto.
* gfortran.dg/intrinsic_std_4.f90:  Ditto.
* gfortran.dg/warn_std_1.f90:  Removed option -Wnonstd-intrinsics.
* gfortran.dg/warn_std_2.f90:  Replaced -Wnonstd-intrinsics by
-Wintrinsics-std and adapted expected errors/warnings.
* gfortran.dg/warn_std_3.f90:  Ditto.
* gfortran.dg/c_sizeof_2.f90:  Adapted expected error/warning message.
* gfortran.dg/gamma_2.f90:  Ditto.
* gfortran.dg/selected_char_kind_3.f90:  Ditto.
* gfortran.dg/fmt_g0_2.f08:  Call with -fall-intrinsics to allow abort.


Added:
trunk/gcc/testsuite/gfortran.dg/intrinsic_shadow_1.f03
trunk/gcc/testsuite/gfortran.dg/intrinsic_shadow_2.f03
trunk/gcc/testsuite/gfortran.dg/intrinsic_shadow_3.f03
trunk/gcc/testsuite/gfortran.dg/intrinsic_std_1.f90
trunk/gcc/testsuite/gfortran.dg/intrinsic_std_2.f90
trunk/gcc/testsuite/gfortran.dg/intrinsic_std_3.f90
trunk/gcc/testsuite/gfortran.dg/intrinsic_std_4.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/decl.c
trunk/gcc/fortran/expr.c
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/intrinsic.c
trunk/gcc/fortran/invoke.texi
trunk/gcc/fortran/lang.opt
trunk/gcc/fortran/options.c
trunk/gcc/fortran/primary.c
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/c_sizeof_2.f90
trunk/gcc/testsuite/gfortran.dg/fmt_g0_2.f08
trunk/gcc/testsuite/gfortran.dg/gamma_2.f90
trunk/gcc/testsuite/gfortran.dg/selected_char_kind_3.f90
trunk/gcc/testsuite/gfortran.dg/warn_std_1.f90
trunk/gcc/testsuite/gfortran.dg/warn_std_2.f90
trunk/gcc/testsuite/gfortran.dg/warn_std_3.f90


-- 


http:/

[Bug bootstrap/36918] [4.4 regression] Bootstrap failure on sparc: assertion failure in options.c

[gnu at the-meissners dot org]

--- Comment #5 from gnu at the-meissners dot org  2008-07-24 18:49 ---
Subject: Re:  [4.4 regression] Bootstrap failure on
sparc: assertion failure in options.c

On Thu, Jul 24, 2008 at 06:36:20PM -, andreast at gcc dot gnu dot org
wrote:
> 
> 
> --- Comment #3 from andreast at gcc dot gnu dot org  2008-07-24 18:36 
> ---
> I bootstrapped choice 1. No regressions.
> 
> I also prefer to save space where possible. So I'd like to avoid choice 3.
> 
> Can we also use 255 or 127 as value for DEFAULT_PCC_STRUCT_RETURN?

Just to echo what I said in IRC for bugzilla, right now you can use 255 or 127.
Using 127 is perhaps better in case the default is changed to use signed bytes
in the future, and 127 will work either way.


-- 


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

[Bug bootstrap/36918] [4.4 regression] Bootstrap failure on sparc: assertion failure in options.c

[andreast at gcc dot gnu dot org]

--- Comment #3 from andreast at gcc dot gnu dot org  2008-07-24 18:36 
---
I bootstrapped choice 1. No regressions.

I also prefer to save space where possible. So I'd like to avoid choice 3.

Can we also use 255 or 127 as value for DEFAULT_PCC_STRUCT_RETURN?


-- 

andreast at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||andreast at gcc dot gnu dot
   ||org
 AssignedTo|unassigned at gcc dot gnu   |andreast at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-07-24 18:36:20
   date||


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

[Bug bootstrap/36918] [4.4 regression] Bootstrap failure on sparc: assertion failure in options.c

[gnu at the-meissners dot org]

--- Comment #2 from gnu at the-meissners dot org  2008-07-24 18:26 ---
Subject: Re:  [4.4 regression] Bootstrap failure on
sparc: assertion failure in options.c

On Thu, Jul 24, 2008 at 05:21:10PM -, ro at gcc dot gnu dot org wrote:
> 
> 
> --- Comment #1 from ro at gcc dot gnu dot org  2008-07-24 17:21 ---
> Michael, could you have a look?  This seems to have been introduced by this
> change:
> 
> 2008-07-23  Michael Meissner  <[EMAIL PROTECTED]>
> Karthik Kumar  <[EMAIL PROTECTED]>
> [...]
> * optc-gen.awk: Add support for TargetSave to allow a back end to
> declare new fields that need to be saved when using function
> specific options.  Include flags.h and target.h in the options.c
> source.  Add support for Save to indicate which options can be set
> for individual functions.  Generate cl_optimize_save,
> cl_optimize_restore, cl_optimize_print, cl_target_option_save,
> cl_target_option_restore, cl_target_option_print functions to
> allow functions to use different optimization or target options.
> 
> and sparc-sun-solaris2.10 is primary platform for 4.4.
> 
> 
> -- 
> 
> ro at gcc dot gnu dot org changed:
> 
>What|Removed |Added
> 
>  CC||gnu at the-meissners dot org
> 
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36918
> 
> --- You are receiving this mail because: ---
> You are on the CC list for the bug, or are watching someone who is.

This is due to DEFAULT_PCC_STRUCT_RETURN being defined as -1.  The code to
store and restore optimization options is trying to use smaller amount of
space, and so it stores the flag values into an unsigned byte instead of an
int.  The code in question is doing an assert to make sure that the value is in
range, so that when the value is restored, it get the same value.

Three possible solutions exist:
1) In sparc.h change DEFAULT_PCC_STRUCT_RETURN to be 2 instead of -1;
2) Change the default space to be signed bytes instead of unsigned;
3) Save ints instead of bytes and don't try to save space.


-- 


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

[Bug bootstrap/36907] [4.4 Regression]: Gcc failed to bootstrap

[hjl dot tools at gmail dot com]

--- Comment #15 from hjl dot tools at gmail dot com  2008-07-24 17:49 
---
I don't think the middle-end should change optimization options
which have been overridden by the backend.


-- 


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

[Bug bootstrap/36907] [4.4 Regression]: Gcc failed to bootstrap

[hjl dot tools at gmail dot com]

--- Comment #14 from hjl dot tools at gmail dot com  2008-07-24 17:41 
---
The following targets are affected by revision 138075:

arm/arm.c:flag_schedule_insns = flag_schedule_insns_after_reload = 0;
bfin/bfin.c:  bfin_flag_var_tracking = flag_var_tracking;
bfin/bfin.c:  bfin_flag_schedule_insns2 = flag_schedule_insns_after_reload;
i386/i386.c:flag_schedule_insns_after_reload = flag_schedule_insns = 0;
ia64/ia64.c:  ia64_flag_var_tracking = flag_var_tracking;
ia64/ia64.c:  ia64_flag_schedule_insns2 = flag_schedule_insns_after_reload;

Michael, I think your patch changes the x86 backend:

  /* When scheduling description is not available, disable scheduler pass
 so it won't slow down the compilation and make x87 code slower.  */
  if (!TARGET_SCHEDULE)
flag_schedule_insns_after_reload = flag_schedule_insns = 0;

You may set flag_schedule_insns_after_reload and flag_schedule_insns
while they should be cleared.


-- 


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

[Bug bootstrap/36918] [4.4 regression] Bootstrap failure on sparc: assertion failure in options.c

[ro at gcc dot gnu dot org]

--- Comment #1 from ro at gcc dot gnu dot org  2008-07-24 17:21 ---
Michael, could you have a look?  This seems to have been introduced by this
change:

2008-07-23  Michael Meissner  <[EMAIL PROTECTED]>
Karthik Kumar  <[EMAIL PROTECTED]>
[...]
* optc-gen.awk: Add support for TargetSave to allow a back end to
declare new fields that need to be saved when using function
specific options.  Include flags.h and target.h in the options.c
source.  Add support for Save to indicate which options can be set
for individual functions.  Generate cl_optimize_save,
cl_optimize_restore, cl_optimize_print, cl_target_option_save,
cl_target_option_restore, cl_target_option_print functions to
allow functions to use different optimization or target options.

and sparc-sun-solaris2.10 is primary platform for 4.4.


-- 

ro at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||gnu at the-meissners dot org


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

[Bug bootstrap/36918] New: [4.4 regression] Bootstrap failure on sparc: assertion failure in options.c

[ro at gcc dot gnu dot org]

As of 20080724, mainline doesn't bootstrap on sparc-sun-solaris2.11 (and
probably
every sparc target) like this:

checking for suffix of object files... configure: error: in
`/vol/gccsrc/obj/gcc-4.4.0-20080724/11-gcc/sparc-sun-solaris2.11/libgcc':
configure: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.
make[2]: *** [configure-stage1-target-libgcc] Error 1

In config.log, I find

configure:2590: checking for suffix of object files
configure:2611: /vol/gccsrc/obj/gcc-4.4.0-20080724/11-gcc/./gcc/xgcc
-B/vol/gccsrc/obj/gcc-4.4.0-20080724/11-gcc/./gcc/
-B/vol/gcc/sparc-sun-solaris2.11/bin/ -B/vol/gcc/sparc-sun-solaris2.11/lib/
-isystem /vol/gcc/sparc-sun-solaris2.11/include -isystem
/vol/gcc/sparc-sun-solaris2.11/sys-include -c -g -O2conftest.c >&5
cc1: internal compiler error: in cl_optimization_save, at options.c:5066

options.c:5066 has

  gcc_assert (IN_RANGE (flag_pcc_struct_return, 0, 255));

The problem is obviously that DEFAULT_PCC_STRUCT_RETURN is -1 in
config/sparc/sparc.h, which works ok with the int flag_pcc_struct_return 
variable, but not with unsigned char flag_pcc_struct_return in options.h
(struct
cl_optimization).

I couldn't easily find my way through the maze of opt[ch]-gen.awk to fix this,
though.

One workaround might be to declare fpcc-struct-return in common.opt, like
e.g. align_functions.


-- 
   Summary: [4.4 regression] Bootstrap failure on sparc: assertion
failure in options.c
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ro at gcc dot gnu dot org
GCC target triplet: sparc-sun-solaris2*


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

[Bug fortran/36403] [4.4 Regression] Some fortran tests using eoshift fail on SH

[domob at gcc dot gnu dot org]

--- Comment #2 from domob at gcc dot gnu dot org  2008-07-24 17:03 ---
Isn't this maybe a general problem about optional string arguments?  Or is this
really a eoshift-specific problem?  I'm just thinking about a general solution
for this kind of problem if it isn't; in that case it would of course be a bit
ugly to have a gfc_conv_intrinsic_xxx function just for each intrinsic that
might get optional string arguments...


-- 


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

[Bug fortran/31243] truncating strings longer than 2**32 characters

[domob at gcc dot gnu dot org]

--- Comment #4 from domob at gcc dot gnu dot org  2008-07-24 16:31 ---
This seems to be still in there...  Any interest that I work on this?  What's
about emitting a warning if either len= or a substring-reference expression is
of a KIND that can have larger values than the machine can handle?  As
suggested in comment #2 by Tobias S.

That is truely not too difficult.  For constant expressions, one could also try
to give an error whenever the value is too large.  Should I work on this or do
you think that's not important or even wanted?


-- 


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

[Bug middle-end/36885] [TUPLES] tuples branch bootstrap failure in libstdc++-v3

[rguenth at gcc dot gnu dot org]

--- Comment #13 from rguenth at gcc dot gnu dot org  2008-07-24 16:12 
---
Subject: Bug 36885

Author: rguenth
Date: Thu Jul 24 16:11:28 2008
New Revision: 138121

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

PR middle-end/36885
* tree.c (walk_tree_1): Also walk CHANGE_DYNAMIC_TYPE_EXPR operands.
* gimple.c (gss_for_code): GIMPLE_CHANGE_DYNAMIC_TYPE is GSS_WITH_OPS.
* gsstruct.def (GSS_CHANGE_DYNAMIC_TYPE): Remove. 

Modified:
branches/gimple-tuples-branch/gcc/ChangeLog.tuples
branches/gimple-tuples-branch/gcc/gimple.c
branches/gimple-tuples-branch/gcc/gsstruct.def
branches/gimple-tuples-branch/gcc/tree.c


-- 


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

[Bug bootstrap/36907] [4.4 Regression]: Gcc failed to bootstrap

[hjl dot tools at gmail dot com]

--- Comment #13 from hjl dot tools at gmail dot com  2008-07-24 15:51 
---
ia64_override_options has

  ia64_flag_schedule_insns2 = flag_schedule_insns_after_reload;
  flag_schedule_insns_after_reload = 0;

If decode_options is called again without calling ia64_override_options,
ia64_flag_schedule_insns2 and flag_schedule_insns_after_reload may be
incorrect.


-- 


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

[Bug middle-end/36885] [TUPLES] tuples branch bootstrap failure in libstdc++-v3

[rguenth at gcc dot gnu dot org]

--- Comment #12 from rguenth at gcc dot gnu dot org  2008-07-24 15:51 
---
Can you re-test bootstrap with
http://gcc.gnu.org/ml/gcc-patches/2008-07/msg01896.html
applied?

Thanks.


-- 


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

[Bug middle-end/36885] [TUPLES] tuples branch bootstrap failure in libstdc++-v3

[rguenth at gcc dot gnu dot org]

--- Comment #11 from rguenth at gcc dot gnu dot org  2008-07-24 15:45 
---
I have a patch.


-- 

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 |2008-07-24 15:45:28
   date||


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

[Bug c/36869] OpenMP issue in gcc vs icc

[singler at gcc dot gnu dot org]

--- Comment #1 from singler at gcc dot gnu dot org  2008-07-24 15:02 ---
The test program is wrong. The loop counter i is not mentioned in the parallel
clause, so it is *shared*. Thus, the two loops interfere and the calculation of
pi goes wrong. Add private(i) to the clause or declare it locally and your
problem is fixed.


-- 

singler at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||singler at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug bootstrap/36907] [4.4 Regression]: Gcc failed to bootstrap

[hjl dot tools at gmail dot com]

--- Comment #12 from hjl dot tools at gmail dot com  2008-07-24 13:15 
---
[EMAIL PROTECTED] gcc]$ cat bar.i
typedef __builtin_va_list __gnuc_va_list;
extern void warning (int, const char *, ...) __attribute__ ((__format__
(__printf__, 2, 3))) __attribute__ ((__nonnull__ (2))) __attribute__
((__cold__));
extern void foo (const char *, __gnuc_va_list);
void
warning (int opt __attribute__ ((__unused__)), const char *format, ...)
{
  __gnuc_va_list ap;

  __builtin_va_start(ap,format);
  foo (format, ap);
  __builtin_va_end(ap);
}
[EMAIL PROTECTED] gcc]$ ../prev-gcc/xgcc -B../prev-gcc/ -O -S bar.i
bar.i: In function âwarningâ:
bar.i:12: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
[EMAIL PROTECTED] gcc]$


-- 


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

[Bug middle-end/36885] [TUPLES] tuples branch bootstrap failure in libstdc++-v3

[rguenth at gcc dot gnu dot org]

--- Comment #10 from rguenth at gcc dot gnu dot org  2008-07-24 14:34 
---
Created an attachment (id=15953)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15953&action=view)
reduced testcase

Reduced testcase, -O2 -g --param ggc-min-expand=0 --param ggc-min-heapsize=0


-- 


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

[Bug fortran/36915] Unneccessary array temporary for same_array_ptr = const * same_array_ptr

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2008-07-24 13:03 ---
See also PR36842 which would benefit as well.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu dot
   ||org
OtherBugsDependingO||36842
  nThis||


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

[Bug c/36913] rewind does not work for files over 8GB

[paolo dot carlini at oracle dot com]

--- Comment #3 from paolo dot carlini at oracle dot com  2008-07-24 12:44 
---
(In reply to comment #2)
> Do you imply that it's source is universal? If so, can it be true that the GNU
> implementation of some lower level function called by 'rewind' is incorrect?

I meant simply that one thing is the (C, whatever) compiler (this is the
Bugzilla for the GNU *compiler* collection), one thing is the C library. rewind
is a C library function. Likely you are experiencing a problem with the LFS
feature (support for files bigger than 2G on 32bit platforms) of your C
library. Please further investigate and then, in case, report about it in
proper place.


-- 


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

[Bug target/36840] Fortran complex array multiply missed optimization

[victork at gcc dot gnu dot org]

--- Comment #4 from victork at gcc dot gnu dot org  2008-07-24 12:30 ---
I'm going to submit a patch which will enable SLP vectorization on complex data
types. But SLP will handle only add, substruct, compare and other operations
which doesn't require permutation.

Adding ability to handle multiplication of complex numbers to SLP is not easy
since it will require "addsub" operation and ability to permute operands in
SLP.

Vectorization of complex numbers multiplication can be done by usual
interleaving loop vectorizer as it is already done for PowerPC. In order to
enable this on x86, permute operations should be modeled on x86 target - see
PR30211.

So, I think this PR should be considered duplicate of PR30211.


-- 


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

[Bug fortran/36915] Unneccessary array temporary for same_array_ptr = const * same_array_ptr

[dfranke at gcc dot gnu dot org]

--- Comment #1 from dfranke at gcc dot gnu dot org  2008-07-24 10:14 ---
Tobias, thanks for opening the PR.


-- 

dfranke at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||dfranke at gcc dot gnu dot
   ||org


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

[Bug tree-optimization/36917] [4.3 regression] miscompilation with -O2 and r136501

[rguenth at gcc dot gnu dot org]

--- Comment #9 from rguenth at gcc dot gnu dot org  2008-07-24 09:52 ---
The difference comes from the second VRP pass which concludes that c_76 is
[1, +INF] from which it changes

# c_173 = PHI <0(7), c_76(12)>

to

# c_173 = PHI <0(7), 1(12)>

which it concludes from

c_76 = (Cell) D.156138_4;

where Cell is

  enum Cell {
Cell_0
  };

so the only valid values for c_76 are 0 and 1.  The problem is probably here
(c is of type Cell):

  D.156112_62 = c_173 * 4;

(D.156112 is unsigned int), where we obviously miss a cast in the IL.

This is from inlining ciTypeFlow::StateVector::type_at which looks like

ciType* ciTypeFlow::StateVector::type_at(ciTypeFlow::Cell) const (this, c)
{
  struct ciType * D.144073;
  struct ciType * * D.144074;
  unsigned int D.144075;
  struct ciType * * D.144076;

  D.144074 = this->_types;
  D.144075 = c * 4;
  D.144076 = D.144074 + D.144075;
  D.144073 = *D.144076;
  return D.144073;
}

gimplified from

return  = *((struct ciType * *) ((const struct StateVector *)
this)->_types + (unsigned int) ((unsigned int) c * 4));

which hints at that c probably has the same precision and signedness as
unsigned int.


-- 


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

[Bug tree-optimization/36917] [4.3 regression] miscompilation with -O2 and r136501

[rguenth at gcc dot gnu dot org]

--- Comment #8 from rguenth at gcc dot gnu dot org  2008-07-24 09:31 ---
Looking at the source I don't see any integer overflows - the fact that
-fno-ivopts makes it work and the effect is on a variable introduced by
ivopts hints at a GCC bug more than a application bug.

So - now I cannot put the state back to UNCONFIRMED. :P


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-07-24 09:31:51
   date||


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

[Bug tree-optimization/36917] [4.3 regression] miscompilation with -O2 and r136501

[doko at ubuntu dot com]

--- Comment #7 from doko at ubuntu dot com  2008-07-24 09:31 ---
Created an attachment (id=15952)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15952&action=view)
preprocessed source (no pch used)


-- 


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

[Bug fortran/29952] Flag to give runtime information " array temporary was created for argument"

[tkoenig at gcc dot gnu dot org]

--- Comment #5 from tkoenig at gcc dot gnu dot org  2008-07-24 09:27 ---
Subject: Bug 29952

Author: tkoenig
Date: Thu Jul 24 09:26:43 2008
New Revision: 138112

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=138112
Log:
2008-07-24  Thomas Koenig  <[EMAIL PROTECTED]>

PR fortran/29952
* gfortran.h:  Add "warn_array_temp" to gfc_option_t.
* lang.opt:  Add -Warray-temporaries.
* invoke.texi:  Document -Warray-temporaries
* trans-array.h (gfc_trans_create_temp_array):  Add argument of
type *locus.
(gfc_conv_loop_setup):  Likewise.
* trans-array.c (gfc_trans_create_temp_array):  If
-Warray-temporaries is given and locus is present, warn about
creation of array temporaries.
(gfc_trans_array_constructor_subarray):  Add locus to call
of gfc_conv_loop_setup.
(gfc_trans_array_constructor):  Add where argument.  Pass where
argument to call of gfc_trans_create_temp_array.
(gfc_add_loop_ss_code):  Add where argument.  Pass where argument
to recursive call of gfc_add_loop_ss_code and to call of
gfc_trans_array_constructor.
(gfc_conv_loop_setup):  Add where argument.  Pass where argument
to calls to gfc_add_loop_ss_code and to gfc_trans_create_temp_array.
(gfc_conv_expr_descriptor):  Pass location to call of
gfc_conv_loop_setup.
(gfc_conv_array_parameter):  If -Warray-temporaries is given,
warn about creation of temporary arrays.
* trans-expr.c (gfc_conv_subref_array_arg):  Add where argument
to call to gfc_conv_loop_setup.
(gfc_conv_function_call):  Add where argument to call to
gfc_trans_creat_temp_array.
(gfc_trans_subarray_assign):  Likewise.
(gfc_trans_assignment_1):  Add where argument to call to
gfc_conv_loop_setup.
* trans-stmt.c (gfc_conv_elemental_dependencies):  Add where
argument to call to gfc_trans_create_temp_array.
(gfc_trans_call):  Add where argument to call to gfc_conv_loop_setup.
(generate_loop_for_temp_to_lhs):  Likewise.
(generate_loop_for_rhs_to_temp):  Likewise.
(compute_inner_temp_size):  Likewise.
(gfc_trans-pointer_assign_need_temp):  Likewise.
(gfc_evaluate_where_mask):  Likewise.
(gfc_trans_where_assign):  Likewise.
(gfc_trans_where_3):  Likewise.
* trans-io.c (transfer_srray_component):  Add where argument
to function. Add where argument to call to gfc_conv_loop_setup.
(transfer_expr):  Add where argument to call to
transfer_array_component.
(gfc_trans_transfer):  Add where expression to call to
gfc_conv_loop_setup.
* trans-intrinsic.c (gfc_conv_intrinsic_anyall):  Add
where argument to call to gfc_conv_loop_setup.
(gfc_conv_intrinsic_count):  Likewise.
(gfc_conv_intrinsic_arith):  Likewise.
(gfc_conv_intrinsic_dot_product):  Likewise.
(gfc_conv_intrinsic_minmaxloc):  Likewise.
(gfc_conv_intrinsic_minmaxval):  Likewise.
(gfc_conv_intrinsic_array_transfer):  Warn about
creation of temporary array.
Add where argument to call to gfc_trans_create_temp_array.
* options.c (gfc_init_options):  Initialize gfc_option.warn_array_temp.
(gfc_handle_option):  Set gfc_option.warn_array_temp.

2008-07-24  Thomas Koenig  <[EMAIL PROTECTED]>

PR fortran/29952
* gfortran.dg/array_temporaries_1.f90: New test case.


Added:
trunk/gcc/testsuite/gfortran.dg/array_temporaries_1.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/invoke.texi
trunk/gcc/fortran/lang.opt
trunk/gcc/fortran/options.c
trunk/gcc/fortran/trans-array.c
trunk/gcc/fortran/trans-array.h
trunk/gcc/fortran/trans-expr.c
trunk/gcc/fortran/trans-intrinsic.c
trunk/gcc/fortran/trans-io.c
trunk/gcc/fortran/trans-stmt.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug tree-optimization/36917] [4.3 regression] miscompilation with -O2 and r136501

[pinskia at gcc dot gnu dot org]

--- Comment #6 from pinskia at gcc dot gnu dot org  2008-07-24 09:27 ---
if -fwrapv works then is really a bug?  Yes overflow is defined in java but c++
is not java. 


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug tree-optimization/36917] [4.3 regression] miscompilation with -O2 and r136501

[doko at ubuntu dot com]

--- Comment #5 from doko at ubuntu dot com  2008-07-24 09:15 ---
-O3 and -fwrapv, r136501 not reverted works


-- 


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

[Bug tree-optimization/36917] [4.3 regression] miscompilation with -O2 and r136501

[doko at ubuntu dot com]

--- Comment #4 from doko at ubuntu dot com  2008-07-24 09:07 ---
Created an attachment (id=15951)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15951&action=view)
diff of tree dump


-- 


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

[Bug tree-optimization/36917] [4.3 regression] miscompilation with -O2 and r136501

[doko at ubuntu dot com]

--- Comment #3 from doko at ubuntu dot com  2008-07-24 09:06 ---
Created an attachment (id=15950)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15950&action=view)
tree dump (r136501)


-- 


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

[Bug tree-optimization/36917] [4.3 regression] miscompilation with -O2 and r136501

[doko at ubuntu dot com]

--- Comment #2 from doko at ubuntu dot com  2008-07-24 09:06 ---
Created an attachment (id=15949)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15949&action=view)
tree dump (r136501 reverted)


-- 


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

[Bug tree-optimization/36917] [4.3 regression] miscompilation with -O2 and r136501

[doko at ubuntu dot com]

--- Comment #1 from doko at ubuntu dot com  2008-07-24 09:05 ---
Created an attachment (id=15948)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15948&action=view)
preprocessed source


-- 


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

[Bug tree-optimization/36917] New: [4.3 regression] miscompilation with -O2 and r136501

[doko at ubuntu dot com]

OpenJDK (using the IcedTea6 build and patches) fails to build with 4.3 from the
4.3 branch, when the jvm built in stage1 is used for the first time in the
stage2 build:

-def-pcompile:
[javac] Compiling 2 source files to
/scratch/packages/openjdk/x/openjdk-6-6b11/openjdk/control/build/linux-i586/langtools/build/toolclasses
WARNING: Default charset US-ASCII not supported, using ISO-8859-1 instead
[javac]
/scratch/packages/openjdk/x/openjdk-6-6b11/openjdk/langtools/make/tools/CompileProperties/CompileProperties.java:26:
cannot access unnamed package
[javac] ANSI_X3.4-1968
[javac] import java.io.BufferedWriter;
[javac] ^

BUILD FAILED

the build failure is not seen when reverting r136501; seen as well when just
reverting the two hunks for record_numbers_of_iterations.

seen with -O3 and -O2, not -O1.

not seen on amd64 and sparc (the other two archs using OpenJDK hotspot).

the miscompiled file is ciTypeFlow.cpp, compiled using
g++-4.3 -fpic -fno-rtti -fno-exceptions -D_REENTRANT -fcheck-new -g -m32
-march=i586 -mtune=generic -O2 -fno-strict-aliasing -DVM_LITTLE_ENDIAN 
-Wpointer-arith -Wconversion -Wsign-compare -c ciTypeFlow.cpp


-- 
   Summary: [4.3 regression] miscompilation with -O2 and r136501
   Product: gcc
   Version: 4.3.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: doko at ubuntu dot com
GCC target triplet: i486-linux-gnu


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

[Bug fortran/36915] New: Unneccessary array temporary for same_array = scalar * same_array

[burnus at gcc dot gnu dot org]

Maybe this could be handled by the Middle End, once the array operations in the
ME are implemented. This would save us from checking the alias information in
the FE.

Regarding the "Middle-End Array Expressions", see:
http://www.gccsummit.org/2008/gcc-2008-proceedings.pdf, pp. 33-42.

 * * *

From: http://gcc.gnu.org/ml/fortran/2008-07/msg00166.html

PS The example from Daniel,

SUBROUTINE sub(I)
 REAL, PARAMETER :: PI = 3.1415
 REAL, DIMENSION(:), POINTER   :: I
 I = 2.0 * PI**2 * I
END SUBROUTINE

produces a temporary because the scalarizer makes no attempt to
resolve pointers, for obvious reasons.  We could add a check that the
only pointer on the rhs is the same as that on the lhs, with no
dependencies, and that there are no targets in the rhs expression.


-- 
   Summary: Unneccessary array temporary for  same_array = scalar *
same_array
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org


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

[Bug fortran/29952] Flag to give runtime information " array temporary was created for argument"

[burnus at gcc dot gnu dot org]

--- Comment #4 from burnus at gcc dot gnu dot org  2008-07-24 08:33 ---
(In reply to comment #3)
> Test case for the run-time check.

By itself this PR not related is PR 36909. However, both require that
gfc_conv_function_call passes on information. For PR 36909 one needs to have
the INTENT of the formal argument, for this PR one needs to pass the procedure
name and either the formal-argument name or its position.

Thus I think one could fix both PRs simultaneously.


-- 


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

[Bug c/36914] va_list is treatead as an array when complied in 64bits

[schwab at suse dot de]

--- Comment #3 from schwab at suse dot de  2008-07-24 08:29 ---
va_list can be any object type, including an array.


-- 

schwab at suse dot de changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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