[Bug rtl-optimization/44691] [4.6 Regression] ICE: RTL check: expected code 'reg', have 'plus' in rhs_regno, at rtl.h:1050

[abel at gcc dot gnu dot org]

--- Comment #6 from abel at gcc dot gnu dot org  2010-08-20 08:07 ---
Subject: Bug 44691

Author: abel
Date: Fri Aug 20 08:07:17 2010
New Revision: 163396

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163396
Log:
PR rtl-optimization/44691
* gfortran.dg/pr44691.f: New test.


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


-- 


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

[Bug fortran/45344] [4.5 Regression] Many Fortran test failures

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2010-08-20 08:41 ---
Subject: Bug 45344

Author: jakub
Date: Fri Aug 20 08:41:00 2010
New Revision: 163397

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163397
Log:
PR fortran/45344
Backport from mainline
2010-05-14  Jakub Jelinek  

* trans.c (trans_code): Set backend locus early.
* trans-decl.c (gfc_get_fake_result_decl): Use source location
of the function instead of current input_location.

* gfortran.dg/gomp/pr44036-1.f90: Adjust.

Modified:
branches/gcc-4_5-branch/gcc/fortran/ChangeLog
branches/gcc-4_5-branch/gcc/fortran/trans-decl.c
branches/gcc-4_5-branch/gcc/fortran/trans.c
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog
branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/gomp/pr44036-1.f90


-- 


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

[Bug fortran/45344] [4.5 Regression] Many Fortran test failures

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2010-08-20 08:43 ---
Fixed.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug fortran/36158] Transformational function BESSEL_YN(n1,n2,x) and BESSEL_JN missing

[burnus at gcc dot gnu dot org]

--- Comment #7 from burnus at gcc dot gnu dot org  2010-08-20 08:43 ---
Comparison of the recurrence version with calling the library every time
(for the run-time library, I expect a similar result for MPFR/compile time
version):
http://gcc.gnu.org/ml/fortran/2010-08/msg00252.html


-- 


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

[Bug fortran/45337] gfortran accepts pointer initialization of DT dummy arguments w/ INTENT(OUT)

[burnus at gcc dot gnu dot org]

--- Comment #9 from burnus at gcc dot gnu dot org  2010-08-20 08:45 ---
(In reply to comment #8)
> Error: Dummy 'x' at (1) cannot have an initializer
> 
> I think this is easy to understand, an additional short message about why it
> can't have an initializer will be better.

Do you have a suggestion?


-- 


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

[Bug bootstrap/45350] [4.6 Regression] Failed to bootstrap on Linux/ia64

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2010-08-20 08:55 ---
Fixed.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu dot org
 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug fortran/45337] gfortran accepts pointer initialization of DT dummy arguments w/ INTENT(OUT)

[jv244 at cam dot ac dot uk]

--- Comment #10 from jv244 at cam dot ac dot uk  2010-08-20 08:57 ---
(In reply to comment #9)
> (In reply to comment #8)
> > Error: Dummy 'x' at (1) cannot have an initializer
>
> Do you have a suggestion?
>
Error: Dummy argument 'x' at (1) cannot have the save attribute which is
implied by initialization.

?? 


-- 


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

[Bug middle-end/45307] Stores expanding to no RTL not removed by tree optimizers, Empty ctors/dtors not eliminated

[hubicka at gcc dot gnu dot org]

--- Comment #14 from hubicka at gcc dot gnu dot org  2010-08-20 10:23 
---
http://gcc.gnu.org/ml/gcc-patches/2010-08/msg01544.html
has patch for empty constructor removal in middle end.


-- 


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

[Bug rtl-optimization/45352] New: ICE: in reset_sched_cycles_in_current_ebb, at sel-sched.c:7058

[zsojka at seznam dot cz]

Command line:
$ gcc -O1 -frerun-cse-after-loop -ftree-vectorize -fschedule-insns
-fschedule-insns2 -fselective-scheduling2 -fsel-sched-pipelining -funroll-loops
-fprefetch-loop-arrays testcase.c
or
$ gcc -O3 -fschedule-insns -fschedule-insns2 -fselective-scheduling2
-fsel-sched-pipelining -funroll-loops -fprefetch-loop-arrays testcase.c

I came to this problem in several testcases, but the set of options could never
be reduced more.

Compiler output:
$ gcc -O1 -frerun-cse-after-loop -ftree-vectorize -fschedule-insns
-fschedule-insns2 -fselective-scheduling2 -fsel-sched-pipelining -funroll-loops
-fprefetch-loop-arrays testcase.c
testcase.c: In function 'main1':
testcase.c:10:1: internal compiler error: in reset_sched_cycles_in_current_ebb,
at sel-sched.c:7058
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Tested revisions:
r163371 - crash


-- 
   Summary: ICE: in reset_sched_cycles_in_current_ebb, at sel-
sched.c:7058
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zsojka at seznam dot cz
  GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64-pc-linux-gnu


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

[Bug rtl-optimization/45352] ICE: in reset_sched_cycles_in_current_ebb, at sel-sched.c:7058

[zsojka at seznam dot cz]

--- Comment #1 from zsojka at seznam dot cz  2010-08-20 11:15 ---
Created an attachment (id=21528)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21528&action=view)
reduced testcase (from gcc.dg/vect/no-vfa-vect-43.c)

The first loop is not needed to reproduce the problem, it just makes values
initialized.


-- 


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

[Bug rtl-optimization/45353] New: ICE: RTL check: expected elt 3 type 'B', have '0' (rtx barrier) in sel_bb_head, at sel-sched-ir.c:4329 with -fselective-scheduling and __builtin_unreachable()

[zsojka at seznam dot cz]

Command line:
$ gcc -O -fschedule-insns -fselective-scheduling testcase.c

Compiler output:
$ gcc -O -fschedule-insns -fselective-scheduling testcase.ctestcase.c: In
function 'foo':
testcase.c:4:1: internal compiler error: RTL check: expected elt 3 type 'B',
have '0' (rtx barrier) in sel_bb_head, at sel-sched-ir.c:4329
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

- testcase.c 
void foo ()
{
  __builtin_unreachable ();
}
-
Current testcases from testsuite, such as gcc.dg/builtin-unreachable-3.c, ICE
as well with given flags.

Tested revisions:
r163371 - crash


-- 
   Summary: ICE: RTL check: expected elt 3 type 'B', have '0' (rtx
barrier) in sel_bb_head, at sel-sched-ir.c:4329 with -
fselective-scheduling and __builtin_unreachable()
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zsojka at seznam dot cz
  GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64-pc-linux-gnu


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

[Bug c/43553] libgcc built with -DHAVE_CC_TLS against xgcc when emutls in use

[howarth at nitro dot med dot uc dot edu]

--- Comment #34 from howarth at nitro dot med dot uc dot edu  2010-08-20 
11:39 ---
No breakage in current bootstrap.


-- 

howarth at nitro dot med dot uc dot edu changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug middle-end/43359] gas_dyn benchmark exhibits missed vectorization with graphite

[howarth at nitro dot med dot uc dot edu]

--- Comment #5 from howarth at nitro dot med dot uc dot edu  2010-08-20 
11:45 ---
Fixed at graphite branch merge r163105 through r163174.


-- 

howarth at nitro dot med dot uc dot edu changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug tree-optimization/45354] New: ICE: verify_flow_info failed: fallthru edge crosses section boundary (bb 6) with gcc.dg/tree-prof/update-cunroll-2.c

[zsojka at seznam dot cz]

Command line:
$ gcc -O -fschedule-insns -fselective-scheduling -freorder-blocks-and-partition
-fprofile-generate gcc.dg/tree-prof/update-cunroll-2.c
$ rm *.gcda
$ ./a.out
$ gcc -O -fschedule-insns -fselective-scheduling -freorder-blocks-and-partition
-fprofile-use gcc.dg/tree-prof/update-cunroll-2.c
gcc.dg/tree-prof/update-cunroll-2.c: In function 't':
gcc.dg/tree-prof/update-cunroll-2.c:12:1: error: fallthru edge crosses section
boundary (bb 6)
gcc.dg/tree-prof/update-cunroll-2.c:12:1: internal compiler error:
verify_flow_info failed
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

I wasn't able to further reduce the testcase.

Tested revisions:
r163371 - crash


-- 
   Summary: ICE: verify_flow_info failed: fallthru edge crosses
section boundary (bb 6) with gcc.dg/tree-prof/update-
cunroll-2.c
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zsojka at seznam dot cz
  GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64-pc-linux-gnu


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

[Bug debug/45171] Invalid DWARF...DIE 0x00006a1d has multiple AT_byte_size attributes.

[howarth at nitro dot med dot uc dot edu]

--- Comment #14 from howarth at nitro dot med dot uc dot edu  2010-08-20 
12:02 ---
Fixed with r162882.


-- 

howarth at nitro dot med dot uc dot edu changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||FIXED


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

[Bug debug/42487] FAIL: gcc.dg/debug/dwarf2/aranges-fnsec-1.c scan-assembler DW_AT_ranges

[howarth at nitro dot med dot uc dot edu]

--- Comment #8 from howarth at nitro dot med dot uc dot edu  2010-08-20 
12:04 ---
Fixed with r163326.


-- 

howarth at nitro dot med dot uc dot edu changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug rtl-optimization/45353] ICE: RTL check: expected elt 3 type 'B', have '0' (rtx barrier) in sel_bb_head, at sel-sched-ir.c:4329 with -fselective-scheduling and __builtin_unreachable()

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2010-08-20 12:21 ---
Created an attachment (id=21529)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21529&action=view)
gcc46-pr45353.patch

Untested fix.


-- 

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

[Bug tree-optimization/44997] [4.6 regression] tree-chrec introduces broken asm code

[jakub at gcc dot gnu dot org]

--- Comment #9 from jakub at gcc dot gnu dot org  2010-08-20 12:38 ---
Invalid.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug middle-end/45355] New: [4.6 regression] FAIL: gcc.c-torture/compile/pr43164.c

[hjl dot tools at gmail dot com]

On Linux/ia64, revision 163389 gave

FAIL: gcc.c-torture/compile/pr43164.c  -O2  (internal compiler error)
FAIL: gcc.c-torture/compile/pr43164.c  -O2  (test for excess errors)
FAIL: gcc.c-torture/compile/pr43164.c  -O2 -flto  (internal compiler error)
FAIL: gcc.c-torture/compile/pr43164.c  -O2 -flto  (test for excess errors)
FAIL: gcc.c-torture/compile/pr43164.c  -O2 -fwhopr  (internal compiler error)
FAIL: gcc.c-torture/compile/pr43164.c  -O2 -fwhopr  (test for excess errors)
FAIL: gcc.c-torture/compile/pr43164.c  -O3 -fomit-frame-pointer  (internal
compiler error)
FAIL: gcc.c-torture/compile/pr43164.c  -O3 -fomit-frame-pointer  (test for
excess errors)
FAIL: gcc.c-torture/compile/pr43164.c  -O3 -g  (internal compiler error)
FAIL: gcc.c-torture/compile/pr43164.c  -O3 -g  (test for excess errors)
FAIL: gcc.c-torture/compile/pr43164.c  -Os  (internal compiler error)
FAIL: gcc.c-torture/compile/pr43164.c  -Os  (test for excess errors)

Revision 163371 is OK.


-- 
   Summary: [4.6 regression] FAIL: gcc.c-torture/compile/pr43164.c
   Product: gcc
   Version: 4.5.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
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=45355

[Bug middle-end/45355] [4.6 regression] FAIL: gcc.c-torture/compile/pr43164.c

[hjl dot tools at gmail dot com]

--- Comment #1 from hjl dot tools at gmail dot com  2010-08-20 13:52 ---
We are running out of stack in recursive call:

Program received signal SIGSEGV, Segmentation fault.
0x41bf3c90 in if_then_else_cond (x=0x23ef08d0, 
ptrue=0x6ef88070, pfalse=0x6ef88080)
at ../../src-trunk/gcc/combine.c:8437
8437  enum machine_mode mode = GET_MODE (x);
(gdb) bt
#0  0x41bf3c90 in if_then_else_cond (x=0x23ef08d0, 
ptrue=0x6ef88070, pfalse=0x6ef88080)
at ../../src-trunk/gcc/combine.c:8437
#1  0x41bf4190 in if_then_else_cond (x=0x23ef0900, 
ptrue=0x6ef88100, pfalse=0x6ef88110)
at ../../src-trunk/gcc/combine.c:8472
#2  0x41bf4190 in if_then_else_cond (x=0x23ef08d0, 
ptrue=0x6ef88190, pfalse=0x6ef881a0)
at ../../src-trunk/gcc/combine.c:8472
#3  0x41bf4190 in if_then_else_cond (x=0x23ef0900, 
ptrue=0x6ef88220, pfalse=0x6ef88230)
at ../../src-trunk/gcc/combine.c:8472
#4  0x41bf4190 in if_then_else_cond (x=0x23ef08d0, 
ptrue=0x6ef882b0, pfalse=0x6ef882c0)
at ../../src-trunk/gcc/combine.c:8472
#5  0x41bf4190 in if_then_else_cond (x=0x23ef0900, 
ptrue=0x6ef88340, pfalse=0x6ef88350)
at ../../src-trunk/gcc/combine.c:8472
#6  0x41bf4190 in if_then_else_cond (x=0x23ef08d0, 
ptrue=0x6ef883d0, pfalse=0x6ef883e0)
at ../../src-trunk/gcc/combine.c:8472
#7  0x41bf4190 in if_then_else_cond (x=0x23ef0900, 
ptrue=0x6ef88460, pfalse=0x6ef88470)
---Type  to continue, or q  to quit---
at ../../src-trunk/gcc/combine.c:8472
#8  0x41bf4190 in if_then_else_cond (x=0x23ef08d0, 
ptrue=0x6ef884f0, pfalse=0x6ef88500)
at ../../src-trunk/gcc/combine.c:8472
#9  0x41bf4190 in if_then_else_cond (x=0x23ef0900, 
ptrue=0x6ef88580, pfalse=0x6ef88590)
at ../../src-trunk/gcc/combine.c:8472
#10 0x41bf4190 in if_then_else_cond (x=0x23ef08d0, 
ptrue=0x6ef88610, pfalse=0x6ef88620)
at ../../src-trunk/gcc/combine.c:8472
#11 0x41bf4190 in if_then_else_cond (x=0x23ef0900, 
ptrue=0x6ef886a0, pfalse=0x6ef886b0)
at ../../src-trunk/gcc/combine.c:8472
#12 0x41bf4190 in if_then_else_cond (x=0x23ef08d0, 
ptrue=0x6ef88730, pfalse=0x6ef88740)
at ../../src-trunk/gcc/combine.c:8472
#13 0x41bf4190 in if_then_else_cond (x=0x23ef0900, 
ptrue=0x6ef887c0, pfalse=0x6ef887d0)
at ../../src-trunk/gcc/combine.c:8472
#14 0x41bf4190 in if_then_else_cond (x=0x23ef08d0, 
ptrue=0x6ef88850, pfalse=0x6ef88860)
at ../../src-trunk/gcc/combine.c:8472
#15 0x41bf4190 in if_then_else_cond (x=0x23ef0900, 
---Type  to continue, or q  to quit---
ptrue=0x6ef888e0, pfalse=0x6ef888f0)
at ../../src-trunk/gcc/combine.c:8472
#16 0x41bf4190 in if_then_else_cond (x=0x23ef08d0, 
ptrue=0x6ef88970, pfalse=0x6ef88980)
at ../../src-trunk/gcc/combine.c:8472
#17 0x41bf4190 in if_then_else_cond (x=0x23ef0900, 
ptrue=0x6ef88a00, pfalse=0x6ef88a10)
at ../../src-trunk/gcc/combine.c:8472
#18 0x41bf4190 in if_then_else_cond (x=0x23ef08d0, 
ptrue=0x6ef88a90, pfalse=0x6ef88aa0)
at ../../src-trunk/gcc/combine.c:8472
#19 0x41bf4190 in if_then_else_cond (x=0x23ef0900, 
ptrue=0x6ef88b20, pfalse=0x6ef88b30)
at ../../src-trunk/gcc/combine.c:8472
#20 0x41bf4190 in if_then_else_cond (x=0x23ef08d0, 
ptrue=0x6ef88bb0, pfalse=0x6ef88bc0)
at ../../src-trunk/gcc/combine.c:8472
#21 0x41bf4190 in if_then_else_cond (x=0x23ef0900, 
ptrue=0x6ef88c40, pfalse=0x6ef88c50)
at ../../src-trunk/gcc/combine.c:8472
#22 0x41bf4190 in if_then_else_cond (x=0x23ef08d0, 
ptrue=0x6ef88cd0, pfalse=0x6ef88ce0)
at ../../src-trunk/gcc/combine.c:8472
---Type  to continue, or q  to quit---
#23 0x41bf4190 in if_then_else_cond (x=0x23ef0900, 
ptrue=0x6ef88d60, pfalse=0x6ef88d70)
at ../../src-trunk/gcc/combine.c:8472
#24 0x41bf4190 in if_then_else_cond (x=0x23ef08d0, 
ptrue=0x6ef88df0, pfalse=0x6ef88e00)
at ../../src-trunk/gcc/combine.c:8472
#25 0x41bf4190 in if_then_else_cond (x=0x23ef0900, 
ptrue=0x6ef88e80, pfalse=0x6ef88e90)
at ../../src-trunk/gcc/combine.c:8472
#26 0x41bf4190 in if_then_else_cond (x=0x23ef08d0, 
ptrue=0x6ef88f10, pfalse=0x6ef88f20)
at ../

[Bug middle-end/45356] New: ICE: in main, at gcc.c:7175 with -fcompare-debug -save-temps and unusable PCH file

[zsojka at seznam dot cz]

Commands needed:
echo "" > empty.h
gcc empty.h -o testcase.h.gch
echo '#include "testcase.h"' > testcase.c
gcc -fcompare-debug -save-temps testcase.c

Output:
testcase.c:1:22: error: one or more PCH files were found, but they were invalid
testcase.c:1:22: error: use -Winvalid-pch for more information
testcase.c:1:22: fatal error: testcase.h: No such file or directory
compilation terminated.
gcc: error: during -fcompare-debug recompilation
gcc: internal compiler error: in main, at gcc.c:7175
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Tested revisions:
r163371 - crash


-- 
   Summary: ICE: in main, at gcc.c:7175 with -fcompare-debug -save-
temps and unusable PCH file
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zsojka at seznam dot cz


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

[Bug bootstrap/45357] New: [4.6 regression] Revision 163403 Failed to bootstrap

[hjl dot tools at gmail dot com]

On Linux/x86, revision 163403:

http://gcc.gnu.org/ml/gcc-cvs/2010-08/msg00616.html

gave:

../../src-trunk/gcc/lto/lto.c: In function 'lto_materialize_function':
../../src-trunk/gcc/lto/lto.c:161:3: error: implicit declaration of function
'has_analyzed_clone' [-Werror=implicit-function-declaration]
../../src-trunk/gcc/lto/lto.c: At top level:
../../src-trunk/gcc/lto/lto.c:124:1: error: 'has_analyzed_clone_p' defined but
not used [-Werror=unused-function]
cc1: all warnings being treated as errors


-- 
   Summary: [4.6 regression] Revision 163403 Failed to bootstrap
   Product: gcc
   Version: 4.5.3
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=45357

[Bug bootstrap/45357] [4.6 regression] Revision 163403 Failed to bootstrap

[hjl at gcc dot gnu dot org]

--- Comment #1 from hjl at gcc dot gnu dot org  2010-08-20 14:42 ---
Subject: Bug 45357

Author: hjl
Date: Fri Aug 20 14:42:28 2010
New Revision: 163405

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163405
Log:
Replace has_analyzed_clone with has_analyzed_clone_p.

2010-08-20  H.J. Lu  

PR bootstrap/45357
* lto.c (lto_materialize_function): Replace has_analyzed_clone
with has_analyzed_clone_p.

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


-- 


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

[Bug c/45358] New: =+ oddness

[christian at leber dot de]

Hello,

there is a minor issue when =+ is used by accident instead of +=.

It is unfortunate there there is not even a warning, because this is a typo
that can cost lots and lots of time.
Furthermore it seems that =+ is was the old syntax in the old pre ANSI C.

=+ behaves like =
(mathematically it is of course the same, but the behavior is still wrong,
but there is also never a reason to write =+ instead of =)

#include 
int main(void) {
int a=1,b=1;

a += 2;
b =+ 2;
printf("a=%d b=%d\n",a,b);
return 0;
}

(no warning, not even with -Wall)
a=3 b=2

It would be nice if future version could at least throw a warning.

Regards
Christian Leber


-- 
   Summary: =+ oddness
   Product: gcc
   Version: 4.4.3
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: christian at leber dot de
 GCC build triplet: x86_64-linux-gnu
  GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu


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

[Bug middle-end/44974] [4.6 Regression] Function with attribute noreturn omits a call to another function with noreturn

[jakub at gcc dot gnu dot org]

--- Comment #5 from jakub at gcc dot gnu dot org  2010-08-20 15:13 ---
Created an attachment (id=21530)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21530&action=view)
gcc46-pr44974.patch

Untested fix.


-- 

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

[Bug c/45358] =+ oddness

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2010-08-20 15:23 ---
=+ in x =+ y; isn't one token, but two, it is the same as if you write
x = + y ;
And, unary + is standard C unary operator:
The result of the unary + operator is the value of its (promoted) operand. The
integer promotions are performed on the operand, and the result has the
promoted type.

So, I don't think there is anything that should be warned about, it is normal
valid C.


-- 


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

[Bug fortran/45305] Array-valued calles to elementals are not simplified

[dominiq at lps dot ens dot fr]

--- Comment #3 from dominiq at lps dot ens dot fr  2010-08-20 15:24 ---
With the patch in comment #2, some error messages are repeated several times:
for instance gcc/testsuite/gfortran.dg/arithmetic_overflow_1.f90 gives

/opt/gcc/work/gcc/testsuite/gfortran.dg/arithmetic_overflow_1.f90:8.26:

   integer(1) :: a(2) = (/ Z'FF', Z'FF' /) ! { dg-error "Arithmetic overflow" }
  1
Error: Arithmetic overflow converting INTEGER(16) to INTEGER(1) at (1). This
check can be disabled with the option -fno-range-check
/opt/gcc/work/gcc/testsuite/gfortran.dg/arithmetic_overflow_1.f90:8.26:

   integer(1) :: a(2) = (/ Z'FF', Z'FF' /) ! { dg-error "Arithmetic overflow" }
  1
Error: Arithmetic overflow converting INTEGER(16) to INTEGER(1) at (1). This
check can be disabled with the option -fno-range-check
/opt/gcc/work/gcc/testsuite/gfortran.dg/arithmetic_overflow_1.f90:8.33:

   integer(1) :: a(2) = (/ Z'FF', Z'FF' /) ! { dg-error "Arithmetic overflow" }
 1
Error: Arithmetic overflow converting INTEGER(16) to INTEGER(1) at (1). This
check can be disabled with the option -fno-range-check
/opt/gcc/work/gcc/testsuite/gfortran.dg/arithmetic_overflow_1.f90:8.26:

   integer(1) :: a(2) = (/ Z'FF', Z'FF' /) ! { dg-error "Arithmetic overflow" }
  1
Error: Arithmetic overflow converting INTEGER(16) to INTEGER(1) at (1). This
check can be disabled with the option -fno-range-check

instead of

/opt/gcc/work/gcc/testsuite/gfortran.dg/arithmetic_overflow_1.f90:8.26:

   integer(1) :: a(2) = (/ Z'FF', Z'FF' /) ! { dg-error "Arithmetic overflow" }
  1
Error: Arithmetic overflow converting INTEGER(16) to INTEGER(1) at (1). This
check can be disabled with the option -fno-range-check


-- 


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

[Bug c/45358] =+ oddness

[schwab at linux-m68k dot org]

--- Comment #2 from schwab at linux-m68k dot org  2010-08-20 15:35 ---
There is a lot of normal valid C we warn about...


-- 


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

[Bug c/45358] =+ oddness

[redi at gcc dot gnu dot org]

--- Comment #3 from redi at gcc dot gnu dot org  2010-08-20 15:36 ---
Yes, "if (b = 2)" is valid and -Wparentheses warns about that.

(In reply to comment #0)
> It would be nice if future version could at least throw a warning.

Obviously it can't be anything *more* than a warning.

N.B. at least in C++ there are valid reasons to use the + operator, such as
turning an lvalue into an rvalue.


-- 


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

[Bug target/45359] New: poor -march=native choices for VIA C7 Esther processors

[opod at nic-nac-project dot org]

C7 is a x86 CPU from VIA based on Esther (C5J) core evolved from the Nehemiah+
(C5P) core found in the C3-2 line.

/proc/cpuinfo
processor   : 0
vendor_id   : CentaurHauls
cpu family  : 6
model   : 10
model name  : VIA Esther processor  800MHz
stepping: 9
cpu MHz : 399.008
cache size  : 128 KB
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 1
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge cmov pat
clflush acpi mmx fxsr sse sse2 tm nx up pni est tm2 rng rng_en ace ace_en ace2
ace2_en phe phe_en pmm pmm_en
bogomips: 798.02
clflush size: 64
cache_alignment : 64
address sizes   : 36 bits physical, 32 bits virtual

gcc -v -fverbose-asm -march=native -S test.c
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-pc-linux-gnu/4.5.1/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ../configure --prefix=/usr
--enable-languages=c,c++,fortran,objc,obj-c++,ada --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
--enable-gnu-unique-object --enable-lto --enable-plugin --disable-multilib
--disable-libstdcxx-pch --with-system-zlib --with-ppl --with-cloog
--libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info
Thread model: posix
gcc version 4.5.1 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-fverbose-asm'  '-S'
 /usr/lib/gcc/i686-pc-linux-gnu/4.5.1/cc1 -quiet -v test.c -march=pentium-m
-mtune=generic -quiet -dumpbase test.c -auxbase test -version -fverbose-asm -o
test.s
[snip]

cat test.s
# GNU C (GCC) version 4.5.1 (i686-pc-linux-gnu)
#   compiled by GNU C version 4.5.1, GMP version 5.0.1, MPFR version
3.0.0-p3, MPC version 0.8.2
# GGC heuristics: --param ggc-min-expand=63 --param ggc-min-heapsize=62811
# options passed:  test.c -march=pentium-m -mtune=generic -fverbose-asm
# options enabled:  -falign-loops -fargument-alias -fauto-inc-dec
# -fbranch-count-reg -fcommon -fdelete-null-pointer-checks -fdwarf2-cfi-asm
# -fearly-inlining -feliminate-unused-debug-types -ffunction-cse -fgcse-lm
# -fident -finline-functions-called-once -fira-share-save-slots
# -fira-share-spill-slots -fivopts -fkeep-static-consts
# -fleading-underscore -fmath-errno -fmerge-debug-strings
# -fmove-loop-invariants -fpcc-struct-return -fpeephole
# -fsched-critical-path-heuristic -fsched-dep-count-heuristic
# -fsched-group-heuristic -fsched-interblock -fsched-last-insn-heuristic
# -fsched-rank-heuristic -fsched-spec -fsched-spec-insn-heuristic
# -fsched-stalled-insns-dep -fshow-column -fsigned-zeros
# -fsplit-ivs-in-unroller -ftrapping-math -ftree-cselim -ftree-forwprop
# -ftree-loop-im -ftree-loop-ivcanon -ftree-loop-optimize
# -ftree-parallelize-loops= -ftree-phiprop -ftree-pta -ftree-reassoc
# -ftree-scev-cprop -ftree-slp-vectorize -ftree-vect-loop-version
# -funit-at-a-time -fvect-cost-model -fverbose-asm
# -fzero-initialized-in-bss -m32 -m80387 -m96bit-long-double
# -maccumulate-outgoing-args -malign-stringops -mfancy-math-387
# -mfp-ret-in-387 -mfused-madd -mglibc -mieee-fp -mmmx -mno-red-zone
# -mno-sse4 -mpush-args -msahf -msse -msse2 -mtls-direct-seg-refs


-- 
   Summary: poor -march=native choices for VIA C7 Esther processors
   Product: gcc
   Version: 4.5.1
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: opod at nic-nac-project dot org
GCC target triplet: i686-pc-linux-gnu


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

[Bug c/45358] =+ oddness

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2010-08-20 16:02 ---
I think we certainly don't want to warn for = +, or =/**/+, so if anything,
there could be a warning for = token immediately followed by a token that makes
a valid = token (i.e. the same file, same line, column 1 above the =
column).


-- 


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

[Bug target/45336] pextr{b,w,d}, (worse than) redundant extensions

[hjl dot tools at gmail dot com]

--- Comment #7 from hjl dot tools at gmail dot com  2010-08-20 16:54 ---
Created an attachment (id=21531)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21531&action=view)
A patch

I talked to icc people. They think the return value should be
zero-extended to reflex what hardware does. However, we need to
optimize out sign_extend in:

(insn:TI 9 7 10 (set (reg:SI 0 ax [orig:68 D.6819 ] [68])
(zero_extend:SI (vec_select:QI (reg:V16QI 21 xmm0 [orig:64 x ] [64])
(parallel [
(const_int 4 [0x4])
]
/export/build/gnu/gcc/build-x86_64-linux/gcc/include/smmintrin.h:442 1681
{*sse4_1_pextrb}
 (expr_list:REG_DEAD (reg:V16QI 21 xmm0 [orig:64 x ] [64])
(nil)))

(insn:TI 10 9 18 (set (reg:DI 0 ax [orig:67 D.6819 ] [67])
(sign_extend:DI (reg:SI 0 ax [orig:68 D.6819 ] [68]))) foo.c:3 126
{extendsidi2_rex64}
 (nil))


-- 


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

[Bug target/45360] New: arm: -mhard-float != -mfloat-abi=hard during linking

[yselkowitz at users dot sourceforge dot net]

The GCC manual (ARM Options) states that -mhard-float is "equivalent to
-mfloat-abi=hard".  However that does seem to be the case when it comes to
linking:

$ arm-elf-gcc -mfloat-abi=hard -print-file-name=libc.a
/usr/lib/gcc/arm-elf/4.5.1/../../../../arm-elf/lib/fpu/libc.a

$ arm-elf-gcc -mhard-float -print-file-name=libc.a
/usr/lib/gcc/arm-elf/4.5.1/../../../../arm-elf/lib/libc.a

$ arm-elf-gcc -mfloat-abi=hard -v -o hello hello.c
...
COLLECT_GCC_OPTIONS='-mfloat-abi=hard' '-v' '-o' 'hello'
 /usr/lib/gcc/arm-elf/4.5.1/../../../../arm-elf/bin/as.exe -mfloat-abi=hard -o
/tmp/ccBX7XJa.o /tmp/ccm5rZK3.s
COMPILER_PATH=/usr/lib/gcc/arm-elf/4.5.1/:/usr/lib/gcc/arm-elf/4.5.1/:/usr/lib/gcc/arm-elf/:/usr/lib/gcc/arm-elf/4.5.1/:/usr/lib/gcc/arm-elf/:/usr/lib/gcc/arm-elf/4.5.1/../../../../arm-elf/bin/
LIBRARY_PATH=/usr/lib/gcc/arm-elf/4.5.1/fpu/:/usr/lib/gcc/arm-elf/4.5.1/../../../../arm-elf/lib/fpu/:/usr/lib/gcc/arm-elf/4.5.1/:/usr/lib/gcc/arm-elf/4.5.1/../../../../arm-elf/lib/:/usr/arm-elf/sys-root/usr/lib/
COLLECT_GCC_OPTIONS='-mfloat-abi=hard' '-v' '-o' 'hello'
 /usr/lib/gcc/arm-elf/4.5.1/collect2.exe --sysroot=/usr/arm-elf/sys-root -X -o
hello /usr/lib/gcc/arm-elf/4.5.1/fpu/crti.o
/usr/lib/gcc/arm-elf/4.5.1/fpu/crtbegin.o
/usr/lib/gcc/arm-elf/4.5.1/../../../../arm-elf/lib/fpu/crt0.o
-L/usr/lib/gcc/arm-elf/4.5.1/fpu
-L/usr/lib/gcc/arm-elf/4.5.1/../../../../arm-elf/lib/fpu
-L/usr/lib/gcc/arm-elf/4.5.1
-L/usr/lib/gcc/arm-elf/4.5.1/../../../../arm-elf/lib
-L/usr/arm-elf/sys-root/usr/lib /tmp/cc4pxySH.o --start-group -lgcc -lc
--end-group /usr/lib/gcc/arm-elf/4.5.1/fpu/crtend.o
/usr/lib/gcc/arm-elf/4.5.1/fpu/crtn.o


$ arm-elf-gcc -mhard-float -v  -o hello hello.c
...
COLLECT_GCC_OPTIONS='-mhard-float' '-v' '-o' 'hello'
 /usr/lib/gcc/arm-elf/4.5.1/../../../../arm-elf/bin/as.exe -mfloat-abi=hard -o
/tmp/ccQgFiBi.o /tmp/ccv7qPvG.s
COMPILER_PATH=/usr/lib/gcc/arm-elf/4.5.1/:/usr/lib/gcc/arm-elf/4.5.1/:/usr/lib/gcc/arm-elf/:/usr/lib/gcc/arm-elf/4.5.1/:/usr/lib/gcc/arm-elf/:/usr/lib/gcc/arm-elf/4.5.1/../../../../arm-elf/bin/
LIBRARY_PATH=/usr/lib/gcc/arm-elf/4.5.1/:/usr/lib/gcc/arm-elf/4.5.1/../../../../arm-elf/lib/:/usr/arm-elf/sys-root/usr/lib/
COLLECT_GCC_OPTIONS='-mhard-float' '-v' '-o' 'hello'
 /usr/lib/gcc/arm-elf/4.5.1/collect2.exe --sysroot=/usr/arm-elf/sys-root -X -o
hello /usr/lib/gcc/arm-elf/4.5.1/crti.o /usr/lib/gcc/arm-elf/4.5.1/crtbegin.o
/usr/lib/gcc/arm-elf/4.5.1/../../../../arm-elf/lib/crt0.o
-L/usr/lib/gcc/arm-elf/4.5.1
-L/usr/lib/gcc/arm-elf/4.5.1/../../../../arm-elf/lib
-L/usr/arm-elf/sys-root/usr/lib /tmp/ccQgFiBi.o --start-group -lgcc -lc
--end-group /usr/lib/gcc/arm-elf/4.5.1/crtend.o
/usr/lib/gcc/arm-elf/4.5.1/crtn.o


Note that -mhard-float is translated to -mfloat-abi=hard when passed to the
assembler but the fpu "multilibs" aren't added to LIBRARY_PATH, resulting in
linking with the soft-float crt*.o and libraries.


-- 
   Summary: arm: -mhard-float != -mfloat-abi=hard during linking
   Product: gcc
   Version: 4.5.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yselkowitz at users dot sourceforge dot net
 GCC build triplet: i686-pc-cygwin
  GCC host triplet: i686-pc-cygwin
GCC target triplet: arm-elf


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

[Bug fortran/36158] Transformational function BESSEL_YN(n1,n2,x) and BESSEL_JN missing

[burnus at gcc dot gnu dot org]

--- Comment #8 from burnus at gcc dot gnu dot org  2010-08-20 17:23 ---
Created an attachment (id=21532)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21532&action=view)
Run-time implementation

Possibly final patch, though not yet regtested.


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

  Attachment #21526|0   |1
is obsolete||


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

[Bug middle-end/45361] New: gcc.target/i386/volatile-2.c failed

[hjl dot tools at gmail dot com]

On Linux/x86-64. revision 163402 gave

FAIL: gcc.target/i386/volatile-2.c scan-assembler movl[ \\t]obj_5,


-- 
   Summary: gcc.target/i386/volatile-2.c failed
   Product: gcc
   Version: 4.5.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
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=45361

[Bug fortran/36158] Transformational function BESSEL_YN(n1,n2,x) and BESSEL_JN missing

[burnus at gcc dot gnu dot org]

--- Comment #9 from burnus at gcc dot gnu dot org  2010-08-20 17:50 ---
(In reply to comment #8)
> Created an attachment (id=21532)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21532&action=view) [edit]
> Possibly final patch, though not yet regtested.

Fails for:
  integer :: x(2)
  x = [1,2]
  print *, RESHAPE([x], [1,2])
  end

Probably due to trans-intrinsics.c change of copying the formal arg list - even
though it looks OK in the debugger. I could not yet trace down where exactly it
fails. GDB/valgrind show the line:

 Invalid read of size 4
at 0x57A7F9: gfc_conv_procedure_call (trans-expr.c:2755)
by 0x58AF4E: conv_generic_with_optional_char_arg.constprop.32
(trans-intrinsic.c:3326)
by 0x58BBDA: gfc_conv_intrinsic_function (trans-intrinsic.c:4917)

but trans-expr.c:2755 is the line where gfc_conv_procedure_call is defined,
which does not help me with debugging :-(


-- 


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

[Bug testsuite/45361] gcc.target/i386/volatile-2.c failed

[ubizjak at gmail dot com]

--- Comment #1 from ubizjak at gmail dot com  2010-08-20 17:57 ---
This is testsuite problem, on x86_64 we have:

movl$0, obj_5(%rip)
movlobj_5(%rip), %eax

vs.

movl$0, obj_5
movlobj_5, %eax

on x86_32.

So, scan patterns should be updated to include (%rip) after the reference.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Component|middle-end  |testsuite
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-08-20 17:57:15
   date||


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

[Bug rtl-optimization/45353] ICE: RTL check: expected elt 3 type 'B', have '0' (rtx barrier) in sel_bb_head, at sel-sched-ir.c:4329 with -fselective-scheduling and __builtin_unreachable()

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2010-08-20 18:07 ---
Subject: Bug 45353

Author: jakub
Date: Fri Aug 20 18:07:12 2010
New Revision: 163412

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163412
Log:
PR rtl-optimization/45353
* sel-sched-ir.c (sel_bb_head): Return NULL even if next_nonnote_insn
after bb_note is a BARRIER.

* gcc.dg/pr45353.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr45353.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/sel-sched-ir.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug testsuite/45361] gcc.target/i386/volatile-2.c failed

[nathan at gcc dot gnu dot org]

--- Comment #2 from nathan at gcc dot gnu dot org  2010-08-20 18:12 ---
Thanks Uros.  Could you prepare a patch to match the x86_64 output -- given you
have the hardware?


-- 


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

[Bug rtl-optimization/45353] ICE: RTL check: expected elt 3 type 'B', have '0' (rtx barrier) in sel_bb_head, at sel-sched-ir.c:4329 with -fselective-scheduling and __builtin_unreachable()

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2010-08-20 18:35 ---
Fixed.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug middle-end/44974] [4.6 Regression] Function with attribute noreturn omits a call to another function with noreturn

[jakub at gcc dot gnu dot org]

--- Comment #6 from jakub at gcc dot gnu dot org  2010-08-20 18:49 ---
Subject: Bug 44974

Author: jakub
Date: Fri Aug 20 18:49:46 2010
New Revision: 163415

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163415
Log:
PR middle-end/44974
* builtins.c (expand_builtin): Don't optimize away
calls to DECL_LOOPING_CONST_OR_PURE_P builtins.

* gcc.dg/pr44974.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr44974.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/builtins.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug preprocessor/45362] New: Dangling reference about saved cpp_macro for push/pop macro

[ktietz at gcc dot gnu dot org]

The issue is that for the push/pop macro the old state of the macro (a
cpp_macro reference) is stored. As this structure is handled by GC without a
root, all get free'ed when garbage collection happens.
This gc can lead to issues when such a saved node gets undefined and the node,
which previously hold the cpp_macro reference, gets reused for a different
macro. As the linked in the saved macro list isn't under control of gc and it
doesn't have a gc root element, the stored reference gets invalid in such cases
and can lead to segmentation faults due access to already free'ed memory.


-- 
   Summary: Dangling reference about saved cpp_macro for push/pop
macro
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ktietz at gcc dot gnu dot org
GCC target triplet: *-*-*


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

[Bug middle-end/44974] [4.6 Regression] Function with attribute noreturn omits a call to another function with noreturn

[jakub at gcc dot gnu dot org]

--- Comment #7 from jakub at gcc dot gnu dot org  2010-08-20 18:56 ---
Fixed.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug testsuite/45361] gcc.target/i386/volatile-2.c failed

[uros at gcc dot gnu dot org]

--- Comment #3 from uros at gcc dot gnu dot org  2010-08-20 19:24 ---
Subject: Bug 45361

Author: uros
Date: Fri Aug 20 19:23:52 2010
New Revision: 163416

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163416
Log:
PR testsuite/45361
* gcc.target/i386/volatile-2.c: Update scan strings to also
include (%rip) for the memory reference on x86_64.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/volatile-2.c


-- 


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

[Bug c/45358] Diagnostic could be issued for old C style a =+ b and similar cases

[steven at gcc dot gnu dot org]

-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|minor   |enhancement
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
  GCC build triplet|x86_64-linux-gnu|
   GCC host triplet|x86_64-linux-gnu|
 GCC target triplet|x86_64-linux-gnu|
   Keywords||diagnostic
   Last reconfirmed|-00-00 00:00:00 |2010-08-20 19:46:42
   date||
Summary|=+ oddness  |Diagnostic could be issued
   ||for old C style  a =+ b and
   ||similar cases


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

[Bug testsuite/45361] gcc.target/i386/volatile-2.c failed

[ubizjak at gmail dot com]

--- Comment #4 from ubizjak at gmail dot com  2010-08-20 20:49 ---
Fixed.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 GCC target triplet||x86_64-pc-linux-gnu
 Resolution||FIXED
   Target Milestone|--- |4.6.0
Version|4.5.3   |4.6.0


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

[Bug target/45336] pextr{b,w,d}, (worse than) redundant extensions

[jakub at gcc dot gnu dot org]

--- Comment #8 from jakub at gcc dot gnu dot org  2010-08-20 20:54 ---
Subject: Bug 45336

Author: jakub
Date: Fri Aug 20 20:54:25 2010
New Revision: 163420

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163420
Log:
PR target/45336
* config/i386/sse.md (*sse4_1_pextrb): Add SWI48 mode iterator
to cover zero extension into 64-bit register.
(*sse2_pextrw): Likewise.
(*sse4_1_pextrd_zext): New insn.

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


-- 


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

[Bug target/45336] pextr{b,w,d}, (worse than) redundant extensions

[hjl at gcc dot gnu dot org]

--- Comment #9 from hjl at gcc dot gnu dot org  2010-08-20 20:58 ---
Subject: Bug 45336

Author: hjl
Date: Fri Aug 20 20:57:56 2010
New Revision: 163421

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163421
Log:
Cast to unsigned short/char first for _mm_extract_epi16/_mm_extract_epi8.

gcc/

2010-08-20  H.J. Lu  

PR target/45336
* config/i386/emmintrin.h (_mm_extract_epi16): Cast to unsigned
short first.

* config/i386/smmintrin.h (_mm_extract_epi8): Cast to unsigned
char first.

gcc/testsuite/

2010-08-20  H.J. Lu  

PR target/45336
* gcc.target/i386/pr45336-1.c: New.
* gcc.target/i386/pr45336-2.c: Likewise.
* gcc.target/i386/pr45336-3.c: Likewise.
* gcc.target/i386/pr45336-4.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr45336-1.c
trunk/gcc/testsuite/gcc.target/i386/pr45336-2.c
trunk/gcc/testsuite/gcc.target/i386/pr45336-3.c
trunk/gcc/testsuite/gcc.target/i386/pr45336-4.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/emmintrin.h
trunk/gcc/config/i386/smmintrin.h
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug target/45363] New: libgcc fails to configure: cc1: internal compiler error: Illegal instruction: 4

[gerald at pfeifer dot com]

This is the relevant part from sparc64-portbld-freebsd8.0/libgcc/config.log:

configure:3211: checking for suffix of object files
configure:3233: /usr/ports/lang/gcc45/work/build/./gcc/xgcc
-B/usr/ports/lang/gcc45/work/build/./gcc/
-B/usr/local/sparc64-portbld-freebsd8.0/bin/
-B/usr/local/sparc64-portbld-freebsd8.0/lib/ -isystem
/usr/local/sparc64-portbld-freebsd8.0/include -isystem
/usr/local/sparc64-portbld-freebsd8.0/sys-include-c -O2 -pipe -g
-I/usr/local/include -fno-strict-aliasing  conftest.c >&5
cc1: internal compiler error: Illegal instruction: 4
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
configure:3237: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "GNU C Runtime Library"
| #define PACKAGE_TARNAME "libgcc"
| #define PACKAGE_VERSION "1.0"
| #define PACKAGE_STRING "GNU C Runtime Library 1.0"
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE_URL "http://www.gnu.org/software/libgcc/";   
| /* end confdefs.h.  */
|
| int
| main ()
| {
|
|   ;
|   return 0;
| }


-- 
   Summary: libgcc fails to configure: cc1: internal compiler error:
Illegal instruction: 4
   Product: gcc
   Version: 4.5.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gerald at pfeifer dot com
  GCC host triplet: sparc64-portbld-freebsd8.0


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

[Bug target/45363] libgcc fails to configure: cc1: internal compiler error: Illegal instruction: 4

[gerald at pfeifer dot com]

--- Comment #1 from gerald at pfeifer dot com  2010-08-20 21:22 ---
Created an attachment (id=21533)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21533&action=view)
Full sparc64-portbld-freebsd8.0/libgcc/config.log file


-- 


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

[Bug target/45363] libgcc fails to configure: cc1: internal compiler error: Illegal instruction: 4

[ebotcazou at gcc dot gnu dot org]

--- Comment #2 from ebotcazou at gcc dot gnu dot org  2010-08-20 22:00 
---
It looks like the cc1 compiler is miscompiled.  Which stage of the bootstrap is
this?  Could you post a backtrace of cc1 from within gdb when it executes the
illegal instruction?  Is that a recent problem on the 4.5 branch?


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |WAITING
Version|4.5.3   |4.5.2


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

[Bug fortran/45337] gfortran accepts pointer initialization of DT dummy arguments w/ INTENT(OUT)

[burnus at gcc dot gnu dot org]

--- Comment #11 from burnus at gcc dot gnu dot org  2010-08-20 22:28 ---
(In reply to comment #7)
> Untested patch:

The patch is not sufficient as the following example shows for which no warning
is printed:

type t
end type t
type t2
  integer :: j = 7
end type t2
contains
  subroutine x(a, b, c)
type(t) ,intent(OUT) :: a = t() ! Wrong
type(t2) ,intent(OUT) :: b = t2() ! Wrong
type(t2) ,intent(OUT) :: c ! OK, default initializer
end subroutine x
end


-- 


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

[Bug tree-optimization/45260] [4.5/4.6 Regression] g++4.5: -prefetch-loop-arrays internal compiler error: in verify_expr, at tree-cfg.c:2541

[changpeng dot fang at amd dot com]

--- Comment #5 from changpeng dot fang at amd dot com  2010-08-20 22:48 
---
I have a fix:
http://gcc.gnu.org/ml/gcc-patches/2010-08/msg01625.html


-- 


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

[Bug middle-end/45230] gcc.c-torture/execute/strncmp-1.c ICEs with -fgraphite-identity

[spop at gcc dot gnu dot org]

--- Comment #3 from spop at gcc dot gnu dot org  2010-08-20 23:50 ---
Subject: Bug 45230

Author: spop
Date: Fri Aug 20 23:49:58 2010
New Revision: 163432

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163432
Log:
Add testcase for PR45230.

2010-08-20  Sebastian Pop  

PR middle-end/45230
* gcc.dg/graphite/id-pr45230.c: New.

Added:
branches/graphite/gcc/testsuite/gcc.dg/graphite/id-pr45230.c
Modified:
branches/graphite/gcc/ChangeLog.graphite


-- 


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

[Bug java/41991] gcj segfaults on i686-apple-darwin9 and x86_64-apple-darwin9

[howarth at nitro dot med dot uc dot edu]

--- Comment #50 from howarth at nitro dot med dot uc dot edu  2010-08-21 
00:31 ---
According to the darwin unwinder maintainers in the Snow Leopard libunwind
sources...

// The following functions are implemented to just call abort
_Unwind_GetDataRelBase
_Unwind_GetTextRelBase
_Unwind_FindEnclosingFunction

//  The following functions are empty and do nothing
__register_frame_info_bases
__register_frame_info
__register_frame_info_table_bases
__register_frame_info_table
__register_frame_table
__deregister_frame_info
__deregister_frame_info_bases


-- 


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

[Bug target/45336] pextr{b,w,d}, (worse than) redundant extensions

[tbptbp at gmail dot com]

--- Comment #10 from tbptbp at gmail dot com  2010-08-21 00:49 ---
Subject: Re:  pextr{b,w,d}, (worse than) redundant extensions

A quick check vs trunk tells me that not only pextr* are now sane but
about 2% movs*/movz* disappeared altogether (in that particular
binary).
Hat's off.


-- 


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

[Bug java/41991] gcj segfaults on i686-apple-darwin9 and x86_64-apple-darwin9

[howarth at nitro dot med dot uc dot edu]

--- Comment #51 from howarth at nitro dot med dot uc dot edu  2010-08-21 
00:55 ---
An additional clarification from the darwin unwinder developers on the status
of the libunwind sources from Snow Leopard...

> Everything down in the darwin layer is supposed to be open source.  It was
> a glitch that our libunwind did not get the right sign offs to make that
> happen in SnowLeopard.
>
> A fork was made in libunwind and incorporated into the open source lldb  
> project.  You can view those sources at:
> 
> http://llvm.org/svn/llvmproject/lldb/trunk/source/Plugins/Process/Utility/libunwind/src/UnwindLevel1-gcc-ext.c
>


-- 


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

[Bug middle-end/45364] New: Apparent infinite loop while compiling wine's directx.c with -O1 -g

[bero at arklinux dot org]

Building the attached code with

gcc -m32 -O1 -g -c directx.i -o test.o

takes forever.

On a machine where
gcc -m32 -O0 -g -c directx.i -o test.o
finishes in 2.9 seconds and
gcc -m32 -O2 -c directx.i -o test.o
finishes in 15 seconds, I left
gcc -m32 -O2 -g -c directx.i -o test.o
running overnight and it still didn't finsh - either something is incredibly
slow, or (more likely) it hits an infinite loop somewhere.


-- 
   Summary: Apparent infinite loop while compiling wine's directx.c
with -O1 -g
   Product: gcc
   Version: 4.5.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bero at arklinux dot org
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug middle-end/45364] Apparent infinite loop while compiling wine's directx.c with -O1 -g

[bero at arklinux dot org]

--- Comment #1 from bero at arklinux dot org  2010-08-21 01:00 ---
Created an attachment (id=21534)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21534&action=view)
test case


-- 


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

[Bug middle-end/45364] Compiling wine's directx.c with -O1 -g takes a very long time

[bero at arklinux dot org]

--- Comment #2 from bero at arklinux dot org  2010-08-21 01:10 ---
Assumed it was an infinite loop a bit too early -- it did finish after giving
it some more time.

There is a speed problem though. Updating summary and severity.


-- 

bero at arklinux dot org changed:

   What|Removed |Added

   Severity|normal  |enhancement
Summary|Apparent infinite loop while|Compiling wine's directx.c
   |compiling wine's directx.c  |with -O1 -g takes a very
   |with -O1 -g |long time


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

[Bug java/41991] gcj segfaults on i686-apple-darwin9 and x86_64-apple-darwin9

[howarth at nitro dot med dot uc dot edu]

--- Comment #52 from howarth at nitro dot med dot uc dot edu  2010-08-21 
02:24 ---
Also the additional clarification that...

> The UnwindLevel1-gcc-ext.c source file in lldb is the same as in SnowLeopard.


-- 


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

[Bug target/45365] New: X86 FP add and multiply aren't commutative

[hjl dot tools at gmail dot com]

According to table 4-7 in chapter 4, Vol 1 of
IA32/Inte64 SDM, x86 FP add and multiply aren't
commutative with Qnan/Snan inputs. But we have

DEF_RTL_EXPR(PLUS, "plus", "ee", RTX_COMM_ARITH)
DEF_RTL_EXPR(MULT, "mult", "ee", RTX_COMM_ARITH)

That impacts x86 FP plus and mult patterns. Should
we introduce a new target option to disable x86
commutative FP plus and mult?


-- 
   Summary: X86 FP add and multiply aren't commutative
   Product: gcc
   Version: 4.5.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com


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

[Bug target/45365] X86 FP add and multiply aren't commutative

[hjl dot tools at gmail dot com]

--- Comment #1 from hjl dot tools at gmail dot com  2010-08-21 03:54 ---
[...@gnu-6 intrin]$ cat mulpd.c
#include 
#include 
#include 
#include 

__m128d a;
__m128d b;
uint64_t av[] = {0x0, 0xfff8ULL};
uint64_t bv[] = {0xffefULL, 0x7fff2d4db6efd985ULL};
uint64_t expa[] = {0x8000ULL, 0xfff8ULL};
uint64_t expb[] = {0x8000ULL, 0x7fff2d4db6efd985ULL};

void check_mulpd(__m128d const* op0, __m128d const* op1,
 uint64_t *exp)
{
__m128d r = _mm_mul_pd (*op0, *op1);;
if (memcmp (&r, exp, sizeof (r)))
  abort ();
}

int main()
{
memcpy(&a, av, sizeof(a));
memcpy(&b, bv, sizeof(b));
check_mulpd(&a, &b, expa);
check_mulpd(&b, &a, expb);
return 0;
}
[...@gnu-6 intrin]$ make
gcc -g -o o0 mulpd.c
gcc -g -O2 -o o2 mulpd.c
./o2
./o0
make: *** [all] Aborted
[...@gnu-6 intrin]$ 


-- 


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

[Bug target/45365] X86 FP add and multiply aren't commutative

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2010-08-21 03:58 ---
How are they are not commutative with respect of the NaNs?  Is it only when
both are operands are NaNs, it causes an issue?  


If I read your testcase correctly, x87 and SSE both don't do IEEE FP correctly
with respect of NaNs.  For multiply and add if either operand is a NaN, the
result is also a NaN IIRC.


-- 


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

[Bug target/45365] X86 FP add and multiply aren't commutative

[hjl dot tools at gmail dot com]

--- Comment #3 from hjl dot tools at gmail dot com  2010-08-21 04:10 ---
(In reply to comment #2)
> How are they are not commutative with respect of the NaNs?  Is it only when
> both are operands are NaNs, it causes an issue?  
> 
> 
> If I read your testcase correctly, x87 and SSE both don't do IEEE FP correctly
> with respect of NaNs.  For multiply and add if either operand is a NaN, the
> result is also a NaN IIRC.

The difference is QNaN and SNaN. They are both NaNs, but not the same.


-- 


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

[Bug target/45365] X86 FP add and multiply aren't commutative

[hjl dot tools at gmail dot com]

--- Comment #4 from hjl dot tools at gmail dot com  2010-08-21 04:14 ---
(In reply to comment #2)
> How are they are not commutative with respect of the NaNs?  Is it only when
> both are operands are NaNs, it causes an issue?  
> 

Yes, only when both operands and NaNs with SSE FP.


-- 


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

[Bug bootstrap/44905] --enable-build-with-cxx bootstrap failure compiling gcc/cppdefault.c

[howarth at nitro dot med dot uc dot edu]

--- Comment #4 from howarth at nitro dot med dot uc dot edu  2010-08-21 
04:20 ---
Fixed with...

Author: lcwu
Date: Fri Jul 23 22:20:45 2010
New Revision: 162492

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162492
Log:
Fix violations of self-assignment check in GCC source.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/dbxout.c
trunk/gcc/omega.c
trunk/gcc/tree-ssa-ccp.c


-- 

howarth at nitro dot med dot uc dot edu changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug testsuite/45361] gcc.target/i386/volatile-2.c failed

[howarth at nitro dot med dot uc dot edu]

--- Comment #5 from howarth at nitro dot med dot uc dot edu  2010-08-21 
05:11 ---
The fix at r163416 caused...


FAIL: gcc.target/i386/volatile-2.c scan-assembler movl[ \t][^,]+,
obj_0(\\(%rip\\))?
FAIL: gcc.target/i386/volatile-2.c scan-assembler movl[ \t][^,]+,
obj_1(\\(%rip\\))?
FAIL: gcc.target/i386/volatile-2.c scan-assembler movl[ \t][^,]+,
obj_2(\\(%rip\\))?
FAIL: gcc.target/i386/volatile-2.c scan-assembler movl[ \t][^,]+,
obj_3(\\(%rip\\))?
FAIL: gcc.target/i386/volatile-2.c scan-assembler movl[ \t][^,]+,
obj_4(\\(%rip\\))?
FAIL: gcc.target/i386/volatile-2.c scan-assembler movl[ \t][^,]+,
obj_5(\\(%rip\\))?
FAIL: gcc.target/i386/volatile-2.c scan-assembler movl[ \t]obj_5(\\(%rip\\))?,
FAIL: gcc.target/i386/volatile-2.c scan-assembler movl[ \t][^,]+,
obj_6(\\(%rip\\))?
FAIL: gcc.target/i386/volatile-2.c scan-assembler movl[ \t][^,]+,
obj_7(\\(%rip\\))?
FAIL: gcc.target/i386/volatile-2.c scan-assembler movl[ \t][^,]+,
obj_8(\\(%rip\\))?

on x86_64-apple-darwin10 at -m32.


-- 


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

[Bug middle-end/45364] Compiling wine's directx.c with -O1 -g takes a very long time

[hjl dot tools at gmail dot com]

--- Comment #3 from hjl dot tools at gmail dot com  2010-08-21 05:13 ---
On Linux/Intel64, I got

time /usr/gcc-4.5/bin/gcc -m32 -O2  pr45364.i -g -c  /tmp
/usr/gcc-4.5/bin/gcc -m32 -O2 pr45364.i -g -c  110.63s user 0.17s system 99%
cpu 1:50.87 total
[...@gnu-6 tmp]$ /usr/gcc-4.5/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/usr/gcc-4.5/bin/gcc
COLLECT_LTO_WRAPPER=/usr/gcc-4.5/libexec/gcc/x86_64-unknown-linux-gnu/4.5.1/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /net/gnu-13/export/gnu/src/gcc-4.5/gcc/configure
--enable-clocale=gnu --with-system-zlib --enable-checking=assert
--with-demangler-in-ld --enable-shared --enable-threads=posix --enable-haifa
--prefix=/usr/gcc-4.5 --with-local-prefix=/usr/local --with-plugin-ld=ld.gold
--enable-gold --with-fpmath=sse
Thread model: posix
gcc version 4.5.1 (GCC) 
[...@gnu-6 tmp]$ 


-- 


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

[Bug testsuite/45361] gcc.target/i386/volatile-2.c failed

[howarth at nitro dot med dot uc dot edu]

--- Comment #6 from howarth at nitro dot med dot uc dot edu  2010-08-21 
05:15 ---
Created an attachment (id=21535)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21535&action=view)
assembly file for gcc.target/i386/volatile-2.c at -m32 on x86_64-apple-darwin10


-- 


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

[Bug testsuite/45361] gcc.target/i386/volatile-2.c failed

[howarth at nitro dot med dot uc dot edu]

--- Comment #7 from howarth at nitro dot med dot uc dot edu  2010-08-21 
05:16 ---
Assembly created with...

/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/
/sw/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20100820/gcc/testsuite/gcc.target/i386/volatile-2.c
-O2 -S -m32 -o volatile-2.s

using...


Using built-in specs.
COLLECT_GCC=gcc-4COLLECT_LTO_WRAPPER=/sw/lib/gcc4.6/libexec/gcc/x86_64-apple-darwin10.5.0/4.6.0/lto-wrapper
Target: x86_64-apple-darwin10.5.0
Configured with: ../gcc-4.6-20100820/configure --prefix=/sw
--prefix=/sw/lib/gcc4.6 --mandir=/sw/share/man --infodir=/sw/lib/gcc4.6/info
--enable-languages=c,c++,fortran,objc,obj-c++,java --with-gmp=/sw
--with-libiconv-prefix=/sw --with-ppl=/sw --with-cloog=/sw --with-mpc=/sw
--with-system-zlib --enable-build-with-cxx --x-includes=/usr/X11R6/include
--x-libraries=/usr/X11R6/lib --program-suffix=-fsf-4.6 --enable-lto
--enable-checking=yes
Thread model: posix
gcc version 4.6.0 20100821 (experimental) (GCC) 


-- 


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

[Bug target/41323] Add new _mm_extract_epu16 intrinsic (resquest)

[hjl dot tools at gmail dot com]

--- Comment #5 from hjl dot tools at gmail dot com  2010-08-21 05:21 ---


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


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug target/45336] pextr{b,w,d}, (worse than) redundant extensions

[hjl dot tools at gmail dot com]

--- Comment #11 from hjl dot tools at gmail dot com  2010-08-21 05:21 
---
*** Bug 41323 has been marked as a duplicate of this bug. ***


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 CC||etjq78kl at free dot fr


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

[Bug testsuite/45361] gcc.target/i386/volatile-2.c failed

[ubizjak at gmail dot com]

--- Comment #8 from ubizjak at gmail dot com  2010-08-21 06:19 ---
Add:

/* { dg-require-effective-target nonpic } */

to the testcase.


-- 


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

[Bug testsuite/45361] gcc.target/i386/volatile-2.c failed

[ubizjak at gmail dot com]

--- Comment #9 from ubizjak at gmail dot com  2010-08-21 06:22 ---
Index: gcc.target/i386/volatile-2.c
===
--- gcc.target/i386/volatile-2.c(revision 163421)
+++ gcc.target/i386/volatile-2.c(working copy)
@@ -1,4 +1,5 @@
 /* { dg-do compile } */
+/* { dg-require-effective-target nonpic } */
 /* { dg-options "-O2" } */

 /* Check volatiles are written, read or not re-read consistently */


-- 


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

[Bug c++/45315] [4.4/4.5/4.6 Regression] ICE: tree check: expected aggr_init_expr, have call_expr in build_value_init, at cp/init.c:317

[jason at gcc dot gnu dot org]

--- Comment #4 from jason at gcc dot gnu dot org  2010-08-21 06:27 ---
Fixed.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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