[Bug tree-optimization/45714] [4.6 Regression] Vectorization of double pow function causes a segmentation fault

[irar at il dot ibm dot com]

--- Comment #3 from irar at il dot ibm dot com  2010-09-19 08:52 ---
gimple_bb (stmt) returns NULL for that statement (D.1575_33 = __builtin_pow
(D.1542_14, D.1574_32)).

We can avoid vectorization in such cases, but looks like it should be fixed to
return the actual basic block.

Ira


-- 


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

[Bug libstdc++/45725] streambuf_iterator compares equal when it should not

[paolo dot carlini at oracle dot com]

--- Comment #1 from paolo dot carlini at oracle dot com  2010-09-19 09:18 
---
(In reply to comment #0)
> bool std::operator==( std::istreambuf_iterator, std::istreambuf_iterator )
> returns TRUE if both iterators are EOF or both are not.  That means two
> iterators at different places in the streambuf -- which, when dereferenced
> produce different characters -- nevertheless compare as equal.  This is
> inconsistent with how other iterators work, and inconsistent with the pointer
> model of iterators.

Maybe, but this is how, exactly those iterators are specified to behave, see
24.5.3.5 and 24.5.3.6 in the ISO C++ Standard which we are implementing. Also
note that the current draft of the next ISO C++ Standard doesn't change that.
Thus, as implementors, there is nothing we can do here, I'm sorry.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug tree-optimization/45714] [4.6 Regression] Vectorization of double pow function causes a segmentation fault

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2010-09-19 09:40 ---
(In reply to comment #3)
> gimple_bb (stmt) returns NULL for that statement (D.1575_33 = __builtin_pow
> (D.1542_14, D.1574_32)).
> 
> We can avoid vectorization in such cases, but looks like it should be fixed to
> return the actual basic block.

If it returns NULL then that stmt was not properly inserted into the insn
stream (or removed).

> Ira
> 


-- 


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

[Bug c/45726] New: Thumb2 instruction emitted for incompatible CPU

[rafael dot carre at gmail dot com]

% cat test.c   
union prop_data_t
{
unsigned int u;
struct
{
unsigned short s1;
unsigned short s2;
};
};

union prop_data_t broken (int a, int b)
{
union prop_data_t var;

if (a)
{
var.s2 = 0;
var.s2 = b ? a : 2;
if (var.s2)
return var;
}

var.u = 0;
return var;
}
% echo $CC
/usr/local/arm-elf-eabi-cvs/bin/arm-elf-eabi-gcc
% $CC -mcpu=arm9tdmi -c test.c -O -pipe   
{standard input}: Assembler messages:
{standard input}:25: Error: selected processor does not support ARM mode
`movteq r0,2'
% $CC -mcpu=arm9tdmi -c test.c -Ofast -pipe
{standard input}: Assembler messages:
{standard input}:23: Error: selected processor does not support ARM mode
`movteq r3,2'
% $CC -mcpu=arm9tdmi -c test.c -pipe   
% $CC -v   
Using built-in specs.
COLLECT_GCC=/usr/local/arm-elf-eabi-cvs/bin/arm-elf-eabi-gcc
COLLECT_LTO_WRAPPER=/usr/local/arm-elf-eabi-cvs/libexec/gcc/arm-elf-eabi/4.6.0/lto-wrapper
Target: arm-elf-eabi
Configured with: ../gcc-4.6-20100918/configure
--prefix=/usr/local/arm-elf-eabi-cvs --target=arm-elf-eabi --enable-lto
--enable-languages=c --disable-docs --disable-libssp
Thread model: single
gcc version 4.6.0 20100918 (experimental) (GCC) 
%

Using 20100918 snapshot

reduced from
http://svn.rockbox.org/viewvc.cgi/trunk/apps/plugins/goban/sgf.c?revision=20001&view=markup

I tried to see which optimization broke with -Ox -Q --help=optimizers but the
list printed doesn't seem to be complete.


-- 
   Summary: Thumb2 instruction emitted for incompatible CPU
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rafael dot carre at gmail dot com
GCC target triplet: arm-elf-eabi


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

[Bug tree-optimization/45714] [4.6 Regression] Vectorization of double pow function causes a segmentation fault

[irar at il dot ibm dot com]

--- Comment #5 from irar at il dot ibm dot com  2010-09-19 10:08 ---
Right. This patch fixes it:

Index: tree-vect-stmts.c
===
--- tree-vect-stmts.c   (revision 164332)
+++ tree-vect-stmts.c   (working copy)
@@ -4478,6 +4478,7 @@ vect_transform_stmt (gimple stmt, gimple
 case call_vec_info_type:
   gcc_assert (!slp_node);
   done = vectorizable_call (stmt, gsi, &vec_stmt);
+  stmt = gsi_stmt (*gsi);
   break;

 case reduc_vec_info_type:

I am going to test it now.

Thanks,
Ira


-- 


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

[Bug tree-optimization/45580] [4.6 Regression] Building WebKit fails with compiler catching SIGSEGV in gimple_fold_obj_type_ref_known_binfo()

[rguenth at gcc dot gnu dot org]

--- Comment #11 from rguenth at gcc dot gnu dot org  2010-09-19 10:19 
---
Created an attachment (id=21832)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21832&action=view)
patch

Patch I'm testing.  The call isn't a virtual one, so in principle the FE lied
to us here (probably ignoring the placement new itself).  So we can try to
recover.  The propagation part ensures the original ICE happens at first CCP
pass already.

Now - we should be able to extract the method we call from

:
  jsNull ();
  MEM[(struct NonNullPassRefPtr *)&D.2023] = D.2021_16(D);
  JSObject::JSObject (&MEM[(struct JSByteArray *)&cell].D.1813, D.2023);
  MEM[(struct JSByteArray *)&cell].D.1813.D.1778._vptr.JSCell =
&_ZTV11JSByteArray[2];
  MEM[(struct JSByteArray *)&cell].m_classInfo = 0B;
  D.1967_8 = MEM[(struct JSCell *)&cell]._vptr.JSCell;
  D.1968_9 = *D.1967_8;
  D.1968_9 (&cell);

but FRE only manages to simplify it down to

  D.1967_8 = &_ZTV11JSByteArray[2];
  D.1968_9 = *D.1967_8;
  D.1968_9 (&cell);

I suppose that's where Honza's SCCVN folding will eventually help.  At DOM:

  D.1968_9 = _ZTV11JSByteArray[2];
  D.1968_9 (&cell);

but maybe we are confused by the vtable being weak:

.weak   _ZTV11JSByteArray
.section   
.rodata._ZTV11JSByteArray,"aG",@progbits,_ZTV11JSByteArray,comdat
.align 8
.type   _ZTV11JSByteArray, @object
.size   _ZTV11JSByteArray, 16
_ZTV11JSByteArray:
.long   0
.long   _ZTI11JSByteArray
.long   _ZN11JSByteArrayD1Ev
.long   _ZN11JSByteArrayD0Ev

though .rodata means we should have folded it anyway.


-- 


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

[Bug tree-optimization/43959] [4.6 Regression] FAIL: gcc.dg/torture/builtin-cproj-1.c -O1 (test for excess errors)

[rguenth at gcc dot gnu dot org]

--- Comment #17 from rguenth at gcc dot gnu dot org  2010-09-19 11:10 
---
Ah.  The following fixes it for me on a cross.  Can you bootstrap & regtest and
install it?  It's pre-approved if it works for you.

Thanks.

Index: gcc/function.c
===
--- gcc/function.c  (revision 164396)
+++ gcc/function.c  (working copy)
@@ -3578,7 +3578,7 @@ gimplify_parameters (void)
   && compare_tree_int (DECL_SIZE_UNIT (parm),
STACK_CHECK_MAX_VAR_SIZE) > 0))
{
- local = create_tmp_var (type, get_name (parm));
+ local = create_tmp_reg (type, get_name (parm));
  DECL_IGNORED_P (local) = 0;
  /* If PARM was addressable, move that flag over
 to the local copy, as its address will be taken,
@@ -3592,7 +3592,7 @@ gimplify_parameters (void)
  tree ptr_type, addr;

  ptr_type = build_pointer_type (type);
- addr = create_tmp_var (ptr_type, get_name (parm));
+ addr = create_tmp_reg (ptr_type, get_name (parm));
  DECL_IGNORED_P (addr) = 0;
  local = build_fold_indirect_ref (addr);



-- 


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

[Bug c/45726] Thumb2 instruction emitted for incompatible CPU

[mikpe at it dot uu dot se]

--- Comment #1 from mikpe at it dot uu dot se  2010-09-19 11:15 ---
I see the same on arm-linux-gnueabi with 4.6-20100907 and 4.5-20100916.  It
happens regardless of whether I pass -mcpu=arm9tdmi, -mcpu=armv5tel, or no
-mcpu= at all.


-- 

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

[Bug lto/45727] New: ICE: in subreg_get_info, at rtlanal.c:3092

[rafael dot carre at gmail dot com]

% /usr/local/arm-elf-eabi-cvs/bin/arm-elf-eabi-gcc -v 
Using built-in specs.
COLLECT_GCC=/usr/local/arm-elf-eabi-cvs/bin/arm-elf-eabi-gcc
COLLECT_LTO_WRAPPER=/usr/local/arm-elf-eabi-cvs/libexec/gcc/arm-elf-eabi/4.6.0/lto-wrapper
Target: arm-elf-eabi
Configured with: ../gcc-4.6-20100918/configure
--prefix=/usr/local/arm-elf-eabi-cvs --target=arm-elf-eabi --enable-lto
--enable-languages=c --disable-docs --disable-libssp
Thread model: single
gcc version 4.6.0 20100918 (experimental) (GCC) 

% make
/usr/local/arm-elf-eabi-cvs/bin/arm-elf-eabi-gcc -mthumb-interwork -nostdlib
-flto -pipe -Os spc_cpu.o spc_emu.o stubs.o spc_dsp.o spc.o -lgcc
In file included from /media/bordel/rockbox/apps/codecs/spc.c:433:0,
 from /media/bordel/rockbox/apps/codecs/spc.c:595,
 from /media/bordel/rockbox/apps/codecs/libspc/spc_dsp.c:782,
 from stubs.i:24,
 from /media/bordel/rockbox/apps/codecs/libspc/spc_emu.c:326,
 from /media/bordel/rockbox/apps/codecs/libspc/spc_cpu.c:865,
 from :18:
/media/bordel/rockbox/apps/codecs/libspc/spc_dsp.c: In function 'DSP_run_':
/media/bordel/rockbox/apps/codecs/libspc/spc_dsp.c:1446:9: error: can't find a
register in class 'LO_REGS' while reloading 'asm'
/media/bordel/rockbox/apps/codecs/libspc/spc_dsp.c:1568:1: internal compiler
error: in subreg_get_info, at rtlanal.c:3092
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
lto-wrapper: /usr/local/arm-elf-eabi-cvs/bin/arm-elf-eabi-gcc returned 1 exit
status
collect2: lto-wrapper returned 1 exit status
make: *** [a.out] Error 1
% wc -l *.i
  4251 spc_cpu.i
  4137 spc_dsp.i
  3717 spc_emu.i
  3713 spc.i
   103 stubs.i
 15921 total



Note: the bug I first wanted to report is different, I only encountered the ICE
in the process.
Should I open a new bug report with the content following?

% sed -i s/-Os// Makefile 
% make
/usr/local/arm-elf-eabi-cvs/bin/arm-elf-eabi-gcc -mthumb-interwork -nostdlib
-flto -pipe  spc_cpu.o spc_emu.o stubs.o spc_dsp.o spc.o -lgcc
In file included from /media/bordel/rockbox/apps/codecs/libspc/spc_dsp.c:773:0,
 from stubs.i:24,
 from /media/bordel/rockbox/apps/codecs/libspc/spc_emu.c:326,
 from /media/bordel/rockbox/apps/codecs/libspc/spc_cpu.c:865,
 from :18:
/media/bordel/rockbox/apps/codecs/spc.c: In function 'codec_main':
/media/bordel/rockbox/apps/codecs/spc.c:536:19: internal compiler error: in
insert_value_copy_on_edge, at tree-outof-ssa.c:243
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
{standard input}: Assembler messages:
{standard input}:11421: Error: lo register required -- `ldrsh r8,[r1]'
{standard input}:11422: Error: Thumb does not support this addressing mode --
`ldrsh r5,[r3]'
{standard input}:11423: Error: Thumb does not support this addressing mode --
`ldrsh r6,[r1,#2]'
{standard input}:11424: Error: Thumb does not support this addressing mode --
`ldrsh r4,[r3,#2]'
{standard input}:11425: Error: lo register required -- `mul r9,r8,r5'
{standard input}:11426: Error: lo register required -- `ldrsh r8,[r1,#4]'
{standard input}:11427: Error: Thumb does not support this addressing mode --
`ldrsh r5,[r2,#2]'
{standard input}:11428: Error: selected processor does not support Thumb mode
`mla r9,r6,r4,r9'
{standard input}:11429: Error: Thumb does not support this addressing mode --
`ldrsh r6,[r1,#6]'
{standard input}:11430: Error: Thumb does not support this addressing mode --
`ldrsh r4,[r2]'
{standard input}:11431: Error: selected processor does not support Thumb mode
`mla r9,r8,r5,r9'
{standard input}:11432: Error: selected processor does not support Thumb mode
`mla r9,r6,r4,r9'
{standard input}:11457: Error: shifts in CMP/MOV instructions are only
supported in unified syntax -- `mov r5,r4,asr#11'
{standard input}:11458: Error: dest must overlap one source register -- `mul
r4,r5,r3'
{standard input}:11481: Error: shifts in CMP/MOV instructions are only
supported in unified syntax -- `mov r4,r4,asr#11'
{standard input}:11482: Error: dest must overlap one source register -- `mul
r6,r4,r3'
{standard input}:11483: Error: dest must overlap one source register -- `mul
r5,r4,r2'
{standard input}:11531: Error: lo register required -- `ldrsh r8,[r1]'
{standard input}:11532: Error: Thumb does not support this addressing mode --
`ldrsh r5,[r3]'
{standard input}:11533: Error: Thumb does not support this addressing mode --
`ldrsh r6,[r1,#2]'
{standard input}:11534: Error: Thumb does not support this addressing mode --
`ldrsh r4,[r3,#2]'
{standard input}:11535: Error: lo register required -- `mul r9,r5,r8'
{standard input}:11536: Error: Thumb does not support this addressing mode --
`ldrsh r5,[r2,#2]'
{standard input}:11537: Error: dest must overlap one source register -- `mul
r8,r4,r6'
{standard input}:11538: Err

[Bug lto/45727] ICE: in subreg_get_info, at rtlanal.c:3092

[rafael dot carre at gmail dot com]

--- Comment #1 from rafael dot carre at gmail dot com  2010-09-19 11:35 
---
Created an attachment (id=21833)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21833&action=view)
testcase


-- 


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

[Bug target/43297] [4.4 regression] -O2 -fPIC breaks htmlnorm.c

[ebotcazou at gcc dot gnu dot org]

--- Comment #6 from ebotcazou at gcc dot gnu dot org  2010-09-19 12:07 
---
Created an attachment (id=21834)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21834&action=view)
More reduced testcase


-- 


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

[Bug target/43297] [4.4 regression] -O2 -fPIC breaks htmlnorm.c

[ebotcazou at gcc dot gnu dot org]

--- Comment #7 from ebotcazou at gcc dot gnu dot org  2010-09-19 12:16 
---
Fixed in latest 4.4.x snapshot:

ebotca...@grobluk:~$ gcc -v
Using built-in specs.
Target: sparc64-unknown-linux-gnu
Configured with: /home/ebotcazou/src-4.4/configure
--prefix=/home/ebotcazou/install-4.4 --enable-languages=c --with-cpu=v8
Thread model: posix
gcc version 4.4.5 20100914 (prerelease) (GCC)


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work|4.3.3   |4.3.3 4.5.1 4.6.0
 Resolution||FIXED


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

[Bug lto/45448] FAIL: gcc.dg/lto/20090116 c_lto_20090116_0.o-c_lto_20090116_0.o link, -O1 -fwhopr -fPIC (internal compiler error)

[t66667 at gmail dot com]

--- Comment #4 from t7 at gmail dot com  2010-09-19 12:17 ---
2nd ICE from PR45727 show same lto problem.


-- 


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

[Bug target/42775] sparc-linux 4.4.2 fails to rebuild itself when using STAGE1_CFLAGS=-O1

[ebotcazou at gcc dot gnu dot org]

--- Comment #5 from ebotcazou at gcc dot gnu dot org  2010-09-19 12:19 
---
Investigating.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 CC|ebotcazou at gcc dot gnu dot|
   |org |
 AssignedTo|unassigned at gcc dot gnu   |ebotcazou at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2010-01-18 08:41:23 |2010-09-19 12:19:49
   date||


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

[Bug target/45701] [4.6 Regression] Fail to prefer using r3 for padding a push/pop multiple to 8-byte alignment

[qiyao at gcc dot gnu dot org]

--- Comment #2 from qiyao at gcc dot gnu dot org  2010-09-19 13:19 ---
In arm.c:arm_get_frame_offsets (void)

  if (!crtl->tail_call_emit
  && arm_size_return_regs () <= 12
  && (offsets->saved_regs_mask & (1 << 3)) == 0)
{
  reg = 3;
}

In gcc-4.5, crtl->tail_call_emit is always false, so the condition is true. 
However, in gcc-4.6, crtl->tail_call_emit can be true.  My stupid question is
'why can't we use r3 when we do tail call optimization?'.  I read one sentence
in comment, 'We try to avoid using the arg registers (r0 -r3) as they might be 
used to pass values in a tail call.'.  Is it the answer to my question?

If that is the answer, in oder to fix this bug, we may refine the condition to
'tail call insns are emitted, and r3 is used to pass values to tail call', like
this,

  if (!(crtl->tail_call_emit && used_to_pass_values (3))
   && ...
   && ...)

Is this a correct fix?


-- 


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

[Bug lto/45727] ICE: in subreg_get_info, at rtlanal.c:3092

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2010-09-19 13:23 ---
Yes, please open a new bugreport for that.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|ICE: in subreg_get_info, at |ICE: in subreg_get_info, at
   |rtlanal.c:3092  |rtlanal.c:3092


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

[Bug tree-optimization/45714] [4.6 Regression] Vectorization of double pow function causes a segmentation fault

[irar at gcc dot gnu dot org]

--- Comment #6 from irar at gcc dot gnu dot org  2010-09-19 14:23 ---
Subject: Bug 45714

Author: irar
Date: Sun Sep 19 14:23:40 2010
New Revision: 164420

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

PR tree-optimization/45714
* tree-vect-stmts.c (vect_transform_stmt): Use a dummy statement 
created in vectorizable_call instead of the original statement in 
def stmt updates.


Added:
trunk/gcc/testsuite/gfortran.dg/vect/pr45714-a.f
trunk/gcc/testsuite/gfortran.dg/vect/pr45714-b.f
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-stmts.c


-- 


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

[Bug tree-optimization/43959] [4.6 Regression] FAIL: gcc.dg/torture/builtin-cproj-1.c -O1 (test for excess errors)

[dave at hiauly1 dot hia dot nrc dot ca]

--- Comment #18 from dave at hiauly1 dot hia dot nrc dot ca  2010-09-19 
14:53 ---
Subject: Re:  [4.6 Regression] FAIL: gcc.dg/torture/builtin-cproj-1.c  -O1 
(test for excess errors)

> Ah.  The following fixes it for me on a cross.  Can you bootstrap & regtest 
> and
> install it?  It's pre-approved if it works for you.

Will test and install if successful.

Dave


-- 


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

[Bug bootstrap/45445] [4.6 regression] ARM bootstrap failure: comparison failures after stage 3

[mikpe at it dot uu dot se]

--- Comment #14 from mikpe at it dot uu dot se  2010-09-19 15:30 ---
On the trivial sreal.c test case the dumps (-fdump-rtl-all -fdump-tree-all)
from stage1 and stage2 start to diverge at `150r.expand':

diff -ru dumps1/sreal.c.150r.expand dumps2/sreal.c.150r.expand
--- dumps1/sreal.c.150r.expand  2010-09-19 17:20:07.0 +0200
+++ dumps2/sreal.c.150r.expand  2010-09-19 17:20:36.0 +0200
@@ -26,8 +26,8 @@

 (insn 7 6 8 3 (parallel [
 (set (reg:DI 137)
-(plus:DI (reg:DI 136)
-(reg:DI 136)))
+(ashift:DI (reg:DI 136)
+(const_int 1 [0x1])))
 (clobber (reg:CC 24 cc))
 ]) sreal.c:3 -1
  (nil))

The immediately preceeding dump (149t.optimized) is as follows for both stages:

;; Function normalize (normalize)

normalize (long long unsigned int * sreal_sig)
{
  long long unsigned int D.2004;
  long long unsigned int D.2003;

:
  D.2003_2 = *sreal_sig_1(D);
  D.2004_3 = D.2003_2 << 1;
  *sreal_sig_1(D) = D.2004_3;
  return;

}

I'll try mixing stage1 and stage2 .o files next.


-- 


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

[Bug bootstrap/45445] [4.6 regression] ARM bootstrap failure: comparison failures after stage 3

[mikpe at it dot uu dot se]

--- Comment #15 from mikpe at it dot uu dot se  2010-09-19 16:29 ---
The code generation difference originates from `expmed.o'.  Using stage1's
expmed.o with stage2's other .o files I get 'adds', using stage2's expmed.o
with stage1's other .o files I get 'lsls'.


-- 


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

[Bug bootstrap/45445] [4.6 regression] ARM bootstrap failure: comparison failures after stage 3

[laurent at guerby dot net]

--- Comment #16 from laurent at guerby dot net  2010-09-19 16:54 ---
expmed.c:make_tree has some non deterministic calls:

tree
make_tree (tree type, rtx x)
{
...
case PLUS:
  return fold_build2 (PLUS_EXPR, type, make_tree (type, XEXP (x, 0)),
  make_tree (type, XEXP (x, 1)));
...


-- 


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

[Bug rtl-optimization/45728] New: ICE: in gen_lowpart_general, at rtlhooks.c:59 at -O1 when comparing union members

[zsojka at seznam dot cz]

PR33380 and PR40199 look similiar, but this might be different.

Compiler output:
$ gcc -O testcase.c
testcase.c: In function 'foo':
testcase.c:13:11: internal compiler error: in gen_lowpart_general, at
rtlhooks.c:59
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Tested revisions:
r164287 - crash
r153685 - crash
4.5 r163761 - crash
4.4 r160770 - crash
4.4 r149995 - crash


-- 
   Summary: ICE: in gen_lowpart_general, at rtlhooks.c:59 at -O1
when comparing union members
   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=45728

[Bug rtl-optimization/45728] ICE: in gen_lowpart_general, at rtlhooks.c:59 at -O1 when comparing union members

[zsojka at seznam dot cz]

--- Comment #1 from zsojka at seznam dot cz  2010-09-19 18:09 ---
Created an attachment (id=21835)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21835&action=view)
reduced testcase

$ gcc -O pr45728.c


-- 


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

Where was the relief? What could

[Cassiano Felch]

traitor, who breaks the sacred oath he has sworn." "Maria," cried
Peter angrily, approaching with a threatening gesture. She drew her
slender figure up to its full height and with quickened breath
awaited him, pointing her finger at him, as she exclaimed with a
sharp tone perceptible through the slight tremor
in her voice: "You, you have voted with the Baersdorps, you, Peter
Van der Werff! You have done this thing, you, the friend of the
Prince, the shield and providence of this brave city, you, the man
who received the oaths of the citizens, the martyr's son, the servant
of liberty--"
"No more!" he interrupted, trembling with shame and rage. "Do you
know what it is to bear the guilt
of this most terrible suffering
before God and men?" "Yes, yes, thrice yes; it is laying one's heart
on the rack, to save Holland and liberty.
That is what it means! Oh, God,
my God! You are lost! You intend to negotiate with Valdez!" "And
suppose I do?" asked the burgomaster, with an angry gesture. Maria
looked him sternly

in the eye, and exclaimed in a loud, resolute tone: "Then it will be
my turn to say: Go to Delft; we need different
men here." The burgomaster turned pale and bent his eyes
on the floor, while she fearlessly confronted him with a steady
glance. The light fell full upon her glowing face, and when Peter
again raised his eyes, it seemed as if the same Maria stood before
him, who as
a bride had
vowed to share trouble and peril with him, remain steadfast in the
struggle
<>

[Bug middle-end/33380] Internal compiler error: in gen_lowpart_general, at rtlhooks.c:62

[jakub at gcc dot gnu dot org]

--- Comment #6 from jakub at gcc dot gnu dot org  2010-09-19 18:50 ---
Can't reproduce with either current trunk nor 4.4.4.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug lto/45729] New: -flto conflicts with -mthumb

[rafael dot carre at gmail dot com]

% cat thumb.i 
int _start(void)
{
extern int f(void);
return f();
}

% cat arm.i 
int f(void)
{
int ret;
asm ("\tmov %0, #0x200\n" : "=r"(ret));
return ret;
}

% /usr/local/arm-elf-eabi-cvs/bin/arm-elf-eabi-gcc -O -flto -mthumb-interwork
thumb.i -c -mthumb   
% /usr/local/arm-elf-eabi-cvs/bin/arm-elf-eabi-gcc -O -flto -mthumb-interwork
arm.i -c  
% /usr/local/arm-elf-eabi-cvs/bin/arm-elf-eabi-gcc -O -flto -mthumb-interwork
arm.o thumb.o -lgcc -nostdlib
/tmp/cc6zNKqK.s: Assembler messages:
/tmp/cc6zNKqK.s:20: Error: invalid immediate: 512 is out of range
lto-wrapper: /usr/local/arm-elf-eabi-cvs/bin/arm-elf-eabi-gcc returned 1 exit
status
collect2: lto-wrapper returned 1 exit status
% /usr/local/arm-elf-eabi-cvs/bin/arm-elf-eabi-gcc -O -flto -mthumb-interwork
arm.o thumb.o -lgcc -nostdlib -mthumb   
/tmp/ccIIQlpY.s: Assembler messages:
/tmp/ccIIQlpY.s:20: Error: invalid immediate: 512 is out of range
lto-wrapper: /usr/local/arm-elf-eabi-cvs/bin/arm-elf-eabi-gcc returned 1 exit
status
collect2: lto-wrapper returned 1 exit status
% /usr/local/arm-elf-eabi-cvs/bin/arm-elf-eabi-gcc -O -flto -mthumb-interwork
arm.o thumb.o -lgcc -nostdlib -mno-thumb


% /usr/local/arm-elf-eabi-cvs/bin/arm-elf-eabi-gcc -v   
Using built-in specs.
COLLECT_GCC=/usr/local/arm-elf-eabi-cvs/bin/arm-elf-eabi-gcc
COLLECT_LTO_WRAPPER=/usr/local/arm-elf-eabi-cvs/libexec/gcc/arm-elf-eabi/4.6.0/lto-wrapper
Target: arm-elf-eabi
Configured with: ../gcc-4.6-20100918/configure
--prefix=/usr/local/arm-elf-eabi-cvs --target=arm-elf-eabi --enable-lto
--enable-languages=c --disable-docs --disable-libssp
Thread model: single
gcc version 4.6.0 20100918 (experimental) (GCC) 


I am not sure what is wrong here:

If -mthumb is not specified during linking, I would expect -flto to generate
ARM code which is interworked properly with existing thumb code
If -mthumb is explicited, I would expect -flto to generate Thumb code which is
interworked properly with existing ARM code


Linking with -mno-thumb on a larger binary (rockbox) shows that the binary is
using both Thumb and ARM,
does it mean that -flto doesn't regenerate assembler for every file from the
GIMPLE representation?


-- 
   Summary: -flto conflicts with -mthumb
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rafael dot carre at gmail dot com
GCC target triplet: arm-elf-eabi


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

[Bug libfortran/45723] opening /dev/null for appending writes

[jvdelisle at gcc dot gnu dot org]

--- Comment #1 from jvdelisle at gcc dot gnu dot org  2010-09-19 20:01 
---
This is an OS specific error.  libgfortran is attempting to seek to the end of
the file to prepare for appending.  Obviously, one can not seek /dev/null.

I will see if we can detect that the file is unseekable and if that is the case
we can start appending AS-IS.


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jvdelisle at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-09-19 20:01:18
   date||


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

[Bug middle-end/45722] [4.6 Regression] FAIL: gcc.c-torture/execute/20040709-2.c execution at -O1 and -Os

[dave at hiauly1 dot hia dot nrc dot ca]

--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca  2010-09-19 
20:09 ---
Subject: Re:  [4.6 Regression] FAIL:
gcc.c-torture/execute/20040709-2.c execution at -O1 and -Os

This bug was introduced in revision 164136.  My comment about 164202
being ok was somehow wrong.

Attached .s files from revisions 164135 and 164136.


--- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca  2010-09-19 
20:09 ---
Created an attachment (id=21836)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21836&action=view)


--- Comment #6 from dave at hiauly1 dot hia dot nrc dot ca  2010-09-19 
20:09 ---
Created an attachment (id=21837)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21837&action=view)


-- 


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

[Bug c++/45606] [4.5/4.6 Regression] match a method prototyped a typedef alias with the original type (using stdlib)

[dodji at gcc dot gnu dot org]

--- Comment #4 from dodji at gcc dot gnu dot org  2010-09-19 20:33 ---
I rewrote the handling of typedef comparison to put canonical type comparison
back. I believe this approach is simpler and happens to fix this issue.

A candidate patch was sent to
http://gcc.gnu.org/ml/gcc-patches/2010-09/msg01525.html


-- 


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

[Bug lto/44246] ICE with -fwhopr/-flto when using strlen and strcat without previous declaration

[hubicka at gcc dot gnu dot org]

--- Comment #8 from hubicka at gcc dot gnu dot org  2010-09-19 21:49 ---
Subject: Bug 44246

Author: hubicka
Date: Sun Sep 19 21:49:28 2010
New Revision: 164425

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

PR lto/44246
* lto-cgraph.c (input_cgraph_1, input_varpool_1): Avoid
processing same node twice.
* gcc.c-torture/compile/pr44246.c:New file.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr44246.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/lto-cgraph.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug lto/44246] ICE with -fwhopr/-flto when using strlen and strcat without previous declaration

[hubicka at gcc dot gnu dot org]

--- Comment #9 from hubicka at gcc dot gnu dot org  2010-09-19 21:57 ---
Fixed.


-- 

hubicka at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug target/42775] [4.4 regression] GCC fails to rebuild itself with STAGE1_CFLAGS=-O1

[ebotcazou at gcc dot gnu dot org]

--- Comment #6 from ebotcazou at gcc dot gnu dot org  2010-09-19 21:58 
---
tree-ssa-operands.c:copy_virtual_operands is miscompiled by delay slot
scheduling so the workaround is to use STAGE1_CFLAGS="-O1 -fno-delayed-branch".
 Another way out is probably to configure with --disable-stage1-checking.


-- 


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

[Bug rtl-optimization/45728] ICE: in gen_lowpart_general, at rtlhooks.c:59 at -O1 when comparing union members

[zsojka at seznam dot cz]

--- Comment #2 from zsojka at seznam dot cz  2010-09-19 22:21 ---
Created an attachment (id=21838)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21838&action=view)
reduced testcase, fails with -m32

This testcase fails with -m32. The only difference is "float" instead of
"double" in "union U".

$ gcc -O pr45728_32.c -m32


-- 


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

[Bug libstdc++/45730] New: Undefined symbol __gnu_cxx::stdio_sync_filebuf >::xsgetn(char*, long)

[howarth at nitro dot med dot uc dot edu]

At r164422, on x86_64-apple-darwin10, the following libstdc++ test regressions
are present at both -m32/-m64...

FAIL: ext/stdio_sync_filebuf/char/1.cc (test for excess errors)
WARNING: ext/stdio_sync_filebuf/char/1.cc compilation failed to produce
executable
FAIL: ext/stdio_sync_filebuf/char/12048-3.cc (test for excess errors)
WARNING: ext/stdio_sync_filebuf/char/12048-3.cc compilation failed to produce
executable
FAIL: ext/stdio_sync_filebuf/char/12048-4.cc (test for excess errors)
WARNING: ext/stdio_sync_filebuf/char/12048-4.cc compilation failed to produce
executable
FAIL: ext/stdio_sync_filebuf/wchar_t/1.cc (test for excess errors)
WARNING: ext/stdio_sync_filebuf/wchar_t/1.cc compilation failed to produce
executable
FAIL: ext/stdio_sync_filebuf/wchar_t/12948-3.cc (test for excess errors)
WARNING: ext/stdio_sync_filebuf/wchar_t/12948-3.cc compilation failed to
produce executable
FAIL: ext/stdio_sync_filebuf/wchar_t/12948-4.cc (test for excess errors)
WARNING: ext/stdio_sync_filebuf/wchar_t/12948-4.cc compilation failed to
produce executable

These are all of the form...

Executing on host: /sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/./gcc/g++
-shared-libgcc -B/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/./gcc
-nostdinc++
-L/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/x86_64-apple-darwin10.5.0/i386/libstdc++-v3/src
-L/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/x86_64-apple-darwin10.5.0/i386/libstdc++-v3/src/.libs
-B/sw/lib/gcc4.6/x86_64-apple-darwin10.5.0/bin/
-B/sw/lib/gcc4.6/x86_64-apple-darwin10.5.0/lib/ -isystem
/sw/lib/gcc4.6/x86_64-apple-darwin10.5.0/include -isystem
/sw/lib/gcc4.6/x86_64-apple-darwin10.5.0/sys-include -m32
-B/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/x86_64-apple-darwin10.5.0/i386/libstdc++-v3/src/.libs
-g -O2 -D_GLIBCXX_ASSERT -fmessage-length=0 -ffunction-sections -fdata-sections
-g -O2 -g -O2 -DLOCALEDIR="." -nostdinc++
-I/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/x86_64-apple-darwin10.5.0/i386/libstdc++-v3/include/x86_64-apple-darwin10.5.0
-I/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/x86_64-apple-darwin10.5.0/i386/libstdc++-v3/include
-I/sw/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20100919/libstdc++-v3/libsupc++
-I/sw/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20100919/libstdc++-v3/include/backward
-I/sw/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20100919/libstdc++-v3/testsuite/util
/sw/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20100919/libstdc++-v3/testsuite/ext/stdio_sync_filebuf/char/1.cc
   -include bits/stdc++.h ./libtestc++.a   -lm   -m32 -o ./1.exe(timeout =
600)
Undefined symbols:^M
  "__gnu_cxx::stdio_sync_filebuf >::xsgetn(char*,
int)", referenced from:
  test01()in ccoWrU4N.o
ld: symbol(s) not found
collect2: ld returned 1 exit status


Using built-in specs.
COLLECT_GCC=gcc-4
COLLECT_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-20100919/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 --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib
--program-suffix=-fsf-4.6 --enable-checking=yes
Thread model: posix
gcc version 4.6.0 20100919 (experimental) (GCC)


-- 
   Summary: Undefined symbol __gnu_cxx::stdio_sync_filebuf >::xsgetn(char*, long)
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
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=45730

[Bug libstdc++/45730] Undefined symbol __gnu_cxx::stdio_sync_filebuf >::xsgetn(char*, long)

[howarth at nitro dot med dot uc dot edu]

--- Comment #1 from howarth at nitro dot med dot uc dot edu  2010-09-20 
00:20 ---
Created an attachment (id=21839)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21839&action=view)
preprocessed source file for ext/stdio_sync_filebuf/char/1.cc at -m64


-- 


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

[Bug libstdc++/45730] Undefined symbol __gnu_cxx::stdio_sync_filebuf >::xsgetn(char*, long)

[howarth at nitro dot med dot uc dot edu]

--- Comment #2 from howarth at nitro dot med dot uc dot edu  2010-09-20 
00:21 ---
Created an attachment (id=21840)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21840&action=view)
assembly file for ext/stdio_sync_filebuf/char/1.cc at -m64


-- 


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

[Bug libstdc++/45730] Undefined symbol __gnu_cxx::stdio_sync_filebuf >::xsgetn(char*, long)

[howarth at nitro dot med dot uc dot edu]

--- Comment #3 from howarth at nitro dot med dot uc dot edu  2010-09-20 
00:26 ---
On x86_64-apple-darwin10 at -m64, we have...

nm libstdc++.6.dylib | grep xsgetn
00041f50 t
__ZN9__gnu_cxx18stdio_sync_filebufIcSt11char_traitsIcEE6xsgetnEPcl
00041eb0 t
__ZN9__gnu_cxx18stdio_sync_filebufIwSt11char_traitsIwEE6xsgetnEPwl
00068df0 T __ZNSt12__basic_fileIcE6xsgetnEPcl
0001a2c0 T __ZNSt13basic_filebufIcSt11char_traitsIcEE6xsgetnEPcl
0001a540 T __ZNSt13basic_filebufIwSt11char_traitsIwEE6xsgetnEPwl
0004cd40 T __ZNSt15basic_streambufIcSt11char_traitsIcEE6xsgetnEPcl
0004cb70 T __ZNSt15basic_streambufIwSt11char_traitsIwEE6xsgetnEPwl


-- 


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

[Bug tree-optimization/45622] Suboptimal code generation on arm

[hp at gcc dot gnu dot org]

--- Comment #1 from hp at gcc dot gnu dot org  2010-09-20 01:57 ---
I hacked around a similar suboptimality using -fno-tree-reassoc.
(...looking...)
See PR37916 (oops! still assigned to me; the easy route I envisioned became a
dead end).

Adding a preprocessed version of huffdec.c (use -save-temps, pick up huffdec.i)
to this PR would help, I think.


-- 


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

[Bug target/43104] Incorrect code generation for target mcu ATMega164P

[eric dot weddington at atmel dot com]

--- Comment #7 from eric dot weddington at atmel dot com  2010-09-20 02:25 
---
Closing bug as WORKSFORME.


-- 

eric dot weddington at atmel dot com changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||WORKSFORME


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

[Bug target/43088] [avr] Suspect optimizer missed code in gcc 4.4.3..

[eric dot weddington at atmel dot com]

--- Comment #2 from eric dot weddington at atmel dot com  2010-09-20 02:30 
---
(In reply to comment #1)
> This bug is confirmed. andhi3/andsi3 causing this problem. conditional checks
> in andhi3 and andsi3 need to compare with zero instead of 0xff [etc]. 
> i.e. in andhi3 we need to replace
> (mask & 0x00ff) != 0xff by (mask & 0x00ff) != 0.
> 
> Similarly other checks in andhi3 and andsi3 need to be replaced.
> 

Abnikant,

Is this bug confirmed for the reported version (4.4.3), or for trunk/4.6?


-- 

eric dot weddington at atmel dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-09-20 02:30:21
   date||


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

[Bug middle-end/42204] update_eliminables should be called in reload after something changes

[eric dot weddington at atmel dot com]

--- Comment #1 from eric dot weddington at atmel dot com  2010-09-20 02:45 
---
Andy, do you have a test case for this bug?


-- 

eric dot weddington at atmel dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug libstdc++/45730] Undefined symbol __gnu_cxx::stdio_sync_filebuf >::xsgetn(char*, long)

[howarth at nitro dot med dot uc dot edu]

--- Comment #4 from howarth at nitro dot med dot uc dot edu  2010-09-20 
02:57 ---
Regression caused by...

Author: hubicka
Date: Sat Sep 18 21:25:29 2010
New Revision: 164402

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

PR tree-optimization/45605
* cgraphunit.c (cgraph_analyze_functions): Allocate bitmap obstack.
* gimple-fold.c (static_object_in_other_unit_p): New function.
(canonicalize_constructor_val): Use it.
(get_symbol_constant_value): Be reaqdy for canonicalize_constructor_val
returning NULL.
(gimple_fold_obj_type_ref_known_binfo): Use
static_object_in_other_unit_p.


-- 


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

[Bug target/41894] wrong code with -fno-split-wide-types

[eric dot weddington at atmel dot com]

--- Comment #9 from eric dot weddington at atmel dot com  2010-09-20 03:03 
---
Closing as fixed in 4.5.0.


-- 

eric dot weddington at atmel dot com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.5.0


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

[Bug middle-end/41738] [4.3/4.4 Regression] optabs expands rotate using wrong mode

[eric dot weddington at atmel dot com]

--- Comment #4 from eric dot weddington at atmel dot com  2010-09-20 03:05 
---
Closing as fixed in 4.5.0.


-- 

eric dot weddington at atmel dot com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
   Target Milestone|4.4.5   |4.5.0


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

[Bug target/35507] [avr] 4.3.0: size of small funcion increases from 2 to 29 words

[eric dot weddington at atmel dot com]

--- Comment #6 from eric dot weddington at atmel dot com  2010-09-20 03:59 
---
Closed as fixed in 4.6.0.


-- 

eric dot weddington at atmel dot com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.6.0


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

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

[t66667 at gmail dot com]

--- Comment #13 from t7 at gmail dot com  2010-09-20 04:00 ---
Ok this ticket is getting very confusing now and no development recently.
 --- Comment #12 From Zdenek Sojka  2010-09-15 18:39  [reply] ---  
You are compiling it without graphite and yet you are using graphite branch to
test. Then you are getting another type of ICE.

--- Comment #10 From t66...@gmail.com  2010-09-15 00:17  [reply] ---  
Based on my observations the bug in PR45406 is triggered differently but with
the same ICE and different language C C++.

--- Comment #3 From Sebastian Pop  2010-08-20 23:50  [reply] ---  
Can you tell us a little more about what is going on in this PR45230.
Are you still working on the problem ?

If not I will detach PR45406 from this ticket.


-- 


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

[Bug c/45731] New: gcc 4.5.1 -march=corei7 fails

[dcy665 at gmail dot com]

hello.c:1: error: bad value (corei7) for -march= switch

although, gcc451 --help=target -march=corei7 is successful.

gcc 4.4.4-10.fc13 (fedora 13 distribution) fails as well.

gcc451 -march=generic produces .s code with -march=core2

configured with:
../gcc-4.5.1/configure --prefix=/usr/local --program-suffix=451
--enable-threads \
--enable-languages=c,c++


-- 
   Summary: gcc 4.5.1 -march=corei7 fails
   Product: gcc
   Version: 4.5.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dcy665 at gmail dot com


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

[Bug target/43088] [avr] Suspect optimizer missed code in gcc 4.4.3..

[abnikant dot singh at atmel dot com]

--- Comment #3 from abnikant dot singh at atmel dot com  2010-09-20 04:24 
---
(In reply to comment #2)
> (In reply to comment #1)
> > This bug is confirmed. andhi3/andsi3 causing this problem. conditional 
> > checks
> > in andhi3 and andsi3 need to compare with zero instead of 0xff [etc]. 
> > i.e. in andhi3 we need to replace
> > (mask & 0x00ff) != 0xff by (mask & 0x00ff) != 0.
> > 
> > Similarly other checks in andhi3 and andsi3 need to be replaced.
> > 
> 
> Abnikant,
> 
> Is this bug confirmed for the reported version (4.4.3), or for trunk/4.6?
> 

It exits for the reported version (4.4.3) and as well as for trunk/4.6.


-- 


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

[Bug target/45731] gcc 4.5.1 -march=corei7 fails

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2010-09-20 04:27 ---
>-march=corei7 is successful.

Yes and that is kinda expected as --help does not process options at all
really.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|c   |target


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

[Bug libfortran/45723] opening /dev/null for appending writes

[jvdelisle at gcc dot gnu dot org]

--- Comment #2 from jvdelisle at gcc dot gnu dot org  2010-09-20 04:46 
---
Created an attachment (id=21841)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21841&action=view)
Possible patch

This patch passes regression testing. Don't seek if filesize is zero.


-- 


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

[Bug target/45726] Thumb2 instruction emitted for incompatible CPU

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2010-09-20 04:52 ---
What binutils version are you using?

movteq is a valid ARM v7 instruction.


-- 


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

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

[zsojka at seznam dot cz]

--- Comment #14 from zsojka at seznam dot cz  2010-09-20 04:57 ---
(In reply to comment #13)
>  --- Comment #12 From Zdenek Sojka  2010-09-15 18:39  [reply] ---  
> You are compiling it without graphite and yet you are using graphite branch to
> test. Then you are getting another type of ICE.

-fgraphite-identity is enabled with -O[23s] in the graphite branch


-- 


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

[Bug target/45731] gcc 4.5.1 -march=corei7 fails

[dcy665 at gmail dot com]

--- Comment #2 from dcy665 at gmail dot com  2010-09-20 06:25 ---
And yet, it does not help (with or without dashes) that corei7 is claimed to be
supported and yet is not.

Either --target-help should not report support or gcc should actually support
it.


-- 


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

[Bug libfortran/45723] opening /dev/null for appending writes

[Joost dot VandeVondele at pci dot uzh dot ch]

--- Comment #3 from Joost dot VandeVondele at pci dot uzh dot ch  
2010-09-20 06:30 ---
(In reply to comment #2)
> Created an attachment (id=21841)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21841&action=view) [edit]
> Possible patch
> 
> This patch passes regression testing. Don't seek if filesize is zero.
> 
seems like a clean solution... thanks.


-- 


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

[Bug tree-optimization/45714] [4.6 Regression] Vectorization of double pow function causes a segmentation fault

[irar at il dot ibm dot com]

--- Comment #7 from irar at il dot ibm dot com  2010-09-20 06:43 ---
Fixed.


-- 

irar at il dot ibm dot com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug target/45694] fortran host associated variables+optimization==failure?

[jpr at csc dot fi]

--- Comment #2 from jpr at csc dot fi  2010-09-20 06:54 ---
Created an attachment (id=21842)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21842&action=view)
somewhat reduced testcase

Hi,

I tried debugging this more. Attached is a somewhat reduced testcase. I also 
had a look at the assembler generated by 
"x86_64-w64-mingw32-gfortran -save-temps -O1 fail1.f90".

The loadinp looks like  

...
loadinp_:
subq$56, %rsp
movl$1952671091, 32(%rsp)
movw$28521, 36(%rsp)
movb$110, 38(%rsp)
leaq32(%rsp), %r10
callparse_sect.1525
... so it stores the  'section' string to stack and loads %r10 with
the stack address and calls the parse_sect:

parse_sect.1525:
pushq   %rdi
pushq   %rsi
pushq   %rbx
movl$4032, %eax
call___chkstk
movq%r10, %rsi
   
which then uses the stack address in %r10. The thing is that the 
__chkstk() call  seems to change the contents of the
%r10. At least doing
...
movq %r10,%r12
call __chkstk
movq %r12,%r10
...
seems to cure the example. What is really going on, anyone?

Br, Juha


-- 


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

Re: build gcc (c,c++,ada) for ia64-hp-hpux11.23 fails

[hobi69]

Eric Botcazou-3 wrote:
> 
> 
> There is no full port of the Ada compiler to this platform in the FSF
> tree.
> You can only build a 64-bit Ada compiler with the unpatched sources.
> 
> -- 
> Eric Botcazou
> 
> 



Thank you very much for your informations and sorry for the delay - I have
been on vacation.
Do you know if there is any configuration option to force build 64bit only?

--
Birger Hoffmann  
-- 
View this message in context: 
http://old.nabble.com/build-gcc-%28c%2Cc%2B%2B%2Cada%29-for-ia64-hp-hpux11.23-fails-tp29612386p29756667.html
Sent from the gcc - bugs mailing list archive at Nabble.com.