[Bug target/45540] interrupt handler stack pointer is wrong

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2010-09-05 06:41 ---


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


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug target/41999] Bug in generation of interrupt function code for ARM processor

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2010-09-05 06:41 ---
*** Bug 45540 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ethan at evolution dot com


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

[Bug rtl-optimization/41849] optimization fails when register variables are used for an interrupt

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|critical|normal


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

[Bug c/45540] New: interrupt handler stack pointer is wrong

[ethan at evolution dot com]

The stack pointer is erroneously adjusted in the prologue of an FIQ interrupt
handler, and not corrected before popping the pc in the epilogue.  The same
error occurs with IRQ handlers if frame pointers are not omitted.  I believe
the compiler is attempting to align the stack to an 8 byte boundary, and not
reversing the adjustment before popping.

The input
-

void foo(void);

__attribute((interrupt("FIQ"))) void fiq_handler()
{
foo();
}

The output
-

fiq_handler:
sub lr, lr, #4
stmfd   sp!, {r0, r1, r2, r3, lr}
sub sp, sp, #4 ; <-- why is this here?
bl  foo
ldmfd   sp!, {r0, r1, r2, r3, pc}^ ; <-- this is now wrong

compile line:
---
$ arm-none-eabi-gcc -march=armv5 -save-temps -fomit-frame-pointer -S fiq_test.c

arm-none-eabi-gcc -v:
-
Using built-in specs.
COLLECT_GCC=arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/opt/arm-eabi-toolchain/libexec/gcc/arm-none-eabi/4.5.0/lto-wrapper
Target: arm-none-eabi
Configured with: ../gcc-4.5.0/configure --target=arm-none-eabi
--prefix=/opt/arm-eabi-toolchain --enable-multilib --enable-languages=c,c++
--with-newlib --disable-shared --with-gnu-as --with-gnu-ld --with-fpu=vfp
--with-float=softfp --with-cpu=arm926ej-s --with-arch=armv5te
--with-system-zlib
Thread model: single
gcc version 4.5.0 (GCC)

pre-processed source:
--
# 1 "fiq_test.c"
# 1 ""
# 1 ""
# 1 "fiq_test.c"
void foo(void);

__attribute((interrupt("FIQ"))) void fiq_handler()
{
foo();
}


-- 
   Summary: interrupt handler stack pointer is wrong
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ethan at evolution dot com
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: arm-none-eabi


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

[Bug c++/45539] New: Redeclare a deleted funciton makes gcc does not issue compile error

[boostcpp at gmail dot com]

I think re-declare a deleted function is well-formed.

void f() = delete ; // shall be the first declaration of the function
void f() ; // re-declare a previous deleted function.

But doing so makes gcc does not issue correct compile errors on following code.

void f() = delete ;
void f() ; // if I comment out this line. gcc issues correct errors.

int main()
{
// should be error: use of deleted function 'void f()'
// gcc does not issue error for this.
typedef decltype(f) type ;

// gcc issues error for this.
// However, error message was: undefined reference to `f()'
// correct error should be: use of deleted function 'void f()'
f() ;
}


-- 
   Summary: Redeclare a deleted funciton makes gcc does not issue
compile error
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: boostcpp at gmail dot com


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

[Bug bootstrap/45538] --enable-build-with-cxx compiling gcc/libcpp/charset.c

[howarth at nitro dot med dot uc dot edu]

--- Comment #2 from howarth at nitro dot med dot uc dot edu  2010-09-05 
05:40 ---
The same bootstrap failure occurs on x86_64 Fedora 10 with...

../gcc/configure --with-gmp=/usr --with-mpfr=/usr --with-mpc=/usr
--prefix=/home/howarth/dist --enable-languages=c,c++ --enable-build-with-cxx

which fails with...

g++  -I../../gcc/libcpp -I. -I../../gcc/libcpp/../include
-I../../gcc/libcpp/include  -g -W -Wall -Wwrite-strings
-Wmissing-format-attribute -pedantic -Wno-long-long  -I../../gcc/libcpp -I.
-I../../gcc/libcpp/../include -I../../gcc/libcpp/include  -c -o charset.o -MT
charset.o -MMD -MP -MF .deps/charset.Tpo ../../gcc/libcpp/charset.c
In file included from ../../gcc/libcpp/system.h:30,
 from ../../gcc/libcpp/charset.c:22:
/usr/lib/gcc/x86_64-redhat-linux/4.3.2/include/stddef.h:152: error: multiple
types in one declaration
/usr/lib/gcc/x86_64-redhat-linux/4.3.2/include/stddef.h:152: error: declaration
does not declare anything


-- 


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

[Bug target/45524] r163815/r163816 produces new regressions on x86_64-apple-darwin10

[howarth at nitro dot med dot uc dot edu]

--- Comment #34 from howarth at nitro dot med dot uc dot edu  2010-09-05 
04:57 ---
Regression result for gcc-pr45524-3.patch on x86_64-apple-darwin10.

http://gcc.gnu.org/ml/gcc-testresults/2010-09/msg00410.html


-- 


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

[Bug bootstrap/45538] --enable-build-with-cxx compiling gcc/libcpp/charset.c

[howarth at nitro dot med dot uc dot edu]

--- Comment #1 from howarth at nitro dot med dot uc dot edu  2010-09-05 
04:46 ---
Created an attachment (id=21701)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21701&action=view)
failed bootstrap log on x86_64-apple-darwin10 with --enable-build-with-cxx


-- 


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

[Bug bootstrap/45538] New: --enable-build-with-cxx compiling gcc/libcpp/charset.c

[howarth at nitro dot med dot uc dot edu]

Current gcc trunk no longer bootstraps with --enable-build-with-cxx on
x86_64-apple-darwin10. The build fails at...

config.status: executing depdir commands
mkdir .deps
g++  -I../../gcc/libcpp -I. -I../../gcc/libcpp/../include
-I../../gcc/libcpp/include  -g -W -Wall -Wwrite-strings
-Wmissing-format-attribute -pedantic -Wno-long-long  -I../../gcc/libcpp -I.
-I../../gcc/libcpp/../include -I../../gcc/libcpp/include  -c -o charset.o -MT
charset.o -MMD -MP -MF .deps/charset.Tpo ../../gcc/libcpp/charset.c
In file included from ../../gcc/libcpp/charset.c:22:
../../gcc/libcpp/system.h:260:21: warning: libintl.h: No such file or directory
In file included from ../../gcc/libcpp/system.h:30,
 from ../../gcc/libcpp/charset.c:22:
/usr/lib/gcc/i686-apple-darwin10/4.2.1/include/stddef.h:152: error: multiple
types in one declaration
/usr/lib/gcc/i686-apple-darwin10/4.2.1/include/stddef.h:152: error: declaration
does not declare anything
make[3]: *** [charset.o] Error 1
make[2]: *** [all-stage1-libcpp] Error 2
make[1]: *** [stage1-bubble] Error 2
make: *** [all] Error 2

when the build is configured as...

../gcc/configure --prefix=/Users/howarth/dist --with-gmp=/sw
--with-libiconv-prefix=/sw --with-ppl=/sw --with-cloog=/sw --with-mpc=/sw
--with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib
--enable-checking=yes --enable-languages=c,c++ --enable-build-with-cxx


-- 
   Summary: --enable-build-with-cxx compiling gcc/libcpp/charset.c
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: howarth at nitro dot med dot uc dot edu
 GCC build triplet: x86_64-apple-darwin10
  GCC host triplet: x86_64-apple-darwin10
GCC target triplet: x86_64-apple-darwin10


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

[Bug target/45524] r163815/r163816 produces new regressions on x86_64-apple-darwin10

[hjl dot tools at gmail dot com]

--- Comment #33 from hjl dot tools at gmail dot com  2010-09-05 03:22 
---
A patch is posted at

http://gcc.gnu.org/ml/gcc-patches/2010-09/msg00375.html


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2010-
   ||09/msg00375.html


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

[Bug bootstrap/45518] [4.6 regression] bootstrap failure on sparc64-unknown-linux-gnu

[froydnj at codesourcery dot com]

--- Comment #4 from froydnj at codesourcery dot com  2010-09-05 01:38 
---
Subject: Re:  [4.6 regression] bootstrap failure on
sparc64-unknown-linux-gnu

On Sat, Sep 04, 2010 at 01:38:34PM -, mikpe at it dot uu dot se wrote:
> Can you show us the complete configure options you used?

gcc63 is down at the moment for scheduled maintenance, so I can't quote
exactly.  As best I can recall, it was:

CC='gcc -m64' /path/to/configure --disable-lib{mudflap,ssp,gomp} \
  --enable-languages=c --disable-nls --enable-threads=posix \
  --with-mpfr=/opt/cfarm/mpfr-2.4.1-64 \
  --with-gmp=/opt/cfarm/gmp-4.2.4-64 --with-mpc=/opt/cfarm/mpc-0.8-64

The --with-* options are specific to compile farm machines.

I talked to Bernd and he had some suggestions for figuring out exactly
what gets miscompiled; due to gcc63 downtime, I haven't had a change to
try those yet.


-- 


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

[Bug fortran/34145] single_char_string.f90 fails with -fdefault-integer-8

[tkoenig at gcc dot gnu dot org]

-- 

tkoenig at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |tkoenig at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2007-11-21 12:25:42 |2010-09-04 23:26:31
   date||


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

[Bug target/36502] i386/darwin generates unnecessary stack ops in every function

[howarth at nitro dot med dot uc dot edu]

--- Comment #43 from howarth at nitro dot med dot uc dot edu  2010-09-04 
21:21 ---
Updated patch to reflect the wider coverage of PRs fixed...
http://gcc.gnu.org/ml/gcc-patches/2010-09/msg00365.html


-- 


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

[Bug target/44651] gcc.target/x86_64/abi/callabi/leaf-[1,2].c fail on darwin

[howarth at nitro dot med dot uc dot edu]

--- Comment #6 from howarth at nitro dot med dot uc dot edu  2010-09-04 
21:20 ---
Updated patch to reflect the wider coverage of PRs fixed...
http://gcc.gnu.org/ml/gcc-patches/2010-09/msg00365.html


-- 


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

[Bug target/42313] FAIL: gcc.target/i386/builtin-unreachable.c scan-assembler-not %e[bs]p on i686 darwin

[howarth at nitro dot med dot uc dot edu]

--- Comment #9 from howarth at nitro dot med dot uc dot edu  2010-09-04 
21:20 ---
Updated patch to reflect the wider coverage of PRs fixed...
http://gcc.gnu.org/ml/gcc-patches/2010-09/msg00365.html


-- 


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

[Bug target/36502] i386/darwin generates unnecessary stack ops in every function

[howarth at nitro dot med dot uc dot edu]

--- Comment #42 from howarth at nitro dot med dot uc dot edu  2010-09-04 
20:39 ---
Posted final version of proposed patch to...

http://gcc.gnu.org/ml/gcc-patches/2010-09/msg00237.html

This patch also fixes PR42313 and PR44651 as yet another added bonus.


-- 


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

[Bug lto/45375] [meta-bug] Mozilla does not build with LTO

[hubicka at gcc dot gnu dot org]

--- Comment #5 from hubicka at gcc dot gnu dot org  2010-09-04 20:39 ---
Oprofile of WHOPR build.  It is quite suprrising how low the usual cpu hogs
shows..
1139097.6329  lto1 lto1
htab_find_slot_with_hash
42787 2.8671  libc-2.11.1.so   libc-2.11.1.so   _int_malloc
36514 2.4468  lto1 lto1
iterative_hash_hashval_t
36289 2.4317  libelf.so.0.8.12 libelf.so.0.8.12
/usr/lib64/libelf.so.0.8.12
28366 1.9008  lto1 lto1 htab_expand
27648 1.8527  libc-2.11.1.so   libc-2.11.1.so   memset
27045 1.8123  lto1 lto1
cgraph_edge_badness
26670 1.7871  lto1 lto1
inflate_fast
25955 1.7392  lto1 lto1
lto_input_tree
20010 1.3408  lto1 lto1
lto_input_uleb128
18853 1.2633  lto1 lto1
bitmap_set_bit
16452 1.1024  as   as   /usr/bin/as
16215 1.0865  lto1 lto1
lto_input_1_unsigned
16141 1.0816  lto1 lto1
lto_output_1_stream
15244 1.0215  libc-2.11.1.so   libc-2.11.1.so   memcpy
15241 1.0213  lto1 lto1
htab_hash_string
13806 0.9251  lto1 lto1
record_reg_classes.constprop.10
13743 0.9209  lto1 lto1
lto_output_tree
13220 0.8859  lto1 lto1
ggc_internal_alloc_stat
12879 0.8630  libc-2.11.1.so   libc-2.11.1.so  
malloc_consolidate
12847 0.8609  libc-2.11.1.so   libc-2.11.1.so   _int_free
11712 0.7848  lto1 lto1
lto_streamer_cache_insert_1
11593 0.7768  lto1 lto1
linemap_lookup
11100 0.7438  lto1 lto1
ht_lookup_with_hash
10837 0.7262  lto1 lto1 gtc_visit
10460 0.7009  lto1 lto1
cgraph_estimate_growth
10438 0.6994  lto1 lto1
value_member
9812  0.6575  lto1 lto1 walk_tree_1
9316  0.6243  oprofiledoprofiled   
/usr/bin/oprofiled
8979  0.6017  libc-2.11.1.so   libc-2.11.1.so   malloc
8825  0.5914  libc-2.11.1.so   libc-2.11.1.so   free
8625  0.5780  lto1 lto1
pointer_set_insert
8304  0.5564  lto1 lto1
ggc_set_mark
8276  0.5546  lto1 lto1
type_pair_eq
8089  0.5420  lto1 lto1
gimple_types_compatible_p_1
7981  0.5348  lto1 lto1
lto_output_uleb128_stream
7388  0.4951  lto1 lto1
df_note_compute
7349  0.4924  lto1 lto1
operand_equal_p
7349  0.4924  lto1 lto1
pointer_map_contains
7117  0.4769  lto1 lto1
bitmap_bit_p
7067  0.4736  lto1 lto1 pool_alloc
7030  0.4711  lto1 lto1
verify_cgraph_node
6954  0.4660  lto1 lto1
lto_input_sleb128
6947  0.4655  lto1 lto1
gt_ggc_mx_lang_tree_node
6747  0.4521  libc-2.11.1.so   libc-2.11.1.so   calloc
6403  0.4291  lto1 lto1 htab_delete
6360  0.4262  lto1 lto1
constrain_operands.part.12
6198  0.4153  lto1 lto1
bitmap_clear_bit
6103  0.4090  lto1 lto1 cse_insn


-- 


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

[Bug testsuite/44651] gcc.target/x86_64/abi/callabi/leaf-[1,2].c fail on darwin

[howarth at nitro dot med dot uc dot edu]

--- Comment #5 from howarth at nitro dot med dot uc dot edu  2010-09-04 
20:28 ---
My proposed patch to fix PR36502...

http://gcc.gnu.org/ml/gcc-patches/2010-09/msg00237.html

also fixes this regression as can be since from the diff of leaf.s generated
with gcc trunk before and after applying my patch...


--- leaf-1.s2010-09-04 16:26:13.0 -0400
+++ leaf-1.s.patched_trunk  2010-09-04 16:24:35.0 -0400
@@ -3,11 +3,7 @@
.globl _foo
 _foo:
 LFB0:
-   subq$8, %rsp
-LCFI0:
xorl%eax, %eax
-   addq$8, %rsp
-LCFI1:
ret
 LFE0:
.section
__TEXT,__eh_frame,coalesced,no_toc+strip_static_syms+live_support
@@ -39,16 +35,6 @@
.set L$set$2,LFE0-LFB0
.quad L$set$2
.byte   0
-   .byte   0x4
-   .set L$set$3,LCFI0-LFB0
-   .long L$set$3
-   .byte   0xe
-   .byte   0x10
-   .byte   0x4
-   .set L$set$4,LCFI1-LCFI0
-   .long L$set$4
-   .byte   0xe
-   .byte   0x8
.align 3
 LEFDE1:
.subsections_via_symbols


-- 


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

[Bug fortran/45530] gfortran internal compiler error

[burnus at gcc dot gnu dot org]

--- Comment #5 from burnus at gcc dot gnu dot org  2010-09-04 19:49 ---
FIXED on the trunk (4.6) and on the 4.5 branch.

Thanks for the bug report!


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug fortran/45489] Default initialization of derived-type function result missing

[burnus at gcc dot gnu dot org]

--- Comment #6 from burnus at gcc dot gnu dot org  2010-09-04 19:48 ---
FIXED.


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug testsuite/43957] [4.6 Regression] FAIL: gcc.dg/const-uniq-1.c scan-tree-dump-times gimple "LC0" 2

[danglin at gcc dot gnu dot org]

--- Comment #5 from danglin at gcc dot gnu dot org  2010-09-04 19:46 ---
Fixed.


-- 

danglin at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||FIXED


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

gcc-bugs@gcc.gnu.org

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2010-09-04 19:41 ---
std::make_pair< void*, int > takes rvalue references which cannot bind to
lvalues.

See the discussion in PR 43785.

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


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug libstdc++/43785] [C++0x] std::make_pair vs explicit template arguments

[pinskia at gcc dot gnu dot org]

--- Comment #20 from pinskia at gcc dot gnu dot org  2010-09-04 19:41 
---
*** Bug 45537 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pluto at agmk dot net


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

[Bug testsuite/43957] [4.6 Regression] FAIL: gcc.dg/const-uniq-1.c scan-tree-dump-times gimple "LC0" 2

[danglin at gcc dot gnu dot org]

--- Comment #4 from danglin at gcc dot gnu dot org  2010-09-04 19:40 ---
Subject: Bug 43957

Author: danglin
Date: Sat Sep  4 19:40:07 2010
New Revision: 163867

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163867
Log:
PR testsuite/43957
* gcc.dg/const-uniq-1.c: Modify regexp.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/const-uniq-1.c


-- 


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

gcc-bugs@gcc.gnu.org

[pluto at agmk dot net]

% cat t.cpp
#include 
void test()
{
void* p = 0;
int i = 0;
std::make_pair< void*, int >( p, i );
}

% make
/local/devel/toolchain45/x86_64-gnu-linux.mt_alloc/bin/x86_64-gnu-linux-g++  
t.cpp -c -std=gnu++0x -o /dev/null
t.cpp: In function 'void test()':
t.cpp:6:37: error: no matching function for call to 'make_pair(void*&, int&)'


btw. comeau accepts this code.


-- 
   Summary: [c++0x] reject valid? no matching function for call to
'make_pair(void*&, int&)'
   Product: gcc
   Version: 4.5.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pluto at agmk dot net
 GCC build triplet: x86_64-gnu-linux
  GCC host triplet: x86_64-gnu-linux
GCC target triplet: x86_64-gnu-linux


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

[Bug fortran/45530] gfortran internal compiler error

[burnus at gcc dot gnu dot org]

--- Comment #4 from burnus at gcc dot gnu dot org  2010-09-04 19:37 ---
Subject: Bug 45530

Author: burnus
Date: Sat Sep  4 19:36:47 2010
New Revision: 163866

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163866
Log:
2010-09-04  Tobias Burnus  

PR fortran/45530
* resolve.c (resolve_fl_namelist): Change constraint checking
order to prevent endless loop.

2010-09-04  Tobias Burnus  

PR fortran/45530
* gfortran.dg/namelist_63.f90: New.


Added:
branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/namelist_63.f90
Modified:
branches/gcc-4_5-branch/gcc/fortran/ChangeLog
branches/gcc-4_5-branch/gcc/fortran/resolve.c
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug pch/45536] PCH uses "-o file" even when there are other arguments

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2010-09-04 19:33 ---
(In reply to comment #1)
> Please provide a complete testcase, including Makefile.

The description has enough information to produce the issue.  The driver is
producing a PCH and an executable with the same output filename.


-- 


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

[Bug pch/45536] PCH uses "-o file" even when there are other arguments

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2010-09-04 19:32 ---
This has enough information to reproduce the bug.  Thanks again for the
testcase.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-09-04 19:32:11
   date||


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

[Bug pch/45536] PCH uses "-o file" even when there are other arguments

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2010-09-04 19:31 ---
The problem is the specs is producing the output file for the PCH.  


[andrew-pinskis-computer:~] apinski% file t.out
t.out: GCC precompiled header (version 013) for C


Related to PR 33980.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|c++ |pch
  GCC build triplet|elf_x86_64  |
   GCC host triplet|elf_x86_64  |
 GCC target triplet|elf_x86_64  |
Summary|gcc updates output timestamp|PCH uses "-o file" even when
   |even when compilation fails |there are other arguments


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

[Bug middle-end/45508] Does adding configure-options for specs-hardcoding make sense?

[nicolai dot stange at zmaw dot de]

--- Comment #5 from nicolai dot stange at zmaw dot de  2010-09-04 19:31 
---
(In reply to comment #4)
> The problem with the configure is the libgcc specs are very target dependent.
Yes, and that's the reason why I think that others might benefit from those
configure-options.

Another remark that I forgot in my first post: There's already an --with-specs
option that sets some specs for something (I don't know for what exactly, but
it can't be used to set link options, I already tried it: Some other tools
complain about unknown options).

If your concern is about the work, not about the additional complexicity:
I would do the work to add those options, just tell me
- For which specs I should do it (all or just link_libgcc)
- How do you want the CPP-Macros for the values of the configure-options to be
named?
- Should those values override or be appended/prepended to the
platform-specific default-specs?
  * If appended/prepended: How do you want the CPP-macro for the concatenated,
final spec string to be named?


-- 


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

[Bug fortran/45489] Default initialization of derived-type function result missing

[burnus at gcc dot gnu dot org]

--- Comment #5 from burnus at gcc dot gnu dot org  2010-09-04 19:25 ---
Subject: Bug 45489

Author: burnus
Date: Sat Sep  4 19:25:36 2010
New Revision: 163865

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163865
Log:
2010-09-04  Tobias Burnus  

PR fortran/45489
* resolve.c (apply_default_init): Mark symbol as referenced,
if it is initialized.
(resolve_symbol): Change intialized check for BT_DERIVED such
that also function results get initialized.

2010-09-04  Tobias Burnus  

PR fortran/45489
* gfortran.dg/initialization_27.f90: New.


Added:
branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/initialization_27.f90
Modified:
branches/gcc-4_5-branch/gcc/fortran/ChangeLog
branches/gcc-4_5-branch/gcc/fortran/resolve.c
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/45019] Aliasing of TARGET dummy argument not detected correctly

[burnus at gcc dot gnu dot org]

--- Comment #14 from burnus at gcc dot gnu dot org  2010-09-04 19:21 ---
FIXED. Thanks for the bugreport.


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug fortran/45019] Aliasing of TARGET dummy argument not detected correctly

[burnus at gcc dot gnu dot org]

--- Comment #13 from burnus at gcc dot gnu dot org  2010-09-04 19:21 ---
Subject: Bug 45019

Author: burnus
Date: Sat Sep  4 19:20:53 2010
New Revision: 163863

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163863
Log:
2010-09-04  Tobias Burnus  

PR fortran/45019
* dependency.c (gfc_check_dependency): Add argument alising
* check.
* symbol.c (gfc_symbols_could_alias): Add argument alising
* check.

2010-09-04  Tobias Burnus  

PR fortran/45019
* gfortran.dg/aliasing_dummy_5.f90: New.


Added:
branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/aliasing_dummy_5.f90
Modified:
branches/gcc-4_5-branch/gcc/fortran/ChangeLog
branches/gcc-4_5-branch/gcc/fortran/dependency.c
branches/gcc-4_5-branch/gcc/fortran/symbol.c
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug target/42313] FAIL: gcc.target/i386/builtin-unreachable.c scan-assembler-not %e[bs]p on i686 darwin

[howarth at nitro dot med dot uc dot edu]

--- Comment #8 from howarth at nitro dot med dot uc dot edu  2010-09-04 
19:13 ---
(In reply to comment #7)
> I fixed the test case to not expect the unimplemented optimization in r157197,
> however, it would be nice to ensure the async signal handlers can handle
> unaligned stacks and to perform this optimization.  I'm fairly certain the
> signal handers have to cope as code gen can do:
> 
> _h:
> subl$12, %esp
> movl$1, %eax
> addl$12, %esp
> ret
> 
> for int h () { return 1; } and certainly we can take a signal at _h+0, where
> esp isn't aligned.  Given that, we can omit sp alignments for leaf functions
> (and no tail calls either), even on machines where otherwise an alignment is
> required, as long as any variables on the stack are correctly aligned.
> 
> When this optimization is added, we can undo the r157197 change. 
> 

My proposed patch to fix PR36502...

http://gcc.gnu.org/ml/gcc-patches/2010-09/msg00237.html

that enables stack realignment on intel darwin also solves this PR as well.
Comparing the output from gcc trunk before and after my patch, I see...

--- builtin-unreachable.s   2010-09-04 15:12:40.0 -0400
+++ builtin-unreachable.trunk_patched   2010-09-04 15:02:45.0 -0400
@@ -3,11 +3,7 @@
.globl _h
 _h:
 LFB0:
-   subl$12, %esp
-LCFI0:
movl$1, %eax
-   addl$12, %esp
-LCFI1:
ret
 LFE0:
.section
__TEXT,__eh_frame,coalesced,no_toc+strip_static_syms+live_support
@@ -39,16 +35,6 @@
.set L$set$2,LFE0-LFB0
.long L$set$2
.byte   0
-   .byte   0x4
-   .set L$set$3,LCFI0-LFB0
-   .long L$set$3
-   .byte   0xe
-   .byte   0x10
-   .byte   0x4
-   .set L$set$4,LCFI1-LCFI0
-   .long L$set$4
-   .byte   0xe
-   .byte   0x4
.align 2
 LEFDE1:
.subsections_via_symbols


-- 


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

[Bug target/45524] r163815/r163816 produces new regressions on x86_64-apple-darwin10

[howarth at nitro dot med dot uc dot edu]

--- Comment #32 from howarth at nitro dot med dot uc dot edu  2010-09-04 
18:12 ---
I can confirm that gcc-pr45524-3.patch bootstraps and eliminates the
regressions caused by r163815/r163816 on x86_64-apple-darwin10.


-- 


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

[Bug tree-optimization/45522] VRP misses oppurtunity for statement folding.

[hubicka at gcc dot gnu dot org]

--- Comment #11 from hubicka at gcc dot gnu dot org  2010-09-04 18:00 
---
Created an attachment (id=21700)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21700&action=view)
proposed fix for sccvn

Well, this is patch I am currently testing. At least small part is shared in
between tree-ssa-ccp (probably should go into gimple-fold) and VN.
I am not sure how much of other initializer folding I need to borrow - i.e.
folding of var_decl into its decl_initial, handling of component_refs and such.

Also the tree-ssa-ccp code seems quite incomplette, it won't fold array with
incomplette initializer for example because it won't find the matching item. 
Probably worth to fix.

Honza


-- 


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

[Bug fortran/45530] gfortran internal compiler error

[burnus at gcc dot gnu dot org]

--- Comment #3 from burnus at gcc dot gnu dot org  2010-09-04 17:47 ---
Subject: Bug 45530

Author: burnus
Date: Sat Sep  4 17:47:02 2010
New Revision: 163862

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163862
Log:
2010-09-04  Tobias Burnus  

PR fortran/45530
* resolve.c (resolve_fl_namelist): Change constraint checking
order to prevent endless loop.

2010-09-04  Tobias Burnus  

PR fortran/45530
* gfortran.dg/namelist_63.f90: New.


Added:
trunk/gcc/testsuite/gfortran.dg/namelist_63.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/45536] gcc updates output timestamp even when compilation fails

[hjl dot tools at gmail dot com]

--- Comment #1 from hjl dot tools at gmail dot com  2010-09-04 17:24 ---
Please provide a complete testcase, including Makefile.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug c++/45536] New: gcc updates output timestamp even when compilation fails

[jklowden at schemamania dot org]

When provided with a spurious header filename on the command line, gcc updates
the output file's timestamp even if compilation fails.  Re-invoking make
consequently produces a message that the target is up to date.  The target may
be a shared library or executable.  

This problem was previously reported to binutils
(http://sourceware.org/bugzilla/show_bug.cgi?id=11977) and closed as invalid,
"not a binutils bug".  

Consider two files: ldtest.h (empty, not included), and ldtest.C:

$ cat ldtest.C 
int
main( int argc, char *argv[] )
{
return 0;
}

Build it, ruin the source, build it (fails), build it again (succeeds):

$ make ldtest.borked
c++ -o ldtest.borked ldtest.C ldtest.h
$ make break
 ldtest.c
mv ldtest.c ldtest.C
$ make ldtest.borked
c++ -o ldtest.borked ldtest.C ldtest.h
ldtest.C: In function ‘int main(int, char**)’:
ldtest.C:4: error: ‘r’ was not declared in this scope
ldtest.C:4: error: expected `;' before ‘eturn’
make: *** [ldtest.borked] Error 1
$ make ldtest.borked
make: `ldtest.borked' is up to date.

$ stat ldtest.C ldtest.borked | grep -E 'ldtest|Change'
  File: `ldtest.C'
Change: 2010-09-03 12:56:18.14013 -0400
  File: `ldtest.borked'
Change: 2010-09-03 12:56:24.168658000 -0400

If ldtest.h is not on the command line, the binary is not updated:

$ make fix
 ldtest.c
mv ldtest.c ldtest.C
$ make ldtest
c++ -o ldtest ldtest.C
$ make break
 ldtest.c
mv ldtest.c ldtest.C
$ make ldtest
c++ -o ldtest ldtest.C
ldtest.C: In function ‘int main(int, char**)’:
ldtest.C:4: error: ‘r’ was not declared in this scope
ldtest.C:4: error: expected `;' before ‘eturn’
make: *** [ldtest] Error 1
$ make ldtest
c++ -o ldtest ldtest.C
ldtest.C: In function ‘int main(int, char**)’:
ldtest.C:4: error: ‘r’ was not declared in this scope
ldtest.C:4: error: expected `;' before ‘eturn’
make: *** [ldtest] Error 1

$ stat ldtest.C ldtest | grep -E 'ldtest|Change'
  File: `ldtest.C'
Change: 2010-09-03 13:05:18.469643000 -0400
  File: `ldtest'
Change: 2010-09-03 13:05:15.407893000 -0400

"c++ -v" doesn't show collect2 being invoked.  The problem might be caused by
the way gcc invokes cc1plus.  I wonder about "--output-pch= ldtest", below:  

$ c++ -o ldtest ldtest.C ldtest.h -v
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-libgcj-multifile
--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.4.2-gcj-1.4.2.0/jre --with-cpu=generic
--host=x86_64-redhat-linux
Thread model: posix
gcc version 4.1.2 20080704 (Red Hat 4.1.2-44)
 /usr/libexec/gcc/x86_64-redhat-linux/4.1.2/cc1plus -quiet -v -D_GNU_SOURCE
ldtest.C -quiet -dumpbase ldtest.C -mtune=generic -auxbase ldtest -version -o
/tmp/ccI315nM.s
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../x86_64-redhat-linux/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2

/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/x86_64-redhat-linux
 /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/backward
 /usr/local/include
 /usr/lib/gcc/x86_64-redhat-linux/4.1.2/include
 /usr/include
End of search list.
GNU C++ version 4.1.2 20080704 (Red Hat 4.1.2-44) (x86_64-redhat-linux)
compiled by GNU C version 4.1.2 20080704 (Red Hat 4.1.2-44).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 2d02d8750f9b337bb19a7dd5b4e2167e
ldtest.C: In function ‘int main(int, char**)’:
ldtest.C:4: error: ‘r’ was not declared in this scope
ldtest.C:4: error: expected `;' before ‘eturn’
 /usr/libexec/gcc/x86_64-redhat-linux/4.1.2/cc1plus -quiet -v -D_GNU_SOURCE
ldtest.h -quiet -dumpbase ldtest.h -mtune=generic -auxbase ldtest -version -o
/tmp/ccI315nM.s --output-pch= ldtest
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../x86_64-redhat-linux/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2

/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/x86_64-redhat-linux
 /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/backward
 /usr/local/include
 /usr/lib/gcc/x86_64-redhat-linux/4.1.2/include
 /usr/include
End of search list.
GNU C++ version 4.1.2 20080704 (Red Hat 4.1.2-44) (x86_64-redhat-linux)
compiled by GNU C version 4.1.2 20080704 (Red Hat 4.1.2-44).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 2d02d8750f9b337bb19a7dd5b4e2167e

While one might argue GIGO, including extra filenames on the command line is an
easy mist

[Bug target/45524] r163815/r163816 produces new regressions on x86_64-apple-darwin10

[howarth at nitro dot med dot uc dot edu]

--- Comment #31 from howarth at nitro dot med dot uc dot edu  2010-09-04 
16:58 ---
(In reply to comment #30)

> I'm not sure whether the patches remove the need for the other patch in 
> comment
> #21 though.  Jack, can you post what you are exactly testing (without the
> regenerated files, which are unnecessary)?
> 

Testing H.J.'s gcc-pr45524-3.patch as it is the first in his series which
bootstraps on x86_64-apple-darwin10.


-- 


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

[Bug bootstrap/44970] [4.6 regression] Revision 162270 failed to bootstrap

[bonzini at gnu dot org]

--- Comment #79 from bonzini at gnu dot org  2010-09-04 16:49 ---
Created an attachment (id=21699)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21699&action=view)
incomplete patch

This shows what I plan to do.  It doesn't even compile stage2, so it is more or
less useless.  Still here it is.


-- 


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

[Bug bootstrap/44970] [4.6 regression] Revision 162270 failed to bootstrap

[bonzini at gnu dot org]

-- 

bonzini at gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-09-04 16:46:13
   date||


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

[Bug fortran/45530] gfortran internal compiler error

[burnus at gcc dot gnu dot org]

--- Comment #2 from burnus at gcc dot gnu dot org  2010-09-04 16:43 ---
The endless loop happens in derived_inaccessible - seemingly called by
resolve_fl_namelist (all resolve.c); that check happens before the
pointer-components check.

Moving the PRIVATE/accessible check _after_ the pointer/allocatable components
cures the issue.


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |burnus at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2010-09-04 08:14:29 |2010-09-04 16:43:21
   date||


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

[Bug target/45524] r163815/r163816 produces new regressions on x86_64-apple-darwin10

[bonzini at gnu dot org]

--- Comment #30 from bonzini at gnu dot org  2010-09-04 16:41 ---
> > It's clear that the way to go is to first write
> > small patch to smooth out the nuances you pointed out, and then
> > introduce the new macro in a way that doesn't change the semantics.
> 
> Since the differences are generally deliberate, what's actually wanted is 
> a macro that preserves them.

Sure, I meant "leaving the differences in semantics to the single configure
scripts".  This is what H.J.'s patch does more or less, and I like it.

I'm not sure whether the patches remove the need for the other patch in comment
#21 though.  Jack, can you post what you are exactly testing (without the
regenerated files, which are unnecessary)?


-- 


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

[Bug target/45070] Miscompiled c++ class with packed attribute on ARM with -Os optimizations (Qt 4.6.2)

[armin76 at gentoo dot org]

--- Comment #16 from armin76 at gentoo dot org  2010-09-04 16:41 ---
I'd like it backported to 4.4 if possible, thanks


-- 


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

[Bug target/45524] r163815/r163816 produces new regressions on x86_64-apple-darwin10

[howarth at nitro dot med dot uc dot edu]

--- Comment #29 from howarth at nitro dot med dot uc dot edu  2010-09-04 
16:32 ---
(In reply to comment #28)
> Created an attachment (id=21698)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21698&action=view) [edit]
> A new patch
> 
> Try this one.
> 

This bootstraps. Regtesting next.


-- 


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

[Bug bootstrap/45067] [4.6 regression] ARM bootstrap failure: internal compiler error: in expand_widen_pattern_expr, at optabs.c:522

[mikpe at it dot uu dot se]

--- Comment #13 from mikpe at it dot uu dot se  2010-09-04 16:19 ---
For the record, the original ICE in this PR was fixed by r162784:
http://gcc.gnu.org/ml/gcc-cvs/2010-07/msg01138.html


-- 


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

[Bug target/45524] r163815/r163816 produces new regressions on x86_64-apple-darwin10

[hjl dot tools at gmail dot com]

--- Comment #28 from hjl dot tools at gmail dot com  2010-09-04 16:07 
---
Created an attachment (id=21698)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21698&action=view)
A new patch

Try this one.


-- 


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

[Bug target/45524] r163815/r163816 produces new regressions on x86_64-apple-darwin10

[howarth at nitro dot med dot uc dot edu]

--- Comment #27 from howarth at nitro dot med dot uc dot edu  2010-09-04 
15:44 ---
Both patches fail on a x86_64-apple-darwin10 bootstrap with..

make[3]: *** No rule to make target
`../../gcc-4.6-20100904/gcc/../libdecnumber/no/decimal32.h', needed by `dfp.o'.
 Stop


-- 


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

[Bug debug/45136] -fcompare-debug failure with -Os -fschedule-insns

[aoliva at gcc dot gnu dot org]

--- Comment #8 from aoliva at gcc dot gnu dot org  2010-09-04 15:28 ---
*** Bug 45130 has been marked as a duplicate of this bug. ***


-- 


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

[Bug debug/45130] -fcompare-debug failure with -Os -fsched-spec-load -fschedule-insns

[aoliva at gcc dot gnu dot org]

--- Comment #3 from aoliva at gcc dot gnu dot org  2010-09-04 15:28 ---


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


-- 

aoliva at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE


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

[Bug debug/45419] -fcompare-debug failure at -O3

[aoliva at gcc dot gnu dot org]

--- Comment #16 from aoliva at gcc dot gnu dot org  2010-09-04 15:27 ---
*** Bug 45408 has been marked as a duplicate of this bug. ***


-- 


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

[Bug debug/45408] -fcompare-debug failure with -O2 -ftree-vectorize -fno-var-tracking-assignments

[aoliva at gcc dot gnu dot org]

--- Comment #4 from aoliva at gcc dot gnu dot org  2010-09-04 15:27 ---


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


-- 

aoliva at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug debug/45419] -fcompare-debug failure at -O3

[aoliva at gcc dot gnu dot org]

--- Comment #15 from aoliva at gcc dot gnu dot org  2010-09-04 15:26 ---
Got a patch


-- 

aoliva at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug target/45524] r163815/r163816 produces new regressions on x86_64-apple-darwin10

[hjl dot tools at gmail dot com]

--- Comment #26 from hjl dot tools at gmail dot com  2010-09-04 15:19 
---
Created an attachment (id=21697)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21697&action=view)
A regenerated patch

I really don't like autconf cache.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

  Attachment #21696|0   |1
is obsolete||


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

[Bug target/45524] r163815/r163816 produces new regressions on x86_64-apple-darwin10

[hjl dot tools at gmail dot com]

-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-09-04 15:14:04
   date||
   Target Milestone|--- |4.6.0


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

[Bug target/45524] r163815/r163816 produces new regressions on x86_64-apple-darwin10

[hjl dot tools at gmail dot com]

--- Comment #25 from hjl dot tools at gmail dot com  2010-09-04 15:13 
---
Created an attachment (id=21696)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21696&action=view)
A patch

Please try this one.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

  Attachment #21695|0   |1
is obsolete||


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

[Bug target/45524] r163815/r163816 produces new regressions on x86_64-apple-darwin10

[howarth at nitro dot med dot uc dot edu]

--- Comment #24 from howarth at nitro dot med dot uc dot edu  2010-09-04 
14:38 ---
Created an attachment (id=21695)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21695&action=view)
Move definition of ENABLE_DECIMAL_FLOAT to 1 into config/dfp.m4.


-- 


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

[Bug target/45524] r163815/r163816 produces new regressions on x86_64-apple-darwin10

[howarth at nitro dot med dot uc dot edu]

--- Comment #23 from howarth at nitro dot med dot uc dot edu  2010-09-04 
14:26 ---
The patch in comment 21 seems to work on x86_64-unknown-linux-gnu for a stock
build. Iin the libgcc build directory before and after the patch, I get...

decimal_float='yes'
enable_decimal_float='bid'


-- 


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

[Bug tree-optimization/45535] [4.6 regression] ICE during tree_ssa_dse

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2010-09-04 14:12 ---
I will have a look (seems I need to build a cross ...)


-- 

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 |2010-09-04 14:12:56
   date||
   Target Milestone|--- |4.6.0


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

[Bug tree-optimization/45522] VRP misses oppurtunity for statement folding.

[rguenther at suse dot de]

--- Comment #10 from rguenther at suse dot de  2010-09-04 14:11 ---
Subject: Re:  VRP misses oppurtunity for statement
 folding.

On Sat, 4 Sep 2010, hubicka at gcc dot gnu dot org wrote:

> --- Comment #9 from hubicka at gcc dot gnu dot org  2010-09-04 13:51 
> ---
> Hi,
> thanks.  In meantime I made tree-ssa-pre to fold statements it produces and it
> gets me to bootstrapland with sanity check in expr.c except for Ada (with the
> patches I sent so far)

Well - that's a workaround and will cause us to miss PRE because we do
not fold during translation of expressions.  So I wouldn't go down that
route.

> So it seems that I need to basically duplicate all logic for initializer
> folding from tree-ssa-ccp.c into this function, right? I guess it makes sense,
> but it is all quite ugly.

Yes ;)

> On VN side, i wondered if we can retire more of expand this way. For example
> dojump knows that:
> a = b ror x;
> if (a != 0)
> can be folded into:
> if (b != 0)
> (ror is rotation).  I guess we should do this kind of tricks in VN instead?

Well ... it's not that easy (that's not CSE but tree-combining, so
the specific thing would fit to forwprop).

Richard.


-- 


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

[Bug tree-optimization/45522] VRP misses oppurtunity for statement folding.

[hubicka at gcc dot gnu dot org]

--- Comment #9 from hubicka at gcc dot gnu dot org  2010-09-04 13:51 ---
Hi,
thanks.  In meantime I made tree-ssa-pre to fold statements it produces and it
gets me to bootstrapland with sanity check in expr.c except for Ada (with the
patches I sent so far)

So it seems that I need to basically duplicate all logic for initializer
folding from tree-ssa-ccp.c into this function, right? I guess it makes sense,
but it is all quite ugly.

On VN side, i wondered if we can retire more of expand this way. For example
dojump knows that:
a = b ror x;
if (a != 0)
can be folded into:
if (b != 0)
(ror is rotation).  I guess we should do this kind of tricks in VN instead?

Honza


-- 


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

[Bug tree-optimization/45535] [4.6 regression] ICE during tree_ssa_dse

[rearnsha at gcc dot gnu dot org]

--- Comment #2 from rearnsha at gcc dot gnu dot org  2010-09-04 13:40 
---
caused by svn+ssh://gcc.gnu.org/svn/gcc/tr...@163802


-- 

rearnsha at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug target/45524] r163815/r163816 produces new regressions on x86_64-apple-darwin10

[howarth at nitro dot med dot uc dot edu]

--- Comment #22 from howarth at nitro dot med dot uc dot edu  2010-09-04 
13:39 ---
I should note that one probe I am using to monitor how this builds is what
"grep decimal_float config.log" reports in the gcc, libdecnumber and libgcc
build directories. Pre-r163815/r163816, on darwin this was..

enable_decimal_float='dpd'

for gcc and libdecnumber but...

decimal_float='no'
enable_decimal_float='no'

in the libgcc build directory. With the patch in comment 21, this is changed
to...

decimal_float='no'
enable_decimal_float='dpd'

Note that this compares to what we got in libgcc with r163815/r163816 of...

decimal_float='yes'
enable_decimal_float='dpd'


-- 


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

[Bug bootstrap/45518] [4.6 regression] bootstrap failure on sparc64-unknown-linux-gnu

[mikpe at it dot uu dot se]

--- Comment #3 from mikpe at it dot uu dot se  2010-09-04 13:38 ---
Can you show us the complete configure options you used?  I'm trying to build
gcc-4.6 for sparc64-linux w/o --with-cpu=v8 (so it defaults to 64-bit mode) and
I can't get past an error after stage1 where it tries to configure a 32-bit
zlib but passes the wrong path to prev-gcc.


-- 

mikpe at it dot uu dot se changed:

   What|Removed |Added

 CC||mikpe at it dot uu dot se


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

[Bug target/45524] r163815/r163816 produces new regressions on x86_64-apple-darwin10

[howarth at nitro dot med dot uc dot edu]

--- Comment #21 from howarth at nitro dot med dot uc dot edu  2010-09-04 
13:08 ---
Index: gcc/configure.ac
===
--- gcc/configure.ac(revision 163853)
+++ gcc/configure.ac(working copy)
@@ -608,10 +608,6 @@
 # Enable C extension for decimal float if target supports it.
 GCC_AC_ENABLE_DECIMAL_FLOAT([$target])

-dfp=`if test $enable_decimal_float != no; then echo 1; else echo 0; fi`
-AC_DEFINE_UNQUOTED(ENABLE_DECIMAL_FLOAT, $dfp,
-[Define to 1 to enable decimal float extension to C.])
-
 bid=`if test $enable_decimal_float = bid; then echo 1; else echo 0; fi`
 AC_DEFINE_UNQUOTED(ENABLE_DECIMAL_BID_FORMAT, $bid,
 [Define to 1 to specify that we are using the BID decimal floating

Index: config/dfp.m4
===
--- config/dfp.m4   (revision 163853)
+++ config/dfp.m4   (working copy)
@@ -30,6 +30,10 @@
   esac
 ])

+ dfp=`if test $enable_decimal_float != no; then echo 1; else echo 0; fi`
+ AC_DEFINE_UNQUOTED(ENABLE_DECIMAL_FLOAT, $dfp,
+ [Define to 1 to enable decimal float extension to C.])
+
 # x86's use BID format instead of DPD
 case x$enable_decimal_float in
   xyes)
@@ -50,4 +54,4 @@
 esac
 AC_SUBST(enable_decimal_float)

-])
\ No newline at end of file
+])

which restore the original code sequencing, eliminates the decimal float
failures on x86_64-apple-darwin10. However, I don't know what this does to
linux due to the remaining differences being omitted.


-- 


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

[Bug tree-optimization/45535] [4.6 regression] ICE during tree_ssa_dse

[rearnsha at gcc dot gnu dot org]

--- Comment #1 from rearnsha at gcc dot gnu dot org  2010-09-04 12:24 
---
Created an attachment (id=21694)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21694&action=view)
testcase


-- 


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

[Bug tree-optimization/45535] New: [4.6 regression] ICE during tree_ssa_dse

[rearnsha at gcc dot gnu dot org]

The attached testcase generates a segfault during alias analysis run as part of
the DSE pass.

Command line options:

/scratch/rearnsha/gnu/gcc-eabi/git/gcc/cc1 -quiet -nostdinc -v -I
/scratch/rearnsha/gnu/gcc-eabi/git/git-vfp-eabi-O3/linux-2.4.23-pre3-testplatform/include
-I . -imultilib fpu -iprefix
/scratch/rearnsha/gnu/gcc-eabi/git/gcc/../lib/gcc/arm-eabi/4.6.0/ -isystem
/scratch/rearnsha/gnu/gcc-eabi/git/gcc/include -isystem
/scratch/rearnsha/gnu/gcc-eabi/git/gcc/include-fixed -D__USES_INITFINI__ -D
__linux__ -D __KERNEL__ -D CONFIG_ARCH_S390X -D CONFIG_ARCH_S390 -U __i386__ -U
__x86_64__ -D KBUILD_BASENAME=memory -isystem
/scratch/rearnsha/gnu/testinstall/arm-eabi/sys-include -iwithprefix include 
-quiet -dumpbase memory.c -mcpu=arm1136jf-s -marm -mfpu=vfp -mfloat-abi=hard
-auxbase-strip memory.o -O3 -w -version -fno-short-enums -fno-strict-aliasing
-fno-common -fomit-frame-pointer besttry.c

Testcase is from CSiBE.


-- 
   Summary: [4.6 regression] ICE during tree_ssa_dse
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rearnsha at gcc dot gnu dot org
GCC target triplet: arm-eabi


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

[Bug middle-end/45534] [4.6 Regression] ICE in refs_may_alias_p_1, at tree-ssa-alias.c:1031

[iains at gcc dot gnu dot org]

-- 

iains at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||iains at gcc dot gnu dot org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-09-04 12:05:15
   date||


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

[Bug middle-end/45534] [4.6 Regression] ICE in refs_may_alias_p_1, at tree-ssa-alias.c:1031

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.6.0


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

[Bug target/45524] r163815/r163816 produces new regressions on x86_64-apple-darwin10

[davek at gcc dot gnu dot org]

--- Comment #20 from davek at gcc dot gnu dot org  2010-09-04 11:57 ---
(In reply to comment #19)
> (In reply to comment #18)
> > See also http://gcc.gnu.org/ml/gcc-testresults/2010-09/msg00342.html for a
> > non-darwin platform.
> > 
> 
>   Yep, it's all the same kind of undefined symbol problems as in Jack's
> original description of the bug.  

Note however that it's before the revision where this patch was applied, and
wouldn't have shown up without my explictly adding the --enable option.


-- 


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

[Bug target/45524] r163815/r163816 produces new regressions on x86_64-apple-darwin10

[davek at gcc dot gnu dot org]

--- Comment #19 from davek at gcc dot gnu dot org  2010-09-04 11:54 ---
(In reply to comment #18)
> See also http://gcc.gnu.org/ml/gcc-testresults/2010-09/msg00342.html for a
> non-darwin platform.
> 

  Yep, it's all the same kind of undefined symbol problems as in Jack's
original description of the bug.  I configured using plain
--enable-decimal-float, I imagine that explicitly specifying
--enable-decimal-float=bid would help.  (Shall give it a try.)


-- 


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

[Bug middle-end/45534] New: [4.6 Regression] ICE in refs_may_alias_p_1, at tree-ssa-alias.c:1031

[dominiq at lps dot ens dot fr]

>From revisions 163847 (163744 works) to 163859, I see the following ICEs

with both -m32 and -m64

libgomp.graphite/force-parallel-3.c:5:6: internal compiler error: in
refs_may_alias_p_1, at tree-ssa-alias.c:1031
libgomp.graphite/force-parallel-9.c:5:6: internal compiler error: in
refs_may_alias_p_1, at tree-ssa-alias.c:1031

with -m64 -Os

gfortran.dg/backspace_1.f:82:0: internal compiler error: in refs_may_alias_p_1,
at tree-ssa-alias.c:1031
gfortran.dg/record_marker_2.f:83:0: internal compiler error: in
refs_may_alias_p_1, at tree-ssa-alias.c:1031
libgomp.fortran/appendix-a/a.16.1.f90:26:0: internal compiler error: in
refs_may_alias_p_1, at tree-ssa-alias.c:1031
libgomp.fortran/omp_atomic2.f90:35:0: internal compiler error: in
refs_may_alias_p_1, at tree-ssa-alias.c:1031

and with -m64 -O2 -fgraphite-identity

gfortran.dg/graphite/pr42393-1.f90:6:0: internal compiler error: in
refs_may_alias_p_1, at tree-ssa-alias.c:1031


-- 
   Summary: [4.6 Regression] ICE in refs_may_alias_p_1, at tree-ssa-
alias.c:1031
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
 GCC build triplet: x86_64-apple-darwin10
  GCC host triplet: x86_64-apple-darwin10
GCC target triplet: x86_64-apple-darwin10


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

[Bug target/45524] r163815/r163816 produces new regressions on x86_64-apple-darwin10

[dominiq at lps dot ens dot fr]

--- Comment #18 from dominiq at lps dot ens dot fr  2010-09-04 11:51 ---
See also http://gcc.gnu.org/ml/gcc-testresults/2010-09/msg00342.html for a
non-darwin platform.


-- 


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

[Bug c/37985] [4.3/4.4/4.5/4.6 Regression] unsigned char shift lacks "statement with no effect" warning

[simartin at gcc dot gnu dot org]

--- Comment #8 from simartin at gcc dot gnu dot org  2010-09-04 11:34 
---
This is due to
  http://gcc.gnu.org/ml/gcc-patches/2006-08/msg01041.html


-- 

simartin at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||simartin at gcc dot gnu dot
   ||org
   Last reconfirmed|2008-12-24 05:11:57 |2010-09-04 11:34:54
   date||


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

[Bug target/45524] r163815/r163816 produces new regressions on x86_64-apple-darwin10

[joseph at codesourcery dot com]

--- Comment #17 from joseph at codesourcery dot com  2010-09-04 11:05 
---
Subject: Re:  r163815/r163816 produces new regressions on
 x86_64-apple-darwin10

On Sat, 4 Sep 2010, bonzini at gnu dot org wrote:

> Please revert the patch in both gcc and src.  It's clear that the way to go is
> to first write small patch to smooth out the nuances you pointed out, and then
> introduce the new macro in a way that doesn't change the semantics.  Sorry for
> the spotty review. :/

Since the differences are generally deliberate, what's actually wanted is 
a macro that preserves them.  The basic information of which targets 
support DFP by default / at all and what the default format is on each 
target should be in a single place.  The information about whether $target 
or $host is relevant, and about what the configuration variables should be 
set to if DFP is disabled, should be passed as arguments to the macro.


-- 


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

[Bug bootstrap/45519] [4.6 regression] Failed to bootstrap

[rguenth at gcc dot gnu dot org]

--- Comment #14 from rguenth at gcc dot gnu dot org  2010-09-04 10:21 
---
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=45519

[Bug bootstrap/45519] [4.6 regression] Failed to bootstrap

[rguenth at gcc dot gnu dot org]

--- Comment #13 from rguenth at gcc dot gnu dot org  2010-09-04 10:21 
---
Subject: Bug 45519

Author: rguenth
Date: Sat Sep  4 10:21:07 2010
New Revision: 163858

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163858
Log:
2010-09-04  Richard Guenther  

PR bootstrap/45519
* tree-flow.h (force_gimple_operand_1): Declare.
(force_gimple_operand_gsi_1): Likewise.
* gimplify.c (force_gimple_operand_1): New worker taking a
gimple predicate for ...
(force_gimple_operand): ... which now wraps it.
(force_gimple_operand_gsi_1, force_gimple_operand_gsi): Likewise.
* tree-ssa-loop-ivopts.c (find_interesting_uses_address): Revert
last change.
* tree-ssa-address.c (gimplify_mem_ref_parts): Use
force_gimple_operand_gsi_1 with is_gimple_mem_ref_addr.
(create_mem_ref): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimplify.c
trunk/gcc/tree-flow.h
trunk/gcc/tree-ssa-address.c
trunk/gcc/tree-ssa-loop-ivopts.c


-- 


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

[Bug target/45524] r163815/r163816 produces new regressions on x86_64-apple-darwin10

[dominiq at lps dot ens dot fr]

--- Comment #16 from dominiq at lps dot ens dot fr  2010-09-04 10:16 ---
Could someone check that revisions 163815 and 163816 are not exposing a more
serious latent bug: I have configured gcc with --enable-decimal-float=no and
--disable-decimal-float without disabling -decimal-float. 

Are these options working on linux?


-- 


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

[Bug rtl-optimization/45223] RTL PRE GCSE pass hoists trapping insn out of loop

[ubizjak at gmail dot com]

--- Comment #7 from ubizjak at gmail dot com  2010-09-04 10:03 ---
Unassigning...


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 AssignedTo|ubizjak at gmail dot com|unassigned at gcc dot gnu
   ||dot org
 Status|ASSIGNED|NEW


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

[Bug bootstrap/45519] [4.6 regression] Failed to bootstrap

[rguenth at gcc dot gnu dot org]

--- Comment #12 from rguenth at gcc dot gnu dot org  2010-09-04 09:34 
---
Created an attachment (id=21693)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21693&action=view)
patch w/o typos...


-- 


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

[Bug fortran/45507] [4.6 Regression] Bogus Error: Can't convert TYPE(c_ptr) to INTEGER(4)

[janus at gcc dot gnu dot org]

--- Comment #6 from janus at gcc dot gnu dot org  2010-09-04 09:31 ---
Fixed with r163856. Closing.


-- 

janus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug fortran/45507] [4.6 Regression] Bogus Error: Can't convert TYPE(c_ptr) to INTEGER(4)

[janus at gcc dot gnu dot org]

--- Comment #5 from janus at gcc dot gnu dot org  2010-09-04 09:29 ---
Subject: Bug 45507

Author: janus
Date: Sat Sep  4 09:29:11 2010
New Revision: 163856

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163856
Log:
2010-09-04  Janus Weil  

PR fortran/45507
* resolve.c (resolve_allocate_expr): Generate default initializers
already at this point, resolve them and put them into expr3, ...
* trans-stmt.c (gfc_trans_allocate): ... instead of waiting until
translation stage.


2010-09-04  Janus Weil  

PR fortran/45507
* gfortran.dg/allocate_alloc_opt_12.f90: New.

Added:
trunk/gcc/testsuite/gfortran.dg/allocate_alloc_opt_12.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/fortran/trans-stmt.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug target/45524] r163815/r163816 produces new regressions on x86_64-apple-darwin10

[bonzini at gnu dot org]

--- Comment #15 from bonzini at gnu dot org  2010-09-04 09:08 ---
Please revert the patch in both gcc and src.  It's clear that the way to go is
to first write small patch to smooth out the nuances you pointed out, and then
introduce the new macro in a way that doesn't change the semantics.  Sorry for
the spotty review. :/


-- 


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

[Bug tree-optimization/45522] VRP misses oppurtunity for statement folding.

[rguenther at suse dot de]

--- Comment #8 from rguenther at suse dot de  2010-09-04 08:29 ---
Subject: Re:  VRP misses oppurtunity for statement
 folding.

On Fri, 3 Sep 2010, hubicka at gcc dot gnu dot org wrote:

> --- Comment #7 from hubicka at gcc dot gnu dot org  2010-09-03 20:28 
> ---
> In #5 the expression is created by PRE via create_expression_by_pieces that
> uses normal fold that is not able of constant variable folding. The statement
> does not get folded later and survives.  I guess one can fold all statements 
> in
> commit_edge_insertions but it seems by symptomatic?

You need to enhance fully_constant_vn_reference_p.

Richard.


-- 


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

[Bug fortran/45530] gfortran internal compiler error

[burnus at gcc dot gnu dot org]

--- Comment #1 from burnus at gcc dot gnu dot org  2010-09-04 08:14 ---
CONFIRM.

NAG prints:
Error: nm2.f90, line 22: Namelist-group-object CURVE has a POINTER component


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||ice-on-invalid-code
   Last reconfirmed|-00-00 00:00:00 |2010-09-04 08:14:29
   date||


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

[Bug bootstrap/45519] [4.6 regression] Failed to bootstrap

[jakub at gcc dot gnu dot org]

--- Comment #11 from jakub at gcc dot gnu dot org  2010-09-04 08:01 ---
*** Bug 45533 has been marked as a duplicate of this bug. ***


-- 

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

[Bug tree-optimization/45533] Incorrect MEM_REF operand causes ICE.

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2010-09-04 08:01 ---


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


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE
Summary| Incorrect MEM_REF operand  |Incorrect MEM_REF operand
   |causes ICE. |causes ICE.


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

[Bug tree-optimization/45533] Incorrect MEM_REF operand causes ICE.

[ramana at gcc dot gnu dot org]

--- Comment #1 from ramana at gcc dot gnu dot org  2010-09-04 07:53 ---
Created an attachment (id=21692)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21692&action=view)
Reduced testcase for ICE


-- 


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

[Bug tree-optimization/45533] New: Incorrect MEM_REF operand causes ICE.

[ramana at gcc dot gnu dot org]

/home/ramana/cross-build/arm-none-linux-gnueabi/obj/gcc2/gcc/cc1 -O2
~/testcase.i

Arch. specific configuration of GCC :--with-cpu=cortex-a9 --with-fpu=neon
--with-float=softfp 

./testcase.i: In function ‘elf_machine_load_address’:
./testcase.i:5254:38: warning: taking address of expression of type ‘void’
[enabled by default]
./testcase.i: In function ‘_dl_relocate_object’:
./testcase.i:5432:1: error: Invalid first operand of MEM_REF.
prephitmp.252_36
./testcase.i:5432:1: note: in statement
D.14709_176 = &MEM[(const struct Elf32_Rel *)prephitmp.252_36 + 8B];

./testcase.i:5432:1: error: Invalid first operand of MEM_REF.
prephitmp.252_36
./testcase.i:5432:1: note: in statement
D.14712_1273 = &MEM[(const struct Elf32_Rel *)prephitmp.252_36 + 8B];

./testcase.i:5432:1: internal compiler error: verify_stmts failed
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


>From a gdb session the pass that seems to have this problem with verification
is ivopts. 

r163801 - works fine
r163802 - starts ICE'ing.


-- 
   Summary:  Incorrect MEM_REF operand causes ICE.
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ramana at gcc dot gnu dot org
  GCC host triplet: x86_64-linux
GCC target triplet: arm-none-linux-gnueabi


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

[Bug fortran/45532] gfortran namelist read error

[burnus at gcc dot gnu dot org]

--- Comment #1 from burnus at gcc dot gnu dot org  2010-09-04 07:35 ---
CONFIRM. The program works with NAG, g95, ifort and prints "1".


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||wrong-code
   Last reconfirmed|-00-00 00:00:00 |2010-09-04 07:35:23
   date||


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