[Bug fortran/43265] [4.3/4.4/4.5 Regression] No EOF condition if reading with '(x)' from an empty file

[jvdelisle at gcc dot gnu dot org]

--- Comment #25 from jvdelisle at gcc dot gnu dot org  2010-03-18 03:58 
---
IO library is significantly changed from 4.3 to 4.4/4.5 No Backport to 4.3

Closing.


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug fortran/43265] [4.3/4.4/4.5 Regression] No EOF condition if reading with '(x)' from an empty file

[jvdelisle at gcc dot gnu dot org]

--- Comment #24 from jvdelisle at gcc dot gnu dot org  2010-03-18 03:56 
---
Subject: Bug 43265

Author: jvdelisle
Date: Thu Mar 18 03:55:52 2010
New Revision: 157533

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157533
Log:
2010-03-17  Jerry DeLisle  

PR libfortran/43265
*gfortran.dg/read_empty_file.f: New test.
*gfortran.dg/read_eof_all.f90: New test.
*gfortran.dg/namelist_27.f90: Eliminate infinite loop posibility.
*gfortran.dg/namelist_28.f90: Eliminate infinite loop posibility.

Added:
branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/read_empty_file.f
branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/read_eof_all.f90
Modified:
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog
branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/namelist_27.f90
branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/namelist_28.f90


-- 


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

[Bug rtl-optimization/43286] Missed related value optimization in cse.c

[carrot at google dot com]

--- Comment #5 from carrot at google dot com  2010-03-18 03:52 ---
In this case arm_arm_address_cost does the right thing. The problem is in
function should_replace_address.

When two addresses have same address cost, we choose the one with higher rtx
cost. The reason is "That has the potential of eliminating the most insns
without additional costs". But when two addresses have the same rtx cost, they
also have the potential to eliminate a previous definition. Just as
demonstrated by this test case.

One of the candidate is

old_rtx
(plus:SI (reg/v/f:SI 133 [ saveArea ])
(const_int 8 [0x8]))

new_rtx
(plus:SI (reg/v/f:SI 140 [ fp ])
(const_int -8 [0xfff8]))

After all of these addresses being replaced, instruction A can be removed.


-- 


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

[Bug fortran/43265] [4.3/4.4/4.5 Regression] No EOF condition if reading with '(x)' from an empty file

[jvdelisle at gcc dot gnu dot org]

--- Comment #23 from jvdelisle at gcc dot gnu dot org  2010-03-18 03:52 
---
Subject: Bug 43265

Author: jvdelisle
Date: Thu Mar 18 03:51:43 2010
New Revision: 157532

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157532
Log:
2010-03-17  Jerry DeLisle  

PR libfortran/43265
* io/io.h: Delete prototype for read_sf, making it static.
* io/read.c (read_x): Modify to call hit_eof if PAD="no".
* io/transfer.c (read_sf_internal): New static function extracted from
read_sf for use on internal units only. Handle empty string case.
(read_sf): New factoring of this function, make it static.  Add special
conditions for EOF based on ADVANCE="no", PAD="no", and whether any
bytes have been previously read from the record.
(read_block_form): Modify to call read_sf or read_sf_internal.
(next_record_r): Add a done flag similar to next_record_w. Call hit_eof
if internal array unit next record returns finished, meaning an EOF was
found and not done, ie not the last record expected.  For external
units call hit_eof if item_count is 1 or there are no pending spaces.
(next_record): Update call to next_record_r.

Modified:
branches/gcc-4_4-branch/libgfortran/ChangeLog
branches/gcc-4_4-branch/libgfortran/io/io.h
branches/gcc-4_4-branch/libgfortran/io/read.c
branches/gcc-4_4-branch/libgfortran/io/transfer.c


-- 


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

[Bug tree-optimization/43416] [4.4 regression] internal compiler error in C++ template instantiations at -O3

[wlam at kosmix dot com]

--- Comment #2 from wlam at kosmix dot com  2010-03-18 03:14 ---
Oops, the description is truncated:

(built from the GNU source distribution, though the Fedora version of 4.4.3
shows similar behavior--

$ g++ -Wfatal-errors -c -O3 -Wall foo.ccfoo.cc: In member function ‘void
TypeRegistry::registerType(int, const ValueType&) [with ValueType =
int (*)()]’:
foo.cc:119: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
Preprocessed source stored into /tmp/cc1IzDg0.out file, please attach this to
your bugreport.

$ gcc -v
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --enable-plugin
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--with-ppl --with-cloog --with-tune=generic --with-arch_32=i686
--build=x86_64-redhat-linux
Thread model: posix
gcc version 4.4.3 20100127 (Red Hat 4.4.3-4) (GCC)

--as well)


-- 


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

[Bug target/42427] [4.5 Regression] invalid assembly code for 301.apsi for -fnon-call-exceptions

[bergner at gcc dot gnu dot org]

--- Comment #10 from bergner at gcc dot gnu dot org  2010-03-18 03:14 
---
Fixed.


-- 

bergner at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug tree-optimization/43416] [4.4 regression] internal compiler error in C++ template instantiations at -O3

[wlam at kosmix dot com]

--- Comment #1 from wlam at kosmix dot com  2010-03-18 03:11 ---
Created an attachment (id=20137)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20137&action=view)
Minimized C++ source causing segmentation fault in gcc 4.4.3 at -O3


-- 


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

[Bug tree-optimization/43416] New: [4.4 regression] internal compiler error in C++ template instantiations at -O3

[wlam at kosmix dot com]

I came across some code that previously compiled at -O3 without complaint on
gcc version 4.3.0 20080428 (Red Hat 4.3.0-8) and gcc version 4.4.1 (Ubuntu
4.4.1-4ubuntu9), but triggered a segmentation fault on gcc 4.4.3.  After
minimization, here is the segmentation fault:

$ /net/test-hsa014/wlam/local/gcc-4.4.3/bin/gcc -Wfatal-errors -c -O3 -Wall
foo.cc
foo.cc: In member function ‘void TypeRegistry::registerType(int,
const ValueType&) [with ValueType = int (*)()]’:
foo.cc:119: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

$ /net/test-hsa014/wlam/local/gcc-4.4.3/bin/g++ -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.4.3/configure
--prefix=/net/test-hsa014/wlam/local/gcc-4.4.3 --disable-multilib
Thread model: posix
gcc version 4.4.3 (GCC)

(built from the GNU source distribution, though


-- 
   Summary: [4.4 regression] internal compiler error in C++ template
instantiations at -O3
   Product: gcc
   Version: 4.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wlam at kosmix dot com
 GCC build triplet: x86_64-redhat-linux
  GCC host triplet: x86_64-redhat-linux
GCC target triplet: x86_64-redhat-linux


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

[Bug target/42427] [4.5 Regression] invalid assembly code for 301.apsi for -fnon-call-exceptions

[bergner at gcc dot gnu dot org]

--- Comment #9 from bergner at gcc dot gnu dot org  2010-03-18 03:10 ---
Subject: Bug 42427

Author: bergner
Date: Thu Mar 18 03:10:04 2010
New Revision: 157530

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157530
Log:
gcc/
PR target/42427
* config/rs6000/rs6000.c (rs6000_split_multireg_move): Add support for
non-offsettable and pre_modify update addressing.
* config/rs6000/dfp.md (*movdd_hardfloat32): Make the "0", "1"
and "2" alternatives "#".
(*movdd_softfloat32): Make all alternatives "#";
* config/rs6000/rs6000.md (DIFD): New define_mode_iterator.
(*movdf_hardfloat32): Make the "0", "1" and "2" alternatives "#".
(*movdf_softfloat32): Make all alternatives "#";
(movdi): Use the new DIFD mode iterator to create a common splitter
for movdi, movdf and movdd patterns.

gcc/testsuite/
PR target/42427
* gcc.dg/pr42427.c: New test.


Added:
trunk/gcc/testsuite/gcc.dg/pr42427.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/dfp.md
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/config/rs6000/rs6000.md
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/43265] [4.3/4.4/4.5 Regression] No EOF condition if reading with '(x)' from an empty file

[jvdelisle at gcc dot gnu dot org]

--- Comment #22 from jvdelisle at gcc dot gnu dot org  2010-03-18 02:54 
---
Correction s/not/now 


-- 


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

[Bug fortran/43265] [4.3/4.4/4.5 Regression] No EOF condition if reading with '(x)' from an empty file

[jvdelisle at gcc dot gnu dot org]

--- Comment #21 from jvdelisle at gcc dot gnu dot org  2010-03-18 02:52 
---
The above patches take care of several other corner cases with end file
conditions. Thanks Terry for report and Tobias for helping with test cases.

I am not proceeding to back port to 4.4.


-- 


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

[Bug fortran/43265] [4.3/4.4/4.5 Regression] No EOF condition if reading with '(x)' from an empty file

[jvdelisle at gcc dot gnu dot org]

--- Comment #20 from jvdelisle at gcc dot gnu dot org  2010-03-18 02:43 
---
Subject: Bug 43265

Author: jvdelisle
Date: Thu Mar 18 02:43:10 2010
New Revision: 157528

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157528
Log:
2010-03-17  Jerry DeLisle  

PR libfortran/43265
*gfortran.dg/read_empty_file.f: New test.
*gfortran.dg/read_eof_all.f90: New test.
*gfortran.dg/namelist_27.f90: Eliminate infinite loop posibility.
*gfortran.dg/namelist_28.f90: Eliminate infinite loop posibility.

Added:
trunk/gcc/testsuite/gfortran.dg/read_empty_file.f
trunk/gcc/testsuite/gfortran.dg/read_eof_all.f90
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/namelist_27.f90
trunk/gcc/testsuite/gfortran.dg/namelist_28.f90


-- 


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

[Bug fortran/43265] [4.3/4.4/4.5 Regression] No EOF condition if reading with '(x)' from an empty file

[jvdelisle at gcc dot gnu dot org]

--- Comment #19 from jvdelisle at gcc dot gnu dot org  2010-03-18 02:38 
---
Subject: Bug 43265

Author: jvdelisle
Date: Thu Mar 18 02:38:17 2010
New Revision: 157527

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157527
Log:
2010-03-17  Jerry DeLisle  

PR libfortran/43265
* io/io.h: Delete prototype for read_sf, making it static.
* io/read.c (read_x): Modify to call hit_eof if PAD="no".
* io/transfer.c (read_sf_internal): New static function extracted from
read_sf for use on internal units only. Handle empty string case.
(read_sf): New factoring of this function, make it static.  Add special
conditions for EOF based on ADVANCE="no", PAD="no", and whether any
bytes have been previously read from the record.
(read_block_form): Modify to call read_sf or read_sf_internal.
(next_record_r): Add a done flag similar to next_record_w. Call hit_eof
if internal array unit next record returns finished, meaning an EOF was
found and not done, ie not the last record expected.  For external
units call hit_eof if item_count is 1 or there are no pending spaces.
(next_record): Update call to next_record_r.

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


-- 


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

[Bug fortran/43409] I/O: INQUIRE for SIZE does not work.

[jvdelisle at gcc dot gnu dot org]

--- Comment #3 from jvdelisle at gcc dot gnu dot org  2010-03-18 02:14 
---
I have a few other bugs ahead of this, but I will fix it if no one else does so
before I get to it.  


-- 


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

[Bug target/43348] [4.4 regression] ICE in final_scan_insn, at final.c:2604

[doko at ubuntu dot com]

--- Comment #8 from doko at ubuntu dot com  2010-03-18 00:52 ---
checked that this patch fixes the testcase, and doesn't show any regressions on
ia64-linux-gnu for the testsuite (4.4 branch 20100311).


-- 


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

[Bug target/43399] [4.5 Regression] bootstrap failure in stage1

[rearnsha at gcc dot gnu dot org]

-- 

rearnsha at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|bootstrap   |target
   Priority|P3  |P1


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

[Bug target/42040] [ia64] Inappropriate address spills

[wilson at codesourcery dot com]

--- Comment #11 from wilson at codesourcery dot com  2010-03-18 00:12 
---
Subject: Re:  [ia64] Inappropriate address spills

On Wed, 2010-03-17 at 23:47 +, sje at cup dot hp dot com wrote:
> Reading Richard's initial comment I thought the problem was that the code was
> (or could be) illegal because the relocation may be out of range and we
> shouldn't
> use the gprel relocation for any of these constant pool references.

The code is invalid only if you use -mno-sdata.

The only reason why Richard wanted to use -mno-sdata is because he saw
the non-optimal code, and hoped that -mno-sdata would fix that.  It
didn't.  It just made the problem worse by generating invalid code.  So
there is probably also a bug here in the handling of -mno-sdata, but
fixing that doesn't help Richard, because it doesn't solve the real
problem he was complaining about, which was the non-optimal code.

I suspect that the -mno-sdata bug is that ia64_expand_load_address does
  else if (sdata_symbolic_operand (src, VOIDmode))
emit_insn (gen_load_gprel (dest, src));
and sdata_symbolic_operand fails to check TARGET_NO_SDATA, so it assumes
that constant pool entries are still in the sdata section, and we end up
with gprel references to items that aren't in the sdata section anymore,
which will fail at link time.  If we fix that, -mno-sdata will work, but
we will still have all of the inappropriate address spills (i.e.
non-optimal code) which is what the PR summary is complaining about.

Jim


-- 


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

[Bug tree-optimization/43415] New: [4.4 regression] gcc takes unusually large amounts of memory and time to compile nested for loop at -O3

[wlam at kosmix dot com]

I came across some source code that failed to compile in gcc 4.4.3 with -O3
because the kernel shot gcc for using too much memory.  After I minimized the
code (and converted it from C++ to C for simplicity) into the below example,
gcc 4.4.3 still took over a minute of CPU and a gigabyte of RAM for cc1 to
build:

$ time /net/test-hsa014/wlam/local/gcc-4.4.3/bin/gcc -Wfatal-errors -c -O3
foo-min.c

real1m2.488s
user1m1.213s
sys 0m1.110s

int main()  
{   
unsigned long long table[256];  
unsigned int i;
for (i=0; i<256; ++i) {
unsigned long long j;
unsigned char x=i;
for (j=0; j<5; ++j) {
x += x<<1;
x ^= x>>1;
}
for (j=0; j<5; ++j) {
x ^= x>>1;
}
for (j=0; j<5; ++j) {
x += x<<1;
x ^= x>>1;
}
table[i] ^= (((unsigned long long)x)<<16);
}
for (i=0; i<256; ++i) {
if ((table[i]&0xff)==i)
return 1;
}
return 0;
}

With additional
for (j=0; j<5; ++j) { ... }
loops, the computation and RAM consumed to compile the example seemed to grow
disproportionately.  For example, the following longer variation consumed over
10 minutes and 15GB RAM before I killed it:

int main()   
{
unsigned long long table[256];   
unsigned int i;  
for (i=0; i<256; ++i) {  
unsigned long long j;
unsigned char x=i;   
for (j=0; j<5; ++j) {
x += x<<1;   
x ^= x>>1;   
}
for (j=0; j<5; ++j) {
x ^= x>>1;
}
for (j=0; j<5; ++j) {
x += x<<1;
x ^= x>>1;
}
for (j=0; j<5; ++j) {
x += x<<1;
x ^= x>>1;
}
for (j=0; j<5; ++j) {
x += x<<1;
x ^= x>>1;
}
table[i] ^= (((unsigned long long)x)<<16);
}
for (i=0; i<256; ++i) {
if ((table[i]&0xff)==i)
return 1;
}
return 0;
}

(The original code I encountered was longer yet...)

I built gcc 4.4.3 from the GNU source distribution to use as the reference gcc
4.4.3 above--

$ /net/test-hsa014/wlam/local/gcc-4.4.3/bin/gcc -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.4.3/configure
--prefix=/net/test-hsa014/wlam/local/gcc-4.4.3 --disable-multilib
Thread model: posix
gcc version 4.4.3 (GCC)

--but the Fedora variation of version 4.4.3 showed similar behavior:

$ gcc -v
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --enable-plugin
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--with-ppl --with-cloog --with-tune=generic --with-arch_32=i686
--build=x86_64-redhat-linux
Thread model: posix
gcc version 4.4.3 20100127 (Red Hat 4.4.3-4) (GCC)


By contrast, the Ubuntu distribution of gcc 4.4.1 (on a different machine with
a similar-speed CPU) completed trivially quickly, as expected--

$ time gcc -Wfatal-errors  -c -O3 -Wall foo.c

real0m0.091s
user0m0.050s
sys 0m0.020s

$ gcc -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.4.1-4ubuntu9'
--with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--enable-multiarch --enable-linker-build-id --with-system-zlib
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --disable-werror
--with-arch-32=i486 --with-tune=generic --enable-checking=r

[Bug target/42040] [ia64] Inappropriate address spills

[sje at cup dot hp dot com]

--- Comment #10 from sje at cup dot hp dot com  2010-03-17 23:47 ---
Reading Richard's initial comment I thought the problem was that the code was
(or could be) illegal because the relocation may be out of range and we
shouldn't
use the gprel relocation for any of these constant pool references.


-- 


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

[Bug bootstrap/43399] [4.5 Regression] bootstrap failure in stage1

[rearnsha at gcc dot gnu dot org]

-- 

rearnsha at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rearnsha at gcc dot gnu dot
   ||org
  Component|target  |bootstrap
   Priority|P1  |P3


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

[Bug target/42040] [ia64] Inappropriate address spills

[wilson at codesourcery dot com]

--- Comment #9 from wilson at codesourcery dot com  2010-03-17 23:25 ---
Subject: Re:  [ia64] Inappropriate address spills

On Wed, 2010-03-17 at 22:09 +, sje at cup dot hp dot com wrote:
> I tried the patch and didn't have any problem bootstrapping and I didn't see
> any regressions.  It also fixed my small test case, but when I went back and
> tried some of the other tests from PR 28490 I still saw some of the bad gprel
> usages.  Here is a slightly more cutdown testcase from 28490 that still fails
> with the patch applied and when compiling with -O2.

I already mentioned in my previous message that the patch does not
eliminate all instances of the gprel usages (constant-pool references).
It just eliminates most of them.  If you want to eliminate all of them,
then you need to get LEGITIMATE_PIC_OPERAND_P working, which in turn
will require setting flag_pic by default. which in turn will require
verifying that this doesn't break anything.  That is probably more work
than I have time for.

And by "fails", you mean that the compiler is still emitting undesirable
code in some cases.  The code isn't incorrect, just non-optimal.  And we
get less non-optimal code with the patch, so it seems to be better than
nothing.  Unless you want to try to write the better
LEGITIMATE_PIC_OPERAND_P solution.

Jim


-- 


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

[Bug fortran/43414] DWARF4: Use DW_AT_main_subprogram for MAIN__

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2010-03-17 23:14 ---
I had filed PR 23280 for that really but it turned out I used the incorrect
dwarf and it pushed to alternative entry points.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-03-17 23:14:42
   date||


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

[Bug fortran/43414] New: DWARF4: Use DW_AT_main_subprogram for MAIN__

[burnus at gcc dot gnu dot org]

DWARF4 draft: http://dwarfstd.org/doc/DWARF4-public-review.pdf

gfortran uses
  main()
to initialize the program and
  MAIN__
as actual Fortran program.

DWARF4 offers:
  DW_AT_main_subprogram   Main or starting subprogram
  Unit containing main or starting subprogram

File: gcc/fortran/trans-decl.c:
The "main" program is generated in create_main_function; the "MAIN__"
subprogram is generated gfc_generate_function_code (only if
sym->attr.is_main_program).

gcc/dwarf2out.c already has DW_AT_main_subprogram defined.


-- 
   Summary: DWARF4: Use DW_AT_main_subprogram for MAIN__
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
OtherBugsDependingO 24546
 nThis:


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

[Bug target/43399] [4.5 Regression] bootstrap failure in stage1

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P1


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

[Bug target/43399] [4.5 Regression] bootstrap failure in stage1

[ramana at gcc dot gnu dot org]

--- Comment #6 from ramana at gcc dot gnu dot org  2010-03-17 22:43 ---
As per Comment #4 and based on conversations on IRC, this is certainly a target
bug . I have verified that this very testcase attached also has the same effect
on the arm-eabi target ( a simple -g -O2 is enough to trigger the ICE) , the
canonical primary platform for the ARM port as well.

Could the release managers consider re-priotizing this bug upwards for the ARM
port ? 

cheers
Ramana


-- 

ramana at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |NEW
  Component|bootstrap   |target
 Ever Confirmed|0   |1
 GCC target triplet|armv7l-unknown-linux-gnueabi|armv7l-unknown-linux-
   ||gnueabi, arm-eabi
  Known to fail||4.5.0
   Last reconfirmed|-00-00 00:00:00 |2010-03-17 22:43:30
   date||


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

[Bug rtl-optimization/43413] Powerpc generates worse code for -mvsx on gromacs even though there are no VSX instructions used

[meissner at gcc dot gnu dot org]

--- Comment #3 from meissner at gcc dot gnu dot org  2010-03-17 22:38 
---
Created an attachment (id=20136)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20136&action=view)
Bzip2 tar file of the ira dump output for altivec, vsx, scalar, and no-spill


-- 


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

[Bug rtl-optimization/43413] Powerpc generates worse code for -mvsx on gromacs even though there are no VSX instructions used

[meissner at gcc dot gnu dot org]

--- Comment #2 from meissner at gcc dot gnu dot org  2010-03-17 22:37 
---
Created an attachment (id=20135)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20135&action=view)
Bzip2 tar file of the assembly output for altivec, vsx, scalar, and no-spill


-- 


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

[Bug rtl-optimization/43413] Powerpc generates worse code for -mvsx on gromacs even though there are no VSX instructions used

[meissner at gcc dot gnu dot org]

--- Comment #1 from meissner at gcc dot gnu dot org  2010-03-17 22:35 
---
Created an attachment (id=20134)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20134&action=view)
Test case from the gromacs benchmark


-- 


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

[Bug rtl-optimization/43413] New: Powerpc generates worse code for -mvsx on gromacs even though there are no VSX instructions used

[meissner at gcc dot gnu dot org]

The powerpc64-unknown-linux-gnu compiler generates much worse code on the
inl1130 function in the gromacs benchmark from spec 2006 when compiling for the
VSX instruction set with -mcpu=power7 (or -mvsx).  The code in question in not
vectorizable, and in fact only uses integer and single precision floating
point.

Just to be clear, the powerpc architecture originally had two sets of registers
(FLOAT_REGS for scalar floating point registers and ALTIVEC_REGS for vector
single precision/int registers).  The VSX addition to the architecture adds a
new set of scalar/vector instructions that can use registers from either
register set.  So, in the VSX work, I added a new register class (VSX_REGS)
that is the union of the two register classes, and changed
TARGET_IRA_COVER_CLASSES to return a cover class that returns VSX_REGS in the
VSX case, and FLOAT_REGS/ALTIVEC_REGS in the traditional case.

In the enclosed test case, it generates the following spills for the options:
-O3 -ffast-math -mcpu=power7 -mvsx -maltivec: 117 stfs, 139 lfs
-O3 -ffast-math -mcpu=power5 -maltivec: 80 stfs, 100 lfs
-O3 -ffast-math -mcpu=power5: 80 stfs, 100 lfs

Now, if I enable -fno-ira-share-spill-slots, it gets somewhat better, though
obviously it uses more stack space because it can't resuse the spill stack
slots:
-O3 -ffast-math -mcpu=power7 -mvsx -maltivec -fno-ira-share-spill-slots: 102
stfs, 111 lfs

If I don't change the IRA cover class, gromacs generates the same code, but
other benchmarks that do use 64 registers won't compile correctly.


-- 
   Summary: Powerpc generates worse code for -mvsx on gromacs even
though there are no VSX instructions used
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: meissner at gcc dot gnu dot org
 GCC build triplet: powerpc64-unknown-linux-gnu
  GCC host triplet: powerpc64-unknown-linux-gnu
GCC target triplet: powerpc64-unknown-linux-gnu


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

[Bug fortran/43310] -pedantic errors involving PARAMETERs and out of range result

[kargl at gcc dot gnu dot org]

--- Comment #13 from kargl at gcc dot gnu dot org  2010-03-17 22:26 ---
(In reply to comment #11)
> > Well, the number model is symmetric. See Fortran 2003 ...
> 
> I agree, but it is a very pedantic view that should at least be mentioned in
> the manual.

You forgot to attach your patch.

> Now I think the implementation is not consistent:
> 
> [macbook] f90/bug% cat > ishft_1.f90
> print *, ishft(1,31)
> end
> [macbook] f90/bug% gfc -Wall -pedantic ishft_1.f90
> [macbook] f90/bug% a.out
>  -2147483648

gfc_simplify_ishft doesn't range check its result.
Patch welcomed.


-- 


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

[Bug fortran/43310] -pedantic errors involving PARAMETERs and out of range result

[kargl at gcc dot gnu dot org]

--- Comment #12 from kargl at gcc dot gnu dot org  2010-03-17 22:20 ---
(In reply to comment #10)
> (In reply to comment #9)
> > (In reply to comment #8)
> > > Maybe we just need to document that -pedantic changes the range of 
> > > integers to
> > > be what the Fortran standard requires (a symmetric range).
> > 
> > The Fortran Standard requires neither a symmetric nor asymmetric
> > range.
> 
> Well, the number model is symmetric. 

You're preaching to the choir. ;)

Yes, the model number representation of integer is symmetric.
However, the representable range on integer does not have to
correspond to the model numbers.

function myabs(i)
  myabs = iabs(i)
end function myabs

function mynot(i)
  mynot = not(i)
end function mynot

Do these functions conform to the standard for all poosible
values of i? Careful with your answer.


-- 


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

[Bug fortran/43412] New: [OOP] BT_CLASS does not does not set array spec

[burnus at gcc dot gnu dot org]

symbol.c's gfc_build_class_symbol has:

  (*as) = NULL;  /* XXX */


Thus the following invalid program is accepted as the check for
"Assumed size array at %L must be a dummy argument" fails as sym->as == NULL.


module m
  type t
  end type t
end module m
subroutine foo()
use m
  class(t), pointer :: y(*) ! <<< invalid
end


-- 
   Summary: [OOP] BT_CLASS does not does not set array spec
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: rejects-valid, accepts-invalid
  Severity: major
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
OtherBugsDependingO 18918
 nThis:


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

[Bug target/42040] [ia64] Inappropriate address spills

[sje at cup dot hp dot com]

--- Comment #8 from sje at cup dot hp dot com  2010-03-17 22:09 ---
I tried the patch and didn't have any problem bootstrapping and I didn't see
any regressions.  It also fixed my small test case, but when I went back and
tried some of the other tests from PR 28490 I still saw some of the bad gprel
usages.  Here is a slightly more cutdown testcase from 28490 that still fails
with the patch applied and when compiling with -O2.

extern const char basesyntax[];
extern const char arisyntax[];
typedef struct __jmp_buf_tag { }
jmp_buf[1];
struct jmploc { jmp_buf loc; };
readtoken1 (int firstc, char const *syntax, char *eofmark, int striptabs)
{
  int c = firstc;
for (;;)
  {
switch (syntax[c])
  {
  case 1:
if (syntax == (basesyntax + 130))
  goto endword;
syntax = (basesyntax + 130);
parsebackq_oldreturn:;
  }
  }
endword:
if (syntax == (arisyntax + 130)) {
struct jmploc jmploc;
if (_setjmp (jmploc.loc))
  goto parsebackq_oldreturn;
}
}


-- 


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

[Bug tree-optimization/43411] New: Missed inline optimization opportunity with indirect calls

[jonty_lawson at yahoo dot co dot uk]

C++ inlining of virtual calls does not occur in many instances when it should
be easy to determine that it is safe.

The problem occurs when there is an object that is referred to via a pointer or
reference. Normally a virtual call through a pointer cannot be inlined because
it is not known what its actual type is at compile time. However, sometimes the
pointer is assigned to an object of known type, and in this case the compiler
could determine the correct version of the method to call, and so inline it.

This is a somewhat unlikely state of affairs in normal code, but it becomes
important when some inlining has already taken place. Often the inlined method
will refer to a parameter via a reference, but this may refer to a type known
precisely at the call site. After inlining this information could be profitably
used to allow further inlining. Small getter/setter methods would benefit
enormously from this.

As far as I can make out, the microsoft C++ compiler seems to do this
optimization.

For example, consider the complete source file:


class P { public: virtual int val() { return 123; } };
class Psub : public P { };

extern int sink1, sink2;

void test() {
Psub p;
P &pRef = p;
sink1 = p.val();
sink2 = pRef.val();
}


inline int v(P &p) { return p.val(); }

void testInlineP() {
P p;
sink1 = v(p);
}

void testInlinePsub() {
Psub p;
sink1 = v(p);
}


With -O3 specified this generates the following code (with a very little
cleanup for clarity):

__Z4testv:
pushl   %ebp
movl$123, %edx
movl%esp, %ebp
leal-24(%ebp), %eax
subl$40, %esp
movl%eax, (%esp)
movl$__ZTV4Psub+8, -24(%ebp)
movl%edx, _sink1
call*__ZTV4Psub+8
movl%eax, _sink2
leave
ret


__Z11testInlinePv:
pushl   %ebp
movl%esp, %ebp
leal-24(%ebp), %eax
subl$40, %esp
movl%eax, (%esp)
movl$__ZTV1P+8, -24(%ebp)
call*__ZTV1P+8
movl%eax, _sink1
leave
ret


__Z14testInlinePsubv:
pushl   %ebp
movl%esp, %ebp
leal-24(%ebp), %eax
subl$40, %esp
movl%eax, (%esp)
movl$__ZTV4Psub+8, -24(%ebp)
call*__ZTV4Psub+8
movl%eax, _sink1
leave
ret


Only the line "sink1 = p.val();" in test has been inlined to "movl $123, %edx /
movl %edx, _sink1". The other calls have not been inlined, even though they can
safely be replaced by the same instruction pair.

The above code was generated with version 3.4.5 mingw, but I have checked that
the same thing happens with version 4.3.3 under Ubuntu. I haven't checked that
it happens with targets other than i386, but it seems likely that it would.

This bug report seems likely to be a more general case of bug report 41012 and
probably replaces it.


-- 
   Summary: Missed inline optimization opportunity with indirect
calls
   Product: gcc
   Version: 4.3.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jonty_lawson at yahoo dot co dot uk


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

[Bug java/43369] gcjh's CNI text options don't work

[tromey at gcc dot gnu dot org]

--- Comment #1 from tromey at gcc dot gnu dot org  2010-03-17 21:46 ---
I tried it and it works fine with svn head.
Make sure to rm a.h before trying with different flags.
Or, use -force.


-- 

tromey at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||tromey at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.5.0


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

[Bug bootstrap/43399] [4.5 Regression] bootstrap failure in stage1

[jakub at gcc dot gnu dot org]

--- Comment #5 from jakub at gcc dot gnu dot org  2010-03-17 21:44 ---
Argh, seems ARM is very badly abusing PRE_DEC:
(insn/f 72 41 73 2 /opt/trunk/libgcc/../gcc/libgcc2.c:553 (parallel [
(set (mem/c:BLK (pre_dec:BLK (reg/f:SI 13 sp)) [6 A8])
(unspec:BLK [
(reg:SI 4 r4)
] 2))
]) 326 {*push_multi} (expr_list:REG_DEAD (reg:SI 4 r4)
(expr_list:REG_FRAME_RELATED_EXPR (sequence [
(set/f (reg/f:SI 13 sp)
(plus:SI (reg/f:SI 13 sp)
(const_int -4 [0xfffc])))
(set/f (mem/c:SI (reg/f:SI 13 sp) [6 S4 A32])
(reg:SI 4 r4))
])
(nil
This violates PRE_DEC documentation in 2 ways:
1) PRE_DEC's mode is not a machine mode for pointers
2) the decrement size is not equal to the size of the mode (as BLKmode size is
0).

@item (pre_dec:@var{m} @var{x})
Represents the side effect of decrementing @var{x} by a standard
amount and represents also the value that @var{x} has after being
decremented.  @var{x} must be a @code{reg} or @code{mem}, but most
machines allow only a @code{reg}.  @var{m} must be the machine mode
for pointers on the machine in use.  The amount @var{x} is decremented
by is the length in bytes of the machine mode of the containing memory
reference of which this expression serves as the address.

I think var-tracking isn't the only one which can be significantly confused by
this (what should it do?), so can DSE, cselib, ...

I'd say the best fix would be actually stop emitting this bogosity by the ARM
backend.  Either you can look at e.g. what s390 does for its load/store
multiple patterns, or even just use PRE_MODIFY instead of PRE_DEC and make the
stack pointer adjustment there explicit and obvious.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ramana at gcc dot gnu dot
   ||org


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

[Bug fortran/43310] -pedantic errors involving PARAMETERs and out of range result

[dominiq at lps dot ens dot fr]

--- Comment #11 from dominiq at lps dot ens dot fr  2010-03-17 21:31 ---
> Well, the number model is symmetric. See Fortran 2003 ...

I agree, but it is a very pedantic view that should at least be mentioned in
the manual. 
Now I think the implementation is not consistent:

[macbook] f90/bug% cat > ishft_1.f90
print *, ishft(1,31)
end
[macbook] f90/bug% gfc -Wall -pedantic ishft_1.f90
[macbook] f90/bug% a.out
 -2147483648


-- 


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

[Bug libgcj/40860] [4.4/4.5 regression] regressions in libjava testsuite on arm-linux

[mikpe at it dot uu dot se]

--- Comment #22 from mikpe at it dot uu dot se  2010-03-17 21:23 ---
I did another binutils experiment. I reverted my patch to disable general
merging of table entries, and instead disabled generating new and merging
cantunwind entries. With that binutils libjava regressed just like with vanilla
post-2.19.1 binutils. The general merging bit seems to be the problem.

--- binutils-2.20.51/bfd/elf32-arm.c.~1~
+++ binutils-2.20.51/bfd/elf32-arm.c
@@ -9148,6 +9148,7 @@ adjust_exidx_size(asection *exidx_sec, i
   bfd_set_section_size (out_sec->owner, out_sec, out_sec->size +adjust);
 }

+#if 0
 /* Insert an EXIDX_CANTUNWIND marker at the end of a section.  */
 static void
 insert_cantunwind_after(asection *text_sec, asection *exidx_sec)
@@ -9162,6 +9163,7 @@ insert_cantunwind_after(asection *text_s

   adjust_exidx_size(exidx_sec, 8);
 }
+#endif

 /* Scan .ARM.exidx tables, and create a list describing edits which should be
made to those tables, such that:
@@ -9248,7 +9250,9 @@ elf32_arm_fix_exidx_coverage (asection *
  if (sec->size == 0)
continue;

+#if 0
  insert_cantunwind_after(last_text_sec, last_exidx_sec);
+#endif
  last_unwind_type = 0;
  continue;
}
@@ -9282,8 +9286,10 @@ elf32_arm_fix_exidx_coverage (asection *
  /* An EXIDX_CANTUNWIND entry.  */
  if (second_word == 1)
{
+#if 0
  if (last_unwind_type == 0)
elide = 1;
+#endif
  unwind_type = 0;
}
  /* Inlined unwinding data.  Merge if equal to previous.  */
@@ -9326,8 +9332,10 @@ elf32_arm_fix_exidx_coverage (asection *
 }

   /* Add terminating CANTUNWIND entry.  */
+#if 0
   if (last_exidx_sec && last_unwind_type != 0)
 insert_cantunwind_after(last_text_sec, last_exidx_sec);
+#endif

   return TRUE;
 }


-- 


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

[Bug tree-optimization/32824] Missed reduction vectorizer after store to global is LIM'd

[changpeng dot fang at amd dot com]

--- Comment #8 from changpeng dot fang at amd dot com  2010-03-17 21:22 
---
Created an attachment (id=20133)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20133&action=view)
patch with the testcase


-- 


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

[Bug debug/37982] Extraneous DW_TAG_variable tag

[dodji at gcc dot gnu dot org]

--- Comment #9 from dodji at gcc dot gnu dot org  2010-03-17 21:15 ---
The situation has change quite a lot since gcc 4.3.0.
Now a DW_TAG_member is emitted for the static member variable, and only one
DW_TAG_variable is emitted to represent the variable definition.

So I guess the bug can be closed now?

With 4.5 I get this:

<0>: Abbrev Number: 1 (DW_TAG_compile_unit)
< c>   DW_AT_producer: (indirect string, offset: 0x62): GNU C++ 4.5.0
20100301 (experimental)
<10>   DW_AT_language: 4(C++)
<11>   DW_AT_name: (indirect string, offset: 0x0): class.c
<15>   DW_AT_comp_dir: (indirect string, offset: 0x19):
/home/dodji/devel/git/gcc-branches.git/gcc-PR37982.git/prtests
<19>   DW_AT_low_pc  : 0x4004b4
<21>   DW_AT_high_pc : 0x4004c0
<29>   DW_AT_stmt_list   : 0x0
 <1><2d>: Abbrev Number: 2 (DW_TAG_structure_type)
<2e>   DW_AT_name: A
<30>   DW_AT_byte_size   : 1
<31>   DW_AT_decl_file   : 2
<32>   DW_AT_decl_line   : 2
<33>   DW_AT_sibling : <0x49>
 <2><37>: Abbrev Number: 3 (DW_TAG_member)
<38>   DW_AT_name: (indirect string, offset: 0x58): elsewhere
<3c>   DW_AT_decl_file   : 2
<3d>   DW_AT_decl_line   : 3
<3e>   DW_AT_MIPS_linkage_name: (indirect string, offset: 0x8):
_ZN1A9elsewhereE
<42>   DW_AT_type: <0x49>
<46>   DW_AT_external: 1
<47>   DW_AT_declaration : 1

[...]

<0>: Abbrev Number: 1 (DW_TAG_compile_unit)
   DW_AT_producer: (indirect string, offset: 0x62): GNU C++ 4.5.0
20100301 (experimental)
   DW_AT_language: 4(C++)
   DW_AT_name: (indirect string, offset: 0x8d): class2.c
   DW_AT_comp_dir: (indirect string, offset: 0x19):
/home/dodji/devel/git/gcc-branches.git/gcc-PR37982.git/prtests
   DW_AT_low_pc  : 0x4004c0
   DW_AT_high_pc : 0x4004c0
   DW_AT_stmt_list   : 0x46
 <1>: Abbrev Number: 2 (DW_TAG_structure_type)
   DW_AT_name: A
   DW_AT_byte_size   : 1
   DW_AT_decl_file   : 1
   DW_AT_decl_line   : 2
   DW_AT_sibling : <0xde>
 <2>: Abbrev Number: 3 (DW_TAG_member)
   DW_AT_name: (indirect string, offset: 0x58): elsewhere
   DW_AT_decl_file   : 1
   DW_AT_decl_line   : 3
   DW_AT_MIPS_linkage_name: (indirect string, offset: 0x8):
_ZN1A9elsewhereE
   DW_AT_type: <0xde>
   DW_AT_external: 1
   DW_AT_declaration : 1

[...]

<1>: Abbrev Number: 6 (DW_TAG_variable)
   DW_AT_specification: <0xcc>
   DW_AT_decl_file   : 2
   DW_AT_decl_line   : 2
   DW_AT_location: 9 byte block: 3 ac 5 40 0 0 0 0 0   
(DW_OP_addr: 4005ac)


-- 


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

[Bug libgcj/40860] [4.4/4.5 regression] regressions in libjava testsuite on arm-linux

[mikpe at it dot uu dot se]

--- Comment #21 from mikpe at it dot uu dot se  2010-03-17 21:13 ---
(In reply to comment #20)
> no change in the libjava testsuite when built with these binutils

But that's still thumb not arm like in comment #16? All my results are from
plain arm (armv5tel) builds.


-- 


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

[Bug bootstrap/43403] [4.5 Regression] ICE in stage1 compiling __bswapdi2

[dave at hiauly1 dot hia dot nrc dot ca]

--- Comment #8 from dave at hiauly1 dot hia dot nrc dot ca  2010-03-17 
21:09 ---
Subject: Re:  [4.5 Regression] ICE in stage1 compiling __bswapdi2

> Let's go with this patch then.  Can you please regtest it?

Yes.  I'll try it when I get home this evening.

Dave


-- 


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

[Bug fortran/43322] compiling under Matlab with gfortran

[pault at gcc dot gnu dot org]

--- Comment #2 from pault at gcc dot gnu dot org  2010-03-17 21:07 ---
As Daniel has indicated, this has nothing to do with gfortran.

Paul


-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WONTFIX


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

[Bug bootstrap/43403] [4.5 Regression] ICE in stage1 compiling __bswapdi2

[jakub at gcc dot gnu dot org]

--- Comment #7 from jakub at gcc dot gnu dot org  2010-03-17 21:01 ---
Created an attachment (id=20132)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20132&action=view)
gcc45-pr43403.patch

Let's go with this patch then.  Can you please regtest it?


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED


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

[Bug bootstrap/43410] Gcc 3.4 failed to boostrap on Linux/x86-64

[hjl dot tools at gmail dot com]

--- Comment #1 from hjl dot tools at gmail dot com  2010-03-17 20:27 ---
False alarm. I did run out of memory.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug fortran/43310] -pedantic errors involving PARAMETERs and out of range result

[burnus at gcc dot gnu dot org]

--- Comment #10 from burnus at gcc dot gnu dot org  2010-03-17 20:16 ---
(In reply to comment #9)
> (In reply to comment #8)
> > Maybe we just need to document that -pedantic changes the range of integers 
> > to
> > be what the Fortran standard requires (a symmetric range).
> 
> The Fortran Standard requires neither a symmetric nor asymmetric
> range.

Well, the number model is symmetric. See Fortran 2003
(http://www.j3-fortran.org/doc/year/04/04-007.pdf):

"13.4 Numeric models" [...]
"The model set for integer i is defined by

  i = s * sum_{k=0}^{q-1} w_k * r^k

where r is an integer exceeding one, q is a positive integer, each wk is a
nonnegative integer less than r, and s is +1 or −1."

> It simply requires that a program(mer) cannot invoke an
> intrinsic procedure that will return an out-of-range value.

That can be found in "13.7 Specifications of the standard intrinsic
procedures":

"A program is prohibited from invoking an intrinsic procedure under cir10
cumstances where a value to be returned in a subroutine argument or function
result is outside the range of values representable by objects of the specified
type and type parameters, unless the intrinsic module IEEE ARITHMETIC (section
14) is accessible and there is support for an infinite or a NaN result, as
appropriate."


-- 


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

[Bug preprocessor/33305] We should warn about empty macro arguments

[vz-gcc at zeitlins dot org]

--- Comment #8 from vz-gcc at zeitlins dot org  2010-03-17 20:05 ---
Sorry for a late follow up but I've just discovered that this change broke
compilation of code using wxWidgets library with "-pedantic-errors -std=c++98"
switches because wxWidgets uses constructions such as (simplified):

#define wxEMPTY_PARAMETER_VALUE /* Fake macro parameter value */

/*
This will be __declspec(dllexport) for some compilers, __attribute__
((visibility("default"))) for other ones and empty in non-shared library build
*/
#define wxEXPORT ...

#define wxDECLARE_SOMETHING(expdecl, name) class expdecl name
#define wxDECLARE_EXPORTED_SOMETHING(name) wxDECLARE_SOMETHING(wxEXPORT, name)


And now, with g++ 4.4.3 from Debian Unstable, this results in "empty macro
arguments are undefined in ISO C90 and ISO C++98" warning/error when wxEXPORT
is empty.

Admittedly, the error may be correct (although to be honest I am not even 100%
sure it is even after rereading 16.3 and 16.3.1 of C++98 several times), but
this use is common and often occurs in other code. Even Boost defines
BOOST_PP_EMPTY in its boost/preprocessor/facilities/empty.hpp and I definitely
saw this many times in other code as well so at the very least there is a
widespread belief in C++ community that such usage is valid.

So ideally I'd like to see gcc behave more leniently when a macro which
expands to an empty value is passed to another macro as argument (as opposed
to directly omitting a macro argument). Failing that, it'd be nice to have a
specific option to turn this behaviour off. Because right now the only choice
seems to be to either disable -pedantic (which would be a really unfortunate
consequence of the change making gcc stricter) or use -std=c++0x which is more
acceptable but still not always desirable.

TIA!


-- 

vz-gcc at zeitlins dot org changed:

   What|Removed |Added

 CC||vz-gcc at zeitlins dot org


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

[Bug bootstrap/43410] New: Gcc 3.4 failed to boostrap on Linux/x86-64

[hjl dot tools at gmail dot com]

On Linux/x86-64, gcc 3.4 failed to bootstrap gcc 4.5.0 at
revision 157518. I got:

gcc -c  -g -fkeep-inline-functions -DIN_GCC   -W -Wall -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute
-Wold-style-definition   -DHAVE_CONFIG_H -I. -I.
-I/net/gnu-13/export/gnu/src/gcc/gcc/gcc
-I/net/gnu-13/export/gnu/src/gcc/gcc/gcc/.
-I/net/gnu-13/export/gnu/src/gcc/gcc/gcc/../include
-I/net/gnu-13/export/gnu/src/gcc/gcc/gcc/../libcpp/include 
-I/net/gnu-13/export/gnu/src/gcc/gcc/gcc/../libdecnumber
-I/net/gnu-13/export/gnu/src/gcc/gcc/gcc/../libdecnumber/bid -I../libdecnumber 
 -I/usr/include/libelf  insn-attrtab.c -o insn-attrtab.o

cc1: out of memory allocating 446876352 bytes after a total of 67346432 bytes
make[5]: *** [insn-attrtab.o] Error 1 

Revision 157387 is OK.


-- 
   Summary: Gcc 3.4 failed to boostrap on Linux/x86-64
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
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=43410

[Bug c++/43393] integral promotion of long bit-fields broken in g++ 4.4.0

[vsoni at tilera dot com]

--- Comment #3 from vsoni at tilera dot com  2010-03-17 19:33 ---
(In reply to comment #2)
> 
> I read that t.f promotes to int.  And that is exactly what the C++ frontend
> does:

That's plausible, but the standard, especially it's intent, is unclear I think.

I see three plausible interpretations:

A) int can represent all values of a long:16 bit-field, AND a long:16 bit-field
is not larger than int (if "larger" is interpreted with respect to the number
of bits in the bit-field representation, i.e. 16 bits).  So it is converted to
int.

B) int can represent all values of a long:16 bit-field, BUT a long:16 bit-field
is larger than int and unsigned int (if "larger" is interpreted with respect to
the size of the declared type of the bit-field, i.e. long).  So two clauses of
[3] apply, and the question is order of precedence:

  B1) The clause concerning int-representable values takes precedence, so it is
converted to int.

  B2) The clause concerning the size of the bit-field takes precedence, so no
integer promotions apply, and it remains long.

I agree that [A] seems to be the "simplest" interpretation in some sense, and
perhaps it's the correct one, but I can't reconcile this with the following: 
It seems to me the programmer's intent when declaring a bit-field of type
long:N, is to treat the value as type long, independent of N.  It also seems to
me that's the intent of the standard when it states that the number of bits in
a bit-field is not part of its type; perhaps the intent is something else?

FWIW, I searched but did not find a discussion of rationale, or a conclusive
example, in the supplementary notes of the C++ Standards Committee.


-- 


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

[Bug bootstrap/43403] [4.5 Regression] ICE in stage1 compiling __bswapdi2

[dave at hiauly1 dot hia dot nrc dot ca]

--- Comment #6 from dave at hiauly1 dot hia dot nrc dot ca  2010-03-17 
18:19 ---
Subject: Re:  [4.5 Regression] ICE in stage1 compiling __bswapdi2

> var-tracking expects that if frame_pointer_rtx (resp. arg_pointer_rtx,
> depending on whether FRAME_POINTER_CFA_OFFSET or ARG_POINTER_CFA_OFFSET is
> defined)
> is said to be eliminated (to stack_pointer_rtx in case of
> !frame_pointer_needed), then it is actually eliminated.  Apparently that's not
> the case on PA, which happily uses both %r3 and %r30 in the code.

ELIMINABLE_REGS isn't defined, we have the default frame pointer
elimination.  If the frame pointer has been eliminated, then %r3
shouldn't be the frame pointer.  I see that %r3 is used in the code
but it's not used as the frame pointer.

Dave


-- 


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

[Bug c/43405] sinl is not computed correctly

[eli dot osherovich at gmail dot com]

--- Comment #5 from eli dot osherovich at gmail dot com  2010-03-17 18:05 
---
The very same code compiled by the Intel C compiler runs as expected.
Moreover, the prototype of sinl is as  follows

long double sinl(long double x);

and 1e22 definitely withing the bounds  of long double.


(In reply to comment #4)
> more details...
> 
> intel (24319101.pdf) manual describe requirements for fsin opcode:
> 
> "Calculates the sine of the source operand in register ST(0) and stores
>  the result in ST(0). The source operand must be given in radians and must
>  be within the range −2^63 to +2^63."
> 
> the 1e+22 is greater than allowed 2^63 ~ 9.22e+18.
> 
> so this bug is rejected by hardware ;)
> 

(In reply to comment #4)
> more details...
> 
> intel (24319101.pdf) manual describe requirements for fsin opcode:
> 
> "Calculates the sine of the source operand in register ST(0) and stores
>  the result in ST(0). The source operand must be given in radians and must
>  be within the range −2^63 to +2^63."
> 
> the 1e+22 is greater than allowed 2^63 ~ 9.22e+18.
> 
> so this bug is rejected by hardware ;)
> 

(In reply to comment #4)
> more details...
> 
> intel (24319101.pdf) manual describe requirements for fsin opcode:
> 
> "Calculates the sine of the source operand in register ST(0) and stores
>  the result in ST(0). The source operand must be given in radians and must
>  be within the range −2^63 to +2^63."
> 
> the 1e+22 is greater than allowed 2^63 ~ 9.22e+18.
> 
> so this bug is rejected by hardware ;)
> 


-- 


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

[Bug tree-optimization/32824] Missed reduction vectorizer after store to global is LIM'd

[burnus at gcc dot gnu dot org]

--- Comment #7 from burnus at gcc dot gnu dot org  2010-03-17 17:58 ---
Patch by Changpeng, which has been approved for 4.6 Stage 1 and moves the
"pass_lim" up;
http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00775.html


-- 


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

[Bug c/43405] sinl is not computed correctly

[pluto at agmk dot net]

--- Comment #4 from pluto at agmk dot net  2010-03-17 17:51 ---
more details...

intel (24319101.pdf) manual describe requirements for fsin opcode:

"Calculates the sine of the source operand in register ST(0) and stores
 the result in ST(0). The source operand must be given in radians and must
 be within the range −2^63 to +2^63."

the 1e+22 is greater than allowed 2^63 ~ 9.22e+18.

so this bug is rejected by hardware ;)


-- 


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

[Bug target/43406] __builtin_popcountll fails with -O0 and -mpopcnt

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2010-03-17 17:47 ---
Fixed in 4.2.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug fortran/43409] I/O: INQUIRE for SIZE does not work.

[burnus at gcc dot gnu dot org]

--- Comment #2 from burnus at gcc dot gnu dot org  2010-03-17 17:43 ---
I was wondering about connected files. (I think it only applies to
inquire_via_unit.) What does one return here if the file has not been flushed?
The *STAT result or does one calls flush on the unit and uses then *STAT?


-- 


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

[Bug fortran/43409] I/O: INQUIRE for SIZE does not work.

[burnus at gcc dot gnu dot org]

--- Comment #1 from burnus at gcc dot gnu dot org  2010-03-17 17:34 ---
If one checks libgfortran/io/*, one sees that (dtp->common.flags &
IOPARM_DT_HAS_SIZE) is only used for read.c and transfer.c and is not touched
at all for inquire.c.

Work-around: gfortran offers the STAT, FSTAT, and LSTAT intrinsics.


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu dot
   ||org


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

[Bug c/43405] sinl is not computed correctly

[ebotcazou at gcc dot gnu dot org]

--- Comment #3 from ebotcazou at gcc dot gnu dot org  2010-03-17 17:34 
---
Glibc is a separate project, see http://sources.redhat.com/bugzilla/


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug fortran/43409] New: I/O: INQUIRE for SIZE does not work.

[burnus at gcc dot gnu dot org]

Found at
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/110fb27c70e1a193
Reported by: Philippe Bourdin

The following program always prints "-42" independent whether the file exists
or not. It at least should initialize the variable by "-1".

!---
integer :: i
i = -42
inquire(file='test.dat', size=i)
print *, i
end
!---


"9.9.1.29 SIZE= specifier in the INQUIRE statement"

"The scalar-int-variable in the SIZE= specifier is assigned the size of the
file in file storage units. If the file size cannot be determined, the variable
is assigned the value -1.

"For a file that may be connected for stream access, the file size is the
number of the highest-numbered file storage unit in the file. For a file that
may be connected for sequential or direct access, the file size may be
different from the number of storage units implied by the data in the records;
the exact relationship is processor-dependent."


-- 
   Summary: I/O: INQUIRE for SIZE does not work.
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org


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

[Bug c/43405] sinl is not computed correctly

[pluto at agmk dot net]

--- Comment #2 from pluto at agmk dot net  2010-03-17 17:28 ---
this is a bug in glibc-2.11.1/sysdeps/x86_64/fpu/s_sinl.S


-- 


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

[Bug c++/43408] Specifying visibility attribute of C++0x enum class emits warning

[paolo dot carlini at oracle dot com]

--- Comment #1 from paolo dot carlini at oracle dot com  2010-03-17 17:21 
---


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


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c++/43407] Specifying visibility attribute of C++0x enum class emits warning

[paolo dot carlini at oracle dot com]

--- Comment #1 from paolo dot carlini at oracle dot com  2010-03-17 17:21 
---
*** Bug 43408 has been marked as a duplicate of this bug. ***


-- 


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

[Bug c++/43408] New: Specifying visibility attribute of C++0x enum class emits warning

[travis at gockelhut dot com]

If one specifies any visibility attribute on an enum class emits the "type
attributes ignored after type is already defined" warning.

Easy to reproduce!  Just add the following lines anywhere and compile them
(without -Wno-attributes):

enum class __attribute__((visibility("default"))) Number
{
Zero, One, Two
};

Obviously this isn't a major concern, since the end result is almost nothing
and 
it certainly isn't "wrong," since the non-finalized standard will not detail
any 
of this behavior, but it kind of annoying in a slight way (barely).


-- 
   Summary: Specifying visibility attribute of C++0x enum class
emits warning
   Product: gcc
   Version: 4.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: travis at gockelhut dot com
 GCC build triplet: 3
  GCC host triplet: 4
GCC target triplet: 4


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

[Bug tree-optimization/43402] [4.5 Regression] dom1 miscompiles binary search

[matz at gcc dot gnu dot org]

--- Comment #9 from matz at gcc dot gnu dot org  2010-03-17 17:03 ---
http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00774.html


-- 


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

[Bug c++/43407] New: Specifying visibility attribute of C++0x enum class emits warning

[travis at gockelhut dot com]

If one specifies any visibility attribute on an enum class emits the "type
attributes ignored after type is already defined" warning.

Easy to reproduce!  Just add the following lines anywhere and compile them
(without -Wno-attributes):

enum class __attribute__((visibility("default"))) Number
{
Zero, One, Two
};

Obviously this isn't a major concern, since the end result is almost nothing
and 
it certainly isn't "wrong," since the non-finalized standard will not detail
any 
of this behavior, but it kind of annoying in a slight way (barely).


-- 
   Summary: Specifying visibility attribute of C++0x enum class
emits warning
   Product: gcc
   Version: 4.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: travis at gockelhut dot com
 GCC build triplet: 3
  GCC host triplet: 4
GCC target triplet: 4


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

[Bug tree-optimization/43402] [4.5 Regression] dom1 miscompiles binary search

[rguenth at gcc dot gnu dot org]

--- Comment #8 from rguenth at gcc dot gnu dot org  2010-03-17 16:42 ---
(In reply to comment #7)
> Hmm, I wonder how that could cause the bug.  Probably because we can't rely
> on SSA form being uptodate during cfgcleanup, and hence looking up PHI
> arguments is wrong, at least for those SSA names that are registered for
> updating.

But you can't have SSA names around when you rename its symbol.  And only
with SSA names the lookup is performed.

After DOM (but before cfgcleanup completes) we have

:
  # start_1 = PHI 
  # limit_2 = PHI 
  # lastMid_3 = PHI 
  D.1978_9 = start_1 + limit_2;
  mid_10 = D.1978_9 >> 1;
  if (lastMid_3 == mid_10)
goto ;
  else
goto ;

which is then simplified.

Hm.  It seems we have a SSA name replacement table, thus probably the
cfgcleanup lookup code has to honor this.

The following seems to fix it:

Index: tree-cfgcleanup.c
===
*** tree-cfgcleanup.c   (revision 157512)
--- tree-cfgcleanup.c   (working copy)
*** cleanup_control_expr_graph (basic_block
*** 100,123 
  {
tree lhs = gimple_cond_lhs (stmt);
tree rhs = gimple_cond_rhs (stmt);
!   /* For conditions try harder and lookup single-argument
!  PHI nodes.  Only do so from the same basic-block though
!  as other basic-blocks may be dead already.  */
!   if (TREE_CODE (lhs) == SSA_NAME)
  {
!   gimple def_stmt = SSA_NAME_DEF_STMT (lhs);
!   if (gimple_code (def_stmt) == GIMPLE_PHI
!   && gimple_phi_num_args (def_stmt) == 1
!   && gimple_bb (def_stmt) == gimple_bb (stmt))
! lhs = PHI_ARG_DEF (def_stmt, 0);
! }
!   if (TREE_CODE (rhs) == SSA_NAME)
! {
!   gimple def_stmt = SSA_NAME_DEF_STMT (rhs);
!   if (gimple_code (def_stmt) == GIMPLE_PHI
!   && gimple_phi_num_args (def_stmt) == 1
!   && gimple_bb (def_stmt) == gimple_bb (stmt))
! rhs = PHI_ARG_DEF (def_stmt, 0);
  }
val = fold_binary_loc (loc, gimple_cond_code (stmt),
   boolean_type_node, lhs, rhs);
--- 100,126 
  {
tree lhs = gimple_cond_lhs (stmt);
tree rhs = gimple_cond_rhs (stmt);
!   if (!name_mappings_registered_p ())
  {
!   /* For conditions try harder and lookup single-argument
!  PHI nodes.  Only do so from the same basic-block though
!  as other basic-blocks may be dead already.  */
!   if (TREE_CODE (lhs) == SSA_NAME)
! {
!   gimple def_stmt = SSA_NAME_DEF_STMT (lhs);
!   if (gimple_code (def_stmt) == GIMPLE_PHI
!   && gimple_phi_num_args (def_stmt) == 1
!   && gimple_bb (def_stmt) == gimple_bb (stmt))
! lhs = PHI_ARG_DEF (def_stmt, 0);
! }
!   if (TREE_CODE (rhs) == SSA_NAME)
! {
!   gimple def_stmt = SSA_NAME_DEF_STMT (rhs);
!   if (gimple_code (def_stmt) == GIMPLE_PHI
!   && gimple_phi_num_args (def_stmt) == 1
!   && gimple_bb (def_stmt) == gimple_bb (stmt))
! rhs = PHI_ARG_DEF (def_stmt, 0);
! }
  }
val = fold_binary_loc (loc, gimple_cond_code (stmt),
   boolean_type_node, lhs, rhs);

though the essence of r157093 was to capture single-valued PHI nodes
with constant operands, so we could restrict the lookup to consider
constants only.


-- 

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|2010-03-17 15:21:02 |2010-03-17 16:42:29
   date||


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

[Bug bootstrap/43403] [4.5 Regression] ICE in stage1 compiling __bswapdi2

[jakub at gcc dot gnu dot org]

--- Comment #5 from jakub at gcc dot gnu dot org  2010-03-17 16:36 ---
var-tracking expects that if frame_pointer_rtx (resp. arg_pointer_rtx,
depending on whether FRAME_POINTER_CFA_OFFSET or ARG_POINTER_CFA_OFFSET is
defined)
is said to be eliminated (to stack_pointer_rtx in case of
!frame_pointer_needed), then it is actually eliminated.  Apparently that's not
the case on PA, which happily uses both %r3 and %r30 in the code.
I guess
--- var-tracking.c.jj22010-03-17 15:29:42.0 +0100
+++ var-tracking.c2010-03-17 17:15:09.0 +0100
@@ -7942,6 +7942,11 @@ vt_init_cfa_base (void)
 #else
   cfa_base_rtx = arg_pointer_rtx;
 #endif
+  if (cfa_base_rtx == hard_frame_pointer_rtx)
+{
+  cfa_base_rtx = NULL_RTX;
+  return;
+}
   if (!MAY_HAVE_DEBUG_INSNS)
 return;


can fix this, that will rule out PA with its arg_pointer_rtx ==
frame_pointer_rtx == hard_frame_pointer_rtx.


-- 


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

[Bug c/43406] __builtin_popcountll fails with -O0 and -mpopcnt

[rbarreira at gmail dot com]

--- Comment #1 from rbarreira at gmail dot com  2010-03-17 16:35 ---
Note that if you use scanf ("%llx", &a) and input "" instead of
having a hardcoded value for a, the bug happens both with -O3 and -O0.

To sum up it seems that when the popcnt instruction is actually issued, it's
using a 32-bit instruction instead of 64-bit.


-- 

rbarreira at gmail dot com changed:

   What|Removed |Added

Summary|__builtin_popcountll fails  |__builtin_popcountll fails
   |with -O0 and -mpopcnt   |with -O0 and -mpopcnt


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

[Bug tree-optimization/43402] [4.5 Regression] dom1 miscompiles binary search

[matz at gcc dot gnu dot org]

--- Comment #7 from matz at gcc dot gnu dot org  2010-03-17 16:05 ---
Hmm, I wonder how that could cause the bug.  Probably because we can't rely
on SSA form being uptodate during cfgcleanup, and hence looking up PHI
arguments is wrong, at least for those SSA names that are registered for
updating.


-- 


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

[Bug c/43406] New: __builtin_popcountll fails with -O0 and -mpopcnt

[rbarreira at gmail dot com]

Sample code:

#include 

int main (void)
{
long long a = 0xLL; // 48 bits set
int popcount;

#if 1
popcount = __builtin_popcountll (a);
#else
popcount = __popcountdi2 (a);
#endif

printf ("%llx popcount = %d\n", a, popcount);
return 0;
}

If -mpopcnt is enabled, this code only outputs the correct value (48) when -O3
is on (apparently it's calculating it at compile time). Without optimizations,
it is apparently only counting the bits in the lower dword of the long long
variable.

OTOH, If __popcountdi2 is used, it works correctly (but according to the
assembly code it's not really using the popcnt instruction which means it's
much slower).


Test runs and output follow (note you need a CPU which supports the popcnt
instruction):

=> gcc popcnt.c -o popcnt -Wall -O0 -mpopcnt && ./popcnt
 popcount = 32
=> gcc popcnt.c -o popcnt -Wall -O3 -mpopcnt && ./popcnt
 popcount = 48
=> gcc popcnt.c -o popcnt -Wall -O0 && ./popcnt
 popcount = 48
=> gcc popcnt.c -o popcnt -Wall -O3 && ./popcnt
 popcount = 48


-- 
   Summary: __builtin_popcountll fails with -O0 and -mpopcnt
   Product: gcc
   Version: 4.1.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rbarreira at gmail dot com
 GCC build triplet: i586-suse-linux
  GCC host triplet: i586-suse-linux
GCC target triplet: i586-suse-linux


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

[Bug tree-optimization/43402] [4.5 Regression] dom1 miscompiles binary search

[hjl dot tools at gmail dot com]

--- Comment #6 from hjl dot tools at gmail dot com  2010-03-17 15:51 ---
It is caused by revision 157093:

http://gcc.gnu.org/ml/gcc-cvs/2010-02/msg00676.html


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

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


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

[Bug tree-optimization/43402] [4.5 Regression] dom1 miscompiles binary search

[matz at gcc dot gnu dot org]

--- Comment #5 from matz at gcc dot gnu dot org  2010-03-17 15:49 ---
Hmm, create_edge_and_update_destination_phis is supposed to add new PHI
arguments for the ultimate threading destination.  But it only does so if
there are already PHI nodes in that BB.  We need to create new ones, which
is difficult as we would have to create a new SSA name to hold the result,
and rewrite all dominating uses.  I wonder how this all is supposed to work.


-- 


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

[Bug bootstrap/43399] [4.5 Regression] bootstrap failure in stage1

[robertcnelson at gmail dot com]

--- Comment #4 from robertcnelson at gmail dot com  2010-03-17 15:42 ---
Here here is the preprocessed source.

http://rcn-ee.homeip.net:81/dl/gcc/SVN-157476-trunk-c-armv7l-256-bug43399/save-temps.log

http://rcn-ee.homeip.net:81/dl/gcc/SVN-157476-trunk-c-armv7l-256-bug43399/libgcc2.i

Results from running with:

/opt/trunk/objdir/./gcc/xgcc -v -save-temps -B/opt/trunk/objdir/./gcc/
-B/opt/install-gcc-trunk/armv7l-unknown-linux-gnueabi/bin/
-B/opt/install-gcc-trunk/armv7l-unknown-linux-gnueabi/lib/ -isystem
/opt/install-gcc-trunk/armv7l-unknown-linux-gnueabi/include -isystem
/opt/install-gcc-trunk/armv7l-unknown-linux-gnueabi/sys-include-g -O2 -O2 
-g -O2 -DIN_GCC   -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition  -isystem ./include  -fPIC
-Wno-missing-prototypes -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2
-D__GCC_FLOAT_NOT_NEEDED   -I. -I. -I../.././gcc -I/opt/trunk/libgcc
-I/opt/trunk/libgcc/. -I/opt/trunk/libgcc/../gcc -I/opt/trunk/libgcc/../include
  -o _muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep -DL_muldi3 -c
/opt/trunk/libgcc/../gcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS^C


-- 


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

[Bug tree-optimization/43402] [4.5 Regression] dom1 miscompiles binary search

[matz at gcc dot gnu dot org]

--- Comment #4 from matz at gcc dot gnu dot org  2010-03-17 15:36 ---
Um, we cleanup the CFG before updating SSA form, hence no wonder that
the missing PHI nodes confuse it.


-- 


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

[Bug tree-optimization/43402] [4.5 Regression] dom1 miscompiles binary search

[matz at gcc dot gnu dot org]

--- Comment #3 from matz at gcc dot gnu dot org  2010-03-17 15:31 ---
It seems the jump threading somehow confuses cfgcleanup.  Right after the
jumps are threaded (in tree_ssa_dominator_optimize after the call to
thread_through_all_blocks) the function looks like so:

:
goto ;

:
# start_16 = PHI 
# limit_19 = PHI 
# lastMid_15 = PHI 

:
# start_1 = PHI 
# limit_2 = PHI 
# lastMid_3 = PHI 
D.2744_9 = start_1 + limit_2;
mid_10 = D.2744_9 / 2;
if (lastMid_3 == mid_10)
  goto ;
else
  goto ;

:
if (result_14 > 0)
  goto ;
else
  goto ;

:
D.2754_17 = cnvNameType[mid_10].type;
D.2753_18 = converterData[D.2754_17];

:
# D.2753_4 = PHI 
return D.2753_4;

:
# start_21 = PHI <0(2)>
# limit_22 = PHI <3(2)>
# lastMid_23 = PHI <4294967295(2)>
D.2744_24 = start_1 + limit_2;
mid_25 = D.2744_9 / 2;
goto ;

:

:
D.2746_12 = cnvNameType[mid_10].name;
result_14 = __builtin_strcmp (realName_13(D), D.2746_12);
if (result_14 < 0)
  goto ;
else
  goto ;

At that point the PHI nodes for BB 10 are still missing, and we have
registered these ssaname updates:

start_21 -> { start_1 }
limit_22 -> { limit_2 }
lastMid_23 -> { lastMid_3 }
D.2744_24 -> { D.2744_9 }
mid_25 -> { mid_10 }

With the right PHI nodes at bb 10 the code still looks good.  But somehow
cfgcleanup scrambles the whole thing.


-- 


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

[Bug c/43405] sinl is not computed correctly

[eli dot osherovich at gmail dot com]

--- Comment #1 from eli dot osherovich at gmail dot com  2010-03-17 15:29 
---
Created an attachment (id=20131)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20131&action=view)
testcase as a standalone file


-- 


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

[Bug c/43405] New: sinl is not computed correctly

[eli dot osherovich at gmail dot com]

sinl (and probably others) are not computed correctly. At least for large
inputs.

Please consider the following simple testcase:

$ cat sintest.c

#include 
#include 

int
main (void) {
  double arg = 1e22;
  long double larg = 1e22L;


  printf("double precision: sin(1e22) = %.16lf\n", sin(arg));
  printf("quad precison: sin(1e22)=%.16Lf\n", sinl(larg));

  return 0;
}


$gcc sintest.c
$./a.out
double precision: sin(1e22) = -0.8522008497671888
quad precison: sin(1e22)=0.4626130407646018


This behavior is demonstrated by gcc-4.4.3 and gcc-4.5 (current snapshot)

I am using ubuntu on a 64 bit linux machine (intel). 

However, the same results were obtained on different machines.


-- 
   Summary: sinl is not computed correctly
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: eli dot osherovich at gmail dot com
  GCC host triplet: x86_64-linux-gnu


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

[Bug middle-end/43365] [4.5 Regression] Destructor not called when returning in exception handler

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2010-03-17 15:24 ---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug tree-optimization/43402] [4.5 Regression] dom1 miscompiles binary search

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2010-03-17 15:21 ---
Confirmed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||wrong-code
   Priority|P3  |P1
   Last reconfirmed|-00-00 00:00:00 |2010-03-17 15:21:02
   date||


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

[Bug c/43385] [4.5 Regression] glibc regex testsuite failures

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2010-03-17 15:19 ---
Waiting for testcase.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug c/43384] [4.3/4.4/4.5 Regression] ICE: Segmentation fault with invalid K&R-like code

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P5


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

[Bug c/43381] [4.4/4.5 Regression] infinite loop in gcc.dg/parm-impl-decl-1.c with -g

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P2


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

[Bug middle-end/42860] ICE in gcc-4.4.3 with graphite

[spop at gcc dot gnu dot org]

--- Comment #4 from spop at gcc dot gnu dot org  2010-03-17 15:14 ---
See PR43398 for a nicely reduced testcase.


-- 


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

[Bug middle-end/42860] ICE in gcc-4.4.3 with graphite

[spop at gcc dot gnu dot org]

--- Comment #3 from spop at gcc dot gnu dot org  2010-03-17 15:13 ---
*** Bug 43398 has been marked as a duplicate of this bug. ***


-- 

spop at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||scientica at gmail dot com


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

[Bug c/43398] ICE with -O -floop-block

[spop at gcc dot gnu dot org]

--- Comment #2 from spop at gcc dot gnu dot org  2010-03-17 15:13 ---
This looks like a duplicate of PR42860.
This works on gcc4.5.

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


-- 

spop at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Known to work||4.5.0
 Resolution||DUPLICATE


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

[Bug rtl-optimization/43058] [4.5 Regression] var-tracking uses up all virtual memory

[jakub at gcc dot gnu dot org]

--- Comment #13 from jakub at gcc dot gnu dot org  2010-03-17 15:05 ---
Created an attachment (id=20130)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20130&action=view)
gcc45-pr43058.patch

So far untested fix.  This just optimizes handling of optimized out variables
which are known to be constant (in some part of the code or whole function).
We don't need to change the location list every time the constant value is
assigned to some register or memory.  That's unlike vars that actually live in
some register or memory at some point, there of course we want to have the
location for the register/memory so that the debugger can change it.
The testcase keeps pushing .LC0 resp. LC1 into some register (or MEM slot) and
then every call actually clobbers that reg resp. MEM slot, so after every set
of the reg resp. mem var-tracking was generating up to 1000 var_location notes
for every a decl with that value, then in the middle of every call another up
to 1000 var_location notes that the var now is constant and doesn't live in the
reg or mem.

While it is IMHO desirable to do what this patch does in any case, I'll try to
come up with another solution which would try to keep the location list less
fragmented.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug bootstrap/43403] [4.5 Regression] ICE in stage1 compiling __bswapdi2

[dave at hiauly1 dot hia dot nrc dot ca]

--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca  2010-03-17 
15:03 ---
Subject: Re:  [4.5 Regression] ICE in stage1 compiling
__bswapdi2

> Can you attach preprocessed source?

Attached.

Dave


--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca  2010-03-17 
15:03 ---
Created an attachment (id=20129)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20129&action=view)


-- 


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

[Bug c/43404] ARM: Internal compiler error when using '&foo' in naked function

[marti at juffo dot org]

--- Comment #1 from marti at juffo dot org  2010-03-17 15:03 ---
Created an attachment (id=20128)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20128&action=view)
test.i


-- 


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

[Bug c/43404] New: ARM: Internal compiler error when using '&foo' in naked function

[marti at juffo dot org]

Tested with GCC 4.4.1 and 4.4.3 (custom built) on Arch Linux
host arch is x86_64 and target is arm-elf

This is the full source code needed to reproduce the bug:

void __data_abort(void) __attribute__ ((naked));
void __data_abort(void)
{
  long foo;
  long* bar = &foo;
}

test.c: In function ‘__data_abort’:
test.c:5: warning: unused variable ‘bar’
test.c:5: internal compiler error: in expand_expr_addr_expr_1, at expr.c:6835

---

% arm-elf-gcc -v -save-temps -Wall -c test.c -o test.o
Using built-in specs.
Target: arm-elf
Configured with: ../configure --prefix=/opt/arm-elf-gcc --target=arm-elf
--enable-interwork --enable-multilib --disable-threads --enable-languages=c,c++
--with-newlib
--with-headers=/home/marti/crosschain/gcc-4.4.3/build/../newlib-1.18.0/newlib/libc/include
Thread model: single
gcc version 4.4.3 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-c' '-o' 'test.o'
 /opt/arm-elf-gcc/libexec/gcc/arm-elf/4.4.3/cc1 -E -quiet -v
-D__USES_INITFINI__ test.c -Wall -fpch-preprocess -o test.i
#include "..." search starts here:
#include <...> search starts here:
 /opt/arm-elf-gcc/lib/gcc/arm-elf/4.4.3/include
 /opt/arm-elf-gcc/lib/gcc/arm-elf/4.4.3/include-fixed
 /opt/arm-elf-gcc/lib/gcc/arm-elf/4.4.3/../../../../arm-elf/sys-include
 /opt/arm-elf-gcc/lib/gcc/arm-elf/4.4.3/../../../../arm-elf/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-c' '-o' 'test.o'
 /opt/arm-elf-gcc/libexec/gcc/arm-elf/4.4.3/cc1 -fpreprocessed test.i -quiet
-dumpbase test.c -auxbase-strip test.o -Wall -version -o test.s
GNU C (GCC) version 4.4.3 (arm-elf)
compiled by GNU C version 4.4.3, GMP version 4.3.2, MPFR version 2.4.2.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 913e44b5d872dc5aa4cdba7cf6499b83
test.c: In function ‘__data_abort’:
test.c:5: warning: unused variable ‘bar’
test.c:5: internal compiler error: in expand_expr_addr_expr_1, at expr.c:6835
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 
   Summary: ARM: Internal compiler error when using '&foo' in naked
function
   Product: gcc
   Version: 4.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: marti at juffo dot org
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: arm-elf


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

[Bug tree-optimization/43401] Register not cleand correctly by acessing thru pointer

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2010-03-17 14:57 ---
This is points-to information being computed wrongly.  A lot was fixed for
GCC 4.4.x in this area.

The constraints are already wrong:

arr = &a
arr.32 = &b
arr.64 = &c
arr.96 = &d
D.2332_12 = arr

With 4.4 and 4.5 we do not create subvars for array elements and so end
up with the valid

arr = &a
arr = &b
arr = &c
arr = &d
D.2407_14 = arr

Fixed as part of

2008-05-08  Richard Guenther  

* tree-flow-inline.h (var_can_have_subvars): Move ...
* tree-ssa-structalias.c (var_can_have_subvars): ... here.
* tree-flow.h (var_can_have_subvars): Remove.
(push_fields_onto_fieldstack): Remove.
(sort_fieldstack): Likewise.
(struct fieldoff): Move ...
* tree-ssa-structalias.c (struct fieldoff): ... here.  Remove
alias_set and base_for_components fields.
(sort_fieldstack): Make static.
(push_fields_onto_fieldstack): Likewise.  Remove code that
handles anything but RECORD_TYPEs.  Remove alias_set and
base_for_components handling.
(create_variable_info_for): Adjust.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Component|c   |tree-optimization
 Ever Confirmed|0   |1
  Known to work||4.4.0
   Last reconfirmed|-00-00 00:00:00 |2010-03-17 14:57:33
   date||


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

[Bug c++/43327] ICE in unifiy.c

[dodji at gcc dot gnu dot org]

--- Comment #3 from dodji at gcc dot gnu dot org  2010-03-17 14:55 ---
A patch was proposed at http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00662.html


-- 


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

[Bug middle-end/43391] [4.5 Regression] make_decl_rtl failure for C++ on AIX and HPUX

[hubicka at gcc dot gnu dot org]

--- Comment #3 from hubicka at gcc dot gnu dot org  2010-03-17 14:42 ---
Mine. Looking into it now.
We might even want to simply relax the checking if it triggers on lately build
stuff like tinfos. Let me see if I can avoid tinfos producing "mallformed"
decls.


-- 

hubicka at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |hubicka at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2010-03-16 14:47:37 |2010-03-17 14:42:31
   date||


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

[Bug bootstrap/43403] [4.5 Regression] ICE in stage1 compiling __bswapdi2

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2010-03-17 14:41 ---
Can you attach preprocessed source?


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu dot org
   Target Milestone|--- |4.5.0


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

[Bug bootstrap/43403] [4.5 Regression] ICE in stage1 compiling __bswapdi2

[danglin at gcc dot gnu dot org]

--- Comment #1 from danglin at gcc dot gnu dot org  2010-03-17 14:30 ---
d...@gsyprf11:~/gcc-4.5/objdir/gcc$ ./xgcc -B./ -v
Reading specs from ./specs
COLLECT_GCC=./xgcc
COLLECT_LTO_WRAPPER=./lto-wrapper
Target: hppa-linux
Configured with: ../gcc/configure --with-gnu-as --with-gnu-ld --enable-shared
--enable-nls --prefix=/home2/dave/opt/gnu/gcc/gcc-4.5.0
--with-local-prefix=/home2/dave/opt/gnu --enable-threads=posix
--enable-__cxa_atexit --build=hppa-linux --enable-clocale=gnu
--enable-java-gc=boehm --enable-java-awt=xlib
--enable-languages=c,c++,objc,fortran,obj-c++,java,ada
Thread model: posix
gcc version 4.5.0 20100317 (experimental) [trunk revision 157506] (GCC)


-- 


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

[Bug bootstrap/43403] New: [4.5 Regression] ICE in stage1 compiling __bswapdi2

[danglin at gcc dot gnu dot org]

/home2/dave/gcc-4.5/objdir/./gcc/xgcc -B/home2/dave/gcc-4.5/objdir/./gcc/
-B/hom
e2/dave/opt/gnu/gcc/gcc-4.5.0/hppa-linux/bin/
-B/home2/dave/opt/gnu/gcc/gcc-4.5.
0/hppa-linux/lib/ -isystem /home2/dave/opt/gnu/gcc/gcc-4.5.0/hppa-linux/include
-isystem /home2/dave/opt/gnu/gcc/gcc-4.5.0/hppa-linux/sys-include-g -O2 -O2
 -g -O2 -DIN_GCC   -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes
-Wmi
ssing-prototypes -Wold-style-definition  -isystem ./include  -fPIC -DELF=1
-DLIN
UX=1 -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED   -I. -I.
-I..
/.././gcc -I../../../gcc/libgcc -I../../../gcc/libgcc/.
-I../../../gcc/libgcc/..
/gcc -I../../../gcc/libgcc/../include  -DHAVE_CC_TLS -o _fixunsxfsi.o -MT
_fixun
sxfsi.o -MD -MP -MF _fixunsxfsi.dep -DL_fixunsxfsi -c
../../../gcc/libgcc/../gcc
/libgcc2.c \
  -fvisibility=hidden -DHIDE_EXPORTS
../../../gcc/libgcc/../gcc/libgcc2.c: In function '__bswapdi2':
../../../gcc/libgcc/../gcc/libgcc2.c:513:1: internal compiler error:
Segmentatio
n fault
Please submit a full bug report,

Program received signal SIGSEGV, Segmentation fault.
0x022d7790 in dv_uid (dv=0x3616ec8) at ../../gcc/gcc/var-tracking.c:1043
1043return CSELIB_VAL_PTR (dv_as_value (dv))->uid;
(gdb) by
Undefined command: "by".  Try "help".
(gdb) bt
#0  0x022d7790 in dv_uid (dv=0x3616ec8) at ../../gcc/gcc/var-tracking.c:1043
#1  0x022d7868 in dv_htab_hash (dv=0x3616ec8)
at ../../gcc/gcc/var-tracking.c:1061
#2  0x022dd060 in add_value_chain (loc=0xfdf01e98, dvp=0x3616ed8)
at ../../gcc/gcc/var-tracking.c:2745
...

(gdb) disass 0x022d7780 0x022d77a0
Dump of assembler code from 0x22d7780 to 0x22d77a0:
0x022d7780 : ldw -24(r3),r26
0x022d7784 : b,l 0x22d74b4 ,rp
0x022d7788 : nop
0x022d778c : ldw 4(ret0),ret0
0x022d7790 : ldw 4(ret0),ret0
0x022d7794 : stw ret0,c(r3)
0x022d7798 : b,l,n 0x22d7814 ,r0
0x022d779c : ldw -24(r3),r26
End of assembler dump.
(gdb) p/x $ret0
$1 = 0x0


-- 
   Summary: [4.5 Regression] ICE in stage1 compiling __bswapdi2
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: danglin at gcc dot gnu dot org
 GCC build triplet: hppa-unknown-linux-gnu
  GCC host triplet: hppa-unknown-linux-gnu
GCC target triplet: hppa-unknown-linux-gnu


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

[Bug tree-optimization/43402] [4.5 Regression] dom1 miscompiles binary search

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|dom1 miscompiles binary |[4.5 Regression] dom1
   |search  |miscompiles binary search
   Target Milestone|--- |4.5.0


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

[Bug bootstrap/43399] [4.5 Regression] bootstrap failure in stage1

[robertcnelson at gmail dot com]

--- Comment #3 from robertcnelson at gmail dot com  2010-03-17 14:04 ---
Rebuilding 157476, will take a couple hours to hit that error..

System: gcc -v

voo...@beagle-256mb-1:~$ gcc -v
Using built-in specs.
Target: arm-linux-gnueabi
Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.2-9'
--with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--enable-multiarch --enable-linker-build-id --with-system-zlib
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc
--disable-sjlj-exceptions --enable-checking=release --build=arm-linux-gnueabi
--host=arm-linux-gnueabi --target=arm-linux-gnueabi
Thread model: posix
gcc version 4.4.3 20100108 (prerelease) (Debian 4.4.2-9) 


-- 


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

[Bug tree-optimization/43402] dom1 miscompiles binary search

[matz at gcc dot gnu dot org]

--- Comment #1 from matz at gcc dot gnu dot org  2010-03-17 14:02 ---
Created an attachment (id=20127)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20127&action=view)
testcase

Testcase reduced from ucnv_bld.c of libicu


-- 


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

[Bug tree-optimization/43402] New: dom1 miscompiles binary search

[matz at gcc dot gnu dot org]

This actually happens in libicu, preventing genbrk (and hence openoffice and
texlive) to work.

# gcc -O1 icubug.c && ./a.out
Aborted

With -O0 it works.  The wrong transformation is done by dom1, it transforms
the loop into a linear sequence without backedges.

:
  goto ;

:
  # start_16 = PHI 
  # limit_19 = PHI 
  # lastMid_15 = PHI 

:
  # start_1 = PHI 
  # limit_2 = PHI 
  # lastMid_3 = PHI 
  D.2744_9 = start_1 + limit_2;
  mid_10 = D.2744_9 / 2;
  goto ;

:
  if (result_14 > 0)
goto ;
  else
goto ;

:
  D.2754_17 = cnvNameType[mid_25].type;
  D.2753_18 = converterData[D.2754_17];

:
  # D.2753_4 = PHI 
  return D.2753_4;

:
  # start_21 = PHI <0(2)>
  # limit_22 = PHI <3(2)>
  # lastMid_23 = PHI <4294967295(2)>
  D.2744_24 = start_21 + limit_22;
  mid_25 = D.2744_24 / 2;
  D.2746_12 = cnvNameType[mid_25].name;
  result_14 = __builtin_strcmp (realName_13(D), D.2746_12);
  if (result_14 < 0)
goto ;
  else
goto ;


-- 
   Summary: dom1 miscompiles binary search
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: matz at gcc dot gnu dot org
  GCC host triplet: x86_64-linux


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

[Bug c/43401] Register not cleand correctly by acessing thru pointer

[matthias at goldhoorn dot eu]

--- Comment #4 from matthias at goldhoorn dot eu  2010-03-17 13:57 ---
Forgotten output with optimization:
(10.00,20.00)
(0.00,0.00)
(0.00,0.00)
(0.00,0.00)
sould be:
(10.00,20.00)
(10.00,20.00)
(10.00,20.00)
(10.00,20.00)


without optimization:
(10.00,20.00)
(10.00,20.00)
(10.00,20.00)
(10.00,20.00)
sould be:
(10.00,20.00)
(10.00,20.00)
(10.00,20.00)
(10.00,20.00)


(In reply to comment #0)
> On the assigned file you can reproduce the bug.
> 
> If you compile this file with -O2 the error occures, only way is use -O0 or 
> use
> volatile statement for the double arrays.
> 
> I think this should be checkt during optimization.
> 
> Greets,
> Matthias
> 


-- 


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

[Bug c/43401] Register not cleand correctly by acessing thru pointer

[matthias at goldhoorn dot eu]

--- Comment #3 from matthias at goldhoorn dot eu  2010-03-17 13:55 ---
Created an attachment (id=20126)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20126&action=view)
Object Dumpo with optimization (broken result)


-- 


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